In my limited software testing experience, a full-time summary of automation testing experience

Abstract ： In my limited software testing experience , I have a full-time experience in automated testing .

Contact Automation

It was the first time I started automated testing , The team uses Python, The framework of interface automation testing is requests+Excel+Jenkins,APP The framework of automated testing is Appium.

The whole company had an existing APP, So during the probation period , My task is to complete the existing APP Automated scripting and debugging .

I remember just starting to go , Very inexperienced , After understanding the business with the function test students , Just bury your head and protect the environment , And then one day , The test supervisor asked me , Whether to output an automated test case . I suddenly realized , So I used the use cases of function test for reference , A screening of use cases , Output an automated test case （ Now look back , The practice at that time was really hasty , There is no automated test plan , There is no review of automation use cases , I only know that the pain point of functional test students is that the iteration is too fast , It's too late to do ）.

After case output , It took about a month , The environment deployment and basic use case script are completed , At that time, about forty or fifty scenes were realized , And completed the automatic sending of test report . The remaining two months , I will expand the scene step by step to more than 200 .

There are also some problems , For example, the acquisition of login graphic verification code , But the use of OCR Graphics recognition was soon solved , Colleagues also have platforms such as cloud coding .

The biggest problem is , When APP After version update iteration , Fixed page all id、class And other properties will change , Because these are written dead in the code , If you want to change, it means that every page All need to be changed , The workload is very heavy , And some tools are needed to get these properties , Such as UI AuTomatorviewer 、Appium Self contained Inspector.

After a busy period of time , Find an Android Developer first , Checked with him , He can't find the problem , Then I found another developer , After checking, he found that Android confused packaging , He gave me a package that didn't mix up APP, This solves this problem .

Another big problem is ,APP Automated tests take a long time to run , We have two or three hundred use cases , If you add failure, try again , It takes about four or five hours to run , In addition, there will be an error in the intermediate script and the problem of running and stopping .

One thing I remember deeply is , We're going to publish it the next day , The first day before work, I started running scripts , Until the evening, I didn't receive the email of the test report , So I rushed back to the company at more than 10 pm , Found that the automation script has stopped .

For a long time , Later I try to introduce UI AuTomator2（ hereinafter referred to as u2） Frame instead Appium, Beyond all doubt ,u2 It has great advantages in execution speed .

I've compared these two frameworks , Same scene ,Appium take 60 Multi second ,u2 It only needs 20 More than a second , It saved two-thirds of the time .

But the new problem is ,u2 Less stable ,Appium Finding elements in is useful to explicitly wait 、 Implicit waiting and forced waiting , and u2 You don't seem to need these , In fact, if you run the scene several times, you will find u2 Execution is too fast to find the element , So you have to manually add forced waiting . This does not save much time .

This problem was not solved at that time , Instead, in a period of time after I left , Through the study pytest-xdist Documents , Find out pytest-xdist Can be based on ssh and socket To achieve distributed execution .

for instance , If there is 200 A scene , At the same time to start 2 An actuator , Then it will go to the executive machine -1 Push up 100 A scenario , To actuator -2 Push another 100 A scenario , Finally, the test reports of the two executors will be integrated into one report . If such a solution could be applied to practice at that time , that APP The problem of long automated testing time will be perfectly solved , The only thing to notice is that , Each scene should be independent , Can't depend on each other .

Come back ,APP Automated testing doesn't seem to generate much revenue , Because I'm the only one who develops and maintains , So when it comes to the maintenance stage, it is time-consuming and labor-consuming , In particular, a fixed page has been changed or a new set of logic has been inserted in the middle , It means that a considerable number of pages need to be adjusted .

Second contact project

After almost doing this for a few months , The company began to set up new projects , At the beginning of a new project, I made up my mind to do interface testing , So I got involved in this project again , Attend the project initiation meeting 、 Participate in technical review , Know what to do , And how to manage interface documents , How to define the interface, etc , Started the interface test of the new project .

That stage , Use requests Read Excel It's very convenient when there aren't many interfaces , Because the code framework is relatively fixed , It only needs Excel Modify the parameters in .

