Nghiên cứu về kiểm thử mô hình ứng dụng Web

i

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




NGUYỄN VIỆT ANH



NGHIÊN CỨU VỀ KIỂM THỬ
MÔ HÌNH ỨNG DỤNG WEB


LUẬN VĂN THẠC SĨ






Hà nội - 2012


ii

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

NGUYỄN VIỆT ANH


NGHIÊN CỨU VỀ KIỂM THỬ
MÔ HÌNH ỨNG DỤNG WEB

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 NGUYỄN VIỆT HÀ




Hà nội - 2012

v

MỤC LỤC

LỜI CẢM ƠN i
LỜI CAM ĐOAN iv
MỤC LỤC v

DANH SÁCH BẢNG BIỂU vii
DANH MỤC CÁC HÌNH VẼ viii
BẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT x
CHƢƠNG 1 ĐẶT VẤN ĐỀ 1
1.1. Lý do chọn đề tài 1
1.2. Mục đích và nội dung nghiên cứu 2
1.3. Cấu trúc của luận văn 2
CHƢƠNG 2 CƠ SỞ LÝ THUYẾT 3
2.1. Các kỹ thuật kiểm thử 3
2.1.1. Khái niệm kiểm thử 3
2.1.2. Vòng đời và quy trình kiểm của việc kiểm thử 3
2.1.3. Kiểm thử hộp trắng 4
2.1.4. Kiểm thử hộp đen 8
2.1.5. Kiểm thử tích hợp 10
2.2. Kiểm thử mô hình ứng dụng Web 12
2.2.1. Ứng dụng Web là gì? 12
2.2.2. Các thành phần của ứng dựng Web 12
2.2.3. So sánh kiểm thử Web và kiểm thử truyền thống 13
2.2.4. Các kiểm thử cho ứng dụng Web 15
CHƢƠNG 3 BÀI TOÁN VÀ GIẢI PHÁP 30
3.1. Mô tả yêu cầu bài toán 30
3.2. Giải pháp giải quyết bài toán 30
3.2.1 Đầu vào cho ứng dụng kiểm thử 32
3.2.2 WebDriver 33
3.2.3 Giải pháp ghi lại kết quả đầu ra 35
CHƢƠNG 4 THỰC NGHIỆM 38
4.1. Cài đặt môi trường kiểm thử 38

vi

4.2. Xây dựng chương trình kiểm thử tự động đăng nhập ứng dụng Web 39
4.3. Các bước thực hiện kiểm thử tự động 43
4.4. Kết quả thực nghiệm 45
4.5. Ý nghĩa chương trình kiểm thử tự động 48
CHƢƠNG 5 KẾT LUẬN 49
TÀI LIỆU THAM KHẢO 50
PHỤC LỤC 51
Phụ lục A. Chương trình kiểm thử đăng nhập tự động ứng dụng Web 51
Phụ lục B. Trường hợp kiểm thử đăng bài viết mới 54
Phụ lục C. Trường hợp kiểm thử với Ẩn/Hiện bài viết 56
Phụ lục D. Một số hàm API khác 57

vii

DANH SÁCH BẢNG BIỂU
Bảng 2.1. Đánh giá yêu tố người dùng. 16

Bảng 3.2: Lựa chọn phương pháp kiểm thử 20

Bảng 4.2. Môi trường thực nghiệm 38
Bảng 4.3. Chương trình hỗ trợ kiểm thử 38
Bảng 4.4. Môi trường WebDriver 39

viii

DANH MỤC CÁC HÌNH VẼ
Hình 2.1. Vòng đời kiểm thử[3]. 3
Hình 2.2. Sơ đồ khối chu trình điều khiển. 5
Hình 2.3. Đồ thị thuật toán (a), Đồ thị luồng(b) 6
Hình 2.4. Độ phức tạp Cyclomatic. 7
Hình 2.5. Kiểm thử hộp đen. 9
Hình 2.6. Kiểm thử Top-Down. 11
Hình 2.7. Kiểm thử tích hợp dưới lên. 11
Hình 2.8. Hệ thống ứng dụng Web 3 tầng. 12
Hình 2.9. Mô hình ứng dụng cho Hệ thống máy tính 14
Hình 2.10. Các hệ thống Client – Server. 14
Hình 2.12. Tính nhất quán trong phương pháp thiết kế 16
Hình 2.13. Ứng dụng hiển thị trên IE 7. 17
Hình 2.14. Ứng dụng hiển thị trên IE 8. 17
Hình 2.15. Các lớp ODBC. 22
Hình 2.16. Tường lửa 25
Hình 2.17. Thời gian chấp nhận được của ứng dụng. 27
Hình 2.18. Sự mất mát trong kinh doanh do thời gian đáp ứng gây ra. 27
Hình 2.19. Mô hình thành phần giao tác nguồn tài nguyên. 28
Hình 2.20. So sánh trên trình duyệt IE và thiết bị di động. 29

Hình 3.1. Mô hình giải quyết bài toán 31
Hình 3.2. Quá trình thực thi 31
Hình 3.3: Kiểm thử chức năng tạo bài viết 32
Hình 3.4: Tệp tin mô tả kiểm thử việc đăng bài viết tự động 32
Hình 3.5: Mô hình hóa trực quan các trường hợp kiểm thử 33

Hình 3.6: Định vị By Id 34
Hình 3.7: Định vị Name 34
Hình 3.8: Định vị By Xpath 34

Hình 4.1. Giao diện trang chủ. 39
Hình 4.2. Giao diện đăng nhập 39
Hình 4.3. Màn hình đăng nhập thành công. 40
Hình 4.4. Bảng trạng thái tương ứng. 40
Hình 4.5. Mô hình trạng thái trực quan. 40
Hình 4.6. Mô tả quy trình với trường hợp không nhập User và Pass 41
Hình 4.7. Mô tả quy trình với trường hợp không nhập User và không nhập Pass 42
Hình 4.8. Mô tả quy trình với trường hợp không nhập Pass và không nhập User 42
Hình 4.9. Mô tả quy trình với trường hợp nhập User và Pass 43
Hình 4.10. Mô tả quy trình với trường hợp không nhập Pass và nhập User 43
Hình 4.11. Quy trình ghi kết quả ra tệp tin XML 44

ix

Hình 4.12. Quy trình ghi kết quả ra tệp tin Excel 44
Hình 4.13. Quy trình ghi xử lý việc kiểm thử ứng dụng Web 45
Hình 4.14. Kết quả ghi ra kiểm thử Login ghi ra tệp tin Excel. 46
Hình 4.15. Trường hợp đăng nhập thành công 47
Hình 4.16. Trường hợp đăng nhập không thành công 47

x

BẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT
CSDL
Cơ sở dữ liệu
HTTP
Giao thức truyền tải siêu văn bản(Hyper Text Transfer Protocol)
HTTPS
Giao thức truyền tải siêu văn bản(Sử dụng bảo mật SSL)
URL
Định danh địa chỉ tài nguyên trang mạng(Uniform Resource
Locator)
DBMS

Quản trị cơ sở dữ liệu(Database Management Systems)
V&V
Kiểm chứng và xác nhận V&V(Verification and Validation)
BVA
Phân tích giá trị biên(Boundary Value Analysis)
DLL
Thư viện liên kết động(Dynamic link library)
XML
Ngôn ngữ đánh dấu mở rộng(Extensible Markup Language)



1

CHƢƠNG 1 ĐẶT VẤN ĐỀ
1.1. Lý do chọn đề tài
Những năm gần đầy công nghệ thông tin đã và đang đạt được những bước phát
triển tích cực, cùng với sự phát triển mạnh mẽ của cơ sở hạ tầng đặc biệt là hệ thống
mạng Internet. Những ứng dụng Web phổ biến nhờ vào sự có mặt bất cứ nơi đâu của
một chương trình. Khả năng cập nhật và bảo trì ứng dụng Web mà không phải phân
phối và cài đặt phần mềm trên hàng ngàn máy tính là lý do chính cho sự phổ biến của
nó. Chính nhờ vào sự phổ biến trên mà các ứng dụng Web giờ đây không chỉ là những
ứng dụng đơn giản nữa, mà việc xây dựng các ứng dụng Web đã trở nên phức tạp hơn
rất nhiều. Các ứng dụng Web được dùng để thực hiện bán hàng trực tuyến, đấu giá
trực tuyến, quản trị quan hệ khách hàng,
Tuy nhiên để triển khai được các ứng dụng Web thì có rất nhiều vấn đề sẽ phát
sinh và ảnh hưởng trực tiếp đến các ứng dụng Web như: Tính bảo mật, hiệu suất, các
thành phần của ứng dụng Web, giao diện, chức năng, khả năng tương thích của ứng
dụng Web với trình duyệt và hệ điều hành,…
Vậy để đảm bảo chất lượng các ứng dụng Web hoạt động tốt và không có bất

kỳ vấn đề nào khi vận hành, thì cần phải đảm bảo tất cả các vấn đề trên đều được giải
quyết một cách triệt để. Muốn làm được điều đó ta phải thực hiện “Kiểm thử ứng
dụng web”, đó cũng là các bước chính đảm bảo cho toàn bộ ứng dụng web hoạt động
tốt hay không. Và sau khi thực hiện các kiểm thử chúng ta có thể tìm ra những vấn đề
phát sinh lỗi để có thể giải quyết trước khi đưa ứng dụng web vào sử dụng thực tế.
Hầu hết công việc kiểm thử đều thực hiện một cách thủ công, vì vậy việc kiểm
thử thủ công sẽ chỉ có thể tin cậy được khi ứng dụng web nhỏ và không có nhiều chức
năng, còn khi ứng dụng Web trở nên phức tạp hơn có rất nhiều chức năng thì việc
kiểm thử thủ công trên không còn đáng tin cậy và khả thi nữa. Ví dụ một vài ca kiểm
thử bị bỏ qua hoặc gặp phải lỗi người kiểm thử không thể biết được các hoạt động
được thực hiện để ghi lại những vấn đề và lỗi đó, ngoài ra việc kiểm thử thủ công có
thể tẻ nhạt và tốn thời gian (do thực hiện công việc lặp đi lặp lại, các chức năng có thể
giống nhau). Chính vì vậy cần phải có một mô hình hoạt động một cách tự động để
khắc phục những vấn đề gặp phải của kiểm thử thủ công. Tuy nhiên trong thực tế để
xây dựng một mô hình kiểm thử tự động không phải là công việc dễ dàng mà ngược
lại nó rất khó khăn và luôn tiềm ẩn lỗi. Mặc dù mô hình hệ thống đã có sẵn và hoàn
chỉnh tuy nhiên không dám khẳng định rằng hoàn toàn đúng đắn vì các ứng dụng web
luôn được thay đổi thêm bớt các hành vi hoạt động. Ngoài ra còn một khó khăn nữa là
khi thực hiện việc kiểm thử mà bên xây dựng ứng dụng và bên kiểm thử không phải là
một nơi phát triển thì khi đó chúng ta không thể có mã nguồn và tài liệu thiết kế đầy
đủ thì việc kiểm thử cũng vô cùng khó khăn.

2

Vì vậy, việc tìm hiểu nghiên cứu xây dựng mô hình ứng dụng web tự động
không chỉ có ý nghĩa trong việc xây dựng một công cụ kiểm thử tự động mà còn mang
tính thực tế cao. Do vậy, mà tôi đã quyết định chọn đề tài: “Nghiên cứu kiểm thử mô
hình cho ứng dụng Web” để nghiên cứu.
1.2. Mục đích và nội dung nghiên cứu
Trong nội dung của bài luận văn tôi tập trung vào việc nghiên cứu về kỹ thuật

kiểm thử. Và dựa trên những kiến thức về kỹ thuật kiểm thử sẽ tìm hiểu về kiểm thử
ứng dụng Web. Cuối cùng là xây dựng công cụ thực hiện việc kiểm thử tự động ứng
dụng Web dựa trên công cụ mã nguồn mở Selenium và WebDriver.
1.3. Cấu trúc của luận văn
Các phần còn lại của luận văn có cấu trúc như sau:
Chương 2 giới thiệu về khái niệm kiểm thử và các kỹ thuật kiểm thử thông
thường, và cụ thể là kiểm thử hộp trắng, và kiểm thử hộp đen. Dựa trên các kỹ thuật
kiểm thử sẽ tập trung tìm hiểu về ứng dụng Web, thành phần ứng dụng Web và các
kiểm thử đối với ứng dụng Web như: kiểm thử giao diện, kiểm thử chức năng, kiểm
thử cơ sở dữ liệu, kiểm thử hiệu năng và kiểm thử với các thiết bị di động.
Chương 3 yêu cầu bài toán về việc xây dựng công cụ kiểm thử tự động các ứng
dụng Web. Thông qua việc thực hiện trường hợp kiểm thử đăng nhập vào ứng dụng
Web. Công cụ kiểm thử tự động sẽ thực hiện việc đọc các trường hợp đầu vào từ tệp
tin Excel, sau khi thực hiện việc kiểm thử chương trình ghi kết quả quá trình kiểm thử
ra tệp tin Excel, XML và chụp ảnh màn hình để xem việc kiểm thử là thành công hay
thất bại. Và để xây dựng công cụ trên giải pháp đưa ra đó là sử dụng các hàm API
được cung cấp bởi công cụ Selenium và WebDriver.
Chương 4 thực hiện cài đặt ứng dụng Web và xây dựng các hàm API để thực
hiện việc kiểm thử, sau khi thực hiện chương trình đưa ra những kết quả đạt được
trong quá trình xây dựng công cụ kiểm thử ứng dụng Web tự động.
Chương 5 là Kết luận, hướng nghiên cứu








3

CHƢƠNG 2 CƠ SỞ LÝ THUYẾT
2.1. Các kỹ thuật kiểm thử
2.1.1. Khái niệm kiểm thử
Có rất nhiều các khái niệm khác nhau về thế nào là kiểm thử, tuy nhiên có một
khái niệm về kiểm thử của (Glen Myers) được cho là tổng quát nhất: “Việc kiểm thử là
quá trình thực thi một chương trình với mục đích là tìm ra lỗi.” [5]
Nếu hiểu theo nghĩa mục đích của (Paul Jorgensen) thì việc thực hiện kiểm thử
hiển nhiên là việc tìm lỗi (error), sai sót (fault), hỏng hóc (failure). Vì vậy kiểm thử là
một cách chạy các ứng dụng theo các trường hợp kiểm thử với mục tiêu: Tìm ra sai sót
và giải thích sự hoạt động
2.1.2. Vòng đời và quy trình kiểm của việc kiểm thử
Mục đích chính của việc kiểm thử đó là thiết kết một chuỗi các trường hợp
kiểm thử mà có khả năng phát hiện được lỗi cao. Và để cho việc kiểm thử đạt được kết
quả tốt nhất thì cần phải có sự chuẩn bị về kế hoạch kiểm thử, trải qua các công đoạn
khác nhau đồng thời phải có những biện pháp để khắc phục khi phát hiện ra lỗi.
Vòng đời của việc kiểm thử thông thường sẽ trải qua đó là: “Mô tả yêu cầu”,
“Phân tích thiết kế”, “Lập trình”, “Kiểm thử”, “Ban giao sản phẩm”.
Mô hình của một đời kiểm thử:

Hình 2.1. Vòng đời kiểm thử[3].
Từ hình vẽ trên có thể thấy rằng lỗi có thể xảy ra ở từ các giai đoạn, “Mô tả yêu
cầu”, “Phân tích thiết kế”, “Lập trình”. Và việc chuyển từ giai đoạn này sang giai
đoạn khác cũng có thể phát sinh các sai sót (do dư thừa và thiếu mô tả yêu cầu). Cuối

4

cùng đến giai đoạn kiểm thử chúng ta sẽ phát hiện ra những sai sót và cụ thể là kết quả
thu được không như mong đợi.
2.1.3. Kiểm thử hộp trắng

Kiểm thử hộp trắng (White-Box Testing) hay còn gọi là kiểm thử logic, cho
phép kiểm tra cấu trúc bên trúc bên trong của ứng dụng với mục đích đảm bảo rằng tất
cả các câu lệnh và điều kiện sẽ được thực thi ít nhất một lần.
Kiểm thử hộp trắng đúng nghĩa là kiểm thử hộp trong suốt, vì vậy mà kiểm thử
hộp trắng còn được gọi bằng một số tên khác đó là kiểm thử hộp thủy tinh (Glass-Box
Testing) hay kiểm thử trong suốt (Clear-Box Testing). Người kiểm thử truy cập vào
mã nguồn chương trình để kiểm tra và lấy nó làm cơ sở cho việc kiểm thử. Và việc
kiểm thử này dựa trên quá trình thực hiện xây dựng chương trình ứng dụng.
Kiểm thử hộp trắng còn là phương pháp kiểm thử dựa vào cấu trúc/mã lệnh của
chương trình. Phương pháp này cho phép kiểm thử một chương trình (một phần
chương trình, hay một hệ thống, một phần của hệ thống) đáp ứng tất cả các giá trị đầu
vào bao gồm cả các giá trị không đúng hay không theo dự kiến của chương trình.
Khi nói đến vần đề kiểm thử hộp trắng cần quan tâm đến vấn đề đường dẫn
lệnh trong kỹ thuật hay phương pháp này. Nếu phải thực hiện tất cả các đường dẫn của
đồ thị điều khiển trong chương trình thông quan việc chạy tất cả các trường hợp kiểm
thử thì có thể nói rằng chương trình đã được kiểm thử một cách triệt để. Tuy nhiên,
điều đó là không thể thực hiện được vì số đường dẫn logic khác nhau trong một
chương trình là rất lớn.
Ngoài những điều kiện không khả thi trên, chương trình còn có thể có rất nhiều lỗi
do các nguyên nhân khác gây ra.Và đây chính là nhược điểm của phương pháp kỹ
thuật kiểm thử hộp trắng.
- Việc kiểm thử bằng kỹ thuật hộp trắng không thể đảm bảo rằng chương trình đã
tuân theo đặc tả.
- Một chương trình bị sai do thiếu đường dẫn, việc kiểm thử hộp trắng không thể
biết được sự thiếu sót này.
- Việc kiểm thử bằng kỹ thuật hộp trắng không thể phát hiện được lỗi do dữ liệu
gây ra.
Như vậy nếu chỉ dùng kỹ thuật kiểm thử hộp trắng đế thực hiện việc kiểm thử
là không đủ để phát hiện các lỗi. Vì vậy để thiết kế các trường hợp kiểm thử để cho
việc kiểm thử triệt để thì cần phải kết hợp với kiểm thử hộp đen (Black-Box Testing).

5


Hình 2.2. Sơ đồ khối chu trình điều khiển.
a) Kiểm thử theo đƣờng dẫn
Kiểm thử đường dẫn (Basic Path Testing) là một kỹ thuật kiểm thử hộp trắng.
Phương pháp kiểm thử theo đường dẫn cho phép người thiết kế trường hợp kiểm thử
thực hiện phép đo độ phức tạp logic của thiết kế thủ tục và sử dụng phép đo này như
một chỉ dẫn cho việc thiết kế một tập cơ sở các đường dẫn thực hiện. Các trường hợp
kiểm thử đó được đảm bảo để thực hiện mỗi lệnh trong chương trình ít nhất một lần
trong quá trình kiểm thử.
Đồ thị luồng
Trong thực tế phương pháp kiểm thử đường dẫn có thể được dùng mà không
cần đồ thị luồng (Flow Graph). Tuy nhiên, đồ thị luồng là một công cụ hữu ích để hiểu
được luồng điều khiển và minh họa phương pháp tiếp cận. Trong phần này sẽ trình bày
những thành phân cơ bản cấu thành nên đồ thị luồng, và mỗi cấu trúc điều khiển tương
ứng có một ký hiệu đồ thị luồng tương ứng.
Biểu diễn điều kiện phức trong đồ thị luồng
Điều kiện phức trong câu lệnh điều kiện được biểu diễn gồm một hoặc nhiều
phép toán logic (AND, OR, NOT) và khi gặp phải điều kiện phức này cần phải được
chia thành các điều kiện đơn trong thực hiện kiểm thử đường dẫn cơ sở. Mỗi đỉnh chứa
điều kiện gọi là đỉnh điều kiện và đặc trưng bởi hai hoặc nhiều cạnh bắt nguồn từ nó.
Ngoài ra từ đồ thi thuật toán chuẩn đổi sang đồ thị luồng, ở trong ví dụ sau đấy
từ đồ thị thuật toán 2.6 (a) sẽ được chuyển thành đồ thị lường 2.6 (b)[3]

6


Hình 2.3. Đồ thị thuật toán (a), Đồ thị luồng(b)

Độ phức tạp cyclomatic
Độ phức tạp Cyclomatic được gọi là thước đo của chương trình ứng dụng, cung
cấp phép đo định lượng độ phức tạp của chương trình. Khi được sử dụng trong ngữ
cảnh của phương pháp kiểm thử đường dẫn cơ sở, giá trị được xác định độ phức tạp
Cyclomatic cho phép số lượng đường dẫn độc lập trong một tập cơ sở của chương
trình và cung cấp một giới hạn trên số lượng kiểm thử bắt buộc để đảm bảo rằng tất cả
các câu lệnh đều được thực hiện ít nhất một lần.
Vậy đường dẫn độc lập ở đây được hiểu là bất kỳ đường đường dẫn nào đi từ
đầu đến cuối chương trình và xác định một tập hợp có thêm các lệnh mới hay một điều
kiện (chưa xuất hiện trong đường dẫn trước đó).
Chúng ta có thể dễ dàng xác định được các đường dẫn động lập cho đồ thị
luồng trong hình 2.6 (b):
- Đường dẫn 1: 1-11
- Đường dẫn 2: 1-2-3-6-8-9-10-1-11
- Đường dẫn 3: 1-2-3-6-7-9-10-1-11
- Đường dẫn 4: 1-2-3-4-5-10-1-11
Mỗi đường dẫn độc lập mới sẽ đưa ra một cung. Đường dẫn 1-2-3-4-5-10-1-2-
3-6-8-9-10-1-11 không được gọi là đường dẫn độc lập vì nó có một tổ hợp các đường
dẫn đã được chỉ ra (đường dẫn 2-3) và nó sẽ không đi qua một cung mới nào.
Nếu các trường hợp kiểm thử được thiết kế để thực hiện những đường dẫn này
thì mọi lệnh trong chương trình sẽ được đảm bảo thực hiện ít nhất một lần và mọi điều
kiện sẽ được thực hiện cả hai trường hợp đúng (true) và sai (false). Tuy nhiên, tập cơ

7

sở đường dẫn không phải là duy nhất. Vì trong thực tế, một số các tập cơ sở khác nhau
có thể suy diễn cho việc thiết kế một thủ tục được đưa ra.
Và theo một số nghiên cứu đã chỉ ra rằng độ phực tạp Cyclomatic càng cao thì
xác suất lỗi càng cao. [3]

Hình 2.4. Độ phức tạp Cyclomatic.
Một số đặc điểm của độ phức tạp Cyclomatic:
- Là số đường dẫn độc lập trong tập các đường dẫn cơ bản của chương trình
- Giá trị này được xem như cận trên của số lần kiểm thử cần được thực hiện để
đảm bảo tất cả các câu lệnh được thực hiện ít nhất một lần.
Chính vì vậy việc tính toán độ phức tạp Cyclomatic rất quan trọng sẽ giúp cho
chúng ta biết có bao nhiêu đường dẫn cần tìm. Giả sử có đồ thị G, độ phức tạp
Cyclomatic V(G) sẽ được tính theo 3 cách sau đây:
1. V(G) = R, R là số vùng của đồ thị luồng.
2. V(G) = P + 1, P là số đỉnh điều kiện có trong đồ thị luồng G
3. V(G) = E – N + 2, E là số cạnh của đồ thị, N là số đỉnh của đồ thị
Để hiểu rõ hơn về độ phức tạp của đồ thị luồng, quay lại hình vẽ 2.6 (b) chúng
ta thực hiện tính độ phức tạp Cyclomatic như sau:
1. V(G) = 4, Có 4 vùng
2. V(G) = 3 + 1 = 4, có 3 đỉnh điều kiện
3. V(G) = 11 – 9 + 2 = 4, Có 11 cạnh, 9 đỉnh
Vậy độ phức tạp trong độ thì luồng hình 2.6 (b) là 4.
b) Kiểm thử cấu trúc điều khiển
Ở trên chúng ta đã hiểu được kiểm thử đường dẫn cơ sở là phương pháp đơn
giản và hiệu quả. Tuy nhiên nếu chỉ sử dụng kiểm thử đường dẫn cơ sở thì chưa đủ
được vì vậy chúng ta cần xem xét các biến thể trên kiểm thử cấu trúc điều khiển mà có
khả năng phủ kiểm thử mở rộng và hoàn thiện chất lượng của kỹ thuật kiểm thử hộp
trắng.

8

Kiểm thử điều kiện (Condition Testing): là phương pháp thiết kế trường hợp
kiểm thử thực thi các điều kiện logic trên 2 giá trị true và false.
Kiểm thử luồng điểu khiển (Control Flow Testing): là một phương pháp kiểm
thử của kiểm thử hộp trắng tạo ra một bộ giá trị bao phủ toàn bộ những trường hợp có

thể xảy ra với các thành phần của một chương trình. Kiểm thử luồng điều khiển bao
gồm:
- Phương thức (Method)
- Cậu lệnh (Statement)
- Nhánh (Branch)
- Điều kiện (Condition)
Kiểm thử luồng dữ liệu: Phương pháp kiểm thử luồng dữ liệu (Data Flow
Testing) lựa chọn các đường dẫn kiểm thử của chương trình dựa vào vị trí khai báo và
sử dụng các biến trong chương trình. Với kiểm thử luồng dữ liệu mỗi câu lệnh được
gán một số hiệu duy nhất và mỗi hàm khi thực hiện không thay đổi tham số và biến
toàn cục.
Kiểm thử vòng lặp: Vòng lặp là cấu trúc cơ bản của cho hầu hết các giải thuật,
tuy nhiên chúng ta thường ít quan tâm đến nó khi thực hiện kiểm thử ứng dụng. Kiểm
thử vòng lặp (Loop Testing) là một kỹ thuật của kiểm thử hộp trắng được dùng để
kiểm thử tính hợp lệ của cấu trúc lặp.
2.1.4. Kiểm thử hộp đen
Kiểm thử hộp đen (Black – Box Testing) hay còn gọi là kiểm thử chức năng,
việc thực hiện kiểm thử này không cần quan tâm đến thiết kế và mã nguồn chương
trình. Kiểm thử hộp đen chỉ quan tâm đến các chức năng của ứng dụng đã được đề ra.
Vì vậy kiểm thử loại này chỉ cần 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?
Ngoài ra kiểm thử hộp đen còn được hiểu là kiểm thử hướng dữ liệu (data –
driven) hay kiểm thử hướng vào ra (input/output driven). Và với khái niệm này thì
người kiểm thử coi ứng dụng như một chiếc hộp đen, có nghĩa là không quan tâm đến
cấu trúc và hoạt động bên trong của chương trình. Kiểm thử hộp đen cho phép các kỹ
thuật viên kiểm thử xây dựng các nhóm dữ liệu đầu vào mà sẽ thực thi đầy đủ các yêu
cầu chức năng của chương trình.
Tuy nhiên, kiểm thử hộp đen không phải là một kỹ thuật thay thế cho kỹ thuật
kiểm thử hộp trắng mà là một phương pháp bổ sung giúp phát hiện các loại lỗi khác

nhau của phương pháp kiểm thử hộp trắng.
Kiểm thử hộp đen thực hiện các trường hợp kiểm thử để cố gắng tìm ra các loại
lỗi sau:

9

- Thiếu hoặc sai chức năng
- Lỗi cấu trúc dữ liệu hay dữ liệu bên ngoài
- Lỗi giao diện
- Lỗi bắt đầu hay kết thúc chương trình
- Lỗi thực thi chương trình
Khác với kiểm thử hộp trắng thường được thực thi rất sớm để phát hiện lỗi, còn
với kiểm thử hộp đen thường thực thi sau cùng vì nó không quan tâm đến cấu trúc điều
khiển mà chỉ tập trung vào miền thông tin. Nếu như mong muốn sử dụng phương pháp
này để tìm ra tất cả các lỗi trong chương trình thì điểu kiện bắt buộc là phải kiểm thử
tất cả các giá trị đầu vào, bởi vì nếu chỉ kiểm thử một giá trị đầu vào thôi thì không
dám đảm bảo chương trình có lỗi hay không. Tuy nhiên, điều này trong thực tế là
không thể thực hiện được.

Hình 2.5. Kiểm thử hộp đen.
a) Phân chia tƣơng đƣơng
Như trình bày ở trên về kiểm thử hộp đen, muốn thực hiện kiểm thử tất cả đầu
vào là điều không thể thực hiện được. Chính vì vậy mà cần phải thực hiện việc phân
chia (nếu có thể) các lớp đầu vào để tạo ra một tập hợp các đầu vào nếu có thể. Phân
chia tương đương sẽ bao gồm hai tính chất:
- Mỗi trường hợp kiểm thử nên gồm nhiều điều kiện đầu vào khác nhau có thể để
giảm thiểu tổng số các trường hợp kiểm thử.
- Nên cố gắng phân chia miền đầu vào của một chương trình thành một số xác
định các lớp tương đương sao cho có thể giả định hợp lý rằng việc kiểm thử
một giá trị đại diện của mỗi lớp là tương đương với việc kiểm thử một giá trị

