Cách Lên Lịch Kiểm Thử API Tự Động Trong Apidog (Cloud, Runner và CLI)

Một bộ kiểm thử chỉ có giá trị khi nó tiếp tục thành công theo thời gian. Dependency có thể phát hành bản cập nhật lúc 2 giờ sáng, chứng chỉ có thể hết hạn cuối tuần, hoặc cấu hình sai có thể làm hỏng endpoint thanh toán. Thay vì chờ khách hàng báo lỗi, hãy chạy kiểm thử API theo lịch và nhận cảnh báo ngay khi có sự cố.

Dùng thử Apidog ngay hôm nay

Apidog cung cấp tính năng Tác vụ theo lịch (Scheduled Tasks) để chạy các Kịch bản kiểm thử (Test Scenarios) đã lưu theo chu kỳ. Bạn chọn kịch bản, môi trường, tần suất, Runner thực thi và kênh cảnh báo. Nếu cần bối cảnh rộng hơn, xem bài viết về giám sát API và tài liệu Tác vụ theo lịch của Apidog.

Lưu ý: Scheduled Tasks hiện ở trạng thái Beta. Số lượt chạy theo lịch phụ thuộc vào gói dịch vụ của bạn.

Tác vụ theo lịch làm gì?

Một tác vụ theo lịch chạy một hoặc nhiều Test Scenario đã lưu theo chu kỳ lặp lại. Các trường hợp sử dụng phổ biến:

• Chạy regression test mỗi đêm cho API production.
• Chạy smoke test mỗi 6 giờ trên staging.
• Kiểm tra sức khỏe API cuối tuần.
• Xác minh luồng quan trọng như đăng ký, giỏ hàng và thanh toán.

Tác vụ lưu các thông tin sau:

• Test Scenario cần chạy.
• Environment cần sử dụng.
• Tần suất chạy.
• Runner thực thi.
• Kênh nhận cảnh báo khi thất bại.

Đây không phải là tính năng cào web hoặc thu thập dữ liệu theo lịch. Scheduled Tasks nằm trong mô-đun Tests và chạy toàn bộ logic kiểm thử API hiện có: assertions, chained requests, extracted variables và các cấu hình thực thi khác. Kết quả là báo cáo pass/fail cho hợp đồng API, không phải dữ liệu được crawl từ website.

Trước khi bắt đầu: cấu hình Runner tự host

Để chạy Scheduled Tasks, bạn cần đăng ký một Runner tự host trước.

Runner là máy thực thi bộ kiểm thử. Khi lịch được kích hoạt, các request không chạy từ máy tính của bạn mà được gửi từ Runner đã chọn. Bạn có thể dùng:

• Máy CI luôn hoạt động.
• Máy ảo chuyên dụng.
• Server nhỏ trong mạng nội bộ.
• Máy nằm trong VPC có quyền truy cập API cần kiểm tra.

Trong trường Runner, Apidog hiển thị hai lựa chọn:

• Apidog Cloud — được đánh dấu là “sắp ra mắt”.
• Runner tự host — lựa chọn khả dụng hiện tại.

Vì request được gửi từ máy Runner, mạng của Runner ảnh hưởng trực tiếp đến kết quả. Ví dụ, Runner nằm sau VPN, trong VPC khác hoặc sau firewall có thể nhận phản hồi khác với máy local của bạn. Đây thường là điều mong muốn khi giám sát môi trường thực tế.

Từng bước tạo tác vụ theo lịch

Ví dụ dưới đây áp dụng cho bộ regression test hàng đêm của API thương mại điện tử gồm đăng ký, danh sách sản phẩm, giỏ hàng và thanh toán qua Stripe.

1. Mở Scheduled Tasks trong mô-đun Tests

Trong ứng dụng Apidog:

1. Mở mô-đun Tests.
2. Trong cây thư mục kiểm thử, chọn Scheduled Tasks.
3. Tại đây, bạn có thể xem, chỉnh sửa và quản lý tất cả tác vụ theo lịch trong project.

Đây cũng là nơi phù hợp để kiểm tra tác vụ nào đang hoạt động và thời điểm chúng chạy.

2. Tạo tác vụ mới

Nhấp + New để tạo Scheduled Task mới.

Bạn cũng có thể tạo thư mục để nhóm tác vụ, ví dụ:

Scheduled Tasks/
├── Production Monitoring/
│   ├── Nightly Regression
│   └── Payment Smoke Test
└── Staging/
    ├── Pre-release Smoke Test
    └── API Contract Check

Đặt tên và mô tả rõ ràng, chẳng hạn:

Tên: Regression production hàng đêm
Mô tả: Kiểm tra đăng ký, danh mục, giỏ hàng và thanh toán lúc 02:00 mỗi ngày

Mỗi tác vụ có nút bật/tắt. Bạn có thể vô hiệu hóa tạm thời mà không cần xóa cấu hình.

3. Chọn Test Scenario cần chạy

Trong phần Test Scenario, chọn một hoặc nhiều kịch bản đã lưu.

Ví dụ cho luồng thương mại điện tử:

