Kiểm thử Game Android

1. Định nghĩa kiểm thử game

Kiểm thử là một phần trong quá trình phát triển game, nhằm kiểm soát chất lượng của sản phẩm được tạo ra. Mục đích của kiểm thử nhằm phát hiện và tài liệu hóa về các lỗi có thể có của phần mềm. Kiểm thử game đòi hỏi nhiều chuyên môn về tính toán, khả năng phân tích,, kỹ năng đánh giá và quan trọng nhất đó chính là sự kiên trì. Trong vài năm trở lại đây, kiểm thử game đang bị chỉ trích rất nhiều vì quá vất vả, tiêu tốn tiền bạc và gây “stress” cho các nhân viên.

1.1. Lịch sử (History)

Trong những ngày đầu, khi con người mới bắt đầu phát triển game trên hệ thống máy tính cá nhân, nhà phát triển sẽ phải chịu trách nhiệm về việc thực hiện các ca kiểm thử. Một dự án thường chỉ có một hoặc nhiều nhất là hai nhân viên kiểm thử (hay gọi là tester), và đôi khi chính các lập trình viên sẽ làm công việc này.

Khi mà các trò chơi (game) ngày càng trở thành phức tạp hơn thì việc “Đánh giá chất lượng” hay “Đảm bảo chất lượng” là cần thiết. Hầu hết các công ty đều có một “tester” kinh nghiệm tiến hành kiểm thử các sản phẩm do lập trình viên khác nhau làm ra.

Bây giờ hầu hết các lập trình viên (developer) đều dựa sự hiểu biết về kỹ thuật cũng như kinh nghiệm của chính mình để tìm ra các lỗi (bugs) trong mã nguồn chương trình hay các lớp đồ họa (graphics layer). Nhân viên kiểm thử sẽ phải chơi nhiều trò chơi khác nhau trên nhiều nền tảng khác nhau (Windows phone, Android, iOS, BlackBerry, ….). Họ có khả năng ghi chú tốt, có thể tìm ra bất cứ vấn đề nào trong báo cáo chi tiết, đáp ứng được kỳ hạn với các yêu cầu cao nhất. Vị trí của nhân viên kiểm thử là rất căng thẳng, chịu nhiều áp lực, đồng lương ít ỏi tuy nhiên lại được đánh giá cao và nó đang ngày một phát triển.

1.2. Mục tiêu và phạm vi

Rất đơn giản, kiểm thử game là nhằm xác định tất các lỗi có thể có trong sản phẩm và loại bỏ chúng. Có nhiều kĩ thuật kiểm thử được áp dụng trong quá trình kiểm thử game nhưng chủ yếu vẫn là “Kiểm thử hộp đen” (Black box) và “Kiểm thử hộp trắng’ (White-box hay Clear-box). Đối tượng và quy trình của hai kỹ thuật kiểm thử này là không có gì khác biệt (Lập kế hoạch kiểm thử, thiết kế kiểm thử, tiến hành kiểm thử, kiểm thử hồi quy và báo cáo lỗi) tuy nhiên chúng lại nhấn mạnh vào các khía cạnh khác nhau của trò chơi:

• “Kiểm thử hộp đen”: tập trung vào các chức năng hay “game play” của trò chơi. Ví dụ như: các menu lựa chọn, cách dùng các nút, đồ họa, animation và “game play” có giống như trong thiết kế hay không.
• “Kiểm thử hộp trắng”: tập trung vào kiến trúc và sự tích hợp giữa các module trò chơi. Ví dụ: cách sử dụng cơ sở dữ liệu, sự tương tác giữa các thành phần của trò chơi như “redering engine”, AI, sound and music…

Đối với kiểm thử hộp đen thì nhân viên kiểm thử phải nắm rõ được cách chơi (cách sử dụng phím điều hướng, các luật…). Còn hộp trắng đòi hỏi phải hiểu rõ về code. Nhân viên kiểm thử sử dụng một công cụ “debugging “, mã nguồn cùng với dữ liệu đầu vào từ đó phân tích kết quả đầu ra có đúng như mong đợi hay không.

1.3. Triết lý kiểm thử (Testing Philosophy)

Kiểm thử không phải là công việc của một người, đó không phải là trách nhiệm nhân viên kiểm thử. Mỗi thành viên trong đội dự án đều phải có chữ “chất lượng” trong đầu, mỗi người phải chịu trách nhiệm về tính chính xác và hoàn thiện của công việc mình làm.

Kiểm thử không chỉ là một quá trình và nó không nên được sử dụng một cách độc lập. Kiểm thử là một phần không thể thiếu trước, trong và sau khi phát triển game.

Trên thực tế, không ai có thể kiểm thử trò chơi một cách hoàn hảo được, tức là kiểm thử tất cả các thành phần của trò chơi, các nhân vật, lỗi logic, input, giao diện hay AI. Chúng ta sẽ áp dụng quy luật “80 – 20” để có được một kết quả kiểm thử tốt nhất, chỉ kiểm tra 20% những phần hay xảy ra lỗi nhất.

2. Kế hoạch và yêu cầu kiểm thử (Testing planning and testing requirements)

2.1. Xác định yêu cầu kiểm thử (Identify the testing requirements)

Một yêu cầu là một mục tiêu phải đáp ứng được. Nhân viên kiểm tử phải hiểu rõ các yêu cầu của trò chơi và chuyển chúng thành các chức năng tương ứng (kiểm thử những gì, phần nào có thể kiểm thử, phần nào không, mục tiêu và giải pháp như thế nào…), thiết kế và xây dựng dành cho các lập trình viên.

Nhân viên kiểm thử phải đọc tài liệu hệ thống, thu thập thông tin hình ảnh và văn bản. Phân tích làm thế nào có thể kiểm thử các thành phần của trò chơi.

Tài liệu yêu cầu kiểm thử đưa ra những gì sẽ được kiểm thử và làm thế nào để kiểm thử chúng, tài liệu bao gồm:

• Danh sách các chức năng
• Các chi tiết cụ thể của thiết kế trong (internal design) và thiết kế ngoài (external design) của game.
• Cấu trúc kiểm thử chi tiết và làm thế nào để một ca kiểm thử được chấp nhận.
• Tiêu chuẩn kiểm thử.
• Tiêu chuẩn hoàn thành (kết quả mong đợi là gì, khi nào thì một công việc được kết thúc và khi nào thì nó đang thực hiện “something is working”).

Sau khi hoàn thành tài liệu yêu cầu kiểm thử, Giám đốc kỹ thuật sẽ xem qua và xác nhận phạm vi cũng như độ ưu tiên. Theo như yêu cầu kiểm thử, các nhân viên kiểm thử sẽ đưa ra thiết kế của riêng mình, xây dựng kế hoạch test “Test plan” và Test case. Tài liệu kiểm thử được phát triển vào giai đoạn đầu của dự án, có thể không bao gồm tất cả các chi tiết của trờ chơi nhưng phải có các yêu cầu chính như trong hợp đồng.

2.2. Xác định yêu cầu về thời hạn (Define the timeline requirements)

Khi một dự án chịu sức ép về thời gian thì chúng ta cũng phải tính toán thời gian cần thiết cho quá trình kiểm thử một cách chính xác:

• Số lần lặp để kiểm tra mỗi chức năng của trò chơi
• Chu trình hoàn thành kiểm thử hồi quy

3. Các kĩ thuật kiểm thử (Testing techniques)

Phần này sẽ trình bày một cách tiếp cận kiểm thử có hệ thống và giải thích cách bạn phá vỡ một chức năng của trò chơi thành nhiều chức năng nhỏ có thể kiểm thử được.

3.1. Thành phần trò chơi và cấu trúc

Kiểm thử một trò chơi có nghĩa là kiểm tra tất cả các thành phần của nó. Bao gồm:

