Blog

Hướng dẫn chạy kiểm thử API tự động trong Azure Pipelines (Từng bước)

Chạy thử nghiệm API tự động trong Azure Pipelines từng bước: thiết kế kịch bản trong Apidog, kích hoạt chúng bằng Apidog CLI và dừng bản dựng nếu có lỗi hồi quy.

Ashley Innocent

Ashley Innocent

15 tháng 6 2026

Hướng dẫn chạy kiểm thử API tự động trong Azure Pipelines (Từng bước)

Apidog cho doanh nghiệp

Triển khai tại chỗ

SSO & RBAC

Tuân thủ SOC 2

Khám phá Apidog Enterprise

API của bạn hoạt động trên máy tính xách tay của bạn. Nó vượt qua mọi kiểm tra trong máy khách thử nghiệm cục bộ của bạn. Sau đó một đồng đội hợp nhất một nhánh, triển khai được thực hiện, và một điểm cuối mà trước đây trả về 200 bắt đầu trả về 500 trong môi trường sản xuất. Không ai phát hiện ra, vì không ai chạy các bài kiểm tra trên nhánh đó. Họ đã chạy chúng trên một máy, một lần, thủ công.

Khoảng trống đó, giữa “các bài kiểm tra tồn tại” và “các bài kiểm tra chạy trên mọi thay đổi,” chính xác là những gì một pipeline CI đóng lại. Nếu mã của bạn đã có trong Azure Repos hoặc GitHub và nhóm của bạn xây dựng trên Azure DevOps, Azure Pipelines là nơi tự nhiên để đặt lưới an toàn đó. Phần khó hiếm khi là YAML. Đó là việc đưa bộ kiểm thử API của bạn vào một dạng mà pipeline có thể chạy không đầu, với môi trường phù hợp, chống lại một bản dựng mới được triển khai, và sau đó làm cho bản dựng thất bại lớn tiếng khi có điều gì đó bị hỏng.

button

Tóm tắt (TL;DR)

“Kiểm thử API tự động trong Azure Pipelines” thực sự có nghĩa là gì

Azure Pipelines là dịch vụ CI/CD bên trong Azure DevOps. Bạn mô tả một bản dựng trong một tệp YAML (azure-pipelines.yml) nằm trong kho lưu trữ của bạn, và Azure chạy tệp đó trên một agent được host hoặc tự host mỗi khi có một sự kiện kích hoạt; một push, một pull request, một lịch trình, hoặc một lần chạy thủ công.

Đối với kiểm thử API, công việc khá đơn giản về hình thức:

  1. Khởi động một agent (một máy ảo sạch).
  2. Cài đặt bất cứ thứ gì mà trình chạy kiểm thử của bạn cần.
  3. Chạy các bài kiểm thử API trên một môi trường mục tiêu.
  4. Báo cáo kết quả và đặt trạng thái bản dựng dựa trên chúng.

Chi tiết khiến mọi người vấp váp là bước 3. Một máy khách API cục bộ có tính tương tác; bạn nhấp "Gửi", bạn nhìn vào phản hồi, bạn đọc dấu kiểm màu xanh lá cây. Một pipeline không có ai để nhấp và không có ai để nhìn. Bạn cần một cách để chạy các xác nhận tương tự mà không có con người và không có GUI. Đó là lý do tại sao một trình chạy dòng lệnh tồn tại.

Nếu bạn muốn một giới thiệu rộng hơn về các khái niệm CI ở đây, sự khác biệt giữa tích hợp liên tục, phân phối liên tục và triển khai liên tục đáng để đọc nhanh trước khi bạn thiết lập pipeline đầu tiên của mình.

Tại sao nên thiết kế bài kiểm thử trong Apidog và chạy chúng bằng CLI

Bạn có thể viết các bài kiểm thử API bằng mã nguồn. Chọn một ngôn ngữ, kéo một thư viện HTTP và một framework xác nhận, tự viết các phần thân yêu cầu, phân tích phản hồi, quản lý mã thông báo xác thực và giữ tất cả chúng đồng bộ với một API thay đổi theo mỗi sprint. Các nhóm vẫn làm điều này. Họ cũng dành một lượng thời gian không tương xứng để duy trì nó.

Apidog đi theo một con đường khác. Bạn xây dựng các kịch bản kiểm thử một cách trực quan: xâu chuỗi các yêu cầu lại với nhau, truyền dữ liệu từ một phản hồi vào yêu cầu tiếp theo, thêm các xác nhận trên mã trạng thái, tiêu đề và các trường JSON, và điều khiển cùng một kịch bản với nhiều hàng dữ liệu. Vì Apidog đã lưu trữ các định nghĩa API của bạn, các bài kiểm thử luôn gần với đặc tả. Khi lược đồ thay đổi, bạn sẽ thấy sự khác biệt thay vì phát hiện ra nó trong sản xuất.

Phần kết nối công việc trực quan đó với CI là Apidog CLI, một trình chạy dòng lệnh được xuất bản trên npm. Nó thực thi một kịch bản kiểm thử đã lưu một cách không đầu và thoát với mã trạng thái phản ánh kết quả: 0 nếu mọi thứ đều đạt, khác không nếu bất kỳ xác nhận nào thất bại. Mã thoát đó là hợp đồng mà mọi hệ thống CI đều hiểu. Azure Pipelines đọc nó và quyết định bản dựng có màu xanh hay đỏ. Bạn thiết kế một lần trong GUI, và cùng một kịch bản chạy không thay đổi trong pipeline.

Đây là cùng một mô hình hoạt động cho GitHub Actions, GitLab CI và Jenkins. Azure Pipelines chỉ là một host khác cho cùng một lệnh CLI, điều này có nghĩa là kiến thức có thể được chuyển giao nếu nhóm của bạn thay đổi nền tảng.

Điều kiện tiên quyết

Trước khi bạn xây dựng pipeline, hãy chuẩn bị những điều sau:

Một lưu ý nhanh về môi trường mục tiêu để kiểm thử. Chạy toàn bộ bộ kiểm thử trên môi trường sản xuất với mỗi cam kết là rủi ro và thường không thể (bạn không muốn dữ liệu kiểm thử trong môi trường sản xuất). Hầu hết các nhóm đều chỉ các bài kiểm thử CI vào một môi trường staging hoặc một triển khai xem trước theo từng nhánh. Môi trường Apidog giúp việc này rõ ràng: giữ một môi trường Staging với URL cơ sở và các biến riêng, và cho CLI biết nên sử dụng môi trường nào khi chạy.

Bước 1: Đưa kịch bản kiểm thử của bạn vào dạng có thể chạy được

CLI cần biết kịch bản nào để chạy. Apidog cung cấp cho bạn hai cách để cung cấp nó.

Tùy chọn A, chạy từ một liên kết trực tuyến được chia sẻ. Trong Apidog, mở kịch bản kiểm thử của bạn, chọn chạy nó qua CLI, và Apidog tạo ra một lệnh trỏ đến kịch bản qua mạng. Đây là tùy chọn ít phải bảo trì hơn: pipeline luôn chạy phiên bản hiện tại của kịch bản, và bạn không cam kết các tệp kiểm thử vào kho lưu trữ. Đánh đổi là pipeline phụ thuộc vào liên kết đó có thể truy cập được trong thời gian chạy.

Tùy chọn B, xuất kịch bản ra một tệp và cam kết nó. Xuất kịch bản (và môi trường của nó) ra một tệp cục bộ, cam kết nó cùng với mã của bạn, và chỉ CLI đến đường dẫn tệp. Điều này ghim bài kiểm thử vào một cam kết cụ thể, điều bạn muốn nếu bạn quan tâm đến khả năng tái sản xuất; các bài kiểm thử đã chạy chính xác là các bài kiểm thử trong cam kết đó. Đánh đổi là bạn phải xuất lại khi kịch bản thay đổi.

Đối với hầu hết các nhóm mới bắt đầu, Tùy chọn A nhanh hơn để thiết lập. Đối với công việc được quy định hoặc yêu cầu kiểm toán cao, khả năng tái sản xuất của Tùy chọn B sẽ thắng thế. Bạn cũng có thể kết hợp: dựa trên liên kết cho các nhánh tính năng thay đổi nhanh, dựa trên tệp cho các nhánh phát hành.

