Vài điều cần tránh khi tự động hóa kiểm thử
Bất kể sự cố gắng của chúng ta để làm cho nền tảng và các đoạn mã kiểm thử của chúng ta ngày càng tốt hơn, luôn luôn xuất hiện những thứ làm cản trở công việc của chúng ta. Mục tiêu về một bộ kiểm thử tự động hoàn hảo, đáng tin cậy, nhanh chóng và dễ chỉnh sửa của chúng ta thường xuyên kết thúc trong thất vọng. Trong bài này, chúng ta sẽ thảo luận một vài điểm mà chúng ta cần tránh khi tự động hóa việc kiểm thử, để làm cho mã kiểm thử tự động của chúng ta đáng tin cậy hơn, và hơn hết là, tăng độ tin tưởng của cả nhóm vào kiểm thử tự động.
Không kiểm thử lại mã kiểm thử
Chúng ta kiểm thử mã của kỹ sư phát triển, vậy ai sẽ kiểm thử mã của chúng ta?
Tất cả các chương trình đều có thể được chấp nhận còn lỗi, nhưng một kịch bản kiểm thử tự động thì không thể chấp nhận được chuyện đó.
Để xuất hiện sai sót ngay vị trí xác nhận đúng/sai hay các vị trí kiểm tra khác sẽ làm cho mục đích của kịch bản kiểm thử không đáp ứng được. Để tránh điều này, sau khi tạo ra các phương thức kiểm thử, chúng ta nên chỉnh sửa các giá trị mong muốn hay thay đổi các giá trị cấu hình để làm mã kiểm thử báo cáo kết quả Fail, qua đó xác nhận mã kiểm thử hoạt động chính xác. Trong vài trường hợp, có thể có lỗi của hệ thống, nơi mà kịch bản kiểm thử tự động sẽ cho kết quả Fail, chúng ta nên cố gắng thay đổi vài thứ để đảm bảo kiểm thử sẽ cho kết quả Pass, khi mà lỗi đã được sửa thành công.
Một gợi ý nhỏ, đối với các kịch bản kiểm thử dành cho lỗi của hệ thống, chúng ta có thể để số hiệu của lỗi (bug ID) vào trong thông báo lỗi. Điểu này sẽ giúp chúng ta tiết kiệm thời gian khi làm phân tích kết quả kiểm thử.
Các kiểm thử bất ổn định
Mình khá chắc rằng, hầu hết những ai làm kiểm thử tự động đều từng tốn nhiều thời gian để làm việc với các bài kiểm thử không ổn định. Các kịch bản kiểm thử cho ra kết quả Pass/Fail một cách ngẫu nhiên, không thể tìm nguyên nhân và debug nó.
Chúng ta phải dựa vào các bản ghi/nhật ký để tìm kiếm nguyên nhân và cố gắng giải quyết nó. Ví dụ với Selenium, trên kinh nghiệm của mình, nhiều khả năng lỗi do sự chậm trễ khi lấy dữ liệu từ máy chủ hay chậm trễ thay đổi trạng thái của các đối tượng UI. Chúng ta nên sử dụng các phương pháp chờ đợi trong các tình huống như vậy. Nếu là vấn đề của môi trường (như tốc độ của hệ thống mang), hãy cố gắng tìm ra nguyên nhân và cung cấp một lý do chính xác hơn cho kết quả Fail đó.
Bỏ qua các kết quả không đáng tin là cực kỳ quan trọng trong bất kỳ hệ thống kiểm thử tự động bởi vì nó sẽ phá hủy lòng tin của nhóm vào mã kiểm thử của bạn và việc tự động hóa nói chung.
Dành nhiều thời gian cho việc phân tích kết quả
Bạn có một bộ kiểm thử tự động nhanh và đáng tin cậy, nhưng mỗi khi có kết quả thực thi, bạn phải dành ra hằng giờ, thậm chí là vài ngày để phân tích nhằm tìm ra lỗi của hệ thống từ các kết quả Fail.
Giai đoạn phân tích kết quả kiểm thử tự động cũng quan trọng như, hoặc hơn, các giai đoạn khác. Trong một dự án Agile, chúng ta đi theo các vòng Sprint ngắn, nó thật sự rất quan trọng trong việc có kết quả phân tích càng sớm càng tốt.
Chúng ta có thể phân loại lỗi vào nhiều loại khác nhau một cách tự động, dựa vào thông báo lỗi trong phương thức kiểm thử. Điều này thật sự dễ dàng với kiểm thử đơn vị hay dịch vụ, nơi mà các thông báo lỗi có thể được phân loại ngay từ đâu. Chúng ta có thể phân loại các lỗi như: Xác thực người dùng, lỗi dữ liệu, lỗi môi trường, …
Đối với kiểm thử giao diện, nó thật sự phức tạp hơn nhiều lần. Kịch bản kiểm thử thường Fail do khác biệt giữa giá trị thực tế và giá trị mong muốn – một lỗi của hệ thống, không phải là vấn đề của kịch bản kiểm thử tự động; nhưng đôi khi, nó Fail ở một vấn đề khác – Không chắc là lỗi hệ thống hay không, nó thật sự là vấn đề. Chúng ta có thể tạo một phương thức kiểm thử tương tự với phương thức mà kết quả là Fail, bằng cách chia ra lý do Fail của kiểm thử, do khác biệt giá trị hay do lý do khác. Đối với việc Fail do các lý do khác, chúng ta cần phải dựa vào báo cáo và nhật ký để tìm ra cốt lõi của vấn đề. Trong một số nền tảng, chúng ta sẽ có các phương thức báo cáo và ghi nhật ký mà nó giúp ích cho việc xác định vấn đề. Bên cạnh đó, việc chụp lại màn hình ngay thời điểm kết thúc kiểm thử sẽ giúp chúng ta giảm thiểu thởi gian dành cho việc phân tích kết quả.
Sự phụ thuộc lẫn nhau của kịch bản kiểm thử
Trong việc tự động hóa, chúng ta thường phải thực thi lại các kịch bản kiểm thử Fail khi mà nó Fail bởi các vấn đề của mã kiểm thử (chúng ta đã bàn luận ở trên). Điều này sẽ dẫn đến, chúng ta sẽ tốn nhiều thời gian để thực thi lại nếu những kịch bản kiểm thử phụ thuộc lẫn nhau. Đây cũng là một điều cần tránh nếu muốn xây dựng một hệ thống kiểm thử tự động ổn định và đáng tin.
Bạn có vấn đề gì cần tránh khi tự động hóa việc kiểm thử, xin vui lòng chia sẻ 🙂