วิธีการทดสอบ API อัตโนมัติด้วย Azure Pipelines (ทีละขั้นตอน)

API ของคุณทำงานได้บนแล็ปท็อปของคุณ มันผ่านการตรวจสอบทุกครั้งในไคลเอนต์ทดสอบในเครื่องของคุณ จากนั้นเพื่อนร่วมทีมรวมสาขา (branch) เข้าด้วยกัน การปรับใช้ (deploy) ก็เกิดขึ้น และเอนด์พอยต์ที่เคยส่งคืนโค้ด 200 ก็เริ่มส่งคืน 500 ในสภาพแวดล้อมจริง (production) ไม่มีใครจับความผิดปกตินี้ได้ เพราะไม่มีใครรันการทดสอบบนสาขานั้น พวกเขารันการทดสอบบนเครื่องเพียงครั้งเดียวด้วยตนเอง

ช่องว่างระหว่าง “มีการทดสอบ” กับ “มีการรันการทดสอบทุกครั้งที่มีการเปลี่ยนแปลง” คือสิ่งที่ CI pipeline เข้ามาเติมเต็ม หากโค้ดของคุณอยู่ใน Azure Repos หรือ GitHub อยู่แล้ว และทีมของคุณสร้างบน Azure DevOps, Azure Pipelines คือที่ที่เหมาะสมในการวางระบบป้องกันความปลอดภัยนี้ ส่วนที่ยากนั้นมักไม่ใช่ไฟล์ YAML แต่เป็นการจัดเตรียมชุดทดสอบ API ของคุณให้อยู่ในรูปแบบที่ pipeline สามารถรันได้โดยอัตโนมัติ (headlessly) ด้วยสภาพแวดล้อมที่ถูกต้อง เทียบกับการสร้างที่ปรับใช้ใหม่ และจากนั้นทำให้ build ล้มเหลวอย่างชัดเจนเมื่อมีสิ่งผิดปกติเกิดขึ้น

สรุปสั้นๆ (TL;DR)

• Azure Pipelines รันการทดสอบ API ของคุณโดยอัตโนมัติทุกครั้งที่มีการคอมมิตหรือ PR เพื่อให้ตรวจพบข้อผิดพลาดที่ย้อนกลับไป (regressions) ได้ก่อนที่จะนำไปใช้งานจริง
• สร้างสถานการณ์การทดสอบของคุณด้วยภาพใน Apidog จากนั้นรันใน CI ด้วย Apidog CLI (apidog-cli) แทนที่จะเขียนและดูแลสคริปต์การทดสอบด้วยตนเอง
• Pipeline ต้องการสี่สิ่ง: Node.js ติดตั้งอยู่บน agent, CLI ติดตั้งอยู่, สถานการณ์การทดสอบของคุณสามารถเข้าถึงได้ผ่านลิงก์หรือไฟล์ที่ส่งออก, และโทเค็นการเข้าถึง (access token) ที่จัดเก็บเป็นความลับ (secret)
• รหัสออก (exit code) ที่ไม่ใช่ศูนย์จาก CLI จะทำให้ build ล้มเหลวโดยอัตโนมัติ นี่คือสิ่งที่ให้การตรวจสอบที่แท้จริง
• เผยแพร่รายงาน HTML หรือ JUnit เป็น pipeline artifact (หรือผ่าน PublishTestResults) เพื่อให้ทุกคนสามารถอ่านผลการผ่าน/ไม่ผ่านได้โดยไม่ต้องเปิดดูบันทึก (logs)

“การทดสอบ API แบบอัตโนมัติใน Azure Pipelines” หมายถึงอะไร

Azure Pipelines คือบริการ CI/CD ภายใน Azure DevOps คุณจะอธิบาย build ในไฟล์ YAML (azure-pipelines.yml) ที่อยู่ใน repo ของคุณ และ Azure จะรันไฟล์นั้นบน hosted หรือ self-hosted agent ทุกครั้งที่เกิด trigger ขึ้น ไม่ว่าจะเป็นการ push, pull request, การตั้งเวลา หรือการรันด้วยตนเอง

สำหรับการทดสอบ API งานมีรูปแบบที่ตรงไปตรงมา:

1. เรียกใช้งาน agent (VM ที่สะอาด)
2. ติดตั้งสิ่งที่ test runner ของคุณต้องการ
3. รันการทดสอบ API กับสภาพแวดล้อมเป้าหมาย
4. รายงานผลและกำหนดสถานะ build ตามผลลัพธ์เหล่านั้น

รายละเอียดที่ทำให้ผู้คนติดขัดคือขั้นตอนที่ 3 ไคลเอนต์ API ในเครื่องเป็นแบบโต้ตอบ; คุณคลิก “Send” คุณดูการตอบกลับด้วยตาเปล่า คุณเห็นเครื่องหมายถูกสีเขียว Pipeline ไม่มีใครให้คลิกและไม่มีใครดูด้วยตาเปล่า คุณต้องการวิธีการรันการตรวจสอบยืนยัน (assertions) แบบเดียวกันโดยไม่มีมนุษย์และไม่มี GUI นั่นคือเหตุผลทั้งหมดที่ command-line runner มีอยู่

หากคุณต้องการความรู้เบื้องต้นเกี่ยวกับแนวคิด CI ที่กว้างขึ้น ความแตกต่างระหว่าง การรวมระบบอย่างต่อเนื่อง (continuous integration), การส่งมอบอย่างต่อเนื่อง (continuous delivery) และการปรับใช้ต่อเนื่อง (continuous deployment) นั้นคุ้มค่าที่จะอ่านอย่างรวดเร็วก่อนที่คุณจะตั้งค่า pipeline แรกของคุณ

ทำไมต้องออกแบบการทดสอบใน Apidog และรันด้วย CLI

คุณสามารถเขียนการทดสอบ API ด้วยโค้ดดิบ เลือกภาษา ดึงไลบรารี HTTP และเฟรมเวิร์กการตรวจสอบยืนยันมาใช้ สร้าง request body ด้วยมือ แยกวิเคราะห์การตอบกลับ จัดการโทเค็นการยืนยันตัวตน และรักษาทั้งหมดให้ซิงค์กับ API ที่เปลี่ยนแปลงทุกสปรินต์ ทีมต่างๆ ทำเช่นนี้ พวกเขายังใช้เวลาจำนวนมากในการดูแลรักษาด้วย

Apidog เลือกเส้นทางที่แตกต่างออกไป คุณสร้าง สถานการณ์การทดสอบ ด้วยภาพ: เชื่อมโยงคำขอเข้าด้วยกัน ส่งข้อมูลจากการตอบกลับหนึ่งไปยังคำขอถัดไป เพิ่มการยืนยันบนรหัสสถานะ, ส่วนหัว (headers) และฟิลด์ JSON และขับเคลื่อนสถานการณ์เดียวกันด้วยข้อมูลหลายแถว เนื่องจากการนิยาม API ของคุณอยู่ใน Apidog อยู่แล้ว การทดสอบจึงอยู่ใกล้กับสเปค เมื่อโครงสร้าง (schema) เปลี่ยนแปลง คุณจะเห็นความเบี่ยงเบนแทนที่จะค้นพบมันในสภาพแวดล้อมจริง

ส่วนที่เชื่อมโยงงานภาพนั้นเข้ากับ CI คือ Apidog CLI ซึ่งเป็น command-line runner ที่เผยแพร่บน npm มันจะรันสถานการณ์การทดสอบที่บันทึกไว้โดยอัตโนมัติ (headlessly) และออกด้วยรหัสสถานะที่สะท้อนผลลัพธ์: 0 ถ้าทุกอย่างผ่าน และไม่ใช่ศูนย์ถ้ามีการยืนยันใดๆ ล้มเหลว รหัสออกนั้นคือสัญญาที่ระบบ CI ทุกระบบเข้าใจ Azure Pipelines อ่านมันและตัดสินใจว่า build เป็นสีเขียวหรือสีแดง คุณออกแบบครั้งเดียวใน GUI และสถานการณ์เดียวกันก็รันได้โดยไม่เปลี่ยนแปลงใน pipeline

นี่คือโมเดลเดียวกันที่ใช้ได้กับ GitHub Actions, GitLab CI และ Jenkins Azure Pipelines เป็นเพียงโฮสต์อีกหนึ่งตัวสำหรับคำสั่ง CLI เดียวกัน ซึ่งหมายความว่าความรู้สามารถถ่ายทอดได้หากทีมของคุณเปลี่ยนแพลตฟอร์ม

ข้อกำหนดเบื้องต้น

• โปรเจกต์ Apidog ที่มีสถานการณ์การทดสอบอย่างน้อยหนึ่งรายการ เปิดส่วน Test Scenarios สร้างสถานการณ์ เพิ่มคำขอสองสามรายการ และแนบการยืนยัน รันหนึ่งครั้งในเครื่องและยืนยันว่าผ่าน หากมันทำงานไม่แน่นอนบนเครื่องของคุณ มันก็จะทำงานไม่แน่นอนใน CI
• โทเค็นการเข้าถึง Apidog CLI ใช้การยืนยันตัวตนด้วยโทเค็นการเข้าถึงส่วนบุคคลจากApidog account settings ของคุณ ปฏิบัติกับมันเหมือนรหัสผ่าน; คุณจะจัดเก็บมันเป็น pipeline secret ไม่ใช่ในไฟล์ YAML
• โปรเจกต์ Azure DevOps ที่มี repo ไฟล์ azure-pipelines.yml ของคุณจะอยู่ใน root ของ repo
• ความคุ้นเคยกับ Node.js (เล็กน้อย) CLI รันบน Node ดังนั้น agent จึงต้องติดตั้ง Node เอเจนต์ที่โฮสต์ของ Azure มี Node อยู่แล้ว คุณเพียงแค่เลือกเวอร์ชัน
• สภาพแวดล้อมเป้าหมายที่เข้าถึงได้ การทดสอบของคุณต้องเรียกใช้ API ที่ทำงานอยู่ ไม่ว่าจะเป็น URL ของ staging, การปรับใช้แบบพรีวิว หรือบริการที่ pipeline เริ่มต้นเอง ตัดสินใจก่อนที่คุณจะเขียน trigger

ข้อควรจำสั้นๆ เกี่ยวกับเป้าหมายที่จะทดสอบ การรันชุดทดสอบกับ production ทุกครั้งที่ commit มีความเสี่ยงและมักจะเป็นไปไม่ได้ (คุณไม่ต้องการข้อมูลทดสอบใน prod) ทีมส่วนใหญ่จะชี้การทดสอบ CI ไปที่สภาพแวดล้อม staging หรือการปรับใช้แบบพรีวิวต่อสาขา สภาพแวดล้อม Apidog ทำให้สิ่งนี้ง่ายขึ้น: ให้มีสภาพแวดล้อม Staging ที่มี base URL และตัวแปรของตัวเอง และบอก CLI ว่าจะใช้ตัวไหนในขณะที่รัน

ขั้นตอนที่ 1: จัดเตรียมสถานการณ์การทดสอบของคุณให้อยู่ในรูปแบบที่รันได้

CLI จำเป็นต้องรู้ว่าต้องรันสถานการณ์ไหน Apidog มีสองวิธีในการป้อนสถานการณ์ให้มัน

ทางเลือก A, รันจากลิงก์ออนไลน์ที่แชร์ ใน Apidog เปิดสถานการณ์การทดสอบของคุณ เลือกที่จะรันผ่าน CLI และ Apidog จะสร้างคำสั่งที่ชี้ไปยังสถานการณ์ผ่านเครือข่าย นี่เป็นทางเลือกที่ดูแลรักษาน้อยกว่า: pipeline จะรันเวอร์ชันปัจจุบันของสถานการณ์เสมอ และคุณไม่ต้องคอมมิตไฟล์ทดสอบไปยัง repo ข้อเสียคือ pipeline ขึ้นอยู่กับว่าลิงก์นั้นสามารถเข้าถึงได้ในขณะที่รัน

ทางเลือก B, ส่งออกสถานการณ์ไปยังไฟล์และคอมมิตมัน ส่งออกสถานการณ์ (และสภาพแวดล้อมของมัน) ไปยังไฟล์ในเครื่อง คอมมิตมันพร้อมกับโค้ดของคุณ และชี้ CLI ไปยังพาธไฟล์ สิ่งนี้จะตรึงการทดสอบไว้ที่ commit ที่เฉพาะเจาะจง ซึ่งเป็นสิ่งที่คุณต้องการหากคุณใส่ใจเรื่องความสามารถในการทำซ้ำ; การทดสอบที่รันคือการทดสอบที่อยู่ใน commit นั้นพอดี ข้อเสียคือคุณต้องส่งออกใหม่เมื่อสถานการณ์เปลี่ยนแปลง

สำหรับทีมส่วนใหญ่ที่เริ่มต้น ทางเลือก A จะตั้งค่าได้เร็วกว่า สำหรับงานที่อยู่ภายใต้กฎระเบียบหรือมีการตรวจสอบเข้มงวด ความสามารถในการทำซ้ำของทางเลือก B จะเป็นประโยชน์ คุณยังสามารถผสมผสานได้: ใช้แบบลิงก์สำหรับ feature branch ที่เปลี่ยนแปลงรวดเร็ว และแบบไฟล์สำหรับ release branch

ไม่ว่าจะด้วยวิธีใด โปรดจดคำสั่งรันที่ Apidog ให้คุณไว้ มันจะดูคล้ายกับสิ่งนี้:

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

ตัวเลือก (flags) ที่คุณจะใช้งานบ่อยที่สุด:

