Nghiên cứu một số kỹ thuật kiểm thử phần mềm và xây dựng ứng dụng kiểm thử

MỤC LỤC
MỤC LỤC .................................................................................................... 1
LỜI MỞ ĐẦU............................................................................................... 3
CHƯƠNG I:TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM ................... 5
1.1 Công Nghệ Phần Mềm là gì?..................................................................5
1.2. Các lĩnh vực của Công Nghệ Phần Mềm...............................................5
1.2.1. Các yêu cầu phần mềm (Software requirements) .................................6
1.2.2. Thiết kế phần mềm (Software design) .................................................7
1.2.3. Xây dựng phần mềm (software construction) ......................................8
1.2.4. Kiểm Thử Phần Mềm (software testing) ..............................................8
1.2.5. Bảo trì phần mềm (Software maintenance) ..........................................8
1.2.6. Quản lí cấu hình phần mềm (Software Configuration Management –
SCM): 9
1.2.7. Quản lí Công Nghệ Phần Mềm (Software Engineering Management). 9
1.2.8. Quy trình Công Nghệ Phần Mềm (Software engineering process) .....10
1.2.9. Các phương thức và công cụ trong Công Nghệ Phần Mềm................10
1.2.10. Chất lượng phần mềm .....................................................................10

CHƯƠNG 2: VẤN ĐỀ CHẤT LƯỢNG PHẦN MỀM VÀ KIỂM THỬ
PHẦN MỀM ............................................................................................... 12
2.1

Sản phẩm phần mềm và vấn đề kiểm thử phần mềm ....................12

2.1.1

Sản phẩm phần mềm là gì?...........................................................12

2.1.2

Thế nào là lỗi phần mềm? ............................................................13

2.1.3

Tại sao lỗi phần mềm xuất hiện? ..................................................14

2.1.4

Chi phí cho việc sữa lỗi................................................................15

2.1.5

Kiểm thử phần mềm là gì? ...........................................................16

2.2

Chất lượng phần mềm .....................................................................17

2.3

Qui trình kiểm thử phần mềm.........................................................19

CHƯƠNG 3: CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM.................... 22
3.1

Nguyên tắc cơ bản kiểm thử phần mềm .........................................23

3.1.1

Mục tiêu kiểm thử ........................................................................23

3.1.2

Luồng thông tin kiểm thử .............................................................23

1


3.1.3
3.2

Thiết kế trường hợp kiểm thử .......................................................24

Kỹ thuật kiểm thử hộp trắng (White-Box Testing) ........................26

3.2.1

Kiểm thử đường dẫn cơ sở (Basic Path Testing)...........................28

3.2.2

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

3.3

Kỹ thuật kiểm thử hộp đen (Black-Box Testing)............................38

3.3.1

Phân hoạch tương đương..............................................................39

3.3.2

Phân tích giá trị biên (BVA - Boundary Value Analysis)..............42

3.3.3

Kỹ thuật đồ thị nhân-quả (Cause-Effect Graph)............................43

3.4

Kiểm thử đơn vị ...............................................................................44

3.4.1

Các lý do của kiểm thử đơn vị......................................................45

3.4.2

Các thủ tục kiểm thử đơn vị..........................................................47

3.5

Kiểm thử tích hợp ............................................................................48

3.5.1

Kiểm thử tích hợp từ trên xuống (Top-Down Integration) ............49

3.5.2

Chiến lược kiểm thử từ dưới lên (Bottom-Up Testing) .................51

3.5.3

Kiểm thử hồi qui ..........................................................................52

3.5.4

Các ghi chú trên kiểm thử tích hợp...............................................53

3.6

Kiểm thử tính hợp lệ........................................................................55

3.6.1

Điều kiện kiểm thử tính hợp lệ .....................................................55

3.6.2

Duyệt lại cấu hình ........................................................................56

3.6.3

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

3.7

Kiểm thử hệ thống ...........................................................................57

3.7.1

Kiểm thử khôi phục......................................................................58

3.7.2

Kiểm thử bảo mật.........................................................................58

3.7.3

Kiểm thử ứng suất........................................................................59

