Transcript ENTITY-RELATIONSHIP DIAGRAM (ERD)

การออกแบบงานวิจัย
และการสร้ าง Test Cases ในการ
ทดสอบ
อาจารย์ ดร. ชลทิพย์ ยาวุธ
อาจารย์ ดร. ผุสดี บุญรอด
Reading Unit in Information Technology
Faculty of Information Technology
King Mongkut's University of Technology North Bangkok
การออกแบบงานวิจยั (Research Design)
การสร างบ านเพื่อให ได ตามความต องการของเจ า
ของบ าน ก็จะต องมีการจัดทําแบบแปลน (Plan) ซึ่งจะ
ถูกเขียนขึ้นโดยสถาปนิกด วยการ พูดคุยกับเจ าของบ
านว า ต องการบ านกี่ช้ นั กี่ ห องนอน กี่ห องนํ้า เพื่อ
จะให สถาปนิกได นําแนวความคิดดังกล่าวไปวิเคราะห
และออกแบบบ้าน (Design)
จากสไลด์ การเลือกป ญหาและการออกแบบการวิจยั โดย รศ.ดร.จุมพล วิเชียรศิลป์
ความหมายของการออกแบบงานวิจัย
การออกแบบงานวิจยั หมายถึง การกําหนดโครงสร างและ
รายละเอียด แนวทางการดําเนินการในการวิจยั เพือ่ จะนําไปสู
การทําวิจยั ทีเ่ ป นไปตามวัตถุประสงค ที่กาํ หนดไว อย าง
ถกู ต อง
ประโยชน ของการออกแบบงานวิจัย
ทําให ผู วิจัยควบคุมค าความแปรปรวนต างๆ ได ถูกต อง
 ช วยให ผู วิจัยเห็นแนวทางในการดําเนินการวิจัย อันจะนําไปสู
การตอบคําถาม หรือ การพิสูจน สมมติฐานทีก่ าํ หนดไว
 ช วยให ทราบรายละเอียดเกีย่ วกับเวลา กําลังคน งบประมาณ
 ช วยให กําหนดขนาดหรือสภาพของเครื่องมือที่จะใช ในการวิจัย
 ช วยให มองเห็นว าผลการวิจัยจะสามารถนําไปใช เป นนัย
สํ าคัญได ในด านใด

ข อควรคํานึงในการออกแบบงานวิจัย
กําหนดวัตถุประสงค ของหัวข อที่จะทําการวิจยั อย างชัดเจน
 กําหนดขอบเขตและข อจํากัดของการวิจยั
 กําหนดตัวแปรต างๆ ตัวแปรต น ตัวแปรตาม
 ตั้งสมมติฐาน หรื อ ผลที่ต องการทราบ

ข อควรคํานึงในการออกแบบงานวิจัย
กําหนดประชากร และ กลุ มตัวอย าง
 การเก็บข อมูล
 สถิติ
 ผ านการตรวจจากผู เชี่ยวชาญหรื อยัง

เครื่องมือทีใ่ ช้ ในการออกแบบ

E-R Diagram (ERD)
Data Dictionary : DD
 Data Flow Diagram
 Unified Modeling Language (UML)



สมมติการวิจัย
แบบสอบถาม
E-R Diagram (ERD)
คือ แบบจำลองที่ใช้ อธิบำยโครงสร้ ำงของฐำนข้ อมูลที่ออกแบบขึ ้น
ซึง่ เขียนออกมำในลักษณะของรูปภำพ
 ใช้ สำหรับกำรออกแบบฐำนข้ อมูลในระดับ Conceptual Level
 เมื่อนำมำเขียนแสดงเป็ นแผนภำพ เรี ยกว่ำ ERD (Entity Relationship
Diagram)


จะช่วยให้ กำรอกแบบได้ ง่ำยขึ ้นด้ วยกำรจัดระเบียบควำมคิดของคนที่
ทำกำรออกแบบ และลดควำมซับซ้ อนของระบบได้ เป็ นอย่ำงดี
Examples…
GPA
Regist_n
o
Stu_lnam
e
Stu_nam
e
Stu_no
Major_n
o
Fac_no
Student
1
1
Regist_n
o
Stu_no
Subject_no
Semeste
r
Year
Level_n
o
n
regi
st
1
Fac_no
1
n
hav
e
stud
y
Registration
Level
hav
e
Fac_no
Level_no
Level_nam
e
Level_Des
c
1
hav
e
n
1
Fac_name_
a
Faculty
1
hav
e
1
Fac_name_
t
Fac_name_e
Major_no
n
Major
Maor_name_
e
Major_name_t
Major_name_
a
Fac_no
พจนานุกรมข้ อมูล

พจนานุกรมข้ อมูล (Data Dictionary : DD) เป็ นกำรทำเอกสำร
อ้ ำงอิง เพื่อช่วยอธิบำยส่วนประกอบของข้ อมูลในระบบที่กำลัง
ศึกษำอยู่ ซึง่ ผังภำพกำรไหลข้ อมูลมิได้ อธิบำยไว้
ตัวอย่ าง Users
ลาดับ
ชื่อฟิ ลด์
ความหมาย
ประเภทฟิ ลด์ ขนาด
หมายเหตุ
1
User_id
รหัสผู้ใช้ งำน
Int
5
Primary Key
2
Name
ชื่อสกุล
Varchar
150
-
3
Address
ที่อยู่
Varchar
200
-
4
Telephone
เบอร์ โทรศัพท์
Varchar
15
-
5
Position
ตำแหน่งงำน
Varchar
100
-
6
Email
อีเมลล์
Varchar
50
-
7
Level
ระดับของผู้ใช้ งำน
Tinyint
1
-
8
username
ชื่อผู้ใช้ งำนสำหรับล็อกอิน
Int
10
Foreign Key
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
DFD
Level 0
DFD Level 1 Process 1
DFD Level 1 Process 2
DFD Level 1 Process 3
DFD Level 1 Process 4
DFD Level 1 Process 5
Unified Modeling Language
(UML)