• Đăng ký và đăng nhập
• Duyệt và thêm vào giỏ hàng
• Thanh toán bằng thẻ thử nghiệm Stripe

Nếu các kịch bản cần cùng cấu hình runtime, bật Use same execution config để áp dụng một cấu hình cho toàn bộ scenario đã chọn.

Cấu hình thực thi có thể bao gồm:

• Environment.
• Test data.
• Số lần lặp.
• Độ trễ giữa các request.
• Tùy chọn lưu request và response.

Chọn Environment đúng

Đây là bước quan trọng nhất:

Mục tiêu	Environment nên dùng
Regression test hàng đêm	Production
Smoke test trước phát hành	Staging
Kiểm tra tích hợp nội bộ	Development hoặc QA

Mặc dù một tác vụ có thể dùng environment khác nhau cho từng scenario, việc giữ một tác vụ chỉ chạy trong một environment thường dễ bảo trì và dễ điều tra lỗi hơn.

4. Đặt chu kỳ chạy

Cấu hình tần suất trong trường lịch chạy. Tùy giao diện, trường này có thể hiển thị là:

• Run Cycle
• Run Mode
• Chu kỳ chạy
• Chế độ chạy

Các ví dụ lịch chạy được tài liệu đề cập:

• Mỗi Chủ Nhật lúc 23:00.
• Mỗi 6 giờ.
• Mỗi 8 giờ.

Gợi ý triển khai:

Loại kiểm tra	Lịch đề xuất
Regression production	Một lần mỗi đêm
Smoke test staging	Mỗi 6 giờ
Health check endpoint quan trọng	Mỗi vài giờ, tùy giới hạn gói
Kiểm tra sau đợt bảo trì	Chạy theo nhu cầu rồi tắt

5. Chọn Runner thực thi

Đặt trường Runner thành Runner tự host đã đăng ký.

Tùy giao diện, trường này có thể được gắn nhãn:

• Runs on
• Run On
• Chạy trên
• Chạy vào

Nếu có nhiều Runner, hãy chọn Runner phù hợp với môi trường mục tiêu. Ví dụ, chọn Runner trong cùng VPC với API production nếu bạn muốn kiểm tra từ góc nhìn của hạ tầng nội bộ.

Tất cả request trong bộ kiểm thử đều xuất phát từ Runner này. Hãy bảo đảm Runner có DNS, VPN, quyền mạng và firewall rule phù hợp để truy cập API.

6. Bật thông báo

Bật Notification để nhận cảnh báo khi tác vụ gặp sự cố.

Apidog hỗ trợ các kênh:

• Slack
• Teams
• Webhook
• Jenkins
• Email

Với Email, bạn có thể chọn thành viên project hoặc nhập thủ công địa chỉ của on-call rotation hay mailbox dùng chung.

Chọn thời điểm gửi cảnh báo:

• Every run: gửi sau mọi lần chạy.
• Failures only: chỉ gửi khi kiểm thử thất bại.

Khuyến nghị:

• Dùng Failures only cho regression test ổn định để tránh làm nhiễu kênh cảnh báo.
• Dùng Every run trong giai đoạn triển khai ban đầu để xác nhận job thực sự đang chạy.

7. Lưu và kích hoạt

Sau khi hoàn tất cấu hình:

1. Lưu tác vụ.
2. Bật toggle để kích hoạt.
3. Kiểm tra lịch chạy và Runner đã chọn.

Bạn có thể tắt tác vụ trong thời gian bảo trì hoặc migration để tránh cảnh báo không cần thiết.

8. Kiểm tra Run History

Sau mỗi lần chạy, Runner tự động tải kết quả lên máy chủ. Mở Scheduled Tasks - Run History để xem:

• Lần chạy thành công hoặc thất bại.
• Thời gian thực thi.
• Assertion nào bị lỗi.
• Chi tiết request/response liên quan.

Khi nhận cảnh báo Slack hoặc Email, Run History là nơi cần mở đầu tiên để điều tra nguyên nhân.

Cài đặt nâng cao và biến thể

Phạm vi biến

Apidog hỗ trợ ba mức chia sẻ biến:

1. Share only in the current test scenario
   
   Biến chỉ tồn tại trong scenario hiện tại.

2. Share across all test scenarios in the current scheduled task
   
   Các scenario trong cùng Scheduled Task có thể dùng chung biến.

3. Share across all scheduled tasks in the current scheduled task folder
   
   Biến được chia sẻ giữa các Scheduled Task trong cùng thư mục.

Hãy chọn phạm vi nhỏ nhất đáp ứng nhu cầu. Điều này giảm nguy cơ token, ID hoặc dữ liệu tạm thời bị dùng ngoài ý muốn bởi scenario không liên quan.

Giữ giá trị biến giữa các lần chạy

Nếu cần truyền dữ liệu từ lần chạy trước sang lần chạy sau, bật Keep variable values trong trang thiết kế Test Scenario.

Ví dụ:

• Lưu ID đơn hàng từ lần chạy trước.
• Dùng lại token đã làm mới.
• Tiếp tục một luồng kiểm tra nhiều ngày.

