Apidog CLI vs Postman CLI: Trình chạy kiểm thử CI nào tốt hơn

Các bài kiểm thử API của bạn vượt qua khi bạn nhấp Chạy trên máy tính xách tay của mình. Điều đó không chứng minh được gì. Bài kiểm thử quan trọng là bài được kích hoạt trên mỗi pull request, mỗi lần merge và mỗi bản dựng hàng đêm, mà không cần con người nhấp vào bất cứ thứ gì. Công việc đưa các bài kiểm thử của bạn vào vòng lặp đó thuộc về một công cụ chạy dòng lệnh (CLI runner). Nó lấy các bài kiểm thử bạn đã viết, chạy chúng không giao diện (headless) bên trong pipeline của bạn, thoát với mã trạng thái mà CI của bạn có thể đọc và viết một báo cáo hiển thị trên bảng điều khiển xây dựng.

Hai công cụ chạy được nhắc đến nhiều lần khi các nhóm thiết lập điều này là: Postman CLI và Apidog CLI. Chúng hướng tới cùng một mục tiêu nhưng từ những điểm khởi đầu khác nhau. Postman CLI chạy các collection bạn xây dựng trong Postman. Apidog CLI chạy các kịch bản kiểm thử trực quan bạn xây dựng trong Apidog. Cả hai đều cài đặt chỉ trong một bước, đều tích hợp vào GitHub Actions, GitLab CI và Jenkins, và đều làm cho bản dựng thất bại (đổi màu đỏ) khi một bài kiểm thử không thành công. Sự khác biệt thực sự nằm ở phía trước lệnh chạy: cách bạn viết bài kiểm thử, cách bạn xác thực trong CI và nơi định nghĩa bài kiểm thử thực sự tồn tại.

💡

Đây là một so sánh cấp độ lệnh giữa hai công cụ này. Không hề cường điệu. Postman CLI thực hiện tốt nhiều việc, và bạn sẽ thấy chính xác công cụ chạy nào phù hợp trước khi đưa nó vào pipeline của mình. Nếu bạn mới sử dụng Apidog, đây là một nền tảng API tất cả trong một bao gồm thiết kế, gỡ lỗi, kiểm thử, mocking và tài liệu trong một không gian làm việc duy nhất, và CLI là phần đưa các bài kiểm thử của bạn vào tự động hóa.

Tải ứng dụng

Tóm tắt

Postman CLI (tệp nhị phân postman) chạy các collection được lưu trữ trong không gian làm việc Postman của bạn. Nó dựa trên Newman, được Postman ký và hỗ trợ, đồng thời xác thực bằng khóa API của Postman. Khi bạn đăng nhập, nó sẽ tự động gửi kết quả chạy trở lại đám mây Postman.
Apidog CLI (`apidog-cli`, tệp nhị phân apidog) chạy các kịch bản kiểm thử bạn thiết kế trực quan trong Apidog. Bạn chỉ định nó đến một kịch bản bằng ID với một mã thông báo truy cập, và nó thực thi kịch bản đó không giao diện (headless) mà không cần GUI.
Cả hai đều xuất báo cáo định dạng JUnit, JSON, HTML và terminal. Cả hai đều làm thất bại bản dựng nếu một bài kiểm thử không thành công. JUnit XML là thứ được tích hợp vào bảng điều khiển CI trong cả hai trường hợp.
Chọn **Postman CLI** khi các bài kiểm thử của bạn đã có sẵn trong các collection của Postman và nhóm của bạn đã cam kết sử dụng đám mây Postman cho việc báo cáo và lịch sử.
Chọn **Apidog CLI** khi bạn muốn tạo kịch bản trực quan, chuỗi yêu cầu, quản lý môi trường và các lần chạy dựa trên dữ liệu từ một nguồn đáng tin cậy duy nhất, với toàn quyền kiểm soát việc báo cáo có ở cục bộ hay chuyển lên đám mây.

