Automated Testing Summary

I have been engaged in automated testing in the past year. I have never been able to understand automation at all. Now, I feel that I still have made some progress in implementing use cases, manual command line execution cases, and self-made tools to execute use cases.

Automated testing should be advantageous for manual testing. Although it may be difficult at the beginning in the implementation of automated use cases, it is a permanent task, this advantage is extremely obvious, especially when version changes or some use cases need to be executed repeatedly. It can greatly save manpower and time costs. In addition, it is felt that manual testing sometimes produces more or less errors, and automated testing greatly reduces these errors. Even so, automated testing also has some defects, such as maintenance. If the software is unstable and the test cases are often modified, it will take a lot of time to modify the code. In addition, automated testing cannot test some intuitive features, such as the overall aesthetic effect and sound.

Many problems have also been encountered in the automated testing work:

1. most of the work time is in the implementation of use cases. The problems encountered in this part can be divided into two parts: how to find and locate page elements, I will describe this issue through cucumber learning notes. The other is the environment problem. The environment problem is mainly because the browser in the environment will automatically upgrade and the old web-driver will not be updated in time, resulting in the failure of normal execution of the use case. The main environment problems I remember are that I cannot jump to the test page normally after opening the browser. Some elements cannot be found in the initial method, and the API changes. This problem can be solved by downgrading the browser or upgrading the web-driver. If you find that some methods have changed after upgrading the web-driver, modify the corresponding method.

2. The second problem encountered during work is that the manual command line execution cases cannot meet the requirements. At the beginning of the automation work, it was also at the beginning of the project that basically did not implement the use case. At work, it was required to implement the use case every day. At that time, because there are few implementation cases, even if you use the command line to execute the implementation case every day, it is very easy. Later, with the increase of use cases, the manual execution has been greatly impressed by the progress of other work. Repeated and tedious manual execution of those use cases is also very painful. So I thought, could I create a simple program for repetitive and tedious work? After a few days of spare time, the automated execution script V1.0 was born. This version is a winform version, which mainly allows you to select use cases and then perform the selected use cases with one click, generate a test case report for the html version. It seems that although this version is extremely simple, it is also very happy. After all, it reduces a lot of work and does not need to execute the use cases during the day's shift, when I leave work every day, I select the case to be executed and run it. The next morning, I came to view the results and sent a report, which is also a small achievement. Later, the number of use cases continued to increase. Since each use case in the project generates a report, it takes a lot of time to view the report, in addition, you can only view problematic reports. The V2.0 version was also born at this time. It is still a winform applet. In addition to the features of the first version, it also analyzes the generated report, extract problematic use cases and some failed information. Then I only need to pay attention to these problematic use cases and then send the corresponding report. Later, the number of use cases continued to increase. All use cases could not be executed on a single machine for one night, and it was also cumbersome to send test reports every day. At this time, V3.0 came into being. In V3.0, the original winform version was changed to the web version, which was implemented by Asp.net mvc5, this version mainly solves the problem of assigning case execution to different machines, intuitively viewing all the case execution results on the web, ensuring that each execution is the latest code and can be customized. set the corresponding execution plan. Because of the Bug, this version has been changed many times, but it is still in use. I will share this system in subsequent articles.

Today's article is written here.