• การอ้างอิงสถานการณ์ (ลิงก์ออนไลน์หรือพาธไฟล์ในเครื่อง),
• -t / โทเค็นการเข้าถึงสำหรับการยืนยันตัวตน,
• -e สำหรับสภาพแวดล้อมที่จะรันการทดสอบ,
• ตัวเลือก reporter เพื่อควบคุมรูปแบบการแสดงผล (ข้อความ CLI, HTML หรือสรุปที่เครื่องอ่านได้),
• จำนวนรอบ (iteration count) เมื่อคุณต้องการให้สถานการณ์วนซ้ำชุดข้อมูล

ยืนยันชื่อ flag ที่แน่นอนเทียบกับคำสั่งรันที่ Apidog สร้างขึ้นสำหรับสถานการณ์ของคุณ; runner จะแสดงการใช้งานด้วย apidog run --help อย่าเดา flag; คัดลอกสิ่งที่ Apidog มอบให้คุณและกำหนดค่าความลับ (secrets) เป็นพารามิเตอร์

ขั้นตอนที่ 2: ตรวจสอบว่า CLI ทำงานได้ในเครื่องก่อน

อย่าแก้ไขข้อบกพร่องของเครื่องมือใหม่ภายใน CI วงจรการตอบกลับของ Pipeline ช้า และบันทึก (logs) ก็มีเสียงรบกวนมากกว่าเทอร์มินัลของคุณ เริ่มต้นด้วยการรันให้ผ่านบนเครื่องของคุณเองก่อน

ติดตั้ง CLI:

npm install -g apidog-cli

จากนั้นรันสถานการณ์ของคุณ:

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

คุณกำลังตรวจสอบสามสิ่ง:

1. คำสั่งเสร็จสิ้นและพิมพ์สรุปผลการผ่าน/ไม่ผ่าน
2. รหัสออกตรงกับผลลัพธ์ รัน echo $? ทันทีหลังจากนั้น; ควรจะเป็น 0 เมื่อสำเร็จและไม่ใช่ศูนย์เมื่อล้มเหลว
3. สภาพแวดล้อมถูกแก้ไขอย่างถูกต้อง; คำขอเข้าถึง URL ของ staging ของคุณ ไม่ใช่ URL ภายในเครื่องที่หลงเหลืออยู่

การตรวจสอบรหัสออกนั้นสำคัญกว่าที่คิดไว้มาก หาก CLI ออกด้วย 0 แม้ว่ามีการยืนยันล้มเหลว pipeline ของคุณก็จะแสดงผลเป็นสีเขียวสำหรับโค้ดที่เสียหาย ซึ่งแย่กว่าการไม่มีการทดสอบเลย จงบังคับให้เกิดความล้มเหลวสักครั้ง (เจตนาทำให้การยืนยันผิดพลาด) และยืนยันว่าคุณได้รับรหัสที่ไม่ใช่ศูนย์ จากนั้นจึงแก้ไขการยืนยันให้กลับมาถูกต้อง

ขั้นตอนที่ 3: สร้างไฟล์ Azure Pipelines YAML

เพิ่มไฟล์ชื่อ azure-pipelines.yml ไปยัง root ของ repo ของคุณ นี่คือจุดเริ่มต้นที่สมบูรณ์และใช้งานได้สำหรับ hosted Ubuntu agent:

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'

อธิบายทีละส่วน:

• trigger จะรัน pipeline ทุกครั้งที่มีการ push ไปยัง main และ develop ปรับเปลี่ยนตามชื่อ branch ของคุณ
• pr จะรันเมื่อมี pull request ที่กำหนดเป้าหมายไปที่ main นี่คือด่านที่หยุด branch ที่เสียไม่ให้รวม (merge) เข้ามา
• pool / vmImage เลือก Microsoft-hosted Ubuntu agent ไม่ต้องจัดการโครงสร้างพื้นฐาน
• NodeTool@0 ติดตั้ง Node เวอร์ชันเฉพาะ เพื่อให้การรันของคุณสามารถทำซ้ำได้ (reproducible)
• ขั้นตอนการติดตั้งจะดึง CLI มาใหม่ทุกครั้งที่รัน เพื่อการ build ที่เร็วขึ้น คุณสามารถแคช node_modules หรือตรึงเวอร์ชันได้ แต่เริ่มจากง่ายๆ ก่อน
• ขั้นตอนการรันคือส่วนที่สำคัญที่สุด หากมีการยืนยันใดๆ ล้มเหลว apidog run จะออกจากระบบด้วยรหัสที่ไม่ใช่ศูนย์ ทำให้ script task ล้มเหลว และ build ทั้งหมดจะกลายเป็นสีแดง

การอ้างอิง $(...) คือตัวแปร pipeline ตัวแปร SCENARIO_ID, STAGING_ENV_ID และโดยเฉพาะอย่างยิ่ง APIDOG_ACCESS_TOKEN มาจากขั้นตอนถัดไป ไม่ได้ถูกเขียนไว้ตายตัว (hard-coded) ที่นี่

ขั้นตอนที่ 4: จัดเก็บความลับ (secrets) อย่างถูกต้อง

โทเค็นการเข้าถึงของคุณจะต้องไม่ปรากฏในไฟล์ YAML เป็นข้อความธรรมดาเด็ดขาด ใครก็ตามที่มีสิทธิ์อ่าน repo ก็จะเห็นมัน และมันจะให้สิทธิ์การเข้าถึงโปรเจกต์ Apidog ของคุณ

1. ใน Azure DevOps เปิด pipeline ของคุณแล้วเลือก Edit จากนั้น Variables (หรือ Library สำหรับ variable group ที่แชร์)
2. เพิ่ม APIDOG_ACCESS_TOKEN แล้ววางโทเค็น
3. สลับไอคอนรูปกุญแจเพื่อทำเครื่องหมายว่าเป็น secret Azure จะเข้ารหัสและปกปิดมันในบันทึก (logs)

ตัวแปรที่เป็นความลับ (Secret variables) ไม่ได้ถูกฉีดเข้าสู่สภาพแวดล้อมเชลล์โดยอัตโนมัติ คุณต้องกำหนดค่าพวกมันอย่างชัดเจนในขั้นตอน อัปเดตขั้นตอนการรันเพื่อส่งผ่านความลับผ่าน 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 และ STAGING_ENV_ID ไม่จำเป็นต้องเป็นความลับ; ปฏิบัติต่อพวกมันเป็นตัวแปรธรรมดาเพื่อให้อ่านง่าย หรือย้ายพวกมันไปไว้ใน variable group ที่คุณนำกลับมาใช้ใหม่ได้ในหลายๆ pipeline สำหรับทีมที่จัดการความลับจำนวนมาก ให้สนับสนุน variable group ด้วย Azure Key Vault เพื่อให้การหมุนเวียน (rotation) เกิดขึ้นในที่เดียว

ขั้นตอนที่ 5: เผยแพร่รายงานการทดสอบที่อ่านง่าย

build ที่เป็นสีแดงบอกคุณว่ามีบางอย่างเสีย มันไม่ได้บอกว่าอะไรเสีย วิธีแก้ไขคือให้ CLI สร้างรายงานและให้ Azure แสดงผล

Apidog CLI สามารถเขียนผลลัพธ์ลงในไฟล์รายงานได้ ชี้มันไปยังรูปแบบเอาต์พุต (HTML สำหรับมนุษย์, XML สไตล์ JUnit หากคุณต้องการมุมมองการทดสอบแบบ native ของ Azure) และไดเรกทอรีเอาต์พุต จากนั้นเผยแพร่ไดเรกทอรีนั้น

 - 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'

สองสิ่งที่ควรสังเกต ประการแรก, condition: always() ทำให้ขั้นตอนการเผยแพร่ทำงานแม้ว่าขั้นตอนการทดสอบจะล้มเหลว นั่นคือจุดประสงค์ทั้งหมด เนื่องจากคุณต้องการรายงานมากที่สุดเมื่อมีสิ่งผิดปกติเกิดขึ้น ประการที่สอง, ตรวจสอบ flag ของ reporter ที่ถูกต้อง (-r, --reporter หรือคล้ายกัน) และตัวเลือกเอาต์พุตเทียบกับ apidog run --help สำหรับเวอร์ชัน CLI ของคุณ จากนั้นปรับตัวอย่างให้ตรงกัน

หากคุณต้องการดูผลลัพธ์ในแท็บ Tests ที่มาพร้อมกับ Azure พร้อมกราฟแนวโน้ม ให้ CLI สร้าง JUnit XML และเพิ่ม task PublishTestResults@2 ที่ชี้ไปที่ไฟล์ XML นั่นจะทำให้คุณมีประวัติการยืนยันต่อการ build ไม่ใช่แค่ไฟล์เดียว

ขั้นตอนที่ 6: สร้างด่านตรวจสอบให้เป็นจริง

การเชื่อมต่อ pipeline ไม่เหมือนกับการบังคับใช้มัน โดยค่าเริ่มต้น build ที่ล้มเหลวจะไม่หยุดใครจากการรวม (merging) เว้นแต่คุณจะบอกให้ Azure DevOps บังคับใช้

