วิธีใช้การคิวรีฐานข้อมูลในการทดสอบ API ด้วย Apidog (MySQL, MongoDB, Redis)

รหัสสถานะสีเขียวหลอกตาคุณ POST /orders endpoint ของคุณส่งคืน 201 Created, เนื้อหาการตอบกลับดูสมบูรณ์แบบ และการทดสอบของคุณผ่าน แต่ข้อมูลในแถวนั้นลงสู่ฐานข้อมูลด้วยสถานะที่ถูกต้องจริงหรือไม่? จำนวนสินค้าคงคลังลดลงหรือไม่? การทดสอบที่อ่านเพียงการตอบกลับ HTTP ตรวจสอบสิ่งที่ API *พูด* ไม่ใช่สิ่งที่ระบบ *ทำ* เพื่อปิดช่องว่างนั้น คุณต้องดูที่ฐานข้อมูลโดยตรง

นั่นคือจุดที่การสืบค้นฐานข้อมูลภายในสถานการณ์การทดสอบมีประโยชน์อย่างยิ่ง คุณกำหนดสถานะเริ่มต้นที่ทราบก่อนส่งคำขอ ส่งคำขอ จากนั้นสืบค้นตารางเพื่อยืนยันความจริงบนดิสก์ Apidog มีคุณสมบัตินี้ในตัวผ่าน Database Connections และตัวประมวลผล Database Operation ทำให้คุณสามารถรันคำสั่ง SQL หรือ NoSQL เป็นขั้นตอนในสถานการณ์เดียวกันที่ขับเคลื่อนการเรียก HTTP ของคุณ โดยไม่ต้องมีสคริปต์ภายนอกมาเชื่อม หากคุณยังใหม่กับการสร้างสถานการณ์ คู่มือเกี่ยวกับ วิธีการเขียนสถานการณ์การทดสอบด้วย Apidog จะครอบคลุมพื้นฐานระดับคำขอที่บทความนี้ต่อยอด สำหรับการทบทวนว่าระบบเก็บข้อมูลเชิงสัมพันธ์จำลองข้อมูลนี้อย่างไร ภาพรวม ฝั่งเซิร์ฟเวอร์ ของ MDN เป็นบทนำที่ดี

การดำเนินการฐานข้อมูลในการทดสอบให้อะไรแก่คุณบ้าง

การทดสอบ API ที่ไม่แตะฐานข้อมูลเลยนั้นเป็นเหมือนกล่องดำ มันเชื่อถือการตอบกลับ ส่วนใหญ่ก็ไม่มีปัญหา แต่ข้อผิดพลาดที่น่าสนใจมักจะอยู่ในช่องว่างระหว่างสิ่งที่ API ส่งคืนกับสิ่งที่มันเก็บไว้ถาวร: เช่น ฟิลด์สถานะที่ไม่เคยเปลี่ยน, foreign key ที่ชี้ไปยังที่ที่ไม่มีอยู่, หรือการ soft-delete ที่กลายเป็นการ hard-delete

ขั้นตอนฐานข้อมูลช่วยให้คุณทำสามสิ่งในการทดสอบที่การทดสอบ HTTP เพียงอย่างเดียวไม่สามารถทำได้:

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

Apidog แบ่งคุณสมบัตินี้ออกเป็นสองส่วน ขั้นแรก คุณสร้างการเชื่อมต่อที่สามารถนำกลับมาใช้ใหม่ได้ภายใต้ Settings > Database Connections จากนั้นคุณแนบขั้นตอน Database Operation เข้ากับคำขอเป็น Pre Processor (ทำงานก่อนคำขอ) หรือ Post Processor (ทำงานหลังจากนั้น) การเชื่อมต่อเดียวนี้ สามารถนำกลับมาใช้ใหม่ได้ในทุกสถานการณ์ในโปรเจกต์

ข้อควรทราบเกี่ยวกับการรองรับก่อนที่คุณจะวางแผน MySQL, SQL Server (2014 และใหม่กว่า), PostgreSQL และ Oracle ใช้งานได้ในแผนบริการฟรี ClickHouse, MongoDB และ Redis เป็นแบบเสียเงิน เอกสาร MongoDB ระบุไว้อย่างชัดเจน: การเชื่อมต่อกับ MongoDB เป็นคุณสมบัติแบบเสียเงิน เช่นเดียวกับ Redis ดังนั้นขั้นตอนการทำงานของ MySQL ด้านล่างนี้จะอยู่ในระดับฟรี ในขณะที่ส่วนของ Mongo และ Redis ต้องใช้แผนแบบเสียเงิน

ขั้นตอนที่ 1: สร้างการเชื่อมต่อฐานข้อมูล

เปิด Settings > Database Connections แล้วคลิก + New ที่มุมขวาบน เลือกประเภทฐานข้อมูลของคุณ จากนั้นกรอกข้อมูลในช่องการเชื่อมต่อ:

• โฮสต์ (เช่น db.staging.internal หรือ 127.0.0.1)
• พอร์ต (3306 สำหรับ MySQL)
• ชื่อผู้ใช้ และ รหัสผ่าน
• ชื่อฐานข้อมูล (เช่น shop)

หากฐานข้อมูลของคุณอยู่หลัง bastion ให้ขยายส่วน SSH Tunnel และเพิ่มรายละเอียด jump-host MySQL ยังมีโหมด SSL ที่มีสี่ตัวเลือก: Prefer (ค่าเริ่มต้น ซึ่งจะลองใช้ SSL แล้วถอยกลับ), Require, Verify CA และ Verify Full เลือกโหมดที่เข้มงวดที่สุดที่เซิร์ฟเวอร์ของคุณรองรับ จากนั้นคลิก Save

สองข้อควรระวังในการเชื่อมต่อที่จะช่วยให้คุณไม่สับสนในภายหลัง:

• การตรวจสอบสิทธิ์ MySQL 8 ปลั๊กอิน caching_sha2_password เริ่มต้นอาจปฏิเสธการเชื่อมต่อได้ หากคุณพบข้อผิดพลาดในการตรวจสอบสิทธิ์ ให้เปลี่ยนผู้ใช้ด้วย ALTER USER 'tester'@'%' IDENTIFIED WITH mysql_native_password BY '...'; แล้วลองอีกครั้ง คู่มืออ้างอิง MySQL ครอบคลุมความแตกต่างของปลั๊กอินอย่างละเอียด
• ข้อมูลประจำตัวเป็นแบบโลคอล รายละเอียดการเชื่อมต่อจะถูกเก็บไว้ในเครื่องของคุณเองและไม่ได้ซิงค์กับคลาวด์ เพื่อนร่วมทีมแต่ละคนต้องตั้งค่าการเชื่อมต่อด้วยตัวเอง หากคุณกำลังประสานงานทีม บันทึกเกี่ยวกับการ แชร์การตั้งค่าการเชื่อมต่อฐานข้อมูล จะอธิบายขั้นตอนการทำงาน

ขั้นตอนที่ 2: กำหนดข้อมูลเริ่มต้นด้วย Pre Processor

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

เปิดคำขอของคุณ ค้นหา Pre Processors วางเมาส์เหนือ Add Database Processor แล้วเลือก Database operation ตั้งชื่อมันว่า seed customer เลือกการเชื่อมต่อ MySQL ของคุณ จากนั้นใต้ Enter SQL Command ให้เขียนคำสั่ง insert ตัวแปรไดนามิกใช้ไวยากรณ์ {{variable_name}} ดังนั้นคุณสามารถดึงค่าได้โดยตรงจากสภาพแวดล้อมของคุณ:

INSERT INTO customers (id, email, status)
VALUES ({{customer_id}}, '{{customer_email}}', 'active')
ON DUPLICATE KEY UPDATE status = 'active';

ตอนนี้คำขอจะทำงานกับสถานะที่รับประกันได้ ลูกค้ามีอยู่จริง มีสถานะใช้งานอยู่ และมี ID ที่ขั้นตอนต่อไปของคุณทราบอยู่แล้ว การกำหนดข้อมูลเริ่มต้นใน Pre Processor ช่วยให้แต่ละการทดสอบเป็นอิสระ แทนที่จะอาศัยผลข้างเคียงจากการเรียงลำดับการทดสอบ