Nếu không bật tùy chọn này, mỗi lần chạy theo lịch bắt đầu với trạng thái mới và các giả định về dữ liệu của lần chạy trước có thể thất bại.

Nhóm tác vụ bằng thư mục

Khi số lượng tác vụ tăng lên, hãy nhóm theo mục đích hoặc environment:

Scheduled Tasks/
├── Production/
│   ├── Nightly Regression
│   ├── Checkout Monitoring
│   └── Auth Health Check
├── Staging/
│   └── Pre-release Smoke Test
└── Migration/
    └── Data Validation

Cách tổ chức này cũng hữu ích nếu bạn cần dùng phạm vi biến cấp thư mục cho các tác vụ liên quan.

Kiểm tra giới hạn gói dịch vụ

Số lượt chạy theo lịch phụ thuộc vào gói đăng ký. Trước khi cấu hình lịch chạy dày đặc như mỗi giờ, hãy kiểm tra giới hạn gói của bạn.

Để tìm hiểu thêm:

• Tác vụ theo lịch nâng cao
• Logic điều kiện trong các kịch bản kiểm thử API
• Chạy kiểm thử API hàng đêm trong CI

Tự động hóa bằng Apidog CLI

Scheduled Tasks UI là một lựa chọn. Lựa chọn khác là chạy scenario bằng Apidog CLI, sau đó để cron hoặc hệ thống CI xử lý lịch chạy.

CLI không có lệnh lập lịch riêng. Việc lập lịch nằm bên ngoài Apidog, chẳng hạn cron, GitHub Actions hoặc CI server hiện có.

Cài đặt CLI, xác thực và chạy scenario theo ID:

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <SCENARIO_ID> -e <ENV_ID> -r cli,junit

Trong đó:

• -t: ID của Test Scenario.
• -e: ID của Environment.
• -r: reporter, có thể là cli, html hoặc junit.
• Nhiều reporter được phân tách bằng dấu phẩy.

Xem chi tiết cách thiết lập token trong hướng dẫn cài đặt Apidog CLI.

Chạy hàng đêm bằng cron

Ví dụ chạy lúc 02:00 mỗi ngày:

0 2 * * * cd /srv/api-tests && apidog run --access-token $APIDOG_ACCESS_TOKEN -t 4471 -e 88 -r junit >> run.log 2>&1

Lệnh này:

1. Chuyển đến thư mục chứa kiểm thử.
2. Chạy scenario 4471 với environment 88.
3. Xuất báo cáo JUnit.
4. Ghi stdout và stderr vào run.log.

Bạn cũng có thể chạy bằng GitHub Actions theo lịch. Xem:

• Apidog CLI trong pipeline CI/CD
• GitHub Actions schedule triggers

Câu hỏi thường gặp

Tôi có thể chạy kiểm thử theo lịch trên Apidog Cloud ngay hôm nay không?

Chưa. Apidog Cloud hiện được đánh dấu là “sắp ra mắt”. Runner tự host là lựa chọn thực thi khả dụng hiện tại.

Scheduled Tasks có thể chạy thường xuyên đến mức nào?

Tần suất cấu hình khá linh hoạt, chẳng hạn mỗi 6 giờ hoặc mỗi Chủ Nhật lúc 23:00. Tuy nhiên, tổng số lượt chạy phụ thuộc vào gói dịch vụ của bạn. Hãy kiểm tra giới hạn gói trước khi đặt lịch chạy dày đặc.

Làm sao để chỉ nhận cảnh báo khi kiểm thử thất bại?

Trong phần Notification, chọn Failures only thay vì Every run, sau đó cấu hình Slack, Teams, Webhook, Jenkins hoặc Email.

Bạn có thể kết hợp regression suite với một kiểm tra sức khỏe API nhẹ để nhận tín hiệu nhanh cho các endpoint quan trọng.

Vì sao kết quả chạy theo lịch khác với khi chạy local?

Request theo lịch được gửi từ Runner, không phải laptop của bạn. Khác biệt về mạng, khu vực, VPN, DNS hoặc firewall có thể làm thay đổi phản hồi. Trong nhiều trường hợp, kết quả từ Runner phản ánh môi trường thực tế tốt hơn.

Biến bị đặt lại sau mỗi lần chạy. Tôi thiếu cấu hình nào?

Bật Keep variable values trong trang thiết kế Test Scenario. Nếu không bật, mỗi lần chạy theo lịch sẽ bắt đầu lại từ trạng thái mới.

Kết luận

Scheduled Tasks biến câu hỏi “API có lẽ vẫn hoạt động” thành một quy trình kiểm chứng tự động:

1. Xây dựng Test Scenario.
2. Đăng ký Runner tự host.
3. Chọn environment và lịch chạy.
4. Cấu hình cảnh báo khi thất bại.
5. Theo dõi Run History để điều tra lỗi.

Nếu cần đưa cùng các kiểm tra đó vào pipeline, hãy dùng Apidog CLI kết hợp cron hoặc CI scheduler. Tải xuống Apidog để thiết lập bộ regression test theo lịch đầu tiên của bạn.