7 NGUYÊN LÝ KIỂM THỬ PHẦN MỀM
Để tìm được các lỗi sớm nhất có thể, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt trong vòng đời phát triển phần mềm hoặc hệ thống.
Nguyên lý 1: Kiểm thử cho thấy sự hiện diện của lỗi
Kiểm thử có thể cho thấy sự có mặt của các lỗi, nhưng không thể chứng minh phần mềm không có lỗi. Kiểm thử giảm xác suất của các lỗi chưa được tìm thấy vẫn còn trong phần mềm.
Nguyên lý 2: Kiểm thử toàn bộ là không thể
Kiểm thử mọi thứ là không thực hiện được, trừ khi nó chỉ bao gồm một số trường hợp bình thường. Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên mức độ ưu tiên để tập trung nỗ lực kiểm thử vào một số điểm cần thiết.
Ví dụ: Chúng ta có một phần mềm dùng để đếm số lượng nguyên âm khi chúng ta nhập một từ có 5 ký tự vào Textbox như sau:
Nếu chúng ta kiểm thử hết tất cả các từ 5 chữ có thể có (ví dụ: apple, hello, awake,…) thì chúng ta sẽ cần tới 26 mũ 5 = 11.881.376 Test Cases để kiểm thử, điều này là bất khả thi vì những vấn đề như thời gian, nhân lực, chi phí không cho phép. Do đó, chúng ta cần có những kỹ thuật kiểm thử phù hợp để rút ngắn được thời gian kiểm thử mà vẫn đảm bảo phần mềm hoạt động đúng theo yêu cầu (ví dụ các kỹ thuật phân vùng tương đương, kỹ thuật phân tích giá trị biên, kỹ thuật dùng bảng quyết định,…)
Nguyên lý 3: Kiểm thử sớm
Để tìm được các lỗi sớm nhất có thể, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt trong vòng đời phát triển phần mềm hoặc hệ thống.
Nguyên lý 4 – Sự tập trung của lỗi
Nỗ lực kiểm thử nên tập trung một cách cân đối vào mật độ lỗi dự kiến và lỗi phát hiện ra sau đó trong các mô-đun. Một số ít các mô-đun thường chứa nhiều lỗi không phát hiện ra trong lúc kiểm thử trước khi phát hành (release), hoặc chịu trách nhiệm cho hầu hết các lỗi hoạt động của phần mềm.
Để hiểu rõ hơn nguyên lý này, ta cần xem xét 3 điều sau:
1. Nguyên tắc tổ gián: chỗ nào có một vài con gián thì ở đâu đó xung quanh nó sẽ có cả tổ gián, có rất nhiều gián; chỗ nào có một vài bug thì xung quanh, gần gần chỗ đó sẽ có nhiều bug.
2. Nguyên tắc 80/20: thông thường 20% chức năng quan trọng trong một phần mềm có thể gây ra đến 80% tổng số bug phát hiện được trong phần mềm đó.
3. Kiểm thử toàn bộ là không thể (nguyên lý kiểm thử 2): do đó cần phải analysis (phân tích) + priorities (tính toán mức độ ưu tiên) để quyết định tập trung vào kiểm thử những chỗ nào.
Trình tự kiểm thử có thể như sau: => Test kỹ chức năng quan trọng => tìm bug => test những gì liên quan và những chức năng gần nó để tìm ra bug nhiều hơn.
Nguyên lý thứ 5 – Nghịch lý thuốc trừ sâu
Nếu việc kiểm thử tương tự nhau được lặp đi lặp lại nhiều lần, thì cuối cùng sẽ có một số trường hợp kiểm thử (ca kiểm thử – test case) sẽ không còn tìm thấy bất kỳ lỗi nào mới. Để khắc phục “nghịch lý thuốc trừ sâu” này, các trường hợp kiểm thử cần phải được xem xét và sửa đổi thường xuyên, và cần phải viết các Test Cases mới và khác nhau để thực hiện kiểm thử nhiều phần khác nhau của phần mềm hoặc hệ thống để tìm ra lỗi tiềm ẩn nhiều hơn nữa.
Nguyên lý này giống như việc trừ sâu trong nông nghiệp, nếu chúng ta cứ phun một loại thuốc với nồng độ giống nhau trong một khoảng thời gian dài thì có một số con sâu sẽ quen dần và cuối cùng việc phun thuốc giống như là tắm chúng vậy (bị lờn thuốc), lúc đó chúng ta không thể diệt sạch chúng được. Do vậy, để diệt sạch sâu một cách hiệu quả, người ta thường thay đổi loại thuốc trừ sâu, mỗi loại chỉ dùng trong khoảng thời gian ngắn.
Nguyên lý 6 – Kiểm thử phụ thuộc vào ngữ cảnh
Nguyên tắc này nói lên việc kiểm thử phụ thuộc vào ngữ cảnh, tùy vào ngữ cảnh khác nhau mà mục tiêu và chiến lược kiểm thử của chúng ta cũng khác nhau, ví dụ: chiến lược kiểm thử một phần mềm kế toán sẽ khác với kiểm thử một trang web thương mại điện tử.
Nguyên lý 7 – Sai lầm về việc không có lỗi
Việc tìm và sửa chữa lỗi sẽ không giúp được gì nếu hệ thống được xây dựng xong nhưng không thể dùng được và không đáp ứng được nhu cầu và sự mong đợi của khách hàng. (Nghĩa là nếu sau khi code, test rồi fix bug, làm đủ tất cả các trường hợp và cuối cùng cho ra một sản phẩm hoạt động rất ổn định, ít lỗi nhưng lại không đáp ứng được nhu cầu của khách hàng hoặc sai ý khách hàng thì dự án phần mềm đó coi như thất bại cho dù phần mềm có đẹp đến đâu, có ổn định đến đâu,….). Quan trọng nhất là phần mềm phải đáp ứng theo yêu cầu khách hàng và khách hàng cảm thấy vui vẻ, hạnh phúc khi sử dụng phần mềm đó.
Mr. Phước Phan
PLT SOLUTIONS