Test Hiệu Năng của Ứng Dụng Điện Thoại: Chiến Lược, Checklist, Tools (Phần I)

Đối với bất kỳ ứng dụng điện thoại nào, hiệu năng mang tính then chốt. Nếu ứng dụng điện thoại của bạn không thực thi tốt, các end user sẽ xóa ứng dụng của bạn và tìm các ứng dụng khác thực thi tốt hơn. Ứng dụng của bạn cần được test hết sức hoàn hảo trước khi đưa nó tới end user.

Hiệu năng của các ứng dụng trên 1 điện thoại hay bất cứ thiết bị thông minh nào đó thường được đánh giá theo 3 tiêu chí:

• Hiệu năng thiết bị
• Hiệu năng Server/API
• Hiệu năng mạng

Hiệu năng thiết bị

Khi người sử dụng trải nghiệm các ứng dụng chậm, họ sẽ rất khó chịu

Đối với hiệu năng thiết bị, bạn sẽ kiểm tra như sau:

• Khởi động ứng dụng Cần bao nhiêu thời gian để ứng dụng của bạn khởi động? Nó là thông số hiệu năng đầu tiên được đánh giá bởi các user. Theo nguyên tắc ngón tay cái, sau khi các user chạm vào biểu tượng ứng dụng , màn hình hiển thị đầu tiên sẽ được hiển thị trong 1-2 giây.

• Thời lượng pin trong khi sử dụng 1 ứng dụng Khi sử dụng liên tục, 1 vài ứng dụng điện thoại, tiêu thụ 1 lượng lớn pin và làm nóng điện thoại. Yếu tố này làm tăng rất nhiều performance của bất kỳ ứng dụng điện thoại nào và thường có thể xảy ra khi ứng dụng của bạn đang sử dụng nhiều tài nguyên hơn được yêu cầu. Sử dụng tài nguyên quá mức sẽ tạo ra gánh nặng cho bộ vi xử lý và điện thoại bị nóng lên.

• Tiệu thụ bộ nhớ Khi test 1 ứng dụng, sự tiêu thụ bộ nhớ bởi 1 ứng dụng cần phải được kiểm tra. Bằng các thực thi 1 số chức năng nhất định trong ứng dụng, sự tiêu thụ bộ nhớ cũng sẽ tăng. Ví dụ, trong các ứng dụng android khi các thông báo được đẩy lên thì sự tiêu thụ bộ nhớ tăng. Trong 1 vài trường hợp, có thể quan sát thấy việc sử dụng bộ nhớ của toàn bộ OS chỉ là 14% nhưng 1 ứng dụng mới đang tiêu thị 11%. Vậy những yếu tố này buộc phải được xử lý trước khi triển khai ứng dụng tới thế giới thật và đưa tới các người sử dụng.

• Sự khác nhau giữa Hardware/Software Khi test 1 ứng dụng điện thoại, bắt buộc phải kiểm tra các ứng dụng trên các thiết bị khác nhau. Có trường hợp mà ứng dụng đang chạy mượt trên 1 thiết bị nhưng trên thiết bị khác thì không. Giống với các nhà cung cấp khác nhau của android, chúng ta có thể kiểm tra các ứng dụng trên các điện thoại Samsung, HTC, và Lenovo. Tương tự, các ứng dụng cần được kiểm tra với các loại ram khác nhau và các thông số kỹ thuật như 1GB hay 2GB.

• Sử dụng với các ứng dụng khác Khi các ứng dụng được test đang chạy song song với các ứng dụng khác, không nên có sự can thiệp. Các tốt nhất để kiểm tra nó là bằng việc chuyển đổi qua lại ứng dụng test và các ứng dụng khác.

• Ứng dụng chạy ẩn 1 ứng dụng mà đang chạy ẩn được khôi phục lại, nó sẽ vẫn duy trì trong cùng trạng thái giống như trước. Nếu kịch bản này không được xử lý chính xác, thì dữ liệu sẽ bị mất. 1 lần nữa bạn phải nhập lại dữ liệu từ đầu khi đang khôi phục lại các ứng dụng.

Hiệu năng của Server/API

