Bài giảng Kiểm thử và đảm bảo chất lượng phần mềm: Chương 1

KIỂM THỬ VÀ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Chương 1

Các nguyên lý kiểm thử

1 Các nguyên lý

2 Vòng đời

3 Kỹ thuật kiểm thử

4 Kiểm thử chức năng 5. Kiểm thử cấu trúc 6 Quản lý chất lượng

1


Các nguyên lý
1

2

3

4

5

6

Kiểm thử phần mềm

Nội dung
Tại sao cần kiểm thử
Quá trình kiểm thử cơ bản
Tâm lý học kiểm thử
Kiểm thử hồi quy và kiểm thử lại
Các kết quả được mong đợi
Mức độ ưu tiên cho các kiểm thử
2


Các thuật ngữ cơ bản
Kiểm thử (IEEE): Kiểm thử là tiến trình vận
hành hệ thống hoặc thành phần dưới những
điều kiện xác định, quan sát hoặc ghi nhận kết
quả và đưa ra đánh giá về hệ thống hoặc
thành phần đó

3


Một “bug” là gì?
Error (lỗi): một hành động của con người tạo ra một
kết quả khơng đúng.
Fault (sai sót): là biểu hiện của một lỗi (error) trong
phần mềm
­ Nó cũng được biết đến như là một khiếm khuyết 
(deffect) hay một bug
­ Nếu được thực thi một sai sót (fault) có thể gây ra một 
thất bại

Failure (thất bại): sự lệch lạc của phần mềm so với
kết quả và dịch vụ được mong đợi
Failure
Failurelà
làmột
một sự
sựkiện,
kiện, fault
faultlà
làmột
một
trạng
trạngthái
tháigây
gâyra
rabởi
bởimột
mộterror
error

4


Error ­ Fault ­ Failure
Một người tạo ra
một error...

… nó tạo ra một fault
trong phần mềm...

…nó có thể gây ra
một failure trong vận
hành phần mềm
5


Độ tin cậy và sai sót
Độ tin cậy: là xác xuất để phần mềm chạy
khơng có thất bại trong một khoảng thời gian
nhất định dưới những điều kiện nhất định
­ Một hệ thống có thể khơng có sai sót (khơng có sai 
sót, đúng ngay từ lần đầu tien)
­ Một hệ thống phần mềm có thể đáng tin cậy 
nhưng vẫn có lỗi khơng?
­ Một ứng dụng phần mềm khơng sai sót “fault­
free” có phải ln ln tin cậy khơng? 
6


Tại sao xẩy ra sai sót trong phần 
mềm?
Phần mềm được viết bởi con người
­ Con người biết một số thứ chứ khơng biết mọi thứ
­ Con người có các kỹ năng nhưng khơng phải là hồn hảo
­ Con người tạo ra sai lầm (lỗi)
Phát triển phần mềm dưới các sức ép giới hạn
nghiệm ngặt
­ Khơng có thời gian để kiểm tra những giả định có thể sai
­ Các hệ thống có thể khơng hồn chỉnh
Nếu bạn đã từng viết phần mềm bạn sẽ…..

7


Chi phí lỗi phần mềm là bao nhiêu?
Các khoản tiền rất lớn
­ Ariane 5 ($7billion)
­ Mariner space probe to Venus ($250m)
­ American Airlines ($50m)
Rất nhỏ hoặc khơng có gì
­ Một sự bất tiện nhỏ
­ Tác động bất lợi khơng thấy được hoặc vơ hình
Phần mềm khơng tuyến tính
­ Đầu vào nhỏ có thể có tác động rất lớn

8


Các hệ thống an tồn – quan trọng
Lỗi phần mềm có thể gây tử vong hoặc chấn
thương
­ Điều trị bằng bức xạ gây chết bệnh nhân(Therac­
25)
­ Tai nạn máy bay (Airbus & Korean Airlines)
­ Thư nháp thấu chi ngân hàng gây ra các vụ tự tử

9


Tại sao kiểm thử là cần thiết?
­

­
­
­
­
­
­
­

Bởi vì phần mềm có khả năng bị sai sót
Để học về độ tin cậy của phần mềm
Để lập đầy khoảng thời gian chuyển giao giữa 
phân phối phần mềm và ngày phát hành
Để chứng minh phần mềm khơng có sai sót
Bởi vì kiểm thử nằm trong kế hoạch dự án
Bởi vì thất bại có thể rất đắt đỏ
Để tránh bị khách hang kiện
Để tồn tại trong kinh doanh
10


Tại sao khơng kiểm thử mọi thứ?
Avr. 4 menus
3 options / menu
Hệ thống có
20 màn hình

Average: 10 fields / screen
2 types input / field
(date as Jan 3 or 3/1)
(number as integer or decimal)

Around 100 possible values

Total for 'exhaustive' testing:
20 x 4 x 3 x 10 x 2 x 100 = 480,000 tests
If 1 second per test, 8000 mins, 133 hrs, 17.7 days
(not counting finger trouble, faults or retest)

10 secs = 34 wks, 1 min = 4 yrs, 10 min = 40 yrs

11


Kiểm thử tồn diện?
Kiểm thử tồn diện là gì
­ Khi tất cả các tester kiệt sức
­ Khi tất cả các kiểm thử được lên kế hoạch  được 
thực hiện
­ Thực hiện tất cả các kết hợp giữa đầu vào và tiền 
điều kiện
Bỏ bao nhiêu thời gian để kiểm thử tồn diện?
­ Thời gian vơ hạn
­ Khơng mất nhiều thời gian lắmnot much time
12
­ Một khoảng thời gian không thực tế


Kiểm thử bao nhiêu thì là đủ?
­ Khơng bao giờ là đủ
­ Khi bạn thực hiện xong cái mà bạn đã lên kế 
hoạch

­ Khi khách hang/ người dung cảm thấy vui vẻ
­ Khi bạn chứng minh được là hệ thống làm việc 
đúng đắn
­ Khi bạn tự tin là hệ thống của bạn làm việc đúng 
đắn
­ Nó phụ thuộc vào rủi ro cho hệ thống của bạn
13


Vậy thì kiểm thử bao nhiêu?
Nó phụ thuộc vào rủi ro
­ Rủi ro của các sai sót quan trọng cịn thiếu
­ Rủi ro của chi phí thất bại phát sinh
­ Rủi ro của phần mềm chưa được kiểm tra hoặc 
đang kiểm tra
­ Rủi ro của việc chia sẻ thị trường và mất uy tín
­ Rủi ro của việc thiếu cánh cửa thị trường
­ Rủi ro của các kiểm thử khơng hiệu quả  rủi ro 
này cịn lớn hơn cả chưa kiểm thử
14


Vì ít thời gian nên phải kiểm tra 
nhiều
Thời gian kiểm tra sẽ ln ln bị giới hạn
Sử dụng rủi ro để quyết định
­ Kiểm thử cái gì trước
­ Kiểm thử cái gì nhiều nhất
­ Làm thế nào để kiểm tra kỹ từng hạng mục
­ Cái gì khơng kiểm tra (tại thời điểm này)

Sử dụng rủi ro để
­ Phân bổ thời gian sẵn có cho việc kiểm thử bằng 
cách phân quyền ưu tiên kiểm thử ...
15


Kiểm thử và chất lượng
Kiểm thử là thước đo chất lượng phần mềm
Kiểm thử có thể tìm ra lỗi; khi chúng bị loại đi
chất lượng phần mềm có thể được cải thiện
Kiểm thử kiểm tra những cái gì
­ Chức năng hệ thống, tính chính xác của các hoạt 
động
­ Chất lương phi chức năng: độ tin cậy, tính sử 
dụng, khả năng bảo trì, tái sử dụng, khả năng 
kiểm thử được
16


Các nhân tố khác tác động đến 
kiểm thử
Các yêu cầu hợp đồng
Yêu cầu pháp lý
Các yêu cầu đặc trù cơng nghiệp
Thật
Thật là
là khó
khó khan
khanđể
đểquyết

quyết định
định
kiểm
kiểm thử
thử bao
bao nhiêu
nhiêu là
làđủ
đủ
nhưng
nhưngnó
nókhơng
khơngcó
cónghĩa
nghĩalà
là
khơng
khơng thể
thể

17


Các nguyên lý
1

2

3

4

5

6

Kiểm thử phần mềm

Nội dung
Tại sao cần kiểm thử
Quá trình kiểm thử cơ bản
Tâm lý học kiểm thử
Kiểm thử hồi quy và kiểm thử lại
Các kết quả được mong đợi
Mức độ ưu tiên cho các kiểm thử
18


Kế hoạch kiểm thử ­ các mức độ khác 
nhau
Chính sách
kiểm thử

Mức độ cơng ty
Chiến lược
kiểm thử
Kế hoạch
kiểm thử
High
Level

mức cao

Mức độ dự án (IEEE 829)

Test Plan

Kế hoạch
Detailed
Kiểm
thử
Detailed
chiDetailed
tiết
Test
Plan

Test
TestPlan
Plan

Mức độ giai đoạn kiểm thử(IEEE 829)
(vd giai đoạn kiểm thử hệ thống,
19
thành phần)


Tiến trình kiểm thử
Lên kế hoạch (mức độ chi tiết)

Đặc tả

Thực thi

Ghi chép

Kiểm tra sự 
hồn thành

20


Lên kế hoạch kiểm thử
Làm thế nào chiến lược và kế hoạch kiểm thử
dự án áp dụng cho phần mềm
Tài liệu hóa bất cứ ngoại lệ nào cho chiến
lược kiểm thử
­ Ví dụ chỉ áp dụng duy nhất một kỹ thuật thiết kế 
test case cho miền chức năng bởi vì nó ít quan 
trọng
Phần mềm khác được cần cho kiểm thử như
Tập tiêu chí hồn tất kiểm tra
21


Đặc tả kiểm thử
Lên kế hoạch (mức độ chi tiết)

Đặc tả

Thực thi

Ghi chép

Kiểm tra sự 
hoàn thành

Chỉ ra các điều kiện
Thiết kế test cases
xây dựng kiểm thử
22


Thế nào là một test case tốt
Hiệu quả
Điển hình
Tiến hóa
Kinh tế

Finds faults

Represents others

Easy to maintain

Cheap to use

23


Đặc tả kiểm thử

Đặc tả kiểm thử có thể được chia nhỏ thành 3
nhiệm vụ riêng biệt :
1. Xác định:
quyết định cài gì sẽ được kiểm thử (xác 
định điều kiện kiểm thử) và độ ưu tiên của chúng 
2.  Thiết kế:       quyết định làm thế nào những gì được 
lựa chọn kiểm thử sẽ được kiểm thử (i.e. thiết kế test 
cases)
3. Xây dựng: cài đặt các kiểm thử (dữ liệu, kịch bản, 
vv)
24


Task 1: xác định các điều kiện kiểm 
thử
Liệt kê các điều kiện chúng ta muốn kiểm tra:
­ Sử dụng kỹ thuật thiết kế test case được đặc tả trong 
kế hoạch kiểm thử
­ Có thể là có nhiều điều kiện kiểm thử cho mỗi chức 
năng hay thuộc tính hệ thống
Quyền ưu tiên cho các điều kiện kiểm thử
­ Phải đảm bảo hầu hết các điều kiện quản trọng được 
kiểm thử
25