Các cụm defect thay đổi theo thời gian
Nguyên lý kiểm thử - Nghịch lý thuốc trừ sâu Nếu các bài kiểm thử giống nhau được lặp đi lặp lại nhiều lần, cuối cùng tập hợp các trường hợp kiểm thử giống nhau sẽ không còn tìm thấy bất kỳ lỗi mới nào nữa. Để khắc phục "nghịch lý thuốc trừ sâu" này, kịch bản kiểm thử phải thường xuyên được làm mới, từ đó có khả năng tìm ra nhiều defect hơn.
Theo thời gian, khi cải thiện toàn bộ vòng đời phát triển phần mềm và áp dụng kiểm thử tĩnh sớm, thì có thể thấy rằng đến giai đoạn kiểm thự động sẽ tìm ra ít defect hơn.
Khi biện pháp ngăn ngừa lỗi bắt đầu, ta thấy số lỗi giảm xuống, như thể hiện trong Hình 1.3.
Phần đầu tiên của cải tiến cho phép giảm thiểu các lỗi trong vận hành; về sau, những cải tiến giúp hiệu quả hơn trong việc cung cấp phần mềm với ít lỗi hơn.
Khi các “điểm nóng” về lỗi được xử lý, ta cần chuyển trọng tâm đến vấn đề khác, ví dụ như nhóm rủi ro tiếp theo.
Theo thời gian, trọng tâm của chúng ta có thể thay đổi từ việc tìm lỗi code sang xem xét các yêu cầu trong tài liệu đặc tả và tài liệu thiết kế, tìm kiếm cách để cải tiến quy trình giúp ngăn chặn lỗi trong sản phẩm.
Như Hình 1.3 ở trên, bản phát hành 9 và 10 có chi phí và nỗ lực tổng thể liên quan đến đánh giá và kiểm thử thấp hơn nhiều so với bản phát hành 4 hoặc 7.
Gỡ lỗi ĐỂ loại bỏ DEFECT
Khi có một lỗi cần phải sửa, lập trình viên phải thực hiện một số công việc để xác định vị trí defect trong code và thực hiện sửa chữa. Quá trình này được gọi là gỡ lỗi (debugging). Lập trình viên sẽ kiểm tra code để tìm nguyên nhân ngay của vấn đề, sửa code và kiểm tra xem code hiện tại có đang thực thi như mong đợi hay không.
Sau đó, bản sửa lỗi thường được kiểm tra riêng (ví dụ: bởi một người kiểm thử độc lập) để xác nhận bản sửa lỗi.
Phần mềm có lỗi không?
Nguyên lý kiểm thử - Kiểm thử cho thấy sự hiện diện của defect Kiểm thử có thể cho thấy sự hiện diện của lỗi, nhưng không thể chứng minh rằng không có lỗi.
Kiểm thử làm giảm xác suất các lỗi chưa được phát hiện còn lại trong phần mềm nhưng, ngay cả khi không tìm thấy lỗi nào, nó không phải là bằng chứng để khẳng định phần mềm không có lỗi.
Nguyên tắc này xuất phát từ lý thuyết về quá trình thực nghiệm khoa học và đã được những người thử nghiệm áp dụng.
Hiểu một cách đơn giản là chúng ta nhìn thấy nhiều thiên nga trắng, nhưng không thể nói “Tất cả thiên nga đều trắng”. Tuy nhiên, khi nhìn thấy một con thiên nga đen, chúng ta có thể nói “Không phải tất cả thiên nga đều trắng”.
Nếu không tìm thấy lỗi nghĩa là người dùng sẽ chấp nhận phần mềm?
Nguyên lý kiểm thử - Quan điểm sai lầm về việc hết lỗi Việc tìm kiếm và sửa chữa các lỗi sẽ không giúp ích được gì nếu hệ thống được xây dựng không sử dụng được và không đáp ứng được nhu cầu và mong đợi của người dùng.
Có một nguyên tắc quan trọng khác mà chúng ta phải xem xét đó là khách hàng không quan tâm đến lỗi hoặc số lượng lỗi, ngoại trừ trường hợp họ bị ảnh hưởng trực tiếp bởi sự không ổn định của phần mềm.
Người sử dụng phần mềm quan tâm hơn đến phần mềm hỗ trợ họ hoàn thành công việc một cách hiệu quả. Phần mềm phải đáp ứng nhu cầu của họ.
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây.
