App test those pits that went through

I now have a large part of the work is also the app test, although they are the app development background, but in the test still fell into a lot of big pits, after all, they are still very different, the angle is not the same. In the development of the test, I think the more difficult is also an angle of conversion, to a developer's point of view to test, often ignore a lot of problems.

Before recording the pits that the app test went through, let's summarize what the app testing is all about.

1. Functional testing, no matter what the software product, is essential is functional testing. We need to test whether the app is fully functional, meets the customer's needs, and meets the user's normal experience. The most important aspect of functional testing is the design of the test case, which is summarized in a separate time. Case design is comprehensive, the high coverage determines the strength of this product function. As a development, it is necessary to take into account the various situations in the logic implementation in the development process, and to do different processing according to different situations, and this kind of consideration tends to be dominated by positive considerations, that is, what the user will do in the normal usage situation, and what kind of problems it can produce. As a test can not be considered solely from the positive process, the user in various situations of various operations to think and design the corresponding test cases, to ensure the perfect app function. So in the app testing process to do:

1) Requirements review--know what to test, the scope of the test

2) Case design--test case according to requirement document and product prototype design

3) Case review--for a tester to review the test cases to see if there are missing case scenarios, review the case is correct.

4) Case execution-tests are performed on test cases, covering test cases.

2.app Client Performance testing. The main parameters of this performance test are: How high the CPU, memory, power consumption, traffic, and the installation time and startup time of the app. In fact, in the actual work of this is not so comprehensive. Our normal testing process is concerned with the installation of the app is time-consuming and startup time-consuming (WiFi under the boot, 4G boot, 3G under the boot). There is a need to pay attention to the operators of the test, the previous problem is that there is no problem in the move, but there is a problem in the Unicom, this is also a concern, of course, this problem is sometimes not developers and testers can control. But like memory, traffic what is the need for special attention, in our work, we in the app Zip package more than 500k in the test environment is a special pop-up prompt box reminders, need to find development to confirm why this place would need to place such a large file.

3. Adaptation compatibility Test. Remember before in the group of people asked how to carry out the compatibility test Ah, and then all the same answer, buy buy buy, buy various models of mobile phones, haha. In the usual test work, our company because the test team is relatively large, so we will continue to update the mainstream models on the market, but it is not possible to achieve comprehensive. We are in the mainstream model on the test can be issued on-line, if encountered production problems, we are special to deal with. With the help of the real machine or to the Baidu Cloud test platform, with their services to reproduce the problem, solve the problem. But this problem is tricky to solve, such as iOS fortunately, the general focus on iOS system version and size can be, these problems can be appropriately adapted. But the Android device is too extensive, often dealing with some problems also need to contact the manufacturer, it is troublesome, so I think this kind of test does not need a special compatibility test, this does not mean much. If you really want to do it, you can find the relevant three-side platform to do.

4. Weak network testing. As mentioned above, the client performance test should be concerned with installation time and startup time, which requires weak network testing. But in our actual work does not carry on the special weak network test, the reason is this kind of test controllability is poor, is not stable, obtains the test result to have the very big reference significance. Therefore, in our actual work, usually have special needs to be tested, but the results obtained are not ideal. When I was developing the app, I had different treatments for different network conditions.

5. Power consumption test. This includes power consumption testing during app usage and power consumption testing for background run suspend settings. When the device is full, how long can the app play, how much power the app consumes per hour, how much the app consumes in a scene for 10 minutes, and so on.

6. Security testing. This should be said to be a very important test, I have not thoroughly studied the security test, this involves more places, security protocols, information encryption and so on.

These are the actual work of some of the tests encountered, I think this is also based on different products to produce different tests, and there is no standard for an app testing what needs to be tested, this depends on the actual requirements of cost control and so on to choose.

To talk about the holes in the app test ...

1.web, client, service side three of the enmity. Now the mainstream of the app is not pure native Client, but with the web, so in the test must be considered comprehensive, Web modification, client modification, service side of the changes, will have an impact on which areas must clarify the idea.

2. Use of the test environment. Test environment no problem does not represent the production environment is not a problem, the cause of the problem is manifold, so as far as possible in the test environment testing, do not let the problem appear in the production environment.

3. Communication with development, demand. This is more important, some of the features of the implementation may differ in some details and requirements design, in this case do not easily let go of the problem, easy back pot (blood and tears lessons). It is not possible to listen to the development opinion or the demand opinion unilaterally, to clarify whether the problem exists or not.

4. No impact test. In the actual work encountered a problem, the development of an interface modified, the tester has only tested a logic in the interface of the call, and did not find out what the development of the interface involved in the business logic, which will lead to the emergence of defects elsewhere, this must be noted, testing to a bug, Do not blindly look at the completion of the modification of the business can be normal use, it is important to understand what he has changed, according to the modified things to design test cases and then execute.

Will encounter a lot of pits in the future ..... I'll add it to you.

App test those pits that went through