Sau khi tạo một bộ kiểm thử, bạn cần thêm nội dung kiểm thử. Apidog cung cấp các chế độ linh hoạt "Static" và "Dynamic" để đáp ứng các nhu cầu quản lý kiểm thử khác nhau.Nhập Nội dung Kiểm thử#
Trong trang chi tiết bộ kiểm thử, tại tab Orchestration, nhấp vào + Add Endpoint Test Case hoặc + Add Test Scenario. Trong cửa sổ lựa chọn bật lên, bạn có thể chuyển đổi giữa chế độ Static hoặc Dynamic.1. Chế độ Static#
Chế độ Static được sử dụng để chỉ định chính xác các mục kiểm thử sẽ được thực thi.Hệ thống ghi lại ID của các trường hợp kiểm thử cụ thể mà bạn chọn. Ngay cả khi các trường hợp kiểm thử mới được thêm vào danh mục nguồn, phạm vi thực thi của bộ kiểm thử này cũng sẽ không thay đổi, qua đó bảo đảm khả năng kiểm soát kết quả kiểm thử.🚀 Tình huống sử dụng phù hợp nhấtXác minh sửa lỗi (Hotfix): Chọn 3-5 trường hợp kiểm thử có liên quan chặt chẽ đến lỗi, tạo thành một "gói xác minh", nhanh chóng xác minh kết quả sửa lỗi mà không lãng phí thời gian chạy các trường hợp không liên quan.
Ổn định nghiệp vụ cốt lõi (Core Path): Dành cho các quy trình cực kỳ cốt lõi và ổn định như "đặt hàng-thanh toán". Chúng ta không muốn cảnh báo giám sát bị kích hoạt chỉ vì một người mới vô tình thêm một trường hợp kiểm thử chưa hoàn chỉnh.
Kiểm thử tương thích phiên bản cũ: Chọn một nhóm trường hợp kiểm thử endpoint cũ chuyên dùng để xác minh khả năng tương thích với client phiên bản cũ.
Chi phí bảo trì cao: Nếu cần đưa các trường hợp mới vào kiểm thử chuyên biệt này, chúng phải được thêm thủ công.
2. Chế độ Dynamic#
Chế độ Dynamic được sử dụng để tự động lọc các mục kiểm thử sẽ được thực thi thông qua các quy tắc.Hệ thống lưu "Quy tắc lọc" (Scope & Filter). Mỗi lần chạy, hệ thống quét toàn bộ dự án theo thời gian thực và đưa tất cả các trường hợp mới nhất đáp ứng tiêu chí vào kế hoạch thực thi.🚀 Tình huống sử dụng phù hợp nhấtKiểm thử hồi quy cấp mô-đun: Đặt thư mục "Trading Center" làm thư mục nguồn. Người kiểm thử chỉ cần viết các trường hợp mới trong thư mục, và bộ kiểm thử sẽ tự động đưa chúng vào khi chạy.
Kiểm thử Smoke: Tạo một bộ kiểm thử động với quy tắc Priority = P0. Chạy trước mỗi lần phát hành để tự động bao phủ tất cả các trường hợp chính được đánh dấu là P0.
Xác minh lặp phiên bản: Sử dụng tính năng thẻ, đặt quy tắc thành Tag = v2.5.0. Sau khi phát triển hoàn tất, chạy bộ kiểm thử này để xác minh tất cả tính năng mới của phiên bản này.
Không tốn chi phí bảo trì: Sau khi các quy tắc được cấu hình, không cần bảo trì chính bộ kiểm thử nữa, chỉ cần duy trì các thuộc tính của trường hợp kiểm thử (vị trí, thẻ, mức độ ưu tiên).
Điều chỉnh Thứ tự Thực thi#
Nội dung đã nhập sẽ được hiển thị trong một danh sách, và bạn có thể kéo các mục trong danh sách để điều chỉnh thứ tự thực thi.Đối với các mục được thêm "tĩnh", bạn có thể sử dụng Edit để xóa từng trường hợp kiểm thử riêng lẻ hoặc xóa toàn bộ nhóm.Đối với các nhóm được thêm "động", bạn chỉ có thể xóa toàn bộ nhóm hoặc chỉnh sửa tiêu chí lọc, và không thể xóa từng mục riêng lẻ trong nhóm.Cấu hình Nâng cao#
Ở phía bên phải của trang thiết kế bộ kiểm thử, bạn có thể mở rộng Advanced Config để kiểm soát chi tiết hơn cách bộ kiểm thử chạy.Môi trường#
Định nghĩa: Theo mặc định, kế thừa môi trường chạy đã được thiết lập trong bộ kiểm thử. Nếu một môi trường được chỉ định tại đây, cấu hình môi trường đó sẽ được ưu tiên trong quá trình thực thi.
Trường hợp sử dụng: Phù hợp với các tình huống cần tái sử dụng cùng một tập hợp bước kiểm thử trong các môi trường khác nhau.
Dữ liệu Kiểm thử#
Được sử dụng để chỉ định có sử dụng dữ liệu kiểm thử trong quá trình thực thi hay không.Sử dụng Dữ liệu Kiểm thử: Chạy nhiều lần dựa trên dữ liệu kiểm thử, thường được dùng cho kiểm thử tham số hóa.
Khi Có Lỗi#
Cấu hình cách kiểm thử xử lý lỗi, có thể bao gồm lỗi khẳng định, lỗi xác thực định dạng dữ liệu, ngoại lệ yêu cầu endpoint, lỗi máy chủ, v.v.Bỏ qua: Tiếp tục thực thi các bước tiếp theo khi xảy ra lỗi, không làm gián đoạn lần chạy hiện tại.
Tiếp tục: Khi xảy ra lỗi, bỏ qua các bước còn lại của vòng hiện tại và trực tiếp chuyển sang vòng thực thi tiếp theo.
Kết thúc thực thi: Ngay lập tức chấm dứt các bước tiếp theo khi xảy ra lỗi.
Số lần lặp#
Định nghĩa: Số lần mỗi luồng lặp qua tất cả các bước.
Trường hợp sử dụng: Thường được dùng cho các tình huống xác minh độ ổn định hoặc kiểm thử tải đơn giản.
Độ trễ#
Định nghĩa: Thiết lập số mili giây (ms) cần chờ sau khi mỗi bước kiểm thử hoàn tất trước khi thực thi bước tiếp theo.
Trường hợp sử dụng: Ngăn việc kích hoạt cơ chế giới hạn tốc độ hoặc ngắt mạch trên máy chủ đích do tần suất yêu cầu cao, bảo đảm quá trình thực thi kiểm thử diễn ra suôn sẻ.
Lưu Yêu cầu/Phản hồi#
Định nghĩa: Kiểm soát việc báo cáo kiểm thử có bao gồm dữ liệu chi tiết của yêu cầu và phản hồi (chẳng hạn như Header, Body, v.v.) hay không.
Tất cả: Lưu chi tiết đầy đủ của tất cả các bước bất kể đạt/không đạt. Khối lượng dữ liệu lớn, phù hợp cho gỡ lỗi chuyên sâu.
Chỉ Không đạt: Chỉ lưu chi tiết cho các bước thất bại trong quá trình thực thi. Được khuyến nghị, tiết kiệm không gian lưu trữ và hỗ trợ nhanh chóng xác định nguyên nhân thất bại.
Không Lưu: Không lưu bất kỳ chi tiết nào; chỉ ghi lại trạng thái đạt/không đạt và thời lượng.
Giá trị Biến Môi trường/Toàn cục#
Giá trị biến môi trường/toàn cục chỉ định các giá trị thực tế nào sẽ được sử dụng cho các biến môi trường/toàn cục trong kịch bản kiểm thử này. Có hai lựa chọn. Thông tin chi tiết có thể được xem tại đây. Khi chọn sử dụng các giá trị biến đã lưu trong Runner, bạn sẽ được yêu cầu chọn thêm phạm vi biến cần sử dụng.Mục đích của phạm vi này là giúp người dùng tách biệt biến tốt hơn theo nhu cầu thực tế, tránh các tình huống trong đó một lần chạy tác vụ theo lịch làm thay đổi biến và khiến các tác vụ khác thất bại. Sau khi chọn phạm vi, bạn cũng có thể xem các giá trị biến trong phạm vi này thông qua mục truy cập xuất hiện trong giao diện sản phẩm. | Phạm vi Biến trong Runner | Đọc/Ghi Biến Môi trường/Toàn cục | Mô tả |
|---|
| Chỉ chia sẻ trong kịch bản kiểm thử hiện tại | - Trong Runner được chỉ định hiện tại, kịch bản kiểm thử này có một tệp chuyên dụng để lưu trữ bền vững các biến môi trường/toàn cục của nó.
- Chỉ kịch bản kiểm thử hiện tại mới có thể đọc và ghi các biến trong tệp này.
| Phạm vi biến nhỏ nhất với mức ảnh hưởng tối thiểu. Phù hợp với các trường hợp cần sử dụng kết quả của lần chạy trước của kịch bản kiểm thử này trong lần chạy tiếp theo.
Các tệp biến cho kịch bản kiểm thử, tác vụ và thư mục tác vụ đều được lưu trong đường dẫn container Runner /opt/runner/variables. |
| Chia sẻ trên tất cả kịch bản kiểm thử trong tác vụ theo lịch hiện tại | - Trong Runner được chỉ định hiện tại, tác vụ theo lịch có một tệp để lưu trữ các biến môi trường/toàn cục có thể được sử dụng trên tất cả các kịch bản kiểm thử của tác vụ đó.
- Tất cả kịch bản kiểm thử trong tác vụ theo lịch hiện tại có thể đọc và ghi các biến trong tệp này.
| Phạm vi biến được khuyến nghị với mức ảnh hưởng vừa phải. Phù hợp với các trường hợp cần chia sẻ dữ liệu giữa các kịch bản kiểm thử khác nhau trong cùng một tác vụ theo lịch. |
| Chia sẻ trên tất cả tác vụ theo lịch trong thư mục tác vụ theo lịch hiện tại | - Trong Runner được chỉ định hiện tại, thư mục tác vụ theo lịch có một tệp để lưu trữ các biến môi trường/toàn cục có thể được sử dụng trên tất cả các tác vụ theo lịch và kịch bản kiểm thử của thư mục đó.
- Tất cả kịch bản kiểm thử trong tất cả tác vụ theo lịch thuộc thư mục hiện tại có thể đọc và ghi các biến trong tệp này.
| Ph ạm vi biến lớn nhất với mức ảnh hưởng đáng kể nhất. Có khả năng việc chạy một tác vụ theo lịch nhất định sẽ sửa đổi giá trị biến, dẫn đến thất bại của các tác vụ theo lịch khác. Phù hợp khi dữ liệu cần được chia sẻ trên nhiều tác vụ trong cùng một thư mục. |
Modified at 2026-06-11 10:23:06
