Apidog CLI vs Newman: รัน API Tests ใน CI (2026)

การทดสอบ API ของคุณผ่านบนแล็ปท็อปของคุณ คำถามที่ยากกว่าคือการทดสอบเหล่านั้นทำงานกับทุก Pull Request, ทุกการผสาน (Merge) และทุก Nightly Build โดยที่มนุษย์ไม่ต้องคลิกอะไรเลยหรือไม่ งานนั้นเป็นของ Command-line Runner มันนำการทดสอบที่คุณเขียนไว้แล้วไปดำเนินการโดยไม่มี UI ภายใน Pipeline ของคุณ ออกจากโปรแกรมด้วยรหัสสถานะที่ CI ของคุณสามารถอ่านได้ และเขียนรายงานที่แดชบอร์ดของคุณสามารถแยกวิเคราะห์ได้ ไม่มี GUI, ไม่มีขั้นตอนด้วยตนเอง, ไม่มีข้ออ้างที่จะข้ามการทำงาน

เป็นเวลาหลายปีที่คำตอบเริ่มต้นสำหรับความต้องการนั้นคือ Newman ซึ่งเป็น Command-line Collection Runner แบบโอเพนซอร์สของ Postman มันเป็นเครื่องมือที่แข็งแกร่งและเข้าใจกันดี และหลายทีมยังคงเลือกใช้เป็นอันดับแรก แต่ถ้าคุณเขียนการทดสอบใน Apidog แทน Postman คุณมีอีกทางเลือกหนึ่งคือ Apidog CLI ซึ่งรันสถานการณ์การทดสอบเดียวกันกับที่คุณสร้างด้วยภาพในแอป โดยไม่มี UI ใน CI บทความนี้เป็นการเปรียบเทียบในระดับคำสั่งอย่างซื่อสัตย์ระหว่างสองเครื่องมือนี้ ครอบคลุมสิ่งที่ Newman ทำได้ดี, ตำแหน่งที่ Apidog CLI เข้ากันได้ และความรู้สึกในการใช้งานของแต่ละเครื่องมือเมื่อเชื่อมต่อเข้ากับ Pipeline จริง

สรุป (TL;DR)

• Newman (newman, ติดตั้งผ่าน npm install -g newman) รันไฟล์ JSON ของ Postman Collection ที่ส่งออก มันเป็นโอเพนซอร์ส ฟรี และอ่าน Collection รวมถึงไฟล์ Environment จากดิสก์หรือ URL รองรับ Environments, ไฟล์ข้อมูล, จำนวนรอบ และตัวรายงานแบบ JUnit/JSON/HTML และจะออกด้วยรหัสที่ไม่ใช่ศูนย์เมื่อการทดสอบล้มเหลว
• Apidog CLI (apidog-cli, ไบนารี apidog) รันสถานการณ์การทดสอบที่คุณออกแบบในแอป Apidog โดยดึงข้อมูลด้วย ID โดยใช้ Access Token คุณไม่ต้องส่งออกอะไรเลยหรือดูแลไฟล์ JSON ด้วยตนเอง สถานการณ์แบบภาพคือการทดสอบ และ CLI จะรันตามที่แอปจะทำทุกประการ
• ทั้งสองเครื่องมือสามารถเสียบเข้ากับ GitHub Actions, GitLab CI, Jenkins และทุกสิ่งที่ทำงานร่วมกับ Node.js ได้ ทั้งคู่จะทำให้ Build ล้มเหลวเมื่อการทดสอบล้มเหลว JUnit XML เป็นสิ่งที่เสียบเข้ากับ CI Dashboards ได้ทั้งสองด้าน
• เลือก Newman เมื่อการทดสอบของคุณมีอยู่แล้วในรูปแบบ Postman Collections และคุณต้องการ Runner ฟรี ที่เป็นมิตรกับ Repo โดยไม่ต้องมีบัญชีใหม่
• เลือก Apidog CLI เมื่อคุณต้องการการสร้างด้วยภาพ, การเชื่อมโยงคำขอ, การจัดการ Environment และการทำงานที่ขับเคลื่อนด้วยข้อมูลซึ่งยังคงซิงค์กับสถานการณ์เดียวกันที่ทีมของคุณแก้ไขข้อผิดพลาดทุกวัน

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

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

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

สิ่งที่ Newman ทำได้ดี

Newman ได้รับตำแหน่งของมัน มันเป็นคู่หูโอเพนซอร์สอย่างเป็นทางการของ Postman และสำหรับทีมที่การทดสอบมีอยู่ในรูปแบบ Postman Collections อยู่แล้ว มันคือเส้นทางที่ตรงที่สุดจาก "การทดสอบบนเครื่องของฉัน" ไปสู่ "การทดสอบใน CI" สิ่งสำคัญคือการระบุจุดแข็งของมันอย่างชัดเจนก่อนที่จะเปรียบเทียบใดๆ

มันฟรีและเป็นโอเพนซอร์ส คุณติดตั้งมันจาก npm และรันได้ทุกที่ที่ Node.js ทำงาน โดยไม่ต้องมีใบอนุญาตแยกต่างหากสำหรับตัว Runner เอง Collection ของคุณเป็นไฟล์ JSON แบบพกพาที่คุณสามารถ Commit เข้าสู่ Repo, จัดเก็บเป็น Build Artifact หรือดึงมาจาก URL ความสามารถในการพกพานั้นเป็นเรื่องจริง และหมายความว่า Newman สามารถเข้าสู่ Pipeline เกือบทุกประเภทได้อย่างง่ายดาย

มันนำสิ่งที่คุณสร้างไว้แล้วกลับมาใช้ใหม่ หากทีมของคุณเขียนคำขอ, Pre-request Scripts และ Test Assertions ใน Postman, Newman จะรัน Collections เหล่านั้นโดยไม่มีการเปลี่ยนแปลง ไม่มีการเขียนใหม่ Scripts ที่คุณเขียนใน Postman Editor จะดำเนินการในลักษณะเดียวกันในการรันแบบ Headless ซึ่งช่วยให้ Postman Shops เรียนรู้ได้ง่าย

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

npm install -g newman

ไบนารีคือ newman คุณรัน Collection ที่ส่งออกโดยการชี้ไปที่ไฟล์ JSON ซึ่งมักจะมีไฟล์ Environment อยู่ข้างๆ:

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

นั่นคือ Core Loop ส่งออก Collection จาก Postman, Commit ไฟล์ JSON และรัน Newman จะอ่านคำขอและ Assertions จากไฟล์และดำเนินการตามลำดับ สำหรับเส้นทางการตั้งค่าทั้งหมด คู่มือของ Apidog เองเกี่ยวกับ วิธีการติดตั้ง Newman และรัน Postman Collections ครอบคลุมขั้นตอนการส่งออกและการรันทีละขั้นตอน

Newman ยังรองรับคุณสมบัติ CI ที่จำเป็นที่คุณคาดหวัง การรันที่ขับเคลื่อนด้วยข้อมูลมาจากไฟล์ CSV หรือ JSON:

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

ในที่นี้ -d ให้ไฟล์ข้อมูลและ -n กำหนดจำนวนรอบ เพื่อให้ Collection รันหนึ่งครั้งต่อแถวหรือจำนวนครั้งที่กำหนด สิ่งเหล่านี้คือพื้นฐานเดียวกันที่ Runner ที่จริงจังต้องการ และ Newman มีสิ่งเหล่านี้มานานหลายปีแล้ว

ที่ Newman เริ่มทำให้คุณมีค่าใช้จ่าย

จุดแข็งที่กล่าวมานั้นจริงใจ แต่ข้อแลกเปลี่ยนก็เช่นกัน และมันแสดงออกมาในการบำรุงรักษาประจำวันมากกว่าในคำสั่งเดียว

ที่ใหญ่ที่สุดคือขั้นตอนการส่งออก Postman Collection ใน CI คือ Snapshot คุณเขียนและแก้ไขข้อผิดพลาดในแอป Postman จากนั้นส่งออกไฟล์ JSON เพื่อรันแบบ Headless ทันทีที่บางคนแก้ไขคำขอในแอปและลืมส่งออกซ้ำ Collection ที่ Commit ไว้ของคุณจะหลุดจากแหล่งข้อมูลที่แท้จริง การรัน CI ยังคงผ่านต่อคำจำกัดความเก่าในขณะที่ API จริงมีการเปลี่ยนแปลงไป ไม่มีอะไรในเครื่องมือบังคับให้ทั้งสองกลับมาซิงค์กัน; ขึ้นอยู่กับผู้ที่จำได้ว่าจะต้องส่งออก

การเขียน Script เป็นอีกเรื่องหนึ่ง ตรรกะการทดสอบของ Postman อยู่ใน JavaScript Snippets ที่แนบมากับแต่ละคำขอ และ Scripts เหล่านั้นคือที่ที่การเชื่อมโยง (Chaining), การดึงตัวแปร (Variable Extraction) และการตรวจสอบ (Assertions) เกิดขึ้น นั่นมีความยืดหยุ่น แต่หมายความว่า Test Suite ของคุณคือกลุ่มของ Script เล็กๆ น้อยๆ ที่ต้องเขียน, แก้ไขข้อผิดพลาด และบำรุงรักษาด้วยตนเอง เมื่อสถานการณ์ขยายตัว พื้นที่ของ Script ที่คุณเป็นเจ้าของก็ขยายตัวตามไปด้วย นี่เป็นส่วนหนึ่งของรูปแบบที่กว้างขึ้นที่ทีมพบเมื่อ Collections ขยายขนาด ซึ่งเราจะเจาะลึกใน ข้อจำกัดของ Postman Collection Runner และวิธีแก้ไข

ทั้งหมดนี้ไม่ได้ทำให้ Newman เป็นเครื่องมือที่ไม่ดี มันทำให้เป็น Runner ที่มีการออกแบบการใช้งานผูกติดอยู่กับรูปแบบการเขียนของ Postman: Scripts พร้อมขั้นตอนการส่งออก หากรูปแบบนั้นเหมาะกับทีมของคุณ Newman ก็ใช้ได้ หากการส่งออกและซิงค์เป็นส่วนที่ทำให้เกิดปัญหา นั่นคือจุดที่ Runner อื่นๆ จะช่วยได้อย่างแน่นอน

สิ่งที่ Apidog CLI ทำแตกต่างกัน

Apidog เลือกเส้นทางที่แตกต่างไปสู่ Pipeline เดียวกัน คุณสร้างการทดสอบด้วยภาพในแอป Apidog คุณเชื่อมโยงคำขอเข้าด้วยกันเป็นสถานการณ์การทดสอบ เพิ่ม Assertions ใน Editor แบบ No-code ดึงค่าจากผลลัพธ์หนึ่งไปยังคำขอถัดไป และวนซ้ำทั้งหมดบนไฟล์ข้อมูล CLI เป็นตัวดำเนินการแบบ Headless สำหรับสถานการณ์เหล่านั้น ไม่มีรูปแบบไฟล์แยกต่างหากและไม่มีอะไรให้ส่งออก มันดึงสถานการณ์ที่คุณระบุด้วย ID จากโปรเจกต์ Apidog ของคุณและรันมันเหมือนกับที่แอปจะทำทุกประการ

นั่นช่วยขจัดปัญหาการเปลี่ยนแปลง สถานการณ์ในโปรเจกต์คือการทดสอบ ไม่มี Snapshot ที่ส่งออกที่อาจหลุดจากการซิงค์ เพราะ CLI รันสถานการณ์แบบ Live ไม่ใช่สำเนา คุณเขียนมันครั้งเดียวใน Visual Builder ที่จัดการการเชื่อมโยงคำขอและ Assertions ให้คุณ จากนั้นสถานการณ์เดียวกันจะรันใน CI Fast Authoring Loop และ Automation Loop ใช้แหล่งความจริงเดียวกัน

การติดตั้งทำได้ด้วยคำสั่ง npm หนึ่งคำสั่ง:

npm install -g apidog-cli

ไบนารีคือ apidog การรันโดยทั่วไปจะระบุสถานการณ์ด้วย ID เลือก Environment และรับรองความถูกต้องด้วย Access Token:

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

คุณไม่ต้องพิมพ์ ID เหล่านั้นด้วยตนเอง เปิดสถานการณ์การทดสอบใน Apidog ไปที่แท็บ CI/CD สร้าง Access Token และ Apidog จะสร้างคำสั่งเต็มให้คุณพร้อม ID สถานการณ์และ ID Environment ที่กรอกไว้แล้ว คุณคัดลอกครั้งเดียว จากนั้นย้าย Token ไปยัง CI Secret และอ้างอิงเป็น $APIDOG_ACCESS_TOKEN หากคุณไม่แน่ใจว่าเวอร์ชันที่ติดตั้งของคุณรองรับ Flag ใด ให้รัน apidog run --help และมันจะพิมพ์ตัวเลือกที่มีให้ทั้งหมด

โมเดลที่ใช้ Token และดึงข้อมูลด้วย ID เป็นความแตกต่างที่ชัดเจนที่สุดจาก Newman Newman อ่านไฟล์ Collection จากดิสก์; Apidog CLI เข้าถึงโปรเจกต์ผ่านเครือข่าย โดยมีการรับรองความถูกต้อง และรันสถานการณ์ที่จัดเก็บไว้ที่นั่น ไม่มีอะไรผิด พวกมันเหมาะกับการตั้งค่าทีมที่แตกต่างกัน และการเลือกส่วนใหญ่ขึ้นอยู่กับว่าคุณต้องการให้การทดสอบเป็นไฟล์ที่ส่งออกหรือเป็นสถานการณ์แบบ Live ในพื้นที่ทำงานที่ใช้ร่วมกัน รุ่นที่ลึกกว่าของการเปรียบเทียบนี้ โดยมีกรอบรอบ Runner สองตัวในโลกของ Postman อยู่ใน Postman CLI กับ Newman หากคุณต้องการมุมนั้นด้วย

เปรียบเทียบแบบเคียงข้างกัน

มีสองสิ่งที่โดดเด่น ประการแรก Runner ทั้งสองครอบคลุมสิ่งจำเป็นของ CI เหมือนกัน: การเลือก Environment, การวนซ้ำที่ขับเคลื่อนด้วยข้อมูล, รูปแบบรายงานที่สำคัญ และการออกด้วยรหัสที่ไม่ใช่ศูนย์เมื่อล้มเหลว ชื่อ Flag ยังใกล้เคียงกันมากจน Memory Transfer (-e, -d, -n, -r) ประการที่สอง ความแตกต่างที่แท้จริงไม่ใช่ความสามารถดิบๆ แต่เป็นที่อยู่ของการทดสอบและวิธีการที่คุณเขียนมัน Newman รัน Collection ที่ส่งออกที่เขียนด้วย Scripts Apidog รัน Live Visual Scenario โดยการอ้างอิง การเปรียบเทียบในเวอร์ชันที่ลึกกว่านี้ ซึ่งอยู่ในกรอบของ Runner สองตัวในโลกของ Postman อยู่ใน Postman CLI กับ Newman หากคุณต้องการมุมนั้นด้วย

ตัวรายงานและรหัสการออก: ส่วนที่ CI อ่านได้จริง

Runner ได้รับตำแหน่งใน Pipeline ผ่านพฤติกรรมสองอย่าง: รายงานที่เขียนและรหัสการออกที่ส่งคืน ทำให้สองสิ่งนี้ถูกต้อง ที่เหลือคือการเชื่อมต่อ

Newman เลือกตัวรายงานด้วยแฟล็ก -r และรายการที่คั่นด้วยคอมมา JUnit และ JSON มาพร้อมกับตัวโปรแกรม; HTML Reporter เป็นส่วนเสริมที่พบบ่อยที่สุด:

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

JUnit XML คือสิ่งที่แดชบอร์ด CI ของคุณแยกวิเคราะห์เป็น Pass หรือ Fail Tree แฟล็ก --bail ของ Newman จะหยุดการทำงานหลังจากความล้มเหลวครั้งแรก ซึ่งช่วยให้ได้ Feedback อย่างรวดเร็วในการทดสอบ Smoke Test หากไม่มี แฟล็กนี้ การทำงานจะเสร็จสมบูรณ์และรายงานความล้มเหลวทั้งหมดพร้อมกัน

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

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

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

ข้อตกลงเรื่อง Exit Code เหมือนกันทั้งสองฝั่ง และเป็นส่วนสำคัญ เมื่อ Assertion ล้มเหลว Runner จะออกด้วยรหัสที่ไม่ใช่ศูนย์ CI จะอ่านรหัสนี้ ทำเครื่องหมายว่าขั้นตอนล้มเหลว, ทำให้ Job ล้มเหลว, และบล็อกการ Merge หรือ Deploy คุณไม่จำเป็นต้องกำหนดค่าอะไรเพิ่มเติม สิ่งเดียวที่อาจผิดพลาดซึ่งเหมือนกันทั้งสองคือการกลืน Exit Code: หากคุณครอบการรันด้วย Shell Pipeline หรือต่อท้าย || true Exit Code ที่ไม่ใช่ศูนย์จะถูกกลืนหายไป ทำให้ Gate หยุดทำงานอย่างเงียบๆ อย่าทำเช่นนั้น สำหรับบริบทที่กว้างขึ้นเกี่ยวกับรูปแบบรายงาน การทดสอบ API ที่ขับเคลื่อนด้วยข้อมูลด้วย CSV หรือ JSON แสดงให้เห็นว่ารายงานเชื่อมโยงกลับไปยังข้อมูล Iteration อย่างไร

Newman ใน GitHub Actions

เนื่องจาก Collection เป็นไฟล์ที่ส่งออกใน Repo เวิร์กโฟลว์จึงสั้น ตรวจสอบโค้ด, ติดตั้ง Newman, รัน Collection, อัปโหลดรายงานแม้จะล้มเหลวก็ตาม

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

