Tutorial #7: Kiểm thử ứng dụng di động trên thiết bị phiên bản hệ điều hành thấp

Tại sao việc kiểm tra ứng dụng di động trên các thiết bị có version/phiên bản hệ điều hành thấp lại quan trọng?

Khi một QA bắt đầu làm việc trong một dự án ứng dụng di động, câu hỏi lớn nhất mà anh ấy/ cô ấy phải đối mặt là về môi trường thử nghiệm.

Với thị trường di động đang phát triển mỗi ngày thì việc quyết định các thiết bị mà ứng dụng di động của bạn nên thử nghiệm là một thách thức thực sự. Vì không thể mua tất cả các thiết bị đang có trên thị trường hoặc không thể thực hiện mọi thử nghiệm trên trình giả lập điều này vượt quá giới hạn, nên các thử nghiệm phải được tạo ra một cách chọn lọc và thông minh.

Android là một hệ điều hành mã nguồn mở và đã mở ra cánh cửa cho các công ty ra mắt thiết bị của họ và điều đó đồng nghĩa giá thành của nó khá thấp. Không phải ai cũng có thể mua iPhone hoặc Samsung S7 hoặc Nexus6, v.v., do đó mọi người có xu hướng mua điện thoại giá cả phải chăng như Samsung S6 hoặc Nexus 5 hoặc Redmi Note4,…

Các Loại Thiết Bị Di Động

Ở mức cao, các thiết bị có thể được phân loại thành thiết bị cao cấp và cấp thấp:

Các thiết bị cao cấp thường là những thiết bị có hệ điều hành Android, 4G hoặc LTE mới nhất, kích thước màn hình 8 inch trở lên, bộ nhớ 7+ GB,…và có giá thành tương đối cao.

Các thiết bị cấp thấp chỉ là những thiết bị đối nghịch với phiên bản HĐH cũ hơn, 2G hoặc ở mạng 3G tối đa, màn hình nhỏ, bộ nhớ thấp hoặc điện thoại có khe cắm thẻ nhớ không lớn hơn 2 hoặc 3 GB và do đó giá thành khá rẻ.

Ví dụ: dưới đây là biểu đồ phân phối điện thoại thông minh cho năm 2017 dựa trên loại mạng:

Như bạn có thể thấy, chỉ có 28% người dùng đang sử dụng công nghệ LTE mới nhất và tiên tiến trong khi phần lớn người dùng vẫn sử dụng GSM.

Các Loại Điện Thoại Nên Sử Dụng Trong Kiểm Thử

Là một Người kiểm thử, thì diện thoại di động mà bạn nên lựa chọn để đưa vào thử nghiệm là gì?

Trong khi lựa chọn môi trường để kiểm thử ứng dụng di động, bạn có thể quyết định kiểm thử thủ công hoặc tự động đồng nghĩa với việc này là bạn có thể sử dụng thiết bị thực hoặc trình giả lập. 

Lựa chọn giữa trình giả lập và thiết bị thực là một câu hỏi khó vì không phải tất cả các sự cố đều xảy ra với trình giả lập hoặc thiết bị thực (cửa sổ bật lên lỗi hoặc thông báo thường bị loại bỏ). Trong khi mặt khác, việc mua tất cả các thiết bị thực đang có trên thị trường đòi hỏi một nguồn chi phí khá lớn cho công ty của bạn.

Nếu có thể bạn nên lựa chọn cho dự án cuả mình một điện thoại cao cấp, 1 hoặc 2 điện thoại tầm trung và ít nhất 2 điện thoại cấp thấp.

Kinh nghiệm mà tôi có được khi làm việc trên nhiều loại thiết bị khác nhau là:

#1) Điện thoại cao cấp: Các ứng dụng chạy rất mượt trên, rõ ràng vì bạn có kết nối 4G, bộ nhớ 8GB, màn hình lớn sẽ bị trục trặc hoặc gặp sự cố. Các điện thoại cao cấp nên được ưu tiên để kiểm tra các khía cạnh chức năng của ứng dụng nhưng nó chưa chắc đã chứng minh là một lựa chọn tốt nhất để kiểm tra khả năng mở rộng (đối với dữ liệu di động) hoặc lỗi giao diện người dùng hoặc rò rỉ bộ nhớ.

#2) Điện thoại Mid End: Ứng dụng chạy mượt mà nhưng vẫn có thể mở rộng và rò rỉ bộ nhớ như 1 trên 15 lần. Nhưng điều này là không đủ vì các sự cố bị lỗi do khách hàng báo cáo cho một ứng dụng di động là không thể chấp nhận được và nó để lại hình ảnh xấu, không giống như các ứng dụng trên máy tính để bàn hoặc web.

#3) Điện thoại cấp thấp: Ứng dụng có thể hoặc không thể chạy trơn tru trên điện thoại cấp thấp do một số yếu tố nhất định. 

Những yếu tố đó bao gồm:

1) Mạng chậm: Hiện tại các thiết bị cấp thấp không có loại mạng ngoài 3G và có các ứng dụng chạy trong nền sử dụng băng thông mạng. Trong một kịch bản thực tế, có thể người dùng đã bật Sync On cho tài khoản email của mình, Whatsapp, Google Now,…chạy trong nền ăn băng thông.

2) Giao diện người dùng : Các thiết bị cấp thấp có thể có kích thước màn hình từ 4 inch đến 6 hoặc 7 inch, do đó việc cuộn xuống danh sách hoặc nhấn vào biểu tượng là một điều khó khăn. Các biểu tượng có kích thước nhỏ và không dễ để chạm vào chúng. Tương tự cuộn xuống một danh sách dài cũng có thể gây ra sự cố và các thẻ trong danh sách không tải hoàn toàn hoặc chúng bị biến dạng.

Sau đây là một ví dụ về lỗi UI

3) Bộ nhớ thấp: Các thiết bị cấp thấp không có bộ nhớ lớn và hầu hết các ứng dụng có tối đa khoảng 5 – 6 GB. Do đó, các ứng dụng chạy chậm và đôi khi điện thoại hiển thị các tin nhắn để đóng hoặc ‘buộc dừng’ một số ứng dụng để giải phóng bộ nhớ.

Tại Sao Kiểm Thử Trên Điện Thoại Cấp Thấp Lại Quan Trọng?

Tùy thuộc vào đối tượng mục tiêu của bạn, không cần sử dụng thiết bị cấp thấp mỗi lần kiểm thử nhưng khi bạn thực hiện phát hành ứng dụng ban đầu, bạn chắc chắn nên thử nghiệm đầy đủ trên thiết bị cấp thấp.

Trên khắp thế giới, người dùng điện thoại cao cấp đắt tiền ít hơn và người dùng điện thoại trung và thấp có số lượng nhiều hơn. Nếu ứng dụng của bạn chạy trơn tru trên điện thoại cao cấp, thì điều đó không có nghĩa là nó cũng sẽ hoạt động tốt trên thiết bị cấp thấp.

Theo những kinh nghiệm mà tôi có thì với một sản phẩm tôi muốn thử nghiệm trên điện thoại cấp thấp trước.

Thử nghiệm trên điện thoại cấp thấp rất quan trọng vì:

  • Hệ điều hành của điện thoại hơi cũ và phiên bản không phải là phiên bản mới nhất.
  • Có rất nhiều ứng dụng đã được cài đặt trên điện thoại sử dụng bộ nhớ lớn, do đó đây là một môi trường hoàn hảo để kiểm thử trên ‘bộ nhớ thấp’.
  • Tương tác với các ứng dụng khác để kiểm tra tính tương thích như sử dụng Google Maps, Trình quay số điện thoại, ứng dụng Nhắn tin,…
  • Chức năng camera không tiên tiến trong điện thoại cấp thấp.
  • Nếu ứng dụng của bạn cần gửi tọa độ địa lý, thì pin của điện thoại cấp thấp sẽ nhanh chóng cạn kiệt.
  • Việc sở hữu màn hình quá nhỏ, chạm vào biểu tượng hoặc cuộn hoặc điều hướng giữa các màn hình có thể xảy ra vấn đề,…

Khi tôi đang thử nghiệm ứng dụng của mình trên các thiết bị cấp thấp, sau đây là những vấn đề mà tôi quan sát thấy chỉ trên điện thoại cấp thấp và không có trên các thiết bị điện thoại khác:

  • Ứng dụng của chúng tôi có dịch vụ web để gửi vị trí địa lý cứ sau 10 phút nhưng trên điện thoại cấp thấp (mà chúng tôi đang sử dụng) có 2G, cuộc gọi dịch vụ web đã thất bại. Do đó, có hai vấn đề lớn xuất hiện:

           – [i] vị trí không được ghi trong DB.

           – [ii] pin của điện thoại bị cạn kiệt.

  • Khi thử nghiệm trên 2G, chúng tôi thấy rằng các dịch vụ web đã tốn một ít thời gian để đăng nhập hoặc tìm nạp dữ liệu cho màn hình hoặc gửi dữ liệu đi. Đôi khi để xem được dữ liệu cập nhật, phải mất 15 phút.
  • Chúng tôi đã có thẻ để hiển thị danh sách giao hàng trong một ngày và trong khi cuộn một danh sách dài gồm 50 thẻ, ứng dụng đã bị sập.
  • Trong khi nhấp vào nút Quay lại, việc điều hướng không thành công và nó đang điều hướng 2 màn hình trở lại thay vì một màn hình.
  • Chúng tôi đã có cơ sở chụp ảnh và sau khi chụp ảnh, chúng tôi đã định cỡ lại (giảm) hình ảnh.Trên các điện thoại cấp thấp, máy ảnh đã bị hỏng sau khi chụp 3-4 hình ảnh trong khi định cỡ lại vì bộ nhớ không được giải phóng khỏi lần chụp ảnh trước đó.

Sau đây là một ví dụ về lỗi như vậy có thể xảy ra:

  • Một số biểu tượng xuất hiện quá nhỏ để có thể Click  và do đó nó đã chặn kiểm tra một số chức năng.

Theo những quan sát mà chúng tôi thu thập được thì đây là một trong những lỗi nghiêm trọng nhất không chỉ xuất hiện một lần trên thiết bị cao cấp. Tất cả những vấn đề này sau đó đã được nhóm phát triển khắc phục và chúng tôi đã thực hiện kiểm thử hồi quy hoàn toàn trên điện thoại cấp thấp.

Trên thực tế, trong lần phát hành đầu tiên, chúng tôi đã gặp phải rất nhiều sự cố máy ảnh từ các khách hàng đang sử dụng điện thoại cấp thấp và sau khi nhấp vào khoảng 20-30 hình ảnh, chúng tôi có thể tái hiện được lỗi đó. Đó là một thử thách khó khăn đối với chúng tôi khi bắt đầu kiểm thử ứng dụng di động.