bất kỳ của lớp đó.
b) Phân tích giá trị biên (BVA – Boundary Value Analysis)
Các điều kiện biên là tình trạng trực tiếp ở phía trên và dưới của các lớp tương
đương đầu vào và lớp tương đương đầu ra. Việc phân tích giá trị biên khác với phương
pháp phân chia tương đương ở hai điểm:
- Từ mỗi lớp tương đương, phân chia tương đương sẽ chọn phân tử bất kỳ làm
phần tử đại diện, trong khi phân tich giá trị biên sử dụng một hoặc một số phần
tử. Như vậy mỗi biên của lớp tương đương là đích của kiểm thử.

10

- Không chú ý tập trung vào những điều kiện đầu vào, các trường hợp kiểm thử
cũng được suy ra từ việc xem xét các kết quả ra (tức là các lớp tương đương
đầu ra)
c) Kỹ thuật đồ thị nhân quả
Đồ thị nhân quả (Cause – Effect Graph) là một phương pháp giúp cho việc thiết
kế các trường hợp kiểm thử trên cơ sở đưa ra mô tả súc tích các điều kiện logic và các
hành vi kèm theo.
Đồ thị nhân qua sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết
quả cho thành phần chương trình. Mỗi nguyên nhân được biểu diễn như một điều kiện
(đúng hoặc sai) của một đầu vào, hoặc kết hợp với đầu vào. Mỗi kết quả được biểu
diễn như một biểu thức Bool biểu diễn kết quả tương ứng cho những thành phần vừa
thực hiện.
Đồ thị nhân – quả đƣợc tạo ra nhƣ sau:
- Tất cả nguyên nhân (các đầu vào) và các kết quả (các đầu ra) được liệt kê dựa
trên đặc tả và được định danh cho mỗi nhân quả.
- Các quan hệ giữa các nguyên nhân (đầu vào) và kết quả (đầu ra) được biểu diễn
trong đồ thị làm rõ ràng các quan hệ logic.
- Từ đồ thị nhân quả ta tạo ra bảng quyết định nguyên nhân và kết quả. Và các dữ
liệu kiểm thử được sinh ra trong các qui tắc của bảng này.

2.1.5. Kiểm thử tích hợp
Chúng ta thường tự đặt ra câu hỏi là khi mọi module đã được kiểm thử đơn vị
xong, nếu tất cả chúng đều làm việc tốt riêng biệt thì tại sao chúng ta lại hoài nghi khi
kết hợp các module riêng biệt đó với nhau? Vậy vấn đề ở chỗ là khi chúng ta thực hiện
gắn chúng với nhau và làm giao diện cho chúng, thì từ đây dữ liệu có thể mất qua giao
diện, một module có thể gặp vần đề sẽ ảnh hưởng đến module khác, các chức năng con
khi kết hợp lại không tạo ra một chính năng chính như mong muốn.
Kiểm thử tích hợp là một kỹ thuật hệ thống xây dựng cấu trúc chương trình
trong khi đồng thời tiến hành các kiểm thử để phát hiện lỗi liên kết với giao tiếp. Mục
đích là lấy các module đã được kiểm thử đơn vị xong và xây dựng nên một chương
trình được quy định bởi thiết kế.
a) Kiểm thử tích hợp từ trên xuống
Kiểm thử tích hợp trên xuống (Top-Down) là tiếp cận tằng dần tới việc xây
dựng cấu trúc chương trình. Các module được tích hợp bằng cách đi dần xuống qua
các cấp bậc điều khiển, bắt đầu với module chính. Các module phụ thuộc vào module
chính sẽ được tổ hợp dẫn vào trong cấu trúc theo chiều sâu trước hoặc chiều rộng
trước.

11


Hình 2.6. Kiểm thử Top-Down.
b) Kiểm thử tích hợp từ dƣới lên
Kiểm thử tích hợp dưới lên (Bottom-Up) bắt đầu xây dựng và kiểm thử với các
module nguyên tử (tức là các module ở mức thấp nhất trong chương trình). Chiến lược
kiểm thử dưới lên được thực hiện qua các bước sau:
1. Các module ở mức thấp được kết hợp thành các nhóm (cluster).
2. Bộ điều khiển (chương trình điểu khiển cho việc kiểm thử) được viết để phối
hợp các trường hợp kiểm thử đầu vào và đầu ra.
3. Kiểm thử nhóm.

4. Các bộ điều khiển được loại bỏ và các nhóm được kết hợp chuyển dịch lên trên
trong cấu trúc chương trình.

Hình 2.7. Kiểm thử tích hợp dưới lên.

12

2.2. Kiểm thử mô hình ứng dụng Web
2.2.1. Ứng dụng Web là gì?
Trong kỹ thuật phần mềm, một ứng dụng Web hay một Webapp là một trình
ứng dụng mà có thể tiếp cận qua web thông qua mạng như Internet.
Các ứng dụng Web là các ứng dụng phần mềm trên nền tảng độc lập được chạy
trên web server hoặc trên ứng dụng server, cùng với giao diện người dùng với trình
duyệt web của phía người dùng. Đồng thời thực hiện việc giao tiếp thông qua mạng
máy tính. Kiến trúc ứng dụng của các ứng dụng web được gọi là mô hình Client –
Server. Trong mô hình này Client gửi yêu cầu đến Server, Server lần lượt xử lý các
yêu cầu và cung cấp các câu trả lời cho phía Client. Điều này có nghĩa là chu trình đáp
ứng yêu cầu và đặt nền tảng cho các ứng dụng Web. Hầu hết các ứng dụng web sử
dụng giao thức HTTP.
2.2.2. Các thành phần của ứng dựng Web
Nếu chúng ta hiểu được các thành phần bên trong của một ứng dụng Web và sự
giao tiếp của các thành phần đó hoạt động với nhau như thế nào thì sẽ giúp cho việc
kiểm tử của chúng ta tốt hơn rất nhiều. Thông thường chúng ta hiểu được kiến trúc của
một ứng dụng Web thông qua việc đọc mã nguồn. Và một cách khác nữa là phân tích
sự giao tiếp giữa các thành phần. Tuy nhiên, chúng ta vẫn cần phải nắm được kiến trúc
của ứng dụng Web ở mức độ thành phần để có thể biết được các loại lỗi cần tìm và các
câu hỏi đặt ra.
Hệ thống Client – Server: trên Web được nhóm thành ba tầng liên quan đến
nhau: (1) các thành phần dịch vụ phía người dùng, (2) các thành phần dịch vụ xử lý,
(3) các thành phần dịch vụ dữ liệu. [5]

Hình 2.8. Hệ thống ứng dụng Web 3 tầng.
Các thành phần phần mềm: Mỗi thành phần trong một hệ thống ứng dụng web
thì cung cấp một chức năng hay một nhóm các chức năng cụ thể có liên quan đến

13

nhau. Thành phần phần mềm là ứng dụng tích hợp và các thành phần của hãng thứ ba,
thành phần dịch vụ, hệ điều hành, và các dịch vụ ứng dụng (như trình chủ Web, cơ sở
dữ liệu SQL).
Các thành phần của hãng thứ ba: Ứng dụng Web được chia làm các thành phần
nhỏ hơn được gọi Unit hay Module. Và các thành phần này bao gồm hai định dạng là
mã nguồn, nhị phân (như trong một DLL hay tệp lưu trữ JAR). Ngoài ra các thành
phần của bên thứ ba còn gồm có: thành phần Java, điều khiển ActiveX,…
Thư viện liên kết động (DLL – dynamic link library): Khi chúng ta hiểu được
DLL và các lỗi tiềm tàng chúng ta sẽ thiết kế được trường hợp kiểm thử phù hợp.
Trình chủ cơ sở dữ liệu: Được coi như những kho cơ sở dữ liệu phục vụ cho
trình chủ Web. Các ứng dụng Web sử dụng trình chủ cơ sở dữ liệu quan hệ.
Ngôn ngữ đánh dấu: HTML là ngôn ngữ đánh dấu chuẩn được sử dụng để tạo
ra các trang Web. Còn XML định dạng dữ liệu chuẩn cho phép các hệ thống hỗ trợ
XML có thể trao đổi với các hệ thống khác.
2.2.3. So sánh kiểm thử Web và kiểm thử truyền thống
Khi thực hiện kiểm thử các ứng dụng Web chúng ta cần quan tâm đến các
phương pháp phân tích và kiểm thử lỗi mới. Giả sử như chúng ta đã nắm được hết các
kỹ thuật kiểm thử thông thường, vấn đề đặt ra lúc này là áp dụng các phương pháp hay
kỹ thuật đó vào việc kiểm thử ứng dụng Web. Và để thực hiện điều này một cách hiệu
quả thì bạn cần hiểu được sự khác nhau giữa kiểm thử ứng dụng Web và kiểm thử
truyền thống thông thường.
a) Mô hình ứng dụng
Đầu tiên chúng ta cần xem xét qua mô hình ứng dụng của hệ thống máy tính so

với hệ thống Client – Server dựa trên hệ thông Web. Với hệ thống máy tính bao gồm
cả phần cứng và phần mềm nhận dữ liệu đầu vào từ người dùng, sau đó dữ liệu được
lưu trữ ở bộ nhớ trong (RAM) hay bộ nhớ ngoài ổ cứng. Hệ thống thực hiện các tính
toán để xử lý sau đó sẽ trả lại đầu ra cho người dùng thông qua các giao diện khác
nhau có thể dưới dạng bản ghi, có thể dưới mẫu văn bản,…Được mô tả hình 2.13[5]

14


Hình 2.9. Mô hình ứng dụng cho Hệ thống máy tính.
Đối với các hệ thống Client-Server, dựa trên hệ thống Web thì sẽ có các vấn đề
khác so với hệ thống máy tính thông thường. Ở đây để hoạt động được hệ thống
Client-Server cần phải có một hệ thống mạng và ít nhất là hai máy tính, một máy đóng
vai trò là Client (máy tính khách) còn một máy đóng vai trò là Server (máy tính chủ).
Trong mô hình này máy Client sẽ gửi yêu cầu đến máy chủ để máy chủ Server xử lý
sau đó sẽ trả lại kết quả được định dạng và hiển thị trong trình duyệt của trình khách.

Hình 2.10. Các hệ thống Client – Server.
b) Các ứng dụng phía Client
Trình khách của hệ thống máy khách chủ truyền thống chỉ được thực thi trên
các nên tảng chuyên biệt như hệ điều hành Windows, Linux,…Còn đối với trình khách
hệ thống Web là các ứng dụng hướng truy cập dữ liệu, và dựa trên các trình duyệt đã
được thiết kế để thực hiện xử lý các hoạt động, nó gần giống với hoạt động của hệ
thống khách chủ truyền thông. Tuy nhiên, có một điểm khác nhau cơ bản đó là trình
khác Web hoạt động trong môi trường trình duyệt Web. Trình duyệt Web cho phép

15

hiển thị thông tin dưới dạng ngôn ngữ đánh dấu (HTML) và nội dung động như Ajax,
Flash, ngôn ngữ đánh dấu mở rộng XML, CSS và các tính năng bảo mật.

