Transcript Chapter 1

CHAPTER 1
SE345
Software Verification and Validation
วัตถุประสงค ์เฉพาะบท
่ ้นักศึกษารู ้จักและเข ้าใจศัพท ์ เทคนิ ค
1. เพือให
้
่ ้ในการทดสอบ
และพืนฐานความรู
้ทีใช
ซอฟต ์แวร ์
่ ้นักศึกษาเข ้าใจกระบวนการ พัฒนา
2. เพือให
ซอฟต ์แวร ์



บรรยาย
ศึกษาและนาเสนอกรณี ตวั อย่าง
Pre-Test
(2 ชม.)
(30 นาที)
(15 นาที)
Pre-Test
ให ้นักศึกษาทา Pre-Test บทที่ 1 ลงใน
่
กระดาษทีอาจารย
์ผูส้ อนได ้จัดเตรียมไว ้ให ้ ใช ้
เวลา 15 นาที

้
่
ความรู ้เบืองต้
นเกียวก
ับ
กระบวนการพัฒนาซอฟต ์แวร ์ และ
การทดสอบซอฟต ์แวร ์
1.1 วงจรชีวต
ิ การพัฒนาซอฟต ์แวร ์ (SDLC)
้
่
1.2 ความรู ้เบืองต
้นเกียวกั
บการทดสอบซอฟต ์แวร ์
(Software Testing
่ ดขึนเมื
้ อเกิ
่ ดบัค (The Cost of
 ค่าใช ้จ่ายทีเกิ
Bugs)
 ทีมการทดสอบซอฟต ์แวร ์ (Software
Testing Teams)
1.3 การทวนสอบและการทดสอบซอฟต ์แวร ์
(Software Verification and Validation)
่ ยวข
่
1.4 คาศัพท ์ทีเกี
้อง (Terminologies)
วงจรชีวต
ิ การพัฒนาซอฟต ์แวร ์
(SDLC)
ในกระบวนการพัฒนาซอฟต ์แวร ์ มีแบบจาลอง
่
่ ้เป็ นแบบจาลองในการ
ทีหลากหลายเพื
อใช
พัฒนาซอฟต ์แวร ์ เช่น Waterfall Model ,
Spiral Model , Incremental Model ,
Agile , Scrum , XP Model , V Model ,
RUP Model , RAD Model ฯลฯ ซึง่
้ ขนตอนต่
้ั
่
แบบจาลองเหล่านี มี
าง ๆ ทีแตกต่
าง
้
กันไปในกิจกรรมย่อยของแต่ละขันตอน
การบ้าน บทที่ 1
่ (12 คะแนน)
งานเดียว
1. ให ้นักศึกษาทาการศึกษาค ้นคว ้าด ้วยตนเอง
่
เกียวกั
บแบบจาลองต่างๆ มาอย่างน้อย 3 แบบจาลอง
้ าสรุปส่งภายในวันศุกร ์ที่ 29 ตุลาคม ก่อน
พร ้อมทังท
16.30 น. ส่งใน E-learning
้
 รายละเอียดกิจกรรม / ขันตอนของแบบจ
าลอง
 รูปภาพแบบจาลอง
 ข ้อดี / ข ้อเสีย
ส่งช ้าหักวันละ 1 คะแนน
่
ให ้ Save ชือไฟล
์  HW1-1_รหัสนักศึกษา.docx
วงจรชีวต
ิ การพัฒนาซอฟต ์แวร ์
(SDLC)
สรุปได ้ว่าวงจรชีวต
ิ การพัฒนาซอฟต ์แวร ์ (Software
้ั
Development Life Cycle) มีขนตอนดั
งนี ้








Project planning, feasibility study:
Systems analysis, requirements definition:
Systems design:
Implementation:
Integration and testing:
System Testing
Acceptance, installation
Maintenance:
้
่ ดขึนใน
เอกสารทีเกิ
กระบวนการพัฒนาซอฟต ์แวร ์

เอกสารใน Project planning,
feasibility study:
 Software Project Management Plan
(SPMP)
 Feasibility study
 Software Configuration
Management Plan (SCMP)
 Test Plan (TP)
้
่ ดขึนใน
เอกสารทีเกิ
กระบวนการพัฒนาซอฟต ์แวร ์
Systems design:
 Software Design Documentation
(SDD)
 Test Case (TC)
 Test Script (TS)
 Implementation:
 Source Code (SC)
 Unit Testing Report (UTR)

้
่ ดขึนใน
เอกสารทีเกิ
กระบวนการพัฒนาซอฟต ์แวร ์
Integration and testing:
 Integration Test Report (ITR)
 System Testing
 System Test Report (STR)
 Acceptance, installation
 Acceptance Test Report (ATR)
 Installation Document (ID)
 Maintenance:
 User Manual (UM)

Why do we test?
่ ้องทดสอบซอฟต ์แวร ์ คือ
มี 2 เหตุผลทีต
คุณภาพ (หรือการยอมร ับ) และการค ้นพบ
ปัญหา
 สาเหตุทต
ี่ ้องทาการทดสอบเพราะว่ามี
่
่
ข ้อผิดพลาด โดยเฉพาะอย่างยิงความเที
ยงตรง
่ ้ร ับการ
ของซอฟต ์แวร ์ และระบบต่าง ๆ ทีได
ควบคุม

If You Don’t Do Both …
Per The Requirements
As Systems Specified It
As Engineering Designed It
You Can Meet the Spec, But …
As the Factory Built It
As Integration Installed It
What the Customer Wanted
Without Validation as part of the process, you will waste:
• Time
• Energy
• Money
• Resources
… and still not get it right.
Why Do Bugs Occur?


There are several reasons specifications are
the largest bug producer. In many instances a
spec simply isn’t written. Other reason may
be that the spec isn’t thorough enough, it’s
constantly changing, or it’s not
communicated well to the entire
development team. Planning software is
vitally important. If it’s not done correctly,
bugs will be created.
The next largest source of bugs is the design.
This is where the programmers lay out their
Bugs are caused for numerous reasons, but, in this
sample project analysis, the main cause can be traced to
the specification
What Exactly Does a Software Tester Do?
The goal of a software tester is to find
bugs.
 The goal of a software tester is to find
bugs and find them as early as
possible.
 The goal of a software tester is to find
bugs, find them as early a possible,
and make sure they get fixed.

Software tester should have:
They are explorers.
 They are troubleshooters.
 They are relentless.
 They are creative.
 They are (mellowed) perfectionists.
 They exercise good judgment.
 They are tactful an diplomatic.
 They are persuasive.

Software tester should have:

They are explorers.
และไม่กลัวที่
จะอยูใ่ นเหตุการณ์ทเขาไม่
ี่
เจอพบ และมีใจร ักที่
จะทดสอบซอฟต ์แวร ์ใหม่ ๆ
 ผู ้ทดสอบต ้องทาตัวเป็ นนักสารวจ

They are troubleshooters.
 ผู ้ทดสอบต ้องเป็ นนักแก ้ไขปัญหา
่ ควรหาเหตุผลว่าทาไมงานนั้นถึงไม่
 ผู ้ทดสอบทีดี
ผ่านการทดสอบ มีสาเหตุเกิดจากอะไร
Software tester should have:

They are relentless.
่
 ผู ้ทดสอบต ้องมีความอดทนทีจะค
้นหา
ข ้อผิดพลาด และต ้องมีความพยายาม เขาจะเกิด
่
ความรู ้สึกว่าปัญหาถูกคลีคลายไปอย่
างรวดเร็ว
่
้
หรือยากทีจะเกิ
ดขึนมาอี
ก
้ั
 บางครงการพบข
้อผิดพลาดอาจเกิดจากความ
บังเอิญก็เป็ นได ้
่
 ผู ้ทดสอบต ้องทาทุกวิถท
ี างทีจะให
้พบ
ข ้อผิดพลาดให ้ได ้
Software tester should have:

They are creative.
่ าอยูน
่
 วิธก
ี ารทดสอบทีท
่ ้ันหากไม่เพียงพอทีจะ
กาจัดข ้อผิดพลาดให ้ออกไปได ้ ผู ้ทดสอบจึงต ้อง
่
มีการคิดสร ้างสรรค ์เพือหาวิ
ธใี นการหา
ข ้อผิดพลาดหรือข ้อบกพร่อง

They are (mellowed) perfectionists.
 ผู ้ทดสอบต ้องมีความสุขม
ุ
ข ้อผิดพลาด
่
รอบคอบ มุ่งทีจะหา
Software tester should have:

They exercise good judgment.
 ผู ้ทดสอบต ้องมีการฝึ กฝนในการตัดสินใจและใช ้
่
่ เขาก
่
ดุลพินิจในการตัดสินใจเกียวกั
บสิงที
าลัง
่
ทดสอบว่าสิงเหล่
านั้นเป็ นข ้อผิดพลาดหรือ
ข ้อบกพร่องหรือไม่

They are tactful an diplomatic.
่
 ผู ้ทดสอบต ้องมีความเชียวชาญ
มีไหวพริบ และมี
้ั ง
ชนเชิ
้ั งในการพูดทีจะบอก
่
 เขาควรมีชนเชิ
Software tester should have:

They are persuasive.
 ผู ้ทดสอบต ้องมีความสามารถในการโน้มน้าว
้
จิตใจ หรือสามารถเกลียกล่
อม
่ ้ทดสอบพบนั้น
 ข ้อผิดพลาดหรือข ้อบกพร่องทีผู
่ าให ้
อาจจะไม่รน
ุ แรง หรือไม่สง่ ผลกระทบทีจะท
ระบบเสียหาย ดังนั้นผู ้ทดสอบต ้องแสดงให ้เห็นว่า
เพราะเหตุใด
 หรือข ้อผิดพลาดหรือข ้อบกพร่องนั้นสมควรที่
ต ้องได ้ร ับการแก ้ไข ( Fixed) ผู ้ทดสอบต ้อง
แสดงให ้ทีมเห็นว่าเพราะอะไรข ้อผิดพลาดหรือ
ทีมการทดสอบซอฟต ์แวร ์
(Software Testing Teams)
Software Customers
Those who contract for the software
to be developed
 Software Users
Those who will use the software

ทีมการทดสอบซอฟต ์แวร ์
(Software Testing Teams)
Software Developers
 Those who involve or assist in
Writing requirements from the
software user,
Designing the software,
Building the software, and
Changing and maintaining the
software as needed
 Development Testers / Software Testers
 Those who perform the check function

ทีมการทดสอบซอฟต ์แวร ์
(Software Testing Teams)
Senior Management
 CEO of the organization and other
senior executives who are responsible
for fulfilling the organization mission.
Information technology is an activity
that supports fulfilling that mission.
 Auditor
 The individual or group responsible for
evaluating the effectiveness, efficiency,
and adequacy of controls in the
information technology area. Testing is

ทีมการทดสอบซอฟต ์แวร ์
(Software Testing Teams)

Project manager
 The individual responsible for managing
the building, maintaining, and/or
implementing of software.
The Cost of Bugs

The costs are logarithmic – that is,
they increase tenfold as time increase.
A bug found and fixed during the early
stages when the specification is being
written might cost next to nothing, or
1$ in our example. The same bug, if
not found until the software is coded
and tested, might cost $10 to $100. If
a customer finds it, the cost could
The cost to fix bugs can increase dramatically
over time.
Software Verification and Validation
Software Verification
Verification helps answer the question
“Are we building the product right?”
 Verification activities are defined
around three basic processes:
inspection, measurement, and
configuration management.
 เราได ้สร ้างระบบอย่างถูกต ้องหรือไม่
่ ฒนาตรงกับข ้อกาหนดทีระบุไว
่
 ซอฟต ์แวร ์ทีพั
้

Software Validation
Validation activities are performed
after the software is developed to
determine if the software correctly
implements the requirements.
 Validation helps answer the question
“Did we build the right product?”
่ กต ้องหรือไม่
 เราได ้สร ้างระบบทีถู
่ ฒนาตรงกับความต ้องการหรือไม่
 ซอฟต ์แวร ์ทีพั

่
่ ยวข้
อง
คาศ ัพท ์ทีเกี
(Terminologies)

Software Testing (การทดสอบซอฟต ์แวร ์)
่ ดทาขึนเพื
้ อประเมิ
่
 เป็ นกิจกรรมทีจั
นและปร ับปรุง
คุณภาพของซอฟต ์แวร ์ โดยการตรวจหา
่ ดขึน้ แล ้วทาการแก ้ไข
ข ้อผิดพลาดและปัญหาทีเกิ
ข ้อผิดพลาดหรือปัญหาดังกล่าวให ้ถูกต ้อง [IEEE,
2004] วัตถุประสงค ์ของการทดสอบซอฟต ์แวร ์ ก็
่ สจ
เพือพิ
ู น์วา่ ซอฟต ์แวร ์ทางานได ้ครบทุกฟังก ์ช ัน
ตามข ้อกาหนดความต ้องการ และตรวจสอบว่าแต่
ละฟังก ์ช ันสามารถประมวลผลข ้อมูลได ้อย่าง
ถูกต ้อง
่
่ ยวข้
อง
คาศ ัพท ์ทีเกี
(Terminologies)

Errors (ความผิดพลาด)
 คนทาผิด หรือเกิดจากการเข ้าใจความหมายใน
เอกสารผิดก็จะทาให ้การเขียน Code ผิดไปด ้วย
่ ยกข ้อผิดพลาดนี ว่้ าความผิดพลาดทีท
่ าให ้
ซึงเรี
เกิด Bug ความผิดพลาดจากความต ้องการ
(Requirement) อาจขยายความผิดพลาดไปยัง
การออกแบบ (Design) และ Code
่
่ ยวข้
อง
คาศ ัพท ์ทีเกี
(Terminologies)


่
Fault (ความคลาดเคลือน)
่
 ความคลาดเคลือนเป็
นผลมาจากความผิดพลาด
่ าเสนอไดอะแกรม narrative text,
(Error) ทีน
dataflow diagrams, hierarchy charts, source
่ ๆ ความคลาดเคลือนที
่
่
่
code และอืน
ยากจะเข
้าใจ เมือ
ผูอ้ อกแบบ (Designer) ละเลยข ้อผิดพลาด ผลของ
่
่ ดขึน้ อาจเกิดจากการขาดหาย
ความคลาดเคลือนที
เกิ
่
(Missing) ทีควรน
าเสนอ
 อาจเกิดจากข ้อมูลในเอกสารขาดหาย ตกหล่น
Failure (ความล ้มเหลว)
้ อเกิ
่ ด Fault
 ความล ้มเหลว เกิดขึนเมื
่
่ ยวข้
อง
คาศ ัพท ์ทีเกี
(Terminologies)




Bugs
 จะพบได ้ตอน Coding
Crashes
 มีผลกระทบทาให ้ระบบล่ม / พัง ใช ้ไม่ได ้
Indicant (เหตุการณ์)
่
่ ยวข
้ เกี
้องกับความล ้มเหลวโดยมี
 เหตุการณ์ทเกิ
ี่ ดขึนที
การแจ ้งเตือนให ้ผูใ้ ช ้ทราบว่าเกิด Failure
Defects (ข ้อบกพร่อง)
่
 เป็ นข ้อบกพร่องทีพบก่
อนการ Coding
 Missing / Wrong / Extra
What are you test for?

A defect is a variance from a desired
product attribute. Any variance at all is
a defect.
 Wrong – A variance from customer/user
specification
 Missing – A specified or wanted
requirement is not in the built product
 Extra – May be an attribute desired by
the user, but a defect nonetheless
่ ดขึน
้
กรณี ตวั อย่างผลกระทบทีเกิ
Disney’s Lion King, 1994-1995:
In the fall of 1994, the Disney company released its first
multimedia CD-ROM game for children, The Lion King
Animated Storybook. Although many other companies
had been marketing children’s programs for years, this
was Disney’s first venture into the market and it was
highly promoted and advertised. Sales were huge. It was
“the game to buy” for children that holiday season. What
happened, however, was a huge debacle. On December
26, the day after Christmas, Disney’s customer support
phones began to ring, and ring, and ring. Soon the
phone support technicians were swamped with calls from
angry parents with crying children who couldn’t get the
software to work. Numerous stories appeared in
ศึกษากรณี ตวั อย่างผลกระทบที่
้
เกิดขึน
้ั ยนใช้เวลา 30 นาที
กิจกรรมในชนเรี
(10 คะแนน)
ให ้นักศึกษาทาการศึกษา “Infamous
Software Error Case Studies” และวิเคราะห ์
วิจารณ์ถงึ สาเหตุทท
ี่ าให ้เกิดข ้อผิดพลาดคืออะไร
ให ้เขียนส่งอาจารย ์เป็ นรูปเอกสารและออกมา
่
วิเคราะห ์ให ้เพือนฟั
งหน้าห ้อง
 Intel Pentium Floating-Point
Division Bug, 1994:
 NASA Mars Polar Lander, 1999:

Questions &
Answers
“What we anticipate seldom occurs;
what we least expected generally
happens.”
- Benjamin Disraeli
่ เราคาดคิ
่
้
“สิงที
ด จะไม่คอ
่ ยเกิดขึน
่ เราคาดไม่
่
้
สิงที
ถงึ ส่วนใหญ่กจ
็ ะเกิดขึน”
Post-Test (10 คะแนน)
ให ้นักศึกษาทา Post-Test บทที่ 1 ลงใน
่
กระดาษทีอาจารย
์ผูส้ อนได ้จัดเตรียมไว ้ให ้ ใช ้
เวลา 15 นาที

การศึกษาด้วยตนเอง

่
เพือการเตรี
ยมตัวเรียนในบทที่ 2
 ให ้นักศึกษาทาการศึกษาเอกสาร “Software Test
Plan” ตามเอกสาร ใน E-Learning “Practial
Support for CMMI-SW Software Project
Documentation Using IEEE Software
Engineering Standards” by Susan K. Land
and John W. Walz, Wiley Interscience
Publication, 2006. แล ้วทาการสร ้างแบบฟอร ์ม
่ าไปใช ้ในการวาง
Template เป็ นภาษาไทย เพือน
แผนการทดสอบต่อไป (10 คะแนน)
 ส่งใน E-learning วันจันทร ์ที่ 1 พฤศจิกายน ก่อน