Apidog CLI vs Newman: Chạy kiểm thử API trong CI (2026)

Các bài kiểm tra API của bạn chạy thành công trên máy tính xách tay. Câu hỏi khó hơn là liệu chúng có chạy trên mọi yêu cầu kéo, mọi lần hợp nhất và mọi bản dựng hàng đêm mà không cần con người nhấp chuột vào bất cứ thứ gì hay không. Công việc đó thuộc về một trình chạy dòng lệnh. Nó lấy các bài kiểm tra mà bạn đã viết, thực thi chúng ở chế độ 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à ghi một báo cáo mà bảng điều khiển của bạn có thể phân tích. Không GUI, không bước thủ công, không có lý do để bỏ qua việc chạy.

Trong nhiều năm, câu trả lời mặc định cho nhu cầu đó là Newman, trình chạy bộ sưu tập dòng lệnh mã nguồn mở của Postman. Đây là một công cụ vững chắc, được hiểu rõ và nhiều nhóm vẫn chọn nó đầu tiên. Nhưng nếu bạn tạo các bài kiểm tra của mình trong Apidog thay vì Postman, bạn có một lựa chọn thứ hai: Apidog CLI, chạy các kịch bản kiểm tra tương tự mà bạn xây dựng bằng giao diện trong ứng dụng, ở chế độ không giao diện trong CI. Bài viết này là một so sánh chân thực, ở cấp độ lệnh, giữa hai công cụ này. Nó bao gồm những gì Newman làm tốt, nơi Apidog CLI phù hợp và cảm nhận về từng công cụ khi được tích hợp vào một pipeline thực tế.

button

TL;DR

Newman (newman, cài đặt qua npm install -g newman) chạy một tệp JSON bộ sưu tập Postman đã xuất. Nó là mã nguồn mở, miễn phí và đọc một bộ sưu tập cùng một tệp môi trường từ đĩa hoặc URL. Nó hỗ trợ môi trường, tệp dữ liệu, số lần lặp và các trình báo cáo JUnit/JSON/HTML, và nó thoát với mã không bằng 0 khi một bài kiểm tra thất bại.
Apidog CLI (apidog-cli, nhị phân apidog) chạy các kịch bản kiểm tra mà bạn thiết kế trong ứng dụng Apidog, được lấy theo ID bằng mã truy cập. Bạn không xuất bất kỳ thứ gì hoặc duy trì một tệp JSON bằng tay; kịch bản trực quan chính là bài kiểm tra, và CLI chạy nó chính xác như cách ứng dụng sẽ làm.
Cả hai đều có thể cắm vào GitHub Actions, GitLab CI, Jenkins và bất kỳ hệ thống nào có Node.js. Cả hai đều làm hỏng bản dựng nếu có bài kiểm tra thất bại. JUnit XML là thứ kết nối vào các bảng điều khiển CI ở cả hai phía.
Chọn Newman khi các bài kiểm tra của bạn đã tồn tại dưới dạng bộ sưu tập Postman và bạn muốn một trình chạy miễn phí, thân thiện với kho lưu trữ mà không cần tài khoản mới.
Chọn Apidog CLI khi bạn muốn tạo tác trực quan, xích nối yêu cầu (request chaining), quản lý môi trường và các lần chạy theo dữ liệu mà vẫn đồng bộ với cùng một kịch bản mà nhóm của bạn gỡ lỗi hàng ngày.

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

Một bài kiểm tra mà bạn chạy thủ công là một bài kiểm tra bị mục ruỗng. Ai đó đã xây dựng nó, nó đã qua một lần, và sau đó nó nằm yên không đụng đến trong khi API thay đổi bên dưới. Thêm bài kiểm tra không giải quyết được vấn đề đó. Các bài kiểm tra tự động chạy trên mọi thay đổi thì có, bởi vì chúng tạo ra tín hiệu đạt hoặc thất bại mà pipeline của bạn có thể hành động.

