Luận văn Một số kỹ thuật kiểm thử phần mềm
ĐẠI HỌC THÁI NGUYÊN
KHOA CÔNG NGHỆ THÔNG TIN
LUẬN VĂN THẠC SĨ
MỘT SỐ KỸ THUẬT
KIỂM THỬ PHẦN MỀM
KHOA HỌC MÁY TÍNH
PGS. TSKH. NGUYỄN XUÂN HUY
CAO THỊ BÍCH LIÊN
60 48 01
:
Chuyên ngành
:
Ngƣời hƣớng dẫn khoa học
Học viên thực hiện :
Mã số
:
:
Thái Nguyên - Năm 2009
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
MỤC LỤC
LỜI CAM ĐOAN …………………………………………………………………..i
MỤC LỤC ....................................................................................................ii
DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT …………………….……v
DANH MỤC CÁC BẢNG ………………………………………………………..vi
DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ …………………………………..…….vii
MỞ ĐẦU....................................................................................................... 1
Chƣơng 1 VẤN ĐỀ CHẤT LƢỢNG PHẦN MỀM VÀ KIỂM THỬ
PHẦN MỀM……………………………………….……………………..….4
1.1.1. Sản phẩm phần mềm là gì?....................................................................4
1.1.2. Thế nào là lỗi phần mềm?......................................................................5
1.1.4. Chi phí cho việc sữa lỗi.........................................................................7
1.1.5. Kiểm thử phần mềm là gì?.....................................................................8
1.2. Chất lƣợng phần mềm................................................................................8
1.3. Qui trình kiểm thử phần mềm...................................................................9
2.1.1. Mục tiêu kiểm thử ...............................................................................12
2.1.2. Luồng thông tin kiểm thử ....................................................................13
2.1.3. Thiết kế trường hợp kiểm thử ..............................................................13
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
ii
2.2.2. Kiểm thử cấu trúc điều khiển ..............................................................22
2.3.1. Phân hoạch tương đương.....................................................................27
2.3.4. Kiểm thử so sánh.................................................................................34
2.4. Đoán lỗi .....................................................................................................34
3.2.1. Xác minh và thẩm định........................................................................37
3.2.2. Tổ chức việc kiểm thử.........................................................................37
3.3. Kiểm thử đơn vị........................................................................................42
3.3.1. Các lý do của kiểm thử đơn vị .............................................................42
3.3.2. Các thủ tục kiểm thử đơn vị.................................................................45
3.4. Kiểm thử tích hợp.....................................................................................45
3.4.3. Kiểm thử hồi qui .................................................................................48
3.5. Kiểm thử tính hợp lệ ................................................................................50
3.5.1. Điều kiện kiểm thử tính hợp lệ ............................................................50
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
iii
3.5.2. Duyệt lại cấu hình ...............................................................................51
3.5.3. Kiểm thử Alpha và Beta ......................................................................51
3.6. Kiểm thử hệ thống....................................................................................52
3.6.1. Kiểm thử khôi phục.............................................................................52
3.6.2. Kiểm thử bảo mật................................................................................52
3.6.3. Kiểm thử ứng suất ...............................................................................53
THỬ ........................................................................................................... 54
4.1. Mục tiêu ....................................................................................................54
4.2. Phƣơng pháp luận ....................................................................................54
4.2.1. Tổng quan về các phương pháp ...........................................................54
4.2.2. Phạm vi giải quyết...............................................................................54
4.2.3. Phân loại các kiểu kiểm thử.................................................................55
4.2.4. Tổ chức giao diện kiểm thử .................................................................56
4.3.1. Chiến lược kiểm thử............................................................................57
4.3.2. Kiểm thử đơn vị ..................................................................................57
KẾT LUẬN................................................................................................. 66
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
iv
DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT
BRO : Kiểm thử nhánh và toán tử quan hệ
BVA : Phân tích giá trị biên
DU
E
: Một chuỗi khai báo - sử dụng
: Là số cạnh của đồ thị lƣu trình
: Là số đỉnh của đồ thị lƣu trình
: Số đỉnh điều kiện có trong đồ thị lƣu trình
: Số vùng của đồ thị lƣu trình
N
P
R
V(G) : Xác định độ phức tạp Cyclomat
V&V : Xác minh và thẩm định
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
v
DANH MỤC CÁC BẢNG
Bảng 1.1: Tỉ lệ công thức của các giai đoạn phát triển phần mềm 4
………….
Bảng 2.1: Bảng
đƣơng…………………………………..
Bảng 2.2: Ví dụ các lớp
…………………………………………
Bảng 2.3: Các ký hiệu trong đồ
………………………………...
Bảng 2.4: Ví dụ bảng
………………………………………………
Bảng 3.1: So sánh kiểm thử Top-Down
………………………
liệt
kê
các
lớp
tƣơng 28
đƣơng 29
quả 32
tƣơng
thị
nhân
quyết
định 33
và
Bottom-Up 49
Bảng 4.1: Bảng các trƣờng hợp kiểm thử cho Module Merge 61
………………
Bảng 4.2: Các trƣờng hợp kiểm thử cho Module Split 62
………………………
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
vi
DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ
Hình 1.1: Sản
phẩm
phần
mềm 5
mềm 6
lỗi 7
………………………………………………………….
Hình 1.2: Các
………………………………………
Hình 1.3: Chi phí sửa lỗi theo
…………………………………
Hình 1.4: Kiểm thử phần mềm
…………………………………
Hình 1.5: Giai đoạn kiểm thử
…………………………………..
Hình 1.6: Qui trình kiểm
nguyên
nhân
gây
ra
lỗi
phần
hiện
ngữ
thời
gian
phát
trong
trong
một
số
cảnh 8
mềm 9
mềm 11
thử 13
khiển 15
trình 16
xử
lý
phần
thử
phần
………………………………………………..
Hình 2.1: Luồng thông tin
…………………………………………………….
Hình 2.2: Ví dụ chu trình
…………………………………………………….
Hình 2.3: Ký hiệu đồ thị
kiểm
điều
lƣu
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
vii
……………………………………………………….
Hình 2.4: Điều
kiện
phức 17
trình 17
…………………………………………………………………
Hình 2.5: Lƣu
………………………………………...
Hình 2.6: Độ phức
đồ
thuật
toán
và
đồ
thị
lƣu
tạp
Cyclomat 19
…………………………………………………………
Hình 2.7: Ví dụ minh họa phát sinh các trƣờng hợp kiểm thử theo đƣờng dẫn cơ 20
sở...
Hình 2.8: Các
………………………………………………………………
Hình 2.9: Ví dụ đồ thị nhân
………………………………………………………….
Hình 3.1: Chiến lƣợc kiểm
…………………………………………………………...
Hình 3.2: Các bƣớc kiểm
…………………………………………………………….
Hình 3.3: Mật độ lỗi là hàm thời gian
………………………………………...
kiểu
vòng
lặp 25
quả 33
thử 38
thử 39
hiện 41
thực
Hình 3.4: Quan hệ giữa chi phí kiểm thử và số lỗi chƣa đƣợc phát hiện 42
………………
Hình 3.5: (a) Kiểm thử đơn vị
(b) Môi trƣờng kiểm thử đơn vị 44
………………………
Hình 3.6: Kiểm
…………………………………………………………
Hình 3.7: Tích hợp Bottom
…………………………………………………………
Hình 4.1: Giao diện kiểm thử
thử
Top
–
Down 46
Up 47
–
nhúng 56
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
viii
…………………………………………………….
Hình 4.2: Minh họa thuật toán
MergeSort……………………………………..
Hình 4.3: Đồ thị lƣu trình của
Merge………………………………………...
sắp
xếp 57
năng 59
chức
Hình 4.4: Giao
MergeSort……………………….
Hình 4.5: Kết quả đƣợc
diện
điều
khiển
kiểm
thử
thuật
toán 64
ghi
ra
FileLog 64
…………………………………………………..
Hình 4.6: Giao diện điều khiển kiểm thử khả năng thực hiện của các thuật toán sắp 65
xếp..
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
ix
MỞ ĐẦU
1. Lý do chọn đề tài
Với sự phát triển như vũ bão của công nghệ thông tin nói chung và công
nghệ phần mềm nói riêng, việc phát triển phần mềm ngày càng được hỗ trợ bởi
nhiều công cụ tiên tiến, giúp cho việc xây dựng phần mềm đỡ mệt nhọc và hiệu quả
hơn. Tuy nhiên, vì độ phức tạp của phần mềm và những giới hạn về thời gian và chi
phí, cho dù các hoạt động đảm bảo chất lượng phần mềm nói chung và kiểm thử nói
riêng ngày càng chặt chẽ và khoa học, vẫn không đảm bảo được rằng các sản phẩm
phần mềm đang được ứng dụng không có lỗi. Lỗi vẫn luôn tiềm ẩn trong mọi sản
phẩm phần mềm và cũng có thể gây những thiệt hại khôn lường.
Kiểm thử phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn phát
triển phần mềm để đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết kế và các
yêu cầu đó đáp ứng các nhu cầu của người dùng. Các kỹ thuật kiểm thử phần mềm
đã, đang được nghiên cứu, và việc kiểm thử phần mềm đã trở thành qui trình bắt
buộc trong các dự án phát triển phần mềm trên thế giới. Kiểm thử phần mềm là một
hoạt động rất tốn kém, mất thời gian, và khó phát hiện được hết lỗi. Vì vậy, việc
kiểm thử phần mềm đòi hỏi phải có chiến lược phù hợp, một kế hoạch hợp lý và
việc thực hiện được quản lí chặt chẽ.
Ở Việt Nam, trong thời gian qua việc kiểm thử phần mềm bị xem nhẹ, với
công cụ lập trình hiện đại, người ta cảm tính cho rằng không kiểm thử cũng không
sao, nên chưa có nhiều sự quan tâm, nghiên cứu. Những năm gần đây, một số tổ
chức nghiên cứu và phát triển phần mềm đã bắt đầu có những quan tâm hơn đến vấn
đề kiểm thử phần mềm. Tuy nhiên, vấn đề kiểm thử phần mềm hầu như vẫn chưa
được đầu tư và quan tâm đúng mức. Nước ta đang trong quá trình xây dựng một
ngành công nghiệp phần mềm thì không thể xem nhẹ việc kiểm thử phần mềm vì
xác suất thất bại sẽ rất cao, hơn nữa, hầu hết các công ty phần mềm có uy tín đều
đặt ra yêu cầu nghiêm ngặt là nếu một phần mềm không có tài liệu kiểm thử đi kèm
thì sẽ không được chấp nhận.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
1
2. Mục tiêu và nhiệm vụ nghiên cứu
- Luận văn tập trung nghiên cứu, tìm hiểu, đánh giá các nguyên lý, chiến lược
và kỹ thuật kiểm thử phần mềm.
- Thiết kế các trường hợp kiểm thử áp dụng cho một vài chương trình cụ thể.
3. Đối tƣợng và phạm vi nghiên cứu
Qui trình và bản chất của các kỹ thuật kiểm thử hộp đen và kiểm thử hộp
trắng.
Chiến lược kiểm thử phần mềm.
Đặc tả thiết kế kiểm thử.
4. Phƣơng pháp nghiên cứu
- Nghiên cứu, tìm hiểu các kỹ thuật, chiến lược kiểm thử phần mềm.
- Sử dụng các phương pháp kiểm thử đã nghiên cứu, thiết kế bộ test cho
chương trình cụ thể. Đưa ra tài liệu kế hoạch kiểm thử và đặc tả kiểm thử;
xây dựng chương trình thực thi kiểm thử.
5. Dự kiến kết quả
- Thiết kế các trường hợp kiểm thử cho một số chương trình cụ thể.
- Tạo các tài liệu kiểm thử (đặc tả trường hợp kiểm thử và kết quả kiểm thử.)
- Xây dựng chương trình kiểm thử.
6. Ý nghĩa khoa học và thực tiễn của Luận văn
Kết quả nghiên cứu có thể làm tài liệu tham khảo cho các cơ sở đang tiến tới
đưa qui trình kiểm thử phần mềm thành một qui trình bắt buộc trong dự án phát
triển phần mềm của họ.
7. Đặt tên đề tài
“Một số kỹ thuật kiểm thử phần mềm.”
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
2
8. Bố cục của Luận văn
Toàn bộ nội dung của Luận văn được chia thành 4 chương như sau:
Chƣơng 1: Vấn đề chất lượng phần mềm và kiểm thử phần mềm.
Chƣơng 2: Các kỹ thuật kiểm thử phần mềm
Chƣơng 3: Chiến lược kiểm thử phần mềm
Chƣơng 4: Một số ứng dụng cụ thể (của qui trình kiểm thử)
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
3
CHƢƠNG 1
VẤN ĐỀ CHẤT LƢỢNG PHẦN MỀM
VÀ KIỂM THỬ PHẦN MỀM
1.1. Sản phẩm phần mềm và vấn đề kiểm thử phần mềm
1.1.1. Sản phẩm phần mềm là gì?
Phần mềm là một (bộ) chương trình được cài đặt trên máy tính nhằm thực hiện
một nhiệm vụ tương đối độc lập nhằm phục vụ cho một ứng dụng cụ thể việc quản
lý họat động của máy tính hoặc áp dụng máy tính trong các họat động kinh tế, quốc
phòng, văn hóa, giáo dục, giải trí,…
Việc tạo ra một sản phẩm phần mềm phải trải qua nhiều giai đoạn, người ta gọi
là qui trình phát triển phần mềm, bắt đầu từ khi bắt đầu có ý tưởng cho đến khi đưa
ra sản phẩm phần mềm thực thi. Khối lượng công việc trong từng giai đoạn của quá
trình sản xuất phần mềm cũng thay đổi theo thời gian. Bảng 1.1 minh họa cụ thể hơn
về điều này.
Bảng 1.1 - Tỉ lệ công việc của các giai đoạn phát triển phần mềm
Phân
tích
yêu cầu
Thiết
kế
sơ bộ
Lập trình và
kiểm thử đơn
vị
Tích hợp và
kiểm thử tích
hợp
Kiểm
thử
hệ thống
Thiết kế
chi tiết
Giai đoạn
Hai thập kỉ 1960 - 1970
Thập kỉ 1980
10%
80%
60%
10%
20%
20%
Thập kỉ 1990
40%
30%
30%
Theo một tài liệu khác [5], chi phí liên quan từng giai đoạn của vòng đời phần
mềm như sau:
Các giai đoạn phát triển
Giai đoạn sản phẩm
Phân tích yêu cầu
Đặc tả
3%
3%
Vận hành và bảo trì
67%
Thiết kế
5%
7%
Lập trình
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
4
Kiểm thử
15%
Như vậy, một sản phẩm phần mềm không chỉ đơn giản là các đoạn mã chương
trình mà còn rất nhiều phần ẩn đằng sau nó (Hình 1.1). Vì vậy, việc mắc lỗi không
chỉ xảy ra trong khi lập trình mà còn xảy ra cao hơn trong các công đoạn khác của
qui trình phát triển một sản phẩm phần mềm. Việc kiểm thử cũng vì thế phải được
tiến hành trong tất cả các phần tạo nên một sản phẩm phần mềm.
Đặc tả
sản phẩm
Duyệt lại
sản phẩm
Tài liệu
thiết kế
Tài liệu
kiểm thử
Lịch biểu
Phản hồi từ
phiên bản
cũ
Khảo sát
khách hàng
Thông tin
cạnh tranh
Dữ liệu
Mã nguồn
Kiến trúc
phần mềm
Sản phẩm
cuối cùng
Setup, Help Files, Samples asn
Examples, Readme files, Error
Messages, Icons and Arts, User
Manuals, Product Support
Information, …
Hình 1.1 – Sản phẩm phần mềm
1.1.2. Thế nào là lỗi phần mềm?
Có rất nhiều định nghĩa khác nhau về lỗi phần mềm, nhưng tựu chung, có thể
phát biểu một cách tổng quát: “Lỗi phần mềm là sự không khớp giữa chương trình
và đặc tả của nó.” [7]
Dựa vào định nghĩa, chúng ta có thể thấy lỗi phần mềm xuất hiện theo ba dạng
sau:
Sai: Sản phẩm được xây dựng khác với đặc tả.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
5
Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản phẩm
được xây dựng.
Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả.
Cũng có trường hợp yêu cầu này có thể là một thuộc tính sẽ được người
dùng chấp nhận nhưng khác với đặc tả nên vẫn coi là có lỗi.
Một hình thức khác nữa cũng được xem là lỗi, đó là phần mềm khó hiểu, khó
sử dụng, chậm hoặc dễ gây cảm nhận rằng phần mềm họat động không đúng.
1.1.3. Tại sao lỗi phần mềm xuất hiện?
Khác với sự cảm nhận thông thường, lỗi xuất hiện nhiều nhất không phải do
lập trình. Nhiều nghiên cứu đã được thực hiện trong các dự án từ rất nhỏ đến các dự
án rất lớn và kết quả luôn giống nhau. Số lỗi do đặc tả gây ra là nhiều nhất, chiếm
khoảng 80%. Có một số nguyên nhân làm cho đặc tả tạo ra nhiều lỗi nhất. Trong
nhiều trường hợp, đặc tả không được viết ra. Các nguyên nhân khác có thể do đặc tả
không đủ cẩn thận, nó hay thay đổi, hoặc do chưa phối hợp tốt trong toàn nhóm
phát triển. Sự thay đổi yêu cầu của khách hàng cũng là nguyên nhân dễ gây ra lỗi
phần mềm. Khách hàng thay đổi yêu cầu không cần quan tâm đến những tác động
sau khi thay đổi yêu cầu như phải thiết kế lại, lập lại kế hoạch, làm lại những việc
đã hoàn thành. Nếu có nhiều sự thay đổi, rất khó nhận biết hết được phần nào của
dự án phụ thuộc và phần nào không phụ thuộc vào sự thay đổi. Nếu không giữ được
vết thay đổi rất dễ phát sinh ra lỗi.
Nguyên nhân khác
Lập trình
Thiết kế
Đặc tả
Hình 1.2 – Các nguyên nhân gây ra lỗi phần mềm
Nguồn gây ra lỗi lớn thứ hai là thiết kế. Đó là nền tảng mà lập trình viên dựa
vào để nỗ lực thực hiện kế hoạch cho phần mềm.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
6
Lỗi do lập trình gây ra cũng khá dễ hiểu. Ai cũng có thể mắc lỗi khi lập trình.
Thời kì đầu, phát triển phần mềm có nghĩa là lập trình, công việc lập trình thì nặng
nhọc, do đó lỗi do lập trình gây ra là chủ yếu. Ngày nay, công việc lập trình chỉ là
một phần việc của quá trình phát triển phần mềm, cộng với sự hỗ trợ của nhiều công
cụ lập trình cao cấp, việc lập trình trở nên nhẹ nhàng hơn, mặc dù độ phức tạp phần
mềm lớn hơn rất nhiều. Do đó, lỗi do lập trình gây ra cũng ít hơn. Tuy nhiên,
nguyên nhân để lập trình tạo ra lỗi lại nhiều hơn. Đó là do độ phức tạp của phần
mềm, do tài liệu nghèo nàn, do sức ép thời gian hoặc chỉ đơn giản là những lỗi
“không nói lên được”. Một điều cũng hiển nhiên là nhiều lỗi xuất hiện trên bề mặt
lập trình nhưng thực ra lại do lỗi của đặc tả hoặc thiết kế.
Một nguyên nhân khác tạo ra lỗi là do bản thân các công cụ phát triển phần
mềm cũng có lỗi như công cụ trực quan, thư viện lớp, bộ biên dịch,…
1.1.4. Chi phí cho việc sửa lỗi
Theo tài liệu trích dẫn của Martin và McCable [7], bảo trì là phần chi phí
chính của phần mềm và kiểm thử là hoạt động chi phí đắt thứ hai, ước tính khoảng
40% (15/33) chi phí trong quá trình phát triển ban đầu của sản phẩm phần mềm.
Kiểm thử cũng là phần chi phí chính của giai đoạn bảo trì do phải tiến hành kiểm
thử lại những thay đổi trong quá trình sửa lỗi và đáp ứng yêu cầu người dùng.
Kiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng
đời phần mềm. Tuy nhiên chi phí cho việc tìm và sửa lỗi tăng một cách đáng kể
trong quá trình phát triển.
Trong tài liệu Boehm [5], có trích dẫn kết quả nghiên cứu của IBM, GTE và
TRW, tổng kết rằng lỗi được phát hiện càng muộn thì chi phí cho việc sữa lỗi càng
lớn. Chi phí tăng theo hàm mũ như hình sau.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
7
Đặc tả Thiết kế lập trình Kiểm thử Phát hành
Hình 1.3 – Chi phí sửa lỗi theo thời gian phát hiện lỗi
1.1.5. Kiểm thử phần mềm là gì?
Kiểm thử phần mềm thường đồng nghĩa với việc tìm ra lỗi chưa được phát
hiện. Tuy nhiên, có nhiều bối cảnh kiểm thử không bộc lộ ra lỗi. Kiểm thử phần
mềm là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm đó
có đúng với đặc tả không và thực hiện trong môi trường như mong đợi hay không.
Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện, tìm một
cách sớm nhất và đảm bảo rằng lỗi đã được sửa, mà kiểm thử phần mềm không làm
công việc chẩn đoán nguyên nhân gây ra lỗi đã được phát hiện và sửa lỗi.
Mục tiêu của kiểm thử phần mềm là thiết kế tài liệu kiểm thử một cách có hệ
thống và thực hiện nó sao cho có hiệu quả, nhưng tiết kiệm được thời gian, công
sức và chi phí.
1.2. Chất lƣợng phần mềm
Chất lượng phần mềm là một khái niệm đa chiều, không dễ định nghĩa đơn
giản theo cách chung cho các sản phẩm là: “Sản phẩm được phát triển phù hợp với
đặc tả của nó.” [8]. Có một số vấn đề khó trong hệ thống phần mềm, đó là:
Đặc tả phải định hướng theo những đòi hỏi về chất lượng của khách hàng
(như tính hiệu quả, độ tin cậy, tính dễ hiểu, tính bảo mật,…) và những yêu
cầu của chính tổ chức phát triển phần mềm vốn không có trong đặc tả
(như các yêu cầu về khả năng bảo trì, tính sử dụng lại,..)
Một số yêu cầu về chất lượng cũng rất khó chỉ ra một cách rõ ràng.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
8
Những đặc tả phần mềm thường không đầy đủ và hay mâu thuẫn.
Công nghệ hệ thống
Công nghệ phần mềm
Quản lý và đảm bảo chất lượng
Đảm bảo chất lượng phần mềm
Xác minh và thẩm định phần
mềm
Xác minh và thẩm định phần
mềm
Kiểm thử phần mềm
Kiểm thử phần mềm
(a) Ngữ cảnh quy trình
(b) Ngữ cảnh chất lượng
Hình 1.4 - Kiểm thử phần mềm trong một số ngữ cảnh
Trên quan điểm qui trình, kiểm thử phần mềm là một phần của xác minh và
thẩm định phần mềm. Xác minh và thẩm định nằm trong công nghệ phần mềm,
công nghệ phần mềm lại là một phần của công nghệ hệ thống (Hình 1.4a). Nhìn từ
ngữ cảnh chất lượng (Hình 1.4b), kiểm thử phần mềm cũng là một phần của xác
minh và thẩm định phần mềm, nên cũng có thể xem như là một phần của đảm bảo
chất lượng phần mềm. Nếu phần mềm là thành phần của hệ thống lớn hơn thì kiểm
thử phần mềm cũng được xem như là một phần của quản lý và đảm bảo chất lượng.
Và để đạt phần mềm chất lượng cao, thì kiểm thử có thể coi là một thành phần chủ
yếu của hoạt động đảm bảo chất lượng phần mềm.
1.3. Qui trình kiểm thử phần mềm
Mục đích của kiểm thử là thiết kế một chuỗi các trường hợp kiểm thử mà có
khả năng phát hiện lỗi cao. Để cho việc kiểm thử đạt được kết quả tốt cần có sự
chuẩn bị về kế hoạch kiểm thử, thiết kế các trường hợp kiểm thử và các dữ liệu
kiểm thử cho các trường hợp. Đây chính là đầu vào cho giai đoạn kiểm thử. Và sản
phẩm công việc của giai đoạn kiểm thử chính là “báo cáo kiểm thử” mà tài liệu hóa
tất cả các trường hợp kiểm thử đã chạy, dữ liệu đầu vào, đầu ra mong đợi, đầu ra
thực tế và mục đích của kiểm thử,… (như Hình 1.5)
KIỂM THỬ
Bàn giao SP
Phân tích
Thiết kế
Mã hóa
Kế hoạch kiểm thử
Các trường hợp kiểm thử
Dữ liệu kiểm thử
Các báo cáo kiểm thử
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
9
Hình 1.5 – Giai đoạn kiểm thử trong xử lý phần mềm
Qui trình kiểm thử bao gồm một số giai đoạn:
Lập kế hoạch kiểm thử. Bước đầu tiên là lập kế hoạch cho tất cả các hoạt
động sẽ được thực hiện và các phương pháp được sử dụng. Các chuẩn
IEEE bao gồm các thông tin về tác giả chuẩn bị kế hoạch, danh sách liệt
kê của kế hoạch kiểm thử. Vấn đề quan trọng nhất đối với kế hoạch kiểm
thử [6,7]:
+ Mục đích: Qui định về phạm vi, phương pháp, tài nguyên và lịch biểu
của các hoạt động kiểm thử.
+ Các tài liệu tham khảo.
+ Các định nghĩa.
+ Khái quát về xác minh và thẩm định (V&V): tổ chức, tài nguyên, trách
nhiệm, các công cụ, kỹ thuật và các phương pháp luận.
+ Vòng đời của V&V: các nhiệm vụ, các dữ liệu vào và các kết quả ra trên
một giai đoạn vòng đời.
+ Báo cáo xác minh và thẩm định(V&V) phần mềm: mô tả nội dung, định
dạng và thời gian cho tất cả các báo cáo V&V.
+ Các thủ tục quản lý V&V bao gồm các chính sách, thủ tục, các chuẩn,
thực nghiệm và các qui ước.
Giai đoạn bố trí nhân viên kiểm thử. Việc kiểm thử thường phải tiến hành
một cách độc lập và các nhóm độc lập có trách nhiệm tiến hành các họat
động kiểm thử, gọi là các nhóm kiểm thử.
Thiết kế các trường hợp kiểm thử. Các trường hợp kiểm thử là các đặc tả
đầu vào cho kiểm thử và đầu ra mong đợi của hệ thống cùng với các câu
lệnh được kiểm thử.
+ Các phương pháp hộp đen để kiểm thử dựa trên chức năng.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
10
+ Các phương pháp hộp trắng để kiểm thử dựa vào cấu trúc bên trong.
Xử lý đo lường kiểm thử bằng cách thu thập dữ liệu.
Đánh giá sản phẩm phần mềm để xác nhận sản phẩm có thể sẵn sàng phát
hành được chưa?
Mô hình chung của qui trình kiểm thử phần mềm được thể hiện trong hình 1.6.
Phân tích
Thiết kế
Mã hóa
KIỂM THỬ
Chạy chương
trình với dữ
liệu kiểm thử
So sánh các
kết quả với
các trường
hợp kiểm thử
Thiết kế các
trường hợp
kiểm thử
Chuẩn bị dữ
liệu kiểm thử
Các trường
hợp
kiểm thử
Kết quả
kiểm thử
Kết quả
Dữ liệu
kiểm thử
kiểm thử
Hình 1.6 – Qui trình kiểm thử phần mềm
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
11
CHƢƠNG 2
CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM
Có thể sử dụng một số kỹ thuật trong quá trình kiểm thử nhằm tăng hiệu quả
của họat động này. Mc Gregor mô tả các kỹ thuật kiểm thử như những công cụ
được thiết kế để đảm bảo rằng tất cả các khía cạnh của sản phẩm đều được khảo sát
[1]. Mặt khác, các kỹ thuật kiểm thử là những công cụ để dễ dàng đạt được hiệu quả
kiểm thử.
Có thể chia các kỹ thuật kiểm thử phần mềm thành hai loại: các kỹ thuật kiểm
thử hộp đen (black-box testing) và kỹ thuật kiểm thử hộp trắng (white-box testing).
Kiểm thử sử dụng kỹ thuật hộp đen thường được gọi đơn giản là các kiểm thử
black-box. Các kiểm thử black-box tìm các lỗi như thiếu các chức năng, khả năng
sử dụng và các yêu cầu phi chức năng.
Các kỹ thuật kiểm thử white-box yêu cầu hiểu biết về cấu trúc chương trình
bên trong và các kiểm thử nhận được từ đặc tả thiết kế bên trong hoặc từ mã [2].
2.1. Nguyên tắc cơ bản kiểm thử phần mềm
Trong lúc kiểm thử, công nghệ phần mềm phát sinh một chuỗi các trường hợp
kiểm thử được sử dụng để “tách từng phần” phần mềm. Kiểm thử là một bước trong
qui trình phần mềm mà có thể được xem xét bởi đội ngũ phát triển bằng cách phá
vỡ thay vì xây dựng. Các kỹ sư phần mềm chính là những người xây dựng và việc
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
12
kiểm thử yêu cầu họ vượt qua các khái niệm cho trước về độ chính xác và giải quyết
mâu thuẫn khi các lỗi được xác định.
2.1.1. Mục tiêu kiểm thử
Các nguyên tắc được xem như mục tiêu kiểm thử là:
Kiểm thử là một quá trình thực thi chương trình với mục đích tìm lỗi.
Một trường hợp kiểm thử tốt là trường hợp kiểm thử mà có khả năng cao
việc tìm thấy các lỗi chưa từng được phát hiện.
Một kiểm thử thành công là kiểm thử mà phát hiện lỗi chưa từng được phát
hiện.
2.1.2. Luồng thông tin kiểm thử
Luồng thông tin cho kiểm thử được biểu diễn bởi mô hình trong hình 2.1. Hai
kiểu của đầu vào được truyền cho quá trình kiểm thử:
Cấu hình phần mềm: gồm các đặc tả yêu cầu, đặc tả thiết kế, và mã nguồn.
Cấu hình kiểm thử: gồm có kế hoạch kiểm thử, các thủ tục, trường hợp kiểm
thử, và các công cụ kiểm thử.
Gỡ rối
Cấu hình phần mềm
Lỗi
Kết quả
kiểm thử
Hiệu chỉnh
Kiểm
thử
đánh
giá
Dữ liệu tỷ lệ lỗi
Mô hình
tin cậy
Dự đoán độ tin cậy
Kết quả mong đợi
Cấu hình kiểm thử
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
13
Hình 2.1 - Luồng thông tin kiểm thử
2.1.3. Thiết kế trƣờng hợp kiểm thử
Thiết kế kiểm thử phần mềm có thể là một quá trình thu thập, phân tích và
thực hiện yêu cầu. Mục tiêu của kiểm thử là phải thiết kế các trường hợp kiểm thử
có khả năng cao nhất trong việc phát hiện nhiều lỗi nhất với thời gian và công sức
tối thiểu. Như vậy, vấn đề quan trọng nhất trong kiểm thử phần mềm là thiết kế và
tạo ra các trường hợp kiểm thử có hiệu quả. Lý do về tầm quan trọng của việc thiết
kế các trường hợp kiểm thử xuất phát từ thực tế: Kiểm thử “vét cạn” là điều không
thể, và như vậy, kiểm thử một chương trình phải luôn xác định là không thể vét cạn.
Vấn đề quan trọng là cố gắng làm giảm sự “không thể vét cạn” nhiều nhất có thể.
Kiểm thử phần mềm còn có các ràng buộc về thời gian, chi phí, … Chìa khoá
của kiểm thử là trả lời của câu hỏi: “Tập con của tất cả các trường hợp kiểm thử có
thể có xác suất phát hiện lỗi cao nhất là gì?”. Việc nghiên cứu các phương pháp
thiết kế trường hợp kiểm thử sẽ cung cấp câu trả lời cho câu hỏi này.
Bất kỳ sản phẩm công nghệ nào có thể được kiểm thử trong hai cách:
Biết về các chức năng cụ thể mà sản phẩm đã được thiết kế để thực hiện.
Biết cách hoạt động bên trong của sản phẩm, kiểm thử có thể được thực
hiện để đảm bảo rằng “tất cả các thành phần ăn khớp nhau”.
Cách tiếp cận kiểm thử đầu tiên được gọi là kiểm thử hộp đen và cách thứ hai
là kiểm thử hộp trắng.
2.2. Kỹ thuật kiểm thử hộp trắng (White-Box Testing)
Kiểm thử hộp trắng hay còn gọi là kiểm thử hướng logic, cho phép kiểm tra
cấu trúc bên trong của phần mềm với mục đích đảm bảo rằng tất cả các câu lệnh và
điều kiện sẽ được thực hiện ít nhất một lần.
Hộp trắng đúng nghĩa phải gọi là hộp trong suốt . Chính vì vậy, kỹ thuật này
còn có một số tên khác là kiểm thử hộp thuỷ tinh (Glass-Box Testing), hay kiểm thử
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
14
hộp trong suốt (Clear-Box Testing). Người kiểm thử truy nhập vào mã nguồn
chương trình và có thể kiểm tra nó, lấy đó làm cơ sở để hỗ trợ việc kiểm thử.
Tương tự như vấn đề kiểm thử đầu vào trong kỹ thuật kiểm thử hộp đen, đó là
vấn đề kiểm thử các đường dẫn lệnh trong kỹ thuật hộp trắng. Nếu phải thực hiện
tất cả các đường dẫn của lưu trình điều khiển trong chương trình thông qua việc
chạy tất cả các trường hợp kiểm thử thì có thể nói rằng chương trình đã được kiểm
thử triệt để. Tuy nhiên điều đó không thể thực hiện được vì số đường dẫn logic khác
nhau trong một chương trình là cực kỳ lớn. Ví dụ trong hình 2.2, sơ đồ khối của một
chu trình điều khiển. Sơ đồ biểu diễn một vòng lặp từ 1 đến 20 lần. Trong thân của
vòng lặp có một tập các lệnh điều kiện rẽ nhánh lồng nhau. Số đường dẫn trong
vòng lặp là 5. Như vậy, tổng số đường dẫn có thể là (5 + 52 + 53 + … + 520) khoảng
xấp xỉ 1014.
Ngoài những điều bất khả thi như trên, chương trình cũng có thể còn nhiều lỗi
do các nguyên nhân khác. Đây chính là nhược điểm của kỹ thuật kiểm thử hộp
trắng.
Việc kiểm thử bằng kỹ thuật hộp trắng không thể đảm bảo rằng chương trình
đã tuân theo đặc tả.
Một chương trình sai do thiếu đường dẫn. Việc kiểm thử hộp trắng không thể
biết được sự thiếu sót này.
Việc kiểm thử bằng kỹ thuật hộp trắng không thể phát hiện được lỗi do dữ
liệu.
Như vậy, việc kiểm thử chỉ dùng kỹ thuật hộp trắng là không đủ để phát hiện
lỗi. Vì vậy, khi thiết kế các trường hợp kiểm thử thường cần phải kết hợp với cả kỹ
thuật kiểm thử hộp đen.
Nguyên tắc của kỹ thuật kiểm thử hộp trắng là:
Thực hiện mọi đường dẫn độc lập ít nhất một lần.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
15
Thực hiện mọi điều kiện logic (if-then-else) trên các giá trị true và false của
chúng.
Thực hiện mọi vòng lặp (các vòng lặp for, while-do) tại các biên và trong
phạm vi hoạt động của chúng.
Thực hiện mọi cấu trúc dữ liệu bên trong để đảm bảo tính hợp lệ của chúng.
lặp <20 lần
Hình 2.2- Ví dụ chu trình điều khiển
2.2.1. Kiểm thử đƣờng dẫn cơ sở (Basic Path Testing)
Kiểm thử đường dẫn cơ sở là một kỹ thuật kiểm thử hộp trắng do Tom
McCabe đề xuất. Phương pháp đường dẫn cơ sở cho phép người thiết kế trường hợp
kiểm thử thực hiện phép đo độ phức tạp logic của thiết kế thủ tục và sử dụng phép
đo này như một chỉ dẫn cho việc thiết kế một tập cơ sở các đường dẫn thực hiện.
Những trường hợp kiểm thử được suy diễn để thực hiện tập cơ sở. Các trường hợp
kiểm thử đó được đảm bảo để thực hiện mỗi lệnh trong chương trình ít nhất một lần
trong quá trình kiểm thử.
2.2.1.1. Đồ thị lưu trình (Flow Graph)
Trong thực tế, phương pháp đường dẫn cơ sở có thể được dùng không cần sử
dụng đồ thị lưu trình. Tuy nhiên, đồ thị lưu trình là một công cụ hữu ích để hiểu lưu
trình điều khiển và minh hoạ phương pháp tiếp cận. Phần này sẽ trình bày một số ký
hiệu đơn giản của lưu trình điều khiển, được gọi là đồ thị lưu trình. Đồ thị lưu trình
vẽ lưu trình điều khiển logic sử dụng một số ký hiệu được minh hoạ như hình 2.3.
Mỗi cấu trúc điều khiển có một ký hiệu đồ thị lưu trình tương ứng.
Đồ thị lưu trình gồm có:
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
16
Mỗi hình tròn gọi là đỉnh, biểu diễn một hoặc nhiều lệnh thủ tục.
Con trỏ được gọi là cung hoặc liên kết biểu diễn lưu trình điều khiển. Một
cung cần phải kết thúc tại một đỉnh.
Mỗi đỉnh có chứa điều kiện gọi là đỉnh điều kiện.
Phần được bao bởi các cung và các đỉnh gọi là vùng.
Tuần tự
Rẽ nhánh
Lựa chọn
Lặp While
Hình 2.3- Ký hiệu đồ thị lƣu trình
Biểu diễn các điều kiện phức trong đồ thị lưu trình
Khi gặp các điều kiện phức xuất hiện trong câu lệnh điều kiện được biểu diễn
gồm một hoặc nhiều phép toán logic (AND, OR, NOT), cần phải được chia thành
các điều kiện đơn trong thực hiện kiểm thử đường dẫn cơ sở. Mỗi đỉnh chứa điều
kiện được gọi là đỉnh điều kiện và được đặc trưng bởi hai hoặc nhiều cạnh bắt
nguồn từ nó.
Ví dụ: if (a OR b) then {Procedure x } else {Procedure y}
if (c AND d) then {Procedure x} else {Procedure y}
a
c
b
d
y
y
x
x
Hình 2.4 - Điều kiện phức
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
17
Ví dụ: Cho lưu đồ thuật toán như hình 2.5a, đồ thị lưu trình có thể xác định
như hình 2.5b..
Cạnh
1
2
2,3
Đỉn
6
4,5
R2
6
4
5
R3
8
7
R1
8
7
9
Vùng
9
10
11
R4
10
11
(a)
(b)
Hình 2.5 – Lƣu đồ thuật toán (a) và đồ thị lƣu trình (b)
2.2.1.2. Độ phức tạp cyclomat
Độ phức tạp cyclomat là một thước đo phần mềm, cung cấp phép đo định
lượng độ phức tạp của chương trình. Khi được sử dụng trong ngữ cảnh của phương
pháp đường dẫn cơ sở, giá trị được xác định cho độ phức tạp cyclomat cho biết số
lượng đường dẫn độc lập trong một tập cơ sở của chương trình và cung cấp cho
chúng ta một giới hạn trên số lượng kiểm thử bắt buộc để đảm bảo rằng tất cả các
câu lệnh được thực hiện ít nhất một lần.
Một đường dẫn độc lập là một đường dẫn bất kỳ trong chương trình đưa ra ít
nhất một tập lệnh xử lý hoặc điều kiện mới.
Tập đường dẫn độc lập cho đồ thị lưu trình được minh hoạ trong hình 2.5b là:
Đường dẫn 1: 1-11
Đường dẫn 2: 1-2-3-4-5-10-1-11
Đường dẫn 3: 1-2-3-6-8-9-10-1-11
Đường dẫn 4: 1-2-3-6-7-9-10-1-11
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
18
Mỗi đường dẫn mới đưa ra một cung mới. Đường dẫn 1-2-3-4-5-10-1-2-3-6-8-
9-10-1-11 không được xem là một đường dẫn độc lập vì nó chỉ là một tổ hợp các
đường dẫn đã được chỉ ra (đường dẫn 2 và 3) và nó sẽ không đi qua một cung mới
nào.
Các đường dẫn 1, 2, 3 và 4 tạo thành một tập cơ sở trong hình 2.5b. Nếu các
trường hợp kiểm thử được thiết kế để thực hiện những đường dẫn này (một tập cơ
sở) thì mọi lệnh trong chương trình sẽ đảm bảo được thực hiện ít nhất một lần và
mọi điều kiện sẽ được thực hiện cả hai mặt đúng (true) và mặt sai (false). Tuy
nhiên, tập cơ sở không phải là duy nhất. Trong thực tế, một số các tập cơ sở khác
nhau có thể được suy diễn cho việc thiết kế một thủ tục được đưa ra.
Một số nghiên cứu công nghiệp đã chỉ rằng độ phức tạp Cyclomat càng cao,
xác suất hoặc lỗi càng cao.
modules
V(G)
Các module trong vùng này dễ xảy ra nhiều lỗi
Hình 2.6 - Độ phức tạp Cyclomat
Việc tính toán độ phức tạp cyclomat sẽ cho chúng ta biết có bao nhiêu đường
dẫn cần tìm. Cho đồ thị lưu trình G, độ phức tạp Cyclomat V(G) được tính theo một
trong 3 công thức sau (dựa trên Lý thuyết đồ thị):
1. V(G) = R, trong đó R là số vùng của đồ thị lưu trình.
2. V(G) = P + 1, trong đó P là số đỉnh điều kiện có trong đồ thị lưu trình G.
3. V(G) = E – N + 2, trong đó E là số cạnh của đồ thị lưu trình, N là số đỉnh
của đồ thị lưu trình G.
Đối chiếu với đồ thị lưu trình trong hình 2.5b, độ phức tạp Cyclomat được tính
như sau:
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
19
Tải về để xem bản đầy đủ
79 trang
26/05/2025
190
Bạn đang xem 30 trang mẫu của tài liệu "Luận văn Một số kỹ thuật kiểm thử phần mềm", để tải tài liệu gốc về máy hãy click vào nút Download ở trên.
File đính kèm:
- luan_van_mot_so_ky_thuat_kiem_thu_phan_mem.pdf
