Nghiên cứu kỹ thuật kiểm thử phần mềm và ứng dụng trên môi trường DOT NET

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ





VŨ MINH HIẾU




NGHIÊN CỨU KỸ THUẬT KIỂM THỬ PHẦN MỀM VÀ ỨNG DỤNG
TRÊN MÔI TRƯỜNG DOT NET



Ngành: Công nghệ Thông tin
Chuyên ngành: Công nghệ Phần mềm
Mã số: 60.48.10




LUẬN VĂN THẠC SĨ

Người hướng dẫn khoa học: PGS.TS. Đặng Văn Đức










Hà Nội - 2009
1

LỜI CẢM ƠN
Lời đầu tiên, tôi xin chân thành cảm ơn PGS.TS Đặng Văn Đức, Viện công nghệ
thông tin, ngƣời đã định hƣớng đề tài nghiên cứu và tận tình hƣớng dẫn cho tôi hoàn
thành luận văn cao học này.
Tôi xin gửi lời cảm ơn chân thành tới Phòng Đào tạo sau đại học & NCKH, các
thầy cô giáo trong Khoa Công nghệ - Trƣờng Đại Học Công Nghệ - Đại Học Quốc Gia
Hà Nội đã giảng dạy, truyền đạt và tạo điều kiện học tập tốt nhất cho tôi suốt quá trình
học cao học cũng nhƣ thời gian thực hiện luận văn cao học.


Hà Nội, ngày 18 tháng 11 năm 2009



Vũ Minh Hiếu

2

LỜI CAM ĐOAN
Tôi xin cam đoan kết quả đạt đƣợc trong luận văn là sản phẩm của riêng
cá nhân, không sao chép lại của ngƣời khác. Trong toàn bộ nội dung của luận văn,
những điều đƣợc trình bày hoặc là của cá nhân hoặc đƣợc tổng hợp từ nhiều nguồn tài
liệu. Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và đƣợc trích dẫn hợp pháp.
Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định
cho lời cam đoan của mình.

Hà Nội, ngày 18 tháng 11 năm 2008




Vũ Minh Hiếu
3

MỤC LỤC
LỜI CẢM ƠN 1
LỜI CAM ĐOAN 2
MỤC LỤC 3
BẢNG CÁC TỪ VIẾT TẮT, KÝ HIỆU 6
THÔNG TIN HÌNH VẼ 8
THÔNG TIN BẢNG 9
MỞ ĐẦU 10
Đặt vấn đề 10
Nội dung của đề tài 12
Cấu trúc luận văn 12

CHƢƠNG 1: KHÁI QUÁT VỀ KIỂM THỬ PHẦN MỀM 13
1.1 Tổng quan 13
1.2 Vai trò của kiểm thử phần mềm 13
1.3 Các công cụ kiểm thử phổ biến hiện nay 16
1.4 Những lợi ích của kiểm thử tự động 22
1.4.1 Áp dụng cho mô hình phát triển phần mềm XP 24
1.4.2 Đối với các kiểm thử viên 25
1.5 Phƣơng pháp để kiểm thử tự động 26
1.6 Kiểm thử phần mềm và các ngôn ngữ lập trình 28
1.7 Kịch bản kiểm thử 31
1.8 Kết chƣơng 33
CHƢƠNG 2: PHƢƠNG PHÁP VÀ CÁC THỂ LOẠI KIỂM THỬ PHẦN MỀM 34
2.1 Tổng quan 34
2.2 Các phƣơng pháp kiểm thử 35
2.2.1 Kiểm thử tĩnh – Static testing 35
2.2.2 Kiểm thử động – Dynamic testing 35
4

2.3 Các chiến lƣợc kiểm thử 35
2.3.1 Kiểm thử hộp đen – Black box testing 35
2.3.2 Kiểm thử hộp trắng – White box testing 37
2.3.3 Kiểm thử hộp xám – Gray box testing 37
2.4 Các cấp độ kiểm thử phần mềm 38
2.4.1 Kiểm thử mức đơn vị - Unit Test 39
2.4.2 Kiểm thử tích hợp - Integration Test 40
2.4.3 Kiểm thử mức hệ thống - System testing 42
2.4.4 Kiểm thử chấp nhận sản phẩm - Acceptance Test 44
2.4.5 Kiểm thử hồi quy - Regression Test 44
2.4.6 Kiểm thử tính đúng – Correctness testing: 45
2.5 Các phƣơng pháp kiểm thử con ngƣời 45

2.5.1 Tổng duyệt – Walkthrough 46
2.5.2 Thanh tra mã nguồn – Code Inspection 46
2.6 Kết chƣơng 47
CHƢƠNG 3: NGHIÊN CỨU XÂY DỰNG CÔNG CỤ KIỂM THỬ PHẦN MỀM TỰ
ĐỘNG TRÊN MÔI TRƢỜNG .NET 48
3.1 Đặt vấn đề 48
3.2 Đặc điểm của môi trƣờng DOT NET và kiểm thử tự động 49
3.2.1 Sử dụng C# trong kiểm thử tự động 53
3.2.2 .NET Reflection 58
3.2.3 Spreadsheets và XML 61
3.2.4 Không gian tên .NET CodeDom 63
3.3 Phân tích và thiết kế hệ thống 66
3.3.1 Mô hình nghiệp vụ và các yêu cầu của hệ thống 66
3.3.2 Phân tích các trƣờng hợp sử dụng 68
5

3.3.3 Biểu đồ trình tự 69
3.3.4 Biểu đồ trạng thái 70
3.3.5 Biểu đồ hợp tác 71
3.3.6 Biểu đồ lớp 71
3.3.7 Mô hình dữ liệu 72
3.4 Chạy thử chƣơng trình 73
 Màn hình chính 73
 Lựa chọn hình thức kiểm thử đơn vị (Unit Test) 73
 Lựa chọn các đơn vị trong danh sách để kiểm thử 74
 File chứa dữ liệu kiểm thử 75
 Sinh kịch bản kiểm thử 75
 Thực thi kịch bản kiểm thử 76
