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

Introduction to Google software testing

2020-11-06 01:15:05 --D

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 : Write a piece of code and test it immediately , 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 : on-line 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 happen ).

 

Two 、 role

1、 Software Development Engineer SWE

Implement the function code used by the end user :

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

Write test code :

   Test Driven Design 、 unit testing 、 Participate in building tests of all sizes .

Add functional code or improve performance code .

Quality responsibility :

   Write to them 、 The repaired and modified code is responsible for quality ( Fault tolerant design 、 Fault recovery 、 Test Driven Design 、 unit testing ).

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 ; It's possible to refactor the code , 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 , By simulating the real working environment and code submission queue to manage the code submission .

Focus on : Quality improvement and increased test coverage .

The purpose of writing code is : It 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 rights meet the requirements of users .

Work :

   Organize overall quality practices ( hold SWE and SET The written tests are organized into categories ), Analyze and interpret test run 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 disclose 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)      It can make SET and TE Keep fresh and busy , A good idea can spread quickly within the company

  • According to the priority 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 product launch , Will experience the Canary 、 Development 、 test 、beta Or the official release .

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

Weekly release , 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 the last month .

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

5、beta Or release 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 run in seconds or less .

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

Use mock, stay fake( False realization ) Running in the environment .

2、 Medium test

Verify that the function modules interact and call each other correctly .

It's usually automated :

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

       Run failed ,SWE Will consciously check and analyze the reasons .

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

Generally run in a fake implementation (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 the end user .

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

It usually runs in a real environment , And use real user data and resources

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