การทดสอบอินเทอร์เฟซคืออะไร? ประเภทและตัวอย่าง
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
การทดสอบอินเทอร์เฟซจะตรวจสอบว่าระบบซอฟต์แวร์สองระบบที่เชื่อมต่อกันนั้นแลกเปลี่ยนข้อมูลได้อย่างถูกต้อง ครอบคลุมถึงการเชื่อมต่อระหว่างเว็บเซิร์ฟเวอร์ แอปพลิเคชันเซิร์ฟเวอร์ และฐานข้อมูลเซิร์ฟเวอร์ ซึ่งเป็นส่วนที่ส่งผ่านคำขอทุกคำขอของแอปพลิเคชัน รวมถึงการจัดการข้อผิดพลาดที่เกี่ยวข้องด้วย
การทดสอบอินเทอร์เฟซคืออะไร?
การทดสอบอินเทอร์เฟซ หมายถึง การทดสอบซอฟต์แวร์ประเภทหนึ่งที่ตรวจสอบว่าการสื่อสารระหว่างระบบซอฟต์แวร์สองระบบที่แตกต่างกันนั้นดำเนินการอย่างถูกต้องหรือไม่
อินเทอร์เฟซคือการเชื่อมต่อที่ผสานรวมส่วนประกอบสองส่วนเข้าด้วยกัน ในโลกของคอมพิวเตอร์ อินเทอร์เฟซนี้อาจเป็นอะไรก็ได้ เช่น API, เว็บเซอร์วิส เป็นต้น การทดสอบบริการหรืออินเทอร์เฟซที่เชื่อมต่อเหล่านี้เรียกว่า การทดสอบอินเทอร์เฟซ
จริงๆ แล้วอินเทอร์เฟซคือซอฟต์แวร์ที่ประกอบด้วยชุดคำสั่ง ข้อความ และคุณลักษณะอื่นๆ ที่ช่วยให้สามารถสื่อสารระหว่างอุปกรณ์และผู้ใช้ได้
ประเด็นสำคัญคืออินเทอร์เฟซนั้นมีข้อจำกัดtract: รูปแบบคำขอที่ตกลงกันไว้ รูปแบบการตอบกลับที่ตกลงกันไว้ ชุดรหัสข้อผิดพลาดที่ตกลงกันไว้ และระยะเวลาหมดเวลาที่ตกลงกันไว้ แบบฝึกหัดการทดสอบอินเทอร์เฟซที่ประกอบด้วยtracเนื่องจากข้อมูลส่วนใหญ่มาจากทั้งสองฝ่าย การเปลี่ยนแปลงที่ทีมหนึ่งทำจึงไม่ส่งผลกระทบต่ออีกทีมโดยที่เราไม่รู้ตัว เพราะข้อมูลเหล่านี้ไม่เคยปรากฏบนหน้าจอ ทำให้ข้อบกพร่องที่พบนั้นมองไม่เห็น การทดสอบกล่องดำ ดำเนินการผ่านทางอินเทอร์เฟซผู้ใช้เพียงอย่างเดียว
วิธีการทดสอบอินเทอร์เฟซ
การทดสอบอินเทอร์เฟซประกอบด้วยการทดสอบสองส่วนหลัก:
- เว็บเซิร์ฟเวอร์และอินเทอร์เฟซเซิร์ฟเวอร์แอปพลิเคชัน
- แอปพลิเคชันเซิร์ฟเวอร์และอินเทอร์เฟซเซิร์ฟเวอร์ฐานข้อมูล
สำหรับสถานการณ์ที่กล่าวข้างต้น การทดสอบอินเทอร์เฟซเสร็จสิ้นแล้ว
- ตรวจสอบเซิร์ฟเวอร์ดำเนินการอย่างถูกต้องหรือไม่
- ข้อผิดพลาดได้รับการจัดการอย่างถูกต้องหรือส่งคืนข้อความแสดงข้อผิดพลาดสำหรับการสืบค้นใด ๆ ที่ทำโดยแอปพลิเคชัน
- ตรวจสอบผลลัพธ์เมื่อการเชื่อมต่อกับเว็บเซิร์ฟเวอร์ถูกรีเซ็ตในระหว่างนั้น
แผนภาพด้านล่างแสดงให้เห็นส่วนประกอบทั้งสองส่วนนั้นเป็นห่วงโซ่เดียวกัน โดยเบราว์เซอร์สื่อสารกับเว็บเซิร์ฟเวอร์ เว็บเซิร์ฟเวอร์สื่อสารกับแอปพลิเคชันเซิร์ฟเวอร์ และแอปพลิเคชันเซิร์ฟเวอร์สื่อสารกับฐานข้อมูลเซิร์ฟเวอร์
ในทางปฏิบัติ ผู้ทดสอบจะทำงานผ่านห่วงโซ่นั้นทีละขั้นตอน โดยแต่ละขั้นตอนจะเริ่มต้นด้วยคำขอที่ถูกต้องก่อน จากนั้นจึงเริ่มต้นด้วยคำขอที่ผิดพลาด และสุดท้ายคือปลายทางปลายทางถูกทำให้ไม่สามารถใช้งานได้โดยเจตนา เพื่อให้ทั้งเส้นทางที่สำเร็จและเส้นทางที่ล้มเหลวถูกบันทึกไว้ในระบบเดียวกัน กรณีทดสอบ.
ตัวอย่างการทดสอบอินเทอร์เฟซ
สมมติว่าสำหรับแอปพลิเคชัน xyz ใดๆ อินเทอร์เฟซจะรับค่าดังนี้ XML รับไฟล์เป็นอินพุตและส่งออก JSON ไฟล์เป็นผลลัพธ์ ในการทดสอบอินเทอร์เฟซของแอปพลิเคชันนี้ สิ่งที่จำเป็นคือข้อกำหนดของรูปแบบไฟล์ XML และรูปแบบไฟล์ JSON
ด้วยความช่วยเหลือจากข้อกำหนดเหล่านี้ เราสามารถสร้างไฟล์ XML ตัวอย่างสำหรับป้อนข้อมูลและป้อนเข้าสู่อินเทอร์เฟซได้ จากนั้นการตรวจสอบความถูกต้องของไฟล์ป้อนข้อมูล (XML) และไฟล์ส่งออก (JSON) ตามข้อกำหนดก็คือการทดสอบอินเทอร์เฟซ
สังเกตสิ่งที่ตัวอย่างไม่จำเป็นต้องมี: หน้าจอ การสร้างส่วนหน้า และความรู้เกี่ยวกับโค้ดภายในอินเทอร์เฟซ ข้อกำหนดรูปแบบสองข้อก็เพียงพอสำหรับการเขียนการทดสอบ ซึ่งเป็นเหตุผลว่าทำไมการทดสอบอินเทอร์เฟซจึงสามารถเริ่มต้นได้นานก่อนที่อินเทอร์เฟซผู้ใช้จะเกิดขึ้น
ทำไมต้องทำการทดสอบอินเทอร์เฟซ
การทดสอบอินเทอร์เฟซเสร็จสิ้น
- เพื่อให้แน่ใจว่าผู้ใช้หรือลูกค้าไม่ควรประสบปัญหาใด ๆ เมื่อใช้ผลิตภัณฑ์ซอฟต์แวร์เฉพาะ
- เพื่อระบุว่าผู้ใช้ปลายทางมักเข้าถึงพื้นที่แอปพลิเคชันใด และเพื่อตรวจสอบความเป็นมิตรต่อผู้ใช้ด้วย
- เพื่อตรวจสอบข้อกำหนดด้านความปลอดภัยในขณะที่การสื่อสารแพร่กระจายระหว่างระบบ
- เพื่อตรวจสอบว่าโซลูชันสามารถจัดการกับความล้มเหลวของเครือข่ายระหว่างแอปพลิเคชันเซิร์ฟเวอร์และเว็บไซต์ได้หรือไม่
นอกจากนี้ยังมีประเด็นเรื่องต้นทุนด้วย การแก้ไขข้อบกพร่องในรูปแบบคำขอจะทำได้ง่ายและรวดเร็วในขณะที่ระบบทั้งสองกำลังเชื่อมต่อกัน แต่จะเสียค่าใช้จ่ายสูงเมื่อระบบปลายทางได้จัดเก็บข้อมูลที่ผิดรูปแบบไปแล้ว
ประเภทของการทดสอบอินเทอร์เฟซ
ในระหว่างการทดสอบอินเทอร์เฟซ การทดสอบประเภทต่างๆ ที่ทำบนอินเทอร์เฟซซึ่งอาจรวมถึง
- ขั้นตอนการทำงาน: ช่วยให้มั่นใจได้ว่าเอ็นจิ้นอินเทอร์เฟซจะจัดการเวิร์กโฟลว์มาตรฐานของคุณตามที่คาดไว้
- กรณีพิเศษ - ค่าที่ไม่คาดคิด: จะต้องพิจารณาประเด็นนี้เมื่อทำการทดสอบโดยสลับวันที่ เดือน และวัน
- การทดสอบประสิทธิภาพ การรับโหลด และเครือข่าย: อินเทอร์เฟซที่มีปริมาณการใช้งานสูงอาจต้องการมากกว่านั้น โหลดการทดสอบ กว่าอินเทอร์เฟซปริมาณต่ำ ขึ้นอยู่กับเอ็นจิ้นอินเทอร์เฟซและโครงสร้างพื้นฐานการเชื่อมต่อ
- ระบบส่วนบุคคล: ซึ่งรวมถึงการทดสอบระบบแต่ละระบบแยกกัน ตัวอย่างเช่น ระบบการเรียกเก็บเงินและระบบการจัดการสินค้าคงคลังสำหรับร้านค้าปลีกควรสามารถทำงานแยกจากกันได้
รายการแรกนั้นใกล้เคียงกันมากพอ การทดสอบเวิร์กโฟลว์ เพื่อนำสถานการณ์ต่างๆ มาใช้ซ้ำ และรายการสุดท้ายนั้นทับซ้อนกับ การทดสอบโมดูลเนื่องจากระบบที่ล้มเหลวด้วยตัวเองก็จะล้มเหลวอีกครั้งเมื่อเชื่อมต่อแล้ว
กลยุทธ์การทดสอบอินเทอร์เฟซ
กลยุทธ์การทดสอบอินเทอร์เฟซ คือ วิธีการที่ใช้ทดสอบอินเทอร์เฟซด้วยการทดสอบทั่วไป โดยไม่คำนึงถึงการใช้งานจริง เราสามารถใช้ abs ได้tracทดสอบกรณีต่างๆ และสร้างตัวอย่างที่เป็นรูปธรรมของกรณีทดสอบสำหรับแต่ละการใช้งานของกลยุทธ์การทดสอบอินเทอร์เฟซ ฐาน/สัมบูรณ์tracกรณีทดสอบ t จะทำการทดสอบที่ไม่ขึ้นกับการใช้งานจริง ในขณะที่การทดสอบแบบรูปธรรมจะดูแลการสร้างอ็อบเจ็กต์เพื่อทดสอบและทำการทดสอบที่ขึ้นกับการใช้งานจริง
ข้อดีของโครงสร้างนั้นคือการนำกลับมาใช้ใหม่ เมื่อมีการใช้งานอินเทอร์เฟซเดียวกันเป็นครั้งที่สาม ประโยชน์ที่ได้รับก็จะเพิ่มขึ้นtract suite ทำงานกับมันโดยไม่มีการเปลี่ยนแปลงใดๆ และจำเป็นต้องเขียนโค้ดเฉพาะการสร้างอินสแตนซ์เท่านั้น แนวคิดเดียวกันนี้ถูกนำไปใช้ในระดับที่ใหญ่ขึ้นใน การทดสอบส่วนประกอบซึ่งเป็นที่ที่มีความเห็นพ้องกันtract suite จะถูกเรียกใช้กับทุกส่วนประกอบที่อ้างว่าตรงตามมาตรฐาน
เครื่องมือทดสอบอินเทอร์เฟซ
เนื่องจากอินเทอร์เฟซไม่มีหน้าจอ เครื่องมือจึงต้องสร้างคำขอโดยตรงและตรวจสอบความถูกต้องจากคำตอบดิบ โดยปกติแล้วทีมงานจะใช้เครื่องมือสามประเภทร่วมกัน
- ไคลเอ็นต์ API และตัวสร้างคำขอ: เครื่องมือช่างเช่น Postman, SoapUIInsomnia และ Hoppscotch ส่งคำขอ REST, SOAP หรือ GraphQL จัดเก็บคำขอเหล่านั้นในรูปแบบคอลเลกชันที่สามารถนำกลับมาใช้ใหม่ได้ และตรวจสอบสถานะรหัส ส่วนหัว และเนื้อหาการตอบกลับ
- Codeไลบรารีทดสอบระดับ -: ไลบรารีที่ทำงานอยู่ภายในชุดทดสอบที่มีอยู่แล้วจะช่วยให้การตรวจสอบอินเทอร์เฟซทำงานควบคู่ไปกับการทดสอบหน่วย และดำเนินการทุกครั้งที่มีการสร้าง ซึ่งจะช่วยป้องกันไม่ให้การทดสอบล้าสมัย
- เครื่องมือโหลดและโปรโตคอล: เครื่องมือเช่น JMeter ขับเคลื่อนอินเทอร์เฟซเดียวกันที่ระดับเสียง ซึ่งเป็นสิ่งที่เปลี่ยนการตรวจสอบการทำงานให้กลายเป็น การทดสอบประสิทธิภาพ ของการเชื่อมต่อ
- การจำลองบริการและการจำลองเสมือน: การใช้ส่วนต่อขยายแทนปลายอีกด้านหนึ่งช่วยให้สามารถทดสอบด้านหนึ่งได้ในขณะที่อีกด้านหนึ่งไม่สามารถใช้งานได้ ยังสร้างไม่เสร็จ หรือมีค่าใช้จ่ายสูงเกินไปที่จะเรียกใช้ซ้ำๆ
การเลือกมีความสำคัญน้อยกว่าการครอบคลุม ไม่ว่าลูกค้ารายใดจะถูกเลือก ชุดคำขอจะต้องถูกจัดเก็บไว้ในระบบควบคุมเวอร์ชันควบคู่ไปกับโค้ด ดังนั้นการเปลี่ยนแปลงอินเทอร์เฟซและการเปลี่ยนแปลงการทดสอบจึงเกิดขึ้นใน commit เดียวกัน รายละเอียดของหมวดหมู่ที่กว้างขึ้นจะกล่าวถึงใน การทดสอบ API.
รายการตรวจสอบและแนวทางปฏิบัติที่ดีที่สุดสำหรับการทดสอบอินเทอร์เฟซ
รายการตรวจสอบสั้นๆ นี้จะช่วยให้การครอบคลุมอินเทอร์เฟซมีความถูกต้องแม่นยำในทุกเวอร์ชัน ควรตรวจสอบรายการตรวจสอบนี้สำหรับแต่ละการเชื่อมต่อ แทนที่จะตรวจสอบสำหรับแอปพลิเคชันโดยรวม
- กับtract แรก: ตรวจสอบให้แน่ใจว่ารูปแบบคำขอและคำตอบตรงกับข้อกำหนดที่เผยแพร่ไว้ทุกฟิลด์ รวมถึงประเภทข้อมูลและฟิลด์เสริมต่างๆ
- ค่าขอบเขต: ส่งข้อมูลว่างเปล่า, ฟิลด์ที่มีความยาวสูงสุด, ชุดอักขระที่ไม่คาดคิด และรูปแบบวันที่ที่กลับด้าน
- เส้นทางการเกิดข้อผิดพลาด: ตรวจสอบให้แน่ใจว่าข้อผิดพลาดทุกครั้งส่งคืนรหัสและข้อความที่มีความหมาย แทนที่จะเป็นเพียงสแต็ก tracหรือความสำเร็จที่เงียบงัน
- การหมดเวลาและการลองใหม่: ขัดจังหวะการเชื่อมต่อระหว่างการร้องขอ และยืนยันว่าผู้โทรสามารถลองใหม่ได้อย่างปลอดภัยโดยไม่ทำซ้ำธุรกรรม
- การรักษาความปลอดภัย: ตรวจสอบการยืนยันตัวตน การอนุญาต และการเข้ารหัสบนลิงก์ และตรวจสอบให้แน่ใจว่าข้อความแสดงข้อผิดพลาดไม่เปิดเผยรายละเอียดภายใน
- ความสอดคล้องของข้อมูล: อ่านบันทึกกลับจากฝั่งปลายทางและยืนยันว่าไม่มีส่วนใดถูกตัดทอน เข้ารหัสใหม่ หรือเรียงลำดับใหม่ระหว่างการส่ง
- ปริมาตร: ทำการร้องขอที่มีปริมาณการใช้งานสูงสุดซ้ำอีกครั้งภายใต้ภาระงานพร้อมกัน และคอยสังเกตว่าการเชื่อมต่อพูลหมดลงหรือไม่
มีหลักปฏิบัติสามประการที่ทำให้เช็คลิสต์นั้นสามารถทำซ้ำได้ ประการแรก ให้สร้างระบบอัตโนมัติสำหรับชุดทดสอบและเรียกใช้ในทุกๆ การสร้าง เพราะอินเทอร์เฟซมักเปลี่ยนแปลงอย่างเงียบๆ มากกว่าหน้าจอ ประการที่สอง ให้บันทึกคำขอและคำตอบทั้งหมดสำหรับทุกความล้มเหลว เนื่องจากแทบเป็นไปไม่ได้เลยที่จะจำลองข้อบกพร่องของอินเทอร์เฟซจากภาพหน้าจอ ประการที่สาม ให้รักษาชุดทดสอบให้เป็นอิสระจากข้อมูลทดสอบที่สร้างโดยชุดทดสอบอื่นๆ เพื่อให้ความล้มเหลวชี้ไปที่อินเทอร์เฟซมากกว่าที่จะชี้ไปที่เรคอร์ดที่หายไป
การตรวจสอบเหล่านี้สอดคล้องกับแผนงานโดยรวมที่ได้อธิบายไว้แล้ว ประเภทของการทดสอบซอฟต์แวร์และพวกมันจะทำงานก่อนที่การเชื่อมต่อเดียวกันจะถูกใช้งานตั้งแต่ต้นจนจบในระหว่างนั้น การทดสอบระบบ.
การทดสอบอินเทอร์เฟซกับการทดสอบการรวม
สองคำนี้มีความเกี่ยวข้องกันมากกว่าที่จะขัดแย้งกัน กล่าวคือ การทดสอบอินเทอร์เฟซเป็นส่วนหนึ่งของงานบูรณาการที่มุ่งเน้นไปที่การเชื่อมต่อโดยตรง ตารางด้านล่างแสดงให้เห็นถึงจุดเน้นของแต่ละด้าน
| การทดสอบอินเทอร์เฟซ | การทดสอบการผสานรวม |
|---|---|
| ประเภทการทดสอบการรวมที่เกี่ยวข้องกับการทดสอบอินเทอร์เฟซระหว่างส่วนประกอบหรือระบบ | การทดสอบดำเนินการเพื่อแสดงข้อบกพร่องในส่วนต่อประสานและการโต้ตอบระหว่างส่วนประกอบหรือระบบที่รวมเข้าด้วยกัน |
| การโฟกัสคือข้อเสียtract — รูปแบบคำขอ รูปแบบการตอบกลับ รหัสข้อผิดพลาด และระยะเวลาหมดเวลา | จุดสนใจอยู่ที่พฤติกรรมโดยรวมของส่วนประกอบต่างๆ เมื่อนำมาเชื่อมต่อกันแล้ว |
| สามารถดำเนินการได้ทันทีที่มีข้อกำหนด โดยที่ปลายอีกด้านยังไม่ได้ต่อเชื่อม | จำเป็นต้องสร้างและติดตั้งส่วนประกอบที่เกี่ยวข้องทั้งหมดพร้อมกัน |
| จุดบกพร่องอยู่ที่จุดเชื่อมต่อจุดหนึ่ง | ความล้มเหลวอาจชี้ไปที่ส่วนประกอบใดก็ได้ในกลุ่มที่ประกอบขึ้น |
ผู้ที่เพิ่งเริ่มต้นศึกษาในสาขาวิชานี้จะพบว่าระดับต่างๆ ที่เกี่ยวข้องได้รับการอธิบายไว้ในรายละเอียดแล้ว การทดสอบการรวม และโดยทั่วไป การทดสอบซอฟต์แวร์ บทนำ ในขณะที่คำศัพท์ที่ใช้ข้างต้นมาจากมาตรฐาน วิศวกรรมซอฟต์แวร์ ในทางปฏิบัติ สำหรับระบบที่ใช้งานผ่านเบราว์เซอร์ การเชื่อมต่อแบบเดียวกันนี้จะถูกใช้งานอีกครั้งในที่สุดระหว่าง การทดสอบแอปพลิเคชันเว็บ.