Vấn đề thực sự: các bài kiểm thử tồn tại nhưng không bao giờ được chạy

Một bài kiểm thử bạn chạy thủ công là một bài kiểm thử sẽ lỗi thời. Ai đó đã viết nó, nó vượt qua một lần, và sau đó nó nằm yên không được chạm đến trong khi API thay đổi. Ba tháng sau, bài kiểm thử đó sai và không ai nhận ra, vì không ai chạy nó. Giải pháp không phải là viết thêm bài kiểm thử. Mà là làm cho các bài kiểm thử bạn có chạy tự động trên mỗi thay đổi, với tín hiệu pass hoặc fail mà pipeline có thể hành động.

Một công cụ chạy CLI là công cụ thu hẹp khoảng cách đó. Để có được một vị trí trong CI, nó phải thực hiện ba điều. Nó phải chạy mà không có GUI, vì công cụ chạy CI của bạn không có màn hình. Nó phải thoát với mã không phải số 0 khi có lỗi, để bản dựng chuyển sang màu đỏ và một merge bị lỗi bị chặn. Và nó phải viết một báo cáo có thể đọc được bằng máy, để người đánh giá thấy những gì đã hỏng mà không cần chạy lại bất cứ thứ gì cục bộ. Postman CLI và Apidog CLI đều đáp ứng được tiêu chí đó một cách rõ ràng. Điểm khác biệt giữa chúng nằm ở mọi thứ xảy ra trước lệnh run: bài kiểm thử được viết như thế nào, và nó nằm ở đâu khi CI tìm kiếm nó.

Nếu bạn đang thiết lập kiểm thử tự động từ đầu, các mẫu rộng hơn trong việc tự động hóa kiểm thử API trong CI/CD đáng để đọc cùng với bài viết này. Ở đây, trọng tâm vẫn là hai công cụ chạy.

Postman CLI làm tốt những gì

Đầu tiên, một điểm cần làm rõ mà nhiều người thường nhầm lẫn: Postman CLI không phải là Newman. Newman là công cụ chạy mã nguồn mở, dựa trên npm đã cũ hơn mà cộng đồng đã sử dụng trong nhiều năm. Postman CLI là một công cụ mới hơn, được xây dựng trên nền tảng của Newman, nhưng được công ty Postman ký và hỗ trợ chính thức. Nếu bạn đã và đang chạy Newman, hai công cụ này không thể thay thế cho nhau, và sự khác biệt này rất quan trọng trong CI. Chúng tôi đã viết rõ sự phân biệt chính xác đó trong bài Postman CLI vs Newman nếu bạn đang phân vân giữa hai lựa chọn phía Postman.

Điểm mạnh lớn nhất của Postman CLI là nó vẫn nằm trong thế giới mà nhóm của bạn đã quen thuộc. Nếu các collection, môi trường và biến dùng chung của bạn đã tồn tại trong không gian làm việc Postman, CLI sẽ chạy chúng mà hầu như không cần chuyển đổi. Bạn không cần xây dựng lại bất cứ thứ gì. Bạn chỉ cần xác thực, đặt tên collection, và nó sẽ chạy các yêu cầu và bài kiểm thử chính xác như ứng dụng Postman.

Cài đặt nó chỉ bằng một lệnh duy nhất. Trên macOS và Linux, bạn chạy script cài đặt chính thức:

curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh

Trên Windows, bạn sử dụng trình cài đặt PowerShell được ký, và cũng có một gói npm nếu bạn muốn ghim nó làm dependency phát triển:npm install -g postman-cli

Tệp nhị phân là postman. Trong CI, bạn xác thực bằng khóa API của Postman, đây là phương pháp Postman khuyên dùng cho các pipeline:

postman login --with-api-key $POSTMAN_API_KEY

Sau đó, bạn chạy một collection bằng ID của nó, hoặc bằng đường dẫn tệp cục bộ nếu bạn đã xuất nó:

postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID

Phần khiến Postman CLI được nhiều người tin dùng là những gì xảy ra sau khi chạy. Khi bạn đăng nhập, nó sẽ gửi thẳng kết quả chạy lên đám mây Postman, nơi chúng hiển thị trong không gian làm việc của bạn cùng với collection. Lịch sử kiểm thử, so sánh các lần chạy và bảng điều khiển hiển thị cho nhóm đều có sẵn mà không cần thêm cấu hình phức tạp nào. Đối với một nhóm đã quen thuộc với Postman, chuyến đi khứ hồi đó thực sự hữu ích, và đó là một lý do hợp lý để gắn bó.

Apidog CLI làm tốt những gì

Apidog đi một con đường khác để đạt được cùng một pipeline. Bạn xây dựng các bài kiểm thử trực quan trong ứng dụng Apidog: chuỗi nhiều yêu cầu thành một kịch bản kiểm thử duy nhất, thêm các xác nhận vào mỗi phản hồi, lấy một giá trị từ phản hồi này và đưa vào yêu cầu tiếp theo, và lặp lại toàn bộ kịch bản trên một tệp dữ liệu. CLI là công cụ thực thi không giao diện (headless) cho các kịch bản đó. Nó không có định dạng kiểm thử riêng. Nó truy cập vào dự án Apidog của bạn, tìm kịch bản bạn đặt tên bằng ID, và chạy nó chính xác như ứng dụng Apidog sẽ làm, sau đó báo cáo kết quả.

Lợi ích là không ai phải duy trì hai bản sao của cùng một bài kiểm thử. Kịch bản bạn xây dựng trong trình chỉnh sửa trực quan chính là bài kiểm thử chạy trong CI. Không có bước nào bạn phải viết lại một bài kiểm thử đang hoạt động thành một script rồi gỡ lỗi script đó. Vòng lặp tạo nhanh và vòng lặp tự động hóa chia sẻ một nguồn thông tin duy nhất. Đối với các luồng nhiều bước, ví dụ đăng nhập sau đó tạo, sau đó đọc, sau đó xóa, việc chuỗi trực quan đó giúp tiết kiệm rất nhiều mã kết nối mà bạn sẽ phải tự viết tay. Cơ chế xây dựng các luồng đó được đề cập trong hướng dẫn về kịch bản kiểm thử cho tự động hóa kiểm thử API.

Cài đặt chỉ bằng một lệnh npm:

npm install -g apidog-cli

Tệp nhị phân là apidog. Một lần chạy điển hình sẽ đặt tên một kịch bản bằng ID, chọn một môi trường, đặt số lần lặp và xác thực bằng một mã thông báo truy cập:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit

Bạn không cần nhập các ID đó bằng tay. Mở kịch bản kiểm thử trong Apidog, chuyển sang tab CI/CD của nó, nhấp để tạo mã thông báo truy cập, và Apidog sẽ xây dựng toàn bộ lệnh cho bạn với ID kịch bản và ID môi trường đã được điền sẵn. Bạn chỉ cần sao chép nó một lần, di chuyển mã thông báo vào một biến bí mật CI, và tham chiếu nó dưới dạng `$APIDOG_ACCESS_TOKEN` trong workflow của bạn.

Mô hình mã thông báo và ID là điểm khác biệt rõ ràng nhất so với Postman CLI. Apidog chạy các bài kiểm thử được lưu trữ trong một dự án mà CLI lấy qua mạng, được xác thực bằng mã thông báo. Cũng không có tùy chọn riêng để báo cáo lên đám mây: bạn chọn `--out-dir` cho các tạo phẩm cục bộ và chỉ thêm `--upload-report` khi bạn muốn đẩy một tổng quan lên đám mây Apidog. Các báo cáo sẽ ở lại nơi bạn đặt chúng.

So sánh song song

