ซอฟต์แวร์มีหลายมิติ

มิติง่ายๆ

Functional Test Scenario & Test Case

Non-Functional Test Scenario & Test Case

Test Case

Traceability

Architecture Test Cases

Test Driven Development

1

23

4

55

5

4

จะ Test อะไรกันดี????

จะ Test อะไรกันดี????

Attribute Refinements (Attributes of System Quality)

เทคนิคตีความ •  ช่วงเวลา = Availability •  ความเร็ว/ปริมาณ = Performance •  อนาคตจะมีผู้ใช้/ฟังก์ชั่น/เซอร์วิสเพิ่ม = Scalability •  มีส่วนที่ต้องปรับปรุง/แก้ไข/เพิ่มเติมได้ =

Modifiability •  ซีเรียสเรื่องการเข้าใช้งาน/เข้าถึงข้อมูล = Security •  หน้าจอซับซ้อน/ผู้ใช้หลากหลาย = Usability •  ต้องเชื่อมต่อกับ External Resources =

Integrability •  External Resources หลากหลาย =

Interoperability •  มีการแลกเปลี่ยนข้อมูล/import/export/migrate =

Portability •  ฯลฯ

Simulate Test Environment for “Test Architecture”

Quality Scenarios

Non-Functional Test Case Test  Case  ID:  XXX  Test  Case  Name:  Test  ‘easy  use’  of  cri<cal  form Relevant  Requirement  IDs:

Objec6ves:  เพื่อทดสอบว่าแบบฟอร์มสําคัญของระบบต้องใช้งานง่าย Approaches:  Non-­‐Func6onal  Test:  Usability Required  Input  /  Test  Data:

Expected  Output  /  Outcome: 80% ของผู้ใช้ทั้งหมด ให้คะแนนความง่ายไม่ต่ํากว่า  80 คะแนน No. Ac6vity Pass? Fail? Remark/Condi6on

1.

Test  Case  ID:  XXX  Test  Case  Name:  Test  ‘handling  load’  of  withdraw  request  (16:00  –  18:00) Relevant  Requirement  IDs:

Objec6ves:  เพื่อทดสอบว่าระบบ Core  Bank  System รองรับโหลด  request ‘ถอนเงิน’  ในช่วงเวลา  16:00-­‐18:00  ได้ Approaches:  Non-­‐Func6onal  Test:  Performance  +  Availability  +  Reliability Required  Input  /  Test  Data: จํานวนตู้ทั้งหมด  1,500 ตู้ทั่วประเทศ Expected  Output  /  Outcome: รองรับ  Request ‘ถอนเงิน’  ได้ 40  request/ตู้/ช.ม. ช่วงเวลา  16:00-­‐18:00 No. Ac6vity Pass? Fail? Remark/Condi6on

1.

Non-Functional Test Case Test  Case  ID:  XXX  Test  Case  Name:  Test  ‘avg  response  <me’  aTer  service  increased Relevant  Requirement  IDs:

Objec6ves:  เพื่อทดสอบว่าค่า  response  <me เฉลี่ยของทุก  TX ต้องเท่าเดิม แม้มีบริการเพิ่มขึ้นภายหลัง Approaches:  Non-­‐Func6onal  Test:  Scalability  +  Performance  +  Reliability Required  Input  /  Test  Data:

Expected  Output  /  Outcome: avg  response  <me  <=  X  วินาที  (+/-­‐  Y  วินาที) นับจาก  ATM  -­‐>  CBS  -­‐>  ATM No. Ac6vity Pass? Fail? Remark/Condi6on

1.

Quality Scenarios

Non-Functional Test Case Test  Case  ID:  XXX  Test  Case  Name:  Test  ‘scheduling’  of  load  balancer Relevant  Requirement  IDs:

Objec6ves:  เพื่อทดสอบการ  scheduling ของการ dispatch  request ไปยังเว็บเซิร์ฟเวอร์ Approaches:  Non-­‐Func6onal  Test:  Performance  +  Reliability +  Availability  +  Scalability Required  Input  /  Test  Data:

Expected  Output  /  Outcome: dispatch  ได้สม่ําเสมอ เป็นธรรม!  สมดุลกับ  resource ที่เหลือของเว็บเซิร์ฟเวอร์ No. Ac6vity Pass? Fail? Remark/Condi6on

1.

Quality Scenarios

Non-Functional Test Case Test  Case  ID:  XXX  Test  Case  Name:  Test  ‘balance  of  stateless  object  crea<on’ Relevant  Requirement  IDs:

Objec6ves:  เพื่อทดสอบ latency ในการสร้าง  stateless  object (เช่น XXXWebCMD และ XXXBusinessService) ที่ต้องสมดุลกับปริมาณ  incoming  request Approaches:  Non-­‐Func6onal  Test:  Performance  +  Scalability  +  Availability  +  Reliability Required  Input  /  Test  Data:

Expected  Output  /  Outcome: เมื่อ  client  request มาถึงอ็อบเจ็คต์ที่ต้องการใช้  (a) ต้องใช้เวลาไม่เกิน  x  ms ในการสร้างและเตรียมจน client  request ได้เริ่มใช้  (b)  ตัวอย่างสมการ  b  –  a  <=  x  ms No. Ac6vity Pass? Fail? Remark/Condi6on

1.

Test  Case  ID:  XXX  Test  Case  Name:  Test  ‘offline  locking  strategy’  of  shared  resource  (MFU)  for  upexpected  TX Relevant  Requirement  IDs:

Objec6ves:  เพื่อทดสอบการเข้าถึง  shared  resource ที่ถูกเข้าถึงบ่อยๆ โดย  TX คาดการณ์ไม่ได้ว่าจะ  commit เมื่อไหร่ Approaches:  Non-­‐Func6onal  Test:  Availability Required  Input  /  Test  Data:

Expected  Output  /  Outcome: offline  locking  strategy ต้องเป็น  op<mis<c  lock No. Ac6vity Pass? Fail? Remark/Condi6on

1.

Quality Scenarios

Non-Functional Test Case Test  Case  ID:  XXX  Test  Case  Name:  Test  size  of  ‘unwanted’  data  sending  from  service  to  client Relevant  Requirement  IDs:

Objec6ves:  เพื่อทดสอบการขนาดข้อมูลที่ส่งจากเซอร์วิสกลับไปยังไคลเอ็นต์ ซึ่งเป็นข้อมูลส่วนที่ไคลเอ็นต์ไม่ต้องการใช้ Approaches:  Non-­‐Func6onal  Test:  Performance  +  Availability Required  Input  /  Test  Data:

Expected  Output  /  Outcome: size  of  unwanted  data  =  0  byte! No. Ac6vity Pass? Fail? Remark/Condi6on

1.

Test  Case  ID:  XXX  Test  Case  Name:  Test  ‘Data  Source’s configura<on’  modifica<on  online Relevant  Requirement  IDs:

Objec6ves:  เพื่อทดสอบการแก้ไขค่าคอนฟิกฯ ของ  Data  Source ขณะออนไลน์ โดยไม่ต้อง  shutdown  system

Approaches:  Non-­‐Func6onal  Test:  Modifiability  +  Availability Required  Input  /  Test  Data:

Expected  Output  /  Outcome: repair  <me  =  0  วินาที No. Ac6vity Pass? Fail? Remark/Condi6on

1.

Non-Functional Test Case Test  Case  ID:  XXX  Test  Case  Name:  Test  ‘evic<on’  of  LRU  resource  in  pool  and  cache Relevant  Requirement  IDs:

Objec6ves:  เพื่อทดสอบการ ‘เคลียร์’ resource ที่ไม่ค่อยได้ใช้ออกจาก  pool และ  cache Approaches:  Non-­‐Func6onal  Test:  Performance  +  Availability +  Scalability Required  Input  /  Test  Data:

Expected  Output  /  Outcome: evict/passivate/swap  out/delete/serialize  ทันทีเมื่อ  resource นั้นครบ  idle  <me  out ตามที่คอนฟิกฯ ไว้ No. Ac6vity Pass? Fail? Remark/Condi6on

1.

Non-Functional Test Case Test  Case  ID:  XXX  Test  Case  Name:  Test  ‘evic<on’  of  LRU  resource  in  pool  and  cache Relevant  Requirement  IDs:

Objec6ves:  เพื่อทดสอบการ ‘เคลียร์’ resource ที่ไม่ค่อยได้ใช้ออกจาก  pool และ  cache Approaches:  Non-­‐Func6onal  Test:  Performance  +  Availability +  Scalability Required  Input  /  Test  Data:

Expected  Output  /  Outcome: evict/passivate/swap  out/delete/serialize  ทันทีเมื่อ  resource นั้นครบ  idle  <me  out ตามที่คอนฟิกฯ ไว้ No. Ac6vity Pass? Fail? Remark/Condi6on

1.