Những người giao hàng không sử dụng điện thoại cao cấp và chỉ có khoảng 5% trong số họ có iPhone 5 hoặc S3 (là sản phẩm mới nhất vào thời điểm đó. Trong khi thử nghiệm trên một thiết bị cấp thấp, sẽ rất tuyệt khi sử dụng mạng di động thay vì Wifi tốc độ cao.

Sau lần phát hành đầu tiên, chúng tôi đã thực hiện kiểm thử tính năng mở rộng, stress và giao diện người dùng trên 2 loại điện thoại: cấp thấp và 1 điện thoại trung cấp, tuy nhiên, các vấn đề chủ yếu được tìm thấy trên các điện thoại cấp thấp. Để chắc chắn, chúng tôi đã thực hiện một BVT trên điện thoại cao cấp.

Không nhất thiết là bạn sẽ gặp phải loại vấn đề tương tự nhưng bạn chắc chắn sẽ quan sát được các vấn đề với điện thoại cấp thấp mà bạn sẽ không bao giờ gặp phải trên điện thoại cao cấp.

Một ví dụ khác xuất hiện trong đầu tôi là rất nhiều ứng dụng sử dụng Google Maps để tải vị trí hoặc hiển thị vị trí của chúng.

Trên điện thoại cấp thấp, phiên bản Google Maps có thể cũ và do đó có thể có sự cố tương thích khi ứng dụng của bạn thực hiện cuộc gọi để tải vị trí trong Google Maps hoặc do mạng chậm, có thể mất nhiều thời gian hơn để tải. Cũng có thể Bản đồ có thể không tải vị trí chính xác mà ứng dụng của bạn thực sự muốn.

Trình Giả Lập Hoặc Trình Mô Phỏng Thay Thế Cho Điện Thoại Cấp Thấp

Tôi có thể sử dụng Trình giả lập hoặc Trình mô phỏng để thay thế cho Điện thoại cấp thấp không?

Không nên sử dụng trình giả lập hoặc giả lập cho điện thoại cấp thấp vì nhóm phát triển ứng dụng của tôi đã thử điều đó và họ đang thực hiện BVT trên trình giả lập và do đó họ đã bỏ lỡ một số sự cố.

Ban đầu, khi chúng tôi bắt đầu làm việc trên một ứng dụng di động, chỉ chúng tôi mới biết và nhóm phát triển không biết rằng có rất nhiều thông báo lỗi bị các trình giả lập loại bỏ và các lỗi không được hiển thị. Chúng tôi đã tìm thấy các vấn đề trong khi thử nghiệm trên các thiết bị thực.

Sau đó, ngay cả nhóm phát triển của chúng tôi đã bắt đầu sử dụng thiết bị thực để thử nghiệm thay vì sử dụng trình giả lập hoặc mô phỏng. Một lý do khác để tránh sử dụng trình giả lập là không thể tạo mạng 2G hoặc 3G và họ sử dụng mạng tốc độ cao của máy tính xách tay hoặc máy tính để bàn của bạn. Tuy nhiên, bạn có thể thực hiện kiểm tra giao diện người dùng và việc xử lí điều hướng trên trình giả lập.

Chiến Lược Thử Nghiệm Cho Điện Thoại Cấp Thấp

Là một QA, chiến lược ‘thử nghiệm’ của tôi đối với điện thoại cấp thấp là gì?

Để quyết định chiến lược thử nghiệm cho điện thoại cấp thấp, hãy xác định thật rõ ràng về các yêu cầu ứng dụng của bạn và những tính năng nào của điện thoại cấp thấp sẽ ảnh hưởng đến ứng dụng và hiệu suất của ứng dụng đó. Các vấn đề tìm thấy trên điện thoại cấp thấp rất khó và càng khó khăn hơn cho QA, rất khó để tái tạo, xác minh và khắc phục các lỗi đó.

Sau đây là một số gợi ý để quyết định chiến lược của bạn, những điều này đã giúp tôi và nhóm của tôi, hy vọng nó cũng sẽ giúp ích được cho bạn:

  • Không bao giờ chỉ thực hiện kiểm thử trên mình điện thoại cấp thấp, số lượng thiết bị và môi trường kiểm thử càng nhiều thì cơ hội tìm thấy các lỗi tiềm ẩn càng lớn.
  • Không nên chỉ để 1 QA thực hiện việc kiểm thử trên một chức năng cụ thể. Mà nên ‘ghép nối QA’ hoặc thử nghiệm theo một vòng tròn như nếu QA1 Kiểm tra chức năng F1, sau đó để QA2 xác minh các lỗi được báo cáo cho F1, và QA3 thực hiện việc kiểm tra hồi quy. Như thế việc tìm ra lỗi hoặc các lỗ hổng mà chúng ta bỏ sót là rất lớn.
  • Thảo luận về chiến lược của bạn, những phát hiện của bạn với các QA khác trong nhóm của bạn, điều này giúp ích rất nhiều vì có thể họ thấy điều gì đó mà bạn có thể không hoặc những người có kinh nghiệm đi trước sẽ giúp đỡ được cho bạn.
  • Khi ứng dụng của bạn hoạt động không được ổn định, hãy tạo một bộ kiểm thử riêng cho các điện thoại cấp thấp và giữ cho chúng được ước tính.
  • Thực tế không thể tạo ra một môi trường thử nghiệm lý tưởng và bạn cũng không có tất cả các mẫu điện thoại đang có trên thị trường. Do đó (với sự đồng ý của Người quản lý hoặc SM), hãy cùng kiểm tra với các đồng nghiệp khác trong công ty của bạn, những người có các thiết bị đó và yêu cầu họ cài đặt và sử dụng ứng dụng của bạn.
  • Tương tự như vậy đối với thử nghiệm Beta, yêu cầu BA hoặc Chủ sở hữu sản phẩm của bạn sử dụng điện thoại cấp thấp và thực hiện kiểm thử một vòng từ đầu đến cuối.
  • Khi các lỗi chính được tìm thấy (như các lỗi được đề cập ở trên), hãy ngồi với nhà phát triển được chỉ định trong khi họ sửa và cũng hiểu từ họ lý do đằng sau lỗi. Điều này sẽ giúp bạn không chỉ trong việc xác minh mà còn giúp bạn trong kiểm thử hồi quy. Bạn cũng có thể lấy ý kiến ​​từ các nhà phát triển để thực hiện việc kiểm thử hồi quy sao cho hiệu quả đem lại lớn nhất.
  • Cuối cùng nhưng không kém phần quan trọng ghi lại những lỗi mà bạn gặp phải trong dự án của mình, đây là một kiến ​​thức lớn mà bạn có được và cũng có thể giúp đỡ người khác. Hãy tạo thành tài liệu về các lỗi thường gặp, cách khắc phục, xác minh và hồi quy.

Kết Luận

Ứng dụng di động là một thị trường phát triển nhanh và có một điện thoại hệ điều hành mới được ra mắt mỗi tháng. Với vai trò là một QA, không thể kiểm tra mọi kết hợp điện thoại OS và điều đó cũng không khả thi. Do đó, trong khi lựa chọn thử nghiệm của bạn, hãy lựa chọn thông minh và chọn điện thoại, trình giả lập,… cho từng loại cao cấp, trung bình và thấp.

Thử nghiệm trên một danh mục khác nhau có thể khác nhau tùy theo yêu cầu ứng dụng của bạn nhưng theo kinh nghiệm của tôi, phải có thử nghiệm (từ đầu đến cuối) trên thiết bị cấp thấp. Lý do là trên các điện thoại cấp thấp các tính năng lỗi thời, mạng chậm,… dẫn đến các vấn đề mà bạn có thể không quan sát được trên điện thoại cao cấp.

Trong thử nghiệm ứng dụng di động, các sự cố không phải lúc nào cũng được tìm thấy trong thử nghiệm mà đôi khi các sự cố báo cáo của khách hàng mà bạn không bao giờ nhận thấy. Do đó, Chủ sở hữu sản phẩm của bạn có thể một hoặc hai lần xin lỗi nhưng không phải lúc nào cũng vậy, vì vậy, hãy cố gắng kiểm tra thêm trên điện thoại cấp thấp.

Nếu Người quản lý hoặc BA của bạn không quan tâm đến việc phải kiểm thử trên các thiết bị điện thoại cấp thấp, hãy cố gắng thuyết phục họ, trừ khi họ có lý do mạnh mẽ hoặc chắc chắn rằng tất cả khách hàng mục tiêu đều sử dụng điện thoại tốt nhất.

Tham khảo: https://www.softwaretestinghelp.com/mobile-testing-low-end-devices/

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

Bình luận

Thư điện tử của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

4 Shares
Share via