Real test = "half product + Half development"?

What is this article about ？ What is a real test ？ It's purely personal , For reference only .

• On a real software testing engineer

• The application of automation in the project

• Application of special performance in the project

01、 Half a product 、 Half a development

Some people find this title a bit ironic , The real test ？ Are we not really testing , What you usually do is not testing ？ In fact, it's neither positive nor negative , But this is an inclusive relationship , If it's just a review + Use case writing execution , So it's not really a test .

Half a product , It is mainly reflected in understanding why this requirement should be done ？ What is its core value ？ What are the characteristics that attract users ？

It means that in the review phase , In addition to helping improve the functional requirements , It is more important to understand the value of this requirement to users . What do you think and feel as a user , You can't simply go through the process .

For example, an application for playing video , diversity 、 Fluency 、 Simplicity 、 Rapidity, etc , This can be summarized after the review .

Then hold this value point , Around this, our whole testing process , You can often find different places .

For example, it is still a playback application , After understanding the features , During the test, you need to pay more attention to the performance of playback , And compatibility . These test points will be indicated when designing the test plan , So that you or your team members can pay more attention to the test points in this part during the test .

Then the priority and coverage will be improved when designing test cases . You can find , The test has a test focus .

Half a development , In fact, I think this is a preference for grey box testing . Reflected in a demand , In addition to clarifying the business logic of this requirement , Its code logic ( Data flow logic ) Also need to know .

From the background json The data structure is displayed to the client and then stored to the local data , This is a flow direction , All need to be understood and tested ( This part refers to the test analysis article written before ).

So the test verification is not just about the functional level , Or an internal implementation ( Of course , The function of test development is to test class methods , It's not about our test ).

What we want to guarantee , It is the correctness and fault tolerance of data at this stage .

The advantage of this is , Can find defects from the inside , When a problem occurs, you can roughly locate the problem , In the face of problems boss The challenge of can put the responsibility on the development , Oh no , Is a better solution to the problem .

The half development is also reflected in the improvement of tool efficiency , Be able to use small scripts , Small framework to improve test efficiency , This requirement is necessary for basic language requirements , The test of a certain round of interview in a large company is your code ability , So there is no doubt that testing is still half development .

02 Scope of functions

• review

• Establishment of test plan

• Writing and maintenance of use cases

• Sharing of technical points

• BUG Submission and summary

• Output test report

• Integration testing

• The release

• Forum / Collect feedback from other channels

• Server performance test

• APP Performance testing

• Web front end performance

• Script automation

03、 Daily workflow

Actually for now , The current workflow is like this ( Of course, the cycle is a version iteration ):

Review new requirements , Record key points –> Write test points ( Use cases )–> Learn about some implementations from developers before testing –> Perform the test ( Look through the code , View the main logic trend < Optional >)–> Submit BUG–> Return to BUG( see BUG Code changes )–> Performance evaluation of new requirements ( Optional )–> Pre release system testing ( Combined with automation )–> Release –> Complementing automation use cases ( Optional )–> Summary of business logic –> rest

Then the basic process is like this , You can see a project team of real testers , Is to complete so much work , So this is also used to distinguish between manual outsourcing personnel and regular employees , How about outsourcing , Everybody knows .

Add ：

Steal the timing of a great God

Time Job content

30% Review the preparation of use case maintenance and subsequent work

20% Execute test case ,BUG Return to

50% automation & New technology learning , introduce !

Learning resource sharing

Finally, thank everyone who reads my article carefully , Watching the rise and attention of fans all the way , Reciprocity is always necessary , Although it's not very valuable , If you can use it, you can take it

These materials , For those who want to engage in 【 software test 】 For our friends, it should be the most comprehensive and complete war preparation warehouse , This warehouse also accompanied me through the most difficult journey , I hope it can help you ！ The above information can be shared , Just click below to enter the group .