Development of UI Automation test framework to avoid repetitive wheel building

Tag: Log SEL Performs a Boolean images Vertica BSP plan format

A lazy up for a long time did not update the article, in fact, lazy is also because of busy, the first half of the overtime to catch up with last year's overtime, overtime, ah, good spit Groove finished writing has been planning to continue the automation of development

There are a variety of UI testing frameworks, but original aim, driving the basic bottom of the PC browser is selenium, driving wireless apps and browsers are basically appium, monkey and the like, the bottom is based on the official support of the automated testing framework developed, And then the upper layer made a variety of packages

First of all in the beginning of planning development automation, the first step is to understand the existing automation development technology, said, the bottom of the several, according to the actual needs to test the business requirements to choose the right automation framework, such as my side to be responsible for PC, wireless m station, wireless app (Android, iOS) four large user portal automated testing, taking into account the technical background of the entire research and development team and the technical background of the group testers, selected the PC based on selenium development, the wireless end based on Appium development, the development language to choose Java, because my basic development language has been using Java, The research and development team has Java, PHP development, encountered problems are also good to consult people; then consider how automated test cases are managed, how the underlying data is managed, how the test results are fed back, whether the use case succeeds or is wrong, if it is wrong, what the reason, Here I use the JUnit Unit Test framework to manage test cases, why I didn't choose testng, because I'm most familiar with JUnit, and one of the reasons behind that is that automation needs to run continuously, not by specific people or what special skills are needed to run, so there is support for a continuous integration framework, Naturally choose Jenkins, and then write the use case to build the compilation, here directly choose ant, why, because it said Ant+junit can directly generate test reports, save to write a test report management system, to avoid repeating the wheel

The technical framework following the selection of the entire system is shown below.

It says that all test cases end up returning the use case execution result, JSON data format, Boolean object success to mark the use case execution, and then you can use assert assertion in JUnit to assert the execution of the use case, Of course, we can also talk about the results saved to the database or local files, convenient for later analysis, we did not do the database to save this piece, time is not enough, there is time to develop later

The above is also missing a point, test cases need to test the basic data, which read from there? TestNG support from the local configuration file read, JUnit to trouble, their own write from the local read file function, can be completed in Beforeclass, but due to continuous integration testing, certainly not every time the data changes, to update the file, commit to the Code branch, You can do this, but because the test data is often updated and requires no SVN or git to execute the use cases they want, we add a Web page to the original management configuration system, all the test base data in the Web configuration, each run of the use case, The test case is here to update the most recent data to run.

The data flow chart is as follows

As above basically completed a qualified sustainable Integration UI testing framework, of course, this framework as long as the replacement of the underlying use case, can also be changed to interface interface Test Framework, this is only investigated under the feasibility, has not been implemented, it is estimated to tread a lot of pits

The above is a framework that is built with existing wheel accessories, except to facilitate the management of test-based data.

Other better implementation programs are welcome to communicate with each other to improve

Development of UI Automation test framework to avoid repetitive wheel building