Hiệu quả của kiểm thử tự động phụ thuộc vào việc chọn đúng tình huống, không phải viết càng nhiều script càng tốt. Bài viết giải thích vì sao hồi quy lặp lại, xác minh trên nhiều môi trường và chuẩn bị dữ liệu đáng được tự động hóa, trường hợp nào có tỷ lệ lợi ích/chi phí thấp và cách chạy song song với môi trường cô lập giúp tiết kiệm thời gian.
Bản thân kiểm thử tự động không tạo ra giá trị; giá trị chỉ xuất hiện khi các bài kiểm thử tự động thực sự được chạy. Nếu một dự án có hàng nghìn dòng script nhưng không ai bảo trì và tỷ lệ test case thất bại luôn cao, vấn đề thường không nằm ở công nghệ mà ở việc chọn sai tình huống để tự động hóa ngay từ đầu.
Việc dùng công cụ nào để chạy test case và so sánh kết quả thực tế với kết quả kỳ vọng đã là những kỹ thuật khá hoàn thiện. Điều thật sự cần cân nhắc là: công việc nào giao cho script thì có lợi, và công việc nào nên để con người xử lý.
Ba loại công việc đáng tự động hóa
Điển hình nhất là kiểm thử hồi quy lặp lại. Mỗi thay đổi mã đều có nguy cơ làm hỏng chức năng hiện có, và kiểm thử hồi quy phải liên tục xác minh cùng một nhóm chức năng. Thực hiện thủ công vừa chậm vừa dễ bỏ sót. Khi giao cho script, đội ngũ có thể chạy toàn bộ bộ kiểm thử sau mỗi vòng lặp; đây là một trong những khâu quan trọng nhất của quy trình tích hợp liên tục và triển khai liên tục.
Loại thứ hai là xác minh trên nhiều môi trường. Ứng dụng web và di động cần được kiểm tra khả năng tương thích trên nhiều trình duyệt và phiên bản hệ điều hành khác nhau; thử thủ công từng môi trường là không thực tế. Framework tự động hóa có thể mô phỏng hành vi người dùng ở nhiều môi trường, kiểm tra giao diện và chức năng có nhất quán hay không, đồng thời phát hiện sớm các vấn đề chỉ xuất hiện trong một số cấu hình nhất định.
Loại thứ ba là khâu chuẩn bị. Khởi tạo dữ liệu kiểm thử, chuẩn bị tài khoản và dọn dẹp môi trường gần như không cần phán đoán, nhưng lại rất tốn thời gian và phải lặp lại ở mỗi vòng hồi quy. Tự động hóa phần này thường mang lại lợi ích lớn hơn việc tiếp tục tối ưu chính các script kiểm thử.
Về phân lớp kiểm thử: kiểm thử đơn vị tập trung vào từng hàm hoặc phương thức, chạy nhanh và thường xuyên; kiểm thử tích hợp xác minh giao diện và tương tác giữa các mô-đun; kiểm thử chức năng mô phỏng thao tác người dùng theo logic nghiệp vụ; kiểm thử end-to-end bao phủ toàn bộ luồng từ giao diện qua backend đến lớp dữ liệu; kiểm thử hiệu năng xem xét thời gian phản hồi khi đồng thời cao và độ tin cậy khi chạy trong thời gian dài. Các lớp này nên được dùng kết hợp: lớp đơn vị bảo đảm tính đúng đắn cơ bản, tích hợp và chức năng xác nhận khả năng sử dụng của nghiệp vụ, end-to-end bảo vệ luồng chính, còn hồi quy ngăn một thay đổi làm hỏng nhiều phần khác.
Những tình huống không đáng tự động hóa
Đầu tiên là thao tác chỉ làm một lần. Với một lần di chuyển hệ thống hoặc kiểm tra tạm thời trước khi phát hành, thời gian viết script có thể dài hơn nhiều so với làm thủ công. Dự án giai đoạn sớm và thay đổi thường xuyên cũng tương tự: yêu cầu vẫn đang thay đổi, script phải thay đổi theo, và chi phí bảo trì có thể vượt lợi ích.
Những tình huống phụ thuộc nhiều vào đánh giá của con người cũng không phù hợp. Kiểm thử khám phá, đánh giá hình ảnh và trải nghiệm, xem câu chữ có gượng hay không hoặc tương tác có trực quan hay không đều không có kết quả kỳ vọng ổn định để script so sánh. Cách phân công hợp lý là để tự động hóa bảo vệ hồi quy, còn con người khám phá các ranh giới.
Hai nút thắt của chính framework
Selenium tương tác với trình duyệt thông qua driver, điều này hạn chế khả năng kiểm soát ở mức thấp, chẳng hạn thay đổi động điều kiện mạng hoặc điều chỉnh tham số dấu vân tay trình duyệt. Khi test case cần mô phỏng các thiết bị, mạng hoặc khu vực khác nhau, chỉ Selenium thường không bao phủ hết nhu cầu.
Một vấn đề khác là dấu vết tự động hóa. Khi framework mô phỏng thao tác của con người, nó thường để lại các đặc điểm có thể nhận diện, như thuộc tính trình duyệt cố định hoặc nhịp thao tác nhanh và đều. Nếu hệ thống đang được kiểm thử nhận ra hành vi của script, hệ thống có thể ngăn luồng tiếp tục. Với đội kiểm thử, kiểu gián đoạn này đôi khi khó chẩn đoán hơn một test case thất bại thông thường.
Chạy song song và cô lập môi trường
Nút thắt hiệu quả thường không nằm ở script mà ở việc môi trường chưa đủ thực tế, chưa đủ đa dạng, hoặc tất cả test case đều phải chờ cùng một môi trường. Tách riêng lớp môi trường sẽ cải thiện đáng kể: tạo hồ sơ môi trường trình duyệt độc lập cho từng nhóm kiểm thử, mỗi hồ sơ có hệ điều hành, múi giờ, độ phân giải màn hình, User Agent, loại trình duyệt, vị trí địa lý và ngôn ngữ riêng để các test case chạy trên những thiết bị độc lập, không ảnh hưởng lẫn nhau; gắn cho mỗi môi trường proxy của khu vực tương ứng để điều kiện mạng gần với người dùng thực; sau đó dùng API để tìm, khởi chạy và đóng môi trường theo lô, tích hợp với các framework như Selenium và Puppeteer, qua đó tự động hóa cả bước chuẩn bị môi trường.
Chạy song song chỉ có ý nghĩa khi các môi trường độc lập với nhau. Nhiều môi trường có thể chạy các test case khác nhau cùng lúc, nên thời gian nhận phản hồi chuyển từ tổng thời gian chạy nối tiếp thành gần bằng thời gian của test case lâu nhất. Điều kiện tiên quyết là dữ liệu và tài khoản không được dùng chung: nếu hai test case thao tác cùng một dữ liệu, chạy song song chỉ tạo ra lỗi giả do chúng can thiệp lẫn nhau.
Việc cố định rõ ràng các tham số môi trường còn giúp giải quyết một vấn đề phổ biến khác: script chạy được ở máy cục bộ nhưng thất bại trên CI. Khác biệt về phiên bản trình duyệt, độ phân giải, múi giờ hoặc điều kiện mạng là nguyên nhân chính của dạng lỗi phụ thuộc môi trường này.
Khi cần tích hợp với script kiểm thử, công cụ quản lý môi trường như PurpleMark cung cấp năng lực ở lớp môi trường: tạo và quản lý tập trung các môi trường trình duyệt trong không gian làm việc web, cấu hình proxy, trang khởi động và tham số dấu vân tay cho từng môi trường, giữ khả năng truy vết bằng nhóm và nhật ký thao tác, đồng thời dùng Local API để khởi chạy và đóng môi trường từ bên ngoài. Nhờ đó, đội kiểm thử có thể tập trung vào test case thay vì liên tục dựng lại môi trường và xóa bộ nhớ đệm.
Ranh giới tuân thủ
Chỉ nên sử dụng các khả năng này trên hệ thống do bạn sở hữu hoặc đã được cấp quyền kiểm thử. Dùng chúng để vượt qua kiểm soát truy cập hoặc cơ chế bảo mật của trang web người khác có thể vi phạm điều khoản của họ và cũng có thể phát sinh rủi ro pháp lý.
Câu hỏi thường gặp
Kiểm thử tự động có thể thay thế hoàn toàn kiểm thử thủ công không? Không. Tự động hóa phù hợp với các tình huống ổn định và lặp lại, trong khi kiểm thử khám phá và đánh giá trải nghiệm vẫn cần con người.
Làm sao kiểm soát chi phí kiểm thử trên nhiều môi trường? Hãy lập kế hoạch theo số tổ hợp môi trường thực sự cần bao phủ, thay vì mở rộng không giới hạn. Ưu tiên các tổ hợp được tỷ lệ người dùng thực cao nhất sử dụng, sau đó mới bổ sung các môi trường ít phổ biến.
