บทแนะนำการทดสอบ REST API: ตัวอย่างกรณีทดสอบด้วยตนเอง
ทีมบรรณาธิการ
⚡ สรุปอย่างชาญฉลาด
การทดสอบ REST API ตรวจสอบความถูกต้องของเว็บเซอร์วิส RESTful โดยการส่งคำขอ HTTP เช่น GET, POST, PUT และ DELETE จากนั้นตรวจสอบรหัสสถานะ ส่วนหัวการตอบกลับ และข้อมูลที่ส่งกลับมาจากเซิร์ฟเวอร์
การทดสอบ REST API คืออะไร
การทดสอบ REST API REST API เป็นเทคนิคการทดสอบอัตโนมัติบนเว็บแบบโอเพนซอร์สที่ใช้สำหรับการทดสอบ RESTful API สำหรับเว็บแอปพลิเคชัน จุดประสงค์ของการทดสอบ REST API คือการบันทึกการตอบสนองของ REST API โดยการส่งคำขอ HTTP/S ต่างๆ เพื่อตรวจสอบว่า REST API ทำงานได้ดีหรือไม่ การทดสอบ REST API ทำได้โดยใช้วิธี GET, POST, PUT และ DELETE
REST ย่อมาจาก Representational State Transfer เป็นรูปแบบสถาปัตยกรรมและแนวทางการสื่อสารที่ใช้ในการพัฒนา บริการเว็บREST กลายเป็นตัวเลือกที่เหมาะสมสำหรับการสร้าง API เนื่องจากช่วยให้ผู้ใช้สามารถเชื่อมต่อและโต้ตอบกับบริการคลาวด์ได้อย่างมีประสิทธิภาพ
API หรือ Application Programming Interface คือชุดคำสั่งการเขียนโปรแกรมสำหรับการเข้าถึงแอปพลิเคชันซอฟต์แวร์บนเว็บ กล่าวอีกนัยหนึ่งคือ เป็นชุดคำสั่งที่โปรแกรมหนึ่งใช้ในการสื่อสารโดยตรงกับอีกโปรแกรมหนึ่ง และใช้ฟังก์ชันของกันและกันเพื่อรับข้อมูล
ตัวอย่างเช่น Google เว็บไซต์สามารถมี API สำหรับการค้นหา การแปล และปฏิทินได้ โดยทั่วไปแล้ว API จะมีลักษณะดังตัวอย่างด้านล่าง ซึ่งประกอบด้วยชื่อเซิร์ฟเวอร์ เส้นทาง และพารามิเตอร์
http://<server name>/v1/export/Publisher/Standard_Publisher_Report?format=csv
แต่ทำไมต้องลงทุนเวลาในการทดสอบที่ชั้นนี้ด้วย?
เหตุใดการทดสอบ REST API จึงมีความสำคัญ
REST API อยู่ระหว่างส่วนติดต่อผู้ใช้และฐานข้อมูล ทำให้เป็นชั้นที่ตรรกะทางธุรกิจส่วนใหญ่อยู่จริง ๆ ความผิดพลาดในกฎการกำหนดราคาหรือการตรวจสอบสิทธิ์จะปรากฏในผลตอบรับของ API ก่อนที่ใครจะสังเกตเห็นตัวเลขที่ไม่ถูกต้องบนหน้าจอ ดังนั้นการทดสอบในส่วนนี้จึงช่วยตรวจจับปัญหาได้เร็วขึ้นและใกล้กับสาเหตุของปัญหามากขึ้น
ความเร็วเป็นเหตุผลข้อที่สอง การร้องขอเสร็จสมบูรณ์ในเวลาเพียงไม่กี่มิลลิวินาที และไม่จำเป็นต้องใช้เบราว์เซอร์ ไม่จำเป็นต้องใช้เอนจิ้นการแสดงผล และไม่จำเป็นต้องใช้ตัวระบุองค์ประกอบที่เปราะบาง ผู้ทดสอบสามารถทดสอบเอนด์พอยต์ได้หลายสิบรายการในเวลาที่ใช้ในการโหลดหน้าเว็บเพียงหน้าเดียว และการร้องขอแบบเดียวกันนี้ทำงานเหมือนกันไม่ว่าส่วนหน้าจะเป็นเว็บไซต์ แอปพลิเคชันบนมือถือ หรือการผสานรวมกับพันธมิตรก็ตาม
ความเสถียรเป็นเหตุผลที่สาม รูปแบบโครงสร้างเปลี่ยนแปลงอยู่ตลอดเวลา แต่ REST คอนเทนต์ที่เผยแพร่แล้วนั้นยังคงเสถียรอยู่tracคาดว่าค่า t จะคงที่ การทดสอบที่เขียนขึ้นโดยอิงจากค่า t นั้นtracเพื่อให้คงอยู่ได้แม้จะมีการออกแบบใหม่ พวกเขาจึงปกป้องส่วนต่างๆ ของผลิตภัณฑ์ที่ทีมอื่นๆ นำไปพัฒนาต่อยอด
ประเภทของวิธีการ API
ส่วนใหญ่มี 4 ประเภท การทดสอบ API วิธีการ: GET, POST, DELETE และ PUT
- GET– เมธอด GET ใช้สำหรับส่งออกข้อมูลtracดึงข้อมูลจากเซิร์ฟเวอร์ที่กำหนดโดยใช้ URI ที่กำหนด ขณะใช้คำขอ GET ควรดึงข้อมูลเฉพาะจากเซิร์ฟเวอร์ที่กำหนดเท่านั้นtracข้อมูล t และไม่ควรมีผลกระทบอื่นใดต่อข้อมูล
- POST– คำขอ POST ใช้เพื่อสร้างเอนทิตีใหม่ นอกจากนี้ยังสามารถใช้เพื่อส่งข้อมูลไปยังเซิร์ฟเวอร์ เช่น ข้อมูลลูกค้า การอัพโหลดไฟล์ ฯลฯ โดยใช้แบบฟอร์ม HTML
- PUT– สร้างเอนทิตีใหม่หรืออัปเดตเอนทิตีที่มีอยู่
- ลบ– ลบการนำเสนอทรัพยากรเป้าหมายที่กำหนดโดย URI ในปัจจุบันทั้งหมด
วิธีทดสอบ REST API
การทดสอบ REST API จำเป็นต้องมีแอปพลิเคชันที่โต้ตอบกับ API ตัวอย่างสำหรับการทดสอบ ในการทดสอบ API คุณต้องมีสองสิ่งต่อไปนี้:
- เครื่องมือทดสอบ/เฟรมเวิร์กเพื่อขับเคลื่อน API
- การเขียนโค้ดของคุณเองเพื่อทดสอบ REST API ตัวอย่าง
สามารถทดสอบกรณีทดสอบ REST API ได้ด้วยเครื่องมือต่างๆ เช่น:
- ไคลเอนต์ส่วนที่เหลือขั้นสูง
- Postman-ลูกค้าส่วนที่เหลือ
- ขดใน Linux
ในที่นี้เราจะใช้ Advanced Rest Client ขั้นตอนการติดตั้ง Advanced Rest Client มีดังต่อไปนี้
วิธีติดตั้ง Advanced Rest Client?
- ไปที่ Google Chromeเว็บสโตร์ของ
- ค้นหา “Advanced Rest Client” หรือไปโดยตรง Good Farm Animal Welfare Awards และติดตั้งส่วนขยาย
- เลือกไอคอน “Advanced Rest Client” ใต้ส่วนแอปของ Chrome – chrome://apps/
รายการสินค้าในร้านค้าออนไลน์จะปรากฏดังที่แสดงด้านล่าง
เมื่อการติดตั้งเสร็จสิ้นแล้ว ให้ทำตามขั้นตอนการทดสอบด้านล่างเพื่อทดสอบระบบ RESTful API.
ขั้นตอนในการทดสอบ REST API
ในที่นี้เราจะใช้ส่วนขยายไคลเอ็นต์ REST ในเบราว์เซอร์ Chrome เพื่อให้เข้าใจได้ชัดเจนยิ่งขึ้น เราจะใช้ API จำลองสำหรับการทดสอบ:
http://ip.jsontest.com/
ขั้นตอนที่ 1) เปิดไคลเอ็นต์ REST ขั้นสูง
เปิดแอป ไคลเอนต์ REST ขั้นสูง (ARC) เมื่อติดตั้งสำเร็จแล้ว
ขั้นตอนที่ 2) ป้อนข้อมูล URL ของ API สำหรับทดสอบ
ป้อนตัวอย่าง REST API URL สำหรับการทดสอบใน URL กล่องข้อความ
ขั้นตอนที่ 3) เลือกวิธี HTTP
เลือกวิธีการสำหรับประเภทของวิธี HTTP ในการทดสอบ API เพื่อกดปุ่ม POST
ขั้นตอนที่ 4) จัดเตรียมชุดส่วนหัว
ใส่ชุดส่วนหัวในกล่องข้อความส่วนหัว คลิกแทรกชุดส่วนหัว
ขั้นตอนที่ 5) ยืนยันการตั้งค่าส่วนหัว
ถัดไปคลิกใช้ชุดนี้
ขั้นตอนที่ 6) จัดเตรียมเนื้อหาในร่างกายที่จำเป็น
- ตอนนี้เปลี่ยนเป็นแท็บเนื้อหา
- ตั้งค่าประเภทเนื้อหาเนื้อหาและมุมมองตัวแก้ไขที่ต้องการ เช่น ประเภทเนื้อหาเนื้อหา : application/json
- มุมมองตัวแก้ไข: อินพุตดิบ
- ในส่วน Payload ให้ส่งข้อมูลคำขอของ API สาธิตสำหรับการทดสอบในรูปแบบคู่คีย์-ค่า เช่น {"key1":"value1","key2":"value2"} หากเป็น API แบบ POST เราจำเป็นต้องส่งข้อมูลหรือพารามิเตอร์ โดยจะส่งผ่านในส่วน Payload ที่กำหนดไว้
{"property" : ["Sites"], "report_type" : ["ALL"]}
⚠️คำเตือน: Content-Type เป็น application/json แต่มี payload ที่ไม่ถูกต้อง JSON แสดงผลลัพธ์ 400 Bad Request
ขั้นตอนที่ 7) ส่งรายละเอียดเพื่อเริ่มการทดสอบ
- กดปุ่มส่ง
- คุณสามารถคลิกปุ่มรายละเอียดเพื่อดูหัวข้อการตอบกลับ
รายละเอียดการตอบกลับมีดังนี้:
การตอบสนองยังคงต้องได้รับการประเมินโดยพิจารณาจากผลลัพธ์ที่คาดหวังไว้
การตรวจสอบผลลัพธ์
โดยหลักแล้ว สำหรับการทดสอบ Web API เราจำเป็นต้องตรวจสอบรหัสการตอบกลับ ข้อความการตอบกลับ และเนื้อหาการตอบกลับ
รหัสการตอบสนองแบ่งออกเป็นห้าประเภทหลัก:
| ครอบครัว | Category | ความหมาย |
|---|---|---|
| 1xx | เกี่ยวกับข้อมูล | ได้รับแล้ว กำลังดำเนินการ |
| 2xx | ความสำเร็จ | เสร็จสมบูรณ์; 200 ตกลง, 201 สร้างเสร็จแล้ว |
| 3xx | การเปลี่ยนเส้นทาง | จำเป็นต้องดำเนินการเพิ่มเติม |
| 4xx | ข้อผิดพลาดของลูกค้า | เพย์โหลด โทเค็น หรือทรัพยากรไม่ถูกต้อง |
| 5xx | ข้อผิดพลาดของเซิร์ฟเวอร์ | คำขอถูกต้อง แต่เซิร์ฟเวอร์ล้มเหลว |
ด้านล่างนี้คือรหัสการตอบสนองที่คุณอาจพบเจอ
การร้องขอเพียงครั้งเดียวพิสูจน์ได้ว่าปลายทางทำงานได้ การทดสอบแบบครบชุดพิสูจน์ได้ว่ามันทำงานได้อย่างต่อเนื่อง
กรณีทดสอบ REST API ที่คุณต้องครอบคลุม
ชุด REST API ที่มีประโยชน์นั้นครอบคลุมหลายหมวดหมู่ แทนที่จะเรียกใช้ฟังก์ชันเดิมซ้ำๆ ด้วยข้อมูลที่แตกต่างกัน:
- เส้นทางแห่งความสุข: ส่งคำขอที่ถูกต้องไปยังปลายทางแต่ละแห่ง และยืนยันรหัสสถานะ โครงสร้างข้อมูล และค่าของทุกฟิลด์
- ผลตรวจเป็นลบ: หากส่งข้อมูล JSON ที่ผิดรูปแบบ ใช้เมธอดที่ไม่รองรับ และขาดรหัสทรัพยากร จะได้รับรหัสข้อผิดพลาด 400, 405 และ 404 แทนที่จะเป็น 500
- ค่าขอบเขต: หากช่องข้อมูลยอมรับอักขระได้ตั้งแต่ 1 ถึง 200 ตัว ให้ทดสอบที่ 0, 1, 200 และ 201 กฎการตรวจสอบความถูกต้องจะใช้ไม่ได้ผลเมื่อถึงขอบเขตของค่าที่กำหนด
- อักขระพิเศษ: ส่งตัวอักษรที่มีเครื่องหมายเน้นเสียง อีโมจิ เครื่องหมายคำพูด และข้อความหลายไบต์ผ่านทุกช่องเพื่อตรวจสอบข้อผิดพลาดในการเข้ารหัส
- กับtract ตรวจสอบ: เปรียบเทียบผลลัพธ์กับข้อกำหนด OpenAPI หรือ Swagger ที่เผยแพร่ไว้ เพื่อตรวจจับการเปลี่ยนแปลงที่ไม่ได้รับการบันทึกไว้ตั้งแต่เนิ่นๆ
- ลำดับ: เรียกใช้เอนด์พอยต์ตามลำดับที่สมเหตุสมผล เช่น POST จากนั้น GET จากนั้น DELETE เนื่องจากสถานะจะถูกส่งต่อระหว่างการเรียกใช้แต่ละครั้ง
- ความสมเหตุสมผลในการปฏิบัติงาน: บันทึกเวลาตอบสนองในทุกการทดสอบ และแจ้งเตือนหากจุดสิ้นสุดใดๆ มีค่าเกินกว่าเกณฑ์ที่ตกลงไว้กับทีม
เครื่องมือทดสอบ REST API
เครื่องมือแต่ละชนิดเหมาะสมกับขั้นตอนการทดสอบที่แตกต่างกัน
| เครื่องมือ | ประเภท | เหมาะสำหรับ |
|---|---|---|
| ไคลเอนต์ส่วนที่เหลือขั้นสูง | ไคลเอนต์เดสก์ท็อป | โทรออกด้วยตนเองอย่างรวดเร็ว |
| Postman | ไคลเอนต์เดสก์ท็อป | พื้นที่สำหรับรวบรวมเอกสารและพื้นที่ทำงานของทีม |
| JMeter | โหลดการทดสอบ | เวลาตอบสนองภายใต้ภาระงาน |
| SoapUI | การทดสอบการทำงาน | พักผ่อนและล้างมือด้วยกัน |
| มั่นใจได้ | Java ห้องสมุด | การทำให้กรณีที่มีเสถียรภาพเป็นไปโดยอัตโนมัติ |
| cURL | บรรทัดคำสั่ง | การคัดลอกข้อความเรียกใช้ลงในรายงานข้อผิดพลาด |
ดูสรุปโดยรวมของ เครื่องมือทดสอบ API.
โดยทั่วไปแล้ว ปลายทางจริงส่วนใหญ่จะปฏิเสธการตอบกลับจนกว่าคำขอจะพิสูจน์ได้ว่าใครเป็นผู้ส่ง
การตรวจสอบสิทธิ์และความปลอดภัยของ REST API
เอนด์พอยต์สาธิตสาธารณะสามารถตอบคำถามของทุกคนได้ แต่ REST API ที่ใช้งานจริงนั้นอยู่เบื้องหลังระบบการตรวจสอบสิทธิ์ และข้อผิดพลาดด้านการอนุญาตนั้นสร้างความเสียหายมากกว่าค่าฟิลด์ที่ไม่ถูกต้องมาก ขั้นแรกให้ระบุกลไกที่ใช้: คีย์ API แบบคงที่, ข้อมูลรับรอง HTTP Basic, โทเค็น Bearer ของ OAuth 2.0 หรือโทเค็นเว็บ JSON ที่ลงนามแล้ว
เมื่อการร้องขอที่ได้รับการตรวจสอบสิทธิ์สำเร็จแล้ว ให้ดำเนินการวิเคราะห์เส้นทางความล้มเหลวอย่างรอบคอบ:
- ไม่มีข้อมูลประจำตัว: ลบส่วนหัว Authorization ออก คาดว่าจะได้รับข้อความ 401 Unauthorized และไม่มีข้อมูลบันทึกในส่วนเนื้อหา
- ข้อมูลประจำตัวไม่ถูกต้อง: หากตัวอักษรตัวใดตัวหนึ่งในโทเค็นเสียหาย จะแสดงข้อผิดพลาด 401 อีกครั้ง พร้อมข้อความที่ไม่อธิบายสาเหตุ
- ข้อมูลประจำตัวหมดอายุ: นำโทเค็นกลับมาใช้ซ้ำหลังจากหมดอายุแล้ว ตรวจสอบว่าถูกปฏิเสธแทนที่จะได้รับการยอมรับ ซึ่งเป็นข้อผิดพลาดทั่วไปที่เกิดจากความคลาดเคลื่อนของเวลา
- ระดับสิทธิ์ไม่ถูกต้อง: ยืนยันตัวตนในฐานะผู้ใช้ที่มีสิทธิ์ต่ำและเรียกใช้ปลายทางที่เข้าถึงได้เฉพาะผู้ดูแลระบบเท่านั้น คาดว่าจะได้รับข้อความ 403 Forbidden ไม่ใช่ 200
- บันทึกของผู้ใช้รายอื่น: เปลี่ยน ID เพื่อให้ผู้ใช้ A ร้องขอข้อมูลของผู้ใช้ B หากทำสำเร็จ แสดงว่าระบบควบคุมการเข้าถึงมีข้อบกพร่องร้ายแรง
สุดท้าย ตรวจสอบให้แน่ใจว่าการเรียกใช้งานทุกครั้งใช้โปรโตคอล HTTPS และการตอบสนองที่ล้มเหลวจะไม่แสดงข้อมูลสแต็กใดๆ tracแบนเนอร์เวอร์ชันหรือเวอร์ชันต่างๆ และการแสดงซ้ำอย่างรวดเร็วจะทำให้เกิดข้อผิดพลาด 429 Too Many Requests
การทดสอบ REST API ยังมีปัญหาที่การทดสอบอินเทอร์เฟซไม่มีอีกด้วย
ความท้าทายสำหรับการทดสอบ API
ปัญหาที่น่าสนใจสำหรับผู้ทดสอบในระหว่างการทดสอบ REST API ได้แก่:
- เพื่อให้แน่ใจว่าชุดทดสอบจะปรับเปลี่ยนพารามิเตอร์ของการเรียกใช้ API ในลักษณะที่ตรวจสอบการทำงานได้ครบถ้วนและแสดงให้เห็นถึงข้อผิดพลาด ซึ่งรวมถึงการสำรวจเงื่อนไขขอบเขตและการกำหนดพารามิเตอร์ทั่วไป
- การสร้างชุดค่าพารามิเตอร์ที่น่าสนใจสำหรับการโทรที่มีพารามิเตอร์ตั้งแต่สองตัวขึ้นไป
- การระบุเนื้อหาที่ต้องใช้ในการเรียกใช้ API ซึ่งอาจรวมถึงการตั้งค่าเงื่อนไขสภาพแวดล้อมภายนอก (อุปกรณ์ต่อพ่วง ไฟล์ ฯลฯ) ตลอดจนข้อมูลที่จัดเก็บภายในซึ่งส่งผลต่อ API
- ลำดับการเรียก API ตามลำดับที่ฟังก์ชันจะถูกดำเนินการ
- เพื่อให้ API สร้างผลลัพธ์ที่เป็นประโยชน์จากการโทรต่อเนื่อง
