Theo một nghĩa nghiêm ngặt, thật không công bằng khi đưa ra bất kỳ khiếu nại nào cho đến khi chất lượng của bộ thử nghiệm được thiết lập. Vượt qua 100% các bài kiểm tra là không có ý nghĩa nếu hầu hết các bài kiểm tra là tầm thường hoặc lặp đi lặp lại với nhau.
Câu hỏi là: Trong lịch sử của dự án, có bất kỳ thử nghiệm nào phát hiện ra lỗi không? Mục tiêu của một bài kiểm tra là tìm lỗi. Và nếu họ không làm, họ đã thất bại khi thử nghiệm. Thay vì cải thiện chất lượng mã, họ chỉ có thể mang lại cho bạn cảm giác an toàn sai lầm.
Để cải thiện thiết kế thử nghiệm của bạn, bạn có thể sử dụng (1) kỹ thuật whitebox, (2) kỹ thuật hộp đen và (3) thử nghiệm đột biến.
(1) Dưới đây là một số kỹ thuật whitebox tốt để áp dụng cho các thiết kế thử nghiệm của bạn. Một thử nghiệm whitebox được xây dựng với mã nguồn cụ thể trong tâm trí. Một khía cạnh quan trọng của thử nghiệm whitebox là bảo hiểm mã:
- Là mọi chức năng được gọi là? [Bảo hiểm chức năng]
- Là mỗi tuyên bố thực hiện? [Bảo hiểm tuyên bố-- Cả bảo hiểm chức năng và bảo hiểm tuyên bố đều rất cơ bản, nhưng tốt hơn là không có gì]
- Đối với mọi quyết định (như
ifhoặc while), bạn có một bài kiểm tra buộc nó là đúng và khác có buộc nó là sai không? [Bảo hiểm quyết định]
- Đối với mọi điều kiện là kết hợp (sử dụng
&&) hoặc phân tách (sử dụng ||), mỗi biểu thức con có kiểm tra trong đó đúng / sai không? [Bảo hiểm điều kiện]
- Phạm vi vòng lặp: Bạn có kiểm tra buộc 0 lần lặp, 1 lần lặp, 2 lần lặp không?
- Là mỗi
breaktừ một vòng lặp được bảo hiểm?
(2) Các kỹ thuật hộp đen được sử dụng khi có sẵn các yêu cầu, nhưng bản thân mã thì không. Những điều này có thể dẫn đến các bài kiểm tra chất lượng cao:
- Các bài kiểm tra hộp đen của bạn có bao gồm nhiều mục tiêu kiểm tra không? Bạn sẽ muốn các bài kiểm tra của mình "mập": Họ không chỉ kiểm tra tính năng X mà còn kiểm tra Y và Z. Sự tương tác của các tính năng khác nhau là một cách tuyệt vời để tìm lỗi.
- Trường hợp duy nhất bạn không muốn kiểm tra "chất béo" là khi bạn đang kiểm tra một tình trạng lỗi. Ví dụ: kiểm tra đầu vào người dùng không hợp lệ. Nếu bạn đã cố gắng đạt được nhiều mục tiêu kiểm tra đầu vào không hợp lệ (ví dụ: mã zip không hợp lệ và địa chỉ đường phố không hợp lệ) thì có khả năng một trường hợp đang che giấu trường hợp khác.
- Xem xét các loại đầu vào và tạo thành một "lớp tương đương" cho các loại đầu vào. Ví dụ: nếu mã của bạn kiểm tra xem một tam giác có bằng nhau không, thì thử nghiệm sử dụng một tam giác có các cạnh (1, 1, 1) có thể sẽ tìm thấy các loại lỗi tương tự như dữ liệu thử nghiệm (2, 2, 2) và (3, 3, 3) sẽ tìm thấy. Tốt hơn là dành thời gian của bạn nghĩ về các lớp đầu vào khác. Ví dụ: nếu chương trình của bạn xử lý thuế, bạn sẽ muốn kiểm tra cho từng khung thuế. [Đây được gọi là phân vùng tương đương.]
- Các trường hợp đặc biệt thường liên quan đến khuyết tật. Dữ liệu thử nghiệm của bạn cũng phải có các giá trị biên, chẳng hạn như các giá trị trên, trên hoặc dưới các cạnh của tác vụ tương đương. Ví dụ: khi kiểm tra thuật toán sắp xếp, bạn sẽ muốn kiểm tra với một mảng trống, một mảng phần tử đơn, một mảng có hai phần tử và sau đó là một mảng rất lớn. Bạn nên xem xét các trường hợp ranh giới không chỉ cho đầu vào, mà còn cho đầu ra. [Đây là cuộc gọi phân tích giá trị biên.]
- Một kỹ thuật khác là "Lỗi đoán." Bạn có cảm giác nếu bạn thử một số kết hợp đặc biệt mà bạn có thể làm cho chương trình của bạn bị phá vỡ? Sau đó, hãy thử nó! Hãy nhớ rằng: Mục tiêu của bạn là tìm lỗi, không xác nhận rằng chương trình hợp lệ . Một số người có sở trường để đoán lỗi.
(3) Cuối cùng, giả sử bạn đã có rất nhiều bài kiểm tra hay về độ bao phủ của whitebox và các kỹ thuật hộp đen được áp dụng. Bạn còn có thể làm gì khác nữa không? Đã đến lúc kiểm tra bài kiểm tra của bạn . Một kỹ thuật bạn có thể sử dụng là Kiểm tra đột biến.
Theo thử nghiệm đột biến, bạn thực hiện sửa đổi (bản sao) chương trình của mình, với hy vọng tạo ra lỗi. Một đột biến có thể là:
Thay đổi một tham chiếu của một biến thành một biến khác; Chèn hàm abs (); Thay đổi ít hơn thành lớn hơn; Xóa một tuyên bố; Thay một biến bằng một hằng số; Xóa một phương thức ghi đè; Xóa một tham chiếu đến một siêu phương thức; Thay đổi thứ tự đối số
Tạo vài chục đột biến, ở nhiều nơi trong chương trình của bạn [chương trình sẽ vẫn cần phải biên dịch để kiểm tra]. Nếu các bài kiểm tra của bạn không tìm thấy các lỗi này, thì bây giờ bạn cần phải viết một bài kiểm tra có thể tìm thấy lỗi trong phiên bản đột biến của chương trình của bạn. Khi một bài kiểm tra tìm thấy lỗi, bạn đã giết chết dị nhân và có thể thử một lỗi khác.
Phụ lục : Tôi quên đề cập đến hiệu ứng này: Lỗi có xu hướng co cụm . Điều đó có nghĩa là bạn càng tìm thấy nhiều lỗi trong một mô-đun, xác suất bạn sẽ tìm thấy càng nhiều lỗi càng cao. Vì vậy, nếu bạn có một thử nghiệm thất bại (có nghĩa là thử nghiệm thành công, vì mục tiêu là tìm lỗi), bạn không chỉ nên sửa lỗi mà còn nên viết thêm các thử nghiệm cho mô-đun, sử dụng kỹ thuật trên.
Chừng nào bạn còn tìm thấy lỗi với tốc độ ổn định, các nỗ lực kiểm tra phải tiếp tục. Chỉ khi có sự suy giảm về tỷ lệ lỗi mới được tìm thấy, bạn mới có niềm tin rằng bạn đã nỗ lực thử nghiệm tốt cho giai đoạn phát triển đó.