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

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

4. มิติง่ายๆ

5. Functional Test Scenario &
Test Case

6. Non-Functional Test Scenario
& Test Case

7. Test Case

8. Traceability

9. Architecture Test Cases

10. Test Driven Development
4
1 5
5 5
3
2
4

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

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

13. Attribute Refinements (Attributes
of System Quality)

14. เทคนิคตีความ
• ช่วงเวลา = Availability
• ความเร็ว/ปริมาณ = Performance
• อนาคตจะมีผู้ใช้/ฟังก์ชั่น/เซอร์วิสเพิ่ม = Scalability
• มีส่วนที่ต้องปรับปรุง/แก้ไข/เพิ่มเติมได้ =
Modifiability
• ซีเรียสเรื่องการเข้าใช้งาน/เข้าถึงข้อมูล = Security
• หน้าจอซับซ้อน/ผู้ใช้หลากหลาย = Usability
• ต้องเชื่อมต่อกับ External Resources =
Integrability
• External Resources หลากหลาย =
Interoperability
• มีการแลกเปลี่ยนข้อมูล/import/export/migrate =
Portability

15. Simulate Test Environment for
“Test Architecture”

16. Quality Scenarios

17. 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

18. 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.

19. Quality Scenarios

20. 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.

21. Quality Scenarios

22. 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

23. Quality Scenarios

24. 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

25. 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.

26. 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.