Chương 3 đề cập đến kiểm thử tĩnh, tài liệu và code, nhưng không thực thi code. Chương này xem xét kiểm thử động, trong đó phần mềm được chạy bằng cách thực hiện kiểm thử trên code đang chạy.
XÁC ĐỊNH ĐIỀU KIỆN KIỂM THỬ VÀ THIẾT KẾTRƯỜNG HỢP KIỂM THỬ
Các nội dung sẽ có trong đề thi ISTQB Foundation (CTFL)
- Phân biệt giữa đặc tả thiết kế kiểm thử, đặc tả trường hợp kiểm thử và đặc tả quy trình kiểm thử. (K1)
- So sánh điều kiện kiểm thử, trường hợp kiểm thử và quy trình kiểm thử. (K2)
- Viết test case: (K3)
thể hiện khả năng truy xuất nguồn gốc rõ ràng đối với các yêu cầu; chứa một kết quả mong đợi. - Chuyển các trường hợp kiểm thử thành đặc tả quy trình kiểm thử có cấu trúc tốt ở mức độ chi tiết phù hợp với kiến thức của người kiểm thử. (K3)
- Viết lịch trình thực hiện kiểm thử cho một tập hợp các trường hợp kiểm thử nhất định, xem xét mức độ ưu tiên và các phụ thuộc logic và kỹ thuật. (K3)
Giới thiệu
Trước khi thực sự có thể thực hiện một bài kiểm thử, cần biết chúng ta đang cố gắng kiểm thử những gì, đầu vào, kết quả được tạo ra bởi những đầu vào đó và cách mà chúng ta thực sự sẵn sàng và chạy các bài kiểm thử.
Trong phần này, ta xem xét ba điều: điều kiện kiểm thử, trường hợp kiểm thử và thủ tục kiểm thử (hoặc tập lệnh) – các nội dung này sẽ được mô tả trong ở dưới. Mỗi nội dung được chỉ định trong tài liệu riêng, theo Tiêu chuẩn tài liệu kiểm thử [IEEE829].
Các điều kiện thử nghiệm được tài liệu hóa trong đặc tả thiết kế kiểm thử (Test Design Specification). Chúng ta sẽ xem xét cách chọn các điều kiện kiểm thử và cách đánh độ ưu tiên cho chúng
Các trường hợp kiểm thử được ghi lại trong Đặc tả trường hợp kiểm thử (Test Case Specification). Chúng ta sẽ xem xét cách viết một trường hợp kiểm thử tốt, cho thấy khả năng truy nguyên rõ ràng đến cơ sở kiểm thử (ví dụ: đặc tả yêu cầu) cũng như các điều kiện kiểm thử.
Thủ tục kiểm thử (test procedure) được ghi lại (như bạn kì vọng) trong một đặc tả thủ tục kiểm thử (còn được biết đến với tên gọi là tập lệnh kiểm thử hoặc tập lệnh kiểm thử thủ công). Chúng ta sẽ xem xét cách dịch các trường hợp kiểm thử thành các thủ tục kiểm thử phù hợp với kiến thức của người kiểm thử (là những người sẽ thực hiện kiểm thử) và xem cách tạo lịch biểu thực hiện kiểm thử, sử dụng việc đánh mức độ ưu tiên và các phụ thuộc logic và kỹ thuật.
Trong phần này, hãy tìm định nghĩa của các thuật ngữ: trường hợp kiểm thử (test case), đặc tả trường hợp kiểm thử (test case specification), điều kiện kiểm thử (test condition), dữ liệu kiểm thử (test data), đặc tả thủ tục kiểm thử (test procedure specification), kịch bản kiểm thử (test script) và truy xuất nguồn gốc (traceability).
Hình thức của tài liệu kiểm thử
Việc kiểm thử có thể được thực hiện với các mức độ hình thức khác nhau. Kiểm thử rất chính thức nên có nhiều tài liệu được kiểm soát tốt và nên kì vọng vào mức độ chi tiết của tài liệu của việc kiểm thử, bao gồm đầu vào và đặc tả chính xác cũng như kết quả mong đợi của việc kiểm thử. Kiểm thử rất không chính thức có thể không có tài liệu nào cả, hoặc chỉ có các ghi chú được lưu giữ bởi từng người kiểm thử, nhưng chúng ta vẫn mong đợi những người kiểm thử ghi nhớ và ghi chú một số ý tưởng về những gì họ dự định kiểm thử và những kết quả mong đợi mà họ kì vọng.
Mức độ chính thức phù hợp tùy thuộc vào ngữ cảnh: một ứng dụng quan trọng về an toàn thương mại có những nhu cầu rất khác so với một ứng dụng dùng một lần chỉ được một số ít người sử dụng trong một thời gian ngắn.
Mức độ chính thức cũng bị ảnh hưởng bởi tổ chức – văn hóa của tổ chức, những người làm việc ở đó, quy trình phát triển hoàn thiện như thế nào, quy trình kiểm thử hoàn thiện như thế nào…. Tính kỹ lưỡng của tài liệu kiểm thử cũng có thể phụ thuộc vào hạn chế về thời gian; dưới áp lực thời hạn quá mức, việc lưu giữ tài liệu tốt có thể bị tổn hại.
Chương này mô tả kiểu tài liệu hóa khá trang trọng. Nếu điều này không phù hợp với bạn, bạn có thể áp dụng cách tiếp cận ít trang trọng hơn, nhưng bạn sẽ biết cách tăng tính trang trọng nếu cần.
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây
