ออกแบบ Test Cases เพื่อทำ Non-Functional Test โดย คุณณรงค์ จันทร์สร้อย

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

มิติง่ายๆ

Functional Test Scenario & Test Case

Non-Functional Test Scenario & Test Case

Test Case

Traceability

Architecture Test Cases

Test Driven Development 4 1 5 5 5 32 4

จะ 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 CaseTest 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

Non-Functional Test CaseTest 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 CaseTest 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 CaseTest 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 ‘oﬄine 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: oﬄine locking strategy ต้องเป็น op<mis<c lock No. Ac6vity Pass? Fail? Remark/Condi6on

Quality Scenarios

Non-Functional Test CaseTest 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

Non-Functional Test CaseTest 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.

ออกแบบ Test Cases เพื่อทำ Non-Functional Test โดย คุณณรงค์ จันทร์สร้อย

by Prathan D. on May 20, 2012

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 525

Statistics

ออกแบบ Test Cases เพื่อทำ Non-Functional Test โดย คุณณรงค์ จันทร์สร้อย Presentation Transcript