Tìm Hiểu Các Kỹ Thuật Kiểm Thử Phần Mềm và Một Số Ứng Dụng Trong Thực Tế

Báo cáo bài tập lớn Kỹ thuật phần mềm
1
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG
----------------------------------------------
BÀI TẬP LỚN MÔN KỸ THUẬT PHẦN MỀM
ĐỀ TÀI: Tìm Hiểu Các Kỹ Thuật Kiểm Thử Phần Mềm
và Một Số Ứng Dụng Trong Thực Tế (BTL05)
Giảng viên hướng dẫn: TS. Vũ Thị Hương Giang
Nhóm sinh viên thực hiện:
Trần Anh Thơ – CNPMK53 – 20082569
Nguyễn Ngọc Toàn– CNPMK53 – 20082704
Nguyễn Thế Anh – CNPMK53 – 20080070
Vũ Hồng Quân – CNPMK53 – 20082128
Hà Nội 10/2011

2
MỤC LỤC
>>>
LỜI NÓI ĐẦU .................................................................................................................... 5
1. Tổng quan về kiểm thử ................................................................................................... 6
1.1 Các khái niệm cơ bản................................................................................................ 6
1.1.1 Định nghĩa.......................................................................................................... 6
1.1.2. Một số thuật ngữ và khái niệm thường gặp trong kiểm thử.............................. 6
1.2. Một số đặc điểm của kiểm thử ................................................................................. 7
1.2.1. Các khó khăn khi kiểm thử ............................................................................... 7
1.2.2. Một số lưu ý khi kiểm thử................................................................................. 7
1.3. Phân loại kiểm thử ................................................................................................... 7
1.4. Mô hình chữ V trong kiểm thử ................................................................................ 8
1.5. Vòng đời của kiểm thử............................................................................................. 9
1.6. Các tiêu chí đánh giá kiểm thử............................................................................... 10
2. Sơ lược các kỹ thuật kiểm thử phần mềm..................................................................... 12
2.1. Kiểm thử tầm hẹp................................................................................................... 12
2.1.1. Kiểm thử hộp đen............................................................................................ 12
2.1.2. Kiểm thử hộp trắng......................................................................................... 17
2.1.3. Kiểm thử hộp xám........................................................................................... 23
2.2. Kiểm thử tầm rộng................................................................................................. 24
2.2.1 Kiểm thử đơn vị (Unit Testing) ....................................................................... 24
2.2.2 Kiểm thử tích hợp (Integration Test) ............................................................... 25
2.2.3. Kiểm thử hệ thống (System Testing) .............................................................. 27
2.2.4. Kiểm thử chấp nhận (Acceptance Testing)..................................................... 28
3. Các chiến lược kiểm thử phần mềm ............................................................................. 30
3.1 Khái quát................................................................................................................. 30
3.2 Chiến lược kiểm thử................................................................................................ 30
4. Các công cụ kiểm thử phần mềm.................................................................................. 33
4.1.Quick test pro.......................................................................................................... 33
4.1.1 Giới thiệu ......................................................................................................... 33
4.1.2 Loại phần mềm hỗ trợ...................................................................................... 34
4.1.3 Đặc điểm .......................................................................................................... 34
4.1.4 Các thành phần quan trọng trong QTP ............................................................ 35