Dù bằng cách nào, hãy ghi chú lệnh chạy chính xác mà Apidog cung cấp cho bạn. Nó sẽ trông gần giống như sau:

apidog run https://api.apidog.com/api/v1/test-scenarios/<scenario-id> \
 -t <access-token> \
 -e <environment-id>

Các cờ bạn sẽ sử dụng nhiều nhất:

Xác nhận các tên cờ chính xác so với lệnh chạy mà Apidog tạo cho kịch bản của bạn; trình chạy in cách sử dụng với apidog run --help. Đừng đoán các cờ; sao chép những cái Apidog cung cấp cho bạn và tham số hóa các bí mật.

Bước 2: Xác minh CLI hoạt động cục bộ trước

Đừng bao giờ gỡ lỗi một công cụ mới bên trong CI. Vòng lặp phản hồi của pipeline chậm và nhật ký ồn ào hơn terminal của bạn. Hãy chạy thành công trên máy của bạn trước tiên.

Cài đặt CLI:

npm install -g apidog-cli

Sau đó chạy kịch bản của bạn:

apidog run https://api.apidog.com/api/v1/test-scenarios/<scenario-id> \
 -t "$APIDOG_ACCESS_TOKEN" \
 -e "<staging-environment-id>"

Bạn đang kiểm tra ba điều:

  1. Lệnh hoàn thành và in tóm tắt đạt/thất bại.
  2. Mã thoát khớp với kết quả. Chạy echo $? ngay sau đó; nó phải là 0 khi thành công và khác không khi thất bại.
  3. Môi trường được giải quyết đúng; các yêu cầu truy cập URL staging của bạn, không phải một URL cục bộ còn sót lại.

Kiểm tra mã thoát đó quan trọng hơn bạn nghĩ. Nếu CLI thoát 0 ngay cả khi một xác nhận thất bại, pipeline của bạn sẽ chuyển sang màu xanh lá cây trên mã bị lỗi, điều này tồi tệ hơn là không có bài kiểm thử nào cả. Buộc một lần thất bại (cố ý làm hỏng một xác nhận) và xác nhận bạn nhận được mã khác không. Sau đó đặt lại xác nhận.

Bước 3: Tạo tệp YAML của Azure Pipelines

Thêm một tệp có tên azure-pipelines.yml vào thư mục gốc của kho lưu trữ của bạn. Đây là một điểm khởi đầu hoàn chỉnh, hoạt động cho một agent Ubuntu được host:

trigger:
 branches:
 include:
 - main
 - develop

pr:
 branches:
 include:
 - main

pool:
 vmImage: ubuntu-latest

variables:
 NODE_VERSION: '20.x'

steps:
 - task: NodeTool@0
 inputs:
 versionSpec: $(NODE_VERSION)
 displayName: 'Install Node.js'

 - script: npm install -g apidog-cli
 displayName: 'Install Apidog CLI'

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID)
 displayName: 'Run API tests'

Giải thích từng phần:

Các tham chiếu $(...) là các biến pipeline. SCENARIO_ID, STAGING_ENV_ID, và đặc biệt là APIDOG_ACCESS_TOKEN đến từ bước tiếp theo, không được mã hóa cứng ở đây.

Bước 4: Lưu trữ bí mật đúng cách

Mã thông báo truy cập của bạn không bao giờ được nằm trong tệp YAML dưới dạng văn bản thuần túy. Bất kỳ ai có quyền đọc kho lưu trữ đều sẽ thấy nó, và nó cấp quyền truy cập vào dự án Apidog của bạn.

Sử dụng một biến pipeline bí mật:

  1. Trong Azure DevOps, mở pipeline của bạn và chọn Edit, sau đó Variables (hoặc Library cho một nhóm biến được chia sẻ).
  2. Thêm APIDOG_ACCESS_TOKEN và dán mã thông báo.
  3. Chuyển đổi biểu tượng khóa để đánh dấu nó là bí mật. Azure mã hóa nó và che dấu nó trong nhật ký.

