Apidog CLI ปะทะ Postman CLI: ตัวรันการทดสอบ CI ตัวไหนดีกว่า

การทดสอบ API ของคุณผ่านเมื่อคุณคลิก Run บนแล็ปท็อป นั่นไม่ได้พิสูจน์อะไรเลย การทดสอบที่สำคัญคือการทดสอบที่ทำงานทุกครั้งที่มี pull request, ทุกครั้งที่มีการ merge, และทุกครั้งที่มี nightly build โดยไม่มีมนุษย์มาคลิกอะไรเลย หน้าที่ของการนำการทดสอบของคุณเข้าสู่กระบวนการนี้เป็นของ command-line runner มันจะนำการทดสอบที่คุณเขียนไว้แล้วไปรันแบบ Headless ภายใน Pipeline ของคุณ ออกด้วยรหัสสถานะที่ CI ของคุณสามารถอ่านได้ และเขียนรายงานที่แสดงบนแดชบอร์ดของ Build

มี Runner สองตัวที่ทีมมักจะนำมาใช้ซ้ำๆ เมื่อทำการเชื่อมต่อระบบนี้ ได้แก่ Postman CLI และ Apidog CLI ทั้งสองมีเป้าหมายเดียวกันแต่เริ่มต้นจากจุดที่แตกต่างกัน Postman CLI จะรัน Collection ที่คุณสร้างใน Postman ส่วน Apidog CLI จะรัน Scenario การทดสอบแบบ Visual ที่คุณสร้างใน Apidog ทั้งสองติดตั้งได้ในขั้นตอนเดียว ทั้งสองสามารถเชื่อมต่อกับ GitHub Actions, GitLab CI และ Jenkins ได้ และทั้งสองจะทำให้ Build เป็นสีแดงเมื่อการทดสอบล้มเหลว ความแตกต่างที่แท้จริงจะอยู่ก่อนคำสั่ง Run คือ: วิธีที่คุณสร้างการทดสอบ, วิธีที่คุณยืนยันตัวตนใน CI และตำแหน่งที่นิยามการทดสอบอยู่จริง

💡

นี่คือการเปรียบเทียบระดับคำสั่งของทั้งสอง ไม่มีข้อโต้แย้งที่ตั้งขึ้นมาเพื่อโจมตี Postman CLI ทำสิ่งต่างๆ ได้ดีหลายอย่าง และคุณจะได้เห็นว่า Runner แต่ละตัวเหมาะกับส่วนใดก่อนที่คุณจะนำไปใช้ใน Pipeline หากคุณเพิ่งเริ่มใช้ Apidog มันคือแพลตฟอร์ม API แบบ All-in-one ที่ครอบคลุมการออกแบบ, การดีบัก, การทดสอบ, การจำลอง และการจัดทำเอกสารใน Workspace เดียวกัน และ CLI คือส่วนที่นำการทดสอบของคุณไปสู่ระบบอัตโนมัติ

ดาวน์โหลดแอป

สรุปโดยย่อ

Postman CLI (ไบนารี postman) จะรัน Collection ที่เก็บอยู่ใน Postman Workspace ของคุณ โดยอิงจาก Newman ซึ่งได้รับการรับรองและสนับสนุนโดย Postman และยืนยันตัวตนด้วย Postman API Key เมื่อคุณลงชื่อเข้าใช้ ระบบจะส่งผลการรันกลับไปยัง Postman Cloud โดยอัตโนมัติ
Apidog CLI (`apidog-cli`, ไบนารี `apidog`) จะรัน Scenario การทดสอบที่คุณออกแบบแบบ Visual ใน Apidog คุณสามารถระบุ Scenario ด้วย ID พร้อม Access Token และมันจะดำเนินการ Scenario นั้นแบบ Headless โดยไม่มี GUI
ทั้งคู่สร้างรายงานในรูปแบบ JUnit, JSON, HTML และ Terminal ทั้งคู่จะทำให้ Build ล้มเหลวเมื่อการทดสอบไม่ผ่าน JUnit XML คือสิ่งที่เชื่อมต่อเข้ากับแดชบอร์ด CI ในทั้งสองกรณี
เลือก **Postman CLI** เมื่อการทดสอบของคุณอยู่ใน Postman Collection อยู่แล้ว และทีมของคุณใช้ Postman Cloud สำหรับการรายงานและบันทึกประวัติ
เลือก **Apidog CLI** เมื่อคุณต้องการสร้าง Scenario แบบ Visual, การเชื่อมโยงคำขอ (request chaining), การจัดการ Environment และการรันแบบ Data-driven จากแหล่งข้อมูลเดียว โดยมีการควบคุมเต็มรูปแบบว่าจะให้รายงานอยู่แบบ Local หรือส่งไปยัง Cloud

ปัญหาที่แท้จริง: การทดสอบที่มีอยู่แต่ไม่เคยถูกรัน

การทดสอบที่คุณรันด้วยมือคือการทดสอบที่จะเสื่อมสภาพลง มีคนเขียนมันขึ้นมา มันเคยผ่านครั้งหนึ่ง แล้วก็ถูกปล่อยทิ้งไว้โดยไม่มีการแตะต้อง ในขณะที่ API เปลี่ยนแปลงไป สามเดือนต่อมาการทดสอบนั้นก็ผิดพลาดและไม่มีใครสังเกตเห็น เพราะไม่มีใครรันมัน วิธีแก้ไขไม่ใช่การเขียนการทดสอบเพิ่ม แต่เป็นการทำให้การทดสอบที่คุณมีรันโดยอัตโนมัติทุกครั้งที่มีการเปลี่ยนแปลง พร้อมสัญญาณผ่านหรือไม่ผ่านที่ Pipeline สามารถดำเนินการได้

CLI Runner คือเครื่องมือที่ช่วยเติมเต็มช่องว่างนั้น เพื่อให้มีบทบาทใน CI มันจะต้องทำสามสิ่ง มันจะต้องทำงานโดยไม่มี GUI เพราะ CI Runner ของคุณไม่มีหน้าจอ มันจะต้องออกด้วยค่าที่ไม่ใช่ศูนย์เมื่อมีบางอย่างล้มเหลว เพื่อให้ Build เป็นสีแดงและบล็อกการ Merge ที่มีปัญหา และมันจะต้องเขียนรายงานที่เครื่องสามารถอ่านได้ เพื่อให้ผู้ตรวจสอบเห็นว่าอะไรเสียโดยไม่ต้องรันซ้ำในเครื่อง Postman CLI และ Apidog CLI ทั้งคู่ทำสิ่งเหล่านี้ได้อย่างไร้ที่ติ จุดที่ทั้งสองแยกจากกันคือทุกสิ่งที่เกิดขึ้นก่อนคำสั่ง run: วิธีการเขียนการทดสอบ และตำแหน่งที่มันอยู่เมื่อ CI กำลังมองหา

หากคุณกำลังตั้งค่าการทดสอบอัตโนมัติจากศูนย์ รูปแบบที่กว้างขึ้นในการ ทำให้การทดสอบ API เป็นไปโดยอัตโนมัติใน CI/CD นั้นคุ้มค่าที่จะอ่านควบคู่ไปกับบทความนี้ ในที่นี้ เราจะมุ่งเน้นที่ Runner ทั้งสอง

Postman CLI ทำอะไรได้ดี

ประการแรก สิ่งที่ทำให้หลายคนสับสนคือ: Postman CLI ไม่ใช่ Newman Newman เป็น Runner แบบ Open-source ที่ใช้ npm ซึ่งชุมชนใช้งานมาหลายปีแล้ว Postman CLI เป็นเครื่องมือใหม่กว่า สร้างขึ้นบนพื้นฐานของ Newman แต่ได้รับการลงนามและสนับสนุนอย่างเป็นทางการโดยบริษัท Postman หากคุณใช้ Newman มาก่อน ทั้งสองสิ่งนี้ไม่สามารถใช้แทนกันได้ และความแตกต่างก็มีความสำคัญใน CI เราได้เขียนความแตกต่างที่ชัดเจนนั้นไว้ใน Postman CLI vs Newman หากคุณกำลังตัดสินใจเลือกระหว่างสองทางเลือกในฝั่ง Postman

จุดแข็งที่สำคัญที่สุดของ Postman CLI คือการที่มันยังคงอยู่ในโลกที่ทีมของคุณคุ้นเคยอยู่แล้ว หาก Collection, Environment และ Shared Variable ของคุณอยู่ใน Postman Workspace อยู่แล้ว CLI จะรันสิ่งเหล่านั้นโดยแทบไม่ต้องมีการแปลอะไรเลย คุณไม่จำเป็นต้องสร้างอะไรใหม่ คุณเพียงแค่ยืนยันตัวตน ระบุชื่อ Collection แล้วมันจะรัน Request และ Test ได้เหมือนกับที่แอปพลิเคชันทำทุกประการ

การติดตั้งทำได้ด้วยคำสั่งเดียว บน macOS และ Linux คุณสามารถรันสคริปต์การติดตั้งอย่างเป็นทางการได้:

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

บน Windows คุณจะใช้ Signed PowerShell Installer และยังมี npm package ให้เลือกใช้หากคุณต้องการกำหนดเป็น dev dependency:

npm install -g postman-cli

ไบนารีคือ postman ใน CI คุณจะยืนยันตัวตนด้วย Postman API Key ซึ่งเป็นวิธีการที่ Postman แนะนำสำหรับ Pipeline:

postman login --with-api-key $POSTMAN_API_KEY

จากนั้นคุณจะรัน Collection ด้วย ID หรือด้วยพาธไฟล์ในเครื่องหากคุณได้ Export ออกมา:

postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID

ส่วนที่ทำให้ Postman CLI ได้รับความภักดีอย่างมากคือสิ่งที่เกิดขึ้นหลังจากการรัน เมื่อคุณลงชื่อเข้าใช้ ระบบจะส่งผลการรันตรงไปยัง Postman Cloud ซึ่งจะแสดงใน Workspace ของคุณพร้อมกับ Collection ประวัติการทดสอบ การเปรียบเทียบการรัน และแดชบอร์ดที่ทีมมองเห็นได้นั้นมีอยู่ทั้งหมดโดยไม่ต้องมีการตั้งค่าเพิ่มเติม สำหรับทีมที่ใช้ Postman อยู่แล้ว การส่งข้อมูลไปกลับนี้มีประโยชน์อย่างแท้จริง และเป็นเหตุผลที่สมเหตุสมผลที่จะใช้งานต่อไป

Apidog CLI ทำอะไรได้ดี

Apidog ใช้วิธีที่แตกต่างกันสำหรับ Pipeline เดียวกัน คุณสร้างการทดสอบแบบ Visual ภายในแอป Apidog: เชื่อมโยง Request หลายรายการเข้าเป็น Scenario การทดสอบเดียว เพิ่ม Assertion ในแต่ละ Response ดึงค่าจาก Response หนึ่งและส่งไปยัง Request ถัดไป และวน Scenario ทั้งหมดด้วยไฟล์ข้อมูล CLI เป็น Executor แบบ Headless สำหรับ Scenario เหล่านั้น มันไม่มีรูปแบบการทดสอบของตัวเอง มันจะเข้าไปใน Apidog Project ของคุณ ค้นหา Scenario ที่คุณระบุด้วย ID และรันมันเหมือนกับที่แอปพลิเคชันทำทุกประการ จากนั้นจึงรายงานผลกลับมา

ผลลัพธ์คือไม่มีใครต้องดูแลการทดสอบเดียวกันสองชุด Scenario ที่คุณสร้างใน Visual Editor คือการทดสอบที่รันใน CI ไม่มีขั้นตอนที่คุณต้องเขียนการทดสอบที่ทำงานได้ใหม่เป็นสคริปต์แล้วดีบักสคริปต์นั้น การสร้างแบบรวดเร็วและวงจรการทำงานอัตโนมัติใช้แหล่งข้อมูลเดียวกัน สำหรับ Flow ที่มีหลายขั้นตอน เช่น เข้าสู่ระบบแล้วสร้างแล้วอ่านแล้วลบ การเชื่อมโยงแบบ Visual นั้นช่วยประหยัด Code เชื่อมต่อจำนวนมากที่คุณจะต้องเขียนด้วยมือ กลไกของการสร้าง Flow เหล่านั้นครอบคลุมอยู่ในคู่มือ Test Scenarios สำหรับการทำ API Test Automation

การติดตั้งทำได้ด้วยคำสั่ง npm เดียว:

npm install -g apidog-cli

ไบนารีคือ apidog การรันทั่วไปจะระบุ Scenario ด้วย ID, เลือก Environment, กำหนดจำนวน Iteration และยืนยันตัวตนด้วย Access Token:

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

คุณไม่จำเป็นต้องพิมพ์ ID เหล่านั้นด้วยมือ เปิด Scenario การทดสอบใน Apidog ไปที่แท็บ CI/CD คลิกเพื่อสร้าง Access Token แล้ว Apidog จะสร้างคำสั่งเต็มรูปแบบให้คุณโดยมี Scenario ID และ Environment ID กรอกไว้ให้แล้ว คุณเพียงคัดลอกครั้งเดียว ย้าย Token ไปยัง CI secret และอ้างอิงถึงมันเป็น `$APIDOG_ACCESS_TOKEN` ใน Workflow ของคุณ

รูปแบบ Token และ ID คือความแตกต่างที่ชัดเจนที่สุดจาก Postman CLI Apidog รันการทดสอบที่เก็บไว้ใน Project ซึ่ง CLI ดึงข้อมูลผ่านเครือข่าย โดยยืนยันตัวตนด้วย Token นอกจากนี้ยังไม่มีตัวเลือก Cloud Opt-in แยกต่างหากสำหรับการรายงาน: คุณเลือก `--out-dir` สำหรับ Artifacts แบบ Local และเพิ่ม `--upload-report` เฉพาะเมื่อคุณต้องการให้ภาพรวมถูกส่งไปยัง Apidog Cloud รายงานจะยังคงอยู่ ณ ตำแหน่งที่คุณวางไว้

เปรียบเทียบเคียงข้าง

มิติ	Postman CLI (`postman`)	Apidog CLI (`apidog`)
แพ็คเกจ / การติดตั้ง	สคริปต์ติดตั้ง, ตัวติดตั้งที่ลงนาม, หรือ `npm i -g postman-cli`	`npm i -g apidog-cli`
คำสั่ง Run	`postman collection run <id\|file>`	`apidog run -t <scenarioId>`
แหล่งที่มาของการทดสอบ	Collections ใน Postman workspace ของคุณ (หรือไฟล์ที่ export)	Test scenarios ใน Apidog project ของคุณ, ดึงข้อมูลด้วย ID
การสร้าง	Collection editor และแอป Postman	Visual scenario builder ในแอป Apidog
การยืนยันตัวตนใน CI	Postman API key (`postman login --with-api-key`)	Access token (`--access-token`)
เลือกสิ่งที่รัน	Collection ID หรือ File path	`-t` scenario, `-f` folder, `--test-suite`
Environment	`-e, --environment`	`-e, --environment <environmentId>`
Data-driven	`-d, --iteration-data` (JSON หรือ CSV)	`-d, --iteration-data` (JSON หรือ CSV)
จำนวน Iteration	`-n, --iteration-count`	`-n, --iteration-count`
Reporters	`cli`, `json`, `junit`, `html`	`cli`, `html`, `json`, `junit`
Fail-fast	`--bail`	`--on-error end` (ค่าเริ่มต้นคือหยุดเมื่อเกิดข้อผิดพลาดครั้งแรก)
การรายงานบน Cloud	ส่งผลลัพธ์โดยอัตโนมัติเมื่อลงชื่อเข้าใช้	เลือกใช้ผ่าน `--upload-report`
สร้างบนพื้นฐานของ	Newman	Engine ของ Apidog เอง

มีสองสิ่งเด่นชัดจากตารางนั้น ประการแรก ทั้ง Runner สองตัวครอบคลุมสิ่งจำเป็นของ CI ในรูปแบบที่เกือบจะเหมือนกัน: การเลือก Environment, การทำซ้ำแบบ Data-driven, รูปแบบรายงานทั้งสี่ที่สำคัญ และการจบการทำงานด้วยสถานะที่ไม่ใช่ศูนย์เมื่อเกิดข้อผิดพลาด หากสิ่งที่คุณต้องการคือ Runner ที่จะทำให้ Build เป็นสีแดงเมื่อ Merge มีปัญหา ตัวใดตัวหนึ่งก็สามารถทำงานได้ ประการที่สอง ความแตกต่างที่แท้จริงคือตำแหน่งที่การทดสอบอยู่และวิธีที่คุณเขียนมัน Postman CLI รัน Collection ที่อยู่ใน Postman workspace ของคุณ Apidog CLI รัน Scenario แบบ Visual ที่อยู่ใน Apidog project ของคุณ

Reporters และ Exit Code: ส่วนที่ CI อ่านจริงๆ

Runner พิสูจน์คุณค่าของมันใน Pipeline ผ่านพฤติกรรมสองอย่าง: รายงานที่มันเขียน และ Exit Code ที่มันส่งคืน หากทำสองสิ่งนี้ถูกต้องทุกอย่างที่เหลือก็คือการเชื่อมต่อ

Postman CLI รับรายการ Reporter ที่คั่นด้วยเครื่องหมายจุลภาค และเมื่อคุณลงชื่อเข้าใช้ มันก็จะส่งผลลัพธ์ไปยัง Postman Cloud ด้วยเช่นกัน:

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

Reporter แบบ junit คือตัวที่แดชบอร์ด CI ของคุณจะแยกวิเคราะห์เป็นโครงสร้างแบบผ่านหรือไม่ผ่าน (pass or fail tree) แฟล็ก --bail จะหยุดการรันที่ Request, Test หรือ Assertion ที่ล้มเหลวครั้งแรก ซึ่งช่วยให้การตอบกลับรวดเร็วในการทดสอบ Smoke test หากคุณไม่ใช้ --bail มันจะรันทุกอย่าง จากนั้นจึงรายงานความล้มเหลวทั้งหมดพร้อมกัน CLI จะออกด้วยค่าที่ไม่ใช่ศูนย์เมื่อเกิดความล้มเหลวใดๆ ดังนั้น Build จึงจะเปลี่ยนเป็นสีแดงได้ด้วยตัวเอง

Apidog CLI ใช้แนวคิด Reporter แบบ -r เดียวกัน และเขียนทุกอย่างภายใต้ไดเรกทอรีเอาต์พุตเดียว:

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

แฟล็ก --on-error ของมันจะกำหนดพฤติกรรมระหว่าง Scenario: end จะหยุดเมื่อเกิดความล้มเหลวครั้งแรกและเป็นค่าเริ่มต้น, continue จะรันทุกขั้นตอนเพื่อให้คุณรวบรวมความล้มเหลวทั้งหมดไว้ในรายงานเดียว, และ ignore จะข้ามขั้นตอนที่รู้ว่าอาจไม่เสถียรโดยไม่ทำให้การรันหยุดชะงัก ไม่ว่าจะด้วยวิธีใด กระบวนการจะจบลงด้วยค่าที่ไม่ใช่ศูนย์หากมีสิ่งใดล้มเหลว และ JUnit XML จะอยู่ใน ./apidog-reports พร้อมให้แดชบอร์ดของคุณนำไปใช้

ผลลัพธ์ในทางปฏิบัติ: ทั้งสองเขียน JUnit XML, ทั้งสองทำให้ Build ล้มเหลวได้อย่างถูกต้อง และทั้งสองเก็บรายงาน HTML ที่คุณสามารถเปิดดูภายหลังได้ ความแตกต่างในการรายงานคือการส่งข้อมูลไปกลับ Cloud Postman จะส่งผลลัพธ์ไปยัง Cloud ของตนโดยอัตโนมัติเมื่อคุณยืนยันตัวตนแล้ว Apidog จะเก็บรายงานไว้ในเครื่องเว้นแต่คุณจะขอให้อัปโหลด ไม่มีตัวใดดีกว่าในทางนามธรรม; ตัวหนึ่งเหมาะกับทีมที่ต้องการประวัติการทำงานแบบโฮสต์โดยไม่ต้องคิดมาก ส่วนอีกตัวหนึ่งเหมาะกับทีมที่ต้องการตัดสินใจอย่างแม่นยำว่าข้อมูลใดจะออกจาก Runner ไป

การเชื่อมต่อแต่ละตัวเข้ากับ GitHub Actions

รูปแบบของ GitHub Actions job จะเหมือนกันสำหรับทั้งสอง: check out repo, ตั้งค่า Node, ติดตั้ง CLI, รันการทดสอบ, และเมื่อ exit code แสดงความล้มเหลวจะบล็อกการ merge เก็บ secret ไว้ในการตั้งค่า Repository ของคุณ ห้ามเก็บไว้ในไฟล์ Workflow เด็ดขาด

นี่คือเวอร์ชัน 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

และนี่คือเวอร์ชัน 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

ทั้งคู่สั้น อ่านง่าย และมีพฤติกรรมเหมือนกันในระดับที่ Pipeline ของคุณให้ความสำคัญ: การรันที่ผ่านจะออกด้วยค่าศูนย์และ Merge จะดำเนินการต่อ การรันที่ล้มเหลวจะออกด้วยค่าที่ไม่ใช่ศูนย์และ Merge จะถูกบล็อก หากคุณต้องการดูรายละเอียดเพิ่มเติมเกี่ยวกับการรัน API Tests ใน GitHub Workflow, API test automation with GitHub Actions จะอธิบายเป็นขั้นตอน สำหรับผู้ใช้ Jenkins แนวคิดเดียวกันนี้มีอยู่ใน การผสานรวม Apidog automated tests กับ Jenkins

แล้วตัวไหนชนะใน CI?

ไม่มีผู้ชนะเพียงหนึ่งเดียว เพราะคำตอบที่ถูกต้องขึ้นอยู่กับว่าการทดสอบของคุณอยู่แล้วที่ไหน และทีมของคุณต้องการสร้างและจัดเก็บอย่างไร

Apidog CLI ชนะเมื่อคุณให้ความสำคัญกับการสร้างแบบ Visual และ Single Source of Truth มากกว่าประวัติบน Cloud ที่โฮสต์อยู่ คุณสร้าง Scenario เพียงครั้งเดียวใน Visual Editor โดยมีการจัดการ Request Chaining และ Assertion ให้คุณ และ Scenario เดียวกันนั้นก็รันใน CI ได้ด้วยการอ้างอิง คุณเป็นผู้ตัดสินใจว่าจะเก็บรายงานไว้ในเครื่องหรืออัปโหลด และเนื่องจาก Apidog ครอบคลุมการออกแบบ, การจำลอง (Mocking) และการจัดทำเอกสารใน Workspace เดียวกัน Scenario การทดสอบจึงอยู่ข้างๆ API Contract ที่มันตรวจสอบ ซึ่งช่วยให้ Test และ Spec ไม่แตกต่างกัน ทีมที่พิจารณาแพลตฟอร์มในวงกว้างสามารถอ่าน การเปรียบเทียบ Apidog กับ Postman ได้อย่างเต็มรูปแบบ

Postman CLI ชนะเมื่อทีมของคุณใช้ Postman อยู่แล้ว Collection ของคุณอยู่ที่นั่น Environment ของคุณอยู่ที่นั่น และคุณต้องการประวัติการรันใน Postman Cloud โดยไม่ต้องตั้งค่าอะไรเลย การส่งข้อมูลไปกลับ Cloud ในทุกครั้งที่รันเป็นความสะดวกสบายอย่างแท้จริงสำหรับการตั้งค่าแบบนั้น และเครื่องมือนี้ได้รับการลงนามและสนับสนุนอย่างเป็นทางการ หากนั่นคือลักษณะทีมของคุณ การเปลี่ยน Runner ก็แทบจะไม่มีประโยชน์เลย

หากคุณรู้สึกว่าติดกับรูปแบบ Postman Cloud หรือคุณแค่อยากจะเขียนการทดสอบครั้งเดียวแล้วรันได้ทุกที่ การย้ายไปใช้ก็ชัดเจน ดาวน์โหลด Apidog สร้าง Scenario เปิดแท็บ CI/CD แล้วคัดลอกคำสั่ง apidog run ที่สร้างขึ้นไปใส่ใน Pipeline ของคุณ นั่นคือการตั้งค่าทั้งหมด

ดาวน์โหลดแอป

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

Postman CLI เหมือนกับ Newman หรือไม่? ไม่ใช่ Newman เป็น Runner แบบ Open-source ที่ใช้ npm ที่เก่ากว่า Postman CLI เป็นเครื่องมือใหม่กว่าที่สร้างขึ้นบนพื้นฐานของ Newman ซึ่งได้รับการลงนามและสนับสนุนโดย Postman พร้อมด้วยการรายงานผลไปยัง Postman Cloud ในตัว หากคุณกำลังเลือกระหว่างสองตัวเลือกในฝั่ง Postman, Postman CLI vs Newman จะอธิบายความแตกต่าง
ฉันจำเป็นต้องมีบัญชีหรือ Token สำหรับ CLI ใดๆ ใน CI หรือไม่? ต้องมีทั้งคู่ แต่รูปแบบจะแตกต่างกัน Postman CLI ยืนยันตัวตนด้วย Postman API Key ผ่าน postman login --with-api-key ส่วน Apidog CLI ยืนยันตัวตนด้วย Access Token ที่ส่งผ่าน --access-token เก็บทั้งสองอย่างเป็น CI secret ห้ามเก็บไว้ในไฟล์ Workflow เด็ดขาด
Runner ทั้งสองตัวจะทำให้ Build ล้มเหลวเมื่อการทดสอบไม่ผ่านหรือไม่? ใช่ ทั้งคู่จะออกด้วยรหัสสถานะที่ไม่ใช่ศูนย์เมื่อมีการทดสอบหรือ Assertion ที่ล้มเหลว ซึ่งเป็นสิ่งที่บอกระบบ CI ของคุณให้ทำเครื่องหมาย Build เป็นสีแดงและบล็อกการ Merge Postman CLI ใช้ --bail เพื่อหยุดเมื่อเกิดความล้มเหลวครั้งแรก; ส่วน Apidog CLI ใช้ --on-error end ซึ่งเป็นค่าเริ่มต้น
ฉันสามารถเก็บรายงานไว้ในเครื่องแทนที่จะส่งไปยัง Cloud ได้หรือไม่? Apidog CLI จะเก็บรายงานไว้ในเครื่องตามค่าเริ่มต้นและเขียนลงใน --out-dir; คุณจะอัปโหลดด้วย --upload-report เท่านั้น Postman CLI ก็เขียนรายงานในเครื่องได้เช่นกัน แต่เมื่อคุณลงชื่อเข้าใช้ มันก็จะส่งผลการรันไปยัง Postman Cloud โดยอัตโนมัติ
ฉันจะหาคำสั่ง Apidog run ที่ถูกต้องสำหรับ Scenario ของฉันได้อย่างไร? เปิด Scenario การทดสอบใน Apidog ไปที่แท็บ CI/CD สร้าง Access Token แล้ว Apidog จะสร้างคำสั่ง apidog run เต็มรูปแบบให้คุณโดยมี Scenario ID และ Environment ID กรอกไว้ให้แล้ว คัดลอก ย้าย Token ไปยัง CI secret และคุณก็ทำเสร็จแล้ว สำหรับแฟล็กที่มีอยู่ทั้งหมด ให้รัน apidog run --help
ทีมที่กำลังย้ายออกจาก Postman Cloud ควรสเลือกตัวไหน? หากเหตุผลที่คุณย้ายออกคือรูปแบบที่เน้น Cloud หรือเรื่องราคา Apidog CLI จะเหมาะสม เพราะมันรัน Scenario แบบ Visual เดียวจาก Project ของคุณและให้คุณตัดสินใจว่าจะให้ข้อมูลใดออกจาก Runner เริ่มต้นด้วย การเปรียบเทียบ Apidog กับ Postman เพื่อดูว่าแพลตฟอร์มต่างๆ มีความสอดคล้องอย่างไรนอกเหนือจาก Runner