Notes on App Functional Testing

　　I haven’t written a blog to record my learning experience for several months. This time I went back to my hometown late at night to write an article to record my interview experience during this time. During the interview process, many interviewers asked about the APP test. Know and work experience to talk about your own understanding of APP testing:

1. Push message push test

1. Check whether the push message is sent according to the specified business rule.
2. When checking not to receive push messages, the user will no longer receive push messages.
3. If the user has set a do-not-disturb time period, check that the user cannot receive push messages during the do-not-disturb time period; the user can receive push messages normally during the non-do-not-disturb time period.
4. When the push message is for the logged-in user, it is necessary to check whether the received push message matches the user's identity, and push other people's messages without error. Generally, only the last logged-in user on the mobile phone is pushed to the message.
5. When testing push messages, you need to use a real machine for testing.

 

2. APP version update:

1. When the client has a new version, there is an update prompt.
2. When the version is a non-mandatory upgrade, the user can cancel the update, and the old version can be used normally. When the user starts the app next time, the update prompt still appears.
3. When the version is a forced upgrade, when the user does not update after the forced update is given, the client exits the client, and the forced upgrade prompt will still appear when the APP is launched next time.
4. When the client has a new version, directly update to check whether the update can be performed normally without deleting the client locally.
5. When the client has a new version, whether the updated client function is a new version function without deleting the client locally.
6. When the client has a new version, without deleting the client locally, check whether the resource file with the same name, such as a picture, can be normally updated to the latest version. If the above cannot be updated successfully, it is also a defect.

 

3. Switching between the front and back of the application

1. Switch the APP to the background, and then return to the APP to check whether it stays on the last operation interface.
2. Switch the APP to the background, and then return to the APP to check whether the function and application status are normal.
3. When the APP switches to the background and then returns to the foreground of the APP, pay attention to whether the program crashes and whether the functional status is normal, especially when the data is automatically updated when switching from the background to the foreground.
4. After the mobile phone is locked and unlocked, enter the APP and pay attention to whether it will crash and whether the functional status is normal, especially when the data is automatically updated from the background to the foreground.
5. When a call is interrupted during the use of the APP, and then switch to the APP, whether the functional status is normal.
6. When the APP process is killed and the APP is restarted, can the APP start normally?
7. After the prompt box that must be processed appears, switch to the background, switch back, and check whether the prompt box still exists. Sometimes there is a defect that the application automatically skips the prompt box.
8. For pages with data exchange, each page must be tested for front-to-background switching and screen lock. This kind of page is most likely to crash.

 

4. Offline browsing

　　Many applications will support offline browsing, that is, a part of the data will be cached on the local client for users to view.

1. Local data can be browsed in the case of wireless network.
2. When you exit the APP and then open the APP, you can browse the local data normally.
3. Switching to the background and then back to the foreground can browse the local data normally.
4. After locking the screen and then unlocking it and returning to the foreground of the application, you can browse the local data normally.
5. When there is an update to the server-side data, a corresponding offline prompt will be given.

 

5. No login

　　Many applications provide a login-free function, which automatically uses the APP as the user who logged in the last time when the application is opened.

1. Consider whether you can enter the login-free state normally when there is no network.
2. After switching user login, verify whether the user login information and data content are updated accordingly to ensure that the original user logs out.
3. According to the existing principles of Mtop, an account is only allowed to log in to one machine. Therefore, it is necessary to check the situation that one account is logged into multiple mobile phones. The user in the original phone needs to be logged out and a friendly prompt is given.
4. The APP switches to the background, and then switches back to the foreground for verification.
5. Switch to the background, and then switch back to the foreground test.
6. After the password is changed, check whether there is a valid identity verification when there is data exchange.
7. When an application that supports automatic login is performing data verification, check whether the system can automatically log in successfully and the data operation is correct.
8. Check that after the user actively logs out, the next time the app is launched, it should stay on the login page.

 

6. Run the test

1. After the APP installation is completed, the trial operation can be opened normally.
2. The APP is opened to test, whether there is a progress prompt of the loading status.
3. Whether the switching of the APP page is smooth and the logic is normal.
4. Log in:

   　　　1). Use a legitimate user to log in to the system;  

   　　　2). Whether the system allows multiple illegal logins, and whether there is a limit on the number of times;  

   　　　3). Whether the login system using the logged-in account is handled correctly;  

   　　　4). Can you log in when the username and password are wrong or omitted;  

   　　　5). For the deleted or modified user, log in with the original user name;  

   　　　6). Do not enter the user password or repeatedly click the "OK/Cancel" button, whether to allow the login;  

   　　　7). After logging in, whether the login information on the page is correct;  

   　　　8). Whether there is a logout button in the page;  

   　　　9). Check the handling of login timeout.

5. register:

　　　　　　 1). Form edit page test;

　　　　　　 2). Length of username and password;

　　　　　　 3). The prompt page after registration;

　　　　　　 4). Whether the data on the front-end registration page and the back-end management page are consistent

　　　　　　 5). After registration, whether the page prompts in the background management system and the user information in the database are normal;

 

7. Positioning, camera services

1. When the APP is useful for cameras and positioning services, you need to pay attention to the differences in system versions.
2. Where the camera service is useful, it is necessary to perform a switching test between the front and the background to check whether the application is normal.
3. When testing the camera service, you need to use a real device for testing.

 

　　The above are some test points I can think of for APP functional testing, and I will add them later when I think of them.