Nghiên cứu và xây dựng công cụ kiểm thử ứng dụng Web

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



ĐOÀN MẠNH ĐỨC


NGHIÊN CỨU VÀ XÂY DỰNG CÔNG CỤ
KIỂM THỬ ỨNG DỤNG WEB


LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN














Hà Nội – 2014

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

ĐOÀN MẠNH ĐỨC

NGHIÊN CỨU VÀ XÂY DỰNG CÔNG CỤ
KIỂM THỬ ỨNG DỤNG WEB


Ngành: Công nghệ thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60480103




LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN







NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. VÕ ĐÌNH HIẾU

Hà Nội – 2014
1


LỜI CẢM ƠN

Luận văn Thạc sĩ này được thực hiện tại Đại học Công Nghệ - Đại học Quốc
Gia Hà Nội dưới sự hướng dẫn của TS. Võ Đình Hiếu. Xin được gửi lời cảm ơn sâu
sắc đến thầy về định hướng khoa học, liên tục quan tâm, tạo điều kiện thuận lợi trong
suốt quá trình nghiên cứu hoàn thành luận văn này. Tôi xin được gửi lời cảm ơn đến
các thầy, cô trong Bộ môn Công nghệ phần mềm cũng như Khoa Công nghệ thông tin
đã mang lại cho tôi những kiến thức vô cùng quý giá và bổ ích trong quá trình theo học
tại trường.
Tôi cũng xin chân thành cảm ơn đến gia đình tôi, những sự quan tâm và động
viên của bố, mẹ và em gái đã giúp tôi có thêm nghị lực, cố gắng để hoàn thành luận
văn này.
Cuối cùng, xin gửi lời cảm ơn chân thành nhất đến các bạn cùng học K19, các
bạn đồng nghiệp đã giúp đỡ tôi trong suốt 2 năm học tập.

Hà Nội, ngày 30 tháng 10 năm 2014

Đoàn Mạnh Đức















2


LỜI CAM ĐOAN

Tôi xin cam đoan luận văn “Nghiên cứu và xây dựng công cụ kiểm thử ứng
dụng Web” là công trình nghiên cứu của cá nhân tôi dưới sự hướng dẫn của TS. Võ
Đình Hiếu, trung thực và không sao chép của tác giả khác. Trong toàn bộ nội dung
nghiên cứu của luận văn, các vấn đề được trình bày đều là những tìm hiểu và nghiên
cứu của chính cá nhân tôi hoặc là được trích dẫn từ các nguồn tài liệu có ghi tham
khảo rõ ràng, hợp pháp.

Tôi xin chịu mọi trách nhiệm và mọi hình thức kỷ luật theo quy định cho lời
cam đoan này.

Hà Nội, ngày 30 tháng 10 năm 2014




Đoàn Mạnh Đức


















3

MỤC LỤC

LỜI CẢM ƠN 1
LỜI CAM ĐOAN 2
MỤC LỤC 3
DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT 5
DANH MỤC CÁC BẢNG 6
DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ 7
LỜI GIỚI THIỆU 9
CHƢƠNG 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 11
1.1. Các khái niệm cơ bản 11
1.1.1. Khái niệm kiểm thử phần mềm 11
1.1.2. Mức kiểm thử 12
1.1.3. Kiểm thử tự động 18
1.1.4. Ứng dụng Web 19
1.2. Kỹ thuật kiểm thử tĩnh 20
1.2.1. Rà soát 20
1.2.2. Kiểm thử dòng dữ liệu tĩnh 21
1.3. Kỹ thuật kiểm thử động 23
1.3.1. Kiểm thử hàm 23
1.3.2. Kiểm thử dòng điều khiển 24
1.3.3. Kiểm thử dòng dữ liệu động 26
1.4. Các loại kiểm thử ứng dụng Web 29
CHƢƠNG 2 CÁC CÔNG CỤ KIỂM THỬ TỰ ĐỘNG CHO CÁC ỨNG DỤNG WEB 33
2.1. Công cụ kiểm thử tự động tĩnh 33
2.1.1. Công cụ kiểm thử ngôn ngữ lập trình phía máy chủ 33
2.1.2. Công cụ kiểm thử ngôn ngữ lập trình phía máy khách 35
2.2. Công cụ kiểm thử tự động động 37
2.2.1. Công cụ kiểm thử giao diện người dùng 37

2.2.2. Công cụ kiểm thử hàm 38
2.2.3. Công cụ kiểm thử khả năng chịu tải của ứng dụng Web 40
2.3. Thư viện hỗ trợ xây dựng công cụ kiểm thử tự động 41
CHƢƠNG 3 XÂY DỰNG CÔNG CỤ KIỂM THỬ TỰ ĐỘNG 44
3.1. Đặt vấn đề bài toán 44
4


3.2. Phân tích bài toán 45
3.3. Thỏa thuận khi sử dụng công cụ 50
3.4. Xây dựng công cụ 50
3.5. Ứng dụng công cụ vào thực tế 54
3.5.1. Ứng dụng vào form thành viên đăng nhập 54
3.5.2. Ứng dụng vào form đăng ký nhận bản tin 58
3.6. Đánh giá ưu nhược điểm của công cụ 60
CHƢƠNG 4 KẾT LUẬN 61
4.1. Tóm tắt kết quả làm được 61
4.2. Hạn chế 61
4.3. Hướng nghiên cứu 61
TÀI LIỆU THAM KHẢO 62
PHỤ LỤC 63
Phụ lục 1: Kết quả sau khi thực hiện kiểm thử form thành viên đăng nhập 63
Phụ lục 2: Kết quả sau khi thực hiện kiểm thử form đăng ký nhận bản tin 64

5



DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

API Application Programming Interface, giao diện lập trình ứng dụng.
C-S Client-Server, máy khách – máy chủ.
CSS Cascading Style Sheets, là ngôn ngữ được dùng để miêu tả cách trình
bày các tài liệu viết bằng ngôn ngữ HTML và XHTML.
HTML Hypertext Markup Language, ngôn ngữ đánh dấu tạo website.
HTTP HyperText Transfer Protocol - Giao thức truyền tải siêu văn bản được
dùng để trao đổi giữa máy khách và máy chủ ứng dụng Web.
HTTPS Hypertext Transfer Protocol Secure, là sự kết hợp giữa giao thức HTTP
và giao thức bảo mật SSL hay TLS cho phép trao đổi thông tin một cách
bảo mật trên Internet.
STT Số thứ tự
TDD Testing Driven Development, kỹ thuật phát triển phần mềm dựa trên
kiểm thử.

URL Uniform Resource Locator, đường dẫn tham chiếu tới tài nguyên trên
Internet.

















6




DANH MỤC CÁC BẢNG

Bảng 1.1. Các điều kiện con kết hợp trong câu lệnh điều kiện 26
Bảng 1.2. Một số lỗi thường gặp trên ứng dụng Web 32
Bảng 2.1. Minh họa một số quy ước về lập trình của Microsoft. 34
Bảng 2.2. Hàm và từ khóa thường dùng của Selenium WebDriver 42

Bảng 3.1. Một số điều kiện đầu vào với input trong ứng dụng Web 47
Bảng 3.2. Một số dữ liệu đầu vào mẫu cho input ngày tháng Việt Nam 49
Bảng 3.3. Kết quả thực hiện kiểm thử bằng công cụ kiểm thử tự động với form đăng
ký nhận bản tin 59




















