Sau bài này, bạn sẽ học được về 7 nguyên tắc cơ bản của kiểm thử phần mềm sau:
- Kiểm thử chứng minh sự hiện diện của lỗi
- Kiểm thử toàn bộ là không khả thi
- Kiểm thử càng sớm càng tốt
- Lỗi thường được phân bố tập trung
- Nghịch lý thuốc trừ sâu
- Kiểm thử phụ thuộc vào ngữ cảnh
- Quan niệm sai lầm về việc “hết lỗi”
Chúng ta sẽ lần lượt đi qua 7 nguyên tắc này nhé
#1: Kiểm thử chứng mình sự hiện diện của lỗi
Kiểm thử chỉ có thể 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 mình rằng sản phẩm không còn lỗi. Nghĩa là sản phẩm luôn có lỗi cho dù có kiểm thử nhiều bao nhiêu. Do đó, điều quan trọng là chúng ta phải thiết kế các trường hợp kiểm thử (test case) sao cho có thể tìm được càng nhiều lỗi càng tốt
#2: Kiểm thử toàn bộ là không khả thi
Trừ khi sản phẩm được kiểm thử quá đơn giản cũng như không có nhiều giá trị đầu vào (chẳng hạn như “Hello World”) thì việc chứng minh sản phẩm không còn bug cho dù có kiểm thử nhiều đến đâu là không khả thi. Hầu hết các sản phẩm ngày nay rất đa dạng và phức tạp do được phát triển trên nhiều nền tảng, công nghệ phong phú cũng như khả năng lưu trữ kết nối dữ liệu lớn, khiến việc kiểm thử trở nên khó khăn và việc kiểm thử toàn bộ là gần như không thể.
Do đó, việc chúng ta có thể làm là chọn thực thi những loại kiểm thử quan trọng nhất dựa trên phân tích rủi ro cũng như tầm quan trọng và độ ưu tiên của việc kiểm thử. Nghĩa là phải lên kế hoạch kiểm thử, thiết kế trường hợp kiểm thử sao cho có độ bao phủ nhiều nhất và giảm thiểu rủi ro sót lỗi khi đến tay người dùng
#3: Kiểm thử càng sớm càng tốt
Hoạt động kiểm thử được triển khai sớm chừng nào thì tốt chừng ấy. Chẳng hạn, chúng ta có thể bắt đầu hoạt động kiểm thử ngay từ khi sản phẩm bắt đầu hình thành chẳng hạn như giai đoan lấy yêu cầu khách hàng hay thiết kế tài liệu sản phẩm.
Thông thường, thời gian cho kiểm thử thường bị co lại khi sản phẩm gần ra thị trường. Do đó, việc kiểm thử sớm trong giai đoạn đầu sẽ giúp chúng ta có thời gian để tiến hành kiểm thử trong từng giai đoạn một cách đầy đủ.
Ngoài ra ai làm phần mềm cũng biết được rằng việc phát hiện lỗi càng trể bao nhiêu thì chi phí để sửa lỗi càng cao bấy nhiêu. Tương tự, việc thay đổi yêu cầu không đúng ngay từ đầu thường tốn ít chi phí thay đổi tính năng trong hệ thống.
#4: Lỗi phân bố tập trung
Trong quá trình kiểm thử, chúng ta sẽ có thể dễ dàng quan sát thấy đa phần những lỗi tìm được thường chỉ liên quan đến một vài tính năng của hệ thống. Điều này cũng thuận theo nguyên lý Pareto: 80% số lượng lỗi được tìm thấy trong 20% tính năng của hệ thống.
Điều này cũng có nghĩa là khi tìm lỗi, chúng ta nên tập trung vào những module, thành phần chức năng chính của hệ thống. Một lỗi trên những module chính này có giá trị gấp nhiều lần lỗi tìm được trên những module phụ khác.
#5: Nghịch lý thuốc trừ sau (pesticide paradox)
Trong kiểm thử phần mềm, nếu bạn cứ thực thi lặp đi lặp lại một 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. Nguyên nhân là do khi 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 khi những trường hợp kiểm thử đã cũ. Do đó, khi một lỗi được sửa hay một tính năng mới được thêm vào, chúng ta nên tiến hành làm regression (kiểm thử hồi qui) nhằm mục đích đảm bảo những thay đổi này không ảnh hưởng đến những vùng khác của sản phẩm. Tuy nhiên, các trường hợp kiểm thử trong regression test cũng cần phải được cập nhật để phản ánh sự thay đổi tương ứng của hệ thống.
#6: Kiểm thử phần mềm phụ thuộc vào ngữ cảnh
Tuy vào loại cũng như bản chất của ứng dụng mà chúng ta sẽ áp dụng những phương thức, kỹ thuật, cũng như loại kiểm thử khác nhau.
Chẳng hạn như phần mềm trong các thiết bị y khoa cần sẽ được kiểm thử kỹ lưỡng hơn một trò chơi điện tử. Quan trọng hơn, việc kiểm thử trên loại thiết bị này đòi hỏi phải dựa trên đánh giá rủi ro, đáp ứng những qui định nghiêm ngặt trong y khoa cũng như một bộ kiểm thử đặc thù. Tương tự, một website “lớn” cần phải được một cách đầy đủ từ hiệu năng đến tính năng nhằm đảm bảo server không bị ảnh hưởng khi có nhiều người truy cập vào hệ thống
#7: Quan niệm sai lầm về việc “hết lỗi”
Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để tung ra thị trường. Việc không tìm thấy lỗi cũng có thể là do bộ trường hợp kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì nhằm tìm kiếm lỗi mới.
Ngoài 7 nguyên tắc trên, còn một số nguyên tắc khác cũng đáng được quan tâm như:
- Kiểm thử cần được làm bởi một bên độc lập: Kiểm thử không được thực thi bởi chính người hay đội làm ra sản phẩm đó vì họ thường “bảo vệ tính đúng đắn” của sản phẩm họ làm ra. Nói cách khác, kiểm thử cần thể hiện tính khách quan trong việc đánh giá chất lượng sản phẩm.
- Kiểm thần cần được thực thi từ người có năng lực: Việc kiểm thử đòi hỏi sự sáng tạo cũng như tinh thần trách nhiệm cao do đó việc kiểm thử cần được thực thi bởi người có năng lực trong việc thiết kế, phân tích, thực thi các trường hợp kiểm thử. Nói cách khác, kiểm thử không phải là công việc thứ cấp và giao cho ai làm cũng được.
- Kiểm thử cả input đầu vào đúng và sai: Chương trình phải đưa ra thông báo đúng khi input đầu vào không hợp lệ và chạy đúng khi input đầu vào hợp lệ.
- Sản phẩm cần phải được “giữ nguyên hiện trạng”: Sản phẩm không được phép chỉnh sửa thay đổi trong suốt quá trìn thực thi các trường hợp kiểm thử nhằm đảm bảo kết quả kiểm thử được nhất quán và chính xác.
- Cung cấp kết quả mong đợi (nếu có thể): Kết quả mong đợi là một phần không thể thiếu trong hoạt động kiểm thử. Việc biết được kết quả mong đợi sẽ giúp chúng ta đánh giá được kết quả kiểm thử.
Kết luận
Kiểm thử không phải chỉ đơn thuần là một hoạt động riêng lẻ mà là một loạt các hoạt động liên quan và bổ sung cho nhau và phức tạp. Tuy nhiên, việc dựa theo 7 nguyên tắc trên sẽ giúp cho chúng ta có cái nhìn tổng quát hơn về kiểm thử cũng như giúp chúng ta đánh giá được tính hiệu quả của hoạt động kiểm thử được thực thi.
-- Nguồn Internet--