บทที่ 13 กลยุทธ์การทดสอบซอฟต์แวร์ (TESTING STRATEGIES)

บทที่ 13 กลยุทธ์การทดสอบซอฟต์แวร์ 13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.2 ประเด็นเรื่องกลยุทธ์การทดสอบ (Strategic Issues) 13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.4 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์เชิงวัตถุ (Test Strategies for Object-Oriented Software)

บทที่ 13 กลยุทธ์การทดสอบซอฟต์แวร์ 13.5 การทดสอบการตรวจรับ (Validation Testing) 13.6 การทดสอบระบบ (System Testing) 13.7 ศิลปะแห่งการค้นหาจุดบกพร่อง (The a Art of debugging) 13.8 สรุปท้ายบท

แนวคิดที่สำคัญ (Key Concepts) การทดสอบอัลฟ่า เบต้า Alpha/beta testing การดีบั๊ก/การค้านหาสาเหตุของจุดบกพร่อง Debugging เกณฑ์เสร็จสิ้น Completing criteria กลยุทธ์แบบดั้งเดิม Conventional strategy การทดสอบระดับบูรณาการ Integrating testing กลุ่มนักทดสอบอิสระ Independent Test Group (ITG) กลยุทธ์เชิงวัตถุ OO Strategy การทดสอบเชิงถดถอย Regression testing การทดสอบสโมค Smoke testing การทดสอบระบบ System testing ข้อกำหนดการทดสอบ Test specification การทดสอบระดับหน่วย Unit testing วี & วี V & V การทดสอบการตรวจรับ Validation testing

“การทดสอบเป็นกระบวนการอันเป็นเอกเทศ และมีความหลากหลายเช่นเดียวกับแนวทางการพัฒนาระบบอันหลากหลาย หลายๆ ปีที่ผ่านมา เครื่องมือป้องกันความผิดพลาดของโปรแกรมที่เรามีอยู่ ก็มีเพียงการออกแบบอย่างระมัดระวังและอาศัยความฉลาดแต่กำเนิดของโปรแกรมเมอร์เท่านั้น แต่ในยุคปัจจุบันที่เทคนิคการออกแบบสมัยใหม่ได้ช่วยให้เราลดข้อผิดพลาดเบื้องต้นที่มากับโค้ด ในทำนองเดียวกันนี้วิธีการทดสอบต่างๆ ก็เริ่มที่จะรวมกลุ่มก้อนเป็นปรัชญาและแนวทางเฉพาะตัวขึ้น” Shooman

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

