การทดสอบ API แบบขับเคลื่อนด้วยข้อมูลด้วย Apidog CLI: การวนซ้ำ CSV และ JSON

คุณได้สร้างสถานการณ์จำลองการทดสอบที่แข็งแกร่งสำหรับเช็คเอาท์ปลายทางของคุณ มันเชื่อมโยงคำขอสามรายการ ตรวจสอบการตอบกลับแต่ละรายการ และผ่านทุกครั้งที่คุณคลิก Run จากนั้นไปป์ไลน์ของคุณต้องการให้ครอบคลุมการรวมอินพุตสี่สิบแบบ ดึงข้อมูลจากไฟล์ที่หัวหน้าฝ่าย QA ของคุณดูแล และรันสถานการณ์เดียวกันกับ staging และ production ด้วยข้อมูลรับรองที่แตกต่างกัน การรันแบบคลิกแล้วรันที่ใช้งานได้บนแล็ปท็อปของคุณไม่สามารถทำเช่นนั้นได้ และคุณไม่ต้องการโคลนสถานการณ์ถึงสี่สิบครั้ง

ส่วนสุดท้ายนั่นแหละคือสิ่งที่ Command Line จัดการ ด้วย Apidog คุณสามารถสร้างสถานการณ์จำลองการทดสอบเพียงครั้งเดียวในเครื่องมือสร้างแบบภาพ (visual builder) จากนั้นเรียกใช้งานจากเทอร์มินัลด้วย แพ็คเกจ apidog-cli แฟล็กที่เปลี่ยนสถานการณ์จำลองหนึ่งสถานการณ์ให้เป็นการรันแบบขับเคลื่อนด้วยข้อมูลคือ -d ซึ่งย่อมาจาก --iteration-data โดยจะรับไฟล์ CSV, ไฟล์ JSON หรือชุดข้อมูลที่คุณจัดเก็บไว้ในโปรเจกต์ Apidog ของคุณ และจะรันสถานการณ์จำลองหนึ่งครั้งต่อแถว โดยจะผูกค่าของแต่ละแถวเข้ากับตัวแปรที่คำขอของคุณอ้างถึง

ปุ่ม

แฟล็ก `-d` อ่านไฟล์อย่างไร

ฟีเจอร์ทั้งหมดอยู่ในตัวเลือกเดียว นี่คือรูปแบบเต็มและย่อ ตรงจาก apidog run --help:

-d, --iteration-data <path|testDataId>   กำหนดข้อมูลที่ใช้สำหรับการทำซ้ำ (เป็น JSON หรือ CSV)

ส่วน <path|testDataId> นี้คือรายละเอียดที่คนส่วนใหญ่มองข้าม อาร์กิวเมนต์นี้ถูกใช้งานเกินความหมาย (overloaded) หากส่งพาธไป CLI จะอ่านไฟล์จากเครื่อง หากส่ง test-data ID ไป CLI จะดึงชุดข้อมูลที่คุณบันทึกไว้ในโปรเจกต์ Apidog ของคุณ แฟล็กเดียวกัน แต่มีแหล่งที่มาสองแบบ และตัวรันจะทราบว่าคุณส่งแบบใด

รูปแบบไฟล์ในเครื่องเป็นจุดเริ่มต้นทั่วไป ชี้ไปที่ไฟล์ที่สัมพันธ์กับตำแหน่งที่คุณรันคำสั่ง:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv -r cli

CLI จะเปิด checkout-cases.csv นับแถวภายใต้ส่วนหัว และรันสถานการณ์จำลอง 605067 หนึ่งครั้งต่อแถว ในแต่ละรอบจะผูกคอลัมน์เข้ากับตัวแปรที่ตรงกันในคำขอของคุณ เรียกใช้สถานการณ์จำลอง และบันทึกผลลัพธ์ของการทำซ้ำนั้น สี่สิบแถว สี่สิบรอบ สถานการณ์จำลองเดียว

