Wednesday, September 21, 2016

4 การทดสอบ (Testing)

4 การทดสอบ (Testing)
เมื่อทำการทดสอบแต่ละหน่วยหรือโมดูลเสร็จสิ้นแล้ว ก็จะทำการรวมโมดูลแต่ละโมดูลเข้าด้วยกันเพื่อทำการทดสอบรวมอีกครั้ง ทำให้สามารถยืนยันได้ว่าระบบที่ได้รับการออกแบบและพัฒนาขึ้นนั้น มีการทำงานที่เป็นปกติถูกต้องเหมาะสม ด้วยเหตุนี้การทดสอบจึงเป็นกระบวนการที่สำคัญเพื่อสามารถยืนยันคุณภาพของโปรแกรมและระบบ โดยการทดสอบจะถูกดำเนินการตามแผนการทดสอบ (test plans) ที่วางไว้ด้วยการให้ระบบทำงานอย่างต่อเนื่องเพื่อสามารถประเมินผลประสิทธิภาพของโปรแกรมและระบบได้

(1) ขั้นตอนการดำเนินการทดสอบ (Test execution procedure)
ขั้นตอนสำหรับการดำเนินการทดสอบในแต่ละการทดสอบมีขั้นตอนดังต่อไปนี้
- การสร้างแผนการทดสอบ (Test plan creation) เป็นขั้นตอนการกำหนดรายการเพื่อการทดสอบแต่ละรายการ เช่น แผนทดสอบ ผู้ร่วมทดสอบ และเกณฑ์การประเมินผล เป็นการทดสอบเพื่อการปรับปรุงคุณภาพของโปรแกรม ที่ไม่มีการทดสอบซ้ำ
- การออกแบบข้อกำหนดในการทดสอบ (Test specifications design ) เป็นขั้นตอนการออกแบบรายการต่างๆ อาทิ ข้อมูลในการทดสอบ และผลที่คาดว่าจะได้ ตามข้อกำหนดในการออกแบบ
- การกำหนดสภาพแวดล้อมในการทดสอบ (Test environment setting) เป็นขั้นตอนในการสร้างข้อมูลเพื่อการทดสอบ และจัดเตรียมสภาพแวดล้อมในการทดสอบรวมถึงเครื่องและอุปกรณ์ต่างๆ ที่ต้องใช้ในการทดสอบ
หากผู้พัฒนาโปรแกรมเป็นผู้จัดเตรียมข้อมูลเพื่อการทดสอบหรือออกแบบสภาพแวดล้อมเพื่อการทดสอบอาจทำให้ข้อผิดพลาดที่ไม่คาดคิดเกิดขึ้นน้อยมาก หรือไม่เกิดขึ้นเลย จึงเป็นการดีหากให้ผู้อื่นที่ไม่ใช่ผู้พัฒนาโปรแกรมเป็นผู้ทำหน้าที่จัดเตรียมสภาพแวดล้อมในการทดสอบ
- การดำเนินการทดสอบ (Test execution) เป็นขั้นตอนในการดำเนินการทดสอบให้เป็นไปตามข้อกำหนดในการทดสอบ หากมีการแก้ไขโปรแกรมหลังจากทำการทดสอบเสร็จสิ้นแล้ว จำเป็นต้องมีการทดสอบใหม่ ด้วยข้อมูลในการทดสอบชุดเดิมเพื่อยืนยันความถูกต้องของผลการทดสอบ
- การประเมินผลการทดสอบ (Test result evaluation) เป็นขั้นตอนการประเมินผลระบบโดยอ้างอิงจากผลการทดสอบ และอธิบายถึงปัญหาต่างๆ ที่พบ

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