ขั้นตอนที่ 3: ยืนยันกับฐานข้อมูลด้วย Post Processor

นี่คือหัวใจสำคัญ คำขอของคุณสร้างคำสั่งซื้อ หลังจากส่งคืนค่าแล้ว คุณจะสืบค้นตาราง orders เพื่อยืนยันว่าแถวนั้นมีอยู่จริงพร้อมสถานะที่ถูกต้อง

เพิ่มคำขอที่เรียกใช้ API ของคุณ:

POST /api/orders
Content-Type: application/json

{
  "customer_id": {{customer_id}},
  "items": [{ "sku": "APRON-01", "qty": 2 }]
}

สมมติว่าเนื้อหาการตอบกลับมี ID คำสั่งซื้อใหม่ ซึ่งคุณจับเก็บไว้ในตัวแปรชื่อ order_id ด้วยการยืนยันการตอบกลับปกติ ตอนนี้เปิด Post Processors ในคำขอนั้น ในโหมด DESIGN คุณจะพบพวกมันในแท็บ Run; ในโหมด DEBUG คุณจะพบพวกมันในแท็บ Request วางเมาส์เหนือ Add PostProcessor เลือก Database operation ตั้งชื่อว่า verify order row และเลือกการเชื่อมต่อของคุณ

ภายใต้ Configure Operation เลือกการดำเนินการและป้อน SQL:

SELECT id, status, total_cents
FROM orders
WHERE id = {{order_id}};

ผลลัพธ์การสืบค้นจะกลับมาเป็นอาร์เรย์ของออบเจกต์ แถวละหนึ่งออบเจกต์ หากต้องการดึงฟิลด์เดียวออกมา ให้เปิด Extract Results (Optional) และเพิ่มรายการ Extract Result To Variable ตั้งค่า Variable Name เช่น db_order_status และ JSONPath Expression ที่แยกฟิลด์ออกจากแถวแรก:

$[0].status

คลิก Send และตรวจสอบ Console เพื่อดูผลลัพธ์ดิบและค่าที่ดึงออกมา ตอนนี้ db_order_status จะเก็บสิ่งที่อยู่บนดิสก์จริง เพิ่มการยืนยันว่ามันเท่ากับ pending (หรืออะไรก็ตามที่ API ของคุณควรตั้งค่า) และการทดสอบของคุณก็จะยืนยันความคงทนของข้อมูล ไม่ใช่แค่การตอบกลับ HTTP เท่านั้น หาก API ส่งคืน 201 แต่เขียน status = 'draft' นี่คือขั้นตอนที่จะตรวจจับได้

ขั้นตอนที่ 4: ดึงค่าจากฐานข้อมูลและนำไปใช้ในขั้นตอนถัดไป

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

ลองนึกภาพขั้นตอนที่การสร้างคำสั่งซื้อยังสร้าง fulfillment_ref ภายในบนเซิร์ฟเวอร์ ซึ่งถูกเขียนลงในแถวแต่ถูกละเว้นจากการตอบกลับ API คำขอถัดไปของคุณ GET /api/fulfillments/{ref} ต้องการค่านั้น สืบค้นหามันใน Post Processor:

SELECT fulfillment_ref
FROM orders
WHERE id = {{order_id}};

ดึงค่าด้วย Variable Name fulfillment_ref และ JSONPath Expression $[0].fulfillment_ref เนื่องจาก Apidog กำหนดขอบเขตตัวแปรนั้นให้กับสภาพแวดล้อม คำขอถัดไปของคุณจึงเพียงแค่อ้างอิง {{fulfillment_ref}} ในพาธหรือเนื้อหา และรับค่าจริงที่เซิร์ฟเวอร์สร้างขึ้น นี่คือรูปแบบเดียวกับการเชื่อมโยงการตอบกลับ HTTP ซึ่งครอบคลุมอยู่ใน การส่งข้อมูลระหว่างขั้นตอนการทดสอบ และ การจัดระเบียบการทดสอบ API และการส่งข้อมูล เว้นแต่ว่าแหล่งที่มาของความจริงคือตารางแทนที่จะเป็นเนื้อหา JSON