3
4.1.5 Ngôn ngữ viết script......................................................................................... 36
4.2 JUnit........................................................................................................................ 36
4.2.1 Giới thiệu ......................................................................................................... 36
4.2.2 Các thành phần quan trọng của JUnit .............................................................. 37
4.2.3 Cách tổ chức chương trình chạy với JUnit ...................................................... 38
4.3 Load Runner............................................................................................................ 39
4.3.1 Giới thiệu ......................................................................................................... 39
4.3.2 Đặc điểm .......................................................................................................... 40
4.3.3 Môi trường hỗ trợ............................................................................................. 40
4.3.4 Các bước thực hiện .......................................................................................... 41
4.4 NUnitTest................................................................................................................ 42
4.4.1 Khái quát.......................................................................................................... 42
5. Demo JUnit(Java) – NUnit(C#) .................................................................................... 44
5.1 JUnit (trong Java).................................................................................................... 44
5.2 NUnit (trong C#)..................................................................................................... 46
6. Tài Liệu Tham Khảo..................................................................................................... 49

4
Bảng Phân Công Công Việc Trong Nhóm
Họ và Tên Công việc thực hiện Mức độ hoàn
thành
Trần Anh Thơ Tổng quan về kiểm thử,
Các kỹ thuật kiểm thử phần mềm 100%
Nguyễn Ngọc Toàn Các kỹ thuật kiểm thử phần mềm
100%
Nguyễn Thế Anh
Các chiến lược kiểm thử phần mềm
Demo Unit Testing trong Java(JUnitTest) và
C#(NUnitTest) 100%
Vũ Hồng Quân Các công cụ kiểm thử phần mềm
100%
 Tài liệu doc này sẽ đi kèm với 2 Project Test (một của Java và một
của C#)

5
LỜI NÓI ĐẦU
Trong ngành kỹ nghệ phần mềm, năm 1979, có một quy tắc nổi tiếng là:
“Trong một dự án lập trình điển hình, thì xấp xỉ 50% thời gian và hơn 50%
tổng chi phí được sử dụng trong kiểm thử các chương trình hay hệ thống đã
được phát triển”. Và cho đến nay, sau gần một phần 3 thế kỷ, quy tắc đó vẫn
còn đúng. Đã có rất nhiều ngôn ngữ, hệ thống phát triển mới với các công cụ
tích hợp cho các lập trình viên sử dụng phát triển ngày càng linh động.
Nhưng kiểm thử vẫn đóng vai trò hết sức quan trọng trong bất kỳ dự án phát
triển phần mềm nào.
Rất nhiều các giáo sư, giảng viên đã từng than phiền rằng: “ Sinh viên của
chúng ta tốt nghiệp và đi làm mà không có được những kiến thực thực tế cần
thiết về cách để kiểm thử một chương trình. Hơn nữa, chúng ta hiếm khi có
được những lời khuyên bổ ích để cung cấp trong các khóa học mở đầu về
cách một sinh viên nên làm về kiểm thử và gỡ lỗi các bài tập của họ”.
Các tác giả của cuốn sách nổi tiếng “TheArt of Software Testing” – Nghệ
thuậtkiểm thử phần mềm, Glenford J. Myers, Tom Badgett, Todd M.
Thomas, Corey Sandler đã khẳng định trong cuốn sách của mình rằng: “ Hầu
hết các thành phần quan trọng trong các thủ thuật của một nhà kiểm thử
chương trình là kiến thức về cách để viết các ca kiểm thử có hiệu quả”. Việc
xây dựng các test – caselà một nhiệm vụ rất khó khăn. Để có thể xây dựng
được tập các test – case hữu ích cho kiểm thử, chúng ta cần rất nhiều kiến
thức và kinh nghiệm.
Đó là những lý do thúc đẩy nhóm em thực hiện đề tài này. Mục đíchcủa đề
tài là tìm hiểu những kiến thức tổng quan nhất về kiểm thử, và cách thiết kế
test – casetrong kiểm thử phần mềm. Việc thực hiện đề tài sẽ giúp em tìm
hiểu sâu hơn và lĩnh vực rất hấp dẫn này, vận dụng được các kiến thức đã
học để có thể thiết kế được các test – case một cách có hiệu quả và áp dụng
vào những bài toán thực tế.
Bản báo cáo được hoàn thành dưới sự hướng dẫn tận tình của cô giáo, TS
Vũ Thị Hương Giang, sự giúp đỡ nhiệt tình của các thầy cô trong bộ môn
Công nghệ phần mềm, và tất cả các bạn. Chúng em hi vọng sẽ nhận được sự
đóng góp ý kiến của các thầy cô và các bạn để bản báo cáo được hoàn thiện
hơn. Những đóng góp đó sẽ là kinh nghiệm quý báu cho nhóm. Và từ đó,
chúng em có thể tiếp tục phát triển đề tài này cho công việc trong tương lai.
Chúng em xin chân thành cám ơn.
Nhóm Sinh Viên Bài tập lớn

6
1. Tổng quan về kiểm thử
1.1 Các khái niệm cơ bản
1.1.1 Định nghĩa
Có thể có nhiều cách định nghĩa kiểm thử và sau đây là một số cách định
nghĩa chính:
 Kiểm thử là quá trình vận hành hệ thống hoặc thành phần dưới những
điều kiện xác định, quan sát hoặc ghi nhận kết quả và đưa ra đánh giá
về hệ thống hoặc thành phần đó (IEEE)
 Kiểm thử là quá trình thực thi một chương trình với mục đích tìm ra
lỗi (Mayer – The art of software testing)
 Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay
dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển
khai nhằm cung cấp cho những người có lợi ích liên quan những
thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy. Mục
đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần
mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong
nhiều ngành khác nhau. (Wikipedia)
1.1.2. Một số thuật ngữ và khái niệm thường gặp trong kiểm thử
 Lỗi (Error): Là một lỗi lầm trong phần mềm do con người gây ra.
 Sai sót (Fault): Sai sót gây ra lỗi. Sai sót có thể được phân loại như
sau:
 Sai sót do đưa ra dư thừa – Đưa ra một vài thứ không chính xác
vào mô tả yêu cầu phần mềm
 Sai sót do bỏ sót – Bỏ sót một số phần đáng ra phải có trong
phần mô tả yêu cầu phần mềm
 Hỏng hóc (Failure): Hỏng hóc xảy ra khi sai sót được thực thi. Trạng
thái hỏng hóc sẽ xảy ra tại các nơi bị sai trong chương trình.
 Kết quả không mong đợi (Incident): Là những kết quả do sai sót đem
đến. Hậu quả là các triệu chứng liên kết với một hỏng hóc và báo cho
người dùng biết sự xuất hiện của hỏng hóc
 Trường hợp kiểm thử (Test case): Là một bộ bao gồm một tập các dữ
liệu đầu vào, các điều kiện thực thi và các kết quả mong đợi với tập
các đầu vào đó.
 Kịch bản kiểm thử (Test Scenario): Các bước thực hiện khi kiểm thử
 Kiểm thử viên (Tester): Người thực hiện kiểm thử phần mềm

7
1.2. Một số đặc điểm của kiểm thử
1.2.1. Các khó khăn khi kiểm thử
 Nâng cao chất lượng của phần mềm nhưng không vượt quá chất lượng
khi thiết kế. Chỉ phát hiện ra các lỗi tiềm tàng và sửa chúng
 Phát hiện lỗi bị hạn chế do thực hiện thủ công là chính
 Do kiểm thử chỉ chạy thử chương trình trên một tập các dữ liệu đầu
vào hữu hạn nên không thể khẳng định là chương trình không có lỗi
 Thường mắc phải một số đặc trưng chủ quan như:
 Bộ dữ liệu kiểm thử không thay đổi trong quá trình xây dựng
phần mềm
 Chỉ kiểm tra trong các trường hợp hợp lệ mà không quan tâm
đến các cận hay các ngoại lệ
 Cài đặt chức năng nào thì chỉ kiểm tra chức năng đó
1.2.2. Một số lưu ý khi kiểm thử
 Chất lượng phần mềm do khâu thiết kế quyết định là chủ yếu chứ
không phải do khâu kiểm thử
 Tính dễ kiểm thử phụ thuộc vào cấu trúc chương trình
 Người kiểm thử và người phát triển nên khác nhau
 Dữ liệu thử cho kết quả bình thường thì không có ý nghĩa nhiều, cần
có những dữ liệu kiểm thử để phát hiện ra lỗ
 Khi thiết kế trường hợp thử không chỉ thiết kế dữ liệu kiểm thử đầu
vào mà còn phải thiết kế trước cả dữ liệu kết quả sẽ có
 Khi phát sinh thêm trường hợp thử thì nên thử lại những trường hợp
trước đó để tránh ảnh hưởng lan truyền sóng
1.3. Phân loại kiểm thử
Có hai mức phân loại kiểm thử:
 Phân biệt theo mức độ chi tiết của các bộ phận hợp thành phần mềm
 Kiểm thử đơn vị (Unit Testing)
 Kiểm thử thành phần (Module Testing)
 Kiểm thử tích hợp (Integration Testing)
 Kiểm thử hệ thống (System Testing)
 Kiểm thử chấp nhận (Acceptance Testing)
 Phân loại dựa trên phương pháp kiểm thử (Thường dùng ở kiểm thử
đơn vị)
 Kiểm thử hộp đen (Black box tesing): Dùng để kiểm tra chức
năng

8
 Kiểm thử hộp trắng (White box testing): Dùng để kiểm tra cấu
trúc
 Kiểm thử hộp xám (Gray box testing)
Cụ thể các hình thức kiểm thử này sẽ được đề cập một cách chi tiết trong
phần dưới
1.4. Mô hình chữ V trong kiểm thử
Mô hình chữ V giải thích sự tương quan giữa các công đoạn xây dựng
phần mềm và các loại kiểm thử
Hình 1 - Mô hình chữ V
Ta thấy nhánh bên trái của chữ V là từng giai đoạn trong quy trình phát triển
phần mềm còn ở nhánh bên phải là từng loại kiểm thử tương ứng với mỗi
giai đoạn phát triển đó. Các mức kiểm thử có thể được lập kế hoạch và thiết
kế song song với các bước tương ứng trong quy trình phát triển phần mềm.
Sau đó chúng ta sẽ thực hiện kiểm thử từ đáy chữ V lên các bước bên trên.
Kê hoạch kiểm thử của hệ thống phải được lập trước khi các pha kiểm thử
bắt đầu và phải thỏa mãn một số điều kiện sau:
 Kiểm thử hệ thống phải khớp với các yêu cầu kiểm thử phần mềm
 Các trường hợp kiểm thử cần phải được hoàn thành khi mà các thiết
kế chi tiết đã xong
 Kiểm thử bắt đầu từ ngay sau khi lập trình
Ở mỗi công đoạn xây dựng phần mềm sẽ tương ứng với một loại kiểm thử
và cần có một hồ sơ kiểm thử tương ứng được thành lập để phục vụ cho việc
kiểm thử.
Ví dụ:

9
 Công đoạn: Yêu cầu phần mềm, Loại kiểm thử: Kiểm thử chấp nhận,
Hồ sơ: Hồ sơ kiểm thử chấp nhận (Acceptance test spec)
 Công đoạn: Mô tả chi tiết phần mềm, Loại kiểm thử: Kiểm thử hệ
thống, Hồ sơ: Hồ sơ kiểm thử hệ thống (System test spec)
 Công đoạn: Hồ sơ kiến trúc (Architecture spec), Loại kiểm thử: Kiểm
thử tích hợp, Hồ sơ: Hồ sơ kiểm thử tích hợp (Integration test spec)
 Công đoạn: Thiết kế chi tiết, Loại kiểm thử: Kiểm thử khối (Module
test), Hồ sơ: Hồ sơ kiểm thử khối (Module test spec)
 Công đoạn: Cài đặt, Loại kiểm thử: Kiểm thử đơn vị, Hồ sơ: Hồ sơ
kiểm thử đơn vị (Unit test spec)
1.5. Vòng đời của kiểm thử
Cơ bản kiểm thử tuân theo vòng đời tương ứng với mọi pha của vòng
đời phát triển phần mềm.
 Trong pha lập kế hoạch dự án người quản lý dự án phải quyết định
những cái gì được kiểm thử dựa trên bản đặc tả yêu cầu phần mềm.
Đây là lúc người lãnh đạo kiểm thử và người quản lí dự án làm việc
cùng nhau để tạo ra bản kế hoạch kiểm thử phần mềm Software Test
Plan (STP) mô tả cho phạm vi, khuôn khổ kiểm thử, phương pháp
kiểm thử, lịch biểu kiểm thử, chức năng được kiểm thử hay không
kiểm thử, kiểu kiểm thử nào cần được thực hiện ở các pha khác nhau
của vòng đời, môi trường cho kiểm thử, và phân công cho từng người
kiểm thử.
 Trong pha phân tích yêu cầu, thành viên tổ kiểm thử phải kiểm thử
bản đặc tả yêu cầu kiểm thử và bản kế hoạch kiểm thử phần mềm để
chắc chắn rằng họ hiểu các yêu cầu và điều gì cần được kiểm thử. Họ
sẽ thêm nhiều chi tiết vào bản kế hoạch kiểm thử phần mềm để chắc
chắn rằng họ đã bao quát mọi chức năng phải được kiểm thử. Sau khi
được hoàn thành, bản kế hoạch kiểm thử được sửa đổi sẽ được gửi
cho tổ phát triển kiểm điểm để đảm bảo tính đúng đắn, tính đầy đủ của
bản kế hoạch này. Cả hai tổ sẽ thảo luận thông tin liên quan tới lịch
biểu dự án và phối hợp các hoạt động phát triển với hoạt động kiểm
thử. Điều này là quan trọng vì cả người phát triển và người kiểm thử
phải làm việc cùng nhau trên các trường hợp kiểm thử, dữ liệu kiểm
thử, kịch đoạn kiểm thử cũng như kiểm thử phụ để đảm bảo rằng sản
phẩm cuối cùng sẽ đáp ứng yêu cầu của khách hàng. Bản kế hoạch
kiểm thử phần mềm được sửa đổi cũng sẽ được gửi tới khách hàng để
kiểm điểm và chấp thuận. Một khi được chấp thuận, nó có nghĩa là

10
nếu mọi kiểm thử đều qua được, sản phẩm phần mềm đáp ứng yêu
cầu của khách hàng.
 Trong pha thiết kế phần mềm, khi người phát triển đưa nhiều chi tiết
vào trong thiết kế, người kiểm thử phải làm việc cùng người phát triển
để bổ sung thêm chi tiết cho bản kế hoạch kiểm thử và trường hợp
kiểm thử. Họ phải xác định kiểm thử nào có thể được tự động hoá và
kiểm thử nào phải được thực hiện thủ công. Đây cũng là lúc để nhận
diện mọi vấn đề rủi ro và lập kế hoạch giảm nhẹ chúng. Tổ kiểm thử
phải xác định dữ liệu kiểm thử cho từng trường hợp kiểm thử, dựng
kịch bản kiểm thử cho mọi kiểm thử tự động và sửa lại lịch biểu kiểm
thử, nếu cần.
 Trong pha cài đặt, khi người phát triển làm việc trên mã của họ và
chuẩn bị kiểm thử của họ (kiểm thử đơn vị và kiểm thử chức năng),
người kiểm thử cũng phải hoàn thành mọi trường hợp kiểm thử của
họ, các kịch bản kiểm thử, bộ dẫn lái kiểm thử và các kiểm thử phụ
khác được yêu cầu trong bản đặc tả yêu cầu phần mềm
 Trong pha kiểm thử, sau khi người phát triển hoàn thành kiểm thử đơn
vị và kiểm thử chức năng của họ, tổ kiểm thử phải thực hiện mọi kiểm
thử còn lại. Mọi kết quả đều phải được làm tài liệu như số lỗi, số các
kiểm thử qua được hay không qua được, tình trạng của lỗi, nếu cần
người kiểm thử cũng phải sửa đổi lại các trường hợp kiểm thử hay
thêm các trường hợp kiểm thử mới. (Nếu có thay đổi yêu cầu hay thay
đổi mã) và kiểm thử lại các trường hợp kiểm thử và thực hiện kiểm
thử rà lại. Tổ kiểm thử cũng phải chuẩn bị cho kiểm thử chấp phận
được tiến hành trong môi trường của khách hang.
 Sau khi dự án được hoàn thành, tổ kiểm thử phải đánh giá mọi hoạt
động kiểm thử, qui trình và kế hoạch kiểm thử cho cải tiến tương lai.
Trong pha này, tổ kiểm thử sẽ phân tích qui trình kiểm thử của mình
và làm tài liệu về những ưu điểm và những hạn chế. Họ phải chắc
chắn rằng nếu họ phạm bất kì sai lầm nào, nó sẽ không lặp lại trong
dự án tương lai.
1.6. Các tiêu chí đánh giá kiểm thử
Tiêu chí đánh giá kiểm thử bao gồm độ bao phủ và chất lượng của kiểm thử:

11
 Sự bao phủ của kiểm thử là một tiêu chí quan trọng trong tiến trình
kiểm thử, nó phải bao phủ toàn bộ các yêu cầu cần kiểm thử và các
trường hợp kiểm thử hay toàn bộ đoạn chương trình
 Chất lượng của kiểm thử là một tiêu chí quan trọng để đánh giá độ tin
cậy, tính hiệu năng, sự ổn định của chương trình. Chất lượng của kiểm
thử phụ thuộc vào việc đánh giá, phân tích để phát hiện ra lỗi của
chương trình trong suốt tiến trình kiểm thử

12
2. Sơ lược các kỹ thuật kiểm thử phần mềm
2.1. Kiểm thử tầm hẹp
Các loại kiểm thử này được thực hiện để kiểm thử đến các đơn vị (unit) hoặc
các khối chức năng (module).
2.1.1. Kiểm thử hộp đen
2.1.1.1 Định nghĩa
Kiểm thử hộp đen còn gọi là kiểm thử chức năng. Việc kiểm thử này
được thực hiện mà không cần quan tâm đến thiết kế và mã viết của chương
trình. Kiểm thử theo cách này chỉ quan tâm đến chức năng đã đề ra của
chương trình. Vì vậy kiểm thử loại này chỉ dựa vào bản mô tả chức năng của
chương trình, xem chương trình có thực sự cung cấp đúng chức năng đã mô
tả trong bản chức năng đó hay không.
Kiểm nghiệm hộp đen dựa vào các định nghĩa về chức năng của chương
trình. Các trường hợp kiểm thử được tạo ra dựa vào bản mô tả chức năng
chứ không phải dựa vào cấu trúc của chương trình.
2.1.1.2 Một số phương pháp kiểm thử hộp đen
 Phân lớp tương đương – Equivalence partitioning.
 Phân tích giá trị biên – Boundary value analysis.
 Kiểm thử mọi cặp – All-pairs testing.
 Kiểm thử fuzz – Fuzz testing.
 Kiểm thử dựa trên mô hình – Model-based testing.
 Ma trận dấu vết – Traceability matrix.
 Kiểm thử thăm dò – Exploratory testing.
 Kiểm thử dựa trên đặc tả – Specification-base testing.
2.1.1.3 Ưu và nhược điểm
Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm
thử viên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi. Sử dụng
nguyên tắc “ Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp
đen tìm ra lỗi mà những lập trình viên đã không tìm ra. Nhưng, mặt khác,

13
người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối mà
không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được
kiểm tra thực sự được xây dựng như thế nào. Đó là lý do mà có nhiều trường
hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra
một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy
nhất, và/hoặc một số phần của chương trình không được kiểm tra chút nào.
Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”,
mặt khác nó lại có nhược điểm của “thăm dò mù”.
2.1.1.4 Khái quát một số phương pháp kiểm thử hộp đen
a) Phân đoạn tương đương
Phân đoạn tương đương là phương pháp chia dữ liệu vào thành các
đoạn, mỗi đoạn đại diện cho một số dữ liệu. Và việc kiểm thử chỉ thực
hiện trên đại diện đó. Mục đích của phương pháp này là giảm số
lượng test bằng cách chọn các tập dữ liệu đại diện.
Phương pháp dựa trên một số ý tưởng sau:
 Chương trình chạy để gom những tín hiệu đầu vào tương tự
nhau vào trong cùng một đoạn
 Test mỗi giá trị đại diện của từng đoạn
 Nếu các giá trị đại diện bị lỗi thì các thành viên trong đoạn đó
cũng sẽ bị lỗi như thế
Trong thực tế, có một số cách để nhận diện các đoạn tương đương
như:
 Dựa vào các điều kiện vào ra trong đặc tính kỹ thuật, mô tả kỹ
thuật
 Phân chia thành hai đoạn đầu vào tương đương là Valid và
Invalid tương ứng với dữ liệu đầu vào hợp lệ và không hợp lệ
 Dựa vào các ý kiến của chuyên gia để phân đoạn tương đương
cho hợp lý
Ví dụ: Kiểm thử một hàm tính giá trị tuyệt đối của một số nguyên x
theo phương pháp phân đoạn tương đương.
Ta có thể chia thành các đoạn tương đương theo bảng sau:
Điều kiện Các đoạn tương
đương Valid
Các đoạn tương
đương Invalid
Số lượng số nhập vào 1 0 hoặc > 1
Kiểu dữ liệu nhập vào Nguyên Không nguyên
Giá trị <0, >= 0
Do đó ta có thể đề xuất test case theo phương pháp phân đoạn tương
đương như sau:

14
 x = -200 với đoạn x < 0 nguyên có 1 chữ số; x = 100 với đoạn x
>= 0 nguyên có 1 chữ số
 x = 23 435 với đoạn số lượng số nhập vào > 1; x = "abcdef"
với đoạn giá trị nhập vào không phải là số nguyên.
b) Phương pháp phân tích giá trị biên
Phương pháp phân tích giá trị biên là một trường hợp riêng của
phương pháp phân đoạn tương đương. Với ý tưởng như sau:
 Kiểm tra điều kiện biên của đoạn thì có tác dụng hơn là kiểm
tra các giá trị tùy ý của các lớp như trên
 Chọn các giá trị biên đầu vào để kiểm tra các đoạn thay vì kiểm
tra những giá trị tùy ý
 Chiến lược của phương pháp
 Chọn một giá trị tùy ý cho mỗi đoạn
 Chọn các giá trị chính xác ở biên trên và biên dưới của
mỗi đoạn
 Chọn các giá trị ở ngay bên dưới và bên trên của mỗi
biên nếu có thể
Ví dụ: Kiểm thử một hàm tính giá trị tuyệt đối của một số nguyên
Bảng phân đoạn tương đương như sau
Điều kiện Các đoạn tương
đương Valid
Các đoạn tương
đương Invalid
Số lượng số nhập vào 1 0 hoặc > 1
Kiểu dữ liệu nhập vào Nguyên Không nguyên
Giá trị <0, >= 0
Các test case như sau:
 Trên đoạn x < 0 ta chọn giá trị tùy ý là x = -123
 Trên đoạn x >= 0 ta chọn giá trị tùy ý là x = 234
 Các đoạn x < 0 và x >= 0 có giá trị biên là x = 0
 Các đoạn x < 0 và x >= 0 có các giá trị trên và dưới biên là x = -
1 và x = +1
 Đoạn Invalid có số lượng số nhập vào > 1 ta chọn x = 124 345
 Đoạn giá trị nhập vào không nguyên ta chọn x = "abcdef"
c) Phương pháp đồ thị nguyên nhân - kết quả (Cause - Effect Graphing)
Phương pháp đồ thị nguyên nhân - kết quả sử dụng một đồ thị có
hướng mà ánh xạ một bộ nguyên nhân sang một bộ kết quả. Bộ các
nguyên nhân có thể được xem như đầu vào còn bộ các kết quả có thể
được xem như đầu ra. Thông thường, đồ thị mô tả những nút nguyên
nhân ở bên trái còn những nút kết quả ở bên phải. Có thể có những nút

15
trung gian đứng ở giữ để kết hợp các nút sử dụng các phép toán logic
AND và OR.
Thay vì các tester phải cố gắng xác định các testcase một cách thủ
công thì họ có thể sử dụng kỹ thuật trên để xác định các trường hợp
kiểm thử có thể bao phủ 100% các chức năng. Điểm bắt đầu để xây
dựng đồ thị nguyên nhân – kết quả là tài liệu đặc tả yêu cầu cái mà mô
tả hệ thống dự định sẽ làm gì. Từng đầu vào và đầu ra trong đồ thị
nguyên nhân kết quả tương ứng với một biểu thức điều kiện cái mà có
thể nhận một trong hai giá trị true hoặc false.
Một vài ví dụ sau đây sẽ mô tả chi tiết hơn phương pháp đồ thị
nguyên nhân - kết quả:
Ví dụ: Xây dựng đồ thị nguyên nhân kết quả của câu lệnh sau: if A
OR B then C;
Có thể xảy ra các trường hợp sau:
 Nếu A đúng và B đúng thì C là đúng
 Nếu A đúng và B sai thì C là đúng
 Nếu A sai và B đúng thì C đúng
 Nếu A sai và B sai thì C sai
Đồ thị nguyên nhân - kết quả sẽ được mô tả như hình dưới:
Đồ thị nguyên nhân - kết quả
Trong hình trên thì A, B, C được gọi là các nút, trong đó thì nút A, B
là các nút nguyên nhân còn nút C là nút kết quả. Từng nút có thể nhận
một trong hai giá trị true hoặc false. Các cung nối giữa các đỉnh có thể
gọi là các vector.
Một số loại quan hệ giữa các nút như sau:

16
Một số loại quan hệ giữa các nút trong đồ thị nguyên nhân – kết quả
Đồ thị nguyên nhân – kết quả sau khi được thiết lập xong sẽ được chuyển
sang bảng quyết định (Decision Table). Bảng quyết định để mô tả quan hệ
logic giữa nguyên nhân và kết quả. Từng cột trong bảng quyết định là một
trường hợp kiểm thử (test case). Từng testcase tương ứng với một đầu vào
cụ thể và đầu vào đó là một tập hợp các giá trị của của các nút nguyên nhân
có thể nhận giá trị true hoặc false.
Ứng với ví dụ trên thì ta có thể xây dựng được bảng quyết định như sau:
Testcase 1 Testcase 2 Testcase 3
Cause A True False False
B False True False
Effect C True True False
Trên lý thuyết, ta thấy khi đầu vào của bài toán có 2 nút cause như trong ví
dụ trên, mà mỗi nút có thể nhận một trong hai giá trị là true hoặc false thì sẽ
có tất cả là 22 = 4 trường hợp kiểm thử. Nhưng trong bảng trên ta chỉ xét 3
trường hợp kiểm thử vì trường hợp cuối cùng (A = true và B = true  C =
true) là dư thừa (Do ở 3 trường hợp xét trước đó thì A, B, C đã nhận cả true
và false) nên ta không cần thiết phải đưa vào.
Do đó, dựa vào bảng quyết định trên thì ta có thể tìm được các testcase bao
phủ được hết các chức năng của chương trình.

17
Ví dụ: Tính result = 1 + 2 + … + |value| nếu result <= maxint và sinh ra lỗi
nếu ngược lại
 Đồ thị nguyên nhân kết quả như sau:
Đồ thị nguyên nhân - kết quả
 Bảng quyết định
2.1.2. Kiểm thử hộp trắng
2.1.2.1Định nghĩa
Kiểm thử hộp trắng còn gọi là kiểm thử cấu trúc. Kiểm thử theo cách
này là loại kiểm thử sử dụng các thông tin về cấu trúc bên trong của ứng
dụng. Cho phép tester truy cập vào các cấu trúc dữ liệu và các đoạn mã bên
trong của chương trình. Việc kiểm thử này dựa trên quá trình thực hiện và
xây dựng phần mềm.

18
2.1.2.2 Tiêu chuẩn của kiểm thử hộp trắng
 Bao phủ dòng lệnh: Mỗi dòng lệnh ít nhất phải được thực thi một lần
 Bao phủ nhánh: Mỗi nhánh trong sơ đồ điều khiển phải được đi qua ít
nhất một lần
 Bao phủ đường: Tất cả các đường từ điểm khởi tạo đến điểm cuối
cùng trong sơ đồ dòng điều khiển phải được đi qua
 Kiểm thử giao diện lập trình ứng dụng - API testing (application
programming interface): là phương pháp kiểm thử của ứng dụng sử
dụng các API công khai và riêng tư.
 Các phương pháp gán lỗi – Fault injection.
 Các phương pháp kiểm thử hoán chuyển – Mutation testing methods.
 Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểm
thử tĩnh.
Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự
hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp
kiểm thử hộp đen. Điều này cho phép các nhóm phần mềm khảo sát các
phần của 1 hệ thống ít khi được kiểm tra và đảm bảo rằng những điểm chức
năng quan trọng nhất đã được kiểm tra.
2.1.2.3 một số phương pháp, kỹ thuật trong kiểm thử hộp trắng
a) Mô tả một số cấu trúc theo lược đồ
Trong các phương pháp kiểm tra tính đúng đắn của chương trình lược
đồ được dùng để:
 Trừu tượng hóa cú pháp của mã lệnh
 Làm khuôn mẫu cơ bản cho các nguyên tắc kiểm tra theo