13.1 แนวทางการทดสอบ ซอฟต์แวร์เชิงยุทธวิธี (A STRATEGIC APPROACH TO SOFTWARE TESTING)

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) กลยุทธ์สำหรับการทดสอบทุกวิธีให้แม่แบบในการทดสอบที่มีลักษณะทั่วไป ร่วมกันดังนี้ การปฏิบัติการทดสอบให้ได้ผล ทีมซอฟต์แวร์ควรตรวจทานเอกสารทางเทคนิคอย่างเป็นทางการ การกระทำนี้จะลดข้อผิดพลาดมากก่อนเริ่มการทดสอบจริง การทดสอบจะเริ่มที่ระดับองค์ประกอบย่อยก่อนและค่อยเคลื่อนสู่การประกอบภาพรวมของระบบทั้งหมด เทคนิคที่แตกต่างกันเหมาะสมกับการทดสอบในจุดต่างๆ กันตามเวลา การทดสอบกระทำโดย ผู้พัฒนาซอฟต์แวร์กลุ่มนักทดสอบอิสระ การทดสอบและการดีบั๊กเป็นกิจกรรมที่แตกต่างกัน แต่การดีบั๊กจะต้องเป็นสิ่งที่เกิดขึ้นควบคู่กันไปกับการทดสอบ

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.1 การตรวจทานและการตรวจรับ (Verification and Validation) การทดสอบซอฟต์แวร์ เป็นส่วนประกอบหนึ่งของหัวข้อที่เรียกว่า การตรวจทานและการตรวจรับ หรือ วี แอนด์ วี (Verification and Validation) การตรวจทาน (Verification) หมายความถึง ชุดของกิจกรรมที่ประกันว่า ซอฟต์แวร์ได้ทำตามหน้าที่เฉพาะที่กำหนดขึ้น การตรวจรับ (Validation) หมายถวามถึง ชุดของกิจกรรมที่ต่างออกไป ที่ประกันว่าซอฟต์แวร์ที่สร้างขึ้นเป็นไปตามความต้องการของลูกค้า

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.1 การตรวจทานและการตรวจรับ (Verification and Validation) นิยามของ V & V รวมกิจกรรมมากมายที่อยู่ภายใต้การประกันคุณภาพซอฟต์แวร์ (Software Quality Assurance – SQA) อันรวมถึงการตรวจทานทางเทคนิคอย่างเป็นทางการ การตรวจสอบหรือการ Audit โครงการและคุณภาพของโครงการ การเฝ้าติดตามเกณฑ์ประกอบการ การจำลองสถานการณ์ การศึกษาความเป็นไปได้ การตรวจทานเอกสาร การตรวจทานฐานข้อมูล การวิเคราะห์อัลกอลิทึม การทดสอบการพัฒนา การทดสอบการใช้งาน การทดสอบคุณสมบัติ และการทดสอบการติดตั้งใช้งาน

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.1 การตรวจทานและการตรวจรับ (Verification and Validation) การทดสอบเป็นปราการด่านสุดท้ายที่ประเมินคุณภาพและค้นพบข้อผิดพลาด แต่การทดสอบไม่ใช่เครื่องรับประกันความปลอดภัย การตรวจทานด้านเทคนิคอย่างเป็นทางการ การจัดการที่เข้มแข็งและการวัดผลทั้งหลายที่นำไปสู่คุณภาพ สิ่งเหล่านี้อาจพิสูจน์ยืนยันได้ระหว่างขั้นตอนการทดสอบ

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.2 การจัดระเบียบการทดสอบซอฟต์แวร์ (Organizing for Software Testing) มีความเข้าใจผิดพลาดที่ควรกล่าวถึงอยู่ คือ นักพัฒนาซอฟต์แวร์ไม่ควรทำการทดสอบ ซอฟต์แวร์ควรจะส่งมอบให้กับคนแปลกหน้าที่จะทดสอบอย่างไม่ปรานี นักทดสอบมาเกี่ยวข้องกับโครงการเมื่อขั้นตอนการทดสอบกำลังจะเริ่มขึ้น คำกล่าวทั้งหมดเป็นคำกล่าวที่ไม่ถูกต้อง

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.2 การจัดระเบียบการทดสอบซอฟต์แวร์ (Organizing for Software Testing) นักพัฒนาการซอฟต์แวร์ต้องรับผิดชอบในการทดสอบหน่วยย่อยแต่ละหน่วยที่เป็นองค์ประกอบของโปรแกรมเพื่อยืนยันว่าแต่ละองค์ประกอบทำงานตามหน้าที่หรือแสดงพฤติกรรมตามแบบที่ออกมา ในหลายๆ ครั้ง นักพัฒนาระบบทำการทดสอบระดับบูรณาการด้วย ซึ่งเป็นขั้นตอนที่นำไปสู่การประกอบสถาปัตยกรรมซอฟต์แวร์ให้สมบูรณ์ เมื่อสถาปัตยกรรมซอฟต์แวร์สมบูรณ์แล้วกลุ่มนักทดสอบอิสระจึงมาเกี่ยวข้องด้วย

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.2 การจัดระเบียบการทดสอบซอฟต์แวร์ (Organizing for Software Testing) บทบาทของกลุ่มนักทดสอบอิสระ (Independent Test Group – ITG) คือ การค้นหาปัญหาที่นักพัฒนาซอฟต์แวร์หาไม่พบ เนื่องจากมีผลประโยชน์ขัดแย้งอยู่ นอกจากนี้ ITG ได้รับค่าจ้างในการหาข้อผิดพลาด

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.2 การจัดระเบียบการทดสอบซอฟต์แวร์ (Organizing for Software Testing) อย่างไรก็ตาม วิศวกรซอฟต์แวร์ไม่ควรนำส่งโปรแกรมให้ ITG แล้วเดินจากไป แต่นักพัฒนาและ ITG ควรร่วมงานกันอย่างใกล้ชิดตลอดโครงการ เพื่อทำให้มั่นใจว่าการทดสอบทำอย่างทั่วถึง ขณะทำการทดสอบนักพัฒนาระบบควรอยู่ด้วย เพื่อแก้ไขข้อผิดพลาดที่พบ

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.2 การจัดระเบียบการทดสอบซอฟต์แวร์ (Organizing for Software Testing) ITG เป็นส่วนหนึ่งของทีมโครงการพัฒนาซอฟต์แวร์ในแง่ที่ว่ากลุ่ม ITG จะเกี่ยวข้องกับการพัฒนาระหว่างการวิเคราะห์และออกแบบ และยังอยู่ระหว่างการวางแผนและการออกข้อกำหนด กระบวนการทดสอบตลอดโครงการขนาดใหญ่ อย่างไรก็ตามในหลายๆ ครั้ง ITG ส่งรายงานกับกลุ่มประกันคุณภาพซอฟต์แวร์ ดังนั้น จึงยังคงความอิสระจากลุ่มวิศวกรซอฟต์แวร์

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.3 กลยุทธ์การทดสอบซอฟต์แวร์สำหรับสถาปัตยกรรมซอฟต์แวร์แบบดั้งเดิม (A Software Testing Strategy for Conventional Software Architectures) กระบวนการพัฒนาซอฟต์แวร์สามารถมองเป็นรูปเกลียว เริ่มแรกกำหนดบทบาทของซอฟต์แวร์ที่นำไปสู่การวิเคราะห์ความต้องการ ซึ่งเป็นขั้นตอนที่สร้างโมเดลข่าวสาร หน้าที่ พฤติกรรม เกณฑ์ประกอบการ ข้อจำกัด และเกณฑ์ตรวจรับสำหรับซอฟต์ เมื่อเคลื่อนที่ตามเกลียวเข้าไป จะมาพบการออกแบบ และสุดท้ายการโค้ด ในการพัฒนาซอฟต์แวร์คอมพิวเตอร์ เราหมุนตามเกลียวเข้าไปข้างในซึ่งมีระดับความเป็นนามธรรมลดลงเรื่อยๆ ทุกวงรอบ

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.3 กลยุทธ์การทดสอบซอฟต์แวร์สำหรับสถาปัตยกรรมซอฟต์แวร์แบบดั้งเดิม (A Software Testing Strategy for Conventional Software Architectures)

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.3 กลยุทธ์การทดสอบซอฟต์แวร์สำหรับสถาปัตยกรรมซอฟต์แวร์แบบดั้งเดิม (A Software Testing Strategy for Conventional Software Architectures) กลยุทธ์สำหรับการทดสอบซอฟต์แวร์ ก็อาจมองในบริบทของเกลียว คือการทดสอบระดับหน่วย ณ แก่นของเกลียวและน้นที่แต่ละหน่วยย่อย หรือองค์ประกอบของซอฟต์แวร์ที่อิมพลีเมนต์ใน Source Code การทดสิบเริ่มก้าวหน้าไปในทิศหมุนออกจากเกลียวไปสู่การทดสอบระดับบูรณาการที่เน้นการออกแบบและการสร้างสถาปัตยกรรมซอฟต์แวร์ หมุนอีกรอบจะพบการทดสอบการส่งมอบที่มีการตรวจรับความต้องการของระบบที่สร้างระหว่างการวิเคราะห์ระบบกับตัวซอฟต์แวร์ที่สร้างขึ้นว่าตรงกันหรือไม่ สุดท้ายก็ถึงการทดสอบระบบ

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.3 กลยุทธ์การทดสอบซอฟต์แวร์สำหรับสถาปัตยกรรมซอฟต์แวร์แบบดั้งเดิม (A Software Testing Strategy for Conventional Software Architectures) รูปที่ 13.2 ขั้นตอนการทดสอบซอฟต์แวร์

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.3 กลยุทธ์การทดสอบซอฟต์แวร์สำหรับสถาปัตยกรรมซอฟต์แวร์แบบดั้งเดิม (A Software Testing Strategy for Conventional Software Architectures) เมื่อพิจารณากระบวนการนี้เป็นขั้นตอน จะพบว่าการทดสอบมี 4 ขั้นตอนที่เรียงลำดับกัน โดยเริ่มการทดสอบเน้นที่แต่ละองค์ประกอบอิสระ เพื่อยืนยันว่าทานได้เป็นส่วนๆ จึงได้ชื่อว่า การทดสอบระดับหน่วย (Unit Testing)

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.3 กลยุทธ์การทดสอบซอฟต์แวร์สำหรับสถาปัตยกรรมซอฟต์แวร์แบบดั้งเดิม (A Software Testing Strategy for Conventional Software Architectures) การทดสอบระดับหน่วยใช้เทคนิคในการทดสอบแบบต่างๆ เป็นจำนวนมากเพื่อพยายามทำงานกับทุกเส้นทางในโครงสร้างควบคุมโปรแกรม เพื่อให้เกิดความมั่นใจว่าได้ครอบคลุมและค้นพบข้อผิดพลาดมากที่สุด

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.3 กลยุทธ์การทดสอบซอฟต์แวร์สำหรับสถาปัตยกรรมซอฟต์แวร์แบบดั้งเดิม (A Software Testing Strategy for Conventional Software Architectures) ถัดจากนั้น องค์ประกอบจะถูกเชื่อมต่อกันเป็นโปรแกรมสำเร็จรูป การทดสอบระดับบูรณาการ รับผิดชอบทวิปัญหาของการตรวจทาน (Verification) และการสร้างโปรแกรม (Program Construction) เทคนิคการออกแบบกรณีทดสอบที่เน้นข้อมูลเข้าและข้อมูลออกเป็นเทคนิคที่ทำกันมากในระดับนี้ แต่เทคนิคที่ทำงานกับโปรแกรมเฉพาะส่วนก็อาจใช้เพื่อให้ครอบคลุมเส้นทางควบคุมหลัก หลังจากที่ซอฟต์แวร์ได้ประกอบกันแล้ว การทดสอบระดับบนจึงเริ่มต้นขึ้น เกณฑ์การตรวจรับที่สร้างการวิเคราะห์ความถูกต้องจะถูกประเมิน การทดสอบการส่งมอบให้ความเชื่อมันว่าตัวซอฟต์แวร์มีหน้าที่ พฤติกรรม และเกณฑ์ประกอบการดังที่ต้องการ

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.3 กลยุทธ์การทดสอบซอฟต์แวร์สำหรับสถาปัตยกรรมซอฟต์แวร์แบบดั้งเดิม (A Software Testing Strategy for Conventional Software Architectures) การทดสอบระดับบนขั้นสุดท้าย อยู่นอกเหนือจากขอบเขตของวิศวกรรมซอฟต์แวร์ และไปอยู่ในบริบทที่กว้างกว่าของวิศวกรรมระบบคอมพิวเตอร์ การทดสอบระบบตรวจทานว่าทุกส่วนประกอบได้เชื่อมต่อกันอย่างถูกต้อง และหน้าที่รวมถึงเกณฑ์ประกอบการของระบบโดยรวมตรงตามความต้องการ

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.4 กลยุทธ์การทดสอบซอฟต์แวร์สำหรับสถาปัตยกรรมเชิงวัตถุ (A Software Testing Strategy for Object-Oriented Architectures) กลยุทธ์โดยรวมสำหรับซอฟต์แวร์เชิงวัตถุ มีปรัชญาเช่นเดียวกันกับสถาปัตยกรรมแบบดั้งเดิม แต่มีแนวทางแตกต่างกัน กล่าวคือเราจะเริ่มด้วยการทดสอบชิ้นงานขนาดเล็กก่อน จากนั้นก็เคลื่อนไปทดสอบชิ้นงานขนาดใหญ่ขึ้น แต่ชิ้นงานขนาดเล็กได้เปลี่ยนจากโมดูลแต่ละโมดูลไปเป็นคลาสที่รวมเอาคุณสมบัติและตัวกระทำการ และมีนัยถึงการติดต่อสื่อสารและการร่วมมือกันทำงานด้วย เมื่อหลายๆ คลาสรวมกันเป็นสถาปัตยกรรมเชิงวัถตุ ชุดของการทดสอบเชิงถดถอยจะทำงาน เพื่อเปิดเผยถึงข้อผิดพลาดอันเนื่องมาจากการสื่อสารและการร่วมกันทำงานระหว่างคลาสที่เป็นองค์ประกอบ รวมถึงผลข้างเคียงที่เกิดจากคลาสใหม่ๆ

13.1 แนวทางการทดสอบซอฟต์แวร์เชิงยุทธวิธี (A Strategic Approach to Software Testing) 13.1.5 เกณฑ์วัดการเสร็จสิ้นการทดสอบ (Criteria for Completion of Testing) Musa และ Ackerman แนะนำเกณฑ์วัดเชิงสถิติว่า เราไม่สามารถแน่ใจได้เต็มที่ว่า ซอฟต์แวร์จะไม่ทำงานล้มเหลว แต่เราอาจทดสอบมากเพียงพอที่จะกล่าวได้ว่ามีความมั่นใจ 95% ว่ามีความน่าจะเป็นที่การทำงาน 1000 ชั่วโมง CPU จะไม่ล้มเหลวในสิ่งแวดล้อมที่กำหนด มีอย่างน้อย 0.995 ดังนั้น แบบจำลองความล้มเหลวของซอฟต์แวร์ที่เป็นฟังก์ชั่นของเวลาการทำงาน สามารถพัฒนาขึ้นจากแบบจำลองเชิงสถิติ และทฤษฎีความน่าเชื่อถือของซอฟต์แวร์

13.2 ประเด็นเรื่องกลยุทธ์การทดสอบ (STRATEGIC ISSUES)

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

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

13.3 กลยุทธ์การทดสอบ สำหรับซอฟท์แวร์แบบดั้งเดิม (TEST STRATEGIES FOR CONVENTIONAL SOFTWARE)

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.1 การทดสอบระดับหน่วย (Unit Testing) การทดสอบระดับหน่วย เจาะจงทดสอบหน่วยที่เล็กที่สุดของงานออกแบบซอฟต์แวร์ คือ องค์ประกอบซอฟต์แวร์ (Component) หรือโมดูลซอฟต์แวร์ (Module) โดยใช้คำอธิบายประกอบการออกแบบระดับองค์ประกอบ เป็นแนวทางทดสอบเส้นทางควบคุมหลัก เพื่อค้นหาข้อผิดพลาดภายในขอบเขตของโมดูล ความซับซ้อนสัมพัทธ์ของการทดสอบและข้อผิดพลาดที่การทดสอบค้นหาได้ จะถูกจำกัดด้วยขอบเขตของการทดสอบระดับหน่วย การทดสอบระดับหน่วยเจาะจงทดสอบตรรกะ กระบวนการทำงานภายใน และโครงสร้างข้อมูลภายในขอบเขตขององค์ประกอบ การทดสอบชนิดนี้สามารถทำพร้อมๆ กันไปหลายๆ องค์ประกอบ

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.1 การทดสอบระดับหน่วย (Unit Testing) ข้อควรคำนึงถึงในการทดสอบระดับหน่วย (Unit Test Considerations) อินเตอร์เฟสโมดูลถูกทดสอบ เพื่อยืนยันการไหลของข้อมูลเข้าและออกจากโปรแกรมหน่วยที่ทดสอบอยู่ โครงสร้างข้อมูลท้องถิ่นถูกตรวจสอบเพื่อยืนยันการเก็บข้อมูลชั่วคราว ความสมบูรณ์ระหว่างขั้นตอนการทำงานของอัลกอริทึม เส้นทางอิสระพื้นฐานทุกเส้นทางที่ผ่านโครงสร้างควบคุมจะถูกใช้งานอย่างน้อยหนึ่งครั้ง เงื่อนไขขอบเขตจะถูกทดสอบเพื่อยืนยันว่าโมดูลทำงานอย่างถูกต้อง ณ เส้นขอบเขตที่จำกัดกระบวนการทำงาน สุดท้ายเส้นทางที่จัดการความผิดพลาดทุกเส้นทางจะถูกทดสอบ

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.1 การทดสอบระดับหน่วย (Unit Testing) ข้อควรคำนึงถึงในการทดสอบระดับหน่วย (Unit Test Considerations) ข้อผิดพลาดที่พบในการคำนวณบ่อยๆ ได้แก่ เข้าใจผิดหรือลำดับการคำนวณไม่ถูกต้อง การคำนวณแบบผสมหลายโหมด การให้ค่าเริ่มต้นผิดพลาด ความเที่ยงตรงไม่เพียงพอ การแทนสัญลักษณ์ของนิพจน์ไม่ถูกต้อง

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.1 การทดสอบระดับหน่วย (Unit Testing) ข้อควรคำนึงถึงในการทดสอบระดับหน่วย (Unit Test Considerations) กรณีทดสอบควรเปิดเผยข้อผิดพลาดเหล่านี้ การเปรียบเทียบชนิดข้อมูลที่แตกต่างกัน ตัวดำเนินการทางตรรกะหรือลำดับไม่ถูกต้อง การเปรียบเทียบตัวแปรไม่ถูกต้อง การจบลูปไม่ถูกต้อง การไม่ออกจากลูปเมื่อพบเส้นทางวนซ้ำอื่น การปรับปรุงค่าตัวแปรลูปไม่เหมาะสม

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.1 การทดสอบระดับหน่วย (Unit Testing) ข้อควรคำนึงถึงในการทดสอบระดับหน่วย (Unit Test Considerations) ความผิดพลาดต่อไปนี้ควรได้รับการทดสอบ คำอธิบายความผิดพลาดฟังดูแล้วไม่ได้เรื่อง คำอธิบายไม่สอดคล้องกับความผิดพลาดที่เกิดขึ้น เงื่อนไขความผิดพลาดก่อให้เกิดการทำงานของระบบปฏิบัติการก่อนการจัดการความผิดพลาด การประมวลผลเงื่อนไขยกเว้นไม่ถูกต้อง คำอธิบายความผิดพลาดไม่ให้ข้อมูลที่เพียงพอที่จะช่วยระบุตำแหน่งที่เป็นสาเหตุของความผิดพลาด

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.1 การทดสอบระดับหน่วย (Unit Testing) ขั้นตอนการทดสอบระดับหน่วย (Unit Test Procedures) เนื่องจากองค์ประกอบ (Component) ไม่ใช่ระบบที่สมบูรณ์ ดังนั้น ไดรฟ์เวอร์หรือสตับ จึงจำเป็นสำหรับการทดสอบระดับหน่วย ในแอพพลิเคชั่นส่วนใหญ่ ไดร์ฟเวอร์เป็นเพียงโปรแกรมหลักที่รับข้อมูลกรณีทดสอบ แล้วส่งผ่านข้อมูลดังกล่าวไปยังองค์ประกอบที่ถูกทดสอบอยู่ จากนั้นก็พิมพ์ผลลัพธ์ออกมาก ส่วนสตับมีเพื่อแทนที่โมดูลที่ถูกเรียกใช้งานจากโมดูลที่กำลังทดสอบอยู่ สตับคือโปรแกรมดัมมี่ (Dummy Program) ที่มีอินเตอร์เฟสหน้าตาเดียวกันกับโมดูลจริงที่จะถูกเรียกใช้งาน แต่มักไม่มีการประมวลผลข้อมูลจริงจัง มีหน้าที่เพียงตรวจทานความถูกต้องของการควบคุมข้อมูลเข้าและอกของโมดูลที่กำหลังทดสอบ

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.1 การทดสอบระดับหน่วย (Unit Testing) ขั้นตอนการทดสอบระดับหน่วย (Unit Test Procedures) ไดร์ฟเวอร์กับสตับเป็นค่าใช้จ่ายส่วนเกินที่ต้องเขียนขึ้นมา แต่ไม่ได้ส่งมอบกับผลิตภัณฑ์สุดท้าย ดังนั้น ไดร์ฟเวอร์กับสตับควรจะเรียบง่ายที่สุด เพื่อให้ค่าใช้จ่ายส่วนเกินไม่สูงมาก น่าเสียดายที่หลายๆ องค์ประกอบไม่สามาถทดสอบระดับหน่วยอย่างเพียงพอถ้าใช้วิธีการเรียบง่าย ในกรณีดังกล่าว การทดสอบที่สบบูรณ์อาจต้องเลื่อนไปอยู่ในขั้นตอนการทดสอบระดับบูรณาการ

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การทดสอบระดับบูรณาการเป็นเทคนิคอันมีระเบียบแบบแผน สำหรับการสร้างสถาปัตยกรรมซอฟต์แวร์ ขณะที่ทำการทดสอบเพื่อเปิดเผยความผิดพลาดที่แฝงมากับการอินเตอร์เฟส วัตถุประสงค์คือ นำองค์ประกอบที่ผ่านการทดสอบระดับหน่วยแล้วมาก่อเป็นโครงสร้างโปรแกรมตามที่ออกแบบไว้

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) แนวโน้มของการพยายามบูรณาการแบบบิ๊กแบง (Big Bag) เป็นสิ่งที่ไม่ถูกต้อง นั่นคือการนำเอาองค์ประกอบทั้หมดมาเชื่อมกันในครั้งเดียว แล้วทดสอบโปรแกรมทั้งหมดโดยรวม ผลลัพธ์ก็คือเกิดความยุ่งเหยิงขึ้น เมื่อพบความผิดพลาดชุดหนึ่ง การแก้ไขก็ลำบากเนื่องจากความซับซ้อนในการหาสาเหตุของความผิดพลาดจากโปรแกรมขนาดใหญ่ทั้งหมด เมื่อแก้ไขข้อผิดพลาดแล้ว ข้อผิดพลาดอันใหม่ก็ปรากฏขึ้นมาอีก วนเวียนซ้ำซากไม่รู้จบ

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การบูรณาการแบบค่อยๆ เพิ่มขึ้น (Incremental) เป็นวิธีที่ตรงข้ามกับบิ๊กแบง การสร้างและทดสอบโปรแกรมจะทำจากส่วนเล็กๆ ก่อน และค่อยๆ เพิ่มเติมขึ้นโดยลำดับ เมื่อพบข้อผิดพลาดก่ายที่จะแยกหาสาเหตุและแก้ไข ดังนั้นอินเตอร์เฟสก็มีแนวโน้มจะถูกทดสอบอย่างถี่ถ้วน และสามารถประยุกต์ใช้การทดสอบอย่างมีระเบียบแบบแผนได้ จะกล่าวถึง กลยุทธ์การทดสอบระดับบูรณาการแบบค่อยๆ เพิ่มขึ้น

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การบูรณาการแบบบนลงล่าง (Top-down Integration) โมดูลจะถูกรวมเข้ากันตามลำดับของการควบคุมจากบนลงล่าง เริ่มจากโมดูลหลัก โดยโมดูลย่อยของโมดูลหลักจะรวมเข้ากับโมดูลหลักในเชิงลึกก่อน หรือเชิงกว้างก่อนก็ได้

รูปที่ 13.5 การบรูณาการแบบลงล่าง

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การบูรณาการแบบบนลงล่าง (Top-down Integration) กระบวนการบูรณาการจะทำเสร็จใน 5 ขั้นตอน โมเดลควบคุมหลักจะถูกใช้เป็นเทสต์ไดรเวอร์ และใช้สตับแทนองค์ประกอบอื่นๆ ทุกตัวภายใต้โมดูลหลัก แทนที่สตับทีละตัวด้วยองค์ประกบจริงตามวิธีเลือกบูรณาการเชิงลึก หรือเชิงกว้าง ทำการทดสอบองค์ประกอบแต่ละส่วนที่นำมากำลังรวมกัน แต่ละรอบที่เสร็จสิ้นการทดสอบ จึงค่อยเพิ่มองค์ประกอบจริงเข้าแทนแทนสตับทีละตัว ทำการทดสอบเชิงถดถอย เพื่อให้มั่นใจว่าไม่มีความผิดพลาดใหม่ๆ เกิดขึ้นเมื่อองค์ประกอบใหม่ถูกรวม

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การบูรณาการแบบบนลงล่าง (Top-down Integration) กลยุทธ์การบูรณาการแบบบนลงล่าง ตรวจสอบความถูกต้องของจุดควบคุมหรือจุดตัดสินใจในระยะต้นของการทดสอบ โปรแกรมที่มีการวางโครงสร้างดี การตัดสินใจมักเกิดขึ้น ณ ระดับบนๆ ของลำดับชั้น ดั้งนั้นจะถูกเรียกใช้งานก่อนหน้าที่อื่นๆ ถ้ามีปัญหาเกิดกับการควบคุมหลัก การค้นพบปัญหาเป็นเรื่องจำเป็นมาก

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การบูรณาการแบบบนลงล่าง (Top-down Integration) แม้ว่ากลยุทธ์แบบบนลงล่างจะฟังดูไม่ซับซ้อนมากนัก แต่ในทางปฏิบัติก็อาจเกิดปัญหาการลำเลียงข้อมูลได้ ผู้ทดสอบอาจแก้ไขปัญหาได้ 3 ทาง คือ เลื่อนการทดสอบออกไปจนกว่าสตับจะถูกแทนที่ด้วยโมดูลจริง พัฒนาสตับที่ทำงานเลียนแบบคล้ายกับโมดูลจริงมาก ทำการทดสอบแบบล่างขึ้นบน

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การทดสอบแบบล่างขึ้นบน (Bottom-Up Integration) เราเริ่มการทดสอบจากโมดูลเดี่ยวๆ คือองค์ประกอบที่อยู่ ณ ระดับล่างสุดของโครงสร้างโปรแกรม เพราะองค์ประกอบรวมตัวกันจากระดับล่างขึ้นมา การทำงานที่จำเป็นขณะรวมกัน จึงมีให้เรียกใช้ในขณะรวมกันในระดับนั้นๆ และไม่มีความจำเป็นต้องใช้สตับ

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การทดสอบแบบล่างขึ้นบน (Bottom-Up Integration) การบูรณาการแบบล่างขึ้นบนอาจทำได้ตามขึ้นตอนต่อไปนี้ รวมองค์ประกอบล่างเข้าด้วยกันเป็นคลัสเตอร์ (Cluster) หรือบางครั้งเรียกว่าบิ้วด์ (Builds) ที่ทำหน้าที่ย่อยเฉพาะอย่าง สร้างไดร์ฟเวอร์เพื่อประสานข้อมูลเข้า-ออกของกรณีทดสอบ ทำการทดสอบคลัสเตอร์ ถอดไดรเวอร์ออกและรวมคลัสเตอร์สองตัวขึ้นไปตามโครงสร้างโปรแกรม