UML เป็ นภาษารู ปภาพมาตรฐาน (Standard Modeling
Language) สําหรับใช้ในการสร้างโมเดลเชิงวัตถุ
•
UML เป็ นเสมือนพิมพ์เขียวที่แสดงภาพรวมของระบบทั้งหมด โดยจะ
แสดงในรู ปแบบของแผนภาพ (Diagram) เพื่อให้เกิดความเข้าใจที่
ตรงกันระหว่างผูอ้ อกแบบระบบ, โปรแกรมเมอร์และผูใ้ ช้งาน
Use Case Diagram
Telephone Ordering System
Check Status
Salesperson
Place Order
Customer
Fill Order
Clerk
Establish
Credit
Manager
ตัวอย่าง Use Case การสั่งซื้อสินค้ าทางโทรศัพท์
Activity Diagram


Activity Diagram
เป็ นแผนภาพที่ใช้ที่แสดงขั้นตอนการ
ทํางานของ use case (เช่นเดียวกับ Sequence Diagram
และ Collaboration Diagram) แต่จะเน้นไปที่งานย่อยของวัตถุ
โดยจะมีกระบวนการทํางานคล้ายกับ Flowchart
Activity Diagram บางครั้งมีลกั ษณะคล้าย Swimlane
โดยจะแบ่งกลุ่มกิจกรรมที่เกิดขึ้นเป็ นช่อง โดยกํากับแต่ละช่องด้วยชื่อของ
Object แต่ละ Swimlane แสดงถึงกิจกรรมที่เกิดขึ้นกับ
Object นั้นๆ
Activity
Diagram
CardHolder
ATM Machine
InsertCard
Request Password
Enter Password
Check Password
Account
Confirm Access
Display Transaction Type
ตัวอย่าง Activity Diagram การ
สอบถามยอดบัญชีจากตู้ ATM
Choose Transaction Type
Read A/C Balance
Display Balance
Close Transaction
Return Card
Confirm Balance
Class Diagram

Class Diagram คือ แผนภาพที่ใช้แสดง Class และ
ความสัมพันธ์ระหว่าง Class ของระบบที่สนใจ (Problem
Domain) เช่น ในระบบจัดซื้อ Class ที่เกี่ยวข้องคือ ผูผ้ ลิต,
พนักงานจัดซื้อ, ใบสัง่ ซื้อ, ใบเสนอราคา, ใบเสร็ จรับเงิน เป็ นต้น
Class Diagram

สัญญลักษณ์ Class ประกอบด้วย
Class Name คือ ชื่อของ Class
2. Attributes คือ คุณลักษณะของ Class
3. Operations หรื อ Methods คือ กิจกรรมที่สามารถกระทํากับ
Object นั้นๆได้
Name
1.
Attributes
Methods
Class Diagram
Customer
FirstName
LastName
CardName
PinNumber
Account
Account
1
VerifyPassword()
Number
Balance
Transaction
Has
*
Deposit()
Withdraw()
UpdateAccount()
1
Perform
*
ตัวอย่าง Class Diagram ในระบบธนาคาร
Transaction
TransactionID
TransactionDate
TransactionTime
TransactionType
Account
Amount
PostBalance
Sequence Diagram


Sequence Diagram เป็ นแผนภาพที่ใช้อธิบายการทํางานของ
Use Case เพื่อแสดงถึงขั้นตอนการทํางานและลําดับของการสื่ อสาร
(Message) ระหว่าง Object ที่ตอบโต้กนั
Sequence Diagram จะแสดงอยูใ่ นรู ปแบบ 2 มิติ โดยเส้นประ
แนวตั้ง (Lifeline) จะนําเสนอในด้านเวลา ส่ วนเส้นแนวนอน
(Message) จะนําเสนอเกี่ยวกับการโต้ตอบกันระหว่าง Object
หรื อ Class ต่างๆ
Sequence Diagram
ATM Machine
Account
Card Holder
InsertCard()
RequestPassword()
EnterPassword()
CheckPassword()
ConfirmAccess()
DisplayTransType()
ChooseTransType()
ReadAccBalance()
ConfirmBalance()
DisplayBalance()
CloseTrans()
ReturnCard()
ตัวอย่าง Sequence Diagram การสอบถามยอดบัญชีจากตู้ ATM
Collaboration Diagram

Collaboration Diagram เป็ นแผนภาพชนิดเดียวกับ
Sequence Diagram โดย Sequence Diagram จะ
เป็ นแผนภาพที่แสดงถึงการสื่ อสาร แต่ Collaboration
Diagram จะนําเสนอการทํางานร่ วมกันระหว่าง Object เป็ นหลัก
แต่กส็ ามารถแสดงถึงลําดับก่อนหลังด้วย
Collaboration Diagram
1. InsertCard
3. EnterPassword
7. ChooseTransType
11.CloseTrans
Card Holder
2. RequestPassword
6. DisplayTranstype
10. DisplayBalance
12. ReturnCard
ATM Machine
4. CheckPassword
8. ReadAccBalance
5. ConfirmAccess
9. ConfirmBalance
Account
ตัวอย่าง Collaboration Diagram การสอบถามยอดบัญชีจากตู้ ATM
Statechart Diagram

Sequence Diagram เป็ นแผนภาพที่ใช้แสดงสถานะต่างๆและการเปลี่ยน
สถานะของ Class ตั้งแต่เริ่ มต้นจนสิ้ นสุ ด
Ready
Do/waiting
for instructions
Booting Complete
Boot
Do/loading the OS
Switch on Complete
Off
Do/Shut down
the power
Switch is turned on
On
Do/turn on
the Computer
ตัวอย่าง Statechart Diagram การเปิ ดเครื่องคอมพิวเตอร์
Component Diagram

Component Diagram เป็ นแผนภาพที่แสดงโครงสร้างและ
ความสัมพันธ์ระหว่างองค์ประกอบ (Components) ต่างๆของ
Software ซึ่งองค์ประกอบดังกล่าวอาจเป็ น Source Code,
Executable Program, Binary รวมถึง Text และ User
Interface
Component Diagram
Professor.exe
Course.dll
Professor Info
Database.dll
AddCourse Offering
ตัวอย่าง Component Diagram ของระบบการลงทะเบียน
Deployment Diagram

Deployment Diagram เป็ นแผนภาพที่แสดงสถาปั ตยกรรมของ
Hardware และ Software ในระบบรวมทั้งความสัมพันธ์ระหว่าง
<<Client Workstation>>
Receptionist PC
<<LAN>>
<<Server>>
Office Server
<<LAN>>
Receptionist PC
Office Server
สมมติการวิจัย
1.3.1 ระบบพยากรณ์ปริมาณการยืมหนังสือที่พั นาขึ้นมีค่า
ความคลาดเคลื่อนจากการพยากรณ์น้อยกว่าหรือเท่ากับ 0.1 (ยอมรับ H1 )
H0:  > 0.1
H1:   0.1
 คือ ค่าความคลาดเคลื่อนเ ลี่ยสะสม
สมมติการวิจัย (ต่ อ)
1.3.2 ระบบพยากรณ์ปริมาณการยืมหนังสือที่พั นาขึ้น
มีระดับประสิทธิภาพในระดับดี คือ มากกว่าหรือเท่ากับ 3.50
(ยอมรับ H1 ) โดยกําหนดนัยสําคัญที่ระดับ .05 (  = .05)
H0:  < 3.50
H1:   3.51
 คือ ค่าเ ลี่ยของกลุ่มตัวอย่างผู้เชี่ยวชาญ ที่ได้จากการ
ประเมินผลของระบบพยากรณ์ปริมาณการยืมหนังสือ
สมมติการวิจัย (ต่ อ)
1.3.3 ระบบพยากรณ์ปริมาณการยืมหนังสือที่พั นาขึ้น
มีระดับความพึงพอใจระดับดี คือ มากกว่าหรือเท่ากับ 3.50
(ยอมรับ H1 ) โดยกําหนดนัยสําคัญที่ระดับ .05 (  = .05)
H0:  < 3.50
H1:   3.51
 คือ ค่าเ ลี่ยของกลุ่มตัวอย่างผู้ใช้งาน ที่ได้จาก
การประเมินผลของระบบพยากรณ์ปริมาณการยืมหนังสือ
ตัวอย่ างการเขียนอ้ างอิงสู ตร
การสร้างตัวแบบการจัดซื้อ จะเกี่ยวข้องกับการจัดซื้อ
และต้นทุนรวม [12] ซึ่งแสดงได้ดงั สมการที่ 2-1
ต้นทุนรวม (TC)
=
CD 
DxO
Q
 Q  hc

2

ใช้ Equation พิมพ์เท่านั้น ห้าม Copy
(2-1)
ตัวอย่ างเกณฑ์ การให้ คะแนนของแบบสอบถาม
ตารางที่ 1 เกณฑ์การให้คะแนนของแบบสอบถาม
ระดับเกณฑ์การให้คะแนน
ความหมาย
5
ระบบที่พ ั นาขึ้นมีประสิ ทธิภาพอยูใ่ นระดับดีมาก
4
ระบบที่พ ั นาขึ้นมีประสิ ทธิภาพอยูใ่ นระดับดี
3
ระบบที่พ ั นาขึ้นมีประสิ ทธิภาพอยูใ่ นระดับพอใช้
2
ระบบที่พ ั นาขึ้นมีประสิ ทธิภาพอยูใ่ นระดับน้อย
1
ระบบที่พ ั นาขึ้นมีประสิ ทธิภาพอยูใ่ นระดับควรปรับปรุ ง
ตัวอย่ างเกณฑ์ ในการแปลผลแบบสอบถาม
ตารางที่ 2 เกณฑ์การให้คะแนนเพื่อประเมินความพึงพอใจของผูใ้ ช้
ระดับเกณฑ์การให้คะแนน
เชิงคุณภาพ
เชิงปริ มาณ
ดีมาก
4.51 – 5.00
ดี
3.51 – 4.50
ปานกลาง
2.51 – 3.50
น้อย
1.51 – 2.50
ควรปรับปรุ ง
1.00 – 1.50
ความหมาย
ผูใ้ ช้มีความพึงพอใจระบบอยูใ่ นระดับดีมาก
ผูใ้ ช้มีความพึงพอใจระบบอยูใ่ นระดับดี
ผูใ้ ช้มีความพึงพอใจระบบอยูใ่ นระดับพอใช้
ผูใ้ ช้มีความพึงพอใจระบบอยูใ่ นระดับน้อย
ผูใ้ ช้มีความพึงพอใจระบบอยูใ่ นระดับควรปรับปรุ ง
ตัวอย่ างการออกแบบ Story Board
........
XXXXXXXXXXXXXXXXXXXX
ปัญหาในการออกแบบและเขียน Diagram
1.
2.
3.
4.
5.
6.
7.
8.
เลือก Diagram ไม่เหมาะสมกับงานที่จะทํา
ใช้สญ
ั ลักษณ์ไม่ถกู ต้อง
เขียนขอบเขตงานไม่ละเอียด
เส้นไม่ Balance
แต่ละ Diagram ข้อมูลไม่สอดคล้องกัน
ออกแบบฐานข้อมูลไม่ Normalization
ออกแบบหน้าตาโปรแกรมไม่เหมาะกับงานที่จะทํา
อื่นๆ
การออกแบบงานวิจยั เกี่ยวกับเครื อข่าย








Performance comparison
Implement
New Approach
Improvement
Analysis
Study
Trend
Survey
Performance comparison
 Joomla
1.5 & Drupal 6.1 Performance 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





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




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





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






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

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







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 (FTASN)
A Study of Recent Research Trends and
Experimental Guidelines in Mobile Ad-hoc Networks
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
52
AGENDA
Test Process
 Role and Responsibility
 V Model
 Test Technique
 Test Type
 Test Flow
 Documents
 Test Tool

53
TEST PROCESS

