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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

สรุปท้ายบท

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

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

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

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

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "กลยุทธ์การทดสอบซอฟต์แวร์ (TESTING STRATEGIES)"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ

เข้าสู่ระบบ

ลงทะเบียนผ่านเครือข่ายสังคม:

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

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "กลยุทธ์การทดสอบซอฟต์แวร์ (TESTING STRATEGIES)"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