Độ phức tạp Cyclomatic (Cyclomatic Complexity) là một độ đo phần mềm, được phát triển bởi Thomas J. McCabe, Sr. vào năm 1976. Nó được sử dụng để chỉ ra độ phức tạp của một chương trình.
Kiểm thử hộp trắng (White-box testing) là kỹ thuật kiểm thử phần mềm mà trong đó cấu trúc bên trong, thiết kế và cách thức hoạt động của phần mềm được biết đến. Các phương pháp kiểm thử hộp trắng bao gồm:
- Phủ kiểm thử câu lệnh (Statement coverage): Đảm bảo mỗi câu lệnh trong mã nguồn được thực thi ít nhất một lần. - Phủ kiểm thử điều kiện (Condition coverage): Đảm bảo tất cả các điều kiện logic trong mã nguồn (ví dụ: trong câu lệnh if) được kiểm tra với cả giá trị đúng và sai. - Phủ kiểm thử quyết định (Decision coverage) hay còn gọi là Branch coverage: Đảm bảo mỗi nhánh (ví dụ: nhánh then và else của câu lệnh if) được thực thi ít nhất một lần. - Phủ kiểm thử đường dẫn (Path coverage): Đảm bảo tất cả các đường dẫn có thể có trong mã nguồn được thực thi ít nhất một lần. - Kiểm thử bảng quyết định (Decision table testing): Là một kỹ thuật kiểm thử hộp đen, nhưng cũng có thể được sử dụng trong kiểm thử hộp trắng để đảm bảo tất cả các kết hợp đầu vào và hành động tương ứng được kiểm tra.
Do đó, cả "Phủ kiểm thử câu lệnh", "Phủ kiểm thử bảng quyết định" và "Phủ kiểm thử điều kiện" đều thuộc kỹ thuật kiểm thử hộp trắng.
Mục đích chính của việc lựa chọn testcase là để đánh giá cả rủi ro và chất lượng của phần mềm. Testcase giúp phát hiện các lỗi tiềm ẩn (đánh giá rủi ro) và xác định mức độ đáp ứng của phần mềm so với các yêu cầu đặt ra (đánh giá chất lượng). Vì vậy, đáp án C là chính xác nhất.
Rủi ro bao gồm cả khả năng một sự cố xảy ra (xác suất) và mức độ nghiêm trọng của hậu quả nếu sự cố đó xảy ra (tác động). Các testcase không phải là một phần của định nghĩa rủi ro mà là một phần của quy trình kiểm thử để giảm thiểu rủi ro.
Phân tích đột biến (Mutation testing) là một kỹ thuật kiểm thử phần mềm được sử dụng để đánh giá chất lượng của bộ ca kiểm thử (test case). Kỹ thuật này bao gồm việc tạo ra các phiên bản "đột biến" của mã nguồn bằng cách thực hiện các thay đổi nhỏ, ví dụ như thay đổi một toán tử hoặc một giá trị. Sau đó, các ca kiểm thử được chạy trên các phiên bản đột biến này. Một ca kiểm thử được coi là "giết" một đột biến nếu nó phát hiện ra sự thay đổi đó (tức là, kết quả chạy ca kiểm thử trên mã gốc khác với kết quả chạy trên mã đột biến). Chất lượng của bộ ca kiểm thử được đánh giá dựa trên số lượng đột biến mà nó "giết" được.
Bước 1 của gỡ lỗi là xác định bản chất và vị trí của lỗi. Vậy bước thứ hai, sau khi đã biết lỗi ở đâu và tại sao nó xảy ra, chính là sửa lỗi đó. Các đáp án khác không hợp lý vì 'xem lỗi', 'định vị lỗi' đã được thực hiện ở bước 1, và 'gửi lỗi' không phải là một bước trong quy trình gỡ lỗi thông thường.
