การทดสอบซอฟต์แวร์แบบไม่ทำลาย (NDT): กลยุทธ์การทดสอบคืออะไร

การทดสอบซอฟต์แวร์แบบไม่ทำลายคืออะไร?

การทดสอบแบบไม่ทำลาย เป็นประเภทการทดสอบซอฟต์แวร์ที่เกี่ยวข้องกับการทดสอบและการโต้ตอบกับแอปพลิเคชันซอฟต์แวร์อย่างถูกต้อง กล่าวอีกนัยหนึ่ง การทดสอบซอฟต์แวร์แบบไม่ทำลาย (NDT) ยังสามารถเรียกว่าการทดสอบเชิงบวกหรือการทดสอบเส้นทางที่มีความสุข ให้ผลลัพธ์ที่คาดหวังและพิสูจน์ว่าแอปพลิเคชันซอฟต์แวร์ทำงานตามที่คาดไว้

ชื่อนี้มีที่มาจากวิศวกรรมศาสตร์ ซึ่งการทดสอบแบบไม่ทำลาย (Non-Destructive Testing) คือการตรวจสอบชิ้นส่วนทางกายภาพโดยไม่ทำให้ชิ้นส่วนนั้นเสียหาย ในด้านซอฟต์แวร์ก็มีแนวคิดเดียวกัน คือ แอปพลิเคชันถูกใช้งานตามที่ออกแบบไว้ และผ่านการทดสอบโดยที่ยังคงสภาพสมบูรณ์

ตัวอย่าง: ป้อนข้อมูลที่ถูกต้องลงในโมดูลการเข้าสู่ระบบ และตรวจสอบว่าระบบยอมรับข้อมูลประจำตัวและนำไปยังหน้าถัดไปหรือไม่

ภาพหน้าจอด้านล่างแสดงแบบฟอร์มล็อกอิน โดยมีค่าที่ถูกต้องพิมพ์อยู่ในช่องชื่อผู้ใช้ก่อนที่จะทำการทดสอบ

ในการทดสอบแบบไม่ทำลายในตัวอย่างข้างต้น ให้ป้อนชื่อผู้ใช้และรหัสผ่านที่ถูกต้องลงในแบบฟอร์มล็อกอิน เนื่องจากข้อมูลที่ป้อนตรงกับข้อกำหนด ผลลัพธ์ที่ต้องการจึงเป็นไปในทางบวก และผู้ทดสอบเพียงแค่ยืนยันว่าแอปพลิเคชันสามารถไปยังหน้าถัดไปได้

เหตุใดจึงต้องทดสอบซอฟต์แวร์แบบไม่ทำลาย (NDT)

การทดสอบแบบไม่ทำลาย (Non-destructive testing) ตอบคำถามแรกที่ผู้เกี่ยวข้องทุกคนถามเกี่ยวกับการสร้างซอฟต์แวร์: ฟีเจอร์นั้นทำงานได้ตามที่ต้องการจริงหรือไม่? นี่คือเหตุผลที่ทีมต่างๆ ใช้การทดสอบนี้

• ข้อดีหลักของวิธีการตรวจสอบแบบไม่ทำลาย (NDT) คือช่วยปรับปรุงคุณภาพซอฟต์แวร์ เนื่องจากข้อบกพร่องที่พบในขั้นตอนการทำงานหลักจะได้รับการแก้ไขตั้งแต่เนิ่นๆ
• เพื่อแสดงให้เห็นว่าฟังก์ชั่นซอฟต์แวร์ทำงานตามข้อกำหนด
• เพื่อตรวจสอบว่าข้อกำหนดด้านประสิทธิภาพได้รับการปฏิบัติตามแล้ว
• เพื่อตรวจสอบว่าตรงตามความต้องการของผู้ใช้ปลายทางหรือไม่
• เพื่อตรวจสอบว่าส่วนเล็กๆ ของโค้ดหรือฟังก์ชันการทำงานนั้นทำงานได้ตามที่คาดหวังและไม่ทำให้ฟังก์ชันการทำงานที่เกี่ยวข้องเสียหาย
• เพื่อสร้างหลักฐานที่สามารถนำมาแสดงได้ที่ การทดสอบการยอมรับของผู้ใช้ การอนุมัติขั้นสุดท้าย ซึ่งลูกค้าต้องการเห็นพฤติกรรมที่คาดหวังไว้มากกว่ารูปแบบความล้มเหลว

