Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "what are the Android APP testing procedures and common problems". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. Automated testing

Automated testing mainly includes several parts, UI function automated testing, interface automated testing, other special automated testing.

1.1UI function Automation Test

The automated testing of UI function, which is often called automated testing, is mainly based on the UI interface, through the script to achieve the click of UI function, instead of manual automated testing.

The advantage of this test lies in the effective release of the testing manpower of the highly repetitive interface feature functional testing, using the execution of the script to achieve a fast and efficient regression of the function.

However, the shortcomings of this kind of testing are also obvious, including high maintenance cost, prone to misjudgment, lack of compatibility and so on. Because it is based on the interface operation, the stability of the interface has become the biggest constraint to the maintenance script. The frequently changing interface interaction means that the test case scripts need to be constantly updated, which takes up a lot of test resources.

=

Misjudgment is easy to occur mainly because the identification based on UI controls is easy to load slowly or abnormally due to network conditions, device configuration, test environment and other reasons, which leads to inaccurate judgment in the process of test case execution, and then affects the accuracy of the test. The lack of compatibility mainly means that the execution of test scripts in different devices, different operating systems, different hardware environments will bring unexpected situations, resulting in inaccurate results of test case execution.

Based on the comparison of the above advantages and disadvantages, in the UI functional automation testing, we mainly realize the testing of the APP core path, and carry out the UI functional automation testing for the functional modules that need a large number of repeated execution, repeated verification and low frequency of UI interface changes.

The need for a large number of repeated execution and verification means that the utilization rate after automation is high, and the frequency of UI interface changes is low, which means that the subsequent maintenance cost is not high. These three types of use cases are relatively high input-output parts for us, and we will give the highest priority to the practice of UI functional automation testing.

In the process of automated testing of UI functions, we can effectively sort out and manage the relevant controls, test cases and test sets, merge the repeatable work in time, and reduce the waste of resources. When the UI function changes, it can also be maintained at a lower cost to reduce the maintenance cost.

1.2 Interface Automation Test

In the section on UI functional automation testing, we mentioned the constraint to automation: stability. Because of the instability of UI interface, the cost of automating UI functions is relatively high, so we naturally think of the part that is more stable and more conducive to automation than UI functions, that is, interfaces.

An APP, the interface may change because of the different demands of the product manager at different stages, but the interface behind it is usually relatively stable, which provides a favorable guarantee for us to carry out automated testing.

We need to prepare the interfaces called by APP, summarize them according to functional modules, sort out the priority of automation, understand the meaning of each interface, the value range of different parameters, take an inventory of various outputs produced by different inputs, and summarize the return of errors or exceptions, so as to ensure the effectiveness and integrity of interface testing.

After the interface automation test starts, it is necessary to maintain an interface document with the development engineer. Later, no matter whether the interface is increased or decreased, or the existing interface has been changed, the test engineer can know as soon as possible, and adjust the use case of the interface automation test accordingly.

1.3 other special automated tests

In addition to the above two types of automation, we can also use automation to do some special tests to help improve our test quality and efficiency. Here, we need to think diligently in our daily testing work, thinking about which work can be realized through automation, which testing can improve testing efficiency with automation, and which functional points can achieve long-term test monitoring through automation.

For example, I am responsible for a project, there is a function, manual testing, we can only do a limited number of click verification, and click frequency is low, but through the script we achieve faster, longer click operation in the testing process, then we can use automation to achieve. It can be executed not only on its own testing equipment, but also on different devices. This automated test is effective, that is, it can improve the testing efficiency and quality. Although this test will not be added to the use case set of UI functional automation for a variety of reasons, automation does give us useful help in the current release, which is what we need to advocate.

In short, we can use a variety of automated testing tools and testing tools to assist us in testing, which is worthy of recognition.

two。 Performance testing

In the testing system of the project I am responsible for, performance testing mainly includes three dimensions of performance testing, namely, time dimension performance testing, resource dimension performance testing and fluency testing.

2.1 time dimension

The performance test of the time dimension mainly refers to the time response of the functional features after the click operation. We are more familiar with the loading time of the first screen, the response jump opening time after clicking, and so on.

There are many ways to test the performance of time dimension. you can calculate time by screenshot, timestamp in the program, and third-party scripts to calculate time. time can also be calculated through image recognition technology.

In the testing process, we need to pre-study the tools combined with the project itself, whether it is an one-time test, or whether it needs to be continuously tested, whether it needs to be converted into a tool for subsequent long-term use, whether it is used on a single device, or whether it needs to be used in different device environments, whether the tool is open source or provides a data interface to be combined with the team's test platform, and so on.

2.2 Resource Dimension

The performance test of resource dimension mainly refers to the consumption of various system resources during the use of APP, including CPU, memory, electricity, traffic and so on.

The choice of testing tools, according to the different test terminals to choose, the test needs to monitor the dimensions, but also according to the project to determine, here do not carry out the specific testing methods.

What needs to be said here is that the performance testing of the resource dimension can be done in two parts, one is the performance testing in the testing process, and the other is the collection of online performance data.

The performance test in the testing process can be evaluated according to the needs of the business test, which scenarios need to be tested, whether it is a test of the current version, or a test to be compared with each subsequent version, whether you only need to test the performance data of the local machine, or whether you need to collect performance data on multiple devices. You only need this APP test, or you need to do a comparison test with the competitor.

On this basis, evaluate whether it is necessary to implement test cases through automated scripts for subsequent reuse. If the subsequent comparative testing of vertical and historical versions is needed, it is necessary to ensure that the test environment and test equipment are as consistent as possible, so as to make the test results more authentic and reliable.

In addition, a small point is added, the processing and calculation of test data can be realized through automated scripts to save the resource cost of human calculation. If necessary, you can also make a simple platform to store the test data on the platform for subsequent analysis.

The collection of online performance data requires the development engineer to report the relevant data in the process of function implementation. After the function is released, the online data are fished, processed and calculated, and the possible problems are found. In the development engineer log to get the log of error users, to achieve the positioning, analysis and resolution of related performance problems.

2.3 fluency test

As the most intuitive experience of the user experience, fluency testing is also a must for many performance tests. There is no need to dwell on the method of doing the fluency test here, but there are a few points to note:

The first is how to plan the use case of the fluency test, the second is how to use the test result data to analyze and improve after the fluency test, and the third is how we need to monitor the fluency from the online data after the release of APP.

The design of fluency test cases needs to be combined with the core functions of APP and the paths commonly used by users. This part is best supported by wired data rather than clapping your head. The jump path of most users in APP obtained under the data support is what we need to focus on. In addition, the paths that are prone to stutter monitored in online data also need to be paid attention to during the testing process.

The analysis and use of the data after the smoothness test, as well as the monitoring of the online fluency data, it is necessary for the test engineer and the development engineer to plan and investigate together. This article will not discuss it.

3. Stability test

With regard to this part, we can start with the testing phase before the release of APP and the online operation phase after release, and carry out the work respectively.

In the testing phase, we can carry out stability testing around Monkey testing and code walk-through, and conditional teams can also use static code scanning tools at this stage. In the process of Monkey testing, we should pay attention to the equipment, environment and frequency of test execution, analyze the problems found in the process, and pay attention to the parts that are prone to problems. Code inspection, can be combined with functional testing process prone to collapse of the module to focus on inspection, to promote the development of pair programming, check the possible problems of these modules. As for static code scanning, it is necessary for developers to solve the problems scanned and develop good code habits to avoid leakage of related problems.

In the operation phase, we can carry out stability testing around the reporting and analysis of external network crash data. This part is more dependent on the development engineer, but in the process, the test engineer can analyze the reported data and locate some basic data of the crash, such as common systems, models, etc., in order to improve and optimize daily stability tests.

That's all for the content of "what are the Android APP testing procedures and FAQs". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.