Một trình chạy CLI lấp đầy khoảng trống đó. Để hữu ích trong CI, nó phải làm ba việc: chạy mà không có GUI, thoát với mã không bằng 0 khi có điều gì đó thất bại để bản dựng chuyển sang màu đỏ, và viết một báo cáo có thể đọc được bằng máy để người đánh giá có thể xem điều gì đã hỏng. Newman và Apidog CLI đều vượt qua tiêu chuẩn đó một cách sạch sẽ. Điểm khác biệt của chúng nằm ở phía trước lệnh chạy, trong cách bài kiểm tra được viết và nơi nó tồn tại. Nếu bạn đang thiết lập CI từ đầu, các mẫu rộng hơn trong cách tự động hóa các bài kiểm tra API trong CI/CD sẽ phù hợp với so sánh này. Ở đây chúng ta tập trung vào hai trình chạy.

Newman làm tốt những gì

Newman đã giành được vị trí của mình. Nó là công cụ đồng hành mã nguồn mở chính thức của Postman, và đối với các nhóm có bài kiểm tra đã tồn tại dưới dạng bộ sưu tập Postman, đây là con đường trực tiếp nhất từ “các bài kiểm tra trên máy của tôi” đến “các bài kiểm tra trong CI.” Điều đáng nói là những điểm mạnh của nó một cách rõ ràng trước khi so sánh.

Nó miễn phí và mã nguồn mở. Bạn cài đặt nó từ npm và chạy nó ở bất cứ nơi nào Node.js chạy, không cần giấy phép riêng cho trình chạy. Bộ sưu tập của bạn là một tệp JSON di động mà bạn có thể commit vào một kho lưu trữ, lưu trữ dưới dạng một artifact xây dựng hoặc lấy từ một URL. Khả năng di động đó là có thật, và nó có nghĩa là Newman có thể dễ dàng tích hợp vào hầu hết mọi pipeline.

Nó tái sử dụng những gì bạn đã xây dựng. Nếu nhóm của bạn viết các yêu cầu, tập lệnh tiền yêu cầu và các xác nhận kiểm tra trong Postman, Newman sẽ chạy chính những bộ sưu tập đó mà không cần thay đổi. Không cần viết lại. Các tập lệnh bạn đã viết trong trình soạn thảo Postman thực thi theo cùng một cách trong lần chạy không giao diện, điều này giúp giảm đường cong học tập cho các cửa hàng Postman.

Cài đặt nó chỉ cần một lệnh:

npm install -g newman

Nhị phân là newman. Bạn chạy một bộ sưu tập đã xuất bằng cách trỏ nó đến tệp JSON, thường với một tệp môi trường đi kèm:

newman run api-tests.postman_collection.json -e staging.postman_environment.json

Đó là vòng lặp cốt lõi. Xuất bộ sưu tập từ Postman, commit tệp JSON và chạy nó. Newman đọc các yêu cầu và xác nhận từ tệp và thực thi chúng theo thứ tự. Để biết đường dẫn thiết lập đầy đủ, hướng dẫn của Apidog về cách cài đặt Newman và chạy các bộ sưu tập Postman bao gồm quy trình xuất và chạy từng bước.

Newman cũng hỗ trợ các yếu tố cần thiết của CI mà bạn mong đợi. Các lần chạy theo dữ liệu đến từ một tệp CSV hoặc JSON:

newman run api-tests.postman_collection.json \
  -e staging.postman_environment.json \
  -d users.csv \
  -n 5

Ở đây -d cung cấp tệp dữ liệu và -n đặt số lần lặp, vì vậy bộ sưu tập chạy một lần cho mỗi hàng hoặc một số lần cố định. Đây là những nguyên thủy mà bất kỳ trình chạy nghiêm túc nào cũng cần, và Newman đã có chúng trong nhiều năm.

Newman bắt đầu khiến bạn phải trả giá ở đâu

Những điểm mạnh trên là chân thực, nhưng những đánh đổi cũng vậy, và chúng xuất hiện trong việc bảo trì hàng ngày hơn là trong bất kỳ lệnh đơn lẻ nào.

Điểm lớn nhất là bước xuất. Một bộ sưu tập Postman trong CI là một bản sao chụp nhanh. Bạn tạo và gỡ lỗi trong ứng dụng Postman, sau đó xuất một tệp JSON để chạy không giao diện. Ngay khi ai đó chỉnh sửa một yêu cầu trong ứng dụng và quên xuất lại, bộ sưu tập đã commit của bạn sẽ lệch khỏi nguồn thông tin đáng tin cậy. Lần chạy CI vẫn tiếp tục thành công dựa trên một định nghĩa cũ trong khi API thực tế đã thay đổi. Không có công cụ nào buộc cả hai phải đồng bộ lại; điều đó tùy thuộc vào người nhớ xuất.

Kịch bản là một điểm khác. Logic kiểm tra của Postman nằm trong các đoạn mã JavaScript đính kèm vào mỗi yêu cầu, và các tập lệnh đó là nơi diễn ra việc xích nối, trích xuất biến và xác nhận. Điều đó linh hoạt, nhưng nó có nghĩa là bộ kiểm tra của bạn là một đống các tập lệnh nhỏ để viết, gỡ lỗi và bảo trì bằng tay. Khi các kịch bản phát triển, thì bề mặt tập lệnh bạn sở hữu cũng vậy. Đây là một phần của một mẫu rộng hơn mà các nhóm gặp phải khi các bộ sưu tập mở rộng quy mô, điều mà chúng tôi đã đi sâu vào trong các hạn chế của Postman Collection Runner và cách khắc phục.

Không điều nào trong số này khiến Newman trở thành một công cụ tồi. Nó khiến nó trở thành một trình chạy có tính tiện dụng gắn liền với mô hình tác giả của Postman: tập lệnh cộng với bước xuất. Nếu mô hình đó phù hợp với nhóm của bạn, Newman vẫn ổn. Nếu việc xuất và đồng bộ hóa là phần liên tục gặp sự cố, đó chính xác là nơi một trình chạy khác sẽ giúp ích.

Apidog CLI làm gì khác biệt

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

Điều đó loại bỏ vấn đề lệch lạc. Kịch bản trong dự án chính là bài kiểm tra. Không có bản sao chụp nhanh đã xuất nào bị mất đồng bộ, bởi vì CLI chạy kịch bản trực tiếp, không phải bản sao của nó. Bạn tạo nó một lần trong một trình xây dựng trực quan xử lý việc xích nối yêu cầu và xác nhận cho bạn, sau đó cùng một kịch bản chạy trong CI. Vòng lặp tạo tác nhanh và vòng lặp tự động hóa chia sẻ một nguồn thông tin đáng tin cậy.

Cài đặt chỉ cần một lệnh npm:

npm install -g apidog-cli

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

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

Bạn không nhập các ID đó bằng tay. Mở kịch bản kiểm tra trong Apidog, chuyển đến tab CI/CD của nó, tạo một mã truy cập, và Apidog sẽ xây dựng lệnh đầy đủ cho bạn với ID kịch bản và ID môi trường đã được điền sẵn. Bạn sao chép nó một lần, sau đó chuyển mã thông báo vào một bí mật CI và tham chiếu nó dưới dạng $APIDOG_ACCESS_TOKEN. Nếu bạn không chắc phiên bản đã cài đặt của mình hỗ trợ những cờ nào, hãy chạy apidog run --help và nó sẽ in ra các tùy chọn chính xác có sẵn.

Mô hình dựa trên mã thông báo, lấy theo ID là sự khác biệt rõ ràng nhất so với Newman. Newman đọc một tệp bộ sưu tập từ đĩa; Apidog CLI truy cập vào một dự án qua mạng, được xác thực và chạy kịch bản được lưu trữ ở đó. Không cái nào sai. Chúng phù hợp với các thiết lập nhóm khác nhau, và lựa chọn chủ yếu là liệu bạn muốn bài kiểm tra tồn tại dưới dạng một tệp đã xuất hay dưới dạng một kịch bản trực tiếp trong một không gian làm việc chia sẻ.

So sánh cạnh nhau

Khía cạnh	Newman (`newman`)	Apidog CLI (`apidog`)
Gói	`newman`	`apidog-cli`
Lệnh chạy	`newman run <collection.json>`	`apidog run`
Nguồn kiểm tra	Tệp JSON bộ sưu tập Postman đã xuất (tệp hoặc URL)	Các kịch bản kiểm tra trong dự án Apidog của bạn, được lấy theo ID
Tạo tác	Ứng dụng Postman, các tập lệnh kiểm tra JavaScript	Trình xây dựng kịch bản trực quan, xác nhận không cần mã
Mô hình đồng bộ	Xuất một bản sao chụp nhanh JSON; xuất lại khi thay đổi	Kịch bản trực tiếp được lấy khi chạy; không cần xuất
Xác thực trong CI	Không có cho tệp; khóa API Postman nếu lấy từ đám mây	Mã truy cập (`--access-token`)
Môi trường	`-e <environment.json>`	`-e <environmentId>`
Chạy theo dữ liệu	`-d <file.csv hoặc .json>`	`-d <path>` (CSV hoặc JSON)
Số lần lặp	`-n <count>`	`-n <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 ở lỗi đầu tiên)
Mã nguồn mở	Có	Không (CLI npm miễn phí; chạy các kịch bản từ gói của bạn)
Tài khoản	Tài khoản Postman cho các bộ sưu tập trên đám mây	Tài khoản Apidog cho dự án

Có hai điều nổi bật. Thứ nhất, cả hai trình chạy đều bao gồm các yếu tố cần thiết của CI: lựa chọn môi trường, lặp lại theo dữ liệu, các định dạng báo cáo quan trọng và thoát không bằng 0 khi thất bại. Tên cờ thậm chí còn đủ gần để bộ nhớ cơ bắp có thể chuyển đổi (-e, -d, -n, -r). Thứ hai, sự khác biệt thực sự không phải là khả năng thô. Đó là nơi bài kiểm tra tồn tại và cách bạn viết nó. Newman chạy một bộ sưu tập đã xuất được tạo bằng tập lệnh. Apidog chạy một kịch bản trực quan trực tiếp bằng tham chiếu. Phiên bản sâu hơn của so sánh này, được đóng khung xung quanh hai trình chạy trong thế giới Postman, có trong Postman CLI vs Newman nếu bạn cũng muốn góc nhìn đó.

Trình báo cáo và mã thoát: các phần mà CI thực sự đọc

Một trình chạy giành được vị trí trong một pipeline thông qua hai hành vi: báo cáo nó viết và mã thoát nó trả về. Làm đúng những điều này thì phần còn lại chỉ là việc kết nối.

Newman chọn các trình báo cáo bằng cờ -r và một danh sách được phân tách bằng dấu phẩy. JUnit và JSON có sẵn; trình báo cáo HTML là tiện ích bổ sung phổ biến nhất:

newman run api-tests.postman_collection.json \
  -e staging.postman_environment.json \
  -r cli,junit \
  --reporter-junit-export ./results/junit.xml

JUnit XML là thứ mà bảng điều khiển CI của bạn phân tích thành một cây đạt hoặc thất bại. Cờ --bail của Newman dừng quá trình chạy sau lỗi đầu tiên, giúp phản hồi nhanh chóng trong một bài kiểm tra sơ bộ. Nếu không có nó, quá trình chạy sẽ hoàn thành và báo cáo mọi lỗi cùng một lúc.

Apidog CLI sử dụng cùng cờ -r được phân tách bằng dấu phẩy và ghi mọi thứ vào một thư mục đầu ra:

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 đầ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. Dù bằng cách nào, quá trình chạy sẽ kết thúc với mã không bằng 0 nếu có bất kỳ điều gì thất bại.

Hợp đồng mã thoát là như nhau ở cả hai phía, và nó là phần chịu tải. Khi một xác nhận thất bại, trình chạy thoát với mã không bằng 0. CI đọc mã đó, đánh dấu bước thất bại, làm hỏng công việc và chặn việc hợp nhất hoặc triển khai. Bạn không cần cấu hình thêm bất cứ điều gì. Cạm bẫy duy nhất, giống hệt nhau cho cả hai, là nuốt mã thoát: bọc quá trình chạy trong một pipeline shell hoặc thêm || true và mã thoát không bằng 0 sẽ bị bỏ qua, do đó cổng sẽ ngừng hoạt động một cách im lặng. Đừng làm điều đó. Để biết ngữ cảnh rộng hơn về các định dạng báo cáo, kiểm thử API theo dữ liệu với CSV hoặc JSON cho thấy báo cáo liên kết trở lại dữ liệu lặp như thế nào.

Newman trong GitHub Actions

Vì bộ sưu tập là một tệp đã xuất trong kho lưu trữ, quy trình làm việc rất ngắn gọn. Kiểm tra mã, cài đặt Newman, chạy bộ sưu tập, tải lên báo cáo ngay cả khi thất bại.

name: API tests

on:
  pull_request:
    branches: [main]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Newman
        run: npm install -g newman

      - name: Run API tests
        run: |
          newman run ./tests/api-tests.postman_collection.json \
            -e ./tests/staging.postman_environment.json \
            -r cli,junit \
            --reporter-junit-export ./results/junit.xml

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: newman-report
          path: ./results

Không cần bí mật nếu các tệp bộ sưu tập và môi trường được commit vào kho lưu trữ. Dòng if: always() giữ cho việc tải lên báo cáo chạy ngay cả khi các bài kiểm tra thất bại, đó chính là lúc bạn muốn đọc nó. Chi phí bạn phải chịu là bước xuất đã tạo ra các tệp JSON đó ngay từ đầu, và việc nhớ làm mới chúng khi API thay đổi.

Apidog CLI trong GitHub Actions

Quy trình làm việc của Apidog có hình dạng tương tự, với một thay đổi: mã truy cập đến từ các bí mật của kho lưu trữ, và bạn chọn kịch bản theo ID thay vì trỏ đến một tệp.

name: API tests

on:
  pull_request:
    branches: [main]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run API test scenario
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1629989 \
            -r html,junit \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-report
          path: ./apidog-reports

Hãy chú ý sự đối xứng. Cùng bước checkout, cùng thiết lập Node, cùng hình dạng cài đặt rồi chạy, cùng luôn tải lên. Sự khác biệt thực sự duy nhất là mã thông báo được kết nối như một bí mật và kịch bản được chọn theo ID chứ không phải theo đường dẫn tệp. Bởi vì kịch bản được lấy trực tiếp, không có tệp JSON nào để giữ cập nhật. Đối với cùng một mẫu trong các hệ thống khác, cách tự động hóa các bài kiểm thử API trong GitHub Actions mang cấu trúc qua GitLab CI và Jenkins.

Cách lựa chọn

Quyết định hiếm khi phụ thuộc vào việc trình chạy nào khách quan tốt hơn. Nó phụ thuộc vào nơi các bài kiểm thử của bạn đã tồn tại và cách nhóm của bạn muốn duy trì chúng.

Chọn Newman khi các bài kiểm thử của bạn đã là các bộ sưu tập Postman. Nếu bộ công cụ của bạn tồn tại trong Postman, nhóm của bạn viết các tập lệnh kiểm thử trong trình chỉnh sửa và bạn muốn một trình chạy mã nguồn mở, miễn phí có thể tích hợp vào bất kỳ pipeline nào mà không cần tài khoản mới, Newman là lựa chọn phù hợp trực tiếp. Đây là lựa chọn tự nhiên cho các cửa hàng Postman cảm thấy thoải mái khi xuất một bộ sưu tập và commit tệp JSON, và không ngại tự mình quản lý các tập lệnh kiểm thử. Bạn có thể đọc thêm về sự khác biệt trong hệ sinh thái Postman trong sự khác biệt giữa Newman và Postman.

Chọn Apidog CLI khi tốc độ tạo tác và một nguồn thông tin duy nhất quan trọng hơn việc duy trì trong Postman. Nếu bạn muốn xây dựng một kịch bản kiểm thử trực quan, xích nối các yêu cầu, trích xuất biến và chạy cùng một kịch bản trên các môi trường mà không cần viết và xuất lại mã kiểm thử, Apidog sẽ loại bỏ sự cản trở đó. Thiết kế, gỡ lỗi, mô phỏng và kiểm thử đều diễn ra trong một không gian làm việc, và CLI chạy chính xác kịch bản bạn đã xây dựng. Đối với các nhóm chuyển từ Postman, việc di chuyển là một điều mà Apidog cung cấp như một giải pháp thay thế Postman cho kiểm thử API, và việc nhập chỉ cần một cú nhấp chuột.

Cũng có một câu trả lời cho cả hai công cụ. Một số nhóm duy trì bước Newman hiện có chạy các bộ sưu tập cũ của họ trong khi họ chuyển các kịch bản mới, phức tạp hơn, được xích nối vào Apidog. Hai CLI này cùng tồn tại tốt trong một pipeline; chúng là các bước riêng biệt với các mã thoát riêng biệt, và bạn có thể loại bỏ bước Newman theo thời gian của riêng mình.

Để thiết lập kịch bản tự động đầu tiên của bạn và chạy nó từ terminal ngay trong buổi chiều, hãy tải xuống Apidog, xây dựng một kịch bản kiểm thử và sao chép lệnh đã tạo từ tab CI/CD của nó.

button