To know more about mobile application automated testing
The most time-consuming and labor-intensive aspect of developing mobile application automation testing is to manually test each function point of the APP or fix bugs. Someone will suggest that the business logic of App can be assisted by nUnit or xUnit test unit. How to test the user interface? As we all know, there are many kinds of mobile devices, the number is extremely large, and the types of devices are also various. How can we ensure that the App user interface can be displayed normally on thousands of iOS and Android devices without errors? This is the most troublesome thing for many APP developers.
With the in-depth development of the mobile Internet, the demand for mobile APPs continues to increase, and more and more digital enterprises begin to focus on the construction of their APPs. In today's increasingly intensified market competition, the methodology that the Internet is fast and unbreakable also affects the decision-making of current enterprises. Enterprises have implemented a rapid iterative model of mobile products: such as the 2-1-1 model proposed by Ali, the weekly release rhythm of Meituan, etc. This has also brought pressure on the R&D team to efficiently test the mobile terminal. Major companies They have started the exploration and practice of mobile automation testing.
Compared with API automation testing and Web automation testing, the implementation cost of mobile application automation testing is relatively high. Google's Android system and Apple's iOS system have a more closed ecology: for example, they can only rely on the tool chain provided by Apple. At the same time, because open source tools and frameworks are not stable and rich enough, automated testing on mobile terminals faces many new challenges: different models, system versions, resolutions, network jitter, etc., will affect the results of automated testing execution. To do a good job in automated testing on the mobile side, the team needs to develop testing strategies and methods that match their projects.
01 - Automated test strategy design for mobile terminals
When designing an automated testing strategy for mobile terminals, we can think about the following questions to see if we can give reasonable reasons:
Why do automated testing on mobile terminals, and where is the value of automated testing?
What is the quality built-in maturity in your project?
If the unit test has sufficient coverage, is it necessary to do end-to-end automated testing?
Is there already a special test system for mobile terminals, such as performance, security, compatibility, stability, etc.?
Does your team already have a solid infrastructure, such as Mobile CI/CD?
If even packaging, building, and distribution are not automatic and continuous, solve this problem first, and then consider automated testing. If you want to get rich, build roads first.
Use Case Stability Design
The stability and maintainability of automated test cases are very important. It is related to the effectiveness of automation. The following points need to be paid attention to:
1. Use a stable testing framework and tools
Many people like to build wheels. Without evaluating and analyzing the advantages and disadvantages of open source frameworks, they start to implement a simple version of the framework and tools by themselves, which is not recommended here.
A stable test framework is the basis of mobile application automation testing. In large-scale automated testing projects, stability is more important than flexibility. We can carry out secondary development first when the open source framework does not meet the requirements, and don't rush to write one from scratch.
2. Failure retry mechanism, intelligent waiting strategy, intelligent judgment, etc.
During the execution of automated tests, various unexpected exceptions may be encountered, such as network fluctuations, memory overflows that cause the APP process to be forcibly killed by the system, etc. Therefore, fault-tolerant processing must be considered to avoid use case execution due to environmental problems fail.
3. Good test case design method
A good use case design method can make our use cases more maintainable and readable. We can adopt the following design methods commonly used in the industry:
Page Object Model
BDD
Data Driven / Keywords Driven
02 - Mobile automated testing framework
A good test framework needs to have the following nine characteristics:
Stability (the framework must have many real use cases, and have a stable version, and continuous maintenance by the community)
Scalability (users can easily carry out secondary development)
Clear architecture (the design of the framework must be clear and modular)
Ease of use (allowing test developers to spend more energy on writing use cases instead of spending time getting familiar with the framework)
Cross-platform support (windows, linux, macos)
Integratability (can be integrated with different CI platforms, such as Jenkins, GoCD, Bamboo, etc.)
Reports (with easy-to-read test reports)
Log (with friendly logs and error prompts)
Technology stack support (can support multiple language technology stack tools
There are many open source testing frameworks in the industry, most of which have the above characteristics, such as Robot Frameowork and Cucumber in the open source community, Katalon that provides commercial support, and Ali’s Macaca and Netease’s Airtest, etc., just study one of them in depth. Details can be See the official websites of these projects.
03 - Mobile Testing Tools
If a worker wants to do a good job, he must first sharpen his tools
Choose a mobile testing tool. At present, the industry uses more automated testing tools for mobile terminals such as Appium, which can support automated testing of Android and iOS simulators and real devices at the same time. The figure below is a technical schematic diagram of Appium. Appium adopts B/S architecture design, and the whole is divided into two parts: server and client. Appium server is implemented with nodejs, a WEB server that provides REST API service, and is mainly used to manage test execution and result feedback. The Appium client provides tripartite library support in multiple languages, making it easy for developers to use their familiar languages to call the Appium client tripartite library to interact with the Appium server.