7

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

Hình 1.1. Mã nguồn minh họa Driver và Stub 13
Hình 1.2. Kiểm thử hồi quy được thực hiện tại các mức kiểm thử khác nhau. 17
Hình 1.3. Các câu lệnh tuần tự có bất thường loại 1. 22
Hình 1.4. Câu lệnh có bất thường loại 2. 22
Hình 1.5. Sơ đồ chuyển trạng thái của một biến tương ứng với những bất thường về
dòng dữ liệu. 23
Hình 1.6. Các biểu tượng xây dựng đồ thị dòng điều khiển. 25
Hình 1.7. Mã nguồn tính tổng các số từ 1 đến 9. 25
Hình 1.8. Đồ thị dòng điều khiển của mã nguồn hình 1.9 25
Hình 1.9. Ví dụ mã nguồn hàm ReturnAverage. 27
Hình 1.10. Đồ thị dòng dữ liệu minh họa hàm ReturnAverage. 28
Hình 2.1. Giao diện Fxcop 33
Hình 2.2. Mã nguồn được phân tích bởi Fxcop 34
Hình 2.3. Kết quả phân tích từ Fxcop 35
Hình 2.4. Giao diện công cụ JSLint 36
Hình 2.5. Mã nguồn được phân tích bởi JSLint 36
Hình 2.6. Kết quả phân tích từ JSLint 36
Hình 2.7. Giao diện Browser Shots 38
Hình 2.8. Giao diện người dùng trên các trình duyệt khác nhau. 38
Hình 2.9. Giao diện Selenium IDE. 38
Hình 2.10. Các thao tác xử lý được Selenium IDE ghi lại. 39
Hình 2.11. Mã HTML của ca kiểm thử được Selenium IDE lưu lại. 40
Hình 2.12. Giao diện công cụ loader.io 41
Hình 2.13. Kết quả khi thực thi kiểm thử với loader.io. 41
Hình 3.1. Form thêm người dùng trên ứng dụng Web. 44
Hình 3.2. Minh họa hộp thông báo đăng nhập thành công 46
Hình 3.3. Minh họa dòng thông báo từ ứng dụng Web đến người dùng 46
8

Hình 3.4. Các dữ liệu mẫu sinh ra từ kỹ thuật kiểm thử giá trị biên mạnh. 49
Hình 3.5. Giao diện công cụ kiểm thử tự động. 50
Hình 3.6. Thêm ô textbox chứa input. 51
Hình 3.7. Lựa chọn các điều kiện cần kiểm thử của input. 51
Hình 3.8. Lỗi xuất hiện được thông báo cho kiểm thử viên. 52
Hình 3.9. Kiểm tra tính hợp lệ của điều kiện của độ dài tối thiểu và tối đa. 52
Hình 3.10. Thông báo không tìm thấy phần tử có id như đã nhập. 53
Hình 3.11. Điều kiện và giá trị được sinh ra khi lựa chọn điều kiện cho input. 53
Hình 3.12. Mã nguồn hàm ngẫu nhiên sinh ra chuỗi ký tự có độ dài là 53
tham số truyền vào. 54
Hình 3.13. Kết quả sau khi thực hiện kiểm thử form. 54
Hình 3.14. Giao diện form thành viên đăng nhập. 55
Hình 3.15. Thông báo không được bỏ trống tên đăng nhập. 55
Hình 3.16. Thông báo tên đăng nhập không được nhỏ hơn 6 ký tự. 55
Hình 3.17. Thông báo sai tên đăng nhập hoặc mật khẩu. 55
Hình 3.18. Lấy id của input. 56
Hình 3.19. Điền thông tin form thành viên đăng nhập vào công cụ. 56
Hình 3.20. Chọn điều kiện cho các input. 57
Hình 3.21. Kết quả kiểm thử form thành viên đăng nhập. 57
Hình 3.22. Giao diện form đăng ký nhận bản tin. 58
Hình 3.23. Thông báo không được bỏ trống email. 58
Hình 3.24. Thông báo nhập sai định dạng email. 58
Hình 3.25. Điền thông tin form đăng ký nhận bản tin vào công cụ. 59
Hình 3.26. Chọn điều kiện cho input email. 59

9






LỜI GIỚI THIỆU

Với sự phát triển của Internet và công nghệ phần mềm, các ứng dụng Web đang
dần thay thế các ứng dụng phần mềm truyền thống bởi tính tiện lợi của nó. Đi kèm với
thành công mà những ứng dụng Web mang lại cho nhà phát triển đó là những thách
thức như phải đảm bảo và nâng cao chất lượng cho người dùng khi sử dụng dịch vụ.
Một trong những giải pháp để hoàn thành tốt công việc này đó là thực hiện kiểm thử
phần mềm. Kiểm thử là một công việc tốn nhiều thời gian và chi phí, thông thường
thời gian dành cho việc kiểm thử chiếm đa số thời gian phát triển ứng dụng phần mềm.
Tuy nhiên, để thực hiện kiểm thử đòi hỏi kiểm thử viên phải kiên nhẫn và tỉ mỉ, chính
những điều này dẫn tới sự cần thiết của kiểm thử tự động. Kiểm thử tự động sẽ thực
hiện tự động các ca kiểm thử theo một kịch bản cho sẵn hoặc tự nó sinh ra. Những lợi
ích của các công cụ kiểm thử tự động mang lại là rất lớn tuy nhiên các tài liệu về kiểm
thử tự động được viết bằng tiếng Việt lại còn rất hạn chế. Xuất phát từ thực tế đó và
được sự gợi ý của giảng viên hướng dẫn, tôi lựa chọn đề tài luận văn “Nghiên cứu và
xây dựng công cụ kiểm thử ứng dụng Web” với mong muốn mang lại cho người đọc
một tài liệu hỗ trợ hữu ích trước khi quyết định sử dụng kiểm thử tự động cho ứng
dụng Web của mình.
Luận văn đƣợc cấu trúc thành bốn chƣơng:

Chương một sẽ trình bày các tìm hiểu về kiểm thử phần mềm như các khái
niệm cơ bản về kiểm thử, các mức kiểm thử, ca kiểm thử, các kỹ thuật kiểm thử tĩnh
và động. Chương một cũng sẽ đưa ra khái niệm về ứng dụng Web, phân biệt ứng dụng
Web với ứng dụng máy khách – máy chủ và các loại kiểm thử cần chú trọng cho ứng
dụng Web.
Chương hai sẽ giới thiệu các công cụ kiểm thử tự động phổ biến hiện nay dành
cho ứng dụng Web, ngoài việc cung cấp thông tin và cách sử dụng từng công cụ, luận
văn còn phân tích ưu nhược điểm của các công cụ giúp người đọc có một gợi ý trước
khi lựa chọn công cụ phù hợp cho ứng dụng cần kiểm thử. Xuất phát trên thực tế, mỗi
ứng dụng Web đều có những yêu cầu đặc thù riêng biệt nên việc sử dụng các công cụ
kiểm thử tự động đã có sẵn có thể không thỏa mãn hoặc phù hợp với việc kiểm thử các
ứng dụng này. Luận văn cũng giới thiệu một nền tảng hỗ trợ xây dựng công cụ kiểm
thử tự động nhằm giúp người đọc có thể lựa chọn nền tảng giúp tự tạo công cụ kiểm
thử cho phù hợp với nhu cầu của mình.
Trong ứng dụng Web, việc kiểm tra tính hợp lệ của các dữ liệu đầu vào là rất
quan trọng do dữ liệu đầu vào không chỉ yêu cầu phải đúng kiểu dữ liệu mà còn đòi
10


hỏi phải đúng định dạng của loại dữ liệu đó. Do đó, ứng dụng Web cần phải có khả
năng kiểm tra tính hợp lệ của dữ liệu đầu vào một cách hiệu quả thì các tiến trình xử lý
tiếp theo mới được đảm bảo hoạt động tốt. Một vấn đề nữa là hiện nay có rất nhiều
công cụ hỗ trợ cho việc kiểm thử tự động ứng dụng Web, tuy nhiên hầu hết các công
cụ chỉ hỗ trợ cho việc thực thi tự động các ca kiểm thử còn việc thiết kế các ca kiểm
thử lại rất hạn chế. Chương ba sẽ trình bày về ý tưởng, phân tích và xây dựng công cụ
kiểm thử tự động nhằm đánh giá khả năng kiểm tra tính hợp lệ dữ liệu đầu vào của ứng
dụng Web. Công cụ được đề xuất có khả năng tự sinh ca kiểm thử, thực thi và lưu lại
kết quả kiểm thử. Ngoài ra chương này cũng minh họa áp dụng công cụ trong thực tế
và đánh giá ưu nhược điểm của công cụ cùng hướng phát triển.
Chương bốn sẽ đưa kết luận về các nội dung đạt được trong luận văn, các mặt

hạn chế và hướng phát triển trong thời gian tới của luận văn.























11

CHƢƠNG 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

1.1. Các khái niệm cơ bản
1.1.1. Khái niệm kiểm thử phần mềm
Kiểm thử phần mềm là công việc được thực hiện nhằm tìm ra lỗi, thiếu sót của phần
mềm hoặc chứng minh phần mềm hoạt động đúng đắn. Kiểm thử phần mềm có vai trò
rất quan trọng trong việc cải thiện chất lượng phần mềm [4, tr.655-657] và làm giảm
chi phí kiểm thử cũng như khắc phục lỗi.
Kiểm thử phần mềm sử dụng quy trình kiểm chứng và thẩm định chất lượng
phần mềm trong quá trình thực hiện việc kiểm thử. Quy trình kiểm chứng sẽ đảm bảo
rằng phần mềm khi được phát triển sẽ đúng với đặc tả của nó và quy trình thẩm định
thì sẽ đảm bảo rằng phần mềm thỏa mãn được yêu cầu của người dùng cuối. Quy trình
kiểm chứng sẽ được thực hiện trước quy trình thẩm định do sản phẩm phần mềm cần
đúng với đặc tả trước. Nếu thực hiện quy trình thẩm định trước quy trình đặc tả, nếu
xảy ra lỗi, rất khó có thể xác định lỗi này là do đặc tả sai hay do lập trình sai so với đặc
tả. Tuy nhiên, thẩm định nếu được thực hiện quá muộn thì khi phát hiện ra lỗi hoặc
thiếu sót sẽ kéo theo chi phí khắc phục lỗi tăng đồng thời khiến thời gian hoàn thiện
phần mềm kéo dài. Vì vậy, quy trình thẩm định nên được thực hiện sớm để góp phần
làm giảm chi phí cũng như thời gian phát triển sản phẩm phần mềm. Trong phương
pháp phát triển phần mềm Agile [4, tr.58-64], khách hàng sẽ đóng vai trò là một thành
viên của nhóm phát triển và thực hiện việc thẩm định sản phẩm phần mềm liên tục sau
mỗi vòng lặp phát triển trong suốt quá trình thực hiện dự án phần mềm. Chính điều
này giúp cho việc phát triển phần mềm theo phương pháp Agile trở nên rất nhanh
chóng và giảm được nhiều chi phí cho việc sửa lỗi do lỗi được phát hiện từ rất sớm.
Trong kiểm thử phần mềm, các khái niệm như lỗi, sai, khuyết thiếu, thất bại đều
có nghĩa khá gần nhau nhưng trên thực tế cần phân biệt rõ các khái niệm này.
 Lỗi: do lập trình viên phạm phải trong quá trình lập trình. Khi lỗi được thực thi
sẽ dẫn tới thất bại.
 Sai: bắt nguồn từ lỗi, do quá trình thực hiện không tuân theo quy trình dẫn đến

phần mềm thực hiện một cách không xác định.
 Thất bại: xảy ra khi chức năng của phần mềm không thực hiện đúng như mong
đợi.
 Khuyết thiếu: là sự thiếu sót các trường hợp có thể xảy ra khi phần mềm hoạt
động, có thể do đặc tả thiếu hoặc thiếu sót khi lập trình.
12


Kiểm thử phần mềm có thể chia làm hai nhóm kỹ thuật chính là kỹ thuật kiểm
thử tĩnh và kỹ thuật kiểm thử động. Kiểm thử tĩnh là kỹ thuật không yêu cầu phải biên
dịch và chạy mã nguồn chương trình để thực hiện việc kiểm thử phần mềm. Kỹ thuật
này kiểm thử chương trình bằng cách kiểm tra cú pháp, cấu trúc mã nguồn của chương
trình hoặc rà soát các tài liệu liên quan như tài liệu đặc tả, tài liệu thiết kế để tìm ra lỗi.
Trong quy trình kiểm chứng và thẩm định chất lượng phần mềm thì kiểm thử tĩnh
được sử dụng trong quy trình kiểm chứng. Kiểm thử động là kỹ thuật chỉ được thực
hiện khi mã nguồn chương trình phần mềm được biên dịch và chạy. Mục đích chính
của kỹ thuật kiểm thử động là thẩm định xem chương trình phần mềm có hoạt động
đúng và đầy đủ các chức năng như những mong muốn của người sử dụng hay không,
do đó trong quy trình kiểm chứng và thẩm định chất lượng phần mềm thì kiểm thử
động được sử dụng trong quy trình thẩm định.

1.1.2. Mức kiểm thử
Một sản phẩm phần mềm từ khi bắt đầu phát triển đến khi hoàn thành và đưa đến tay
người dùng cuối phải trải qua bốn mức kiểm thử đó là: Kiểm thử mức đơn vị, mức tích
hợp, mức hệ thống và mức chấp nhận.
Kiểm thử mức đơn vị
Kiểm thử mức đơn vị hay còn gọi là kiểm thử thành phần (module testing) là mức thấp
nhất trong các mức độ kiểm thử. Đơn vị ở đây có thể là một chức năng cụ thể, một
hàm (function), một lớp trong lập trình hướng đối tượng hoặc một thành phần nhỏ đã
hoàn thiện trong chương trình. Thường thì các lập trình viên sẽ đảm nhận kiểm thử ở