Khi các ứng dụng đang tương tác với các server qua API, thời gian phản hồi trở thành tính quyết định tới hiệu năng. Đối với hiệu năng server, bạn cần kiểm tra như sau

• Dữ liệu đến và từ Server Các ứng dụng nên xử lý dữ liệu hiệu quả khi nó được gửi từ server. Không phải mất quá nhiều thời gian trong khi tải dữ liệu. Trong các ứng dụng nhất định, dữ liệu được gửi trong 1 định dạng được xác định. Vì vậy trước khi hiển thị nó trong các ứng dụng, nó sẽ cần được chuyển đối tới sang 1 định dạng phù hợp. Trong quá trình này, các ứng đụng đôi khi trở nên chậm hơn và thời gian phản hồi trở nên dài hơn.

• Các API Calls được tạo ra từ ứng dụng Số các call từ ứng dụng đang test tới server được tạo ra từ ứng dụng cần hạn chế. Trong 1 vài trường hợp, nhiều API call được thực hiện cho cùng 1 chức năng. Để hiệu năng tốt hơn, điều này cần được xử lý với số lượng call ít nhất.

• Server down time Do bất kỳ lý do gì đó nếu các server down hoặc không thể truy cập được chúng ta có thể lưu dữ liệu trong cơ sở dữ liệu tại nơi sử dụng. Vì vậy, bất cứ khi nào các server down, chúng ta có thể hiển thị dữ liệu được lưu trữ trong các cơ sở dữ liệu tại nơi sử dụng. 1 giải pháp khác có thể là các server cơ sở dữ liệu dự phòng nghĩa là nếu 1 trong các server down hoặc trong giai đoạn bảo trì, server dự phóng sẽ có sẵn để chuyển đổi. Server dự phòng sẽ cần được sao lưu liên tục và đồng bộ với server chính.

Hiệu năng mạng

Hiệu năng của các ứng dụng trên các mạng khác nhau và các thuộc tính mạng cần được đánh giá.

Đối với hiệu năng mạng, bạn cần kiểm tra các thứ sau.

• Jitters Khi có trễ trong việc tiếp nhận thông tin trên mạng, thì nó được gọi là các jitter. Đó là 1 vấn đề với các mạng phi kết nối hoặc các mạng chuyển mạch. Khi thông tin được phân phối vào trong các gói dữ liệu, các gói tin có thể đi qua bởi 1 con đường không giống nhau từ người gửi đến người nhận. Khi dữ liệu đến tại địa điểm dự kiến, nó sẽ trở nên hỗn độn hơn so với ban đầu. Trong trường hợp của jitter, các ứng dụng điện thoại cần có đủ khả năng để xử lý nó. Bạn cần hiển thị các thông báo thích hợp để các end user, hoặc gửi yêu cầu lại hoặc đợi cho đến khi hệ thống phản hồi trở lại.

• Packet loss Trong trường hợp mất toàn bộ gói tin, các ứng dụng sẽ có thể gửi lại yêu cầu cho các thông tin hoặc sẽ tạo ra các cảnh báo phù hợp. Nếu dữ liệu không hoàn chỉnh, thì các user sẽ không thể hiểu được thông tin được hiển thị trong ứng dụng. Điều này có thể gây stress cho các user. Vì vậy, tốt hơn là hiển thị 1 thông điệp phù hợp hoặc nhắc người dùng thử lại.

• Tốc độ mạng Các ứng dụng cần được kiểm tra trên nhiều trạng thái mạng khác nhau với tốc độ thay đổi. Các ứng dụng phải được test trên 2.5G, 3G và 4G. Cả wifi và mạng điện thoại đều được bao gồm. Ngoài ra, các hành xử của ứng dụng cần được theo dõi. Đặc biệt, khi cả 2 loại mạng có sẵn, và sự chuyển đổi xảy ra từ mạng này sang mạng khác. Ví dụ, 1 vấn đề có thể phát sinh trong 1 ứng dụng cho các user trong khi chuyển từ mạng điện thoại từ 4G sang wifi và ngược lại. Trong trường hợp này, các sẽ không phản hồi và có thể yêu cầu khởi động lại các ứng dụng để sử dụng.

Tham khảo: http://www.guru99.com/mobile-app-performance-testing-strategy-tools.html