1. ไปที่ Repos, จากนั้น Branches, ค้นหา main, และเปิด Branch policies
2. เพิ่ม Build Validation และเลือก pipeline ของคุณ
3. ตั้งค่าเป็น required (จำเป็น)

ตอนนี้ pull request จะไม่สามารถรวมเข้ากับ main ได้จนกว่า API test pipeline จะผ่าน นี่คือความแตกต่างระหว่างการทดสอบที่รันกับการทดสอบที่ปกป้อง จนกว่าคุณจะเปิดใช้งานสิ่งนี้ คุณจะมีแค่แดชบอร์ด; หลังจากนั้น คุณก็จะมีด่านตรวจสอบ

ตัวอย่างที่ขับเคลื่อนด้วยข้อมูลที่สมจริง

สถานการณ์แบบรันครั้งเดียวจับข้อผิดพลาดที่ชัดเจนได้ API จริงๆ ต้องการให้เอนด์พอยต์เดียวกันถูกทดสอบด้วยอินพุตหลายๆ อย่าง ไม่ว่าจะเป็น payloads ที่ถูกต้อง, กรณีขอบ (edge cases), หรือคำขอที่ผิดรูปแบบที่ควรจะส่งคืน 400 แทนที่จะเป็น 500

Apidog รองรับ การทดสอบที่ขับเคลื่อนด้วยข้อมูล (data-driven testing): แนบชุดข้อมูล CSV หรือ JSON เข้ากับสถานการณ์ แล้วมันจะรันหนึ่งครั้งต่อแถว โดยแทนที่ค่าของแถวนั้นลงในคำขอและการยืนยัน ตัวอย่างเช่น สถานการณ์การล็อกอินอาจรันแถวสำหรับผู้ใช้ที่ถูกต้อง, รหัสผ่านผิด, บัญชีที่ถูกล็อก และ body ที่ว่างเปล่า ซึ่งแต่ละแถวมีรหัสสถานะที่คาดหวังเป็นของตัวเอง

ใน pipeline ไม่มีอะไรเปลี่ยนแปลงเกี่ยวกับรูปแบบของคำสั่ง; คุณยังคงเรียกใช้ apidog run กับสถานการณ์เดิม ชุดข้อมูลจะเดินทางไปพร้อมกับสถานการณ์ ดังนั้นการเรียกใช้ CLI เพียงครั้งเดียวก็ครอบคลุมทุกแถว เมื่อคุณเพิ่มกรณีขอบใหม่ใน Apidog การรัน pipeline ครั้งถัดไปจะรับรู้สิ่งนั้นโดยไม่ต้องแก้ไข YAML นั่นคือผลตอบแทนของการเก็บตรรกะการทดสอบไว้ในเครื่องมือแทนที่จะเป็น pipeline: pipeline ยังคงเรียบง่ายในขณะที่การครอบคลุมการทดสอบของคุณเพิ่มขึ้น

ปัญหาทั่วไปและวิธีแก้ไข

build ผ่านทั้งๆ ที่เอนด์พอยต์เสีย นี่มักจะเป็นปัญหาเกี่ยวกับรหัสออก (exit-code) เสมอ ยืนยันว่า CLI ส่งคืนค่าที่ไม่ใช่ศูนย์เมื่อล้มเหลว (ขั้นตอนที่ 2) และตรวจสอบให้แน่ใจว่าคุณไม่ได้ "กลืน" มัน; การใช้ || true ท้ายคำสั่ง หรือสคริปต์หลายคำสั่งที่จบด้วยคำสั่งอื่น จะปกปิดความล้มเหลวไว้ เก็บการเรียกใช้ apidog run ไว้เป็นคำสั่งที่มีความหมายสุดท้ายในบล็อกสคริปต์ของมัน

apidog: command not found. ขั้นตอนการติดตั้งไม่ได้ทำงาน, ทำงานหลังจากขั้นตอนการทดสอบ, หรือติดตั้งไปยังพาธที่เชลล์ของ agent มองไม่เห็น ยืนยันว่า npm install -g apidog-cli ปรากฏขึ้นก่อนขั้นตอนการรัน บน self-hosted agent บางตัว global npm bin ไม่อยู่ใน PATH; ให้ติดตั้งในเครื่องและเรียกใช้ผ่าน npx apidog run ... แทน

การยืนยันตัวตนล้มเหลวใน CI แต่ใช้งานได้ในเครื่อง ความลับ (secret) ไม่ถึงขั้นตอนนั้น ตัวแปรที่เป็นความลับต้องถูกแมปผ่าน env: (ขั้นตอนที่ 4); พวกมันไม่ได้ถูกฉีดอัตโนมัติ นอกจากนี้ ตรวจสอบว่าโทเค็นไม่ได้ถูกวางพร้อมกับขึ้นบรรทัดใหม่หรือเครื่องหมายคำพูด

