Ƣ
Ệ

VIỆ

ỀN THÔNG
Ệ

Ồ ÁN

ƢƠ

Ề

CÔNG NGHỆ PH N MỀM

ề tài 04
TÌM HIỂU CÁC KỸ THUẬT KIỂM THỬ PH N MỀM
Giảng viên hƣớng dẫn: Thầy Lƣơng

ạnh Bá.

Sinh viên thực hiện: Nhóm 01.
1.

han ăng

ƣng.

2.



Bắt đầu viết

Cả nhóm

1.0

27/10/2010

Sửa đổi

Cả nhóm

1.1

Nhóm 01- Lớp công nghệ phần mềm K52

Page 2


Báo cáo Đại cương Công nghệ phần mềm

hần 1:
1.

Các kỹ thuật kiểm thử phần mềm. ........................................................................................... 7
1.1.

Các khái niệm cơ bản. ...................................................................................................... 7


Kế thừa ca kiểm thử. ............................................................................................... 17

1.3.4.

Ma trận đồ thị. ......................................................................................................... 21

1.4.

Kiểm thử cấu trúc điều khiển. ........................................................................................ 23

1.4.1.

Kiểm thử điều kiện.................................................................................................. 23

1.4.2.

Kiểm thử luồng dữ liệu. .......................................................................................... 25

1.4.3.

Kiểm thử vòng lặp. ................................................................................................. 28

1.5.

Kiểm thử hộp đen. .......................................................................................................... 28

1.5.1.

Kiểm thử dựa vào đồ thị (Graph-Based). ................................................................ 29


Kiểm thử tài liệu và các thiết bị trợ giúp. ................................................................... 37

1.6.4.

Kiểm thử cho hệ thống thời gian thực: ....................................................................... 38

1.7.
2.

Ụ LỤ
iới thiệu về các kỹ thuật và chiến lƣợc kiểm thử phần mềm ................ 7

Tổng kết.......................................................................................................................... 40

Các chiến lược kiểm thử. ....................................................................................................... 41

Nhóm 01- Lớp công nghệ phần mềm K52

Page 3


Báo cáo Đại cương Công nghệ phần mềm
2.1.

Những đặc điểm cơ bản một chiến lược kiểm thử. ........................................................ 42

2.1.3.

Chiến lược kiểm thử phần mềm. ............................................................................. 44


Tích hợp dưới lên. ................................................................................................... 54

2.4.3.

Kiểm thử hồi quy. ................................................................................................... 55

2.4.4.

Chú thích trên kiểm thử tích hợp. ........................................................................... 56

2.4.5.

Tài liệu kiểm thử tích hợp. ...................................................................................... 56

2.5.

Kiểm thử chấp nhận. ...................................................................................................... 58

2.5.1.

Tiêu chuẩn của kiểm thử chấp nhận. ...................................................................... 58

2.5.2.

Xem xét cấu hình. ................................................................................................... 58

2.5.3.

Kiểm thử Alpha và Beta. ........................................................................................ 58


Phương pháp tiếp cận gỡ lỗi. .................................................................................. 63

hần 2: iới thiệu về một số công cụ kiểm thử và khảo sát quy trình kiểm thử
tại công ty phần mềm Fsoft. ............................................................................................... 65
3.
3.1.

Giới thiệu một số bộ kiểm thử phổ biến hiện nay. ............................................................. 65
Defect Management system. .......................................................................................... 65

Nhóm 01- Lớp công nghệ phần mềm K52

Page 4


Báo cáo Đại cương Công nghệ phần mềm
3.1.1.
3.2.

Giới thiệu công cụ BugZero.................................................................................... 65

Một số công cụ kiểm thử chức năng. ............................................................................. 65

3.2.1.

Rational Robot tester............................................................................................... 66

3.2.2.

Quick Test Pro. ....................................................................................................... 66


4.2.4.

Những kỹ năng mà một kiểm thử viên (tester) cần phải có. ................................... 80

4.2.5.

Các quy định và ý nghĩa của kiểm thử. ................................................................... 80

4.2.6.

Kiểm thử cần có đầu vào và đầu ra hợp lý. ............................................................. 81

4.2.7.

Quá trình kiểm thử cần được thực hiện theo mô hình vòng lặp. ............................ 83

4.2.8.

Giới thiệu một số công cụ được sử dụng để kiểm thử tại Fsoft. ............................. 83

4.2.9.

Kịch bản lỗi (defect). .............................................................................................. 84

4.2.10. Sự áp dụng của các kỹ thuật kiểm thử tại Fsoft. ..................................................... 85
4.2.11. Xây dựng tài liệu kiểm thử. .................................................................................... 88
4.2.12. Quản lý sự thay đổi và quản lý điều khiển. ............................................................. 88
4.3.



MSSV
20071484

20073430

Công việc

Liên hệ

Tìm hiểu một số công cụ kiểm thử và

0983193089

khảo sát quy trình kiểm thử tại công ty

(PDHung3012@g

phần mềm Fsoft

mail.com)

Tìm hiểu về một số công cụ kiểm thử và

01688329541

khảo sát quy trình kiểm thử tại công ty
phần mềm Fsoft
Nguyễn Trung Hiếu


thử phần mềm
Toàn bộ nội dung phần 1 được nhóm chúng em tìm hiểu và dịch lại từ cuốn sác (A
practical of Software Engineering- PAOSE) của tác giả R.Pressman tái bản lần thứ 5.

1. Các kỹ thuật kiểm thử phần mềm.
Sự phát triển của hệ thống phần mềm bao gồm mỗi chuỗi các qui trình mà khả năng
có sai sót của con người là rất cao. Các lỗi có thể xảy ra ngay từ khi bắt đầu của tiến trình
khi đối tượng được khai báo. Bởi vì không thể đảm bảo được tính hoàn hảo của phần
mềm, phát triển phần mềm được đi kèm với một hoạt động đảm bảo chất lượng.
Kiểm thử phần mềm là một thành phần chủ chốt của bảo đảm chất lượng phần mềm.
Kiểm thử là tiến trình (và là nghệ thuật) nhằm phát hiện lỗi bằng việc xem xét lại đặc tả,
thiết kế và mã hoá. Kiểm thử là mấu chốt của đảm bảo chất lượng phần mềm.
Sự tăng lên trông thấy của phần mềm như là một hệ thống và sự mất mát khi phần
mềm không hoạt động kích thích cho việc phải có sự kiểm thử hoàn hảo, được tổ chức
tốt. Là bất thường khi một tổ chức phát triển phần mềm có thể sử dụng tới 30 đến 40%
của toàn bộ dự án cho kiểm thử. Thực tế, thời gian cho công việc kiểm thử lên tới 3 đến 5
lần của tất cả các bước phát triển phần mềm còn lại!
Trong phần này, chúng tôi thảo luận về các đặc điểm cở bản của kiểm thử phần mềm
và kỹ thuật thiết kế ca kiểm thử (test case – TC). Thiết kế ca kiểm thử tập trung vào một
tập các kỹ thuật cho việc tạo các ca kiểm thử bao trùm lên toàn bộ mục đích cần kiểm
thử. Trong phần 2, chiến lược kiểm thử và debug phần mềm được giới thiệu.

1.1.

ác khái niệm cơ bản.

Kiểm thử là một điều thú vị. Trong suốt các hoạt động phát triển phần mềm từ trước
đó, kỹ sư đã xây dựng phần mềm từ các khái niệm trừu tượng tới một sản phẩm hoàn
thiện. Bây giờ là công việc kiểm thử. Kỹ sư xây dựng một chuỗi các ca kiểm thử nhằm
đánh đổ phần mềm đã được xây dựng. Thực tế, kiểm thử là một bước trong quá trình phát

Định nghĩa chi tiết của các ca kiểm thử có thể bắt đầu ngay khi thiết kế mô hình hoàn tất.
Do đó, mọi kiểm tra có thể được lên kế hoạch và thiết kế trước khi bắt đầu code.

Nguyên tắc Pareto ứng dụng cho kiểm thử phần mềm. Nói ngắn gọn, nguyên
tắc Pareto cho rằng 80% mọi lỗi bắt được thông qua kiểm thử sẽ có vẻ dò vết được từ
20% mọi thành phần của chương trình. Tất nhiên, vấn đề là tách các thành phần đó ra
riêng biệt và cần kiểm tra chu đáo chúng.