c) Các ứng dụng phía Server
Các ứng dụng được phát triển phía trình chủ khác với ứng dụng trên trình khách
ở hai điểm chính sau: Thứ nhất là, các ứng dụng trên trình chủ là các chương trình
không có giao diện để người dùng cuối của hệ thống tương tác, người dùng cuối chỉ
tương tác với các ứng dụng phía trình khách. Thứ hai, các ứng dụng trên trình chủ
được thực thi liên tục, nghĩa là khi các ứng dụng trên trình chủ được khởi động thì nó
luôn thường trực để cung cấp dịch vụ cho các ứng dụng phía trình khách. Còn ở phía
trình khách muốn một ứng dụng hoạt động thì người dùng phải tương tác với ứng dụng
đó thông qua giao diện.
2.2.4. Các kiểm thử cho ứng dụng Web
Như các mục đã phân tích ở trên thì chúng ta đã nắm được thế nào là một ứng
dụng Web, các thành phần của một ứng dụng Web là gì, và đã có sự so sánh giữa kiểm
thử thông thường và kiểm thử ứng dụng Web. Vấn đề đặt ra lúc này là để kiểm thử
một ứng dụng Web chúng ta cần quan đến những vấn đề gì?
a) Kiểm thử Giao diện ngƣời dùng
Vấn đề đầu tiên trong kiểm thử ứng dụng Web chúng ta cần xem xét đến đó là
“Kiểm thử Giao diện người dùng”. Khi xây dựng một giao diện ứng dụng Web chúng
ta phải quan tâm đến tư tưởng của người thiết kế xem mục tiêu thiết kế giao diện đó áp
dụng cho lĩnh vực gì, và tư tưởng của người phát triển xem sử dụng công nghệ gì để
xây dựng giao diện.
Kiểm thử thiết kế giao diện ngƣời dùng
Kiểm thử giao diện người dùng là cách để đưa ra đánh giá mức độ một thiết kế
có thỏa mãn yêu cầu người dùng hay không? Giao diện có tính dễ sử dụng, và ở đây
vấn đề nhìn và cảm nhận được xem xét kiểm thử một cách hết sức cẩn thận. Khi thực
hiện kiểm thử thiết kế giao diện người dùng cần chú ý đến khả năng phù hợp về thiết
kế, chỉ ra được các vùng thiết kế có thể dẫn người dùng đến trạng thái lỗi và chỉ được
ra cái mà người dùng mong đợi.
Người dùng ứng dụng: Thực hiện thiết kế luôn chú trọng đến phần đông người
sử dụng tuy nhiên cũng cần phải biết được nhu cầu và đặc điểm của người dùng ứng
dụng Web đó là một yếu tố quan trọng để đánh giá thiết kế giao diện cho ứng dụng đó.

Kiểm thử giao diện người dùng thì luôn có hai đối tượng cần quan tâm: 1 – người
dùng phía trình chủ, 2 – người dùng phía trình khách.


16

Ở đây chúng ta có thể sử dụng một mẫu để thu thập đánh giá được những yếu tố
liên quan đến người sử dụng:
Thuộc tính
Mức độ kinh nghiệm
0 – không có, 1- thấp, 2 – trung bình, 3 - cao
Kinh nghiệm về máy tính
3
Kinh nghiệm về Web
3
Kinh nghiệm về ứng dụng thực tế
0
Bảng 2.1. Đánh giá yêu tố người dùng.
Xem xét và xây dựng thiết kế: Ở phần trên chúng ta đã hiểu được các yêu tố liên
quan đến người dùng, ở mục này cần phải thiết kế cho ứng dụng. Vì mỗi người dùng
khác nhau và ứng dụng khác nhau yêu cầu được thiết kế khác nhau.
Mặc dù có rất nhiều phương pháp thiết kế được sử dụng, người kiểm thử ở đây
không phải là đánh giá xem phương pháp nào tốt nhất. Tuy vậy, chúng ta cũng không
nên bỏ qua các lỗi thiết kế, và công việc của chúng ta là chỉ ra sự không nhất quán của
sự cài đặt giao diện.

Hình 2.11. Tính nhất quán trong phương pháp thiết kế.
- Tương tác của người dùng: Khi người dùng sử dụng ứng dụng sẽ có rất nhiều
loại thao tác dữ liệu như quan bàn phím, chuột. Các phương pháp thao tác dữ
liệu được tạo ra thông qua điều khiển giao diện màn hình, như cắt và dán, kéo

thả.
Kiểm thử thực thi giao diện ngƣời dùng
Kiểm thử thực thi giao diện là chúng ta thực hiện việc kiểm thử xem xét xem
các chức năng giao diện người dùng có hoạt động đúng đắn không? Một điều khiển
khi hoạt động độc lập thì có thể đúng đắn, nhưng khi được kết hợp lại thì hoạt động
của nó không còn đúng nữa khi đó sẽ ảnh hưởng đến các chức năng ở bên trong. Trong
thực thế thì kiểm thử thiết kế giao diện người dùng được kết hợp với kiểm thử chức
năng. Thực chất thì ranh giới giữa tính nhất quán của thiết kế và chức năng của thiết
kế không phải lúc nào cũng rõ ràng.
Kiểm thử thực thi giao diện người dùng sẽ bao gồm các phần từ giao diện cần
phải được kiểm thử:

17

- Font (kiểu chữ): Chữ có dễ đọc không? Nên để chữ nghiêng, đậm hay có chân
- Màu sắc: Có thích hợp với với màu nền,
- Đường viền (Boder): Có thể được sử dụng bao quanh các điều khiển như các
đường viền quanh các nút(button).
- Hình ảnh (Image): Kiểm tra hình ảnh có làm tăng thời gian tải không?
Chúng ta có thể thấy được lỗi giao diện gặp phải ở hai phiên bản khác nhau của
một trình duyệt cụ thể là trình duyệt IE (Internet Explorer).

Hình 2.12. Ứng dụng hiển thị trên IE 7.

Hình 2.13. Ứng dụng hiển thị trên IE 8.
b) Kiểm thử Chức năng
Kiểm tra chức năng cũng giống các trường hợp kiểm thử khác là tìm ra lỗi, tuy
nhiên kiểm thử chức năng cho phép kiểm thử cho tất cả các liên kết trong trang Web,
kết nối cơ sở dữ liệu, cách thức sử dụng trong các trang Web để gửi và nhận thông tin
của người sử dụng.

Có một số phƣơng pháp giúp cho việc kiểm thử chức năng:
Kiểm thử đơn giản chấp nhận được: Mục tiêu của kiểm thử này là kiểm tra
hành vi thích hợp của các điều khiển giao diện(text box, radio, button,…). Kiểm thử
mọi sự tồn tại của các điều khiển giao diện trên môi trang, mỗi cửa sổ, hay mỗi hội
thoại. Kiểm tra các trạng thái mặc định(được phép chỉnh sửa, hay không được phép