Lợi nhuận:
- Khả năng tạo ra các bài kiểm tra đơn vị, tích hợp và giao diện người dùng bằng trí tuệ nhân tạo theo kim tự tháp kiểm tra và bao gồm các tình huống giới hạn và lỗi cũng như các tình huống vui vẻ
- Khả năng loại bỏ các thử nghiệm trống/vô dụng và phạm vi bao phủ cồng kềnh bằng cách kiểm tra xem mỗi thử nghiệm được tạo có thực sự xác thực một hành vi hay không
- Đảm bảo quá trình kiểm tra phát hiện được lỗi và ngăn chặn việc sửa lỗi bằng cách cho AI biết mã nên làm gì
Viết mã là một nửa công việc; Chứng minh rằng mã hoạt động chính xác là nửa còn lại. Ứng dụng dành cho thiết bị di động gặp phải hàng trăm thiết bị, kích thước màn hình, phiên bản hệ điều hành và hành vi người dùng khác nhau. Không thể kiểm tra tất cả những thứ này một cách thủ công; Đó là lý do tại sao thử nghiệm tự động (mã kiểm tra mã — thử nghiệm chạy mà không cần con người nhấp chuột) là xương sống của chất lượng trên thiết bị di động. AI cực kỳ hiệu quả trong việc viết bài kiểm tra vì viết bài kiểm tra chính xác là loại công việc mẫu mà nó thích: xác thực một hành vi cụ thể cho các đầu vào cụ thể. Trong phần này, chúng ta sẽ học cách tăng tốc kiểm thử đơn vị, kiểm thử giao diện và tự động hóa bằng AI nhưng vẫn đảm bảo chất lượng kiểm thử qua con mắt con người.
Kim tự tháp kiểm tra: kiểm tra cái gì và bao nhiêu
Một chiến lược thử nghiệm lành mạnh giống như một kim tự tháp. Cơ sở bao gồm một số lượng lớn các bài kiểm tra đơn vị (kiểm tra nhanh để kiểm tra một chức năng hoặc lớp riêng lẻ); chúng nhanh và rẻ. Ở giữa là thử nghiệm tích hợp ít hơn (kiểm tra xem nhiều phần hoạt động cùng nhau như thế nào). Ở trên cùng có giao diện người dùng/kiểm tra toàn diện tối thiểu (kiểm tra được thực hiện bằng cách nhấp vào màn hình như người dùng thực hiện); chúng thực tế nhưng chậm chạp và mong manh. AI trợ giúp ở mọi lớp, nhưng giá trị cao nhất nằm ở lớp cơ sở: nhanh chóng tạo ra các bài kiểm tra đơn vị về logic nghiệp vụ.
Loại thử nghiệm
Phạm vi
tốc độ
Hiệu quả AI
kiểm tra đơn vị
Chức năng/lớp đơn
rất nhanh
rất cao
hội nhập
lớp xen kẽ
trung bình
cao
Giao diện người dùng/từ đầu đến cuối
Tất cả luồng màn hình
chậm
Trung bình (dễ vỡ)
Mẹo: Khi yêu cầu AI "tạo các bài kiểm tra cho chức năng này", hãy yêu cầu rõ ràng các trường hợp đặc biệt: đầu vào trống, null, số âm, giá trị rất lớn, lỗi mạng. AI tạo ra con đường hạnh phúc một cách dễ dàng; Những sai lầm thực sự ẩn giấu trong ranh giới và nhảy ra ngoài nếu bạn không muốn chúng ở đó.
Các bước viết bài test với AI
- Xác định hành vi cần kiểm tra. "Chức năng này sẽ cung cấp đầu ra này cho đầu vào này."
- Chỉ định khuôn khổ. JUnit + MockK trên Android, XCTest trên iOS, Espresso (Android) hoặc XCUITest (iOS) cho giao diện người dùng.
- Yêu cầu trạng thái giới hạn. Kịch bản vui vẻ + lỗi + điểm dừng.
- Quản lý các đối tượng giả. Các phần phụ thuộc bên ngoài như mạng và cơ sở dữ liệu được mô phỏng để thử nghiệm (mô hình mô phỏng được kiểm soát thay vì dịch vụ thực tế).
- Chạy thử nghiệm và xác minh. Bài kiểm tra có vượt qua không, nó có xác nhận điều gì thực sự có ý nghĩa không?
Bước thứ năm là rất quan trọng. AI đôi khi tạo ra những bài kiểm tra vô dụng mà “luôn luôn đậu”; ví dụ: một bài kiểm tra không xác minh bất cứ điều gì hoặc kiểm tra dữ liệu giả mạo của chính nó. Một bài kiểm tra đậu và một bài kiểm tra có giá trị là những điều khác nhau.
Thận trọng: Chỉ vì AI có thể tạo ra không có nghĩa là bài kiểm tra đúng. Đôi khi AI chấp nhận hành vi hiện tại (có thể bị lỗi) của mã là "chính xác" và viết các bài kiểm tra tương ứng. Việc kiểm tra như vậy sẽ sửa lỗi thay vì bắt lỗi. Bạn xác định những gì bài kiểm tra mong đợi; Nói cho AI biết nó nên làm gì chứ không phải mã làm gì.
Kiểm tra độ bao phủ và sai lầm
Phạm vi kiểm tra (bao nhiêu phần trăm mã được chạy bởi các bài kiểm tra) là một thước đo hữu ích nhưng gây hiểu lầm. Mức độ bao phủ 90% cho biết 90% mã đã được thực thi; nhưng vẫn chưa xác minh được rằng những dòng đó có hoạt động chính xác hay không. Việc kiểm tra chạy một dòng và không kiểm tra kết quả sẽ làm tăng phạm vi nhưng không mang lại tính bảo mật. Mục tiêu không phải là những con số cao mà là sự xác nhận có ý nghĩa. Bạn có thể nhanh chóng mở rộng quy mô bằng AI nhưng hãy đảm bảo rằng mỗi bài kiểm tra thực sự kiểm tra một hành vi.
ba trường hợp nhỏ
Trường hợp 1 – Tình hình biên giới bị bắt. AI đã được yêu cầu thực hiện các bài kiểm tra về chức năng chuyển tiền trong ứng dụng ngân hàng và cụ thể là các kịch bản "số tiền âm" và "nhiều hơn số dư" đã được thêm vào. Thử nghiệm cho thấy rằng giao dịch chuyển tiền không bị chặn với số tiền âm; đây sẽ là một lỗ hổng bảo mật lớn trong sản xuất. Đóng bằng cách thêm điều khiển một dòng. Bài học: bài kiểm tra ranh giới là bài kiểm tra có giá trị nhất.
Trường hợp 2 - Bài kiểm tra giả. Một nhóm cảm thấy nhẹ nhõm khi tăng phạm vi bao phủ lên 85% với 40 bài kiểm tra đơn vị do AI sản xuất. Trong quá trình kiểm tra, người ta thấy rằng hầu hết các cuộc kiểm tra không thực sự xác minh bất kỳ đầu ra nào, họ chỉ gọi hàm và viết khẳng địnhTrue(true). Độ che phủ cao nhưng khả năng bảo vệ bằng không. Các bài kiểm tra đã được đại tu và viết lại với những xác nhận thực tế. Bài học: số liệu bảo hiểm có thể nói dối.
Trường hợp 3 - Thử nghiệm giao diện người dùng được tăng tốc. Một nhóm thương mại điện tử đã viết tập lệnh XCUITest về quy trình thêm vào giỏ hàng bằng AI trong 20 phút; Nếu viết bằng tay thì phải mất nửa ngày. AI đoán số nhận dạng thành phần màn hình; Nhóm đã khớp chúng với mã thực và sửa chúng. Tốc độ nháp là có thật, nhưng việc xác minh số nhận dạng là công việc của con người.
Dấu nhắc yếu / Dấu nhắc mạnh
Dấu nhắc yếu: "Viết bài kiểm tra cho chức năng này."
Lời nhắc mạnh mẽ: "Tạo các bài kiểm tra đơn vị cho hàm Kotlin này với JUnit5 + MockK. Chức năng: chuyển tiền (số tiền, nguồn, mục tiêu). Hành vi cần kiểm tra (mã nên LÀM gì):- Chuyển khoản hợp lệ phải thành công- Phải từ chối số tiền âm hoặc bằng 0- Phải từ chối số tiền lớn hơn số dư- Lỗi mạng phải đưa ra ngoại lệ thích hợp Mỗi bài kiểm tra chỉ nên xác minh một điều, tên của chúng phải mang tính mô tả, mô phỏng dịch vụ bên ngoài. Không viết xác nhận trống."
Mẫu có thể sao chép
Mẫu kiểm thử đơn vị: "Tạo các bài kiểm tra đơn vị [JUnit/XCTest] cho chức năng này cho [ngôn ngữ]. Hành vi dự kiến: [việc cần làm]. Bao gồm: kịch bản hài lòng, đầu vào rỗng, điểm dừng, trường hợp lỗi. Hãy để mỗi bài kiểm tra xác minh hành vi đơn lẻ; sử dụng xác nhận có ý nghĩa; mô phỏng. [mã]"
Mẫu thử nghiệm giao diện người dùng: "Viết thử nghiệm giao diện người dùng cho quy trình sau bằng [Espresso/XCUITest]: [từng bước của quy trình người dùng]. Chọn thành phần màn hình có id trợ năng, sử dụng id thay vì văn bản. Thêm chiến lược chờ. Nhắc tôi khớp id thành phần với mã thực tế."
Mẫu kiểm tra thử nghiệm: "Kiểm tra các thử nghiệm này:1) Chúng có thực sự xác minh một đầu ra/hành vi hay chúng không có giá trị?2) Chúng có bao gồm các trường hợp giới hạn không?3) Chúng có sửa lỗi mã hay mong đợi hành vi đúng không? Gắn cờ và củng cố các thử nghiệm yếu. [kiểm tra]"
Mẫu tối ưu hóa phạm vi bảo hiểm: "Xác định các phần chưa được kiểm tra của lớp này và đề xuất các thử nghiệm có ý nghĩa. Ưu tiên các đường dẫn có rủi ro thực sự, không chỉ số lượng phạm vi bảo hiểm. [code]"
Những lỗi thường gặp
- Chỉ cần thử nghiệm kịch bản hạnh phúc. Lỗi được lưu trữ ở trạng thái giới hạn; Hãy yêu cầu họ một cách cởi mở.
- Chấp nhận một bài kiểm tra trống rỗng/vô dụng. Các thử nghiệm thuộc loại khẳng địnhTrue(true) sẽ mở rộng phạm vi và không cung cấp sự bảo vệ nào.
- Yêu cầu AI xác minh xem mã đang làm gì. Việc kiểm tra nên mong đợi mã sẽ làm gì; nếu không nó sẽ sửa lỗi.
- Nhầm số phạm vi cho mục đích. Độ bao phủ 90% không có nghĩa là độ chính xác 90%.
- Liên kết tới văn bản trong thử nghiệm giao diện người dùng. Bài kiểm tra bị hỏng khi văn bản thay đổi; Sử dụng mã định danh ổn định (id).
- Thiết lập mô phỏng không chính xác. "Kiểm tra đơn vị" gọi dịch vụ thực tế sẽ chậm và dễ hỏng.
Tóm lại
Thử nghiệm là xương sống của chất lượng di động và AI rất hiệu quả trong lĩnh vực này, đặc biệt là trong thử nghiệm đơn vị. Thực hiện theo kim tự tháp thử nghiệm: nhiều đơn vị, tích hợp trung bình, thử nghiệm giao diện người dùng ít. Yêu cầu AI một cách rõ ràng về kịch bản vui vẻ cũng như các trường hợp giới hạn và đường dẫn lỗi. Đảm bảo rằng mỗi thử nghiệm được tạo thực sự xác thực một hành vi; Các bài kiểm tra trống rỗng và mức độ bao phủ tăng cao là sai lệch. Quan trọng nhất là cho AI biết mã nên làm gì chứ không phải làm gì để quá trình kiểm tra bắt được lỗi chứ không phải sửa lỗi.
Nhiệm vụ ứng dụng
Yêu cầu kiểm tra từ AI bằng cách sử dụng “Mẫu kiểm tra đơn vị” cho chức năng logic nghiệp vụ (ví dụ: tính toán chiết khấu hoặc xác thực biểu mẫu) và chỉ định rõ ràng các trường hợp giới hạn (null, âm, quá lớn). Chạy các thử nghiệm đã tạo, sau đó kiểm tra các thử nghiệm tương tự bằng "Mẫu kiểm tra thử nghiệm". Tìm ít nhất một bài kiểm tra yếu, củng cố nó và kiểm tra xem các bài kiểm tra có bắt được lỗi thực sự của hàm hay không (bằng cách thêm một lỗi nhỏ).
danh sách kiểm tra
- [ ] Tôi đã chọn lớp thích hợp cho kim tự tháp thử nghiệm (đơn vị ưu tiên)
- [ ] Tôi muốn các trường hợp giới hạn và lỗi bên cạnh kịch bản vui vẻ
- [ ] Tôi đã xác minh rằng mỗi bài kiểm tra đều chứa một khẳng định có ý nghĩa
- [ ] Tôi đã nói với AI rằng mã nên làm gì chứ không phải nó làm gì
- [ ] Tôi tập trung vào các lộ trình rủi ro thực tế chứ không phải số lượng bảo hiểm
- [ ] Tôi đã sử dụng mã định danh ổn định trong các thử nghiệm giao diện người dùng, tôi không liên kết với văn bản