(2) เทคนิคการทดสอบ (Testing techniques) เทคนิคในการทดสอบหลัก (main testing) เทคนิคหนึ่งในการพัฒนาระบบคือ การทดสอบกล่องดำ (Black box test) การทดสอบวิธีนี้เป็นเทคนิดในการตรวจสอบการทำงานหรือฟังก์ชั่นต่างๆ ในโปรแกรมให้เป็นไปตามข้อกำหนด โดยมุ่งเน้นที่ข้อมูลนำเข้า (input data) และผลลัพท์ที่ได้จากการทำงาน (output results) (เป็นการทดสอบที่ไม่สนใจการทำงานภายในระบบ แต่สนใจเฉพาะข้อมูลที่ใส่เข้าไปในระบบแล้วได้ผลลัพท์ใดจากการประมวลผลหรือการทำงานของระบบ)

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

ข้อมูลปกติ (Normal data) เพื่อใช้ในการยืนยันการทำงานที่เป็นปกติ
ข้อมูลยกเว้น (Exception data) เพื่อใช้ในการยืนยันการทำงานเมื่อเกิดข้อมูลที่ถูกยกเว้นในการประมวลผล
ข้อมูลผิดพลาด (Error data) เพื่อใช้ในการยืนยันการทำงานสามารถตรวจพบเมื่อเกิดข้อมูลที่ผิดพลาด


* หลังจากทำการทดสอบครั้งแรกกับข้อมูลปกติ จะต้องทำการทดสอบกับข้อมูลยกเว้นและข้อมูลที่ผิดพลาดต่อไป
วิธีการหลักสองวิธีที่ใช้ในการสร้างข้อมูลเพื่อใช้ในการทดสอบแบบกล่องดำคือ การแบ่งข้อมูลออกเป็นส่วนเทียบเท่า (equivalence partitioning) และการวิเคราะห์ค่าขอบเขต (boundary value analysis)

●การแบ่งข้อมูลออกเป็นส่วนเทียบเท่า (Equivalence partitioning) การแบ่งข้อมูลออกเป็นส่วนเทียบเท่า เป็นวิธีการแบ่งข้อมูลเพื่อการอินพุทออกเป็นกลุ่มของข้อมูลที่ถูกต้องยอมรับได้ (valid equivalence class) หรือเป็นกลุ่มข้อมูลที่ไม่ถูกต้องไม่สามารถยอมรับได้ (invalid equivalence class) และเปลี่ยนข้อมูลเหล่านั้นให้อยู่ในรูปแบบข้อมูลตัวแทนของแต่ละกลุ่ม หรือเป็นข้อมูลตัวแทนที่เทียบเท่ากับข้อมูลของกลุ่มนั้น เพื่อใช้เป็นข้อมูลในการทดสอบ ข้อมูลเพื่อใช้ในการทดสอบที่สร้างด้วยวิธีนี้สามารถสร้างได้ง่าย

กลุ่มข้อมูลเทียบเท่าที่ยอมรับได้ Valid equivalence class
ขอบเขตของค่าข้อมูลเพื่อทำการอินพุทได้รับการประมวลผลด้วยกระบวนการปกติ
กลุ่มข้อมูลเทียบเท่าที่ยอมรับไม่ได้ Invalid equivalence class
ขอบเขตของค่าข้อมูลเพื่อทำการอินพุทได้รับการประมวลผลด้วยลักษณะข้อมูลผิดพลาด

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

(4) การดำเนินการทดสอบ (Test execution) การทดสอบประเภทต่างๆ ต่อไปนี้เป็นการทดสอบในการพัฒนาระบบ
• การทดสอบเชิงบูรณาการ หรือการทดสอบรวม (Integration testing หรือ Consolidated testing) การทดสอบประเภทนี้เป็นการทดสอบที่รวมโมดูลและโปรแกรมเข้าไว้ด้วยกัน และเป็นการตรวจสอบรับรองว่าการทำงานรวมของแต่ละโมดูลและโปรแกรมเป็นไปโดยถูกต้องตามที่ได้ออกแบบทางสถาปัตยกรรมซอฟต์แวร์ การทดสอบรวมจะดำเนินการทำงานระหว่างโมดูลและระหว่างโปรแกรมเมื่อทำการทดสอบแต่ละหน่วยเรียบร้อยแล้ว เพื่อสามารถยืนยันได้ว่าการเปลี่ยนแปลงหน้าจอและข้อมูลที่ทำการส่งผ่านระหว่างแต่ละโปรแกรมเป็นไปโดยถูกต้อง การทดสอบรวมในลักษณะนี้ถูกใช้ในการทดสอบโดยแผนกพัฒนาระบบ
การทดสอบเชิงบูรณาการหรือการทดสอบรวม มีการรวมการทดสอบประเภทต่างๆ ดังต่อไปนี้
• การทดสอบแบบบนลงล่าง (top – down testing) การทดสอบแบบบนลงล่าง เป็นการทดสอบตามลำดับที่เริ่มต้นจากโมดูลที่อยู่ในระดับบน โดยในการทดสอบหลายกรณี โมดูลที่อยู่ในระดับต่ำอาจยังไม่เสร็จสมบูรณ์ และเพื่อทำให้สามารถทดสอบด้วยวิธีนี้ได้อาจทำการจัดเตรียมโมดูลย่อยที่สมมติขึ้นชั่วคราว (เรียกว่าสตับ Stub) เพื่อใช้ในการทดสอบในกรณีที่โมดูลที่อยู่ในระดับบนมีการเรียกใช้งาน
•การทดสอบจากล่างขึ้นบน (Bottom-up testing)
การทดสอบจากล่างขึ้นบน เป็นวิธีการในการทดสอบตามลำดับที่เริ่มต้นจากโมดูลในระดับล่าง หากโมดูลในระดับที่สูงกว่ายังไม่เสร็จสมบูรณ์ อาจมีการจัดเตรียมโมดูลชั่วคราวเพื่อใช้ในการทดสอบ เรียกว่า ไดรเวอร์ (driver) ซึ่งอาจถูกเรียกใช้จากโมดูลในระดับที่ต่ำกว่าเพื่อทำการทดสอบ
●การทดสอบระบบ (System testing) หรือการทดสอบแบบครอบคลุม (Comprehensive testing) การทดสอบระบบ เป็นการตรวจสอบเพื่อรับรองความถูกต้องการทำงานของฟังก์ชั่นทั้งหมดตามที่ได้มีการออกแบบไว้ตามของความต้องการในการพัฒนาระบบ (the requirements specification designed) จากการออกแบบสถาปัตยกรรมระบบ การทดสอบแบบนี้จะทำการทดสอบหลังจากทำการรวมหรือบูรณาการโปรแกรมเข้าด้วยกันเพื่อทำการทดสอบรวมเสร็จสิ้นแล้ว และเป็นการทดสอบที่ต้องได้รับความร่วมมือจากทั้งแผนกที่ทำการพัฒนาระบบ และผู้ใช้ระบบ (แผนกผู้ใช้ระบบ)

อ้างอิง
การทดสอบแบบแซนด์วิช (Sandwich testing) การทดสอบแบบแซนด์วิช เป็นวิธีการทดสอบที่รวมการทดสอบแบบบนลงล่าง (top-down) และแบบล่างขึ้นบน (bottom-up) เข้าไว้ด้วยกัน ซึ่งเป็นการทดสอบแบบรวมประเภทหนึ่ง

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

การทดสอบฟังก์ชั่น (Function testing) เพื่อตรวจสอบรับรองว่าได้รวมฟังก์ชั่นที่ต้องการไว้แล้ว

การทดสอบประสิทธิภาพ (Performance testing) เพื่อตรวจสอบรับรองประสิทธิภาพในการประมวลผล (processing performance) รวมถึงเวลาในการตอบสนอง (response time) เวลารวมการตอบสนอง (turnaround time) และประสิทธิผล (throughput) ตามที่ต้องการ

การทดสอบการจัดการข้อยกเว้น (Exception handling testing) เพื่อตรวจสอบรับรองฟังก์ชั่นการประมวลผลความผิดพลาด (error processing functions) และฟังก์ชั่นในการกู้คืน (recovery functions) สามารถทำงานได้เป็นปกติ