3.5 Thử nghiệm và đánh giá 78
TÀI LIỆU THAM KHẢO 81

6

BẢNG CÁC TỪ VIẾT TẮT, KÝ HIỆU
Từ viết tắt
Đầy đủ
Tiếng Việt
Assembly



CRL
CNTT
CNPM
CSDL
DLL
EXE


IDE
GUI

KH
KTV
KTTĐ
Module



MSIL

XML

PM
PTPM




Common Language Runtime



Dynamic Link Library
EXE


Intergrated Development
Graphical user interface
Environment







Microsoft Intermediate
Language
eXtensible Markup
Language

Trong môi trƣờng .Net, Một gói kết
hợp Assembly là sự kết hợp của một
hoặc nhiều module, hoặc file (dll, exe,
html) cần để ứng dụng hoạt động.
Ngôn ngữ thời gian thực
Công nghệ thông tin
Công nghệ phần mềm
Cơ sở dữ liệu
Thƣ viện liên kết động
Định dạng file thực thi của DOS,
OpenVMS, Microsoft Windows,
Symbian, và hệ điều hành OS/2
Môi trƣờng phát triển tích hợp
Giao diện ngƣời dùng đồ họa

Khách hàng
Kiểm thử viên
Kiểm thử tự động
Mỗi một module là một file có thể
thực thi. Mỗi module có thể là một thƣ
viện động (.dll) hoặc là một file thực
thi (.exe).
Ngôn ngữ thông dịch của .NET

Ngôn ngữ Đánh dấu Mở rộng

Phần mềm
Phát triển phần mềm

7

XP
QTP

JVM
Extreme Programming
QuickTest Professional

Java Virtual Machine
Lập trình cực đoan
Công cụ kiểm thử phần mềm do hãng
Mecury cung cấp
Máy ảo Java

8

THÔNG TIN HÌNH VẼ
Hình vẽ
Trang
Hình 1.1: Mô hình tổ chức Visual Studio Team System 2008 Team
Foundation Server
Hình 1.2: Giao diện QuickTest Professional
Hình 1.3: Logo JMeter
Hình 1.4: 6 bƣớc của kiểm thử phần mềm tự động
Hình 2.1: Mối tƣơng quan giữa phát triển và kiểm thử phần mềm
Hình 3.1: Mô hình quá trình xử lý tách thông tin
Hình 3.2: Mô hình xử lý sinh kịch bản kiểm thử
Hình 3.3: Mô hình nghiệp vụ
Hình 3.4: Ca sử dụng mức gộp

Hình 3.5: Trƣờng hợp sử dụng của công cụ Unit Test
Hình 3.6: Biểu đồ trình tự
Hình 3.7: Biểu đồ trạng thái
Hình 3.8: Biểu đồ hợp tác
Hình 3.9: Biểu đồ lớp
Hình 3.10: Cửa sổ giao diện chính
Hình 3.11: Cửa sổ chọn file phân tích
Hình 3.12: Cửa sổ chọn thuộc tính kiểm thử
Hình 3.13: File dữ liệu phân tích thuộc tính
Hình 3.14: Cửa sổ tạo file kịch bản kiểm thử
Hình 3.15: Cửa sổ thực hiện kiểm thử
Hình 3.16: File thông tin kết quả kiểm thử
17

18
20
27
39
49
49
68
68
69
70
71
71
72
73
74
74

75
76
77
77

9

THÔNG TIN BẢNG
Bảng
Trang
Bảng 3.1: Không gian tên .NET System
Bảng 3.2: Mã nguồn để kiểm thử phƣơng thức objAdvancedCalc.Square()
Bảng 3.3: Mã nguồn kiểm thử phƣơng thức objAdvancedCalc.SimpleCalc()
Bảng 3.4: Mã nguồn kiểm thử phƣơng thức objAdvancedCalc.Sum()
Bảng 3.5: Mã nguồn kiểm thử phƣơng thức objAdvancedCalc.GetType()
Bảng 3.6: Một số lớp (class) quan trọng trong không gian tên
System.Reflection
Bảng 3.7: Truy vấn thể loại System.Reflection.Assembly theo tên
Bảng 3.8: Truy vấn thông tin thể loại theo thể hiện của đối tƣợng
Bảng 3.9: Xác định thông tin thể loại của một tiến trình đang chạy
Bảng 3.10: Làm việc với Excel
Bảng 3.11: Các kiểu cung cấp bởi CodeDom để xây dựng không gian tên
Bảng 3.12: Cấu trúc của Test Script đƣợc sinh bởi không gian tên CodeDom
51
55
55
56
57
58

60
60
61
62
64
65
10

MỞ ĐẦU
Đặt vấn đề
Công nghệ thông tin là một trong những thuật ngữ đƣợc nhắc đến nhiều nhất hiện
nay, nó xuất hiện trên các mặt báo, các phƣơng tiện truyền thông, trên mạng Internet
cho tới những tài liệu cũng nhƣ báo cáo chuyên ngành. Điều này cũng dễ hiểu vì công
nghệ thông tin đƣợc coi là một cuộc cách mạng cho sự phát triển của xã hội loài ngƣời.
Kể từ năm 1981 khi chiếc máy vi tính đầu tiên của IBM đƣợc giới thiệu trên thị trƣờng
đánh dấu một mốc quan trọng cho sự tiến bộ của khoa học kỹ thuật. Cho tới thời điểm
hiện tại, trải qua một khoảng thời gian rất ngắn so với chiều dài lịch sử của xã hội loài
ngƣời, tuy nhiên công nghệ thông tin đã phát triển rất nhanh (còn đƣợc diễn tả bằng
cụm từ: “bùng nổ”). Công nghệ thông tin đã đƣợc ứng dụng trong hầu hết các lĩnh vực
của xã hội, và thực tế đã chứng minh đƣợc tầm quan trọng của nó.
Trong hai thập kỷ qua phần mềm đã trở thành một thành phần của hầu hết các
doanh nghiệp. Hầu nhƣ tất cả các doanh nghiệp hoạt động trong mọi lĩnh vực tại Việt
Nam cũng nhƣ trên toàn Thế Giới đều sử dụng phần mềm. Phần mềm đƣợc áp dụng
trong việc hỗ trợ phát triển, sản xuất, tiếp thị, và hỗ trợ cho các sản phẩm - dịch vụ của
doanh nghiệp.
Thúc đẩy sự phát triển của công nghệ thông tin luôn là chính sách đƣợc ƣu tiên
hàng đầu của các quốc gia nhằm làm tiền đề cho sự phát triển của khoa học kỹ thuật và
kinh tế - xã hội.
Công nghệ thông tin là ngành ứng dụng công nghệ vào quản lý và xử lý thông
tin, đặc biệt trong các cơ quan, doanh nghiệp. Ở Việt Nam thì khái niệm công nghệ

thông tin đƣợc hiểu theo nghĩa sau: “Công nghệ thông tin là tập hợp các phƣơng pháp
khoa học, các phƣơng tiện và công cụ kỹ thuật hiện đại - chủ yếu là kỹ thuật máy tính
và viễn thông - nhằm tổ chức khai thác và sử dụng có hiệu quả các nguồn tài nguyên
thông tin rất phong phú và tiềm năng trong mọi lĩnh vực hoạt động của con ngƣời và
xã hội”.
Công nghệ thông tin là sự kết hợp của hạ tầng phần cứng và nền tảng phần mềm.
Hạ tầng phần cứng sẽ ngày càng mạnh mẽ là tiền đề cho phép phần mềm cũng ngày
11

càng lớn và phức tạp hơn. Chính vì lý do này mà Công nghệ phần mềm (quy trình phát
triển phần mềm) đã đƣợc chú tâm bàn thảo từ rất sớm nhằm tìm ra những phƣơng pháp
để phát triển phần mềm thuận tiện có chất lƣợng cao đáp ứng tốt nhu cầu ngày càng đa
dạng và phức tạp.
Hầu hết các quy trình phát triển phần mềm đều trải qua các bƣớc từ xác định yêu
cầu, phân tích, xây dựng, kiểm thử, cho tới triển khai và bảo trì. Trong đó kiểm thử
phần mềm là một công việc khá phức tạp, tốn nhiều công sức và cũng là điều kiện tiên
quyết cho một sản phẩm phần mềm có chất lƣợng tốt.
Bất kỳ sản phẩm phần mềm nào cho dù đã áp dụng kỹ thuật kiểm thử tiên tiến
nhất hiện nay đều có phát sinh lỗi. Một số lỗi đã đƣợc phát hiện và chỉnh sửa trong
thời gian lập trình. Một số khác đƣợc tìm ra và chỉnh sửa trong các hình thức kiểm thử
(vd: kiểm thử module). Các doanh nghiệp phần mềm đều nhận ra một thực tế là có
nhiều lỗi phần mềm vẫn chƣa đƣợc phát hiện và một số sẽ đƣợc sửa sau đó thông qua
những bản vá lỗi hoặc nâng cấp. Kiểm thử là điều kiện tiên quyết cho một phần mềm
hoàn thiện, tuy nhiên với kỹ thuật kiểm thử hiện nay việc đảm bảo cho một phần mềm
hoàn hảo (không có lỗi) là một việc rất khó khăn, tốn thời gian, và tƣởng chừng nhƣ
không thể. Theo thống kê của Tassey năm 2002, thì lỗi trong những phần mềm đóng
gói gây thiệt hại cho nền kinh tế Mỹ khoảng 59,5 tỷ USD [9].
Kiểm thử chiếm khoảng 25% tới 50% tổng chi phí phát triển một phần mềm. Bộ
phận kiểm thử thƣờng gồm các kỹ sƣ với vai trò là kiểm thử viên, ngƣời sử dụng công
cụ, và những ngƣời phát triển công cụ kiểm thử. Ngân sách và con ngƣời đều đóng vai

trò quan trọng vì một sản phẩm trong quá trình xây dựng phải đƣợc kiểm thử một cách
tốt nhất và hiệu quả nhất.
Vào năm 2008, tổng doanh thu của phần mềm Việt Nam đạt trên 500 triệu USD
(tổng doanh thu trên toàn thế giới vào khoảng 519 tỷ USD - theo:
). Số lƣợng các kỹ sƣ và lập trình viên tại Việt Nam năm 2008
vào khoảng 13.500 ngƣời. Những con số trên dựa trên tổng kết của Hiệp hội Doanh
nghiệp phần mềm Việt Nam (vinasa: ). Giảm chi phí phát
triển phần mềm và nâng cao chất lƣợng phần mềm là mục tiêu quan trọng của các
ngành công nghiệp phần mềm Việt Nam. Một nghiên cứu tƣơng tự cũng cho biết rằng
12