การทดสอบเข้าถึงสภาพแวดล้อมที่ไม่ถูกต้อง ค่า -e ชี้ไปยังสภาพแวดล้อม Apidog ที่ผิด หรือ base URL ของสภาพแวดล้อมยังคงอ้างอิง localhost ให้รักษาสภาพแวดล้อม Staging ที่แยกต่างหากซึ่งตัวแปรของมันแก้ไขเป็น URL ที่เข้าถึงได้และปลอดภัยสำหรับ CI และส่ง ID ของมันอย่างชัดเจน

ผลการผ่าน/ไม่ผ่านที่ไม่คงที่ในการรันแต่ละครั้ง มักจะเป็นสถานะที่เปลี่ยนแปลงได้ที่ถูกใช้ร่วมกัน (shared mutable state); การทดสอบที่สร้างบันทึก และการรันในภายหลังที่ชนกับบันทึกนั้น ทำให้สถานการณ์เป็นอิสระ: สร้างสิ่งที่ต้องการ ยืนยัน จากนั้นล้างข้อมูล หรือใช้ตัวระบุที่ไม่ซ้ำกันต่อการรัน เพื่อให้การรันซ้ำไม่ชนกับข้อมูลของวันก่อน หากคุณกำลังย้ายจากเครื่องมืออื่น รูปแบบใน วิธีการรันการทดสอบ API ใน CI โดยไม่มี Newman ก็ครอบคลุมถึงข้อผิดพลาดในการแยกตัวที่คล้ายกัน

เหนือกว่าพื้นฐาน

• ตั้งเวลาการรันรายคืน เพิ่ม schedules trigger เพื่อรันชุดทดสอบทั้งหมดในเวลา 02:00 น. กับ staging เพื่อให้คุณตรวจจับความเปลี่ยนแปลงที่เกิดจากการเปลี่ยนแปลงข้อมูลหรือการเปลี่ยนแปลง API ของบุคคลที่สาม แม้ในวันที่ไม่มีใคร push โค้ด
• แยกชุดทดสอบที่เร็วและช้า รัน smoke scenario อย่างรวดเร็วในทุก PR เพื่อการตอบรับที่รวดเร็ว และรัน full regression suite เมื่อรวม (merge) เข้ากับ main การนิยาม pipeline สองชุด ใช้ CLI ตัวเดียวกัน
• ทดสอบหลายสภาพแวดล้อมใน matrix ใช้ pipeline matrix เพื่อรันสถานการณ์เดียวกันกับ staging และสภาพแวดล้อม pre-prod แบบขนานกัน โดยแต่ละตัวมี Environment ID ของตัวเอง
• สร้างด่านตรวจสอบการปรับใช้ (deploy) ไม่ใช่แค่การรวม (merge) เท่านั้น วาง API test stage ก่อน deploy stage ของคุณใน multi-stage pipeline เพื่อให้การทดสอบที่ล้มเหลวหยุดการเผยแพร่ ไม่ใช่แค่การรวม

แต่ละข้อเหล่านี้เป็นการเพิ่มเติมเล็กน้อยจากรากฐานเดียวกัน: CLI ที่ออกจากระบบอย่างราบรื่นและ pipeline ที่เคารพ exit code

คำถามที่พบบ่อย

ฉันจำเป็นต้องเขียนโค้ดเพื่อรันการทดสอบ API ใน Azure Pipelines หรือไม่? ไม่ คุณสร้างสถานการณ์การทดสอบด้วยภาพใน Apidog และ pipeline จะรันมันด้วยคำสั่ง CLI เพียงคำสั่งเดียว "โค้ด" เดียวคือ azure-pipelines.yml ซึ่งเป็นการกำหนดค่า ไม่ใช่ตรรกะการทดสอบ หากคุณต้องการการทดสอบที่ใช้สคริปต์ทั้งหมด คุณก็ยังสามารถทำได้ แต่จุดประสงค์ของเวิร์กโฟลว์นี้คือการข้ามการเขียนโค้ด

ฉันสามารถรัน Postman collections ที่มีอยู่ของฉันใน Azure Pipelines แทนได้หรือไม่? ทำได้ โดยปกติจะใช้ Newman หรือ runner ที่คล้ายกัน หากคุณกำลังพิจารณาตัวเลือกต่างๆ Apidog สามารถนำเข้า Postman collections ได้โดยตรง ดังนั้นคุณจึงสามารถนำการทดสอบที่มีอยู่มาใช้และรันผ่าน CLI เดียวกันโดยไม่ต้องดูแลรักษา toolchain แยกต่างหาก ดู วิธีการรันการทดสอบ API ใน CI โดยไม่มี Newman เพื่อเปรียบเทียบ

การทดสอบควรชี้ไปที่ใด; staging หรือ production? สภาพแวดล้อม staging หรือ per-branch preview environment เกือบตลอดเวลา การรันการทดสอบที่เขียนข้อมูลจำนวนมากกับ production จะทำให้ข้อมูลจริงปนเปื้อนและอาจก่อให้เกิดผลข้างเคียงจริงได้ รักษา Apidog environment เฉพาะสำหรับ CI ที่มี base URL ที่ปลอดภัย และส่ง ID ของมันไปยัง CLI ด้วย -e

Pipeline รู้ได้อย่างไรว่าการทดสอบล้มเหลว? ผ่านรหัสออก (exit code) apidog run จะส่งคืน 0 เมื่อการยืนยันทั้งหมดผ่าน และรหัสที่ไม่ใช่ศูนย์เมื่อมีรายการใดล้มเหลว Azure Pipelines จะทำให้ script task ล้มเหลวเมื่อมีรหัสออกที่ไม่ใช่ศูนย์ ซึ่งจะทำให้ build ล้มเหลว ตรวจสอบสิ่งนี้ในเครื่องของคุณด้วย echo $? สักครั้งเพื่อให้คุณมั่นใจในด่านตรวจสอบ

สิ่งนี้ใช้ได้กับ Azure DevOps Classic (UI) pipelines ด้วยหรือไม่ ไม่ใช่แค่ YAML? ได้ ขั้นตอนเดียวกันนี้สามารถนำไปใช้ได้; เพิ่ม task “Use Node”, command-line task ที่รัน npm install -g apidog-cli, และ command-line task อีกตัวที่รัน apidog run ... แนะนำให้ใช้ YAML เพราะมันอยู่ใน repo ของคุณและมีการควบคุมเวอร์ชัน แต่ runner ไม่ได้สนใจว่าขั้นตอนต่างๆ ถูกกำหนดไว้อย่างไร

ฉันสามารถใช้ self-hosted agent แทน Microsoft-hosted agent ได้หรือไม่? ได้ self-hosted agent ทำงานในลักษณะเดียวกัน; เพียงแค่ต้องแน่ใจว่าได้ติดตั้ง Node.js แล้ว และ global npm bin อยู่ใน PATH ของ agent หรือเรียกใช้ CLI ผ่าน npx self-hosted agent มีประโยชน์เมื่อ staging API ของคุณสามารถเข้าถึงได้จากภายในเครือข่ายส่วนตัวเท่านั้น

สรุป

build CI ที่เป็นสีเขียวควรหมายถึง API ของคุณทำงานได้จริง ไม่ใช่แค่ว่าโค้ดคอมไพล์ได้ การไปถึงจุดนั้นใน Azure Pipelines ประกอบด้วยสี่ขั้นตอน: ออกแบบสถานการณ์การทดสอบจริงใน Apidog, รันมันโดยอัตโนมัติ (headlessly) ด้วย Apidog CLI, ให้ exit code เป็นตัวกำหนดสถานะ build และกำหนดให้ build ต้องผ่านก่อนที่จะมีการรวม (merge) สิ่งใดๆ เมื่อวงจรนี้ทำงาน ทุกการ push จะได้รับการตรวจสอบอย่างละเอียดถี่ถ้วนแบบเดียวกับที่เพื่อนร่วมทีมที่ระมัดระวังที่สุดของคุณจะทำ โดยอัตโนมัติทุกครั้ง

เหตุผลที่สิ่งนี้ยังคงดูแลรักษาได้คือการแยกส่วน ตรรกะการทดสอบอยู่ใน Apidog ซึ่งอยู่ใกล้กับสเปค API ของคุณและง่ายต่อการขยาย Pipeline ยังคงเป็นเพียง wrapper บางๆ; ติดตั้ง, รัน, รายงาน เมื่อ API ของคุณเติบโตขึ้น คุณก็เพิ่มสถานการณ์และแถวข้อมูลในเครื่องมือ และ pipeline ก็ยังคงทำงานเดียวของมันโดยไม่ต้องแก้ไข

พร้อมที่จะตั้งค่าแล้วหรือยัง? ดาวน์โหลด Apidog, สร้างสถานการณ์การทดสอบ, คัดลอกคำสั่งรัน CLI, และวางลงในไฟล์ azure-pipelines.yml ของคุณ ข้อผิดพลาดที่ย้อนกลับไปครั้งถัดไปของคุณจะถูกจับโดยเครื่องจักร แทนที่จะเป็นลูกค้า