วิธี ย้าย จาก ReadyAPI ไป Apidog

สรุปสั้นๆ (TL;DR)

การย้ายจาก ReadyAPI ไป Apidog นั้นค่อนข้างตรงไปตรงมาสำหรับชุดทดสอบที่เน้น REST เป็นหลัก. ส่งออกโปรเจกต์ ReadyAPI ของคุณ, แปลงสิ่งที่สามารถทำได้ผ่านการนำเข้า OpenAPI, และสร้างสคริปต์ Groovy ใหม่ด้วยตนเองใน JavaScript. กรณีทดสอบ SOAP ต้องการการทำงานด้วยมือมากที่สุด. วางแผนการย้ายแบบเป็นขั้นตอนเพื่อให้ครอบคลุมการทดสอบอย่างต่อเนื่อง.

บทนำ

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

คู่มือนี้จะนำคุณไปสู่กระบวนการย้ายข้อมูลทีละขั้นตอน. ครอบคลุมการส่งออกโปรเจกต์ ReadyAPI ของคุณ, การวิเคราะห์สิ่งที่คุณมี, การนำเข้าสู่ Apidog, การจัดการการแปลง Groovy เป็น JavaScript, การตั้งค่า CI/CD, และการจัดการช่วงการเปลี่ยนผ่านเมื่อเครื่องมือทั้งสองทำงานพร้อมกัน.

ขั้นตอนที่ 1: ตรวจสอบโปรเจกต์ ReadyAPI ของคุณก่อนเริ่มต้น

ก่อนที่จะส่งออกสิ่งใดๆ, ใช้เวลาทำความเข้าใจว่ามีอะไรอยู่ในโปรเจกต์ ReadyAPI ปัจจุบันของคุณบ้าง. การตรวจสอบนี้จะกำหนดระยะเวลาที่การย้ายข้อมูลจะใช้และส่วนที่คุณต้องมุ่งเน้นความพยายาม.

เปิดโปรเจกต์ ReadyAPI ของคุณและตอบคำถามเหล่านี้:

คุณมีชุดทดสอบ, กรณีทดสอบ, และขั้นตอนทดสอบกี่รายการ? เปิดแผง Navigator แล้วนับ. โปรเจกต์ที่มี 50 กรณีทดสอบจะใช้เวลาไม่กี่ชั่วโมงในการย้าย. โปรเจกต์ที่มี 500 กรณีจะใช้เวลาหลายวัน.

กรณีทดสอบ REST เทียบกับ SOAP มีสัดส่วนเท่าไร? กรณีทดสอบ REST จะย้ายได้สะอาดกว่ามาก. กรณีทดสอบ SOAP ต้องใช้การทำงานด้วยมือมากขึ้น โดยเฉพาะอย่างยิ่งหากใช้ WS-Security policies หรือการยืนยันที่ซับซ้อน.

มีสคริปต์ Groovy ในกรณีทดสอบของคุณมากน้อยแค่ไหน? คลิกดูผ่านกรณีทดสอบของคุณและมองหาขั้นตอน Script. นับว่ามีกรณีทดสอบกี่รายการที่มีตรรกะ Groovy ที่กำหนดเอง. สคริปต์ Groovy แต่ละรายการต้องได้รับการแปลงเป็น JavaScript ด้วยตนเอง.

คุณใช้การทดสอบที่ขับเคลื่อนด้วยข้อมูล (data-driven tests) กับขั้นตอน DataSource หรือไม่? Apidog รองรับการทดสอบที่ขับเคลื่อนด้วยข้อมูลด้วยไฟล์ CSV และ JSON แต่การตั้งค่าแตกต่างจากรูปแบบ DataSource/DataSink ของ ReadyAPI.

คุณใช้ขั้นตอน Properties หรือ Property Transfer เป็นจำนวนมากหรือไม่? รูปแบบเหล่านี้ทำงานแตกต่างกันใน Apidog. คุณจะใช้ตัวแปรและตัวแปรสภาพแวดล้อมแทน.

คุณกำลังรันการทดสอบโหลดผ่าน LoadUI Pro หรือไม่? การผสานรวม LoadUI Pro จะไม่ถูกนำมาใช้ใน Apidog. คุณจะต้องตั้งค่า k6 หรือเครื่องมือทดสอบโหลดอื่นๆ แยกต่างหากสำหรับสถานการณ์เหล่านั้น.

บันทึกสิ่งที่คุณพบ. สเปรดชีตที่มีชื่อกรณีทดสอบ, ประเภท (REST/SOAP), มี Groovy (ใช่/ไม่ใช่), และความซับซ้อน (ง่าย/ปานกลาง/ซับซ้อน) จะช่วยให้คุณประมาณการการย้ายข้อมูลได้ก่อนที่จะเริ่มต้น.

ขั้นตอนที่ 2: ส่งออกโปรเจกต์ ReadyAPI ของคุณ

ReadyAPI จัดเก็บโปรเจกต์เป็นไฟล์ XML. หากต้องการส่งออกโปรเจกต์เพื่อการวิเคราะห์:

1. เปิด ReadyAPI และเปิดโปรเจกต์ของคุณ.
2. ไปที่ File > Save As เพื่อบันทึกโปรเจกต์เป็นไฟล์ XML แบบสแตนด์อโลน.
3. บันทึกไฟล์ข้อมูลภายนอกใดๆ (CSV, Excel, XML test data) ที่การทดสอบของคุณอ้างอิง.
4. จดบันทึกการกำหนดค่าสภาพแวดล้อมที่คุณตั้งค่าไว้ในส่วน Environments.

ไฟล์ XML ของโปรเจกต์ประกอบด้วยชุดทดสอบ, กรณีทดสอบ, ขั้นตอนทดสอบ, สคริปต์, และการกำหนดค่าทั้งหมด. เป็นการแสดงผลที่สมบูรณ์ของโปรเจกต์ทดสอบของคุณ.

ขั้นตอนที่ 3: ดึงคำจำกัดความ API ของคุณออกมา

เส้นทางการย้ายข้อมูลที่สะอาดที่สุดสำหรับ REST API จะผ่านข้อกำหนด OpenAPI ไม่ใช่จากไฟล์ XML ของโปรเจกต์ ReadyAPI โดยตรง.

ตัวเลือก A: ส่งออกจาก ReadyAPI. หากคุณมีบริการ REST ใน ReadyAPI, คลิกขวาที่บริการนั้นใน Navigator และมองหาตัวเลือกการส่งออกหรือสร้างคำจำกัดความ API. ReadyAPI สามารถส่งออก Swagger/OpenAPI specs จากคำจำกัดความบริการได้.

ตัวเลือก B: ใช้ OpenAPI spec ของแบ็คเอนด์ของคุณ. หากบริการแบ็คเอนด์ของคุณมี OpenAPI spec อยู่แล้ว (ที่ /openapi.json หรือคล้ายกัน), ให้ดาวน์โหลดโดยตรง. ซึ่งจะให้คำจำกัดความที่ถูกต้องและเป็นปัจจุบันที่สุดแก่คุณ.

ตัวเลือก C: ดึงข้อมูลด้วยตนเอง. สำหรับ API ที่ไม่มี spec อยู่แล้ว, ให้ใช้คำขอ ReadyAPI REST ของคุณเป็นแหล่งที่มา. จดบันทึกปลายทาง, เนื้อหาคำขอ, ส่วนหัว, และโครงสร้างการตอบกลับ. คุณจะต้องสร้างสิ่งเหล่านี้ใหม่ใน Apidog.

ขั้นตอนที่ 4: นำเข้าสู่ Apidog

เมื่อ OpenAPI spec ของคุณพร้อมแล้ว, ให้นำเข้าสู่ Apidog.

1. เปิด Apidog และสร้างโปรเจกต์ใหม่.
2. ไปที่ APIs > Import และเลือกรูปแบบของคุณ (OpenAPI 3.0, Swagger 2.0, เป็นต้น).
3. อัปโหลดไฟล์ spec หรือวาง URL.
4. Apidog จะแยกวิเคราะห์ spec และสร้างคำจำกัดความ API สำหรับปลายทางทั้งหมด.

หลังจากนำเข้า, คุณจะมีคำจำกัดความ API ที่มีโครงสร้างพร้อมปลายทาง, พารามิเตอร์, เนื้อหาคำขอ, และสคีมาการตอบกลับทั้งหมดที่กรอกไว้. นี่คือรากฐานสำหรับกรณีทดสอบของคุณ.

หากคุณมีคอลเลกชัน Postman ที่มีอยู่ (อาจจะย้ายมาจากเครื่องมืออื่นก่อนหน้านี้), Apidog ก็สามารถนำเข้าสิ่งเหล่านั้นได้เช่นกันผ่าน File > Import > Postman.

ขั้นตอนที่ 5: สร้างกรณีทดสอบใหม่สำหรับปลายทาง REST

สำหรับกรณีทดสอบ REST, กระบวนการย้ายข้อมูลคือ:

1. เปิดกรณีทดสอบ ReadyAPI REST.
2. ระบุคำขอ, การยืนยัน, และแหล่งข้อมูลใดๆ ที่ใช้.
3. สร้างกรณีทดสอบที่สอดคล้องกันใน Apidog โดยการเลือกปลายทาง API และเพิ่มขั้นตอนทดสอบ.

การยืนยันแปลได้ดังนี้:

• การยืนยันแบบ Contains (body contains string) กลายเป็นการยืนยัน JavaScript: pm.test('contains value', () => { pm.expect(pm.response.text()).to.include('expected string'); });
• การยืนยันรหัสสถานะ: pm.test('status 200', () => { pm.response.to.have.status(200); });
• การยืนยัน JSONPath: pm.test('field value', () => { pm.expect(pm.response.json().fieldName).to.equal('expected'); });

สำหรับการทดสอบ GET และ POST ที่ตรงไปตรงมาโดยไม่มี Groovy, การย้ายข้อมูลนี้จะรวดเร็ว. กรณีทดสอบง่ายๆ ที่มีการยืนยัน 5 ถึง 10 รายการสามารถสร้างใหม่ได้ภายใน 15 ถึง 30 นาที.

ขั้นตอนที่ 6: แปลงสคริปต์ Groovy เป็น JavaScript

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

รูปแบบ Groovy ทั่วไปและ JavaScript ที่เทียบเท่า:

การอ่านค่าการตอบกลับ:

// Groovy (ReadyAPI)
def response = context.expand('${TestStep#Response}')
def json = new groovy.json.JsonSlurper().parseText(response)
def value = json.fieldName

// JavaScript (Apidog)
const response = pm.response.json();
const value = response.fieldName;

การตั้งค่าตัวแปร:

// Groovy
testRunner.testCase.setPropertyValue('myVariable', someValue)

// JavaScript
pm.variables.set('myVariable', someValue);

การยืนยันแบบมีเงื่อนไข:

// Groovy
if (statusCode == 200) {
  assert responseBody.contains("success")
}

// JavaScript
if (pm.response.code === 200) {
  pm.test('response contains success', () => {
    pm.expect(pm.response.text()).to.include('success');
  });
}

การจัดการวันที่:

// Groovy
def now = new Date()
def formatted = now.format('yyyy-MM-dd')

// JavaScript
const now = new Date();
const formatted = now.toISOString().split('T')[0];

สำหรับสคริปต์ Groovy ที่ซับซ้อนซึ่งมีการนำเข้าไลบรารี Java หรือตรรกะที่ซับซ้อน, การแปลงต้องใช้การวิเคราะห์อย่างระมัดระวัง. อ่านสคริปต์แต่ละรายการ, ทำความเข้าใจว่ากำลังทำอะไรอยู่, และเขียน JavaScript ที่เทียบเท่า. อย่าพยายามแปลโดยอัตโนมัติ — ความหมายใกล้เคียงกันพอที่จะหลอกคุณได้ แต่ก็แตกต่างกันมากพอที่จะทำให้เกิดข้อผิดพลาดที่ตรวจไม่พบ.

ขั้นตอนที่ 7: จัดการกรณีทดสอบ SOAP

กรณีทดสอบ SOAP เป็นส่วนที่ท้าทายที่สุดของการย้าย ReadyAPI. Apidog ไม่มีเครื่องมือเฉพาะสำหรับ SOAP ดังนั้นจึงต้องใช้วิธีการที่แตกต่างกัน.

สำหรับบริการ SOAP ที่มีอินเทอร์เฟซ REST ด้วย (ซึ่งพบเห็นได้บ่อยขึ้นเรื่อยๆ), ให้ย้ายการทดสอบไปใช้ปลายทาง REST และละทิ้งเลเยอร์ SOAP.

สำหรับบริการ SOAP ที่ไม่มีทางเลือก REST, คุณมีสองทางเลือก:

เก็บ ReadyAPI ไว้สำหรับ SOAP เท่านั้น. รัน ReadyAPI ควบคู่ไปกับกรณีทดสอบ SOAP และใช้ Apidog สำหรับ REST. นี่คือทางออกที่ใช้งานได้จริงซึ่งช่วยรักษาส่วนที่ครอบคลุมของ SOAP โดยไม่ขัดขวางการย้าย REST.

ใช้ SoapUI Open Source. SoapUI Open Source ฟรีและรองรับการทดสอบ SOAP. มันไม่สามารถแทนที่ฟังก์ชันทั้งหมดของ ReadyAPI ได้ แต่ครอบคลุมการทดสอบฟังก์ชัน SOAP พื้นฐานโดยไม่มีค่าใช้จ่ายใบอนุญาต.

อย่าเร่งรีบในการย้าย SOAP. กรณีทดสอบ WS-Security โดยเฉพาะอย่างยิ่งมีความเสี่ยงอย่างมากหากการยืนยันของพวกเขาไม่ถูกสร้างขึ้นใหม่อย่างรอบคอบ.

ขั้นตอนที่ 8: ตั้งค่าสภาพแวดล้อมและตัวแปร

คุณสมบัติ Environment ของ ReadyAPI สอดคล้องกับระบบ Environment ของ Apidog. สำหรับสภาพแวดล้อม ReadyAPI แต่ละรายการที่คุณกำหนดค่าไว้:

1. สร้างสภาพแวดล้อมที่ตรงกันใน Apidog (Settings > Environments).
2. เพิ่มตัวแปรเดียวกัน: base URLs, authentication tokens, shared headers, เป็นต้น.
3. ตรวจสอบว่ากรณีทดสอบอ้างอิงตัวแปรด้วยไวยากรณ์ Apidog ที่ถูกต้อง: {{variableName}} ในช่อง URL และเนื้อหาคำขอ.

ขั้นตอนที่ 9: กำหนดค่า CI/CD

การตั้งค่า CI ของ ReadyAPI โดยทั่วไปเกี่ยวข้องกับคำสั่ง testrunner บน build agents. Apidog ใช้วิธีการที่แตกต่างกัน.

ติดตั้ง Apidog CLI บน CI agent ของคุณ:

npm install -g apidog-cli

รันคอลเลกชันการทดสอบ:

apidog run "path/to/collection.json" -e "environment-id"

สำหรับ GitHub Actions, ขั้นตอนของเวิร์กโฟลว์อาจมีลักษณะดังนี้:

- name: Run API tests
  run: apidog run collection.json --environment staging

สำหรับ Jenkins, เพิ่มขั้นตอนเชลล์ลงในไปป์ไลน์ของคุณที่เรียกใช้ Apidog CLI. ไม่จำเป็นต้องติดตั้ง ReadyAPI บน build agent.

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

ขั้นตอนที่ 10: รันเครื่องมือทั้งสองพร้อมกันในช่วงการเปลี่ยนผ่าน

อย่าเปลี่ยนจาก ReadyAPI ไป Apidog ในวันเดียว. รันเครื่องมือทั้งสองพร้อมกันอย่างน้อยหนึ่งรอบการเผยแพร่ (release cycle).

