Upload
prathan-d
View
7.588
Download
1
Embed Size (px)
DESCRIPTION
ออกแบบ Test Cases เพื่อทำ Non-Functional Test โดย คุณณรงค์ จันทร์สร้อย
Citation preview
ซอฟต์แวร์มีหลายมิติ
มิติง่ายๆ
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.