บทที่ 20 Testing

การทดสอบระบบจะแบ่งออกเป็น

1. Component testing เป็นการทดสอบแต่ละ sub system ย่อยๆหรือแต่ละ component
2. Integration testing เป็นการทดสอบที่นำแต่ละระบบย่อยมารวมกันแล้วทดสอบ

ส่วนใหญ่ผู้พัฒนา Software มักจะเป็นผู้ทดสอบในระดับ component แต่ในระดับ Integration มักจะให้บุคคลที่ 3 ที่ไม่เกี่ยวข้องกับการพัฒนา Software เป็นผู้ทดสอบ

1. Component testing
1.1 Defect testing จุดประสงค์เพื่อทดสอบว่า component นั้นๆมีข้อผิดพลาดอะไรบ้าง ประกอบด้วยขั้นตอน
- ออกแบบสถานะการณ์ที่ต้องการจะทดสอบ และจะได้ออกมาเป็นกรณีทดสอบพร้อมทั้งระบุได้ว่าผลลัพธ์ที่ได้จะเป็นยังไง
- เตรียวข้อมูลที่จะทดสอบ
- ลงมือทดสอบ
- เอาผลลัพธ์ที่ได้จากการทดสอบจริงมาเปรียบเทียบกับที่คาดการณ์ไว้ในตอนแรก
1.2 Black – box testing เป็นการทดสอบระดับฟังก์ชัน โดยเราจะไม่สนใจว่าฟังก์ชันนั้นทำงานยังไง แต่จะสนใจเพียงว่า input ที่เข้าไปเป็นอะไรและได้ output อะไรออกมา ในตอนออกแบบจะมีการกำหนดเป็น specification ของฟังก์ชันไว้เลยว่า input ของมันคืออะไรและได้ output อะไร รวมทั้งระบุด้วยว่า input ที่ทำให้เกิดความผิดพลาดมีอะไรบ้างและทำการทดสอบด้วยว่าเกิดความผิดพลาดตามที่คาดไว้หรือเปล่า
1.3 Equivalence partitioning ( เคยพูดไปแล้ว ) เราจะแบ่งช่วงของข้อมูลโปรเซสออกเป็นส่วนๆให้ครอบคลุมทุกความเป็นไปได้ เรียกว่า partitioning แล้วทดสอบให้ครบทุกส่วน เช่นโปรแกรมทำงานได้ที่ช่วงเลข 1-10 ข้อมูลในช่วงที่ต้องทดสอบก็คือ 1-10 , 0 , -1 , 11 , ตัวอักษร เป็นต้น
1.4 Search routine specification จะเป็นการแบ่งเนื้อหาในตัวโปรแกรมออกเป็นตัวย่อยๆแล้วเอาแต่ละส่วนย่อยๆมาทดสอบ ในลักษณะเป็น partitioning อีกทีหนึ่ง ( แต่เป็นการทดสอบแต่ละกรณีที่เป็นไปได้ไม่ใช่ข้อมูลที่เป็นไปได้ ) ในตย. ข้างล่าง (slide13) จะทดสอบว่าถ้ามีการใส่ข้อมูลในกรณีต่างๆเพื่อจะไปค้นหาข้อมูลนั้นผลจะเป็นอย่างไรบ้าง เช่น ใส่ลงไปทีละค่า เรียงตามลำดับและไม่เรียงตามลำดับ หรือใส่ลงไปมากกว่า 1 ค่าเรียงตามลำดับและไม่เรียงตามลำดับ

1.5 Structural testing เป็นการทดสอบในระดับโครงสร้างหรือเรียกว่าเป็น White–box เพราะว่าเป็นการเข้าไปทดสอบในแต่ละคำสั่งในฟังก์ชันย่อยเลย เพราะฉะนั้นเราจะเอาโมดูลมาแตกเป็นทีละ block ของคำสั่งแล้วมาทดสอบว่าทำงานได้จริงหรือเปล่า

1.6 Path testing

เป็นการทดสอบว่าเวลาเราออกแบบโปรแกรมมาแล้ว Flow ของโปรแกรมจะถูกใช้งานจริงทุก Path หรือไม่ แล้วถ้าถูกใช้งานจริงทุก Path แต่ละ Path จะทำให้เกิดข้อผิดพลาดอะไรหรือเปล่า ดังรูปตย.ข้างล่าง (slide17,18)Path ทั้งหมดที่เป็นไปได้

- 1, 2, 3, 8, 9
- 1, 2, 3, 4, 6, 7, 2
- 1, 2, 3, 4, 5, 7, 2
- 1, 2, 3, 4, 6, 7, 2, 8, 9

คือการที่เราเอาระบบย่อยๆแต่ละระบบเอามารวมเข้ากับระบบใหญ่ทีละระบบย่อยแล้วทดสอบทั้งระบบ แล้วก็นำระบบย่อยที่เหลือมารวมแล้วก็ทดสอบอีก ทำอย่างนี้ซ้ำไปเรื่อยๆจนครบทุกระบบย่อย ดังตย.ข้างล่าง (slide20) ในการทดสอบนี้จะให้ความสำคัญกับการที่เราเอาแต่ละส่วนมารวมกันแล้วนั้นมันสามารถทำงานได้จริงหรือไม่ ซึ่งจะมีการทดสอบเป็น 2 ลักษณะ คือ

- แบบ Top – down จะเป็นการทดสอบในระดับบนสุดก่อนแล้วจึงทดสอบในระดับย่อยลงมา

- แบบ Bottom-up จะเป็นการทดสอบในระดับย่อยก่อนขึ้นไปสู่ระดับบน

วิธีการในการทดสอบ

1. ประเมิน architecture
2. ทดลอง run โปรแกรม
3. ลงมือทดสอบในแต่ละส่วนย่อยๆ อย่างเช่นวิธีในข้อ 1.1 , 1.2 , …. ของ Component testing
4. เขียนโปรแกรมเข้ามาช่วยในการทดสอบ

2.1 Interface testing เป็นการทดสอบ interface ระหว่างโมดูลย่อย ไม่ใช่ User interface สิ่งที่ต้องทดสอบคือ
- ทดสอบว่ามี Parameter อะไรบ้าง
- ทดสอบการใช้ memory ร่วมกัน
- ทดสอบการเรียกใช้งาน Procedure กันระหว่างแต่ละระบบย่อย
- ทดสอบการส่งค่ากันระหว่างโมดูล

2.2 Stress testing เป็นการทดสอบความคงทนของระบบ โดยเรามักจะใส่ข้อมูลเข้าไปให้เกิด Overload แล้วดูว่าระบบจะทนอยู่ได้นานแค่ไหน

2.3 Object - Oriented testing ในกรณีที่เราพัฒนา software ในลักษณะ Object สิ่งที่เราเน้นการทดสอบในระดับ Class เป็นหลัก และมักใช้ White-box ในการทดสอบ โดยเข้าไปทดสอบยังตัว Method ต่างๆในแต่ละ Class สิ่งที่เราจะต้องทดสอบคือ
- การทำงานร่วมกันของแต่ละ Object
- ทดสอบ Class แต่ละ Class
- ทดสอบ Object หลายๆ Object ที่เป็นกลุ่มเกี่ยวข้องกัน
- ทดสอบทั้งระบบ

บรรยายเมื่อ 25 กพ. 2545 เทอม 2/44