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

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

on

  • 7,812 views

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

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

Statistics

Views

Total Views
7,812
Views on SlideShare
7,209
Embed Views
603

Actions

Likes
3
Downloads
167
Comments
2

1 Embed 603

http://www.welovebug.com 603

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • ซอฟต์แวร์มีหลายมิต ิ
  • มิติง่ายๆ
  • 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 อะไรกันดี????
  • จะ 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  ‘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
  • 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.
  • 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.