SIT คืออะไร? การทดสอบการบูรณาการระบบ (System Integration Testing) พร้อมตัวอย่าง
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
การทดสอบการบูรณาการระบบ (System Integration Testing) ตรวจสอบว่าโมดูลฮาร์ดแวร์และซอฟต์แวร์ที่สร้างขึ้นแยกกันนั้นทำงานได้อย่างถูกต้องเมื่อรวมเข้าด้วยกันเป็นระบบที่สมบูรณ์ การทดสอบนี้จะเปิดเผยข้อบกพร่องด้านอินเทอร์เฟซ การไหลของข้อมูล จังหวะเวลา และหน่วยความจำ ซึ่งการทดสอบหน่วย (Unit Testing) เพียงอย่างเดียวไม่สามารถตรวจพบได้ก่อนการปล่อยใช้งาน
การทดสอบการรวมระบบคืออะไร?
System การทดสอบการผสานรวม หมายถึงการทดสอบซอฟต์แวร์ประเภทหนึ่งที่ดำเนินการในสภาพแวดล้อมฮาร์ดแวร์และซอฟต์แวร์แบบรวมเพื่อตรวจสอบพฤติกรรมของระบบที่สมบูรณ์ เป็นการทดสอบที่ดำเนินการบนระบบบูรณาการที่สมบูรณ์เพื่อประเมินการปฏิบัติตามข้อกำหนดของระบบตามข้อกำหนดที่ระบุ
การทดสอบการบูรณาการระบบ (System Integration Testing หรือ SIT) เป็นการทดสอบที่ดำเนินการเพื่อตรวจสอบปฏิสัมพันธ์ระหว่างโมดูลต่างๆ ของระบบซอฟต์แวร์ โดยเกี่ยวข้องกับการตรวจสอบข้อกำหนดซอฟต์แวร์ระดับสูงและระดับต่ำที่ระบุไว้ในเอกสารข้อกำหนดซอฟต์แวร์/ข้อมูล และเอกสารการออกแบบซอฟต์แวร์
SIT ยังตรวจสอบการทำงานร่วมกันของระบบซอฟต์แวร์กับระบบอื่น ๆ และทดสอบอินเทอร์เฟซระหว่างโมดูลของแอปพลิเคชันซอฟต์แวร์ ในการทดสอบประเภทนี้ โมดูลจะถูกทดสอบทีละส่วนก่อน จากนั้นจึงนำมารวมกันเพื่อสร้างระบบ ตัวอย่างเช่น ส่วนประกอบซอฟต์แวร์และ/หรือฮาร์ดแวร์จะถูกรวมและทดสอบทีละขั้นตอนจนกว่าระบบทั้งหมดจะถูกรวมเข้าด้วยกัน
แผนภาพด้านบนแสดงลำดับขั้นตอนที่กำหนด SIT: โมดูลที่ได้รับการตรวจสอบแยกกันจะถูกรวมเข้าด้วยกันทีละขั้นตอนจนกระทั่งเหลือระบบบูรณาการเดียวที่อยู่ระหว่างการทดสอบ
ทำไมต้องทำการทดสอบการรวมระบบ?
ในสาขาวิศวกรรมซอฟต์แวร์ การทดสอบการรวมระบบทำได้เนื่องจาก
- ช่วยในการตรวจจับ ข้อบกพร่อง ก่อน
- จะมีข้อเสนอแนะก่อนหน้านี้เกี่ยวกับการยอมรับของแต่ละโมดูล
- การจัดกำหนดการการแก้ไขข้อบกพร่องมีความยืดหยุ่น และสามารถซ้อนทับกับการพัฒนาได้
- การไหลของข้อมูลที่ถูกต้อง
- กระแสการควบคุมที่ถูกต้อง
- ช่วงเวลาที่ถูกต้อง
- การใช้หน่วยความจำที่ถูกต้อง
- ถูกต้องตามข้อกำหนดของซอฟต์แวร์
การทดสอบการบูรณาการระบบ เทียบกับ การทดสอบระบบ เทียบกับ การทดสอบการยอมรับของผู้ใช้
เนื่องจากทั้งสามระดับนี้เรียงต่อกัน จึงมักทำให้เกิดความสับสนอยู่บ่อยครั้ง การทดสอบระบบ SIT ตรวจสอบโครงสร้างที่สร้างเสร็จแล้วหนึ่งชิ้นเทียบกับข้อกำหนด และตรวจสอบรอยต่อระหว่างโครงสร้างต่างๆ การทดสอบการยอมรับของผู้ใช้ ตรวจสอบความเหมาะสมของธุรกิจจากมุมมองของลูกค้า ตารางด้านล่างแสดงความแตกต่างระหว่างทั้งสองประเภท
| พารามิเตอร์ | การทดสอบการรวมระบบ | การทดสอบระบบ | การทดสอบการยอมรับของผู้ใช้ |
|---|---|---|---|
| โฟกัสหลัก | อินเทอร์เฟซและการไหลของข้อมูลระหว่างโมดูลแบบบูรณาการ | พฤติกรรมโดยรวมของโครงสร้างที่ประกอบเสร็จแล้ว | ความฟิตทางธุรกิจสำหรับการใช้งานจริง |
| ระดับการทดสอบ | ระดับสอง | ระดับสาม | ระดับสุดท้ายก่อนเปิดใช้งานจริง |
| เทคนิค | กล่องดำ | กล่องสีดำ กล่องสีขาว หรือกล่องสีเทา | กล่องดำ |
| แสดงโดย | ผู้ทดสอบการบูรณาการและนักพัฒนา | ทีมทดสอบอิสระ | ลูกค้าหรือผู้ใช้ปลายทาง |
| ข้อบกพร่องทั่วไป | อินเทอร์เฟซ, เวลา, หน่วยความจำ และแผนผังข้อมูลping ข้อผิดพลาด | ข้อผิดพลาดของระบบทั้งแบบที่ใช้งานได้และใช้งานไม่ได้ | ความไม่สอดคล้องกันระหว่างความสามารถในการใช้งานและข้อกำหนด |
| ทำงานเมื่อ | หลังจาก การทดสอบหน่วย | หลังจาก SIT | หลังจากการทดสอบระบบ |
ลำดับขั้นตอนมีความสำคัญ โมดูลจะผ่านการทดสอบหน่วย (Unit Testing) SIT จะพิสูจน์อินเทอร์เฟซ การทดสอบระบบ (System Testing) จะพิสูจน์ผลิตภัณฑ์ที่ประกอบเสร็จแล้ว และ UAT จะยืนยันว่าผลิตภัณฑ์ตรงตามความคาดหวังทางธุรกิจ ข้ามขั้นตอนนี้ping SIT ผลักดันข้อบกพร่องของอินเทอร์เฟซไปยัง UAT ซึ่งการแก้ไขแต่ละครั้งมีต้นทุนสูงกว่ามาก
วิธีทำการทดสอบการรวมระบบ
เป็นเทคนิคที่เป็นระบบสำหรับการสร้างโครงสร้างโปรแกรม พร้อมทั้งทำการทดสอบเพื่อค้นหาข้อผิดพลาดที่เกี่ยวข้องกับการเชื่อมต่อระบบ
โมดูลทั้งหมดได้รับการบูรณาการไว้ล่วงหน้า และโปรแกรมทั้งหมดได้รับการทดสอบโดยรวม แต่ในระหว่างกระบวนการนี้ มีแนวโน้มที่จะพบชุดข้อผิดพลาด
การแก้ไขข้อผิดพลาดดังกล่าวทำได้ยากเนื่องจากสาเหตุของการแยกมีความซับซ้อนเนื่องจากการขยายโปรแกรมทั้งหมดอย่างกว้างขวาง เมื่อข้อผิดพลาดเหล่านี้ได้รับการแก้ไขและแก้ไขแล้ว ข้อผิดพลาดใหม่จะปรากฏขึ้น และกระบวนการดำเนินต่อไปอย่างราบรื่นในวงวนที่ไม่มีที่สิ้นสุด. เพื่อหลีกเลี่ยงสถานการณ์ดังกล่าว จึงมีการใช้วิธีการอื่น นั่นคือ การบูรณาการแบบเพิ่มทีละขั้น (Incremental Integration) ซึ่งจะอธิบายรายละเอียดในส่วนถัดไป
มีวิธีการเพิ่มเติมบางอย่าง เช่น การทดสอบการรวมระบบจะดำเนินการบนระบบที่ใช้โปรเซสเซอร์เป้าหมาย วิธีการที่ใช้ก็คือ สีดำ Box การทดสอบ- สามารถใช้การรวมจากล่างขึ้นบนหรือจากบนลงล่างได้
กรณีทดสอบถูกกำหนดโดยใช้ข้อกำหนดซอฟต์แวร์ระดับสูงเท่านั้น
การรวมซอฟต์แวร์อาจทำได้สำเร็จเป็นส่วนใหญ่ในสภาพแวดล้อมโฮสต์ โดยมีหน่วยเฉพาะสำหรับสภาพแวดล้อมเป้าหมายที่ยังคงจำลองอยู่ในโฮสต์ต่อไป จำเป็นต้องทำการทดสอบซ้ำในสภาพแวดล้อมเป้าหมายเพื่อการยืนยันอีกครั้ง
การทดสอบยืนยันในระดับนี้จะระบุปัญหาเฉพาะสภาพแวดล้อม เช่น ข้อผิดพลาดในการจัดสรรและยกเลิกการจัดสรรหน่วยความจำ ความเป็นไปได้ในการดำเนินการบูรณาการซอฟต์แวร์ในสภาพแวดล้อมโฮสต์จะขึ้นอยู่กับว่ามีฟังก์ชันเฉพาะเป้าหมายมากน้อยเพียงใด สำหรับระบบฝังตัวบางระบบ การเชื่อมโยงกับสภาพแวดล้อมเป้าหมายจะแข็งแกร่งมาก ทำให้การดำเนินการบูรณาการซอฟต์แวร์ในสภาพแวดล้อมโฮสต์เป็นไปไม่ได้ในทางปฏิบัติ
การพัฒนาซอฟต์แวร์ขนาดใหญ่จะแบ่งการรวมซอฟต์แวร์ออกเป็นหลายระดับ ระดับล่างของการรวมซอฟต์แวร์อาจขึ้นอยู่กับสภาพแวดล้อมโฮสต์เป็นหลัก โดยระดับต่อมาของการรวมซอฟต์แวร์จะขึ้นอยู่กับสภาพแวดล้อมเป้าหมายมากขึ้น
หมายเหตุ หากมีการทดสอบซอฟต์แวร์เพียงอย่างเดียว จะเรียกว่าการทดสอบการรวมซอฟต์แวร์ซอฟต์แวร์ [SSIT] และหากมีการทดสอบทั้งฮาร์ดแวร์และซอฟต์แวร์ จะเรียกว่าการทดสอบการรวมซอฟต์แวร์ฮาร์ดแวร์ [HSIT]
แนวทางแบบค่อยเป็นค่อยไป
เนื่องจากการรวมทุกอย่างเข้าด้วยกันในคราวเดียวทำให้ยากต่อการแยกแยะข้อบกพร่อง ทีมส่วนใหญ่จึงเลือกใช้วิธีการดำเนินการทีละขั้นตอนตามที่อธิบายไว้ในที่นี้
การทดสอบส่วนเพิ่มเป็นวิธีหนึ่งของการทดสอบการบูรณาการ ในวิธีการทดสอบประเภทนี้ คุณต้องทดสอบแต่ละโมดูลของซอฟต์แวร์แยกกันก่อน จากนั้นจึงทำการทดสอบต่อโดยผนวกโมดูลอื่นเข้ากับโมดูลนั้น ต่อท้ายโมดูลอื่นต่อไปเรื่อยๆ
การบูรณาการแบบค่อยเป็นค่อยไปเป็นสิ่งที่ตรงกันข้ามกับแนวทางบิ๊กแบง โปรแกรมถูกสร้างและทดสอบในส่วนเล็กๆ ซึ่งข้อผิดพลาดสามารถแยกและแก้ไขได้ง่ายกว่า อินเทอร์เฟซมีแนวโน้มที่จะได้รับการทดสอบอย่างสมบูรณ์ และอาจใช้วิธีการทดสอบอย่างเป็นระบบ
การทดสอบแบบเพิ่มหน่วยมีสองประเภท
- วิธีการจากบนลงล่าง
- วิธีการจากล่างขึ้นบน
วิธีการจากบนลงล่าง
ในแนวทางประเภทนี้ แต่ละคนจะเริ่มต้นด้วยการทดสอบเฉพาะส่วนต่อประสานกับผู้ใช้ โดยมีฟังก์ชันการทำงานพื้นฐานที่จำลองโดย stubs จากนั้นคุณเลื่อนลงไปด้านล่างโดยรวมชั้นล่างและชั้นล่างดังที่แสดงในภาพด้านล่าง
- เริ่มต้นจากโมดูลควบคุมหลัก โมดูลต่างๆ จะถูกรวมเข้าด้วยกันโดยเลื่อนลงไปตามลำดับชั้นการควบคุม
- โมดูลย่อยของโมดูลควบคุมหลักจะรวมอยู่ในโครงสร้างทั้งในลักษณะกว้างก่อนหรือในลักษณะลึกก่อน
- การบูรณาการแบบเชิงลึกจะบูรณาการโมดูลทั้งหมดบนเส้นทางควบคุมหลักของโครงสร้างตามที่แสดงในแผนภาพต่อไปนี้:
กระบวนการบูรณาการโมดูลจะดำเนินการในลักษณะต่อไปนี้:
- โมดูลควบคุมหลักถูกใช้เป็นตัวขับทดสอบ และส่วนต้นขั้วจะถูกแทนที่สำหรับโมดูลทั้งหมดที่อยู่รองจากโมดูลควบคุมหลักโดยตรง
- ต้นขั้วรองจะถูกแทนที่ทีละโมดูลด้วยโมดูลจริง ขึ้นอยู่กับแนวทางที่เลือก (กว้างก่อนหรือลึกก่อน)
- การทดสอบจะดำเนินการเมื่อแต่ละโมดูลถูกรวมเข้าด้วยกัน
- เมื่อเสร็จสิ้นการทดสอบแต่ละชุด ต้นขั้วอีกอันจะถูกแทนที่ด้วยโมดูลจริงเมื่อเสร็จสิ้นการทดสอบแต่ละชุด
- เพื่อให้แน่ใจว่าไม่มีข้อผิดพลาดใหม่เกิดขึ้น การทดสอบการถดถอย อาจจะดำเนินการ
กระบวนการดำเนินต่อไปจากขั้นตอนที่ 2 จนกระทั่งโครงสร้างโปรแกรมทั้งหมดถูกสร้างขึ้น กลยุทธ์จากบนลงล่างฟังดูไม่ซับซ้อน แต่ในทางปฏิบัติ ปัญหาด้านลอจิสติกส์ก็เกิดขึ้น
ปัญหาเหล่านี้ที่พบบ่อยที่สุดเกิดขึ้นเมื่อต้องมีการประมวลผลในระดับต่ำในลำดับชั้นเพื่อทดสอบระดับบนอย่างเพียงพอ
Stubs จะเข้ามาแทนที่โมดูลระดับต่ำเมื่อเริ่มต้นการทดสอบจากบนลงล่าง ดังนั้นจึงไม่มีข้อมูลสำคัญใดสามารถไหลขึ้นไปในโครงสร้างของโปรแกรมได้
ผู้ทดสอบความท้าทายอาจเผชิญ:
- ชะลอการทดสอบหลายๆ ครั้งจนกว่าต้นขั้วจะถูกแทนที่ด้วยโมดูลจริง
- พัฒนาสตับที่ทำหน้าที่จำกัดซึ่งจำลองโมดูลจริง
- รวมซอฟต์แวร์จากด้านล่างของลำดับชั้นขึ้นไป
หมายเหตุ แนวทางแรกทำให้เราสูญเสียการควบคุมการติดต่อระหว่างการทดสอบเฉพาะและการรวมโมดูลเฉพาะ ซึ่งอาจส่งผลให้เกิดความยากลำบากในการระบุสาเหตุของข้อผิดพลาดซึ่งมีแนวโน้มที่จะละเมิดธรรมชาติที่มีข้อจำกัดสูงของวิธีการจากบนลงล่าง
แนวทางที่สองนั้นสามารถใช้ได้ผล แต่จะทำให้มีค่าใช้จ่ายเพิ่มขึ้นมาก เนื่องจากโครงร่างมีความซับซ้อนมากขึ้นเรื่อยๆ
แนวทางด้านล่างขึ้น
การรวมจากล่างขึ้นบนเริ่มต้นการก่อสร้างและการทดสอบด้วยโมดูลที่ระดับต่ำสุดในโครงสร้างของโปรแกรม ในกระบวนการนี้ โมดูลต่างๆ จะถูกรวมเข้าด้วยกันจากล่างขึ้นบน
ในแนวทางนี้ การประมวลผลที่จำเป็นสำหรับโมดูลที่อยู่ใต้บังคับบัญชาจนถึงระดับที่กำหนดจะพร้อมใช้งานเสมอ และความจำเป็นในการ stub ก็หมดไป
กระบวนการทดสอบการรวมระบบนี้ดำเนินการเป็นชุดสี่ขั้นตอน
- โมดูลระดับต่ำจะถูกผสมเข้าเป็นคลัสเตอร์ที่ทำหน้าที่ย่อยซอฟต์แวร์เฉพาะ
- ไดรเวอร์ถูกเขียนขึ้นเพื่อประสานอินพุตและเอาต์พุตของกรณีทดสอบ
- คลัสเตอร์หรือการสร้างได้รับการทดสอบแล้ว
- ไดรเวอร์จะถูกลบออกและคลัสเตอร์จะถูกรวมเข้าด้วยกันโดยเคลื่อนขึ้นไปในโครงสร้างโปรแกรม
เมื่อการบูรณาการดำเนินไปในระดับที่สูงขึ้น ความจำเป็นในการเรียนรู้การขับขี่ทดสอบแยกต่างหากก็จะลดลง อันที่จริง หากโครงสร้างโปรแกรมสองระดับบนสุดได้รับการบูรณาการจากบนลงล่าง จำนวนผู้ขับขี่สามารถลดลงได้อย่างมาก และการบูรณาการกลุ่มต่างๆ ก็จะง่ายขึ้นมาก การบูรณาการเป็นไปตามรูปแบบที่แสดงไว้ด้านล่าง
หมายเหตุ หากโครงสร้างโปรแกรมสองระดับบนสุดถูกรวมจากบนลงล่าง จำนวนไดรเวอร์จะลดลงอย่างมาก และการบูรณาการโครงสร้างจะง่ายขึ้นอย่างมาก
แนวทางบิ๊กแบง
ในแนวทางนี้ โมดูลทั้งหมดจะไม่ถูกรวมเข้าด้วยกันจนกว่าและเว้นแต่โมดูลทั้งหมดจะพร้อม เมื่อพร้อม โมดูลทั้งหมดจะถูกรวมเข้าด้วยกัน จากนั้นจึงดำเนินการเพื่อดูว่าโมดูลที่รวมเข้าด้วยกันทั้งหมดใช้งานได้หรือไม่
ในแนวทางนี้ เป็นการยากที่จะทราบสาเหตุของความล้มเหลวเนื่องจากการบูรณาการทุกอย่างในคราวเดียว
นอกจากนี้ ยังมีโอกาสสูงที่จะเกิดจุดบกพร่องร้ายแรงในสภาพแวดล้อมการใช้งานจริง
วิธีการนี้จะนำมาใช้เฉพาะเมื่อต้องทำการทดสอบการรวมระบบพร้อมกันเท่านั้น
การทดสอบการรวมซอฟต์แวร์ฮาร์ดแวร์
การทดสอบการรวมซอฟต์แวร์ฮาร์ดแวร์ เป็นกระบวนการทดสอบส่วนประกอบซอฟต์แวร์คอมพิวเตอร์ (CSC) สำหรับฟังก์ชันการทำงานระดับสูงบนสภาพแวดล้อมฮาร์ดแวร์เป้าหมาย เป้าหมายของการทดสอบการรวมฮาร์ดแวร์/ซอฟต์แวร์คือการทดสอบพฤติกรรมของซอฟต์แวร์ที่พัฒนาแล้วซึ่งรวมอยู่ในส่วนประกอบฮาร์ดแวร์
การทดสอบการรวมฮาร์ดแวร์-ซอฟต์แวร์ตามความต้องการ
จุดมุ่งหมายของการทดสอบการรวมฮาร์ดแวร์/ซอฟต์แวร์ตามความต้องการคือเพื่อให้แน่ใจว่าซอฟต์แวร์ในคอมพิวเตอร์เป้าหมายจะเป็นไปตามข้อกำหนดระดับสูง ข้อผิดพลาดทั่วไปที่แสดงโดยวิธีการทดสอบนี้ได้แก่:
- ข้อผิดพลาดอินเทอร์เฟซฮาร์ดแวร์/ซอฟต์แวร์
- การละเมิดการแบ่งพาร์ติชันซอฟต์แวร์
- ไม่สามารถตรวจจับความล้มเหลวโดยการทดสอบในตัว
- การตอบสนองที่ไม่ถูกต้องต่อความล้มเหลวของฮาร์ดแวร์
- ข้อผิดพลาดเนื่องจากการเรียงลำดับ โหลดอินพุตชั่วคราว และกำลังไฟฟ้าอินพุตชั่วคราว
- คำติชมวนซ้ำพฤติกรรมที่ไม่ถูกต้อง
- การควบคุมฮาร์ดแวร์การจัดการหน่วยความจำไม่ถูกต้องหรือไม่เหมาะสม
- ปัญหาการโต้แย้งบัสข้อมูล
- การทำงานที่ไม่ถูกต้องของกลไกในการตรวจสอบความเข้ากันได้และความถูกต้องของซอฟต์แวร์ที่โหลดภาคสนาม
การรวมซอฟต์แวร์ฮาร์ดแวร์เกี่ยวข้องกับการตรวจสอบข้อกำหนดระดับสูง การทดสอบทั้งหมดในระดับนี้ดำเนินการกับฮาร์ดแวร์เป้าหมาย
- การทดสอบกล่องดำเป็นวิธีการทดสอบหลักที่ใช้ในการทดสอบระดับนี้
- กำหนด กรณีทดสอบ จากข้อกำหนดระดับสูงเท่านั้น
- การทดสอบจะต้องดำเนินการกับฮาร์ดแวร์มาตรฐานการผลิต (ตามเป้าหมาย)
สิ่งที่ต้องพิจารณาเมื่อออกแบบกรณีทดสอบสำหรับการรวม HW/SW
- การได้มาซึ่งข้อมูลทั้งหมดอย่างถูกต้องโดยซอฟต์แวร์
- การปรับขนาดและช่วงของข้อมูลที่คาดหวังตั้งแต่ฮาร์ดแวร์ไปจนถึงซอฟต์แวร์
- ผลลัพธ์ที่ถูกต้องของข้อมูลจากซอฟต์แวร์ไปยังฮาร์ดแวร์
- ข้อมูลภายในข้อกำหนด (ช่วงปกติ)
- ข้อมูลนอกข้อกำหนด (ช่วงผิดปกติ)
- ข้อมูลขอบเขต
- ขัดจังหวะการประมวลผล
- การจับเวลา
- การใช้หน่วยความจำที่ถูกต้อง (การกำหนดแอดเดรส การทับซ้อน ฯลฯ)
- การเปลี่ยนผ่านของรัฐ
หมายเหตุ สำหรับการทดสอบการขัดจังหวะ การขัดจังหวะทั้งหมดจะได้รับการตรวจสอบอย่างเป็นอิสระจากคำขอเริ่มแรกผ่านการให้บริการเต็มรูปแบบและเมื่อเสร็จสิ้น กรณีทดสอบจะได้รับการออกแบบมาโดยเฉพาะเพื่อทดสอบการขัดจังหวะอย่างเพียงพอ
ซอฟต์แวร์กับการทดสอบการรวมซอฟต์แวร์
เป็นการทดสอบส่วนประกอบซอฟต์แวร์คอมพิวเตอร์ที่ทำงานภายในสภาพแวดล้อมของคอมพิวเตอร์โฮสต์/เป้าหมาย โดยจำลองระบบทั้งหมด [ส่วนประกอบซอฟต์แวร์คอมพิวเตอร์อื่นๆ] และทดสอบฟังก์ชันการทำงานระดับสูง
โดยจะเน้นที่พฤติกรรมของ CSC ในสภาพแวดล้อมโฮสต์/เป้าหมายจำลอง แนวทางที่ใช้สำหรับการบูรณาการซอฟต์แวร์อาจเป็นแนวทางแบบเพิ่มทีละขั้นตอน (แบบบนลงล่าง แบบล่างขึ้นบน หรือการผสมผสานทั้งสองแบบ ซึ่งเรียกว่าแนวทางแบบแซนด์วิชหรือแบบไฮบริด)
เกณฑ์การเข้าและออกสำหรับการทดสอบการรวมระบบ
เมื่อกำหนดแนวทางและรูปแบบการบูรณาการทั้งสองแบบได้แล้ว คำถามที่เหลือคือทีมควรเริ่มและหยุดเมื่อใด โดยปกติแล้วในการทดสอบการบูรณาการ จะใช้กลยุทธ์ ETVX (เกณฑ์การเข้า เกณฑ์งาน การตรวจสอบ และเกณฑ์การออก)
เกณฑ์รายการ:
- เสร็จสิ้นการ การทดสอบหน่วย
ปัจจัยการผลิต:
- ข้อมูลข้อกำหนดซอฟต์แวร์
- เอกสารการออกแบบซอฟต์แวร์
- แผนการตรวจสอบซอฟต์แวร์
- เอกสารการรวมซอฟต์แวร์
กิจกรรม:
- ขึ้นอยู่กับข้อกำหนดระดับสูงและต่ำ สร้างกรณีทดสอบและขั้นตอน
- รวมโมดูลระดับต่ำที่ใช้ฟังก์ชันทั่วไป
- พัฒนาสายรัดทดสอบ
- ทดสอบโครงสร้าง
- เมื่อผ่านการทดสอบแล้ว โครงสร้างจะถูกรวมเข้ากับรุ่นอื่นๆ และทดสอบจนกว่าระบบจะรวมเข้าด้วยกันทั้งหมด
- ดำเนินการทดสอบทั้งหมดอีกครั้งบนแพลตฟอร์มที่ใช้โปรเซสเซอร์เป้าหมาย และรับผลลัพธ์
เกณฑ์การออก:
- การรวมโมดูลซอฟต์แวร์เข้ากับฮาร์ดแวร์เป้าหมายสำเร็จแล้ว
- ประสิทธิภาพที่ถูกต้องของซอฟต์แวร์ตามข้อกำหนดที่ระบุ
Outputs
- รายงานการทดสอบบูรณาการ
- กรณีและขั้นตอนการทดสอบซอฟต์แวร์ [SVCP]
ความท้าทายทั่วไปในการทดสอบการบูรณาการระบบ
ถึงแม้จะมีแนวทางที่เหมาะสมและเกณฑ์การยุติที่ชัดเจน สภาพแวดล้อมแบบบูรณาการก็ยังสร้างปัญหาที่มักไม่ปรากฏให้เห็นในระหว่างการทดสอบหน่วย การตรวจพบปัญหาเหล่านี้ตั้งแต่เนิ่นๆ จะช่วยให้กำหนดการมีความสมจริงมากขึ้น
- สภาพแวดล้อมไม่ตรงกัน: แบบบูรณาการ สภาพแวดล้อมการทดสอบ โดยปกติแล้วการจำลองสถานการณ์จริงมักไม่เกิดขึ้น ดังนั้นข้อผิดพลาดด้านเวลาและการกำหนดค่าจึงมักปรากฏให้เห็นจนถึงช่วงท้ายๆ
- ความพร้อมในการพึ่งพา: อินเทอร์เฟซของบุคคลที่สามและอินเทอร์เฟซแบบเก่ามักยังไม่เสร็จสมบูรณ์ ทำให้ผู้ทดสอบต้องพึ่งพาแบบจำลองและโปรแกรมจำลองเป็นเวลานานกว่าที่วางแผนไว้
- ความไม่สอดคล้องกันของข้อมูล: โมดูลสองโมดูลอาจแสดงข้อมูลเดียวกันในรูปแบบที่แตกต่างกัน ทำให้เกิดความไม่ตรงกันโดยไม่แสดงอาการผิดปกติให้เห็น แทนที่จะเป็นความล้มเหลวที่เห็นได้ชัด
- ผู้รับผิดชอบข้อบกพร่อง: เมื่อความล้มเหลวเกิดขึ้นกับสองทีม การวิเคราะห์หาสาเหตุที่แท้จริงและ การจัดการข้อบกพร่อง ชะลอตัวลงอย่างเห็นได้ชัด
- ต้นทุนการถดถอย: อินเทอร์เฟซใหม่ทุกอันจะขยายใหญ่ขึ้น การทดสอบการถดถอย เนื่องจากเป็นชุดโปรแกรม ดังนั้นการเรียกใช้งานซ้ำด้วยตนเองจึงไม่สามารถทำได้อย่างยั่งยืนในที่สุด
ปัญหาเหล่านี้ส่วนใหญ่เป็นความเสี่ยงด้านกำหนดการมากกว่าปัญหาทางเทคนิคที่แก้ไขไม่ได้ การตกลงเรื่องวันพร้อมใช้งานของอินเทอร์เฟซ ขอบเขตของโปรแกรมจำลอง และการรับผิดชอบในการคัดแยกข้อบกพร่องก่อนที่จะรวมระบบเวอร์ชันแรกเข้าไป จะช่วยลดปัญหาเหล่านี้ได้มาก สำหรับอินเทอร์เฟซที่ผู้จำหน่ายเป็นเจ้าของ ควรบันทึกรูปแบบข้อความที่ตกลงกันไว้และผู้ติดต่อสำหรับการแจ้งปัญหาด้วย เพราะหากไม่มีผู้รับผิดชอบ จะทำให้การแก้ไขล่าช้ากว่าที่ควรจะเป็น
แนวปฏิบัติที่ดีที่สุดสำหรับการทดสอบการบูรณาการระบบ
วงจร SIT ที่ทำซ้ำได้นั้นขึ้นอยู่กับวินัยเกี่ยวกับอินเทอร์เฟซ ข้อมูล และหลักฐาน มากกว่าเครื่องมือ แนวทางปฏิบัติทั้งห้าข้อด้านล่างนี้เหมาะสำหรับการสร้างระบบฝังตัวขนาดเล็กและสภาพแวดล้อมขนาดใหญ่ที่มีผู้จำหน่ายหลายราย และแต่ละข้อจะช่วยลดการทำงานซ้ำในขั้นตอนการทดสอบขั้นต่อๆ ไป
- ก่อนอื่นให้สร้างแผนผังอินเทอร์เฟซทุกอันก่อน ก่อนที่จะเขียนกรณีทดสอบใดๆ ให้ระบุการแลกเปลี่ยนข้อมูลแต่ละรายการ ทิศทาง โปรโตคอล และเจ้าของข้อมูล
- จัดลำดับความสำคัญตามระดับความเสี่ยง ตรวจสอบอินเทอร์เฟซที่ใช้ในการส่งข้อมูลทางการเงิน ข้อมูลส่วนบุคคล หรือข้อมูลที่อยู่ภายใต้ข้อกำหนด ก่อนตรวจสอบอินเทอร์เฟซที่ใช้สำหรับตกแต่ง
- ออกแบบข้อมูลทดสอบที่สมจริง ครอบคลุมช่วงปกติ ช่วงขอบเขต และช่วงผิดปกติ เพื่อให้ตรวจพบข้อผิดพลาดในการปรับขนาดและการปัดเศษได้ตั้งแต่เนิ่นๆ
- สร้างระบบอัตโนมัติสำหรับเส้นทางที่เสถียร อินเทอร์เฟซสายไฟตรวจสอบเข้ากับ บูรณาการอย่างต่อเนื่อง กระบวนการทำงานจึงตรวจสอบความถูกต้องอีกครั้งในทุกขั้นตอนการสร้าง
- เก็บหลักฐานไว้ traceable. เชื่อมโยงผลลัพธ์แต่ละรายการเข้ากับข้อกำหนดผ่านทาง tracเมทริกซ์ความสามารถ ดังนั้นเกณฑ์การออกจากระบบจึงสามารถพิสูจน์ได้ ไม่ใช่เพียงแค่กล่าวอ้าง
⚠ คำแนะนำ: กำหนดรายละเอียดของอินเทอร์เฟซให้แน่นอนก่อนเริ่มกระบวนการผสานรวม การเปลี่ยนแปลงรูปแบบข้อความในภายหลังจะทำให้กรณีทดสอบทั้งสองฝั่งของอินเทอร์เฟซใช้ไม่ได้ผล และเป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้ต้องทำงาน SIT ซ้ำ