Tiêu chí	Postman CLI (`postman`)	Apidog CLI (`apidog`)
Gói / cài đặt	Script cài đặt, trình cài đặt có chữ ký, hoặc `npm i -g postman-cli`	`npm i -g apidog-cli`
Lệnh chạy	`postman collection run <id\|file>`	`apidog run -t <scenarioId>`
Nguồn kiểm thử	Các collection trong không gian làm việc Postman của bạn (hoặc tệp đã xuất)	Các kịch bản kiểm thử trong dự án Apidog của bạn, được lấy bằng ID
Viết bài kiểm thử	Trình chỉnh sửa collection và ứng dụng Postman	Trình xây dựng kịch bản trực quan trong ứng dụng Apidog
Xác thực trong CI	Khóa API của Postman (`postman login --with-api-key`)	Mã thông báo truy cập (`--access-token`)
Chọn nội dung chạy	ID collection hoặc đường dẫn tệp	Kịch bản `-t`, thư mục `-f`, `--test-suite`
Môi trường	`-e, --environment`	`-e, --environment <environmentId>`
Dựa trên dữ liệu	`-d, --iteration-data` (JSON hoặc CSV)	`-d, --iteration-data` (JSON hoặc CSV)
Số lần lặp	`-n, --iteration-count`	`-n, --iteration-count`
Trình báo cáo	`cli`, `json`, `junit`, `html`	`cli`, `html`, `json`, `junit`
Dừng nhanh khi lỗi	`--bail`	`--on-error end` (mặc định dừng khi lỗi đầu tiên)
Báo cáo đám mây	Tự động gửi kết quả khi đã đăng nhập	Tùy chọn bật thông qua `--upload-report`
Dựa trên	Newman	Công cụ riêng của Apidog

Hai điều nổi bật từ bảng đó. Thứ nhất, cả hai công cụ chạy đều bao gồm các yếu tố cần thiết của CI gần như giống nhau: lựa chọn môi trường, lặp lại dựa trên dữ liệu, bốn định dạng báo cáo quan trọng và thoát với mã không phải số không khi có lỗi. Nếu tất cả những gì bạn cần là một công cụ chạy làm cho bản dựng thất bại khi một merge xấu, thì cả hai đều làm được. Thứ hai, sự khác biệt thực sự là về nơi bài kiểm thử tồn tại và cách bạn viết nó. Postman CLI chạy một collection tồn tại trong không gian làm việc Postman của bạn. Apidog CLI chạy một kịch bản trực quan tồn tại trong dự án Apidog của bạn.

Báo cáo viên và mã thoát: những phần CI thực sự đọc

Một công cụ chạy chứng minh giá trị của nó trong một pipeline thông qua hai hành vi: báo cáo nó viết ra và mã thoát nó trả về. Làm đúng hai điều này thì mọi thứ khác chỉ là kết nối.

Postman CLI chấp nhận một danh sách trình báo cáo được phân tách bằng dấu phẩy, và khi bạn đăng nhập, nó cũng gửi kết quả lên đám mây Postman:

postman collection run $POSTMAN_COLLECTION_ID \
  -e $POSTMAN_ENV_ID \
  --reporters cli,junit \
  --bail

Trình báo cáo junit là thứ mà bảng điều khiển CI của bạn phân tích thành cây pass hoặc fail. Cờ --bail dừng chạy ngay khi gặp yêu cầu, bài kiểm thử hoặc xác nhận đầu tiên không thành công, giúp phản hồi nhanh chóng trong một smoke test. Bỏ --bail và nó sẽ chạy tất cả mọi thứ, sau đó báo cáo tất cả các lỗi cùng một lúc. CLI thoát với mã không phải số không khi có bất kỳ lỗi nào, do đó bản dựng sẽ tự động chuyển sang màu đỏ.

Apidog CLI sử dụng cùng ý tưởng trình báo cáo -r và ghi mọi thứ vào một thư mục đầu ra duy nhất:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 \
  -r html,junit --out-dir ./apidog-reports

