Một bộ kiểm thử thành công chỉ có ý nghĩa nếu nó duy trì thành công. Quy trình thanh toán của bạn hoạt động tốt hôm nay, nhưng một dependency có thể phát hành bản cập nhật gây lỗi lúc 2 giờ sáng, một chứng chỉ hết hạn vào cuối tuần, hoặc một cấu hình sai lệch làm sập điểm cuối thanh toán vào Chủ Nhật. Bạn sẽ phát hiện ra từ một khách hàng khó chịu thay vì từ một lần chạy thử. Giải pháp là một cách nhàm chán và đáng tin cậy: chạy các bài kiểm tra API của bạn theo lịch trình, không cần con người nhấp chuột, và nhận thông báo ngay khi có sự cố xảy ra.
Apidog có một tính năng Tác vụ theo lịch (Scheduled Tasks) tích hợp sẵn dành cho mục đích này. Bạn trỏ nó đến các kịch bản kiểm thử đã xây dựng, thiết lập tần suất, chọn một máy để chạy và kết nối các cảnh báo. Hướng dẫn này sẽ trình bày tất cả một cách trung thực, bao gồm cả những giới hạn hiện tại. Nếu bạn mới làm quen với việc chạy các kiểm tra tự động đối với các điểm cuối trực tiếp, bài giới thiệu của chúng tôi về giám sát API sẽ cung cấp bối cảnh rộng hơn, và tài liệu Tác vụ theo lịch của Apidog là nguồn thông tin chính thức cho giao diện người dùng.
Một lưu ý nhanh trước khi bạn bắt đầu. Tính năng Tác vụ theo lịch (Scheduled Tasks) hiện đang ở phiên bản Beta và số lượng lần chạy theo lịch chính xác mà tài khoản của bạn nhận được phụ thuộc vào gói dịch vụ của bạn. Hãy ghi nhớ cả hai điều này khi bạn đọc.
Tác vụ theo lịch làm gì (và chúng khác với trình thu thập dữ liệu theo lịch như thế nào)
Một tác vụ theo lịch trong Apidog chạy một hoặc nhiều Kịch bản kiểm thử (Test Scenarios) đã lưu theo một chu kỳ lặp lại. Hãy nghĩ đến việc kiểm thử hồi quy hàng đêm trên API cốt lõi của bạn, kiểm tra "smoke check" vài giờ một lần đối với môi trường staging, hoặc quét kiểm tra sức khỏe cuối tuần. Tác vụ sẽ ghi nhớ những kịch bản nào cần chạy, môi trường nào cần tác động, tần suất kích hoạt, máy nào thực thi công việc và ai sẽ được thông báo khi nó thất bại.
Nếu bạn đã thấy cụm từ "tác vụ theo lịch" gắn liền với việc cào web (web scraping) hoặc thu thập dữ liệu, thì đó là một việc khác. Tính năng này không phải để thu thập dữ liệu các trang web theo bộ đếm thời gian. Nó nằm trong module Kiểm thử (Tests) và điều khiển các kịch bản kiểm thử API của bạn: các khẳng định (assertions), các yêu cầu nối tiếp (chained requests), các biến được trích xuất (extracted variables), và tất cả các tính năng khác. Kết quả đầu ra là báo cáo thành công hoặc thất bại trên hợp đồng API của bạn, chứ không phải một tập dữ liệu đã được cào.
Sự khác biệt đó rất quan trọng vì nó thay đổi cách bạn cấu hình. Bạn không viết bộ chọn (selectors) hay quy tắc cào dữ liệu (crawl rules). Bạn đang chọn các kịch bản kiểm thử hiện có và cho Apidog biết khi nào và ở đâu để chạy chúng.
Trước khi bắt đầu: cấu hình Runner tự host
Đây là điều kiện tiên quyết mà mọi người thường mắc lỗi. Để chạy các tác vụ theo lịch, trước tiên bạn cần cấu hình một Runner tự host. Tài liệu đã nói rõ về điều này.
Runner là một máy thực thi bộ kiểm thử. Khi một tác vụ theo lịch được kích hoạt, Apidog không chạy các yêu cầu trong ứng dụng khách trên máy tính của bạn; nó giao việc cho Runner bạn đã chọn, và mọi yêu cầu trong bộ kiểm thử được gửi từ máy đó. Một máy CI, một máy chủ nhỏ luôn hoạt động, hoặc một máy ảo chuyên dụng đều hoạt động tốt. Dù bạn chọn gì, nó vẫn sẽ hoạt động và có thể truy cập được theo lịch trình bạn muốn.
Trường đích Runner cung cấp hai lựa chọn: Apidog Cloud, được đánh dấu "sắp ra mắt", hoặc một Runner tự host. Vì Apidog Cloud chưa có sẵn, Runner tự host là lựa chọn duy nhất hoạt động được hiện nay. Đừng lên kế hoạch xung quanh việc thực thi trên đám mây cho đến khi nó được phát hành.
Vì các yêu cầu bắt nguồn từ máy của Runner, môi trường mạng của nó định hình kết quả của bạn. Một Runner nằm sau VPN của công ty, ở một khu vực khác hoặc trong một mạng con được tường lửa bảo vệ có thể thấy các phản hồi khác với máy tính xách tay của bạn. Đó thường là điều bạn muốn để giám sát thực tế, nhưng điều đáng biết là khi một lần chạy theo lịch không khớp với một lần chạy cục bộ.
Từng bước: tạo tác vụ theo lịch
Sau khi đã đăng ký Runner, phần còn lại diễn ra trong ứng dụng khách. Ví dụ đang thực hiện dưới đây là một bộ kiểm thử hồi quy hàng đêm cho một API thương mại điện tử bao gồm đăng ký người dùng, liệt kê sản phẩm, giỏ hàng và thanh toán được hỗ trợ bởi Stripe.
1. Mở Tác vụ theo lịch (Scheduled Tasks) trong mô-đun Kiểm thử (Tests)
Mở mô-đun Kiểm thử (Tests) trong ứng dụng khách Apidog. Trong cây thư mục Kiểm thử, nhấp vào Tác vụ theo lịch (Scheduled Tasks) để xem và quản lý mọi tác vụ theo lịch trong dự án. Tất cả các tác vụ trên toàn dự án đều hiển thị ở đây trong phần Tác vụ theo lịch (Scheduled Tasks), vì vậy đây là nơi duy nhất để bạn xem những gì đang chạy và khi nào.
2. Tạo tác vụ
Nhấp vào + Mới để tạo một tác vụ theo lịch mới. Bạn cũng có thể tạo một thư mục ở đây để nhóm các tác vụ liên quan, điều này rất tiện lợi khi bạn có các bộ kiểm thử riêng biệt cho môi trường staging và production hoặc cho các dịch vụ khác nhau.
Đặt cho tác vụ một Tên tác vụ (Task Name) và Mô tả (Description) rõ ràng. Những điều này tồn tại để phân biệt các tác vụ và giải thích mục đích của chúng, để bạn trong tương lai biết "Kiểm thử hồi quy hàng đêm, môi trường production" thực sự bao gồm những gì mà không cần mở nó. Mỗi tác vụ cũng có một nút bật/tắt (enable/disable toggle), và các tác vụ trong cây thư mục có thể được bật hoặc tắt bất cứ lúc nào.
3. Chọn các kịch bản kiểm thử (Test Scenarios) để chạy
Trong mục Kịch bản kiểm thử (Test Scenario), chọn một hoặc nhiều kịch bản để bao gồm. Đối với ví dụ thương mại điện tử, bạn có thể chọn "Đăng ký và đăng nhập", "Duyệt và thêm vào giỏ hàng", và "Thanh toán bằng thẻ thử nghiệm Stripe" để một tác vụ duy nhất bao gồm toàn bộ luồng quan trọng.
Mỗi kịch bản có thể mang theo các cài đặt thực thi riêng: Môi trường (Environment), dữ liệu kiểm thử, số lần lặp, độ trễ và liệu có lưu yêu cầu và phản hồi hay không. Nếu bạn không muốn điều chỉnh từng cái một, hãy bật "Sử dụng cùng cấu hình thực thi" (Use same execution config) để áp dụng một cấu hình thời gian chạy duy nhất cho mọi kịch bản đã chọn cùng một lúc. Điều đó giúp một bộ kiểm thử lớn trở nên nhất quán và nhanh chóng thiết lập.
Lựa chọn môi trường là cài đặt mà mọi người quan tâm nhất. Trỏ một trình giám sát production hàng đêm vào môi trường prod của bạn, và trỏ một kiểm thử "smoke test" trước phát hành vào môi trường staging. Vì mỗi kịch bản có thể chỉ định môi trường riêng của nó, một tác vụ thậm chí có thể kết hợp các mục tiêu nếu bạn cần, mặc dù việc giữ một tác vụ trong một môi trường duy nhất sẽ dễ hiểu hơn.
4. Đặt chu kỳ chạy
Đặt trường lịch chạy (run-schedule) theo tần suất bạn muốn. Tùy thuộc vào màn hình bạn đang ở, trường này có thể hiển thị là "Chu kỳ chạy" (Run Cycle) hoặc "Chế độ chạy" (Run Mode); đó là cùng một cài đặt và cách diễn đạt nhãn có thể khác nhau trên giao diện người dùng. Tài liệu cung cấp các ví dụ cụ thể mà bạn có thể làm theo: mỗi Chủ Nhật lúc 11 giờ tối, mỗi 6 giờ hoặc mỗi 8 giờ.
Đối với kiểm thử hồi quy hàng đêm, một lần chạy muộn vào ban đêm hàng ngày giúp giảm thiểu tiếng ồn và phát hiện vấn đề trước giờ làm việc. Đối với kiểm thử "smoke test" trên môi trường staging, mỗi 6 giờ sẽ cung cấp phản hồi nhanh hơn mà không làm quá tải môi trường.
5. Chọn nơi nó chạy
Đặt trường Runner thành Runner tự host của bạn. Giống như trường lịch trình, trường này được gắn nhãn không nhất quán trên các màn hình như "Chạy trên" (Runs on), "Chạy vào" (Run On), hoặc "Chạy trên" (Runs On); tất cả đều có nghĩa giống nhau, đó là máy thực thi bộ kiểm thử. Apidog Cloud cũng xuất hiện ở đây nhưng sẽ "sắp ra mắt", vì vậy hãy chọn Runner tự host của bạn. Nếu bạn đã đăng ký nhiều Runner đa năng, hãy chọn Runner cụ thể mà bạn muốn, ví dụ một Runner nằm trong cùng VPC với API của bạn.
Hãy nhớ rằng tất cả các yêu cầu được khởi tạo trong bộ kiểm thử đều được gửi từ máy được chỉ định ở đây, vì vậy hãy chọn một Runner có mạng nhìn thấy API của bạn theo cách mà lưu lượng truy cập thực tế vẫn thấy.
6. Bật thông báo
Bật Thông báo (Notification) để tác vụ thông báo cho bạn khi có sự cố. Tài liệu khuyến nghị điều này cho các tác vụ theo lịch, và đó là mục đích chính của các lần chạy tự động: im lặng có nghĩa là thành công, và một thất bại phải đến được với bạn thật nhanh.
Apidog hỗ trợ các kênh sau: Slack, Teams, Webhook, Jenkins và Email. Đối với Email, địa chỉ của các thành viên dự án sẽ tự động hoàn thành, và bạn có thể nhập thủ công các địa chỉ không phải thành viên cho vòng luân chuyển trực hoặc hộp thư dùng chung. Slack sẽ gửi trực tiếp các lỗi vào kênh nhóm của bạn; tùy chọn Webhook cho phép bạn phân phối đến bất kỳ dịch vụ nào khác mà bạn đang sử dụng, từ PagerDuty đến một điểm cuối tùy chỉnh.
Bạn cũng có thể chọn thời điểm cảnh báo được kích hoạt: sau mỗi lần chạy, hoặc chỉ khi có lỗi. Đối với một bộ kiểm thử hàng đêm ổn định, tùy chọn "chỉ khi có lỗi" (failures-only) giữ cho kênh yên tĩnh cho đến khi có vấn đề. Trong quá trình triển khai không ổn định, tùy chọn "mỗi lần chạy" (every-run) cung cấp cho bạn một tín hiệu sống còn xác nhận rằng công việc đang được thực thi.
7. Lưu và kích hoạt
Chuyển đổi nút bật/tắt của tác vụ để kích hoạt nó, và nó sẽ bắt đầu chạy theo tần suất bạn đã đặt. Bạn có thể tắt nó sau này mà không cần xóa, điều này hữu ích trong thời gian ngừng hoạt động theo kế hoạch hoặc trong cửa sổ di chuyển gây nhiễu.
8. Đọc lịch sử chạy
Sau mỗi lần chạy, kết quả sẽ tự động tải lên từ Runner về máy chủ. Mở phần Lịch sử chạy tác vụ theo lịch (Scheduled Tasks - Run History) trong ứng dụng khách để xem chúng. Đây là dấu vết kiểm tra của bạn: lần chạy nào thành công, lần nào thất bại, khẳng định nào bị hỏng và khi nào. Khi một cảnh báo xuất hiện trong Slack, Lịch sử chạy là nơi bạn đến để xem chi tiết đằng sau nó.
Cài đặt nâng cao và các biến thể
Khi tác vụ cơ bản đã chạy, một vài tùy chọn sẽ giúp nó vững chắc hơn.
Phạm vi biến (Variable scope). Khi các kịch bản của bạn truyền dữ liệu giữa các lần chạy, Apidog cung cấp ba cấp độ chia sẻ, từ nhỏ nhất đến lớn nhất: "Chỉ chia sẻ trong kịch bản kiểm thử hiện tại" (Share only in the current test scenario), giữ một biến trong một tệp riêng cho kịch bản đó; "Chia sẻ giữa tất cả các kịch bản kiểm thử trong tác vụ theo lịch hiện tại" (Share across all test scenarios in the current scheduled task), cho phép các kịch bản trong cùng một tác vụ đọc giá trị của nhau; và "Chia sẻ giữa tất cả các tác vụ theo lịch trong thư mục tác vụ theo lịch hiện tại" (Share across all scheduled tasks in the current scheduled task folder), là phạm vi rộng nhất. Hãy chọn phạm vi nhỏ nhất vẫn cho phép dữ liệu của bạn luân chuyển, để mã thông báo xác thực từ một kịch bản không bị rò rỉ vào một kịch bản không liên quan.
Tính bền vững của biến (Variable persistence). Các giá trị chỉ được truyền từ lần chạy này sang lần chạy tiếp theo nếu tùy chọn "Giữ giá trị biến" (Keep variable values) được bật trên trang thiết kế kịch bản kiểm thử. Nếu lần chạy hàng đêm của bạn cần ID đơn hàng đã được ghi lại từ hôm qua hoặc một mã thông báo đã được làm mới, hãy bật tùy chọn này. Nếu không, mỗi lần chạy sẽ bắt đầu lại từ đầu và mọi giả định giữa các lần chạy sẽ bị phá vỡ một cách âm thầm.
Nhóm bằng thư mục. Khi bộ kiểm thử của bạn phát triển, hãy tạo các thư mục dưới Tác vụ theo lịch (Scheduled Tasks) để tách biệt, ví dụ, các trình giám sát production khỏi các kiểm tra trước khi phát hành. Phạm vi biến cấp thư mục sau đó cho phép một nhóm các tác vụ liên quan chia sẻ thiết lập một cách gọn gàng.
Giới hạn gói dịch vụ. Số lượng lần chạy theo lịch mà bạn nhận được phụ thuộc vào gói đăng ký của bạn. Tài liệu chỉ đến trang giá của Apidog để biết số liệu chính xác, vì vậy hãy kiểm tra gói của bạn trước khi bạn đặt một tần suất chạy mỗi giờ một cách mạnh mẽ. Nếu bạn cần bao quát sâu hơn về việc nhóm và các mô hình lập lịch nặng hơn, hướng dẫn của chúng tôi về các tác vụ theo lịch nâng cao sẽ đi sâu hơn, và hướng dẫn liên quan về logic điều kiện trong các kịch bản kiểm thử API giúp bạn xây dựng các kịch bản đáng để lập lịch ngay từ đầu. Đối với các nhóm thiết lập các kiểm tra tự động đầu tiên của họ, bài viết về chạy kiểm thử API hàng đêm trong CI rất phù hợp với hướng dẫn này.
Tự động hóa quy trình làm việc với Apidog CLI
Giao diện người dùng của Tác vụ theo lịch (Scheduled Tasks UI) là một cách. Apidog CLI là cách thứ ba, và nó là một cách thực tế: bạn chạy một kịch bản đã lưu mà không cần giao diện người dùng (headlessly), sau đó để cron hoặc nhà cung cấp CI của bạn xử lý tần suất. Nói rõ hơn, CLI không có lệnh lập lịch tự nhiên; việc lập lịch nằm ngoài Apidog trong công cụ bạn đã tin cậy cho cron.
Cài đặt và xác thực, sau đó chạy một kịch bản theo ID đối với một môi trường đã chọn. Hướng dẫn cài đặt Apidog CLI trình bày đầy đủ việc thiết lập token:
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
Ở đây, -t là ID kịch bản kiểm thử, -e là ID môi trường, và -r là trình báo cáo (cli, html, hoặc junit, được phân tách bằng dấu phẩy cho nhiều loại). Để chạy nó hàng đêm với cron, hãy thêm một dòng:
0 2 * * * cd /srv/api-tests && apidog run --access-token $APIDOG_ACCESS_TOKEN -t 4471 -e 88 -r junit >> run.log 2>&1
Hoặc kích hoạt nó từ một công việc GitHub Actions đã được lập lịch. Dù bằng cách nào, báo cáo JUnit sẽ được đưa vào bảng điều khiển pipeline hiện có của bạn. Xem Apidog CLI trong pipeline CI/CD của bạn để biết cách thiết lập đầy đủ, bao gồm cron và các trình kích hoạt lịch trình của GitHub Actions.
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. Mục tiêu Runner liệt kê Apidog Cloud là "sắp ra mắt", vì vậy Runner tự host là máy thực thi hoạt động duy nhất hiện nay. Hãy đăng ký một Runner trước, sau đó chọn nó trong tác vụ.
Các tác vụ theo lịch có thể chạy bao lâu một lần? Tùy theo gói dịch vụ của bạn cho phép. Tần suất bản thân nó rất linh hoạt, với các ví dụ được ghi lại như mỗi 6 giờ hoặc mỗi Chủ Nhật lúc 11 giờ tối, nhưng số lượng lần chạy theo lịch bị giới hạn bởi gói đăng ký của bạn. Hãy kiểm tra trang giá của Apidog để biết giới hạn chính xác cho cấp độ của bạn thay vì tự giả định một con số.
Làm cách nào để tôi chỉ nhận được thông báo khi một bài kiểm thử thất bại? Trong cài đặt Thông báo (Notification) của tác vụ, chọn tùy chọn "chỉ khi có lỗi" (failures-only) thay vì "mỗi lần chạy", sau đó thêm một kênh: Slack, Teams, Webhook, Jenkins hoặc Email. Điều này giữ cho kênh của bạn yên tĩnh vào những đêm thành công và ồn ào khi có sự cố. Kết hợp nó với một kiểm tra sức khỏe API nhẹ nhàng để có tín hiệu hoạt động nhanh chóng bên cạnh bộ kiểm thử hồi quy sâu hơn.
Tại sao kết quả theo lịch của tôi khác với các lần chạy kiểm thử cục bộ của tôi? Bởi vì các yêu cầu đến từ máy của Runner, chứ không phải máy tính xách tay của bạn. Mạng, khu vực và bất kỳ VPN hoặc tường lửa nào của nó đều định hình các phản hồi. Điều đó là bình thường, và thường là cái nhìn thực tế hơn về những gì người dùng của bạn gặp phải.
Các biến của tôi bị đặt lại sau mỗi lần chạy. Tôi đã bỏ lỡ điều gì? Tùy chọn "Giữ giá trị biến" (Keep variable values) trên trang thiết kế kịch bản kiểm thử. Kích hoạt nó để các giá trị đã chụp được duy trì từ lần chạy này sang lần chạy tiếp theo. Nếu không có nó, mỗi lần chạy theo lịch sẽ bắt đầu lại từ đầu và mọi phụ thuộc giữa các lần chạy sẽ thất bại.
Kết luận
Các kiểm thử theo lịch biến "chúng tôi nghĩ API hoạt động" thành "chúng tôi biết, và chúng tôi đã nhận được thông báo nếu nó không hoạt động." Xây dựng kịch bản của bạn một lần, đăng ký một Runner tự host, đặt Chu kỳ chạy (Run Cycle), kết nối Slack hoặc email khi thất bại, và để nó chạy trong khi bạn ngủ. Khi bạn muốn cùng các kiểm tra đó bên trong một pipeline, CLI cộng với cron cung cấp cho bạn cách thứ ba mà không cần thêm công cụ nào. Tải xuống Apidog để thiết lập bộ kiểm thử hồi quy theo lịch đầu tiên của bạn. Nó miễn phí để bắt đầu, không yêu cầu thẻ tín dụng.