当前位置:网站首页>Introduction to Google software testing

Introduction to Google software testing

2020-11-06 01:35:46 itread01

Some time ago, I was confused , There is no clear learning direction and content . But one thing should be certain : When you are confused, use your spare time to read !

This book , At present, I just have a rough look at it , I feel a lot . Here are some personal notes , There are some differences with the original text . It is suggested that interested partners read the original books !

 

One 、 Quality is not equal to testing

The mass is not measured : It's impossible to develop quality software without testing .

Guarantee quality :

   Test and development are carried out at the same time :google The goal is .

   Development responsibility for quality : Test immediately after writing a piece of code , More code done, more testing done ; Quality is like preventive behavior ( Quality is a problem in the development process , It's not a test problem ).

       Test : Online bug Heavy , It will roll back the version ; Judge how well prevention is being done ( Development testing , Can you ensure that there will be no rollback level bug It happened ).

 

Two 、 role

1、 Software development engineers SWE:

Implement functional code used by end users :

   Create design documents 、 Choose the best data structure and overall architecture 、 Code and implementation auditing .

Write test code :

   Test Driven Design 、 Unit test 、 Participate in building tests of all sizes .

Add functional code or code that improves performance .

Quality responsibility :

   Write to them 、 Repaired and modified code is responsible for quality ( Fault tolerant design 、 Fault recovery 、 Test Driven Design 、 Unit test ).

2、 Software Test Development Engineer SET:

Focus of work :

   Guarantee SWE The developed functional modules have testability : Participate in design review , Observe code quality and risk ; Code may be refactored , Write unit test framework and automated test framework .

   Common test infrastructure .

Responsible for providing test support :

       There's a testing framework : You can isolate newly developed code , Manage code submission by simulating a real work environment and code submission queue .

Concern : Quality improvement and increased test coverage .

The purpose of writing code is : Can make SWE Test your own function .

3、 Test Engineer TE

Focus on testing from the user's point of view :

       Spend a lot of time simulating user scenarios and automating script or code writing .

       Whether the performance expectations are met , In security 、 Internationalization 、 Whether the access permission meets the requirements of users .

Work :

   Organize overall quality practices ( hold SWE and SET The written tests are organized into categories ), Analyze and interpret test execution results , Drive test execution , Build end to end automated testing .

 

3、 ... and 、 Organizational structure

Most companies :

       Senior managers usually come from product managers or development managers , Not from the test team .

       When the product is released , The priority is whether the function is complete and easy to use , Little consideration is given to quality .

       As a team , Testing is always making way for development :“ The industry is full of flaws 、 Products of premature birth ” The problem is ; If the quality is not good, release another patch .

Google Organize reporting relationships :

       Divide different areas of focus : Client 、 Geography 、 Advertising, etc ( The development work is reported to these domain focused managers ).

       Testing is an independent department : Engineering productivity team

  • Enter the product team on lease :

1)      Do related work to improve quality , Or publish some unacceptable defect rate data ;

2)      Not reporting directly to the product team , You can't pass the test just because the project needs to be released urgently ( You can negotiate in advance . Have your own priorities , In reliability 、 Security issues don't compromise );

3)      Can make SET and TE Keep fresh and busy , A good idea can spread quickly within the company

  • According to the priorities of different product teams 、 Complexity , And compared with other products , And then assign testers ( There may be a mistake , But on the whole, it will maintain a certain balance between the actual demand and the unclear demand ).

 

    Four 、 Climb, walk and run

1、Google Products often contain only the most basic features available in the initial release

Feedback from internal and external users is obtained in the subsequent fast iterations .

Every iteration pays a lot of attention to quality .

Before the product is released , Will experience the Canary 、 Develop 、 Test 、beta Or officially release the version .

2、 The Canary version

The version to build every day ( Members of the core development team will install ):

       This version may not be able to use the basic functions it should have ;

       Error code installed , Mobile phones don't even have access to basic features ;

Used to exclude filtering obviously inappropriate versions :

       Build failed , It means that there may be serious problems with the process

3、 Development version

Release... Every week , This version has certain functions and passed a series of tests : Product engineers will install .

Can't meet the daily needs of real work , Will call back the Canary version : The engineering team will take the time to reassess .

4、 Test version

Passed the continuous test , The best version in a month .

Has sustained good performance , Will act as beta Candidates for testing .

5、beta Or release the version

The first version released to the public : Experienced internal use and passed all quality assessments .

 

5、 ... and 、 Test type

Use appellation : Small tests 、 Medium test 、 Big test .

Emphasize the scope of the test, not the form ; The smaller the scale , The more likely it is to be automated testing .

1、 Small tests

Verify that the code for a single function or function module works as expected .

It's usually automated :

       It can be done in seconds or less .

       SWE Realize , There will also be a small amount of SET Participate in .

Use mock, stay fake( False realization ) Execute... In the environment .

2、 Medium test

Verify the interaction between function modules and the correct function when calling each other .

It's usually automated :

       After the development of independent modules ,SET Will drive the implementation and execution of these tests ,SWE Will be deeply involved in , Code together 、 Debug and maintain these tests .

       Execution failed ,SWE Will consciously examine and analyze the reasons .

       Late development ,TE These use cases will be executed manually or automatically .

General execution in the false implementation of (fake) In the environment or in the real world .

3、 Big test

Covering multiple modules , Focus on the integration of all modules , Tends to result driven , Verify that the software meets the needs of end users .

Or through automation , Or exploratory testing : All three kinds of engineers are involved in ; It takes hours or more .

It's usually executed in a real environment , And use real user data and

版权声明
本文为[itread01]所创,转载请带上原文链接,感谢