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

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ở

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ữ: http://www.blah 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 https://www.facebook.com/

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

―https://www.facebook.com/‖ 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:

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ư:

Ở 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

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)

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

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

THUỘC TÍNH KINH NGHIỆM TỐI THIỂU

Kinh nghiệm về máy tính

Kinh nghiện về web

Hiểu biết về lĩnh vực

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

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

 Người dùng bị bắt buộc suy nghĩ theo phép ẩn dụ thiết kế từ quan điểm của

người thiết kế, mặc dù chính phép ẩn dụ là rất khó để liên hệ đến các kinh

nghiệm trong cuộc sống thực

Các thuật ngữ khác nhau được sử dụng để mô tả cùng một chức năng

Tương tác của người dùng(đầu vào dữ liệu)

Người dùng có thể thực hiện nhiều loại thao tác dữ liệu qua bàn phím và các sự kiện

chuột Các phương pháp thao tác dữ liệu được tạo ra qua cácđiều khiển giao diện màn

hình và các công nghệ khác như các và dán(cut-and-paste) và kéo thả(drag-and-drop)

Các điều khiển giao diện người dùng (user interface control)

Các điều khiển giao diện người dùng là các đối tượng đồ họa cho phép người dùng

tương tác với ứng dụng Chúng ta cho phép người dùng khởi tạo các hoạt động, yêu

cầu hiển thị dữ liệuvà các đặc tả các giá trị dữ liệu Các điều khiển(control) thường

được mã hóa /cài đặt bởi các phần tử trong trang HTML như nút radio(radio button),

hộp kiểm tra(check box), nút điều khiển(command button), thanh cuộn(scroll bar)

trình đơn kéo xuống, trường văn bản(text filed),

Các điều khiển giao diện người dùng động (dynamic user interface controls)

Các Thẻ đa phương tiện HTML(HTML multimedia tags) cho phép sử dụng các đối

tượng giao diện động, như Java applet, điều khiển AtiveX, và scrip (gồm JavaScrip và

VBScrip)

Scrip

Scriplà những câu lệnh có thể thực thi Mở trình duyệt khi trang HTML nạp một khi

chúng được gọi dựa trên một số sự kiện Một Script ở dạng ngôn ngữ Lập trình hướng

đối tượng(object- oriented programming), nghĩa là các lệnh của chương trình được xác

định và gửi các câu lệnh đến các thành phần riêng biệt của trang web Các scrip không

cầm được biên dịch và có thể truyền trực tiếp vào các trang HTML Các script được

nhúng vào trang mã HTML với thẻ <SCRIPT>

Các script có thể được thực thi trên phía trình chủ hoặc thuyết trình khách Các script

phía trình khách thường được sử dụng để đặt các giá trị cho các điều khiển giao diện

người dùng, chỉnh sửa nội dung trang web và xử lý lỗi

Hình 2.3 Bảng, mẫu, và khung mô phỏng các điều khiển giao diện trong Windows

Có một số các ngôn ngữ Script được hỗ trợ bởi các trình duyệt phổ biến Một số trình duyệt hỗ trợ chỉ một vài ngôn ngữ Script và không hỗ trợ các ngôn ngữ Script khác JavaScript, được phát triển bởi Nestcape, là một trong những ngôn ngữ Script phổ biến nhất Các ngôn ngữ Script phổ biến khác bao gồm phiên bản JavaScript của Microsoft (Jscript) và visual Basic Script (VBScript)

Java

Java là ngôn ngữ máy tính được phát triển bởi Sun Microsystem, cho phép ứng dụng chạy qua internet (tuy nhiên các đối tượng java không chỉ giới hạn thực thi qua internet) Java là ngôn ngữ biên dịch (complied language), nghĩa là nó phải được thực thi qua một trình biên dịch (complied) để được dịch thành một ngôn ngữ mà bộ sử lý máy tính có thể sử dụng

ActiveX

ActiveX là một điều khiển Windows có thể thực thi trong các trình duyệt cho phép ActiveX (như Internet Explorer) Tương tự như Java applet, các điều khiển ActiveX hỗ trợ thực thi các đối tượng dựa trên sự kiện(event-based object) trong một trình duyệt Lợi ích chính của điều khiển ActiveX là rằng chúng là những thành phần mà có thể dễ dàng kết hợp với các thành phần khác nữalà một khi người dùng phải nhiều điều khiển ActiveX duy trì trên hệ thống của người dùng nhằm tăng tốc độ thời gian tại các trang web thường xuyên được duyệt

Server Side Includes (SSL)

SSL là các chỉ thị (directives) dành cho trình chủ web, chúng được nhúng vào trong các thẻ chú thích HTML Các chính chủ web có thể được cấu hình để đọc các chú thích trong tài liệu HTMLvà thực hiện các xử lý thích hợp khi chúng được tìm thấy Các SSL thường được sử dụng để lấy thông tin từ các nguồn khác vào trong các trang web – ví dụ, thông tin và thời gian hiện hành Ví dụ đây là một SSL (được bao giữa

các thẻ chú thích HTML) yêu cầu trình chủ web gọi một số script CGI có tên mykiểm thử.cgi

<!—exec cgi=‖/cgi-bin/mydir/mykiểm thử.cgi‖ !>

Cascading style sheet(CSS)

Là stysheet phổ biến và được phát triển nhất CSS cung cấp một hệ thống để xác định sựu ưu tiên khi nhiều chỉ thị về hình thức thể hiện tác động lên cùng một thành phần của trang web CSS có các luật để ứng dụng khi có sự động độ các chỉ thị, như thế cho phép người thiết kế web quản lý nhiều mức các luật áp dụng cho một số lượng giới hạn các trtang web

Có nhiều cách tham chiếu các style sheet Trình duyệt xem xet tất cả các thông tin về hình thức thể hiện (có thể cả sự động độ) và tìm cách thông dịch Hình 10.2 mô tả sự pha trộn nhiều hình thức thể hiện được áp dụng cho một trang Một số hình thức có thể không được tương thích với một vài trình duyệt Validator CSS của W3C có thể tải về tại htpp://jigsaw.w3.org/css-validator

Một số lỗi của điều khiển giao diện người dùng mà bạn nên xem xét bao gồm:

- Trạng thái mặc định của điều khiển giao diện là không đúng

- Một sự lựa chọn không tốt trạng thái mặc định

- Gía trị đầu vào mặc định là không đúng

- Một sự lựa chọn không tốt giá trị đầu vào mặc định

- Giá trị đầu vào được cập nhật là không đúng

- Tiêu điểm của đầu tiên không được gán cho điều khiển thường sự dụng nhiều nhất

- Nút điều khiển được sử dụng nhiều nhất không được chọn là nút mặc định

- Mẫu hay hộp thoại quá lớn hay quá dài so với độ phân giải hiển thị hỗ trợ tối thiểu (nghĩa là 800 x 600)

- Mã HTML thường được sinh ra một cách động Rất quan trọng để hiểu mã HTML được sinh ra như thế nào Đừng giả thiết rằng bạn đã kiểm thử trang đó và bạn sẽ không cần phải kiểm thử lại cho đến khi nào có sự thay đổi nào đó

- Đặt View Text Size bởi Largest hay Smallest để xem mỗi cài đặt có thể ảnh hưởng như thế nào đến giao diện người dùng

- Kiểm tra các thuộc tính ATL Một trong những mẹo của kiểm thử viên hộp đen sử dụng phát triển các thẻ ALT là tắt chọn lựa Show Pictures trong trình duyệt web Khi một trang web hiển thị, bạn sẽ dễ dàng nhìn thấy các phần tử đồ họa trong một trang và có thể nhanh chóng xác định nếu thẻ ATL bị thiếu

- Kiểm tra sự mô tả đúng đắn trong các thẻ ATL

- Tránh báo cáo nhiều liên kết bị sai hay hình ảnh bị thiếu bởi cùng một lỗi (chẳng hạn, cùng một hình ảnh được sử dụng trong 20 trang HTML bị thiếu)

- Các đầu vào không hợp lệ không được phát hiện và xử lý ở phía trình khách

- Các đầu vào không hợp lệ không được phát hiện và xử lý ở phía trình chủ

- Các script thường được sử dụng để xử lý các điều khiển giao diện chuẩn (như, đặt tiêu điểm đầu vào, đặt trạng thái mặc định ) Đấy là một công việc khá nhàm chán, và thường xuyên nảy sinh ra các lỗi Cần tìm kiếm chúng

- Script, CSS, Java applet và điều khiển ActiveX thường xuyên gây ra các lỗi không tương thích trong các phiên bản trình duyệt khác nhau của các nhà sản xuất khác nhau Bảo đảm rẳng thực thi kiểm thử khả năng tương thích cho tất cả các trình duyệt được hỗ trợ Xem thêm thông tin trong Chương 17 ―Kiểm thử cấu hình và khả năng tương thích‖

- Nếu ứng dụng của bạn sử dụng các script, CSS, Java applet, và điều khiển ActiveX, trong khi người dùng có thể không cho hoạt động một hoặc nhiều chức năng này, xác định xem ứng dụng của bạn sẽ hoạt động hay đơn giản là ngừng hoạt động

- Để nhanh chóng xác định một trang web có chứa các script, Java applet hay các điều khiển ActiveX, xin hãy đặt các lựa chọn này (script, Java applet hay điều khiển ActiveX) trong trình duyệt là Prompt Khi trình duyệt hiển thị một trang web cần các chức năng này được cho phép hoạt động, trình duyệt sẽ nhắc bạn

- Để kiểm thử vấn đề không tương hích của script (chẳng hạn Java script) giữa các trình duyệt khác nhau về phía phiên bản và nhà sản xuất, trước hết xác định trang nào sử dụng script và dùng cho mục đích gì Một khi đã tạo được danh mục các trang web này, thực thi các trang này wua mổi công cụ HTML có hỗ trợ để kiểm tra sự không tương thích của script dựa trên phương pháp phân tích tĩnh Một công cụ cung cấp sự hỗ trợ này là Dearmweaver của Macromedia

- Kiểm tra xem các trang web sẽ hiển thị đúng đắn trên các thiết bị cầm tay, chúng thường không hỗ trợ chế độ đồ họa và co màn hình tương đối nhỏ

Các phương pháp phê duyệt (navigation methods)

Các phương pháp duyệt mô tả người dùng duyệt một ứng dụng web hay hay các trang web như thế nào, từ một điều khiển giao diện đến một giao diên khác ở trong cùng một trang (màn hình, cửa sổ, hay hộp thoại) và từ một trang đến các trang khác Người dùng duyệt bằng cách sử dụng các thiết bị vào, như bàn phim, chuột Các phương pháp duyệt thường được đánh giá bởi mức độ dễ dàng chúng cho phép người dùng truy cập đến các chức năng và dữ liệu thường được sử dụng

Các ma trận hành động chuột/phím (mouse/keyboard action matrices)

Phụ lục D và E chứa các ma trận kiểm thử chi tiết các hành động chuột và bàn phím Các ma trận này có thể được cắt xén để ghi nhận bao phủ kiểm thử duyệt cho hệ thống web cần được kiểm thử

Các nút lệnh (action commands)

Đôi khi, tên của các nút lệnh trên màn hình không được sử dụng một cách nhất quán trong toàn bộ ứng dụng Điều này một phần là do ý nghĩa tên của các nút lệnh thường được biến đổi từ chương trình này sang chương trình khác Nếu các đặt tên của các mút lệnh thay đổi trong một chương trình, thì sẽ dẫn đến sự nhầm lẫn của người dùng

Ví du, nếu một nút Submit được ssuwr dụng để lưu trữ dữ liệu (data saving) trong một vùng của chương trình, thì tên nút lệnh Submit được sử dụng cho hoạt động lưu dữ liệu trong toàn bộ ứng dụng

Nên xem xét các nút lệnh được chọn là các mút mặc định Các nút điều khiển mặc định nên là các nút it chứa các lựa chọn rủi ro nhất (các nút lệnh ít có khả năng xóa dữ liệu của người dùng tạo ra)

Hình sau liệt kê một số nút lệnh thực hiện các hành động khẳng định và hủy bỏ, đi kèm theo là các y nghĩa và các quyết định mà các hành động này dẫn đến

Thực hiện và đóng hộp thoại, cửa

sổ, hay trang hiện hành

Procseed Tôi chấp nhận điều kiện được

nêu

Thực hiện và đóng hộp thoại, cửa

sổ, hay trang hiện hành

Submit Lưu dữ liệu trong mẫu, trang,

hay hộp thoại

Các nút lệnh hủy

bỏ

Cancel Tôi không chấp nhận các cài

đặt hay điều kiện được nêu Quay trở lại trạng thái trước đó và đóng hộp thoại, cửa sổ, hay

trang hiện hành

No Tôi không chấp nhận các cài Thực hiện và đóng hộp thoại, cửa

QUYÊT ĐỊNH QUYẾT ĐỊNH KÉO THEO đặt hay điều kiện được nêu sổ, hay trang hiện hành

Reset Đặt lại các cài đặt về trạng thái

trước đó

Xóa tất cả các thay đổi chưa được lưu trong hộp thoại,cửa sổ, hay trang hiện hành

Các thông điệp lỗi và phản hồi

Sự nhất quán trong các phản hồi có thể nghe và có thể nhìn là cần thiết để duy trì giao

tiếp giao tiếp giữa người dùng và ứng dụng Các thông điệp, tiếng bíp, và các hiệu ứng

âm thanh khác cần phải duy trì nhất quán và thân thiện với người dùng Đặc biệt thông

báo lỗinên được đánh giá sự sáng sủa, dễ hiểu, và sự nhất quán (xem mục ―Kiểm thử

hướng tác vụ(TOFT)‖ trong chương 11, ―Kiểm thử chúc năng‖ để có thông tin chi tiết

hơn về các thông điệp lỗi.)

Hai loại phản hồi dạng thông điệp thường được sử dụng Hình 10.14 minh họa thông

điệp lỗi điển hình phía trình khách (được sinh ra bởi kiểm tra lỗi JavaScrip trên trình

khách) sử dụng một thông báo dựa trên trình duyệt Hình 10.5 minh họa phản hồi phía

trình chủ

Hình 2.4 Thông điệp lỗi dựa trên trình duyệt

Các thông điệp lỗi phía trình khách thường hiệu qua hơn và giảm được sự quá tải trên

trình chủ và mạng so với xử lý các thông điệp lỗi phía trình chủ

Các thông điệp lỗi phía trình chủ trước hết yêu cầu dữ liệu được gửi từ trình khách đến

trình chủ và sau đó dữ liệu được trả lại từ trình chủ về trình khách, ở đó các thông điệp

lỗi được hiển thị cho người dùng

Hình 2.5 Phản hồi phía trình chủ

Một số các lỗi cần xác định bao gồm:

- Hiển thị sai thông điệp lỗi ứng với điều kiện

- Thiếu thông điệp lỗi

- Diễn đạt không tốt, sai ngữ pháp, và lỗi chính tả

- Các thông điệp không được viết cho người dùng, như thế chúng trở nên vô ích đối

với người dùng Ví dụ, ―Lỗi trình điểu khiển 80004005‖

- Thông điệp lỗi không cụ thể hoặc không mang lại giải pháp hợp lý

- Các lỗi tương tự nhưng lại được xử lý bởi các thông điệp lỗi khác nhau

- Các thông điệp lỗi không cần thiết kế làm cho người dùng rối trí

- Phản hồi không thích hợp hay giao tiếp lỗi đối với người dùng

- Các phương pháp xử lý được sử dụng cho các lỗi tương tự nhau là không nhất

quán

Biểu diễn dữ liệu (đầu ra dữ liệu)

Trong các ứng dụng web, thông tin có thể được giao tiếp với người dùng qua các điều

khiển giao diện (ví dụ, trình đơn, nút lệnh ) mà các điều khiển này có thể được tạo ra

bên trong một trang HTML (khung(trame), bảng (table), hộp thoại )

Hình 2.6, 2.7 và 2.8 ba hình thức biểu diễn dữ liệu trong ứng dụng mẫu Mỗi hình thức

chuyển tải cùng dữ liệu qua một mẫu khác nhau được xây dựng từ các khung vào bảng

trong HTML

Hình 2.6 Báo cáo lỗi trong Full View

Hình 2.7 Báo cáo cùng loại lỗi trong Edit View

Hình 2.8 Báo cáo nhiều lỗi trong Tabular View

Trong ví du của ứng dụng mẫu, có ít nhất ba loại lỗi tiềm ẩn: (1) lỗi dữ liệu(dữ liệu

không đúng trong các bản ghi do thủ tục ghi), (2) lỗi truy vấn cơ sở dữ liệu và (3) lỗi

biểu diễn dữ liệu Lỗi dữ liệu và lỗi truy vấn cơ sở dữ liệu sẽ xuất hiện trong tất cả các

trình bày, trong khi một lỗi biểu diễn dữ liệu trong script phía trình chủ sẽ chỉ xuất

hiện trong sự trình bày mà nó liên quan đến Hình 10.19 minh họa tiến trình biểu diễn

dữ liệu Lỗi xuất hiện ở đâu phụ thuộc vào lỗi ở đâu trong tiến trình

Hình 2.9 Sơ đồ biểu diễn dữ liệu

Hãy phân tích ứng để tập hợp các thông tin kiến trúc của thiết kế Một trong những cách hiệu quả là phỏng vấn một lập trình viên của bạn Một khi bạn đã tập hợp được các thông tin này hãy sử dụng chúng để phát triển các ca kiểm thử cho mức đơn vị cũng như mức tương tác

2.1.2 Kiểm thử thực thi giao diện người dùng

Kiểm thử thực thi giao diện người dùng xem xét ứng dụng về hoạt động của nó Đánh giá xem các chức năng giao diện người dùng có hoạt động đúng đắn Nếu một điều khiển giao diện không hoạt động như được thiết kế, nó có thể thất bại trong việc cho phép truy cập đến các chức năng ờ bên trong, trong khi tồn tại độc lập các chức năng

đó có thể hoạt động đúng đắn Kiểm thử chức năng thường được thực hiện đồng thời với kiểm thử thiết kế giao diện người dùng, tuy nhiên nên xem xét riêng rẽ hai loại kiểm thử này

LƯU Ý Nội dung chương này hữu ích trong việc hỗ trợ các kiểm thử chức năng đặc trưng đối với giao diện người dùng

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 luôn luôn rõ ràng Ví dụ, một liên kết văn bản có một màu sắc nào đó được duy trì nhất quán từ màn hình này sang màn hình khác, trong khung nền mà trên đó liên kết văn bản được hiển thị thay đổi Bởi vì nền thay đổi, liên kết văn bản trở nên rất khó đọc trên một số màn hình Mặc dù liên kết văn bản là rất quan trọng trong ví dụ này, màu sắc của liên kết văn bản nên được điều chỉnh để cải thiện khả năng dễ đọc

Các phần tử giao diện người dùng

Bảng 2.4 liệt kê một số phần tử giao diện người dùng cần được kiểm thử

Bảng 2.4 Các phần tử giao diện người dùng

LOẠI PHẦN TỬ CÁC VẤN ĐỀ CẦN XÉT

Kiểu chữ(fonts) Sự nhất quán của hình thức thể hiện

Khó đọc kiểu chữ nghiêng và có chân (italic and serif font) Hiển thị lộn xộn do sử dụng nhiều kiểu chữ trong một tài liệu; vấn

đề có sẵn các kiểu chữ khác nhau trên nền mà ứng dụng sẽ thực thi

Màu sắc Khả năng thích hợp của màu nền sau (background)

Khả năng thích hợp của màu nền trước (foreground)

Khả năng thích hợp của màu kiểu chữ

Hình ảnh Các hình ảnh lớn có thể làm tăng thời gian tải

Các gợi ý trực quan và thiết kế chi tiết nên phù hợp màu nền, không nên cạnh tranh với nó

Phù hợp với nền

Tính dễ đọc các nhãn

Tính dễ đọc các nút

Kích thước của hình ảnh phù hợp

Khung (frames) Một số trình duyệt không thể hiển thị các khung

Các cài đặt hiển thị và loại trình duyệtcó thể ảnh hưởng đến sự hiển thị các khung

Sử dụng các nút quay lui (back buttons) thường dẫn đến những kết quả không mong đợi

Bảng (table) Các bảng lồng nhau (bảng này trong bảng khác) làm chậm thời

gian nạp HTML Hình thức biểu diễn có thể thay đổi tùy thuộc cài đặt thể hiện và loại trình duyệt (sự co giảm hoặc bao phủ cod thể không đúng) Kiểm thử nên thực hiện trên tất cả các trình duyệt, cài đặt màn hình, kích thước của cửa sổ trình duyệt

Những phức tạp đặc trưng đối với các ứng dụng web

- Các trình duyệt web có các thách thức chung của chúng đối với kiểm thử chức năng Trên thị trường phần lớn chỉ sử dụng một số phiên bản và loại trình duyệt

Nếu mục đích là hỗ trợ hầu hết các trình duyệt, các lập trình viên phải lập trình cho người dùng web có modem chậm nhất và khả năng đơn giản nhất, chẳng hạn chỉ là trình duyệt văn bản hoặc trình duyệt đặc biệt Thậm chi khi phát triển HTML cẩn thận, các thay đổi trong biểu diễn đồ họa giữa các trình duyệt là nên tránh Ví dụ, khi hiển thị cùng một bảng trên Internet Explorer của Microsoft FireFox của Mozilla, người dùng có thể thấy các kết quả khác nhau

- Giao tiếp giữa trình duyệt và trình chủ là mô hình nhập dữ liệu tường minh

(explicit-submission-) Nghĩa là, Các dữ liệu và sự cập nhật không được ghi lên

trình chủ cho đến khi dùng thực hiện một hành động Ví dụ dữ liệu sẽ bị mất nếu người dùng kết thúc ứng dụng web trước khi nhấp chuột vào nút nhập liệu, như

Save hay Submit

- Các ngôn ngữ Script, như Jscript, JavaScrip, VBScript có thể được sử dụng để thực hiện một số xử lý có giới hạn phía trình duyệt

- Nếu không sử dụng script phía trình duyệt xử lý nỗi phải được thực hiện phía trình chủ, đó không phải là cách hiệu quả Ví dụ giả sử một người ở lreland tương tác với một số trình chủ yếu ở California Nếu người dùng ở lreland nhập dữ liệu trong định dạng không đúng người dùng sẽ được thông báo ngay lập tức nếu script được xử lý phía trình khách Nếu lỗi được xử lý thuyết trình chủ dữ liệu sẽ đến California và quay trở lại lreland trước khi người dùng biết lỗi ở phía chính khách

- Các ứng dụng web sử dụng mô hình trang đơn (single-page paradigm) Vì thế chúng ta không có các ưu điểm về tổ chức bậc thường thấy trong các ứng dụng giao diện đồ họa (chẳng hạn các ứng dụng Window) Các ứng dụng web không có cung cấploại hộp thoại luôn ở phía trên (modal dialog box), loại hộp thoại này rất phổ biến trong các môi trường đồ họa khác; khi các hội thoại luôn ở phía trên được sử dụng, chúng yêu cầu người dùng phải thực hiện một hành động trước khi điều khiểncủa ứng dụng hay của hệ điều hành được trả lại của người dùng

- Nút Back của trình duyệt có thể làm phức tạp sự phụ thuộc giữa các trang web

Nhắp đúp Back thay vì một nút nhập dữ liệu thích hợp là nguyên nhân thường gặp làm mất dữ liệu chưa được ghi

- Thay đổi cài đặt độ sâu màu (depth color) màn hình (16 màu, 24-bit màu, 32-bit

mau ), cũng như thay đổi độ phân giải màn hình (640 x 800, 800 x 600, 1280 x 1024, ) và kích thước kiểu chữ thường được tạo ra những kết quả không như mong đợi Tất cả các kết hợp độ sâu màu, độ phân giải, kích thước kiểu chữnên

được xem xét trong kiểm thử ứng dụng dựa trên trình duyệt

- Các loại và phiên bản khác nhau của trình duyệt trên các hệ điều hành khác nhau (Windows, Solars, Macintosh ) có thể hiển thị các phần tử HTML một cách khác nhau Phụ thuộc vào cài đặt chế độ hiển thị thậm chí một trình duyệt có thể hiển

thị các phần tử bởi nhiều cách Hơn nữa đặt lại kích thước của cửa sổ trình duyệt

có thể dẫn đến sự hiển thịcác khung và bạn không như mong đợi Các ứng dụng

web nên được kiểm thử với tất cả các loại và phiên bản trình duyệt phổ biến

- Hình sau minh họa các lỗi giao diện là kết quả của sự không tương thích của trình duyệt Các Thẻ HTML trong các ví dụ này là chỉ dành cho một trình duyệt Chúng không được thiết kế để tương thích với các trình duyệt khác Những lỗi này là kết quả của hai trình duyệt khác nhau đọccác bảng và điều khiển chuẩn HTML Trình duyệt trong hình 2.11 không hiển thị chính xác hộp văn bản cuộn (scrolling text box) và trình đơn kéo xuống (pull-down menu) như trình duyệt trong hình 2.10 hiển thị Cả 2 trình duyệt trình bày cùng một trang HTML với

các kết quả khác nhau

Hình 2.10 Không tương thích của trình duyệt – Trình duyệt A

Hình 2.11 Không tương thích của trình duyệt – Trình duyệt B

Ma trận khả năng tương thích về hiển thị (display compability matrix)

Phụ lục G, ―Ma trận kiểm thử khả năng tương thích về hiện thị‖, liệt kê các cài đặt

hiển thị lên được xem xét trong khi kiểm thử ứng dụng dựa trên trình duyệt

2.1.3 Kiểm thử khả năng sử dụng và khả năng truy cập

Kiểm thử khả năng sử dụng (usability testing)

Tùy thuộc vào quy định của tổ chức kiểm thử phần mềm kiểm thử khả năng sử dụng

(usability testing) có thể vượt quá phạm vi trách nhiệm được phân công cho nhóm

kiểm thử

Khả năng sử dụng mà độ đo hỗ trợ người thiết kế sản phẩm hay dịch vụ (bao gồm có

ứng dụng web, ứng dụng phần mềm, và ứng dụng trên thiết bị di động)xác định sự hài

lòng của những người dùng khi họ tương tác với sản phẩm hay dịch vụ qua giao diện,

bao gồm giao diện người dùng Một thiết kế giao diện người dùng hiệu quả là một giao

diện cung cấp khả năng sử dụng cao nhất cho người dùng Để thiết kế cho khả năng sử

dụng cao các câu hỏi được đặt ra:

- Mức độ dễ dàng đối với một người dùng chưa bao giờ nhìn thấy sản phẩm trước

khi thực hiện các công việc cơ bản?

- Mức độ dễ dàng đối với một người dùng đã từng sử dụng sản phẩm trước khi nhớ lại làm thế nào thực hiện cùng các công việc đó?

- Mức độ hiệu quả đối với một người dùng đã từng sử dụng sản phẩm trước khi thực hiện nhanh chóng các côngviệc thường xuyên được sử dụng?

- Tần suất nào cho người dùng gặp lỗi khi sử dụng sản phẩm? các lỗi này nghiêm trọng như thế nào? Mức độ bỏ qua lỗi của sản phẩm - nghĩa là khả năng cho phép người dùng dễ dàng phục hồi ứng dụng do lỗi? Mức độ cung cấp thông tin của sản phẩm khi giao tiếp các điều kiện lỗi với người dùng?

- Mức độ kinh nghiệm của người dùng khi sử dụng sản phẩm?

Muc ―Kiểm thử thiết kế giao diện người dùng‖ đề cập một cách phi hình thứckhái niệm thiết kế và kiểm thử khả năng sử dụng Kiểm thử khả năng sử dụng đi một bước

xa hơn hình thức hóa kiểm thử khả năng sử dụngđể đảm bảo thiết kế đạt được các mục tiêu và khả năng sử dụng Kiểm thử khả năng sử dụng gồm một số phương pháp khácnhau để phát triển sản phẩm, gắn các công việc cho người dùng thực hiện các công việc, và quan sát tương tác của người dùng và tập hợp các thông tin để đo lường khả năng sử dụng

Kiểm thử khả năng truy cập (accessibility testing)

Để tạo ra trang web có khả năng truy cập cao, người thiết kế cần phải tính đến nội dung của trang web phải được sẵn sàng và truy cập được đối với mọi người, kể cả những người tàn tật Điều đó có nghĩa là mọi người đều có thể duyệt trong một trang web hay giữa các trang web; duyệt nội dung với chỉ sử dụng bàn phím hay thiết bị vào đặc biệt khác với chuột; dễ dàng hiểu và theo vết nội dung và các hướng dẫn được cung cấp sự hia lòng lớn nhất đối với người dùng Sự khác biệt chính là khả năng truy cập thực hiện mục tiêu bởi việc làm cho sản phẩm dễ dàng sử dụng hơn với một số người, bao gồm cả người tàn tật

2.2 Kiểm thử chức năng

2.2.1 Phân loại chức năng

Để định nghĩa tốt hơn phạm vi của kiểm thử chức năng, hãy xem các mức hoạt động khác nhau của một ứng dụng:

- FAST Mỗi đầu vào và điều khiển duyệt có hoạt động như mong đợi?

- TOFT Ứng dụng có thể thực hiện các chức năng hưu ích như mong đợi?

- Kiểm thử biên Điều gì xảy ra khi sử dụng các giá trị biên?

- Kiểm thử lối ép buộc Điều gì xảy ra khi một điều kiện lỗi xuất hiện?

- Kiểm thử dạng khám phá Kinh nghiệm nói lên điêu gì về các vùng tiềm ẩn

vấn đề trong ứng dụng? Kiểm thử khám phá bao gồm việc nghiên cứu, lập kế hoạch ,và thực thi kiểm thử một cách đồng thời

Tấn công phần mềm.Tại sao phần mềm bị lỗi? Làm thế nào bạn có thể biến những

bài học kinh nghiệm thành hoạt động tương tác nhằm công kích và phát hiện lỗi các phần mềm?

2.2.2 Các phương pháp kiểm thử chức năng

Một số phương pháp kiểm thử hộp đen có thể được áp dụng trong kiểm thử chức năng

sẽ được thảo luận ở phần này

Kiểm thử đơn giản chấp nhận chức năng

Kiểm thử đơn giản chấp nhận được chức năng ( functional acceptance simple testing – FAST) là mức thứ hai của kiểm thử chấp nhận (so với kiểm thử chấp nhận phát hành (release acceptance testing – RAT) Thay vì chỉ bao gồm một số chức năng cơ bản của ứng dụng( như trong RAT), kiểm thử FAST bao phủ các chức năng theo chiều rộng, nhưng không theo chiều sâu Kiểm thử FAST thực thi mức thấp nhất chức năng mỗi lệnh như một chương trình Sự kết hợp các chức năng không được kiểm thử trong phạm vi của kiểm thử FAST Vấn đề này được xem xét trong kiểm thử hướng tác vụ (task-oriented functional testing – TOFT) được thảo luận ở phần sau

Một trong những mục tiêu của kiểm thử FAST là kiểm tra hành vi thích hợp của các điều kiện giao diện (ví dụ như text box, pull-down list, radio button…) dựa trên thiết

kế Kiểm thử FAST đòi hỏi phải kiểm tra sự tồn tại của các điều kiện giao diện trên mỗi trang, mỗi cửa sổ, hay mỗi hộp thoại; kiểm tra trạng thái mặc định (ví dụ như được phép chỉnh sửa (enable), không được phép chỉnh sửa (disable), được tô sáng (highliged)…); kiểm tra giá trị mặc định hay chế độ mặc định; kiểm tra thứ tự tab kiểm tra hanh vi của các phím tắt (như Ctr-X, Ctrl-V…) và các phím truy cập khác (như Alt-O để mở một tệp tin) Hơn nữa, trong tiến trình này, bạn hiểu được suy nghĩ và logic thực hiện của người phát triển khi xây dựng các chức năng cho người dùng cuối Sau này, bạn sử dụng những thông tin này để thiết kế những ca kiểm thử nhằm phát hiện các sai sót về lo-gic thiết kế

Trong môi trường Web, kiểm thử FAST cần kiểm tra:

- Các liên kết, như liên kết nội dung, liên kết thumbnail, liên kết bitmap, và liên kết ánh xạ ảnh

- Các điều khiển cơ bản, như điều hứng tiến và lùi ( backward and forwar navigating), phóng to và thu nhỏ, các điều khiển giao diện khác, và các bài kiểm tra tải lại nội dung ( content- refreshing)

- Kiểm tra các lệnh hành động như thêm, xóa, cập nhật, và xử lý dữ liệu khác; tạo hồ sơ người dùng ( user profile) hay tài khoản người dùng, bao gồm tài khoản email, tài khoản cá nhân, tài khoản nhóm; và kiểm tra dữ liệu đầu vào

- Các chức năng quan trọng khác như đăng nhập/đăng xuất (log in/log out), thông báo email, tìm kiếm, xử lý và kiểm tra thẻ tín dụng, hoặc giải quyết các trường hợp quên mật khẩu

Một số lỗi đơn giản bạn có thể tìm thấy trong tiến trình này bao gồm:

- Liên kết bị đứt

- Hình ảnh bị thiếu

- Liên kết không đúng

- Hình ảnh không đúng

- Liên kết đúng nhưng không có nội dung hoặc nội dung khôngcập nhật

- Lỗi trong tính toán đặt hàng/mua hàng

- Bỏ qua sự phân loại thẻ tín dụng

- Chấp nhận thẻ tín dụng đã hết hạn

- Chấp nhận thẻ tín dụng có số không hợp lệ

- Nội dung không đúng hoặc ngữ cảnh trả lời email tự động không đúng

- Không thông minh trong kiểm tra địa chỉ

- Trình chủ không trả lời lỗi DNS (Domain Name Service) (không có thông điệp cập nhật trình chủ gửi đến người dùng)

- Không có khả năng kiểm tra các địa chỉ email không hợp lệ của người dùng Kiểm thử chức năng hướng tác vụ ( task-oriented functioal testing- TOFT) kiểm tra xem ứng dụng có thể thực hiện các công việc hữu ích một cách đúng đắn hay không Kiểm thử chức năng hướng tác vụ là những kiểm thử ―tích cực‖ (positive tests) nhằm kiểm tra các chức năng của chương trình bằng cách so sánh các kết quả của các công việc được thưc hiện với tài liệu đặc tả sản phẩm và đặc tả yêu cầu, nếu có, hoặc so sánh với mong đợi độ chính xác và toàn vẹn của mỗi tác vụ riêng rẽ chương trình thực hiện Nếu hành vi hay kết quả khác với đặc tả trong yêu cầu sản phẩm thì sẽ được báo cáo lỗi

Các kiểm thử TOFT được thực hiện với một danh sách các chức năng cần được kiểm thử Để có được danh sách các chức năng cần kiểm thử, đặc tả sản phẩm càn được phân tích kỹ lưỡng Sản phẩm cũng cần được kiểm tra xem có chức năng nào không được định rõ hoặc hoàn toàn không có trong đặc tả hay không Tóm lại, tất cả những chức năng đều trở thành một mục trong danh sách các chức năng cần kiểm thử Các tác động cạnh tranh và yêu cầu thị trường cũng cần được xem xét khi phát triển những chi tiết trong danh sách

Kiểm thử lỗi ép buộc

Kiểm thử lỗi ép buộc (forced- error kiểm thửs – FET) cố ý tạo ra những điều kiện lỗi phần mềm (error conditions) Mục tiêu của FET là tìm các điều kiện lỗi không được phát hiện và/ hoặc sử lý sai Các điều kiện lỗi cần được xử lý một các hợp lý; nghĩa là, ứng dụng phục hồi thành công, hệ thống phục hồi thành công, hay ứng dụng thoát ra

mà không làm hỏng dữ liệu và vẫn có cơ hội lưu giữ công việc đang làm

Thường khó thu thập một danh sach đầy đủ các điều kiện lỗi Dưới đây là một số cách tạo danh sách điều kiện lỗi:

- Thu thập danh sách các thông điệp lỗi từ các lập trình viên

- Phỏng vấn các lập trình viên

- Khảo sát dữ liệu chuỗi ký tự trong tệp nguồn

- Thu thập thông tin từ đặc tả

- Sử dụng tiện ích để trích lọc các chuỗi ký tự kiểm thử từ tệp nguồn nhị phân hoặc tệp script

- Sử dụng kinh nghiệm của bạn

Sử dụng một ma trận kiểm thử đầu vào hợp lệ/ không hợp lệ chuẩn (như ma trận trong Phụ lục F, ―Hướng dẫn thiết kế các ca kiểm thử Web: Ma trận thẩm định kiểm thử biên đầu vào‖)

Kiểm thử điều kiện biên và Phân tích lớp tương đương

Kiểm thử điều kiện biên (boundary condition test) tương tự như Kiểm thử ép buộc lỗi (FET) trong đó các biên của mỗi biến được kiểm thử Ví dụ, khi kiểm thử một mẫu đăng ký trực tuyến, bạn cần kiểm tra một trường văn bản với một giới hạn từ hai đến bảy ký tự có hoạt động như mong đợ hay không Trường đó có chấp nhận hai, ba, sáu

và bảy ký tự không? Nếu một hay tám ký tự có được không? Trường đó có thể để