• Menu và các chức năng của Menu.
• Nghệ thuật (mô hình nhân vật, đối tượng, bản đồ…)
• Animation (tỷ lệ khung hình)
• Âm thanh và hiệu ứng âm thanh (kết hợp với animation, chuỗi các hành động…)
• Music
• Camera (phóng to, thu nhỏ, phát lại)
• Logic game
• world/level/scene
• thuộc tính nhân vật
• thuộc tính hành động
• Điều kiện để đi tới level tiếp theo
• Ghi điểm
• Độ khó của các level
• AI logic
• Thống kê (trước game và trong game như thống kê nhân vật, điểm cao)
• Tiêu đề màn hình
• SFX (hiệu ứng đặc biệt)
• Bất cứ movie clip nào
• Cách sử dụng các hành động kết hợp nhiều nút
• Độ dễ sử dụng của các nút chức năng
• Hiệu ứng rung của game
• Game options (start/ menu selection, hints, game pause, pause menu options, …)

3.2. Các “tip” khi kiểm thử game

• Kiểm tra toàn bộ màn hình, không chỉ kiểm tra một phần nhỏ của nó
• Nắm vững các quy luật của trò chơi và kiểm thử các trường hợp chống lại các quy luật này
• Thử nghiệm “cắt” (cho hai hoặc nhiều đối tượng chồng chéo lên nhau hoặc hủy bỏ lẫn nhau)
• Kiểm tra điều kiện va chạm chính xác hay không chính xác (khi hai đối tượng chạm vào nhau)
• Kiểm tra sự chuyển sang màu xám (khi một lựa chọn hay icon không thể được chọn)
• Kiểm tra việc loading/ saving từ các thiết bị (thẻ nhớ ngoài) và đảm bảo các thông báo chính xác được hiện lên màn hình.
• Đảm bảo thông tin dữ liệu đang được tải hiển thị lên màn hình
• Đảm bảo thời gian “loading” là chấp nhận được (không ai muốn chờ nhiều hơn 20 giây)
• Kiểm tra chế độ multiplayer mode.
• Kiểm tra rò rỉ bộ nhớ hay lượng tài nguyên bị chiếm dụng khi chơi game trong một vài ngày
• Kiểm tra khả năng tương thích với các nền tảng (HDH,…)
• Kiểm tra kết nối mạng thông qua các modem có tốc độ khác nhau

3.3. Các kỹ thuật kiểm thử

a. Cấu trúc file (File structure)

Mục tiêu cơ bản là tìm hiểu cấu trúc cơ bản hình thành kiến trúc của trò chơi, và hiểu được sự tương quan, phụ thuộc của các tập tin với game. Khi kiêm tra một modun của trò chơi,điều quan trọng nhất là phải hiểu được những thứ gì đang diễn ra, đang làm việc bên trong của trò chơi. Điều này giúp các Tester dễ dàng tìm ra được lỗi và đẩy nhanh quá trình phân tích.

b. Tạo file (Make file)

Một phần mềm được xây dựng thành các modun và thường xuyên được cập nhật và nâng cấp bởi nhiều người phát triển. Đôi khi có những sai sót giữa những người phát triển, từ đó tạo ra các lỗi đối với phần mềm vì sự thiếu thống nhất giữa các modun và các nhà phát triển.Mỗi lần sảy ra sai sót, một tập tin sẽ được tạo ra để ghi lại thông tin về lỗi. Khi kiểm tra lỗi, những thông tin lưu trong tập tin đó là rất có ích cho việc điều tra nguyên nhân gây ra lỗi phần mềm.Nếu số lượng lỗi là quá nhiều cho việc sửa chữa chúng ta lên thông báo với người phát triển hoặc những người có trách nhiệm với đoạn mã gây ra lỗi.

c. Quản lý bộ nhớ (Memory management)

Đó là biện pháp tốt dùng để quản lý bộ nhớ sau từngquá trình xây dựng và phát triển. Nếu như có sự thay đổi lớn giữa lần sau và lần trước, chúng ta cần phải đánh dấu nó. Đôi khi nó có thể là lỗi sai.Nếu như kích thước của file exe quá lớn thì nó sẽ gây ra khó khăn khi tải.

d. Debugger và kiểm tra mã (Debugger and code inspection)

Phân bổ thời gian của bạn sẽ phải dành ra một khoảng lớn thời gian dành để debug game hoặc giúp đỡ ai đó debug game. Một trong những kỹ năng chính trong việc kiểm thử game là khả năng debug của Tester, các chương trình như Visual C++, Linux Debugger có hỗ trợ mạnh trong việc debug như thế này.

Khi bạn kiểm tra một số mã Code inspection , các trình sửa lỗi sẽ giúp bạn rất nhiều trong việc cung cấp thông tin của các biến. Sử dụng các thông tin đó dùng để xác định các mã được sử dụng, các điểm và các mảng. Kiểm tra tài liệu hướng làm cho tài liệu dễ hiểu và chính xác hơn, đảm bảo rằng trong việc lập trình các tài liệu cần phải được hướng dẫn chính xác, khi đó thì mã code của những người code trước sẽ dễ dàng được những người tiếp tục phát triển hoặc những thành phần phát triển ở modun khác có thể tiếp tục sử dụng mã code của người trước.

Bạn có thể phải làm một số loại kiểm tra dữ liệu tùy thuộc vào loại game. Nếu trò chơi sử dụng một số loại chương trình thống kê ngẫu nhiên, chúng ta cần phải chắc chắn rằng dữ liệu được lưu trữ một cách đúng đắn và chỉ dành cho các thành phần của chương trình cần sử dụng tới dữ liệu đó.

e. Các chương trình kiểm thử (Test program)

Một điều quan trọng trong việc kiểm thử phần mềm là sử dụng các chương trình kiểm thử được viết để kiểm thử phần mềm, một vài ví dụ như những chương trình được viết cho phép cheat code, chạy những file nhạc, hoặc enable / disable AI, tạo kịch bản thử nghiệm.

Các Game Tester cũng có thể dùng các chương trình kiểm thử để có thể kiểm thử các kịch bản hoặc tình huống cụ thể.

f. Sound testing

Kiểm thử âm thanh chỉ đơn giản là lắng nghe những âm thang và đảm bảo rằng điểm khởi đầu và chiều dài củac chúng là thích hợp. Người kiểm thử phần mềm thường có nhu cầu viết một chương trình “kiểm thử âm thanh” để chơi tất cả các tập tin âm thanh riêng biệt trong trò chơi. (chỉ là một mẹo nhỏ, bạn nên kiểm thử với một phần mềm phát nhạc, và quan sát xem chúng có thật sự sẵn sàng không).

Kiểm thử âm thanh bao gồm việc kiểm tra nếu như có bất kì lỗi nào trong qua trình tải các file, lắng nghe các file âm thanh bị lỗi hoặc bị biến dạng. Ngoài ra, kiểm thử để chắc chắn rằng tất cả các file âm thanh được tải một cách chính xác. Nếu như trò chơi có Colour Commentary (hoặc CC), sử dụng hồ sơ cc để phân tích. Phân tích giúp bạn xác định bao nhiêu lần một CC được gọi, và nếu nó được chơi hoặc ghi đè.

Sự phân tích liên quan tới các cảnh và các tình huống của cc và kiểm tra nếu có bất kì thông tin nào được chơi, nếu bạn nhận thấy bất kỳ vấn đề nào trong cc, bạn nên kiểm tra các thông tin đã được qua và được chơi. Tất nhiên cách để phân tích cc là lắng nghe thực sự à lưu ý bất kì bất thường hoặc vấn đề nào xảy ra.

g. Cơ sở dữ liệu và thống kế trong game (Database and Game Statistics)

Mục đích chính của cơ sở dữ liệu cho một trò chơi là:

• Thống kê người chơi hoặc các đội game. Nó sẽ được sử dụng duy nhất cho màn hình hiển thị, hoặc nó có thể được sử dụng bởi trí thông minh nhân tạo để mô phỏng sự chơi game thực tế hoặc sự ngẫu nhiên.
• Thống kê thời gian chạy.Nó được sử dụng bởi các máy chơi game để nhớ một trạng thái nhất định, các thuộc tính hoặc điểm của người chơi khi họ chuyển từ cấp này sang cấp khác (hoặc sang một trạng thái khác).