mức này để đảm bảo thời gian do việc phát hiện và sửa lỗi cần được thực hiện liên tục.
Có thể áp dụng tất cả các kỹ thuật kiểm thử được nêu ở 1.2 và 1.3 để kiểm thử mức
đơn vị.
Đa số các lỗi của chương trình đều được phát hiện ở mức đơn vị, các lỗi về tích
hợp chưa xuất hiện ở mức này. Càng nhiều lỗi được tìm và sửa ở mức này sẽ càng
giúp giảm lỗi ở những giai đoạn phát triển sau của chương trình. Hiện nay, trong
phương pháp phát triển phần mềm Agile có một kỹ thuật lập trình khá hiệu quả đó là
phát triển dựa trên kiểm thử [4, tr.221-224] (TDD – Testing Driven Development), các
lập trình viên sẽ thiết kế các ca kiểm thử trước khi lập trình và từ đó lập trình các chức
năng để thỏa mãn các ca kiểm thử. Việc xây dựng trước các ca kiểm thử sẽ giúp lập
trình viên xác định được những thiếu sót hay lỗi có thể có nhằm hạn chế lỗi và rút
ngắn thời gian thực hiện một cách hiệu quả.
Do đơn vị là một thành phần nhỏ trong chương trình nên không thể hoạt động
độc lập, để thực hiện kiểm thử động cần giả lập các Driver và Stub. Driver sẽ đóng vai
trò gọi thực thi đơn vị còn Stub đóng vai trò là các đơn vị có giao tiếp với đơn vị đang
xét. Xét một ví dụ cụ thể với đơn vị được kiểm thử là một hàm có tên
TinhNghiemPTBac2 viết bằng ngôn ngữ lập trình C# có nhiệm vụ tính nghiệm của
phương trình bậc hai một ẩn số. Tham số đầu vào của hàm là các biến a, b, c kiểu số
13


thực và hàm này có gọi một hàm khác làm nhiệm vụ tính delta. Driver trong ví dụ này
sẽ gán cứng ba tham số a, b, c sau đó gọi và truyền ba tham số này cho hàm
TinhNghiemPTBac2. Stub ở đây là hàm tính delta có tên TinhDelta, có thể tính hoặc
gán cứng giá trị trả về để kiểm tra xem hàm TinhNghiemPTBac2 hoạt động ra sao.



public void TinhNghiemPTBac2(double a, double b, double c)
{

double x1, x2;
double delta = TinhDelta(a, b, c);
if(delta < 0)
Console.WriteLine(“Phuong trinh vo nghiem”);
else if (delta == 0)
{
x1 = -b / 2 * a;
Console.WriteLine(“Phuong trinh co 1 nghiem duy nhat x = ” + x1);
}
else
{
x1 = (-b + Math.Sqrt(delta)) / 2 * a;
x2 = (-b - Math.Sqrt(delta)) / 2 * a;
Console.WriteLine(“Phuong trinh co 2 nghiem x1=”+ x1 +“,x2= ”
+ x2);
}
}

public void Driver()
{
double a = 2, b = 9, c = 4;
TinhNghiemPTBac2(a, b, c);
}

public double TinhDelta(double a, double b, double c)
{
return b * b – 4 * a * c;
}
Hình 1.1. Mã nguồn minh họa Driver và Stub

14


Kiểm thử mức đơn vị có ưu điểm là giúp người thực hiện dễ dàng xác định và
sửa lỗi do phạm vi kiểm thử là rất nhỏ. Việc phát hiện lỗi sớm sẽ giảm chi phí kiểm
thử so với việc phát hiện lỗi muộn ở những giai đoạn phát triển sau. Tuy nhiên kiểm
thử mức đơn vị có một số nhược điểm như tốn nhiều thời gian để thực hiện, chưa phát
hiện được các lỗi xảy ra khi tích hợp, ngoài ra Driver và Stub là giả lập chứ không
phải chương trình hoàn chỉnh nên vẫn có thể có thiếu sót nhất định.

Kiểm thử mức tích hợp
Sau khi một đơn vị chương trình hoàn thành việc kiểm thử mức đơn vị, đơn vị này sẽ
được tích hợp với các đơn vị chương trình khác có liên quan để dần tạo nên chương
trình tổng thể. Các chức năng mà đơn vị chương trình cung cấp cũng như các tham số
cần truyền để sử dụng sẽ được thông qua giao diện. Các đơn vị khi được tích hợp sẽ
làm việc với nhau thông qua các giao diện. Các loại giao diện chủ yếu chia làm ba loại
chính:
 Giao diện gọi hàm: một hàm trong đơn vị này sẽ gọi một hàm ở đơn vị khác.
 Giao diện dùng chung bộ nhớ: cả 2 đơn vị sẽ cùng dung chung, chia sẻ một
khối bộ nhớ. Một ví dụ đơn giản là cả 2 đơn vị dùng chung một biến toàn cục.
 Giao diện truyền bản tin: một đơn vị tạo và gửi một bản tin đến đơn vị khác.
Một ví dụ đơn giản về truyền bản tin là trong các ứng dụng Web, việc liên lạc
giữa máy chủ và máy khách được truyền qua lại thông qua các bản tin
HTTP/HTTPS.
Kiểm thử mức tích hợp sẽ giúp tìm ra các thiếu sót, lỗi xuất hiện khi tích hợp
nếu có. Mặc dù ở mức kiểm thử đơn vị, một đơn vị cũng đã được kiểm tra giao tiếp
với các đơn vị khác, cụ thể là các Stub và Driver giả lập, tuy nhiên dù có kiểm tra kỹ
thì khi tích hợp với các đơn vị thực tế thì vẫn có thể xảy ra lỗi.
Một số lỗi hay thiếu sót có thể xảy ra ở mức kiểm thử tích hợp [2]:
 Lỗi không đủ chức năng: lỗi này xuất hiện khi đơn vị cung cấp chức năng

không như đơn vị sử dụng mong đợi.
 Thay đổi tính năng: một đơn vị được sửa đổi nhưng các đơn vị sử dụng nó
không được điều chỉnh theo nên chức năng của chương trình bị ảnh hưởng.
 Sử dụng giao diện không đúng: đơn vị sử dụng không đúng giao diện của đơn
vị được gọi, có thể là do truyền sai kiểu dữ liệu.
 Hiểu giao diện không đầy đủ: xảy ra khi đơn vị gọi hiểu nhầm hoặc không đầy
đủ giao diện của đơn vị được gọi. Có thể ví dụ như trong lập trình hướng đối
tượng, bằng việc nạp chồng phương thức, có thể có nhiều phương thức trùng
tên nhưng khác nhau tham số đầu vào, việc truyền nhầm tham số có thể dẫn tới
việc gọi sai phương thức dẫn tới sai kết quả trả về.
 Không xử lý lỗi trả về: một đơn vị được gọi có thể trả về một mã lỗi nhưng đơn
vị gọi lại không kiểm tra lỗi mà coi đó là kết quả hoặc không biết sửa.
15


 Lỗi xung đột tài nguyên: các đơn vị dùng chung bộ nhớ có thể bị xung đột khi
sử dụng. Ví dụ: một đơn vị vừa ghi dữ liệu vào một biến toàn cục thì đơn vị
khác lại ghi đè dữ liệu vào biến đó.
 Các vấn đề về phi chức năng: ví dụ với các hệ thống thời gian thực, việc xử lý