Các biến bí mật không được tự động đưa vào môi trường shell; bạn phải ánh xạ chúng một cách rõ ràng trong bước. Cập nhật bước chạy để truyền bí mật qua env:

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID)
 displayName: 'Run API tests'
 env:
 APIDOG_ACCESS_TOKEN: $(APIDOG_ACCESS_TOKEN)

SCENARIO_ID và STAGING_ENV_ID không cần phải là bí mật; hãy coi chúng là các biến thông thường để dễ đọc, hoặc chuyển chúng vào một nhóm biến mà bạn tái sử dụng trên các pipeline. Đối với các nhóm quản lý nhiều bí mật, hãy hỗ trợ nhóm biến bằng Azure Key Vault để việc xoay vòng diễn ra ở một nơi.

Bước 5: Xuất bản báo cáo kiểm thử dễ đọc

Một bản dựng thất bại cho bạn biết điều gì đó đã hỏng. Nó không cho bạn biết điều gì. Cách khắc phục là để CLI xuất một báo cáo và Azure hiển thị nó.

Apidog CLI có thể ghi kết quả của nó vào một tệp báo cáo. Chỉ định nó một định dạng đầu ra (HTML cho con người, một XML kiểu JUnit nếu bạn muốn chế độ xem kiểm thử gốc của Azure) và một thư mục đầu ra, sau đó xuất bản thư mục đó.

Để có một artifact dễ đọc:

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID) \
 -r html \
 --out-dir $(Build.ArtifactStagingDirectory)/api-report
 displayName: 'Run API tests'
 env:
 APIDOG_ACCESS_TOKEN: $(APIDOG_ACCESS_TOKEN)

 - task: PublishBuildArtifacts@1
 condition: always()
 inputs:
 pathToPublish: $(Build.ArtifactStagingDirectory)/api-report
 artifactName: api-test-report
 displayName: 'Publish API test report'

Hai điều cần lưu ý. Thứ nhất, condition: always() làm cho bước xuất bản chạy ngay cả khi bước kiểm thử thất bại; đó là toàn bộ mục đích, vì bạn muốn báo cáo nhất khi có điều gì đó bị hỏng. Thứ hai, kiểm tra cờ báo cáo viên chính xác (-r, --reporter, hoặc tương tự) và tùy chọn đầu ra so với apidog run --help cho phiên bản CLI của bạn, sau đó điều chỉnh ví dụ cho phù hợp.

Nếu bạn muốn xem kết quả trong tab Tests tích hợp của Azure với biểu đồ xu hướng, hãy để CLI xuất JUnit XML và thêm tác vụ PublishTestResults@2 trỏ đến XML. Điều đó cung cấp cho bạn lịch sử từng xác nhận trên các bản dựng, không chỉ là một tệp một lần.

Bước 6: Biến cổng bảo vệ thành hiện thực

Thiết lập pipeline không giống như việc thực thi nó. Theo mặc định, một bản dựng thất bại sẽ không ngăn cản bất kỳ ai hợp nhất trừ khi bạn yêu cầu Azure DevOps làm điều đó.

Thiết lập chính sách nhánh trên main:

  1. Đi tới Repos, sau đó Branches, tìm main, và mở Branch policies.
  2. Thêm Build Validation và chọn pipeline của bạn.
  3. Đặt nó là bắt buộc.

Giờ đây, một pull request không thể hợp nhất vào main cho đến khi pipeline kiểm thử API vượt qua. Đó là sự khác biệt giữa các bài kiểm thử chạy và các bài kiểm thử bảo vệ. Cho đến khi bạn bật tính năng này, bạn có một bảng điều khiển; sau đó, bạn có một cổng bảo vệ.

Một ví dụ thực tế dựa trên dữ liệu

Các kịch bản chạy một lần phát hiện các lỗi rõ ràng. Các API thực cần cùng một điểm cuối được kiểm tra với nhiều đầu vào; các payload hợp lệ, các trường hợp biên, yêu cầu sai định dạng mà lẽ ra phải trả về 400 thay vì 500.