รูปแบบเป็นไปตามไฟล์ แฟล็กเดียวกันนี้รองรับ JSON โดยไม่มีตัวเลือกเพิ่มเติมใดๆ:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.json -r cli

คุณไม่จำเป็นต้องบอก CLI ว่าคุณกำลังใช้รูปแบบใด มันจะอ่านส่วนขยายและรูปร่างของไฟล์ นั่นหมายความว่าคุณสามารถเปลี่ยน CSV เป็นอาร์เรย์ JSON กลางโปรเจกต์ได้โดยไม่ต้องแก้ไขคำสั่ง ตราบใดที่ชื่อคอลัมน์และคีย์ JSON ตรงกับตัวแปรที่สถานการณ์จำลองของคุณคาดหวัง

สิ่งที่ CLI คาดหวังในแต่ละไฟล์

CSV เป็นรูปแบบสำหรับกรณีที่เป็นตารางข้อมูลแบนราบ (flat, tabular cases) แถวหัวข้อจะตั้งชื่อตัวแปรของคุณ ทุกแถวที่อยู่ถัดจากนั้นคือหนึ่งการทำซ้ำ นี่คือไฟล์ checkout-cases.csv จริงสำหรับปลายทางส่วนลด:

sku,quantity,coupon,expected_status,expected_total
DESK-01,1,SAVE10,200,89.10
DESK-01,0,SAVE10,422,0
CHAIR-09,3,,200,447.00
DESK-01,1,EXPIRED,410,0
GHOST-99,1,SAVE10,404,0

ห้าคอลัมน์กลายเป็นห้าตัวแปร ภายในเนื้อหาคำขอ คุณเขียน {{sku}} และ {{quantity}}; ในการยืนยัน คุณเปรียบเทียบการตอบกลับกับ {{expected_status}} และ {{expected_total}} ตัวรันจะผูกค่าเหล่านี้ต่อแถว ช่องว่าง coupon ในแถวที่สามจะกลายเป็นสตริงว่าง ซึ่งเป็นกรณีไม่มีคูปองที่คุณต้องการครอบคลุมอย่างแท้จริง

JSON เป็นรูปแบบเมื่อกรณีของคุณมีโครงสร้างซ้อนกันที่ไม่สามารถแปลงเป็นคอลัมน์ได้ดี ไฟล์จะเป็นอาร์เรย์ของอ็อบเจกต์ ซึ่งแต่ละอ็อบเจกต์คือหนึ่งการทำซ้ำ:

[
  {
    "label": "valid order, two items",
    "order": {
      "items": [
        { "sku": "DESK-01", "qty": 1 },
        { "sku": "CHAIR-09", "qty": 2 }
      ],
      "shipping": { "country": "US", "method": "ground" }
    },
    "expected_status": 200
  },
  {
    "label": "unshippable country",
    "order": {
      "items": [{ "sku": "DESK-01", "qty": 1 }],
      "shipping": { "country": "ZZ", "method": "ground" }
    },
    "expected_status": 422
  }
]

ภายในสถานการณ์จำลอง คุณอ้างถึง {{order}} และ {{expected_status}} ในลักษณะเดียวกัน และตัวรันจะส่งฟิลด์ของแต่ละอ็อบเจกต์ไปยังการทำซ้ำ ฟิลด์ label มีไว้สำหรับคุณ มันจะปรากฏในรายงานเพื่อให้การผ่านที่ล้มเหลวอ่านว่า "ประเทศที่ไม่สามารถจัดส่งได้" แทนที่จะเป็น "การทำซ้ำ 2" ซึ่งเป็นความแตกต่างระหว่างการวินิจฉัยห้าวินาทีกับการวินิจฉัยห้านาที

กฎบางข้อช่วยป้องกันไฟล์เหล่านี้จากการสร้างปัญหาใน CI:

รักษาชื่อหัวข้อให้เหมือนกับชื่อตัวแปรในสถานการณ์จำลองของคุณ คอลัมน์ที่ชื่อว่า qty จะไม่ผูกกับคำขอที่อ่าน {{quantity}} ความไม่ตรงกันนี้เป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้การรันแบบขับเคลื่อนด้วยข้อมูลผ่านในเครื่องแต่สร้างค่าว่างเปล่าในไปป์ไลน์
ใส่เครื่องหมายคำพูดในฟิลด์ CSV ที่มีเครื่องหมายจุลภาค หรือย้ายไฟล์นั้นไปเป็น JSON ฟิลด์ข้อความอิสระที่มีเครื่องหมายจุลภาคจะถูกแยกเป็นสองคอลัมน์และเลื่อนค่าทั้งหมดที่ตามมา
ใส่ผลลัพธ์ที่คาดไว้ในข้อมูล ไม่ใช่ในสถานการณ์จำลอง แถวแรกคาดหวัง 200 แถวสี่คาดหวัง 410 หากคุณกำหนดค่าที่คาดหวังแบบตายตัวในการยืนยัน คุณก็จะกลับไปสู่หนึ่งสถานการณ์จำลองต่อหนึ่งกรณี
คอมมิตไฟล์เหล่านี้ถัดจากการกำหนดค่าการทดสอบของคุณ เพื่อให้พวกมันมีการกำหนดเวอร์ชันพร้อมกับโค้ดที่พวกมันใช้งาน ไฟล์ข้อมูลเป็นส่วนหนึ่งของการทดสอบ ไม่ใช่สิ่งประดิษฐ์ที่กระจัดกระจาย

สำหรับด้าน JSONPath ของการเขียน assertion ที่อ่านค่าที่ถูกผูกไว้เหล่านี้ การตั้งค่า assertion และการดึงตัวแปรจาก JSON response จะอธิบายไวยากรณ์โดยละเอียด

การรันจากชุดข้อมูลที่จัดเก็บไว้แทนการใช้ไฟล์

รูปแบบที่สองของ -d เป็นสิ่งที่มักไม่ปรากฏในคำแนะนำส่วนใหญ่ แทนที่จะเป็นพาธ คุณจะส่ง Test Data ID:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d 38291 -r cli

ตอนนี้ CLI จะดึงชุดข้อมูลที่มี ID นั้นจากโปรเจกต์ Apidog ของคุณ แทนที่จะอ่านไฟล์จากดิสก์ของตัวรัน ซึ่งมีประโยชน์เมื่อข้อมูลอยู่กับทีม ไม่ใช่กับรีโพซิโทรี หัวหน้าฝ่าย QA ของคุณดูแลตารางกรณีศึกษาภายใน Apidog แก้ไขในแอป และการรัน CI ทุกครั้งจะใช้เวอร์ชันปัจจุบันโดยไม่ต้องมีใครคอมมิตไฟล์ CSV สถานการณ์จำลอง สภาพแวดล้อม และข้อมูลล้วนอยู่บนเซิร์ฟเวอร์ คำสั่งเพียงแค่ระบุด้วย ID

ข้อแลกเปลี่ยนคือแหล่งความจริงของคุณอยู่ที่ไหน CSV ที่ถูกคอมมิตช่วยให้คุณมีชุดข้อมูลที่สามารถเปรียบเทียบความแตกต่างได้ในการร้องขอการรวม (pull requests) และถูกผูกกับคอมมิตที่กำลังถูกทดสอบ Test Data ID ที่จัดเก็บไว้ให้คุณมีตารางที่ใช้ร่วมกันเพียงแห่งเดียวที่ทุกคนสามารถแก้ไขได้ในที่เดียว ไม่มีแบบไหนผิด เลือกไฟล์ที่ถูกคอมมิตเมื่อข้อมูลควรเคลื่อนไหวควบคู่ไปกับโค้ด และเลือก ID ที่จัดเก็บไว้เมื่อข้อมูลเป็นของบุคคลที่ไม่ได้ยุ่งเกี่ยวกับรีโพซิโทรี

การรันแบบออฟไลน์จากไฟล์ที่ส่งออก

