Editor's Note: The author of this article is Ma Lin, Manager of the Testing Department of the R&D Center of Leading Future Technology Group.
Leading Future Technology Group was established in 2007 and is headquartered in Beijing. It is a leading B2B integrated solution service provider in China. With more than ten years of experience in the industry, Leading Future Technology Group (hereinafter referred to as “Leading Future”) is committed to providing customers with digital solutions for all-scenario procurement, covering office materials, industrial products, gifts and welfare, smart office and other fields, and can provide 21 major categories Premium merchandise with over 2 million SKUs.
At present, Leading Future has provided professional services to tens of thousands of customers including central enterprises, government, military, state-owned enterprises and the world's top 500. Relying on more than 1,000 service outlets and professional service teams across the country, online procurement and online The in-depth integration of services has achieved full coverage of customer services and made customers' work better.
Relying on more than ten years of B-side procurement service experience, the leading future uses the self-developed digital system to create a full digital procurement link for various enterprise procurement scenarios, which is more in line with business application scenarios. At present, the Group's B2B office service platform includes the leading future mall on the PC terminal and the leading future mall on the mobile terminal, and the back-end includes ERP operation management system, CRM customer management system, WMS warehouse management system and mobile office OA system.
Testing Issues and Challenges
The testing team leading the future has nearly 40 people and is affiliated to the group's R&D center. There are more than 20 parallel testing projects in each product line. The projects are all based on the micro-service architecture, involving test content such as function, interface, UI, performance, Elasticsearch, and big data. There are generally short project delivery cycles, heavy tasks, and tight testing time, making it difficult to achieve 100% coverage and regression. Based on various factors, the testing team plans to gradually increase the proportion of interface testing compared to the higher implementation costs of unit testing and system testing (UI, integration, etc.), similar to expanding the middle layer in the spindle model.
Interface testing related work content
■ Functional testing team:summarizes a CheckList for common errors in the interface, and uses tools such as browser F12 and Fiddler to verify the correctness of the request and response content of the external interface of the page by manual packet capture;
■ Interface testing teamfor connecting with third-party systems: Test the interfaces developed by connecting with third-party systems, involving interface testing and joint debugging of the interfaces of both parties. The number of such projects is large, the cycle is short, and the interface design scheme of each project is different;
■ Own product interface testing team:The many microservices of each product line involve thousands of internal and external interfaces, which are uniformly maintained in Swagger. Single-interface testing and multi-interface testing based on business scenarios are required, and long-term iterative maintenance of interface test cases and scripts is required.
Main work pain points
■ The immersion level of interface testing for each test group is inconsistent. Some are based on independent tools, some are based on Pytest framework, and some are based on JMeter. It is difficult to standardize and integrate all kinds of test scripts, and cannot be managed uniformly. In addition, the personnel effectiveness and product quality between projects cannot be reasonably measured and compared horizontally;
■ The execution of the interface test case is not connected with the development self-test link. We hope that the interface test case is developed by the tester, and then handed over to the developer for self-testing. After passing the test, the tester conducts the final acceptance, and there is no need for the tester to repeatedly execute the use case and then notify the developer of the result. This seems to be a simple link, but without the support of a unified platform, only relying on Postman, Git and other tools to maintain the use case script, it is difficult to implement seamless connection between development and testing.
Advantages of MeterSphere
After using the MeterSphere open source continuous testing platform, we obviously feel that the interface testing is more standardized and efficient. To sum up, the advantages of MeterSphere mainly include the following aspects:
1. Low switching cost and easy to use
From traditional manual functional testing to interface and performance automation testing, the ease of use design of the MeterSphere platform is still very good. Basically, students who have used ZenTao, Postman, and JMeter can quickly get started and seamlessly connect. It took just over a week for the testing team ahead of the future to get in touch with MeterSphere and put it into practice.
2. Effectively improve team work efficiency
Compared with various independent and stand-alone testing tools, the MeterSphere continuous testing platform is more suitable for team collaboration, and can be supplemented with corresponding permission control for different roles. From the dashboard on the homepage of each project, we can view the number of interfaces macroscopically, and then estimate the workload of post-testing and formulate an accurate test plan. Through interface coverage statistics, the actual work progress of the project can be controlled.
3. Powerful and flexible interface test support capability
In the testing department, a number of projects have achieved comprehensive application from interface definition, writing interface test cases, coordinating multiple interfaces to cover business lines, and generating test reports.
① Interface definition function. Some third-party projects will be entered manually, and some large-scale self-owned projects will be imported directly through Swagger. For thousands of interfaces, this function is very convenient;
② Write independent interface test cases. MeterSphere supports the definition of general capabilities such as various requests, parameterization, association, and assertion. At the same time, it expands more tools such as pre-script, post-script, SQL, parameter extraction, and global settings. Currently, it basically meets the requirements of most projects. Interface test scenarios.
③ Interface testing based on business scenarios. In addition to forward and reverse testing for each independent interface, the team also considered scenario-based interface testing, and executed multiple interfaces in turn in a line of business manner to improve product quality confidence. This part of the use case is relatively complex, involving more script content such as database reading, encryption processing, batch construction of test data, and association.
④ With the gradual familiarity with MeterSphere, each test team also accumulated some tips. For example, the labeling function is used flexibly to indicate which are positive use cases and which are abnormal use cases; and for abnormal test cases designed with different input parameters, the number of abnormal test cases is large and the similarity is high. At this time, we will maintain the standard API definition first. All parameters define valid inputs in advance, and then use them as templates to generate multiple abnormal use cases, so that only minor modifications are required in the corresponding parameter positions.
TDD and DevOps
The MeterSphere open source continuous testing platform can strengthen the collaboration and communication of the testing team, and improve the continuous software delivery capability through automated testing. After the introduction of MeterSphere, we have tried the process improvement in which testers write interface test cases in parallel, and at the same time create test plans in the test tracking module, assign roles and permissions to developers, and let developers execute and pass the process improvement in order to reduce the number of tests Repeated communication during execution. This process invisibly standardizes the developed interface design specification, otherwise the test case will be difficult to execute and pass.
Looking forward to improvements
■ The configuration of the test environment is often lower than that of the production environment. When executing scripts, individual use cases often fail to execute due to network jitter, service instability, service call timeout and other factors. At this time, it is necessary to manually supplement and execute the failed individual use cases for verification outside the overall test plan, so it is hoped that the MeterSphere platform can set the global and local settings for the repeated execution times after the use case fails;
■ I hope that the MeterSphere platform can collect as many enterprise application scenarios in different fields and scales as possible, and combine with the latest testing concepts in the industry to form its own testing theoretical system and supporting best practices. It is also hoped that the MeterSphere open source project team can design typical Demo cases, supplemented by detailed documents, video materials, etc., to inspire and support more small and medium-sized enterprises, which is also conducive to the promotion of the MeterSphere project in the enterprise user group.
The introduction of the MeterSphere open source continuous testing platform into the leading future has brought us a great surprise, and I would like to thank the MeterSphere open source project team for their hard work. We also expect that the MeterSphere project will grow faster, become more powerful, and steadily build into the best open source test management platform in China in the future.