รูปที่ 13.6 การบูรณาการแบบขึ้นบน

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การทดสอบเชิงถดถอย (Regression Testing) การทดสอบเชิงถดถอยอาจทำโดยมนุษย์ โดยการทดสอบช้ำชุดกรณีทดสอบเดิม หรืออาจทำอัตโนมัติโดยใช้เครื่องมือบันทึกและเล่นซ้ำ (Capture/Playback tools) เครื่องมือนี้ช่วยนักวิศวกรรมซอฟต์แวร์ดักจับกรณีทดสอบ และเปรียบเทียบผลของการทดสอบเพื่อใช้ทดสอบซ้ำในคราวถัดไป

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การทดสอบเชิงถดถอย (Regression Testing) การทดสอบเชิงถดถอยประกอบด้วยกรณีทดสอบที่แตกต่างกันสามอย่าง ตัวแทนของตัวทดสอบที่จะทำงานกับทุกหน้าที่ของซอฟต์แวร์ ตัวทดสอบเพิ่มเติมมุ่งทดสอบหน้าที่ ที่อาจได้รับผลกระทบจากการเปลี่ยนแปลงสูง ตัวทดสอบที่มุ่งเจาะจงองค์ประกอบที่เพิ่งทำการเปลี่ยนแปลงไป

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การทดสอบแบบสโมค (Smoke Testing) เป็นวิธีการทดสอบระดับบูรณาการแบบหนึ่งที่นิยมใช้กันทั่วไประหว่างการพัฒนาซอฟต์แวร์ ออกแบบมาให้เป็นกลไกที่ใช้ในโครงการที่มีข้อจำกัดด้านเวลาสูง เพื่อให้ทีมงานประเมินโครงการได้บ่อยๆ

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การทดสอบแบบสโมค (Smoke Testing) การทดสอบแบบสโมคมีกิจกรรมที่สำคัญ คือ ลดความเสี่ยงเชิงบูรณาการ ผลิตภัณฑ์สุดท้ายมีคุณภาพดีขึ้น ช่วยให้การหาสาเหตุและการแก้ไขข้อผิดพลาดทำได้ง่าย การประเมินความก้าวหน้าทำได้ง่าย

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การเลือกกลยุทธ์ที่ใช้ในการทดสอบ (Strategic Options) การเลือกกลยุทธ์การทดสอบระดับบูรณาการขึ้นอยู่กับลักษณะของซอฟต์แวร์ และบางครั้งขึ้นอยู่กับตารางเวลาของโครงการ วิธีการผสมที่เรียกว่า การทดสอบแบบแซนวิช (Sandwich Testing) ใช้ทั้งแบบบนลงลง่าง ควบคู่ไปกับตัวทดสอบแบบล่างขึ้นบน

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) การเลือกกลยุทธ์ที่ใช้ในการทดสอบ (Strategic Options) ขณะที่ทดสอบระดับบูรณาการ ผู้ทดสอบควรระบุโมดูลวิกฤต (critical module) ออกมา ซึ่ง โมดูลวิกฤตมีลักษณะอย่างใดอย่างหนึ่ง ดังต่อไปนี้ รับผิดชอบหลายความต้องการของซอฟต์แวร์ มีระดับการควบคุมสูง ซับซ้อนและอาจผิดพลาดง่าย มีความต้องการด้านเกณฑ์ประเมินที่แน่นอน

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) เอกสารประกอบการทดสอบระดับบูรณาการ (Integration Test Documentation) แผนโดยรวมสำหรับการทดสอบซอฟต์แวร์และคำอธิบายแต่ละอันถูกบันทึกในข้อกำหนดการทดสอด (Test Specification) เอกสารนี้บรรจุการทดสอบ ขั้นตอนการทดสอบ อันเป็นผลงานของกระบวนการซอฟต์แวร์ และกลายเป็นส่วนหนึ่งของโครงการแบบซอฟต์แวร์

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) เอกสารประกอบการทดสอบระดับบูรณาการ (Integration Test Documentation) แผนการทดสอบอธิบายกลยุทธ์โดยรวมสำหรับการบูรณาการ การทดสอบถูกแบ่งออกเป็นระยะ (Phase) และบิ้วด์ที่รับผิดชอบหน้าที่และพฤติกรรมของซอฟต์แวร์

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) เอกสารประกอบการทดสอบระดับบูรณาการ (Integration Test Documentation) ตารางสำหรับการทดสอบระดับบูรณาการ การพัฒนาซอฟต์แวร์ส่วนเกิน และเรื่องอื่นๆ ที่เกี่ยวข้อง ก็ควรมีการคำนึงถึงเป็นส่วนหนึ่งของแผนการทดสอบ มีจัดวันเริ่มต้นและจบงานแต่ละระยะ พร้อมทั้งเผื่อเวลาไว้สำหรับการทดสอบโมดูลระดับหน่วยด้วย ซอฟต์แวร์ส่วนเกิด เช่น สตับและไดร์ฟเวอร์ที่อาจต้องใช้ความพยายามในการสร้างขึ้นเป็นพิเศษ ต้องมีการอธิบายอย่างย่อไว้ด้วย สุดท้ายสิ่งแวดล้อมและทรัพยากรการทดสอบต้องจัดสรรและอธิบายไว้ด้วย โครงแบบฮาร์ดแวร์ที่ไม่ได้ใช้งานประจำ โปรแกรมเลียนแบบแบบพิสดาร และเครื่องมือและเทคนิคทดสอบพิเศษก็ควรจะใส่ด้วยถ้ามีการใช้งาน

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) เอกสารประกอบการทดสอบระดับบูรณาการ (Integration Test Documentation) ประวัติของการทดสอบจริง ปัญหา ข้อน่าสงสัย ควรบันทึกในรายงานการทดสอบ (Test Report) ที่อาจต่อท้ายข้อกำหนดการทดสอบ ข้อมูลเหล่านี้อาจสำคัญในภายหลังระหว่างการซ่อมบำรุงซอฟต์แวร์ ภาคผนกและการอ้างอิงที่เหมาะสมจึงควรมีอยู่ด้วย

13.3 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์แบบดั้งเดิม (Test Strategies for Conventional Software) 13.3.2 การทดสอบระดับบูรณาการ (Integration Testing) เอกสารประกอบการทดสอบระดับบูรณาการ (Integration Test Documentation) เช่นเดียวกับส่วนประกอบของโครงแบบซอฟต์แวร์ส่วนอื่นๆ รูปแบบของข้อกำหนดการทดสอบอาจปรับเปลี่ยนให้เหมาะสมกับความต้องการส่วนตัวขององค์กร ควรระลึกไว้ว่า กลยุทธ์การบูรณาการที่บรรจุในแผนการทดสอบ และแผนรายละเอียดที่อธิบายในขั้นตอนการทดสอบเป็นหัวใจสำคัญและต้องปรากฏอยู่ในเอกสาร

13.4 กลยุทธ์การทดสอบ สำหรับซอฟต์แวร์เชิงวัตถุ (TEST STRATEGIES FOR OBJECT-ORIENTED SOFTWARE)

13.4 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์เชิงวัตถุ (Test Strategies for Object-Oriented Software) 13.4.1 การทดสอบระดับหน่วยในบริบทเชิงวัตถุ (Unit Testing in the OO Context) แนวคิดเรื่องหน่วยเปลี่ยนไปเป็นซอฟต์แวร์เชิงวัตถุ การห่อหุ้มวัตถุ (Encapulation) เป็นแรงขับเคลื่อน นิยามของคลาส ซึ่งหมายความว่าแต่ละคลาสแต่ละอินสแตนด์ของคลาส ได้แก่วัตถุ บรรจุแอตทริบิวส์ (ข้อมูล) และตัวดำเนินการ (หน้าที่การทำงาน) ที่จัดการกับข้อมูลที่บรรจุอยู่ คลาสที่ถูกห่อหุ้มก็คือจุดสนใจของการทดสอบระดับหน่วย อย่างไรก็ตาม ตัวดำเนินการภายในคลาสเป็นหน่วยเล็กที่สุดที่ทดสอบได้ เนื่องจากในคลาสหนึ่งสามารถมีตัวดำเนินการหลายตัว และตัวดำเนินการบางตัว อาจเป็นส่วนหนึ่งของหลายๆ คลาส เทคนิคที่ประยุกต์การทดสอบระดับหน่วยจึงเปลี่ยนไป

13.4 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์เชิงวัตถุ (Test Strategies for Object-Oriented Software) 13.4.1 การทดสอบระดับหน่วยในบริบทเชิงวัตถุ (Unit Testing in the OO Context) เราไม่สามารถทดสอบตัวดำเนินการหนึ่งอย่างอิสระ ดังที่เคยทำซอฟต์แวร์ทั่วๆ ไป แต่ต้องทดสอบเป็นส่วนหนึ่งของคลาส ลองพิจารณาลำดับชั้นของคลาสที่มีตัวดำเนินการ X ที่นิยามไว้สำหรับคลาสแม่ และถูกถ่ายทอดสู่คลาสลูกจำนวนหนึ่ง คลาสลูกแต่ละคลาสต่างใช้ตัวดำเนินการ X แต่ใช้กับแอตทริบิวส์ส่วนตัวและตัวดำเนินการอื่นๆ ที่กำหนดสำหรับคลาสตนเองเท่านั้น เพราะว่าตัวดำเนินการ X ภายใต้สภาพแวดล้อมของแต่ละคลาสลูก ซึ่งหมายความว่าการทดสอบตัวดำเนินการ X อย่างอิสระแบบเดิม จะใช้ไม่ได้ผลในบริบทเชิงวัตถุ

13.4 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์เชิงวัตถุ (Test Strategies for Object-Oriented Software) 13.4.1 การทดสอบระดับหน่วยในบริบทเชิงวัตถุ (Unit Testing in the OO Context) การทดสอบคลาสสำหรับซอฟต์แวร์เชิงวัตถุ เทียบเท่ากับการทดสอบระดับหน่วยสำหรับซอฟต์แวร์แบบดั้งเดิม สิ่งที่แตกต่างกัน การทดสอบระดับหน่วยในซอฟต์แวร์แบบดั้งเดิม เน้นที่รายละเอียดการทำงานหรืออัลกอริทึมของโมดูลและข้อมูลที่ไหลผ่านอินเตอร์เฟสของโมดูล ขณะที่การทดสอบคลาสสำหรับซอฟต์แวร์เชิงวัตถุ ถูกขับเคลื่อนด้วยตัวดำเนินการห่อหุ้มภายในคลาส และพฤติกรรมในแต่ละสถานะของคลาส