Cờ --on-error của nó định hình hành vi giữa kịch bản: end dừng lại ở lỗi đầu tiên và là mặc định, continue chạy mọi bước để bạn thu thập tất cả các lỗi trong một báo cáo, và ignore bỏ qua một bước được biết là không ổn định mà không làm chệch hướng quá trình chạy. Dù bằng cách nào, quá trình cũng sẽ kết thúc với mã không phải số không nếu có bất kỳ lỗi nào, và tệp JUnit XML sẽ nằm trong ./apidog-reports sẵn sàng cho bảng điều khiển của bạn lấy lên.

Kết quả thực tế: cả hai đều viết tệp JUnit XML, cả hai đều làm thất bại bản dựng một cách chính xác, và cả hai đều lưu trữ một báo cáo HTML mà bạn có thể mở sau này. Sự khác biệt trong báo cáo là chuyến đi khứ hồi lên đám mây. Postman đẩy kết quả lên đám mây của nó theo mặc định khi bạn được xác thực. Apidog giữ báo cáo cục bộ trừ khi bạn yêu cầu tải lên. Không có cái nào tốt hơn về mặt trừu tượng; một cái phù hợp với các nhóm muốn có lịch sử được lưu trữ mà không cần suy nghĩ, cái còn lại phù hợp với các nhóm muốn quyết định chính xác những gì rời khỏi công cụ chạy.

Kết nối từng công cụ vào GitHub Actions

Cấu trúc của một job GitHub Actions là giống nhau cho cả hai: checkout repo, thiết lập Node, cài đặt CLI, chạy các bài kiểm thử, và mã thoát lỗi sẽ chặn quá trình merge. Lưu bí mật trong cài đặt repository của bạn, không bao giờ trong tệp workflow.

Đây là phiên bản Postman CLI:

- name: Run API tests (Postman CLI)
  run: |
    curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh
    postman login --with-api-key ${{ secrets.POSTMAN_API_KEY }}
    postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID --reporters cli,junit --bail

Và phiên bản Apidog CLI:

- name: Run API tests (Apidog CLI)
  run: |
    npm install -g apidog-cli
    apidog run --access-token ${{ secrets.APIDOG_ACCESS_TOKEN }} -t 605067 -e 1629989 -r cli,junit

Cả hai đều ngắn gọn, dễ đọc, và cả hai đều hoạt động theo cùng một cách ở mức độ mà pipeline của bạn quan tâm: một lần chạy thành công thoát với mã không và quá trình merge tiếp tục, một lần chạy thất bại thoát với mã không phải không và quá trình merge bị chặn. Nếu bạn muốn tìm hiểu sâu hơn về cách chạy kiểm thử API trong một GitHub workflow, bài tự động hóa kiểm thử API với GitHub Actions sẽ hướng dẫn từng bước. Đối với người dùng Jenkins, ý tưởng tương tự được trình bày trong bài tích hợp kiểm thử tự động Apidog với Jenkins.

Vậy công cụ nào thắng trong CI?

Không có người thắng cuộc duy nhất, vì câu trả lời đúng phụ thuộc vào nơi các bài kiểm thử của bạn đang tồn tại và cách nhóm của bạn muốn tạo và lưu trữ chúng.

Apidog CLI thắng thế khi bạn coi trọng việc tạo trực quan và một nguồn thông tin duy nhất hơn là một lịch sử đám mây được lưu trữ. Bạn xây dựng một kịch bản một lần trong trình chỉnh sửa trực quan, với việc chuỗi yêu cầu và các xác nhận được xử lý cho bạn, và kịch bản đó sẽ chạy trong CI bằng cách tham chiếu. Bạn quyết định xem báo cáo có ở cục bộ hay được tải lên. Và vì Apidog bao gồm thiết kế, mocking và tài liệu trong cùng một không gian làm việc, kịch bản kiểm thử nằm cạnh hợp đồng API mà nó kiểm tra, giúp giữ cho các bài kiểm thử và thông số kỹ thuật không bị sai lệch. Các nhóm đang cân nhắc các nền tảng rộng hơn có thể đọc bài so sánh Apidog và Postman đầy đủ.

