What are the differences between testing an app, and traditional software testing? What aspects of test cases should be added?

With the increasing influence of cell phones in people's lives, app testing is becoming more and more known. From the beginning of crowdsourcing to the current automation of the exploration, mobile testing on the technology development is also rapidly changing.

App testing is much more complex and difficult than the traditional soft armor testing related in the past.

Based on work experience, I will be how to do a good job of app testing boiled down to the following.

(1) ? Non-functional testing

An important aspect of app testing is the non-functional requirements of the app. Before a mobile app is launched in the market or undergoes further development, testers have certain responsibilities to do the tracking of such requirements.

The first test to be done in the early development phase should be the utility test. This is usually done by alpha users or coworkers. Walk into a cafe or restaurant and ask the people inside how they use their app. Show them the first version at this stage of development and gather feedback on how well users use the new features to get a first impression.

(2) ? Functional Testing

Every new feature developed needs to be tested. functional testing is an important aspect of app testing. Testers should have to perform manual testing and later maintenance of automated testing. At the beginning, the tester has to manually test the app as a "black box" to see if the provided functionality is correct and works as designed. In addition to classic software testing, such as clicking a button, submitting an order, and seeing what happens, testers must also perform more functional app testing.

In addition to the entire manual testing process, test automation is also important for mobile apps. Every code change or new feature can affect existing features and their state. Usually there is not enough time for manual regression testing, so testers have to find a tool to perform automated regression testing. There are many automated testing tools on the market, both commercial and open source, for different platforms such as Android, iPhone, Windows Phone 7, BlackBerry, and mobile web apps, and depending on the development strategy and structure, QA testers need to find out which automation tool is best suited for their environment.

(3) ? Client-side performance testing

How well an app does is not only reflected in the functionality. The performance of the tested app on low-end and mid-range machines is also important. For example, a very fun game or app that only runs smoothly on high-end machines and gets stuck on low-end and mid-range machines won't achieve a good reputation.

The performance test of the app, we are more concerned about the parameters: CPU, memory, power consumption, traffic, FPS, but also need to pay attention to the installation time and startup time of the app.

At present, we may be more confused about a problem, how high the CPU, memory, power consumption, traffic, FPS is considered to meet the published value? Here we can tell you, you can refer to some of the values of the boutique games, and compare the data of the app you developed with the boutique apps in the industry.

(4) ? Adaptation compatibility test

App after the function test, also need to be adapted to its compatibility test need to check the items are mainly the following:

(a) in the different flat-branded models on the installation, pull up, click and uninstallation is normal;

(b) in different operating systems installation, pull up, click and uninstallation is normal;

(b) in the different operating systems on the installation, pull up, click and uninstallation is normal;

We often encountered the following problems in the actual test:

(a) on a certain system of a flat brand, the app can not be installed;

(b) on a certain system of a flat brand, the app can not be pulled up;

(c) on a certain system of a flat brand, the app is unresponsive after pulling up, or pulling up the black screen or splash screen;

(5) ? Weak network testing

Apps will inevitably encounter weak network environments during use, such as on the bus or in the subway. In such cases, network jitter, uplink or downlink timeouts often occur, resulting in packet loss in the app.

As a tester, we have to do certain scenarios of weak network environment modeling for apps before they go live and see if there are certain unknown issues with apps in weak network environments. Here are the weak network environment scenarios we commonly use:

(a) 3G weak network signal scenario simulation;

(b) downtown low-speed mobile scenario simulation;

(c) suburban high-speed mobile scenario simulation;

(d) request-response timeout_uplink timeout scenario simulation;

(e) request-response timeout_downlink timeout scenario simulation;

(f) network jitter scenario simulation;

(6) ? Power Consumption Test

The performance of the app on the phone, in addition to the function, whether the app consumes power is also one of the key items to pay attention to in the testing process. How long can the app play when the cell phone device is fully charged; how much power does the app consume per hour; how much power does the app consume when it hangs out for 10 minutes in a certain scenario; these are the points we usually pay more attention to in the power consumption test.

(7) ? Protocol test

Simulate the client to send protocol packets directly to the server to see if the server has a certain checksum, recognize the data sent by the client. The protocol test is mainly to deal with users sending malicious protocols to the server and fooling the server's checksum.

(8) Security Testing

Apps need to do detailed security testing before they go live. Security testing is mainly to detect whether the app is easy to crack by the outside world; whether there is a risk of being injected by malicious code; whether the risk of plug-ins is high or low after the launch.

(9) Server performance testing

Server performance testing, mainly including standalone capacity testing and 24-hour stability testing. The stand-alone capacity test can detect how many users a single server can carry under the premise that 90% of the response time and success rate are up to standard. Using a specific game model pressure test for 24 hours, the service has no restart, no memory leaks, and the success rate of each transaction meets the standard.

This can be booked on the WeTest portal.

(10) Server disaster recovery test

Server disaster recovery test mainly refers to whether a service process has the ability to recover itself after it crashes. For example, after the game logic process disappears, whether it will automatically pull up; memcached crash, whether it will restart, whether it will have an impact on all players. These are all factors that need to be considered during app testing.

(11) Interruption testing

The testing methods proposed for the way of classifying the level of service and real-time characteristics of intelligent terminal applications, such as: testing the interaction of the app with the incoming calls, file downloads, music listening and other key applications when it is in the foreground and background running state. Test the response of the app when a call, SMS, MMS, microblogging or other notification comes in.

(12) Public opinion tracking after launch

After the new app is launched, the user's evaluation of the app, the existence of bugs that were not detected during the testing period, the popularity of the app's posts on forums, and the reputation of the app on the app store are all points that testers need to pay attention to after the app is launched. points. If you need to test the bugs that were not found during the testing period, you need to confirm them in the new test service and fix them accordingly.