มีวิธีที่สามในการป้อนข้อมูลให้กับ CLI และมันเปลี่ยนรูปร่างของคำสั่งทั้งหมด คุณสามารถส่งออก test case จาก Apidog เป็นไฟล์ที่มีอยู่ในตัวเอง (self-contained file) และรันไฟล์นั้นได้โดยตรง โดยไม่ต้องใช้ scenario ID และไม่ต้องมีการเชื่อมต่อเครือข่ายเพื่อดึง scenario:

apidog run ./checkout.apidog-cli.json -r cli,html

ที่นี่อาร์กิวเมนต์แรกคือ file-source ซึ่งเป็น test case ที่ส่งออกนั้นเอง ไม่ใช่แฟล็ก CLI จะรันสิ่งที่อยู่ในไฟล์ คุณยังคงสามารถเพิ่มข้อมูลการทำซ้ำด้วย -d ได้:

apidog run ./checkout.apidog-cli.json -d ./checkout-cases.csv -r cli,junit

สิ่งนี้มีความสำคัญในสองสถานการณ์ สถานการณ์แรกคือ CI runner ที่แยกจากเครือข่าย (air-gapped) หรือถูกจำกัดที่ไม่สามารถเข้าถึง Apidog cloud เพื่อแก้ไข scenario ID ได้ ไฟล์ที่ส่งออกจะมีทุกสิ่งที่การรันต้องการ สถานการณ์ที่สองคือความสามารถในการทำซ้ำ (reproducibility): ไฟล์ที่ส่งออกคือ snapshot ที่ถูกตรึงของ scenario ณ เวลาที่ส่งออก ดังนั้นการรันจากไฟล์นั้นจะไม่ได้รับผลกระทบจากการที่คนอื่นแก้ไข scenario ในแอปในภายหลัง สำหรับกลไกการติดตั้งและการรันครั้งแรก คู่มือการติดตั้ง Apidog CLI จะครอบคลุมการเตรียมไบนารี และ เอกสารอ้างอิง Apidog CLI ฉบับสมบูรณ์ จะระบุทุกแฟล็กในตารางเดียว

การจับคู่ `-d` กับ `-n` และการแทนที่ตัวแปร

การรันแบบขับเคลื่อนด้วยข้อมูลไม่ค่อยมาเดี่ยวๆ แฟล็กสามตัวนี้มักถูกใช้คู่กับ -d เสมอ

-n, --iteration-count กำหนดจำนวนครั้งที่ scenario จะรัน เมื่อคุณให้ไฟล์ข้อมูล จำนวนแถวจะกำหนดการทำซ้ำอยู่แล้ว ดังนั้นคุณมักจะละเว้น -n และให้ไฟล์เป็นตัวตัดสิน คุณจะใช้ -n เป็นหลักเมื่อคุณต้องการรันตารางมากกว่าหนึ่งครั้ง หรือเมื่อคุณรันโดยไม่มีไฟล์ข้อมูลเลย เช่นการทดสอบความทนทาน (soak test) ที่ทำซ้ำ scenario เดียวกัน:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 50 -r cli

--env-var และ --global-var จะฉีดคู่ key=value ในขณะรันโดยไม่กระทบต่อสภาพแวดล้อมในโปรเจกต์ของคุณ นี่คือวิธีที่คุณเก็บความลับและการตั้งค่าต่อไปป์ไลน์ (per-pipeline config) ออกจากทั้ง scenario และไฟล์ข้อมูล ไฟล์ข้อมูลจะเก็บ test cases; ส่วนตัวแปรที่ถูกแทนที่ (overrides) จะเก็บสิ่งที่เปลี่ยนแปลงในการรันแต่ละครั้ง:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv \
  --env-var "base_url=https://staging.internal" \
  --global-var "api_key=$RUNTIME_API_KEY" \
  -r cli,junit

