Perspective On Testing

Definition of Testing (จำกัดความของ Testing)

• [Hetzel] :
  • Testing is the process of establishing confidence that a program or system does what is supposed to do
  • เป็นกระบวนการสร้างความมั่นใจว่าโปรแกรมหรือระบบที่ทำนั้นทำงานได้จริง
• [Myer 1979] :
  • Testing is the process of executing a program or system with the intent of finding errors
  • เป็นกระบวนการ execute program และหา error ต่างๆ
• [IEEE 1983] :
  • Testing is the process of exercising or evaluating a system by manaual or automated means to verify that it satisfies specified requirements or to identify differences between expected and actual results
  • เป็นกระบวนการ การดำเนินการ หรือ การประเมิน ระบบ ซึ่งอาจทำด้วยมือ หรือ tool ในการตรวจสอบว่าระบบทำงานตามที่ได้กำหนดความต้องการระบบ หรือดูการเปรียบระหว่างผลที่คาดว่าและผลจริง
• [Hetzel 1983] :
  • Testing is any activites aimed at evaluating an attribute or capability of a program or a system
  • คือการทำไปตามวัตถุประสงค์และตรวจสอบความสามารถของโปรแกรมหรือระบบได้

Basic Definitions (คำจำกัดความพื้นฐาน)

• Error (Mistake)
  • เป็นข้อผิดพลาดที่เกิดจาก software developer หรือ ความเข้าใจผิด
• Fault / Defect / Bug
  • เป็นข้อผิดพลาดที่เกิดมาจาก error ทั้งใน software และ documention
  • เป็นเป็น 2 ประเภท
    - faults of commision คือ fault ที่เราทำผิดเอง หาเจอโดยการ review เช่น เครื่องหมายในสมการผิด
    - faults of omision คือ fault ที่ละเว้นไม่ทำ เช่น ใน spec มีสิ่งที่ต้องทำ 4 อย่าง แต่ทำจริงๆ 3 อย่าง
• Failure
  • software ทำงานถูกต้องแต่ไม่ตาม spec
  • software ทำงานถูกต้องแต่เกิด failure เนื่องจาก input data
• Incident
  • คือ อาการ ที่สัมพันธ์กับ failure ที่ถูกรายงานโดย user
• Test case
  • มีการกำหนดค่าต่างๆ และความสัมพันธ์ของพฤติกรรมโปรแกรม
  • มีกลุ่มของ input และ รายการผลลัพธ์ที่คาดว่าจะเกิด (expected ouputs)

Another Definition

• Debugging (Fault Localization) คือกระบวนการหาว่า bug อยู่ส่วนไหนของ code ทั้งทำการแก้ไข และทำการทดสอบอีกครั้งจนกว่าจะไม่มี bug
• Vrification คือกระบวนการพิสูจน์และตรวจสอบผลิตภัณฑ์ว่าทำตามความต้องการของผู้ใช้ครบและถูกต้อง
• Validation คือกระบวนการรับรองและพิสูจน์ผลิตภัณฑ์ว่าทำตามความต้องการของผู้ใช้ครบและถูกต้อง

A Testing Life Cycle

• 3 Phase แรก (จากภาพด้านซ้าย) Bugs ถูกนำเข้า
• Testing Phase นี้ทำการหา Bugs ต่างๆ
• 3 Phase หลัง (จากภาพด้านขวา) Bugs ถูกนำออก

Test Cases

• Test Case คือ case ต่างๆที่เรา เตรียมจะทำการทดสอบ ระบบของเราโดนการเตรียมจะเตรียมทั้ง เหตุการณ์ที่จะเกิดกับระบบ และผลลัพธ์ที่จะเกิดขึ้นกับระบบ หากทำการ test ตามเงื่อนไข แล้ว ผลลัพธ์ได้ตรงตามที่ คาดหมายไว้ถือว่า ผ่าน test cast นั้น แต่หาก ผลลัพธ์ไม่ตรงหรือเกิด error แสดง ว่า Test ไม่ผ่าน
• มี Format หลากหลาย ซึ่งมีรายละเอียดหลักดังตัวอย่างรูปข้างล่างนี้

• มีคำอธิบาย ดังนี้
  • Test Case ID คือ รหัส Test Case
  • Purpose คือ วัตถุประสงค์ว่าทำการทดสอบเรื่องอะไร
  • Pre Conditions คือ เงื่อนไขก่อนทำการทดสอบ csae นี้
  • Inputs คือ ข้อมูลนำเข้าสำหรับการทดสอบ case นี้
  • Expected Outputs คือ ผลลัพธ์ที่คาดว่าจะเกิดหลังทำการทดสอบ case นี้
  • Post Conditions คือ เงื่อนไขหลังทำการทดสอบ csae นี้
  • Execution History คือ ประวัติการทดสอบด้วย case นี้ ซึ่งมีรายละเอียดดังนี้
    • Date คือ วันที่ทำการทดสอบ
    • Result คือ ผลการทดสอบ เช่น ผ่าน ไม่ผ่าน
    • Version คือ เวอร์ชัน
    • Run by คือ ผู้ทำการทดสอบ

Structural and Behavioral View

