Test cases
Download
1 / 110

การออกแบบงานวิจัย และการสร้าง Test Cases ในการทดสอบ - PowerPoint PPT Presentation


  • 99 Views
  • Uploaded on

การออกแบบงานวิจัย และการสร้าง Test Cases ในการทดสอบ. อาจารย์ ดร. ชลทิพย์ ยาวุธ อาจารย์ ดร. ผุสดี บุญรอด. Reading Unit in Information Technology Faculty of Information Technology King Mongkut's University of Technology North Bangkok. การออกแบบงานวิจัย ( Research Design ).

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' การออกแบบงานวิจัย และการสร้าง Test Cases ในการทดสอบ' - keilah


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Test cases

การออกแบบงานวิจัยและการสร้าง Test Cases ในการทดสอบ

อาจารย์ ดร. ชลทิพย์ ยาวุธ

อาจารย์ ดร. ผุสดี บุญรอด

Reading Unit in Information TechnologyFaculty of Information TechnologyKing Mongkut's University of Technology North Bangkok


Research design
การออกแบบงานวิจัย (Research Design)

การสรางบานเพื่อใหไดตามความตองการของเจาของบาน ก็จะตองมีการจัดทําแบบแปลน (Plan) ซึ่งจะถูกเขียนขึ้นโดยสถาปนิกดวยการ พูดคุยกับเจาของบานวา ตองการบานกี่ชั้น กี่ หองนอน กี่หองน้ำ เพื่อจะใหสถาปนิกไดนําแนวความคิดดังกล่าวไปวิเคราะหและออกแบบบ้าน (Design)

จากสไลด์ การเลือกปญหาและการออกแบบการวิจัย โดย รศ.ดร.จุมพล วิเชียรศิลป์


ความหมายของการออกแบบงานวิจัย

การออกแบบงานวิจัย หมายถึง การกําหนดโครงสรางและรายละเอียด แนวทางการดําเนินการในการวิจัย เพื่อจะนําไปสูการทําวิจัยที่เปนไปตามวัตถุประสงคที่กําหนดไวอยางถูกตอง


ประโยชนของการออกแบบงานวิจัยประโยชนของการออกแบบงานวิจัย

  • ทําใหผูวิจัยควบคุมคาความแปรปรวนตางๆ ไดถูกตอง

  • ชวยใหผูวิจัยเห็นแนวทางในการดําเนินการวิจัย อันจะนําไปสูการตอบคําถาม หรือ การพิสูจนสมมติฐานที่กําหนดไว

  • ชวยใหทราบรายละเอียดเกี่ยวกับเวลา กําลังคน งบประมาณ

  • ชวยใหกําหนดขนาดหรือสภาพของเครื่องมือที่จะใชในการวิจัย

  • ชวยใหมองเห็นวาผลการวิจัยจะสามารถนําไปใชเปนนัยสําคัญไดในดานใด


ขอควรคํานึงในการออกแบบงานวิจัยขอควรคํานึงในการออกแบบงานวิจัย

  • กําหนดวัตถุประสงคของหัวขอที่จะทําการวิจัยอยางชัดเจน

  • กําหนดขอบเขตและขอจํากัดของการวิจัย

  • กําหนดตัวแปรตางๆ ตัวแปรตน ตัวแปรตาม

  • ตั้งสมมติฐาน หรือ ผลที่ตองการทราบ


ขอควรคํานึงในการออกแบบงานวิจัยขอควรคํานึงในการออกแบบงานวิจัย

  • กําหนดประชากร และ กลุมตัวอยาง

  • การเก็บขอมูล

  • สถิติ

  • ผานการตรวจจากผูเชี่ยวชาญหรือยัง


เครื่องมือที่ใช้ในการออกแบบเครื่องมือที่ใช้ในการออกแบบ

  • E-R Diagram (ERD)

  • Data Dictionary : DD

  • Data Flow Diagram

  • Unified Modeling Language (UML)

  • สมมติการวิจัย

  • แบบสอบถาม


E r diagram erd
E-R Diagram (ERD)เครื่องมือที่ใช้ในการออกแบบ

  • คือ แบบจำลองที่ใช้อธิบายโครงสร้างของฐานข้อมูลที่ออกแบบขึ้น ซึ่งเขียนออกมาในลักษณะของรูปภาพ

  • ใช้สำหรับการออกแบบฐานข้อมูลในระดับ Conceptual Level

  • เมื่อนำมาเขียนแสดงเป็นแผนภาพ เรียกว่า ERD (Entity Relationship Diagram)

  • จะช่วยให้การอกแบบได้ง่ายขึ้นด้วยการจัดระเบียบความคิดของคนที่ทำการออกแบบ และลดความซับซ้อนของระบบได้เป็นอย่างดี


Examples
Examples…เครื่องมือที่ใช้ในการออกแบบ

GPA

Regist_no

Stu_lname

Major_no

Fac_name_t

Stu_name

Fac_no

Fac_name_e

Fac_name_a

Stu_no

Level_no

Fac_no

Student

n

1

Faculty

1

n

1

have

Regist_no

1

1

regist

Stu_no

study

have

have

Major_no

1

Subject_no

Registration

1

n

Maor_name_e

n

Semester

have

1

Level

Major

Major_name_t

Fac_no

Year

Major_name_a

Level_Desc

Level_no

Level_name

Fac_no


พจนานุกรมข้อมูลเครื่องมือที่ใช้ในการออกแบบ

  • พจนานุกรมข้อมูล(Data Dictionary : DD)เป็นการทำเอกสาร อ้างอิง เพื่อช่วยอธิบายส่วนประกอบของข้อมูลในระบบที่กำลัง ศึกษาอยู่ ซึ่งผังภาพการไหลข้อมูลมิได้อธิบายไว้


Users
ตัวอย่าง เครื่องมือที่ใช้ในการออกแบบUsers


Data flow diagram dfd
Data Flow Diagram (DFD)เครื่องมือที่ใช้ในการออกแบบ

  • A graphic tool used to portray the flow of data through a system.

  • For documenting the old system as well as beginning to create the new one.

  • Shows a highly useful partitioning of the system into tasks (activities, functions) and subtasks.


Context diagram
Context Diagramเครื่องมือที่ใช้ในการออกแบบ


Dfd level 0
DFD เครื่องมือที่ใช้ในการออกแบบLevel 0


Dfd level 1 process 1
DFD Level 1 Process 1เครื่องมือที่ใช้ในการออกแบบ


Dfd level 1 process 2
DFD Level 1 Process 2เครื่องมือที่ใช้ในการออกแบบ


Dfd level 1 process 3
DFD Level 1 Process 3เครื่องมือที่ใช้ในการออกแบบ


Dfd level 1 process 4
DFD Level 1 Process 4เครื่องมือที่ใช้ในการออกแบบ


Dfd level 1 process 5
DFD Level 1 Process 5เครื่องมือที่ใช้ในการออกแบบ


Unified modeling language uml
Unified Modeling Language (UML)เครื่องมือที่ใช้ในการออกแบบ

  • UML เป็นภาษารูปภาพมาตรฐาน (Standard Modeling Language) สำหรับใช้ในการสร้างโมเดลเชิงวัตถุ

  • UML เป็นเสมือนพิมพ์เขียวที่แสดงภาพรวมของระบบทั้งหมด โดยจะแสดงในรูปแบบของแผนภาพ (Diagram) เพื่อให้เกิดความเข้าใจที่ตรงกันระหว่างผู้ออกแบบระบบ, โปรแกรมเมอร์และผู้ใช้งาน


Use case diagram
Use Case Diagramเครื่องมือที่ใช้ในการออกแบบ

ตัวอย่าง Use Case การสั่งซื้อสินค้าทางโทรศัพท์