ในช่วงเวลาที่ทำงานพร้อมกัน:

• รันการทดสอบ ReadyAPI ใน CI ในฐานะที่เป็นประตูทดสอบหลัก.
• รันการทดสอบ Apidog ควบคู่ไปและเปรียบเทียบผลลัพธ์.
• ตรวจสอบข้อผิดพลาดใดๆ ใน Apidog ที่ไม่ปรากฏใน ReadyAPI.
• ค่อยๆ เพิ่มกรณีทดสอบใหม่เฉพาะใน Apidog.

เมื่อคุณมั่นใจว่า Apidog สามารถตรวจจับข้อผิดพลาดเดียวกันกับ ReadyAPI ได้, ให้ลบ ReadyAPI ออกจากไปป์ไลน์ CI. เก็บการติดตั้ง ReadyAPI ไว้ใช้งานได้อีกสองสามเดือนเพื่อเป็นทางเลือกสำรอง.

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

การย้ายจาก ReadyAPI ไป Apidog โดยทั่วไปใช้เวลานานเท่าใด?โปรเจกต์ที่เน้น REST เท่านั้นและมีการเขียนสคริปต์ Groovy น้อยที่สุดสามารถย้ายได้ภายในหนึ่งถึงสามวัน. โปรเจกต์ขนาดใหญ่ที่มีสคริปต์ Groovy จำนวนมาก, กรณีทดสอบ SOAP, และโครงสร้างการทดสอบที่ซับซ้อนอาจใช้เวลาสองถึงหกสัปดาห์. การตรวจสอบในขั้นตอนที่ 1 จะให้การประมาณการที่ชัดเจนที่สุดก่อนที่คุณจะดำเนินการ.

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

ฉันสามารถรัน ReadyAPI และ Apidog ใน CI pipeline เดียวกันระหว่างการย้ายได้หรือไม่?ได้, และนี่คือแนวทางที่แนะนำ. เพิ่มขั้นตอน Apidog CLI ลงในไปป์ไลน์ที่มีอยู่ของคุณควบคู่ไปกับขั้นตอน ReadyAPI testrunner. เปรียบเทียบผลลัพธ์ทีละการรันในช่วงระยะเวลาการเปลี่ยนผ่าน.

ฉันต้องสร้างสภาพแวดล้อมใหม่ด้วยตนเอง หรือมีวิธีอัตโนมัติหรือไม่?การกำหนดค่าสภาพแวดล้อมจะต้องสร้างใหม่ด้วยตนเองใน Apidog. ไม่มีการนำเข้าการตั้งค่าสภาพแวดล้อม ReadyAPI โดยอัตโนมัติ. เปิดสภาพแวดล้อม ReadyAPI ของคุณในหน้าต่างหนึ่งในขณะที่สร้างใหม่ใน Apidog.

จะเกิดอะไรขึ้นกับ ReadyAPI tests ที่ไม่มี REST ที่เทียบเท่า?สำหรับกรณีทดสอบเฉพาะ SOAP ที่ไม่มีทางเลือก REST, ตัวเลือกที่ใช้งานได้จริงคือการดูแล ReadyAPI (อาจใช้ใบอนุญาตน้อยลง) สำหรับการทดสอบเฉพาะเหล่านั้น, การย้ายไปที่ SoapUI Open Source, หรือการยอมรับช่องว่างในการทดสอบหากบริการเหล่านั้นเป็นแบบเก่าและมีความเสี่ยงต่ำ.

Apidog รองรับประเภทการยืนยันแบบเดียวกับ ReadyAPI หรือไม่?Apidog รองรับการยืนยัน JavaScript ที่สามารถแสดงเงื่อนไขตรรกะเดียวกันกับประเภทการยืนยันในตัวของ ReadyAPI ได้. ไวยากรณ์แตกต่างกันแต่ความสามารถเทียบเท่ากันสำหรับการทดสอบ REST. ประเภทการยืนยันเฉพาะ ReadyAPI บางประเภท (SOAP Fault, WS-Security) ไม่มีใน Apidog.

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