Các loại kiểm thử khác nhau

Kiểm thử cài đặt add-on

Các thiết bị di động thick-client, như PDA và smartphone, cung cấp thiết bị lưu trữ phụ và khả năng cài đặt phần mềm add-on bao gồm trình duyệt, các thành phần phía client khác và các template (như các ứng dụng Web Clipping cho các thiết bị Palm OS). Bạn cần xem xét những gì liên quan đến quá trình cài đặt các thành phần này và thiết kế các ca kiểm thử để bao quát các kịch bản cài đặt khác nhau, bao gồm các hệ điều hành chéo, các thiết bị chéo, các phiên bản trình duyệt chéo… (Xem thêm thông tin trong Chương 16, “Kiểm thử cài đặt”).

Kiểm thử đồng bộ dữ liệu

Do băng thông mạng không dây bị hạn chế, một trong những giải pháp thiết kế phổ biến là tải xuống nội dung Web để hiển thị sau đó ngắt kết nối mạng. Tiến trình đồng bộ có thể thực hiện trong 2 cách:

-         Phương pháp  đồng bộ với ứng dụng trên máy tính cá nhân. Trong trường hợp này, máy tính cá nhân luôn có kết nối đến Internet. Sau đó, nội dung Web trên máy tính cá nhân có thể được truyền đến thiết bị qua quá trình đồng bộ dữ liệu.

-         Đồng bộ cũng có thể được thực hiện nhờ vào mạng không dây. Người dùng đồng bộ thiết bị với một proxy server qua kết nối không dây. Các trang Web với định dạng trước được lưu trữ trên các Web server kết nối đến Proxy server sẽ được truyền đến thiết bị trong quá trình đồng bộ. Người dùng có thể duyệt các trang Web được truyền đến, đang được lưu trữ trên thiết bị.

Ví dụ, AvantGo cung cấp khả năng truy cập các trang HTML được định dạng trước, tải lên trên thiết bị di động để xem với trình duyệt AvantGo khi không kết nối mạng. Đặc biệt các trang Web được định dạng để xem trên thiết bị di động có thể được tổ chức thành các kênh (channel). AvantGo cung cấp các hướng dẫn tạo trang tương thích cho người phát triển. Các trang ở trên Web server được đồng bộ hóa đến thiết bị của người dùng qua proxy server của AvantGo. Sau đó, người dùng có thể duyệt các trang được lưu trữ trong bất kỳ trình duyệt Web khác. Họ có thể điền các mẫu, thêm và xóa các trang, tải lại nội dung trong các lần đồng bộ tiếp theo.

Ngược lại, người dùng có thể tương tác thời gian thực, duyệt trực tuyến  khi các trang Web được truy cập trực tiếp qua kết nối có dây hoặc không dây giữa thiết bị và server. Các trang Web được duyệt có thể được đồng bộ với máy tính cá nhân sau đó. Mặc dù ứng dụng Web cần được kiểm thử ít có sự kiểm soát qua cơ chế đồng bộ, có các hiệu ứng tiềm ẩn trên hành vi của ứng dụng liên quan đến đồng bộ dữ liệu. Ví dụ, nếu bạn lấy một cookiee khi duyệt một Website, khi bạn kết nối trực tiếp đến Website đó, cookie sẽ được gửi đến client trên thiết bị di động (giả sử rằng nó hỗ trợ cookie). Sau đó, khi bạn duyệt nội dung không kết nối mạng của cùng Website đó qua tiến trình đồng bộ với máy tính cá nhân, phiên bản cookie trên máy tính cá nhân cho Website đó có thể được ghi đè lên phiên bản trên thiết bị di động, đó không phải là điều được mong muốn.

Tất cả các kịch bản này nên được xem xét trong tiến trình lập kế hoạch kiểm thử và thiết kế các ca kiểm thử.

Kiểm thử thực thi giao diện người dùng và sự hạn chế về khả năng sử dụng

Một số yếu tố ảnh hướng đến khả năng sử dụng gồm yếu tố người dùng mà bạn hướng đến và các hạn chế của thiết bị, như kích thước màn hình, băng thông, công nghệ, thiết bị và Website. Tuy nhiên, đối với kiểm thử thực thi giao diện người dùng và khả năng sử dụng, bạn nên đặt ra các câu hỏi sau:

-                     Các phương pháp nhập liệu trên các nền tảng được hỗ trợ ảnh hướng đến khả năng sử dụng như thế nào?

-                     Website cần được kiểm thử xuất hiện như thế nào trong trình duyệt với các thiết lập mặc định của các tính chất, như kích thước trang, hình ảnh, kích thước cỡ chữ v.v…?

-                     Độ trễ mạng ảnh hướng như thế nào đến chức năng của ứng dụng Web cần được kiểm thử? Ví dụ, trong khi thực hiện một giao tác với một ứng dụng về ngân hàng qua một kết nối chậm, server sẽ tạm ngưng hoạt động (time-out) trong quá trình thực hiện giao tác? Khi nào sự kiện đó xuất hiện, điều gì sẽ xảy ra với giao tác?

-                     Có hữu ích không khi tận dụng các công cụ để kiểm thử cú pháp WMLScript và WML không hợp lệ, các liên kết thiết sót, các nội dung không được hỗ trợ v.v…?

-                     Các bao bọc văn bản (text-wrapping) có hoạt động đúng đắn không?

-                     Giao diện duyệt có thể thực hiện trực quan không?

-                     Các giao diện nhập liệu có nhất quán và thân thiện không?

-                     Có nhất quán trong việc cài đặt trình đơn, nút và xử lý lỗi?

-                     Các hình ảnh có được hiển thị vừa vặn và đúng vị trí?

Các tham khảo hướng dẫn về giao diện người dùng

Nên có các hướng dẫn trong quá trình thiết kế và cài đặt giao diện người dùng. Các lập trình viên có thể sử dụng chúng để thiết lập các nguyên tắc thiết kế ứng dụng. Điều này không có nghĩa là các hướng dẫn đó phải được tuân thủ chặt chẽ; mà chỉ đơn thuần là sử dụng các thông tin này như là một nguồn tham khảo để ngăn cản các lập trình viên mất thời gian “phát minh lại những gì đã có” trong khi thiết kế và cài đặt giao diện người dùng.

Kiểm thử trình duyệt

Tất cả các vấn đề về kiểm thử ứng dụng Web trên máy tính cá nhân có thể áp dụng cho kiểm thử ứng dụng Web trên thiết bị di động. Một số các vấn đề về trình duyệt đáng được nhắc lại ở đây, dựa vào đó bạn nên phát triển các ca kiểm thử để xác định các vấn đề:

-                     Hiệu ứng do ứng dụng cần được kiểm thử, do thiếu hỗ trợ hoặc hỗ trợ không tương thích về cookie, script, plug-in (như Macromedia Flash), Java applet, ActiveX, CSS (Cascading Style Sheet) và kết nối sử dụng SSL (Secure Sockets Layer).

-                     Không tương thích hoặc thiết hỗ trợ cho một hoặc nhiều ngôn ngữ đánh dấu, như HDML, WML, cHTML, xHTML, HTML hay XML.

-                     Hỗ trợ các ứng dụng PQA hay Web Clipping, so với các ứng dụng hỗ trợ kênh.

-                     Các vấn đề hỗ trợ sự kế thừa (legacy). Ví dụ, một phiên bản trước của ứng dụng hỗ trợ HDML. Hiện tại, nó hỗ trợ WML nhưng nó cũng phải cho phép người dùng dùng các trình duyệt hiểu DHTML như thể hai chế độ hỗ trợ phải được cài đặt.

-                     Vấn đề về bộ nhớ cache. Bộ nhớ cache lưu trữ tạm thời nội dung Web trên phía trình duyệt, phía server hoặc cả hai. Ví dụ, khi chế độ sử dụng cache được bật bên phía client (thông thường bạn có thể thay đổi kích thước bộ nhớ cache), khi bạn duyệt một trang Web, trang đó sẽ được lưu trữ trên đĩa, trong một tệp cache. Sau đó, khi bạn duyệt lại trang Web đó, trình duyệt sẽ tìm kiếm trong bộ nhớ cache. Nếu nó tìm thấy, nó sẽ hiển thị trang từ bộ nhớ cache thay vì từ Web server gốc, nhằm tiết kiệm thời gian và giảm lưu thông trên mạng. Đôi khi, điều đó ảnh hướng đến kiểm thức hay chức năng của ứng dụng Web; trình duyệt sẽ không có mã nguồn hay nội dung mới nhất từ server gốc kịp thời, dẫn đến kết quả không mong muốn.

Kiểm thử trên nền tảng riêng biệt (Plattform-specified test)

Khi công ty của bạn phát triển một ứng dụng cho một nền tảng cụ thể, như Windows, UNIX, MacOS, Palm Computing hay Windows PocketPC, bạn cần thực thi các kiểm thử tìm kiếm lỗi liên quan đến nền tảng cụ thể thay vì tìm kiếm lỗi các chức năng. Ví dụ, trên Windows, việc xóa một thư viện liên kết động (dll) hay khóa đăng ký (registry) không đúng đắng có thể gây nên lỗi liên quan đến nền tảng. Khi ứng dụng của bạn hoạt động như mọng đợi trên một nền tảng, nó được xem là tương thích với nền tảng đó.

Mặc dù phạm vi và chi tiết của kiểm thử nền tảng sẽ được mô tả bởi yêu cầu kiểm thử hay mục tiêu kiểm thử, loại kiểm thử này thường được chuẩn hóa và nhiều chuẩn của nhà sản xuất cho các ứng dụng trên thiết bị di động được cung cấp. Các mẫu của các chuẩn này được mô tả trong các mục con tiếp theo.

Kiểm thử sự hợp chuẩn với nền tảng hay biểu tượng (plattform or logo compliance test)

Khi một nhà sản xuất phần cứng cấp phép cho hệ điều hành hay phần mềm được nhúng trong một thiết bị di động, những nhà cấp phép thường yêu cầu nhà sản xuất hay người được cấp phép thực hiện kiểm thử chấp thuận nền tảng nhằm đảm bảo rằng sự cài đặt phần mềm trên thiết bị theo đúng chuẩn của những nhà cấp phép, nghĩa là nó sẽ tương thích với các thành phần khác của hệ điều hành và các ứng dụng phần mềm khác. Cùng một tiến trình đó cũng có thể được áp dụng cho nhà sản xuất phần mềm mà cung cấp ứng dụng cho một thiết bị hay nền tảng. Hầu hết các nhà sản xuất hệ điều hành và nền tảng có kế hoạch kiểm thử công khai và thường đặt trên Website của họ để có thể tải xuống dễ dàng. Kế hoạch kiểm thử chuẩn Microsoft Logo Certification cho các nền tảng Windows khác nhau là một ví dụ về kiểm thử sự chấp nhận nền tảng.

Trong một số trường hợp, công ty của bạn có thể có cam kết thực hiện các kiểm thử xác nhận này; nhưng phần lớn thì không, thực hiện các kiểm thử này là tùy chọn. Trong thực tế, ứng dụng Web cần được kiểm thử chỉ sử dụng các phương tiện cung cấp bởi thiết bị client, trong trường hợp này là trình duyệt. Cho dù thế nào đi nữa, nghiên cứu các kiểm thử chuẩn này có thể mang lại cho bạn ý tưởng phát triển các ca kiểm thử, thực thi các vùng của ứng dụng mà có thể có các lỗi liên quan đến nền tảng.

Kiểm thử khả năng tương thích cấu hình

Sử dụng một trình mô phỏng (xem thêm mục “Các trình mô phỏng trình duyệt và thiết bị”), bạn có thể thực hiện kiểm thử chức năng cơ bản. Các kiểm thử khác cần phải được thực hiện trên thiết bị vật lý. Điều đó có nghĩa là trên phía client bạn sẽ giải quyết với:

-                     Các thiết bị chéo (cross device).

-                     Các hệ điều hành chéo bao gồm các chuẩn về OEM.

-                     Các trình duyệt chéo.

-                     Các phiên bản chéo.

-                     Các ngôn ngữ chéo (nếu có).

-                     Các định dạng đồ họa.

-                     Các định dạng âm thanh.

Để làm quen với các vấn đề về khả năng tương thích, xem tại www.nttdocomo

.co/jp/englishy/i/tag/imodetag.html, bạn có thể tìm thấy ở đó một tài liệu có tên “Online of i-Mode compatible HTML”. Tài liệu này mô tả các vấn đề về khả năng tương thích trong HTML: các vấn đề về nội dung và thiết bị, như các ký tự đặc biệt, số lượng ký tự mỗi trang, khả năng tương thích tệp hình ảnh, kích thước màn hình, độ phân giải màu, kích thước bộ nhớ cache v.v…

Kiểm thử kết nối

Kiểm thử kết nối tìm kiếm các lỗi liên quan đến các thiết bị và mạng được kết nối với nhau, những trở ngại trong quá trình truyền dữ liệu có thể ảnh hưởng như thế nào đến chức năng cũng như sự toàn vẹn dữ liệu. Các mục con tiếp theo mô tả các vấn đề cần xem xét.

Thiết bị với các hỗ trợ kết nối mạng

Đối với các thiết bị có các kết nối 802.11b, bluetooth và IR, cần xem xét:

Thiết bị giải quyết việc khởi tạo kết nối như thế nào?

-                     Tần suất kết nối tạm ngưng (time-out)?

-                     Thời gian tạm ngưng có thể được cấu hình? Các thiết lập kết nối (ví dụ, ngắt kết nối mỗi 5 phút) ảnh hưởng như thế nào đến hành vi của ứng dụng Web trên thiết bị di động cần được kiểm thử?

-                     Các điều kiện về thời gian tạm ngưng ảnh hưởng như thế nào đến chức năng của ứng dụng hay dữ liệu đang được truyền đi?

Độ trễ (latency)

Các thông điệp được truyền qua mạng cần thời gian để đến đích. Phụ thuộc vào kích thước của thông điệp, tốc độ truyền dữ liệu, độ tin cậy và khả năng phủ sóng của mạng không dây, sẽ có chậm trễ trong quá trình truyền dữ liệu. Vấn đề đặt ra là ứng dụng ghi nhận và thông báo cho người dùng về sự chậm trễ hay không?

Hơn nữa, có thể thông điệp sẽ được truyền đến đích với sự chậm trễ đáng kể do trở ngại, chẳng hạn tắc nghẽn mạng hay thiết bị ở chế độ ngủ. Như thế, cần kiểm tra xem ứng dụng có ghi nhận trạng thái truyền dẫn, để bảo đảm rằng người dùng biết được khi nào thông tin cũ, do chậm trễ và khi nào do thông tin mới.

Lỗi truyền dẫn

Như đã chỉ ra trước đó, dữ liệu truyền qua mạng không dây có thể có nhiều trở ngại. Như thế, nội dung được truyền bởi thiết bị client và server có thể bị biến đổi do độ trễ hay trở ngại. Các giao thức mạng không dây thường cho phép phát hiện và sửa chữa nhiều lỗi; tuy nhiên, ở mức ứng dụng, lập trình viên cần phải tính đến xử lý lỗi nhằm giải quyết các loại lỗi truyền dẫn khác nhau.

Ví dụ, các nhà cung cấp mạng khác nhau xử lý các lỗi truyền dẫn một cách khác nhau. Một số nhà cung cấp gửi liên tục vào các thời điểm khác nhau cho đến khi thông điệp đến được ứng dụng client. Một số nhà cung cấp khác sẽ báo động cho người dùng về sự thất bại và để cho người dùng quyết định có gửi lại thông điệp hay không. Một số nhà cung cấp khác nữa có thể dừng việc gửi thông điệp mà không có bất cứ thông báo nào cho người dùng. Những sự khác nhau này có thể ảnh hướng đến dữ liệu được truyền bởi ứng dụng Web trên thiết bị di động cần được kiểm thử.

Sự di chuyển từ vùng được phủ sóng sang vùng không được phủ sóng

Trong khi đang được kết nối server, thiết bị có thể được mang từ vùng phủ sóng tốt sang vùng không được phủ sóng. Ứng dụng Web trên thiết bị di động nên xử lý tình huống này tượng tự như các tình huống nên gây lỗi truyền dẫn, đã được thảo luận ở trên.

Ví dụ, giả sử trên phía server, ứng dụng kiểm tra trạng thái kết nối 30s/lần, 10s kể từ lần kiểm tra gần nhất, thiết bị được mang từ vùng phủ sóng tốt sang vùng không được phủ sóng, 15s sau đó thiết bị được mang trở lại vùng phủ sóng tốt. Ở bước kiểm tra tiếp theo, ứng dụng xác định rằng kết nối  vẫn tốt, mà không biết rằng trong vòng 15s vừa qua kết nối vừa mất. Điều này có thể đặt ứng dụng vào một trạng thái không xác định mà có thể gây nên các lỗi về chức năng hay lỗi về toàn vẹn dữ liệu.

Sự chuyển đổi giữa dữ liệu và tín hiệu thoại

Thiết bị được xử lý như thế nào trong khi đang có cuộc gọi điện thoại, và ngược lại? Đối với nhiều mạng và điện thoại di động, bạn không thể cùng lúc gọi điện thoại và truy cập Web qua TCP/IP. Sự gián đoạn truyền dữ liệu do có cuộc điện thoại đến cũng có thể gây nên những lỗi mà ứng dụng Web trên thiết bị di động cần được kiểm thử không biết cách xử lý.

Thứ tự gởi dữ liệu hay thông điệp

Các nhà cung cấp mạng khác nhau có các phương pháp khác nhau để gửi dãy các thông điệp giữa server và client. Không nên tin tưởng rằng nhà cung cấp gửi các thông điệp trong cùng thứ tự mà chúng được gửi từ ứng dụng Web trên thiết bị di động. Hãy kiểm tra để đảm bảo rằng ứng dụng cần được kiểm thử có các cài đặt riêng của nó nhằm bảo vệ sự toàn vẹn dữ liệu.

Kiểm thử hiệu năng

Nhiều vấn đề về kiểm thử hiệu năng đã được thảo luận trong chương 19, “kiểm thử hiệu năng”, có thể áp dụng để kiểm thử các ứng dụng Web trên thiết bị di động.

Khi kiểm thử gateway (như WAP gateway, cho phép chuyển đổi các giao thức HTTP thành WSP (Wireless Session Protocol in WAP), hoặc SSL và WTLS (Wireless Transport Layer Security) và ngược lại), bảo đảm rằng công cụ kiểm thử hỗ trợ các giao thức đó.

Hình 20.4 trình bày một ví dụ yêu cầu và trả lời Web qua WAP gateway. Hình này cũng minh họa thêm các hoạt động xuất hiện ở WAP gateway:

Hình 20.4 Mô hình yêu cầu/trả lời Web trong WAP.

1. Khi người dùng di động thực hiện một yêu cầu, yêu cầu WAP được gửi đến WAP gateway.

2. WAP gateway chuyển yêu cầu WSP thành một yêu cầu HTTP.

3. Từ đó, yêu cầu HTTP (hoặc HTTPS, nếu SSL được sử dụng) được gửi đến Web server, như trong kiến trúc Web chuẩn.

4. Khi Web server trả lời với nội dung Web, như HTML, WML hay WMLScript, WAP gateway thực hiện chuyển đổi tiêu đề HTTP thành WSP, chuyển đổi HTTP thành WSP, chuyển đổi định dạng hình ảnh (GIF thành WBMP chẳng hạn), mã hóa WML, biên dịch WMLScript, v.v…

5. Sau đó, WAP gateway gửi trả lời WSP với nội dung được mã hóa đến client di động.

Các vấn đề khác cần xem xét gồm khả năng của công cụ mô phỏng băng thông bị hạn chế trong môi trường 2G/3G và các tính năng xử lý Script, cookie…