MongoDB และ Redis: ตัวเลือก NoSQL

ตัวประมวลผลทำงานในลักษณะเดียวกันสำหรับ NoSQL stores โดยมีพื้นผิวการกำหนดค่าที่แตกต่างกัน ทั้งสองเป็นคุณสมบัติแบบเสียเงิน ดังนั้นโปรดวางแผนให้เหมาะสม เอกสารประกอบ Apidog มีข้อมูลอ้างอิงฟิลด์ฉบับเต็มหากคุณต้องการ

MongoDB

เพิ่มขั้นตอน Database Operation และเลือก MongoDB เป็นประเภท แทนที่จะเป็น SQL ดิบ คุณจะได้เมนูดรอปดาวน์ Operation Type ที่มี Find, Insert, Update, Delete และ Run Database Command สำหรับการดำเนินการ CRUD ใดๆ Collection Name เป็นสิ่งที่จำเป็น ช่อง Query Condition รับค่า JSON:

{ "_id": "65486728456e79993a150f1c" }

Apidog จะแปลงสตริง ID ที่ตรงกันให้เป็น ObjectId โดยอัตโนมัติ ดังนั้นคุณไม่จำเป็นต้องห่อหุ้มเอง เมื่อคุณต้องการประเภท BSON ตัวช่วย ISODate(...), ObjectId(...), NumberDecimal(...) และ NumberLong(...) จะถูกรองรับ; คู่มือ MongoDB อธิบายว่าแต่ละประเภทเหล่านี้จับคู่กับค่าที่เก็บไว้อย่างไร การเชื่อมต่อยอมรับได้ทั้ง connection string แบบเต็ม หรือส่วนประกอบโฮสต์และข้อมูลประจำตัวแต่ละรายการ

ข้อสังเกตอย่างตรงไปตรงมา: ขั้นตอนของ MySQL แสดงการดึงค่า JSONPath ไปยังตัวแปร แต่เอกสารของ MongoDB และ Redis ไม่ได้อธิบายกลไก Extract Result To Variable แบบเดียวกัน ดังนั้น ให้พึ่งพาการดำเนินการของ Mongo สำหรับการกำหนดข้อมูลเริ่มต้นและการยืนยันสถานะ และอย่าสันนิษฐานว่าเส้นทางการดึงค่าแบบ SQL จะทำงานเหมือนกันจนกว่าคุณจะได้ตรวจสอบแล้วใน Console

Redis

การเชื่อมต่อ Redis ต้องการ Host, Port, Password และ Database Index การดำเนินการแบบภาพจะใช้เมนูดรอปดาวน์ Operation Type ที่รองรับ GET, SET และ DELETE หากต้องการอ่านเซสชันที่แคชไว้ ให้เลือก GET และตั้งค่า Key เป็น `user:session:123` สำหรับสิ่งใดก็ตามที่เมนูดรอปดาวน์ไม่ครอบคลุม แท็บ Run Redis Command จะรันคำสั่งที่ถูกต้อง:

KEYS user:*

นั่นคือวิธีที่คุณยืนยันรายการแคชที่ API ควรจะเขียน หรือล้างรายการก่อนการทดสอบเพื่อพิสูจน์ว่า endpoint เติมข้อมูลใหม่

ความหลากหลายและข้อจำกัดขั้นสูง

สิ่งที่คุณควรรู้เล็กน้อยก่อนสร้างชุดการทดสอบขนาดใหญ่:

• การวนซ้ำ เมื่อคุณวนซ้ำแถวในขั้นตอน ForEach ให้อ้างอิงรายการวนซ้ำปัจจุบันด้วย {{$.StepID.element.field}} โดยที่ StepID คือหมายเลขจริงของขั้นตอนการวนซ้ำ มีประโยชน์สำหรับการยืนยันหนึ่งแถวต่อการวนซ้ำ
• การแยกสาขาตามค่า DB ดึงฟิลด์สถานะออกมา จากนั้นกำหนดเส้นทางส่วนที่เหลือของสถานการณ์ตามค่านั้น การจับคู่การอ่านฐานข้อมูลกับ ตรรกะเงื่อนไขในสถานการณ์การทดสอบ API ช่วยให้การทดสอบดำเนินไปในเส้นทางหนึ่งเมื่อแถวเป็น paid และอีกเส้นทางหนึ่งเมื่อเป็น pending
• การกำหนดเส้นทางสภาพแวดล้อม เพิ่มเติมเกี่ยวกับเรื่องนี้ด้านล่าง แต่สรุปสั้นๆ คือ: กำหนดการเชื่อมต่อหนึ่งรายการต่อสภาพแวดล้อม และ Apidog จะเลือกการเชื่อมต่อที่ถูกต้องโดยอัตโนมัติ
• Stored procedures อินเทอร์เฟซแบบกราฟิกไม่รองรับการดำเนินการที่ซับซ้อน เช่น stored procedures ให้เก็บ SQL ในขั้นตอนของคุณเป็นคำสั่งที่ตรงไปตรงมา
• การตั้งค่า Oracle Oracle ต้องการ Oracle Client ที่ติดตั้งแยกต่างหากบนเครื่องของคุณก่อนที่จะเชื่อมต่อได้เลย

จัดการข้อมูลประจำตัวสำหรับแต่ละสภาพแวดล้อม

คุณไม่ต้องการให้การทดสอบไปกระทบข้อมูลที่ใช้จริงโดยบังเอิญ คำตอบของ Apidog คือการเชื่อมต่อฐานข้อมูลหนึ่งรายการต่อสภาพแวดล้อม คุณสร้างการเชื่อมต่อ staging และการเชื่อมต่อ local โดยแต่ละรายการมีโฮสต์และรหัสผ่านของตนเอง

จากนั้นคุณเปลี่ยนสภาพแวดล้อมโดยใช้เมนูดรอปดาวน์ที่มุมขวาบน Apidog จะกำหนดเส้นทางการสืบค้นแต่ละรายการในสถานการณ์ไปยังการเชื่อมต่อที่ตรงกับสภาพแวดล้อมที่เลือกโดยอัตโนมัติ เลือก staging และคำสั่ง SELECT ของคุณจะทำงานกับ staging; เปลี่ยนไปที่ local และขั้นตอนเดียวกันจะทำงานกับฐานข้อมูลในแล็ปท็อปของคุณ โดยไม่ต้องแก้ไข SQL หรือขั้นตอนใดๆ ข้อมูลประจำตัวจะแตกต่างกันไปตามสภาพแวดล้อมโดยไม่ต้องมีการกำหนดค่าใหม่ด้วยตนเองระหว่างการรัน

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

ทำให้ขั้นตอนการทำงานเป็นอัตโนมัติด้วย Apidog CLI

เมื่อสถานการณ์ผ่านในแอปแล้ว ให้รันแบบ headlessly ใน CI เพื่อให้ทุก pull request ยืนยันฐานข้อมูลใหม่ ไม่ใช่แค่สัญญา HTTP ติดตั้ง CLI และตรวจสอบสิทธิ์:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

จากนั้นรันสถานการณ์ที่คุณสร้างขึ้น โดยใช้ ID ของมัน กับสภาพแวดล้อมที่เลือก:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

ในที่นี้ -t คือ ID สถานการณ์การทดสอบ, -e คือ ID สภาพแวดล้อม และ -r คือ reporter (cli, html หรือ junit; แยกด้วยคอมมาสำหรับหลายรายการ เช่น -r html,cli) สิ่งหนึ่งที่ต้องวางแผนคือ: รายละเอียดการเชื่อมต่อฐานข้อมูลเป็นแบบโลคอล ดังนั้น runner จึงต้องการการกำหนดค่าที่ส่งออกเพื่อเข้าถึงฐานข้อมูลของคุณจาก CI หากคุณป้อนข้อมูลแถวสถานการณ์จากชุดข้อมูล การ ทดสอบแบบขับเคลื่อนด้วยข้อมูลด้วย Apidog CLI จะแสดงให้เห็นว่าแต่ละแถวทำการยืนยันฐานข้อมูลเดียวกันอย่างไร และ การตั้งเวลาการทดสอบ API ด้วย Apidog ครอบคลุมการรันสิ่งนี้เป็นประจำ เพื่อให้การยืนยันฐานข้อมูลที่ล้มเหลวปรากฏขึ้นเหมือนการทดสอบอื่นๆ

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