Postman CLI thắng thế khi nhóm của bạn đã sử dụng Postman. Các collection của bạn ở đó, môi trường của bạn ở đó, và bạn muốn lịch sử chạy trong đám mây Postman mà không cần thiết lập gì thêm. Chuyến đi khứ hồi lên đám mây trên mỗi lần chạy thực sự tiện lợi cho thiết lập đó, và công cụ này được ký và hỗ trợ chính thức. Nếu điều đó mô tả nhóm của bạn, việc chuyển đổi công cụ chạy sẽ không mang lại nhiều lợi ích.

Nếu bạn cảm thấy bị gò bó bởi mô hình đám mây của Postman, hoặc bạn chỉ muốn viết bài kiểm thử một lần và chạy chúng ở mọi nơi, thì hướng đi đã rõ ràng. Tải xuống Apidog, xây dựng một kịch bản, mở tab CI/CD của nó, và sao chép lệnh apidog run được tạo vào pipeline của bạn. Đó là toàn bộ thiết lập.

Tải ứng dụng

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

Postman CLI có giống Newman không? Không. Newman là công cụ chạy npm mã nguồn mở cũ hơn. Postman CLI là một công cụ mới hơn được xây dựng trên nền tảng của Newman, được Postman ký và hỗ trợ, với khả năng báo cáo tích hợp lên đám mây Postman. Nếu bạn đang chọn giữa hai công cụ này phía Postman, bài Postman CLI vs Newman sẽ phân tích sự khác biệt.

Tôi có cần tài khoản hoặc mã thông báo cho bất kỳ CLI nào trong CI không? Có, cho cả hai, nhưng hình thức khác nhau. Postman CLI xác thực bằng khóa API của Postman thông qua postman login --with-api-key. Apidog CLI xác thực bằng mã thông báo truy cập được truyền dưới dạng --access-token. Lưu trữ cả hai dưới dạng biến bí mật CI, không bao giờ trong tệp workflow.

Cả hai công cụ chạy có làm thất bại bản dựng khi một bài kiểm thử không thành công không? Có. Cả hai đều thoát với mã trạng thái không phải số không khi có bất kỳ bài kiểm thử hoặc xác nhận nào không thành công, đây là điều báo cho hệ thống CI của bạn đánh dấu bản dựng màu đỏ và chặn quá trình merge. Postman CLI sử dụng --bail để dừng lại ở lỗi đầu tiên; Apidog CLI sử dụng --on-error end, đây là mặc định của nó.

Tôi có thể giữ báo cáo cục bộ thay vì gửi chúng lên đám mây không? Apidog CLI giữ báo cáo cục bộ theo mặc định và ghi chúng vào --out-dir; bạn chỉ tải lên bằng --upload-report. Postman CLI cũng viết các báo cáo cục bộ, nhưng khi bạn đăng nhập, nó cũng tự động gửi kết quả chạy lên đám mây Postman.

Làm cách nào để lấy chính xác lệnh chạy Apidog cho kịch bản của tôi? Mở kịch bản kiểm thử trong Apidog, chuyển sang tab CI/CD của nó, tạo mã thông báo truy cập, và Apidog sẽ xây dựng toàn bộ lệnh apidog run với ID kịch bản và ID môi trường đã được điền sẵn. Sao chép nó, di chuyển mã thông báo vào một biến bí mật CI, và bạn đã hoàn tất. Để xem tất cả các cờ có sẵn, hãy chạy apidog run --help.

Nhóm nào đang chuyển từ đám mây Postman nên chọn cái nào? Nếu lý do bạn rời đi là mô hình tập trung vào đám mây hoặc giá cả, thì Apidog CLI phù hợp, vì nó chạy một kịch bản trực quan duy nhất từ dự án của bạn và cho phép bạn quyết định những gì rời khỏi công cụ chạy. Bắt đầu với bài so sánh Apidog và Postman để xem các nền tảng này khớp với nhau như thế nào ngoài công cụ chạy.