เมื่อทำการทดสอบแบบไม่ทำลาย (NDT) แล้ว?

จังหวะเวลาเป็นสิ่งสำคัญมากกว่าเทคนิคอื่นๆ ส่วนใหญ่ เพราะเส้นทางที่ราบรื่นจะควบคุมทุกอย่างในขั้นตอนถัดไป

• เป็นการทดสอบรูปแบบแรกที่ผู้ทดสอบจะดำเนินการกับแอปพลิเคชัน กล่าวคือ ในขั้นตอนเริ่มต้นของการทดสอบ SDLC.
• การทดสอบแบบไม่ทำลายมักใช้ในกรณีที่ไม่มีเวลาเพียงพอสำหรับวงจรการทดสอบเต็มรูปแบบ เนื่องจากยังสามารถพิสูจน์ได้ว่าตรงตามเกณฑ์การยอมรับ
• การทดสอบนี้จะทำงานก่อนสถานการณ์เชิงลบและสถานการณ์ที่ก่อให้เกิดความเสียหาย หากกระบวนการหลักหยุดชะงัก การทดสอบการจัดการข้อผิดพลาดจะรายงานสิ่งผิดปกติแทนที่จะเป็นข้อบกพร่องที่แท้จริง
• ขั้นตอนนี้จะถูกทำซ้ำหลังจากแก้ไขข้อบกพร่องทุกครั้ง ซึ่งเป็นส่วนที่ทับซ้อนกันกับ การทดสอบการถดถอย.

กลยุทธ์การทดสอบสำหรับการทดสอบแบบไม่ทำลาย

กลยุทธ์สำหรับการทดสอบแบบไม่ทำลายนั้นเรียบง่ายอย่างจงใจ และหัวใจสำคัญอยู่ที่การมองโลกในแง่ดีมากกว่าการเลือกใช้เครื่องมือ

• แนวทางการทดสอบแบบไม่ทำลายควรเป็นไปในเชิงบวก
• จุดประสงค์ของเทคนิค NDT คือการพิสูจน์ว่าแอปพลิเคชันจะทำงานได้เมื่อได้รับข้อมูลป้อนเข้าที่ถูกต้อง
• การทดสอบแบบไม่ทำลายไม่จำเป็นต้องมีข้อกำหนดหรือสภาพแวดล้อมพิเศษใดๆ
• หลักปฏิบัติที่ดีที่สุดสำหรับการทดสอบแบบไม่ทำลายคือการตรวจสอบว่าระบบทำงานได้ตามที่ควรจะเป็นหรือไม่

แผนภาพด้านล่างสรุปวิธีการจัดระเบียบกลยุทธ์ดังกล่าวโดยปกติในระหว่างรอบการทดสอบ

วิธีการเขียนกรณีทดสอบแบบไม่ทำลาย (เชิงบวก)

กรณีทดสอบที่ไม่ทำลายล้างจะมีประโยชน์ก็ต่อเมื่อข้อมูลป้อนเข้ามีความถูกต้องที่พิสูจน์ได้ และผลลัพธ์ที่คาดหวังมาจากข้อกำหนด ไม่ใช่จากสมมติฐานของผู้ทดสอบ ขั้นตอนต่อไปนี้จะสร้างกรณีทดสอบประเภทนั้น กรณีทดสอบ.

ขั้นตอนที่ 1) เลือกเกณฑ์การยอมรับหนึ่งข้อ อ่านข้อกำหนดและเรียบเรียงใหม่เป็นข้อความที่ตรวจสอบได้เพียงประโยคเดียว ตัวอย่างเช่น “ช่องชื่อผู้ใช้รับอักขระตัวอักษรและตัวเลขได้หกถึงยี่สิบตัว”

ขั้นตอนที่ 2) เลือกข้อมูลป้อนเข้าที่ถูกต้อง เลือกค่าที่อยู่ในช่วงที่อนุญาตอย่างเหมาะสม การแบ่งส่วนความเท่าเทียมกัน ช่วยได้ตรงนี้ — โดยปกติแล้วค่าตัวแทนเพียงค่าเดียวต่อพาร์ติชันที่ถูกต้องก็เพียงพอแล้ว

ขั้นตอนที่ 3) เขียนผลลัพธ์ที่คาดหวังก่อนดำเนินการ ผลลัพธ์ที่คาดหวังจะต้องเขียนจากข้อกำหนด การเขียนหลังจากที่รันเสร็จแล้วจะทำให้การทดสอบกลายเป็นคำอธิบายว่ากระบวนการสร้างนั้นได้ทำอะไรไปบ้าง

ขั้นตอนที่ 4) เรียงลำดับขั้นตอนตามลำดับการใช้งาน ลำดับขั้นตอนควรตรงกับวิธีที่ผู้ใช้จริงจะทำภารกิจให้สำเร็จ เพราะจุดประสงค์ของเทคนิคนี้คือการยืนยันเส้นทางการใช้งานที่ตั้งใจไว้

ขั้นตอนที่ 5) บันทึกรหัสระบุข้อกำหนด Tracการนำกรณีดังกล่าวกลับไปสู่เกณฑ์ที่กำหนดไว้ คือสิ่งที่ช่วยให้ทีมสามารถพิสูจน์ความครอบคลุมในระหว่างการตรวจสอบได้

ตัวอย่างการใช้งานโมดูลการเข้าสู่ระบบมีลักษณะดังนี้

โปรดสังเกตว่าไม่มีสิ่งใดในกรณีนี้พยายามทำลายฟิลด์ กรณีที่ป้อนอักขระห้าตัวเพื่อดูข้อความแสดงข้อผิดพลาดคือ... ผลตรวจเป็นลบไม่ใช่แบบที่ไม่ก่อให้เกิดความเสียหาย

ตัวอย่างการทดสอบแบบไม่ทำลาย

ตัวอย่างด้านล่างแสดงให้เห็นว่าการทดสอบแบบไม่ทำลายทำงานอย่างไรกับแอปพลิเคชันแบบหลายโมดูลหลังจากที่แก้ไขข้อบกพร่องแล้ว

• แอปพลิเคชันนี้ประกอบด้วยห้าโมดูล ได้แก่ หน้าเข้าสู่ระบบ หน้าหลัก หน้าแสดงรายละเอียดผู้ใช้ การสร้างผู้ใช้ใหม่ และการสร้างงาน
• สมมติว่ามีข้อผิดพลาดในหน้าล็อกอิน: ช่องชื่อผู้ใช้รับอักขระตัวอักษรและตัวเลขได้น้อยกว่าหกตัว ซึ่งขัดกับข้อกำหนดที่ระบุว่าชื่อผู้ใช้ต้องไม่น้อยกว่าหกตัว ดังนั้นพฤติกรรมนี้จึงถือเป็นข้อบกพร่อง
• ข้อผิดพลาดดังกล่าวจะถูกรายงานไปยังทีมพัฒนาผ่านช่องทางปกติ กระบวนการจัดการข้อบกพร่องปัญหาได้รับการแก้ไขแล้ว และเวอร์ชันที่สร้างขึ้นจะถูกส่งกลับไปยังทีมทดสอบ
• ทีมทดสอบไม่เพียงตรวจสอบหน้าล็อกอินที่แก้ไขข้อบกพร่องแล้วเท่านั้น แต่ยังทดสอบโมดูลอื่นๆ ด้วย ในระหว่างการทดสอบโมดูลทั้งหมดด้วยข้อมูลที่ถูกต้อง ทีมจะทำการทดสอบแบบไม่ทำลาย เพื่อยืนยันว่าแอปพลิเคชันทั้งหมดยังคงทำงานได้อย่างถูกต้อง

การทดสอบแบบไม่ทำลายเทียบกับการทดสอบแบบทำลาย

เทคนิคทั้งสองมักถูกสอนควบคู่กัน เพราะให้คำตอบที่ตรงกันข้ามกับคำถามเกี่ยวกับการสร้างสิ่งเดียวกัน การทดสอบแบบทำลายล้าง การทดสอบแบบทำลายล้างจะมองหาจุดที่ซอฟต์แวร์เกิดข้อผิดพลาด ในขณะที่การทดสอบแบบไม่ทำลายล้างจะยืนยันว่าพฤติกรรมที่ตั้งใจไว้ยังคงเป็นไปตามนั้น

ทั้งสองอย่างเป็นส่วนเสริมกัน ไม่ใช่ทางเลือกอื่น การทดสอบแบบไม่ทำลายเพียงอย่างเดียวทำให้ไม่สามารถตรวจสอบการจัดการข้อผิดพลาดได้ และการทดสอบแบบทำลายเพียงอย่างเดียวก็ไม่สามารถพิสูจน์ได้ว่าผลิตภัณฑ์ทำงานได้ตามที่ต้องการ

ข้อดีและข้อจำกัดของการทดสอบซอฟต์แวร์แบบไม่ทำลาย

การรู้ว่าเทคนิคดังกล่าวเริ่มใช้ไม่ได้ผลในจุดใดนั้นสำคัญพอๆ กับการรู้ว่าเทคนิคนั้นครอบคลุมอะไรบ้าง

ข้อดี

• ออกแบบและดำเนินการได้รวดเร็ว เนื่องจากข้อมูลทดสอบมาจากข้อกำหนดโดยตรง
• ไม่จำเป็นต้องใช้สภาพแวดล้อมพิเศษ การจำลองข้อผิดพลาด หรือชุดข้อมูลที่เสียหาย
• สร้างหลักฐานที่ตรงกับข้อกำหนดแบบหนึ่งต่อหนึ่ง ซึ่งเหมาะสมกับการตรวจสอบและการอนุมัติ
• ใช้งานได้ดีพอๆ กัน การทดสอบด้วยตนเอง และตามที่เขียนบทไว้ การทดสอบอัตโนมัติดังนั้นจึงสามารถนำกรณีเดียวกันมาใช้ซ้ำในชุดทดสอบการถดถอยได้
• ให้สัญญาณที่ชัดเจนและตรงไปตรงมาเกี่ยวกับความสมบูรณ์ของสิ่งก่อสร้างในทุกระดับ ตั้งแต่ระดับหน่วยไปจนถึงระดับอื่นๆ การทดสอบการรวม ไปยัง การทดสอบระบบ.

ข้อ จำกัด

• การทดสอบแบบเต็มรูปแบบไม่ได้บอกอะไรเกี่ยวกับพฤติกรรมของแอปพลิเคชันเมื่อได้รับข้อมูลที่ไม่ถูกต้อง ดังนั้นข้อบกพร่องร้ายแรงในการจัดการข้อผิดพลาดจึงอาจยังคงปรากฏให้เห็นได้
• ขอบเขตของการทดสอบขึ้นอยู่กับคุณภาพของข้อกำหนด สิ่งใดที่ไม่ระบุไว้จะไม่ได้รับการทดสอบ
• การใช้แนวทางที่ราบรื่นเพียงอย่างเดียวในการดำเนินการก่อนการปล่อยเวอร์ชันใหม่ อาจทำให้เกิดความมั่นใจที่ผิดพลาดได้
• เครื่องมือนี้ไม่ได้วัดความทนทาน การฟื้นตัว หรือประสิทธิภาพภายใต้สภาวะกดดัน ซึ่งต้องใช้เทคนิคเฉพาะจากชุดเทคนิคที่กว้างกว่า ประเภทของการทดสอบซอฟต์แวร์.

ให้ถือว่าการทดสอบแบบไม่ทำลายเป็นพื้นฐานที่เทคนิคอื่นๆ ทุกชนิดจะต่อยอด และกำหนดตารางการทดสอบนี้ไว้ในแผนงานที่ครอบคลุมกว่า วงจรชีวิตการทดสอบซอฟต์แวร์ แทนที่จะเป็นกิจกรรมที่ทำเพียงครั้งเดียว

คำถามที่พบบ่อย