การ Test คืออะไร
การ Test คือกระบวนการทดสอบระบบว่าสามารถทางานได ้อย่างถูกต ้อง ได ้ผลลัพธ์ตรงกับความ
ต ้องการของ User หรือไม่ โดยจะต ้องทดสอบให ้ครอบคลุมทุกๆ Business Requirement และ
้
จะต ้องไม่เกิดข ้อผิดพลาด (Error) ต่างๆ ขึน
้ เมือ
่ User นาระบบไปใชงาน
นิยาม
ี่ งทีจ
"การทดสอบโปรแกรม ทาขึน
้ เพือ
่ ลดความเสย
่ ะเกิดความผิดพลาดขึน
้ กับโปรแกรมก่อนจะถึงมือ
ผู ้ใช“้

กระบวนการTest มีความสาค ัญอย่างไรต่อองค์กร
เนือ
่ งจาก Error จะเกิดขึน
้ ตลอดเวลา ทุกๆ Phase ของการพัฒนา Application ตัง้ แต่
requirement analysis, design and build ระดับความรุนแรงของ Error จะแตกต่างกันออกไป ซงึ่
ี หายต่อองค์กร ดังนัน
จะก่อให ้เกิดความเสย
้ จึงต ้องมีกระบวนการ Test ขึน
้ มาเพือ
่ ตรวจสอบระบบ ทา
ี่ ง (Risk) ทีจ
ให ้ระบบมีคณ
ุ ภาพ (Quality) มากยิง่ ขึน
้ และลดความเสย
่ ะเกิด Error (bug) ลง จนทา
ให ้ % ในการเกิด error = 0%
แต่ในความเป็ นจริงแล ้ว % error จะเป็ น 0% นัน
้ เป็ นไปได ้ยากมาก ดังนัน
้ ในการทางานจริง จะต ้อง
มีการจัด priority ของ Case ต่างๆ ว่า Case ไหนจาเป็ นทีจ
่ ะต ้องกาจัด error ไม่ให ้เกิดขึน
้ ถ ้าเกิด
ี ต่อองค์กรมาก ก็จะถูกจัดไว ้เป็ น Priority แรกๆ Case
error ประเภทนีข
้ น
ึ้ แล ้วจะก่อให ้เกิดผลเสย
เหล่านีจ
้ ะถูกเรียกว่า Critical Case
54
TEST PROCESS (CONT)

อะไรคือข ้อจากัดของการทดสอบระบบ (Limitation of testing)
>>
>>
>>
>>

Knowledge
Time
Resource (Human, Software, Hardware)
Unlimited Change Requirement (not good)
เมือ
่ ไหร่จงึ จะหยุดทาการทดสอบระบบ (when to stop testing)
>> Meet Objective – ทดสอบจนครบวัตถุประสงค์ทไี่ ด ้ Plan เอาไว ้
>> Exit Criteria – หยุดทดสอบเมือ
่ เงือ
่ นไขต่างๆ ครบตามทีร่ ะบุไว ้ใน exit criteria
55
TEST PROCESS (CONT)
ในมุมมองของ Programmer และ Tester จะมีแนวความคิด (View) ทีแ
่ ตกต่างกันใน
่
เรือ
่ งของการ Test ตัวอย่างเชน
Programmer
Tester
Test only coding, not test in business view
Need to test in business view
Test only code that their change
Test integration flow and possible error occur,
need to be test
Testing is no need for a little bit code change,
not impact other (ถ ้ามีการแก ้ไขเล็กๆน ้อยๆ จะ
ไม่สนใจทาการทดสอบ และจะไม่ดวู า่ มีผลกระทบ
กับสว่ นอืน
่ ๆ หรือไม่)
Every change need to be test, and not
change impact area need to be test
(Test ทัง้ ทีม
่ ก
ี ารแก ้ไขและไม่มก
ี ารแก ้ไข)
Make data to test, no need data from other
system
Positive and Negative case need to be test
56
Test Process (cont)
Test
Planning
Test Creation
NO
Requirement
Analysis
Create Test
Scenario
Create Test
Case
Review Test
Case
YES
Cover all
requirements?
Test Execution
Create test
coverage
matrix
Test
Preparation
Record Defect
Log
Analyze Defect
NO
Execute
PASS?
Run Test Case
Test
Environment
Set up
Record Test
Result
YES
Create .
Summary
Test Report
Create
Test data
Test Planning ประกอบด ้วย
- Test strategy หมายถึงการกาหนดวิธก
ี ารทดสอบให ้เหมาะสมกับ Application หรือ ระบบทีเ่ ราจะทาการทดสอบ ว่าควรจะมีการทดสอบแบบ
ใดบ ้าง
- Test schedule หมายถึง Task งานต่างๆ ทีส
่ ามารถแตกแยกย่อยออกมา และระบุวน
ั ในการทดสอบได ้
- Test Resource หมายถึง Resource ต่างๆ ทีจ
่ ะต ้องใช ้ในการทดสอบ ไม่วา่ จะเป็ น Human , S/W, H/W หรือ Time
57
ROLE AND RESPONSIBILITY
TASK
Work Product
Response By
Test Planning
Test Plan
Test Leader / QA
Requirement Analysis
Test Design or
Test Specification
Test Leader / QA
Test Creation
Test Scenario
Test Case / Test Script
Test coverage matrix
Test Leader / QA
Test Preparation
Environment set up Check list
Tester
Test Execution
Defect Log
Test Result
Summary Test Report
Tester / Developer / DBA
58
V MODEL
59
V MODEL (CONT)
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?”
60
Software quality triangle
คุณภาพของ Software สามารถแสดงออกมาในรูปแบบของสามเหลีย
่ ม ซงึ่ ในแต่ละมุมจะแทนด ้วย
User requirement, software , Requirements Specification
Software
Gap
Gap
User Requirement
Gap
Requirement 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)
3. Software – User requirements Gap
่ งว่างนีเ้ กิดขึน
้ มาจาก Software ทีพ
้ มาไม่ตรงก ับ Requirement ทีไ่ ด้มาจาก User ซงึ่
ชอ
่ ัฒนาขึน
อาจจะต้อง re-work เพือ
่ แก้ไขให้ software เป็นไปตามที่ user ต้องการ
Shapes of Software Quality Triangles
่ งว่างทงั้ 3 แบบ ทาให้เกิด Quality Triangle ทีแ
ชอ
่ ตกต่างก ันออกไป ด ังนี้

