Phân tích kiểm thử: xác định điều kiện kiểm thử
Phân tích kiểm thử là quá trình xem xét một cái gì đó có thể được sử dụng để lấy thông tin kiểm thử. Cơ sở cho các bài kiểm thử này được gọi là “cơ sở kiểm thử”. Nó có thể là một yêu cầu hệ thống, một đặc tả kỹ thuật, bản thân code (để kiểm thử cấu trúc) hoặc một quy trình nghiệp vụ. Đôi khi, việc kiểm thử có thể dựa trên kiến thức của người dùng có kinh nghiệm về hệ thống, điều này có thể không được ghi chép lại. Cơ sở kiểm thử bao gồm bất cứ điều gì mà các bài kiểm thử dựa vào. Điều này cũng đã được thảo luận trong Chương 1.
Từ góc độ kiểm thử, xem xét cơ sở kiểm thử để xem những gì có thể được kiểm thử – đây là các điều kiện kiểm thử. Điều kiện kiểm thử (test condition) đơn giản chỉ là thứ mà chúng ta có thể kiểm thử. Nếu chúng ta đang tìm cách đo độ bao phủ của các quyết định của code (nhánh), thì cơ sở kiểm thử sẽ là chính mã code đó và danh sách các điều kiện kiểm thử sẽ là kết quả quyết định (Đúng và Sai). Nếu có một đặc tả yêu cầu, mục lục có thể là danh sách ban đầu về các điều kiện kiểm thử.
Một cách tốt để hiểu các yêu cầu tốt hơn đo là cố gắng xác định các bài kiểm thử đáp ứng được các yêu cầu đó, như [Hetzel, 1988] đã chỉ ra.
Ví dụ, nếu đang kiểm thử hệ thống tiếp thị và quản lý khách hàng cho một công ty điện thoại di động, có thể có các điều kiện kiểm thử liên quan đến chiến dịch tiếp thị, chẳng hạn như độ tuổi của khách hàng (dưới tuổi vị thành niên, thiếu niên, thanh niên, trưởng thành), giới tính, mã bưu chính hoặc mã zip và tùy chọn mua hàng (thanh toán theo mức sử dụng hoặc hợp đồng). Ví dụ, một chiến dịch quảng cáo cụ thể có thể nhắm đến các khách hàng nam thanh thiếu niên ở miền trung tây Hoa Kỳ theo hình thức trả tiền khi sử dụng.
Các chuyên gia kiểm thử sử dụng nhiều tên gọi khác nhau để thể hiện ý tưởng cơ bản về “danh sách những thứ có thể kiểm thử”.
Ví dụ, Marick đề cập đến “yêu cầu kiểm thử” là những thứ cần được kiểm thử. Mặc dù, nó không có ý ám chỉ rằng mọi thứ cần phải được kiểm thử, nhưng cũng quá dễ dàng để diễn giải theo cách như vậy. [Marick, 1994]
Ngược lại, Hutcheson nói về “kiểm thử tồn kho” (test inventory) như một danh sách những thứ có thể kiểm thử [Hutcheson, 2003].
Craig nói về “mục tiêu kiểm thử” như là những thể loại rộng rãi của những thứ cần kiểm thử, và “kiểm thử tồn kho” là danh sách thực tế những thứ cần được kiểm thử [Craig, 2002].
Tất cả các tác giả này đều đề cập đến thuật ngữ ISTQB điều kiện kiểm thử (test condition).
Khi xác định các điều kiện kiểm thử, chúng ta muốn “mở rộng mạng lưới” để xác định càng nhiều điều kiện càng tốt, sau đó bắt đầu chọn lọc xem điều kiện nào tiếp tục phát triển chi tiết hơn và kết hợp thành các trường hợp kiểm thử. Có thể gọi chúng là “khả năng kiểm thử” (test possibilities).
Trong Chương 1, đã giải thích rằng kiểm thử mọi thứ được gọi là kiểm thử toàn bộ (được định nghĩa là thực hiện mọi kết hợp đầu vào và điều kiện tiên quyết) và chúng ta đã chứng minh rằng đây là một mục tiêu không thực tế. Do đó, vì không thể kiểm tra mọi thứ, ta phải chọn một tập hợp con của tất cả các kiểm thử có thể. Trong thực tế, tập hợp con được chọn có thể là một tập hợp con rất nhỏ và nó phải có xác suất cao tìm thấy hầu hết các lỗi trong hệ thống. Cần một số quy trình tư duy thông minh để hướng dẫn lựa chọn; kỹ thuật kiểm thử (test techniques) (tức là kỹ thuật thiết kế kiểm thử) là những quy trình tư duy như vậy.
Một kỹ thuật kiểm thử giúp ta chọn một tập các kiểm thử tốt từ tổng số tất cả các bài kiểm thử có thể có. Các kỹ thuật khác nhau đưa ra những cách nhìn khác nhau về phần mềm đang được kiểm thử, có thể thách thức các giả định được đưa ra về nó. Mỗi kỹ thuật cung cấp một bộ quy tắc hoặc hướng dẫn để người kiểm thử tuân theo trong việc xác định các điều kiện kiểm thử và trường hợp kiểm thử. Các kỹ thuật được mô tả chi tiết sau trong chương này.
Các điều kiện kiểm thử được chọn sẽ phụ thuộc vào chiến lược kiểm thử hoặc phương pháp kiểm thử chi tiết. Ví dụ, chúng có thể dựa trên rủi ro, mô hình hệ thống, lỗi có thể xảy ra, yêu cầu tuân thủ, lời khuyên của chuyên gia hoặc tự tìm tòi.
Từ “tự tìm tòi” (heuristic) xuất phát từ cùng một gốc tiếng Hy Lạp với eureka, có nghĩa là “tôi tìm thấy”. Heuristic là một cách hướng sự chú ý của bạn, một quy tắc thông thường hữu ích trong việc giải quyết vấn đề.
Các điều kiện kiểm thử sẽ có thể được liên kết trở lại nguồn của chúng trong cơ sở kiểm thử – điều này được gọi là truy xuất nguồn gốc (traceability).
Truy xuất nguồn gốc có thể theo chiều ngang thông qua tất cả các tài liệu kiểm thử ở một cấp độ kiểm thử nhất định (ví dụ: kiểm thử hệ thống, từ điều kiện kiểm thử thông qua trường hợp kiểm thử đến tập lệnh kiểm thử) hoặc theo chiều dọc thông qua các lớp tài liệu phát triển (ví dụ: từ yêu cầu đến thành phần).
Tại sao truy xuất nguồn gốc lại quan trọng? Hãy xem xét các ví dụ sau:
- Các yêu cầu đối với một chức năng hoặc tính năng nhất định đã thay đổi. Một số trường thì dải giá trị khác nhau có thể nhập được. Những bài kiểm thử nào đang xem xét những giá trị biên đó? Những giá trị này cần phải thay đổi. Có bao nhiêu bài kiểm thử thực sự sẽ bị ảnh hưởng bởi sự thay đổi này trong các yêu cầu? Những câu hỏi này có thể được trả lời dễ dàng nếu các yêu cầu có thể dễ dàng được truy xuất từ các bài kiểm thử.
- Một tập hợp các bài kiểm thử đã chạy tốt trong quá khứ đã bắt đầu có vấn đề nghiêm trọng. Những bài kiểm thử này thực sự thực hiện chức năng gì? Khả năng truy xuất nguồn gốc giữa các bài kiểm thử và yêu cầu đang được kiểm thử cho phép các chức năng hoặc tính năng bị ảnh hưởng được xác định dễ dàng hơn.
- Trước khi cung cấp một bản phát hành mới, chúng ta muốn biết liệu đã kiểm tra tất cả các yêu cầu được chỉ định trong đặc tả yêu cầu hay chưa. Chúng ta có danh sách các bài kiểm thử đã vượt qua – mọi yêu cầu đã được kiểm thử chưa?
Sau khi đã xác định danh sách các điều kiện kiểm thử, điều quan trọng là phải ưu tiên chúng để xác định các điều kiện kiểm thử quan trọng nhất (trước khi dành nhiều thời gian cho việc thiết kế các trường hợp kiểm thử dựa trên chúng). Bạn nên thử và nghĩ về gấp đôi số điều kiện kiểm thử nếu bạn cần – sau đó bạn có thể loại bỏ những điều kiện ít quan trọng hơn và bạn sẽ có một tập hợp các điều kiện kiểm thử tốt hơn nhiều!
Lưu ý rằng việc dành thêm thời gian ngay bây giờ để xác định các điều kiện kiểm thử sẽ không mất nhiều thời gian vì chúng ta chỉ liệt kê những thứ có thể kiểm thử. Đây là một khoản đầu tư tốt cho thời gian của chúng ta – chúng ta không muốn dành thời gian thực hiện các bài kiểm thử kém!
Điều kiện kiểm thử có thể được xác định cho dữ liệu kiểm thử cũng như đầu vào kiểm thử và kết quả kiểm thử, ví dụ: các loại bản ghi khác nhau, phân phối các loại bản ghi khác nhau trong một tệp hoặc cơ sở dữ liệu, các kích thước bản ghi hoặc trường khác nhau trong một bản ghi. Dữ liệu kiểm thử phải được thiết kế để đại diện cho các loại dữ liệu quan trọng nhất, tức là các điều kiện dữ liệu quan trọng nhất.
Các điều kiện kiểm thử được ghi lại trong tài liệu IEEE 829 có tên là Thông số kỹ thuật thiết kế kiểm thử, được hiển thị bên dưới. (Tài liệu này có thể được gọi là Đặc tả điều kiện kiểm thử, vì nội dung được đề cập trong tiêu chuẩn thực sự là điều kiện kiểm thử.)
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây
