Kiểm thử chỉ chứng minh được rằng sản phẩm có lỗi, Kiểm thử phần mềm không thể chứng minh sản phẩm không có lỗi. Nghĩa là sản phẩm luôn có lỗi cho dù có kiểm thử bao nhiêu. Do đó cần thiết kế các Test case sao cho có thể tìm nhiều lỗi càng tốt.
Kiểm thử được thực hiện bằng những kỹ thuật khác nhau. Kiểm thử làm giảm xác suất lỗi chưa tìm thấy vẫn còn trong phần mềm.
2. Exhaustive testing is impossible (Kiểm thử toàn bộ là không thể)
Kiểm thử toàn bộ là không thể do yếu tố thời gian và chi phí,
Thay vì cố gắng test toàn bộ nên sử dụng phân tích rủi ro, kỹ thuật kiểm thử và mức độ ưu tiên để tập trung Test các trường hợp ưu tiên và rủi ro cao.
3. Early testing saves time and money (Kiểm thử càng sớm tiết kiệm thời gian và tiền)
Tìm lỗi sớm cả hoạt động test tính và test động nên bắt đầu sớm có thể trong vòng đời phát triển phần mềm.
Cần phát hiện bug từ bước đầu tiên như nghiên cứu yêu cầu (Requirement), thiết kế (design).
Test sớm giúp giảm hoặc loại bỏ chi phí thay đổi.
4. Defects cluster together (Lỗi thường được phân bố tập trung)
Lỗi tập trung vào những module, thành phần chức năng chính của hệ thống.
Theo nguyên lý parent: 80% số lượng lỗi được tìm thấy trong 20% tính năng của hệ thống. Do đó cần xác định những module có tính rủi ro và nhiều lỗi để tập trung tìm kiếm lỗi nhanh và hiệu quả hơn.
Nếu bug ở module này thì chức năng tương tự hoặc liên quan ở module khác cũng sẽ bị lỗi.
5. Beware of the pesticide paradox (Nghịch lý thuốc trừ sâu)
Nếu thực hiện lặp đi lặp lại 1 bộ Test case thì có khả năng rất thấp bạn sẽ tìm được lỗi từ những trường hợp kiểm thử này. Do hệ thống ngày càng hoàn thiện những lỗi được tìm thấy lúc trước đã được sửa trong lúc bộ test case đã cũ.
Khi một lỗi được sửa hay hay một tính năng mới được thêm vào thì chúng ta nên làm test hồi quy nhằm đảm bảo những thay đổi này không ảnh hưởng đến những vùng sản phẩm khác.
6. Testing is context dependent (Kiểm thử phụ thuộc vào ngữ cảnh)
Quá trình kiểm thử được thực hiện khác nhau trong các ngữ cảnh khác nhau.
Tùy thuộc vào loại ứng dụng ví dụ như Web, APP, Windown, API, Batch
Tùy thuộc vào quy trình phát triển phần mềm đang sử dụng trong doanh nghiệp,
Hoặc là do đặc thù từng loại nghiệp vụ sản phẩm.
7. Absence-of-errors is a fallacy (Quan niệm sai lầm về việc “hết lỗi”)
Việc không tìm thấy lỗi không có nghĩa là sản phẩm không còn lỗi. Lỗi có thể xảy ra sau khi chạy một thời gian .
Test và fix tất cả các bug theo yêu cầu đặc tả không có nghĩa là sản phẩm khi người dùng sử dụng sẽ được chấp nhận
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
SUBSCRIBE TO OUR NEWSLETTER