chậm có thể gây mất đồng bộ giữa các đơn vị.
Một số chiến lược được áp dụng trong kiểm thử mức tích hợp:
 Tích hợp từng bước (incremental).
 Tích hợp từ trên xuống (top - down).
 Tích hợp từ dưới lên (bottom - up).
 Tích hợp kẹp (sandwich).
 Tích hợp tất cả cùng một thời điểm (big bang).
Kiểm thử mức hệ thống
Kiểm thử mức hệ thống có nhiệm vụ kiểm tra xem hệ thống hoặc chương trình sau khi
đã tích hợp đầy đủ các đơn vị có hoạt động đúng với tài liệu đặc tả yêu cầu hay không.
Do hầu hết các lỗi, thiếu sót đã được kiểm tra và sửa chữa ở mức kiểm thử đơn vị và

kiểm thử tích hợp nên ở mức kiểm thử hệ thống tuy vẫn kiểm tra lỗi nhưng tập trung
nhiều vào đảm bảo chất lượng của chương trình hơn.
Các loại kiểm thử được dùng trong mức kiểm thử hệ thống [6, tr.193-194]:
 Kiểm thử cơ bản (basic test): kiểm tra xem chương trình có thể cài đặt, gỡ bỏ
được hay không, có cấu hình được không,
 Kiểm thử chức năng (Functionality test): kiểm tra tổng thể các chức năng mà
chương trình cung cấp .
 Kiểm thử khả năng chịu lỗi (Robustness test): chương trình có thể hoạt động
nếu xảy ra lỗi hay không.
 Kiểm thử tương thích (Interoperability test): chương trình có thể tương thích
với các phần mềm khác trong cùng môi trường hoạt động hay không.
 Kiểm thử hiệu năng (performance test): kiểm tra xem hiệu năng của chương
trình có đảm bảo không. Ví dụ: thời gian xử lý yêu cầu.
 Kiểm thử khả năng mở rộng (Scalability test): kiểm tra giới hạn mà chương
trình có thể mở rộng như chức năng, tài nguyên, lượng truy cập,
 Kiểm thử khả năng chịu tải (Stress test): kiểm tra giới hạn tối đa mà chương
trình có thể xử lý khi có áp lực cao. Ví dụ: nhiều người truy cập cùng lúc,
 Kiểm thử khả năng ổn định quá tải (Stability test): kiểm tra xem chương trình
có thể duy trì hoạt động trong một thời gian quá tải kéo dài hay không.
 Kiểm thử độ tin cậy (Reliability test): kiểm tra xem chương trình có thể hoạt
động trong một thời gian dài mà không có lỗi xảy ra.
 Kiểm thử tài liệu hướng dẫn sử dụng (Documentation test): kiểm tra xem tài
liệu hướng dẫn sử dụng cho người dùng cuối có chính xác và dễ dùng không.
16


 Kiểm thử tính pháp lý (Regulatory test): kiểm tra tính pháp lý của chương trình
có phù hợp với quy định của chính phủ nước sở tại hay không.
 Kiểm thử bảo mật (Security test): kiểm tra xem chương trình có đảm bảo khả
năng bảo mật, an toàn thông tin trước sự xâm phạm có chủ ý từ bên ngoài hay

bên trong không.
 Kiểm thử khả năng phục hồi (Recovery test): kiểm tra xem chương trình có thể
khôi phục hoạt động ổn định, khôi phục dữ liệu nếu bị tấn công hoặc mất dữ
liệu hay không.

Kiểm thử mức chấp nhận
Ở mức kiểm thử mức chấp nhận, người thực hiện việc kiểm tra chương trình chính là
những người sẽ sử dụng trực tiếp chương trình phần mềm sau này hay còn gọi là người
dùng cuối. Người dùng cuối là những người hiểu hơn ai hết cái họ muốn ở sản phẩm
như phần mềm có đáp ứng đầy đủ những chức năng mà họ cần hoặc có đúng với quy
trình công việc mà họ vẫn làm hay không? giao diện chương trình có dễ sử dụng hay
không? các thao tác sử dụng có quá phức tạp hay không? đây là những vấn đề mà các
kiểm thử viên hay người phát triển không thể kiểm tra được chính xác. Đây cũng là
mức quyết định xem sản phẩm đã thực sự hoàn thiện để chuyển tới tay người dùng hay
chưa. Các thiếu sót, lỗi sẽ được ghi lại trong quá trình kiểm tra và chuyển tới đội ngũ
phát triển để sửa chữa.
Kiểm thử mức chấp nhận giúp đảm bảo chương trình phần mềm có thể làm hài
lòng người sử dụng đem lại sự thống nhất về kỹ thuật giữa đội ngũ phát triển và khách
hàng. Tuy nhiên kiểm thử mức chấp nhận cũng có một số nhược điểm như tốn kém chi
phí sửa chữa nếu phát sinh lỗi, thiếu sót, thay đổi. Ngoài ra, người dùng thường sử
dụng chương trình một cách cẩn thận, không cố tình tạo ra các vi phạm (nhập sai kiểu
dữ liệu, dùng sai quy cách) khiến lỗi chưa thể bị phát hiện trong quá trình kiểm tra.
Kiểm thử hồi quy
Trong quá trình phát triển phần mềm, nếu có một sự thay đổi xảy ra như thay đổi yêu
cầu chức năng, quy trình xử lý thì đòi hỏi cần phải thực hiện việc kiểm tra lại để đảm
bảo rằng chương trình phần mềm vẫn hoạt động tốt, không phát sinh ra lỗi, kiểm thử
hồi quy sẽ thực hiện việc này. Kiểm thử hồi quy không phải là một mức kiểm thử
giống như các mức đã nêu ở trên, nó có thể thực hiện lại các mức kiểm thử và sử dụng
lại các ca kiểm thử đã được xây dựng. Hình 1.2 minh họa việc thực hiện kiểm thử ở
các mức lần lượt từ kiểm thử mức đơn vị đến kiểm thử mức chấp nhận và áp dụng

kiểm thử hồi quy để thực hiện lại việc kiểm thử các mức kiểm thử đơn vị, tích hợp và
hệ thống.
17



Hình 1.2. Kiểm thử hồi quy được thực hiện tại các mức kiểm thử khác nhau.

Ưu điểm của kiểm thử hồi quy là đảm bảo các chức năng vẫn hoạt động tốt sau
khi có sự thay đổi, chỉnh sửa, ngoài ra nó cũng giúp xác định được các lỗi phát sinh
sau khi chương trình được thay đổi. Tuy nhiên nhược điểm của kiểm thử hồi quy là chi
phí và thời gian để thực hiện khá tốn kém.
Ca kiểm thử
Ca kiểm thử là một tập các giá trị đầu vào và đầu ra mong đợi đối với mỗi hành vi cần
kiểm thử của phần mềm. Để thực hiện kiểm thử động thì cần phải thiết kế các ca kiểm
thử hiệu quả có khả năng phát hiện nhiều lỗi nhất với thời gian, chi phí và công sức tối
thiểu. Có hai cách tiếp cận để thiết kế các ca kiểm thử, đó là kiểm thử hộp đen và kiểm
thử hộp trắng.
Kiểm thử hộp đen
Với cách tiếp cận hộp đen, có thể xem chương trình như một chiếc hộp màu đen khiến
người sử dụng không thể nhìn được mã nguồn, cấu trúc, thuật toán bên trong đó cũng
như cách thức nó hoạt động như thế nào. Người thực hiện việc kiểm thử chỉ có thể
thao tác với các chức năng mà chương trình cung cấp, đưa dữ liệu vào và nhận được
dữ liệu ra sau khi chương trình xử lý, tính toán. Kiểm thử hộp đen đôi khi còn được
gọi là kiểm thử chức năng hay kiểm thử về cách hoạt động.
Kiểm thử hộp đen cũng chia làm kiểm thử hộp đen tĩnh và hộp đen động. Kiểm
thử hộp đen tĩnh chính là kiểm tra tài liệu đặc tả yêu cầu để xác định các chức năng mà
chương trình cung cấp cũng như yêu cầu về đầu vào, đầu ra. Kiểm thử hộp đen động
chính là kiểm thử chức năng của chương trình đang chạy để kiểm tra xem có lỗi, thiếu
sót chức năng và có đúng với đặc tả hay không.

Phương pháp kiểm thử hộp đen có ưu điểm là không yêu cầu người thực việc
kiểm thử phải biết lập trình hay tham gia vào quá trình viết mã nguồn cho chương
trình, thậm chí người dùng cuối cũng có thể tham gia kiểm thử. Phương pháp cũng
không phụ thuộc vào cài đặt thuật toán, nếu có thay đổi trong mã nguồn vẫn có thể sử
dụng lại ca kiểm thử cũ. Phương pháp này cũng giúp loại bỏ những nhầm lẫn trong
việc thống nhất kỹ thuật, chức năng mà chương trình cung cấp giữa người dùng cuối
và đội ngũ thực hiện do đưa ra chương trình trực quan và rất hiệu quả khi kiểm thử
những chương trình lớn. Tuy nhiên nhược điểm của phương pháp kiểm thử hộp đen là
Kiểm thử mức
đơn vị
Kiểm thử mức
tích hợp
Kiểm thử mức
hệ thống
Kiểm thử mức
chấp nhận
Kiểm thử hồi quy
18


việc kiểm thử đầy đủ các trường hợp dữ liệu vào có thể có là không khả thi. Phương
cũng chỉ phát hiện ra các lỗi có thể quan sát được và nếu có lỗi thì không chỉ ra được
nguyên nhân, vị trí gây ra lỗi. Ngoài ra nếu không có tài liệu đặc tả chính xác thì rất
khó để thiết kế ca kiểm thử chính xác.
Kiểm thử hộp trắng
Kiểm thử hộp trắng là phương pháp kiểm thử dựa vào các cấu trúc, thuật toán bên
trong của chương trình để xác định chương trình có thực hiện đúng không. Để thực
hiện kiểm thử hộp trắng đòi hỏi người thực hiện phải có kiến thức về lập trình và kiến
trúc phần mềm đang được kiểm thử để có thể truy cập vào mã nguồn, cấu trúc thuật
toán. Một số tên gọi khác của kiểm thử hộp trắng là kiểm thử hộp thủy tinh, hộp trong

suốt hay kiểm thử cấu trúc, phương pháp này thường được dùng ở mức kiểm thử đơn
vị.
Kiểm thử hộp trắng cũng chia ra làm kiểm thử hộp trắng tĩnh và hộp trắng
động. Kiểm thử hộp trắng tĩnh chính là thực hiện các kỹ thuật rà soát còn kiểm thử hộp
trắng động là sử dụng các kỹ thuật kiểm thử luồng điều khiển, kiểm thử luồng dữ liệu
động và kiểm thử miền.
Ưu điểm của phương pháp là đảm bảo tất cả câu lệnh trong chương trình đều
được thực thi ít nhất một lần giúp tránh lỗi tiềm ẩn, tối ưu hóa mã nguồn. Ngoài ra do
người thực hiện việc kiểm thử hiểu về mã nguồn, cấu trúc thuật toán, kiến trúc của
chương trình nên có thể kiểm thử một cách kỹ lưỡng chương trình. Tuy nhiên phương
pháp cũng có nhược điểm như đòi hỏi người thực hiện phải hiểu về mã nguồn, cấu trúc
thuật toán, kiến trúc của chương trình. Áp dụng phương pháp khiến tốn kém chi phí,
nhân lực và thời gian khi thực hiện do yêu cầu kỹ thuật khá phức tạp. Ngoài ra để kiểm
thử tất cả các đường dẫn trong chương trình là việc không khả thi và nếu thay đổi cài
đặt thuật toán trong mã nguồn thì phải thiết kế lại ca kiểm thử. Một nhược điểm nữa
của phương pháp là khi thực hiện không đảm bảo các chức năng của chương trình hoạt
động đúng với tài liệu đặc tả.
Nên lựa chọn cách tiếp cận hộp đen hay hộp trắng để thiết kế ca kiểm thử?
Mỗi cách tiếp cận đều có ưu và nhược điểm, khi thiết kế ca kiểm thử nên sử dụng kết
hợp cả hai cách để đạt hiệu quả tốt nhất với mỗi ca kiểm thử.

1.1.3. Kiểm thử tự động
Kiểm thử phần mềm là một công việc tốn nhiều thời gian và chi phí, thông thường thời
gian dành cho việc kiểm thử chiếm hơn 50% tổng thời gian phát triển phần mềm.
Ngoài ra, để thực hiện kiểm thử đòi hỏi kiểm thử viên phải kiên nhẫn và tỉ mỉ, chính
những điều này dẫn tới sự cần thiết của kiểm thử tự động. Kiểm thử tự động sẽ thực
hiện tự động các ca kiểm thử theo một kịch bản cho sẵn hoặc tự nó sinh ra. Kiểm thử
tự động giúp rút ngắn thời gian, chi phí, nhân lực cho dự án phần mềm. Một ưu điểm
nữa là kiểm thử tự động cung cấp cho chúng ta khả năng để thực hiện kiểm thử hồi
quy với các chức năng mà mã nguồn liên tục thay đổi. Tuy nhiên đối với một số ca

19


kiểm thử phức tạp thì không thể sử dụng kiểm thử tự động mà vẫn cần phải thực hiện
kiểm thử thủ công.

