Khi nào chúng ta có thể đáp ứng các mục tiêu kiểm thử?
Nguyên lý kiểm thử - Kiểm thử sớm Các hoạt động kiểm thử phải bắt đầu càng sớm càng tốt trong vòng đời phát triển phần mềm và phải tập trung vào các mục tiêu đã xác định.
Có thể sử dụng cả kiểm thử động và kiểm thử tĩnh như một phương tiện để đạt được các mục tiêu kiểm thử tương tự. Cả hai đều cung cấp thông tin để cải thiện hệ thống và quy trình phát triển phần mềm.
Chúng ta đã đề cập ở trên rằng kiểm thử có thể có các mục đích và mục tiêu khác nhau, thường bao gồm:
- Tìm kiếm defect;
- Đạt được sự tin tưởng và cung cấp thông tin về chất lượng;
- Ngăn ngừa defect.
Nhiều loại hoạt động xem xét và kiểm thử diễn ra ở các giai đoạn khác nhau trong vòng đời phát triển. Chúng có các mục tiêu khác nhau.
Có các loại kiểm thử nào?
Kiểm thử sớm (ví dụ như hoạt động xem xét và thiết kế thử nghiệm sớm) giúp phát hiện sớm defect, tốn ít chi phí để tìm và sửa chữa. Khi lập trình, các lập trình viên và tester thường chạy một tập hợp các bài kiểm tra để xác định và sửa chữa defect trong phần mềm.
Trong quy trình kiểm thử (bao gồm kiểm thử thành phần, kiểm thử tích hợp và kiểm thử hệ thống), mục tiêu chính là tìm ra càng nhiều lỗi càng tốt, do đó các lỗi trong phần mềm được xác định và được sửa chữa.
Sau quy trình kiểm thử đó, người dùng có thể thực hiện kiểm thử chấp nhận để xác nhận rằng hệ thống hoạt động như mong đợi và đã đáp ứng các yêu cầu.
Mục tiêu của kiểm thử là sữa chữa defect?
Việc sửa chữa defect không phải lúc nào cũng là mục tiêu của kiểm thử. Đôi khi, đơn giản là ta chỉ muốn thu thập thông tin và đo lường phần mềm.
Điều này có thể ở dạng các thước đo thuộc tính chẳng hạn như thời gian trung bình giữa các lần hỏng hóc (MTBF – Mean time between failures ) để đánh giá độ tin cậy hoặc mật độ lỗi trong phần mềm, đánh giá và hiểu rủi ro của việc phát hành nó.
Khi bảo trì phần mềm bằng cách sửa lỗi, chúng ta sẽ thay đổi phần mềm đã được sử dụng. Trong trường hợp đó, mục tiêu của kiểm thử có thể là để đảm bảo rằng chúng ta không mắc error và tạo ra các defect khi thay đổi phần mềm. Đây được gọi là kiểm thử hồi quy (regression testing) – kiểm thử để đảm bảo việc sửa chữa một tính năng này không làm ảnh hưởng đến tính năng khác của phần mềm.
Có thể tiếp tục kiểm thử hệ thống sau khi nó được đưa vào sử dụng. Trong trường hợp này, mục tiêu chính có thể là đánh giá các đặc tính của hệ thống như độ tin cậy hoặc tính khả dụng.
Defect clusterting
Nguyên lý kiểm thử - Phân cụm defect (Defect clustering) Một số lượng nhỏ các mô đun lại chưa đa số các lỗi trong quá trình kiểm thử, hoặc chưa nhiều lỗi nhất trong lúc vận hành.
Tập trung vào các defect có thể giúp ta lập kế hoạch kiểm thử. Việc xem xét defect và failure để cải tiến quy trình cho phép cải thiện quy trình kiểm thử, quy trình thiết kế và phát triển.
Các defect có xu hướng phân cụm. Điều này có thể xảy ra do một số phần của mã code đặc biệt phức tạp và phức tạp, hoặc do việc thay đổi phần mềm và các sản phẩm khác có xu hướng gây ra các lỗi sai. Người kiểm thử thường sẽ sử dụng thông tin này khi thực hiện đánh giá rủi ro của họ để lập kế hoạch kiểm thử và sẽ tập trung vào các “điểm nóng” đó.
Trọng tâm chính của review là gì?
Trọng tâm chính của đánh giá (review) và kiểm thử tĩnh là thực hiện kiểm thử càng sớm càng tốt, tìm kiếm và sửa chữa defect với chi phí rẻ hơn, ngăn ngừa defect xuất hiện ở các giai đoạn sau của dự án này. Các hoạt động này giúp tìm ra các defect sớm hơn và xác định sớm các cụm lỗi tiềm năng.
Ngoài ra, một kết quả quan trọng của kiểm thử là thông tin trong việc hỗ trợ đánh giá rủi ro; những đánh giá này sẽ đóng góp vào việc lập kế hoạch cho thực thi kiểm thử được thực hiện sau này trong vòng đời phát triển phần mềm.
Ta cũng có thể tiến hành phân tích nguyên nhân gốc rễ lỗi để ngăn ngừa các defect và failure xảy ra lần nữa, có thể xác định được nguyên nhân của các cụm hiện tại và các cụm tiềm năng trong tương lai.
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây.
