+3

Tạo test case quá phiền phức? Giảm 70% thời gian bằng tự động

Mỗi lần triển khai API mới, tôi luôn nghĩ đến những điều giống nhau.

"Đã viết test case bình thường rồi, còn trường hợp ngoại lệ thì sao? Giá trị biên thì sao?" "Trường hợp Pet ID trống, định dạng không hợp lệ, ID không tồn tại... có quá nhiều pattern"

API tìm kiếm pet, API đăng ký pet, API quản lý kho... mỗi khi tính năng tăng lên, test case cũng tăng theo. Thành thật mà nói, tôi cảm thấy công việc này phiền phức nhất.

Lúc đó, tôi biết được Apidog đã thêm tính năng AI. Nghe nói "có thể tự động tạo test case". Tôi quyết định thử xem công việc viết thủ công cho đến nay có thể hiệu quả hóa được bao nhiêu.

Nói trước kết luận, cái này khá hữu ích. Tuy không hoàn hảo nhưng chắc chắn thời gian làm việc đã giảm.

Tại sao viết test case thủ công lại khó khăn đến vậy

Trước tiên, hãy sắp xếp lại những vấn đề tôi thường gặp phải.

Khó đảm bảo tính toàn diện Có thể viết được test case bình thường, nhưng khi cố gắng cover hết trường hợp ngoại lệ và giá trị biên thì sẽ có sót. Đặc biệt khi có nhiều parameter liên quan, chỉ nghĩ về pattern kết hợp thôi cũng đã mệt.

Phiền phức khi đối ứng với thay đổi spec Mỗi khi spec của API thay đổi, phải xem xét lại toàn bộ test case. Chỉ tìm xem phải sửa chỗ nào thôi cũng mất thời gian.

Cách viết trong team không đồng nhất A viết chi tiết, nhưng B chỉ viết tối thiểu. Khi review thường phải băn khoăn "Như vậy có đủ không?"

Hay trì hoãn trường hợp ngoại lệ Viết xong test case bình thường rồi thỏa mãn, trường hợp ngoại lệ thì nghĩ "để sau viết" rồi quên mất. Và bug được phát hiện ở production... vòng lặp xấu cứ lặp lại.

Tôi đã viết test case mỗi lần với những vấn đề như vậy.

Thực tế sử dụng tính năng AI của Apidog

Cách dùng đơn giản đến ngạc nhiên

Thực tế sử dụng tính năng AI của Apidog

Sau khi tạo định nghĩa API, mở tab "Test Case". Ở giữa màn hình có nút "Generate with AI", chỉ cần click vào đó.

Ở màn hình tiếp theo, có thể chọn loại test muốn tạo:

  • Positive(Test case bình thường)
  • Negative(Test case ngoại lệ)
  • Boundary Values(Giá trị biên)
  • Security(Bảo mật)

Lần đầu tiên, tôi chọn tất cả và tạo hàng loạt.

Nội dung test case được tạo ra

Đợi vài giây, test case sẽ hiển thị dài dằng dặc.

Lần này, tôi thử với "API tìm kiếm bằng Pet ID" trong dự án demo pet shop:

Test case bình thường

  • Tìm kiếm thành công với Pet ID hợp lệ (200 OK)
  • Lấy đúng thông tin pet với Pet ID tồn tại
  • Response chứa các field cần thiết (name, status, category)

Test case ngoại lệ

  • Pet ID trống, lỗi 400
  • Định dạng ID không hợp lệ (chuỗi ký tự...), lỗi 400
  • Pet ID không tồn tại, lỗi 404
  • Pet ID đã bị xóa, lỗi 410

Giá trị biên

  • Pet ID = 0 (giá trị tối thiểu)
  • Pet ID = 1 (giá trị tối thiểu + 1)
  • Pet ID = 999999 (giá trị tối đa)
  • Pet ID = -1 (số âm)

Bảo mật

  • Đối phó SQL injection (' OR '1'='1 v.v.)
  • Kiểm tra quyền (truy cập thông tin pet của user khác)

Thành thật mà nói, tôi ngạc nhiên "Nghĩ đến tận đây sao". Đặc biệt pattern giá trị biên và bảo mật là phần dễ bỏ sót khi viết thủ công nên rất hữu ích.

※Screenshot: Danh sách test case được tạo

Việc quyết định chấp nhận·xóa rất quan trọng

Test case được tạo ra có cái có thể dùng ngay, có cái cần sửa.

Mỗi test case có nút "Accept" "Discard" nên có thể chọn trong khi xác nhận nội dung.

Nhân tiện, số lượng tạo có chế độ tự động và chế độ thủ công:

  • Tạo tự động: AI tự quyết định số lượng phù hợp (lần này tạo 21 case)
  • Cài đặt thủ công: Có thể chỉ định số lượng tạo tối đa 80 case

Tôi chọn tạo tự động và 21 test case được tạo ra. Tôi chọn trong khi xác nhận nội dung:

  • Test case bình thường: Gần như chấp nhận nguyên bản
  • Test case ngoại lệ: Sửa một phần theo business logic
  • Giá trị biên: Điều chỉnh số theo spec API
  • Bảo mật: Chấp nhận case SQL injection và XSS

Cuối cùng, trong 21 case được tạo, tôi chấp nhận 16 case và xóa hoặc sửa 5 case.

Điều quan trọng là lựa chọn phù hợp với business logic của mình. Không phải dùng nguyên bản case AI tạo mà chỉ chấp nhận những cái cần thiết.

Điều cần biết trước khi dùng tính năng AI

Cần cài đặt API key

Bản thân Apidog không cung cấp AI model. Cần tự cài đặt API key của OpenAI, Claude v.v.

Cách cài đặt:

  1. Mở màn hình cài đặt Apidog
  2. Bật nút "Enable AI Features" lên ON
  3. Click "Add Provider"
  4. Chọn LLM model ưa thích (OpenAI, Claude, Gemini...) và nhập API key

Tính năng AI mặc định ở trạng thái tắt. Nếu dùng lần đầu, cần kích hoạt ở màn hình cài đặt.

Tôi đang dùng Claude Sonnet 4, nhưng GPT-4 cũng hoạt động tốt.

Hiệu năng model ảnh hưởng đến độ chính xác tạo

Đây là điểm quan trọng.

Nếu dùng model hiệu năng cao, test case gần với thực tế sẽ được tạo ra. Ngược lại, nếu model hiệu năng thấp, case sai lệch sẽ tăng lên.

Theo kinh nghiệm của tôi:

  • Claude Sonnet 4/DeepSeek V3.1: Có thể dùng ở mức thực tế
  • GPT-5: Cũng ở mức thực tế
  • GPT-3.5: Có thể tạo case cơ bản nhưng độ chính xác giảm

Nên chọn model cân nhắc giữa chi phí và độ chính xác.

3 điểm nhận ra khi thực tế sử dụng

1. Nội dung tạo ra chỉ là "bản nháp"

AI tạo ra chỉ là bản nháp. Dùng nguyên bản cho production là nguy hiểm.

Đặc biệt phần phụ thuộc vào business logic, AI không thể tự quyết định. Ví dụ:

  • "API này cần quyền admin"
  • "Giá trị này cần đồng nhất với table khác"
  • "Error message này trả về bằng tiếng Việt"

Những spec như vậy cần con người review và thêm·sửa.

2. Hiệu quả tiết kiệm thời gian là chắc chắn

Công việc viết thủ công mất 1 giờ, dùng AI chỉ mất 15 phút.

Đặc biệt ở giai đoạn đầu dự án hoặc khi thay đổi spec lớn, sự khác biệt này rất lớn.

Trường hợp của tôi, mỗi tuần dùng 5~6 giờ để tạo test case, sau khi dùng AI giảm xuống 2~3 giờ. Thời gian rảnh có thể làm test logic core chắc chắn hơn.

3. Chất lượng trong team được đồng nhất hóa

Trước đây, độ chi tiết test case của mỗi người khác nhau.

Dùng AI, baseline tối thiểu được đảm bảo. Từ đó mỗi người thêm·sửa theo nhu cầu nên chất lượng tổng thể được nâng cao.

Với engineer mới, cũng là tham khảo "nên viết test case như thế nào".

Flow sử dụng của riêng tôi

Cuối cùng, tôi ổn định với cách dùng như sau:

1. Tạo bản nháp bằng AI Ở giai đoạn đầu dự án hoặc thay đổi lớn, trước tiên tạo hàng loạt bằng AI.

2. Review và điều chỉnh Xác nhận case được tạo, quyết định chấp nhận·xóa·sửa.

3. Bổ sung thủ công Phần phụ thuộc business logic hoặc path quan trọng thì thêm thủ công.

4. Tích hợp vào CI/CD Tích hợp test case đã xác định vào CI/CD pipeline, thực thi liên tục.

5. Xem xét định kỳ Khi có thay đổi spec, tạo lại bằng AI và xác nhận sự khác biệt.

Sau khi chuyển sang flow này, việc tạo và maintain test case trở nên dễ dàng hơn nhiều.

Tổng kết: Dùng AI như "người cộng tác" mới đúng

Lần này dùng tính năng AI của Apidog, điều tôi cảm nhận nhất là "không phải giao hết cho AI mà dùng như người cộng tác".

Nhờ AI tạo bản nháp, tôi có thể tập trung vào xác nhận spec và business logic. Kết quả là cả chất lượng test và tốc độ làm việc đều được cải thiện.

Tuy không phải công cụ hoàn hảo nhưng chắc chắn hiệu quả phát triển tăng lên.

Đặc biệt, những người này nên thử:

  • Mất quá nhiều thời gian tạo test case
  • Hay bỏ sót trường hợp ngoại lệ và giá trị biên
  • Chất lượng test trong team không đồng nhất
  • Phiền phức khi phải viết lại test mỗi khi thay đổi spec

Hãy thử tạo bằng AI một lần và xem có thể hiệu quả hóa được bao nhiêu với API của mình.


Nếu bài viết này hữu ích, hãy chia sẻ nhé. Nếu có câu hỏi hoặc ý kiến, đừng ngại để lại comment.


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí