Đề cương kiểm thử ứng dụng web và di động (ĐHCQ)

MỤC LỤC
Bài 1: Tổng quan về kiểm thử ứng dụng Web ................................................................6
1.1 Ứng dụng Web là gì? ............................................................................................6
1.2 Các thành phần của ứng dụng Web ......................................................................9
1.3 Một số khái niệm cần phân biệt ..........................................................................17
1.4 Kiểm thử ứng dụng Web ....................................................................................21
Bài 2: Kiểm thử giao diện, kiểm thử chức năng ............................................................22
2.1 Kiểm thử giao diện người dùng ...........................................................................22
2.1.1 Kiểm thử thiết kế giao diện người dùng ........................................................22
2.1.2 Kiểm thử thực thi giao diện người dùng ........................................................34
2.1.3 Kiểm thử khả năng sử dụng và khả năng truy cập ........................................37
2.2 Kiểm thử chức năng .............................................................................................38
2.2.1 Phân loại chức năng .......................................................................................38
2.2.2 Các phương pháp kiểm thử chức năng ..........................................................38
Bài 3: Kiểm thử phía trình chủ ......................................................................................43
3.1 Kiểm thử phía trình chủ .......................................................................................43
3.1.1 Các vấn đề chung phía trình chủ....................................................................43
3.1.2 Các vấn đề về kết nối .....................................................................................43
3.1.3 Các vấn đề về nguồn tài nguyên ....................................................................45
3.1.4 Các vấn đề về sao lưu, phục hồi ....................................................................46
3.1.5 Các vấn đề về vượt qua hỏng hóc ..................................................................47
3.1.6 Các vấn đề về đa tuyến ..................................................................................47
3.2 Công cụ kiểm thử Selenium .................................................................................50
3.2.1 Giới thiệu công cụ Selenium .........................................................................50
3.2.2 Công cụ Selenium IDE ..................................................................................50
3.2.3 Công cụ Selenium WebDriver .......................................................................58
3.2.4 Công cụ Selenium Grid .................................................................................62
Bài 4: Thực hành - Sử dụng công cụ kiểm thử Selenium IDE ......................................68
Bài 5: Kiểm thử sử dụng script, kiểm thử CSDL, kiểm thử trợ giúp ............................69
5.1 Sử dụng script để kiểm thử ..................................................................................69
5.1.1 Các ngôn ngữ script .......................................................................................69

5.1.2 Ứng dụng script với việc kiểm thử ................................................................ 70
5.2 Kiểm thử cơ sở dữ liệu .........................................................................................77


5.2.1 Mối quan hệ giữa các trình chủ CSDL .......................................................... 77
5.2.2 Giao diện trình khách/SQL (client) ............................................................... 79
5.2.3 Các phương pháp kiểm thử............................................................................ 81
5.3 Kiểm thử trợ giúp ................................................................................................. 96
5.3.1 Phân tích hệ thống trợ giúp............................................................................ 96
5.3.2 Giải pháp kiểm thử trợ giúp ........................................................................ 101
Bài 6: Thảo luận - Ứng dụng công cụ Selenium trong kiểm thử ứng dụng Web ....... 105
Bài 7: Thực hành - Sử dụng công cụ kiểm thử Selenium WebDriver ...................... 106
Bài 8: Kiểm thử cài đặt, kiểm thử bảo mật ................................................................. 107
8.1 Kiểm thử cài đặt ................................................................................................. 107
8.1.1 Vai trò của các chương trình cài đặt/ xóa cài đặt ........................................ 107
8.1.2 Các tùy chọn và tính năng phổ biến ............................................................ 109
8.1.3 Các vấn đề thường gặp của cài đặt phía trình chủ ....................................... 115
8.2 Kiểm thử bảo mật............................................................................................... 117
8.2.1 Mục đích của bảo mật.................................................................................. 117
8.2.2 Phân tích sự tấn công ................................................................................... 119
8.2.3 Các khái niệm cơ bản về giải pháp bảo mật ................................................ 122
8.2.4 Các lỗ hổng và tấn công phổ biến ............................................................... 131
8.3 Công cụ kiểm thử SoapUI.................................................................................. 138
8.3.1 Giới thiệu chung .......................................................................................... 138
8.3.2 Cài đặt SoapUI ............................................................................................ 138
Bài 9: Thực hành - Sử dụng công cụ kiểm thử SoapUI ............................................ 144
Bài 10: Kiểm thử hiệu năng, kiểm thử cấu hình và khả năng tương thích.................. 145
10.1 Kiểm thử cấu hình và khả năng tương thích .................................................... 145
10.1.1 Tiếp cận kiểm thử cấu hình và khả năng tương thích ............................... 145
10.1.2 So sánh kiểm thử cấu hình và kiểm thử khả năng tương thích ................. 149

10.1.3 Các vấn đề của kiểm thử cấu hình/ khả năng tương thích ......................... 149
10.2 Kiểm thử hiệu năng .......................................................................................... 154
10.2.1 Các khái niệm kiểm thử hiệu năng ............................................................ 154
10.2.2 Các yếu tố quan trọng của kiểm thử hiệu năng ......................................... 157
10.2.3 Ba giai đoạn của kiểm thử hiệu năng ........................................................ 161
10.2.4 Thiết lập các mục tiêu, mong đợi và định nghĩa các sản phẩm kết quả .... 162
10.3 Công cụ kiểm thử Jmeter ................................................................................. 173


10.3.1 Giới thiệu chung ........................................................................................173
10.3.2 Hướng dẫn cài đặt ......................................................................................174
Bài 11: Thảo luận - Ứng dụng công cụ SoapUI và Jmeter trong kiểm thử ứng dụng
Web ..............................................................................................................................183
Bài 12: Thực hành - Sử dụng công cụ kiểm thử Jmeter ............................................184
Bài 13: Các khái niệm cơ bản về ứng dụng di động ...................................................185
13.1 Giới thiệu..........................................................................................................185
13.2 Phân loại ứng dụng trên thiết bị di động ..........................................................187
13.2.1 Ứng dụng gốc (Native applications) ..........................................................187
13.2.2 Ứng dụng Web (Web applications) ...........................................................187
13.2.3 Ứng dụng lai (Hybrid applications) ...........................................................189
13.3 Các hệ điều hành trên thiết bị di động .............................................................190
13.3.1 Hệ điều hành Android ................................................................................190
13.3.2 Hệ điều hành iOS .......................................................................................191
Bài 14: Phương pháp và kỹ thuật kiểm thử trên thiết bị di động (I) ...........................193
14.1 Thiết bị kiểm thử ..............................................................................................193
14.1.1 Các thiết bị thực .........................................................................................193
14.1.2 Máy mô phỏng và giả lập ..........................................................................193
14.1.3 Thiết bị di động đám mây ..........................................................................194
14.1.4 Tổng kết .....................................................................................................195
14.2 Các mức độ kiểm thử .......................................................................................195

14.2.1 Kiểm thử mức đơn vị (Component kiểm thửing) ......................................195
14.2.2 Kiểm thử mức tích hợp (Integration kiểm thửing) ....................................196
14.2.3 Kiểm thử mức hệ thống (System kiểm thửing) .........................................196
14.2.4 Kiểm thử mức chấp nhận (Acceptance kiểm thửing) ................................196
Bài 15: Phương pháp và kỹ thuật kiểm thử trên thiết bị di động (II) ..........................198
15.2 Công cụ kiểm thử Appium ...............................................................................198
15.2.1 Giới thiệu về Appium ................................................................................198
15.2.2 Hướng dẫn cài đặt ......................................................................................199
15.3 Tích hợp nối tiếp ..............................................................................................224
Bài 16: Thảo luận - Ứng dụng công cụ kiểm thử Selenium trên thiết bị di động .......226
Bài 17: Thực hành - Sử dụng công cụ kiểm thử Selenium cho thiết bị di động ........227
Bài 18: Các tiêu chí đảm bảo chất lượng ứng dụng di động (I) ..................................228


18.1 Độ tin cậy (Reliability) .................................................................................... 228
18.1.1 Sự gián đoạn (Interruptions) ...................................................................... 228
18.1.2 Mạng (Networks)....................................................................................... 228
18.2 Khả năng chuyển đổi (Transferability) ............................................................ 229
18.2.1 Cài đặt (Installation) .................................................................................. 229
18.2.2 Cập nhật hệ điều hành (OS updates) ......................................................... 230
18.3 Bảo mật ............................................................................................................ 230
18.3.1 Lưu trữ dữ liệu (Data storage) ................................................................... 230
18.3.2 An ninh đường truyền (Transport security) ............................................... 230
18.3.3 Bảo vệ nhị phân (Binary protection) ......................................................... 231
Bài 19: Thảo luận - Ứng dụng công cụ Appium trên thiết bị di động ........................ 232
Bài 20: Thực hành - Sử dụng công cụ kiểm thử Appium (I) ..................................... 233
Bài 21: Các tiêu chí đảm bảo chất lượng ứng dụng di động (II) ................................. 234
21.1 Khả năng sử dụng (Usability) .......................................................................... 234
21.2 Hiệu năng (Performance) ................................................................................. 234
21.2.1 Thời gian khởi động (Launch time)........................................................... 234

21.2.2 Thời gian đáp ứng (Responsiveness)......................................................... 235
21.2.3 Tuổi thọ pin (Battery life).......................................................................... 235
21.2.4 Hiệu quả sử dụng mạng (Network usage efficiency) ................................ 235
21.3 Tuân thủ lưu trữ ứng dụng (Application store compliance) ............................ 235
Bài 22: Thực hành - Sử dụng công cụ kiểm thử Appium (II) ..................................... 237
Bài 23: Các công cụ kiểm thử tự động ........................................................................ 238
23.1 Robotium.......................................................................................................... 238
23.1.1 Giới thiệu chung ........................................................................................ 238
23.1.2 Hướng dẫn cài đặt...................................................................................... 238
23.2 Các công cụ kiểm thử khác .............................................................................. 238
23.2.1 Experitest ................................................................................................... 238
23.2.2 Ranorex ...................................................................................................... 239
23.2.3 Calabash & Xamarin Test Cloud ............................................................... 240
23.2.4 Perfecto mobile .......................................................................................... 240
23.2.5 IBM Mobile Quality Assurance ................................................................ 241
23.2.6 Tổng quan về các công cụ kiểm thử .......................................................... 241
23.2.7 Các công cụ xác nhận tự động ................................................................... 242


23.3 Hướng dẫn kiểm thử ........................................................................................243
Bài 24: Thảo luận - Ứng dụng công cụ kiểm thử Robotium trên thiết bị di động ......246
Bài 25: Thực hành - Sử dụng công cụ kiểm thử Robotium.........................................247


Bài 1: Tổng quan về kiểm thử ứng dụng Web
1.1 Ứng dụng Web là gì?
Định nghĩa Web

Hình 1.1. World Wide Web
Hẳn chúng ta đã quá quen thuộc với việc gõ lên thanh URL trên màn hình Internet

Explorer (IE), Firefox, Chrome những dòng chữ: h blah…com. Từ
―Web‖ mà chúng ta đang tìm hiểu là tên gọi tắt của ―World Wide Web‖ ( chính là chữ
www bạn thấy trong URL bên trên). Khi mạng máy tính toàn cầu Internet ra đời, nó
mở ra một môi trường mạng lưới ảo kết nối mọi máy tính (như mạng nhện - web).
Trong đó, tất cả máy tính trở thành những đầu mút kết nối lẫn nhau, mỗi đầu mút chia
sẻ thông tin, tài liệu mà nó lưu trữ để tất cả đầu mút khác có thể truy cập và ngược lại.
Khi ta kết nối máy tính của mình vào bất kỳ đầu mút nào, ta cũng có thể tiếp cận thông
tin của tất cả nơi khác trên mạng lưới. Ta gọi mạng lưới đó là ―World Wide Web‖ một không gian ảo kết nối tất cả thông tin từ mọi nơi trên thế giới.
Cùng với sự phát triển không ngừng, theo thời gian tất cả máy tính kết nối trong mạng
lưới được phân hóa theo 2 mục đích chuyên biệt:
1. Server: có dung lượng lưu trữ lớn và cấu hình rất mạnh chỉ nhằm mục tiêu chia sẻ
thông tin
2. Client/Workstation: đây chính là máy tính cá nhân/thiết bị của chúng ta khi kết nối
Internet, chỉ nhằm mục đích truy cập thông tin từ nơi khác và chia sẻ một lượng
rất nhỏ thông tin.
Thêm vào đó, các loại hình chia sẻ thông tin trực tuyến không chỉ dừng lại ở việc
trao đổi và truy cập dữ liệu. Sự phát triển của công nghệ đã mở ra các loại hình dịch vụ
trực tuyến mới với đa dạng mục đích hơn: báo chí, tìm kiếm, kinh doanh trực tuyến,
thanh toán trực tuyến, email, mạng xã hội…
Vậy ứng dụng Web là gì?
Ta hãy xem xét một ví dụ đơn giản: khi bạn ―lướt Facebook‖
1. Bạn mở một trình duyệt bất kỳ, ví dụ như Firefox hoặc Internet Explorer và gõ
vào URL của trang Facebook />2. Màn hình sẽ hiện ra trang chủ quen thuộc của Facebook. Trên đó hiển thị logo
Facebook, dòng slogan ―kết nối và chia sẻ‖ quen thuộc, một form đăng nhập
username, password và một form đăng ký cho những user mới.
3. Bạn gõ username, password vào form đăng nhập và click ―Log In‖


4. Màn hình sẽ chuyển đến trang cá nhân của tài khoản mà bạn vừa đăng nhập, trên
đó hiện ra các dòng status của bạn và bạn bè

Chúng ra nói rằng trang Facebook mà bạn vừa đăng nhập ở trên là một ―Ứng dụng
Web‖ (Web Application – xin gọi tắt là WebApp). WebApp này cung cấp cho bạn (là
người dùng - một end-user) một dịch vụ mạng xã hội đến từ tập đoàn Facebook. Tất cả
mọi WebApp khi được xây dựng đều nhằm mục đích cung cấp một dịch vụ nào đó mà
chủ nhân nó muốn (vd: mạng xã hội Facebook, hộp Mail Google, báo điện tử
VNExpress, trang mua sắm Lazada). Hãy cùng phân tích chuyện gì đã xảy ra đằng sau
màn hình desktop khi bạn thực hiện 4 hành động trên:
Ở bước 1: Facebook, cũng như tất cả mọi WebApp khác, để kết nối và hoạt động
được trên mạng Internet nó cần được cài đặt lên một máy chủ (Host - Server) và đăng
ký một tên miền (vd: ―www.facebook.com‖). Khi bạn (một end-user) gõ đường URL
― vào trình duyệt web trên máy mình, ta nói rằng bạn
đang thực hiện gửi một yêu cầu (request) đến tên miền ―www.facebook.com‖ nhằm
xin phép truy cập vào WebApp Facebook. Tuy nhiên, máy móc không hiểu tiếng
người và để phía Server kia giao tiếp được với bạn thì request của bạn cần được thông
dịch qua một thứ ngôn ngữ giao tiếp mà server đó có thể hiểu được. Các trình duyệt
web (browser) như Firefox, IE, Chrome ra đời nhằm mục đích này. Chúng được cài
đặt trên máy tính của bạn (client) để thông dịch các request của bạn qua mã máy, gói
đoạn mã máy lại thành từng gói dữ liệu và gửi đến địa chỉ www.facebook.com. Hiện
nay, ngôn ngữ giao tiếp thông dụng nhất dùng để giao tiếp với các server trên Internet
là HTTP (Hypertext Transfer Protocol)
Một gói request http thường có định dạng tương tự như sau:
GET / HTTP/1.1
Host: facebook.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5)
Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
…
Ở bước 2: Khi server Host kia nhận được gói dữ liệu request của bạn, nó phân
tích và chuyển đến một trung tâm điều phối được cài sẵn trên chính nó gọi là Web
Server. Trung tâm điều phối này là một phần mềm có nhiệm vụ quản lý và điều phối

các tài nguyên của WebApp (resource). Ta hiểu tài nguyên là các thành phần cấu thành
một WebApp, trong đó có các trang web (webpage), các file hình ảnh, các file video,
các hiệu ứng chữ chạy, chữ nổi .… Web Server này đọc gói request của bạn và nó sẽ
hiểu rằng bạn đang cần truy cập vào WebApp ―Facebook‖. Nó bắt đầu áp dụng quy
trình thủ tục được lập trình sẵn là yêu cầu bạn khai báo xem bạn có tài khoản chưa
trước khi cho bạn đi xa hơn. Nó soạn ra một gói dữ liệu trả về (response) bao gồm mã
cho phép truy cập và nội dung trang web homepage của Facebook.
Một gói response http thường có định dạng tương tự như sau:


HTTP/1.1 200 OK
Date: Sat, 31 May 2015 23:59:59 GMT
Content-Type: text/html
Content-Length: 1354
<html>
<body>
(Nội dung trang web homepage Facebook).
</body>
</html>

Bạn sẽ thấy rằng ngoài thông tin quy định về ngày giờ và mã truy cập, gói dữ liệu
này còn kèm theo 2 đoạn tag <html><body>…</body></html>. Giữa 2 đoạn tag này
thường là nội dung một webpage được viết dưới định dạng HTML, CSS và Javascript.
Đây là các ngôn ngữ trình diễn nội dung web thông dụng và cũng có thể được đọc hiểu
bởi browser. Browser nhận gói dữ liệu này, biên dịch nội dung kẹp trong gói response
và vẽ lên màn hình trang web Login Facebook với đầy đủ hình ảnh và màu sắc trên
máy bạn. Và với những thông tin trình diễn trên màn hình, bạn sẽ hiểu là server muốn
bạn đăng nhập với một tài khoản để đi xa hơn. Trên webpage vẽ sẵn form để bạn nhập
username và password. Form đăng ký cũng được vẽ sẵn bên dưới để bạn hiểu là bạn
cần đăng ký nếu chưa có tài khoản.

Ở bước 3: Khi bạn nhập username, password và click ―Log In‖, cũng giống như ở
bước 1 ở trên, bạn đã thực hiện 1 thao tác gửi request để yêu cầu được truy cập vào
trang tài khoản cá nhân của tài khoản mà bạn nhập vào. Browser cũng sẽ biên dịch
request của bạn thành 1 gói http request và gửi đến server kia. Tuy nhiên, lần này có
một chút khác biệt là request này còn kèm theo 2 trường usersername và password bạn
nhập vào. Ta sẽ có một gói request đại loại như:
POST / HTTP/1.1
content-type:application/x-www-form-urlencoded;charset=utf-8
host: facebook.com
content-length: 1354
Action=GetUserHome&Username=HmacSHA256&Password=45rffdd33yyd35ggd&S
ignatureVersion=2&Versi


Ở bước 4: Tương tự như quy trình giao nhận bước 1 và 2, gói dữ liệu request lại
được chuyển đến Web Server và tại đây bắt đầu quá trình phân tích/điều hướng để
gom những tài nguyên (resource) cần thiết nhằm nhào nặn ra nội dung trang wall
facebook của bạn. Trong trường hợp này, thông tin cần được xử lý phức tạp hơn vì cần
phải truy xuất những bài post và status, hình ảnh liên quan đến tài khoản của bạn.
Webserver có thể huy động đến các cổng xử lý khác để xử lý thông tin, hiệu ứng và
truy xuất đến cơ sở dữ liệu (database) của Facebook để lấy ra những dữ liệu cần thiết
từ tài khoản của bạn. Toàn bộ quá trình xử lý này sẽ dẫn đến một kết quả cuối cùng là
tạo ra nội dung trang wall facebook dưới dạng html, css và javascript để đưa vào gói
trả về response. Browser trên máy bạn lại nhận response và bung ra trang wall
facebook cá nhân của bạn với đầy đủ status, hình ảnh và comment phong phú.
Cứ như thế, ta thấy rằng lướt web thực ra là một vòng tuần hoàn khép kín giữa
việc yêu cầu (request) và gửi trả (response) dữ liệu giữa phía người dùng (client) và
server. Phía server tạo ra nội dung web dưới dạng mã html, css. Browser ở phía client
sẽ đảm nhận vai trò nhận và vẽ lên màn hình người dùng các nội dung sống động. Khi
ta nói rằng ta xây dựng và kiểm thử một WebApp, có nghĩa rằng ta xây dựng và kiểm

thử toàn bộ hệ thống giúp tạo nên vòng tuần hoàn khép kín trên.

Hình 1.2. Mô hình hoạt động của 1 ứng dụng web (web application)
1.2 Các thành phần của ứng dụng Web
Giới thiệu tổng quan
Một hệ thống Web bao gồm các thành phần phần cứng, phần mềm và người dùng.
Trong phần này chủ yếu trình bày các thành phần phần mềm của hệ thống Web.
Kiến trúc ứng dụng phân tán
Trong một kiến trúc phân tán, các thành phần được nhóm lại thành các cụm dịch vụ
liên quan. Kiến trúc phân tán được sử dụng cho cả hệ thống khách-chủ truyền thống và
hệ thống khách-chủ trên Internet.
Hệ thống khách-chủ truyền thống

Một ứng dụng truy cập cơ sở dữ liệu điển hình gồm bốn thành phần:
1. Mã nguồn giao diện người dùng: Người dùng cuối hoặc các thiết bị
nhập/xuất tương tác với mã nguồn giao diện người dùng để thực hiện các xử


lý nhập/xuất.
2. Mã nguồn xử lý: áp dụng các luật, tính toán dữ liệu, và các xử lý dữ liệu.
3. Mã nguồn dịch vụ truy cập dữ liệu: Xử lý phục hồi dữ liệu và cập nhập dữ
liệu, hơn nữa còn gửi kết quả trả lời cho trình khách.
4. Lưu trữ dữ liệu: lưu trữ thông tin.
So sánh các hệ thống thin-client và thick-client
Khi phần lớn công việc xử lý được thực hiện ở phía trình chủ, một hệ thống như
vậy được gọi là hệ thống thin-client. Ngược lại, khi phần lớn công việc xử lý được
thực hiện ở phía trình khách, hệ thống như vậy được gọi là hệ thống thick-client.
Trong một hệ thống thin-client, giao diện người dùng thực thi trên máy khách
trong khi tất cả các thành phần khác thực thi trên máy chủ. Ngược lại, trong hệ thống
thick-client hầu hết các xử lý được thực hiện phía trình khách; ứng dụng trình khách

thực hiện xử lý dữ liệu và áp dụng các luật xử lý logic vào dữ liệu. Trình chủ chỉ có
trách nhiệm cung cấp các chức năng truy cập dữ liệu và lưu trữ dữ liệu.

Hình 1.3. Hệ thống thin-client

Hình 1.4. Hệ thống thick-client


Hệ thống khách-chủ trên Web
Các thành phần của một hệ thống khách-chủ trên Web có thể được nhóm thành ba
tầng liên quan nhau: (1) các thành phần dịch vụ người dùng (máy khách), (2) các thành
phần dịch vụ xử lý (máy chủ), (3) các thành phần dịch vụ dữ liệu (máy chủ). Trong khi
thiết kế các hệ thống này cần xem xét đến các vấn đề xử lý, hiệu năng, khả năng mở
rộng và bảo trì hệ thống.
Ví dụ của một ứng dụng Web ba tầng được mô tả như hình dưới đây

Hình 1.5. Hệ thống Web ba tầng
Với mô hình thin-client, trình chủ chịu trách nhiệm thực thi tất cả các dịch vụ. Sau
khi thu nhận và xử lý dữ liệu, chỉ một trang HTML đơn giản được trả về cho trình
khách. Ngược lại, mô hình thick-client, trình khách sử dụng các thành phần như các
điều khiển ActiceX và Java applet để xử lý dữ liệu, chúng được cài đặt và thực thi trên
máy khách. Mỗi mô hình này đòi hỏi một chiến lược kiểm thử khác nhau.

Hình 1.6. Một ứng dụng mô hình thin-client trên Web


Hình 1.7. Một ứng dụng mô hình thick-client trên Web
Trong kiểm thử các hệ thống thick-client, nên tập trung vào kiểm thử hiệu năng và
kiểm thử khả năng tương thích. Nếu các Java applet??? được sử dụng, các applet này
sẽ được gửi tới trình duyệt mỗi khi có yêu cầu (trừ khi cùng một applet được dùng

trong cùng một thể hiện (instance) của trình duyệt). Nếu applet có kích thước lớn tới
vài trăm KB, thì nó sẽ chiếm một lượng lớn băng thông để tải về với khoảng thời gian
phản hồi đáng kể.
Cho dù trên lý thuyết, các Java applet được thiết kế không phụ thuộc vào nền/ hệ
điều hành, nhưng chúng nên được kiểm thử trên nhiều trình duyệt khác nhau, vì chúng
có thể được tạo ra bởi nhiều phiên bản khác nhau của bộ công cụ phát triển phần mềm
(SDK- Software development kit). Mỗi SDK cung cấp một tập các chức năng khác
nhau. Hơn nữa, các applet cần được dịch bởi một máy ảo Java (JVM-Java Vitual
Machine). Các trình duyệt khác nhau, trên các nền khác nhau, và với các phiên bản
đều có các máy ảo khác nhau được cài đặt sẵn, mà chúng có thể chứa các lỗi về khả
năng không tương thích. Đối với các trình điều khiển ActiveX, tác động về hiệu năng
mạng chỉ xảy ra một lần. Tuy nhiên, có thể xuất hiện những lỗi không tương thích với
các trình duyệt khác với Internet Explorer và trên các hệ điều hành khác với Microsoft
Windows.
Trong hệ thống thin-client, vấn đề không tương thích ít liên quan hơn. Tuy nhiên,
vấn đề hiệu năng nên được xem xét ở phía trình chủ, là nơi các yêu cầu được xử lý, và
trên mạng, là nơi quá trình truyền dữ liệu xảy ra.
Mô hình thin-client được thiết kế để giải quyết các vấn đề không tương thích cũng
như vấn đề giới hạn về khả năng xử lý ở phía trình khách (mô hình thin-client tập
trung công việc xử lý ở trình chủ). Hơn nữa, các cập nhật được thực hiện ngay lập tức,
bởi vì các cập nhật chỉ cần được thực hiện ở phía trình chủ. Ví dụ, các thiết bị số cầm
tay (PDA - Personal Digital Assistant) không có thể thực hiện nhiều xử lý vì có bộ nhớ
nhỏ. Mô hình thin-client rất phù hợp đối với các thiết bị PDA thì hầu hết các thao tác
xử lý đều được thực hiện ở phía trình chủ và chỉ trả kết quả cuối cùng về lại cho phía
trình khách. Máy tính để bàn (hệ điều hành cung cấp nhiều khả năng xử lý) cho phép


nhiều công việc xử lý được thực hiện trên máy, do đó mô hình thick-client được
thường lựa chọn để cải thiện hiệu năng.
Các thành phần phần mềm

Một thành phần là một phần xác định của một hệ thống lớn cung cấp một chức
năng cụ thể hoặc một nhóm các chức năng liên quan nhau. Hệ thống trên Web, ví dụ
hệ thống thương mại điện tử, được kết hợp từ nhiều thành phần cứng và phần mềm.
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, các
thành phần dịch vụ, hệ điều hành (và các thành phần dịch vụ của nó), và các dịch vụ
ứng dụng (các trình chủ được đóng gói, như trình chủ Web, trình chủ SQL, và các
thành phần dịch vụ liên quan của chúng). Kiểm thử thành phần (component kiểm
thửing) là kiểm thử riêng rẽ các thành phần phần mềm, hoặc các nhóm các thành phần
nhằm phát hiện các lỗi chức năng và các lỗi tương tác. Các thành phần phần mềm quan
trọng bao gồm hệ điều hành, thành phần dịch vụ của ứng dụng phía trình chủ, và các
thành phần của hãng thứ ba.
Hệ điều hành
Các hệ điều hành mở rộng các dịch vụ và chức năng của chúng đến với các ứng
dụng. Các chức năng thường được đóng gói dưới dạng nhị phân, ví dụ như thư viện
liên kết động (DLL - Dynamic link library). Khi một ứng dụng cần truy cập một dịch
vụ, ứng dụng sẽ gọi giao diện lập trình ứng dụng (API - Application programming
interface) được định nghĩa trước. Hơn nữa, với công nghệ hướng đối tượng những
thành phần này mở rộng chức năng của nó bằng cách cung cấp các sự kiện (ví dụ, khi
một sự kiện nào đó được Nhấn đúp, hãy thực hiện hành động sau), các thuộc tính (ví
dụ khi màu nền là màu trắng và màu chữ là màu đen), và các phương thức (ví dụ loại
bỏ đi hoặc thêm một mục nào đó trong một danh sách cuộn) để cho các ứng dụng khác
truy cập.
Các thành phần dịch vụ của ứng dụng
Trình chủ được đóng gói phía trình chủ. Một trình chủ là một chương trình
phần mềm cung cấp các dịch vụ cho các chương trình phần mềm khác từ cùng một
máy cục bộ hoặc từ một máy ở xa. Phần cứng mà trên đó chương trình phần mềm trình
chủ thực khi cũng được gọi là trình chủ hay máy chủ. Tuy nhiên, các phần cứng có thể
hỗ trợ nhiều chương trình khách cùng lúc, vì vậy thông thường phần mềm được gọi là
trình chủ trong khi phần cứng được gọi là máy chủ (lưu ý trong tiếng Anh trình chủ
hay máy chủ đều gọi là Server). Các trình chủ được đóng gói cung cấp các dịch vụ và

mở rộng chức năng của chúng đến các ứng dụng khác tương tự như mô hình mở rộng
của hệ điều hành. Hai trình chủ được đóng gói thường được sử dụng trong các hệ
thống Web là trình chủ Web và trình chủ cơ sở dữ liệu. Các trình chủ Web lưu các
trang HTML mà có thể được gửi hoặc cung cấp tới trình khách Web thông qua trình
duyệt. Thông thường các trình chủ web được đóng gói cung cấp các chức năng cho
phép các ứng dụng dễ dàng được thực hiện các xử lý trên cơ sở dữ liệu. Các chức năng
này có thể được đóng gói trong một mô đun nhị phân, ví dụ như DLL. Để truy cập đến
các chức năng đó cần sử dụng các API được định nghĩa trước.


Dịch vụ phía trình khách. Ở phía trình khách một trình duyệt điển hình thường
được hỗ trợ nhiều dịch vụ, bao gồm máy ảo Java để chạy các Java applet, các trình
thông dịch script để thực thi các script.

Hình 1.8. Kịch bản có thể của các thành phần phần mềm
Các thành phần của hãng thứ ba
Ứng dụng phần mềm được chia nhỏ thành các thành phần, hay còn được gọi là các
đơn vị (unit) hoặc các mô đun (module). Trong lập trình hướng đối tượng và các công
nghệ phần mềm phân tán, các thành phần lại được hiểu với nghĩa khác: khả năng tái sử
dụng (reusability). Mỗi thành phần cung cấp một mẫu (template) mà có thể được lắp
ráp với những thành phần khác để tạo ra các ứng dụng. Các thành phần có thể được
chia thành hai định dạng: (1) mã nguồn, như trong một lớp trong lập tình hướng đối
tượng, và(2) nhị phân, như trong một DLL hoặc tệp lưu trữ Java (JAR - Java Archive).
Các thành phần nhị phân phù hợp với các vấn đề kiểm thử được đề cập ở đây.
Các thành phần ứng dụng tích hợp
Một ứng dụng tích hợp (integrated application) chứa một số thành phần, có thể
bao gồm một ứng dụng cơ sở dữ liệu thực thi trên phía trình chủ, hoặc một ứng dụng


tạo các biểu đồ trên nền Java thực thi trên phía trình chủ trong một trang HTML, mà

trang này thực thi bên phía trình khách. Ví dụ như hình dưới đây:

Hình 1.9. Java applet
Java applet được minh họa trong hình này, các thành phần phần mềm thực thi
trong ngữ cảnh của trình duyệt Web, hoặc là trong một ứng dụng chứa (container).
Một ứng dụng chứa có thể là một ứng dụng trên trình chủ Web, một ứng dụng cơ sở
dữ liệu hay bất kỳ một ứng dụng khác có thể giao tiếp với thành phần phần mềm thông
qua một giao diện chuẩn hoặc một giao thức. Điển hình là các thành phần phần mềm
được phân bố đến nhiều trình chủ khác nhau trên mạng. Sau đó các thành phần phần
mềm giao tiếp với nhau thông qua các giao diện hoặc các giao thức đã biết để truy cập
các dịch vụ cần thiết.
Thư viện liên kết động (DLL)
Thư viện liên kết động được đưa vào để cải tiến phương pháp chia sẻ các chức
năng. Một DLL là một tệp tin chứa các hàm và nguồn tài nguyên được lưu trữ độc lập
với các ứng dụng sử dụng chúng, và chỉ được liên kết đến khi có các yêu cầu. Hệ điều
hành sẽ ánh xạ DLL vào trong không gian địa chỉ của ứng dụng khi ứng dụng hoặc
một DLL khác thực hiện lời gọi đến một hàm DLL. Sau đó ứng dụng sẽ thực thi hàm
trong DLL.
Các tệp tin với phần mở rộng là DLL chứa các hàm được cung cấp cho các
chương trình khác sử dụng. Nhiều ứng dụng hoặc thành phần đồng thời có thể chia sẻ
cùng một tập các hàm và do đó chúng có thể chia sẻ cùng các DLL lúc thực thi. Nếu
một chương trình hay một thành phần được liên kết đến một DLL mà cần phải được
cập nhật, thì trên lý thuyết chỉ cần thay thế phiên bản DLL cũ bằng một phiên bản
DLL mới. Tuy nhiên điều này không đơn giản như vậy. Trong một số tình huống lỗi


có thể sinh ra trong phương án này. Ví dụ nếu một ứng dụng sử dụng một thành phần
của DLL mà thành phần đó không thể sử dụng được thì ứng dụng sẽ thất bại khi nạp.
(h5.10).

Hình 1.10. Chương trình gọi DLL
Đây là một ví dụ khác. Ứng dụng gọi thư viện liên kết động được mô tả như trong
hình 5.7 là một ứng dụng Visual Basic. Nó dùng một vài hàm được cung cấp bởi DLL
hệ thống tên là KERNEL32.DLL. Sau khi nạp ứng dụng, nhấp chuột vào nút Show
Free Memory để hiển thị dung lượng bộ nhớ vật lý còn trống.
Để cài đặt chức năng này phải viết đoạn mã xử lý sự kiện nhấp chuột trên nút
Show Free Memory. Bởi vì có một hàm hỗ trợ tên là GlobalMemoryStatus có sẵn
trong DLL hệ thống Windows tên là KERNEL32.DLL, một lập trình viên có thể đơn
giản gọi hàm này để lấy thông tin. Quy trình sử dụng một hàm trong DLL được mô tả
trong hình sau. Gọi hàm DLL khi có một sự kiện nhấp chuột trên nút Show Free
Memory.

Khai báo hàm DLL


Gọi hàm DLL
Các lỗi liên quan đến DLL
-

Thiếu DLL. Ví dụ, khi ứng dụng DLLCALLER.EXE được thực thi trên
máy tính của lập trình viên, mọi việc đều diễn ra suôn sẻ. Tuy nhiên khi
thực thi trên một máy tính khác, thông báo lỗi như hình 5.10 sẽ xuất hiện.
Ứng dụng này được tạo ra bằng Visual Basic 4.0 và phụ thuộc vào DLL trên
là VB40032.DLL. Nếu DLL đó không được cài đặt, ứng dụng sẽ không
được nạp một cách đúng đắn. Ứng dụng không thông báo về việc thiếu tệp
tin KERNEL32.DLL vì đó là một DLL hệ thống. Nếu không có nó, thì thậm
chí hệ điều hành cũng sẽ không thể hoạt động được.

-

DLL không tương thích API. Có thể có hai phiên bản khác nhau của cùng
một DLL, nếu kiểu dữ liệu, cấu trúc, hoặc số lượng các tham số thay đổi từ
phiên bản này qua phiên bản khác thì lỗi sẽ xuất hiện.

-

Các vấn đề không tương thích khác. Một trong những thuận lợi của việc
sử dụng DLL là khi tác giả của DLL cần thay đổi cài đặt của một hàm (ví
dụ, để cải thiện hiệu năng) nhưng không phải là API, sự thay đổi này trong
suốt đối với các ứng dụng gọi DLL này - nghĩa là, không có vấn đề gì xảy
ra. Tuy nhiên, điều này không phải luôn luôn đúng. Bạn phải kiểm thử để
khẳng định khả năng tương thích với ứng dụng của bạn.

Hình 1.11. Lỗi gây ra do thiếu DLL
Scripts
Bên phía trình chủ các đoạn script thường được sử dụng để chuyển đổi dữ liệu
từ dạng này sang dạng khác, như thế đâu ra từ một chương trình được sử dụng bởi một
chương trình khác. Điều này được gọi là ―mã liên kết‖ (glue code). Một ví dụ thường
gặp là dùng một loại script đơn giản để lấy dữ liệu từ cơ sở dữ liệu và gửi đến chương
trình xuất báo cáo. Ngày nay cách này được sử dụng một cách rộng rãi trong Active
Server Page (ASP), một công nghệ của Microsoft và Java Server Page (JSP), một công
nghệ của Sun Microsystem: dữ liệu được lấy từ trình chủ Web và được định dạng cho
trình duyệt của người dùng. Chúng ta sẽ đề cập nhiều hơn về ASP và JSP ở phần sau
trong chương này.
Liên quan đến mã liên kết và các bộ lọc
1.3 Một số khái niệm cần phân biệt
a) Precision (tập chung) và accuracy (chính xác)
Là một kiểm thửer, điều quan trọng là bạn phải biết sự khác nhau
giữa precision và accuracy. Hãy coi như bạn đang kiểm thử phần mềm Calculator.

Bạn có nên kiểm tra rằng các câu trả lời phần mềm trả về cho bạn
là precise hay accurate? Hay cả hai? Nếu lịch làm việc của dự án buộc bạn phải đưa ra
những quyết định dựa trên sự rủi ro và bạn chỉ được chọn một trong những từ này, khi
đó, bạn sẽ chọn từ nào?
Nếu phần mềm mà bạn kiểm tra là mô phỏng một chò chơi như bóng chày hoặc mô
phỏng một chuyến bay. Trước hết, bạn có nên kiểm tra khả năng precision của nó hoặc
khả năng accuracy của nó?
Hình dưới mô tả một cách hình ảnh về 2 thuật ngữ này. Mục đích của trò phóng phi
tiêu này (dart game) là ném trúng vào tâm của tấm bảng. Phi tiêu trên tấm bảng phía
trên bên trái là không precise mà cũng không accurate. Chúng không được tập chung
lại cùng nhau mà cũng không trúng tâm của tấm bảng.

Những cây phi tiêu trên tấm bảng giải thích về sự khác nhau giữa 2 thuật ngữ
Precision và Accuracy
Tấm bảng phía trên, bên phải biểu diễn những cây phi tiêu precise nhưng
không accurate. Chúng tập chung lại thành một nhóm, vì vậy người ném đã thực
hiện precision, nhưng anh ta không accurate bởi vì các cây phi tiêu không trúng đích.
Tấm bảng ở phía dưới, bên trái là một ví dụ về sự accuracy nhưng lại thiếu
sự precision. Nhưng cây phi tiêu này đều trúng đích. Người ném đã ném trúng mục
tiêu mà anh ta nhắm đến, nhưng những cây phi tiêu không nằm tập chung tại một vị
trí.
Tấm bảng ở phía dưới, bên phải là sự kết hợp hoàn hảo của precision và accuracy. Các
cây phi tiêu tập chung tại một chỗ và đều trúng đích.
Phần mềm bạn kiểm tra cần có đạt precise hay accurate hay không phụ thuộc rất nhiều
vào cái đích mà sản phẩm cuối cùng của bạn hướng tới. Phần mềm Calculator giống là
phần mềm đòi hỏi cả hai yêu cầu đều phải đạt được. Nhưng, cũng có thể quyết định
rằng Calculator sẽ chỉ đạt yêu cầu về sự chính xác (accurate) và sự tập chung
(precise) đạt tới chữ số thập phân thứ 5. Sau tất cả, sự tập chung (precision) có thể
thay đổi. Tùy thuộc vào việc kiểm thửer nhận thức về bản đặc tả như thế nào. Họ có

thể tự thiết kế những bài kiểm tra của họ để chứng minh những nhận định của họ.
b) Verification (sự kiểm tra) và Validation (sự xác nhận)


Verification và Validation thường được sử dụng thay thế cho nhau nhưng thực chất
chúng là các khái niệm khác nhau. Sự khác nhau này rất quan trọng trong kiểm thử
phần mềm.
Verification là quy trình xác nhận rằng một số khía cạnh của phần mềm là phù hợp với
bản đặc tả của nó. Validation là quy trình xác nhận rằng phần mềm phù hợp với yêu
cầu của người sử dụng. Chúng có vẻ như rất giống nhau, nhưng một lời giải thích cho
các vấn đề kính thiên văn không gian Hubble (Hubble space telescope) sẽ giúp biểu
diễn sự khác nhau này.
Vào tháng 4 năm 1990, Kính thiên văn không gian Hubble (Hubble space
telescope) được đưa vào quỹ đạo quanh trái đất. Là một thiết bị phản chiều, Hubble sử
dụng một l tấm gương lớn như một phương tiện chính để khuếch đại đối tượng mà nó
nhằm tới. Quá trình chế tạo tấm gương này là đỏi sự chính xác và tập chung tuyệt đối.
Kiểm tra tấm gương rất khó, từ khi chiếc kính thiên văn này được thiết kế để sử dụng
trong không gian và người ta không thể xác định được vị trí, thậm chí là nó có tầm
nhìn xuyên suốt ngay cả khi nó vẫn ở trên trái đất. Với những lý do này thì chỉ có một
cách kiểm tra tốt nhất là đo đạc cẩn thận tất cả các thuộc tính của nó và so sánh với
những tiểu chuẩn đã được chỉ ra. Quá trình kiểm tra này đã được thực thi
và Hubble được tuyên bố là đã sẵn sàng.
Nhưng thật không may, ngay sau khi nó được đưa vào quỹ đạo hoạt động, các bức ảnh
nó gửi về không hề có trung tâm. Tổ chức điều tra đã khám phá ra rằng tấm gương đã
được chế tạo không hợp lý. Khi ở trên mặt đất, tấm gương này đã được sản xuất theo
đúng bản đặc tả, nhưng bản đặc tả này lại sai. Tấm gương vô cùng precise nhưng nó
không accurate. Quá trình kiểm tra đã xác nhận rằng tấm gương được sản xuất đã đáp
ứng được sự kiểm tra của bản đặc tả (spec verification), nhưng nó không xác nhận
được rằng nó đáp ứng được yêu cầu cơ bản (original requirementvalidation).
Năm 1993, một phái đoàn trên tài con thoi đã sửa kính thiên văn Hubble bằng cách cài

đặt một ―corrective len‖ để lấy lại trung tâm của những bức ảnh được chụp
bởi Hubble.
Mặc dù không có một ví dụ về phần mềm, verification và validation áp dụng tốt như
nhau với quá trình kiểm thử. Chứa từng có bản đặc tả nào là đúng. Nếu bạn thay đổi
bản đặc tả và thông qua sản phẩm cuối cùng, thì bạn sẽ tránh được những vấn đề như
với chiếc kính thiên văn Hubble.
c) Quality (chất lượng) và reliability (sự đáng tin cậy)
Trong cuốn từ điển của trường cao đẳng Merriam-Webster đã định nghĩa
rằng quality là ―độ đo sự hoàn hảo‖ hoặc ―sự vượt chội về thứ hạng‖. Nếu sản phẩm
phần mềm có chất lượng cao, nó sẽ đáp ứng được nhu cầu của khách hàng. Khách
hàng sẽ cảm thấy sản phẩm hoàn hảo và nó sẽ được sắp thứ hạng cao hơn trong danh
sách lựa chọn của khách hàng.
Kiểm thửer có thể cảm thấy 2 khái niệm quality và reliability là gần như nhau. Họ cảm
thấy rằng nếu như họ có thể kiểm tra một chương trình cho đến khi nó chạy ổn định và
có thể tin tưởng được (realiability). Khi đó, họ có thể quả quyết rằng sản phẩm đã đạt
chất lượng tốt. Nhưng thật không may, điều này không hẳn đã đúng. Reliability chỉ là
một khía cạnh của quality.
Quan niệm về quality của người sử dụng phần mềm có thể bao gồm cả sự thoải mái
của các feature, sản phẩm có khả năng chạy trên cả những PC cũ, dịch vụ hậu mãi của