Activity diagram
Activity Diagramเครื่องมือที่ใช้ในการออกแบบ

  • Activity Diagram เป็นแผนภาพที่ใช้ที่แสดงขั้นตอนการทำงานของ use case (เช่นเดียวกับ Sequence Diagram และ Collaboration Diagram) แต่จะเน้นไปที่งานย่อยของวัตถุ โดยจะมีกระบวนการทำงานคล้ายกับ Flowchart

  • Activity Diagram บางครั้งมีลักษณะคล้าย Swimlane โดยจะแบ่งกลุ่มกิจกรรมที่เกิดขึ้นเป็นช่อง โดยกำกับแต่ละช่องด้วยชื่อของ Object แต่ละ Swimlane แสดงถึงกิจกรรมที่เกิดขึ้นกับ Object นั้นๆ


Activity diagram1
Activity Diagramเครื่องมือที่ใช้ในการออกแบบ

ตัวอย่าง Activity Diagram การสอบถามยอดบัญชีจากตู้ ATM


Class diagram
Class Diagramเครื่องมือที่ใช้ในการออกแบบ

  • Class Diagram คือ แผนภาพที่ใช้แสดง Class และ ความสัมพันธ์ระหว่าง Class ของระบบที่สนใจ (Problem Domain) เช่น ในระบบจัดซื้อ Class ที่เกี่ยวข้องคือ ผู้ผลิต, พนักงานจัดซื้อ, ใบสั่งซื้อ, ใบเสนอราคา, ใบเสร็จรับเงิน เป็นต้น


Class diagram1

Nameเครื่องมือที่ใช้ในการออกแบบ

Attributes

Methods

Class Diagram

  • สัญญลักษณ์ Class ประกอบด้วย

    • Class Name คือ ชื่อของ Class

    • Attributes คือ คุณลักษณะของ Class

    • Operations หรือ Methods คือ กิจกรรมที่สามารถกระทำกับObject นั้นๆได้


Class diagram2
Class Diagramเครื่องมือที่ใช้ในการออกแบบ

ตัวอย่าง Class Diagram ในระบบธนาคาร


Sequence diagram
Sequence Diagramเครื่องมือที่ใช้ในการออกแบบ

  • Sequence Diagram เป็นแผนภาพที่ใช้อธิบายการทำงานของ Use Case เพื่อแสดงถึงขั้นตอนการทำงานและลำดับของการสื่อสาร (Message) ระหว่าง Object ที่ตอบโต้กัน

  • Sequence Diagram จะแสดงอยู่ในรูปแบบ 2 มิติ โดยเส้นประแนวตั้ง (Lifeline) จะนำเสนอในด้านเวลา ส่วนเส้นแนวนอน (Message) จะนำเสนอเกี่ยวกับการโต้ตอบกันระหว่าง Object หรือ Class ต่างๆ


Sequence diagram1
Sequence Diagramเครื่องมือที่ใช้ในการออกแบบ

ตัวอย่าง Sequence Diagram การสอบถามยอดบัญชีจากตู้ ATM


Collaboration diagram
Collaboration Diagramเครื่องมือที่ใช้ในการออกแบบ

  • Collaboration Diagram เป็นแผนภาพชนิดเดียวกับ Sequence Diagram โดยSequence Diagram จะเป็นแผนภาพที่แสดงถึงการสื่อสาร แต่ Collaboration Diagram จะนำเสนอการทำงานร่วมกันระหว่าง Object เป็นหลัก แต่ก็สามารถแสดงถึงลำดับก่อนหลังด้วย


Collaboration diagram1
Collaboration Diagramเครื่องมือที่ใช้ในการออกแบบ

ตัวอย่าง Collaboration Diagram การสอบถามยอดบัญชีจากตู้ ATM


Statechart diagram
Statechart Diagramเครื่องมือที่ใช้ในการออกแบบ

  • Sequence Diagram เป็นแผนภาพที่ใช้แสดงสถานะต่างๆและการเปลี่ยนสถานะของ Class ตั้งแต่เริ่มต้นจนสิ้นสุด

ตัวอย่าง Statechart Diagram การเปิดเครื่องคอมพิวเตอร์


Component diagram
Component Diagramเครื่องมือที่ใช้ในการออกแบบ

  • Component Diagram เป็นแผนภาพที่แสดงโครงสร้างและความสัมพันธ์ระหว่างองค์ประกอบ (Components) ต่างๆของ Software ซึ่งองค์ประกอบดังกล่าวอาจเป็น Source Code, Executable Program, Binary รวมถึง Text และ User Interface


Component diagram1
Component Diagramเครื่องมือที่ใช้ในการออกแบบ

ตัวอย่าง Component Diagram ของระบบการลงทะเบียน


Deployment diagram
Deployment Diagramเครื่องมือที่ใช้ในการออกแบบ

  • Deployment Diagram เป็นแผนภาพที่แสดงสถาปัตยกรรมของ Hardware และ Software ในระบบรวมทั้งความสัมพันธ์ระหว่าง


สมมติการวิจัยเครื่องมือที่ใช้ในการออกแบบ


สมมติการวิจัย เครื่องมือที่ใช้ในการออกแบบ(ต่อ)


สมมติการวิจัย เครื่องมือที่ใช้ในการออกแบบ(ต่อ)


ตัวอย่างการเขียนอ้างอิงสูตรตัวอย่างการเขียนอ้างอิงสูตร

การสร้างตัวแบบการจัดซื้อ จะเกี่ยวข้องกับการจัดซื้อ

และต้นทุนรวม [12] ซึ่งแสดงได้ดังสมการที่ 2-1

ต้นทุนรวม (TC) = (2-1)

ใช้ Equation พิมพ์เท่านั้น ห้าม Copy


ตัวอย่างเกณฑ์การให้คะแนนของแบบสอบถามตัวอย่างเกณฑ์การให้คะแนนของแบบสอบถาม

ตารางที่ 1เกณฑ์การให้คะแนนของแบบสอบถาม


ตัวอย่างเกณฑ์ในการแปลผลแบบสอบถามตัวอย่างเกณฑ์ในการแปลผลแบบสอบถาม

ตารางที่ 2เกณฑ์การให้คะแนนเพื่อประเมินความพึงพอใจของผู้ใช้


Story board
ตัวอย่างการออกแบบ ตัวอย่างเกณฑ์ในการแปลผลแบบสอบถามStory Board

........

XXXXXXXXXXXXXXXXXXXX


Diagram
ปัญหาในการออกแบบและเขียน Diagram

  • เลือก Diagram ไม่เหมาะสมกับงานที่จะทำ

  • ใช้สัญลักษณ์ไม่ถูกต้อง

  • เขียนขอบเขตงานไม่ละเอียด

  • เส้นไม่ Balance

  • แต่ละ Diagram ข้อมูลไม่สอดคล้องกัน

  • ออกแบบฐานข้อมูลไม่ Normalization

  • ออกแบบหน้าตาโปรแกรมไม่เหมาะกับงานที่จะทำ

  • อื่นๆ


การออกแบบงานวิจัยเกี่ยวกับเครือข่ายการออกแบบงานวิจัยเกี่ยวกับเครือข่าย

  • Performance comparison

  • Implement

  • New Approach

  • Improvement

  • Analysis

  • Study

  • Trend

  • Survey


Performance comparison
Performance comparisonการออกแบบงานวิจัยเกี่ยวกับเครือข่าย

  • Joomla 1.5 & Drupal 6.1Performance Comparison

  • Performance Comparison of Major Web Browsers

  • Performance comparision CakePHP and symfony

  • Performance Comparison of Mobile Ad-hoc Network Routing Protocol

  •  Ad-hoc and Hybrid Networks Performance Comparison of MANET Routing Protocols in Ad-hoc and Hybrid Networks

  • A Performance Comparison of Wireless Ad Hoc Network Routing Protocols under Security Attack