ฐานข้อมูลใดบ้างที่ฟรีและฐานข้อมูลใดที่ต้องเสียเงิน? MySQL, SQL Server (2014 และใหม่กว่า), PostgreSQL และ Oracle อยู่ในแผนบริการฟรี ClickHouse, MongoDB และ Redis ต้องการแผนบริการแบบเสียเงิน เอกสารของ MongoDB และ Redis ทั้งสองระบุว่าการเชื่อมต่อเป็นคุณสมบัติแบบเสียเงิน ดังนั้นโปรดตรวจสอบหน้าข้อมูลราคา ก่อนวางแผนชุด NoSQL ดาวน์โหลด Apidog เพื่อลองใช้ฐานข้อมูลฟรีเป็นอันดับแรก

ฉันสามารถใช้ค่าจากฐานข้อมูลในการร้องขอภายหลังได้หรือไม่? ได้ เพิ่ม Post Processor ด้วย Database operation, รันคำสั่ง SELECT จากนั้นใช้ Extract Result To Variable พร้อมกับ Variable Name และ JSONPath Expression เช่น $[0].fulfillment_ref เพื่อแยกฟิลด์ออกจากแถวแรก อ้างอิงถึงมันในภายหลังด้วย {{variable_name}} แนวคิดการเชื่อมโยงเดียวกันสำหรับการตอบกลับ HTTP ครอบคลุมอยู่ใน การส่งข้อมูลระหว่างขั้นตอนการทดสอบ

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

การเชื่อมต่อ MySQL 8 ของฉันล้มเหลวอยู่เสมอ ทำไม? MySQL 8 ใช้ปลั๊กอินการตรวจสอบสิทธิ์ caching_sha2_password เป็นค่าเริ่มต้น ซึ่งอาจบล็อกการเชื่อมต่อได้ เปลี่ยนผู้ใช้เป็น mysql_native_password ด้วย ALTER USER ... IDENTIFIED WITH mysql_native_password แล้วเชื่อมต่อใหม่

ฉันสามารถรัน stored procedures หรือตรรกะฐานข้อมูลที่ซับซ้อนได้หรือไม่? ไม่ได้ผ่านอินเทอร์เฟซแบบกราฟิก มันรองรับคำสั่ง SELECT, INSERT, UPDATE และ DELETE มาตรฐาน แต่การดำเนินการที่ซับซ้อนเช่น stored procedures ไม่ได้รับการสนับสนุน จำกัดขั้นตอนการทดสอบของคุณให้เป็นคำสั่งโดยตรง

สรุป

การสืบค้นฐานข้อมูลเปลี่ยนการทดสอบ API จาก “การตอบกลับดูถูกต้อง” เป็น “ข้อมูลถูกต้องตามจริง” กำหนดสถานะที่ทราบใน Pre Processor ยืนยันแถวที่บันทึกไว้ถาวรใน Post Processor และดึงค่าที่เซิร์ฟเวอร์สร้างขึ้นเพื่อเชื่อมโยงกับคำขอถัดไป ทั้งหมดนี้อยู่ภายในสถานการณ์เดียว ตั้งค่าการเชื่อมต่อหนึ่งรายการต่อสภาพแวดล้อม และขั้นตอนเดียวกันนี้จะทำงานได้อย่างปลอดภัยกับ staging หรือ local โดยไม่ต้องแก้ไข

ลองใช้ฟรี ไม่ต้องใช้บัตรเครดิต: ดาวน์โหลด Apidog, ชี้การเชื่อมต่อ MySQL ไปยังฐานข้อมูล dev ของคุณ และเพิ่ม Post Processor หนึ่งตัวที่อ่านแถวที่คำขอถัดไปของคุณสร้างขึ้นกลับมา