Software
- SA Poor understanding of user requirements
- Corrected during software development
- Software meets user requirements
(software ทีพ
่ ัฒนาออกมาดี อาจจะเนือ
่ งมาจาก Developer มี
้
ประสบการณ์จงึ เขียน software ออกมาใชงานได
้ดี)
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
Better
alignment
(Developer มีความเข ้าใจ Requirement น ้อย ทาให ้สร ้าง
Software ไม่ตรงกับ Requirement)
- 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
TEST TECHNIQUE
Black Box Testing
>> ไม่ตอ
้ งมีความรูเ้ รือ
่ งของระบบว่ามีการออกแบบหรือเขียน Code อย่างไร
>> สนใจเฉพาะว่าระบบมี Function การทางานอย่างไร และจะได้ output
ออกมาเป็นอะไรบ้าง
สาหร ับ Technique ต่างๆ ทีใ่ ชใ้ นการทดสอบแบบ Black box testing นนมี
ั้
หลายวิธ ี แต่จะขอยกต ัวอย่างทีร่ จ
ู ้ ักก ันดีคอ
ื

Equivalence partitioning
้ มา 1 ค่า แล้วนาค่านนมาใช
เป็นการกาหนดค่าต ัวแทน ของกลุม
่ ข้อมูลขึน
ั้
ใ้ นการทดสอบ ซงึ่ จะ
้ า่ ต ัวแทนนีม
้ าทาการทดสอบได้ผลล ัพธ์อย่างไร ค่าอืน
สามารถ Apply ได้วา่ ถ้าใชค
่ ๆ ทีอ
่ ยูภ
่ ายใต้กลุม
่
่ เดียวก ัน
นี้ ก็จะมีผลล ัพธ์เชน
่ ระบบธนาคารสามารถให้โอนเงินผ่าน ATM ขนต
เชน
ั้ า่ คือ 100 และสูงสุดคือ 500 บาท
่
การทดสอบจะต้องกาหนดต ัวแทนของกลุม
่ ของข้อมูลทีจ
่ ะต้องนามาทดสอบ ต ัวอย่างเชน
66
TEST TECHNIQUE (CONT)
Black Box Testing
กรณีโอนเงิน 50 บาท
กรณีโอนเงิน 200 บาท
กรณีโอนเงิน 1000 บาท
(เป็นต ัวแทนของกลุม
่ ที่ < 100 )
(เป็นต ัวแทนของกลุม
่ ทีอ
่ ยูร่ ะหว่าง 100 - 500 )
(เป็นต ัวแทนของกลุม
่ ที่ > 500 )
เพราะฉะนนจะได้
ั้
ชุดของข้อมูลมาสามชุด และได้ data มาทดสอบ 3 ค่าเท่านน
ั้

Boundary value analysis
่
้ มา เพือ
เป็นวิธก
ี ารทดสอบโดยกาหนดขอบเขตของข้อมูลขึน
่ จะได้คา่ input data ทีค
่ รอบคลุม เชน
ระบบธนาคารสามารถให้โอนเงินผ่าน ATM ขนต
ั้ า่ คือ 100 และสูงสุดคือ 500 บาท
่
การทดสอบจะต้องกาหนดขอบเขตของข้อมูลทีจ
่ ะต้องนามาทดสอบ ต ัวอย่างเชน
กรณีโอนเงิน 99 บาท
กรณีโอนเงิน 100 บาท
กรณีโอนเงิน 101 บาท
กรณีโอนเงิน 499 บาท
กรณีโอนเงิน 500 บาท
กรณีโอนเงิน 501 บาท
67
TEST TECHNIQUE
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 เข ้ามาเกีย
ิ ใจนัน
ในการตัดสน
้ ๆ อาจจะมี เงือ
่ นไขอืน
่ ๆ เชน
่ วข ้องในการตัดสน
้ ๆก็ได ้
68
TEST TYPE
ประเภทของการทดสอบ 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
่ Performance Test, Reliability Test เป็ นต ้น
และ S/W เชน
 ตัวอย่างของ Non-function Test ได ้แก่
 Performance Test
 Reliability
 Usability
 Load Test
 Stress Test

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



System Integration Test (SIT – For large size)



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
End to End Test (E2E)
Regression Test
User Acceptance Test (UAT)


Alpha (in-house test)
Beta
70
LEVEL OF TESTING (cont)
สาหรับการทา Performance Testing จะขึน
้ อยูก
่ บ
ั ความเหมาะสมและ Requirement ว่า
ิ ธิภาพในเรือ
ต ้องการจะวัดคุณภาพหรือประสท
่ งใด
่
ซงึ่ จะต ้องมีข ้อมูลต่างๆ เหล่านี้ เชน
 objectives of performance testing
 problems in performance testing
 Understand measurement in performance test
 Able to select types of performance test appropriately
71
LEVEL OF TESTING (cont)
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

72
LEVEL OF TESTING (cont)
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 ซงึ่ จะ
่ Operating system, file system, hardware,
รวมไปถึง Infrastructure ของระบบ เชน
middleware, network configuration
Response by :
Tester or QA
Skill:
Testing skill
Test technique:
Black box
Test environment:
Test environment

73
LEVEL OF TESTING (cont)
Regression Test
จุดประสงค์ ทาการทดสอบเพือ
่ ดูวา่ การเปลีย
่ นแปลง (change) ในจุดหนึง่ จะไปกระทบกับสว่ นอืน
่ ๆ
ทีไ่ ม่ได ้ทาการเปลีย
่ นแปลงหรือไม่ ซงึ่ Regression test นัน
้ จะเป็ นการทดสอบทัง้ ระบบอีกครัง้ หนึง่
เป็ นการ Test ซ้ากับ Case เดิมทีเ่ คย Test ไปแล ้ว เพือ
่ ทีจ
่ ะได ้ verify ได ้ว่า Function เดิม ยังใช ้
่
งานได ้อยู่ เชน