các công ty phần mềm, và thường bao gồm cả giá cả của sản phẩm. Sự tin tưởng hoặc
cách thức mà phần mềm thâm nhập vào dữ liệu của khách hàng, có thể là rất quan
trọng, nhưng không phải lúc nào cũng thế.
Chắc rằng, với một chương trình có chất lượng cao và đáng tin cậy, thì kiểm thửer phải
kiểm tra và thông qua trong suốt quá trình phát triển sản phẩm.
d) Testing (Kiểm thử) và quality assurance (đảm bảo chất lượng) (QA)
Cặp khái niệm cuối cùng là testing và quality assurance (có thể viết tắt là QA). Hai
thuật ngữ này, một cái thường được sử dụng để mô tả nhóm hoặc quá trình kiểm tra và
xác nhận chất lượng phần mềm. Bạn sẽ được tìm hiểu nhiều hơn về thước đo chất

lượng phần mềm, nhưng trước tiên hãy xem xét những khái niệm sau:



Mục đích của testing là tìm ra lỗi, tìm thấy chúng sớm nhất có thể, và đảm bảo rằng
chúng đã được sửa.
Trách nhiệm chính của người QA là tạo và bắt phần mềm phải tuân theo các chuẩn để
cải tiến quy trình phát triển phần mềm và ngăn chặn các lỗi xuất hiện bất cứ lúc nào
Dĩ nhiên, 2 khái niệm này vẫn có sự chồng chéo nhau. Một số tester sẽ làm nhiệm
vụ QA, một số thì thực thi việc kiểm tra. Hai công việc này cùng các nhiệm vụ của nó
có quan hệ chặt chẽ với nhau. Tuy nhiên khó mà tránh khỏi sự lộn xộn giữa các thành
viên làm nhiện vụ kiểm thử (testing) và các thành viên đảm bảo chất lượng phần mềm
(QA).
Mô hình chữ V
Mô hình chữ V sẽ giúp chúng ta hình dung về quy trình kiểm thử trong toàn bộ kế
hoạch thực hiện dự án.


1.4 Kiểm thử ứng dụng Web
Nếu bạn hiểu đúng những nội dung trên, bạn sẽ hình dung được khi kiểm thử một ứng
dụng web:
1. Chúng ta không chỉ kiểm thử trình duyệt (browser) vì đó chỉ là 1 trình biên dịch
thông dụng cho tất cả ứng dụng web. Chúng ta cần kiểm thử ―dịch vụ‖ mà server
cung cấp cho client.
2. Quy trình (có thể) sẽ dẫn chúng ta đến việc kiểm thử ở cả 2 phía: máy client và
server.
3. Tùy vào độ lớn của dịch vụ được xây dựng, chúng ta có thể sẽ làm việc với một
vòng trao đổi dữ liệu khép kín phức tạp thông qua nhiều trình ứng dụng, đi qua
nhiều cơ sở dữ liệu, và thông qua nhiều máy chủ khác nhau trước khi có thể tạo ra
một response đến client cho user.

Phạm vi cần kiểm thử sẽ trải dài trên nhiều mảng kiến thức: kiểm thử trên một ứng
dụng server (application), kiểm thử trên một cơ sở dữ liệu (database), kiểm thử phần
nội dung hiển thị trên trình duyệt client, kiểm thử việc truyền tải dữ liệu qua lại giữa
client và server hoặc (có thể) giữa các server với nhau (API), kiểm thử các nội dung số
và có thể bao gồm cả những quy trình mã hóa dữ liệu (web standards & encryptions)


Bài 2: Kiểm thử giao diện, kiểm thử chức năng
2.1 Kiểm thử giao diện người dùng
2.1.1 Kiểm thử thiết kế giao diện người dùng
Kiểm thử thiết kế giao diện người dùng đánh giá mức độmột thiết kế ―quan tâm đến‖
người dùng, bởi cung cấp hướng dẫn rõ ràng phân tích thông tinphản hồi, và duy trì
tính nhất quán của ngôn ngữvà phương pháp. Ân tượng chủ quan về tính dễ sử dụng
(ease of use) và nhìn và cảm nhận (look end feel) được xem xét cẩn thận trong kiểm
thử thiết kế giao diện người dùngcác vấn đề liên quan đến duyệt giao diện
(navigation) luồng tự nhiên (natural flow), các nút lệnh (command), khả năng sử
dụng (usability) và khả năng truy cập (accessibility) được khẳng định trong kiểm thử
thiết kế giao diện.
Trong kiểm thử thiết kế giao diện người dùng bạn nênđặc biệt chú ý đến khả năng
phù hợp của các mặt của thiết kế. Tìm kiếm các vùng của thiết kế có thể dẫn người
dùng vào các trạng thái lỗi hoặc không chỉ ra rõ ràng điều người sử dụng mong đợi
từ chúng.
Tính thẩm mỹ, thông tin phản hồi, và khả năng tương tác nhất quánảnh hưởng trực
tiếp đến khả năng sử dụng của ứng dụng, và như thế nên được xem xét một cách cẩn
thận. Người dùng cần có thể dựa vào các gợi ý mà họ nhận được từ ứng dụngđể có
quyết định giao diện hiệu quả và hiểu được cách tốt nhấtđể có quyết định giao diện
hiệu quả và hiểu được cách tốt nhấtđể làm việc với ứng dụng. Khi các gợi ý không rõ
ràng, giao tiếp giữa người dùng và ứng dụng có thể bị phá vỡ.
Rất quan trọng để hiểu rõ mục đích của thành phần mềm được kiểm thửtrước khi bắt
đầu kiểm thử toàn diện người dùng hai câu hỏi chính để trả lời là:

1. Ai là người dùng chính của ứng dụng.
2. Phương pháp thuyết tuyến nào được sử dụng?
Mô tả sơ lược về người dùng(profiling the target users)
Kiểm thử giao diện người dùng liên quan đến hai loại người dùng chính: (1) người
dùng phía trình chủ, và quan trọng hơn,(2) người dùng phía trình khách. Người dùng
phía trình khách thường tương tác với các ứng dụng web qua trình duyệt web. Thông
thường người dùng phía trình khach không có kiến thức về kỹ thuật và kiến thức ứng
dụng như là người dùng phía trình chủ trên cùng một hệ thống. Hơn nữa các chức
năng của ứng dụng dành cho người dùng phía trình khách thường khác với các chức
năng cho người dùng phía trình chủ (thường là những người quản trị hệ thống). Vì
thế, kiểm thử giao diện phía trình khách và kiểm thuer giao diện phía trình chủ nên
được đánh giá bởi các chuẩn khác nhau.
Khi tạo ra mô tả sơ lược về người dùng (user profile), cần xem xét bốn loại tiêu
chuẩn sau cho cả người dùng phía trình khách và người dùng phía trình chủ: kinh
nghiệm về máy tính, kinh nghiệm về web, hiểu biết về lĩnh vực, và kinh nghiệm về ứng
dụng cụ thể đó.
Kinh nghiệm về máy tính
Đối với người dùng phía trình khách, kinh nghiệm về kỹ thuật có thể rất giới hạn, tuy
nhiên người dùng điển hình có thể có kinh nghiệm với một loạt ứng dụng cụ thể, như
chương trình tán gẫu(instant messaging), bảng tính, xử lý văn bản, chương trình giới
thiệu desktop, chương trình vẽ đồ họa, hoặc phần mền phát triển giảng dạy. Ngược
lại, những người quản trị hệ thống và nhân viên dịch vụ thông tin là những người cài


đặt các ứng dụng trên phía trình chủ có thể có nhiều kinh nghiệm về kỹ thuật, bao
gồm hiểu biết sâu sắc về cấu hình hệ thống và lập trình ở mức scrip. Họ cũng có thể
có các kinh nghiệm về khắc phục các sự cố, nhưng lại rất ít kinh nghiệm với các phần
mềm ứng dụng cho người dùng cuối.
Kinh nghiệm về web
Người dùng đã sử dụng các hệ thống web được bao lâu? Các hệ thống web đôi khi

yêu cầu người dùng phía trình khách phải cấu hình trình duyệt. Vì thế, kinh nghiệm
với trình duyệt phải cấu hình trình duyệt web sẽ rất là hữu ích. Người dùng có quen
thuộc với các thuật ngữ và biệt ngữ Internet, như Java, HyperText Markup Language
(HTML), extensible Markup Language (XML), proxy server... Người dùng có cần
kiến thức về các ứng dụng hỗ trợ, như Arcrobat Reader, File Transfer Protocol (FPT),
và các trình khách sử lý hình ảnh/âm thanh? Người dùng phía trình chủ được mong
dợi kiến thức về web ở mức độ nào? Họ có cần phải chỉnh sửa scrip Perl hay không?
Hiểu biết về lĩnh vực
Người dùng có quen thuộc với các vấn đề liên quan đến ứng dụng? Ví dụ, nếu
chương trình liên quan đến xây dựng các công thức trong bảng tính, thì chắc hẳn là
người dùng phải có các kỹ năng toán học và tinh toán nhất định. Rõ ràng không nên
kiểm thử chương trình như thế bởi những kiểm thử viên không có kinh nghiêm làm
việc với công thức trên bảng tính. Một ví dụ khác, hãy xem xét một ứng dụng dùng
để soạn thảo các ký hiệu âm nhạc việc xác định rõ chương trình được thiết kế cho các
nhà soạn nhạc có kinh nghiệm (hiểu rất rõ các kỹ hiệu âm nhạc) hay cho các nhà soạn
nhạc it kinh nghiệm với các ký hiệu âm nhạc, là rất quan trọng để đánh giá tnhs hiệu
quả của thiết kế. Người dùng chưa có kinh nghiệm cần các hướng dẫn cơ bản, trong
khi nguời dùng có kinh nghiệm cần các tiện ích hiệu quả. Một người dùng của hệ
thống thương mạiđiện tử là một người bán lẻ có nhiều kinh nghiệm với việc xử lý thẻ
tín dụng? Người dùng của một hệ thống bất động sản trực tuyến là một chuyên bất
động sản, người hiểu biết rất rõ về các dịch vụ bất động sản; hay người dùng chỉ là
người đầu tiên mua bán bất động sản?
Kinh nghiệm về ứng dụng cụ thể
Người dùng sẽ quen thuộc với mục đích và chức năng của chương trình nhờ vào kinh
nghiệm đã có? Đây là phần phát hành đầu tiên của sản phẩm, hay đã tồn tại nhiều
dùng trên thị trường quen thuộc với sản phẩm? Có hay không các sản phẩm phổ biến
khác trên thị trường có phương pháp thiết kế và chức năng tương tự? (Xem thêm
thông tin trong mục ―Phương pháp thiết kế‖ trong chương này).
Bảng 10.1 cung cấp cách phân loại bốn thuộc tính của kinh nghiệm người dùng. Thiết
kế giao diện người dùng nên được đánh giá mức độ mà các đặc tính của phần mềm

cần được kiểm thử phù hợp với kinh nghiệm và kỹ năng của người dùng.
Bảng 2.1.Đánh giá kinh nghiệm người dùng
MỨC ĐỘ KINH NGHIỆM
Không có = 0
Thấp = 1
Trung bình = 2
Cao = 3
THUỘC TÍNH
Kinh nghiệm về máy tính
Kinh nghiện về web
Hiểu biết về lĩnh vực

KINH NGHIỆM TỐI THIỂU


MỨC ĐỘ KINH NGHIỆM
Kinh nghiệm về ứng dụng
Một khi chúng ta đã có mô tả về người dùng của ứng dụng cần được kiểm thử,
chúng ta sẽ có thể xác định phương pháp thiết kế là phù hợp đối với người dùng đượch
hướng đến. Chúng ta cũng có thể xác định các đặc tính của ứng dụng làm cho ứng
dụng quá phức tạp hoặc quá đơn giản. Một thiết kế quá đơn giản cũng như một thiết kế
quá phức tạp có thể dẫn đến làm mất đi khả năng kha thác sản phẩm.
KIỂM THỬ ỨNG DỤNG MẪU
Bảng 2.2. Đánh giá người dùng được hướng đến của ứng dụng mẫu
MỨC ĐỘ KINH NGHIỆM
Không có = 0
Thấp = 1
Trung bình = 2
Cao = 3
THUỘC TÍNH

Kinh nghiệm về máy tính
Kinh nghiệm về web
Hiểu biết về lĩnh vực
Kinh nghiệm về ứng dụng

KINH NGHIỆM TỐI THIỂU
2-3
2-3
1-3
0

Xem xét thiết kế
Bước tiếp theo trong chuẩn bị kiểm thử giao diện người dùng là nghiên cứu thiết kế
dùng cho ứng dụng. Các loại ứng dụng và người dùng khác nhau yêu cầu các thiết kế
khác nhau.
CÁC CHỦ ĐỀ CẦN XEM XÉT KHI ĐÁNH GIÁ MỘT THIẾT KẾ
- Phương pháp thiết kế
- Tương tác của người dùng(đầu vào dữ liệu)
- Biểu diễn dữ liệu (đầu ra dữ liệu)
Phương pháp thiết kế
Các phép ẩn dụ (metaphor) trong thiết kế là cầu nối về nhận thức, giúp cho người
dùng hiểu được lô-gic của luồng giao diện bởi liên hệ với các kinh nghiệm người
dùng có thể có với trong thực tế hay ở các nơi khác. Một ví dụ của phép ẩn dụ trong
thiết kế là các danh mục web sử dụng thiết kế liên tưởng đến danh mục các thẻ của
thư viện. Một ví dụ khác về phép ẩn dụ là các ứng dụng lập lịch có giao diện như sự
bố trí của một lịch đặt bàn và một số địa chỉ liên lạc. Microsoft Word sử dụng phép
ẩn dụ dựa trên tài liệu (document- based metaphor) cho chương trình xử lý văn bản
của nó- một phép ẩn dụ phổ biến cho rất nhiều loại ứng dụng.
CÁC VÍ DỤ CẢU HAI PHÉP ẨN DỤ KHÁC NHAU TRONG THIẾT KẾ
- Hình A mô tả ứng dụng của sử dụng phép ẩn dụ dựa trên tài liệu. Nó gồm không

gian làm việc mà dữ liệu được nhập vào và được thao tác bởi cách tương tụ như
viết trên giấy.
- Hình B minh họa ví dụ phép ẩn dụ dựa trên thiết kế thiết bị (device-based
metaphor). Máy tính ảo này gồm các điều khiển giao diện được thiết kế để nhận
đầu vào của người dùng và thực hiện các hàm tính toán.


Hình 2.1. Phép ẩn dụ dựa trên tài liệu

Hình 2.2. Phép ẩn dụ dựa trên thiết bị
Hãy suy nghĩ về các vấn đề dưới đây:
Hãy ghi nhớ rằng các thẻ (tag)điều khiển(control) và đối tượng giao diện hỗ trợ bởi
HTML là rất cơ bản so với các thành phần đó trong giao diện người dùng đồ
họa(graphical user interface) có sẵn trên hệ điều hành Microsoft Windows hay
Maccintosh. Nếu người thiết kế muốn mô phỏng giao diện Windows hãy tìm các
khiếm khuyết của thiết kế.
 Nếu bạn có vấn đề để hiểu giao diện, đấy là một lỗi giao diện và người dùng
cuối sẽ có cùng vấn đề như vây.
 Giao diện người dùng thường được thiết kế một cách không có chủ ý cho người
thiết kế hay người phát triển thay vì cho người dùng cuối.
 các chức năng quan trọng thường bị hiểu sai hoặc rất khó để tìm thấy.