ไม่จำเป็นต้องใช้ Secret หากไฟล์ Collection และ Environment ได้รับการ Commit เข้าสู่ Repo บรรทัด if: always() ทำให้การอัปโหลดรายงานยังคงทำงานแม้ว่าการทดสอบจะล้มเหลว ซึ่งเป็นเวลาที่คุณต้องการอ่านมันมากที่สุด ค่าใช้จ่ายที่คุณต้องจ่ายคือขั้นตอนการส่งออกที่สร้างไฟล์ JSON เหล่านั้นตั้งแต่แรก และการต้องจำที่จะรีเฟรชมันเมื่อ API มีการเปลี่ยนแปลง

Apidog CLI ใน GitHub Actions

เวิร์กโฟลว์ของ Apidog มีรูปแบบเดียวกัน โดยมีการเปลี่ยนแปลงหนึ่งอย่าง: Access Token มาจาก Repository Secrets และคุณเลือก Scenario ด้วย ID แทนที่จะชี้ไปที่ไฟล์

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

สังเกตความสมมาตร การ Checkout แบบเดียวกัน, การตั้งค่า Node แบบเดียวกัน, รูปแบบ Install-then-run แบบเดียวกัน, การ Always-upload แบบเดียวกัน ความแตกต่างที่แท้จริงเพียงอย่างเดียวคือ Token ที่เชื่อมต่อเป็น Secret และ Scenario ที่เลือกด้วย ID แทนที่จะเป็นเส้นทางไฟล์ เนื่องจาก Scenario ถูกดึงมาแบบสด ไม่มีไฟล์ JSON ที่ต้องคอยอัปเดตอยู่เสมอ สำหรับรูปแบบเดียวกันในระบบอื่นๆ วิธีการทำให้ API Tests เป็นอัตโนมัติใน GitHub Actions จะนำโครงสร้างไปใช้กับ GitLab CI และ Jenkins

วิธีการเลือก

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

เลือก Newman เมื่อการทดสอบของคุณเป็น Postman Collections อยู่แล้ว หาก Test Suite ของคุณอยู่ใน Postman ทีมของคุณเขียน Test Scripts ใน Editor และคุณต้องการ Runner แบบโอเพนซอร์สฟรีที่สามารถใช้ได้กับ Pipeline ใดๆ โดยไม่ต้องมีบัญชีใหม่ Newman คือตัวเลือกที่เหมาะสมที่สุด มันเป็นตัวเลือกตามธรรมชาติสำหรับร้านค้าที่ใช้ Postman ที่คุ้นเคยกับการส่งออก Collection และ Commit ไฟล์ JSON และไม่รังเกียจที่จะจัดการ Test Scripts ด้วยตนเอง คุณสามารถอ่านเพิ่มเติมเกี่ยวกับความแตกต่างภายในระบบนิเวศของ Postman ได้ใน ความแตกต่างระหว่าง Newman กับ Postman คืออะไร

เลือก Apidog CLI เมื่อความเร็วในการสร้างและแหล่งความจริงเดียวสำคัญกว่าการคงอยู่ใน Postman หากคุณต้องการสร้าง Scenario การทดสอบด้วยภาพ, เชื่อมโยงคำขอ, ดึงตัวแปร และรัน Scenario เดียวกันนั้นข้าม Environment โดยไม่ต้องเขียนและส่งออก Test Code ซ้ำ Apidog จะช่วยลดความยุ่งยากเหล่านั้น การออกแบบ, แก้ไขข้อผิดพลาด, Mock และทดสอบจะอยู่ในพื้นที่ทำงานเดียว และ CLI จะรัน Scenario ที่คุณสร้างขึ้นมาอย่างแม่นยำ สำหรับทีมที่ย้ายจาก Postman Apidog มีวิธีการรองรับการย้ายนี้ในฐานะ ทางเลือกที่ดีที่สุดของ Postman สำหรับการทดสอบ API และการ Import ทำได้เพียงคลิกเดียว

นอกจากนี้ยังมีคำตอบที่ใช้ได้ทั้งสองเครื่องมือ บางทีมยังคงใช้ Newman ในการรัน Collections เก่าๆ ในขณะที่ย้าย Scenario ที่ซับซ้อนและมีการเชื่อมโยงกันใหม่ไปยัง Apidog CLI ทั้งสองสามารถอยู่ร่วมกันได้ดีใน Pipeline เดียวกัน พวกมันเป็นขั้นตอนที่แยกกันพร้อมรหัสการออกที่แยกกัน และคุณสามารถเลิกใช้ขั้นตอน Newman ได้ตามกำหนดเวลาของคุณเอง

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