How to measure the app project? How to build a test system

APP Project test system from 0 To 1 The main considerations for the construction of the project are as follows ：

① automated testing 、② Performance testing 、③ Stability test

One 、 automated testing

Automated testing mainly includes several parts ,UI Automated testing of functions 、 Automated testing of interfaces 、 Other special automated tests .

1.1UI Function automation test

UI Automated testing of functions , That is what we often call automated testing , Mainly based on UI Automated testing of the interface , By scripting UI Function click , Replace manual automated testing .

The advantage of this test is to effectively release the testing manpower of highly repeated interface feature function test , Using the execution of scripts , Realize the rapid and efficient regression of functions .

But the shortcomings of this test are also obvious , Mainly including high maintenance cost , Prone to misjudgment , Insufficient compatibility, etc . Because it is based on interface operation , The stability of the interface has become the biggest constraint of the maintenance script . Frequently changing interface interaction , This means that the test case script needs to be constantly updated , Take up a lot of test resources . Miscarriage of justice is mainly due to UI Control , It's easy because of network conditions 、 Device configuration 、 Slow or abnormal loading due to test environment and other reasons , This leads to inaccurate judgment during the execution of test cases , Then affect the accuracy of the test . The lack of compatibility mainly refers to the test scripts on different devices 、 Different operating systems 、 Execution in different hardware environments will lead to unpredictable situations , Lead to inaccurate test case execution results .

Based on the above comparison , We are UI Functional automation testing , The main achievement is APP Core path testing , It requires a lot of repetition 、 Repeat validation 、UI The function modules with low interface change frequency are tested UI Implementation of functional automation test . A lot of repetition is required 、 Repeat validation , It means high utilization after Automation ,UI The interface change frequency is low , It means that the subsequent maintenance cost is not high , These three types of use cases are high input-output parts for us , We will do it with the highest priority UI Practice of functional automation testing .

Doing it UI In the process of functional automation testing , It can be used for related controls 、 The test case 、 Effectively sort out and manage test sets , Timely merge repeatable work , Reduce the waste of resources . When UI When the function changes , It can also be maintained at a lower cost , Reduce maintenance costs .

1.2 Interface automation testing

stay UI Part of functional automation testing , We mentioned the constraints of Automation ： stability . It is because UI Interface instability , So do UI The cost of functional automation is relatively high , Then it's natural for us to think about UI More stable 、 More conducive to automation , That's the interface .

One APP, The interface may change because of the different demands of the product manager at different stages , But the interface behind it is usually more stable , This provides a favorable guarantee for us to carry out automated testing .

We need to prepare APP The called interface , It is sorted and summarized according to the functional modules , Prioritize automation , Understand the meaning of each interface , Value range of different parameters , Count the situation where different inputs produce various outputs , Summarize the return of errors or exceptions , So as to ensure the effectiveness and integrity of interface test .

After the interface automation test is started , You need to maintain an interface document with the Development Engineer , In the future, whether the interface is increased or decreased , Or there are relevant changes to the existing interface , Test engineers can know for the first time , And make corresponding adjustments to the use cases of interface automation test .

1.3 Other special automated tests

In addition to the above two categories of Automation , We can also use automation to do some special tests , To help improve our test quality and test efficiency . here , We need to think hard in our daily testing work , Think about what can be done through automation , Which test automation can improve test efficiency , Which function points can realize long-term test monitoring through automation .

Two 、 Performance testing

Performance testing mainly includes three dimensions of performance testing , That is, the performance test of time dimension 、 Performance test and fluency test of resource dimension .

2.1 Time dimension

Performance test of time dimension , It mainly refers to the time response of functional features after clicking . We are familiar with the first screen loading time , Click to respond to jump opening time, etc .

There are many ways to test the performance of time dimension , You can use the screen capture to calculate the time , You can also use the time stamp in the program to calculate the time , Third party scripts can also be used to calculate time , The time can also be calculated by image recognition technology .

During the test , We should conduct pre research on tools in combination with the project itself , It's a one-time test , Or do you need continuous testing later , Whether it needs to be converted into tools for subsequent long-term use , It is used on a single device , You still need to consider compatibility and use it in different device environments , Whether the tool is open source or provides data interface for subsequent integration with the team's test platform , And so on. .

2.2 Resource dimension

Performance test of resource dimension , Mainly refers to APP Consumption of various system resources during use , Include CPU、 Memory 、 Electric quantity 、 Flow, etc .

Selection of test tools , Choose by yourself according to different test terminals , Test the dimensions that need to be monitored , It is also determined according to the project , The specific test methods are not expanded here .

What needs to be said here is , Performance test of resource dimension , Can do two parts of work , One part is the performance test in the test process , The other part is the collection of online performance data .

Performance testing during testing , It can be evaluated according to the needs of business testing , What scenarios need to be tested , This is a test of the current version , Or each subsequent version should be tested for comparison , Yes, you only need to test the performance data of the machine , You still need to collect performance data on multiple devices , Just need Ben APP test , We still need to do comparative tests with competitive products, etc .

On this basis , Evaluate whether test cases need to be implemented through automated scripts , For subsequent reuse . If it is necessary to conduct longitudinal and historical version comparison test later , You need to ensure that the test environment 、 The test equipment shall be as consistent as possible , So that the test results are more real and reliable .

Add another small point , Processing and calculation of test data , This can be achieved through automated scripts , Save the resource cost calculated by manpower . If necessary , You can also make a simple platform , Store all test data on the platform , For subsequent analysis .

Online performance data collection , The development engineer is required to report the relevant data in the process of function realization , After the function is released , Retrieve online data 、 Processing and calculation , Find out the possible problems . With the cooperation of the development engineer's log and the log of the wrong user , Realize the positioning of related performance problems 、 Analyze and solve .

2.3 Fluency test

Fluency test is the most intuitive feeling of user experience , It is also a must for many performance tests . There is no need to repeat the method of fluency test here , But there are a few points to note ：

One is how we plan the use cases for fluency testing , The second is how to use the test result data to analyze and improve after the fluency test , The third is APP After the release, we need how to monitor the fluency from the online data .

On the design of fluency test cases , Need to combine APP Core functions 、 Users often use paths to design , This part should be supported by wired data , Instead of patting your head to think . Most users obtained under the support of data are in APP Jump path in , That's what we need to focus on . in addition , The path that is easy to get stuck in the online data , We also need to pay attention during the testing process .

Analysis and use of data after convective patency test , And the monitoring of online fluency data , This requires test engineers and development engineers to jointly plan 、 Joint investigation .

3、 ... and 、 Stability test

This part , It can be downloaded from APP The pre release testing phase and the post release online operation phase of , Work separately .

Testing phase , We can focus on Monkey test 、 Code walk through two aspects of stability testing , Conditional teams can also use static code scanning tools at this stage .Monkey During the test , Pay attention to the equipment for test execution 、 Environmental Science 、 frequency , The problems found in the process should also be analyzed , Focus on the parts that are prone to problems . Code walkthrough , Key walk through can be carried out in combination with modules prone to crash during function test , Promote development and pair programming , Check for possible problems with these modules . As for static code scanning , We need to develop students to solve the scanned problems , Develop good code habits , To avoid leakage of relevant problems .

Operation stage , We can conduct stability tests around the reporting and analysis of external network crash data . This part relies more on development engineers to solve , But in the process , The test engineer can analyze the reported data , Locate some basic data of the crash , For example, common systems 、 Models, etc , In order to improve and optimize the daily stability test .