SoloPi status quo
In July last year, Ant Group officially opened source the client automation testing tool SoloPi, which mainly consists of three modules: recording and playback (for functional testing), performance tool (for performance testing) and one computer with multiple controls (for compatibility testing). Since open source, we have also received the company inside and outside the different sounds of tools, some classmates for this tool can improve the efficiency of testing students expressed support, also have students think out of the code automation test could limit the flexibility of the classmate, let this model is very difficult to go far, and classmates think it is just a flash in the pan, Simple packaging of tools on the PC without any real innovation.
Actually, this tool since 17 years of research and development, we still have three years of history, the first SoloPi itself is only a performance testing tool, then gradually extended to cover the functional testing, performance testing, compatibility testing, abnormal test, Mock test and a series of mobile terminal test scenario testing framework, this along the way, SoloPi grew up step by step like our children, steadily and systematically.
In retrospect, SoloPi’s initial appeal was simple: testing is messy, and we wanted easier testing. Therefore, we started with the most troublesome performance testing tools at that time. There were no more than three forms of performance testing tools in the past: PC driven tools, intrusive testing modules, and ROOT tools.
**PC tools: ** With the exception of Android Studio’s built-in performance testing tools, most of the documentation on the market describes the command-line approach, and there are differences, many errors, and few actual tools.
** Intrusive test modules: ** Such tools need to be packaged separately for testing due to their intrusion into the source code, and the tools themselves may also have an impact on performance.
**ROOT tool: ** The first is the need for Android system ROOT permission, for the more and more strict control of the Android system, its path will be more and more narrow.
In order to solve the problems of difficult performance testing and inconsistent standards, we try to start with Android debugging ability and study a scheme that can realize application weight lifting on Android phones without root. After a long period of research, we finally found an ADB remote debugging solution implemented in Java (github.com/cgutman/Adb…). , this scheme communicates with the Android debugging port and obtains shell permissions through the local Socket, so as to achieve local application empowerment (hereinafter referred to as wireless ADB empowerment scheme).
Combined with the wireless ADB empowerment scheme, SoloPi further achieves the corresponding precise acquisition scheme for each performance metric. Testing students no longer need to search/develop/optimize performance testing tools, just need a SoloPi, just a few minutes can quickly complete the usual hours of performance testing work.
After being used in the field of performance testing, we continue to expand SoloPi’s application scope in wireless automation solutions. This time, we’ll focus on the functional testing area. Traditional functional testing usually has two ways: one is to manually execute the test, and the other is to write automated scripts based on the test framework. The cost of the former is huge, and a lot of manpower may be needed to cope with the accelerating product iteration. The latter has a large requirement for testing students’ code ability, which also leads to the relatively slow progress of converting manual testing into automatic testing to save manpower. Combined with our experience in performance testing, we tried to transfer the automated testing capabilities that were traditionally only available on PC to mobile platforms. Based on the usage habits of mobile phones, we developed a set of easy-to-use and powerful automated testing framework, namely the current recording and playback. By recording playback, we can proudly say that we were able to save up to 70% of the time of functional testing.
After the completion of the functional testing scheme, we have more expectations for the automated testing framework. Thus was born a machine control such a compatibility test tool. As for the multi-control of one machine, it started from a chat. If the recording and playback process is separated, the use case recorded by one machine can be played back by several or even dozens of other machines, which can greatly reduce the cost of compatibility test. In the past, compatibility testing has always been a difficult problem in wireless testing. Exponential efficiency can be achieved through one computer and multiple controls. Through the deployment in the test room environment, we have gradually cultivated the habit of testing the compatibility test through one machine and multiple controllers. In the internal practice of Alipay, one of the test students reported that he even did not know how to test compatibility without one computer and multiple controls.
In order to further reduce the testing cost of the majority of students, we continue to explore and optimize the whole R&D process, and have tried and made efforts on some nodes (such as data preparation, abnormal scenarios, small program H5, etc.). Around the core of test performance, SoloPi constantly develops and updates a series of test tools to save labor costs.
Future trends of SoloPi
With the continuous development of testing technology, the trend of intelligent and simple testing is increasingly obvious. Take the MTSC conference in 19 as an example, more than half of the topics are related to AI. Centering on the core of test improvement, we will further explore this aspect and bring AI+ testing to every employee.
During the year of our open source, we also found the appeal of similar tools from game practitioners. Currently, SoloPi is still focused on supporting the testing ability of traditional applications, so we will also make further integration in game scenes. We hope to provide further support for engines like Unity 3D, Cocos2D-X and Unreal. The cost of playtesting can also be reduced.
SoloPi is not just a tool for mobile testing, we want it to be a product for testing practitioners. At the same time, we have been thinking about a problem: how to further reduce the cost of learning and using the test students? In the second half of this year, we plan to launch a set of more lightweight testing methods, which can truly allow students to test like normal application, so as to achieve real intelligence and simplicity.
By the way
The SoloPi Contributor campaign is officially underway. Whether you are a good coder, experienced user, or just starting out, you can participate by submitting features, writing practical documentation, sorting out any bugs you may have encountered, or in any other way that will help others use SoloPi better. We also for the activities involved in the five positive contributor to the exquisite gift, more details can be accessed: testerhome.com/topics/2507…
👉 Click here to visit SoloPi warehouse address now