Kiểm thử nên bắt đầu từ các thành phần nhỏ dần tới các thành phần lớn.
Nói chung, các kiểm thử đầu tiên được lên kế hoạch và thực thi trên các thành phần nhỏ
lẻ. Trong quá trình kiểm thử, dần dần tập trung vào kiểm thử tích hợp và kiểm thử toàn
hệ thống.

Kiểm thử thấu đáo là không thể. Số lượng hoán vị tính toán cho thậm chí một
chương trình kích cỡ vừa là cực kì lớn (xem 17.2). Do đó, không thể nào thực thi mọi tổ
hợp trong kiểm tra. Tuy nó, có thể xem xét cấu trúc logic chương trình để đảm bảo rằng

Nhóm 01- Lớp công nghệ phần mềm K52

Page 8


Báo cáo Đại cương Công nghệ phần mềm
mọi điều kiện trong thiết kế các mức thành phần được thỏa mãn.

ể đƣợc kết quả tốt nhất, kiểm thử nên đƣợc chỉ đạo bởi một bên thứ ba
độc lập. Như đã nói, kỹ sư phần mềm làm ra hệ thống không phải là người tốt nhất để
thực hiện việc kiểm thử hệ thống.
1.1.3. hả năng kiểm thử.
Trong hoàn cảnh lý tưởng, kỹ sư phần mềm thiết kế một chương trình, một hệ thống,



Báo cáo Đại cương Công nghệ phần mềm
 Các trạng thái phần mềm và phần cứng và các biến được điều khiển trực tiếp bởi
kỹ sư kiểm thử.
 Dạng đầu vào và đầu ra là thống nhất.
 Các kiểm thử có thể tự động, tự tái tạo, chuyên môn hóa một cách thuận tiện

Khả năng phân tích đƣợc.
 Hệ thống phần mềm được xây dựng từ các module độc lập.
 Module phần mềm có thể được kiểm thử độc lập

Sự đơn giản.
 Chức năng đơn giản, nghĩa là tập các tính năng phải thỏa mãn yêu cầu tối thiểu
của yêu cầu.
 Cấu trúc đơn giản, nghĩa là kiến trúc được modul hóa để giới hạn sự lan truyền lỗi
 Code đơn giản, nghĩa là một chuẩn code được áp dụng cho sự dễ dàng bảo trì và
kế thừa.

Tính bền vững.





Các thay đổi tới phần mềm là không thường xuyên.
Các thay đổi tới phần mềm được kiểm tra.
Các thay đổi tới phần mềm không được không thỏa mãn các ca kiểm thử đã có.
Phần mềm phục hồi tốt khi bị hỏng.


lỗi nhận diện ví trí con chuột.
2. Một kiểm thử tốt không dƣ thừa. Thời gian kiểm thử và tài nguyên bị giới hạn.
Không có lý do nào trong việc dựng một kiểm thử có cùng một mục đích như một
kiểm thử khác. Mỗi kiểm thử nên có một mục đích riêng (thậm chí nó chỉ khác
nhau chút ít). Ví dụ, một modulle phần mềm SafeHome (thảo luận ở chương trước
) được thiết kế để nhận diện password người dùng để kích hoạt hay ngừng kích
hoạt hệ thống. Để phát hiện lỗi trong đầu vào password, người kiểm thử thiết kế
một chuỗi các kiểm thử nhập vào một chuỗi các password. Xác thực và không xác
thực passwords được đưa vào từ các kiểm thử riêng rẽ. Tuy nhiên, mỗi đầu vào ấy
nên ở các dạng thất bại khác nhau. Ví dụ như, password sai 1234 không nên được
chấp nhận trong hệ thống mà nhận 8080 làm password đúng. Nếu nó chấp nhận,
kiểm thử phát hiện được lỗi. Một đầu vào kiểm thử khác là 1235, cũng có cùng
mục đích như 1234 và như vậy là trùng lặp. Tuy nhiên, đầu vào 8081 hoặc 8180
có khác nhau một tí so với đầu vào kiểm thử 1234 ở trên, bởi nó có thể ở dạng lỗi
là một password sai gần đúng (phần mềm có thể có cơ chế hỗ trợ lấy lại mật khẩu
với dạng mật khẩu gần đúng chẳng hạn).
3. Một kiểm thử tốt phải là “giống tốt”. Trong một tập các kiểm thử có mục đích
tương tự nhau, thời gian và tài nguyên hạn chế có thể cho phép thực thi một tập
con của tập đó. Trong các trường hợp như vậy, một kiểm thử có khả năng phát
hiện lỗi cao nhất nên được sử dụng.
4. Một kiểm thử tốt nên không quá đơn giản và cũng không quá phức tạp. Mặc
dầu thỉnh thoảng có thể chấp nhận việc nối một chuỗi kiểm thử trong một ca kiểm
thử, các chuỗi kiểm thử thường che mất lỗi (không biết lỗi phát sinh từ đầu, bắt lỗi
sai, …). Tổng quát, mỗi kiểm thử nên được thực thi riêng biệt.