การทดสอบภาระงาน (Load testing หรือ Rush testing) เพื่อทดสอบการทำงานของระบบ โดยมอบหมายภาระงานที่มีการอินพุทหรือนำเข้าข้อมูลจำนวนมาก และเพิ่มจำนวนของเครื่องลูกข่ายในการทำงานให้มากที่สุดเพื่อตรวจสอบรับรองว่าระบบยังสามารถทำงานได้ในสภาวะการณ์ที่มีภาระงานสูง

การทดสอบการทำงาน (Operability testing) เพื่อตรวจสอบรับรองว่าระบบง่ายต่อการใช้โดยผู้ใช้ (แผนกผู้ใช้ระบบ)

การทดสอบแบบถดถอย (Regression testing) เพื่อตรวจสอบรับรองว่า ไม่มีโปรแกรมอื่นๆ ได้รับผลกระทบ เมื่อเกิดความผิดพลาดใดๆ ขึ้นในทุกๆ กระบวนการทดสอบที่ถูกปรับเปลี่ยน หรือเมื่อมีการเปลี่ยนแปลงข้อกำหนดใดๆ


การทดสอบการเจาะระบบ(Penetration testing) หรือการทดสอบการบุกรุก (Intrusion testing) เป็นการทดสอบเพื่อค้นหาช่องโหว่ในการรักษาความปลอดภัยของระบบ และจุดอ่อนของไฟร์วอลล์ (ช่องโหว่ vulnerability) จากการโจมตีหรือบุกรุกจากภายนอกที่เกิดขึ้นจริง

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


รายการทดสอบ

ฟังก์ชั่นทางธุรกิจ (Business function) เพื่อตรวจรับรองความครบถ้วนของฟังก์ชั่นที่ต้องการทางธุรกิจ
การทำงาน (Operability)  เพื่อตรวจรับรองว่าระบบง่ายต่อการใช้งานโดยผู้ใช้ (แผนกผู้ใช้ระบบ)
การวัดความผิดปกติ (Anomaly measures) เพื่อตรวจรับรองว่า สามารถตรวจวัดความผิดปกติใดๆ ที่อาจเกิดขึ้น อาทิ ข้อมูลผิดปกติ การทำงานที่ผิดปกติ และอุปกรณ์ผิดปกติ
ประสิทธิผล (Throughput) เพื่อตรวจรับรองประสิทธิผล (throughput) ที่ได้จากระบบเมื่อใช้อุปกรณ์ที่กำหนด
เวลาในการประมวลผล (Processing time) เพื่อตรวจรับรองเวลาในการตอบสนองของระบบอยู่ในขอบเขตที่ยอมรับได้

(5) การประเมินผลการทดสอบ (Test result evaluation) เพื่อสามารถตรวจรับระบบที่ถูกต้องตรงตามความต้องการ จึงต้องให้ความสำคัญกับผลการทดสอบที่น่าพึงพอใจเป็นอันดับแรก จึงจำเป็นต้องพิจารณาเกณฑ์ในการประเมินระบบโดยอ้างอิงจากผลการทดสอบระบบ

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


จำนวนของข้อผิดพลาดที่ยอมรับได้ (Gompertz curve) และยอมรับไม่ได้ (Not a Gompertz curve)

· จำนวนของข้อผิดพลาดที่ยอมรับได้ (Gompertz Curve) หมายถึงจำนวนของข้อผิดพลาดสะสมต้องไม่เพิ่มขึ้นตามระยะเวลาที่เปลี่ยนแปลงไป สามารถหยุดการทดสอบได้ จำนวนของข้อผิดพลาดที่ยอมรับไม่ได้ (Not a Gompert Curve) หมายถึงจำนวนของข้อผิดพลาดสะสมเพิ่มขึ้นตามเวลาที่เปลี่ยนแปลงไป ไม่ต้องทำการทดสอบต่อไป เนื่องจากโปรแกรมมีปัญหาเชิงคุณภาพ

No comments: