chapter2

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

Chương 2

KIỂM THỬ TRONG VÒNG ĐỜI
PHÁT TRIỂN PHẦN MỀM

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


Vòng đời
1

2

3

4

5

6

Kiểm thử phần mềm

Nội dung
Vòng đời kiểm thử
Kiểm thử đơn vị
Kiểm thử tích hợp
Kiểm thử hệ thống
Kiểm thử chấp nhận

2


Vòng đời của kiểm thử phần mềm

3


Vịng đời của kiểm thử phần mềm…


Q trình sửa lỗi bao gồm
- Phân loại lỗi, cơ lập lỗi  tìm ra nguyên nhân
và nơi gây lỗi
- Đưa ra giải pháp sửa lỗi
- Khắc phục lỗi

4


Phân loại kiểm thử





Theo mức độ chi tiết
- Kiểm thử đơn vị
- Kiểm thử hệ thống
- Kiểm thử tích hợp
Dựa trên phương pháp thử nghiệm (thường
dùng ở mức kiểm thử đơn vị)
- Kiểm thử hộp đen  kiểm tra chức năng
- Kiểm thử hộp trắng kiểm tra cấu trúc
5


Kiểm thử hộp đen
•
•

•

Cịn gọi là kiểm thử hàm, kiểm thử chức năng
Tập trung vào hành vi vào/ra. Với đầu vào đã biết
ra có thể đốn/tính đầu ra, rồi kiểm tra chương
trình có tạo kết quả như ta đốn/tính.
– Khơng thể kiểm thử hết các bộ dữ liệu đầu vào
Bài toán đặt ra là giảm số lượng ca kiểm thử
bằng việc chia không gian đầu vào thành các
miền tương đương
– Sau đó chọn một ca kiểm thử từ mỗi miền tương

đương này.
6


Kiểm thử hộp trắng










Còn gọi là kiểm thử cấu trúc, kiểm thử logic
Các tiêu chuẩn bao phủ
Lệnh
- Mọi lệnh đều được thử
Vòng lặp
- 0, 1, >1 lần
Đường đi
- Tất cả các khả năng chạy của chương trình
Nhánh (if, while, ..)
- Biểu thức điều kiện được thử với cả True và False
• Các nhánh đều được chạy ít nhất một lần

•

7

So sánh kiểm thử hộp trắng và hộp đen




Hộp trắng
- Số đường đi nhiều khi là vô hạn
- Kiểm tra những gì đã làm, khơng phải
những gì cần được làm
- Khơng phát hiện được ca kiểm thử cịn
thiếu
- thích hợp cho kiểm thử hệ thống và tích
hợp
Hộp đen
- Dễ bùng nổ tổ hợp về số ca kiểm thử
(dữ liệu đúng và dữ liệu sai)
- Thường không chắc ca kiểm thử này có
phát hiện được lỗi cụ thể kia hay khơng
- Thích hợp cho kiểm thử đơn vị và tích
hợp.








Cần cả hai
Kiểm thử hộp trắng và hộp đen
là hai thái cực của kiểm thử
Việc lựa chọn ca kiểm thử nằm
giữa và phụ thuộc vào
- Số đường đi logic có thể
- Tính chất của dữ liệu đầu vào
- Khối lượng tính tốn
- Độ phức tạp của cấu trúc dữ
liệu và giải thuật
Hai kỹ thuật là bổ sung cho
nhau.

•

8


Mơ hình chữ V

9


Vòng đời
1

2

3

4

5

6

Kiểm thử phần mềm

Nội dung
Vòng đời kiểm thử
Kiểm thử đơn vị
Kiểm thử tích hợp
Kiểm thử hệ thống
Kiểm thử chấp nhận

10


Kiểm thử đơn vị








Kiểm thử các lớp, hàm, đối tượng, gói, mơđun
Sử dụng kỹ thuật hộp đen
Dữ liệu tạo ra dựa trên tài liệu thiết kế

Có thể sử dụng cả kiểm thử hộp trắng và kiểm
thử tĩnh với các phần mềm yêu cầu chất
lượng cao
Thường thực hiện trên phần cứng phát triển
phần mềm
11


Môi trường kiểm thử đơn vị

Kết quả kiểm thử

Bộ điều khiển

Các ca kiểm thử

Đơn vị được
kiểm thử

Stub

Stub

Mô-đun giả lập
12


Vòng đời
1

2

3

4

5

6

Kiểm thử phần mềm

Nội dung
Vòng đời kiểm thử
Kiểm thử đơn vị
Kiểm thử tích hợp
Kiểm thử hệ thống
Kiểm thử chấp nhận

13


Kiểm thử tích hợp




Phát hiện vấn đề khi ghép các đơn vị, mô-đun/thành phần với
nhau, sau khi đã thực hiện kiểm thử đơn vị
Các vấn đề ghép nối

– Bên trong: giữa các thành phần( Gọi: call/message passing/…); Tham số( kiểu,
số lượng, thứ tự, giá trị); Kết quả trả về (ai, kiểu, trình tự)
– Bên ngồi: Ngắt (wrong handler?); Thời gian vào ra
- Tương tác





Sử dụng kỹ thuật hộp đen
Một số trường hợp có thể sử dụng kỹ thuật hộp trắng nhưng
chi phí cao, khó khăn
Dữ liệu thử được tạo ra dựa trên thiết kế tổng thể

14


Tích hợp Big-Bang




Lý thuyết:
- Nếu chúng ta có các thành phần đã từng kiểm
thử tại sao chúng ta không kết nối chúng với
nhau cùng lúc? Điều này sẽ tiếp kiệm thời gian
không?
Thực hiện:
- Mất nhiều thời gian để định vị lỗi và sửa lỗi

- Tái kiểm thử sau khi sửa lỗi có phổ rộng hơn
- Kết quả cuối cùng?  Mất nhiều thời gian hơn
15


Tích hợp gia tăng





Baseline 0: tested component
Baseline 1: two components
Baseline 2: three components, etc.
Thuận lợi:
- Vị trí lỗi dễ định vị và sửa chữa hơn
- Khôi phục dễ sau các vấn đề và biến động xấu
- Giao tiếp nên được kiểm thử trong các kiểm thử
thành phần, NHƯNG…
- Thêm vào đường cơ sở đã được kiểm thử
16


Tích hợp Top-Down






Baselines:
- baseline 0: component a
- baseline 1: a + b
- baseline 2: a + b + c
b
- baseline 3: a + b + c + d
- etc.
d
e
Cần gọi tới các thành
phần mức thấp hơn
h i
j
chưa được tích hợp
Stubs: mơ tả các thành phần cịn
n thiếu
o

a
c
f
k

g
l

m

17

Tích hợp Bottom-up






Baselines:
- baseline 0: component n
- baseline 1: n + i
- baseline 2: n + i + o
- baseline 3: n + i + o + d
- etc.
Cần trình điều kiển để
gọi cấu hình đường cơ sở
Cũng cần stub cho vài
đường cơ sở

a
b

c

d
h

e

i

n

j

f
k

g
l

m

o
18


Tích hợp khả năng tối thiểu
Baselines:
- baseline 0: component a
- baseline 1: a + b
- baseline 2: a + b + d
d
- baseline 3: a + b + d + i
- etc.
h i
 Cần các stubs
 Khơng nên cần trình
n
điều khiển (nếu top-down)

a



b

c
e
j

f
k

g
l

m

o
19


Tích hợp tiểu trình (thread)
Thứ tục xử lý một vài sự kiện quyết định thứ tự tích
a
hợp
 Ngắt, giao dịch người dùng
b
 Khả năng tối thiểu hóa
về thời gian

d
e
f
 Thuận lợi:
- Tiến trình xử lý chính trước
h i
j
k
- Cảnh báo sớm các vấn đề thực hiện
 Bất lợi:
- Có thể cần module giả lập và trình điềunkhiểnophức tạp


c
g
l

m

20


Hướng dẫn tích hợp








Hạn chế tối đa các phần mềm hỗ trợ cần đến
Mỗi thành phần chỉ tích hợp 1 lần
Mỗi đường cơ sở nên tạo ra một kết quả có
khả năng xác minh dễ dàng
Tích hợp số lượng nhỏ các thành phần tại mỗi
lần tích hợp
Mỗi thành phần quan trọng cho 1 lần tích hợp
- Kết hợp các thành phần liên quan đơn giản
21


Kế hoạch tích hợp




Tích hợp nên được lên kế hoạch trong pha
thiết kế kiến trúc
Thứ tự tích hợp sau đó sẽ quyết định thứ tự
xây dựng
- Các thành phần hoàn tất trong thời gian đường cơ sở
của chúng
- Phát triển thành phần và kiểm thử tích hợp thực hiện
song song để tiết kiệm thời gian
22


Vòng đời
1

2

3

4

5

6

Kiểm thử phần mềm

Nội dung
Vòng đời kiểm thử
Kiểm thử đơn vị
Kiểm thử tích hợp
Kiểm thử hệ thống
Kiểm thử chấp nhận

23


Kiểm thử hệ thống






Mục đích của kiểm nghiệm hệ thống là để đảm
bảo toàn bộhệthống hoạt động như ý mà
khách hàng mong muốn.
Dựa vào yêu cầu của người dùng để kiểm thử
Chỉ sử dụng kỹ thuật hộp đen
Nên thực hiện trong môi trường phần mềm sẽ
được thực hiện

24


Kiểm thử hệ thống bao gồm một
loạt các kiểm thử










Kiểm thử chức năng (function testing)
Kiểm thử hiệu suất (performance testing)
Kiểm thử mức độ đáp ứng (stress testing)
Kiểm thử quá tải(overload testing)
Kiểm thử cấu hình (configuration testing)
Kiểm thử ổn định (robustness testing)
Kiểm thử hồi phục (recovery testing)

Kiểm thử chất lượng (quality testing)
Kiểm thử cài đặt (installation testing)
25