Bài 1: Giới thiệu kiểm thử thiết bị di động

Đã qua rồi cái thời mà điện thoại chỉ dùng cho mục đích nghe, gọi, nhắn tin và phải đổ chuông để thu hút sự chú ý của chúng ta hoặc máy tính là một cỗ máy chỉ có một vài người sử dụng. Giờ đây chúng là một phần cuộc sống của chúng ta, một cửa sổ cho thế giới.
Máy tính đã làm thay đổi cách con người chúng ta nghĩ, cư xử, học hỏi và tồn tại. Ngày nay, các giải pháp di động đã chiếm lĩnh thị trường. Mọi người không muốn bật máy tính xách tay/PC để làm một việc gì đó, thay vào đó họ muốn các thiết bị cầm tay của họ thực hiện mọi thứ một cách nhanh chóng. Do đó, các giải pháp di động mà nhà phát triển muốn cung cấp đến khách hàng của mình phải được kiểm tra rất tốt về chất lượng. Hướng dẫn này dành cho những người đã thử nghiệm trên thiết bị di động hoặc những người đã chuyển sang sử dụng nó trong thời gian gần đây. Dựa trên một số kinh nghiệm của bản thân và các nguồn tài liệu tham khảo, tôi sẽ đưa đến cho bạn đọc những kiến thức căn bản nhất để có thể kiểm thử được các ứng dụng trên các thiết bị di động.

1. Các loại kiểm thử ứng dụng di động

Có hai loại kiểm thử diễn ra trên thiết bị di động đó là:

# 1. Kiểm thử phần cứng:

Thiết bị bao gồm bộ xử lý trong, phần cứng bên trong, kích thước màn hình, độ phân giải, bộ nhớ, camera, radio, bluetooth, wifi,…

2.Kiểm thử phần mềm hoặc kiểm thử ứng dụng:

Ứng dụng làm việc trên các thiết bị di động và các chức năng của nó được kiểm thử. Đây gọi là kiểm thử Ứng dụng di động để phân biệt với các phương pháp có từ sớm hơn. Các ứng dụng di động bao gồm:

a. Ứng dụng gốc_Native apps: Là ứng dụng được tạo riêng trên một nền tảng giống như di động hoặc máy tính bảng.

b. Ứng dụng di động web_Mobile web apps: Là các ứng dụng phía server để truy cập vào các website trên di động sử dụng các trình duyệt khác nhau như: Chrome, Firefox bằng cách kết nối tới một mạng di động hoặc mạng không dây giống như WIFI

c .Ứng dụng lai_Hybrid apps : Là sự kết hợp giữa ứng dụng gốc và ứng dụng web. Chúng chạy trên các thiết bị hoặc offline và chúng được viết bằng các công nghệ web như HTML5 và CSS.

Một số điểm khác nhau cơ bản giữa các ứng dụng trên:

  • Ứng dụng gốc chỉ chạy trên một nền tảng trong khi ứng dụng di động web thì đa nền tảng.
  • Ứng dụng gốc được viết trên nền tảng giống SDKs trong khi ứng dụng di động web được viết với các công nghệ web: html, css, asp.net, java, php,…
  • Trong một vài ứng dụng gốc, việc cài đặt là bắt buộc nhưng trong ứng dụng di động web, việc cài đặt là không cần thiết.
  • Ứng dụng gốc có thể được cập nhật từ play store hoặc app store trong khi các ứng dụng di động web thì được cập nhật tập trung.
  • Rất nhiều ứng dụng gốc không yêu cầu kết nối internet nhưng ứng dụng di động web thì yêu cầu.
  • Ứng dụng gốc làm việc nhanh hơn khi so sánh với ứng dụng di động web.
  • Ứng dụng gốc được cài đặt thông qua app stores hoặc google play store trong khi ứng dụng mobile web là các websites và được truy cập thông qua internet.

Ý nghĩa của kiểm thử ứng dụng di động.

Kiểm thử ứng dụng trên thiết bị di động có nhiều thách thức hơn kiểm thử ứng dụng web trên máy tính để bàn bởi vì:

  • Phạm vi khác nhau của các ứng dụng di động kèm theo sự khác nhau của độ phân giải màn hình và cấu hình phần cứng giống như: bàn phím cứng, bàn phím ảo và các con lăn chuột.
  • Sự đa dạng của các thiết bị di động như: HTC, Sam sung, apple, nokia…
  • Khác nhau của các hệ điều hành di động: Android, window, ios..
  • Sự khác nhau giữa các phiên bản hệ điều hành: IOS5.x, 6.x…
  • Sự khác nhau giữa các mạng di động: GSM and CDMA…
  • Việc cập nhật thường xuyên: Với mỗi cập nhật nên tạo thêm một vòng kiểm thử mới để chắc chắn rằng không có chức năng nào của ứng dụng bị ảnh hưởng.

Với bất kì ứng dụng nào, kiểm thử ứng dụng di động là rất quan trọng vì thường có hàng triệu người sử dụng sản phẩm. Việc có bug có thể gây ra việc thất thoát tiền, các vấn đề pháp lý và thiệt hại không thể khắc phục trong việc xây dựng hình ảnh thương hiệu.

2. Những điểm khác nhau cơ bản giữa kiểm thử di động và kiểm thử ứng dụng trên máy tính để bàn

  • Trên máy để bàn, ứng dụng được kiểm thử ở bộ xử lý trung tâm. Với thiết bị mobile, ứng dụng được kiểm thử trên các bộ ứng cầm tay: samsung, nokia, apple…
  • Độ phân giải màn hình ứng dụng di động nhở hơn máy tính để bàn
  • Ứng dụng di động có bộ nhớ nhỏ hơn máy tính để bàn
  • Ứng dụng di động sử dụng kết nối mạng như: 2G, 3G, 4G, wifi trong khi máy tính để bàn sử dụng băng thông để kết nối
  • Các công cụ tự động cho ứng dụng máy tính để bàn không thể làm việc trên ứng dụng di động.

3. Các loại kiểm thử ứng dụng di động

Để giải quyết tất cả các khía cạnh kĩ thuật trên, các loại kiểm thử sau đây được thực hiện trên các ứng dụng di động:

  • Kiểm thử tính khả dụng (Usability Testing): Kiểm tra các khía cạnh khả năng sử dụng các ứng dụng di động, để chắc chắn rằng ứng dụng di động dễ dàng sử dụng và mang lại sự hài lòng về trải nghiệm người dùng cho khách hàng.
  • Kiểm thử chức năng (Function Testing): Kiểm tra các chức năng chính của ứng dụng di động theo đặc điểm kĩ thuật của thiết bị
  • Kiểm thử khả năng tương thích (Compatibility Testing): Kiểm tra khả năng tương thích của ứng dụng của bạn với các tính năng thiết bị gốc để đảm bảo rằng ứng dụng của bạn không cản trở các ứng dụng khác trong thiết bị. Kiểm thử ứng dụng trên các loại thiết bị di động, trình duyệt, kích thước màn hình, phiên bản hệ điều hành khác nhau – dựa vào tài liệu yêu cầu.
  • Kiểm thử giao diện (Interface testing): Kiểm tra màu sắc, menu, các icon, lịch sử, cài đặt, điều hướng trên ứng dụng, tính nhất quán của giao diện người dùng trên các thiết bị khác nhau.
  • Kiểm thử dịch vụ (Services testing): Kiểm thử ứng dụng online và offline.
  • Kiểm thử nguồn tài nguyên ở mức thấp (Low-level resource testing): Kiểm thử sử dụng bộ nhớ, tự động xóa các tệp tin tạm thời…
  • Kiểm thử hiệu năng (Performance testing): Kiểm thử hiệu năng của ứng dụng bằng cách thay đổi kết nối từ 2G, 3G sang WIFI, chia sẻ tài liệu, khả năng tiêu thụ pin… Kiểm tra hành vi của ứng dụng di động trong các nguồn tài nguyên thấp (Bộ nhớ/ Không gian lưu trữ), hành vi của trang web điện thoại di động khi nhiều người sử dụng điện thoại di động cùng truy cập vào trang app di động.
  • Kiểm thử khả năng hoạt động (Operational testing): Kiểm thử việc sao lưu và kế hoạch phục hồi dữ liệu nếu pin hết, hoặc mất mát dữ liệu trong khi nâng cấp ứng dụng từ kho ứng dụng.
  • Kiểm thử cài đặt (Installation tests): Kiểm tra ứng dụng bằng cách cài đặt/ gỡ bỏ nó trên các thiết bị.
  • Kiểm thử bảo mật (Security Testing): Kiểm thử một ứng dụng để xác minh liệu hệ thống thông tin có bảo mật dữ liệu hay không.
  • Kiểm tra gián đoạn: Vì lí do các thiết bị di động có bộ nhớ thấp hơn nhiều so với desktop nên phải đảm bảo rằng khi có cuộc gọi thoại, tin nhắn SMS, cắm sạc, thông báo bộ nhớ thấp trong khi ứng dụng đang chạy không gây ra bất cứ xung đột nào.

4. Chiến lược kiểm thử ứng dụng di động

Chiến lược kiểm thử nên chắc chắn rằng tất cả chất lượng và hiệu năng cần phải phù hợp. Một vài chiến lược kiểm thử ứng dụng di động như sau:

# 1. Việc lựa chọn các thiết bị:

Phân tích thị trường và lựa chọn các thiết bị được sử dụng rộng rãi. (Quyết định này hầu như đều phụ thuộc vào khách hàng. Khách hàng hoặc người xây dựng ứng dụng xem xét các nhân tố phổ biến hoặc các thiết bị chính tốt nhất trên thị trường cần cho ứng dụng, cần sử dụng để kiểm thử )

# 2. Môi trường giả lập:

Việc sử dụng giả lập là cực kỳ hữu ích trong giai đoạn đầu phát triển của ứng dụng. Nó cho phép chúng ta kiểm tra ứng dụng một cách nhanh chóng và hiệu quả. Giả lập là một hệ thống chạy phần mềm từ môi trường này sang môi trường khác mà không cần thay đổi chính phần mềm đó. Nó bao gồm tất cả các tính năng và làm việc trên môi trường thật.

Các môi trường giả lập thiết bị di động:
  • Giả lập thiết bị: Cung cấp bởi các nhà sản xuất thiết bị.
  • Giả lập trình duyệt: Mô phỏng môi trường trình duyệt di động.
  • Giả lập hệ điều hành: Apple cung cấp giải lập cho Iphones, Microsoft cung cấp giả lập cho window phones và Google cung cấp cho android phones
Danh sách một vài giả lập thiết bị ứng dụng miễn phí và dễ dàng sử dụng
  • iPhone Tester: Tất cả những gì bạn cần làm đó là nhập URL vào phần tìm kiếm và bạn sẽ được xem nó sẽ hiển thị như thế nào trên Iphone.

 

  • Mobile Phone Emulator: Được sử dụng để kiểm tra các thiết bị cầm tay như iPhone, Blackberry, HTC, Samsung,…

  • MobiReady: Với môi trường giả lập này, chúng tôi không chỉ kiểm tra ứng dụng web mà còn có thể kiểm tra mã.

 

  • Responsivepx: Môi trường này giúp kiểm tra phản hồi của các trang web, hiển thị và các chức năng của trang web đó.

 

  • Screenfly: Nó là một công cụ tùy biến và được sử dụng để kiểm tra các trang web theo các danh mục khác nhau.

 

# 3. Sau khi đã đạt được sự hài lòng khi phát triển ứng dụng trên giả lập, bạn hãy dùng thiết bị thật để kiểm thử.

# 4. Xem xét kiểm thử đám mây (cloud computing):

Các thiết bị chạy trên đa hệ thống hoặc mạng thông qua internet nơi mà các ứng dụng có thể được kiểm thử, cập nhật và quản lý. Về mục đích kiểm thử, nó tạo ra trang web dựa trên môi trường di động trên một giả lập để truy cập và ứng dụng di động.

Ưu điểm:

  • Sao lưu và phục hồi: Điện toán đám mây tự động sao lưu dữ liệu của bạn. Khả năng lưu trữ dữ liệu là không giới hạn.
  • Có thể truy nhập từ nhiều thiết bị khác nhau ở mọi nơi.
  • Hiệu quả, dễ sử dụng, bảo trì và cập nhật.
  • Phát triển nhanh chóng.
  • Có thể chạy các script giống nhau trên một vài thiết bị song song.

Nhược điểm:

  • Tính điều khiển kém: Vì các ứng dụng được điều khiển từ xa hoặc môi trường của bên thứ 3, người dùng bị hạn chế điều khiển và truy nhập trên một số chức năng.
  • Vấn đề về kết nối mạng: Do được thiết lập trên internet, do đó vấn đề về mạng ảnh hưởng tới sự sẵn sàng và chức năng của ứng dụng.
  • Vấn đề về an ninh: Không có cái gì trên Internet là được hoàn toàn bảo mật. Do đó, tạo cơ hội cho các hacker nhiều hơn.

# 5. Kiểm thử tự động và kiểm thử bằng tay

  • Nếu ứng dụng chứa chức năng mới, hãy kiểm thử nó bằng tay.
  • Nếu ứng dụng yêu cầu kiểm thử một hoặc hai lần, hãy kiểm thử nó bằng tay.
  • Sử dụng kiểm thử tự động cho trường hợp test hồi quy (regression test).
  • Sử dụng kiểm thử tự động cho các kịch bản phức tạp, mất nhiều thời gian để thực hiện khi thực hiện nó bằng tay.

# 6. Cấu hình mạng:

Cấu hình mạng là một phần cần thiết của kiểm thử di động. Cần kiểm thử ứng dụng trên các mạng khác nhau như: 2G, 3G, 4G, wifi…

5. Testcases cho kiểm thử ứng dụng di động

Ngoài các testcases cơ bản về chức năng, ứng dụng di động yêu cầu một vài test cases đặc biệt sau đây:

  • Tiêu hao pin: Cần phải kiểm tra lượng tiêu thụ của pin trong khi chạy ứng dụng trên các thiết bị di động.
  • Tốc độ của ứng dụng: Thời gian phản hồi trên các thiết bị khác nhau, với các tham số bộ nhớ khác nhau, với các loại mạng khác nhau…
  • Yêu cầu dữ liệu: Cài đặt để xác nhận liệu người dùng có thể download nó với lượng data giới hạn hay không?
  • Yêu cầu về bộ nhớ: Download, cài đặt và chạy thử.
  • Tính năng của ứng dụng: Chắc chắn ứng dụng không bị crash khi bị lỗi mạng hoặc bất cứ điều gì.

Phạm vi kiểm thử phụ thuộc vào một số yêu cầu cần kiểm tra hoặc mức độ thay đổi được thực hiện cho ứng dụng. Nếu những thay đổi là ít, chỉ cần thực hiện 1 vòng kiểm thử. Trong trường hợp có những thay đổi lớn hoặc phức tạp, nên sử dụng kết hợp cả kiểm thử hồi quy.

Một dự án kiểm thử ứng dụng ví dụ: ILL (International Learn Lab) là một ứng dụng được thiết kế để giúp quản trị viên, nhà xuất bản tạo các trang web hợp tác. Sử dụng trình duyệt web, người hướng dẫn chọn từ một bộ tính năng để tạo một lớp đáp ứng yêu cầu của họ.

Quy trình kiểm thử di động:

Step #1: Xác định loại kiểm thử

Vì một ứng dụng ILL có thể áp dụng cho các trình duyệt, do đó bắt buộc phải kiểm thử ứng dụng này trên tất cả các trình duyệt được hỗ trợ bằng các thiết bị di động khác nhau. Chúng tôi cần thực hiện kiểm tra khả năng sử dụng, chức năng và khả năng tương thích trên các trình duyệt khác nhau với sự kết hợp của các trường hợp kiểm thử công và kiểm thử tự động.

Step #2: Xác định Kiểm thử bằng tay hoặc kiểm thử tự động

Phương pháp tiếp theo cho dự án này là Agile với việc lặp lại hai tuần. Cứ hai tuần một lần, nhóm phát hành bản dựng mới cho nhóm kiểm thử và nhóm kiểm thử sẽ chạy các trường hợp thử nghiệm của họ trong môi trường QA. Nhóm kiểm thử tự động tạo các tập lệnh cho tập hợp các chức năng cơ bản và chạy các tập lệnh giúp xác định xem bản dựng mới có đủ ổn định để kiểm tra hay không. Nhóm kiểm tra thủ công sẽ kiểm tra chức năng mới.

JIRA được sử dụng để viết các tiêu chí chấp nhận; duy trì các trường hợp kiểm tra và ghi nhật ký/ xác minh lại các bug được tìm thấy. Khi vòng lặp kết thúc, cuộc họp lập kế hoạch lặp lại được tổ chức ở nhóm phát triển. Team, product owner, business analyst và QA team thảo luận về những điểm tốt cần phát huy và những điểm hạn chế còn tồn đọng để khắc phục.

Step #3: Beta testing

Sau khi hoàn thành kiểm tra hồi quy bởi nhóm QA, bản dựng sẽ chuyển sang UAT. Kiểm tra chấp nhận người dùng được thực hiện bởi khách hàng. Họ xác minh lại tất cả các lỗi để đảm bảo mọi lỗi đã được sửa và ứng dụng đang hoạt động như mong đợi trên mọi trình duyệt được phê duyệt.

Step #4: Kiểm thử hiệu năng

Nhóm kiểm tra hiệu suất kiểm tra hiệu suất của ứng dụng web bằng cách sử dụng các tập lệnh JMeter và với các mức tải khác nhau trên ứng dụng.

Step #5: Kiểm thử trình duyệt

Ứng dụng web được kiểm tra trên nhiều trình duyệt. Cả hai đều sử dụng các công cụ mô phỏng khác nhau cũng như sử dụng các thiết bị di động thực tế.

Step #6: Phát hành

Sau mỗi tuần thứ 4, thử nghiệm chuyển sang giai đoạn mới, trong đó vòng kiểm thử cuối cùng để kết thúc thử nghiệm trên các thiết bị này được thực hiện để đảm bảo sản phẩm đã sẵn sàng để sản xuất. Và sau đó, nó được phát hành trực tiếp!

6. Cách kiểm thử ứng dụng di động trên nền tảng Android và iOS

Điều này rất quan trọng đối với những người kiểm thử trên nền tảng Android và iOS bởi vì chúng có sự khác biệt rất lớn: khác biệt về giao diện, lượt xem ứng dụng, tiêu chuẩn mã hóa, hiệu suất,…

Sự khác biệt cơ bản giữa kiểm thử ứng dụng di động trên nền tảng IOS và android

Bạn có thể đã trải qua tất cả các hướng dẫn, tôi sẽ đưa ra một số khác biệt lớn ở đây, điều này có thể giúp bạn phần nào trong quá trình kiểm thử:

# 1) Vì có rất nhiều thiết bị Android có sẵn trên thị trường và tất cả chúng đều có độ phân giải và kích thước màn hình khác nhau.

Ví dụ: kích thước Samsung S2 quá nhỏ khi so sánh với Nexus 6. Có khả năng cao là bố cục và thiết kế ứng dụng của bạn bị biến dạng trên một trong các thiết bị. Xác suất trong iOS thấp vì chỉ có các thiết bị có thể đếm được trên thị trường và trong số nhiều điện thoại có độ phân giải tương tự.

Ví dụ: trước khi iPhone 6 trở lên ra đời, tất cả các phiên bản cũ hơn chỉ có kích thước tương tự.

# 2) Ví dụ để khẳng định điểm trên là trong Android, các nhà phát triển phải sử dụng hình ảnh 1x, 2x, 3x, 4x và 5x để hỗ trợ độ phân giải hình ảnh cho tất cả các thiết bị trong khi iOS chỉ sử dụng 1x, 2x và 3x. Tuy nhiên, trách nhiệm của người thử nghiệm là đảm bảo rằng hình ảnh và các thành phần UI khác được hiển thị chính xác trên tất cả các thiết bị.

Bạn có thể tham khảo sơ đồ bên dưới để hiểu khái niệm về độ phân giải hình ảnh:


# 3) Khi thị trường tràn ngập các thiết bị Android, mã phải được viết theo cách mà hiệu suất vẫn ổn định. Vì vậy, rất có thể ứng dụng của bạn có thể hoạt động chậm trên các thiết bị phiên bản cũ hơn.

# 4) Một vấn đề khác với Android là nâng cấp phần mềm không có sẵn cho tất cả các thiết bị. Các nhà sản xuất thiết bị quyết định khi nào cần nâng cấp thiết bị của họ. Nó trở thành một nhiệm vụ rất khó khăn để kiểm tra mọi thứ cả với hệ điều hành mới và hệ điều hành cũ.

Ngoài ra, nó trở thành một nhiệm vụ khó khăn cho các nhà phát triển để sửa đổi mã của họ để hỗ trợ cả hai phiên bản.

Ví dụ: Khi Android 6.0 xuất hiện, đã có một thay đổi lớn hệ điều hành này bắt đầu hỗ trợ cấp quyền ứng dụng. Để làm rõ hơn, người dùng cũng có thể thay đổi quyền (vị trí, danh bạ) ở cấp ứng dụng.

Bây giờ, nhóm thử nghiệm có trách nhiệm đảm bảo rằng hiển thị màn hình quyền trên ứng dụng khởi chạy trên Android 6.0 trở lên và không hiển thị màn hình cấp phép trên các phiên bản thấp hơn.

# 5) Từ góc độ kiểm thử, thử nghiệm xây dựng tiền sản xuất (tức là phiên bản beta) khác nhau trên cả hai nền tảng. Trong Android, nếu người dùng được thêm vào danh sách người dùng beta thì anh ta chỉ có thể thấy bản dựng beta được cập nhật trên Play Store nếu anh ta đăng nhập vào cửa hàng play với cùng một ID email được thêm dưới dạng người dùng beta.

Các yếu tố chính trong kiểm thử ứng dụng di động:

#1. Xác định phạm vi kiểm thử của riêng bạn
Mọi người đều có phong cách kiểm thử riêng. Một số người kiểm thử chỉ tập trung vào những gì họ nhìn thấy từ đôi mắt của họ và những người còn lại đam mê tất cả mọi thứ hoạt động đằng sau hậu trường của bất kỳ ứng dụng di động nào.

Nếu bạn là người kiểm thử iOS / Android, tôi khuyên bạn ít nhất nên làm quen với một số hạn chế/ chức năng cơ bản phổ biến của Android hoặc iOS vì nó luôn tăng giá trị cho thử nghiệm của bạn. Tôi biết những điều này không đơn giản.

#2. Đừng giới hạn quá trình kiểm thử của bạn
Việc kiểm tra không nên chỉ giới hạn trong việc khám phá ứng dụng di động và tìm ra lỗi. Với tư cách là một QA bạn nên nhận thức được tất cả các yêu cầu gửi đến máy chủ và phản hồi mà chúng tôi nhận được từ đó.

Cấu hình Putty để xem lịch sử hoặc xác minh logic cho lịch sử tùy thuộc vào nội dung đang được sử dụng trong dự án của bạn. Nó không chỉ giúp bạn biết được dòng chảy từ đầu đến cuối của ứng dụng mà còn giúp bạn trở thành một người thử nghiệm tốt hơn khi bạn có thêm ý tưởng và kịch bản ngay bây giờ.

Lý do: Không có gì đến thế giới này mà không có lý do. Bất kỳ tuyên bố nên có một lý do hợp lệ đằng sau nó. Lý do đằng sau việc phân tích lịch sử là có nhiều trường hợp ngoại lệ được ghi nhận trong lịch sử nhưng chúng không cho thấy bất kỳ tác động nào đến giao diện người dùng do đó chúng ta có thể không nhận thấy điều đó.

Vì vậy, chúng ta có nên bỏ qua nó?

Không, chúng ta không nên. Nó không có bất kỳ tác động nào đến giao diện người dùng nhưng nó có thể là một mối quan tâm tương lai. Chúng tôi có khả năng sẽ thấy ứng dụng của mình bị sập nếu các loại ngoại lệ này tiếp tục phát triển. Như chúng tôi đã đề cập về sự cố ứng dụng trong khâu cuối cùng, điều này dẫn đến việc QA có quyền truy cập vào các bản phân tích của dự án.

Crashlytics là một công cụ trong đó các sự cố được ghi lại cùng với mô hình thời gian và thiết bị.

Bây giờ câu hỏi ở đây là nếu người kiểm tra đã thấy ứng dụng bị sập thì tại sao anh ta cần phải bận tâm về sự cố?

Câu trả lời cho điều này khá thú vị. Có một số sự cố có thể không hiển thị trên giao diện người dùng nhưng chúng được ghi lại trên crashlytics. Nó có thể là do sự cố bộ nhớ hoặc một số trường hợp ngoại lệ gây tử vong có thể ảnh hưởng đến hiệu suất sau này.

#3. Kiểm tra đa nền tảng
Kiểm tra tương tác đa nền tảng là rất quan trọng.

Trích dẫn một ví dụ đơn giản, giả sử bạn đang làm việc trên một ứng dụng trò chuyện như WhatsApp hỗ trợ gửi hình ảnh và video và ứng dụng được xây dựng trên cả hai nền tảng iOS và Android (Phát triển có thể hoặc không đồng bộ hóa).

Đảm bảo kiểm tra khả năng giao tiếp của Android và iOS, lý do là iOS sử dụng “Objective C”, trong khi lập trình Android dựa trên Java và do cả hai đều được xây dựng trên các nền tảng khác nhau, đôi khi cần phải sửa chữa thêm ứng dụng để nhận ra các chuỗi đến từ các nền tảng ngôn ngữ khác nhau.

#4. Theo dõi kích thước của Ứng dụng di động của bạn

Một lời khuyên quan trọng khác cho những người kiểm thử trên thiết bị di động – Hãy tiếp tục kiểm tra kích thước của ứng dụng của bạn sau mỗi lần phát hành.

Nên đảm bảo rằng kích thước của ứng dụng không đạt đến điểm mà người dùng cuối muốn tải xuống ứng dụng này mà kích thước lớn.

#5. Kiểm thử nâng cấp ứng dụng
Đối với người kiểm thử ứng dụng di động, trường hợp nâng cấp ứng dụng là rất quan trọng. Đảm bảo ứng dụng của bạn không gặp sự cố khi nâng cấp vì nhóm nhà phát triển có thể đã không khớp với số phiên bản.

Việc lưu giữ dữ liệu cũng quan trọng không kém vì trong bất kỳ tùy chọn nào người dùng đã lưu trong phiên bản trước nên được giữ lại khi nâng cấp ứng dụng.

Ví dụ: Người dùng có thể đã lưu chi tiết thẻ ngân hàng của mình trong các ứng dụng như PayTm,…

#6. Hệ điều hành thiết bị có thể không hỗ trợ Ứng dụng
Nghe có vẻ thú vị?

Vâng, nhiều thiết bị có thể không hỗ trợ ứng dụng của bạn. Nhiều người trong số các bạn phải biết rằng các nhà cung cấp viết các trình ứng dụng có thể mọi truy vấn SQL ứng dụng của bạn không tương thích với thiết bị và do đó, nó sẽ đưa ra một ngoại lệ và thậm chí có thể không khởi chạy ứng dụng trên điện thoại đó.

Điều quan tâm ở đây là: Hãy thử sử dụng ứng dụng của bạn trên các thiết bị của riêng bạn ngoại trừ những ứng dụng bạn sử dụng trong văn phòng. Hoàn toàn có thể bạn thấy một số vấn đề với ứng dụng của mình.

#7. Kiểm tra quyền ứng dụng
Tiếp theo trong danh sách là Kiểm tra quyền của ứng dụng di động. Hầu như mọi ứng dụng thứ hai đều yêu cầu người dùng truy cập vào điện thoại liên lạc, máy ảnh, thư viện, địa điểm của họ,… Tôi đã thấy một vài người kiểm thử mắc lỗi bằng cách không kiểm tra sự kết hợp đúng đắn của các quyền này.

Ví dụ thời gian thực khi chúng tôi đang kiểm thử một ứng dụng trò chuyện có tất cả các tính năng chia sẻ hình ảnh và tệp âm thanh. Quyền lưu trữ được đặt thành NO.

Bây giờ, khi người dùng nhấp vào tùy chọn Camera, nó sẽ không bao giờ mở cho đến khi quyền lưu trữ được đặt thành YES. Kịch bản đã bị bỏ qua vì Android Marshmallow có chức năng này mà nếu quyền lưu trữ được đặt thành NO, máy ảnh có thể được sử dụng cho ứng dụng đó.

Phạm vi mở rộng hơn với những gì chúng ta đã thảo luận trong tình huống trên. Chúng ta nên đảm bảo rằng ứng dụng không yêu cầu bất kỳ quyền nào không được sử dụng.

Bất kỳ người dùng cuối nào quen thuộc với ngành công nghiệp phần mềm đều không được tải xuống ứng dụng có quá nhiều quyền được yêu cầu. Nếu bạn đã xóa bất kỳ tính năng nào khỏi ứng dụng của mình, thì hãy đảm bảo xóa màn hình cho phép tương tự.

So sánh với các ứng dụng tương tự và phổ biến trên thị trường.
Đạo đức của câu chuyện – Nếu bạn nghi ngờ, thì hãy tự mình kết luận nó. So sánh với các ứng dụng tương tự khác trên cùng một nền tảng có thể củng cố lập luận của bạn rằng chức năng được thử nghiệm có hoạt động hay không.

#8. Nhận tổng quan về tiêu chí từ chối bản build
Cuối cùng, phần lớn các bạn có thể đã gặp phải tình huống các bản build của bạn bị Apple từ chối. Tôi biết chủ đề này đã giành được phần lớn sự quan tâm của độc giả nhưng nó luôn luôn tốt khi biết các chính sách từ chối của Apple.

Là một người kiểm thử, chúng tôi trở nên khó khăn trong việc phục vụ các khía cạnh kỹ thuật nhưng vẫn có một số tiêu chí loại bỏ mà người thử nghiệm có thể quan tâm.

#9. Luôn luôn độc lập
Là một người thử nghiệm, hãy suy nghĩ và làm việc một cách khách quan và độc lập. Hãy xem xét mọi vấn đề từ nhiều phía từ Nhóm Dev/ Người quản lý. Nếu bạn đam mê kiểm thử thì luôn luôn có mặt trong mọi tình huống. Cố gắng tham gia vào các hoạt động của dự án, trước khi bạn bắt tay vào kiểm thử.

