Thread Testing ในการทดสอบซอฟต์แวร์คืออะไร?
ทีมบรรณาธิการ
⚡ สรุปอย่างชาญฉลาด
การทดสอบแบบเธรดจะตรวจสอบความสามารถในการทำงานหลักของงานทางธุรกิจแต่ละงานขณะที่งานนั้นเคลื่อนที่ผ่านระบบที่บูรณาการเข้าด้วยกัน และจะดำเนินการในช่วงเริ่มต้นของการทดสอบการบูรณาการ แทนที่จะดำเนินการหลังจากที่ส่วนประกอบแต่ละส่วนเสร็จสมบูรณ์แล้ว
การทดสอบเธรดคืออะไร?
การทดสอบเธรด การทดสอบแบบ tích hợp (Progressive Testing หรือ RT) เป็นการทดสอบซอฟต์แวร์ประเภทหนึ่งที่ตรวจสอบความสามารถในการทำงานหลักของงานเฉพาะอย่างที่เรียกว่า "เธรด" (thread) โดยปกติจะดำเนินการในขั้นตอนแรกๆ ของการพัฒนาซอฟต์แวร์ การทดสอบการรวม ขั้นตอน การทดสอบแบบใช้เธรดเป็นหนึ่งในกลยุทธ์แบบเพิ่มทีละขั้นที่ใช้ระหว่างการทดสอบการบูรณาการระบบ ด้วยเหตุนี้ การทดสอบแบบใช้เธรดจึงอธิบายได้อย่างเหมาะสมกว่าว่าเป็น การทดสอบปฏิสัมพันธ์ของเธรด.
เธรดในที่นี้ไม่ได้หมายถึงเฉพาะเธรดของระบบปฏิบัติการเท่านั้น วิศวกรรมซอฟต์แวร์ ในแง่ของคำศัพท์ เธรดหมายถึงธุรกรรมทางธุรกิจที่เสร็จสมบูรณ์หนึ่งรายการ เช่น "ลูกค้าสั่งซื้อสินค้า" tracตรวจสอบทุกโมดูลที่มันสัมผัส การทดสอบเธรดจะถามว่าเส้นทางเดียวนั้นยังคงทำงานได้อย่างถูกต้องหรือไม่เมื่อโมดูลต่างๆ ถูกเชื่อมต่อเข้าด้วยกัน
แผนภาพด้านล่างแสดงให้เห็นว่าเธรดแต่ละส่วนถูกรวมเข้าด้วยกันและใช้งานอย่างไรในฐานะระบบย่อย ก่อนที่จะประกอบเป็นระบบทั้งหมด
ประเภทของการทดสอบเธรด
การทดสอบแบบใช้เธรดแบ่งออกเป็นสองประเภท และความแตกต่างนี้จะเป็นตัวกำหนดทั้งข้อมูลทดสอบและข้อบกพร่องที่คุณมีแนวโน้มที่จะพบ
- การทดสอบแบบเธรดเดียว: การทดสอบแบบเธรดเดียวเกี่ยวข้องกับการทำธุรกรรมของแอปพลิเคชันครั้งละหนึ่งรายการเท่านั้น มีการประมวลผลคำขอเพียงหนึ่งรายการ ดังนั้นพฤติกรรมการตอบสนองจึงคาดเดาได้ และการทดสอบนั้นง่ายต่อการเขียนสคริปต์และทำซ้ำ
- การทดสอบแบบมัลติเธรด: การทดสอบแบบมัลติเธรดเกี่ยวข้องกับการทำธุรกรรมหลายรายการที่ทำงานพร้อมกันในเวลาเดียวกัน โดยจะมีการเตรียมเธรดแยกต่างหากสำหรับบริการเดียวกัน เพื่อให้สามารถสังเกตการตอบสนองและการจัดการสถานะร่วมกันภายใต้ภาระงานพร้อมกันได้
ธุรกรรมที่ผ่านการทดสอบอย่างราบรื่นในโหมดการทำงานแบบเธรดเดียว อาจยังคงล้มเหลวในการทำงานแบบมัลติเธรด เนื่องจากรอบการทำงานที่สองจะเพิ่มการแย่งชิงข้อมูล การเชื่อมต่อ และหน่วยความจำเดียวกัน
วิธีการทดสอบเธรด
กระบวนการทำงานแบบเธรดมุ่งเน้นไปที่กิจกรรมการบูรณาการมากกว่าวงจรการพัฒนาโดยรวม ในทางปฏิบัติ วิธีการนี้ทำงานดังนี้
- การทดสอบตามเธรดเป็นรูปแบบทั่วไปของการทดสอบตามเซสชัน โดยในเซสชันนั้นเป็นรูปแบบของเธรด แต่เธรดไม่จำเป็นต้องเป็นเซสชัน
- เธรดหรือโปรแกรม (ฟังก์ชันขนาดเล็ก) จะถูกรวมเข้าและทดสอบทีละขั้นตอนในฐานะระบบย่อย จากนั้นจึงเรียกใช้งานสำหรับระบบทั้งหมด
- ในระดับต่ำสุด ระบบนี้ช่วยให้ผู้บูรณาการมีความรู้ความเข้าใจที่ดีขึ้นเกี่ยวกับขอบเขตของสิ่งที่ต้องทดสอบ
- แทนที่จะทดสอบส่วนประกอบซอฟต์แวร์โดยตรง วิธีการนี้ต้องการให้ผู้บูรณาการมุ่งเน้นไปที่การทดสอบเส้นทางการทำงานเชิงตรรกะในบริบทของระบบโดยรวม
เนื่องจากหน่วยงานที่รับผิดชอบคือเส้นทางการดำเนินธุรกิจมากกว่าส่วนประกอบ การทดสอบเธรดจึงอยู่ตรงกลางระหว่างสองสิ่งนี้อย่างเป็นธรรมชาติ การทดสอบโมดูล และเต็ม การทดสอบระบบ.
เคล็ดลับสำหรับการทดสอบแบบมัลติเธรด
ข้อบกพร่องแบบมัลติเธรดขึ้นอยู่กับจังหวะเวลา ดังนั้นการทดสอบแบบสะอาดหมดจดเพียงครั้งเดียวจึงพิสูจน์อะไรได้ไม่มากนัก เคล็ดลับด้านล่างจะช่วยเพิ่มโอกาสในการตรวจพบข้อบกพร่องเหล่านั้น
- ทดสอบโปรแกรมมัลติเธรดของคุณโดยการเรียกใช้งานซ้ำๆ ด้วยแอปพลิเคชันที่ทำงานสลับกันไป
- ทดสอบโปรแกรมมัลติเธรดของคุณโดยการเรียกใช้โปรแกรมหลายๆ อินสแตนซ์พร้อมกัน
- เรียกใช้โปรแกรมมัลติเธรดของคุณบนฮาร์ดแวร์รุ่นต่างๆ ด้วยระดับความเครียดและภาระงานที่แตกต่างกัน
- ใช้การตรวจสอบโค้ด เนื่องจากข้อผิดพลาดในการซิงโครไนซ์บางอย่างอ่านง่ายกว่าการจำลองขึ้นมา
- รวบรวมเฉพาะข้อผิดพลาดและความล้มเหลวที่เกิดขึ้นในเธรดอื่นที่ไม่ใช่เธรดหลักเท่านั้น
ข้อบกพร่องทั่วไปที่พบระหว่างการทดสอบเกลียว
ข้อผิดพลาดในการทำงานพร้อมกันมักไม่แสดงอาการให้เห็นชัดเจนในขณะที่สแต็กสะอาดหมดจด trace. หมวดหมู่ด้านล่างนี้ครอบคลุมปัญหาเกือบทั้งหมดที่พบในการทำงานแบบมัลติเธรด และแต่ละหมวดหมู่มีอาการเฉพาะที่ควรสังเกต
- เงื่อนไขการแข่งขัน: สองเธรดอ่านและเขียนค่าเดียวกันโดยไม่คำนึงถึงลำดับ ดังนั้นผลลัพธ์สุดท้ายจึงขึ้นอยู่กับว่าเธรดใดทำงานเสร็จก่อน อาการ: ผลรวมที่ถูกต้องในบางครั้งและไม่ถูกต้องในบางครั้ง
- ภาวะชะงักงัน: สองเธรดต่างถือล็อกที่อีกเธรดต้องการ และไม่มีเธรดใดดำเนินการต่อได้ อาการคือ การทำธุรกรรมค้างอยู่อย่างไม่มีกำหนด แทนที่จะล้มเหลวพร้อมแสดงข้อผิดพลาด
- การแย่งชิงทรัพยากร: เธรดจะเข้าคิวเพื่อแย่งการเชื่อมต่อ ตัวจัดการไฟล์ หรือระเบียนเดียวกัน และปริมาณงานจะลดลงอย่างมากก่อนที่จะถึงขีดจำกัดของฮาร์ดแวร์
- ข้อมูลเสียหาย: โครงสร้างข้อมูลที่ใช้ร่วมกันซึ่งเขียนไว้ไม่ครบถ้วน ทำให้บันทึกอยู่ในสถานะที่ไม่สามารถทำธุรกรรมที่ถูกต้องได้
- ความอดอยาก: เธรดที่มีลำดับความสำคัญต่ำจะไม่ได้รับทรัพยากรที่ต้องการ ส่งผลให้เส้นทางของผู้ใช้รายหนึ่งหมดเวลา ในขณะที่ส่วนอื่นๆ ของระบบดูเหมือนจะทำงานได้ตามปกติ
แต่ละกรณีจำเป็นต้องบันทึกการทำงานที่ล้มเหลวลงในบันทึกข้อมูล เนื่องจากข้อบกพร่องที่เกิดขึ้นเพียงครั้งเดียวในห้าสิบครั้งนั้น จะไม่สามารถรายงานได้หากไม่บันทึกไว้ กระบวนการจัดการข้อบกพร่อง.
การทดสอบแบบมัลติเธรด เทียบกับ การทดสอบแบบขนาน เทียบกับ การทดสอบแบบบูรณาการ
คำศัพท์ทั้งสามคำนี้มีความหมายทับซ้อนกันและมักถูกใช้สับสนกันในแผนการทดสอบ ตารางนี้จึงแยกคำศัพท์เหล่านี้ตามความหมายการใช้งาน
| แง่มุม | การทดสอบเธรด | การทดสอบการทำงานพร้อมกัน | การทดสอบบูรณาการ |
| หน่วยที่อยู่ระหว่างการทดสอบ | ธุรกรรมทางธุรกิจหนึ่งรายการข้ามโมดูล | ผู้ใช้หรือเธรดหลายตัวทำงานพร้อมกัน | ส่วนเชื่อมต่อระหว่างส่วนประกอบสองชิ้นขึ้นไป |
| คำถามหลัก | เส้นทางคีย์นี้ใช้งานได้ตั้งแต่ต้นจนจบหรือไม่? | อะไรจะเกิดปัญหาเมื่อมีการเข้าถึงพร้อมกัน? | โมดูลต่างๆ สื่อสารกันได้อย่างถูกต้องหรือไม่? |
| เวทีทั่วไป | การทดสอบการบูรณาการเบื้องต้น | การทดสอบระบบหรือประสิทธิภาพ | หลังจากการทดสอบหน่วย |
| ข้อบกพร่องที่กำหนดเป้าหมาย | เส้นทางการดำเนินการที่ผิดพลาด การส่งต่อข้อมูลที่ขาดหายไป | การติดตาย, สภาวะการแข่งขัน, การแย่งชิงการล็อก | อินเทอร์เฟซไม่ตรงกัน ข้อมูลไม่ถูกต้องtracts |
| ความสัมพันธ์ | รูปแบบมัลติเธรดมีความทับซ้อนกับการทดสอบการทำงานพร้อมกัน | กว้างกว่าขอบเขตการทดสอบเกลียวแบบหลายเธรด | การทดสอบเธรดเป็นกลยุทธ์แบบค่อยเป็นค่อยไปอย่างหนึ่งภายในนั้น |
ในระยะสั้น การทดสอบการทำงานพร้อมกัน การทดสอบแบบมัลติเธรดถามว่าการเข้าถึงพร้อมกันส่งผลต่อระบบอย่างไร ในขณะที่การทดสอบแบบมัลติเธรดถามว่าเส้นทางสำคัญเส้นใดเส้นหนึ่งจะยังคงใช้งานได้หลังจากการรวมระบบหรือไม่ ทีมที่ดำเนินการทั้งสองอย่างมักจะกำหนดให้ทำการทดสอบแบบมัลติเธรดก่อน
ข้อดีของการทดสอบเกลียว
เทคนิคนี้เหมาะสมที่จะนำมาใช้ในแผนการบูรณาการด้วยเหตุผลเชิงปฏิบัติหลายประการ
- เส้นทางธุรกิจที่สำคัญจะได้รับการตรวจสอบตั้งแต่เนิ่นๆ เพื่อให้สามารถตรวจพบปัญหาการส่งต่อข้อมูลที่ไม่ราบรื่นก่อนที่จะประกอบระบบทั้งหมดเสร็จสมบูรณ์
- ผู้บูรณาการจะได้รับภาพที่ชัดเจนเกี่ยวกับขอบเขตงาน เนื่องจากหน่วยทดสอบเป็นธุรกรรมที่สามารถระบุได้ ไม่ใช่สิ่งที่เป็นนามธรรมtracขอบเขตส่วนประกอบ t
- การทดสอบเส้นทางการดำเนินการเชิงตรรกะในบริบทของระบบจะเปิดเผยข้อผิดพลาดที่แยกออกมา การทดสอบส่วนประกอบ ไม่สามารถมองเห็นได้
- การทำงานแบบมัลติเธรดเผยให้เห็นข้อบกพร่องด้านการทำงานพร้อมกัน เช่น การติดตาย การแข่งขันของเงื่อนไข และความขัดแย้งด้านทรัพยากร ซึ่งหากไม่เช่นนั้น ข้อบกพร่องเหล่านี้ก็จะส่งผลกระทบต่อการใช้งานจริง
- การรวมระบบแบบเพิ่มทีละน้อยช่วยลดพื้นที่การดีบักให้เหลือน้อยที่สุด เนื่องจากมีการเพิ่มเธรดเพียงครั้งละหนึ่งเธรดเท่านั้น
- ผลลัพธ์ที่ได้จะส่งผลโดยตรงต่อ... การทดสอบการถดถอยเนื่องจากเธรดที่ผ่านไปนั้นถือเป็นตัวเลือกที่ชัดเจนสำหรับชุดทดสอบการถดถอย
ข้อเสียของการทดสอบเธรด
- สำหรับการทดสอบแบบมัลติเธรด ความท้าทายที่ใหญ่ที่สุดคือการเขียนโปรแกรมทดสอบที่สามารถทำซ้ำได้สำหรับการทดสอบหน่วย
- การเขียน Unit Test สำหรับโค้ดแบบ Multithreading เป็นงานที่ท้าทายมาก
- เกณฑ์การทดสอบสำหรับระบบมัลติเธรดแตกต่างจากการทดสอบแบบเธรดเดียว สำหรับการทดสอบแบบมัลติเธรด ปัจจัยต่างๆ เช่น ขนาดหน่วยความจำ ความจุในการจัดเก็บ และปัญหาเรื่องจังหวะเวลา จะแตกต่างกันไปเมื่อเรียกใช้โค้ดบนฮาร์ดแวร์ที่แตกต่างกัน
- ไม่สามารถทดสอบเธรดได้จนกว่าโมดูลที่เกี่ยวข้องจะพร้อมใช้งาน ดังนั้นการจัดตารางเวลาจึงขึ้นอยู่กับลำดับการรวมระบบ
- ความล้มเหลวเป็นระยะๆ มักถูกมองข้ามว่าเป็นเพียงสัญญาณรบกวนจากสภาพแวดล้อม ซึ่งทำให้การบันทึกข้อมูลอย่างเป็นระบบมีความสำคัญอย่างยิ่ง