13.4 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์เชิงวัตถุ (Test Strategies for Object-Oriented Software) 13.4.2 การทดสอบระดับบูรณาการในบริบทเชิงวัตถุ (Integration Testing in the OO Context) ซอฟต์แวร์เชิงวัตถุไม่มีโครงสร้างการควบคุมตามลำดับขั้นที่ชัดเจน ดังนั้น การทดสอบระดับบูรณาการจากบนลงล่าง หรือล่างขึ้นบนจึงไร้ความหมาย นอกจากการรวมตัวดำเนินการทีละตัวเข้ากับคลาสมักจะเป็นไปไม่ได้ เพราะปฏิกิริยาโดยตรงและโดยอ้อมขององค์ประกอบที่ประกอบกันขึ้นเป็นคลาส

13.4 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์เชิงวัตถุ (Test Strategies for Object-Oriented Software) 13.4.2 การทดสอบระดับบูรณาการในบริบทเชิงวัตถุ (Integration Testing in the OO Context) สองกลยุทธ์ที่ใช้ทดสอบระดับบูรณาการในระบบเชิงวัตถุ คือ การทดสอบตามสายงานขนาดเล็ก (Thread-based Testing) ซึ่งรวมเอาชุดของคลาสที่จำเป็นในการตอบสนองต่อข้อมูลเข้าหรือเหตุการณ์หนึ่งๆ ของระบบ แต่ละสายงานจะถูกรวบรวมและทดสอบแยกกันทีละสาย การทดสอบตามการใช้งาน (Use-based Testing) เริ่มสร้างระบบโดยการทดสอบคลาสที่เป็นอิสระ (Independent Class) คือคลาสที่ไม่ใช้หรือใช้คลาสบริการน้อย หลังจากทดสอบคลาสอิสระแล้ว จึงทดสอบระดับถัดมา เรียกว่าคลาสขึ้นแก่กัน (Dependent Classes) ซึ่งการเรียกใช้งานคลาสอิสระ ลำดับชั้นของการทดสอบคลาสขึ้นแก่กันจะต่อเนื่องกันไปจนกว่าระบบทั้งหมดถูกทดสอบ

13.4 กลยุทธ์การทดสอบสำหรับซอฟต์แวร์เชิงวัตถุ (Test Strategies for Object-Oriented Software) 13.4.2 การทดสอบระดับบูรณาการในบริบทเชิงวัตถุ (Integration Testing in the OO Context) การทดสอบคลัสเตอร์ (Cluster Testing) เป็นขั้นตอนหนึ่งในการทดสอบระดับบูรณาการของซอฟต์แวร์เชิงวัตถุ ในที่นี้กลุ่มที่ทำงานร่วมกันจะถูกทดสอบ โดยการออกแบบกรณีที่พยายามเปิดเผยข้อผิดพลาดในการทำงานร่วมกัน

13.5 การทดสอบการตรวจรับ (VALIDATION TESTING)

13.5 การทดสอบการตรวจรับ (Validation Testing) การทดสอบการตรวจรับนิยามง่ายๆ คือ ความสำเร็จของการตรวจรับเกิดขึ้นเมื่อซอฟต์แวร์ทำงานในลักษณะที่สมเหตุสมผลตามความคาดหมายของลูกค้า ความคาดหมายที่สมเหตุสมผลได้รับการกำหนดไว้ในข้อกำหนดความต้องการของซอฟต์แวร์ (Software Requirement Specification) คือ เอกสารที่อธิบายลักษณะทุกๆ อย่างที่ผู้ใช้งานมองเห็นได้ของซอฟต์แวร์ ข้อกำหนดบรรจุส่วนที่เรียกว่า เกณฑ์การตรวจรับ (Validation Test Criteria) ข้อมูลที่บรรจุในส่วนนี้เป็นพื้นฐานสำหรับการทดสอบการตรวจรับ

13.5 การทดสอบการตรวจรับ (Validation Testing) 13.5.1 เกณฑ์การทดสอบการตรวจรับ (Validation Test Criteria) การทดสอบการตรวจรับของซอฟต์แวร์สำเร็จได้โดยผ่านชุดการทดสอบที่สาธิตว่า ซอฟต์แวร์ทำงานตรงตามความต้องการ แผนการทดสอบร่างชนิดของการทดสอบที่จะดำเนินการ และขั้นตอนการทดสอบกำหนดกรณีทดสอบเฉพาะ ทั้งแผนการและขั้นตอนถูกออกแบบมาเพื่อยืนยันว่าทุกๆ ความต้องการเชิงหน้าที่ทำงานเป็นที่พอใจ ทุกลักษณะพฤติกรรมประสบผลสำเร็จ และความต้องการเชิงเกณฑ์ประกอบการได้บรรลุเป้าหมาย เอกสารกำกับมีความถูกต้อง ซอฟต์แวร์ใช้งานง่าย และความต้องการอื่นๆ ก็ครบถ้วน

13.5 การทดสอบการตรวจรับ (Validation Testing) 13.5.1 เกณฑ์การทดสอบการตรวจรับ (Validation Test Criteria) หลังจากการทดสอบการตรวจรับแต่ละครั้งกับกรณีทดสอบ มีความเป็นไปได้อยู่ 2 อย่าง คือ หน้าที่การทำงานและเกณฑ์ประกอบการเป็นไปตามที่กำหนดและยอมรับได้ มีความเบี่ยงเบนจากข้อผิดพลาดที่ค้นพบ เนื่องจากความผิดพลาดที่พบในช่วงนี้ของโครงการยากที่จะแก้ไขก่อนกำหนดส่งมอบได้ ดังนั้นจึงจำเป็นต้องต่อรองกับลูกค้าเพื่อหาวิธีแก้ไขความด้อยประสิทธิภาพ

13.5 การทดสอบการตรวจรับ (Validation Testing) 13.5.2 การทบทวนโครงแบบ (Configuration Review) ส่วนประกอบที่สำคัญในกระบวนการตรวจรับ คือ การทบทวนโครงแบบ เป้ามายของการทบทวนเพื่อยืนยันว่าทุกส่วนประกอบของโครงแบบซอฟต์แวร์ได้พัฒนามาอย่างเหมาะสม มีการจัดเก็บรายละเอียดที่จำเป็นเพื่อใช้ในช่วงบำรุงรักษาตามวงจรชีวิตซอฟต์แวร์ บางครั้งเรียกว่า การตรวจสอบ (Audit)

13.5 การทดสอบการตรวจรับ (Validation Testing) 13.5.3 การทดสอบแบบอัลฟ่าและเบต้า (Alpha and Beta Testing) เมื่อจัดสร้างซอฟต์แวร์ตามความต้องการของลูกค้ารายหนึ่ง ชุดของการทดสอบการส่งมอบ (Acceptance Test) จะถูกจัดทำขึ้นเพื่อให้ลูกค้าตรวจสอบความถูกต้องของทุกความต้องการ การทดสอบกระทำโดยผู้ใช้งานสุดท้าย ไม่ใช่นักวิศวกรซอฟต์แวร์ การทดสอบการส่งมอบกินช่วงเวลากว้างตั้งแต่การทดสอบคร่าวๆ อย่างไม่เป็นทางการ ไปจนถึงการวางแผนการ การทดสอบอย่างเป็นระบบโดยใช้ชุดทดสอบจำนวนมาก

13.5 การทดสอบการตรวจรับ (Validation Testing) 13.5.3 การทดสอบแบบอัลฟ่าและเบต้า (Alpha and Beta Testing) ถ้าซอฟต์แวร์ที่พัฒนาเป็นผลิตภัณฑ์สำหรับผู้ใช้หลายๆ ราย จะไม่สามารถทดสอบการส่งมอบอย่างเป็นทางการกับผู้ใช้ทุกรายได้ ผู้ผลิตจึงเลือกใช้กระบวนการที่เรียกว่า การทดสอบแบบอัลฟ่าและเบต้า (Alpha and Beta Testing) เพื่อค้นหาข้อผิดพลาดที่ผู้ใช้งานเท่านั้นอาจหาพบได้

13.5 การทดสอบการตรวจรับ (Validation Testing) 13.5.3 การทดสอบแบบอัลฟ่าและเบต้า (Alpha and Beta Testing) การทดสอบแบบอัลฟ่า ดำเนินการ ณ สถานที่ของผู้พัฒนาระบบโดยผู้ใช้งานสุดท้าย ซอฟต์แวร์จะถูกใช้ในลักษณะที่ใช้จริงโดยมีผู้พัฒนาเฝ้าสังเกตการณ์ การใช้งานตามปกติของผู้ใช้และบันทึกข้อผิดพลาดรวมทั้งปัญหาในการใช้งานอื่นๆ การทดสอบแบบอัลฟ่ากระทำภายใต้สิ่งแวดล้อมที่มีการควบคุม

