Thiết kế kiểm thử: xác định các trường hợp kiểm thử
Các điều kiện kiểm thử có thể khá mơ hồ, bao gồm khá nhiều khả năng như đã thấy với ví dụ về công ty điện thoại di động (ví dụ: một thiếu niên ở miền Trung Tây) hoặc một điều kiện kiểm thử có thể cụ thể hơn (ví dụ: một khách hàng nam trả theo từng lần với số tiền ít hơn 10$ tín dụng). Tuy nhiên, khi thực hiện một trường hợp kiểm thử, phải được yêu cầu rất cụ thể; trên thực tế, cần thông tin đầu vào cụ thể chính xác và chi tiết, chứ không phải mô tả chung chung (ví dụ: Jim Green, 17 tuổi, sống ở Grand Rapids, Michigan, với khoản tín dụng là 8,64 đô la, kết quả mong đợi: thêm vào chiến dịch tiếp thị Q4). Lưu ý rằng một trường hợp kiểm thử bao gồm một số điều kiện (thanh thiếu niên, nam giới, khu vực trung tây, thanh toán theo mức sử dụng và tín dụng dưới 10 đô la).
Đối với điều kiện kiểm thử là “một khách hàng đã tồn tại”, đầu vào của trường hợp kiểm thử cần phải là “Jim Green” trong đó Jim Green đã tồn tại trên cơ sở dữ liệu khách hàng hoặc một phần của kiểm thử này là thiết lập bản ghi cơ sở dữ liệu cho Jim Green.
Tất nhiên, một trường hợp kiểm thử cần phải có các giá trị đầu vào, nhưng chỉ có một vài giá trị để nhập vào hệ thống thì không phải là một bài kiểm thử! Nếu bạn không biết hệ thống phải làm gì với đầu vào, bạn không thể biết bài kiểm thử của mình đạt hay không.
Những trường hợp kiểm thử chi tiết này có nên được viết ra không? Chúng có thể được ghi lại chính thức (được mô tả cụ thể ở dưới). Tuy nhiên, có thể kiểm thử mà không cần tài liệu ở cấp độ kịch bản kiểm thử. Nếu cung cấp cho người kiểm thử chấp nhận của người dùng có kinh nghiệm với một nền tảng nghiệp vụ vững chắc danh sách các điều kiện kiểm thử mức cao, thì họ có thể thực hiện tốt công việc kiểm thử. Nhưng nếu đưa cùng một danh sách cho một người mới bắt đầu hoàn toàn không biết gì về hệ thống, thì họ có thể sẽ không thực hiện tốt công việc, vì vậy họ sẽ được hưởng lợi từ việc có các kịch bản kiểm thử chi tiết hơn.
Kịch bản kiểm thử có thể được ghi lại như được mô tả trong Tiêu chuẩn IEEE 829 cho Tài liệu Kiểm thử. Lưu ý rằng tất cả các nội dung được mô tả trong tiêu chuẩn không nhất thiết phải là các tài liệu vật lý riêng biệt. Nhưng danh sách tiêu chuẩn về những gì cần được theo dõi là một điểm khởi đầu tốt, ngay cả khi các điều kiện kiểm thử và kịch bản kiểm thử cho một chức năng hoặc tính năng nhất định đều được lưu giữ trong một tài liệu vật lý.
Một trong những khía cạnh quan trọng nhất của kiểm thử là nó đánh giá hệ thống có làm những gì nó phải làm hay không. Copeland đã từng nói “Về cốt lõi, kiểm thử là quá trình so sánh “cái gì là” với “cái gì phải là””. [Copeland, 2003]
Nếu chúng ta chỉ đơn giản đưa vào các thông tin đầu vào và nghĩ rằng “điều này thật thú vị, tôi đoán hệ thống có thể ổn vì nó không gặp sự cố”, vậy thì chúng ta có thực sự đang kiểm thử không? Bạn đã quan sát thấy rằng hệ thống làm những gì hệ thống làm – đây không phải là kiểm thử.
Boris Beizer gọi đây là “kiểm thử dành cho trẻ nhỏ” [Beizer, 1990]. Chúng ta có thể không biết chi tiết câu trả lời đúng ở mỗi lần là gì và đôi khi vẫn có thể nhận được một số lợi ích từ phương pháp này, nhưng nó không thực sự là kiểm thử.
Để biết hệ thống nên làm gì, chúng ta cần có một nguồn thông tin về hành vi chính xác của hệ thống – đây được gọi là “tiên tri” (oracle) hoặc kiểm thử tiên (test oracle).
Điều này không liên quan gì đến cơ sở dữ liệu hoặc công ty tạo ra chúng. Nó xuất phát từ Nhà tiên tri Hy Lạp cổ đại ở Delphi, người được cho là có thể dự đoán tương lai với độ chính xác không thể nhầm lẫn. Trên thực tế, câu trả lời của nhà tiên tri ấy mơ hồ đến mức mọi người diễn giải chúng theo bất kỳ cách nào họ muốn – có lẽ hơi giống với đặc tả yêu cầu!
Khi một giá trị đầu vào nhất định đã được chọn, người kiểm thử cần xác định kết quả mong đợi của việc nhập đầu vào đó sẽ là gì và ghi lại nó như một phần của trường hợp kiểm thử.
Kết quả mong đợi bao gồm thông tin được hiển thị trên màn hình để phản hồi đầu vào, nhưng cũng bao gồm các thay đổi trong dữ liệu và/hoặc trạng thái cũng như bất kỳ hậu quả nào khác của kiểm thử (ví dụ: một bức thư sẽ được in suốt đêm).
Điều gì sẽ xảy ra nếu không xác định kết quả mong đợi trước khi chạy bài kiểm thử?
Chúng ta vẫn có thể xem những gì hệ thống tạo ra và có thể sẽ nhận thấy nếu có gì đó không ổn. Tuy nhiên, chúng ta có thể sẽ không nhận thấy những khác biệt nhỏ trong tính toán hoặc kết quả có vẻ ổn (nghĩa là hợp lý). Vì vậy, sẽ kết luận rằng bài kiểm thử đã vượt qua, trong khi thực tế phần mềm không đưa ra kết quả chính xác. Những khác biệt nhỏ trong một phép tính có thể cộng lại thành một điều gì đó rất lớn sau này, chẳng hạn nếu kết quả được nhân với một hệ số lớn.
Kết quả mong đợi lý tưởng nên được dự đoán trước khi chạy kiểm thử – khi đó đánh giá về việc phần mềm có làm đúng hay không sẽ khách quan hơn.
Đối với một số ứng dụng, có thể không dự đoán hoặc biết chính xác kết quả mong đợi sẽ là gì; chỉ có thể thực hiện “kiểm tra tính hợp lý”. Trong trường hợp này, chúng ta có “tiên tri một phần” (partial oracle)- biết khi nào có điều gì đó rất không ổn, nhưng có lẽ sẽ phải chấp nhận điều gì đó có vẻ hợp lý. Một ví dụ là khi một hệ thống đã được viết để tính toán một thứ gì đó mà nó không thể tạo ra các kết quả mong đợi theo cách thủ công trong một khoảng thời gian hợp lý vì các phép tính quá phức tạp.
Ngoài kết quả mong đợi, kịch bản kiểm thử cũng chỉ định môi trường và những thứ khác phải có trước khi kiểm thử có thể chạy (điều kiện tiên quyết) và bất kỳ điều gì nên áp dụng sau khi kiểm thử hoàn thành (điều kiện sau).
Kịch bản kiểm thử cũng nên cho biết lý do tại sao nó tồn tại – tức là mục tiêu kiểm thử mà nó là một phần của hoặc các điều kiện kiểm thử mà nó đang thực hiện (truy xuất nguồn gốc). Kịch bản kiểm thử giờ đây có thể được ưu tiên sao cho các trường hợp kiểm thử quan trọng nhất được thực hiện trước và các trường hợp kiểm thử có mức độ ưu tiên thấp được thực hiện sau hoặc thậm chí không được thực hiện. Điều này có thể phản ánh các ưu tiên đã được thiết lập cho các điều kiện kiểm thử hoặc mức độ ưu tiên có thể được xác định bởi các yếu tố khác liên quan đến các trường hợp kiểm thử cụ thể, chẳng hạn như một giá trị đầu vào cụ thể đã gây rắc rối trong quá khứ, rủi ro liên quan
với bài kiểm thử hoặc trình tự hợp lý nhất để chạy các bài kiểm thử. Chương 5 cung cấp thêm chi tiết về kiểm thử dựa trên rủi ro.
Các trường hợp kiểm thử cần phải được chi tiết để có thể kiểm tra chính xác kết quả và biết rằng chúng ta có phản hồi chính xác từ hệ thống. Nếu các bài kiểm thử được tự động hóa, công cụ kiểm thử cần biết chính xác những gì để so sánh đầu ra của hệ thống.
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây
