Development testing Development testing
- Development testing ประกอบด้วยกิจกรรมการทดสอบทั้งหมดที่ดำเนินการโดยทีมพัฒนาระบบ
- Unit testing
- Unit testing แต่ละหน่วยย่อยโปรแกรมหรือคลาสของวัตถุจะได้รับการทดสอบ
- Unit testing ควรเน้นการทดสอบฟังก์ชันการทำงานของ object หรือ method
- Component testing
- เป็นการทดสอบชิ้นส่วนซึ่งมีการรวมหน่วยต่าง ๆ ไว้หลายชิ้นเพื่อสร้าง composite components
- การทดสอบส่วนประกอบควรมุ่งเน้นไปที่การทดสอบ interface ระหว่าง components
- System testing
- ส่วนประกอบบางส่วนหรือทั้งหมดของระบบถูกรวมเข้าด้วยกันและทดสอบระบบโดยรวม
- การทดสอบระบบควรเน้นการทดสอบการโต้ตอบระหว่างส่วนประกอบต่าง ๆ Unit testing
- Unit testing เป็นขั้นตอนการทดสอบส่วนประกอบแต่ละชิ้นโดยแยกออกจากกัน
- เป็นกระบวนการทดสอบข้อบกพร่อง
- Unit อาจหมายถึง
- Function หรือ method ภายในวัตถุ
- Object classes ที่มี attributes และ methods อยู่ภายใน
- Composite components ที่มี interface ที่กำหนดไว้ เพื่อเข้าถึงฟังก์ชันการทำงานของพวกมัน Object class testing
- ครอบคลุมการทดสอบทั้งหมดของ class
- ทดสอบการทำงานทั้งหมดที่เกี่ยวข้องกับ object
- การตั้งค่าและการสอบถามคุณลักษณะทั้งหมดของ object
- การใช้ object ในทุกสภาวะที่เป็นไปได้
- การสืบทอดคลาส (Inheritance) ทำให้การออกแบบการทดสอบในวัตถุทำได้ยากลำบากยิ่งขึ้น เนื่องจากข้อมูลที่จะทดสอบอาจจะไม่ใช่ข้อมูล localized ของวัตถุนั้น Case study: The weather station object interface Weather station testing
- ต้องกำหนด test cases สำหรับ reportWeather, calibrate, test, startup และ shutdown
- ใช้แบบจำลอง state model เพื่อระบุลำดับของการเปลี่ยนสถานะที่จะทดสอบและลำดับเหตุการณ์จะทำให้เกิดการเปลี่ยนเหล่านั้น
- ตัวอย่างเช่น:
- Shutdown -> Running-> Shutdown
- Configuring-> Running-> Testing -> Transmitting -> Running
- Running-> Collecting-> Running-> Summarizing -> Transmitting -> Running
Automated testing
- ทุกโอกาสที่เป็นไปได้ การทดสอบ unit testing ควรเป็นแบบอัตโนมัติ เพื่อให้การทดสอบดำเนินไปและตรวจสอบโดยไม่มีการแทรกแซงโดยมนุษย์
- ในการทดสอบ unit testing โดยอัตโนมัติ เราจะใช้ test automation framework (เช่น JUnit) เพื่อเขียนและรันการทดสอบโปรแกรมให้เรา
- Unit testing frameworks มี test class ทั่วไปที่เราสามารถ extend เพื่อสร้าง test case จากนั้นพวกมันจะเรียกใช้ (run) การทดสอบทั้งหมดที่เราเขียนขึ้น และรายงานผลการทดสอบออกมา Automated test components
- ส่วนการติดตั้ง (setup part)
- จะเริ่มต้นระบบด้วยกรณีทดสอบ ได้แก่ อินพุตและเอาท์พุตที่คาดหวัง
- ส่วนการเรียกใช้ (calling part)
- จะเรียกใช้งาน object หรือ method ที่จะทดสอบ
- ส่วนยืนยันผลการเปรียบเทียบ (assertion part)
- จะเปรียบเทียบผลของการเรียกใช้งานกับผลลัพธ์ที่คาดหวังไว้
- ถ้าการการเปรียบเทียบยืนยันว่าเป็นความจริงการทดสอบนี้ประสบความสำเร็จถ้าเป็นเท็จแล้วก็จะล้มเหลว Choosing unit test cases
- เมื่อใช้ test cases ตามที่กำหนดไว้ component ที่กำลังทดสอบจะต้องทำในสิ่งที่คาดหวัง
- หากมีข้อบกพร่องใด ๆ ใน component ควรถูกตรวจพบโดย test cases
- การทดสอบ unit test มี 2 กรณี
- กรณีแรกควรสะท้อนถึงการทำงานโดยปกติของโปรแกรม และควรแสดงให้เห็นว่าส่วนประกอบทำงานได้ตามที่คาดไว้
- กรณีที่สองจะขึ้นอยู่กับประสบการณ์การทดสอบ
- โดยทั่วไป ควรใช้อินพุตที่ผิดปกติเพื่อตรวจสอบว่าได้รับการประมวลผลอย่างถูกต้องโดย component และไม่ทำให้ component นั้นเสียหาย Testing strategies
- Partition testing
- อินพุตที่มีลักษณะเหมือนกัน ควรได้รับการประมวลผลในลักษณะเดียวกัน
- Guideline-based testing
- การทดสอบตามเกณฑ์ จะใช้หลักเกณฑ์ในการทดสอบเพื่อเลือก test case
- Guideline เหล่านี้มักได้จากประสบการณ์เกี่ยวกับข้อผิดพลาดประเภทต่าง ๆ ที่โปรแกรมเมอร์มักเจอและใช้แก้ปัญหาในการพัฒนา components Partition testing
- ข้อมูล input และ output มักจะถูกนำไปใช้ในหลาย ๆ class และสมาชิกใน class ทั้งหมดมีความเกี่ยวข้องกัน
- แต่ละ class เหล่านี้เป็นพาร์ติชันหรือโดเมนที่เท่าเทียมกัน ซึ่งโปรแกรมทำงานในลักษณะที่เทียบเท่ากันสำหรับสมาชิกทั้งหมดของ class
- ควรเลือก test case จากแต่ละพาร์ติชัน Equivalence partitioning Equivalence partitions Testing guidelines (sequences)
- ทดสอบซอฟต์แวร์ด้วยลำดับ (sequences) ที่มีเพียงค่าเดียว
- ใช้ลำดับขนาดต่าง ๆ กัน ในการทดสอบที่แตกต่างกัน
- ทำการทดสอบเพื่อให้สามารถเข้าถึงองค์ประกอบลำดับแรกกลางและสุดท้ายของลำดับได้
- ทดสอบด้วยลำดับของความยาวเป็นศูนย์ General testing guidelines
- เลือกอินพุตที่บังคับให้ระบบสร้างข้อความแสดงข้อผิดพลาดทั้งหมด
- ออกแบบอินพุทที่ทำให้บัฟเฟอร์อินพุตเกิดการ overflow
- ใช้งานอินพุทเดียวกันหรือ series ของอินพุตซ้ำหลายๆ ครั้ง
- บังคับให้ component สร้างผลลัพธ์ที่ไม่ถูกต้องขึ้นมา
- บังคับให้ผลการคำนวณมีขนาดใหญ่เกินไปหรือเล็กเกินไป Component testing
- Software components มักประกอบขึ้นจาก components ที่สร้างจาก object จำนวนหนึ่งที่มีการโต้ตอบซึ่งกันและกันในรูปแบบต่าง ๆ
- ตัวอย่างเช่นในระบบ weather station นั้น reconfiguration component ประกอบด้วย object ที่เกี่ยวข้องกับแต่ละด้านของ reconfiguration
- เราสามารถเข้าถึงฟังก์ชันการทำงานของ object เหล่านี้ผ่าน interface ของ component ที่กำหนด
- การทดสอบ composite component ควรเน้นที่การแสดงให้เห็นว่า interface ของส่วนประกอบทำงานได้ตามข้อกำหนด
- ทั้งนี้อยู่บนข้อสันนิษฐานว่ามีการทดสอบ unit test ของแต่ละ object ภายใน component เหล่านั้นมาเสร็จสิ้นเป็นที่เรียบร้อยแล้ว Interface testing
- วัตถุประสงค์คือเพื่อตรวจจับข้อผิดพลาดอันเนื่องมาจากข้อผิดพลาดของ interface หรือทดสอบข้อสันนิษฐานเกี่ยวกับ interface นั้น
- ชนิดของ interface
- Parameter interfaces เป็นข้อมูลที่ส่งผ่านจาก method หรือ procedure หนึ่งไปยังอีก procedure หนึ่ง
- Shared memory interfaces เป็นหน่วยความจำที่ใช้ร่วมกันระหว่าง procedures หรือ functions
- Procedural interfaces เป็น sub-system ที่ encapsulate ชุดของ procedures ที่จะเรียกโดย sub-system อื่น ๆ
- Message passing interfaces เป็น sub-system ที่ขอบริการจาก sub-system อื่น ๆ Interface testing Interface errors
- ใช้งาน interface ผิดวิธี
- Component เรียกใช้ component อื่นและทำให้เกิดข้อผิดพลาดในการใช้ interface เช่น พารามิเตอร์ผิดพลาด
- ความเข้าใจผิดเกี่ยวกับ interface
- Component ที่เป็นผู้เรียกมีข้อสันนิษฐานเกี่ยวกับลักษณะการทำงานของ component ที่เรียกอย่างไม่ถูกต้อง
- ข้อผิดพลาดด้านเวลา
- Component ผู้เรียกและผู้ถูกเรียกทำงานด้วยความเร็วที่แตกต่างกันและใช้งานข้อมูลที่ไม่อัพเดต (ตามวงรอบการทำงาน) Interface testing guidelines
- ออกแบบ test เพื่อให้พารามิเตอร์ของ procedure ที่ถูกเรียกอยู่ในช่วงปลายสุดของ range
- ทดสอบ pointer เสมอโดยใช้ค่า null
- ออกแบบ test ซึ่งทำให้ component ทำงานไม่ผ่าน
- ใช้ stress testing ในระบบส่งข้อความ
- ในระบบหน่วยความจำร่วมกัน (shared memory systems) ให้เปลี่ยนแปลงลำดับการทำงานของ component System testing
- การทดสอบระบบในระหว่างการพัฒนาเกี่ยวข้องกับการรวม component เพื่อสร้างเวอร์ชันของระบบแล้วจึงทดสอบระบบรวม
- สิ่งที่มุ่งเน้นในการทดสอบระบบคือ การทดสอบปฏิสัมพันธ์ระหว่าง component ต่างๆ
- การทดสอบระบบตรวจสอบว่า component สามารถทำงานร่วมกันได้อย่างถูกต้องและส่งข้อมูลที่ถูกต้องในเวลาที่เหมาะสมผ่าน interface ของตน
- การทดสอบระบบทดสอบพฤติกรรมที่เกิดขึ้นใหม่ของระบบ ซึ่งต่างไปจาก component เดี่ยว ๆ System and component testing
- ในระหว่างการทดสอบระบบนั้น component ที่พัฒนาขึ้นโดยเฉพาะ รวมทั้ง component ที่นำมา reuse และระบบ off-the-shelf อาจรวมเข้าด้วยกัน
- เมื่อทดสอบส่วนย่อยเสร็จ เราอาจถือได้ว่าระบบที่สมบูรณ์ได้รับการทดสอบแล้ว
- Component ที่พัฒนาขึ้นโดยสมาชิกในทีมหรือทีมย่อยต่าง ๆ อาจรวมอยู่ในขั้นตอนนี้ การทดสอบระบบใช้ทรัพยากรส่วนรวมมากกว่าแต่ละขั้นตอน
- ในบางบริษัท การทดสอบระบบอาจเกี่ยวข้องกับทีมทดสอบที่แยกออกไปต่างหาก โดยไม่มีส่วนเกี่ยวข้องกับนักออกแบบและนักเขียนโปรแกรม Use-case testing
- Use-case ที่ถูกพัฒนาขึ้นมาเพื่อระบุปฏิสัมพันธ์ในระบบ สามารถใช้เป็นพื้นฐานสำหรับการออกแบบการทดสอบระบบ
- แต่ละ Use-case มักจะเกี่ยวข้องกับองค์ประกอบของระบบหลายอย่าง ดังนั้น ในการทดสอบระบบต้องบังคับให้ปฏิสัมพันธ์เหล่านี้เกิดขึ้นให้ครบถ้วน
- Sequence diagram ที่เชื่อมโยงกับ use-case จะอธิบายถึงส่วนประกอบและปฏิสัมพันธ์ที่จะต้องได้รับการทดสอบ Collect weather data sequence chart Test cases derived from sequence diagram
- อินพุทคำขอสำหรับรายงานควรมี acknowledgement ที่เกี่ยวข้อง (รายงานควรได้รับการส่งกลับมายังการร้องขอ)
- ควรสร้างข้อมูลสรุปที่สามารถใช้เพื่อตรวจสอบว่ามีการจัดระเบียบรายงานอย่างถูกต้อง
- คำขอทางด้านอินพุทสำหรับรายงานถูกส่งไปยัง WeatherStation ส่งผลให้รายงานสรุปถูกสร้างขึ้น
- สามารถทดสอบโดยการสร้างข้อมูลดิบที่สอดคล้องกับข้อมูลสรุปที่ได้เตรียมไว้ Testing policies
- เป็นไปไม่ได้ที่จะทำการทดสอบระบบได้อย่างครบถ้วนสมบูรณ์ ดังนั้นจึงอาจมีการดนโยบายในการทดสอบ ซึ่งกำหนดให้มีความครอบคลุมการทดสอบระบบเท่าที่จำเป็น
- ตัวอย่างของนโยบายการทดสอบ:
- ควรทดสอบระบบทั้งหมดที่เข้าถึงได้ผ่านทางเมนู
- ต้องมีการทดสอบชุดค่าผสมของฟังก์ชัน (เช่นการจัดรูปแบบข้อความ) ที่เข้าถึงได้ผ่านเมนูเดียวกัน
- เมื่อมีการป้อนข้อมูลจากผู้ใช้ระบบจะต้องทดสอบฟังก์ชันทั้งหมดด้วยอินพุตที่ถูกต้องและไม่ถูกต้อง