จากรูปข้างบน มีรายละเอียดดังนี้

• S - ความต้องการของผู้ใช้ (สีน้ำเงิน+สีเหลือง)
• P - สิ่งที่โปรแกรมทำได้ (สีเหลือง+สีเขียว)
• Fault of omission คือ ส่วนสีน้ำเงิน
• Fault of comission คือ ส่วนสีน้ำเขียว
• ส่วนที่โปรแกรมทำงานได้ตามความต้องการผู้ใช้ คือ ส่วนสีเหลือง

Comparing Structural Test Case Identification Methods

จากรูปด้านบน วงกลมสีน้ำตาล คือ test case ที่สามารถทดสอบได้ โดยรูปด้านซ้าย คือ test case ที่ใช้ method A และ รูปด้านขวา คือ test case ที่ใช้ method B ซึ่ง Test case ที่ดีควรต้องทดสอบด้าน spec มากกว่า

Error and Fault Taxonomies

• Process คือ กระบวนการที่ใช้อ้างว่าจะต้องทำอะไร
• Product คือ ผลลัพธ์
• Faults สามารถแบ่งได้หลายประเภทในหลายทาง เช่น
  • กระบวนการของซอฟต์แวร์
  • the consequence of corresponding failures
  • ความยากของการแก้ปัญหา
  • ความเสี่ยง
  • anomaly of occurrence

Faults Classified by Severity

ความรุนแรงแบ่งเป็นประเภทต่างๆ ดังนี้

• Mild คือ การสะกดผิด
• Moderate คือ ข้อมูลซ้ำซ้อน
• Annoying คือ การพิมพ์ผิด เช่น bill for $0.00
• Disturbing คือ บาง transaction ไม่ได้ process
• Serious คือ transaction หายได้
• Very Serious คือ transaction execute ผิด
• Extreme คือ พบ Very Serious บ่อยๆ
• Intolerable คือ Database ไม่สามารถทนได้
• Catastrophic คือ system shutdown
• Infectious คือ shutdown กระจายไปที่อื่นๆ

Software Anomalies

ความผิดพลาดแบ่งเป็น 5 ประเภท ดังนี้

• Input/output faults
• Logic faults
• Computation faults
• Interface faults
• Data faults

Test Case Design Approaches

• Functional (Black-box) Testing
  • based on program โดยพิจารณาแต่ละ function ว่าที่ input value และ output value
  • ไม่รู้ว่า implement ยังไง
  • function ของ back box เข้าใจโดย terms of inputs and outputs
  • test case ถูกออกแบบตาม specification of the software
  • ข้อดี
    • test cases นี้สามารถใช้ได้ตลอดเวลาแม้ว่าการ implement จะเปลี่ยน
    • test cases สามารถสร้างไปพร้อมกับการ implement
  • ข้อเสีย
    • เกิดการ test ซ้ำซ้อนได้
    • ไม่ได้ test ทุกส่วนของ program
• Structural (White-Box, Glass-Box, Clear-Box) Testing
  • รู้ว่า implement ยังไง
  • มีการออกแบบ test case (coverage)
• Functional VS Structural Testing
  • Structural Testing ไม่สามารถทดสอบทุกฟังก์ชั่นที่ implement
  • Functional Testing ไม่สามารถรับประกันว่า ทุก implement จะถูกทดสอบ

Comparing Functiona Test Case Identification Methods

• • test case ใช้วิธี method A ดีกว่าเพราะ cover มากกว่า

Level of Testing

• ระดับของการทดสอบเป็นแบบ V-Model โดยการนำ Development Life Cycle และ Testing Life Cycle มา map กัน ซึ่งการส่งมอบให้ลูกค้าทดสอบเป็น Acceptance Testing

Requirements Phase Testing Activities

• ทำการ Develop prototype เพื่อรู้ความต้องการของ user
• reviews requirements specification ว่ามีความขัดแย้ง กำกวม ไม่สมบูรณ์ ตรงไหน
• spec doc ต้องมี testable
• ต้องทำ design acceptance and system test plan เพราะมี user เข้ามาเกี่ยวข้องด้วย

Design Phase Testing Activities

• ทำการ design review ก็ต่อเมื่อ
  • ทุกๆ ส่วนของ requirement specification มีผลกระทบใน design
  • ทุกๆ ส่วนของ design สามารถตรวจสอบกลับใน requirement specification ได้
• specification ต้องสามารถตรวจหา Logic faults,interface faults, lack of exception handling, and nonconformance ได้
• ต้องทำการวางแผน integration and unit testing

Implement Testing Activities

• จัดการ unit testing แบบ informal และ formal โดยใช้ testing techniques
• ต้องทำ code reviews and inspections

Integration Phase Testing Activies

• integration testing ถูกจัดการหลังจากการทำ functionality
• acceptance testing ถูกทำก่อนที่จะส่งมอบใช้ user

Maintenance Phase Testing

• จะทำการ test เมื่อถ้ามีการเปลี่ยนการ implemented
• จะทำการ test เมื่อถ้าการเปลี่ยนไม่มีผลต่อ product
• จะทำการ test เมื่อ functionality ของ product
• จะต้องทำ Regression testing