Implement
Implementการออกแบบงานวิจัยเกี่ยวกับเครือข่าย

  • How to Implement DHTs (Distributed Hash Tables) in Mobile Ad Hoc Networks?

  • Physical Implementation and Evaluation Ad Hoc Network Routing Protocols Unmodied Simulation Models

  • Design and Implementation of Ad-hoc Communication and Application on Mobile Phone Terminals

  • Grid Computing Implementation in Ad Hoc Networks

  • Automated Position System Implementation over Vehicular Ad Hoc Networks in 2-Dimension Space


New approach
New Approachการออกแบบงานวิจัยเกี่ยวกับเครือข่าย

  • A New Approach to Service Discovery in Wireless Mobile Ad Hoc Networks

  • A New Approach to Channel Access Scheduling for Ad Hoc Networks

  • A REINFORCEMENT LEARNING APPROACH FOR SECURE ROUTING IN MOBILE AD HOC NETWORKS

  • A New Approach to Adaptive Multi-routing Protocol for Mobile Ad Hoc Network


Improvement
Improvementการออกแบบงานวิจัยเกี่ยวกับเครือข่าย

  • Link Failure Detection Improvement for Wireless Ad Hoc Networks

  • Active Packets Improve Dynamic Source Routing for Ad-hoc Networks

  • On the Capacity Improvement of Ad Hoc Wireless Networks Using Directional Antennas

  • Performance Improvement of Ad-Hoc Networks by Using a Behavior-Based Architecture

  • Improvement of TCP Performance in Ad Hoc Networks Using Cross Layer Approach


Analysis
Analysisการออกแบบงานวิจัยเกี่ยวกับเครือข่าย

  • Ad Hoc Wireless Networks : Analysis, Protocols, Architecture and Towards Convergence

  • Throughput-Delay Analysis of Mobile Ad-hoc Networks with a Multi-Copy Relaying Strategy

  • Performance Analysis of Mobile Ad-hoc Network Using AODV Protocol

  • Scenario based Performance Analysis of AODV and OLSR in Mobile Ad hoc Networks

  • Performance Analysis of Ad hoc Routing Protocols in Mobile WiMAX Environment

  • Centrality Analysis in Vehicular Ad Hoc Networks


Study
Studyการออกแบบงานวิจัยเกี่ยวกับเครือข่าย

  • Ad Hoc Networks: Study of Protocol Behaviour

  • Study of Connectivity in Wireless Ad-hoc Networks with an Improved Radio Model

  • Study on Address Allocation in Ad-Hoc Networks

  • Wi-Fi in Ad Hoc Mode: A Measurement Study

  • Study of connectivity in vehicular ad hoc networks


Trend
Trendการออกแบบงานวิจัยเกี่ยวกับเครือข่าย

  • Trends in Middleware for Mobile Ad Hoc Networks

  • Current Trends in Vehicular Ad Hoc Networks

  • Ultra Wide Band (UWB) Ad-hoc Networks: Review and Trends

  • Current Trends in Vehicular Ad Hoc Networks

  • Applications and Future Trends in Mobile Ad Hoc Networks

  • Future Trends on Ad-hoc and Sensor Networks (FT-ASN)

  • A Study of Recent Research Trends and Experimental Guidelines in Mobile Ad-hoc Networks


Survey
Surveyการออกแบบงานวิจัยเกี่ยวกับเครือข่าย

  • A Survey of Mobile Ad Hoc network Routing Protocols

  • A Survey on Wireless Ad Hoc Networks

  • A survey of clustering schemes for mobile ad hoc networks

  • Mobility Models for Vehicular Ad Hoc Networks: A Survey and Taxonomy

  • SURVEY AND TAXONOMY OF UNICAST ROUTING PROTOCOLS FOR MOBILE AD HOC

  • Security Issues in Mobile Ad Hoc Networks - A Survey

  • A survey of mobility models for ad hoc

  • Mobility Models for Systems Evaluation A Survey


Test methodology

Test Methodologyการออกแบบงานวิจัยเกี่ยวกับเครือข่าย

52


Agenda

Test Processการออกแบบงานวิจัยเกี่ยวกับเครือข่าย

Role and Responsibility

V Model

Test Technique

Test Type

Test Flow

Documents

Test Tool

AGENDA

53


Test process

การ การออกแบบงานวิจัยเกี่ยวกับเครือข่ายTest คืออะไร

การ Test คือกระบวนการทดสอบระบบว่าสามารถทำงานได้อย่างถูกต้อง ได้ผลลัพธ์ตรงกับความต้องการของ User หรือไม่ โดยจะต้องทดสอบให้ครอบคลุมทุกๆ Business Requirement และจะต้องไม่เกิดข้อผิดพลาด (Error) ต่างๆ ขึ้น เมื่อ User นำระบบไปใช้งาน

นิยาม

"การทดสอบโปรแกรม ทำขึ้นเพื่อลดความเสี่ยงที่จะเกิดความผิดพลาดขึ้นกับโปรแกรมก่อนจะถึงมือผู้ใช้“

กระบวนการTest มีความสำคัญอย่างไรต่อองค์กร

เนื่องจาก Error จะเกิดขึ้นตลอดเวลา ทุกๆ Phase ของการพัฒนา Application ตั้งแต่ requirement analysis, design and build ระดับความรุนแรงของ Error จะแตกต่างกันออกไป ซึ่งจะก่อให้เกิดความเสียหายต่อองค์กร ดังนั้นจึงต้องมีกระบวนการ Test ขึ้นมาเพื่อตรวจสอบระบบ ทำให้ระบบมีคุณภาพ (Quality) มากยิ่งขึ้น และลดความเสี่ยง (Risk) ที่จะเกิด Error (bug) ลง จนทำให้ % ในการเกิด error = 0%

แต่ในความเป็นจริงแล้ว % error จะเป็น 0% นั้นเป็นไปได้ยากมาก ดังนั้นในการทำงานจริง จะต้องมีการจัด priority ของ Case ต่างๆ ว่า Case ไหนจำเป็นที่จะต้องกำจัด error ไม่ให้เกิดขึ้น ถ้าเกิด error ประเภทนี้ขึ้นแล้วจะก่อให้เกิดผลเสียต่อองค์กรมาก ก็จะถูกจัดไว้เป็น Priority แรกๆ Case เหล่านี้จะถูกเรียกว่า Critical Case

TEST PROCESS

54


Test process cont

อะไรคือข้อจำกัดของการทดสอบระบบ (Limitation of testing)

>> Knowledge

>> Time

>> Resource (Human, Software, Hardware)

>> UnlimitedChange Requirement (not good)

เมื่อไหร่จึงจะหยุดทำการทดสอบระบบ (when to stop testing)

>> Meet Objective – ทดสอบจนครบวัตถุประสงค์ที่ได้ Plan เอาไว้

>> Exit Criteria – หยุดทดสอบเมื่อเงื่อนไขต่างๆ ครบตามที่ระบุไว้ใน exit criteria

TEST PROCESS (CONT)

55