การแยกนี้ตั้งใจทำ ข้อมูลการทำซ้ำเป็นส่วนที่เหมือนกันในทุกที่: กรณีที่ endpoint ของคุณต้องจัดการ การแทนที่ตัวแปรเป็นส่วนที่เปลี่ยนแปลงไปตามสภาพแวดล้อม: โฮสต์, คีย์, ผู้เช่า (tenant) เก็บข้อมูลรับรองใน CI secret store ของคุณและส่งผ่านด้วย --global-var จากตัวแปรสภาพแวดล้อม ดังเช่นที่ $RUNTIME_API_KEY ทำข้างต้น อย่าใส่ไว้ใน CSV ซึ่งใครก็ตามที่มีสิทธิ์เข้าถึงรีโพสามารถอ่านได้

การอ่านผลลัพธ์ต่อการทำซ้ำ

การรันแบบขับเคลื่อนด้วยข้อมูลจะมีประโยชน์ก็ต่อเมื่อคุณสามารถบอกได้ว่าแถวใดล้มเหลว แฟล็กของรีพอร์ตเตอร์จะตัดสินว่าคุณจะได้อะไรกลับคืนมา

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv \
  -r cli,junit --out-dir ./test-reports

-r cli จะพิมพ์รายละเอียดการแยกย่อยต่อการทำซ้ำที่อ่านได้ไปยังเทอร์มินัล ซึ่งเป็นสิ่งที่คุณสแกนในบันทึกการสร้าง -r junit จะเขียน JUnit XML ซึ่งเป็นรูปแบบที่แดชบอร์ด CI เกือบทุกตัวสามารถแยกวิเคราะห์เป็นโครงสร้างผ่าน/ไม่ผ่านได้ ดังนั้นแถวที่ล้มเหลวจะแสดงเป็นชื่อการทดสอบที่ล้มเหลวแทนที่จะเป็นข้อความบันทึกที่ซ่อนอยู่ คุณสามารถส่ง html และ json ได้ด้วยเช่นกัน html จะให้รายงานที่สามารถเรียกดูได้เพื่อจัดเก็บเป็น build artifact และ json จะให้เอาต์พุตที่มีโครงสร้างดิบหากคุณประมวลผลผลลัพธ์ภายหลัง --out-dir จะควบคุมตำแหน่งที่ไฟล์จะถูกบันทึกเพื่อให้คุณสามารถเก็บเป็น artifact ได้

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

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv \
  --on-error continue \
  -r cli,junit --out-dir ./test-reports

--on-error continue จะรันทุกการทำซ้ำแม้ว่าการทำซ้ำก่อนหน้าจะล้มเหลว ดังนั้นรายงานเดียวจะแสดงให้คุณเห็นว่าแถวสอง เจ็ด และสิบเก้าเสียพร้อมกัน การรันจะยังคงสิ้นสุดด้วยรหัสออกจากระบบที่ไม่ใช่ศูนย์หากมีสิ่งใดล้มเหลว ดังนั้นมันจึงยังคงเป็นประตูตรวจสอบที่แท้จริง --on-error end เป็นค่าเริ่มต้นแบบล้มเหลวเร็ว (fast-fail) สำหรับการตรวจสอบความเรียบร้อยอย่างรวดเร็ว ส่วน ignore ใช้สำหรับขั้นตอนที่ทราบว่าไม่เสถียร (flaky) ซึ่งคุณไม่ต้องการให้ขัดขวางการรัน

การแก้ไขข้อผิดพลาดของการผูกข้อมูลที่ไม่ได้ทำอะไรเงียบๆ

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

เมื่อการรันแบบขับเคลื่อนด้วยข้อมูลมีพฤติกรรมแปลกๆ ให้เพิ่ม --verbose:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv \
  --verbose -r cli

--verbose จะพิมพ์คำขอและคำตอบทั้งหมดสำหรับการทำซ้ำแต่ละครั้ง ให้ดูที่เนื้อหาคำขอที่ตัวรันส่งไปจริง หากคุณเห็น {{sku}} ยังคงอยู่โดยไม่มีการแทนที่ หรือค่าที่ว่างเปล่าในขณะที่เซลล์ CSV ไม่ว่างเปล่า แสดงว่าการผูกข้อมูลเสีย มีสามสาเหตุหลัก ตามลำดับความบ่อยที่เกิดขึ้น:

ชื่อคอลัมน์และชื่อตัวแปรไม่ตรงกัน ส่วนหัว CSV คือ product_sku และคำขออ่าน {{sku}} เปลี่ยนชื่อหนึ่งในนั้นให้เหมือนกัน
เครื่องหมายจุลภาคที่ไม่ตั้งใจแยกแถว CSV ฟิลด์ข้อความอิสระที่ไม่ได้ใส่เครื่องหมายคำพูดทำให้ทุกคอลัมน์ที่ตามมาเลื่อนไป ดังนั้น expected_status ตอนนี้จึงมีสิ่งที่ควรอยู่ในคอลัมน์ถัดไป ใส่เครื่องหมายคำพูดในฟิลด์หรือเปลี่ยนไฟล์เป็น JSON
พาธไปยังไฟล์ข้อมูลผิดพลาดเมื่อเทียบกับไดเรกทอรีการทำงานใน CI มันใช้งานได้ดีบนแล็ปท็อปของคุณและอ่านอะไรไม่ได้อย่างเงียบๆ ในไปป์ไลน์ ใช้พาธที่สัมพันธ์กับ root ของ repo ที่ขั้นตอน checkout สร้างขึ้น และยืนยันว่าไฟล์มีอยู่จริงในขั้นตอนก่อนการรัน

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

การเชื่อมต่อเข้ากับ CI

ผลตอบแทนคือตารางทั้งหมดจะรันทุกครั้งที่มีการเปลี่ยนแปลงโดยไม่ต้องมีใครคลิก Run นี่คือ GitHub Actions job ที่ติดตั้ง CLI และรัน scenario ที่ขับเคลื่อนด้วย CSV ในทุก Pull Request:

name: Data-driven API tests
on: [pull_request]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install Apidog CLI
        run: npm install -g apidog-cli
      - name: Run data-driven scenario
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
        run: |
          apidog run --access-token $APIDOG_ACCESS_TOKEN \
            -t 605067 -e 1629989 \
            -d ./test-data/checkout-cases.csv \
            --on-error continue \
            -r cli,junit --out-dir ./test-reports
      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: api-test-report
          path: ./test-reports

โทเค็นมาจาก secrets.APIDOG_ACCESS_TOKEN ซึ่งตั้งค่าไว้ครั้งเดียวในการตั้งค่า repo --on-error continue จะรวบรวมทุกแถวที่ล้มเหลวไว้ในรายงานเดียว แทนที่จะหยุดที่ข้อผิดพลาดแรก if: always() บนการอัปโหลดจะเก็บรายงานไว้แม้ว่าการรันจะล้มเหลว ซึ่งเป็นเวลาที่คุณต้องการอ่านมากที่สุด เปลี่ยนพาธ CSV เป็นไฟล์ JSON หรือ ID ชุดข้อมูลที่จัดเก็บไว้ และไม่มีอะไรเปลี่ยนแปลง

การดำเนินการสามอย่างเดียวกันนี้สามารถนำไปใช้กับระบบ CI ใดก็ได้: ติดตั้ง Node.js และ CLI, เปิดเผยโทเค็นเป็นตัวแปรสภาพแวดล้อม, เรียกใช้ apidog run พร้อมกับ -d GitLab CI, Jenkins, CircleCI และอื่นๆ ไม่จำเป็นต้องเขียนการทดสอบของคุณใหม่สำหรับแต่ละแพลตฟอร์ม สำหรับคำแนะนำเชิงลึกเกี่ยวกับ GitHub Actions โปรดดูที่ การทำให้ API tests เป็นไปโดยอัตโนมัติใน GitHub Actions และสำหรับข้อมูลเกี่ยวกับแฟล็กทั้งหมดของ CLI ที่ครอบคลุมเรื่องรีพอร์ตเตอร์ การจัดการข้อผิดพลาด และ TLS โปรดดู คู่มือ Apidog CLI ฉบับสมบูรณ์ ซึ่งจะอธิบายทุกตัวเลือก