้
กรณีทม
ี่ ก
ี ารแก ้ไข Function กลางทีใ่ ชงานร่
วมกันของระบบ จาเป็ นจะต ้องทาการทดสอบใหม่ทัง้ หมด
เพือ
่ ดูวา่ การแก ้ไข function กลางจะไปมีผลกระทบกับสว่ นอืน
่ ๆ หรือไม่

หรือกรณีท ี่ มีการ Upgrade software จาก oracle8i เป็ น oracle10g ในกรณีนจ
ี้ ะต ้องทาการทดสอบ
Application ใหม่ทงั ้ หมด เพือ
่ ทีจ
่ ะ verify ให ้ได ้ว่าเมือ
่ upgrade oracle แล ้วจะไม่มผ
ี ลกระทบใดๆ ต่อ
application เดิม
Response by :
Skill:
Test technique:
Test environment:
Tester / QA
Testing skill
Black box
Test environment
** จะทาการทดสอบก็ตอ
่ เมือ
่ มี Requirement แจ ้งมาว่าให ้ทาการทดสอบใหม่ทัง้ ระบบ
74
LEVEL OF TESTING (cont)
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 :
Skill:
Test technique:
Test environment:
User
Testing skill
Black box
Test environment (Realistic & Representative)
75
LEVEL OF TESTING (cont)
Load Test
จุดประสงค์ เพือ
่ ทาการทดสอบ performance ของเครือ
่ งในเรือ
่ งของ Time ว่าในเวลาหนึง่ ๆ ต่อ
จานวน Transaction ทีส
่ ง่ เข ้าไปพร ้อมๆ กันในระบบ จะมี Response time เป็ นไปตาม Business
Requirement ของ User หรือไม่ ซงึ่ สามารถแยกได ้เป็ น 2 ข ้อ คือ
- Response time : The end to end response time associated with a specific usersystem 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 ของตัวระบบ
่ unix shell script (สาหรับงาน Process)
>> Script ต่างๆ เชน
76
LEVEL OF TESTING (cont)
Stress Test
จุดประสงค์ เพือ
่ ทาการทดสอบ Capacity ของเครือ
่ งว่ามี limitation ในการรองรับปริมาณข ้อมูลได ้
มากทีส
่ ด
ุ เท่าไหร่ จนกว่าเครือ
่ งจะ down

Response by :
Skill:
Test technique:
Test environment:
Tester / QA / Developer
Testing skill specify performance testing
Black box
Test environment (same as production environment)
77
LEVEL OF TESTING (cont)
Security Test (Non-functional)
จุดประสงค์ เพือ
่ ทาการทดสอบว่าระบบมีความปลอดภัยมากเพียงพอ ทีบ
่ ค
ุ คลภายนอกไม่สามารถ
hack เข ้ามาดึงข ้อมูลของลูกค ้าได ้

่
สาหรับวิธใี นการป้ องกันระบบจากบุคคลภายนอก มีได ้หลายวิธ ี ตัวอย่างเชน
 Password rules (Single sign on, LDAP)
 Access rights (user roles, file system security)
 Set time outs
Response by :
Skill:
Test technique:
Test environment:
Tester / QA / Developer
Testing skill, network security, programming skill
Black box
Test environment (Realistic & Representative)
78
LEVEL OF TESTING (cont)
Availability & Reliability test
จุดประสงค์
1. เพือ
่ ทาการทดสอบว่าระบบสามารถทางานได ้ตลอดเวลา โดยไม่เกิดปั ญหาขึน
้
ื่ ถือของระบบ เชน
่ กรณีทรี่ ะบบ down ไป ก็สามารถทีจ
2. เพือ
่ ทาการทดสอบความน่าเชอ
่ ะกู ้กลับคืน
มาได ้ โดยข ้อมูลทุกอย่างยังถูกต ้อง

สาหรับวิธใี นการทดสอบจะยกตัวอย่าง 2 แบบคือ

Disaster & Recovery Test (data backup & data recovery Test)
 Data Backup
 To perform regular and ad-hoc back-ups as part of normal operational lifecycle 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 backup 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 ในสว่ นนี้ ก็ไม่จาเป็ นต ้องทาการทดสอบ
79
LEVEL OF TESTING (cont)

Availability & Reliability test (cont)

Horizontal Scalable
้
หมายถึง เมือ
่ ระบบมีการใชงานมากขึ
น
้ และเครือ
่ งทีม
่ อ
ี ยูเ่ ริม
่ รับ request ไม่ไหว คือเริม
่
้
มี response time ทีช
่ าลง
ก็ควรจะทาการ upgrade ระบบให ้รับ request ได ้มากขึน
้ ซงึ่ ทา
ได ้ 2 วิธค
ี อ
ื เลือกทีจ
่ ะเพิม
่ CPU เพิม
่ Ram หรือเลือกทีจ
่ ะเพิม
่ เครือ
่ งแทน (Load Balance)
้
การทดสอบจะต ้องรู ้ spec ของ hardware ต่างๆ ทีใ่ ชงานอยู
่ ทีต
่ ้องการจะเพิม
่ CPU หรือ RAM
หรือ เครือ
่ งใหม่ เพือ
่ ทีจ
่ ะได ้เตรียมอุปกรณ์ตา่ งๆ ได ้ถูกต ้องและเหมาะสมเพือ
่ พร ้อมต่อการ
ทดสอบ
Response by :
Skill:
Test technique:
Test environment:
Developer / DBA
Technical skill
Black box
Test environment (same as production environment)
** ถ ้าระบบไม่ม ี requirement ในส่วนนี้ ก็ไม่จาเป็ นต ้องทาการทดสอบ
80
Test FLOW
Unit
Test
Integra
tion
Test
System
Test
* SIT
*
Regressi
on Test
* Performance Test
* Security Test
* Disaster & Recovery Test
* Horizontal Scalable Test
UAT
P
R
O
D
U
C
T
I
O
N
* Means optional testing stage
81
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


