Lập kế hoạch cho những thách thức khi kiểm thử Mobile

Bản thân vốn là 1 dev quen với việc phát triển những ứng dụng web. Tới khi chuyển hướng sang QA thì công việc ở những ngày đầu tiên của mình cũng là tiếp xúc với ứng dụng web sêm sêm với các ứng dụng web đã từng làm. Tới khi được chuyển sang làm ở dự án về app trên mobile, chị đồng nghiệp có nói là sẽ có nhiều cái mới mẻ để cho mình được học hỏi so với việc test ứng dụng trên web. Kinh nghiệm còn ít, chưa hiểu được sự khác nhau giữa 2 loại app này; lại được nghe lời giới thiệu như vậy, mình hào hứng đi tìm hiểu thì gặp được bài viết này. Bài viết không đề cập đến sự khác nhau giữa test app trên web và test app moblie, mà nó đề cập tới những vấn đề (thách thức) bạn sẽ gặp phải khi thực hiện test app mobile. Chúng ta cùng nhau đi tìm hiểu nhé.

Khi phát triển các ứng dụng di động (app mobile) thì không thể bỏ qua các thiết bị di động. Có một số thách thức khi test các ứng dụng di động mà không gặp phải khi test các ứng dụng web (trên máy tính). Dưới đây là 1 số challenge mà bạn nên đưa vào kế hoạch kiểm thử ứng dụng di động của mình.

Challenge #1. Thách thức lớn nhất đối với kiểm thử Mobile là các thiết bị (Devices)

Có khoảng hàng nghìn thiết bị mobile khác nhau sẽ được các khách hàng của chúng ta sử dụng để truy cập ứng dụng (mobile). Vì vậy, kiểm thử ứng dụng di động phải tính đến tất cả các thiết bị này; bỏ qua 1 số thiết bị nào đó đồng nghĩa với việc có thể bạn sẽ mất một số lượng đáng kể khách hàng tiềm năng.

Các giải pháp khả thi:

1. Chỉ test trên các thiết bị thực.
2. Chỉ test trên các thiết bị giả lập (mô phỏng).
3. Kết hợp cả thiết bị thực và thiết bị mô phỏng.

Real devices (Thiết bị thực):

Tất nhiên không có gì tuyệt vời hơn việc có đầy đủ các thiết bị thực phục vụ cho quá trình kiểm thử. Nó giúp bạn kiểm soát tất cả các tình huống tiềm năng và lỗi. Nhưng để có đủ hết các loại thiết bị thực (với tất cả các loại hệ điều hành, đầy đủ các loại phiên bản, hãng sản xuất ....) thì rất là tốn kém. Thử hình dung công ty có bao nhiêu team làm di động, và mỗi 1 team cần 20-30 con device, nhân lên số lượng sẽ là bao nhiêu... một số lượng rất là khủng. Hoặc không chỉ nhìn đống device cũng đủ làm cho bạn hoa mắt, chóng mặt, tẩu hỏa nhập ma =))

Emulated devices (Thiết bị mô phỏng):

Thiết bị mô phỏng đóng vai trò đặc biệt quan trọng khi không có thiết bị thật cho việc kiểm thử các ứng dụng di động mặc dù test trên thiết bị thật luôn được ưu tiên vì nó tái lập hành động của người dùng cuối. Nhưng cũng không thể bỏ qua tầm quan trọng của thiết bị mô phỏng. Thiết bị mô phỏng có thể giúp chúng ta giả lập kích thước màn hình, version của hệ điều hành, kích thước thẻ nhớ… theo ý muốn. Và giúp có thể chuyển đổi giữa các mô hình thiết bị dễ dàng, đơn giản bằng việc tải 1 cấu hình device mới để hiển thị app của chúng ta giống như cách mà thiết bị thực sẽ làm. Các thiệt bị mô phỏng này được tập trung trong 1 trình mô phỏng : hệ điều hành iOs có trình mô phỏng Simulator, hệ điều hành Android có trình mô phỏng Emulator… Các trình mô phỏng này được cập nhật thường xuyên tất cả các cấu hình device hiện có trên thị trường, bạn sẽ dễ dàng sử dụng tất cả các cấu hình device này mà không cần phải mua thiết bị thực; rất hiệu quả về chi phí.

Trình mô phỏng Android

Là một máy ảo giả lập chạy trên máy chủ, chạy được cả trên Windows, Mac OS và Linus

*Ưu điểm: *

Là một bản dịch của phần mềm có thể chạy được trên cả Emulator và Android phone

*Nhược điểm: *

Chạy rất chậm do phải dịch lại, mỗi lệnh chạy trên CPU máy ảo phải dịch lại để chạy trên CPU máy chủ. Mỗi lần chạy thử phần mềm trên Emulator phải mất 1-5 phút để Emulator khởi động tùy thuộc vào tốc độ của CPU máy bạn.

Trình mô phỏng iOS

Simulator được tích hợp trong phần mềm soạn thảo Xcode và có thể giả lập được cả iPhone lẫn iPad

*Ưu điểm: *

Các ứng dụng được mô phỏng nhanh chóng

*Nhược điểm: *

Bản dịch này khác với bản dịch cho iDevice CPU. Hãng Apple có khuyến cáo sử dụng các Simulator như một công cụ kiểm tra sơ bộ để tăng tốc độ lập trình và không phải là sự thay thế của các thử nghiệm trên thiết bị.

Nói tóm lại chúng ta không thể phủ nhận vai trò của trình mô phỏng nhưng luôn lưu ý ưu tiên thử nghiệm ứng dụng trên nhiều thiết bị devices thật với các hệ điều hành khác nhau bởi rất nhiều bug được tìm ra trên các thiết bị thật mà không thể phát hiện được trên các trình mô phỏng.

Kết hợp Real devices + Emulated devices

Thật không may, các thiết bị mô phỏng vẫn thiếu một số đặc điểm riêng mà chỉ có thiết bị thực mới có, ví dụ như : cung cấp đồ họa chính xác hoàn hảo tới từng pixel, hiệu suất và tốc độ của các thiết bị khác nhau, ảnh hưởng của các điều kiện bên ngoài có thể ảnh hưởng đến hoạt động của thiết bị.

Vì vậy, cách tốt nhất là kết họp cả Real devices và Emulated devices.

Để thực hiện mobile testing, bạn cần một thiết bị di động. Ngoài ra, bạn cần sự hỗ trợ từ nhiều phần mềm giả lập khác nhau, trên những phần mềm giả lập đó bạn cần khẳng định một điều rằng làm thế nào sản phẩm của chúng ta sẽ làm việc và có giao diện trông giống như trên một thiết bị điện thoại di động nhất.

Để có thể thực hiện kiểu test này, chúng ta cần phải có được những thiết bị cần thiết tương ứng và sau đó tiến hàng test để kiểm tra xem ứng dụng có đạt được kỳ vọng phát triển hay không. Chắc bạn cũng từng có suy nghĩ, muôn có đầy đủ thiết bị để thực hiện công việc test thì việc phải bỏ ra một khoản chi phí khá lớn là điều không thể tránh khỏi. Vậy có lựa chọn nào khả thi hơn không?

Các giải pháp cho vấn đề này là sử dụng Mobile Simulators and Mobile Emulators. Đây chủ yếu là các chương trình phần mềm được thiết kế để cung cấp mô phỏng cho các tính năng quan trọng của smartphone. Tổng quan chúng rất giống nhau, nên trên thực tế chúng được sử dụng khá nhiều để thay thế cho nhau.

Hãy so sánh cách test trên một Emulator / Simulator khác nhau như thế nào đối với một Real Device - Thiết bị thực:

Một trình mô phỏng không thể bắt chước các tính năng sau đây:

• Pin điện thoại di động.
• Camera của điện thoại di động.
• Khó khăn trong việc bắt chước sự gián đoạn về cuộc gọi hay gửi tin nhắn SMS.
• Không có quá nhiều mô phỏng thực tế cho việc sử dụng bộ nhớ điện thoại di động.
• ...

Vậy, sự lựa chọn tốt nhất cho mobile testing là gì?

Kinh nghiệm tốt nhất chỉ ra rằng, ở giai đoạn đầu của quá trình phát triển, nên sử dụng trình giả lập để đạt được mục tiêu cao nhất với chi phí tương đối (thấp), tốc độ cao và sự đa dạng về thiết bị mà trình giả lập cung cấp. Vì ở giai đoạn này chưa cần tới kết xuất pixel hoàn hảo của một thiết bị thực tế. Lợi ích thu được là tăng số lượng các các test case và các loại thiết bị được bao phủ trong bộ Test case. Trước khi hoàn thiện sản phẩm, bạn cần có sự tỉnh táo trong việc lựa chọn thiết bị test. Ví dụ, có một số lượng lớn người sử dụng điện thoại thông minh Android, vậy sự lựa chọn thông minh nhất là test trên các thiết bị thực Android mới nhất và có thể tiến hành test hồi quy trên simulators để xác nhận rằng các ứng dụng đang hoạt động như mong đợi và xác nhận rằng tất cả các yêu cầu phát triển và mục tiêu đã được đáp ứng.

Challenge #2. Thách thức về khu vực mạng (Regional Network)

Mỗi quốc gia đều có các nhà mạng cụ thể. Tổng số có khoảng hơn 800 nhà mạng di động trên toàn thế giới. Mỗi nhà mạng có thể hỗ trợ nhiều công nghệ mạng và các giao thức như LTE, CDMA, GSM. Hầu hết các nhà mạng đã chèn các proxy vào Web di động (hoặc gateway) để điều chỉnh làm thế nào, khi nào để khách hàng của họ có thể kết nối với một trang web cụ thể.

Bên cạnh các công nghệ, cũng có những thách thức về địa điểm mà không kém phần quan trọng. Để có thể kiểm tra toàn bộ mạng lưới chồng trên một cơ sở hạ tầng mạng điều hành cụ thể, chúng ta phải được kết nối với mạng đích. Lưu ý rằng các tín hiệu vô tuyến không mạnh trên mạng di động. Vì vậy, nếu muốn thử nghiệm Telecom Italia chúng ta phải ở Italia hoặc nếu muốn thử nghiệm China Unicom thì chúng ta phải ở Trung Quốc... Tuy nhiên việc du lịch khắp thế giới để test thật là điều không tưởng. Để khắc phục điều này, chúng ta có các lựa chọn sau :

1. Bỏ qua (bypass) các tầng thấp hơn của network, đơn giản chỉ cần test trên Internet hoặc LAN
2. Có thể sử dụng real network bằng cách sử dụng điện thoại hoặc modem.

Network Bypass

Để sử dụng kỹ thuật này, chúng ta cần 1 trình mô phỏng device vì hầu hết các thiết bị thực không có khả năng làm việc này. Chúng ta có thể sử dụng TCP / IP để kết nối trực tiếp tới máy chủ và bỏ qua các hệ thống đường hầm GPRS được sử dụng bởi các nhà mạng. Đầu tiên cần phải kiểm tra xem liệu thiết bị giả lập của chúng ta có thể thực hiện bỏ qua mạng bằng cách sử dụng Internet được hay không. Trông chờ kết quả tốt đẹp là thiết bị giả lập có thể truy cập được vào proxy của nhà mạng để thực hiện các test thực tế hơn. Bằng việc bỏ qua netwwork này, chúng ta sẽ không sử dụng airtime nên sẽ không phải mất phí cho khoản này.

Real Networks

Test trong Real Network ??? Điều này không phải là không thể, bạn có thể sử dụng thiết bị thực ở trong địa điểm đích (target location), nhưng lại mất chi phí đi lại. Có một cách đơn giản và tiết kiệm hơn rất nhiều - real device in the cloud (thiết bị thực trong đám mây). Loại giải pháp này vẫn có thể tốn kém vì chi phí cho thiết bị cần phải thêm chi phí phần cứng điều khiển từ xa, phần mềm điều khiển từ xa và phần mềm cục bộ. Hoặc có thể tiết kiệm chi phí mua các thứ này bằng cách thuê tài nguyên của nhà cung cấp nào đó, cho phép chúng ta truy cập các thiết bị thực từ xa vào bất kỳ thời gian nào bạn muốn. Tất cả những gì cần làm là mở 1 tài khoản và mua khoảng thời gian thử nghiệm với 1 mô hình thiết bị nhất định.

Challenge #3. Manual or automated scripting (Kiểm thử thủ công hay kiểm thử tự động)

Chúng ta sẽ cần phải chọn phương pháp sẽ được sử dụng để thực sự thực hiện các kịch bản test, có thể là thủ công hoặc tự động. Câu hỏi đặt ra là kiểm thử thủ công hay kiểm thử tự động sẽ tốt hơn???

Vì có nhiều thiết bị di động khác nhau, có cấu trúc khác nhau vì vậy nên tạo các kịch bản tự động để phù hợp với mọi thiết bị. Một kịch bản với các phím bấm chặt chẽ trên iPhone sẽ không được thực hiện hiệu quả trên một điện thoại di động của Samsung, vì giao diện của chúng hoàn toàn khác nhau. Tin vui là hầu hết các phần mềm kiểm thử tự động cung cấp các chức năng kịch bản cấp cao như "đi đến URL" hoặc "gửi SMS" mà không phụ thuộc vào cấu trúc menu cụ thể của thiết bị test. Hầu hết các trình thiết bị giả lập có thể được sử dụng để tự động thực hiện kiểm thử với một ngôn ngữ kịch bản cấp cao, trừu tượng mà không phụ thuộc vào thiết bị.

Chi phí tạo kịch bản tự động thường cao hơn chi phí của một lần thực hiện bằng tay của một kịch bản test, tuy nhiên, nếu chạy trên cơ sở định kỳ, nó thực sự có thể tiết kiệm thời gian và tiền bạc. Bên cạnh đó, nhiều công cụ kịch bản tự động có một khả năng đặc biệt có thể kiểm tra toàn bộ trang web chỉ với một lệnh duy nhất. Điều này có nghĩa là thiết lập thử nghiệm nhanh sẽ xem xét tất cả các trang trong ứng dụng di động của chúng ta để tìm ra lỗi và sự không nhất quán.

Lời kết

Bài viết trên đây còn sơ sài, nếu quan tâm bạn có thể tham khảo thêm ở bài gốc sau đây : http://www.softwaretestingmagazine.com/knowledge/planning-for-mobile-testing-challenges/ Và 1 số nguồn khác trên Internet