Viết test tự động cho app mobile bằng AI

Trả lời nhanh: Agent viết kiểm thử rất nhanh, nhưng dễ tạo ra kiểm thử giả: chạy qua, tăng con số phủ, mà không kiểm tra điều gì có ý nghĩa. Cách tránh: mô tả theo hành vi cần đảm bảo chứ không theo hàm cần kiểm, và luôn thử làm hỏng code để xem kiểm thử có bắt được không. Ba tầng nên có trong luồng CI CD mobile: kiểm thử đơn vị cho logic, kiểm thử widget cho giao diện, và một vài kiểm thử đầu cuối cho các luồng quan trọng nhất.

Kiểm thử là phần ai cũng biết nên làm và ai cũng để sau. Agent hạ thấp rào cản đó rất nhiều, nhưng nếu giao sai cách thì bạn nhận về hàng trăm ca kiểm thử không bảo vệ được gì. Bài này nói cách giao đúng và cách kiểm chứng rằng chúng thật sự có tác dụng.

Ba tầng và tỷ lệ hợp lý

Kiểm thử đơn vị cho logic thuần: tính giá, xác thực dữ liệu nhập, chuyển đổi định dạng. Chạy nhanh, không cần thiết bị, nên có nhiều nhất.

Kiểm thử widget cho từng thành phần giao diện: hiển thị đúng với dữ liệu này, hiện thông báo khi danh sách rỗng, nút bị vô hiệu khi chưa nhập đủ. Chạy trên máy ảo nhẹ, khá nhanh.

Kiểm thử đầu cuối chạy cả ứng dụng thật trên máy giả lập và đi qua trọn một luồng. Chậm và dễ hỏng vặt, nên chỉ dành cho vài luồng quan trọng nhất: đăng nhập, đặt hàng, thanh toán.

Tỷ lệ thực dụng: nhiều kiểm thử đơn vị, vừa phải kiểm thử widget, rất ít kiểm thử đầu cuối. Làm ngược lại thì bộ kiểm thử chạy hàng chục phút và hỏng vặt liên tục, và cả đội sẽ bắt đầu bỏ qua nó.

Mô tả cho đúng để không nhận về test giả

Cách giao kém: viết kiểm thử cho file cart.ts. Agent sẽ viết một ca cho mỗi hàm, mỗi ca gọi hàm rồi kiểm tra kết quả bằng chính công thức trong hàm đó. Chạy qua hết nhưng không bảo vệ gì.

Cách giao tốt hơn, mô tả theo hành vi:

Viet kiem thu cho gio hang, dam bao cac hanh vi sau: - Them cung mot san pham hai lan thi tang so luong, khong tao dong moi- Giam so luong ve 0 thi xoa khoi gio- Ma giam gia het han thi khong duoc ap dung- Tong tien lam tron den hang don vi, khong lam tron tung dong- Gio rong thi khong cho dat hang Moi hanh vi mot ca kiem thu, ten ca mo ta hanh vi bang tieng Viet.Khong dung so lieu ngau nhien.

Danh sách hành vi là thứ chỉ bạn biết, và nó cũng chính là phần giá trị nhất. Dòng cuối tránh loại kiểm thử lúc đạt lúc không, thứ gây mất niềm tin nhanh nhất.

Kiểm chứng rằng kiểm thử có tác dụng

Đây là bước ít người làm và nó phân biệt kiểm thử thật với kiểm thử trang trí.

Cách làm rất đơn giản: cố ý làm hỏng code rồi chạy kiểm thử. Đổi dấu cộng thành dấu trừ trong hàm tính tổng, bỏ điều kiện kiểm tra mã giảm giá hết hạn. Nếu bộ kiểm thử vẫn xanh, nghĩa là nó không kiểm gì cả.

Bạn cũng giao được việc này cho agent: bảo nó liệt kê những thay đổi nhỏ có thể làm mà kiểm thử vẫn qua. Danh sách đó chính là các lỗ hổng trong bộ kiểm thử của bạn.