3.7.4

Kiểm thử khả năng thực hiện........................................................60

CHƯƠNG 4: ỨNG DỤNG......................................................................... 61
KẾT LUẬN................................................................................................. 69
DANH MỤC HÌNH.................................................................................... 70
TÀI LIỆU THAM KHẢO.......................................................................... 71

2


LỜI MỞ ĐẦU
Hàng ngày chúng ta vẫn thường được nghe những câu chuyện về sự cố
phần mềm máy tính hay một lỗ hổng trong bảo mật và an toàn thông tin như:
Một ngân hàng đưa ra thông báo sai lệch về sự cân bằng thu chi cho một tài
khoản, trên sao Hỏa một vệ tinh dò đường đột ngột biến mất, một cửa hàng nhỏ
in hóa đơn sai cho khách hàng hay một tin tặc đã đột nhập và lấy cắp hàng triệu

số thẻ tín dụng. Tại sao những sự cố này xảy ra? Phải chăng những người lập
trình viên không thể tạo ra được các chương trình làm việc rõ ràng và không lỗi?
Ngày nay cùng 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 các công cụ tiên tiến, yêu cầu của khách hàng về chức năng của chương
trình nhiều, sự liên kết, trao đổi, xử lí thông tin chéo giữa các chương trình ngày
càng cao, cộng với những giới hạn về thời gian và chi phí khiến cho các chương
trình ngày càng phức tạp và việc đảm bảo một chương trình chạy không bị lỗi
dường như là điều không thể. Đó cũng là lí do chính để “Kiểm Thử Phần Mềm”
(Software Testing) ra đời.
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ẽ.
Đề tài tập trung nghiên cứu, tìm hiểu, đánh giá các kỹ thuật dùng trong
Kiểm Thử Phần Mềm, vị trí của Kiểm Thử Phần Mềm trong Công Nghệ Phần
Mềm và thiết kế một chương trình tự động kiểm tra các liên kết của một website.

3


Đề tài được chia làm 4 chương:
Chương 1 là tổng quan về Công Nghệ Phần Mềm
Chương 2 là vấn đề chất lượng phần mềm và kiểm thử phần mềm.
Chương 3 là phần chính của đề tài, tập trung vào phân tích đánh giá các
kỹ thuật kiểm định phần mềm.

Cuối cùng là chương 4 thiết kế một chương trình kiểm thử.

4


CHƯƠNG I:TỔNG QUAN VỀ CÔNG NGHỆ PHẦN
MỀM
Trong chương I này trình bày những vấn đề cơ bản của các lĩnh vực của
Công Nghệ Phần Mềm theo cách thống nhất của Viện Kĩ thuật Điện và điện Tử
IEEE, vai trò, phạm vi của từng lĩnh vực để thấy vị trí của Kiểm Thử Phần Mềm
trong ngành Công Nghệ Phần Mềm.

1.1 Công Nghệ Phần Mềm là gì?
Đã có rất nhiều định nghĩa về Công Nghệ Phần Mềm, theo Ian
Sommerville [8]: Công Nghệ Phần Mềm là các hoạt động bao gồm: đặc tả, phát
triển, đưa vào hoạt động, bảo trì và loại bỏ phần mềm một cách có hệ thống. Các
kỹ sư phần mềm được cung cấp các kỹ thuật và công cụ để phát triển các hệ
thống phần mềm.
Theo Stephen R. Schach [9]: Công Nghệ Phần Mềm là các hoạt động
nhằm đảm bảo chất lượng phần mềm, hoàn thành sản phầm đúng thời hạn trong
điều kiện giới hạn về ngân sách và làm hài lòng khách hàng.
Và theo từ điển tin học IEEE [10], Công Nghệ Phần Mềm là việc áp dụng
một cách có hệ thống các nguyên tắc, các tiêu chuẩn đảm bảo chất lượng để phát
triển, đưa vào hoạt động và bảo trì một sản phẩm phần mềm.
Như vậy, Công Nghệ Phần Mềm là một lĩnh vực nghiên cứu của tin học,
nhằm đưa ra các nguyên lí, phương pháp, công cụ, cách tiếp cận và phương tiện
phục vụ cho việc thiết kế, cài đặt và bảo trì các sản phẩm phần mềm, đảm bảo
các tiêu chuẩn về chất lượng.

1.2. Các lĩnh vực của Công Nghệ Phần Mềm

Với các mục đích: đưa ra một cái nhìn tổng quan về Công Nghệ Phần
Mềm thống nhất trên toàn thế giới; Tạo ranh giới để phân biệt Công Nghệ Phần
Mềm với các lĩnh vực khác trong ngành Công nghệ thông tin như Khoa học máy
tính, Quản lí dự án, Công nghệ máy tính hay Toán học; Miêu tả các vấn đề cơ
bản của Công Nghệ Phần Mềm; phạm vi của Công Nghệ Phần Mềm; Cung cấp
5


nền tảng đại cương cho các chương trình phát triển, hệ thống chứng chỉ và bản
quyền. Viện Kỹ thuật Điện và Điện Tử (IEEE) đã chia Công Nghệ Phần Mềm
thành 10 lĩnh vực [7] theo hình 1.1

Hình 1.1: Các lĩnh vực trong Công Nghệ Phần Mềm

Trong phần tiếp theo đề tài trình bày khái quát về chức năng, vai trò và phạm vi
của những lĩnh vực con của Công Nghệ Phần Mềm.
1.2.1. Các yêu cầu phần mềm (Software requirements)
Một yêu cầu phần mềm [7] là một thuộc tính được thể hiện đúng khi phần
mềm được tạo ra để giải quyết một vấn đề nào đó. Ví như tự động hóa một khâu
nào đó của người sử dụng, hỗ trợ doanh nghiệp ra quyết định hay điều khiển thiết
bị. Cũng có thể xem yêu cầu như một chức năng phải tồn tại trên hệ thống. Chức
năng của con người, các quy trình của doanh nghiệp và các thiết bị trong mỗi hệ
thống là khác nhau vì thế nên các yêu cầu phần mềm có thể được định nghĩa là
tổng hợp các yêu cầu của người sử dụng tại mỗi bộ phận khác nhau của tổ chức
và từ môi trường nơi phần mềm sẽ được sử dụng. Cần phân biệt một số loại yêu
cầu:

6

+ Yêu cầu chức năng và yêu cầu không chức năng: Yêu cầu chức năng là
các yêu cầu về dịch vụ mà hệ thống phải đáp ứng; Yêu cầu không chức năng là
các ràng buộc mà hệ thống phải tuân theo.
+ Yêu cầu hệ thống và yêu cầu phần mềm: Hệ thống là sự phối hợp hoạt
động của các thành phần nhằm thực hiện một mục đích định trước, bao gồm các
thành phần như: phần cứng, phần mềm, con người, thông tin, kỹ thuật, dịch vụ …
Yêu cầu hệ thống là các yêu cầu cho toàn hệ thống. Khi một hệ thống chứa các
thành phần phần mềm thì các yêu cầu phần mềm chính là các yêu cầu hệ thống.

1.2.2. Thiết kế phần mềm (Software design)
Thiết kế phần mềm [7] là một quy trình của việc định nghĩa kiến trúc, các
thành phần, giao diện và các đặc tính khác của hệ thống hay thành phần của hệ
thống và kết quả của quy trình đó.
Cơ bản về thiết kế phần mềm: Cung cấp các khái niệm cơ bản làm rõ vai
trò và phạm vi của thiết kế phần mềm. Đó là những phái niệm chung, ngữ cảnh,
quy trình và các kỹ thuật sử dụng trong thiết kế phần mềm.
Một số đặc trưng trong thiết kế phần mềm: Đó là sự trùng lặp, điều khiển
và thao tác sự kiện, sự phân tán của các thành phần, lỗi và khả năng chịu lỗi,
tương tác và biểu diễn và cuối cùng là tính đồng nhất dữ liệu.
Kiến trúc và cấu trúc phần mềm: Kiến trúc phần mềm là sự miêu tả các hệ
thống con và các thành phần của một hệ thống phần mềm và mối liên hệ giữa
chúng. Một số đặc tính của kiến trúc phần mềm đó là: điểm nhìn, phong cách
thiết kế, thiết kế mẫu và tập hợp các chương trình sử dụng lại.
Các chú thích thiết kế phần mềm: Bao gồm các quy định, các chuẩn dùng
để miêu tả, giải thích trên các thiết kế.
Các phương pháp và chiến lược thiết kế: Phương pháp thiết kế đầu tiên
phải được đến đó là miêu tả, sau đó là các phương pháp thiết kế hướng chức
năng, phương pháp thiết kế hướng đối tượng, thiết kế cấu trúc dữ liệu trung tâm
và thiết kế hướng thành phần.

7


1.2.3. Xây dựng phần mềm (software construction)
Xây dựng phần mềm [7] là những việc làm trực tiếp để tạo ra sản phẩm
phần mềm bao gồm các hoạt động như viết mã chương trình, kiểm tra, kiểm thử
đơn vị, kiểm thử tích hợp và gỡ lỗi. Xây dựng phần mềm bao gồm 3 lĩnh vực
nhỏ:
Cơ bản về xây dựng phần mềm: 4 nguyên lí cơ bản trong xây dựng phần
mềm đó là: Giảm tới mức tối thiểu độ phức tạp; Dự đoán trước sự thay đổi; Tạo
các đầu mối để kiểm tra và cuối cùng là tuân thủ theo các chuẩn.
Quản lí xây dựng phần mềm: Quản lí xây dựng phần mềm bao gồm các
chủ đề nhỏ là các mô hình xây dựng, kế hoạch xây dựng và đo lường xây dựng.
Các khía cạnh thực hành trong xây dựng phần mềm: đó là thiết kế xây
dựng, các ngôn ngữ xây dựng, lập trình, kiểm thử, tái sử dụng, chất lượng xây
dựng và tích hợp.

1.2.4. Kiểm Thử Phần Mềm (software testing)
Các khái niệm, vai trò và các kỹ thuật Kiểm Thử Phần Mềm sẽ được trình
này chi tiết trong Chương II của đề tài.

1.2.5. Bảo trì phần mềm (Software maintenance)
Trong quá trình hoạt động một số khuyết điểm bộc lộ, môi trường hoạt
động thay đổi và những yêu cầu mới của người dùng phát sinh do đó đòi hỏi phải
có một quá trình bảo trì phần mềm [7]. Quá trình bảo trì phần mềm bắt đầu khi
thời gian bảo hành phần mềm kết thúc hay các hỗ trợ sau cài đặt được chuyển
giao, nhưng các hoạt động bảo trì phần mềm thực sự thì xuất hiện sớm hơn. Bảo
trì phần mềm được định nghĩa như là các hoạt động để đảm bảo hỗ trợ sản phẩm
phần mềm hoạt động tốt nhất. Các hoạt động được thực hiện cả trước và sau khi
chuyển giao phần mềm, bao gồm: Lập kế hoạch cho các hoạt động sau khi

chuyển giao, cho các hoạt động bảo trì và yêu cầu hậu cần cho các hoạt động

8


chuyển giao. Các hành động bảo trì phần mềm sau khi chuyển giao bao gồm việc
sửa chữa phần mềm, đào tạo và tạo kênh thông tin trao đổi và hỗ trợ.
1.2.6. Quản lí cấu hình phần mềm (Software Configuration Management –
SCM):
Một hệ thống là một tập các thành phần được tổ chức để thực hiện một
chức năng hay một tập các chức năng. Cấu hình của một hệ thống [7] là các đặc
tính vật lí hay thuộc chức năng của phần cứng, phần mềm hay tổng hợp của phần
mềm và phần cứng. Những thuộc tính này phối hợp với nhau theo một thủ tục,
một cách nào đó để phục vụ cho một mục đích định trước. Quản lí cấu hình là
lĩnh vực áp dụng các kỹ thuật, sự trực tiếp quản lí và theo dõi hệ thống để xác
định và ghi nhận các đặc tính vật lí và chức năng cấu hình của một thành phần
nào đó trong hệ thống, điều khiển thay đổi những đặc tính đó, ghi nhận và thông
báo quá trình thay đổi và trạng thái cài đặt, kiểm tra đảm bảo thỏa mãn với các
yêu cầu định trước.

1.2.7. Quản lí Công Nghệ Phần Mềm (Software Engineering Management).
Quản lí Công Nghệ Phần Mềm [7] được định nghĩa như một ứng dụng
quản lí các hoạt động lập kế hoạch, phối hợp hoạt động, đo lường, giám sát, điều
khiển và thông báo để đảm bảo sự phát triển và bảo trì của phần mềm một cách
có hệ thống và đảm bảo chất lượng. Quản lí Công Nghệ Phần Mềm phân thành 6
lĩnh vực nhỏ, phân thành hai hướng chính là quản lí và đánh giá Công Nghệ Phần
Mềm.
Khởi tạo và xác đinh phạm vi: bao gồm một số công việc như xác định và
cân đối các yêu cầu, phân tích khả năng và tạo quy trình cho việc kiểm tra, xét lại
các yêu cầu.

Lập kế hoạch dự án phần mềm: Bao gồm việc tạo các quy trình, xác định
khả năng chuyển giao, ảnh hưởng, lên kế hoạch và ước lượng chi phí, cấp phát
tài nguyên, quản lí rủi ro, quản lí chất lượng…

9


Công bố dự án phần mềm: Đó là sự thực thi các kế hoạch, quản lí hợp
đồng cung cấp, thực thi các quy trình đo lường, quy trình quản lí, quy trình điều
khiển và thông báo.
Kiểm tra và đánh giá: Xác định mức độ thỏa mãn các yêu cầu, kiểm tra và
đánh giá hiệu năng.
Kết thúc: Xác đinh thời điểm kết thúc và các hành động kết thúc.
Đánh giá Công Nghệ Phần Mềm: Bao gồm việc khởi tạo và giữ vững
những cam kết đánh giá, lập kế hoạch đánh giá, thực hiện kế hoạch và đanh giá.

1.2.8. Quy trình Công Nghệ Phần Mềm (Software engineering process)
Quy trình Công Nghệ Phần Mềm [7] phân thành hai mức, mức thứ nhất
bao gồm các kĩ thuật và hành động của người quản trị được sử dụng và thực hiện
trong các quy trình vòng đời phần mềm, trong các quá trình phát triển, bảo trì và
thu hồi. Mức thứ hai tập trung vào việc định nghĩa, cài đặt, quản lí, đánh giá, thay
đổi và cải tiến của các quy trình vòng đời phần mềm

1.2.9. Các phương thức và công cụ trong Công Nghệ Phần Mềm.
Các công cụ phát triển phần mềm [7] là các sản phẩm, công cụ được sử
dụng để trợ giúp các quy trình vòng đời phần mềm, hệ thống hóa Công Nghệ
Phần Mềm.
Các phương thức Công Nghệ Phần Mềm [7] đảm bảo các hoạt động được
thực hiện đúng và thực hiện một cách có hệ thống, đảm bảo sự thành công

1.2.10. Chất lượng phần mềm
Có rất nhiều các định nghĩa khác nhau về chất lượng phần mềm [7] , Phil
Crosby -1979 [33] định nghĩa chất lượng phần mềm là sự làm đúng theo yêu cầu
của người sử dụng, IBM hướng tới thị trường, coi chất lượng phần mềm là sự hài
lòng của khách hàng. Mới đây nhất chất lượng phần mềm được định nghĩa theo
chuẩn ISO9001-00 là mức độ đáp ứng của các đặc tính phần mềm đối với những
10