ในมุมมองของ (Programmer และ Tester จะมีแนวความคิด (View) ที่แตกต่างกันใน

เรื่องของการ Test ตัวอย่างเช่น

TEST PROCESS (CONT)

56


Test process cont1
Test Process (cont) (

Test Creation

Test

Planning

NO

Cover all

requirements?

Create Test

Scenario

Create Test

Case

Review Test

Case

Requirement

Analysis

Create test

coverage

matrix

YES

Test Execution

Test Preparation

Record Defect

Log

Analyze Defect

Execute

PASS?

Run Test Case

Test

Environment

Set up

NO

Record Test

Result

Create .

Summary

Test Report

Create

Test data

YES

  • Test Planning ประกอบด้วย

  • Test strategy หมายถึงการกำหนดวิธีการทดสอบให้เหมาะสมกับ Application หรือ ระบบที่เราจะทำการทดสอบ ว่าควรจะมีการทดสอบแบบใดบ้าง

  • Test schedule หมายถึง Task งานต่างๆ ที่สามารถแตกแยกย่อยออกมา และระบุวันในการทดสอบได้

  • Test Resource หมายถึง Resource ต่างๆ ที่จะต้องใช้ในการทดสอบ ไม่ว่าจะเป็น Human , S/W, H/W หรือ Time

57



V MODEL (

59


V Model (เป็น Methodology ที่ไว้สำหรับตรวจสอบคุณภาพของระบบ ซึ่งจะมี Stage

ต่างๆ ของการ Test คอย validate & verify ตั้งแต่เริ่มต้น Requirement จนถึง phase

สุดท้ายของการพัฒนาระบบ

Left side “V” จะเป็น activity ของ Analysis Requirement and Design เมื่อเสร็จสิ้นการ Design แล้ว กระบวนการ Build จะเริ่มต้นขึ้น

Right side “V” จะเป็น Testing activity ซึ่งจะเริ่มต้นขึ้นหลังจาก Build เสร็จ ในช่วงแรกของการทดสอบ จะ focus เฉพาะ individual component หลังจากนั้นจะเปลี่ยนเป็น focus ในเรื่องของ Functional , non-functional ให้ตรงกับ Business Requirement

ความหมาย Verification and Validation

Verification

is the process confirming that something meets its specification

“Do we build the system right?”

Validation

is the process confirming that it meets the user’s requirements

“Do we build the right software?”

V MODEL (CONT)

60


Software quality triangle (

Software

Gap

Gap

User Requirement

Requirement Specification

Gap

คุณภาพของ Software สามารถแสดงออกมาในรูปแบบของสามเหลี่ยม ซึ่งในแต่ละมุมจะแทนด้วย

User requirement, software , Requirements Specification

61


Software quality triangle (cont) (

1. User requirements – Requirements specification Gap

ช่องว่างนี้เกิดขึ้นมาจาก Developer ไม่เข้าใจ Requirement ของ User ซึ่งอาจจะเนื่องมาจากสาเหตุ

ดังนี้

  • Misunderstood requirements

  • Ignored requirements

  • Missing requirements

  • Outdated requirements

  • Unneeded requirements

    2. Requirements specification - Software Gap

    ช่องว่างนี้เกิดขึ้นมาจากการพัฒนา Software ไม่ตรงตาม Requirement specification ซึ่งอาจจะเกิด

    มาจากสาเหตุดังนี้

  • Requirement not identified in the specification

  • Changes to requirements identified after development commenced

  • Wrong interpretation of requirement due to vagueness and ambiguity in the specification

  • Features added by the developers to exploit technical opportunities

  • Features removed by the developers because they were too difficult to implement

62


Software quality triangle (cont) (

Software

  • SA Poor understanding of user requirements

  • Corrected during software development

  • Software meets user requirements

  • (software ที่พัฒนาออกมาดี อาจจะเนื่องมาจาก Developer มีประสบการณ์จึงเขียน software ออกมาใช้งานได้ดี)

3. Software – User requirements Gap

ช่องว่างนี้เกิดขึ้นมาจาก Software ที่พัฒนาขึ้นมาไม่ตรงกับ Requirement ที่ได้มาจาก User ซึ่ง

อาจจะต้อง re-work เพื่อแก้ไขให้ software เป็นไปตามที่ user ต้องการ

  • Shapes of Software Quality Triangles

    ช่องว่างทั้ง 3 แบบ ทำให้เกิด Quality Triangle ที่แตกต่างกันออกไป ดังนี้

63


Software quality triangle (cont) (

  • SA,DEV Poor understanding of user requirements

  • Good software development

  • Software does not meets user requirements

  • (Developer พัฒนา Software ได้ดี เข้าใจ Requirement Spec. เป็นอย่างดี แต่ Software ที่ได้ไม่ตรงกับความต้องการของ User)

Software

  • SA Good understanding of user requirements

  • Poor software development

  • Software does not meets user requirements

  • (Developer มีความเข้าใจ Requirement น้อย ทำให้สร้าง Software ไม่ตรงกับ Requirement)

Better alignment

  • Poor understanding of user requirements

  • Poor software development

  • Software does not meets user requirements

  • (เป็นรูปแบบที่แย่ที่สุด เนื่องจากแต่ละส่วนไม่มีความเข้าใจกัน)

64


Test Technique (

Software

White Box

Internal Quality

External Quality

Black Box

User Requirement

Requirement Specification

65


Black Box Testing (

>> ไม่ต้องมีความรู้เรื่องของระบบว่ามีการออกแบบหรือเขียน Code อย่างไร

>> สนใจเฉพาะว่าระบบมี Function การทำงานอย่างไร และจะได้ output

ออกมาเป็นอะไรบ้าง

สำหรับ Technique ต่างๆ ที่ใช้ในการทดสอบแบบ Black box testing นั้นมี

หลายวิธี แต่จะขอยกตัวอย่างที่รู้จักกันดีคือ

Equivalence partitioning

เป็นการกำหนดค่าตัวแทน ของกลุ่มข้อมูลขึ้นมา 1 ค่า แล้วนำค่านั้นมาใช้ในการทดสอบ ซึ่งจะสามารถ Apply ได้ว่าถ้าใช้ค่าตัวแทนนี้มาทำการทดสอบได้ผลลัพธ์อย่างไร ค่าอื่นๆ ที่อยู่ภายใต้กลุ่มนี้ ก็จะมีผลลัพธ์เช่นเดียวกัน

เช่น ระบบธนาคารสามารถให้โอนเงินผ่าน ATM ขั้นต่ำคือ 100 และสูงสุดคือ 500 บาท

การทดสอบจะต้องกำหนดตัวแทนของกลุ่มของข้อมูลที่จะต้องนำมาทดสอบ ตัวอย่างเช่น

TEST TECHNIQUE

66


Black Box Testing (

กรณีโอนเงิน 50 บาท (เป็นตัวแทนของกลุ่มที่ < 100 )

กรณีโอนเงิน 200 บาท (เป็นตัวแทนของกลุ่มที่อยู่ระหว่าง 100 - 500 )

กรณีโอนเงิน 1000 บาท (เป็นตัวแทนของกลุ่มที่ > 500 )

เพราะฉะนั้นจะได้ชุดของข้อมูลมาสามชุด และได้ data มาทดสอบ 3 ค่าเท่านั้น

Boundary value analysis

เป็นวิธีการทดสอบโดยกำหนดขอบเขตของข้อมูลขึ้นมา เพื่อจะได้ค่า input data ที่ครอบคลุม เช่นระบบธนาคารสามารถให้โอนเงินผ่าน ATM ขั้นต่ำคือ 100 และสูงสุดคือ 500 บาท

การทดสอบจะต้องกำหนดขอบเขตของข้อมูลที่จะต้องนำมาทดสอบ ตัวอย่างเช่น

กรณีโอนเงิน 99 บาท

กรณีโอนเงิน 100 บาท

กรณีโอนเงิน 101 บาท

กรณีโอนเงิน 499 บาท

กรณีโอนเงิน 500 บาท

กรณีโอนเงิน 501 บาท

TEST TECHNIQUE (CONT)

67


White Box Testing (

>> ต้องมีความรู้เรื่องของระบบว่ามีการออกแบบอย่างไร ทำงานอย่างไร

>> ต้องมีความรู้ในเรื่องของ Programming

ขอยกตัวอย่าง Technique ของ white box testing ดังนี้

Statement Coverage

เหมาะกับทำในระดับ Unit Test

ทุกบรรทัดหรือทุกๆ Statement จะต้องทำการทดสอบรวมถึงส่วนที่เป็น exception error ด้วย

ใช้เวลา Test นานกว่า Technique อื่นๆ

Branch Coverage

เน้นไปที่การทดสอบ case ครบทุกๆ case ที่มีการตัดสินใจในโปรแกรม

ใช้เวลาเร็วกว่า statement testing

ในการตัดสินใจนั้นๆ อาจจะมี เงื่อนไขอื่นๆ เช่น or หรือ and เข้ามาเกี่ยวข้องในการตัดสินใจนั้นๆก็ได้

TEST TECHNIQUE

68


ประเภทของการทดสอบ (Program จะแบ่งได้เป็น 2 ประเภท ดังนี้

Functional Test

ใช้ Technique การ Test แบบ Black box

Functional Test จะทำการทดสอบโดย Tester

เป็นการทดสอบว่าระบบทำอะไร “What” a system does

Non-Functional Test

เป็นการทดสอบว่าระบบทำงานดีอย่างไร “How well” the system works

ส่วนใหญ่จะเป็นการทดสอบในเรื่องการ verify capacity, reliability ของระบบ ทั้ง H/W และ S/W เช่น Performance Test, Reliability Test เป็นต้น

ตัวอย่างของ Non-function Test ได้แก่

Performance Test

Reliability

Usability

Load Test

Stress Test

TEST TYPE

69


Level of testing cont

Level (ของการทดสอบ จะถูกกำหนดไว้ใน Test Planning ในส่วนของ Test Strategy เพื่อเป็น

แนวทางว่าควรจะใช้การ Test แบบใดให้เหมาะสมกับ Program และ Requirement ของ user

Level of Testing จะประกอบด้วย

Unit test (white box & black box testing technique)

Integration Test (For small size)

System Test

Functional

Non-Functional Test

Performance Test

Load Test

Stress Test

Security Test

Reliability / Availability Test

Disaster & Recovery Test (data backup & data recovery Test)

Horizontal Scalable

System Integration Test (SIT – For large size)

End to End Test (E2E)

Regression Test

User Acceptance Test (UAT)

Alpha (in-house test)

Beta

LEVEL OF TESTING(cont)

70


Level of testing cont1

สำหรับการทำ (Performance Testing จะขึ้นอยู่กับความเหมาะสมและ Requirement ว่าต้องการจะวัดคุณภาพหรือประสิทธิภาพในเรื่องใด

ซึ่งจะต้องมีข้อมูลต่างๆ เหล่านี้ เช่น

objectives of performance testing

problems in performance testing

Understand measurement in performance test

Able to select types of performance test appropriately

LEVEL OF TESTING(cont)

71


Unit Test (

จุดประสงค์ เพื่อตรวจสอบผลการทำงานของ module ย่อยทั้งหมดของระบบ

เปรียบเทียบ กับสิ่งที่ design ไว้ ว่ามีความแตกต่างกันหรือไม่

Response by : Programmer

Skill: Programming skill, Internal program design

Test technique: Black box and White box

Test environment: Develop environment

Integration Test

จุดประสงค์ เพื่อตรวจสอบความถูกต้องของ Function การทำงานต่างๆ เมื่อมีการ Integrate unit /

module เข้าร่วมกันโดยจะให้ความสำคัญในส่วนของการ Interface ระหว่างกันว่าสามารถใช้งาน

ร่วมกันได้หรือไม่ ซึ่งอาจจะอยู่ในรูปแบบ Client/Server และ distributed system

Response by : Programmer, Tester or QA

Skill: Programming skill, Testing skill

Test technique: Black box and White box

Test environment: Develop environment and Test environment

LEVEL OF TESTING (cont)

72


System Test (

จุดประสงค์ เพื่อ Verify ระบบว่าระบบทำงานได้ถูกต้องและได้ผลลัพธ์ตรงตาม Requirement โดย

จะทำการทดสอบแบบ Functional และ Non-Functional Test ขึ้นอยู่กับว่าแบบใดจะเหมาะสมกับ

Requirement ของ User

Response by : Tester or QA

Skill: Testing skill

Test technique: Black box

Test environment: Test environment

System Integration Test

จุดประสงค์ เพื่อ Verify ว่าระบบต่างๆ สามารถทำงานร่วมกันได้อย่างถูกต้อง ตรงตามวัตถุประสงค์

และ Requirement ที่มี โดยจะ verify ทั้ง Network integration และ Product integration ซึ่งจะ

รวมไปถึง Infrastructure ของระบบ เช่น Operating system, file system, hardware,

middleware, network configuration

Response by : Tester or QA

Skill: Testing skill

Test technique: Black box

Test environment: Test environment

LEVEL OF TESTING (cont)

73


Regression Test (

จุดประสงค์ ทำการทดสอบเพื่อดูว่าการเปลี่ยนแปลง (change) ในจุดหนึ่ง จะไปกระทบกับส่วนอื่นๆ

ที่ไม่ได้ทำการเปลี่ยนแปลงหรือไม่ ซึ่ง Regression test นั้นจะเป็นการทดสอบทั้งระบบอีกครั้งหนึ่ง

เป็นการ Test ซ้ำกับ Case เดิมที่เคย Test ไปแล้ว เพื่อที่จะได้ verify ได้ว่า Function เดิม ยังใช้

งานได้อยู่ เช่น

กรณีที่มีการแก้ไข Function กลางที่ใช้งานร่วมกันของระบบ จำเป็นจะต้องทำการทดสอบใหม่ทั้งหมด เพื่อดูว่าการแก้ไข function กลางจะไปมีผลกระทบกับส่วนอื่นๆ หรือไม่

หรือกรณีที่ มีการ Upgrade software จาก oracle8i เป็น oracle10g ในกรณีนี้จะต้องทำการทดสอบ Application ใหม่ทั้งหมด เพื่อที่จะ verify ให้ได้ว่าเมื่อ upgrade oracle แล้วจะไม่มีผลกระทบใดๆ ต่อ application เดิม

Response by : Tester / QA

Skill: Testing skill

Test technique: Black box

Test environment: Test environment

** จะทำการทดสอบก็ต่อเมื่อมี Requirement แจ้งมาว่าให้ทำการทดสอบใหม่ทั้งระบบ

LEVEL OF TESTING (cont)

74


User Acceptance Test (

จุดประสงค์ เพื่อ Confirm business requirement กับ User โดย Verify และ Validate ว่าระบบ

ทำงานได้ถูกต้องและได้ผลลัพธ์ตรงตาม Requirement โดยจะต้องทำการทดสอบบน

environment ที่เสมือนจริง (production) และจะใช้ข้อมูลจริงในการทดสอบ

ALPHA : on developer site

เป็นการทดสอบแบบ in-house โดยจะให้ User เป็นคนทดสอบระบบ พร้อมกับจะมี Tester/ QA เป็นคนแนะนำ

BETA : on customer site

เป็นการทดสอบโดย User สามารถทำการทดสอบได้เองบน environment ที่จัดเตรียมไว้ให้ หรือสามารถนำ software กลับไปทดสอบเองได้ และถ้าเจอ Error ก็สามารถแจ้งให้ Developer ทำการแก้ไข

Response by : User

Skill: Testing skill

Test technique: Black box

Test environment: Test environment (Realistic & Representative)

LEVEL OF TESTING (cont)

75


Load Test (

จุดประสงค์ เพื่อทำการทดสอบ performance ของเครื่องในเรื่องของ Time ว่าในเวลาหนึ่งๆ ต่อ

จำนวน Transaction ที่ส่งเข้าไปพร้อมๆ กันในระบบ จะมี Response time เป็นไปตาม Business

Requirement ของ User หรือไม่ ซึ่งสามารถแยกได้เป็น 2 ข้อ คือ

- Response time : The end to end response time associated with a specific user- system interaction

- Throughput :The ability of the business system to execute a given number of businesses or system related processes within a given unit of time

Response by : Tester / QA

Skill: Testing skill specify performance testing

Test technique: Black box

Test environment: Test environment (Realistic & Representative)

Test tool:

>> Load Runner (สำหรับ Web application or windows application) สามารถ จำลอง Request เป็น Time Interval ได้คือ ให้เริ่มจาก load น้อยๆ ไปหา load มากๆ แล้วกลับมาน้อยใหม่ เพื่อดูเรื่องการคืน Memory ของตัวระบบ

>> Script ต่างๆ เช่น unix shell script (สำหรับงาน Process)

LEVEL OF TESTING (cont)

76


Stress Test (

จุดประสงค์ เพื่อทำการทดสอบ Capacity ของเครื่องว่ามี limitation ในการรองรับปริมาณข้อมูลได้

มากที่สุดเท่าไหร่ จนกว่าเครื่องจะ down

Response by : Tester / QA / Developer

Skill: Testing skill specify performance testing

Test technique: Black box

Test environment: Test environment (same as production environment)

LEVEL OF TESTING (cont)

77


Security Test (Non-functional) (

จุดประสงค์ เพื่อทำการทดสอบว่าระบบมีความปลอดภัยมากเพียงพอ ที่บุคคลภายนอกไม่สามารถ

hack เข้ามาดึงข้อมูลของลูกค้าได้

สำหรับวิธีในการป้องกันระบบจากบุคคลภายนอก มีได้หลายวิธี ตัวอย่างเช่น

Password rules (Single sign on, LDAP)

Access rights (user roles, file system security)

Set time outs

Response by : Tester / QA / Developer

Skill: Testing skill, network security, programming skill

Test technique: Black box

Test environment: Test environment (Realistic & Representative)

LEVEL OF TESTING (cont)

78


Availability & Reliability test (

จุดประสงค์

เพื่อทำการทดสอบว่าระบบสามารถทำงานได้ตลอดเวลา โดยไม่เกิดปัญหาขึ้น

เพื่อทำการทดสอบความน่าเชื่อถือของระบบ เช่นกรณีที่ระบบ down ไป ก็สามารถที่จะกู้กลับคืนมาได้ โดยข้อมูลทุกอย่างยังถูกต้อง

สำหรับวิธีในการทดสอบจะยกตัวอย่าง 2 แบบคือ

Disaster & Recovery Test (data backup & data recovery Test)

Data Backup

To perform regular and ad-hoc back-ups as part of normal operational life-cycle and perform backups of data prior to, or during batch processing.

Data Recovery

Backed up data can be re-loaded and the system fully restored to the back-up point without loss or corruption of data.

Recovery data at each commit point within an on-line transaction process without corruption of existing data.

To verify maximum recovery time (SLA)

Rollback data entry or batch process without corruption or loss of data

** ถ้าระบบไม่มี requirement ในส่วนนี้ ก็ไม่จำเป็นต้องทำการทดสอบ

LEVEL OF TESTING (cont)

79


Availability & Reliability test (cont) (

Horizontal Scalable

หมายถึง เมื่อระบบมีการใช้งานมากขึ้น และเครื่องที่มีอยู่เริ่มรับ request ไม่ไหว คือเริ่มมี response time ที่ช้าลง ก็ควรจะทำการ upgrade ระบบให้รับ request ได้มากขึ้น ซึ่งทำได้ 2 วิธีคือเลือกที่จะเพิ่ม CPU เพิ่ม Ram หรือเลือกที่จะเพิ่มเครื่องแทน (Load Balance)

การทดสอบจะต้องรู้ spec ของ hardware ต่างๆ ที่ใช้งานอยู่ ที่ต้องการจะเพิ่ม CPU หรือ RAM หรือ เครื่องใหม่ เพื่อที่จะได้เตรียมอุปกรณ์ต่างๆ ได้ถูกต้องและเหมาะสมเพื่อพร้อมต่อการทดสอบ

Response by : Developer / DBA

Skill: Technical skill

Test technique: Black box

Test environment: Test environment (same as production environment)

** ถ้าระบบไม่มี requirement ในส่วนนี้ ก็ไม่จำเป็นต้องทำการทดสอบ

LEVEL OF TESTING (cont)

80


Test flow
Test FLOW (

P

R

O

D

U

C

T

I

O

N

* SIT

* Regression Test

Unit Test

Integration Test

System Test

UAT

* Performance Test

* Security Test

* Disaster & Recovery Test

* Horizontal Scalable Test

* Means optional testing stage

81


Documents cont
Documents (cont) (

Test Planning

Test Specification / Test Design

Test Specification / Test Design

Test Specification / Test Design

Test Case/ Test Script

Test Case/ Test Script

Test Case/ Test Script

Requirement traceability

matrix

Requirement traceability

matrix

Requirement traceability

matrix

Test Result

Test Result

Test Result

Defect Log

Defect Log

Defect Log

Test Summary Report

Test Summary Report

Test Summary Report

Integration Test

System Test

System Integration Test

แผนผังการจัดทำเอกสารที่เกี่ยวข้องกับกระบวนการทดสอบ

82


Documents
Documents (

Input Document

Requirement (มีชื่อเรียกที่แตกต่างกันในแต่ละองค์กร เช่น Project Proposal, High Level Architecture Design etc.)

Program Specification (มีชื่อเรียกที่แตกต่างกันในแต่ละองค์กร Software Requirement Specification, Program Specification, Functional Specification etc.)

Work flow process

Output Document (deliverable document)

Test Plan

Test Specification / Test Design *

Test Scenario

Test Case / Test Script

Requirement traceability matrix

Test Summary Report *

Defect Log

Test Result

*Optional document

83


Documents cont1
Documents (cont) (

ตัวอย่าง Requirement Document

84


Documents cont2
Documents (cont) (

ตัวอย่าง Program specification Document

85


Documents cont3
Documents (cont) (

ตัวอย่าง Work Flow Process

86


Documents cont4
Documents ((cont)

Output (Deliverable Document)

ขั้นตอนต่างๆ ในการทำเอกสารสำหรับ Test Phase จะเริ่มต้นตั้งแต่การทำ Requirement Analysis

จนถึงกระบวนการ Build ระบบ ซึ่งเอกสารที่จะกล่าวถึงจะมีดังนี้

Test Planning

เป็นเอกสารที่จัดทำขึ้นเพื่อไว้สำหรับเป็นแนวทางในการทดสอบเป็นมุมมองแบบ High Level โดยจะ

มีการกำหนด objective ในการทดสอบ, การกำหนด Test strategy ต่างๆ, การกำหนด Role &

Responsibility โดยใน Test Plan ประกอบด้วยหัวข้อที่สำคัญดังนี้

Test strategyหมายถึงการกำหนดวิธีการทดสอบให้เหมาะสมกับ Application หรือ ระบบที่เราจะทำการทดสอบ ว่าควรจะมีการทดสอบแบบใดบ้าง เช่น

>> ระบบ A เป็นระบบงานที่มีขนาดเล็ก ไม่มี Interface ติดต่อกับระบบงานอื่นๆ จะต้องทำการทดสอบ เริ่มตั้งแต่ Unit test -> Integration Test (ภายใน module ตัวเอง) -> System Test -> UAT

>> ระบบ B เป็นระบบงานธนาคาร มี Interface ติดต่อกับองค์กรภายนอก และต้องรองรับปริมาณ Transaction ที่เข้ามาในแต่ละวันเป็นจำนวนมาก ก็จะทำการทดสอบเริ่มตั้งแต่ Unit test -> Integration Test (ภายใน module ตัวเอง) -> System Test -> System Integration Test (SIT) ->Regression Test -> UAT

และจะต้องทำการทดสอบในส่วนของ Non-Functional เพิ่มเติมคือ Performance Test, Security Test, Disaster& Recovery Test , Scalable Test และ Test แบบอื่นๆ ที่เหมาะสมและครอบคลุมกับ Business Requirement

Test scheduleหมายถึง Task งานต่างๆ ที่สามารถแตกแยกย่อยออกมา และระบุวันในการทดสอบได้

Test Resourceหมายถึง Resource ต่างๆ ที่จะต้องใช้ในการทดสอบ ไม่ว่าจะเป็น Human , S/W, H/W หรือ Time

87


Documents cont5
Documents (cont) (

จาก Test Plan สามารถแตกออกมาเป็น Element ต่างๆ เพื่อให้เห็นรายละเอียดได้ดังนี้

S [Scope] : What to test (In scope), what not to test (Out scope)

P [People] : Training, Responsibility, Schedule

A [Approach] : To testing

C [Criteria] : Entry / Exit Criteria

E [Environment] : Environment needs

D [Deliverables] : Deliverables as part of test process

I [Incidentals] : Introduction, Identification

R [Risks] : Risks and Contingencies

T [Tasks] : Tasks involves in testing

88


Documents cont6
Documents (cont) (

ตัวอย่าง Test Planning Document

Test Scheduling

Test Strategy

89


Documents cont7
Documents (cont) (

ตัวอย่าง Test Planning Document

ตัวอย่าง Entry Criteria & Exit Criteria ในแต่ละ Test Level

90


Documents cont8
Documents (cont) (

Test Design / Test specification

เป็นเอกสารที่จัดทำขึ้นเพื่อแสดงรายละเอียดของTest conditionที่จะนำไปใช้ Run Test รวมถึง

ระบุถึง Input data แบบคร่าวๆ ที่ใช้ในการทดสอบโดยจะยังไม่ได้เฉพาะเจาะจงลงไป ถ้าจะ

กล่าวถึง Input data แบบเจาะจง จะไปอยู่ในเอกสาร Test Case

Test Design/ Test specification จะถูกเขียนขึ้นในภาพรวมของแต่ละ Test phase

ซึ่งจะมีความใกล้เคียงกับ Test Plan เพียงแต่ว่าจะเฉพาะเจาะจงลงไปในแต่ละ phase ของการ Test

มากกว่า

91


Documents cont9
Documents (cont) (

Test Scenario

เป็นเอกสารที่จัดทำขึ้นเพื่อร้อยเรียง flow ต่างๆของระบบเข้าไว้ด้วยกัน เหมือนเรียบเรียงไว้เป็น

storyboard เพื่อเอาไว้ใช้สำหรับแตกออกมาเป็น Test Case ในขั้นตอนต่อไป โดยจะบอกใน

ภาพรวมว่า การจะเกิดรายการขึ้นมาได้ 1 รายการนั้น จะต้องผ่านขั้นตอนตั้งแต่เริ่มต้น จนกระทั่ง

สิ้นสุด อย่างไร

ตัวอย่าง Test Scenario

92


Documents cont10
Documents (cont) (

Environment Set up Test Check list

เป็นเอกสารที่จัดทำขึ้นเป็น Check list เพื่อไว้สำหรับตรวจสอบว่าการ Set up / config

environment ต่างๆ ครบถ้วน เป็นไปตาม List ที่ได้ทำไว้

ตัวอย่าง Environment Set up Test Check list

93


Documents cont11
Documents (cont) (

Environment Set up Test Check list

ตัวอย่าง Environment Set up Test Check list

94


Documents cont12
Documents (cont) (

Test Case / Test Script

เป็นเอกสารที่จัดทำขึ้นเพื่อไว้สำหรับใช้ในการทดสอบระบบ โดยหลักการทำ Test Case อย่างง่าย

ที่สุดนั้น จะต้องอยู่บนพื้นฐานของ Business Requirement และวัตถุประสงค์ของระบบ ในเอกสารจะ

ระบุถึง Step / procedure รวมถึงวิธีการ Set up อย่างละเอียด เพื่อที่ผู้ที่ Run Test ตาม Test Case

จะสามารถทำตามได้ง่าย

หลักการของการคิด Test Case จะต้องคำนึงถึง

Negative Case / Invalid Case

Positive Case / Valid Case

ในส่วนของเอกสาร Test Case จะต้องประกอบไปด้วย

ชื่อ Test Case โดยปกติแล้วจะตั้งชื่อให้สื่อ เช่น การ login เข้าระบบ

คำอธิบาย Case ต่างๆ ว่าต้องการ Test กรณีใดบ้าง

Expected Result (ผลลัพธ์ที่คาดหวังว่าจะได้ออกมา ซึ่งจะต้องตรงกับ Requirement)

ข้อมูล Input ที่จะใช้ทดสอบใน Case ต่างๆ

Step ในการทดสอบ

Actual Result (ผลลัพธ์ที่ได้จาก Program)

Test Result เพื่อระบุว่า Test case ข้อนี้ PASS หรือ FAIL

95


Documents cont13
Documents (cont) (

ตัวอย่าง Test Case

96


Documents cont14
Documents (cont) (

Test Coverage Matrix

เป็นเอกสารที่จัดทำขึ้นเพื่อให้แน่ใจว่า ทุก ๆ Business requirement ได้มี Test case control

เอาไว้แล้วเพื่อที่จะไม่ตกหล่น Requirement ใดไป

เอกสาร Test Coverage Matrix มีหลายรูปแบบขึ้นอยู่กับความถนัดของผู้ใช้งาน

ตัวอย่าง Test Coverage Matrix

97


Documents cont15
Documents (cont) (

  • Test Result

    มีอยู่หลายแบบ บางครั้งก็จัดทำเป็นเอกสารแยกออกมาอีกชุดหนึ่ง แต่ส่วนใหญ่จะนิยมนำ Test

    Result ไว้เป็นส่วนหนึ่งในเอกสารTest Case เพื่อลดความซ้ำซ้อนในการทำเอกสาร

    ตัวอย่าง Test Result

98


Documents cont16
Documents (cont) (

Defect Log

ไว้บันทึกผลการทดสอบกรณีที่เจอ Error (bug) ตาม Test Case ที่ได้ทำไว้ และเพื่อส่งเอกสารฉบับ

นี้ให้กับ SA/ Developer ทำการ analyze และดำเนินการ fix bug ในขั้นตอนต่อไป

ในการบันทึก Defect จะต้องใส่ severity (ระดับความรุนแรงของ Error) ด้วย ซึ่งในส่วนนี้จะต้องเป็น

ข้อตกลงร่วมกันระหว่างทุกคนที่อยู่ในทีมงานของ Project นั้นๆ ว่า จะจัด Error ต่างๆ ไว้ที่ระดับ

ใดบ้าง โดยในแต่ละระดับก็จะมีนิยามที่แตกต่างกัน

ตัวอย่างเช่นบางหน่วยงานจะกำหนดว่า

99


ตัวอย่าง (Defect Log

Documents (cont)

Defect Log  Defect Analysis

100


Documents cont17
Documents (cont) (

  • Test Summary Report

    เป็นเอกสารชุดสุดท้ายที่จัดทำขึ้นมาในแต่ละ Phase ของการ Test เพื่อเป็นการสรุปผลการทดสอบ

    ทั้งหมดว่ามีจำนวน Test case ทั้งหมดกี่ Case ทำการทดสอบไปกี่ Case Test อยู่บน Environment

    ใด และถ้ามี Error จะอยู่ที่ severity ใดบ้าง เป็นจำนวนกี่ Case

    ตัวอย่างSummary Test Report

101


Documents cont18
Documents (cont) (

  • Test Summary Report

    ตัวอย่างTest Summary Report (cont)

102


Documents cont19
Documents (cont) (

Test Planning

Test Specification / Test Design

Test Specification / Test Design

Test Specification / Test Design

Test Case/ Test Script

Test Case/ Test Script

Test Case/ Test Script

Requirement traceability

matrix

Requirement traceability

matrix

Requirement traceability

matrix

Test Result

Test Result

Test Result

Defect Log

Defect Log

Defect Log

Test Summary Report

Test Summary Report

Test Summary Report

Integration Test

System Test

System Integration Test

Level of Documents

จากเอกสารทั้งหมด สามารถจัดกลุ่มแบ่งเป็น Level ได้ตามแผนผังดังนี้

103


Test tool
Test Tool (

Quick Test

เป็น Automate test tool ที่ช่วยในการทดสอบแบบ Functional Test และ Regression Test โดยที่ Tester ไม่จำเป็นที่จะต้องมา run test case ที่ซ้ำๆ กันเป็นจำนวนหลายๆ ครั้ง สามารถใช้ Tool นี้ช่วยได้ โดยที่ต้อง capture flow การทำงานของหน้าจอเพื่อให้ tool รับรู้ก่อน หลังจากนั้นเมื่อจะเริ่มทำการทดสอบจริง Tool ก็จะจดจำการทำงานที่เคยบันทึกไว้

ข้อดี คือ ไม่เปลือง Resource/effort ที่จะต้องมาทำการทดสอบแบบซ้ำๆ

Load Runner

เป็น Automate test tool ที่ช่วยในการทดสอบ Performance Test และ Load Test เพื่อดู Capacity ของระบบ , Response time, throughput, bottleneck etc. และสามารถที่จะวิเคราะห์ออกมาได้ว่าเกิดปัญหาหรือ bottleneck ที่ส่วนใด เพื่อให้สามารถ tuning performance ได้มีประสิทธิภาพมากยิ่งขึ้น

HP Quality Center (QC)

เป็น Quality Tool ไว้สำหรับควบคุมคุณภาพของระบบ จะประกอบไปด้วยหลาย Module แต่ที่นิยมนำมาใช้งานในเรื่องการ Test คือ Requirements, Test Plan, Test Lab และ Defect Manager เราสามารถที่จะนำ Requirement และ Test Case ใส่เข้าไปในระบบ เมื่อเราทำการทดสอบตาม Test case แล้ว ให้มาบันทึก Defect ไว้ใน QC

หลังจากนั้น QC จะทำการส่ง alert mail แจ้งไปยังผู้ที่เกี่ยวข้องต่างๆ ให้รับทราบว่ามี defect เกิดขึ้น เมื่อทำการแก้ไข defect และ re-test เสร็จเรียบร้อยแล้ว ให้ทำการ close defect ด้วย จาก Tool ตัวนี้จะสามารถ Track Status ของการทดสอบและสามารถที่จะทราบได้ว่ามีการทำ Test Case ครอบคลุมทุก Requirement แล้วหรือยัง

104


ในปัจจุบันการพัฒนา (Software Application แบบ Agile process กำลังถูกนำมาใช้ จึงมีการนำวิธี

Agile เข้ามาประยุกต์ใช้ร่วมกับ Test Process เพื่อปรับให้การ Develop Application มี

ประสิทธิภาพมากขึ้น

การทำงานแบบ Agile จะนิยมการติดต่อสื่อสารแบบ Real Time มากกว่าการติดต่อสื่อสารโดยการเขียนเป็นเอกสาร

โดยทีมงานจะต้องประกอบไปด้วยบุคคลที่เกี่ยวข้องที่จะมีส่วนช่วยในการพัฒนา Software ให้สำเร็จ อย่างน้อย

ได้แก่ SA, Programmer, Business Analyze, Tester, manager Concept ของ QA ใน agile คือ “ต้องช่วย

support Developer เพื่อให้ได้ Software คุณภาพดีเยี่ยมไปถึงมือลูกค้า “นั่นหมายถึงว่า Tester จะต้อง

ยอมรับการเปลี่ยนแปลงอยู่ตลอดเวลา เพื่อให้ Software ออกมามีคุณภาพ ดังนั้นจึงไม่สามารถวางแผนการ Test

ได้ล่วงหน้านานๆ เนื่องจาก Developer สามารถที่จะเปลี่ยนแปลง Program ได้ตลอดเวลาเพื่อให้งานออกมามี

คุณภาพ

จากหลักการของ Agile ทำให้ Tester ต้องลดงานบางส่วนลง เพื่อจะได้มีเวลาในการทดสอบได้หลายครั้งมาก

ยิ่งขึ้น งานที่ควรจะลดลงคืองานเอกสาร เนื่องจากเอกสารบางอย่างอาจจะสามารถยุบรวมกัน หรือตัดทิ้งได้ หรือ

เขียนให้กระชับมากยิ่งขึ้นได้ ยกตัวอย่างเช่น เอกสาร Test Case อาจจะถูกเปลี่ยนมาเป็น Test Check List เท่านั้น

เพื่อลดเวลาในการทำงานลง แต่ไม่ได้หมายความว่าให้ลดจำนวน Test Case ลง ทุกอย่างยังคงอยู่บนพื้นฐาน

business requirement

Concept ของ Agile จะต้องร่วมทำการทดสอบกับ Developer ทุกๆ สัปดาห์ โดยใช้เวลาให้น้อยที่สุด คือไม่เกิน 1

ชม. Developer จะต้องทำการ demo program ที่กำลังทำการ develop อยู่ให้กับ Tester เพื่อทำการตรวจสอบ

แบบคร่าวๆ ว่าทำงานได้หรือไม่ ซึ่งการทำ Test ทุกๆ สัปดาห์จะมีข้อดีคือ ทำให้ Developer ต้องใส่ใจในคุณภาพ

งานของตัวเองอยู่ตลอดเวลา ทำให้ช่วยลดปัญหาที่ปลายเหตุ หลังจากที่ deploy program ออกมาให้กับ Tester

แล้วเจอ Error ทำให้ต้องวนกลับไปแก้ไขใหม่

AGILE Testing

105


เมื่อเริ่มต้นทำการทดสอบในส่วนของ System Integration Test (SIT/E2E) Developer จะทำ

Demo ให้ดูอีกครั้ง หลังจากนั้น Tester จะทำการทดสอบ Program ทั้งหมดเองตาม Check List ที่

ได้ทำไว้ ซึ่งจะต้องทำการทดสอบใหม่ทั้งหมด เนื่องจากว่าเราไม่สามารถมั่นใจได้ว่า Code ที่กำลัง

ทำการทดสอบอยู่เป็น Code ตัวเดิม เนื่องจากหลักการของ Agile จะมีความยืดหยุ่นมากในเรื่องของ

การ Develop Program คือสามารถแก้ไขได้ตลอดเวลา

จากหลักการดังกล่าว เมื่อมาถึงขั้นตอนสุดท้ายของการทดสอบ จะพบว่า Error น้อยลงกว่าปกติหรือ

อาจจะไม่มีเลย เนื่องจากได้ผ่านการทดสอบกับ Developer มาแล้วทุกอาทิตย์

AGILE Testing (cont)

106


Agile development

เป็นแหล่งรวมวิธีการพัฒนา Software ที่ใช้วิธีแบบ IID (Iterative and Incremental Development) เช่น Extreme Programming (XP), Scrum, Crystal, Feature Driven Development (FDD) เป็นต้น

Crystal Process

107


Test case
เครื่องมือที่ใช้ในการสร้าง TEST CASE ของงานวิจัยเกี่ยวกับเครือข่าย

  • Simulation Tools เช่น The ns-3 network simulator, QNAP2, OPNET, GloMoSim, NetSim

  • Test bed

  • อื่นๆ


Parameters
Parameters

  • Node Density

  • Mobility Model

  • Performance metrics

  • Node velocity

  • Pause time

  • Traffic Type

  • Layer

  • Topology

  • Bandwidth


จุดที่ผิดบ่อยครั้ง ในบทที่ 4

  • คำนวณค่าคะแนนทางคณิตศาสตร์ไม่ถูกต้อง

  • ใช้เกณฑ์การแปลผลที่ไม่น่าเชื่อถือ

  • แปลผลในเอกสารผิด

  • เขียนบทที่ 4 โดยขาดการวิเคราะห์ผลการทดลอง

  • หน้าจอที่ออกแบบขึ้นก่อนเขียนโปรแกรม ไม่ใช่

  • หน้าจอเดียวกับที่เขียนโปรแกรมเสร็จแล้ว


ad