Lợi nhuận:
- Khả năng tạo ra các bài kiểm tra đơn vị, tích hợp và trường hợp biên với xác nhận có ý nghĩa với AI
- Khả năng trích xuất một cách có hệ thống phạm vi kiểm tra, giới hạn giá trị và các tình huống tiêu cực với sự hỗ trợ của AI
- Khả năng xác minh rằng các thử nghiệm do AI tạo ra thực sự xác minh hành vi chứ không chỉ lặp lại mã hiện có
Kiểm tra là cơ chế chứng minh rằng phần mềm thực sự hoạt động như đã hứa. Một bộ thử nghiệm tốt sẽ cho bạn biết chỉ trong vài giây liệu một thay đổi có phá vỡ điều gì đó hay không và giúp kỹ sư có thể tự tin hành động. AI tăng tốc phần tẻ nhạt nhất và bị bỏ qua nhiều nhất của quá trình viết bài kiểm tra: tạo ra vô số kịch bản, điểm dừng và trường hợp tiêu cực. Nhưng có một cái bẫy lén lút ở đây: AI có thể viết các bài kiểm tra để xác minh hành vi hiện tại (có thể bị lỗi) của mã, chứ không phải hành vi được cho là của nó; hoặc nó có thể tạo ra các bài kiểm tra trống luôn vượt qua mà không thực sự kiểm tra bất cứ điều gì. Giá trị của bài kiểm tra không phải ở chỗ nó có vượt qua hay không mà ở chỗ nó có kiểm tra đúng hay không và chuyển sang màu đỏ khi sai.
Trong học phần này, bạn sẽ học cách tạo các bài kiểm thử đơn vị, tích hợp và trường hợp biên với các xác nhận có ý nghĩa; cách trích xuất một cách có hệ thống phạm vi kiểm tra, điểm dừng và các tình huống nhược điểm; và chúng tôi sẽ xem cách bạn có thể kiểm tra xem các bài kiểm tra mà AI tạo ra có thực sự xác thực hành vi hay không.
Các khái niệm: Kiểm thử đơn vị: Kiểm tra một chức năng/lớp riêng lẻ. Kiểm thử tích hợp: Kiểm thử xem nhiều bộ phận có hoạt động chính xác với nhau không. Khẳng định: Một tuyên bố kiểm tra xem kết quả có bằng với những gì được mong đợi hay không; Đây là trung tâm của bài kiểm tra. Phạm vi bao phủ: Bao nhiêu mã được chạy bằng thử nghiệm; Độ che phủ cao không đảm bảo chất lượng.
Tạo ra các bài kiểm tra có ý nghĩa
Một bài kiểm thử tốt thực hiện rõ ràng ba điều: nó thiết lập một trạng thái, nó thực hiện một hành động, nó khẳng định kết quả. Khi in các bài kiểm tra tới AI, hãy chỉ định hành vi nào bạn muốn xác minh và những tình huống nào sẽ bao gồm; Nếu không, nó tạo ra những bài kiểm tra hời hợt luôn vượt qua.
- Xác định hành vi cần kiểm tra. “Cái gì được coi là đúng?” Trả lời câu hỏi một cách rõ ràng.
- Yêu cầu các loại kịch bản. Điều kiện bình thường, giới hạn, âm, lỗi.
- Nhập khẩu khẳng định có ý nghĩa. Nó không chỉ "gửi lỗi" mà còn "trả về giá trị chính xác".
- Kiểm tra tính chính xác của bài kiểm tra. Bài kiểm tra có chuyển sang màu đỏ khi bạn phá mã một cách có ý thức không?
Lời nhắc tạo thử nghiệm toàn diện: "Viết thử nghiệm đơn vị cho chức năng 'áp dụng giảm giá (số tiền, phiếu giảm giá)' sau. Có ÍT NHẤT một trường hợp trong các danh mục sau: (1) phiếu giảm giá hợp lệ thông thường, (2) điểm dừng (0 số tiền, giảm giá 100%), (3) âm (phiếu giảm giá không hợp lệ, số tiền âm), (4) trường hợp lỗi (phiếu giảm giá rỗng). Xác nhận giá trị mong đợi CONCRETE trong mỗi thử nghiệm (không chỉ 'đã hoạt động'). Đặt tên cho các thử nghiệm có thể đọc được. Mã: [mã]"
Lời nhắc trích xuất giá trị biên: "Thực hiện phân tích giá trị biên cho các đầu vào của hàm này. Đối với mỗi tham số, trích xuất các giá trị 'ngay ranh giới', 'ngay dưới ranh giới', 'ngay phía trên ranh giới' dưới dạng bảng. Sau đó liệt kê các kịch bản thử nghiệm bao gồm các ranh giới này. Chưa viết mã, chỉ phân tích và danh sách kịch bản. Chức năng: [chữ ký]"
Thận trọng: Phạm vi kiểm tra cao (ví dụ: 90%) không chứng minh rằng mã là chính xác. Phạm vi đo lường số lượng hàng được thực thi; không phải những dòng đó tạo ra kết quả chính xác. Một thử nghiệm không có khẳng định có ý nghĩa sẽ làm tăng mức độ bao phủ nhưng không đảm bảo bất kỳ điều gì. Nội dung khẳng định quyết định chất lượng chứ không phải số lượng khẳng định.
Tự kiểm tra bài kiểm tra: Logic của đột biến
Cách thực tế nhất để hiểu liệu thử nghiệm do AI tạo ra có thực sự hoạt động hay không là cố tình phá mã (logic thử nghiệm đột biến). Đảo ngược điều kiện, tạo dấu + -; Nếu không có bài kiểm tra nào chuyển sang màu đỏ thì bài kiểm tra của bạn không thực sự duy trì hành vi đó.
Lời nhắc tìm kiếm lỗ hổng bảo mật trong thử nghiệm: "Hãy cho tôi biết những lỗi tiềm ẩn nào trong mã này mà các thử nghiệm sau CÓ THỂ KHÔNG phát hiện được. Đề xuất 5 đột biến nhỏ có thể được thực hiện đối với mã (ví dụ: >= thay vì >, - thay vì +) và cho biết từng lỗi mà các thử nghiệm hiện có có phát hiện được hay không. Đối với những lỗi không bị phát hiện, hãy đề xuất thử nghiệm cần được thêm vào. Mã: [code] Kiểm tra: [test]"
Nhắc yếu / Nhắc mạnh
YẾU: "Viết bài kiểm tra cho chức năng này." (Kết quả: thường là một kịch bản vui vẻ, xác nhận yếu; bỏ sót lỗi.) MẠNH: "Viết bài kiểm tra cho hàm 'passwordStrong' này. Quy tắc: ít nhất 8 ký tự, 1 chữ cái viết hoa, bắt buộc phải có 1 chữ số. Bao gồm các trường hợp sau dưới dạng các bài kiểm tra RIÊNG: chính xác 8 ký tự (giới hạn), 7 ký tự (giới hạn dưới), không có chữ hoa, không có chữ số, chuỗi trống, chỉ dấu cách, quá dài (1000 ký tự) Xác nhận rõ ràng giá trị đúng/sai dự kiến trong mỗi thử nghiệm và tên bài kiểm tra theo những gì nó kiểm tra."
Lời nhắc mạnh mẽ đưa ra các quy tắc và kịch bản ranh giới đầy đủ. Các cặp ranh giới như "chính xác 8/7 ký tự" là những vị trí thường mắc lỗi nhất (khó hiểu > với >=). Dấu nhắc yếu vượt qua các ranh giới này và chuyển lỗi sang quá trình sản xuất.
Các loại thử nghiệm và nơi sử dụng
Loại thử nghiệm
Nó xác nhận điều gì?
Đóng góp của AI
Chú ý
đơn vị
Chức năng/lớp đơn
Tạo nhiều kịch bản nhanh chóng
Cần phải khẳng định có ý nghĩa
hội nhập
Các bộ phận làm việc cùng nhau
Kịch bản và dự thảo dữ liệu mô phỏng
Hành vi gây nghiện thực sự
kết thúc/chấp nhận
Toàn bộ luồng người dùng
Danh sách bước và kỳ vọng
dễ bị giòn
hồi quy
Lỗi cũ không quay lại
Kiểm tra lỗi cụ thể
Nên được thêm vào mỗi lần sửa chữa
Hộp đựng nhỏ
Trường hợp 1 - Bài kiểm tra luôn đạt. AI viết 12 bài kiểm tra cho một hàm và tất cả đều vượt qua. Kỹ sư trở nên nghi ngờ và cố tình bóp méo giá trị trả về của hàm; Chỉ có 3 trong số các bài kiểm tra chuyển sang màu đỏ. 9 bài kiểm tra còn lại không chứa các xác nhận có ý nghĩa. Việc kiểm tra được tăng cường bằng cách tìm kiếm đột biến; sự bảo vệ thực sự đạt được trong 9 kịch bản.
Trường hợp 2 - Lỗi ranh giới. Chức năng xác minh độ tuổi sẽ hiển thị "18 tuổi trở lên là hợp lệ" nhưng >18 được ghi, nghĩa là 18 tuổi bị từ chối. Lỗi xuất hiện ngay lập tức trong quá trình thử nghiệm vì AI tạo ra kịch bản “chính xác là 18” thông qua phân tích điểm dừng. Một thử nghiệm giới hạn duy nhất sẽ ngăn chặn mọi khiếu nại của người dùng thực sự.
Trường hợp 3 - Sửa chữa hành vi hiện tại. Khi AI được yêu cầu "viết bài kiểm tra dựa trên mã này", nó sẽ tạo ra bài kiểm tra chấp nhận "chính xác" lỗi làm tròn đã tồn tại trong mã. Khi kỹ sư in bài kiểm tra theo yêu cầu (giá trị đúng dự kiến) chứ không phải mã, bài kiểm tra chuyển sang màu đỏ và xảy ra lỗi thực sự. Các thử nghiệm phải xuất phát từ kỳ vọng chứ không phải từ mã.
Những lỗi thường gặp
- Khẳng định vô nghĩa. "Không đưa ra lỗi" là chưa đủ; Giá trị đúng phải được xác minh.
- Phạm vi nhầm lẫn với chất lượng. Độ che phủ cao không đảm bảo kết quả chính xác.
- In bài kiểm tra bằng mã. Sửa lỗi hiện tại thành "true"; Các thử nghiệm nên xuất phát từ sự mong đợi.
- Bỏ qua các giá trị giới hạn Nhầm lẫn > với >= là lỗi phổ biến nhất; cặp ranh giới phải được kiểm tra.
- Không tự kiểm tra bài kiểm tra. Kiểm tra không chuyển sang màu đỏ khi bạn phá mã sẽ không mang lại sự bảo vệ.
Tóm lại
Một bộ thử nghiệm tốt là chìa khóa để thực hiện các thay đổi một cách tự tin. AI nhanh chóng tạo ra vô số kịch bản, giới hạn và tình huống tiêu cực; Nhưng nếu nó lấy các bài kiểm tra từ mã chứ không phải từ yêu cầu, nó có thể sửa các lỗi hiện có hoặc viết các bài kiểm tra vô nghĩa luôn vượt qua. Khẳng định giá trị mong đợi cụ thể trong mỗi thử nghiệm, bao gồm các cặp ràng buộc và xác minh rằng thử nghiệm của bạn thực sự bảo vệ bằng cách cố tình phá mã. Nội dung của khẳng định chứ không phải số lượng phạm vi quyết định chất lượng.
Nhiệm vụ ứng dụng
Chọn một chức năng và yêu cầu nó tạo các thử nghiệm theo bốn loại (bình thường, giới hạn, âm tính, lỗi) với lời nhắc tạo thử nghiệm toàn diện; Có giá trị mong đợi cụ thể được khẳng định trong mỗi thử nghiệm. Sau đó, chạy lời nhắc tìm kiếm lỗ hổng kiểm tra, đề xuất 5 đột biến nhỏ trong mã và chạy thử nghiệm để kiểm tra xem chúng phát hiện được những đột biến nào. Thêm một thử nghiệm mới cho ít nhất một đột biến chưa được phát hiện và cho thấy rằng nó hiện có màu đỏ.
danh sách kiểm tra
- [ ] Tôi đã in các bài kiểm tra dựa trên hành vi mong đợi/đúng chứ không phải mã.
- [ ] Tôi đã đề cập đến các tình huống bình thường, giới hạn, tiêu cực và lỗi.
- [ ] Tôi khẳng định giá trị mong đợi cụ thể trong mỗi bài kiểm tra.
- [ ] Tôi đã thử nghiệm các cặp đường viền (ngay phía trên bên dưới/ngay phía trên bên dưới).
- [ ] Bằng cách cố tình phá mã, tôi xác nhận rằng các bài kiểm tra đã chuyển sang màu đỏ.
- [ ] Tôi đã thêm một thử nghiệm mới cho các đột biến chưa được phát hiện.