การทดสอบแบบทำลายล้างในซอฟต์แวร์คืออะไร?
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
การทดสอบแบบทำลายล้างจงใจผลักดันแอปพลิเคชันซอฟต์แวร์จนกว่าจะล้มเหลว เพื่อเปิดเผยจุดที่ความทนทานของระบบพังทลายลงภายใต้การใช้งานที่ไม่เหมาะสม การป้อนข้อมูลที่ไม่ถูกต้อง และพฤติกรรมที่ไม่สามารถคาดเดาได้ ซึ่งการตรวจสอบการทำงานแบบปกติไม่สามารถเข้าถึงได้
การทดสอบแบบทำลายล้างคืออะไร?
การทดสอบแบบทำลายล้าง การทดสอบแบบทำลายล้าง (Destructive Testing) เป็นวิธีการทดสอบซอฟต์แวร์ที่ใช้ในการค้นหาจุดบกพร่องในโปรแกรมซอฟต์แวร์ ในเทคนิคนี้ แอปพลิเคชันจะถูกทำให้ล้มเหลวโดยเจตนา เพื่อตรวจสอบความแข็งแกร่งและระบุจุดบกพร่อง แตกต่างจากวิธีการทดสอบที่ตรวจสอบว่าแอปพลิเคชันควรทำงานอย่างไร การทดสอบแบบทำลายล้างจะตรวจสอบพฤติกรรมของผู้ใช้ที่ไม่สามารถคาดเดาได้ภายในแอปพลิเคชัน
ความรู้เกี่ยวกับข้อกำหนดดั้งเดิมไม่จำเป็นสำหรับการทดสอบแบบทำลายล้าง อย่างไรก็ตาม ความรู้บางอย่างจะช่วยในการพัฒนาได้ping กลยุทธ์การทดสอบที่ดี
ภาพประกอบด้านล่างแสดงให้เห็นถึงแนวคิดนี้ — ผู้ทดสอบทำงานโดยขัดแย้งกับผลิตภัณฑ์ แทนที่จะทำงานร่วมกับผลิตภัณฑ์
เหตุใดจึงต้องทำการทดสอบแบบทำลายล้าง?
- การเข้าใจพฤติกรรมที่คาดการณ์ได้ของซอฟต์แวร์เมื่อถูกใช้งานอย่างไม่เหมาะสมนั้นเป็นสิ่งสำคัญ
- ช่วยตรวจสอบความทนทานของผลิตภัณฑ์ซอฟต์แวร์
- มันช่วยเปิดเผยข้อบกพร่องหายากที่ผู้ใช้ทั่วไปไม่เคยพบเจอ แต่จะปรากฏขึ้นในภายหลังระหว่างการผลิต
การทดสอบแบบทำลายเทียบกับการทดสอบแบบไม่ทำลาย
ทั้งสองแนวทางนี้เป็นส่วนเสริมซึ่งกันและกัน ไม่ใช่คู่แข่งกัน การทดสอบแบบไม่ทำลาย — หรือที่เรียกว่าการทดสอบเชิงบวกหรือการทดสอบเส้นทางที่ราบรื่น — จะทำงานร่วมกับซอฟต์แวร์อย่างถูกต้องและทำให้ระบบยังคงสภาพเดิม การทดสอบแบบทำลายล้างจะทำตรงกันข้าม คือป้อนข้อมูลที่ไม่ถูกต้องและลำดับการทำงานที่ผิดพลาดเข้าไปเรื่อยๆ จนกว่าจะมีบางอย่างเสียหาย
| แง่มุม | การทดสอบแบบทำลายล้าง | การทดสอบแบบไม่ทำลาย |
| เจตนา | บังคับให้แอปพลิเคชันล้มเหลว | ตรวจสอบว่าแอปพลิเคชันทำงานได้ตามที่ระบุไว้ |
| อินพุตที่ใช้ | ไม่ถูกต้อง ผิดรูป เกินขอบเขต ผิดลำดับ | ข้อมูลถูกต้อง อยู่ในช่วงที่คาดไว้ |
| คำถามได้รับคำตอบแล้ว | มันพังตรงไหนและอย่างไร? | มันทำงานได้ตามที่ควรจะเป็นหรือไม่? |
| ความรู้ที่จำเป็น | สามารถเลือกหรือไม่เลือกก็ได้ | สำคัญ |
| ค่าใช้จ่ายทั่วไป | ระดับสูง — เน้นการสำรวจและเปิดกว้าง | ต่ำกว่า — มีสคริปต์และสามารถทำซ้ำได้ |
| ผล | จุดล้มเหลว ขีดจำกัดช่วง การฟื้นตัว | ผ่านหรือไม่ผ่านตามข้อกำหนด |
ในการทดสอบแบบทำลาย คุณตรวจสอบอะไรบ้าง?
การทดสอบแบบทำลายล้างจะพิจารณาทั้งสองด้านของขอบเขตพฤติกรรม:
- พฤติกรรมซอฟต์แวร์ที่เหมาะสม
- พฤติกรรมซอฟต์แวร์ที่ไม่เหมาะสม
- การใช้งานที่ไม่เหมาะสม
- ข้อมูลอินพุตไม่ถูกต้อง
- ข้อมูลเอาต์พุตที่เหมาะสม
ตลอดการดำเนินการต้องมีเงื่อนไขสองประการดังนี้:
- ซอฟต์แวร์จะไม่ประมวลผลหรือยอมรับข้อมูลป้อนเข้าที่ไม่ถูกต้องโดยเด็ดขาด
- ไม่ว่าข้อมูลที่ป้อนเข้ามาจะถูกต้องหรือแม่นยำเพียงใด ซอฟต์แวร์ก็ควรสร้างข้อมูลผลลัพธ์ที่ถูกต้องเสมอ
การทดสอบแบบทำลายล้างทำอย่างไร?
การทดสอบแบบทำลายล้างนั้นเกี่ยวข้องกับกิจกรรมหลายอย่าง เช่น การออกแบบชุดสคริปต์ทดสอบ การเรียกใช้สคริปต์เหล่านั้น การแจ้งข้อบกพร่อง การปิดข้อบกพร่อง และการให้ผลการทดสอบว่าผ่านหรือไม่ผ่านแก่ผู้มีส่วนได้ส่วนเสียเมื่อสิ้นสุดรอบการทำงาน
มีวิธีการใช้งานมากมาย ตัวอย่างบางส่วนมีดังต่อไปนี้
- วิธีการวิเคราะห์จุดล้มเหลว: การตรวจสอบระบบโดยละเอียดเพื่อประเมินว่าอะไรอาจผิดพลาดได้ในจุดต่างๆ ความช่วยเหลือจากผู้เชี่ยวชาญ นักวิเคราะห์ธุรกิจ อาจนำกลยุทธ์นี้ไปใช้ก็ได้
- การตรวจสอบโดยผู้ทดสอบ: รับของคุณ กรณีทดสอบ ได้รับการวิเคราะห์หรือตรวจสอบโดยผู้ทดสอบรายอื่นที่ไม่คุ้นเคยกับระบบหรือฟังก์ชันนั้นมากนัก
- การตรวจสอบกรณีทดสอบทางธุรกิจ: ผู้ใช้งานขั้นสุดท้ายหรือผู้เชี่ยวชาญมักนึกถึงสถานการณ์ที่เป็นไปได้หลายอย่างที่ผู้ทดสอบมองข้ามไป เพราะผู้ทดสอบมุ่งเน้นไปที่ข้อกำหนดที่ระบุไว้เป็นหลัก
- ดำเนินการทดสอบเชิงสำรวจโดยใช้เอกสารบันทึกการทำงาน: การทดสอบเชิงสำรวจ เอกสารบันทึกการทดสอบจะระบุสิ่งที่ได้รับการทดสอบ ช่วยให้สามารถทำการทดสอบซ้ำได้ และควบคุมขอบเขตของการทดสอบให้อยู่ในระดับที่เหมาะสม
- ใช้แหล่งข้อมูลอื่น: ขอให้คนอื่นทำการทดสอบซอฟต์แวร์และวิเคราะห์สถานการณ์ที่พบ
ตัวอย่างการทดสอบแบบทำลายล้าง
ลองพิจารณาหน้าจอเข้าสู่ระบบและโปรไฟล์ของแอปพลิเคชันธนาคาร รหัสผ่านทำลายล้างจะใช้งานได้กับกรณีต่างๆ เช่นนี้:
- ลองวางข้อความยาว 5,000 ตัวอักษรลงในช่องที่จำกัดไว้เพียง 50 ตัวอักษร แล้วตรวจสอบว่าช่องนั้นปฏิเสธข้อความดังกล่าวแทนที่จะตัดทอนโดยไม่แจ้งให้ทราบล่วงหน้าหรือไม่
- ป้อนตัวอักษร สัญลักษณ์ และค่าลบลงในช่องป้อนตัวเลข
- ทำลายลำดับขั้นตอนที่คาดไว้ — เปิดหน้ายืนยันการชำระเงินโดยตรงโดยไม่ต้องทำขั้นตอนก่อนหน้าให้เสร็จสิ้น
- กดปุ่มส่งซ้ำๆ อย่างรวดเร็วเพื่อตรวจสอบว่ามีการสร้างข้อมูลซ้ำหรือไม่
- ตัดการเชื่อมต่อเครือข่ายระหว่างการทำธุรกรรม และตรวจสอบว่าแอปพลิเคชันสามารถกู้คืนได้อย่างราบรื่นหรือทิ้งร่องรอยไว้บางส่วน
แต่ละกรณีมีข้อกำหนดที่ชัดเจน ได้แก่ ข้อความยืนยันที่ชัดเจน ข้อมูลไม่เสียหาย และไม่มีข้อผิดพลาดที่ไม่ได้จัดการ สิ่งอื่นใดนอกเหนือจากนี้ถือเป็นจุดบกพร่องที่ควรแจ้งเป็นข้อบกพร่อง
วิธีการทดสอบแบบทำลายล้าง
วิธีการต่อไปนี้ถูกนำมาใช้ในวิศวกรรมซอฟต์แวร์เพื่อบรรลุเป้าหมายของการทดสอบแบบทำลายล้าง:
- การทดสอบอัลฟ่า/เบต้า
- การทดสอบการถดถอย
- การทดสอบอินเทอร์เฟซ
- การแบ่งส่วนความเท่าเทียมกัน
- การทดสอบลูป
- การทดสอบการยอมรับ และอื่นๆ
เทคนิคการทดสอบแบบทำลายล้าง
เทคนิคด้านล่างนี้สามารถนำไปปรับใช้ได้ โดยอาจต้องปรับเปลี่ยนบ้าง:
- การทดสอบกล่องสีขาว
- การทดสอบความปลอดภัย
- การทดสอบข้อบกพร่อง
- การทดสอบควันและอื่น ๆ
เทคนิคเสริมที่น่าสนใจเมื่อเป้าหมายคือความทนทาน ได้แก่ การทดสอบเชิงลบ, ทดสอบความเครียด, การทดสอบการกู้คืน และ การทดสอบคลุมเครือ.
ข้อดีและข้อเสียของการทดสอบแบบทำลายล้าง
ควรชี้แจงข้อดีข้อเสียให้ชัดเจนก่อนที่จะนำเทคนิคนี้ไปวางแผนใช้ในเวอร์ชันที่จะวางจำหน่าย
ข้อดี
- Revระบุจุดบกพร่องที่การทดสอบตามข้อกำหนดไม่สามารถเข้าถึงได้
- กำหนดขอบเขตระยะการใช้งานที่แท้จริง เพื่อให้สามารถใช้งานผลิตภัณฑ์ภายในขอบเขตเหล่านั้นได้อย่างมั่นใจ
- เผยให้เห็นข้อบกพร่องที่หายากซึ่งปรากฏขึ้นในกระบวนการผลิตหลังจากวางจำหน่ายไปนานแล้ว
- ตรวจสอบความทนทาน ความสามารถในการกู้คืน และการจัดการข้อผิดพลาดภายใต้สภาวะการใช้งานที่ไม่เหมาะสม
ข้อเสีย
- โดยธรรมชาติแล้วเป็นสิ่งที่ไม่แน่นอน ดังนั้นจึงไม่สามารถรับประกันหรือวัดขอบเขตความคุ้มครองได้อย่างง่ายดาย
- ใช้เวลานานและขึ้นอยู่กับประสบการณ์และความคิดสร้างสรรค์ของผู้ทดสอบ
- การทำซ้ำผลลัพธ์อาจทำได้ยากหากไม่มีการบันทึกขั้นตอนที่ใช้ไว้อย่างละเอียดถี่ถ้วน
- การทดสอบที่ควบคุมไม่ดีอาจทำให้ข้อมูลทดสอบที่ใช้ร่วมกันเสียหายได้ ดังนั้นจึงจำเป็นต้องมีสภาพแวดล้อมที่แยกต่างหาก