Input Document

่ Project Proposal, High Level
Requirement (มีชอื่ เรียกทีแ่ ตกต่างกันในแต่ละองค์กร เชน

Program Specification (มีชอื่ เรียกทีแ่ ตกต่างกันในแต่ละองค์กร Software Requirement

Work flow process
Architecture Design etc.)
Specification, Program Specification, Functional Specification etc.)
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 (cont)
ต ัวอย่าง Requirement Document
84
Documents (cont)
ต ัวอย่าง Program specification Document
85
Documents (cont)
ต ัวอย่าง Work Flow Process
select trunc(to_date('vMMYYYY', 'MM/YYYY')),
trunc(last_day(to_date('vMMYYYY', 'MM/YYYY')))
into
vFirstDay, vLastDay
from dual
START
Config file
select to_char(add_months(sysdate,-1),'MM/YYYY')
into vMMYYYY
from dual
Script ISIM_SUMINV_ISB
select
oper_code, vat_flag
into
vOperCode, vVatFlag
from
ic_oper_commercial
where
call_type = 'IS'
and
oper_status = 'B'
Find Company
Code
Find Month / Year
Script ISIM_SUMINV_ISD
select
oper_code, vat_flag
into
vOperCode, vVatFlag
from
ic_oper_commercial
where
call_type = 'IS'
and
oper_status = 'D'
Find First day, last
day
Script ISIM_SUMINV_ISB
Select distinct currency_terminate, broker
into vCurrency, vBroker
from ic_summary_ismsb
where record_type = '01'
and broker = ('vOperCode')and (start_date_gmt >=
to_date('vFirstDay', 'DD/MM/YYYY')
and start_date_gmt < to_date('vLastDay', 'DD/MM/YYYY') + 1)
IC_OPER_COMM
ERCIAL
Find Operator
Code
B
Find Currency
Script ISIM_SUMINV_ISD
select distinct currency_terminate, plmn_origin
into vCurrency, vPlmn
from ic_summary_ismsd
where record_type = '01'
and plmn_origin = ('vOperCode')
and (start_date >= to_date('vFirstDay', 'DD/MM/YYYY')
and start_date < to_date('vLastDay', 'DD/MM/YYYY') + 1)
AF
TD
Find SDR Rate
RA
FT
A
Find VAT Rate
NO
IC_SUMMARY
_ISIMB
IC_SUMMARY
_ISIMD
IC_INTER_EXCH_
RATE
1. Retrieve Exchange
rate each of currency
2. Summary Amount
from original table
3. Convert amt, vat for
each currency
Insert data into
summary invoice
table
DR
NO
select sdr_rate
into
vSDR
from IC_INTER_EXCH_RATE
where currency_code = 'vCurrency'
and (exp_date >= to_date(‘vFirstDay’, 'DD/MM/YYYY')
and exp_date < to_date(‘vLastDay’, 'DD/MM/YYYY') + 1)
select o.oper_code, vat_rate
into vOperCode1, vVatRate
from IC_OPER_VATRATE o, IC_VAT_RATE v
where o.vat_code = v.vat_code
and o.oper_owner = 'AIS'
and o.call_type = 'IS'
and o.status = '1'
and o.oper_code in (‘vOperCode’)
exchange rate
USD
select sdr_rate
from IC_INTER_EXCH_RATE
where currency_code = 'USD'
and s.start_date_gmt between eff_date and exp_date
IC_SUMMARY_G
ENINV_IS
Last Operator
code?
Yes
Commit all
transactions
Write log and
stamp flag into
table
IC_ISIM_INV_PR
OCESS_LOG
IC_ISIM_SEQNO
Write unix log
Last company?
Yes
END
86
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 (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 (cont)
ต ัวอย่าง Test Planning Document
Test Scheduling
Test Strategy
89
Documents (cont)
ต ัวอย่าง Test Planning Document
ตัวอย่าง Entry Criteria & Exit Criteria ในแต่ละ Test Level
90
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 (cont)
Test Scenario
เป็ นเอกสารทีจ
่ ัดทาขึน
้ เพือ
่ ร ้อยเรียง flow ต่างๆของระบบเข ้าไว ้ด ้วยกัน เหมือนเรียบเรียงไว ้เป็ น
storyboard เพือ
่ เอาไว ้ใชส้ าหรับแตกออกมาเป็ น Test Case ในขัน
้ ตอนต่อไป โดยจะบอกใน
ภาพรวมว่า การจะเกิดรายการขึน
้ มาได ้ 1 รายการนัน
้ จะต ้องผ่านขัน
้ ตอนตัง้ แต่เริม
่ ต ้น จนกระทั่ง
ิ้ สุด อย่างไร
สน
ต ัวอย่าง Test Scenario

92
Documents (cont)

Environment Set up Test Check list
เป็ นเอกสารทีจ
่ ด
ั ทาขึน
้ เป็ น Check list เพือ
่ ไว ้สาหรับตรวจสอบว่าการ Set up / config
environment ต่างๆ ครบถ ้วน เป็ นไปตาม List ทีไ่ ด ้ทาไว ้
ต ัวอย่าง Environment Set up Test Check list
93
Documents (cont)
Environment Set up Test Check list
ต ัวอย่าง Environment Set up Test Check list

94
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 (cont)
ต ัวอย่าง Test Case
96
Documents (cont)
Test Coverage Matrix
เป็ นเอกสารทีจ
่ ัดทาขึน
้ เพือ
่ ให ้แน่ใจว่า ทุก ๆ Business requirement ได ้มี Test case control
เอาไว ้แล ้ว เพือ
่ ทีจ
่ ะไม่ตกหล่น Requirement ใดไป

้
เอกสาร Test Coverage Matrix มีหลายรูปแบบขึน
้ อยูก
่ บ
ั ความถนั ดของผู ้ใชงาน
ต ัวอย่าง Test Coverage Matrix
97
Documents (cont)
Test Result
มีอยูห
่ ลายแบบ บางครัง้ ก็จัดทาเป็ นเอกสารแยกออกมาอีกชุดหนึง่ แต่สว่ นใหญ่จะนิยมนา Test
้
Result ไว ้เป็ นสว่ นหนึง่ ในเอกสารTest Case เพือ
่ ลดความซ้าซอนในการท
าเอกสาร

ต ัวอย่าง Test Result
98
Documents (cont)
Defect Log
ไว ้บันทึกผลการทดสอบกรณีทเี่ จอ Error (bug) ตาม Test Case ทีไ่ ด ้ทาไว ้ และเพือ
่ สง่ เอกสารฉบับ
นีใ้ ห ้กับ SA/ Developer ทาการ analyze และดาเนินการ fix bug ในขัน
้ ตอนต่อไป
ในการบันทึก Defect จะต ้องใส่ severity (ระดับความรุนแรงของ Error) ด ้วย ซงึ่ ในสว่ นนีจ
้ ะต ้องเป็ น
ข ้อตกลงร่วมกันระหว่างทุกคนทีอ
่ ยูใ่ นทีมงานของ Project นัน
้ ๆ ว่า จะจัด Error ต่างๆ ไว ้ทีร่ ะดับ
ใดบ ้าง โดยในแต่ละระดับก็จะมีนย
ิ ามทีแ
่ ตกต่างกัน

่ บางหน่วยงานจะกาหนดว่า
ตัวอย่างเชน
99
Documents (cont)
ต ัวอย่าง Defect Log
Defect Log  Defect Analysis
100
Documents (cont)
Test Summary Report
เป็ นเอกสารชุดสุดท ้ายทีจ
่ ัดทาขึน
้ มาในแต่ละ Phase ของการ Test เพือ
่ เป็ นการสรุปผลการทดสอบ
ทัง้ หมดว่ามีจานวน Test case ทัง้ หมดกี่ Case ทาการทดสอบไปกี่ Case Test อยูบ
่ น Environment
ใด และถ ้ามี Error จะอยูท
่ ี่ severity ใดบ ้าง เป็ นจานวนกี่ Case

ต ัวอย่าง Summary Test Report
101
Documents (cont)
Test Summary Report
ต ัวอย่าง Test Summary Report (cont)

102
Documents (cont)
Level of Documents
จากเอกสารทัง้ หมด สามารถจัดกลุม
่ แบ่งเป็ น Level ได ้ตามแผนผัง ดังนี้
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
103
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
AGILE Testing
ในปั จจุบน
ั การพัฒนา Software Application แบบ Agile process กาลังถูกนามาใช ้ จึงมีการนาวิธ ี
Agile เข ้ามาประยุกต์ใชร่้ วมกับ Test Process เพือ
่ ปรับให ้การ Develop Application มี
ิ ธิภาพมากขึน
ประสท
้
ื่ สารแบบ Real Time มากกว่าการติดต่อสอ
ื่ สารโดยการเขียนเป็ นเอกสาร
การทางานแบบ Agile จะนิยมการติดต่อสอ
โดยทีมงานจะต ้องประกอบไปด ้วยบุคคลทีเ่ กีย
่ วข ้องทีจ
่ ะมีสว่ นชว่ ยในการพัฒนา 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 ทาให ้ต ้องวนกลับไปแก ้ไขใหม่
105
AGILE Testing (cont)
เมือ
่ เริม
่ ต ้นทาการทดสอบในสว่ นของ System Integration Test (SIT/E2E) Developer จะทา
Demo ให ้ดูอก
ี ครัง้ หลังจากนัน
้ Tester จะทาการทดสอบ Program ทัง้ หมดเองตาม Check List ที่
ได ้ทาไว ้ ซงึ่ จะต ้องทาการทดสอบใหม่ทัง้ หมด เนือ
่ งจากว่าเราไม่สามารถมั่นใจได ้ว่า Code ทีก
่ าลัง
ทาการทดสอบอยูเ่ ป็ น Code ตัวเดิม เนือ
่ งจากหลักการของ Agile จะมีความยืดหยุน
่ มากในเรือ
่ งของ
การ Develop Program คือสามารถแก ้ไขได ้ตลอดเวลา
จากหลักการดังกล่าว เมือ
่ มาถึงขัน
้ ตอนสุดท ้ายของการทดสอบ จะพบว่า Error น ้อยลงกว่าปกติหรือ
อาจจะไม่มเี ลย เนือ
่ งจากได ้ผ่านการทดสอบกับ Developer มาแล ้วทุกอาทิตย์
106
Agile development
เป็ นแหล่งรวมวิธก
ี ารพัฒนา Software ทีใ่ ชวิ้ ธแ
ี บบ IID (Iterative and
่ Extreme Programming (XP), Scrum,
Incremental Development) เชน
Crystal, Feature Driven Development (FDD) เป็ นต ้น
Crystal Process
107
เครื่ องมือที่ใช้ในการสร้าง TEST CASE ของ
งานวิจยั เกี่ยวกับเครื อข่าย

Simulation Tools เช่น The ns-3 network
simulator, QNAP2, OPNET, GloMoSim,
NetSim
Test bed
 อื่นๆ

Parameters
 Node
Density
 Mobility Model
 Performance metrics
 Node velocity
 Pause time
 Traffic Type
 Layer
 Topology
 Bandwidth
จุดทีผ่ ดิ บ่ อยครั้ง ในบทที่ 4
1.
2.
3.
4.
5.
คํานวณค่าคะแนนทางคณิ ตศาสตร์ไม่ถกู ต้อง
ใช้เกณฑ์การแปลผลที่ไม่น่าเชื่อถือ
แปลผลในเอกสารผิด
เขียนบทที่ 4 โดยขาดการวิเคราะห์ผลการทดลอง
หน้าจอที่ออกแบบขึ้นก่อนเขียนโปรแกรม ไม่ใช่
หน้าจอเดียวกับที่เขียนโปรแกรมเสร็ จแล้ว