1.2.

iểm thử hộp trắng.

Kiểm thử hộp trắng, đôi khi gọi là kiểm thử hộp-trong-suốt, là một phương pháp thiết

nhiều khả năng tìm ra chúng.

1.3.

iểm thử lộ trình cơ sở.

Kiểm thử hướng lộ trình cơ sở (basis path testing) là một kỹ thuật kiểm thử hộp trắng
được đề xuất lần đầu bởi Tom McCabe. Phương pháp lộ trình cơ sở cho phép người thiết
kế ca kiểm thử kế thừa cấu trúc logic phức tạp của thiết kế sản phẩm và sử dụng sự đo
lường này như là một hướng dẫn để xác định các tập các đường đi được thực thi. Các ca
kiểm thử nhận được từ việc thực thi tập nền tảng đó và đảm bảo thực thi mọi câu lệnh
trong chương trình ít nhất một lần trong suốt quá trình kiểm thử.
1.3.1. ồ thị luồng.
Trước khi phương pháp lộ trình cơ sở được giới thiệu, một ghi chú đơn giản đại diện
cho luồng điều khiển, gọi là đồ thị luồng( hoặc bản đồ chương trình) được giới thiệu. Đồ
thị luồng miêu tả luồng điều khiển logic sử dụng các ghi chú như ở hình 1.1. Mỗi một cấu
trúc xây dựng (tham khảo chương 16- tài liệu PAOSE của tác giả R.Pressman) có ký hiệu
đồ thị luồng tương ứng.
Để làm rõ cách sử dụng một đồ thị luồng, ta xem xét thiết kế chương trình miêu tả ở
hình 1.2A. Ở đây, một sơ đồ luồng được sử dụng để mô tả cấu trúc điều khiển chương
trình. Hình 1.2B ánh xạ sơ đồ luồng thành một đồ thị luồng tương ứng (giả sử rằng không
có điều kiện phức tạp nào trong các hình thoi điều kiện trong sơ đồ luồng). Mỗi hình tròn
trong hình 1.2B gọi là một nốt đồ thị luồng, tượng trưng cho một hoặc một số câu lệnh
được thực hiện liên tiếp kề nhau. Mỗi chuỗi các hộp tiến trình và một hình tthoi quyết
định có thể ánh xạ tới một nốt. Mũi tên trong đồ thị luồng được gọi là cạnh hay đường
dẫn, tương trưng cho luồng điều khiển và tương tự như mũi tên trong sơ đồ luồng. Một
cạnh phải kết thúc ở một nốt, cho dù nốt đó không đại diện cho bất kì câu lệnh thực thi
nào (vd, xem ký hiệu cho cấu trúc if-then-else). Các khoảng bao bởi các cạnh và nốt được
gọi là các vùng. Khi đếm các vùng, ta coi vùng nằm ngoài đồ thị cũng là một vùng.



Hình 1.2 Sơ đồ luồng (trên ( )) và đồ thị luồng (dƣới ( )) tƣơng ứng

Nhóm 01- Lớp công nghệ phần mềm K52

Page 15


Báo cáo Đại cương Công nghệ phần mềm

Hình 1.3 ác điều kiện logic phức tạp
1.3.2. Cyclomatic Complexity (độ phức tạp lặp).
Cyclomatic Complexity là một sự đo lường phần mềm cung cấp các đo lường tính
toán được của logic chương trình. Khi được sử dụng trong ngữ cảnh của phương pháp
kiểm tra tập đường đi, giá trị được tính cho cyclomatic complexity định nghĩa số các
thành phần độc lập trong tập lộ trình của chương trình và cung cấp chúng ta một cận trên
số các kiểm thử cần thực hiện để đảm bảo rằng mọi câu lệnh đều được duyệt qua ít nhất
một lần.
Một hướng độc lập là bất kì hướng nào trong chương trình mà đưa vào ít nhất một tập
mới các câu lệnh hoặc một điều kiện mới. Trong đồ thị luồng, một hướng độc lập phải đi
qua ít nhất một cạnh không trùng lặp trước khi hướng được xác định. Ví dụ, một tập các
hướng độc lập trong đồ thị luồng mô tả ở 1.2B là
hướng 1: 1-11
hướng 2: 1-2-3-4-5-10-1-11
hướng 3: 1-2-3-6-8-9-10-1-11
hướng 4: 1-2-3-6-7-9-10-1-11
Chú ý rằng mỗi hướng mới có thên cạnh mới. Hướng
1-2-3-4-5-10-1-2-3-6-8-9-10-1-11
không được xem là một hướng độc lập vì nó chỉ là sự kết hợp của các hướng riêng lại
và không tìm thêm được bất kì cạnh mới nào.

ế thừa ca kiểm thử.

Nhóm 01- Lớp công nghệ phần mềm K52

Page 17


Báo cáo Đại cương Công nghệ phần mềm

Hình 1.4.

DL cho thiết kế ca kiểm thử với các nốt đƣợc xác định

Phương pháp kiểm tra phần nền tảng có thể ứng dụng cho môt thiết kế chương trình
hoặc source code. Trong phần này, chúng tôi giới thiệu kiểm thử hướng nền tảng như là
một chuỗi các bước. Thủ tục average, mô tả ở hình 17.4, được sử dụng làm ví dụ để hình
dung mỗi bước trong phương thức thiết kế ca sử dụng. Chú ý rằng average, mặc dầu là
một giải thuật rất đơn giản, chứa nhiều điều kiện và vòng lặp. Các bước sau đây có thể
được ứng dụng để kế thừa tập nền tảng:
1. Sử dụng thiết kế và code như là một cơ sở, vẽ các đồ thị luồng tương ứng. Một đồ
thị luồng được tạo sử dụng ký hiệu và các quy tắc giới thiệu ở chương 16 cuốn
sách PAOSE của tác giả R.Pressman. Quay trở lại PDL cho average trong hình
1.4, một đồ thị luồng được tạo bằng cánh đánh số các câu lệnh PDL ánh xạ tới các
nốt đồ thị luồng tương ứng. Đồ thị luồng tương ứng ở hình 1.5.

Nhóm 01- Lớp công nghệ phần mềm K52

Page 18




Hình 1.5.

ồ thị luồng cho thủ tục average

Kiểm thử phần 1:
value(k) = giá trị hợp lên, k

a trận đồ thị tƣơng ứng với một đò thị luồng

Ở hình này, mỗi nốt trong đồ thị luồng được xác định với các chữ số, trong khi mỗi
cạnh được định danh bởi chữ cái. Một chữ cái được đặt vào mỗi ô của ma trận tương ứng
với sự kết nối giữa 2 nốt. Ví dụ, nốt 3 được nối với nốt 4 bởi cạnh b.
Tới thời điểm này, đồ thị ma trận không gì hơn là một bảng chỉ dẫn cho đồ thị luồng.
Tuy nhiên, bằng cách thêm vào trong số cho mỗi ô ma trận, ma trận luồng có thể trở
thành một công cụ hữu hiệu cho việc đánh giá cấu trúc điều khiển chương trình trong
suốt quá trình kiểm thử. Trọng số cung cấp thông tin thêm về luồng điều khiển. Ở dạng
đơn giản nhất, trong số là 1 (nếu một kết nối tồn tại) và 0(nếu không tồn tại). Nhưng
trọng số có thể được gán bằng một số cách hữu ích hơn:





Xác xuất một cạnh được thực thi
Thời gian thực hiện khi đi qua cạnh đó
Bộ nhớ cần thiết khi đi qua cạnh đó.
Tài nguyên cần sử dụng khi đi qua cạnh đó.

Nhóm 01- Lớp công nghệ phần mềm K52

Page 22


Báo cáo Đại cương Công nghệ phần mềm

Hình 1.7



Báo cáo Đại cương Công nghệ phần mềm
E1 <relational-operator> E2
hoặc . Một điều kiện phức hợp là sự kết hợp của hai hoặc nhiều điều kiện

đơn giản, toán tử boolean, và dấu ngoặc. Ta giả sử răng toán tử boolean được chấp nhận
trong điều kiện phức hợp bao gồm OR(|), AND(&) và NOT. Một điều kiện không có
mệnh đề quan hệ được xem là một mệnh đề boolean.
Nếu một điều kiện là sai, khi đó ít nhất một hướng trong điều kiện là sai. Cho nên, các
loại lỗi trong một điều kiện bao gồm:

khác).





Toán từ boolean sai (không chính xác, thiếu hoặc thêm các toán tử boolean
Lỗi biến boolean
Lỗi sử dụng ngoặc
Lỗi toán tử quan hệ
Lỗi biểu thức đại số

Phương pháp kiểm thử điều kiện tập trung vào kiểm tra mỗi điều kiện trong chương
trình. Chiến lược kiểm thử điều kiện (bàn đến sau) có 2 ưu điểm. Một, đo lường sự bao
quát của việc kiểm thử một điều kiện là đơn giản. Thứ hai, kiểm thử điều kiện trong một

giản (một mệnh đề boolean mà trong đó mỗi biến boolean xuất hiện chỉ một lần) với n
biến boolean (n > 0), ta có thể dễ dạng tạo một tập kiểm thử với nhỏ hơn 2n kiểm thử sao
cho tập kiểm thử này đảm bảo việc phát hiện các lỗi toán tử boolean và cũng hiệu quả
cho việc phát hiện các lỗi khác.
Tai[TAI89] đề nghị một chiến lược kiểm thử điều kiện xây dựng dựa vào kỹ thuật
trên. Được gọi là kiểm thử BRO (branch and relational operator), kỹ thuật đảm bảo việc
phát hiện nhánh và toán tử lỗi trong một điều kiện cung cấp rằng mọi biến boolean và
toán tử quan hệ trong điều kiện xuất hiện chỉ một lần và không có biến chung.
Chiến lược BRO sử dụng ràng buộc điều kiện cho một điều kiện C. Một ràng buộc
điều kiện của C với n điều kiện đơn giản được định nghĩa là (D1, D2,…, Dn) trong đó
Di (
) là một ký tự chỉ ra một ràng buộc trong đầu ra của điều kiện đơn giản thứ I
trong điều kiện C. Một ràng buộc điều kiện D cho điều kiện C được gọi là che đậy bởi
một thực thi của C nếu trong quá trình thực thi C, đầu ra của mỗi điều kiện đơn giản
trong C thỏa mãn ràng buộc tương ứng trong D.
Với một biến boolean, B, ta chỉ ra một ràng buộc trong đầu ra của B mà chỉ ra rằng B
phải là hoặc đúng hoặc sai. Tương tự, với một mệnh đề quan hệ, ký hiệu >, =, < được sử
dụng đẻ chỉ ra ràng buộc trong đầu ra của mệnh đề.
Ví dụ, xem xét điều kiện
C1: B1 & B2
trong đó B1 và B2 là các biến boolean. Ràng buộc điều kiện cho C1 là ở dạng (D1, D2),
trong đó mỗi D1 và D2 là đúng hoặc sai (t or f). Giá trị (t,f) là ràng buộc điều khiển cho C1
và được bao phủ bởi kiểm thử làm cho giá trị B1 là đúng hoặc giá trị B2 là sai. Chiến lược
kiểm thử BRO đòi hỏi rằng tập ràng buộc {(t, t), (f,t), (t,f)} được bao phủ bới các thực thi
của C1. Nếu C1 là sai dựa vào một hoặc nhiều toán tử boolean lỗi, ít nhất một trong tập
điều kiện ràng buộc làm cho C1 sai.
1.4.2. iểm thử luồng dữ liệu.
Phương pháp kiểm thử luồng dữ liệu chọn một phần kiểm thử của một chương trình
dựa vào vị trí của các định nghĩa và sử dụng các biến trong chương trình. Một số các
chiến lược kiểm thử luồng dữ liệu được nghiên cứu và so sánh.