trường hợp
 Kiểm tra tính đúng đắn trên toàn bộ lược đồ
Dưới đây là một số lược đồ của các loại câu lệnh thường gặp:

19
Một số lược đồ của các câu lệnh
b) Kiểm tra theo câu lệnh (Statement Testing)
Phương pháp này thiết kế quá trình kiểm tra sao cho mỗi câu lệnh của
chương trình được thực hiện ít nhất một lần. Phương pháp kiểm tra
này xuất phát từ ý tưởng. Nếu một câu lệnh không được thực hiện thì
ta không thể biết có lỗi xảy ra trong câu lệnh đó hay không. Do đó ý
tưởng của phương pháp này là đưa ra test case sao cho test case đó sẽ
quét hết tất cả các câu lệnh trong đoạn chương trình ta muốn kiểm
thử.
Ví dụ: Cho đoạn chương trình sau:
Đoạn chương trình trên mô tả bài toán tính

20
result = 1 + 2 + … + |value| nếu result <= maxint và In ra 'Too Large'
nếu ngược lại
Dựa vào đoạn mã trên ta có thể xây dựng được đồ thị sau:
Với bộ giá trị Input (maxint = 10, value = -1) và (maxint = 0, value = -
1) sẽ kiểm tra được toàn bộ các lệnh trong đoạn chương trình trên.
c) Kiểm tra theo đường dẫn (Path Testing)
Đây là phương pháp kiểm tra bao trùm mọi đường dẫn của chương
trình và cần kết hợp với lược đồ tiến trình
Ví dụ: Với đoạn mã
if (A > B && C > D) {
S1;
}
else{
S2;
}
S3;
Ta sẽ có lược đồ tiến trình như sau:

21
Lược đồ mô tả cấu trúc path của chương trình
Nhận xét: Phương pháp kiểm tra theo biểu thức phụ thuộc nhiều vào
các biểu thức điều kiện. Tuy nhiên, có những trường hợp số lượng
đường dẫn quá lớn (thường trong các trường hợp có vòng lặp). Vì vậy
phương pháp này thường không phải là lựa chọn thực tế để kiểm tra
tính đúng đắn của chương trình.
d) Kiểm tra theo điều kiện (Condition Testing)
Đây là phương pháp kiểm tra các biểu thức điều kiện trên hai giá trị
true hoặc false.
Phương pháp trên sẽ được minh họa qua ví dụ sau:
Ví dụ 1:
if (x > 0 && y > 0){
x = 100;
}
else{
x = 5000;
}
Trong trương hợp trên ta thấy các bộ kiểm tra {(x > 0, y > 0), (x <= 0,
y > 0)} sẽ kiểm tra toàn bộ các điều kiện.
Ví dụ 2:
if (x != 0){
y = 100;
}
if (z < 1){
z /= x;
}else{
z = 0;
}

22
Với bộ kiểm tra {(x = 0, z = 1), (x = 1, z = 0)} sẽ kiểm tra bao trùm
được các điều kiện.
Tuy nhiên không kiểm tra được trường hợp lỗi chia cho 0 (trong
trường hợp x = 0).
Do đó ta rút ra nhận xét là khi kiểm tra bằng phương pháp kiểm thử
theo điều kiện cần xem xét kết hợp các điều kiện với nhau.
e) Kiểm tra theo vòng lặp (Loop Testing)
Đây là phương pháp kiểm thử tập trung vào tính hợp lệ của các cấu
trúc vòng lặp
Với từng loại vòng lặp ta có cách thức kiểm tra như sau:
 Các bước cần kiểm tra cho vòng lặp đơn
o Bỏ qua vòng lặp
o Lặp một lần
o Lặp hai lần
o Lặp m lần (m < n)
o Lặp (n - 1), n, (n + 1) lần
Trong đó n là số lần lặp tối đa của vòng lặp
 Các bước cần kiểm tra cho vòng lặp dạng lồng nhau
o Khởi đầu với vòng lặp nằm bên trong nhất. Thiết lập các
tham số lặp cho các vòng lặp bên ngoài về giá trị nhỏ
nhất
o Kiểm tra với tham số min+1, 1 giá trị tiêu biểu, max-1 và
max cho vòng lặp bên trong nhất trong khi các tham số
lặp của các vòng lặp bên ngoài là nhỏ nhất

23
o Tiếp tục tương tự với các vòng lặp liền ngoài tiếp theo
cho đến khi tất cả vòng lặp bên ngoài được kiểm tra
 Các bước cần kiểm tra cho vòng lặp nối tiếp
o Nếu các vòng lặp là độc lập với nhau thì kiểm tra như
trường các vòng lặp dạng đơn, nếu không thì kiểm tra
như trường hợp các vòng lặp lồng nhau
Ví dụ:
#define MAX 10
#define MIN 1
void main(){
int input, numberOfInterations = 0;
scanf("%d", &input);
for (int i = input; i >= MIN && i <= MAX;
i++){
numberOfInterations++;
}
printf("%d", numberOfInterations);
}
Nhận thấy đây là trường hợp vòng lặp đơn nên ta sẽ thiết lập được test
case như trong bảng sau:
Đầu vào Đầu ra
11 0 (Bỏ qua vòng lặp)
10 1 (Chạy 1 lần lặp)
9 2 (Chạy 2 lần lặp)
5 6 (Chạy m lần lặp với m < n)
2 9 (Chạy n - 1 lần lặp)
1 10 (Chạy n lần lặp)
0 0 (Bỏ qua vòng lặp)
2.1.3. Kiểm thử hộp xám
Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và
giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là
kiểm thử ở mức người sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu
đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc
hộp xám, bởi vì đầu vào và đầu ra rõ ràng là ở bên ngoài hộp đen mà chúng
ta vẫn gọi về hệ thống được kiểm tra. Sự khác biệt này đặc biệt quan trọng
khi quản lý kiểm thử tích hợp – Integration testing giữa 2 modun mã lệnh
được viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là

24
được đưa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế
đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi.
2.2. Kiểm thử tầm rộng
Hình dưới mô tả các bước kiểm thử có trong quy trình phát triển phần mềm
Hình 2 - Các loại kiểm thử
Dưới đây ta sẽ trình bày một cách chi tiết từng kỹ thuật kiểm thử trên
2.2.1 Kiểm thử đơn vị (Unit Testing)
Trước hết ta sẽ định nghĩa khái niệm đơn vị. Một đơn vị là một thành
phần phần mềm nhỏ nhất mà ta có thể kiểm tra được. Ví dụ, các hàm
(Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) đều
có thể được xem là Unit.
Do đó kiểm thử đơn vị là kiêm tra sự thực thi của các đơn vị chương trình
riêng rẽ.
Do các Unit được kiểm tra thường có kích thước nhỏ và chức năng hoạt
động tương đối đơn giản nên chúng ta sẽ không gặp mấy khó khăn trong
việc tổ chức kiểm tra ghi nhận và phân tích kết quả kiểm tra. Nếu phát hiện
lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ
khoanh vùng trong một đơn thể Unit đang kiểm tra. Trong thực tiễn thường
thì thời gian chi phí cho Unit Test sẽ được đền bù bằng việc tiết kiệm rất
nhiều thời gian và chi phí cho việc kiểm tra và sửa lỗi ở các mức kiểm tra
sau đó. Do đó nếu trong bước này chúng ta làm cẩn thận thì các bước test
sau sẽ ít gặp lỗi hơn nhiều.

25
Giá thành sẽ càng bị đội lên nếu không phát hiện thấy lỗi
ở ngay bước Unit Testing
Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực
hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát
triển phần mềm. Thông thường, Unit Test đòi hỏi kiểm tra viên có kiến thức
về thiết kế và code của chương trình. Mục đích của Unit Test là bảo đảm
thông tin được xử lý và xuất ra khỏi Unit là chính xác trong mối tương quan
giữa dữ liệu nhập và chức năng của unit.
Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước
các tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu
vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra. Các test case và
script này nên được giữ lại để tái sử dụng
2.2.2 Kiểm thử tích hợp (IntegrationTest)
Integration test kết hợp các thành phần của một ứng dụng và kiểm tra
như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành
phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm
tra sự giao tiếp và truyền thông điệp giữa chúng.

26
Các mục tiêu chính của Integration Test bao gồm:
 Phát hiện lỗi giao tiếp xảy ra giữa các Unit.
 Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối
cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở
mức hệ thống (System Test).
Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức
năng và cấu trúc nội tại của Unit. Có một số phép kiểm tra đơn giản trên
giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao
tiếp liên quan đến Unit thật sự được kiểm tra đầy đủ khi các Unit tích hợp
với nhau trong khi thực hiện Integration Test. Trừ một số ít ngoại lệ,
Integration Test chỉ nên thực hiện trên những Unit đã được kiểm tra cẩn thận
trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa. Một
số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao
tiếp giả lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc
tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.
Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng
Unit. Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác
mà nhóm các Unit đó đã được tích hợp trước đó và đã hoàn tất các đợt
Integration Test trước đó. Lúc này, ta chỉ cần kiểm tra giao tiếp của Unit mới
thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm cho số
lượng kiểm tra sẽ giảm đi rất nhiều và sai sót sẽ giảm đáng kể.
Có 4 loại kiểm tra trong Integration Test:
 Kiểm tra cấu trúc (structure): Tương tự White Box Test tức là kiểm tra
nhằm bảo đảm các thành phần bên trong của một chương trình chạy
đúng, chú trọng đến hoạt động của các thành phần cấu trúc nội tại của
chương trình chẳng hạn các lệnh và nhánh bên trong.
 Kiểm tra chức năng (functional): Tương tự Black Box Test tức là
kiểm tra chỉ chú trọng đến chức năng của chương trình, không quan
tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình
theo yêu cầu kỹ thuật.

27
 Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ
thống.
 Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ
thống.
2.2.3. Kiểm thử hệ thống (System Testing)
System test bao gồm một loạt những kiểm nghiệm nhằm xác minh
toàn bộ các thành phần của hệ thống được tích hợp một cách đúng đắn. Mục
đích của kiểm thử hệ thống là đảm bảo toàn bộ hệ thống hoạt động như
khách hàng mong muốn.
System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp
thành công. Thông thường loại kiểm tra này tốn rất nhiều công sức và thời
gian. Trong nhiều trường hợp, việc kiểm tra đòi hỏi yên cầu phải có môi
trường kiểm thử thích hợp. Ví dụ như một số thiết bị phụ trợ, phần mềm
hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống
phân bố, hoặc hệ thống nhúng. Ở mức độ của kiểm thử hệ thống thì tester
cũng tìm kiếm các lỗi, nhưng trọng tâm của loại kiểm thử này là đánh giá về
chức năng, hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến
chất lượng của toàn hệ thống.
Điểm khác nhau then chốt giữa Integration Test và System Test là System
Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú
trọng sự giao tiếp giữa các thực thể hoặc đối tượng khi chúng làm việc cùng
nhau. Trong quy trình kiểm thử thì thông thường ta phải thực hiện Unit Test
và Integration Test để đảm bảo mọi đơn vị và giao tiếp, tương tác giữa
chúng hoạt động chính xác trước khi thực hiện System Test.
Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình
thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này,
lập trình viên hoặc tester sẽ bắt đầu kiểm tra phần mềm như một hệ thống
hoàn chỉnh. Và việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn
hình thành và phân tích các yêu cầu của phần mềm.
System Test kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu
cầu phi chức năng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo
mật… Mức kiểm tra này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp
với các phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi bế tăc
(deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, phần mềm
thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm tra để
chấp nhận (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).
Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System
Test thường được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập
với nhóm phát triển dự án

28
System test bao gồm một số loại kiểm tra sau:
 Kiểm tra chức năng (Functional Testing): Kiểm tra hệ thống sau khi
tích hợp có hoạt động đúng chức năng với yêu cầu đặt ra trong bản
mô tả yêu cầu hay không.
VD: Với hệ thống xử lý văn bản thì kiểm tra các chức năng như: tạo
tài liệu, sửa tài liệu, xóa tài liệu… có hoạt động đúng theo yêu cầu hay
không.
 Kiểm tra hiệu năng (Performance Testing): Đảm bảo tối ưu việc phân
bổ tài nguyên hệ thống nhằm đạt các chỉ tiêu như thời gian xử lý hay
đáp ứng câu truy vấn.
 Kiểm tra mức độ đáp ứng (Stress Testing): Thực thi hệ thống với giả
thiết là các tài nguyên hệ thống yêu cầu không đáp ứng được về chất
lượng, ổn định, số lượng. Loại kiểm tra này tập trung vào các điểm tới
hạn, điểm chết, các tình huống bất thường của hệ thống.
 Kiểm tra cấu hình (Configuration Network): Phân tích hệ thống với
các thiết lập cấu hình khác nhau
 Kiểm nghiệm ổn định (Robustness Testing): Kiểm nghiệm dưới các
điều kiện không mong đợi. Ví dụ như người dùng gõ lệnh sai hay
nguồn điện bị ngắt.
 Kiểm tra khả năng phục hồi (Recorvery Testing): Đảm bảo hệ thống
có khả năng khôi phục trạng thái ổn định trước đó trong tình huống
mất tài nguyên hoặc dữ liệu. Điều này đặc biệt quan trọng với các hệ
thống giao dịch như ngân hàng trực tuyến.
 Kiểm tra khả năng bảo mật (Security Testing): Đảm bảo tính toàn vẹn,
bảo mật của dữ liệu và của hệ thống.
 Kiểm tra quá tải (Overload Testing): Đánh giá hệ thống khi nó vượt
qua giới hạn cho phép.
 Kiểm tra chất lượng (Quality Testing): Đánh giá sự tin tưởng, vấn đề
duy tu, tính sẳn sàng của hệ thống. Bao gồm cả việc tính toán thời
gian trung bình hệ thống sẽ bị hỏng và thời gian trung bình để khắc
phục.
 Kiểm tra cài đặt (Installation Testing): Người dùng sử dụng các chức
năng của hệ thống và ghi lại các lỗi tại vị trí sử dụng thật sự. VD: Một
hệ thống điều khiển một lò nấu thép phải đảm bảo không chịu sự ảnh
hưởng của nhiệt độ.
2.2.4. Kiểm thử chấp nhận (Acceptance Testing)
Sau giai đoạn System Test là Acceptance Test, đây là giai đoạn kiểm
tra được khách hàng thực hiện. Mục đích của Acceptance Test là để chứng

29
minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp
nhận sản phẩm và trả tiền thanh toán hợp đồng.
Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi
trường hợp, các phép kiểm tra của System Test và Accepatnce Test gần như
tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.
Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người
sử dụng, thông thường sẽ thông qua hai loại kiểm tra gọi là Alpha Test và
Beta Test. Với Alpha Test, người sử dụng kiểm tra phần mềm ngay tại nơi
phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên
kế hoạch sửa chữa. Với Beta Test, phần mềm sẽ được gửi tới cho người sử
dụng để kiểm tra ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi
ngược lại cho lập trình viên để sửa chữa.
Trên thực tế, nếu khách hàng không quan tâm và không tham gia vào quá
trình phát triển phần mềm thì thường kết quả Acceptance Test sẽ sai lệch rất
lớn, mặc dù PM đã trải qua tất cả các kiểm tra trước đó. Sự sai lệch này liên
quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng. Ví dụ
đôi khi một PM xuất sắc vượt qua các phép kiểm tra về chức năng thực hiện
bởi nhóm thực hiện dự án, nhưng khách hàng khi kiểm tra sau cùng vẫn thất
vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập
quán sử dụng của khách hàng…

30
3. Các chiến lược kiểm thử phần mềm
3.1 Khái quát
Một chiến lược kiểm thử là một bản phác họa mô tả phần kiểm thử của một
qui trình phát triển phần mềm. Nó được tạo ra để thông báo đến các quản lý
dự án, tester và DEV về một số vấn đề chính của quá trình kiểm thử. Bao
gồm mục tiêu kiểm thử, các phương pháp dùng để kiểm thử các chức năng
mới, tổng thời gian và nguồn nhân lực được yêu cầu cho dự án và môi
trường kiểm thử.
Các chiến lược kiểm thử mô tả làm thế nào để các rủi ro sản phẩm của các
bên liên quan được giảm bớt ở các mức kiểm thử, loại kiểm thử nào sẽ được
thực hiện, và sẽ áp dụng điều kiện bắt đầu và kết thúc kiểm thử nào. Chúng
được tạo ra dựa trên các tài liệu thiết kế phát triển phần mềm. Các tài liệu
thiết kế hệ thống được sử dụng chủ yếu và đôikhi cũng tham khảo tài liệu
thiết kế khái niệm. Các tài liệu thiết kế mô tả chức năng của phần mềm sẽ
được kích hoạt trong đợt phát hành sắp tới. Ở mọi giai đoạn (chặng) thiết kế
phát triển, một chiến lược kiểm thử tương ứng sẽ được tạo để kiểm thử các
tập đặc điểm mới (vì ở mỗi chặng phát triển phần mềm thì có các đặc điểm
riêng cần kiểm thử).
Định nghĩa khác: Phương pháp tiếp cận kiểm thử và Cấu trúc kiểm thử là
các thuật ngữ khác thường được sử dụng để mô tả cái gọi là chiến lược kiểm
thử.
Ví dụ một chiến lược kiểm thử được trình bày một cáchđơn giản: "Chúng ta
sẽ sử dụng black box testing, cause-effect graphing, boundary testing, và
white box testing để kiểm thử sản phẩm này dựa vào bản mô tả định nghĩa
của nó."
3.2 Chiến lược kiểm thử
Tiến trình kỹ nghệ phần mềm có thể được xét theo vòng xoắn ốc. Ban đầu,
kỹ nghệ phần mềm xác định vai trò của phần mềm và đưa tới việc phân tích
yêu cầu phần mềm, chỗ thiết lập nên lĩnh vực thông tin, chức năng, hành vi,
hiệu năng, ràng buộc và tiêu chuẩn hợp lệ cho phần mềm. Đi vào trong vòng
xoắn ốc, chúng ta tới thiết kế và cuối cùng tới mã hoá. Để xây dựng phần
mềm máy tính, chúng ta đi dọc theo đường xoắn ốc, mỗi lần mức độ trừu
tượng lại giảm dần.
Một chiến lược cho kiểm thử phần mềm cũng có thể xem xét bằng cách đi
theo đường xoắn ốc ra ngoài. Việc kiểm thử đơn vị bắt đầu tại tâm xoáy của
xoắn ốc và tập chung vào các đơn vị của phần mềm khi được cài đặt trong

31
chương trình gốc. Việc kiểm thử tiến triển bằng cách đi ra theo đường xoắn
ốc tới kiểm thử tíchhợp, nơi tập trung vào thiết kế và việc xây dựng kiến
trúc phần mềm. Đi thêm một vòng xoáy nữa trên đường xoắn ốc chúng ta
gặp kiểm thử hợp lệ, nơi các yêu cầu, được thiết lập như một phần của việc
phân tích yêu cầu phần mềm, được hợp lệ hoá theo phần mềm đã được xây
dựng. Cuối cùng chúng ta tới kiểm thử hệ thống, nơi phần mềm và các phần
tử hệ thống khác được kiểm thử như một toàn bộ. Để kiểm thử phần mềm
máy tính, chúng ta theo đường xoáy mở rộng dần phạm vi kiểm thử một lần.
Hình 3 – Các bước kiểm thử
Xem xét tiến trình này theo quan điểm thủ tục vì việc kiểm thử bên trong
hoàn cảnh kỹ nghệ phần mềm thực tại là một chuỗi gồm ba bước được thực
hiện tuần tự nhau. Các bước này được minh họa trong Hình 3. Ban đầu,
việc kiểm thử tập trung vào từng mô đun riêng biệt, đảm bảo rằng nó vận
hành đúng đắn như một đơn vị. Do đó mới có tên kiểm thử đơn vị. Kiểm thử
đơn vị dùng rất nhiều các kỹ thuật kiểm thử hộp trắng, thử các đường đặc
biệt trong cấu trúc điều khiển của một mô đun để đảm bảo bao quát đầy đủ
và phát hiện ra lỗi tối đa. Tiếp đó các mô đun phải được lắp ghép hay tích
hợp lại để tạo nên bộ trình phần mềm hoàn chỉnh. Việc kiểm thử tích hợp đề
cập tới các vấn đề có liên quan tới các vấn đề kiểm chứng và xây dựng
chương trình. Các kỹ thuật thiết kế kiểm thử hộp đen chiếm đại đa số trong
việc tíchhợp, mặc dầu một số giới hạn các kiểm thử hộp trắng cũng có thể
dược dùng để đảm bảo bao quát đa số các đường điều khiển.

32
Sau khi phần mềm đã được tíchhợp (được xây dựng), một tập các phép
kiểm thử cao cấp sẽ được tiến hành. Các tiêu chuẩn hợp lệ (được thiết lập
trong phân tích yêu cầu) cũng phải được kiểm thử. Việc kiểm thử hợp lệ
đưa ra sự đảm bảo cuối cùng rằng phần mềm đáp ứng cho tất cả các yêu cầu
chức năng, hành vi và sự hoàn thiện. Các kỹ thuật kiểm thử hộp đen được
dùng chủ yếu trong việc hợp lệ hoá này.
Bước kiểm thử cấp cao cuối cùng rơi ra ngoài phạm vi của kỹ nghệ phần
mềm và rơi vào hoàn cảnh rộng hơn của kỹ nghệ hệ thống máy tính. Phần
mềm, một khi được hợp lệ hoá, phải được tổ hợp với các phần tử hệ thống
khác (như phần cứng, con người, cơ sở dữ liệu). Kiểm thử hệ thống kiểm
chứng lại rằng tất cả các yếu tố có khớp đúng với nhau không và rằng chức
năng/ độ hoàn thiện hệ thống toàn bộ đã đạt được.

33
4. Các công cụ kiểm thử phần mềm
4.1.Quick test pro
4.1.1 Giới thiệu
Phần mềm QuickTest Pro là phần mềm kiểm soát việc test tự động những
chức năng của một sản phẩm phần mềm khác, là một bộ phận (module) của
hệ thống Mercury Quality Center bao gồm nhiều module phần mềm phối
hợp với nhau để quản lý toàn bộ quy trình đảm bảo chất lượng sản phẩm
phần mềm. Trước đây, phần mềm này do hãng Mercury
(www.mercury.com) phát hành. Sau này, tập đoàn HP đã mua lại toàn bộ
hãng Mercury, nên tên gọi của nó đầy đủ là: HP Mercury QuickTest Pro.
Nếu ta có một sản phẩm phần mềm Quản lý Nhân sự. Ví dụ, khi mở phần
mềm Quản lý Nhân sự lên, thì người dùng sẽ gặp form Đăng nhập (login) để
nhập vào "Tên tài khoản" và "Mật khẩu", rồi nhấn nút "OK" hoặc "Cancel"
để vào.
Ta lập trình ra lệnh cho QuickTest Pro tự động điền thông tin vào 2 ô "Tên
tài khoản" và "Mật khẩu", và rồi cũng tự động "nhấn" nút "OK" hoặc
"Cancel" dùm bạn luôn. Công việc này gọi là viết script cho QuickTest Pro.
Viết script để thực hiện nhiều trường hợp nhập dữ liệu khác nhau, nhiều thao
tác khác nhau, để thử xem chức năng của form "Đăng nhập" có hoạt động
đúng hay không. QuickTest Pro sau khi chạy script xong, sẽ thực hiện ghi
nhận kết quả việc test tự động, và có thể xuất report. Nếu có đủ một hệ thống
Mercury Quality Center thì ít ra phải có thêm phần mềm Mercury Test
Director đóng vai trò là phần mềm chủ (serving software) đảm nhận việc
tổng hợp các kết quả test, các báo cáo, các phát sinh... của QuickTest Pro, từ
đó phục vụ cho công việc quản trị chất lượng sản phẩm phần mềm của bạn
(Software Quality Assurance).
Đây là chương trình dùng để kiểm tra chức năng (functional test) và cho
phép thực hiện kiểm tra hồi qui (regression test) một cách tự động. Đây cũng
là công cụ áp dụng phương pháp Keyword-Driven, một kỹ thuật scripting
hiện đại, cho phép kĩ thuật viên bổ sung test casebằng cách tạo file mô tả
cho nó mà không cần phải chỉnh sửa hay bổ sung bất cứ script nào cả. Nó
cũng phù hợp trong tình huống chuyển giao công việc mà người mới tiếp
nhận chưa có thời gian hoặc không hiểu script vẫn có thể thực hiện kiểm tra
phần mềm theo đúng yêu cầu.

34
4.1.2 Loại phần mềm hỗ trợ
QTP giúp chúng ta kiểm tra phần mềm theo hướng chức năng trên rất nhiều
loại chương trình phần mềm khác nhau. Tuy nhiên Mercury chỉ hỗ trợ sẵn
một số loại chương trình thông dụng như:
 Ứng dụng Windows chuẩn/Win32.
 Ứng dụng web theo chuẩn HTML, XML chạy trong trình duyệt
Internet Explorer, Netscape hoặc AOL.
 Visual Basic.
 ActiveX.
 QTP hỗ trợ Unicode (UTF-8, UTF-16).
 Một số loại chương trình khác đòihỏi chúng ta phải cài đặt thêm
thành phần bổ sung của QTP thì mới thực hiện kiểm tra được. Các
loại chương trình đó là
- .NET Framework 1.0, 1.1, 2.0
- Các đốitượng chuẩn của .NET và các đối tượng
khác thừa kế từ các đối tượng chuẩn.
- Java Sun JDK 1.1 – 1.6
- IBM JDK 1.2 – 1.4
- Oracle Applications 11.5.7, 11.5.8, 11.5.9
- PeopleSoft Enterprise 8.0 – 8.8
- SAP GUI HMTL 4.6D, 6.10, 6.20
- SAP Workplace 2.11
- SAP Enterprise Portal 5.0
- Siebel 7.0, 7.5, 7.7
- Terminal Emulators
- Attachmate EXTRA! 6.7, 7.1
- IBM Personal Communications
4.1.3 Đặc điểm
 Dễ sử dụng, bảo trì, tạo test script nhanh. Cung cấp dữ liệu kiểm tra rõ
ràng và dễ hiểu.
 Kiểm tra phiên bản mới của ứng dụng với rất ít sự thay đổi. Ví dụ khi
ứng dụng thay đổi nút tên “Login” thành “Đăng nhập”, thì chỉ cần cập
nhật lại Object Repository(OR –được giải thích ở phần sau) để QTP
nhận ra sự thay đổi đó mà không cần thay đổi bất cứ test script nào.
 Hỗ trợ làm việc theo nhóm thông qua sự chia sẻ thư viện, thống nhất
quản lý Object Repository.
 Thực tế cho thấy, QTP thực hiện kiểm tra tự động trên nhiều trình
duyệt cùng lúc tốt hơn những công cụ kiểm tra khác.

35
 Với chức năng Recovery Scenarios, QTP cho phép xử lý những sự
kiện hoặc lỗi không thểđoán trước có thể làm script bị dừng trong khi
đang chạy.
 QTP có khả năng hiểu test script của Mercury Winrunner (một công
cụ kiểm tra khác của Mercury).
 Quản trị Object Repository
 Phối hợp giữa các KTV qua việc đồng bộ hóa dữ liệu, khả năng trộn,
nhập/xuất ra file XML
 Kiểm tra tài nguyên: Kiểm tra tài nguyên cần thiết trước khi thực thi
lệnh kiểm tra tự động.
 Hỗ trợ XML cho báo cáo: Lưu trữ kết quả kiểm tra dưới dạng XML,
HTML, từđó cho phép tùy biến báo cáo.
 Quản trị từ khóa trong quá trình sử dụng
 Hỗ trợ đa giao tiếp: Cho phép người dùng mở và soạn thảo đồng thời
nhiều hàm thư viện và Object Repository.
 Giao diện sử dụng đẹp, dễ bắt nhập
 Hỗ trợ quản lý script: Debug toolbar, hỗ trợ kiểm tra lỗi trong test
script (debug)
 Testing: Hỗ trợ quá trình tạo test script hoặc thực hiện kiểm tra tự
động
4.1.4 Các thành phần quan trọng trong QTP
a) Action
Giống như thủ tục hay hàm trong các ngôn ngữ lập trình khác, Action
ghi lại các bước thực hiện kiểm tra tự động và nó có thể được sử dụng lại
nhiều lần. Trong một test script có thể có nhiều Action.
b) DataTable
Nơi lưu dữ liệu phục vụ cho kiểm tra tự động. Một test script sẽ có
một DataTable được dùng chung cho tất cả các Action. Bên cạnh đó mỗi
Action cũng có một DataTable cho riêng mình.
c) Object Repository(OR)
 Cấu trúc theo dạng cây, mô tả các đốitượng trong phần mềm được
kiểm tra. Đây được xem là cầu nối để test script tương tác với phần
mềm được kiểm tra.
 Khi ra lệnh cho QTP ghi lại thao tác người dùng lên phần mềm thì
trong OR sẽ tựđộng phát sinh thành phần đại diện cho những đối
tượng trên PHầN MềM vừa được thao tác.
 OR có thể tổ chức thành 2 loại, một loại dùng chung trong nhiều test
script, loại khác dùng theo từng Action.
d) Checkpoint

36
Là nơi kiểm tra trong test script, khi chạy nó sẽ thực hiện so sánh kết
quả thực tế khi kiểm tra phần mềm với kết quả mong đợi. Sau khi tiến hành
so sánh QTP sẽ tự động ghi lại kết quả vào Test Results (nơi lưu kết quả khi
chạy test script).
4.1.5 Ngônngữ viết script
QTP sử dụng ngôn ngữ VBScript để viết test script. Đây là ngôn ngữ dễ học;
rất giống ngôn ngữ VBA. Chế độ Expert View của QTP là chế độ soạn thảo
dành cho VBScript. Ngoài việc dùng VBScript để tương tác với phần mềm
được kiểm tra, QTP còn có khả năng cấu hình hệ thống bằng ngôn ngữ
Windows Script.
Chi tiết về ngôn ngữ VBScript, người đọc có thể dễ dàng tìm trong các sách
hiện có trên thị trường, thậm chí ngay chính trong phần help của QTP.
4.2 JUnit
JUnit là một framework đơn giản dùng cho việc tạo các unit testing tự động,
và chạy các test có thể lặp đi lặp lại. Nó chỉ là một phần của họ kiến trúc
xUnit cho việc tạo các unit testing. JUnit là một chuẩn trên thực tế cho unit
testing trong Java. JUnit về nguồn gốc được viết bởi 2 tác giả Erich Gamma
và Kent Beck
JUnit có những đặc điểm đáng lưu tâm như sau:
 Xác nhận (assert) việc kiểm tra kết quả được mong đợi
 Các Test Suite cho phép chúng ta dễ dàng tổ chức và chạy các test
 Hỗ trợ giao diện đồ họa và giao diện dòng lệnh
 Các test case của JUnit là các lớp của Java, các lớp này bao gồm một
hay nhiều các phương thức unit testing, và những test này lại được
nhóm thành các Test Suite.
 Mỗi phương thức test trong JUnit phải được thực thi nhanh chóng.
Tốc độ là điều tối quan trọng vì càng nhiều test được viết và tíchhợp
vào bên trong quá trình xây dựng phần mềm, cần phải tốn nhiều thời
gian hơn cho việc chạy toàn bộ TestSuite. Các lập trình viên không
muốn bị ngắt quãng trong một khoãng thời gian dài trong khi các test
chạy, vì thế các test mà chạy càng lâu thì sẽ có nhiều khả năng là các
lập trình viên sẽ bỏ qua bước cũng không kém phần quan trọng này.
 Các test trong JUnit có thể là các test được chấp nhận hay thất bại, các
test này được thiết kế để khi chạy mà không cần có sự can thiệp của
con người. Từ những thiết kế như thế, bạn có thể thêm các bộ test vào

37
quá trình tíchhợp và xây dựng phần mềm một cách liên tục và để cho
các test chạy một cách tự động
4.2.2 Các thành phần quan trọng của JUnit
* Phương thức assertXXX()
i. assertEquals(): So sánh 2 giá trị để kiểm tra bằng nhau. Test sẽ được
chấp nhận nếu các giá trị bằng nhau
ii. assertFalse(): Đánh giá biểu thức luận lý. Test sẽ được chấp nhận nếu
biểu thức sai
iii. assertNotNull(): So sánh tham chiếu của một đốitượng với null. Test
sẽ được chấp nhận nếu tham chiếu đối tượng khác null
iv. assertNotSame(): So sánh địa chỉ vùng nhớ của 2 tham chiếu đối
tượng bằng cáchsử dụng toán tử “==”. Test sẽ được chấp nhận nếu cả
2 đều tham chiếu đến các đốitượng khác nhau
v. assertNull(): So sánh tham chiếu của một đốitượng với giá trị null.
Test sẽ được chấp nhận nếu tham chiếu là null
vi. assertSame(): So sánh địa chỉ vùng nhớ của 2 tham chiếu đốitượng
bằng cách sử dụng toán tử “ ==”. Test sẽ được chấp nhận nếu cả 2 đều
tham chiếu đến cùng một đối tượng
vii. assertTrue(): Đánh giá một biểu thức luận lý. Testsẽ được chấp nhận
nếu biểu thức đúng
viii. fail(): Phương thức này làm cho test hiện hành thất bại, phương thức
này thường được sử dụng khi xử lý các biệt lệ
Tất cả các phương thức của bảng trên đều nhận vào một String không bắt
buộc làm tham số đầu tiên. Khi được xác định, tham số này cung cấp một
thông điệp mô tả test thất bại.
* Phương thức set up và tear down
i. Hai phương thức setUp() và tearDown() là một phần của lớp
junit.framework.TestCase Bằng cách sử dụng các phương thức setUp
và tearDown. Khi sử dụng 2 phương thức setUp() và tearDown() sẽ
giúp chúng ta tránh được việc trùng mã khi nhiều test cùng chia sẻ
nhau ở phần khởi tạo và dọndẹp các biến.
ii. JUnit tuân thủ theo một dãy có thứ tự các sự kiện khi chạy các test.
Đầu tiên, nó tạo ra một thể hiện mới của test caseứng với mỗi phương
thức test. Từ đó, nếu bạn có 5 phương thức test thì JUnit sẽ tạo ra 5
thể hiện của test case. Vì lý do đó, các biến thể hiện không thể được
sử dụng để chia sẻ trạng thái giữa các phương thức test. Sau khi tạo
xong tất cả các đối tượng test case, JUnit tuân theo các bước sau cho
mỗi phương thức test:

38
iii. Gọi phương thức setUp() của test case / Gọi phương thức test / Gọi
phương thức tearDown() của test case
iv. Quá trình này được lặp lại đối với mỗi phương thức test trong test
case.
v. Thông thường bạn có thể bỏ qua phương thức tearDown() vì mỗi unit
test riêng không phải là những tiến trình chạy tốn nhiều thời gian, và
các đốitượng được thu dọn khi JVM thoát. tearDown() có thể được sử
dụng khi test của bạn thực hiện những thao tác như mở kết nối đến cơ
sở dữ liệu hay sử dụng các loại tài nguyên khác của hệ thống và bạn
cần phải dọn dẹp ngay lập tức. Nếu bạn chạy một bộ bao gồm một số
lượng lớn các unit test, thì khi bạn trỏ tham chiếu của các đối tượng
đến null bên trong thân phương thức tearDown() sẽ giúp cho bộ dọn
rác lấy lại bộ nhớ khi các test khác chạy
vi. Đôi khi bạn muốn chạy vài đoạn mã khởi tạo chỉ một lần, sau đó chạy
các phương thức test, và bạn chỉ muốn chạy các đoạnmã dọn dẹp chỉ
sau khi tất cả test kết thúc. Ở phần trên, JUnit gọi phương thức
setUp() trước mỗi test và gọi tearDown() sau khi mỗi test kết thúc, vì
thế để làm được điều như trên, chúng ta sẽ sử dụng lớp
junit.extension.TestSetup để đạt được yêu cầu trên.
* Chạycác test lặp đi lặp lại
i. Trong một vài trường hợp, chúng ta muốn chạy một test nào đó lặp đi
lặp lại nhiều lần để đo hiệu suất hay phân tích các vấn đề trục trặc.
JUnit cung cấp cho chúng ta lớp junit.extension.RepeatedTest để làm
được điều này. Lớp RepeatedTestgiúp chúng ta thực hiện điều này
một cách dễ dàng
ii. public static Test suite() {
//Chạy toàn bộ test suite 10 lần
return new RepeatedTest(new
TestSuite(TestGame.class), 10);
}
iii. Tham số đầu tiên của RepeatedTest là một Testcần chạy, tham số thứ
2 là số lần lặp lại. Vì TestSuite cài đặt interface Test nên chúng ta có
thể lặp lại toàn bộ test như trên
4.2.3 Cách tổ chức chương trình chạy với JUnit
* Tổ chức các test vào các test suite
i. Thông thường JUnit tự động tạo ra các TestSuite ứng với mỗi Test
Case. Tuy nhiên bạn muốn tự tạo các Test Suite của riêng mình bằng