Cách dễ nhất để kiểm tra cơ sở dữ liệu là đi vào trong trò chơi đó và sử dụng một trình gỡ rối (debugger), và phân tích trò chơi sử dụng các dữ liệu đúng. Có được một bản in của cơ sở dữ liệu và nhìn vào màn hình để đảm bảo rằng các dữ liệu đã được tải xuống, được đặt trong một vị trí đúng, và trình diễn thông tin chính xác. Một lưu ý đó là, người ta có thể kiểm tra việc cơ sở dữ liệu được export để đảm bảo không có lỗi phát sinh trong quá trình export. Một kĩ thuật tốt khác là kiểm tra ngẫu nhiên, trên dữ liệu thống kê của một người chơi, để đảm bảo rằng dữ liệu là chính xác.

h. Overlays

Hãy chắc chắn rằng các lớp phủ được lạp một cách chính xác. Một người kiểm thử sẽ viết một chương trình để kiểm tra xem các lớp phủ có đang được gọi một cách chính xác hay không, và xác định xem có bất cứ cái nào không được sử dụng hay không.

i. Phần mềm theo dõi lỗi (Bug tracking software)

Người kiểm thử phần mềm nên biết để sử dụng PVCS Tracker để theo dõi và bão cáo lỗi, và biết như thế nào để sử dụng các mẫu tiêu chuẩn để tạo/tùy chỉnh một lỗi mới của cơ sở dữ liệu cho một dự án mới. Nó sẽ tuyệt vời hơn nếu bạn có quyền quản trị để theo dõi sự sự thiết lập của những người khác với các tài khoản và quản trị cơ sở dữ liệu (một ID khách hàng đăng nhập mới, các trường và thông tin).

j. Nhân viên kiểm thử và tình yêu đối với game (Game test and love of the game)

Một người kiểm thử phần mềm cũng cần phải có “tình yêu đối với các trò chơi” trong thâm tâm. Một thời gian đáng kể của bạn sẽ được dành cho chơi game để tìm ra lỗi. Bạn phải có những kĩ năng để tìm và bào báo cáo các lỗi của trò chơi cũng như giúp sửa chữa chúng. Điều quan trọng là kiểm thử các yếu tố thú vị của game thật tốt, nếu bạn không cảm thấy vui vẻ trong khi chơi game sau đó hãy thảo luận với đồng nghiệp của bạn giống như một Game Tester. Nếu những sự thay đổi xảy ra quá muộn, chúng có thể sẽ không được thực hiện. Tuy nhiên, hãy nhớ rằng trình gỡ rối luôn là người bạn tốt nhất của bạn.

Đây chưa phải là tất cả các “tip” được sử dụng khi kiểm thử, bạn cần một chút sang tạo, tưởng tượng và “đơn giản” sẽ là rất hữu ích.

4. Kế hoạch và chiến lược kiểm thử (Test plan and strategy)

4.1. Kiểm thử đơn vị (Unit testing)

a. Mục tiêu

Mục tiêu của kiểm thử đơn vị là nhằm xác minh các module của chương trình hoạt động tốt. Kiểm thử đơn vị được thiết kế để kiểm tra một lóp độc lập, một thành phần hay module riêng rẽ. Các lập trình viên có thể sử dụng kiểm thử đơn vị, tuy nhiên chỉ được trên các thành phần mà họ đang làm việc.

b. Tiêu chuẩn tiến hành (Entry Criteria)

• Các test case được xem xét kỹ lưỡng
• Xây dựng là kiểm tra toàn diện và tự kiểm tra
• Môi trường kiểm thử đơn vị được thiết lập

c. Tiêu chuẩn hoàn thành (Exit Criteria)

• Tất cả các test case trong kế hoạch đều được thực hiện
• Các module làm việc đúng như kết quả mong đợi
• Các lỗi được cố định trong mã nguồn và khoanh vùng để theo dõi

d. Kiểm thử đăng nhập và báo cáo (Logging testing and report)

