Lợi nhuận:
- Khả năng nhận biết ba mặt của sự tin cậy giả tạo (không quyết đoán, tự khẳng định, khẳng định tầm thường) và áp dụng biện pháp giải độc
- Khả năng sử dụng kiểm tra đột biến và điểm đột biến làm thước đo chất lượng chính xác hơn so với mức độ bao phủ phần trăm bằng công cụ hoặc thủ công
- Khả năng định vị AI là đội đỏ chống lại thử nghiệm và săn lùng các sơ hở thử nghiệm mà không rơi vào bẫy khen ngợi
Trọng tâm của mô-đun này là cảnh báo định kỳ: bảng thử nghiệm phát sáng màu xanh lá cây không phải là bằng chứng về chất lượng. Nếu các bài kiểm tra mang lại cho bạn sự tự tin, bạn cần biết liệu sự tự tin đó là thật hay giả. Trong thời đại trí tuệ nhân tạo (AI), câu hỏi này trở nên quan trọng hơn bao giờ hết, bởi AI rất giỏi trong việc tạo ra các bài kiểm tra trôi chảy, trông mượt mà nhưng trống rỗng. Sự tự tin sai lầm - tin rằng phần mềm là chính xác vì các bài kiểm tra có màu xanh lá cây, trong khi trên thực tế, các bài kiểm tra không xác minh bất cứ điều gì - là điều nguy hiểm nhất có thể xảy ra với nhóm QA; bởi vì nó che giấu không phải là không có lỗi mà là bạn không thể nhìn thấy lỗi. Đơn vị này tập hợp triết lý xác thực của toàn bộ mô-đun thành một nguyên tắc: kiểm tra các bài kiểm tra của bạn.
Tiêu chuẩn vàng để đo lường chất lượng xét nghiệm: xét nghiệm đột biến
Cách mạnh mẽ nhất để hiểu liệu một thử nghiệm có thực sự bảo vệ hay không là thử nghiệm đột biến (thử nghiệm đột biến - một kỹ thuật tạo ra các biến dạng/đột biến nhỏ có chủ ý trong mã nguồn và đo lường xem các thử nghiệm có phát hiện ra các biến dạng này hay không). Logic rất đơn giản: nếu bạn cố tình phá mã (biến + thành -, a > thành >=, true thành false), bộ kiểm tra tốt sẽ phát hiện lỗi đó và chuyển sang màu đỏ. Nếu không, sự gián đoạn đó là một đột biến sống sót — vì vậy các thử nghiệm của bạn không thực sự bảo tồn được hành vi đó.
Điểm đột biến = đột biến bị tiêu diệt/tổng đột biến. Một gói có phạm vi phủ sóng 90% có thể có điểm đột biến là 40%; Điều này chỉ ra rằng các dòng đang hoạt động nhưng hành vi chưa được xác minh. Điểm đột biến là thước đo chất lượng trung thực hơn nhiều so với mức độ bao phủ phần trăm.
Mẹo: Có các công cụ đột biến tự động (PIT/Pitest cho Java, Stryker cho JavaScript/TypeScript, Stryker.NET cho .NET, mutmut cho Python). Chúng tự động tạo và kiểm tra hàng trăm đột biến. Nếu bạn không có công cụ thì ngay cả phương pháp "kiểm tra mã phá mã" thủ công cũng vô giá đối với các chức năng quan trọng.
Ba mặt của niềm tin giả tạo và thuốc giải độc của nó
Hình thức giả tin cậy
triệu chứng
thuốc giải độc
Kiểm tra mà không khẳng định
Mã hoạt động, không có gì được xác nhận
Khẳng định đúng đắn trong mọi bài kiểm tra; kiểm tra đột biến
bài kiểm tra tự xác nhận
Dự kiến = đầu ra của mã
Tính toán giá trị kỳ vọng một cách độc lập
Khẳng định tầm thường
"không rỗng", "200 được trả về"
Xác thực quy tắc kinh doanh/kết quả thực tế
Ngụy biện phạm vi cao
90% đường, mức độ bảo vệ thấp
Nhìn vào điểm đột biến
Khả năng chịu đựng thử nghiệm dễ vỡ
"Lại mắc kẹt, vượt qua"
Nguyên nhân gốc rễ + kiểm tra xác định
Sử dụng AI làm “đội đỏ”
AI vừa có thể tạo ra niềm tin giả vừa có thể trở thành đồng minh mạnh mẽ trong việc săn lùng nó. Sử dụng AI làm đội đỏ chống lại các bài kiểm tra của riêng bạn: hỏi “viết mã vượt qua các bài kiểm tra này nhưng sai” hoặc “tìm một cách lật đổ sẽ đánh lừa các bài kiểm tra này”. Nếu AI tìm thấy sơ hở trong các bài kiểm tra của bạn thì những sơ hở đó là rủi ro thực sự.
Thận trọng: Đừng hỏi AI "Chất lượng bài kiểm tra của tôi có tốt không?" và coi câu trả lời "có, tuyệt vời" là sự đảm bảo. AI có xu hướng tốt bụng. Thay vào đó, hãy thách thức AI thực hiện một nhiệm vụ cụ thể: “tạo ra một lỗi vượt qua các bài kiểm tra này”. Nếu nó có thể tạo ra lỗi đó thì các bài kiểm tra của bạn sẽ không phát hiện được lỗi đó.
Đột biến tương đương và giới hạn của điểm số
Kiểm tra đột biến rất mạnh mẽ, nhưng nó có một nhược điểm: một số đột biến hoàn toàn không thay đổi hành vi của mã. Chúng được gọi là đột biến tương đương (đột biến tương đương - mã bị hỏng, đột biến tạo ra kết quả giống hệt với kết quả ban đầu). Ví dụ: việc thay đổi giá trị ban đầu của một biến không bao giờ được sử dụng sẽ không ảnh hưởng đến kết quả đầu ra; Không có bài kiểm tra nào có thể và không nên nắm bắt được điều này. Vì vậy, điểm đột biến 100% thường không thể đạt được trong thực tế và không phải là mục tiêu. Việc loại bỏ các đột biến tương đương bằng tay tốn rất nhiều công sức; Vì vậy, đừng đọc điểm đột biến như một điểm thi tuyệt đối mà hãy coi đó là một chỉ báo trung thực về việc "bài kiểm tra của tôi có thực sự bảo vệ không?"
Cách tiếp cận thực tế là thế này: thay vì liên tục chạy thử nghiệm đột biến trên toàn bộ cơ sở mã, hãy chạy nó trên các mô-đun có rủi ro cao nhất và các quy tắc kinh doanh phức tạp nhất. Kiểm tra từng đột biến còn sót lại trong các mô-đun này; Nếu đó là khoảng cách thực sự, hãy thêm một bài kiểm tra; nếu đó là một đột biến tương đương, hãy đánh dấu nó bằng sự biện minh và vượt qua. AI có thể thực hiện sàng lọc ban đầu để đánh giá liệu một đột biến còn sót lại có tương đương hay không; nhưng quyết định cuối cùng được đưa ra bởi bạn, người biết mã đó làm gì.
Thận trọng: Kiểm tra đột biến tốn kém về mặt tính toán (tất cả các kiểm tra liên quan đều được chạy lại cho mỗi đột biến). Vì vậy, một chiến lược phổ biến và hợp lý là lên lịch kiểm tra sâu hàng tuần hoặc trước khi phát hành cho các mô-đun quan trọng, thay vì mỗi lần hợp nhất.
Dấu nhắc yếu / Dấu nhắc mạnh
Yếu: "Các bài kiểm tra của tôi đã đủ chưa?"
Strong: "Hoạt động như một đội đỏ cho chức năng và bộ kiểm thử này. (1) Tạo ra 8 đột biến trong mã có thể bị loại bỏ (thay thế toán tử, dịch chuyển ranh giới, đảo ngược điều kiện, thay thế giá trị trả về). (2) Đối với mỗi đột biến, hãy chỉ ra thử nghiệm nào trong số các thử nghiệm hiện có sẽ bắt được nó và thử nghiệm nào sẽ KHÔNG. (3) Đối với mỗi đột biến tồn tại, hãy viết một thử nghiệm mới sẽ giết chết nó. (4) Đồng thời cho thấy liệu bạn có thể tạo một ví dụ mã vượt qua tất cả các thử nghiệm này nhưng vi phạm quy tắc nghiệp vụ hay không. Mã+kiểm tra: [dán]"
Lời nhắc mạnh mẽ; Nó định vị AI như một giám khảo phá bài kiểm tra chứ không phải một cỗ máy khen ngợi.
Bốn mẫu có thể sao chép
1) Kiểm soát đột biến thủ công:
Tạo 8 đột biến đáng kể (gián đoạn nhỏ có chủ ý) cho mã này: thay thế toán tử số học, giới hạn so sánh (> so với >=), đảo ngược logic, trả về/thay thế liên tục, bỏ qua điều kiện. Đối với mỗi đột biến, hãy dự đoán thử nghiệm nào có sẵn sẽ bắt được nó hay không. Mã+kiểm tra: [dán]
2) Tiêu diệt đột biến còn sót lại:
Báo cáo kiểm tra đột biến sau đây chứa các đột biến còn sót lại (chưa được phát hiện): [danh sách/báo cáo]. Đối với mỗi đột biến, hãy viết một bài kiểm tra tối thiểu để loại bỏ đột biến đó (mã sẽ chuyển sang màu đỏ khi bị hỏng theo cách đó). Nhận xét về hành vi mà bài kiểm tra xác nhận.
3) Đội đỏ - xét nghiệm máu:
Bạn có thể viết mã ĐẠT TẤT CẢ các bài kiểm tra sau nhưng vi phạm quy tắc kinh doanh sau: [quy tắc kinh doanh]. Nếu vậy, lỗ hổng nào trong các thử nghiệm này cho phép điều này xảy ra? Thêm bài kiểm tra sẽ đóng lỗ hổng đó. Kiểm tra: [dán]
4) Kiểm tra chất lượng thử nghiệm:
Kiểm tra bộ thử nghiệm này để biết chất lượng. Đánh dấu vào mỗi bài kiểm tra: - Có khẳng định đúng hay là đạo cụ? - Giá trị mong đợi có độc lập, bắt nguồn từ mã không? - Nó có xác minh quy tắc kinh doanh hay điều gì đó tầm thường không? Cuối cùng đưa ra "điểm khẳng định đúng" ước tính và 3 bài kiểm tra yếu nhất. Kiểm tra: [dán]
ba trường hợp nhỏ
Trường hợp 1 - Độ bao phủ 92%, điểm đột biến 38%. Một đội dựa vào mức độ bao phủ cao. Khi thử nghiệm đột biến được thực hiện với Stryker, tỷ lệ là 38%: hầu hết các đột biến được tạo ra đều tồn tại. Đây là bằng chứng cho thấy các cuộc kiểm tra không chạy các dòng và xác minh hành vi. Nhóm đã đầu tư ba tuần vào chất lượng thử nghiệm; Điểm đột biến tăng lên 81% và hai lỗi tính toán thực sự đã được phát hiện trong các thử nghiệm nâng cao này trong bản phát hành tiếp theo.
Trường hợp 2 - AI đã đánh lừa bài kiểm tra. Với mẫu “đội đỏ”, một chuyên gia đã yêu cầu AI cung cấp mã vượt qua các bài kiểm tra hiện có nhưng vi phạm quy tắc giảm giá. AI đã viết mã luôn trả về mức chiết khấu bằng 0 - và tất cả các thử nghiệm vẫn có màu xanh vì không có thử nghiệm nào xác minh giá trị chiết khấu thực tế. Khoảng cách nhìn thấy, khẳng định thực sự được thêm vào.
Trường hợp 3 – Bẫy khen ngợi. Một người thử nghiệm cấp dưới đã hỏi AI: "Bài kiểm tra của tôi có tốt không?" và cảm thấy nhẹ nhõm khi nghe câu trả lời: "Rất toàn diện." Đồng nghiệp cấp cao của anh ấy đã kiểm tra các bài kiểm tra tương tự bằng cách sử dụng mẫu "kiểm tra chất lượng bài kiểm tra"; Hóa ra 12 trong số 20 bài kiểm tra là trang trí (không có khẳng định hoặc rác). Câu hỏi đúng đã mang lại câu trả lời đúng.
Những lỗi thường gặp
- Phạm vi nhầm lẫn với chất lượng. Dựa vào mức độ bao phủ của hàng cao và hoàn toàn không nhìn vào điểm đột biến.
- Tin tưởng vào lời khen ngợi của AI. Hỏi "Bài kiểm tra của bạn có tốt không?" và coi câu trả lời tích cực là sự đảm bảo.
- Lấy giá trị mong đợi từ mã. Kiểm tra tự xác minh xác nhận mã bị lỗi.
- Hãy hài lòng với những khẳng định tầm thường. Các kiểm tra không xác thực quy tắc thực tế, chẳng hạn như "không rỗng", "200 được trả về".
- Bỏ qua các đột biến còn sót lại. Bỏ qua những gì không có trong báo cáo đột biến.
- Thậm chí không cố gắng thay đổi mã quan trọng theo cách thủ công. Bỏ qua bước “break code and test” nếu chưa có tool.
Tóm lại
Niềm tin giả tạo là tin rằng phần mềm là đúng vì các bài kiểm tra có màu xanh lá cây; trong khi các bài kiểm tra có thể không xác nhận bất cứ điều gì. Tiêu chuẩn vàng để đo lường điều này là thử nghiệm đột biến: cố tình phá mã và đo xem liệu các thử nghiệm có bắt được nó hay không. Điểm đột biến là thước đo chất lượng trung thực hơn nhiều so với mức độ bao phủ phần trăm. AI vừa tạo ra sự tin tưởng giả vừa trở thành một đội đỏ hùng mạnh trong việc săn lùng nó - hãy yêu cầu “tạo ra một lỗi vượt qua các bài kiểm tra này”. Kiểm tra các thử nghiệm của bạn: xác nhận đúng, giá trị kỳ vọng độc lập, xác thực quy tắc kinh doanh và các đột biến bị loại bỏ.
Nhiệm vụ ứng dụng
Nhập hàm chứa quy tắc công việc và kiểm tra quy tắc đó từ dự án của riêng bạn. Nếu có thể, hãy chạy công cụ đột biến (Stryker/Pitest/mutmut) và đo điểm đột biến; Nếu không có công cụ, hãy tạo ít nhất 8 đột biến bằng mẫu "điều khiển đột biến thủ công" và thử chúng theo cách thủ công. Đối với mỗi đột biến còn sống sót, hãy viết một bài kiểm tra mới với mẫu "tiêu diệt đột biến sống sót". Cuối cùng, với mẫu “đội đỏ”, hãy xem liệu AI có thể tạo ra mã đánh lừa các bài kiểm tra của bạn hay không. Báo cáo điểm đột biến bắt đầu và kết thúc của bạn (hoặc tỷ lệ đột biến bị bắt/tổng số đột biến).
danh sách kiểm tra
- [ ] Tôi đánh giá chất lượng bài kiểm tra bằng điểm đột biến chứ không phải mức độ bao phủ.
- [ ] Tôi đã chạy thử nghiệm đột biến (bằng công cụ hoặc thủ công) đối với mã quan trọng.
- [ ] Tôi đã viết các bài kiểm tra mới cho từng đột biến còn sót lại.
- [ ] Tôi đã sử dụng AI làm đội đỏ và tìm kiếm những sơ hở trong các bài kiểm tra của mình.
- [ ] Tôi không coi lời khen "bài kiểm tra của bạn rất tốt" của AI là sự trấn an.
- [ ] Tôi đã kiểm tra xem mỗi thử nghiệm có xác minh xác nhận thực tế, giá trị kỳ vọng độc lập và quy tắc kinh doanh hay không.