các ngành công nghiệp phần mềm bị thiệt hại về kinh tế, vì không có đủ cơ sở hạ tầng
cho việc kiểm thử phần mềm.
Hiện nay có khá nhiều công cụ kiểm thử đƣợc giới thiệu trên thị trƣờng. Tuy
nhiên, vẫn còn phải xem xét về khả năng đáp ứng đƣợc nhu cầu về đảm bảo chất lƣợng
phần mềm xét trên nhiều khía cạnh khác nhau. Các công cụ kiểm thử có thể kiểm thử
phần mềm với một số cấp độ tự động, qua đó những kiểm thử viên có thể giành thời
gian để xem xét và giải quyết những vấn đề thuộc phạm vi có nhiều rủi ro hơn, tuy
nhiên, tính tự động của các công cụ mới chỉ dừng ở các kỹ thuật đơn giản và những
kịch bản kiểm thử bao gồm chuỗi sự kiện nhấn chuột hoặc bàn phím. Kiểm thử viên
mong đợi các công cụ kiểm thử hiệu quả và linh hoạt hơn với các tính năng tự động
cao để có thể theo kịp sự phát triển rất nhanh trong công nghệ phần mềm hiện nay.
Mục tiêu của Luận văn là nghiên cứu kỹ thuật phát triển một công cụ kiểm thử tự
động, có thể kiểm thử một sản phẩm phần mềm phức tạp một cách hiệu quả với yêu
cầu tác động của con ngƣời là ít nhất.
Nội dung của đề tài
Xuất phát từ việc phân tích và mục tiêu nêu trên, nội dung của đề tài luận văn sẽ
bao gồm những vấn đề chính sau:
- Nghiên cứu, tìm hiểu các vấn đề tổng quan về kiểm thử phần mềm.
- Nghiên cứu kiến trúc và các thể loại kiểm thử phần mềm.

- Nghiên cứu xây dựng công cụ kiểm thử phần mềm tự động trên môi trƣờng Dot
Net và thử nghiệm.
Cấu trúc luận văn
Luận văn sẽ đƣợc chia thành 3 chƣơng chính dựa vào nội dung nêu trên:
- Chƣơng 1: Khái quát về kiểm thử phần mềm.
- Chƣơng 2: Phƣơng pháp và các thể loại kiểm thử phần mềm.
- Chƣơng 3: Nghiên cứu xây dựng công cụ kiểm thử phần mềm tự động trên môi
trƣờng .NET.
13

CHƢƠNG 1: KHÁI QUÁT VỀ KIỂM THỬ PHẦN MỀM
1.1 Tổng quan
Kiểm thử phần mềm là một trong những khâu quan trọng của quy trình phát triển
phần mềm nhằm kiểm tra xem phần mềm làm ra có những lỗi gì cần khắc phục. Kiểm
thử không thể chứng minh đƣợc phần mềm là hết lỗi mà nó chỉ giúp cho ngƣời viết mã
nguồn tìm ra và có biện pháp khắc phục càng nhiều lỗi càng tốt.
Bản chất của kiểm thử phần mềm là các cách thức làm việc với máy tính và
chƣơng trình, tuy nhiên với những phần mềm lớn, việc kiểm thử cũng yêu cầu có sự
phối hợp của nhiều nhóm chuyên môn phụ trách các thành phần riêng biệt, cho nên
kiểm thử cũng cần các kĩ năng của con ngƣời.
Để thực hiện tốt công việc kiểm thử, ngoài nắm vững các kĩ thuật kiểm thử điển
hình, kiểm thử viên cũng cần xây dựng kế hoạch kiểm thử, chuẩn bị dữ liệu kiểm thử,
tiến hành kiểm thử, viết báo cáo về kết quả kiểm thử, và cần biết quản lí toàn bộ công
việc kiểm thử.
Kiểm thử cần đƣợc nhìn theo nhiều góc độ khác nhau liên quan tới phần mềm:
kiểm thử chức năng, kiểm thử hiệu năng, cấu hình, an ninh và liên quan tới qui trình
kiểm thử: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử chấp nhận;
đồng thời phải thực hiện quản lí toàn bộ quá trình kiểm thử: ghi lại hoàn cảnh lỗi, việc
sửa chữa, kiểm thử rà lại
1.2 Vai trò của kiểm thử phần mềm

Các lỗi trong phần mềm không chỉ làm phiền phức và bực mình cho ngƣời dùng
mà chúng còn gây tổn thất rất lớn cho nền kinh tế. Đơn cử hàng năm nền kinh tế Mỹ
thiệt hại khoảng 59,5 tỷ USD do lỗi phần mềm gây ra (thông số đƣợc công bố bởi Viện
Công nghệ và Tiêu chuẩn quốc gia (NIST) thuộc Bộ Thƣơng mại Mỹ).
Theo Giám đốc Arden Bement của NIST, hiện nay mọi ngành ở Mỹ gần nhƣ đều
phụ thuộc vào phần mềm để phát triển, từ khâu sản xuất đến khâu phân phối và hỗ trợ
khách hàng. Bởi thế, các lỗi kỹ thuật phần mềm là vô cùng nguy hiểm.
14

Những ngƣời sử dụng phần mềm chịu thiệt hại một nửa và nửa còn lại dành cho
các nhà phát triển và kinh doanh phần mềm. Nghiên cứu cũng cho thấy, việc kiểm thử
để phát hiện và loại bỏ những khiếm khuyết ngay từ ban đầu có thể giảm mức thiệt hại
khoảng 22,2 tỷ USD cho Mỹ trong vòng 1 năm.
Hiện nay, có hơn một nửa số lỗi không đƣợc phát hiện cho đến khi phần mềm đã
đƣợc tung ra thị trƣờng. Chính vì lý do này mà Viện Hàn lâm Khoa học Mỹ đã đề nghị
các nhà lập pháp thông qua điều luật yêu cầu những hãng sản xuất phần mềm phải có
trách nhiệm về vấn đề bảo mật và lỗi phần mềm.
Theo các số liệu của tạp chí SoftwareMag (softwaremag.com) năm 2007 tổng
doanh thu của CNPM trên toàn Thế Giới là 451.8 tỷ USD và tăng 14,7% so với năm
2006. Bên cạnh sự phát triển mạnh mẽ của nghành công nghiệp phần mềm thì những
lỗi – khiếm khuyết của phần mềm cũng xảy ra ngày càng thƣờng xuyên, dẫn tới những
tổn thất do nó gây ra cũng ngày càng nặng nề hơn. Dƣới đây là một vài ví dụ điển hình
về sự tổn thất đó.
Một trong những lỗi phần mềm điển hình về mức độ thiệt hại là vào tháng 4 năm
1999, một lỗi phần mềm đã gây ra lỗi hệ thống phóng tên lửa Quân sự của Mỹ làm
thiệt hại 1.2 tỉ USD. Đây có lẽ là một lỗi phần mềm gây thiệt hại kinh tế lớn nhất trong
lịch sử công nghiệp phần mềm. Chính điều này đã thúc đẩy một cuộc tổng điều tra
trong ngành quân sự và nền công nghiệp của Mỹ về vấn đề tích hợp phần mềm và quy
trình kiểm thử .
Một ví dụ điển hình khác cũng hay đƣợc nhắc tới là tai nạn khi phóng Vệ tinh

thăm dò thời tiết Sao Hỏa của NASA vào tháng 10 năm 1999. Nguyên nhân của sự
việc là do trục trặc trong một bộ phận của phần mềm ở chức năng chuyển đổi chuẩn
độ đo của Anh sang chuẩn độ đo mét. Năm 2002, ngƣời ta đã phát triển một module
dành cho việc kiểm thử dụng cụ Quang học nhằm đảm bảo không có việc lẫn lộn giữa
các phép đo. Nếu Vệ tinh thăm dò thời tiết của Sao Hỏa đƣợc trang bị module này thì
đã không xảy ra tai nạn đáng tiếc trên đây.
Đảm bảo chất lƣợng phần mềm cần đƣợc quan tâm một cách đúng mức, và đòi
hỏi những ngƣời liên quan có kiến thức và đánh giá đúng về vai trò của kiểm thử phần
mềm, gồm: các quản trị viên cao cấp, quản lý dự án, nhân viên phát triển phần mềm,
15

nhân viên kiểm thử phần mềm và ngƣời dùng cuối. Khi bắt đầu một dự án dựa theo
các mô hình phát triển phần mềm, những ngƣời dùng cuối, lập trình viên, kiểm thử
viên, và quản trị viên cao cấp đều phải nắm đƣợc yêu cầu phần mềm, các đặc tả phần
mềm và các chiến lƣợc kiểm thử.
Trong hầu hết các mô hình phát triển phần mềm thì kiểm thử đƣợc lên kế hoạch
ngay từ thời điểm bắt đầu dự án và đƣợc thực thi song song với vòng đời phát triển của
phần mềm. Chúng ta sẽ không thể kiểm thử một sản phẩm nếu không có hiểu biết chi
tiết về nó. Kiểm thử một sản phẩm đang trong giai đoạn đƣợc xây dựng sẽ luôn là một
trải nghiệm bổ ích cho các kiểm thử viên. Thời gian và nỗ lực của kiểm thử viên phụ
thuộc vào độ phức tạp của một sản phẩm cũng nhƣ kinh nghiệm của anh ta trong lĩnh
vực kiểm thử phần mềm.
Sẽ rất hữu ích nếu ta sử dụng các công cụ kiểm thử tự động, điều này sẽ hạn chế
bớt việc các kiểm thử viên phải giành quá nhiêu thời gian cho công việc nghiên cứu
một sản phẩm mới. Qua đó họ có thể giành thời gian nhiều hơn tập trung cho những
vấn đề, những yếu tố phức tạp và rủi ro cao trong khi vận hành phần mềm.
Kiểm thử phần mềm là một tiến trình thử thách, trải nghiệm một ứng dụng để tìm
ra lỗi và để xác định rằng chúng đáp ứng đƣợc những yêu cầu nhất định. Trong vòng
đời phát triển phần mềm, các lập trình viên và kiểm thử viên cùng làm việc để tìm ra
lỗi và đảm bảo cho chất lƣợng của sản phẩm. Các sản phẩm phần mềm đã đƣợc

chuyển giao sẽ phải bao hàm tất cả các chức năng đƣợc yêu cầu và phải tƣơng thích
với hạ tầng phần cứng của khách hàng.
Trong một thời gian dài, kiểm thử phần mềm đã đƣợc thực hiện một cách thủ
công; có nghĩa là những kiểm thử viên chạy ứng dụng dựa trên những tiến trình đã
đƣợc định sẵn. Kể từ thời điểm ban đầu của nền công nghiệp phần mềm, các kiểm thử
viên đã tạo ra những tiến trình kiểm thử tự động khá hiệu quả. Nhiều công ty phần
mềm danh tiếng đã tạo ra những công cụ kiểm thử phần mềm mà hiện nay đang đƣợc
chào bán rộng rãi trên thị trƣờng. Ngày nay, có nhiều công cụ kiểm thử trên thị trƣờng
đã đƣợc dùng để tìm ra lỗi để có biện pháp chỉnh sửa kịp thời trƣớc khi chuyển giao.
Nhƣ đã đề cập ở trên, những công cụ này thực thi một số tác vụ một cách tự động
16

(thực hiện một vài kế hoạch và sinh ra kịch bản kiểm thử), tuy nhiên nó vẫn tồn tại
một số khuyết điểm sau:
 Các kịch bản kiểm thử, tự thân chúng cũng cần đƣợc kiểm thử.
 Không thể thực hiện tất cả các tiến trình kiểm thử một cách độc lập.
 Chúng thực thi các tiến trình có thể không thống nhất hoàn toàn với thiết
kế phần mềm của tổ chức.
 Một vài tiến trình đƣợc phân tách từ việc tự sinh kịch bản kiểm thử.
Trong hầu hết các trƣờng hợp, tạo lập hoặc ghi lại một kịch bản kiểm thử cho
mỗi thành phần của một assembly là một công việc phức tạp mà các kiểm thử viên
phải thực hiện. Tạo và lập tài liệu cho dữ liệu kiểm thử với các công cụ hiện tại đều
hoàn toàn sử dụng sức ngƣời. Do vậy, khả năng tự động của những công cụ kiểm thử
sẽ bị hạn chế.
Nội dung của luận văn là nghiên cứu để phát triển một công cụ kiểm thử phần
mềm sao cho kiểm thử viên không cần viết các kịch bản kiểm thử bằng tay hoặc phải
ghi lại các kịch bản kiểm thử một cách thủ công. Tiến trình kiểm thử phần mềm sẽ
đƣợc thực thi với yêu cầu tƣơng tác trực tiếp từ con ngƣời là ít nhất. Công cụ đƣợc
thiết kế để giảm bớt và sát với yêu cầu của hầu hết các sản phẩm phần mềm. Đồng thời
đây cũng là cách thức để tạo ra các module có thể sử dụng lại để kiểm thử nhiều mã

nguồn khác nhau.
1.3 Các công cụ kiểm thử phổ biến hiện nay
Trên thị trƣờng hiện nay có nhiều công cụ kiểm thử phần mềm. Với các nhà cung
cấp nhƣ: Rational Software của IBM, Mercury Interactives, Segue Software. Hiện có
nhiều nhà cung cấp khác và cũng có một số công cụ kiểm thử nguồn mở nhƣ Ant,
JUnit, và JProbe… Sau đây là một số công cụ kiểm thử phần mềm đƣợc sử dụng phổ
biến hiện nay:
 Visual Studio Team System Test Edition
17


Hình 1.1: Mô hình tổ chức Visual Studio Team System 2008 Team Foundation Server
Visual Studio Team System Test Edition bao gồm một bộ công cụ thử nghiệm đã
đƣợc tích hợp chặt chẽ với Visual Studio. Nó không chỉ làm việc trong khuôn khổ của
nền tảng kiểm thử, mà còn tham gia vào một nền tảng lớn hơn tham gia vào các khâu
khác trong toàn bộ vòng đời của phần mềm.
Test Edition cho phép ta tạo, quản lý, chỉnh sửa và chạy công việc kiểm thử,
đồng thời cũng nhận đƣợc và lƣu trữ kết quả kiểm thử. Visual Studio tích hợp một vài
loại thử nghiệm bao gồm: kiểm thử đơn vị (Unit Test), kiểm thử web (Web Test), kiểm
thử chịu tải (Load Test), và các kiểm thử thủ công.
Thực hiện kiểm thử bằng cách sử dụng môi trƣờng phát triển tích hợp của Visual
Studio (IDE Visual Studio). Ngoài ra, có thể chạy các nhóm thử nghiệm hoặc kiểm tra
bất kỳ đơn vị thử nghiệm độc lập nào khác bằng cách sử dụng dòng lệnh (command
line).
Do các công cụ thử nghiệm đƣợc tích hợp với các thành phần khác của Visual
Studio Team System, nên kiểm thử viên có thể lƣu trữ kết quả vào cơ sở dữ liệu, tạo ra
các hình thức báo cáo khác nhau, so sánh các loại dữ liệu, và xem có bao nhiêu lỗi, là
những lỗi nào đã đƣợc tìm thấy bởi công cụ kiểm thử.
Đây quả là một công cụ mạnh mẽ mà Microsoft trang bị cho bộ sản phẩm Visual
Studio của mình. Với lợi thế là tích hợp chặt chẽ vào môi trƣờng phát triển phần mềm,

công cụ sẽ giảm bớt đƣợc nhiều công sức trong quá trình thực hiện các thao tác kiểm
18

thử, đồng thời việc quản lý nó cũng thống nhất trong suốt quá trình phát triển phần
mềm. Tuy nhiên để sở hữu đƣợc bộ công cụ này thì chúng ta cũng phải bỏ ra một
khoản chi phí khá lớn, vào khoảng 5.200 USD. Đồng thời chúng ta cũng phải trang bị
nền tảng Visual Studio Team System 2008 Team Foundation Server (mức giá tham
khảo: 2.500 USD) để có thể tích hợp bộ công cụ này.
 QuickTest Professional

Hình 1.2: Giao diện QuickTest Professional
QuickTest Professional (QTP) với phiên bản mới nhất 9.5 của hãng Mercury khá
tốt và mạnh, bao gồm nhiều chức năng điển hình của một công cụ kiểm thử tự động.
QTP là công cụ 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 tạo kịch bản kiểm thử (lập trình trong
kiểm thử tự động) hiện đại, cho phép kiểm thử viên bổ sung Test Case bằ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ứ kịch bản nào. 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 kịch bản vẫn có thể thực hiện đƣợc.
QTP giúp chúng ta kiểm thử 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
19

chƣơng trình thông dụng nhƣ: Ứng dụng Windows; Ứng dụng web theo chuẩn HTML,
XML; Ngôn ngữ lập trình C#, VB NET.
Một số loại chƣơng trình khác yêu cầu 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, nhƣ: .NET Framework 1.1, 2.0, 3.5; Các đối tƣợ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;
và IBM JDK.

QTP sử dụng ngôn ngữ VBScript để viết kịch bản kiểm thử.
Ưu điểm:
- Dễ sử dụng, bảo trì, tạo kịch bản kiểm thử nhanh. Cung cấp dữ liệu kiểm
thử rõ ràng và dễ hiểu.
- Kiểm thử 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ứ kịch bản kiểm thử nào.
- Hỗ trợ làm việc theo nhóm thông qua việc 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 thử tự động trên nhiều trình duyệt
cùng lúc tốt hơn những công cụ khác.
- 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 kịch bản bị dừng trong khi đang
chạy.
- QTP có khả năng hiểu kịch bản kiểm thử của Mercury Winrunner (một
công cụ kiểm tra khác của Mercury).
Nhược điểm:
- Chƣa hỗ trợ tốt trên nhiều nền tảng công nghệ khác nhau.
- Giá thành khá cao: cho một máy 9.000 USD; cho nhiều máy dùng cùng
lúc 12.000 USD.
 JMeter
20


Hình 1.3: Logo JMeter
JMeter của Apache Jakarta là công cụ đƣợc phát triển bởi ngôn ngữ Java cho
phép kiểm tra máy chủ Web và thêm vào đó là khả năng kiểm tra các ứng dụng với các
giao thức khách nhƣ JDBC, FTP, và LDAP. Thực tế, với công cụ mở rộng và cho phép
ngƣời dùng tạo ra các tình huống giả định thì ngƣời dùng có khả năng kiểm tra bất kỳ

giao thức nào thông qua Java. Với chế độ mặc định nó có thể đƣa ra những file CSV
để dễ dàng truyền các tham số vào cơ sở dữ liệu và đƣa ra đƣợc rất nhiều thông tin hơn
CSV. Đây là công cụ đƣợc rất nhiều ngƣời mới vào nghề sử dụng trong vô số các công
cụ khác đang có trên mạng Internet.
 JUnit, NUnit
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 tác vụ kiểm thử có thể lặp đi lặp lại. Nó 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. Tƣơng
tự, NUnit là phiên bản dùng cho các sản phẩm phát triển trên nền tảng .NET, nó có thể
tích hợp với Microsoft Visual Studio.
Đây là một bộ công cụ giành cho Unit Test rất hiệu quả và hoàn toàn miễn phí.
Tuy nhiên công cụ mới dừng ở việc kiểm thử thành phần, chƣa mở rộng thêm các hình
thức kiểm thử khác.
 Một số công cụ kiểm thử phổ biến khác
Công cụ kiểm thử thành phần (component hoặc unit test):
- QACenter - Compuware
- PurifyPlus - IBM Rational
- Tau Architect và Tau Developer - Telelogic
- C++ Test, Java Test, Insure++, và .Test - Parasoft
21

Công cụ kiểm thử chức năng (function test):
- WinRunner - Mercury Interactive
- QuickTest Professional - Mercury Interactive
- Astra QuickTest - Mercury Interactive
- QACenter - Compuware
- SilkTest - Segue Software
- Rational Suite TestStudio - IBM Rational
- TauTester - Telelogic

- e-Test suite - Empirix
- Webking - Parasoft
- WetFT - RadView Software
Công cụ kiểm thử chịu tải (performance/load-test):
- LoadRunner - Mercury Interactive
- Astra LoadTest - Mercury Interactive
- QACenter - Compuware
- WebLoad - RadView Software
- Rational Suite TestStudio - IBM Rational
- SilkPerformer - Segue
- e-Test suite - Empirix
- webking - Parasoft
- Test Perspective - Keynote Systems
- LoadPro - Keynote Systems
Công cụ theo dõi thực thi (performance-monitoring):
- Vantage - Compuware
- Topaz - Mercury Interactive
- OneSight - Empirix
22

- FarSight - Empirix
- Rational Suite TestStudio - IBM Rational
Công cụ quản lý kiểm thử (test-management):
- QA Director - Compuware
- TestDirector - Mercury Interactive
- Rational Suite TestStudio - IBM Rational
- SilkPlan Pro - Segue
Với tƣ cách là một ngƣời làm việc trực tiếp trong lĩnh vực sản xuất phần mềm và
là ngƣời nghiên cứu Luận văn này, tôi đã đánh giá cao những khả năng tuyệt vời của
các công cụ kiểm thử hiện có, mặc dù tính tự động và hiệu quả của chúng chƣa đƣợc

nhƣ mong muốn. Những hạn chế trong các công cụ đƣợc thƣơng mại hóa gặp phải là
thƣờng không theo kịp với các thay đổi của công nghệ và khó thích ứng với quá trình
thiết kế mới trong các ngành công nghiệp phần mềm. Trong luận văn này, tôi sẽ
nghiên cứu đề xuất nâng cấp các cơ sở hạ tầng kiểm thử để tránh đƣợc những hạn chế
này.
1.4 Những lợi ích của kiểm thử tự động
Ngƣời ta mong đợi gì ở một công cụ tự động kiểm thử phần mềm?. Đó là tiết
kiệm thời gian cũng nhƣ chi phí, các chuẩn sẽ đƣợc tuân theo một cách nghiêm ngặt,
và tất nhiên chất lƣơng phần mềm sẽ đƣợc nâng cao.
Kiểm thử phần mềm vẫn luôn giữ một vai trò quan trọng trong ngành công
nghiệp phần mềm. Thƣờng bao hàm việc đào tạo các kiểm thử viên và yêu cầu họ học
những kỹ thuật kiểm thử trƣớc khi một dự án đƣợc bắt đầu. Cùng với khả năng cũng
nhƣ kinh nghiệm của đội ngũ kiểm thử tăng nên thì tính tự động trong công việc cũng
đƣợc nâng cao. Khi kiểm thử một sản phẩm hoàn toàn mới cũng chính là một quá trình
trau dồi kinh nghiệm cho mỗi kiểm thử viên. Những hiểu biết sâu sắc về dự án sẽ giúp
cho tính tự động trong công việc của họ tăng lên.
Về mặt kỹ thuật, rất nhiều tác vụ kiểm thử có thể đƣợc thực hiện một cách tự
động. Tuy nhiên, quản lý khả năng tự động hóa của các tác vụ kiểm thử cũng đƣợc coi
23

nhƣ các vấn đề về mặt kỹ thuật và cần đƣợc nghiên cứu kỹ càng. Quá trình phân tích
cần xác định rõ các thông tin sau:
 Ngày nay các dự án phần mềm thƣờng rất phức tạp và đƣợc giành để giải
quyết các vấn đề phức tạp. Các công cụ kiểm thử phần mềm thƣơng mại
thƣờng cần nhiều thời gian để tìm hiểu về một vấn đề riêng biệt và để theo
kịp công nghệ. Để đáp ứng đƣợc khung thời gian hạn chế của một dự án,
các kiểm thử viên cũng cần tự phát triển một công cụ kiểm thử cho riêng
mình để có thể bổ sung khiếm khuyết cho các công cụ kiểm thử thƣơng
mại trên thị trƣờng.
 Đôi khi các kiểm thử viên cần xác định hoặc là kết hợp kiểm thử tự động

vào những dự án đang thực hiện hoặc sẽ kết hợp vào dự án hoàn toàn mới.
Bƣớc đầu tiên của các tiến trình kiểm thử sẽ luôn liên quan tới kiểm thử
bằng tay. Các kiểm thử viên sử dụng chúng nhƣ là một cách để nghiên cứu
về tiến trình phần mềm. Giống nhƣ các tiến trình phần mềm, các kiểm thử
viên trở nên hiểu biết sâu sắc hơn về sản phẩm và các vấn đề tiềm tàng mà
họ có thể dự đoán trƣớc. Các công cụ kiểm thử tự động sau đó có thể đƣợc
bổ sung vào để làm việc với từng vấn đề cụ thể.
 Các tổ chức đã phát triển một mô hình phát triển phần mềm mang tên “lập
trình cực đoan” (Extreme Programming - XP) cho những dự án có rủi ro
cao trong do yêu cầu phần mềm không thống nhất. Họ không làm rõ đƣợc
chi tiết các yêu cầu ngay từ đầu. Thay vào đó mã nguồn của họ có thể
hoàn toàn đƣợc chỉnh sửa hoặc cập nhật thƣờng xuyên. Các kịch bản kiểm
thử là một phần của mã nguồn điều khiển cùng với mã nguồn của chƣơng
trình. Trên thực tế, kiểm thử tự động khó có thể áp dụng cho mô hình XP
do những kịch bản kiểm thử có thể đƣợc chỉnh sửa và trả về với mỗi quá
trình phát triển tích hợp.
 Hiếm khi một tổ chức có thể không chú ý tới những công cụ kiểm thử tự
động. Để quản lý chất lƣợng, việc phát triển một công cụ kiểm thử tự động
là một bƣớc thúc đẩy cho việc phát triển dự án.
Vòng đời của một mô hình phát triển phần mềm cũng tác động tới việc mở rộng
các tiến trình kiểm thử tự động:
24

 Thƣờng thì việc thay đổi xảy ra thƣờng xuyên trong giai đoạn bắt đầu dự
án. Mục đích của ta là phát triển một công tụ để sinh tự động các kịch bản
kiểm thử, nó cần phản ánh đƣợc những thay đổi đồng thời đem lại lợi ích
và hiệu quả đối với những sản phẩm không có tính thống nhất hay dễ bị
thay đổi.
 Những công cụ kiểm thử thƣơng mại có khả năng kiểm thử các thành phần
giao diện ngƣời dùng (GUI). Trong hầu hết thời gian, những ngƣời dùng

cần ghi lại một dãy các thao tác click chuột và nhấn bàn phím. Dữ liệu của
các kịch bản kiểm thử thƣờng bị cứng hóa. Đôi khi các kịch bản kiểm thử
cũng cần xem xét lại và gỡ lỗi (debug) trƣớc khi đƣợc đƣa vào thi hành.
Trên thực tế việc sử dụng và dùng lại những công cụ này trong những sản
phẩm không ổn định sẽ là một thảm họa. Một công cụ kiểm thử tự động
cần có khả năng tự nhận biết và xác minh các thành phần giao diện ngƣời
dùng và tự sinh ra các dữ liệu dẫn hƣớng kịch bản kiểm thử.
 Cùng với tiến bộ của công nghệ, việc lập trình cũng trở lên dễ dàng hơn.
Vòng đời phát triển phần mềm cũng ngắn hơn, đồng nghĩa với việc cho
phép ít thời gian hơn để kiểm thử. Một công cụ kiểm thử tự động sẽ làm
nhẹ bớt áp lực cho các kiểm thử viên để họ có nhiều thời gian hơn cho
việc nhận diện những vùng rủi ro cao của dự án.
1.4.1 Áp dụng cho mô hình phát triển phần mềm XP
Kent Beck tạo ra mô hình XP trong cuốn sách của ông mang tên Extreme
Programming Explained: Embrace Change (Addison-Wesley, 1999). Theo định nghĩa
XP là một kỹ thuật nhẹ nhàng tập trung cho việc lập trình những dự án phần mềm có
tính rủi ro cao. Nó tránh việc định rõ chi tiết các đặc tả và nhìn nhận các tác vụ một
cách đơn giản. Để thực hiện các vấn đề phức tạp, nó dựa vào dãy các tƣơng tác và giao
tiếp giữa lập trình viên, kiểm thử viên, và khách hàng.
Quyền ƣu tiên đầu tiên của việc quản lý một dự án XP là phải chắc chắn rằng
cuối cùng thì tất cả các yêu cầu của KH phải đƣợc thỏa mãn. Tuy nhiên các nhà phát
triển sử dụng mô hình XP tin rằng không cần thiết phải tập trung vào KH để thấy trƣớc
đƣợc yêu cầu của một sản phẩm. Các lập trình viên không phải là thầy bói và cũng