日本語
EnglishKIỂM THỬ HỘP TRẮNG VÀ KIỂM THỬ DỰA TRÊN KINH NGHIỆM
①Kiểm thử hộp trắng (White box Testing)
Kiểm thử hộp trắng là một phương pháp kiểm thử được thực hiện dựa trên cấu trúc bên trong của hệ thống hoặc mã nguồn. Phương pháp này có thể được áp dụng ở mọi cấp độ kiểm thử, nhưng thường được sử dụng nhiều nhất trong kiểm thử thành phần (component testing), tập trung vào hai kỹ thuật dựa vào mã nguồn. Các kỹ thuật này phân loại dựa trên yếu tố chi tiết chú trọng trong mã nguồn.
Một phần quan trọng của kiểm thử hộp trắng là đo lường mức độ thực thi các yếu tố được chú trọng, được gọi là “độ bao phủ” (coverage) hay độ bao phủ mã nguồn (code coverage).
Kiểm thử câu lệnh (Statement Testing) và Độ bao phủ (Coverage)
Trong kiểm thử câu lệnh (statement testing), các trường hợp kiểm thử được thiết kế để kiểm tra các câu lệnh thực thi trong mã nguồn. Bao phủ đo lường trong loại kiểm thử này được gọi là “bao phủ câu lệnh” (statement coverage) và được tính toán bằng công thức sau:
Bao phủ câu lệnh (%) = (Số câu lệnh đã thực thi / Tổng số câu lệnh trong mã cần kiểm thử) × 100
Kiểm thử quyết định (Decision Testing) và Độ bao phủ (Coverage)
Kiểm thử quyết định (Decision Testing) là một kỹ thuật thiết kế trường hợp kiểm thử dựa trên các điều kiện phân nhánh trong mã nguồn và kết quả của chúng. Các điều kiện phân nhánh được thể hiện khác nhau tùy vào ngôn ngữ lập trình, với các ví dụ điển hình bao gồm câu lệnh if-else, switch-case, và do-while.
Bao phủ đo lường trong loại kiểm thử này được gọi là “bao phủ quyết định” (Decision Coverage), được tính toán bằng công thức sau:
Bao phủ quyết định (%) = (Số kết quả phân nhánh đã thực thi / Tổng số kết quả phân nhánh) × 100
Giống như bao phủ câu lệnh (Statement Coverage) đã đề cập trước đó, chúng ta sẽ sử dụng một đoạn code ví dụ dưới đây để giải thích cách tính Độ bao phủ quyết định.
public void foo(int x) {
if (x != 0) {
x = 1 / x;
}
}
Để đạt được Độ bao phủ quyết định 100%, cần đảm bảo rằng cả hai kết quả phân nhánh của câu lệnh if (đúng và sai) đều được thực thi trong quá trình kiểm thử. Trong ví dụ này, đối với biến x, cần thiết kế hai trường hợp kiểm thử như sau:
- Khi x bằng 0 (kết quả là sai).
- Khi x không bằng 0 (kết quả là đúng).
Cả hai trường hợp này phải được kiểm tra để đảm bảo rằng mọi nhánh phân quyết trong mã nguồn đều được thực thi ít nhất một lần.
Tầm quan trọng của Kiểm thử câu lệnh (Statement Testing) và Kiểm thử quyết định (Decision Testing)
Kiểm thử câu lệnh (Statement Testing) và kiểm thử quyết định (Decision Testing) đều có giá trị riêng. Nếu đạt được bao phủ quyết định 100% thì bao phủ câu lệnh cũng sẽ đạt 100%. Tuy nhiên, điều ngược lại không phải lúc nào cũng đúng. Sự khác biệt này sẽ trở nên rõ ràng khi xem xét các ví dụ cụ thể.
Ví dụ, nếu một câu lệnh if không có câu lệnh else, nghĩa là không có câu lệnh rõ ràng nào để xử lý điều kiện sai, thì các trường hợp kiểm thử cần thiết của kiểm thử câu lệnh và kiểm thử quyết định sẽ khác nhau. Điều này xảy ra vì hai phương pháp đánh giá mã nguồn từ các quan điểm khác nhau.
Kiểm thử câu lệnh nhằm xác nhận rằng các câu lệnh thực thi trong mã hoạt động như mong đợi và không gây ra kết quả không mong muốn trong quá trình thực thi. Ngược lại, kiểm thử quyết định đảm bảo rằng cả hai kết quả của điều kiện phân nhánh (đúng và sai) đều được kiểm tra và có thể phát hiện các hành vi không mong muốn xảy ra trong từng trường hợp.
Tuy nhiên, khi thiết kế các trường hợp kiểm thử dựa trên mã nguồn, nếu mã nguồn có lỗi, thì kết quả mong đợi được xác định trong kiểm thử cũng có thể sai. Để giải quyết vấn đề này, ngay cả khi thực hiện kiểm thử hộp trắng, cũng cần tham khảo tài liệu đặc tả để xác định kết quả mong đợi.
②Kiểm thử dựa trên kinh nghiệm
Kỹ thuật kiểm thử dựa trên kinh nghiệm là phương pháp thiết kế các trường hợp kiểm thử dựa trên kỹ năng, trực giác, cũng như kinh nghiệm của người kiểm thử về các ứng dụng hoặc công nghệ tương tự trước đây. Phương pháp này thường được sử dụng kết hợp với các kỹ thuật Kiểm thử hộp đen và Kiểm thử hộp trắng.
Ví dụ, việc kiểm thử các yêu cầu liên quan đến “yêu cầu ngầm định” không được ghi rõ trong tài liệu đặc tả có thể gặp khó khăn nếu chỉ sử dụng các kỹ thuật Kiểm thử hộp đen. Các “yêu cầu ngầm định” này thường là các khu vực dễ phát sinh lỗi do không được nêu rõ, và kỹ thuật kiểm thử dựa trên kinh nghiệm rất hiệu quả trong việc phát hiện những lỗi như vậy.
Tuy nhiên, kỹ thuật này cũng có một số thách thức. Kiểm thử dựa trên kinh nghiệm phụ thuộc nhiều vào cách làm việc và kinh nghiệm trước đó của người thực hiện, dẫn đến hiệu quả kiểm thử không đồng nhất. Ngoài ra, mức độ bao phủ kiểm thử (test coverage) cũng có thể khác nhau giữa các cá nhân. Việc đo lường bao phủ trong trường hợp này cũng rất khó khăn, dẫn đến khó đánh giá hiệu quả kiểm thử dựa trên độ bao phủ.
Dự đoán lỗi (Error Guessing)
Dự đoán lỗi là một phương pháp kiểm thử dựa trên kiến thức của người kiểm thử để dự đoán khả năng xảy ra lỗi, khuyết điểm hoặc sự cố trong hệ thống. Kiến thức này có thể bao gồm các yếu tố sau:
- Hành vi và lịch sử hoạt động trước đây của ứng dụng
- Các xu hướng sai sót phổ biến mà nhà phát triển dễ mắc phải
- Các sự cố đã xảy ra ở các ứng dụng khác
Những kiến thức này được tích lũy qua kinh nghiệm của người kiểm thử và do đó, có giới hạn tùy thuộc vào kiến thức và kinh nghiệm của từng cá nhân. Do đó, để giảm thiểu rủi ro của các lỗi, khuyết điểm và sự cố có thể xảy ra, việc lập danh sách các rủi ro này và thiết kế các trường hợp kiểm thử dựa trên danh sách đó là điều nên làm. Khi danh sách này được chia sẻ giữa các người kiểm thử, kiểm thử có thể trở nên ít phụ thuộc vào kỹ năng cá nhân, và khi được chia sẻ với nhà phát triển, giúp ngăn ngừa các khuyết điểm từ sớm trong quá trình thiết kế và triển khai.
Một số ví dụ điển hình khi dự đoán lỗi bao gồm:
- Giá trị 0
Khi thực hiện phép chia cho 0, sẽ phát sinh lỗi ngoại lệ. - Giá trị Null
Khi tham chiếu tới giá trị null, sẽ phát sinh lỗi ngoại lệ. - Năm nhuận (Ngày 29 tháng 2)
Vấn đề liên quan đến ngày tháng đặc biệt.
Những trường hợp kiểm thử này có xu hướng dễ fail dựa trên kinh nghiệm, và cũng có những mẫu dự đoán lỗi điển hình liên quan đến thứ tự thao tác, thời gian thực hiện hoặc đặc điểm của đối tượng kiểm thử.
Kiểm thử khám phá (Exploratory Testing)
Kiểm thử khám phá là phương pháp kiểm thử trong đó người kiểm thử tiến hành thiết kế, thực hiện, ghi chép nhật ký, đánh giá lại và cải thiện quy trình kiểm thử khi họ học hỏi về hệ thống. Trong phương pháp này, không có các trường hợp kiểm thử được tạo trước, mà người kiểm thử tìm hiểu sâu hơn về đối tượng kiểm thử trong quá trình thực hiện kiểm thử. Khác với các phương pháp chính thức, kiểm thử khám phá không phụ thuộc vào các trường hợp kiểm thử đã được lập kế hoạch trước, nhưng có thể được thực hiện dựa trên một số tiêu chí nhất định. Tuy nhiên, phương pháp này không phải là một cách tiếp cận có hệ thống, và người kiểm thử sẽ thực hiện kiểm thử dựa trên “test charter” – một tài liệu hướng dẫn cho quá trình kiểm thử và có thể thay thế cho việc tạo các trường hợp kiểm thử chính thức.
Kiểm thử theo phiên (Session-Based Testing) có các đặc điểm sau:
- Thực hiện kiểm thử trong một khoảng thời gian cố định (phiên).
- Ghi chép lại các bước đã thực hiện và các sự kiện đã phát hiện trong nhật ký kiểm thử.
Kiểm thử khám phá đặc biệt hiệu quả khi tài liệu đặc tả không đầy đủ và không thể tạo các trường hợp kiểm thử trước, hoặc khi không có nhiều thời gian trong kế hoạch. Phương pháp này cho phép thiết kế và thực hiện kiểm thử đồng thời, giúp tiết kiệm thời gian và nâng cao hiệu quả kiểm thử.
Ngoài ra, kiểm thử khám phá cũng có thể bổ sung cho các phương pháp kiểm thử chính thức. Sau khi thực hiện kiểm thử chính thức hoặc trong khi thực hiện song song, kiểm thử khám phá có thể giúp phát hiện các lỗi do thiếu sót trong đặc tả hoặc do sai sót trong việc thiết kế đặc tả. Tuy nhiên, nếu kiểm thử khám phá phát hiện ra lỗi mà lẽ ra phải được phát hiện trong các kiểm thử chính thức, có thể là một dấu hiệu cho thấy quy trình kiểm thử đang gặp vấn đề.
Thêm vào đó, khi đặc tả không rõ ràng, người kiểm thử cần phải dự đoán khi thực hiện kiểm thử khám phá, điều này phụ thuộc vào kỹ năng và kinh nghiệm của người kiểm thử. Kiểm thử khám phá rất hiệu quả trong việc phát hiện các lỗi nghiêm trọng, nhưng sự khác biệt về kỹ năng và kinh nghiệm giữa những người kiểm thử có thể ảnh hưởng đến kết quả kiểm thử.
Kiểm thử dựa trên danh sách kiểm tra (Checklist-Based Testing)
Trong kiểm thử dựa trên danh sách kiểm tra, danh sách kiểm tra được sử dụng để thiết kế các trường hợp kiểm thử. Danh sách kiểm tra liệt kê các điều kiện kiểm thử và ở Nhật Bản, thường được gọi là “quan điểm kiểm thử“, được lập thành danh sách và sử dụng trong thiết kế kiểm thử. Danh sách kiểm tra cần được tạo ra phù hợp với đối tượng kiểm thử. Có thể tạo mới từ đầu hoặc sử dụng danh sách kiểm tra có sẵn và tùy chỉnh lại. Dù là trường hợp nào, danh sách kiểm tra phải được chuẩn bị như một phần của phân tích kiểm thử.
Danh sách kiểm tra được tạo ra dựa trên kinh nghiệm của người kiểm thử, tương tự như phương pháp dự đoán lỗi (Error Guessing). Ngoài ra, các thông tin sau cũng có thể được xem xét:
- Các yếu tố quan trọng đối với người dùng.
- Hiểu biết về lý do và cách thức phần mềm không đạt yêu cầu.
Kiểm thử dựa trên danh sách kiểm tra không chỉ được sử dụng cho kiểm thử chức năng mà còn có thể được áp dụng cho kiểm thử phi chức năng. Kiểm thử phi chức năng thường yêu cầu kiến thức chuyên môn và có thể thiếu rõ ràng trong tài liệu đặc tả, vì vậy kiểm thử dựa trên danh sách kiểm tra thường được sử dụng hiệu quả trong những tình huống này.
Danh sách kiểm tra có thể được viết ở mức độ trừu tượng cao, và từ đó người kiểm thử thiết kế các trường hợp kiểm thử và thực hiện kiểm thử. Trong một số trường hợp, người kiểm thử có thể trực tiếp thực hiện kiểm thử dựa trên danh sách kiểm tra. Phương pháp này có lợi thế là có thể thực hiện kiểm thử rộng rãi, nhưng có nhược điểm là việc giải thích danh sách kiểm tra có thể khác nhau giữa các người kiểm thử, dẫn đến sự khác biệt trong cách thực hiện kiểm thử. Hơn nữa, vì kiểm thử khó có thể tái hiện lại, cần phải cẩn trọng khi áp dụng phương pháp này.
※Bài test luyện tập: