Khi số lượng trường hợp kiểm thử (test case) và kịch bản kiểm thử (test scenario) cho các endpoint trong một dự án liên tục tăng lên, chi phí quản lý và chạy chúng một cách riêng lẻ sẽ tăng vọt. Cái ban đầu được tạo ra để đảm bảo chất lượng—kiểm thử tự động—lại có thể tự nó trở thành gánh nặng bảo trì.
Theo truyền thống, các nhóm thường chọn các trường hợp kiểm thử một cách thủ công. Khi một dự án đã tích lũy nhiều trường hợp và kịch bản kiểm thử, việc quyết định thủ công xem nên đưa cái nào vào và chạy cái nào để kiểm thử hồi quy trở thành một công việc thủ công nặng nề.
Bộ kiểm thử (Test Suites) của Apidog giải quyết vấn đề này bằng một phương pháp linh hoạt. Thay vì lưu trữ cứng nhắc các ID, một bộ kiểm thử lưu trữ một tập hợp các quy tắc lọc—ví dụ, theo thư mục, thẻ (tag), độ ưu tiên, hoặc kết hợp các điều kiện.
Trước mỗi lần chạy, bộ kiểm thử tự động tập hợp tất cả các trường hợp kiểm thử và kịch bản kiểm thử phù hợp với các quy tắc đó. Bạn có thể tập trung vào việc viết kiểm thử và áp dụng thẻ; các tài sản kiểm thử mới sẽ được tự động chọn và đưa vào quy trình CI/CD của bạn để tích hợp liên tục hoàn toàn tự động.
Tất cả kết quả thực thi sau đó được tổng hợp trong một báo cáo duy nhất để dễ dàng phân tích và khắc phục sự cố.
Tạo và Điều phối Bộ Kiểm thử Đầu tiên của Bạn
Sau khi cập nhật Apidog lên phiên bản mới nhất, hãy mở module Tests và tìm phần Test Suite. Nhấp vào menu ... bên cạnh và chọn Create Test Suite.
Trong cửa sổ bật lên, hãy nhập tên mô tả và đặt các tùy chọn như độ ưu tiên hoặc thẻ. Một bộ kiểm thử trống sẽ được tạo.
Tiếp theo, thêm nội dung vào bộ kiểm thử. Một bộ kiểm thử có thể chứa các trường hợp kiểm thử endpoint riêng lẻ hoặc kịch bản kiểm thử được tạo thành từ nhiều bước kiểm thử.
Thêm Nội dung Kiểm thử: Tĩnh và Động
Khi bạn nhấp vào Add Endpoint Test Case hoặc Add Test Scenario, bạn có thể chọn chế độ Static hoặc Dynamic. Các chế độ này xác định cách bộ kiểm thử quyết định những gì cần chạy và phù hợp với các mục tiêu bảo trì và kiểm thử khác nhau.
Chế độ tĩnh (Static mode) cố định tập hợp chính xác các mục cần chạy. Khi bạn chọn các trường hợp cụ thể ở chế độ tĩnh, hệ thống sẽ lưu trữ các ID duy nhất của các trường hợp đó. Nếu các trường hợp mới được thêm vào cùng một thư mục hoặc các trường hợp được di chuyển sau này, phạm vi thực thi của bộ kiểm thử sẽ không thay đổi. Hành vi mang tính xác định và nhất quán trong mỗi lần chạy.
Chế độ động (Dynamic mode) hoạt động khác. Nó không lưu trữ các ID trường hợp cụ thể; nó lưu trữ các quy tắc lọc, chẳng hạn như "tất cả các trường hợp trong một thư mục nhất định" hoặc "tất cả các trường hợp có thẻ 'semantic-valid'," hoặc "tất cả các kịch bản kiểm thử có độ ưu tiên P0".
Ở chế độ động, mỗi khi bộ kiểm thử chạy, hệ thống sẽ quét lại dự án bằng cách sử dụng các quy tắc này và bao gồm tất cả các trường hợp hiện đang khớp. Bất kỳ trường hợp kiểm thử hoặc kịch bản nào có thuộc tính (thư mục, thẻ, độ ưu tiên) khớp với các quy tắc sẽ được tự động đưa vào.
Chế độ Tĩnh so với Động: Chọn như thế nào?
Không có chế độ nào tốt hơn một cách phổ quát; chúng phục vụ các nhu cầu khác nhau. Việc lựa chọn phụ thuộc vào cách bạn muốn bộ kiểm thử hoạt động theo thời gian.
Đối với các kiểm thử chuyên biệt, phạm vi hẹp (ví dụ: một bộ hồi quy cố định), chế độ tĩnh dễ dự đoán hơn. Đối với việc lặp lại liên tục và kiểm thử hồi quy "tự động tiếp nhận" hoặc kiểm thử nhanh (smoke testing), chế độ động giảm đáng kể công việc bảo trì.
Để so sánh nhanh hai chế độ, hãy xem bảng dưới đây:
| Khía cạnh | Chế độ Tĩnh | Chế độ Động |
|---|---|---|
| Logic cốt lõi | Lưu trữ ID trường hợp cụ thể | Lưu trữ quy tắc lọc (thư mục, thẻ, độ ưu tiên, v.v.) |
| Nội dung theo thời gian | Cố định trừ khi bạn thay đổi thủ công | Tự động cập nhật khi các trường hợp khớp được thêm hoặc xóa |
| Chi phí bảo trì | Cao hơn; các trường hợp mới phải được thêm thủ công | Thấp hơn; đặt quy tắc một lần, sau đó các lần chạy sẽ được đồng bộ |
| Sử dụng điển hình | Xác minh sửa lỗi, ổn định đường dẫn cốt lõi, kiểm thử tương thích | Hồi quy toàn diện, kiểm thử nhanh, nghiệm thu bản phát hành |
Thứ tự Thực thi và Cấu hình Nâng cao
Sau khi thêm nội dung, bạn có thể sắp xếp lại các mục trong danh sách điều phối bằng cách kéo chúng.
Đối với mỗi mục thực thi (ví dụ: kịch bản kiểm thử), bạn có thể kiểm soát hành vi chạy chi tiết hơn thông qua các tùy chọn ở bên phải.
Ví dụ, On Error cho phép bạn chọn có tiếp tục, bỏ qua lượt hiện tại hay dừng toàn bộ quá trình chạy khi một bước thất bại. Iterations cho phép bạn chạy toàn bộ bộ kiểm thử nhiều lần để kiểm tra độ ổn định đơn giản. Cùng với nhau, các tùy chọn này biến một bộ kiểm thử không chỉ là một tập hợp các trường hợp mà còn là một luồng thực thi có thể kiểm soát được.
Chạy Bộ Kiểm thử
Khi bộ kiểm thử đã được thiết lập, bạn có thể chạy nó theo nhiều cách: từ chạy thủ công cục bộ đến tự động hóa dựa trên đám mây, tùy thuộc vào giai đoạn và môi trường của bạn.
Chạy Bộ Kiểm thử Cục bộ
Cách trực tiếp nhất là nhấp vào Run trong ứng dụng Apidog. Việc thực thi chạy từ máy cục bộ của bạn và phù hợp cho các kiểm tra nhỏ, nhanh chóng trong quá trình phát triển và gỡ lỗi. Trong cấu hình chạy, bạn có thể chuyển đổi môi trường chạy và đặt thông báo khi quá trình chạy kết thúc.
Khi quá trình chạy hoàn tất, Apidog tạo một báo cáo kiểm thử và hiển thị nó trong giao diện người dùng. Báo cáo liệt kê từng trường hợp kiểm thử endpoint và kịch bản kiểm thử theo thứ tự thực thi, với trạng thái đạt/không đạt rõ ràng. Bạn có thể mở từng mục riêng lẻ để xem chi tiết hơn.
Chạy Bộ Kiểm thử qua CLI
Đối với các bộ kiểm thử lớn hơn hoặc môi trường không có giao diện đồ họa (ví dụ: máy chủ không có GUI), Apidog CLI là lựa chọn tốt hơn. Nó mang khả năng thực thi kiểm thử của Apidog đến bất kỳ thiết bị đầu cuối nào.
Để chạy qua CLI, hãy cài đặt Apidog CLI và đảm bảo nó được cập nhật. Sau đó, trong tab CI/CD của bộ kiểm thử, sử dụng lệnh đã tạo:
Sao chép lệnh đó vào terminal của bạn để chạy bộ kiểm thử và xem luồng cũng như kết quả giống như trong giao diện người dùng.
Khi quá trình chạy kết thúc, một thư mục tên apidog-reports/ sẽ được tạo trong thư mục hiện tại và chứa báo cáo kiểm thử HTML.
Chạy qua CLI là cơ sở để tích hợp CI/CD. Bạn có thể chèn lệnh này vào Jenkins, GitLab CI hoặc GitHub Actions và kích hoạt các kiểm thử hồi quy tại các điểm quan trọng như khi hợp nhất mã.
Chạy Bộ Kiểm thử qua Tác vụ Lập lịch
Apidog hỗ trợ Scheduled Tasks (Tác vụ Lập lịch). Trong tab Scheduled Tasks của bộ kiểm thử, hãy tạo một tác vụ và đặt lịch chạy cũng như môi trường chạy của nó.
Không giống như các lần chạy cục bộ, các tác vụ lập lịch phải chạy trên một Runner tự lưu trữ.
Runner là một chương trình nhẹ mà nhóm của bạn có thể triển khai trên một máy chủ nội bộ. Sử dụng Runner giúp tránh các lỗi khi máy cục bộ bị tắt hoặc không thể truy cập được và cho phép bạn sử dụng tài nguyên của máy chủ cho các lần chạy kiểm thử lớn hơn.
Sau khi một tác vụ lập lịch được cấu hình, Apidog sẽ chạy bộ kiểm thử trên Runner vào các thời điểm đã chỉ định và tải lên lịch sử chạy cũng như các báo cáo. Bạn cũng có thể cấu hình thông báo lỗi để khi có vấn đề xảy ra, những người liên quan sẽ được cảnh báo nhanh chóng.
Tóm tắt
Với sự điều phối tĩnh và động, bạn có thể giữ cho các kiểm thử chuyên dụng có phạm vi chặt chẽ và để các bộ hồi quy tự động phát triển cùng dự án của bạn, mà không cần cập nhật thủ công liên tục. Kết hợp với các lần chạy cục bộ, tích hợp CLI và tác vụ lập lịch, bộ kiểm thử có thể phù hợp với mọi giai đoạn trong quy trình làm việc của bạn—từ kiểm tra nhanh trong quá trình phát triển đến hồi quy tự động trong CI/CD và kiểm tra theo lịch trình trong môi trường production.
Để biết thêm về bộ kiểm thử, hãy xem tài liệu Apidog. Hãy thử tạo bộ kiểm thử đầu tiên của bạn, điều phối các kiểm thử hiện có và xây dựng một thiết lập hồi quy tự động bền vững từng bước một.