Thông thường, testers sử dụng kiểm tra tự động để nâng cao chất lượng kiểm tra thủ công, đẩy nhanh việc thực hiện các kiểm tra chức năng và giảm thiểu lỗi của con người trong quá trình xác minh. Nó tích hợp tự động hóa vào toàn bộ quy trình đảm bảo chất lượng, do đó chúng ta phải áp dụng các bước tương tự cho kiểm thử tự động như chúng ta làm cho kiểm thử thủ công.
Khi quyết định những gì nên được tự động hóa và những gì nên được thực hiện thủ công, có một số tiêu chí cần lưu ý. Blog này cung cấp về 10 mẹo cho quy trình thử nghiệm tự động và chỉ ra mối liên hệ giữa thử nghiệm thủ công và tự động.
Một ứng dụng thử nghiệm thực hiện các phép tính và trả về một kết quả. Làm thế nào để bạn xác minh rằng kết quả là chính xác? Lựa chọn đầu tiên là thực hiện cùng một phép tính trong tập lệnh thử nghiệm và so sánh kết quả với những gì ứng dụng trả về! Tuy nhiên, chiến lược này không chính xác vì những lý do sau:
Trong những trường hợp như vậy, cách tiếp cận chính xác là tính toán thủ công giá trị chính xác và lưu nó trong kịch bản theo kế hoạch. Nếu một phép tính duy nhất là đủ, kết quả phải được ghi ngay vào tập lệnh. Nếu cần tính toán, sử dụng mảng hoặc phương pháp DDT.
Sẽ là tối ưu nếu các cá nhân có thẩm quyền cung cấp cho bạn dữ liệu nguồn và kết quả chính xác cho họ (ví dụ: chuyên gia sản phẩm). Bạn chịu trách nhiệm mã hóa bản test, nhưng việc xác định kết quả mong đợi thường không phải là trách nhiệm của bạn.
Bây giờ, nếu bản test của bạn đã thất bại, hoặc ứng dụng không hoạt động hiệu quả hoặc các yêu cầu đã thay đổi, đòi hỏi phải cập nhật dữ liệu bản test.
Trong mọi trường hợp, bạn có thể yên tâm rằng thất bại không liên quan đến mã thử nghiệm!
Nếu không thể loại bỏ hoàn toàn các phép tính như vậy vì một số lý do, hãy cố gắng đơn giản hóa và giảm chúng càng nhiều càng khả thi trong các bản test. Ngoài ra, hãy cẩn thận để bao gồm các nhận xét trong tập lệnh hoặc thông báo lỗi giải thích những gì đã được tính toán và tại sao. Trong tương lai, bạn hoặc người khác có thể cần phân tích các lỗi tiềm ẩn.
Khi tự động hóa, sản phẩm mới hơn của người thử nghiệm thường xuyên gặp lỗi khi một thử nghiệm sử dụng dữ liệu được cung cấp bởi một thử nghiệm khác. Minh họa cho điều này là tính năng CRUD, trong đó một bản test tạo một bản ghi, một bản cập nhật khác và một bên thứ ba xóa nó.
Ưu điểm duy nhất của chiến lược này là nó tiết kiệm thời gian; tuy nhiên, nhiều khuyết điểm có thể xuất hiện đồng thời:
Có những công việc phải được tự động hóa trong mỗi dự án, trong khi những công việc khác chỉ nên được để lại cho thử nghiệm thủ công. Những nhiệm vụ như vậy sẽ là duy nhất cho mỗi dự án, nhưng bạn có thể xác định một số lĩnh vực chung không nên tự động hóa.
Trong phần lớn các trường hợp, các bản test được viết để đánh giá chức năng cơ bản và không xác minh các trường hợp cá nhân, chẳng hạn như một khiếm khuyết với dữ liệu cụ thể. Tuy nhiên, không phải là không phổ biến đối với một lỗi cố định trước đây xuất hiện lại sau một thời gian; lý do cho sự xuất hiện lại của nó có thể hoàn toàn khác nhau, nhưng hậu quả là như nhau. Trong những trường hợp như vậy, việc xây dựng một bản test riêng biệt để kiểm tra lỗi đơn lẻ này hoặc một số lỗi là hợp lý.
Do chúng không phù hợp với các kịch bản thử nghiệm thủ công, những khiếm khuyết này chỉ có thể được phát hiện bằng sự trùng hợp ngẫu nhiên. Thông thường, các vấn đề như vậy xảy ra trong việc tích cực phát triển các dự án mà nhiều lập trình viên đang sửa đổi cùng một chức năng, do đó can thiệp vào các sửa đổi của nhau. Nếu bạn viết một bản test như vậy, bạn phải cung cấp số lỗi hiện có trong trình theo dõi lỗi trong báo cáo để bạn có thể xem lịch sử khám phá và sửa lỗi. Khi viết một bản test tự động và phát hiện ra một sai lầm trong chương trình đang được kiểm tra, bạn có thể trả lời tương tự. Bạn báo cáo lỗi và cho biết số lỗi trong phần nhận xét của quá trình xác minh bản test mới. Sau khi lỗi loại này đã được giải quyết, lỗi chỉ đơn giản là biến mất khỏi báo cáo.
Để bản test được đơn giản hóa, các bản test phải bao gồm mã đơn giản hóa. Rõ ràng, bạn có thể tạo ra một khuôn khổ phức tạp, nhưng trong phần lớn các trường hợp, điều này là không cần thiết. Điều tương tự cũng đúng với các chủ đề khác mà lập trình viên gặp phải thường xuyên, chẳng hạn như biểu thức thông thường, tương tác với cơ sở dữ liệu và sử dụng các chức năng ứng dụng nội bộ. Trong một vài trường hợp khi bạn cần thiết kế các giải pháp kiểm thử phức tạp hơn, thì các lập trình viên thường có kiến thức nhiều hơn và có thể cung cấp hướng dẫn có giá trị.
Nếu bạn phải đối mặt với một tình huống khó khăn mà bạn không biết cách giải quyết, hãy tìm kiếm sự tư vấn của các nhà phát triển. Rõ ràng, nó không đáng để tìm kiếm sự trợ giúp cho mỗi điều nhỏ; nó thường có lợi hơn nhiều để hiểu một mình bạn, do đó có được kinh nghiệm.
Tuy nhiên, hãy nhớ rằng quan điểm của nhà phát triển ứng dụng khác với quan điểm của bạn và không phải tất cả các đề xuất đều hữu ích như nhau. Lập trình viên xem ứng dụng từ bên trong và hiểu cách nó hoạt động. Từ bên ngoài, bạn có thể thấy nó nên hoạt động như thế nào.
GCT Solutions đồng hành cùng doanh nghiệp trong việc triển khai giải pháp AI và phát triển các nền tảng số hiện đại nhằm nâng cao hiệu quả vận hành một cách rõ ràng và có thể đo lường. Với năng lực về AI Services, AI Consulting, Platform Modernization and Software Engineering chúng tôi giúp tổ chức mở rộng quy mô công nghệ, tối ưu hoạt động và đẩy nhanh quá trình chuyển đổi số.