yêu cầu của người dùng. Viện Kĩ thuật Điện và Điện Tử IEEE chia chất lượng
phần mềm thành 3 lĩnh vực nhỏ hơn:
Quy trình quản lí chất lượng phần mềm: Quản lí chất lượng phần mềm áp
dụng tới tất cả các khía cạnh của các quy trình phần mềm, sản phẩm, người quản
lí quy trình và những yêu cầu, đánh giá và phản hồi từ các quy trình đó. Hai công
việc cơ bản trong quản lí chất lượng phần mềm là: Đưa ra các yêu cầu của sản
phẩm và các đặc tính chất lượng của nó, và lên kế hoạch các quy trình để thỏa
mãn những đặc tính chất lượng đó. Một số các quy trình quản lí phần mềm được
IEEE đưa ra là:
+ Quy trình đảm bảo chất lượng
+ Quy trình kiểm tra
+ Quy trình thẩm định
+ Quy trình tái kiểm tra
+ Quy trình kiểm toán
Trong chương I, luận văn đã trình bày những vấn đề cơ bản của các lĩnh
trong Công Nghệ Phần Mềm theo cách thống nhất của Viện Kĩ thuật Điện và
điện Tử IEEE, vai trò, phạm vi của từng lĩnh vực để thấy vị trí của Kiểm Thử
Phần Mềm trong ngành Công Nghệ Phần Mềm. Trong chương tiếp theo, đề tài sẽ
trình bày chi tiết về Kiểm Thử Phần Mềm, các kĩ thuật trong Kiểm Thử và so
sánh các kĩ thuật đó.

11


CHƯƠNG 2: VẤN ĐỀ CHẤT LƯỢNG PHẦN MỀM
VÀ KIỂM THỬ PHẦN MỀM
2.1

Sản phẩm phần mềm và vấn đề kiểm thử phần mềm

2.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 2.1
minh họa cụ thể hơn về điều này.
Bảng 2.1 - Tỉ lệ công việc của các giai đoạn phát triển phần mềm
Giai đoạn

Phân tích Thiết kế
yêu cầu
sơ bộ

Hai thập kỉ 1960 - 1970

10%

Thập kỉ 1980
Thập kỉ 1990

Thiết kế Lập trình và Tích hợp và kiểm Kiểm thử
chi tiết kiểm thử đơn vị
thử tích hợp
hệ thống
80%

20%
40%

10%

60%
30%

20%
30%

Theo một tài liệu khác [12], 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

3%

Đặc tả

3%

Thiết kế

5%

Lập trình

7%

Kiểm thử

15%

Vận hành và bảo trì

67%

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 2.1). Vì vậy, việc mắc
12


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

Phản hồi
từ phiên
bản cũ

Tài liệu
thiết kế

Thông tin
cạnh tranh

Kiến trúc
phần mềm

Lịch biểu

Tài liệu
kiểm thử

Khảo sát
khách
hàng

Dữ liệu

Mã nguồn

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 2.1 – Sản phẩm phần mềm

2.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ả.

13


 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.
2.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 2.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.

14


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. Dó 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,…
2.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 [12], 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.
Sự thay đổi một tài liệu yêu cầu khi duyệt lại lần đầu tiên là không đắt nếu
không nói là không đáng kể. Chi phí sẽ tăng lên nhiều hơn nếu các yêu cầu thay
đổi sau khi đã lập trình. Thay đổi yêu cầu lúc đó đồng nghĩa với việc viết lại
chương trình.

15


Việc sửa lỗi sẽ không còn đáng kể nếu người lập trình tự phát hiện lỗi của
mình. Không có sự liên quan đến chi phí khác. Họ không phải giải thích lỗi cho
bất kỳ người nào. Họ cũng không phải nhập lại lỗi đó vào cơ sở dữ liệu lỗi và lưu

vết lỗi. Người kiểm thử và người quản lý không phải phải duyệt lại tình trạng lỗi.
Và lỗi đó không ảnh hưởng đến công việc của người khác trong nhóm dự án.
Sửa một lỗi trước khi phát hành một phần mềm rẻ hơn rất nhiều so với việc
khắc phục nó sau khi đã phát hành.
Trong tài liệu Boehm [4], 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

Chi phí để sữa lỗi

càng lớn. Chi phí tăng theo hàm mũ như hình sau.

Đặc tả

Thiết kế

lập trình

Kiểm thử

Phát hành

Hình 2.3 – Chi phí sửa lỗi theo thời gian phát hiện lỗi