Lập trình viên sẽ sửa các lỗi được tìm thấy trong kiểm thử đơn vị. Ngoài ra nếu các lỗi tương úng với các module hay thành phần khác được tìm thấy trong quá trình kiểm thử đơn vị, chúng sẽ được báo cáo lại.

4.2. Kiểm thử hệ thống (System testing)

Trong kiểm thử hệ thống, các đơn vị riêng biệt (gói/ module/ thành phần), hoặc nhóm các đơn vị của ứng dụng sẽ được liên kết lại với nhau và kiểm thử như một ứng dụng thống nhất. Mục đích của “Kiểm thử hệ thống” là xác định các lỗi sẽ xảy ra khi một hệ thống hoàn chỉnh được cài đặt. Các nội dung cần xác minh có thể bao gồm: chức năng, tiện ích, bảo mật, cài đặt…

Các bước trong kiểm thử bao gồm:

• Tạo ra tất cả kịch bản và test case kiểm thử
• Chuẩn bị tài liệu kiểm thử: mô tả về các test case, các bước tiến hành và kết quả mong đợi
• Báo cáo các lỗi.

Dưới đây là các loại kiểm thử chính sẽ được thực hiện:

• Application Characteristics (AC): thông tin về ứng dụng được cung cấp để giúp nhóm kiểm thử trong khi làm việc.
• Stability (ST): kiểm tra sự ổn định của ứng dụng trên thiết bị
• Application Launch (AL): một khi ứng dụng được chạy nó phải khởi động và kết thúc một cách chính xác, điều này có liên quan tới thiết bị và các ứng dụng khác đã được cài đặt trước đó.
• User Interface (UI): kiểm tra giao diện ứng dụng có đúng như trong thiết kế không.
• Functionality (FN): Các chức năng được liệt kê trong tài liệu kiểm thử hoạt động đúng như mong đợi.
• Connectivity (CO): ứng dụng phải chứng minh được khả năng kết nói với mạng một cách đúng đắn, đối phó được với các sự cố mạng như: đứt mạng, delay… và các sự cố từ máy chủ.
• Personal Information Management (PI): ứng dụng truy cập thông tin người dung một cách thích hợp và không làm sai lệch thông tin.
• Security: kiểm tra cách tính năng bảo mật của chương trình.

4.3. Kiểm thử hồi quy (Regression Testing)

Đây là một bước bổ sung, được tiến hành sau khi hoàn thành “Kiểm thử hệ thống” để kiểm thử các chức năng mới. Kiểm thử hồi quy bao gồm một tập các tiêu chuẩn kiểm thử để đảm bảo các chức năng cũ sẽ không bị phá vỡ bởi các chức năng mới. Kiểm thử hồi quy cũng được tiến hành khi ứng dụng ra một phiên bản mới nào đó sau khi đã sửa một số lỗi ở phiên bản trước.

4.4. Báo cáo kiểm thử (Test Report)

Đối với mỗi báo cáo, cần phải có đầy đủ các thông tin sau:

• Tên của ứng dụng
• Số phiên bản (version number) của ứng dụng
• Thiết bị sử dụng để kiểm thử
• Version firmware của thiết bị

Đối với các báo cáo lỗi, cần có các thông tin sau:

• Mô tả lỗi
• Tần suất xảy ra lỗi: lỗi hệ thống, ngẫu nhiên hay chỉ xảy ra một lần.
• Vị trí của lỗi trong ứng dụng
• Các bước để tạo lại lỗi

5. Thực hành kiểm thử cho ứng dụng "SLIMO"

1. Install and Lauching

1.1. Install

Test Description: Ứng dụng phải được cài đặt thông qua Google Play

Require for: Màn hình khóa kiếm tiền Slimo.

Testing Note:

1. Nếu có lỗi trong quá trình cài đặt, tester phải ghi rõ trong báo cáo test.
2. Ứng dụng chỉ được phép cài đặt từ Google Play, do đó công việc test chỉ được bắt đầu khi ứng dụng đã được đưa lên Google Play.

Testing Steps:

1. Mở trình duyệt của thiết bị;
2. Nhập vào đường link tới trang cài đặt ứng dụng;
3. Kết nối tới đường link liên kết;
4. Chấp nhận quá trình cài đặt phần mềm.

RESULT:

1. Ứng dụng được cài đặt trên thiết bị.
2. Icon của ứng dụng được hiển thị trong Menu của thiêt bị.

Result of Test: PASS

1.2. LifeCycle – Long launch time

Test Description: Đảm bảo Ứng dụng phản hồi tới người dùng về thời gian khởi động chương trình.

Require for: Màn hình khóa kiếm tiền Slimo.

Testing Steps

1. Chạy ứng dụng từ Menu chương trình.
2. Quan sát thời gian.

RESULT: Nếu thời gian khởi động lớn hơn 5 giây, thì ứng dụng phải hiển thị một thanh “Progress bar” giúp người dùng biết được tiến trình load tài nguyên đang diễn ra.

Result of Test: PASS

1.3. Splash screen

Test Description: Ứng dụng hiển thị Splash Screen ngay sau khi khởi động.

Required for: Màn hình khóa kiếm tiền Slimo.

Testing Steps

1. Chạy ứng dụng từ Menu chương trình.
2. Quan sát màn hình Splash Screen.

**RESULT:**Ngay sau khi chạy ứng dụng được chạy màn hình sẽ hiển thị màn hình Splash Screen

Result of Test: PASS

2. Memory Usage

Test Description: Ứng dụng xử lý được trường hợp thiết bị thiếu bộ nhớ khi ghi dữ liệu vào files trên hệ thống.

Required for: Ứng dụng có ghi vào “file system”.

Not required for: Ứng dụng không ghi vào “file system”

Testing Steps

1. Khởi động ứng dụng và cho ứng dụng thực hiện quá trình ghi files vào hệ thống (ghi điểm và số tiền).
2. Thoát ứng dụng.
3. Khởi động lại ứng dụng, thực hiện đọc dữ liệu từ files đã được ghi ở S1.

RESULT:

1. Ứng dụng xử lý được trường hợp thiếu bộ nhớ (out of memory).
2. Đưa ra cảnh báo tới người dùng “lack of memory” khi cố gắng lưu trữ file.

Result of Test: PASS

3. Performance

3.1. Suspend/resume from main menu

Test Description: Đảm bảo ứng dụng có thể tạm dừng được tại Main Menu. Required for: All applications.

Testing Steps

1. Chạy ứng dụng.
2. Di chuyển đến màn hình Main Menu của ứng dụng.
3. Tạm dừng ứng dụng bằng cách nhấn nút Home trên thiết bị
4. Quay lại ứng dụng

RESULT: Ứng dụng tạm dừng và tiếp tục chính xác, không làm hỏng trải nghiệm người dùng.

Result of Test: PASS

3.2. LifeCycle – Suspend while executing

Test Description: Kiểm tra việc tạm dừng ứng dụng khi đang chạy ở bất kỳ màn hình nào. Required for: All applications.

Testing Steps

1. Chạy ứng dụng.
2. Khi đang ở bất kỳ màn hình nào, tiến hành tạm dừng ứng dụng (nút Home trên thiết bị)
3. Quay trở lại ứng dụng.

RESULT: Ứng dụng tạm dừng và tiếp tục chính xác, không làm hỏng trải nghiệm người dùng.

Result of Test: PASS

3.3. LifeCycle - Resume

Test Description: Đảm bảo ứng dụng có thể quay trở lại trạng thái làm việc chính xác.

Required for: All applications.

Testing Note: Mục đích của test case này nhằm xác thực sự ổn định của ứng dụng khi mà tạm dừng rồi quay trở lại nhiều lần.

Testing Steps

1. Thực hiện Lifecycle – Suspend / resume from main menu
2. Resume ứng dụng
3. Thực hiện Lifecycle – Suspend while executing
4. Repeat step 2.

RESULT: Ứng dụng quay trở lại trạng thái trước khi bị tạm dừng, hoặc tại trạng thái mà không ảnh hưởng tới trải nghiệm người dùng.

Result of Test: PASS