Quan trọng nhất, hãy tiếp tục xem JIRA, QC, FRS hoặc bất cứ điều gì được sử dụng trong dự án của bạn cho tất cả các cập nhật mới nhất từ khách hàng và nhà phân tích kinh doanh. Ngoài ra, hãy sẵn sàng chia sẻ quan điểm của bạn nếu bạn yêu cầu sửa đổi. Điều này áp dụng cho tất cả những người kiểm thử đang làm việc trên các phiên bản và nền tảng khác nhau.

Cho đến khi không cảm thấy sản phẩm là của riêng mình.

#10. Giữ ứng dụng của bạn ở chế độ nền trong một thời gian dài (12-24 giờ)
Tôi biết nghe có vẻ lạ nhưng có nhiều logic đằng sau hậu trường mà tất cả chúng ta đều không hiểu.

Tôi đang chia sẻ điều này bởi vì tôi đã thấy ứng dụng bị sập sau khi khởi chạy nó, nói sau khoảng 14 giờ từ trạng thái nền. Lý do có thể là bất cứ điều gì tùy thuộc vào cách các nhà phát triển đã mã hóa nó.

#11. Kiểm tra hiệu suất ứng dụng của bạn
Trong thế giới di động, hiệu suất của ứng dụng của bạn tác động đến mức độ ứng dụng được công nhận trên toàn thế giới. Là một nhóm kiểm thử, việc kiểm tra phản hồi ứng dụng của bạn trở nên quá quan trọng và quan trọng hơn là cách thức hoạt động khi một số lượng lớn người dùng đang truy câp hoặc sử dụng đồng thời.

Ví dụ: về PayTm.

Tất cả các bạn phải nhấp vào tùy chọn THÊM TIỀN trong ứng dụng PayTm, sau đó sẽ hiển thị số dư bạn có trong ví của mình. Nếu chúng tôi xem xét những gì đang diễn ra đằng sau hậu trường, thì đó là một yêu cầu đang diễn ra với máy chủ với ID người dùng PayTm và máy chủ sẽ gửi lại phản hồi với số dư trong tài khoản của bạn.

Trường hợp trên chỉ khi một người dùng đã nhấn máy chủ. Chúng tôi cần đảm bảo rằng ngay cả khi 1000 người dùng truy cập máy chủ, họ sẽ nhận được phản hồi tốt đúng hạn vì khả năng sử dụng của người dùng cuối là mục tiêu chính của sản phẩm.

Kết luận

Để thiết kế chiến lược kiểm thử đúng đắn, cần phải lựa chọn đúng giả lập di động, thiết bị và công cụ kiểm thử. Chắn chắn rằng có thể bao phủ được 100% bao gồm tính an toàn, tính có thể sử dụng, hiệu năng, chức năng, khả năng tương thích.

Kiểm thử di động ban đầu có vẻ rất dễ dàng nhưng khi bạn tiếp tục đào sâu, bạn sẽ hiểu rằng không dễ để đảm bảo rằng mọi thứ được phát triển sẽ chạy trơn tru trên hàng ngàn thiết bị trên toàn thế giới .

Bạn hầu như chỉ thấy các ứng dụng được hỗ trợ trên các phiên bản hệ điều hành mới nhất. Tuy nhiên, nhiệm vụ của những người kiểm thử là đảm bảo rằng họ không bỏ lỡ bất kỳ kịch bản nào. Chúng còn nhiều điểm khác cần được xem xét.

Các kịch bản như tiêu thụ pin, kiểm tra gián đoạn, thử nghiệm trên các mạng khác nhau (3G, Wi-Fi), kiểm tra trong khi chuyển đổi mạng, kiểm tra khỉ các ứng dụng di động, v.v … đều hữu ích khi thử nghiệm trên thiết bị di động.

Thái độ của người kiểm tra rất quan trọng trong môi trường thử nghiệm thực sự. Khi bạn nghiêm túc thực hiện bạn sẽ đạt được thành quả nhất định. Hi vọng qua những hướng dẫn trên đây các bạn sẽ hiểu được phần nào về kiểm thử trên ứng dụng di động.

Tham Khảo: https://www.softwaretestinghelp.com/beginners-guide-to-mobile-application-testing/

Có thể bạn sẽ thích…

1 phản hồi

  1. 26/08/2019

    […] Bài 1: Giới thiệu kiểm thử thiết bị di động […]

Để lại một bình luận