Chúng ta đã từng chứng kiến sự cố máy tính năm 2000. Từ một giải pháp
tiết kiệm bộ nhớ là biểu diễn năm có bốn chữ số thành năm có hai chữ số cuối
vào đầu những năm 70 của thế kỷ trước dẫn đến việc 25 năm sau làm cả thế giới
lo sợ và phải bỏ ra nhiều tỉ đô la để khắc phục.
2.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 đó

16


có đúng với đặc tả không và thực hiện trong môi trường như mong đợi hay
không.
Trên thực tế, hệ thống đang thực hiện khác biệt với việc duyệt lại mã
nguồn. Thông thường, người phát triển thực hiện việc đọc lại và phân tích mã
nguồn. Nói cách khác, kiểm thử đòi hỏi một hệ thống chạy được. Đặc tả là căn cứ
chủ yếu hỗ trợ cho việc kiểm thử. Nó xác định những hành vi đúng và làm cho dễ
dàng hơn trong việc xác định những hành vi không đúng. Mỗi hành vi không
đúng chính là một lỗi phần mềm. Nói chung, người phát triển phải tự chẩn đoán
nguyên nhân sinh lỗi trong mã nguồn.
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 có thể 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. Chúng ta sẽ nghiên cứu kĩ hơn vấn đề này ở những phần tiếp theo.
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í.

2.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ó.” (Ian. Samerville [13] trích dẫn định nghĩa của Crosby). 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,..)

17


 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 (như tính
bảo trì).
 Những đặc tả phần mềm thường không đầy đủ và hay mâu thuẫn.
Vì thế phải có sự thỏa hiệp về chất lượng:
 Chúng ta không thể đợi các đặc tả hoàn thiện trước khi chú ý đến quản lý
chất lượng.
 Chúng ta phải sắp xếp các thủ tục để hoàn thiện chất lượng mặc dù đặc tả
chưa hoàn thiện.
 Quản lý chất lượng không chỉ quan tâm đến việc làm hạn chế tối thiểu
những khiếm khuyết của sản phẩm và đảm bảo tuân theo đặc tả, mà còn
phải quan tâm đến những thuộc tính chất lượng khác của sản phẩm.

Công nghệ hệ thống

Quản lý và đảm bảo chất lượng

Công nghệ phần mềm

Đả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 2.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 2.4a). Nhìn
từ ngữ cảnh chất lượng (Hình 2.4b), kiểm thử phần mềm cũng là một phần 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

18


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.

2.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ử dã 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 2.5)
Phân tích

Thiết kế

Mã hóa

KIỂM THỬ

Bàn giao SP

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ử

Hình 2.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

1012-1986 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ử[IEEE86]:
+ Mục đích: Qui định về phạm vi, phương pháp, tài nguuyê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.

19


+ 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ó một vài phương pháp thiết kế trường hợp kiểm thử
và các qui tắc từ các nhà thiết kế kiểm thử có kinh nghiệm. Tuy nhiên, có
hai chiến lược kiểm thử cơ bản
 Các phương pháp hộp đen để kiểm thử dựa trên chức năng.

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. Ở đây, người kiểm thử
không thể trực tiếp cải tiến chương trình mà họ chỉ có thể đánh giá nó.
 Đá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
2.6.

20


Thiết kế

Phân tích

Thiết kế các
trường hợp
kiểm thử

Mã hóa

Chạy
chương trình
với dữ liệu
kiểm thử

Chuẩn bị dữ
liệu kiểm thử

Các trường

hợp
kiểm thử

KIỂM THỬ

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ử

Kết quả
kiểm thử

Hình 2.6 – Qui trình kiểm thử phần mềm

21

Kết quả
kiểm thử