13.5 การทดสอบการตรวจรับ (Validation Testing) 13.5.3 การทดสอบแบบอัลฟ่าและเบต้า (Alpha and Beta Testing) การทดสอบแบบเบต้า ดำเนินการ ณ สถานที่ของผู้ใช้งานสุดท้าย ผู้พัฒนามักไม่อยู่ด้วย ดังนั้น การทดสอบแบบเบต้า จึงเป็นการประยุกต์ใช้งานจริงของซอฟต์แวร์ ภายใต้สิ่งแวดล้อมที่ผู้พัฒนาควบคุมไม่ได้ ผู้ใช้งานสุดท้ายบันทึกปัญหาทุกอย่างที่พบขณะทดสอบแบบเบต้า และรายงานสิ่งเหล่านี้ให้ผู้พัฒนาทราบเป็นระยะๆ วิศวกรซอฟต์แวร์จะทำการปรับปรุงแก้ไขและเตรียมพร้อมเพื่อวางตัวผลิตภัณฑ์รุ่นถัดไปให้ลูกค้าทุกกลุ่ม

13.6 การทดสอบระบบ (SYSTEM TESTING)

13.6 การทดสอบระบบ (System Testing) วัตถุประสงค์ของการทดสอบระบบก็เพื่อทดลองใช้งานระบบคอมพิวเตอร์ทั้งหมดอย่างเต็มที่ แม้ว่าการทดสอบแต่ละชุดมีวัตถุประสงค์แตกต่างกัน แต่ก็ทำงานร่วมกัน เพื่อตรวจทานว่า องค์ประกอบของระบบได้รวมกันอย่างเหมาะสม และทำงานตามหน้าที่ที่กำหนด

13.6 การทดสอบระบบ (System Testing) 13.6.1 การทดสอบการกู้คืน (Recovery Testing) การทดสอบการกู้คืนเป็นการทดสอบระบบที่ทำให้ซอฟต์แวร์ทำงานล้มเหลวในหลากสถานการณ์และตรวจสอบว่าการกู้คืนได้เกิดขึ้นอย่างเหมาะสม ถ้าการกู้คืนเป็นไปโดยอัตโนมัติ นั้นคือ ระบบทำการกู้คืนได้ด้วยตัวเอง การตั้งค่าใหม่ กลไกลการตรวจสอบจุดล้มเหลว การกู้คืนข้อมูล และการเริ่มทำงานใหม่จะถูกประเมินว่าถูกต้องหรือไม่ ถ้าหากกู้คืนต้องใช้มนุษย์ช่วย เวลาเฉลี่ยในการซ่อม (Mean – Time – To – Repair – MTTR) จะถูกประเมิน

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

13.6 การทดสอบระบบ (System Testing) 13.6.3 การทดสอบแรงเครียด (Stress Testing) การทดสอบแรงเครียดทำงานกับระบบในลักษณะที่ใช้ทรัพยากรจำนวนมากผิดปกติจำนวนมาก หรือ ปริมาณมาก เช่น สร้างสัญญาณขัดจังหวะ 10 ครั้งต่อวินาที จากโดยปกติเฉลี่ยเพียงหนึ่งหรือสองครั้ง อัตราเข้าของข้อมูลเพิ่มขึ้นแบบทวีคูณ เพื่อหาว่าหน้าที่รับข้อมูลจะตอบสนองอย่างไร กรณีทดสอบที่จองเนื้อที่ความจำหรือทรัพยากรอื่นๆ มากที่สุด กรณีทดสอบที่อาจก่อให้เกิดปัญหาการจัดการเนื้อที่หน่วยความจำ กรณีทดสอบที่อาจก่อให้เกิดการตามล่าหาข้อมูลจากฮาร์ดดิสก์

13.6 การทดสอบระบบ (System Testing) 13.6.3 การทดสอบแรงเครียด (Stress Testing) อีกรูปแบบหนึ่งของการทดสอบแรงเครียด คือ เทคนิคที่เรียกว่า การทดสอบความไว (Sensitivity Testing) ในบางสถานการณ์ โดยเฉพาะกับอัลกอริทึมทางคณิตศาสตร์ ช่วงเล็กๆ มากๆ ของข้อมูลที่อยู่ในขอบเขตของข้อมูลที่โปรแกรมยอมรับได้ อาจก่อให้เกิดการสุดโต่งหรือแม้แต่การทำงานที่ผิดพลาด หรือเกณฑ์ประกอบการลดลงอย่างมาก การทดสอบความไพยายามที่จะเปิดเผยข้อมูลภายในชั้นข้อมูลที่ยอมรับได้ ซึ่งอาจก่อให้เกิดความไม่คงตัวหรือการประมวลผลที่ไม่เหมาะสม

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

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

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (THE ART OF DEBUGGING)

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (The Art of Debugging) การค้นหาสาเหตุของจุดบกพร่อง (Debugging) เป็นผลสืบเนื่องจากการทดสอบที่สัมฤทธิ์ผล นั่นคือ เมื่อกรณีทดสอบค้นพบข้อผิดพลาด การค้นหาสาเหตุของจุดบกพร่องเป็นการกระทำที่มุ่งหวัง จะขจัดความผิดพลาดที่ค้นพบ แม้ว่าการค้นหาสาเหตุของจุดบกพร่องน่าจะเป็นกระบวนการอันมีระเบียบ แต่ก็ยังเป็นศิลปะอยู่มาก หลังจากประเมินผลการทดสอบ นักวิศวกรซอฟต์แวร์มักจะเผชิญกับตัวบ่งชี้ อาการของปัญหาซอฟต์แวร์ กล่าวคือ อาการภายนอกที่แสดงออกของข้อผิดพลาดกับสาเหตุภายในของความผิดพลาด อาจจะไม่มีความสัมพันธ์ต่อกันที่ชัดเจน กระบวนการทางจิตใจที่เรายังไม่เข้าใจที่ดีสามารถเชื่อมอาการกับสาเหตุเรียกว่า การค้นหาสาเหตุของจุดบกพร่อง (Debugging)

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (The Art of Debugging) 13.7.1 กระบวนการค้นหาสาเหตุของจุดบกพร่อง (The Debugging Process) กระบวนการค้นหาสาเหตุของจุดบกพร่องเริ่มต้นด้วยการทำงานของกรณีทดสอบ การประเมินผลลัพธ์อันเปิดเผยถึงความไม่สอดคล้องกันของผลลัพธ์จริงกับผลลัพธ์ที่คาดหมาย ในหลายๆ กรณีข้อมูลที่ไม่สอดคล้องกันเป็นอาการของสาเหตุที่ซ่อนอยู่ การค้นหาสาเหตุของจุดบกพร่องพยายามจะจับคู่สาเหตุกับอาการซึ่งนำไปสู่การแก้ไขข้อผิดพลาด

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (The Art of Debugging) 13.7.1 กระบวนการค้นหาสาเหตุของจุดบกพร่อง (The Debugging Process)

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (The Art of Debugging) 13.7.1 กระบวนการค้นหาสาเหตุของจุดบกพร่อง (The Debugging Process) การค้นหาสาเหตุมักมีผลสัมฤทธิ์ 2 ประการ คือ สาเหตุของปัญหาถูกค้นพบและได้รับการแก้ไข สาเหตุของปัญหาไม่ถูกค้นพบ ในกรณีหลังนี้ผู้แก้ไขอาจต้องเดาสาเหตุและออกแบบกรณีทดสอบเพิ่มเติมเพื่อช่วยยืนยันการคาดเดา งานที่นำไปสู่การแก้ไขข้อผิดพลาดมีลักษณะวนซ้ำ

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (The Art of Debugging) 13.7.1 กระบวนการค้นหาสาเหตุของจุดบกพร่อง (The Debugging Process) ทำไมการค้นหาสาเหตุของจุดบกพร่องถึงเป็นเรื่องยาก อาการและสาเหตุอาจอยู่ไกลกันทางภูมิศาสตร์ นั่นคือ อาการอาจปรากฏขึ้นที่ส่วนหนึ่งของโปรแกรม ขณะที่สาเหตุอาจอยู่ที่อื่นไกลๆ องค์ประกอบที่มีความขึ้นแก่กันสูงจะยิ่งทำให้สถานการณ์นี้เลวร้ายลง อาการอาจหายไปชั่วคราวเมื่อข้อผิดพลาดอื่นถูกแก้ไข อาการอาจเกิดขึ้นจากสาเหตุที่ไม่ใช่ข้อผิดพลาด อาการเกิดจากสาเหตุที่ไม่ใช่ข้อผิดพลาด

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (The Art of Debugging) 13.7.1 กระบวนการค้นหาสาเหตุของจุดบกพร่อง (The Debugging Process) ทำไมการค้นหาสาเหตุของจุดบกพร่องถึงเป็นเรื่องยาก อาการอาจเป็นผลของปัญาเกี่ยวกับเวลา มากกว่าปัญหาด้านกระบวนการ อาจเป็นการยากที่จะสร้างเงื่อนไขข้อมูลเข้าซ้ำเติมได้อีก อาการอาจอยู่เพียงชั่วครู่ชั่วยาม ซึ่งเกิดขึ้นเป็นธรรมดาในระบบฝังตัวที่เชื่อมฮาร์ดแวร์เข้าด้วยกันอย่างแยกไม่ออก อาการอาจสืบเนื่องจากสาเหตุที่กระจายครอบคลุมงานย่อยจำนวนหนึ่ง ที่ทำงานบนหน่วยประมวลผลที่แตกต่างกัน

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (The Art of Debugging) 13.7.2 กลยุทธ์การค้นหาสาเหตุของจุดบกพร่อง (Debugging Strategies) Bradley อธิบายวิธีการแก้ไขข้อผิดพลาดไว้ว่า “การดีบั๊กเป็นการประยุกต์วิธีการทางวิทยาศาสตร์ที่ได้พัฒนามากว่า 2,500 ปี อย่างตรงไปตรงมา พื้นฐานของการดีบั๊ก คือ การหาตำแหน่งของต้นตอปัญหา โดยการแบ่งส่วนเกณฑ์สอง (Binary Partitioning) ผ่านสมมติฐานการทำงานที่ทำนายค่าใหม่ที่จะถูกตรวจสอบ”

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (The Art of Debugging) 13.7.2 กลยุทธ์การค้นหาสาเหตุของจุดบกพร่อง (Debugging Strategies) เทคนิคการดีบั๊ก (Debugging Tactics) การใช้แรงงานอย่างบ้าบิ่น (Brute force) เป็นวิธีที่ใช้กันทั่วไป มีประสิทธิภาพต่ำที่สุดในการแยกสาเหตุของข้อผิดพลาด มักจะใช้วิธีนี้เมื่อได้ลองวิธีการอื่นหมดแล้ว โดยใช้หลักว่า ให้คอมพิวเตอร์หาข้อผิดพลาดโดยมีการถ่ายข้อมูลในหน่วยความจำภายในออกมาหมด การติดตามกระแสการทำงานจริง และการเพิ่มข้อความเอาท์พุตในโปรแกรม โดยหวังว่าจะพบร่องรอยที่นำพาไปหาสาเหตุของข้อผิดพลาด แม้ว่าปริมาณอันมากมายของข้อมูลที่ผลิตออกมา อาจนำไปสู่ความสำเร็จ แต่บ่อยครั้งมักไปสู่การเสียเวลาและความพยายาม

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (The Art of Debugging) 13.7.2 กลยุทธ์การค้นหาสาเหตุของจุดบกพร่อง (Debugging Strategies) เทคนิคการดีบั๊ก (Debugging Tactics) การติดตามย้อนรอย (Backtracking) เป็นวิธีการดีบั๊กที่ค่อนข้างธรรมดาที่สามารถใช้อย่างได้ผลสำหรับโปรแกรมขนาดเล็ก โดยเริ่มต้นจากจุดเกิดอาการ จากนั้นติดตามซอร์สโค้ดย้อนร้อยด้วยตาจนกว่าจะถึงจุดที่เป็นสาเหตุ ถ้าจำนวนบรรทัดของโปรแกรมที่เพิ่มขึ้น จำนวนเส้นทางย้อนร้อยอาจมีขนาดใหญ่เกินกว่าจะจัดการได้

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (The Art of Debugging) 13.7.2 กลยุทธ์การค้นหาสาเหตุของจุดบกพร่อง (Debugging Strategies) เทคนิคการดีบั๊ก (Debugging Tactics) การกำจัดทีละสาเหตุ (Cause Elimination) ทำได้โดยการอุปนัยหรือนิรนัย และนำเนวคิดของการแบ่งส่วนเกณฑ์สอง (Binary Partitioning) มาใช้ ข้อมูลที่สัมพันธ์กับการเกิดขึ้นข้อผิดพลาดจะถูกจัดเรียงตามสาเหตุต่างๆ ที่เป็นไปได้ สมมติฐานสาเหตุถูกสร้างขึ้น และข้อมูลดังกล่าวจะใช้ในการพิสูจน์หรือกำจัดสมมติฐาน อีกวิธีการหนึ่ง คือ การร่างรายการของสาเหตุที่อาจเป็นไปได้ และ ทดสอบแต่ละรายการ เพื่อกำขัดสาเหตุที่ไม่ใช่ออก ถ้าการทดสอบเบื้องต้นชี้ว่าสมมติฐานบางอย่างอาจเป็นสาเหตุที่แท้จริง ข้อมูลทดสอบจะปรับให้ละเอียดขึ้น เพื่อพยายามแยกปัญหาออกมา

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (The Art of Debugging) 13.7.2 กลยุทธ์การค้นหาสาเหตุของจุดบกพร่อง (Debugging Strategies) การดีบั๊กอัตโนมัติ (Automated Debugging) เราอาจปรับปรุงวิธีการดีบั๊กต่างๆ ที่กล่าวมาให้ดีขึ้นได้ด้วยเครื่องมือการดีบั๊กที่สนับสนุนการทำงานกึ่งอัตโนมัติสำหรับนักวิศวกรรมซอฟต์แวร์ สิ่งแวดล้อมการพัฒนาบูรณาการ (Integrated Development Environments - IDEs) เป็นวิธีที่อาจค้นหาข้อผิดพลาดที่กำหนดล่วงหน้าบางส่วนได้ สาขาหนึ่งที่อุตสาหกรรมกำลังให้ความสนใจ คือ การสร้างภาพ (Visualization) ของโครงสร้างโปรแกรมเพื่อการวิเคราะห์ เครื่องมือต่างๆ ได้แก่ ตัวคอมไพล์การดีบั๊ก เครื่องช่วยดีบั๊กแบบไดนามิค ตัวสร้างกรณีทดสอบอัตโนมัติ และตัวจับคู่การอ้างอิงข้ามกัน

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (The Art of Debugging) 13.7.2 กลยุทธ์การค้นหาสาเหตุของจุดบกพร่อง (Debugging Strategies) ปัจจัยด้านบุคคล (The People Factor) การกล่าวถึงวิธีการค้นหาสาเหตุของจุดบกพร่องและเครื่องมือจะสมบูรณ์ไปไม่ได้ ถ้าขาดการกล่าวถึงมิตรที่มีพลังอำนาจ ได้แก่ บุคคลากรอื่นๆ ที่อาจให้มุมมองที่สดใหม่ ฝ่าเมฆหมอกชั่วโมงแห่งความขัดข้อง ภาษิตสุดท้ายแห่งการดีบั๊กคือ ถ้าทุกอย่างล้มเหลว ต้องหาคนช่วย

13.7 ศิลปะแห่งการค้นหาสาเหตุจุดบกพร่อง (The Art of Debugging) 13.7.3 การแก้ไขข้อผิดพลาด (Correcting the Error) เมื่อใดที่บั๊กถูกค้นพบแล้ว ก็ต้องได้รับแก้ไขด้วย Van Vleck แนะนำให้ลองตอบคำถามต่อไปนี้ก่อนลงมือแก้ไข สาเหตุของบั๊กนี้เกิดได้ในส่วนอื่นๆ ของโปรแกรมหรือไม่ ก่อนที่การแก้ไขจะเกิดขึ้น พิจารณาว่าจะมีบั๊กอื่นอะไรอีกบ้างที่อาจเกิดขึ้นได้จากการแก้ไขบั๊กนี้ ควรมีการตรวจดูซอร์สโค้ดเพื่อหาความเชื่อมกันของตรรกะและโครงสร้างข้อมูล หากมีการแก้ไขในส่วนของโปรแกรมที่มีการเชื่อมโยงกันสูง จะต้องระมัดระวังเพิ่มขึ้นในการแก้ไขด้วย จะทำอะไรได้บ้างที่ป้องกันความผิดพลาดนี้ได้ตั้งแต่เริ่มต้น

13.8 สรุปท้ายบท

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

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

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