Principles of testing

1 Principles
4 Dynamic test
techniques
2 Lifecycle
5 Management
3 Static testing
6 Tools
Software Testing
ISEB Foundation Certificate Course
Principles of Testing
1 Nguyên lý
4 Kỹ thuật kiểm
thử động
2 Vòng đời
5 Quản lý
3 Kiểm thử tĩnh
6 Công cụ
Kiểm thử phần mềm
ISEB Foundation Certificate Course
Nguyên lý kiểm thử
Contents
Why testing is necessary
Fundamental test process
Psychology of testing
Re-testing and regression testing
Expected results
Prioritisation of tests
Principles
1
4
2

5
3
6
ISEB Foundation Certificate Course
Nội dung
Tại sao kiểm thử lại cần thiết
Quá trình kiểm thử cơ bản
Tâm lý kiểm thử
Tái kiểm thử và kiểm thử hồi quy
Những kết quả mong đợi
Sắp xếp độ ưu tiên trong kiểm thử
Nguyên lý
1
4
2
5
3
6
ISEB Foundation Certificate Course
What is a “bug”?



Error: a human action that produces an
incorrect result
Fault: a manifestation of an error in software
- also known as a defect or bug
- if executed, a fault may cause a failure
Failure: deviation of the software from its
expected delivery or service

- (found defect)
Failure is an event; fault is a state of
the software, caused by an error
“bug” là gì?



Error : là hành động của con người, tạo ra một kết
quả sai
Fault : là một biểu hiện của lỗi trong phần mềm
- còn được biết như là một defect hay bug
- nếu phần mềm được thực thi, thì fault có thể tạo ra
failure
Failure: là dẫn xuất của phần mềm sinh ra lỗi không
mong muốn
- (tìm ra ảnh hưởng của lỗi đó)
Failure là một sự kiện; fault là trạng thái
của phần mềm, được tạo ra bởi Error
Error - Fault - Failure
A person makes
an error
… that creates a
fault in the
software
… that can cause
a failure
in operation
Error - Fault - Failure
Một người tạo ra
error…

… mà tạo ra fault
trong phần mềm
…
… mà có thể tạo
ra failure trong
lúc vận hành
Reliability versus faults

Reliability: the probability that software will
not cause the failure of the system for a
specified time under specified conditions
- Can a system be fault free? (zero faults, right first
time)
- Can a software system be reliable but still have
faults?
- Is a “fault free” software application always
reliable?
Sự tin cậy về việc chống fault

Sự tin cậy: là khả năng của phần mềm mà không tạo
ra lỗi hệ thống trong thời gian cụ thể dưới một điều
kiện nhất định nào đó.
- Hệ thống đó có thể là hệ thống không có fault không?
(fault bằng không, đúng trong lần chạy đầu tiên)
- Hệ thống phần mềm có thể đáng tin cậy nhưng vẫn có
fault không?
- Ứng dụng phần mềm “không có fault” luôn có đáng
tin cậy hay không?
Why do faults occur in software?




software is written by human beings
- who know something, but not everything
- who have skills, but aren’t perfect
- who do make mistakes (errors)
under increasing pressure to deliver to strict
deadlines
- no time to check but assumptions may be wrong
- systems may be incomplete
if you have ever written software
Tại sao xảy ra fault trong phần mềm ?



phần mềm được viết bởi con người
- con người biết nhiều thứ, nhưng không thể biết tất cả
- con người có kỹ năng, nhưng không hoàn hảo
- con người có thể làm sai (errors)
duới một áp lực ngày càng tăng do phải giao đúng
thời hạn
- không có thời gian để kiểm tra nhưng giả định là có thể
sai
- hệ thống có thể vẫn chưa hoàn thành
nếu từ trước tới giờ bạn đã viết phần mềm
So why is testing necessary?
- because software is likely to have faults
- to learn about the reliability of the software
- to fill the time between delivery of the software and
the release date

- to prove that the software has no faults
- because testing is included in the project plan
- because failures can be very expensive
- to avoid being sued by customers
- to stay in business
Tại sao kiểm thử lại cần thiết?
- vì phần mềm có thể có lỗi
- để tìm hiểu về độ tin cậy của phần mềm
- lắp lại thời gian giữa phân phối sản phẩm và việc đưa
vào sử dụng.
- chứng minh phần mềm không có lỗi
- vì kiểm thử là giai đoạn bao gồm trong kế hoạch dự án
- vì lỗi có thể sinh ra chi phí rất đắc
- tránh sự kiện tụng của khách hàng
- cạnh tranh về thương mại
Exhaustive testing?


What is exhaustive testing?
- when all the testers are exhausted
- when all the planned tests have been executed
- exercising all combinations of inputs and
preconditions
How much time will exhaustive testing take?
- infinite time
- not much time
- impractical amount of time
Kiểm thử toàn diện?



Kiểm thử toàn diện là gì?
- khi tất cả những người kiểm thử phần mềm đã kiểm
thử phần mềm toàn diện
- khi tất cả kế hoạch kiểm thử được thực hiện
- thực hiện tất cả các kết hợp của đầu vào và điều kiện
tiên quyết
Kiểm thử toàn diện mất bao nhiêu thời gian?
- vô thời hạn
- không có mất nhiều thời gian
- không có lượng thời gian cụ thể trong thực tế
How much testing is enough?
-
-
-
-
it’s never enough
when you have done what you planned
when your customer/user is happy
when you have proved that the system works
correctly
- when you are confident that the system works
correctly
- it depends on the risks for your system
Kiểm thử bao nhiêu là đủ?
-
-
-
-
không bao giờ đủ
khi bạn làm xong những gì đã lên kế hoạch

khi khách hàng/người dùng hài lòng
khi bạn chứng minh được hệ thống làm việc
chính xác
- khi bạn chắc chắn hệ thống làm việc
chính xác
- tùy thuộc vào rủi ro của hệ thống của bạn
How much testing?

It depends on RISK
-
-
-
-
-
-
risk of missing important faults
risk of incurring failure costs
risk of releasing untested or under tested software
risk of losing credibility and market share
risk of missing a market window
risk of over testing, ineffective testing
Chi phí kiểm thử?

Tùy thuộc RỦI RO
- có nguy cơ bỏ qua những lỗi quan trọng
- có nguy cơ phát sinh chi phí cho lỗi đó
- có nguy cơ đưa ra phần mềm chưa được kiểm
thử hay đang trong giai đoạn kiểm thử
- có nguy cơ mất uy tín và thị phần
- có nguy cơ bỏ qua thị trường tiềm năng

- có nguy cơ phần mềm trong giai đoạn kiểm thử,
kiểm thử không hiệu quả

use RISK to
- allocate the time available for testing by
prioritising testing
So little time, so much to test


test time will always be limited
use RISK to determine:
- what to test first
-
-
-
what to test most
how thoroughly to test each item
what not to test (this time)
}
i.e. where to
place emphasis

dùng RỦI RO để
- sắp xếp thời gian sẵn có cho kiểm thử bằng cách sắp
xếp độ ưu tiên trong kiểm thử …
Vì có ít thời gian, vì có nhiều chi
tiết để kiểm thử


thời gian kiểm thử sẽ luôn hạn chế

dùng RỦI RO để xác định:
- những gì sẽ kiểm thử đầu tiên
-
-
-
những gì lưu ý nhất sẽ kiểm thử
kiểm thử xuyên suốt tất cả vấn đề
những gì không kiểm thử (trong lúc này)
}
tức là những nơi
quan trọng
Most important principle
Prioritise tests
so that,
whenever you stop testing,
you have done the best testing
in the time available.
Nguyên lý quan trọng nhất
Sắp xếp độ ưu tiên kiểm thử
Như vậy,
Bất cứ khi nào bạn dừng kiểm thử,
thì bạn đã thực hiện xong việc kiểm
thử theo cách tốt nhất trong khoảng
thời gian cho phép.