CHƯƠNG 3: 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 (2001) 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. 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). Các kỹ thuật kiểm thử hộp đen nhận được các kiểm thử từ đặc tả thiết kế
chức năng không cần quan tâm cấu trúc chương trình bên trong (Kit, 1995).
Người kiểm thử đưa ra các đầu vào cho thành phần hoặc hệ thống và xem xét đầu
ra tương ứng. Nếu các đầu ra thực tế phù hợp với các đầu ra mong muốn thì kiểm
thử xác nhận rằng chức năng được kiểm thử như mong muốn. Nếu các đầu ra là
không đúng các dự đoán của chúng thì kiểm thử đã thành công trong việc phát
hiện được lỗi phần mềm (Sommerville, 2001). 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ử blackbox 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ã (Kit,
1995). Phân tích mức độ phủ là kỹ thuật kiểm thử hộp trắng – nó phát hiện những
phần nào của mã sẽ được thực hiện trong khi kiểm thử. Thực hiện kiểm thử hộp
trắng có thể làm sáng tỏ các lỗi tìm thấy trong kiểm thử hộp đen bởi vì chúng
xem xét phần mềm thông qua việc nghiên cứu cấu trúc của nó.

22


3.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 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.
3.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.
3.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 3.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ử.
Kiểm thử được thực hiện và tất cả các kết quả được xem xét, kết quả kiểm
thử được so sánh với kết quả mong đợi. Khi dữ liệu không đúng được nhận biết,
lỗi được bao hàm và việc gỡ rối bắt đầu. Thủ tục gỡ rối là thành phần khó dự
đoán nhất của thủ tục kiểm thử. Một “lỗi” với sự khác nhau 0.01% giữa các kết
quả ra thực tế và kết quả mong đợi có thế mất hàng giờ, ngày, tháng để nhận biết
23


và hiệu chỉnh. Sự không chắc trong gỡ rối mà kiểm thử gây nên sẽ là khó lập lịch
biểu độ tin cậy.

Gỡ rối

Cấu hình phần mềm

Lỗi
Kết quả
kiểm thử
Kiểm
thử

Hiệu chỉnh
đánh
giá
Dữ liệu tỷ lệ lỗi

Cấu hình kiểm thử

Kết quả mong đợi

Mô hình
tin cậy

Dự đoán độ tin cậy

Hình 3.1 - Luồng thông tin kiểm thử

3.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. Tuy nhiên, các kỹ sư phần mềm thường xem kiểm thử như
một giai đoạn cuối cùng, sau giai đoạn lập trình. Các trường hợp kiểm thử được
hoạch định có thể tạo ra cảm giác đúng nhưng ít được đảm bảo là chúng sẽ hoàn
thành. 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. Một số lượng lớn các phương pháp thiết kế trường hợp kiểm thử đã được

phát triển, cung cấp cho đội ngũ phát triển cách tiếp cận có hệ thống cho việc
kiểm thử. Các phương pháp thường cung cấp một cách tiếp cận đảm bảo tính đầy
đủ của kiểm thử và cung cấp khả năng cao nhất để phát hiện các lỗi của phần
mềm.
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

24


thể vét cạn (tức kiểm thử không thể đảm bảo rằng chương trình không còn lỗi
nào). 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,
các kiểm thử có thể được thực hiện để chứng tỏ mỗi chức năng được thực
hiện đầy đủ, tại một thời điểm nào đó tìm kiếm các lỗi trong mỗi chức năng;
 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”, tức là, hoạt
động bên trong thực hiện theo đặc tả và tất cả các thành phần bên trong đã
được thực hiện một cách thoả đáng.
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.

Khi phần mềm máy tính được xem xét, kiểm thử hộp đen ám chỉ các kiểm
thử mà được thực hiện trên giao diện phần mềm. Mặc dù chúng được thiết kế để
phát hiện các lỗi, các kiểm thử hộp đen được sử dụng để chứng tỏ các chức năng
phần mềm là hoạt động; rằng đầu vào được chấp nhận một cách hợp lý và đầu ra
được sinh ra phù hợp; và duy trì tính toàn vẹn của thông tin bên ngoài (chẳng
hạn, các tập tin dữ liệu). Kiểm thử hộp đen xem xét một vài khía cạnh cơ bản của
hệ thống với sự quan sát cấu trúc logic bên trong của phần mềm.
Kiểm thử hộp trắng của phần mềm được căn cứ vào việc xem xét cẩn thận
chi tiết thủ tục. Các đường dẫn logic xuyên suốt phần mềm được kiểm thử bằng

25