Apidog hỗ trợ kiểm thử hướng dữ liệu: đính kèm một tập dữ liệu CSV hoặc JSON vào một kịch bản, và nó sẽ chạy một lần cho mỗi hàng, thay thế các giá trị của hàng vào các yêu cầu và xác nhận. Ví dụ, một kịch bản đăng nhập có thể chạy các hàng cho một người dùng hợp lệ, mật khẩu sai, tài khoản bị khóa và một nội dung trống, mỗi loại với mã trạng thái mong đợi riêng.

Trong pipeline, không có gì thay đổi về hình dạng của lệnh; bạn vẫn gọi apidog run chống lại cùng một kịch bản. Tập dữ liệu đi kèm với kịch bản, vì vậy một lệnh gọi CLI bao gồm mọi hàng. Khi bạn thêm một trường hợp biên mới trong Apidog, lần chạy pipeline tiếp theo sẽ nhận nó mà không cần chỉnh sửa YAML. Đó là lợi ích của việc giữ logic kiểm thử trong công cụ thay vì trong pipeline: pipeline vẫn nhàm chán trong khi phạm vi bao phủ của bạn tăng lên.

Các vấn đề thường gặp và cách khắc phục

Bản dựng vượt qua mặc dù một điểm cuối bị lỗi. Hầu như luôn là vấn đề mã thoát. Xác nhận CLI trả về giá trị khác không khi thất bại (Bước 2), và đảm bảo bạn không bỏ qua nó; một || true ở cuối hoặc một tập lệnh đa lệnh kết thúc bằng một lệnh khác sẽ che giấu lỗi. Giữ lệnh apidog run là lệnh có ý nghĩa cuối cùng trong khối tập lệnh của nó.

apidog: command not found. Bước cài đặt chưa chạy, chạy sau bước kiểm thử, hoặc cài đặt vào một đường dẫn mà shell của agent không thể nhìn thấy. Xác nhận npm install -g apidog-cli xuất hiện trước bước chạy. Trên một số agent tự host, bin npm toàn cầu không có trong PATH; hãy cài đặt cục bộ và gọi nó qua npx apidog run ... thay vào đó.

Xác thực thất bại trong CI nhưng hoạt động cục bộ. Bí mật không đến được bước đó. Các biến bí mật phải được ánh xạ qua env: (Bước 4); chúng không được tự động đưa vào. Cũng kiểm tra xem mã thông báo chưa được dán với một dòng mới ở cuối hoặc một dấu ngoặc kép.

Các bài kiểm thử truy cập sai môi trường. Giá trị -e trỏ đến môi trường Apidog sai, hoặc URL cơ sở của môi trường vẫn tham chiếu localhost. Giữ một môi trường Staging chuyên dụng mà các biến của nó phân giải thành các URL có thể truy cập, an toàn cho CI, và truyền ID của nó một cách rõ ràng.

Đạt/thất bại không ổn định giữa các lần chạy. Thường là trạng thái chia sẻ có thể thay đổi; một bài kiểm thử tạo một bản ghi, và một lần chạy sau đó va chạm với nó. Hãy làm cho các kịch bản tựcontained: tạo những gì bạn cần, xác nhận, sau đó dọn dẹp, hoặc sử dụng các định danh duy nhất cho mỗi lần chạy để các lần chạy lại không vấp phải dữ liệu của ngày hôm qua. Nếu bạn đang di chuyển từ một công cụ khác, các mẫu trong cách chạy kiểm thử API trong CI mà không cần Newman đề cập đến cùng một cạm bẫy cô lập.

Ngoài những điều cơ bản

Một khi pipeline cốt lõi đã vững chắc, một vài mở rộng sẽ mang lại lợi ích:

Mỗi điều này là một bổ sung nhỏ vào cùng một nền tảng: một CLI thoát sạch và một pipeline tôn trọng mã thoát.

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

Tôi có cần viết bất kỳ mã nào để chạy kiểm thử API trong Azure Pipelines không? Không. Bạn xây dựng các kịch bản kiểm thử một cách trực quan trong Apidog và pipeline chạy chúng bằng một lệnh CLI duy nhất. "Mã" duy nhất là chính tệp azure-pipelines.yml, đây là cấu hình, không phải logic kiểm thử. Nếu bạn thích các bài kiểm thử hoàn toàn dựa trên script, bạn vẫn có thể làm điều đó, nhưng mục đích của quy trình làm việc này là bỏ qua nó.

Tôi có thể chạy các Postman collections hiện có của mình trong Azure Pipelines thay thế không? Có, thường là với Newman hoặc một trình chạy tương tự. Nếu bạn đang cân nhắc các lựa chọn, Apidog nhập trực tiếp các Postman collections, vì vậy bạn có thể mang các bài kiểm thử hiện có vào và chạy chúng qua cùng một CLI mà không cần duy trì một bộ công cụ riêng biệt. Xem cách chạy kiểm thử API trong CI mà không cần Newman để so sánh.

Các bài kiểm thử nên trỏ đến đâu; staging hay production? Gần như luôn là staging hoặc một môi trường xem trước theo từng nhánh. Chạy các bài kiểm thử ghi dữ liệu nặng trên môi trường production sẽ làm ô nhiễm dữ liệu thật và có thể gây ra các tác dụng phụ thật. Giữ một môi trường Apidog chuyên dụng cho CI với các URL cơ sở an toàn, và truyền ID của nó cho CLI bằng -e.

Làm thế nào pipeline biết một bài kiểm thử đã thất bại? Thông qua mã thoát. apidog run trả về 0 khi mọi xác nhận đều đạt và một mã khác không khi có bất kỳ lỗi nào. Azure Pipelines làm thất bại tác vụ script khi có mã thoát khác không, điều này làm thất bại bản dựng. Hãy xác minh điều này một lần cục bộ với echo $? để bạn tin tưởng vào cổng bảo vệ.

Điều này có hoạt động với Azure DevOps Classic (UI) pipelines không, không chỉ YAML? Có. Các bước tương tự áp dụng; thêm một tác vụ "Use Node", một tác vụ dòng lệnh chạy npm install -g apidog-cli, và một tác vụ dòng lệnh khác chạy apidog run .... YAML được khuyến nghị vì nó nằm trong kho lưu trữ của bạn và được kiểm soát phiên bản, nhưng trình chạy không quan tâm các bước được định nghĩa như thế nào.

Tôi có thể sử dụng agent tự host thay vì agent do Microsoft host không? Có. Các agent tự host hoạt động tương tự; chỉ cần đảm bảo Node.js được cài đặt và bin npm toàn cầu nằm trên PATH của agent, hoặc gọi CLI qua npx. Các agent tự host hữu ích khi API staging của bạn chỉ có thể truy cập được từ bên trong một mạng riêng.

Tóm lại

Một bản dựng CI màu xanh lá cây nên có nghĩa là API của bạn thực sự hoạt động, không chỉ là mã đã được biên dịch. Để đạt được điều đó trong Azure Pipelines, bạn cần bốn bước: thiết kế các kịch bản kiểm thử thực tế trong Apidog, chạy chúng một cách không đầu với Apidog CLI, để mã thoát điều khiển trạng thái bản dựng, và yêu cầu bản dựng phải đạt trước khi bất kỳ điều gì được hợp nhất. Một khi vòng lặp đó đang chạy, mọi push đều nhận được sự giám sát kỹ lưỡng như người đồng đội cẩn thận nhất của bạn sẽ làm, tự động, mỗi lần.

Lý do điều này vẫn duy trì được là do sự phân tách. Logic kiểm thử nằm trong Apidog, nơi nó gần với đặc tả API của bạn và dễ dàng mở rộng. Pipeline vẫn là một lớp vỏ mỏng; cài đặt, chạy, báo cáo. Khi API của bạn phát triển, bạn thêm các kịch bản và hàng dữ liệu vào công cụ, và pipeline tiếp tục thực hiện công việc của nó mà không cần chỉnh sửa.

Sẵn sàng thiết lập chưa? Tải xuống Apidog, xây dựng một kịch bản kiểm thử, lấy lệnh chạy CLI và đưa nó vào tệp azure-pipelines.yml của bạn. Lỗi hồi quy tiếp theo của bạn sẽ được phát hiện bởi máy thay vì một khách hàng.

button

Thực hành thiết kế API trong Apidog

Khám phá cách dễ dàng hơn để xây dựng và sử dụng API

Đăng ký miễn phíTải xuống