Về con số phủ, hãy coi nó là chỉ dấu chứ không phải mục tiêu. Phủ chín mươi phần trăm bằng những ca không kiểm gì thì vô nghĩa, trong khi phủ sáu mươi phần trăm nhắm đúng phần logic quan trọng lại rất có giá trị.

Ghép vào luồng tự động

Kiểm thử chạy tay thì sớm muộn cũng bị bỏ. Cách chia theo tần suất:

• Mỗi lần đẩy code: kiểm thử đơn vị và kiểm thử widget. Phải nhanh, dưới vài phút.
• Mỗi lần gộp vào nhánh chính: thêm kiểm thử đầu cuối trên máy giả lập, theo bài về emulator.
• Trước mỗi lần phát hành: chạy toàn bộ, cộng thử tay trên máy thật.

Hai việc bắt buộc khi chạy kiểm thử giao diện trên máy chủ: chờ máy ảo sẵn sàng trước khi chạy, và thu ảnh chụp màn hình khi có ca thất bại. Thiếu cái sau thì một ca thất bại chỉ trên CI gần như không thể lần ra nguyên nhân.

Cách dựng máy chạy nằm ở bài runner cho CI mobile.

Bẫy hay gặp

Kiểm thử lúc đạt lúc không. Nguyên nhân thường là phụ thuộc vào thời gian thật, vào thứ tự chạy, hoặc vào dữ liệu còn sót từ lượt trước. Một ca như vậy tệ hơn là không có, vì nó khiến cả đội quen với việc bỏ qua màu đỏ.

Kiểm thử phụ thuộc vào mạng thật. Gọi API thật trong kiểm thử là công thức của những lượt chạy hỏng vì lý do ngoài tầm kiểm soát. Hãy giả lập lớp gọi mạng.

Kiểm thử quá bám vào chi tiết hiển thị. Ca kiểm thử tìm theo văn bản chính xác sẽ hỏng mỗi lần sửa câu chữ. Tìm theo định danh phần tử thì bền hơn nhiều.

Bộ kiểm thử chạy quá lâu. Vượt quá mười phút là bắt đầu có người bỏ qua. Khi đó hãy cắt bớt số ca đầu cuối và chuyển việc kiểm chứng xuống tầng thấp hơn.

Dấu hiệu một bài kiểm thử là kiểm thử giả

Phép thử quyết định: cố tình làm hỏng

# Cach duy nhat de biet mot bai kiem thu co tac dung that: # 1. Mo ham dang duoc kiem, doi mot dieu kien#    vi du doi dau lon hon thanh dau nho hon# 2. Chay lai bai kiem thu donpm test -- ten_bai_kiem_thu # 3. Neu no VAN XANH thi bai kiem thu do vo dung, xoa hoac viet lai# 4. Neu no DO thi tot, hoan tac thay doi vua roigit checkout -- duong/dan/toi/tep.ts # Lam phep nay voi khoang 5 bai dau tien.# Neu qua nua so do van xanh, cach mo ta yeu cau cua ban dang co van de.

Mô tả thế nào để nhận về bài kiểm thử dùng được

• Nêu hành vi, đừng nêu cách cài đặt. Nói rõ đầu vào nào cho ra kết quả nào, thay vì nói hàm gọi những gì bên trong.
• Nêu cả trường hợp biên. Danh sách rỗng, mạng mất giữa chừng, người dùng bấm hai lần liên tiếp. Đây là nơi lỗi thật sống.
• Cấm giả lập phần đang kiểm. Nêu thẳng ràng buộc này, nếu không bạn sẽ nhận về bài kiểm thử giả lập chính hàm cần kiểm.

Tỷ lệ hợp lý cho ứng dụng di động

Với ứng dụng di động, phần kiểm thử giao diện chạy trên thiết bị luôn chậm và dễ hỏng vặt. Đừng cố phủ hết mọi luồng bằng tầng này. Chọn khoảng ba tới năm luồng quan trọng nhất về mặt doanh thu hoặc mất dữ liệu, phủ chắc chúng, còn lại đẩy xuống hai tầng dưới. Một bộ kiểm thử giao diện chạy trong năm phút được đội chạy mỗi ngày có ích hơn một bộ chạy bốn mươi phút bị tắt đi sau hai tuần.