1.1.4. Ứng dụng Web
Khái niệm ứng dụng Web
Ứng dụng Web là một phần mềm mà người dùng có thể tương tác thông qua trình
duyệt Web. Ứng dụng Web không đòi hỏi người dùng phải cài đặt trước khi sử dụng
và có thể tương tác trên bất kỳ hệ điều hành hoặc thiết bị nào miễn là môi trường đó có
thể cài đặt và sử dụng một trình duyệt Web đủ tiêu chuẩn. Ứng dụng Web được cài đặt
trên máy chủ và giao tiếp với máy khách thông qua các bản tin HTTP, HTTPS.
Sự khác biệt giữa Ứng dụng Web và Website
Về mặt hoạt động thì cả ứng dụng Web lẫn Website đều là các ứng dụng phần mềm
được người dùng tương tác thông qua trình duyệt Web chính vì thế nên khái niệm ứng
dụng Web và Website thường quy về chung làm một. Tuy nhiên Website thiên về
khuynh hướng chỉ truyền tải thông tin đến người dùng còn ứng dụng Web thiên về
khuynh hướng tương tác qua lại giữa người dùng và ứng dụng. Có thể ví dụ đơn giản
về Website như sau: Website tin tức cung cấp cho người dùng các thông tin nhưng họ
chỉ có thể đọc chứ không thể chỉnh sửa. Minh họa về ứng dụng Web có thể nói đến
ứng dụng Google Docs cho phép người dùng tạo văn bản, chỉnh sửa và quản lý đem lại
sự tương tác như một phần mềm thực sự trên máy tính.
Sự khác biệt giữa mô hình máy khách – máy chủ (C-S) truyền thống và Web.
Ở phía máy khách thì mô hình C-S truyền thống đòi hỏi với mỗi hệ điều hành khác
nhau thì phải thiết kế ứng dụng phù hợp với hệ điều hành đó và để sử dụng ứng dụng
thì cần phải cài đặt, còn với mô hình Web thì do được sử dụng thông qua các trình
duyệt Web nên chỉ cần được thiết kế cho phù hợp chuẩn chung (HTML, các thành
phần khác như CSS, ngôn ngữ lập trình phía máy khách) mà các nhà cung cấp trình
duyệt Web đã thỏa thuận.

Trên lý thuyết thì chỉ cần nhà phát triển đáp ứng được các chuẩn mà nhà cung
cấp trình duyệt Web đề ra thì các nội dung hiển thị trên các trình duyệt khác nhau sẽ là
đồng nhất, tuy nhiên thực tế thì với những trình duyệt khác nhau, nội dung hiển thị có
thể khác nhau đôi chút, các tính năng có thể chưa chắc hoạt động ổn định như mong
muốn.
Việc kiểm thử các tính năng được cung cấp của ứng dụng dựa theo các sự kiện
(click chuột, nhấn phím, kết hợp giữa chuột và phím) là rất phức tạp do các sự kiện có
thể được phối hợp, lồng ghép với nhau (ví dụ: single-click, double-click, tổ hợp các
phím kết hợp lại). Tuy nhiên thì với các ứng dụng được sử dụng thông qua trình duyệt
Web thì việc kiểm thử đơn giản hơn. Lý do là các trình duyệt Web hầu hết nguyên bản
chỉ có nhiệm vụ là hiển thị dữ liệu nên việc giao tiếp giữa người dùng và trình duyệt
Web chỉ đơn giản là các sự kiện single-click, submit button hay mouse over-hover mặc
dù sau này dựa vào các Web Engine (Javascript, activeX) có thể hỗ trợ thêm một số sự
20


kiện phức tạp hơn như drap hay drop tuy nhiên vẫn bị giới hạn do có thể một số sự
kiện (ví dụ phím tắt) được đặc tả dành riêng cho trình duyệt đang chạy ứng dụng Web
đó.
Trong ứng dụng máy khách của mô hình C-S Web thì cũng có 2 loại là Thin-
Client: Ở phía máy khách thì ứng dụng chỉ mang tính hiển thị, đưa yêu cầu còn xử lý,
lưu trữ dữ liệu thì do máy chủ thực thi, các vấn đề không tương thích sẽ bị loại trừ khá
nhiều, việc kiểm thử trên máy khách lúc này trở nên đơn giản; còn Thick-Client: ở
phía máy khách thì ứng dụng ngoài hiển thị, đưa yêu cầu thì còn có khả năng xử lý
một phần, phía máy chủ cũng sẽ xử lý phần còn lại và chứa dữ liệu (Ví dụ đơn giản:
bẫy lỗi ngay trên máy khách) thì lúc này các vấn đề không tương thích sẽ dễ xảy ra.

1.2. Kỹ thuật kiểm thử tĩnh
Kiểm thử tĩnh là kỹ thuật không yêu cầu phải biên dịch và chạy mã nguồn chương
trình để thực hiện việc kiểm thử phần mềm. Kỹ thuật này kiểm thử chương trình bằng

cách kiểm tra cú pháp, cấu trúc mã nguồn của chương trình hoặc rà soát các tài liệu
liên quan như tài liệu đặc tả, tài liệu thiết kế để tìm ra lỗi. Trong quy trình kiểm chứng
và thẩm định chất lượng phần mềm thì kiểm thử tĩnh được sử dụng trong quy trình
kiểm chứng.
Mục đích chính của kỹ thuật kiểm thử tĩnh là giúp phát hiện, lường trước lỗi
cũng như các thiếu sót, nhầm lẫn có thể có trong quá trình phát triển phần mềm một
cách sớm nhất. Điều này sẽ giúp giảm chi phí, thời gian và nhân lực để sửa chữa, khắc
phục lỗi nếu xảy ra. Việc thực hiện kiểm thử tĩnh có thể bằng tay (rà soát) hoặc tự
động bằng máy (phân tích tĩnh).
Kỹ thuật kiểm thử tĩnh đòi hỏi người thực hiện phải có kiến thức và kinh
nghiệm tốt. Ngoải ra với những chương trình có độ phức tạp cao thì để thực hiện kỹ
thuật này sẽ mất rất nhiều thời gian.

1.2.1. Rà soát
Các kỹ thuật rà soát có thể chia ra làm các bước sau:
 Rà soát không chính thức (informal review): thực hiện bằng cách đọc các tài
liệu liên quan và đưa ra các ghi chú, chưa cần phải phát hiện lỗi.
 Phản biện chéo (peer review): việc rà soát được thực hiện bởi đội ngũ lập trình
dự án phần mềm, mọi người cùng tham gia thảo luận để đưa ra thống nhất
chung về vấn đề kỹ thuật cho phù hợp với dự án. Cả đội sẽ cùng nhau rà soát
mã nguồn, tìm lỗi và đưa ra cách giải quyết.
 Thông qua (walkthrough): người viết các mã nguồn, tài liệu đặc tả, thiết kế, sẽ
giải thích từng bước trước toàn đội dự án nhằm đạt được sự hiểu rõ, đồng thuận,
sau đó nhận các phản hồi góp ý của thành viên trong đội dự án và đưa ra thay
đổi hợp lý.
21


 Thanh tra (inspection): các thành viên quan trọng trong đội dự án sẽ tham gia
họp, một danh sách các vấn đề cần rà soát sẽ được lập và đưa ra để phát hiện lỗi

và sữa chữa. Thanh tra khác thông qua ở chỗ người trình bày mã nguồn, tài liệu
đặc tả, thiết kế không phải là người trực tiếp viết mà là một người khác, điều
này khiến người trình bày phải thật sự hiểu về những gì sẽ giải thích.
Vai trò của một số thành viên tham ra thực hiện kỹ thuật rà soát [6, tr.56-57]:
 Chủ tịch: người đóng vai trò chủ trì cuộc họp.
 Tác giả: người viết mã nguồn, tài liệu đặc tả, thiết kế đồng thời thực hiện các
thay đổi được đề xuất.
 Người trình bày: người trình bày các tài liệu cần rà soát, có thể là tác giả nếu ở
bước thông qua.
 Rà soát viên: người thực hiện việc nghiên cứu tài liệu, mã nguồn và đưa ra các
câu hỏi và đề xuất thay đổi.
 Thư ký: người ghi chép lại các vấn đề được phát hiện trong cuộc họp.
 Quan sát viên: những người chưa có kinh nghiệm về rà soát, tham gia cuộc họp
để học kinh nghiệm.

1.2.2. Kiểm thử dòng dữ liệu tĩnh
Một đơn vị chương trình như một hàm, một module là một chuỗi các câu lệnh thực
hiện tuần tự theo thứ tự khai báo biến, tính toán, gán giá trị, trả ra kết quả. Khi một
biến được khai báo thì cần phải được tính toán, gán giá trị và được tham chiếu trong
một bước nào đó trong đơn vị chương trình, tuy nhiên trong quá trình lập trình, biến
này có thể không được tham chiếu hoặc sử dụng không đúng gây ra lãng phí hoặc sai
sót. Từ vấn đề trên, một ý tưởng được đưa ra đó là có thể thực hiện kiểm thử theo dòng
dữ liệu. Dòng dữ liệu là một loạt các thay đổi trạng thái của biến bắt đầu từ khai báo
đến khi trả ra kết quả. Một dòng dữ liệu sẽ gồm một tập các đường đi và với mỗi
đường đi này sẽ được thiết kế một ca kiểm thử để kiểm tra tính đúng đắn của nó. Kỹ
thuật kiểm thử dòng dữ liệu chia làm hai loại là kiểm thử dòng dữ liệu tĩnh và kiểm thử
dòng dữ liệu động. Kỹ thuật kiểm thử dòng dữ liệu tĩnh không yêu cầu chạy chương
trình và có thể phát hiện các vấn đề về khai báo, gán giá trị và tham chiếu biến.
Các vấn đề bất thường về dòng dữ liệu theo [6, tr.113-114] được chia làm ba
loại:

 Loại 1: Gán giá trị rồi lại gán tiếp giá trị. Xem xét hai câu lệnh ở hình 1.3, có
hai hàm f1 và f2 với 2 tham số lần lượt được truyền vào là y1 và y2. Có thể giải
thích vấn đề này theo bốn tình huống sau:
o Câu lệnh thứ nhất dư thừa khi câu lệnh thứ hai được thực hiện.
o Câu lệnh thứ nhất bị nhầm lẫn khi lập trình, câu lệnh đúng có thể là z =
f1(y1).
o Câu lệnh thứ hai bị nhầm lẫn, câu lệnh đúng có thể là
22


o z = f2(y2).
o Giữa hai câu lệnh bị thiếu một câu lệnh khác, có thể là câu lệnh z =
f3(x).

x = f1(y1);
x = f2(y2)

Hình 1.3. Các câu lệnh tuần tự có bất thường loại 1.

Chỉ người lập trình đoạn mã nguồn này mới có thể giải thích rõ được vấn đề
thuộc tình huống nào trong bốn tình huống đã nêu. Những vấn đề bất thường như này
rất hay xảy ra nên cần phân tích mã nguồn để phát hiện.
 Loại 2: Chưa gán giá trị nhưng được tham chiếu. Xem xét câu lệnh ở hình 1.4,
biến y2 chưa được gán giá trị đã được tham chiếu để tính toán. Có thể giải thích
vấn đề này theo hai tình huống sau:
o Biến y2 bị quên gán giá trị.
o Có sự nhầm lẫn khi tham chiếu biến y2, có thể biến đáng lẽ được tham
chiếu là biến y3 đã được gán ở bước nào đó phía trên câu lệnh tính toán
này.

int x, y1 = 1, y2;
x = y1 + y2;

Hình 1.4. Câu lệnh có bất thường loại 2.

 Loại 3: Đã được gán giá trị nhưng không được sử dụng.
Huang [5] đã giới thiệu ý tưởng về trạng thái của biến trong chương trình tương
ứng với những bất thường về dòng dữ liệu theo một sơ đồ chuyển trạng thái như hình
1.5.

U
D
R
A
u
d, u, r
d, u
r
r
d
u
d
r
23


Hình 1.5. Sơ đồ chuyển trạng thái của một biến tương ứng với những bất thường về
dòng dữ liệu.
Các trạng thái của biến gồm:
 U (Undefined): trạng thái chưa được gán giá trị.

 D (Defined): trạng thái đã được gán giá trị nhưng chưa được tham chiếu.
 R (Referenced): trạng thái đã được gán giá trị và đã được tham chiếu.
 A (Abnormal): trạng thái bất thường.
Các hành động gồm:
 d: gán giá trị.
 u: chưa gán giá trị hoặc khai báo lại không gán giá trị.
 r: tham chiếu.
Có thể diễn giải sơ đồ trong hình 1.5 như sau, một biến được khai báo nhưng
chưa được gán giá trị sẽ ở trạng thái U, nếu biến này được tham chiếu (hành động r)
thì biến sẽ ở trạng thái A, tức là xảy ra bất thường. Một biến ở trạng thái D, tức là đã
được gán giá trị, nếu xảy ra hành động d thì cũng sẽ vào trạng thái A.
Việc sử dụng kỹ thuật kiểm thử dòng dữ liệu tĩnh rất hiệu quả trong việc phát
hiện ra các bất thường về biến tuy nhiên vẫn cần kết hợp với kỹ thuật kiểm thử dòng
dữ liệu động để có thể phát hiện thêm các lỗi tiềm ẩn của chương trình.

1.3. Kỹ thuật kiểm thử động
Kiểm thử động là kỹ thuật chỉ được thực hiện khi mã nguồn chương trình phần mềm
được biên dịch và chạy. Mục đích chính của kỹ thuật kiểm thử động là thẩm định xem
chương trình phần mềm có hoạt động đúng và đầy đủ các chức năng như những mong
muốn của người sử dụng hay không, do đó trong quy trình kiểm chứng và thẩm định
chất lượng phần mềm thì kiểm thử động được sử dụng trong quy trình thẩm định.
Kỹ thuật kiểm thử động chia làm hai loại là kiểm thử chức năng và kiểm thử
phi chức năng. Kiểm thử chức năng được thực hiện bằng cách sử dụng trực tiếp chức
năng cần được kiểm thử, sau đó đưa dữ liệu đầu vào và nhận được dữ liệu đầu ra. Dữ
liệu đầu ra này sẽ được so sánh với dữ liệu đầu ra được ước lượng trước đó dựa theo
dữ liệu đầu vào và tài liệu đặc tả để tìm ra lỗi hoặc thiếu sót. Kiểm thử phi chức năng
bao gồm nhiều loại như kiểm thử hiệu năng hoạt động, độ tin cậy, khả năng bảo mật,
khả năng tương thích, tính sẵn sàng.
Kỹ thuật kiểm thử động có ưu điểm là thời gian và chi phí thực hiện thấp, có thể
thực hiện được ở tất cả các mức kiểm thử. Tuy nhiên nhược điểm của kỹ thuật là đòi

hỏi phải biên dịch và chạy chương trình trước khi kiểm thử. Khi có lỗi xảy ra, rất khó
để tìm ra nguyên nhân và vị trí mã nguồn gây ra lỗi. Trong khuôn khổ luận văn, xin
trình bày ba kỹ thuật kiểm thử động là kỹ thuật kiểm thử hàm, kiểm thử dòng điều
khiển và kiểm thử dòng dữ liệu động.

1.3.1. Kiểm thử hàm