[UI automation testing] Jenkins configuration

Some time ago, I helped the team build a UI automation environment. Here I will share some configurations of the Jenkins environment with you.

background:

One of the goals of the team in the second half of the year is to realize automated testing. Here I want to complain. The test platform developed before was originally intended for interface automation testing and performance testing. However, due to various reasons, the function of interface automation testing The whole thing was discarded, which has a lot to do with ease of use, and also has something to do with our company's interface business. However, students who develop the performance test function are very happy to use it, and the management of the interface is currently an important bridge connecting the front end and the back end. At present, environmental management has been added (my company mainly uses docker to create development and test environments), and recently, demand management and bug management have been added, so it has changed from a "test platform" to a "development collaboration platform". Why not use the mainstream defect management system on the market? For example, Zen Tao, JIRA. Because our company has its own specific development process. In terms of environmental management (docker), the platforms on the market are not enough.

Back to automated testing, of course, interface automation is the priority. I have also shared the comparison of mainstream interface tools/frameworks before, but after actually communicating with the test students of the business line, I found that the payment interface is asynchronous, and the gateway to go is also asynchronous. Not sure, it turned out to be hard to do. The business of adding and testing is interlocking. From selecting an activity, adding a shopping cart, to paying, the user involves more than a dozen interfaces, all of which are highly dependent on the return value of the previous interface. It doesn't make much sense to test a single interface if you remove the dependency (using mockServer), and it can't cover the existing business scenarios.

Therefore, we gave up the interface automation test and started from the UI first, which is easier to do, just simulate the user's operation process. Therefore, it is not that interface automation is necessarily better than UI automation, it depends on the project.

Technologies used in UI automation:

  • selenium: no explanation.

  • pytest: A unit testing framework, because it can globally configure the opening and closing of browser drivers, and there are many useful extensions, which are more suitable for UI automation.

  • pytest-html: Generate HTML test reports, you can configure automatic screenshots of use case failures, which is very important for UI automation.

  • pytest-rerunfailures: It can realize the failed rerun of use cases, which is also very important for UI automation. Selenium-page-objects: The page objects library I encapsulated has been introduced before, which makes it easier for you to write the page layer.

  • Git/Bitbucket: Our test code is submitted to Bitbucket for management.

What do Jenkins do?

The next thing is the point, Jenkins is mainly used to run UI automation tests. Next, let me introduce my configuration.

Configure Git, connect to Bitbucket, and check for project code updates.

Timed task, set to run every night at 22:00.

Build commands, pull code, and run all use cases.

Set the path of the HTML test report

Set path for XML test report.

Configure the email function.

The general effect is as follows:

You can click HTML Report to view the HTML report. For the latest results, you can see the report in XML format of the project. Test trend graph, which is generated based on the XML report plug-in.

View test HTML test report in Jenkins.

Of course, there is also the email received when the build is completed.

I hope the above introduction can provide you with some ideas.

Friends who are studying for the test can click the small card below

Guess you like

Origin blog.csdn.net/m0_68405758/article/details/132044775