การรันทดสอบที่ไม่ได้พิมพ์อะไรที่มีประโยชน์ออกมาเลย เป็นการรันทดสอบที่ไม่มีใครเชื่อถือ เมื่อ Pipeline ของคุณเป็นสีแดง มีคนเปิด Build Log ขึ้นมา และสิ่งที่พวกเขาพบคือรายการ Timestamp จำนวนมากและ Exit Code ที่ไม่ใช่ศูนย์ การยืนยันใดที่ล้มเหลว? ทดสอบกับสภาพแวดล้อมใด? บนแถวใดของไฟล์ข้อมูล? การรันนั้นรู้ เพียงแต่ไม่เคยบันทึกไว้ในที่ที่คุณสามารถอ่านได้ในภายหลัง
นั่นคือช่องว่างที่ Reporter เข้ามาเติมเต็ม เมื่อคุณรันการทดสอบ API จาก Command Line รายงานคือส่วนที่คุณต้องใช้ชีวิตอยู่ด้วยจริงๆ: ไฟล์ที่คุณเก็บถาวร, ไฟล์ที่แดชบอร์ด CI ของคุณแยกวิเคราะห์, สิ่งที่คุณส่งให้เพื่อนร่วมทีมในตอน 9 โมงเช้า ซึ่งไม่ได้เฝ้าดู Pipeline ตอนตี 2 ผลการตัดสินของการทดสอบเป็นเพียงครึ่งหนึ่งของงาน อีกครึ่งหนึ่งคือการทำให้ผลการตัดสินนั้นอ่านเข้าใจได้ทั้งคนและเครื่องจักรไปพร้อมกัน
Apidog command-line runner จัดการได้ทั้งสองอย่าง Apidog มาพร้อมกับ CLI ที่รัน scenarios การทดสอบที่คุณสร้างขึ้นด้วยภาพในแอป และมีหนึ่ง Flag ที่ควบคุมรายงานทั้งหมดที่สร้างขึ้น: -r, --reporters คุณส่งรายการที่คั่นด้วยคอมมาให้ Runner จะเขียนแต่ละรูปแบบลงดิสก์ และคุณเป็นผู้ตัดสินใจว่าใครจะอ่านอะไร คู่มือนี้เกี่ยวกับ Flag นั้นและไฟล์ที่มันสร้างขึ้น: แต่ละ Reporter มีไว้เพื่ออะไร, อะไรที่ถูกบันทึกลงดิสก์, บันทึกที่ไหน, และจะเชื่อมต่อแต่ละตัวเข้ากับ Workflow จริงได้อย่างไร หากคุณต้องการภาพรวมที่กว้างขึ้นของ Flag ทุกตัวที่ Runner ยอมรับ, apidog run command reference ครอบคลุมทั้งหมด; หน้านี้จะเน้นไปที่รายงาน
ทำไมรายงานถึงสำคัญกว่าการรัน
รัน Scenario ในเครื่องคุณเองและคุณจะเห็นมันทำงาน คุณจะเห็นแต่ละ Request ถูกส่งไป, แต่ละ Assertion เป็นสีเขียว, และสรุปผลในตอนท้าย วงจรข้อเสนอแนะคือ Terminal ที่อยู่ตรงหน้าคุณแบบสดๆ
ใน CI วงจรนั้นหายไป การรันเกิดขึ้นบนเครื่องที่คุณไม่เคยเห็น, ในเวลาที่คุณไม่ได้เฝ้าดู, และบันทึกเดียวที่มีคือสิ่งที่ถูกเขียนลงดิสก์ก่อนที่ Runner จะหยุดทำงาน หากการรันไม่สร้างรายงาน, ความล้มเหลวจะบอกคุณเพียงแค่ว่ามีบางอย่างเสีย คุณจะต้องรันทั้งหมดนั้นใหม่ในเครื่องคุณเองและหวังว่ามันจะเสียในลักษณะเดียวกัน
รายงานที่ดีจะช่วยลดช่องว่างนั้น มันจะบันทึกว่า Scenario ใดถูกรัน, กับสภาพแวดล้อมใด, จำนวนการวนซ้ำกี่ครั้ง, การยืนยันใดที่ผ่าน, การยืนยันใดที่ล้มเหลว, และรายละเอียด Request และ Response ที่อยู่เบื้องหลังแต่ละความล้มเหลว หากมีข้อมูลนั้นอยู่ในดิสก์, ความล้มเหลวตอนตี 2 จะกลายเป็นการอ่านเพียงห้านาทีในเช้าวันถัดไป แทนที่จะเป็นการตามล่าหาสาเหตุ นั่นคือเหตุผลทั้งหมดที่ Flag ของ Reporter มีอยู่, และเป็นเหตุผลว่าทำไมการเลือกรูปแบบที่ถูกต้องสำหรับผู้รับแต่ละกลุ่มจึงคุ้มค่ากับการใช้เวลาคิดสักเล็กน้อย
Flag เดียวที่ควบคุมทุกรายงาน
Apidog CLI เป็นแพ็คเกจ npm ที่ชื่อว่า apidog-cli ติดตั้งครั้งเดียวคุณก็จะได้ Binary ตัวเดียวคือ apidog ซึ่งมี Subcommand หลักคือ run ติดตั้งแบบ Global:
npm install -g apidog-cli
ทุกรายงานที่ Runner สามารถสร้างได้มาจาก Flag ตัวเดียวใน Command นั้น: -r, --reporters มันรับรายการที่คั่นด้วยคอมมา, และสี่ค่าที่มันยอมรับคือ cli, html, json, และ junit ค่าเริ่มต้น, หากคุณไม่ส่งอะไรเลย, คือ cli
การรันที่สมบูรณ์พร้อม Reporter สองตัวมีลักษณะดังนี้:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,cli
นั่นคือการยืนยันตัวตนด้วย Token, รัน Scenario ทดสอบ 605067 กับสภาพแวดล้อม 1629989 หนึ่งครั้ง, และส่งออกทั้งไฟล์ HTML และ Output ที่อ่านได้ใน Terminal ID เหล่านี้คือ Scenario ID และ Environment ID; คุณคัดลอกทั้งสองอย่าง, พร้อมกับ Access Token, จากแท็บ CI/CD ของ Scenario ใน Apidog แทนที่จะพิมพ์ด้วยตนเอง หากการตั้งค่าใดๆ เหล่านั้นไม่คุ้นเคย, Apidog CLI complete guide จะแนะนำการติดตั้ง, Tokens, และการรันครั้งแรกของคุณตั้งแต่ต้นจนจบ
แนวคิดหลัก: การรันหนึ่งครั้งสามารถสร้างรายงานได้หลายรายการพร้อมกัน คุณไม่ได้เลือกรูปแบบเดียว คุณกำลังเลือกผู้รับสำหรับแต่ละ Output และรวมรายการเหล่านั้นเข้าด้วยกัน บรรทัด CI ทั่วไปจะส่งออกไฟล์ HTML ที่มนุษย์อ่านได้และไฟล์ JUnit ที่เครื่องอ่านได้จากการรันเดียวกัน, ดังนั้นการรันเดียวกันจึงตอบสนองได้ทั้งคนและแดชบอร์ด
cli: รายงานที่คุณอ่านใน Build Log
Reporter แบบ cli จะพิมพ์สรุปที่อ่านง่ายตรงไปยัง Terminal เป็นค่าเริ่มต้น, และเป็นตัวที่คนจะสแกนดูก่อน
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli
สิ่งที่มันให้คุณคือผลลัพธ์แบบสดๆ: จำนวน Request ที่รันไปแล้ว, จำนวน Assertion ที่ผ่านและล้มเหลว, และ Assertion เฉพาะตัวใดที่ล้มเหลว ใน Build Log ของ CI, นี่คือบล็อกที่คนจะอ่านเมื่อพวกเขากดเข้าไปใน Job ที่ล้มเหลว มันบอกพวกเขาได้อย่างรวดเร็วว่าความล้มเหลวเกิดจากการยืนยันเดียวที่เสียไป หรือห้าสิบการยืนยัน, และ Endpoint ใดที่เกี่ยวข้อง, ก่อนที่พวกเขาจะเสียเวลาดาวน์โหลดอะไร
เปิด cli ไว้เสมอแม้ว่าคุณจะเขียนรูปแบบสำหรับเครื่องจักรก็ตาม มันไม่มีค่าใช้จ่ายและทำให้ Build Log มีประโยชน์ในตัวมันเอง Pipeline ที่ส่งออกเฉพาะ JUnit XML จะสร้างแดชบอร์ดที่สมบูรณ์แบบและ Log ที่ไร้ประโยชน์; ใครก็ตามที่อ่าน Output ดิบจะไม่เห็นอะไรนอกจาก Runner เริ่มต้นและหยุดทำงาน การเพิ่ม cli เข้าไปในรายการจะแก้ไขปัญหานั้นได้:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli,junit --out-dir ./apidog-reports
อีกสอง Flag กำหนดสิ่งที่ cli พิมพ์ --verbose จะขยายให้แสดง Request และ Response เต็มรูปแบบสำหรับทุกขั้นตอน, ซึ่งเป็นการดำเนินการแรกของคุณเมื่อ Scenario ผ่านบนแล็ปท็อปแต่ล้มเหลวใน Pipeline; รายละเอียดของการส่งข้อมูลจะแสดงให้คุณเห็นอย่างแม่นยำว่า Runner ส่งอะไรไปและได้รับอะไรกลับมา --silent ทำตรงกันข้ามและระงับ Console Output ทั้งหมด, ซึ่งเหมาะกับ Job ที่ถูกกำหนดเวลาซึ่งมีเสียงดังและคุณสนใจเฉพาะ Exit Code และไฟล์ที่บันทึกไว้เท่านั้น
html: รายงานที่คุณส่งให้มนุษย์
Reporter แบบ html จะเขียนไฟล์ HTML ที่สมบูรณ์ในตัวเอง เปิดในเบราว์เซอร์ใดก็ได้แล้วคุณจะเห็นการรันทั้งหมดแสดงผลเป็นภาพ: ทุก Request, การยืนยันบนนั้น, สถานะผ่านและล้มเหลว, และรายละเอียด Request และ Response ที่อยู่เบื้องหลังแต่ละขั้นตอน ไม่ต้องติดตั้งอะไร, ไม่ต้องรัน Server; เป็นไฟล์เดียวที่คุณเพียงแค่ดับเบิลคลิก
นี่คือรูปแบบที่คุณจัดเก็บและแบ่งปัน บันทึกเป็น Build Artifact และรายงานจะคงอยู่เกินกว่าการรัน Pipeline, ดังนั้นหนึ่งสัปดาห์ต่อมาคุณก็ยังสามารถเปิดรายงานที่แน่นอนจากการ Deploy ที่เสียได้ นอกจากนี้ยังเป็นสิ่งที่คุณส่งให้คนที่ถามว่า "อะไรเสีย?" โดยไม่ต้องให้พวกเขาติดตั้ง CLI หรือรันซ้ำอะไร พวกเขาเปิดไฟล์, เห็นขั้นตอนที่เป็นสีแดง, อ่าน Response Body ที่ทำให้ Assertion ล้มเหลว, และพวกเขาก็ทำงานเสร็จ
HTML มีบทบาทสำคัญที่สุดในการรันแบบ Data-driven เมื่อ Scenario หนึ่งวนซ้ำผ่านไฟล์ CSV ที่มีห้าสิบแถว, รายงาน HTML จะแสดงผลลัพธ์ต่อการวนซ้ำ, ดังนั้นคุณจึงสามารถเห็นได้ว่าแถวที่ 1 ถึง 49 ผ่าน และแถวที่ 50 ล้มเหลวเนื่องจากบัญชีหนึ่งมี Token ที่หมดอายุ จำนวนการผ่านหรือล้มเหลวเพียงอย่างเดียวไม่สามารถบอกคุณได้ หากคุณรัน Scenario ข้ามไฟล์ข้อมูล, รูปแบบนี้จะครอบคลุมอยู่ใน data-driven API testing with CSV and JSON
ข้อแลกเปลี่ยน: HTML มีไว้สำหรับสายตา ไม่ใช่สำหรับการแยกวิเคราะห์ อย่าพยายาม Scrape เพื่อสถานะผ่าน/ล้มเหลวใน Script นั่นคือสิ่งที่ JSON และ JUnit มีไว้ให้
junit: รายงานที่แดชบอร์ด CI ของคุณแยกวิเคราะห์
Reporter แบบ junit จะส่งออก XML ในรูปแบบ JUnit มาตรฐาน รูปแบบนั้นสำคัญเพราะมันเป็นภาษากลางของการรายงานผลการทดสอบ CI ระบบ CI เกือบทุกระบบ ไม่ว่าจะเป็น GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure Pipelines, รู้จักวิธีอ่าน JUnit XML และแปลงมันให้เป็นแผนผังผ่าน/ล้มเหลว, แสดงความล้มเหลวใน Widget ของ Merge Request, และดูแนวโน้มผลลัพธ์ของการ Build เมื่อเวลาผ่านไป
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r junit --out-dir ./apidog-reports
หากคุณเลือกรูปแบบสำหรับเครื่องจักรเพียงรูปแบบเดียวสำหรับ CI, ให้เลือกอันนี้ ผลตอบแทนคือผลการทดสอบของคุณจะไม่อยู่แค่ในไฟล์ Log อีกต่อไป แต่จะไปปรากฏในแดชบอร์ดที่ทีมของคุณดูกันอยู่แล้ว ผู้ตรวจสอบจะเปิด Pull Request และเห็นว่า Assertion ใดที่ล้มเหลวแสดงผลอยู่ในบรรทัดเดียวกัน, ไม่ต้องเสียเวลาขุดคุ้ย Log, ไม่ต้องดาวน์โหลด Artifact
การเชื่อมต่อทำได้สองขั้นตอน: สร้างไฟล์ XML, จากนั้นบอกระบบ CI ของคุณว่าจะหาไฟล์นั้นได้ที่ไหน ใน GitLab CI, ขั้นตอนที่สองคือบล็อก reports: junit::
api-tests:
stage: test
image: node:20
script:
- npm install -g apidog-cli
- apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t 605067 -e 1629989 -r junit,cli --out-dir ./apidog-reports
artifacts:
when: always
paths:
- apidog-reports/
reports:
junit: apidog-reports/*.xml
ใน Jenkins, สิ่งที่เทียบเท่าคือขั้นตอน junit ในบล็อก post ที่ชี้ไปยังไฟล์เดียวกัน ใน GitHub Actions, คุณอัปโหลดไดเรกทอรีเป็น Artifact และให้ Action ที่รองรับ JUnit แสดงผลมัน Workflow ของ GitHub ฉบับเต็ม, รวมถึงการอัปโหลด Artifact ที่รันแม้การทดสอบจะล้มเหลว, มีอยู่ใน running Apidog CLI tests in GitHub Actions
json: รายงานที่ Scripts ของคุณประมวลผลต่อ
Reporter แบบ json จะสร้างผลลัพธ์ที่เป็นโครงสร้างดิบ ในขณะที่ HTML มีไว้สำหรับสายตาและ JUnit มีไว้สำหรับแดชบอร์ด, JSON มีไว้สำหรับโค้ดที่คุณเขียนเอง
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r json --out-dir ./apidog-reports
ใช้มันเมื่อรูปแบบที่มีอยู่ไม่ตรงกับสิ่งที่คุณต้องการทำกับผลลัพธ์ ส่ง Metric อัตราการผ่านไปยังระบบ Monitoring สร้างสรุป Slack แบบกำหนดเอง ป้อนผลลัพธ์เข้าสู่ Script ที่ตัดสินใจว่าจะ Rollback การ Deploy หรือไม่ เปรียบเทียบการรันของวันนี้กับเมื่อวาน การดำเนินการใดๆ ที่เป็นแบบ Programmatic จะเริ่มต้นจาก JSON, เพราะเป็นรูปแบบที่คุณสามารถแยกวิเคราะห์ได้โดยไม่ต้องคาดเดาโครงสร้าง
Flag รายงานหนึ่งถูกสร้างขึ้นมาโดยเฉพาะสำหรับ Output รูปแบบ JSON --out-json-failures-separated <value> จะแยกความล้มเหลวออกเป็นไฟล์ JSON ของตัวเอง นั่นทำให้คุณได้เอกสารที่มีเฉพาะความล้มเหลว, ซึ่งอ่านและเปรียบเทียบได้ง่ายกว่าการสแกนผลลัพธ์ทั้งหมดเพื่อหาสองสามขั้นตอนที่ล้มเหลว ในการทดสอบ Regression ขนาดใหญ่ที่ส่วนใหญ่ผ่าน, ไฟล์ที่มีเฉพาะความล้มเหลวสร้างความแตกต่างระหว่างการเหลือบดูกับการใช้คำสั่ง grep
ไฟล์จะไปอยู่ที่ไหน: --out-dir, --out-file, และ Placeholders
การเลือกรูปแบบคือครึ่งหนึ่งของภาพรวม อีกครึ่งหนึ่งคือการควบคุมว่าไฟล์จะไปอยู่ที่ไหนและมีชื่อว่าอะไร, ซึ่งสำคัญในทันทีที่คุณเก็บรายงานมากกว่าหนึ่งชุดการรันไว้
--out-dir <dir> กำหนดไดเรกทอรีที่จะเขียนรายงานลงไป ค่าเริ่มต้นคือ ./apidog-reports ใน CI, ชี้ไปที่ที่ที่ขั้นตอน Artifact ของคุณสามารถหาเจอได้, และรักษามันให้สอดคล้องกันเพื่อที่การตั้งค่าการอัปโหลดของคุณจะไม่ต้องเปลี่ยนแปลง:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r html,junit --out-dir ./apidog-reports
--out-file <name> กำหนดชื่อไฟล์รายงาน, และนี่คือจุดที่มันมีประโยชน์ หากไม่มี, การรันแต่ละครั้งมีแนวโน้มที่จะเขียนทับของเก่า, ดังนั้นคุณจะเก็บได้เพียงรายงานล่าสุดเท่านั้น Flag นี้ยอมรับ Placeholders ที่ Runner จะเติมให้ในขณะที่เขียน:
{SCENARIO_NAME}จะกลายเป็นชื่อของ Scenario ที่ถูกรัน{FOLDER_NAME}จะกลายเป็นชื่อโฟลเดอร์เมื่อคุณรันโฟลเดอร์ของ Scenarios{GENERATE_TIME}จะกลายเป็น Timestamp
ประทับชื่อไฟล์ด้วยชื่อ Scenario และ Timestamp แล้วการรันแต่ละครั้งจะเขียนไฟล์ที่แตกต่างกันและบอกข้อมูลในตัวเอง แทนที่จะเขียนทับไฟล์ก่อนหน้า:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r html --out-file "{SCENARIO_NAME}-{GENERATE_TIME}"
ตอนนี้ไดเรกทอรีรายงานของคุณอ่านได้เหมือนเป็นประวัติ คุณสามารถบอกได้ว่ารายงานใดมาจาก Scenario ใดและรันเมื่อใดโดยไม่ต้องเปิดไฟล์ใดๆ, ซึ่งเป็นสิ่งที่คุณต้องการอย่างแท้จริงเมื่อคุณกำลังสแกนโฟลเดอร์ของการรันตอนกลางคืนเพื่อหาไฟล์ที่สิ่งต่างๆ เริ่มผิดพลาดครั้งแรก
อีกหนึ่ง Flag รายงานที่ช่วยเติมเต็มฝั่ง Cloud --upload-report [value] จะอัปโหลดภาพรวมรายงานไปยัง Apidog Cloud, เพื่อให้การรันแสดงในประวัติโปรเจกต์ของคุณควบคู่ไปกับไฟล์ในเครื่อง เป็นตัวเลือกที่คุณจะเลือกใช้เมื่อคุณต้องการให้ผลลัพธ์ปรากฏให้เห็นภายใน Apidog เอง, ไม่ใช่แค่เป็นไฟล์บน CI Runner
กลยุทธ์ Reporter ตามกลุ่มเป้าหมาย
วิธีที่ชัดเจนที่สุดในการตัดสินใจคือการจับคู่ Reporter แต่ละตัวกับผู้ที่จะอ่านมัน, จากนั้นส่งตัวที่คุณต้องการพร้อมกัน
- คนที่กำลังสแกน Build Log อยู่ตอนนี้อ่าน
cliรวมไว้เสมอ - คนที่เปิดรายงานที่บันทึกไว้ในภายหลังอ่าน
htmlจัดเก็บเป็น Artifact - แดชบอร์ด CI อ่าน
junitนี่คือสิ่งที่แสดงความล้มเหลวใน Merge Request และแนวโน้มผลลัพธ์ของการ Build - Script ที่คุณเขียนอ่าน
jsonเป็นรูปแบบเดียวที่มีไว้เพื่อถูกแยกวิเคราะห์โดยโค้ดของคุณเอง
สำหรับ CI Pipelines ส่วนใหญ่, การรวมกันที่ใช้บ่อยคือ HTML สำหรับมนุษย์และ JUnit สำหรับแดชบอร์ด, โดยเปิด cli ไว้เพื่อให้ Log ดิบยังคงอ่านได้:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli,html,junit --out-dir ./apidog-reports
การรันหนึ่งครั้งนั้นสร้าง Log ที่อ่านได้, Artifact ที่สามารถเรียกดูได้, และไฟล์ XML ที่สามารถแยกวิเคราะห์ได้ สามกลุ่มเป้าหมาย, การรันเดียว, ไม่มีการซ้ำซ้อน
ข้อควรระวังหนึ่งที่ควรกล่าวอย่างชัดเจน: รายงานจะบอกคุณว่าเกิดอะไรขึ้น, แต่ Exit Code คือสิ่งที่ทำให้ Pipeline ดำเนินการตามนั้น Apidog CLI จะ Exit ด้วยค่าที่ไม่ใช่ศูนย์เมื่อ Assertion ใดๆ ล้มเหลว, และ Exit Code นั้น, ไม่ใช่รายงาน, คือสิ่งที่ทำให้ Build ล้มเหลวและบล็อกการ Merge รายงานอธิบายความล้มเหลว; Exit Code บังคับใช้มัน อย่าห่อหุ้ม Command ด้วยอะไรก็ตามที่กลืนกิน Code นั้น, เช่นการต่อท้าย || true ใน Shell, ไม่เช่นนั้นคุณจะได้รายงานสีแดงที่สมบูรณ์แบบที่แนบมากับการ Build ที่ยังคงเป็นสีเขียว เวอร์ชันที่ลึกซึ้งกว่าของตรรกะ Quality Gate นั้นอยู่ในคู่มือ automating API tests in CI/CD
การนำมารวมกัน
รัน Scenario ใน CI และส่งออก Artifact ที่มีประโยชน์ทั้งสามสำหรับสามกลุ่มเป้าหมาย:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r cli,html,junit --out-dir ./apidog-reports
รันการสแกนโฟลเดอร์ตอนกลางคืน, รวบรวมทุกความล้มเหลวในรายงานเดียว, และตั้งชื่อแต่ละไฟล์ให้บอกข้อมูลในตัวเอง:
apidog run --access-token $APIDOG_ACCESS_TOKEN -f 88012 -r html,junit --on-error continue --out-dir ./nightly-reports --out-file "{FOLDER_NAME}-{GENERATE_TIME}"
รัน Scenario แบบ Data-driven และเก็บ JSON เฉพาะความล้มเหลวไว้สำหรับการเปรียบเทียบอย่างรวดเร็ว:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -d ./accounts.csv -r json --out-json-failures-separated true --out-dir ./apidog-reports
หากคุณไม่อยากติดตั้ง CLI แบบ Global บน Ephemeral Runner, ให้เปลี่ยนจากการติดตั้งเป็นการใช้ npx และใช้ Flag ของ Reporter เดิม:
npx apidog-cli run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r html,junit --out-dir ./apidog-reports
พฤติกรรมของ Reporter จะเหมือนกันไม่ว่าจะใช้วิธีใด; การเลือกระหว่างการติดตั้งแบบ Global กับ npx เป็นเรื่องของ Runner Hygiene, ไม่ใช่เรื่องของรายงานที่คุณจะได้รับ
ชื่อ Flag, ค่าเริ่มต้น, และ Reporter สามารถเปลี่ยนแปลงได้ระหว่างการออกรุ่น CLI, ดังนั้น Runner จึงเป็นแหล่งข้อมูลที่เชื่อถือได้ที่สุดเสมอ รัน apidog run --help บนเวอร์ชันที่คุณติดตั้งและเชื่อถือสิ่งนั้นมากกว่าบทความใดๆ, รวมถึงบทความนี้ด้วย ในการตั้งค่า Scenario ที่ CLI จะรันตั้งแต่แรก, Download Apidog, สร้าง Scenario หนึ่งในแอป, จากนั้นคัดลอก Command ที่สร้างขึ้นจากแท็บ CI/CD และเพิ่ม Reporter ที่คุณต้องการ