39
cách tổ chức các Test vào Test Suite. JUnit cung cấp lớp
junit.framework.TestSuite hỗ trợ việc tạo các Test Suite
ii. Khi sử dụng giao diện text hay graphic, JUnit sẽ tìm phương thức sau
trong test casecủa bạn
iii. public static Test suite() { … }
iv. Nếu không thấy phương thức trên, JUnit sẽ sử dụng kỹ thuật
reflection để tự động xác định tất cả các phương thức testXXX() trong
test casecủa bạn, rồi thêm chúng vào một test suite. Sau đó nó sẽ chạy
tất cả các test trong suite này
* Test các exception
i. Chúng ta sử dụng cặp từ khóa try/catch để bắt các exception như
mong đợi, chúng ta sẽ gọi phương thức fail() khi exception chúng ta
mong đợi không xảy ra.
ii. Trong ví dụ sau, constructorcủa lớp Person nên tung ra
IllegalArgumentException khi cả 2 tham số của nó đều mang giá trị
null. Test sẽ thất bại nếu nó không tung ra exception.
public void testPassNullsToConstructor() {
try {
Person p = new Person(null, null);
fail("Expected
IllegalArgumentException because both
args are null");
}
catch (IllegalArgumentException expected)
{
//Bỏ qua phần này không xử lý vì có
nghĩa là test được chấp nhận
}
}
iii. Nói chung bạn chỉ nên sử dụng kỹ thuật này khi bạn mong đợi một
exception xảy ra. Đốivới các điều kiện lỗi khác bạn nên để exception
chuyển sang cho JUnit. Khi đó JUnit sẽ bắt lấy và tường trình 1 lỗi
test.
4.3 Load Runner
Về Performance Test(PT): PT là một dạng kiểm thử tự động, để tìm ra điểm
“thắt cổ chai” của phần mềm cần kiểm tra, qua đó giúp cho người làm phần
mềm có thay đổi thích hợp để tăng khả năng thực thi của phần mềm (PM).

40
Bên cạnh đó cũng giúp người kiểm tra biết được những thông số ngưỡng của
phần mềm, đề ra tiêu chuẩn cho những lần kiểm tra sau.
Khi thực hiện PT, người kiểm tra phải đề ra kết quả mong đợi một cáchrõ
ràng. Ví dụ: đối với ứng dụng web, chúng ta cần biết thông số quan trọng là:
số kết nối (session) đồng thời mà server có thể phục vụ, thời gian (bao nhiêu
phút/giây) mà trình duyệt nhận được kết quả từ server....
Khi thực hiện PT người ta thường chọn thời điểm mà chương trình tương đối
ổn định. Thông thường chức năng nằm trong tình huống cần kiểm tra hiệu
năng đã được kiểm tra là chạy đúng. Điều này sẽ giúp cho việc phân tích
đánh giá kết quả của PT dễ dàng và đúng đắn.
Mercury LoadRunner là công cụ kiểm tra tự động thực hiện việc kiểm tra
hiệu năng của phần mềm. Nó cho phép chúng ta tìm ra những lỗi về khả
năng thực thi bằng việc phát hiện nguyên nhân, chỗ làm cho phần mềm chạy
chậm hoặc không đúng yêu cầu. Đây là công cụ mạnh với giải pháp kiểm tra
tải, phát hiện và đưa ra giải pháp cải tiến.
Ứng dụng LoadRunner sẽ giúp giảm thời gian viết test script đến 80%, đó là
nhờ nó cung cấp chức năng tự động phát sinh script mô tả lại các tình huống
muốn kiểm tra.
4.3.2 Đặc điểm
Theo một số quan niệm thì một công cụ PT phải có khả năng thực hiện kiểm
tra chức năng. Điều này mang nghĩa tương đối vì thực tế công cụ PT không
thể thay thế công cụ kiểm tra chức năng và ngược lại. Ví dụ: trong môi
trường web, công cụ kiểm tra chức năng kiểm tra hoạt động của phần mềm ở
cả phía client và server. Còn công cụ PT chỉ kiểm tra ở phía server mà thôi.
LoadRunner có khả năng tạo ra hàng ngàn người dùng ảo thực hiện các giao
dịch cùng một lúc. Sau đó LoadRunner giám sát các thông số xử lý của phần
được kiểm tra. Kết quả thống kê sẽ được lưu lại và cho phép kĩ thuật viên
thực hiện phân tích.
4.3.3 Môi trường hỗ trợ
LoadRunner có khả năng thực hiện PT trên nhiều môi trường khác nhau, cụ
thể những giao thức và công nghệ phổ biến như ERP/CRM, Web,
J2EE/.NET, XML, .NET, Wireless, Streaming Media. LoadRunner hỗ trợ
hơn 60 giao thức và được xem là công cụ có khả năng hỗ trợ tối đa những
công nghệ mới hiện nay.
Bên cạnh đó còn có những môi trường yêu cầu phải mua và cài đặt thêm
thành phần hỗ trợ như: VMWare, Web Forms, Java (SWT, AWT), ActiveX,
Delphi 8 .NET WinForms, WPF from .NET 3.0, JBDC, SIP...

41
4.3.4 Các bước thực hiện
Sau khi cài đặt, LoadRunner sẽ cung cấp sẵn một số ứng dụng cho chúng ta
thử nghiệm. Trong bài viết này chúng ta thực hiện kiểm tra ứng dụng
Mercury Web Tours.
Mở web server tại $Mercury LoadRunner >Samples>Web>Start
Web Server
Mở LoadRunner $menu Start>Programs>Mercury
LoadRunner>LoadRunner.
Chọn Create/Edit Scripts để mở Virtual User Generator tạo script cho người
dùng ảo.
Chọn giao thức để kiểm tra ứng dụng web: chọn New Vuser script, sau đó
chọn Web (HTTP/HTML)
LoadRunner tổ chức các bước thực hiện một cách rõ ràng bên trái màn hình,
rất dễ sử dụng. Sau đây là công việc phải làm trong các bước đó.
i. Recording (Ghi nhận): Cho phép tự động phát sinh script ghi lại thao
tác người dùng lên ứng dụng cần kiểm tra. Cách tổ chức script của
LoadRunner được chia ra thành 3 thành phần chính.
- vuser_init: mỗi người dùng ảo sẽ thực hiện một lần trước khi
chạy PT.
- Run: bao gồm một hoặc nhiều hàm (action), và cho phép
người dùng ảo chạy lặp lại nhiều lần. Dựa trên action chúng ta
có thể tổ chức các nhóm chứa các action khác nhau và theo thứ
tự tùy ý.
- vuser_end: mỗi người dùng ảo thực hiện một lần cuối cùng
khi chạy PT.
ii. Replay (Phát lại):
Đây là bước cho phép chạy thử để kiểm tra script đã chạy đúng yêu
cầu của một người dùng ảo hay chưa, qua đó có sự chỉnh sửa nếu cần.
Bên cạnh đó LoadRunner còn cho phép tổ chức thứ tự, số lần lặp lại
các action hiện đang có bằng cách chọn Open Run-Time Settings, và
thiết lập thời gian tương tác giữa người dùng ảo và web server...
iii. Enhancements (Nâng cao):
Tạo transaction: transaction là một số hành động do chúng ta chọn từ quá
trình tự động phát sinh script. Mục tiêu là giám sát thông số hoạt động của
một số hành động trong transaction đó. Thông số giám sát sẽ được thể hiện
sau khi chúng ta thực hiện kiểm tra PT.
- Tham biến hóa: thay thế các giá trị cố định trong script bằng các biến.

42
- Kiểm tra nội dung: cho phép thêm các điểm kiểm tra nội dung, trong
LoadRunner gọi là content check, có thể hiểu giống như một thuật ngữ khác
đã được đề cập trong bài viết trước là checkpoint.
iv. Prepare ForLoad (Chuẩn bị thực thi):
- Thiết lập sự lặp lại của các action, ở giai đoạn Replay chúng ta cũng có thể
làm điều này.
- Thiết kế tình huống: thiết lập số người dùng ảo tối đa thực hiện cùng một
lúc, thời gian chạy bao lâu, số lượng người dùng ảo tăng như thế nào (Ramp
Up) hoặc giảm như thế nào (Ramp Down).
Ví dụ: Giả lập tổng số người dùng tối đa là 100, bắt đầu là 10 người và cứ 10
phút thì tăng 1 người. Chạy trong thời gian 5 tiếng, sau đó cứ 10 phút thì
giảm 1 người dùng.
- Thực hiện tình huống: thực thi các tình huống kiểm tra, phân tích kết quả
dựa trên các thông số của môi trường kiểm tra, ví dụ: số yêu cầu gửi tới web
server xử lý trong 1 giây, số hồi đáp từ server trong 1 giây, số trang mà
người dùng có thể mở trong 1 giây, ...
v. Finish (Kết thúc):
- Upload script lên Performance Center server, đây là một phần trong việc
thực hiện giải pháp chia sẻ tài nguyên PT qua Internet.
- Quản lý script thông qua việc kết hợp với giải pháp mà Mercury cung cấp
là Quality Center.
4.4 NUnitTest
4.4.1 Khái quát
NUnit (hhtp://www.nunit.org) là khung kiểm tra đơn vị chương trình (như
lớp, hàm hay module) có mã nguồn mở. Được phát triển theo mô hình JUnit
(công cụ kiểm tra nổi tiếng dùng cho Java), nhưng NUnit được viết bằng C#
và khai thác được ưu điểm của các ngôn ngữ .NET.
NUnit cho phép bạn viết hàm kiểm tra lỗi (unit test) theo ngôn ngữ lựa chọn
để kiểm tra một chức năng cụ thể của chương trình. Unit test là cách thức tốt
để kiểm tra hoạt động của đoạn codeviết mới, và cũng là một phương thức
kiểm tra hồi quy ứng dụng. Các unit test có thể lưu lại và chạy lại mỗi khi
bạn sửa đổi code, điều này giúp phát hiện lỗi dễ dàng hơn và đảm bảo phát
triển ứng dụng tốt hơn.

43
NUnit cung cấp khung để viết các unit test, và còn có giao diện đồ họa để
chạy các unit test và xem kết quả. Ví dụ, chúng ta sẽ kiểm tra hoạt động của
lớp Hashtable trong .NET với việc thêm vào và lấy ra 2 đốitượng. Bước đầu
tiên là tham chiếu đến NUnit.Framework để có thể dùng các thuộc tính và
hàm của NUnit; kế tiếp, tạo một lớp và đánh dấu nó với thuộc tính
[TestFixture] để NUnit biết lớp này có hàm kiểm tra.

44
5. Demo JUnit(Java) – NUnit(C#)
5.1 JUnit (trong Java)
Ta tạo một project mới cùng class Calculator và đặt nó trong package
bachkhoa đặt trong package SourcePackage, nó có 2 phương thức là chia()
và giaiThua()như sau
package bachkhoa;
public class Calculator {
public int chia(int a, int b){
try{
return a/b;
}
catch(ArithmeticException ae){
throw ae;
}
}
public int giaiThua(int n){
int re = 1;
for (int i=1;i<=n;i++){
re = re*i;
}
return re;
}
}
Để test unit này (test phương thức chia() và giaiThua()), ta tạo ra một lớp
CalculatorTest trong package bachkhoa trong package Test Packages như
sau
Trước hết là phương thức chia()
/**
* Test of chia method, of class Calculator.
*/
@Test
public void testDevide() {
System.out.println("devide");
try {
int a = 6;
int b = 0;
Calculator instance = new Calculator();
int expResult = 2;

45
int result = instance.chia(a, b);
assertEquals(expResult, result);
// TODO review the generated test code and
remove the default
call to fail.
//fail("The test case is a prototype.");
} catch (ArithmeticException ae) {
assertTrue(true);
}
}
Ở đây, ta truyền vào hàm chia hai đốisố a = 6 vàb = 0 và mongmuốn
hàm sẽ phải trả ra Exception ArithmeticException do ta đặt
assertTrue(true); trong hàm Test. Kết quả là PASS do hàm chia()
đã throw Exception này ra đúng như mong đợi.
Và tiếp theo là test phương thức giaiThua()
/**
* Test of giaithua method, of class Calculator.
*/
@Test
public void testGiaithua() {
System.out.println("giaithua");
int n = 3;
Calculator instance = new Calculator();
int expResult = 6;
int result = instance.giaiThua(n);
assertEquals(expResult, result);
// TODO review the generated test code and
remove the default call to fail.
//fail("The test case is a prototype.");
}
Ở đây, ta truyền vào hàm tính giai thừa của mộtsố với đối số n = 3 và
mongmuốn hàm sẽ phải trả ra kết quả6 do ta đặt int expResult =
6; trong hàm Test. Kết quả là PASS do hàm giaiThua() đãtrả đúng kết quả
như mong đợi.
Kết quả được hiển thị như sau

46
Kết quả pass 100% test
5.2 NUnit (trong C#)
Ta tạo một project mới cùng class Program và đặt nó trong namespace
TestDemo, nó có một phương thức là chia() như sau
namespace TestDemo
{
class Program
{
public static void Main()
{
}
private int chia(int a, int b)
{
return a / b;
}
}
}
Ta sẽ tạo một Unit Testđể kiểm thử hàm chia() trong lớp Program nói trên
Ta sẽ tạo hai test case :
1. Một test case bình thường truyền vào tham số a = 6 ; b = 2 và mong
muốn nhận được kết quả trả về là 3
2. Một test case truyền vào a = 4 và b = 0 và mong muốn phải trả ra kết
quả là -1; chứ nếu bung ra Exception (cụ thể ở đây là
DivideByZeroException – do chia cho 0 – chương trình bị crash)
chứng tỏ là lập trình viên chưa xử lý trường hợp này
/// <summary>
///A test for chia

47
///</summary>
[TestMethod()]
[DeploymentItem("TestDemo.exe")]
public void chiaTest()
{
Program_Accessor target = new Program_Accessor();
// TODO: Initialize to an appropriate value
int a = 6; // TODO: Initialize to an appropriate value
int b = 2; // TODO: Initialize to an appropriate value
int expected = 3; // TODO: Initialize to an appropriate
value
int actual;
actual = target.chia(a, b);
Assert.AreEqual(expected, actual);
}
/// <summary>
///A test for chia
///</summary>
[TestMethod()]
[DeploymentItem("TestDemo.exe")]
public void chiaTest1()
{
try
{
Program_Accessor target = new Program_Accessor();
// TODO: Initialize to an appropriate value
int a = 6; // TODO: Initialize to an appropriate
value
int b = 0; // TODO: Initialize to an appropriate
value
int actual;
actual = target.chia(a, b);
if (actual == -1)
{
Assert.IsFalse(false);
}
}
catch (DivideByZeroException ex)
{
Assert.IsFalse(true);
}
}
Và nhận được kết quả

48
Chi tiết của Test Case 1:
Chi tiết của Test Case 2:
Ta có thể thấy Test 1 lấy 6 / 2 = 3 là chính xác nhưng Test 2 đã fail do bị
bung ra DivideByZeroException.

49
6. Tài Liệu Tham Khảo
 Slide bài giảng của cô Vũ Thị Hương Giang
 The Art Of Software Testing – Second Edition - Glenford J. Myers
 McGraw Hill - Software Engineering - A Practitioner's Approach -
Pressman (5th Ed)(2001)
 Sybex - Effective Software Test Automation
 Happy About® Global Software TestAutomation - Hung Q. Nguyen,
Michael Hackett, Brent K. Whitlock
 http://en.wikipedia.org/wiki/Unit_testing
 http://en.wikipedia.org/wiki/Software_testing
 http://msdn.microsoft.com/en-us/library/ms243147(v=vs.80).aspx
 http://students.depaul.edu/~slouie/QTUsersGuide.pdf

Tìm Hiểu Các Kỹ Thuật Kiểm Thử Phần Mềm và Một Số Ứng Dụng Trong Thực Tế

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (13)

Ähnlich wie Tìm Hiểu Các Kỹ Thuật Kiểm Thử Phần Mềm và Một Số Ứng Dụng Trong Thực Tế

Ähnlich wie Tìm Hiểu Các Kỹ Thuật Kiểm Thử Phần Mềm và Một Số Ứng Dụng Trong Thực Tế (20)

Mehr von Nguyễn Anh

Mehr von Nguyễn Anh (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Tìm Hiểu Các Kỹ Thuật Kiểm Thử Phần Mềm và Một Số Ứng Dụng Trong Thực Tế