การทดสอบ API ส่วนใหญ่จะทำงานเป็นเส้นตรง เรียกใช้งาน login, เรียกใช้งาน checkout, เรียกใช้งาน endpoint สำหรับใบเสร็จ, และยืนยันผลระหว่างทาง ซึ่งจะใช้งานได้จนกว่าจะมีขั้นตอนใดขั้นตอนหนึ่งล้มเหลวในลักษณะที่ขั้นตอนถัดไปต้องพึ่งพา หากการเข้าสู่ระบบ (login) ส่งคืนค่า 401 การเรียกใช้คำขอ checkout ก็ไม่มีประโยชน์ แย่กว่านั้นคือมันซ่อนความล้มเหลวที่แท้จริงไว้เบื้องหลังความผิดพลาดที่สองที่ทำให้เข้าใจผิด สิ่งที่คุณต้องการคือการทดสอบที่อ่านการตอบสนองจากการเข้าสู่ระบบ ตัดสินใจว่าจะดำเนินการต่อหรือไม่ และรายงานความจริงว่าสิ่งต่างๆ เสียหายที่จุดใด
การตัดสินใจนั้นคือตรรกะแบบมีเงื่อนไข (conditional logic) และคุณสร้างมันขึ้นมาด้วยการควบคุมโฟลว์ (flow control) คู่มือนี้จะแสดงวิธีเพิ่มการแยกสาขาแบบ if/else ในสถานการณ์การทดสอบ API ใน Apidog เพื่อให้การทำงานสามารถแยกสาขาตามการตอบสนองก่อนหน้าได้ คุณจะได้สร้างสถานการณ์จริง: เข้าสู่ระบบ ตรวจสอบรหัสสถานะ และดำเนินการไปยังการชำระเงิน (checkout) เฉพาะเมื่อการเข้าสู่ระบบสำเร็จเท่านั้น หากคุณยังใหม่กับสถานการณ์ Apidog บทแนะนำเกี่ยวกับ วิธีเขียนสถานการณ์การทดสอบด้วย Apidog จะครอบคลุมพื้นฐานเชิงเส้นตรงที่บทความนี้ต่อยอดขึ้นไป สำหรับคำจำกัดความของรูปแบบการแยกสาขาเอง คู่มือ MDN เกี่ยวกับคำสั่งเงื่อนไข เป็นข้อมูลเบื้องต้นที่ดี คุณสามารถดาวน์โหลด Apidog และทำตามได้ฟรี
การควบคุมโฟลว์คืออะไร และอะไรที่ไม่ใช่การควบคุมโฟลว์
ใน Apidog การทดสอบอัตโนมัติจะอยู่ในโมดูล Tests หน่วยที่คุณทำงานด้วยคือ Test Scenario ซึ่งเอกสารอธิบายว่าคล้ายกับ Collection ใน Postman ภายในสถานการณ์ คุณจะจัดเรียง Test Steps: แต่ละขั้นตอนเป็นคำขอแต่ละรายการ หรือเป็น องค์ประกอบควบคุมโฟลว์ เช่น การแยกสาขา, การวนซ้ำ, หรือการหน่วงเวลา
การควบคุมโฟลว์คือชุดขององค์ประกอบควบคุมโฟลว์ ช่วยให้สถานการณ์สามารถทำอะไรได้มากกว่าแค่การดำเนินการตามคำขอตามลำดับ เอกสาร Apidog เกี่ยวกับการควบคุมโฟลว์และการแยกสาขาแบบมีเงื่อนไข คือข้อมูลอ้างอิงเบื้องหลังทุกป้ายกำกับที่ใช้ในที่นี้ สิ่งที่บทความนี้เน้นคือ Conditional Branching ซึ่งเป็นชื่อของ Apidog สำหรับ if/else การแยกสาขาจะอ่านค่าที่คุณป้อนเข้าไป ทดสอบค่านั้นกับเงื่อนไข และเรียกใช้ชุดขั้นตอนหนึ่งเมื่อเงื่อนไขเป็นจริง และอีกชุดหนึ่งเมื่อเงื่อนไขไม่เป็นจริง
ขอชี้แจงล่วงหน้า เนื่องจากสองสิ่งนี้มักจะสับสนกัน การแยกสาขาไม่ใช่การวนซ้ำ การแยกสาขาจะตัดสินใจเพียงครั้งเดียวว่าบล็อกของขั้นตอนจะทำงานหรือไม่ การวนซ้ำจะเรียกใช้บล็อกหลายครั้ง Apidog มีฟีเจอร์แยกต่างหากสำหรับการวนซ้ำ เรียกว่า For Loops และ ForEach Loops และมันแก้ปัญหาที่แตกต่างกัน: การทำซ้ำคำขอเดิมซ้ำๆ ในช่วงข้อมูลหรือในรายการของอาร์เรย์ หากคุณต้องการวนดูอาร์เรย์ของ ID คำสั่งซื้อ นั่นคือ ForEach loop ซึ่งครอบคลุมใน บทช่วยสอน ForEach loop ไม่ใช่การแยกสาขา คู่มือนี้จะเน้นที่ if/else
เอกสารของ Apidog ไม่ได้ระบุข้อจำกัดแบบฟรีเทียบกับแบบเสียเงินสำหรับการควบคุมโฟลว์, การแยกสาขาแบบมีเงื่อนไข, การวนซ้ำ, หรือการส่งข้อมูลระหว่างขั้นตอน และไม่มีความแตกต่างระหว่างคลาวด์กับแบบโฮสต์ด้วยตัวเองสำหรับฟีเจอร์เหล่านี้ หากคุณสามารถสร้างสถานการณ์ได้ คุณก็สามารถเพิ่มการแยกสาขาเข้าไปได้
สร้างสถานการณ์ที่แยกสาขาตามการตอบสนองจากการเข้าสู่ระบบ
นี่คือเป้าหมาย ผู้ใช้เข้าสู่ระบบ หาก endpoint สำหรับการเข้าสู่ระบบส่งคืนค่า 200 สถานการณ์จะดำเนินการสร้างการชำระเงิน (checkout) หากส่งคืนค่าอื่นใด สถานการณ์จะหยุดและรายงานความล้มเหลวแทนที่จะแสร้งทำเป็นว่าการชำระเงินได้ทำงานแล้ว
ขั้นตอนที่ 1: สร้างสถานการณ์การทดสอบ
เปิด Apidog และไปที่โมดูล Tests คลิกเครื่องหมาย `+` ถัดจากแถบค้นหาเพื่อสร้าง Test Scenario ใหม่ เลือกไดเรกทอรีที่จะจัดเก็บ และตั้งค่าความสำคัญเพื่อสิ้นสุดการสร้าง ตอนนี้คุณมีสถานการณ์ว่างเปล่าพร้อมสำหรับขั้นตอนต่างๆ แล้ว
ขั้นตอนที่ 2: เพิ่มคำขอเข้าสู่ระบบเป็นขั้นตอนแรก
เพิ่ม Test Step แรกของคุณ Apidog มีหลายวิธีในการนำคำขอเข้ามา: นำเข้าจากข้อมูลจำเพาะของ endpoint ที่มีอยู่, นำเข้าจากกรณี endpoint ที่บันทึกไว้, เพิ่มคำขอที่กำหนดเองโดยตรง, หรือเพิ่มจากสตริง cURL สำหรับการเริ่มต้นอย่างรวดเร็ว ให้เพิ่มคำขอที่กำหนดเอง ตั้งค่าเป็น POST และชี้ไปยัง endpoint การรับรองความถูกต้องของคุณพร้อมกับเนื้อหา JSON:
POST https://api.your-store.com/v1/login
Content-Type: application/json
{
"email": "dana@example.com",
"password": "correct-horse-battery-staple"
}
เรียกใช้ขั้นตอนนี้เพียงครั้งเดียวเพื่อยืนยันว่ามันส่งคืนสิ่งที่คุณคาดหวัง การเข้าสู่ระบบที่สำเร็จจะส่งคืนค่า 200 และโทเค็นในเนื้อหา ซึ่งมีลักษณะดังนี้:
{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"userId": "usr_10482"
}
ขั้นตอนที่ 3: เข้าสู่โหมด Orchestrate
คลิกขั้นตอนใดก็ได้เพื่อเข้าสู่โหมด Orchestrate แผงด้านซ้ายจะแสดงโฟลว์โดยรวมของสถานการณ์ แผงด้านขวาจะแสดงรายละเอียดของขั้นตอนที่คุณเลือก มุมมองแบบแยกนี้คือที่ที่คุณจะจัดเรียงการแยกสาขา หากคุณต้องการจัดเรียงขั้นตอนใหม่ ให้ลากไอคอน `≡` บนขั้นตอนนั้นเพื่อย้าย
ขั้นตอนที่ 4: เพิ่มการแยกสาขาแบบมีเงื่อนไข
คลิกปุ่ม `Add Step` นี่คือวิธีหลักในการแทรกองค์ประกอบควบคุมโฟลว์ใดๆ จากเมนู ให้เลือก `Conditional Branching` นั่นจะสร้างคำสั่ง If ซึ่งเป็นการแยกสาขาที่ว่างเปล่าที่รอเงื่อนไขและขั้นตอนบางอย่างที่จะเรียกใช้
ตอนนี้สร้างเงื่อนไข คุณต้องป้อนรหัสสถานะของการตอบสนองจากการเข้าสู่ระบบเข้าสู่การแยกสาขา Apidog สร้างเงื่อนไขจากชุดตัวดำเนินการตัดสิน (judgment operators) ที่กำหนดไว้ รายการทั้งหมดคือ: เท่ากับ (Equals), ไม่เท่ากับ (Does not equal), มีอยู่ (Exists), ไม่มีอยู่ (Does not exist), น้อยกว่า (Less than), น้อยกว่าหรือเท่ากับ (Less than or equal), มากกว่า (Greater than), มากกว่าหรือเท่ากับ (Greater than or equal), ตรงกับ Regex (Matches with Regex), มี (Contains), ไม่มี (Does not contain), ว่างเปล่า (Is empty), ไม่ว่างเปล่า (Is not Empty), อยู่ในรายการ (In List), และ ไม่อยู่ในรายการ (Not in List)
สำหรับการแยกสาขานี้ คุณต้องการให้รหัสสถานะการเข้าสู่ระบบเท่ากับ 200 ดังนั้นเงื่อนไขคือ: สถานะการตอบสนองการเข้าสู่ระบบ `Equals` `200`
ขั้นตอนที่ 5: อ้างอิงการตอบสนองก่อนหน้าในเงื่อนไข
ในการนำผลลัพธ์การเข้าสู่ระบบเข้าสู่ช่องเงื่อนไข คุณมีสองวิธี
วิธีแรกไม่จำเป็นต้องตั้งค่าใดๆ คลิกเข้าไปในช่องค่าของเงื่อนไขแล้วคลิกไอคอนไม้กายสิทธิ์ จากนั้นเลือก `Retrieve pre-step data` Apidog ให้คุณชี้ไปยังขั้นตอนการเข้าสู่ระบบก่อนหน้านั้นโดยตรงและดึงค่าออกจากผลลัพธ์ ภายใต้พื้นฐานนี้จะใช้การอ้างอิงก่อนขั้นตอนด้วยไวยากรณ์ `{{$.<step id>.response.body.<field path>}}` ตัวอย่างเช่น หากคุณต้องการโทเค็นจากเนื้อหาการเข้าสู่ระบบแทนสถานะ คุณจะอ้างอิง `{{$.1.response.body.token}}` โดยที่ `1` คือ ID ของขั้นตอนการเข้าสู่ระบบ
สองสิ่งที่ควรทราบเกี่ยวกับ `Retrieve pre-step data` คือ มันทำงานเฉพาะในโมดูล Tests ไม่ใช่ในโมดูล APIs และมันจะแก้ไขค่าได้ก็ต่อเมื่อคุณเรียกใช้สถานการณ์ทั้งหมดเท่านั้น ไม่ใช่เมื่อคุณเรียกใช้ขั้นตอนเดียวแบบแยก หากการอ้างอิงก่อนขั้นตอนดูว่างเปล่าในระหว่างการเรียกใช้แบบเดี่ยว นั่นเป็นเรื่องปกติ ให้เรียกใช้สถานการณ์ทั้งหมดแล้วค่าจะถูกเติมเข้ามา
วิธีที่สองใช้ตัวแปรแบบมีชื่อและทำงานได้ทั้งในโมดูล Tests และ APIs ในคำขอเข้าสู่ระบบ ให้เปิด post-processors และเพิ่มการกระทำ `Extract Variable` ดึงข้อมูลฟิลด์ที่คุณสนใจด้วยนิพจน์ JSONPath เช่น `$.token` แล้ว Apidog จะเก็บไว้ภายใต้ชื่อ จากนั้นคุณสามารถอ้างอิงได้ทุกที่ในภายหลังเป็น `{{token}}` วิธีนี้เป็นแนวทางที่ยืดหยุ่นกว่าเมื่อคุณต้องการให้ค่าเดียวกันใช้งานได้ในหลายโมดูลหรือในหลายสาขา กลไกเชิงลึกของการย้ายค่าระหว่างขั้นตอนจะกล่าวถึงในคู่มือ วิธีส่งข้อมูลระหว่างขั้นตอนการทดสอบ
สำหรับสาขาที่ใช้รหัสสถานะ การใช้ `Retrieve pre-step data` บนสถานะของขั้นตอนการเข้าสู่ระบบเป็นเส้นทางที่สั้นที่สุด
ขั้นตอนที่ 6: เพิ่มสาขา Else
เลื่อนเมาส์ไปที่บล็อก If แล้วคลิก `+ Else` นั่นจะทำให้คุณได้เส้นทางทางเลือกที่ทำงานเมื่อเงื่อนไขเป็นเท็จ ซึ่งหมายถึงการเข้าสู่ระบบไม่ได้ส่งคืนค่า 200
ตอนนี้เติมทั้งสองด้าน:
- ภายในบล็อก If ให้เพิ่มคำขอชำระเงิน (checkout) เป็น Test Step นี่คือเส้นทางแห่งความสำเร็จ มันจะทำงานก็ต่อเมื่อการเข้าสู่ระบบส่งคืนค่า 200 เท่านั้น หากการชำระเงินต้องการโทเค็นการเข้าสู่ระบบ ให้อ้างอิงที่นี่ด้วย `{{token}}` (หากคุณดึงออกมาแล้ว) หรือด้วยการอ้างอิงก่อนขั้นตอนไปยังเนื้อหาการเข้าสู่ระบบ การเรียกใช้การชำระเงินจริงมักจะมีการส่ง Bearer Token ในส่วนหัว `Authorization` ซึ่งเป็นรูปแบบเดียวกับที่ เอกสาร API ของ Stripe ใช้สำหรับคำขอที่ต้องมีการรับรองความถูกต้อง
- ภายในบล็อก Else ให้เพิ่มขั้นตอนที่ทำให้ความล้มเหลวเด่นชัด ทางเลือกทั่วไปคือการส่งคำขอไปยัง endpoint สำหรับการบันทึก (logging) หรือการแจ้งเตือน (notification) หรือคำขอที่กำหนดเองพร้อมกับการยืนยัน (assertion) ที่ล้มเหลวเสมอ เพื่อให้รายงานสถานการณ์ระบุการทำงานนี้ได้อย่างชัดเจน
สถานการณ์ของคุณตอนนี้อ่านเหมือนตรรกะธรรมดา: หากการเข้าสู่ระบบเท่ากับ 200 ให้ดำเนินการชำระเงิน มิฉะนั้น ให้รายงานและหยุด
ขั้นตอนที่ 7: บันทึก
คลิก `Save All` เพื่อบันทึกสถานการณ์ การเปลี่ยนแปลงที่ยังไม่ได้บันทึกจะแสดงจุดบ่งชี้ ดังนั้นหากคุณเห็นจุดนั้น คุณยังมีงานที่ต้องเขียน เรียกใช้สถานการณ์ทั้งหมดและดูว่าการแยกสาขาทำงานอย่างไร ชี้การเข้าสู่ระบบไปยังข้อมูลรับรองที่ถูกต้อง แล้วบล็อก If จะทำงาน ชี้ไปยังข้อมูลรับรองที่ไม่ถูกต้อง แล้วบล็อก Else จะทำงานแทน
ความหลากหลายและการควบคุมโฟลว์ขั้นสูง
เมื่อการแยกสาขาพื้นฐานทำงานได้ บล็อกประกอบเดียวกันนี้ก็ครอบคลุมการใช้งานได้มากมาย
แยกสาขาตามฟิลด์ในเนื้อหา ไม่ใช่แค่สถานะ รหัสสถานะเป็นกรณีทั่วไป แต่เงื่อนไขสามารถอ่านค่าใดๆ ที่คุณสามารถอ้างอิงได้ สมมติว่าการเข้าสู่ระบบของคุณส่งคืน `200` แม้สำหรับบัญชีที่ถูกล็อก โดยมีสถานะจริงอยู่ในฟิลด์ `status` ให้เรียกใช้ `{{$.1.response.body.status}}` และใช้ตัวดำเนินการ `Equals` เทียบกับ `"active"` หรือใช้ `Contains` เทียบกับสตริงข้อความ รายการตัวดำเนินการยังให้การตรวจสอบช่วงด้วย: `Greater than` บนยอดคงเหลือที่ส่งคืน, `In List` เพื่อทดสอบว่าบทบาทที่ส่งคืนเป็นหนึ่งในค่าที่อนุญาตหลายค่าหรือไม่
รวมการแยกสาขาเข้ากับการวนซ้ำ การแยกสาขาและการวนซ้ำทำงานร่วมกันได้ ภายใน ForEach loop ที่วนซ้ำบนอาร์เรย์ของ ID ผลิตภัณฑ์ ขั้นตอน Conditional Branching สามารถข้ามผลิตภัณฑ์ที่สินค้าหมดและประมวลผลส่วนที่เหลือ การอ้างอิงดัชนีของลูป `{{$.<loop step id>.index}}` เริ่มต้นที่ 0 และองค์ประกอบ ForEach คือ `{{$.<loop step id>.element.<field path>}}` ลูปเป็นหัวข้อของตัวเอง; บทช่วยสอน ForEach loop จะกล่าวถึงเรื่องนี้อย่างละเอียด
หยุดลูปก่อนกำหนดด้วย Break If เมื่อคุณกำลังวนซ้ำ องค์ประกอบ `Break If condition` จะยุติลูปทันทีที่เงื่อนไขเป็นจริง คุณสามารถลากมันเพื่อจัดตำแหน่งใหม่และเพิ่มมันได้มากกว่าหนึ่งครั้งในลูป
จัดการข้อผิดพลาดด้วย On Error ลูปจะมีองค์ประกอบ `On Error` ที่ถูกตรึงไว้ที่จุดเริ่มต้นของลูป ซึ่งคุณไม่สามารถย้ายได้ ตัวเลือกของมันจะตัดสินใจว่าจะเกิดอะไรขึ้นเมื่อคำขอภายในลูปเกิดข้อผิดพลาด: `Ignore` ดำเนินการต่อด้วยคำขอถัดไป, `Continue` ข้ามคำขอที่เหลือของรอบปัจจุบัน, `Break execution` หยุดลูปและดำเนินการต่อหลังจากนั้น, และ `End execution` หยุดสถานการณ์ทั้งหมด
เพิ่มการรอ (Wait) ระหว่างขั้นตอน บางครั้งบริการปลายทางจำเป็นต้องรอสักครู่ก่อนที่จะสะท้อนการเขียน องค์ประกอบ `Wait` จะเพิ่มการหน่วงเวลาที่วัดเป็นมิลลิวินาที ซึ่งมีประโยชน์ระหว่างการเรียกสร้าง (create call) และการอ่านที่ตรวจสอบมัน
อ้างอิงค่าภายในสคริปต์ หากการแยกสาขาต้องการตรรกะที่ซับซ้อนเกินกว่ารายการตัวดำเนินการ สคริปต์ pre-processor หรือ post-processor สามารถคำนวณได้ ภายในสคริปต์คุณไม่สามารถใช้ไวยากรณ์ `{{variable}}` ได้โดยตรง ให้ใช้ `pm.variables.get("$.2.response.body.token")` แทน โดยจับคู่ ID ขั้นตอนและเส้นทางฟิลด์ สำหรับรูปแบบที่กว้างขึ้นของการเชื่อมโยงคำขอเพื่อให้คำขอหนึ่งป้อนข้อมูลให้อีกคำขอหนึ่ง โปรดดูคู่มือเกี่ยวกับ การเชื่อมโยงคำขอ (request chaining) และบทความเชิงลึกเกี่ยวกับ การจัดการการทดสอบ API และการส่งข้อมูล
หมายเหตุเกี่ยวกับการอ้างอิงตัวเอง: สถานการณ์ไม่สามารถอ้างอิงสถานการณ์การทดสอบดั้งเดิมได้เอง การป้องกันนี้ช่วยป้องกันการวนซ้ำไม่รู้จบโดยไม่ตั้งใจเมื่อคุณซ้อนสถานการณ์
ทำให้เวิร์กโฟลว์เป็นอัตโนมัติด้วย Apidog CLI
สถานการณ์ที่คุณเพิ่งสร้างไม่จำเป็นต้องทำงานภายในแอปเท่านั้น Apidog มาพร้อมกับตัวรันบรรทัดคำสั่งที่เรียกใช้สถานการณ์ที่บันทึกไว้แบบ headless ซึ่งเป็นสิ่งที่คุณต้องการใน CI อย่างแท้จริง ติดตั้งและเข้าสู่ระบบ:
npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
จากนั้นเรียกใช้สถานการณ์การแยกสาขาของคุณด้วย ID โดยชี้ไปยังสภาพแวดล้อมและเลือกตัวสร้างรายงาน (reporter):
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
ในที่นี้ `-t` คือ ID สถานการณ์การทดสอบ, `-e` คือ ID สภาพแวดล้อม, และ `-r` คือตัวสร้างรายงาน ใช้ `cli` สำหรับเอาต์พุตคอนโซล หรือ `html` และ `junit` สำหรับสิ่งประดิษฐ์ที่ไปป์ไลน์ของคุณสามารถเผยแพร่ได้; แยกด้วยเครื่องหมายจุลภาค เช่น `-r html,cli` เพื่อส่งออกพร้อมกันหลายรายการ การแยกสาขาจะทำงานในลักษณะเดียวกับในแอป: ตัวรันจะอ่านการตอบสนองจากการเข้าสู่ระบบ เลือกเส้นทาง If หรือ Else และรหัสออกจะสะท้อนผลลัพธ์ ดังนั้นการเข้าสู่ระบบที่ล้มเหลวจะทำให้การสร้าง (build) ล้มเหลว การตั้งค่าทั้งหมดอยู่ใน คู่มือการติดตั้ง Apidog CLI และการเชื่อมต่อเข้ากับไปป์ไลน์จะครอบคลุมใน คู่มือ Apidog CLI GitHub Actions หากคุณต้องการเรียกใช้สถานการณ์เดียวกันตามเวลาที่กำหนดแทนที่จะเรียกใช้ทุกครั้งที่มีการคอมมิต โปรดดูวิธี ตั้งเวลาการทดสอบ API ใน Apidog
คำถามที่พบบ่อย (FAQ)
Conditional Branching และ loop ใน Apidog แตกต่างกันอย่างไร?
Conditional Branching จะตัดสินใจเพียงครั้งเดียวว่าบล็อกของขั้นตอนจะทำงานหรือไม่ โดยขึ้นอยู่กับเงื่อนไข ลูปจะทำงานบล็อกซ้ำๆ ใช้การแยกสาขาเมื่อคุณมีการตัดสินใจแบบเลือกอย่างใดอย่างหนึ่ง เช่น ดำเนินการชำระเงินเฉพาะเมื่อการเข้าสู่ระบบสำเร็จเท่านั้น ใช้ For หรือ ForEach loop เมื่อคุณต้องการทำซ้ำคำขอตามจำนวนครั้งหรือบนอาร์เรย์ บทช่วยสอน ForEach loop ครอบคลุมการวนซ้ำทั้งหมด
เหตุใดการอ้างอิง `Retrieve pre-step data` ของฉันจึงว่างเปล่า?
มีสองสาเหตุหลัก ประการแรก `Retrieve pre-step data` ทำงานเฉพาะในโมดูล Tests เท่านั้น ไม่ใช่โมดูล APIs ประการที่สอง มันจะแก้ค่าได้ก็ต่อเมื่อคุณเรียกใช้สถานการณ์การทดสอบทั้งหมดเท่านั้น หากคุณเรียกใช้ขั้นตอนเดียวแบบแยก การอ้างอิงจะไม่มีอะไรให้ชี้ถึง ให้เรียกใช้สถานการณ์ทั้งหมดแล้วค่าจะถูกเติมเข้ามา
ฉันสามารถแยกสาขาตามฟิลด์ภายในเนื้อหาการตอบสนองได้หรือไม่ ไม่ใช่แค่รหัสสถานะ?
ได้ คุณสามารถอ้างอิงฟิลด์ด้วยนิพจน์ pre-step เช่น `{{$.1.response.body.status}}` หรือดึงข้อมูลเข้าสู่ตัวแปรที่มีชื่อ จากนั้นเลือกตัวดำเนินการ เช่น `Equals`, `Contains` หรือ `In List` ค่าใดๆ ที่คุณสามารถอ้างอิงได้สามารถใช้เป็นเงื่อนไขได้ การย้ายค่าเหล่านั้นจะครอบคลุมใน วิธีส่งข้อมูลระหว่างขั้นตอนการทดสอบ
ฉันจะใช้ตัวแปรภายในสคริปต์แทนที่จะเป็น condition builder ได้อย่างไร?
สคริปต์ไม่รองรับไวยากรณ์ `{{variable}}` ให้ใช้ `pm.variables.get("$.2.response.body.token")` ในสคริปต์ pre- หรือ post-processor โดยจับคู่ ID ขั้นตอนและเส้นทางฟิลด์ที่คุณต้องการ
การแยกสาขามีค่าใช้จ่ายเพิ่มเติม หรือต้องใช้เวอร์ชันที่โฮสต์ด้วยตัวเองหรือไม่?
เอกสารของ Apidog ไม่ได้ระบุข้อจำกัดของแผนสำหรับ flow control, conditional branching, loops, หรือการส่งข้อมูล และไม่มีความแตกต่างระหว่างคลาวด์กับแบบโฮสต์ด้วยตัวเองสำหรับฟีเจอร์เหล่านี้ หากคุณสามารถสร้างสถานการณ์ได้ คุณก็สามารถเพิ่มการแยกสาขาเข้าไปได้
สรุป
การทดสอบแบบเส้นตรงจะบอกคุณว่ามีบางอย่างเสีย การทดสอบแบบแยกสาขาจะบอกคุณว่าเสียที่ไหน และหยุดการเสียเวลาไปกับขั้นตอนที่ไม่สามารถสำเร็จได้อีกต่อไป เพิ่มขั้นตอน Conditional Branching ป้อนข้อมูลการตอบสนองก่อนหน้าด้วย `Retrieve pre-step data` หรือตัวแปรที่ดึงออกมา เชื่อมโยง If และ `+ Else` แล้วสถานการณ์ของคุณจะทำการตัดสินใจในแบบที่ API จริงของคุณทำ เมื่อมันทำงานในแอปได้ คำสั่ง `apidog run` เพียงครั้งเดียวก็นำตรรกะเดียวกันนั้นไปใช้ใน CI ได้ ลองใช้ Apidog ฟรี โดยไม่จำเป็นต้องใช้บัตรเครดิต และเปลี่ยนการทดสอบแบบเส้นตรงของคุณให้เป็นสถานการณ์ที่คิดได้