But with more and more interfaces , It also means that there are more and more dependencies between interfaces ,Excel Management is a disaster , stay Excel Clarify the dependencies of different interfaces in , It's a very headache .

Later I used Postman Did some quick tests , When there is plenty of waiting time , Then slowly add... To the interface test of the whole main process . In the interface test phase , I found some problems before and after , But the big problem is that it has not been solved Excel The problem of storing data and failure to verify the correctness of data .

And we are still a payment related business , This makes the interface test results only ensure that the service is normal , The return code is normal , But whether the data is correct is unknown .

It was not until later , The automation team changed a group of people , The new colleagues began to implement Java Stack , Use Springboot+httpclient+Maven As an interface automation framework , Basically abandoned the previous Python Automation script .

In those months, several colleagues devoted themselves to the preparation of interface automation script of the same project , Compared with before, I was responsible for the automation of two projects alone , Things are really much better .

This automation is also scenario based , There is verification for normal and abnormal input , And the final warehousing inspection , The amount of scripts is very large , The request data and expected results of all abnormal scenarios are stored , When it comes to subsequent requests , First get the request data from the database and send the request , Get the response result and compare it with the expected result of the database , Normal scenarios require manual writing of logic , Compare the value of the important field in the response result with the value in the database .

At that time , Considering many complex scenarios that cannot be measured by the front end , Concurrent 、 Idempotent or something , Therefore, the defects found are more meaningful , But the maintenance cost is still relatively high .

What is automation ？

The last year or two , I sometimes think about what automated testing is ？ Automated testing was born to improve testing efficiency , Sometimes it's not used properly , But become a burden in testing activities .

But there's no denying it , Automated testing is still effective , The difference is only the way of using , in my opinion , To do a good job in automated testing, we need to avoid the following points ：

Not for automation, for automation

Automated testing cannot be based on KPI, It depends on whether the current project is suitable for automation , Whether there are enough resources to invest and the cooperation of external teams .

Automation is not everything

Don't be greedy for perfection , Delusion that all test scenarios can be automated , Especially for projects with fast update iterations . Can realize stable functions , And be ready to return , That's enough .

Automated scenarios

One is the basic scene , The other can be a scenario that the front end cannot achieve .

For the endless fields in the interface, strict exception verification is carried out , To ensure that the program is robust enough , Sometimes it's not so necessary .

Because the development cycle is short, the company has several versions a week , Development simply doesn't have time to do exception handling for some unimportant fields , Of course, the types of important fields 、 length 、 Non null verification still needs to be done .

Awareness of Automation

Some peers believe that , Automation is to find defects , But the defects found by automation are not comparable to functional testing at all , Isn't automation meaningless without finding defects ？

This is not the case , Especially the automation of some regression tests , On the one hand, it is to improve efficiency , On the one hand, it is to enhance the confidence of the team before going online .

Training of team talents

Met some companies , Finally started Automation , Well done , Wait until the person in charge leaves , No one will maintain , Then recruit some automated testers to start a new stove , over and over , In the final analysis, no one does technical backup .

Last ： It can be in the official account ： Sad spicy bar ！ Get one by yourself 216 Page software testing engineer interview guide document information 【 Free of charge 】. And the corresponding video learning tutorial is free to share ！, It includes basic knowledge 、Linux necessary 、Shell、 The principles of the Internet 、Mysql database 、 Special topic of bag capturing tools 、 Interface testing tool 、 Test advanced -Python Programming 、Web automated testing 、APP automated testing 、 Interface automation testing 、 Testing advanced continuous integration 、 Test architecture development test framework 、 Performance testing 、 Safety test, etc. .

I recommend one 【Python Automated test communication group ：746506216】, We can discuss communication software testing together , Learn software testing together 、 Interview and other aspects of software testing , Help you advance quickly Python automated testing / Test Development , On the road to high pay .

Friends who like software testing , If my blog helps you 、 If you like my blog content , please “ give the thumbs-up ” “ Comment on ” “ Collection ” One Key triple connection ！