เวิร์กโฟลว์ที่ปรับขนาดได้โดยไม่ต้องขยายการทดสอบ

เริ่มต้นด้วยหนึ่งสถานการณ์จำลองและสามแถว สร้างสถานการณ์จำลองในแอปโดยมีการอ้างอิงตัวแปรในคำขอและผลลัพธ์ที่คาดหวังในการยืนยัน เขียน CSV ที่มีเส้นทางปกติ, ข้อผิดพลาดที่ทราบ, และกรณีขอบหนึ่งกรณี รันในเครื่องด้วย -d จนกว่าทั้งสามการทำซ้ำจะมีพฤติกรรมถูกต้อง

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

สุดท้าย นำคำสั่ง apidog run -d ไปใส่ใน CI พร้อมกับ --on-error continue และรีพอร์ตเตอร์ junit ตอนนี้ การเปลี่ยนแปลงที่ทำให้แถวคูปองที่หมดอายุล้มเหลวจะทำให้บิลด์ล้มเหลวทันทีที่ถูกพุช โดยมีการระบุการทำซ้ำที่ชี้ตรงไปยังกรณีที่เสียหาย สถานการณ์จำลองยังคงเป็นสิ่งเล็กๆ ที่อ่านง่าย ไม่ว่าตารางจะกว้างแค่ไหน นั่นคือชัยชนะที่ทับทวี: การครอบคลุมเติบโตขึ้นจากการป้อนข้อมูล และการบำรุงรักษาคงที่

หากคุณยังตัดสินใจอยู่ว่า CLI runner เช่นนี้เหมาะสมกับ stack ของคุณเมื่อเทียบกับเฟรมเวิร์กที่เน้นโค้ดเป็นหลักหรือไม่ การเปรียบเทียบใน เครื่องมือใดที่จะเลือกสำหรับการทดสอบ API ที่ขับเคลื่อนด้วยข้อมูลด้วย CSV หรือ JSON จะเปรียบเทียบแนวทางต่างๆ และ Apidog CLI vs Newman ครอบคลุมสิ่งที่คล้ายกันที่สุดในโลกของ Postman ในรูปแบบ command-line

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

แฟล็ก -d สามารถรับทั้งพาธไฟล์และชุดข้อมูลที่จัดเก็บไว้ได้หรือไม่? แฟล็ก -d จะรับเพียงอย่างใดอย่างหนึ่งต่อการรัน: พาธไฟล์ CSV หรือ JSON ในเครื่อง หรือ test-data ID ที่ชี้ไปยังชุดข้อมูลที่บันทึกไว้ในโปรเจกต์ Apidog ของคุณ คุณส่งค่าเพียงค่าเดียว ใช้พาธไฟล์เมื่อข้อมูลควรมีการกำหนดเวอร์ชันพร้อมกับ repo ของคุณ และใช้ ID ที่จัดเก็บไว้เมื่อมีตารางที่ใช้ร่วมกันอยู่ในแอปและคุณไม่ต้องการคอมมิตสำเนา

ฉันต้องบอก CLI หรือไม่ว่าไฟล์ของฉันเป็น CSV หรือ JSON? ไม่ ตัวรันจะอ่านรูปแบบจากไฟล์นั้นเอง ดังนั้นแฟล็ก -d เดียวกันจึงจัดการได้ทั้งสองอย่าง รักษาชื่อคอลัมน์ (CSV) หรือคีย์อ็อบเจกต์ (JSON) ให้ตรงกับชื่อตัวแปรที่สถานการณ์จำลองของคุณอ้างถึง แล้วคุณสามารถเปลี่ยนรูปแบบได้โดยไม่ต้องเปลี่ยนคำสั่ง

จะเกิดอะไรขึ้นถ้าฉันใช้ -d และ -n ร่วมกัน? จำนวนแถวของไฟล์ข้อมูลจะกำหนดจำนวนการทำซ้ำ ดังนั้น -n จึงไม่จำเป็นต้องใช้กับ -d คุณควรใช้ -n เมื่อคุณต้องการทำซ้ำการรันโดยไม่มีไฟล์ข้อมูล เช่นการทดสอบความทนทาน หรือเมื่อคุณต้องการรันตารางทั้งหมดมากกว่าหนึ่งครั้งโดยเฉพาะ

ทำไมการรันแบบขับเคลื่อนด้วยข้อมูลของฉันจึงผ่านโดยไม่ได้ทดสอบอะไรเลย? สาเหตุที่พบบ่อยที่สุดคือการผูกข้อมูลที่ไม่ได้เกิดขึ้น: ชื่อคอลัมน์ที่ไม่ตรงกับชื่อตัวแปร หรือพาธไฟล์ใน CI ผิดพลาดซึ่งไม่ได้อ่านอะไรเลย รันครั้งเดียวด้วย --verbose และตรวจสอบเนื้อหาคำขอที่ CLI ส่งไป หากคุณเห็น {{variables}} ที่ไม่ได้ถูกแทนที่ หรือค่าว่างเปล่า ให้แก้ไขชื่อที่ไม่ตรงกันหรือพาธก่อนที่จะเชื่อผลลัพธ์สีเขียว

ฉันจะเก็บข้อมูลรับรอง (credentials) ออกจากไฟล์ข้อมูลได้อย่างไร? เก็บโทเค็นและคีย์ทั้งหมดออกจาก CSV หรือ JSON ส่งพวกมันในขณะรันด้วย --global-var หรือ --env-var จาก CI secret store ของคุณ เหมือนกับที่คุณส่ง --global-var "api_key=$RUNTIME_API_KEY" ไฟล์ข้อมูลควรเก็บข้อมูลอินพุตสำหรับการทดสอบและผลลัพธ์ที่คาดหวัง ไม่ใช่สิ่งใดที่ใช้ยืนยันตัวตนของการรัน

ฉันสามารถรันข้อมูลเดียวกันกับ staging และ production ได้หรือไม่? ได้ คุณสามารถรักษาสถานการณ์จำลองและไฟล์ข้อมูลให้คงที่และเปลี่ยนเป้าหมายด้วย -e ชี้การตรวจสอบ pull-request ไปยัง ID สภาพแวดล้อม staging และการทดสอบ smoke test หลังการปรับใช้ไปยัง production โดยใช้สถานการณ์จำลองเดียวกันและข้อมูลเดียวกัน เพียงแค่ค่า -e ที่แตกต่างกัน การแยกสภาพแวดล้อมออกจากข้อมูลคือเหตุผลทั้งหมดที่ทำให้สิ่งนี้ใช้งานได้

สรุป

แฟล็ก -d คือเรื่องราวทั้งหมดของการขับเคลื่อนด้วยข้อมูลสำหรับ Apidog CLI และมันมีความยืดหยุ่นมากกว่าที่เห็นในตอนแรก มันอ่านไฟล์ CSV หรือ JSON ในเครื่อง หรือชุดข้อมูลที่จัดเก็บไว้ในโปรเจกต์ของคุณด้วย ID มันจับคู่กับ -n สำหรับการทำซ้ำ กับ --env-var และ --global-var สำหรับการกำหนดค่าต่อการรัน และกับ --on-error continue เพื่อให้การรันครั้งเดียวแสดงทุกแถวที่ล้มเหลว รันจาก scenario ID ออนไลน์ หรือจากไฟล์ที่ส่งออกแบบออฟไลน์ และอ่านผลลัพธ์ต่อการทำซ้ำผ่านรีพอร์ตเตอร์ junit และ cli

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

แฟล็ก -d อ่านไฟล์อย่างไร