Bạn đã viết một bài kiểm tra đăng nhập. Nó hoạt động. Sau đó, một đồng nghiệp đặt câu hỏi hiển nhiên: liệu nó có hoạt động với tài khoản bị khóa, email chưa được xác minh, mật khẩu có khoảng trắng thừa, chuỗi SQL-injection mà ai đó cuối cùng sẽ dán vào trường không? Giờ đây bạn có một lựa chọn. Sao chép bài kiểm tra đó năm lần và thay đổi một giá trị trong mỗi bản sao, hoặc tìm cách cấp cho cùng một bài kiểm tra nhiều hàng dữ liệu đầu vào và để nó chạy tất cả.
Cách sao chép-dán là nguyên nhân khiến hầu hết các bộ kiểm thử bị mục nát. Năm bài kiểm thử gần như giống hệt nhau sẽ dần khác biệt sau một năm. Một bài có thêm một khẳng định mới, những bài khác thì không. Việc đổi tên trường làm hỏng bốn trong số chúng một cách lặng lẽ. Bạn phải duy trì năm thứ mà đáng lẽ chỉ cần một. Kiểm thử tham số hóa khắc phục điều này tận gốc: bạn viết bài kiểm thử một lần, sau đó chỉ định nó vào một bảng các đầu vào và đầu ra mong đợi. Một kịch bản, hàng trăm trường hợp, chỉ một nơi để chỉnh sửa.
nút
Kiểm thử tham số hóa thực sự có nghĩa là gì
Kiểm thử tham số hóa, đôi khi được gọi là kiểm thử hướng dữ liệu, tách biệt logic của một bài kiểm thử khỏi dữ liệu mà nó chạy. Logic là chuỗi các bước: gửi yêu cầu, kiểm tra mã trạng thái, xác thực một trường trong phản hồi. Dữ liệu là tập hợp các đầu vào và kỳ vọng bạn muốn logic đó chạy.
Hãy hình dung một kịch bản kiểm thử duy nhất cho một điểm cuối mã giảm giá. Logic luôn giống nhau. Gửi POST /api/orders kèm theo mã, sau đó khẳng định trên phản hồi. Dữ liệu thay đổi theo từng trường hợp:
| code | order_total | expected_status | expected_discount |
|---|---|---|---|
| WELCOME10 | 100 | 200 | 10 |
| WELCOME10 | 5 | 422 | 0 |
| EXPIRED | 100 | 410 | 0 |
| (empty) | 100 | 400 | 0 |
| FAKE123 | 100 | 404 | 0 |
Năm hàng, năm hành vi riêng biệt, một bài kiểm thử. Trình chạy lặp qua các hàng. Trong mỗi lần lặp, nó liên kết các giá trị cột với các biến, gửi yêu cầu và kiểm tra các khẳng định dựa trên kỳ vọng của hàng đó. Khi hàng 3 thất bại vì mã hết hạn trả về 200 thay vì 410, bạn sẽ nhận được một lỗi rõ ràng chỉ ra một hàng. Bạn không phải tìm kiếm trong năm tệp kiểm thử riêng biệt để tìm ra bản sao nào bị lỗi.
Mẫu này quan trọng nhất ở các rìa. Việc kiểm tra các trường hợp thông thường (happy-path) dễ viết và hiếm khi bắt được lỗi khiến bạn phải thức giấc lúc 2 giờ sáng. Lỗi nằm ở các trường hợp biên: chuỗi rỗng, số âm, tên Unicode, token hết hạn, giá trị vượt quá giới hạn một xu. Tham số hóa giúp việc thêm một trường hợp biên dễ dàng như việc thêm một hàng vào bảng tính.
Tại sao một tệp dữ liệu riêng biệt tốt hơn các giá trị được mã hóa cứng
Bạn có thể mã hóa cứng từng trường hợp trực tiếp trong bài kiểm thử. Hầu hết mọi người bắt đầu từ đó. Vấn đề phát sinh sau này.
Khi dữ liệu nằm trong bài kiểm thử, một người không phải kỹ sư không thể đóng góp các trường hợp. Trưởng nhóm QA của bạn biết mười lăm đầu vào phức tạp đã làm hỏng điểm cuối này trước đây, nhưng họ không thể thêm chúng mà không chỉnh sửa mã và mở yêu cầu kéo. Khi dữ liệu nằm trong tệp CSV, họ chỉnh sửa bảng tính và commit nó. Rào cản gần như bằng không.
Một tệp riêng biệt cũng giúp kịch bản kiểm thử của bạn dễ đọc. Một bài kiểm thử lặp qua một tệp bên ngoài rất ngắn gọn: một yêu cầu, một vài khẳng định, xong. Một bài kiểm thử với ba mươi trường hợp nội tuyến là một bức tường lặp lại mà không ai muốn chạm vào. Và khi bạn cần tạo các trường hợp theo chương trình, chẳng hạn như hàng nghìn hàng được kéo từ nhật ký sản xuất, một tệp là lựa chọn hợp lý duy nhất. Bạn không thể dán hàng nghìn trường hợp vào phần thân bài kiểm thử.
Định dạng bạn chọn phụ thuộc vào hình dạng dữ liệu của bạn. Các trường hợp dạng bảng, phẳng phù hợp với CSV. Các payload lồng nhau hoặc có cấu trúc phù hợp với JSON. Cả hai đều là đầu vào hạng nhất trong trình chạy của Apidog, vì vậy lựa chọn là về dữ liệu của bạn, không phải về giới hạn của công cụ.
Thiết lập tệp dữ liệu của bạn
Bắt đầu với CSV cho các trường hợp dạng bảng. Hàng tiêu đề đặt tên cho các biến của bạn; mỗi hàng bên dưới là một lần lặp. Đây là bảng mã giảm giá dưới dạng một tệp thực, discount-cases.csv:
code,order_total,expected_status,expected_discount
WELCOME10,100,200,10
WELCOME10,5,422,0
EXPIRED,100,410,0
,100,400,0
FAKE123,100,404,0
Mỗi tiêu đề cột trở thành một biến mà bạn tham chiếu bên trong bài kiểm thử. Trong phần thân yêu cầu, bạn viết {{code}} và {{order_total}}; trong các khẳng định, bạn so sánh với {{expected_status}} và {{expected_discount}}. Trình chạy thực hiện việc liên kết từng hàng một.
Khi đầu vào của bạn bị lồng, hãy dùng JSON. Một mảng các đối tượng, mỗi đối tượng cho một lần lặp, cho phép mỗi trường hợp mang dữ liệu có cấu trúc mà sẽ rất khó để làm phẳng thành các cột. Đây là user-cases.json cho một điểm cuối tạo người dùng, nơi payload có các trường lồng nhau:
[
{
"scenario": "valid full profile",
"user": {
"email": "ada@example.com",
"roles": ["admin", "billing"],
"profile": { "country": "US", "timezone": "America/New_York" }
},
"expected_status": 201
},
{
"scenario": "missing email",
"user": {
"email": "",
"roles": ["viewer"],
"profile": { "country": "GB", "timezone": "Europe/London" }
},
"expected_status": 400
},
{
"scenario": "unknown role",
"user": {
"email": "grace@example.com",
"roles": ["wizard"],
"profile": { "country": "CA", "timezone": "America/Toronto" }
},
"expected_status": 422
}
]
Bên trong bài kiểm thử, bạn tham chiếu các giá trị có cấu trúc bằng cú pháp {{user}}, {{expected_status}} tương tự, và Apidog chuyển các trường của mỗi đối tượng cho lần lặp. Cột scenario là một nhãn cho chính bạn; nó hiển thị trong báo cáo để một lần lặp bị lỗi hiển thị là "unknown role" thay vì "iteration 3."
Một vài quy tắc giúp các tệp dữ liệu không gây rắc rối cho bạn:
- Giữ một mối quan tâm cho mỗi tệp. Một tệp mã giảm giá và một tệp tạo người dùng là hai tệp, không phải một tệp với các cột hỗn hợp.
- Đặt kết quả mong đợi vào dữ liệu, không phải vào bài kiểm thử. Toàn bộ vấn đề là hàng 2 mong đợi 422 trong khi hàng 1 mong đợi 200. Nếu kỳ vọng được mã hóa cứng, bạn quay lại việc một bài kiểm thử cho mỗi trường hợp.
- Trích dẫn bất cứ thứ gì có dấu phẩy trong CSV, hoặc chuyển tệp đó sang JSON. Một trường văn bản tự do có dấu phẩy là lỗi CSV kinh điển.
- Lưu trữ các tệp này trong kho lưu trữ của bạn bên cạnh phần còn lại của cấu hình kiểm thử để chúng được phiên bản hóa cùng với mã mà chúng kiểm tra.
Xây dựng kịch bản tham số hóa trong Apidog
Trong ứng dụng Apidog, hãy xây dựng kịch bản kiểm thử một lần như bất kỳ kịch bản nào khác. Thêm yêu cầu vào điểm cuối của bạn. Trong phần thân, thay thế các giá trị cố định bằng các tham chiếu biến: {{code}}, {{order_total}}, v.v. Đây là các cột từ tệp dữ liệu của bạn.
Sau đó, thêm các khẳng định đọc từ cùng một tệp. Đối với ví dụ giảm giá, bạn sẽ khẳng định rằng trạng thái phản hồi bằng {{expected_status}} và trường giảm giá trong phần thân JSON bằng {{expected_discount}}. Bởi vì cả đầu vào và đầu ra mong đợi đều đến từ hàng, cùng một logic khẳng định xác thực mọi trường hợp một cách chính xác. Nếu bạn chưa viết khẳng định trong Apidog trước đây, Khẳng định API: một hướng dẫn thực tế bao gồm các mẫu, và cách đặt khẳng định và trích xuất biến từ phản hồi JSON trình bày chi tiết về phía JSONPath.
Để kết nối dữ liệu, hãy mở cài đặt chạy của kịch bản kiểm thử và đính kèm tệp CSV hoặc JSON của bạn làm nguồn dữ liệu lặp. Apidog đọc tệp, đếm số hàng và chạy kịch bản một lần cho mỗi hàng, liên kết các cột của mỗi hàng với các biến tương ứng. Chạy nó bên trong ứng dụng và bạn sẽ nhận được một phân tích chi tiết cho từng lần lặp: hàng nào đã vượt qua, hàng nào thất bại, và giá trị thực tế so với giá trị mong đợi cho mỗi khẳng định thất bại.
Đây cũng là nơi tham số hóa kết hợp với phần còn lại của bộ kiểm thử của bạn. Một kịch bản tham số hóa vẫn là một kịch bản, vì vậy bạn có thể nhóm một vài trong số chúng vào một bộ kiểm thử và chạy toàn bộ bộ đó như một công việc duy nhất. Vòng lặp hướng dữ liệu xử lý phạm vi rộng trong một điểm cuối duy nhất; bộ kiểm thử xử lý phạm vi phủ sóng trên các điểm cuối.
Chạy nó từ dòng lệnh
Ứng dụng là nơi bạn xây dựng và gỡ lỗi. CI là nơi kiểm thử phát huy tác dụng, chạy trên mọi pull request mà không cần ai phải nhấp vào nút. Chức năng chuyển giao đó là dành cho Apidog CLI. Nó lấy kịch bản bạn đã xây dựng trong ứng dụng và chạy nó mà không cần giao diện người dùng từ một terminal, với cùng dữ liệu lặp.
CLI được phân phối dưới dạng gói npm. Cài đặt nó trên toàn cầu:
npm install -g apidog-cli
Tệp thực thi là apidog, vì vậy mọi lệnh bắt đầu bằng apidog run. Một lần chạy cơ bản trỏ đến một kịch bản theo ID và một môi trường theo ID:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli
Để điều khiển kịch bản đó từ một tệp dữ liệu, hãy thêm cờ iteration-data. Nó chấp nhận một đường dẫn đến một tệp JSON hoặc CSV:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 \
-d ./discount-cases.csv -r cli,junit --out-dir ./test-reports
Cờ -d (dạng đầy đủ --iteration-data) là trọng tâm của các lần chạy tham số hóa từ dòng lệnh. Apidog đọc tệp, chạy kịch bản một lần cho mỗi hàng và báo cáo từng lần lặp. Thay thế discount-cases.csv bằng user-cases.json và cùng một cờ xử lý mảng JSON; trình chạy nhận định dạng từ tệp. Xử lý mã truy cập như một mật khẩu và lưu trữ nó dưới dạng bí mật CI, không bao giờ trong một tệp đã cam kết. Đó là lý do tại sao mọi ví dụ đều tham chiếu $APIDOG_ACCESS_TOKEN thay vì một giá trị cố định.
Một vài cờ kết hợp tự nhiên với các lần chạy tham số hóa:
-d, --iteration-data <path>trỏ lần chạy đến tệp CSV hoặc JSON của bạn. Đây là cờ biến một lần chạy đơn lẻ thành một lần chạy hướng dữ liệu.-n, --iteration-count <n>chạy kịch bản một số lần cố định. Khi bạn cung cấp một tệp dữ liệu, số lượng hàng thường điều khiển các lần lặp, vì vậy bạn sử dụng-nchủ yếu cho các trường hợp lặp lại mà không có dữ liệu, như các bài kiểm thử độ bền (soak tests).-r, --reporters <list>chọn định dạng đầu ra. Sử dụngclicho đầu ra nhật ký xây dựng dễ đọc vàjunitđể xuất XML mà các bảng điều khiển CI phân tích thành cây pass/fail cho mỗi lần lặp.--out-dir <path>đặt nơi các báo cáo được lưu trữ để bạn có thể lưu trữ chúng dưới dạng các tạo phẩm xây dựng.
Nếu bạn muốn danh sách các cờ chính thức, hiện tại cho phiên bản đã cài đặt của mình, hãy chạy apidog run --help. CLI in mọi tùy chọn với dạng ngắn và dài của nó.
Kết nối các lần chạy tham số hóa vào CI
Lý do để đầu tư vào các bài kiểm thử tham số hóa là chúng mang lại lợi ích tự động. Đây là một công việc GitHub Actions cài đặt CLI và chạy một kịch bản dựa trên CSV trên mọi pull request:
name: API tests
on: [pull_request]
jobs:
api-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install Apidog CLI
run: npm install -g apidog-cli
- name: Run parameterized API tests
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
run: |
apidog run --access-token $APIDOG_ACCESS_TOKEN \
-t 605067 -e 1629989 \
-d ./tests/discount-cases.csv \
-r cli,junit --out-dir ./test-reports
- name: Upload report
if: always()
uses: actions/upload-artifact@v4
with:
name: api-test-report
path: ./test-reports
Mã thông báo đến từ secrets.APIDOG_ACCESS_TOKEN, được thiết lập một lần trong cài đặt kho lưu trữ của bạn. Trình báo cáo junit ghi XML mà hầu hết các bảng điều khiển CI biến thành một cây kết quả cho mỗi lần lặp, vì vậy một hàng bị lỗi hiển thị dưới dạng một kiểm thử bị lỗi được đặt tên thay vì một khối văn bản nhật ký. Lệnh if: always() trên bước tải lên có nghĩa là bạn giữ báo cáo ngay cả khi lần chạy thất bại, đó chính xác là lúc bạn cần nó. Để tìm hiểu sâu hơn về phía Actions, hãy xem cách tự động hóa các bài kiểm thử API trong GitHub Actions.
Cùng một kịch bản và cùng một tệp dữ liệu chạy trong bất kỳ hệ thống CI nào. GitLab CI, Jenkins, CircleCI và phần còn lại đều quy về ba bước tương tự: cài đặt Node và CLI, công khai token dưới dạng biến môi trường, gọi apidog run với -d. Không có việc viết lại kiểm thử của bạn cho từng nền tảng.
So sánh các cách tiếp cận kiểm thử tham số hóa
Apidog không phải là cách duy nhất để chạy các bài kiểm thử API hướng dữ liệu. Cần biết bức tranh tổng thể để bạn chọn lựa phù hợp.
Postman và các trình chạy của nó cũng hỗ trợ tệp dữ liệu. Với Postman’s Collection Runner hoặc công cụ dòng lệnh Newman, bạn đính kèm tệp CSV hoặc JSON và tham chiếu các biến {{column}} trong các yêu cầu, rất giống với mẫu ở đây. Đó là một cách tiếp cận có khả năng và được tài liệu hóa tốt. Đánh đổi là logic kiểm thử của bạn nằm trong các tập lệnh JavaScript pre-request và test, vì vậy khi các khẳng định của bạn tăng lên, bạn phải duy trì nhiều mã hơn. Nếu bạn đang cân nhắc các trình chạy dòng lệnh cụ thể, Postman CLI vs Newman phân tích sự khác biệt.
Các framework ưu tiên mã như pytest với @pytest.mark.parametrize, JUnit’s @ParameterizedTest, hoặc REST Assured cung cấp cho bạn quyền kiểm soát ngôn ngữ lập trình đầy đủ. Chúng là lựa chọn đúng đắn khi logic kiểm thử của bạn thực sự cần mã: thiết lập phức tạp, tạo dữ liệu tùy chỉnh, kết nối chặt chẽ với một cơ sở mã kiểm thử hiện có. Chi phí là mọi trường hợp đều nằm trong mã, vì vậy những người không phải kỹ sư không thể đóng góp, và bạn phải tự duy trì phần xử lý HTTP.
Góc nhìn của Apidog là kịch bản trực quan và dữ liệu bên ngoài, vì vậy logic vẫn dễ đọc và các trường hợp vẫn mở cho bất kỳ ai có thể chỉnh sửa bảng tính, trong khi cùng một kịch bản vẫn chạy không đầu trong CI. Nếu bạn đang đặc biệt chọn một công cụ để chạy hướng dữ liệu CSV và JSON, sự so sánh trong công cụ nào cho kiểm thử API hướng dữ liệu với CSV hoặc JSON đi sâu hơn vào các đánh đổi. Không có cách nào là sai. Phù hợp cách tiếp cận với người viết các trường hợp và mức độ logic tùy chỉnh mà mỗi trường hợp cần.
Một quy trình làm việc thực tế có thể mở rộng
Đây là cách nó trông như thế nào khi nó trở thành một phần trong quy trình làm việc của nhóm bạn.
Bắt đầu từ phạm vi hẹp. Chọn một điểm cuối đã từng gây rắc rối cho bạn. Viết kịch bản duy nhất trong Apidog với các tham chiếu biến trong yêu cầu và kết quả mong đợi trong các khẳng định. Xây dựng một tệp CSV với ba hàng: một trường hợp "happy path" (thành công), một trường hợp lỗi đã biết, một trường hợp biên. Chạy nó trong ứng dụng cho đến khi cả ba lần lặp đều hoạt động như mong đợi.
Sau đó, mở rộng dữ liệu, không phải bài kiểm thử. Mỗi khi có một báo cáo lỗi, hãy thêm đầu vào gây ra lỗi đó dưới dạng một hàng mới với đầu ra mong đợi chính xác của nó. Lỗi trở thành một trường hợp hồi quy vĩnh viễn và bạn không bao giờ viết một bài kiểm thử mới, bạn chỉ thêm một dòng vào một tệp. Sau vài tháng, tệp sẽ tích lũy những sự phức tạp trong thế giới thực mà điểm cuối của bạn thực sự phải đối mặt.
Cuối cùng, tự động hóa nó. Đặt lệnh apidog run -d vào CI để toàn bộ bảng chạy trên mọi pull request. Giờ đây, một thay đổi làm hỏng đường dẫn mã hết hạn sẽ làm lỗi bản dựng ngay khi nó được đẩy, với một lần lặp được đặt tên chỉ thẳng vào hàng bị lỗi.
Lợi ích cộng dồn là việc bảo trì. Khi hình dạng phản hồi của điểm cuối thay đổi, bạn sửa khẳng định một lần và mọi trường hợp đều nhận được bản sửa lỗi. Khi bạn cần năm mươi trường hợp nữa, bạn thêm năm mươi hàng. Logic kiểm thử vẫn là một thứ nhỏ gọn, dễ đọc, bất kể phạm vi phủ sóng của bạn rộng đến đâu.
Các câu hỏi thường gặp
Sự khác biệt giữa kiểm thử tham số hóa và kiểm thử hướng dữ liệu là gì? Chúng mô tả cùng một ý tưởng và mọi người sử dụng các thuật ngữ này thay thế cho nhau. Cả hai đều có nghĩa là chạy một bài kiểm thử nhiều lần với các đầu vào và đầu ra mong đợi khác nhau được cung cấp từ bên ngoài bài kiểm thử. "Tham số hóa" tập trung vào cơ chế liên kết tham số; "hướng dữ liệu" tập trung vào nguồn dữ liệu bên ngoài. Trên thực tế, hãy coi chúng là từ đồng nghĩa.
Tôi nên sử dụng CSV hay JSON cho tệp dữ liệu của mình? Phù hợp định dạng với hình dạng dữ liệu của bạn. Các trường hợp dạng bảng, phẳng, nơi mỗi hàng có cùng các cột đơn giản, phù hợp với CSV, và CSV dễ dàng hơn cho những người không phải kỹ sư chỉnh sửa trong bảng tính. Các payload lồng nhau hoặc có cấu trúc, như phần thân yêu cầu có mảng và đối tượng con, phù hợp với JSON. Apidog đọc cả hai dưới dạng dữ liệu lặp, vì vậy hãy chọn bất kỳ định dạng nào đại diện cho các trường hợp của bạn mà không bị bóp méo.
Hàng trăm lần lặp có làm chậm pipeline của tôi không? Mỗi hàng là một lần chạy kịch bản, vì vậy tổng thời gian tỷ lệ thuận với số lượng hàng nhân với độ trễ mỗi yêu cầu. Đối với hầu hết các bài kiểm thử API, đó là vài giây, không phải vài phút. Nếu một tập dữ liệu lớn làm kéo dài quá trình xây dựng của bạn, hãy chia nó ra: chạy một tập hợp con kiểm thử nhanh (smoke subset) trên mỗi pull request và toàn bộ bảng trên một công việc hàng đêm hoặc trước khi phát hành. Cùng một kịch bản và tệp cung cấp cả hai; chỉ có tập con dữ liệu thay đổi.
Làm cách nào để giữ bí mật khỏi các tệp dữ liệu và cấu hình kiểm thử của tôi? Hoàn toàn giữ thông tin đăng nhập khỏi tệp dữ liệu. Token và mật khẩu thuộc về biến môi trường hoặc kho bí mật của hệ thống CI của bạn, được tham chiếu dưới dạng $APIDOG_ACCESS_TOKEN và những thứ tương tự. Tệp dữ liệu chỉ nên chứa đầu vào kiểm thử và kết quả mong đợi, không phải thông tin xác thực. Bất kỳ ai có thể đọc kho lưu trữ đều có thể đọc CSV, vì vậy hãy xử lý nó theo cách đó.
Tôi có thể chạy cùng một kịch bản tham số hóa trên môi trường staging và production không? Có. Giữ kịch bản và tệp dữ liệu cố định, và chuyển đổi môi trường bằng cờ -e. Trỏ một kiểm tra pull request đến staging và một kiểm thử nhanh sau khi triển khai đến production bằng cách sử dụng cùng ID kịch bản và cùng dữ liệu, chỉ khác ID môi trường. Đó là toàn bộ lý do môi trường và dữ liệu là các đầu vào riêng biệt.
Tổng kết
Kiểm thử API tham số hóa biến việc bao phủ từ một công việc sao chép-dán nhàm chán thành một nhiệm vụ nhập dữ liệu. Bạn viết bài kiểm thử một lần, mô tả mỗi trường hợp dưới dạng một hàng trong tệp CSV hoặc JSON và để trình chạy làm phần còn lại. Logic vẫn nhỏ gọn và dễ đọc, các trường hợp vẫn mở cho bất kỳ ai trong nhóm, và CI chạy toàn bộ bảng trên mọi thay đổi.
Apidog cung cấp cho bạn trình xây dựng kịch bản trực quan để tạo, các tệp CSV và JSON bên ngoài cho dữ liệu, và lệnh apidog run -d để thực thi không đầu trong bất kỳ hệ thống CI nào. Xây dựng một kịch bản, chỉ định nó vào một bảng các trường hợp đang phát triển, và phạm vi kiểm thử của bạn sẽ mở rộng mỗi khi ai đó thêm một hàng. Tải xuống Apidog và biến bài kiểm thử một lần không ổn định tiếp theo của bạn thành một kịch bản tham số hóa có thể mở rộng.
nút