What is the cause of the crash in the App and the design of the test case?

Application crash is a very common bug. Many times, when we are using an APP, the app will suddenly stop responding, and the "Forced Closing Error" window will pop up in the interface, so it is necessary to forcibly close the app.

What are the reasons for App crash?

Several factors related to App crash: memory management errors, program logic errors, device compatibility, network factors, etc. , as follows:

1. Memory management error: It may be that the available memory is too low, the memory required by the app exceeds the limit of the device, and the app cannot run, resulting in the crash of the app.

Or memory leaks, the longer the program runs, the more memory it takes up, and eventually it runs out of memory, leading to the collapse of the whole system.

Or using unauthorized memory locations may also cause the application to crash.

2. Program logic error: array out of bounds, stack overflow, concurrent operation, logic error.

For example, the application adds a new untested function and calls a released pointer, which will crash at run time.

3. Device compatibility: Due to the diversity of devices, the performance of app on different devices may be different.

4. Network factors: It may be that the network speed is not good enough to reach the fast response time required by the app, which leads to the crash of the app. Or switching between different networks may also affect the stability of the app.

Application crash test case design

1. Verify the application behavior on multiple devices with different screen resolutions, operating systems and operators.

2. Use the newly released operating system version to verify the behavior of the application.

3. Verify the App behavior in the environment where the network quality suddenly changes (such as tunnels and elevators).

4. Change from cellular to Wi-Fi through manual network, and vice versa, and verify the behavior of the App.

5. Verify the application behavior in an environment without network.

6. Verify the application behavior of incoming calls/short messages and device-specific alarms (such as alarms and notifications).

7. Verify the behavior of the application in different view modes by changing the orientation of the device.

8. Verify the behavior of the application when the device is out of memory.

9. Verify the behavior of the application by applying a load using a test tool.