Function test - knowledge points and common interview questions

Familiar with the project

 Familiar with new projects 
1. According to the UI Interface and requirements documents , Use mind mapping to sort out the organization chart of the project （ Page level ）
     Purpose ： Understand the functions of the page 
2. According to the organization chart , For each page, click on each function ; Sort out the core business processes of the project , Describe the business process in words 
     Which system － Which page － Which button 
3. Combined with architecture + Core business process ＝ The core function module of the project （ The implementation of core business processes requires the use of functional modules ）, stay X-Mind Use small flags to identify the core functional modules 

Project introduction

 One 、 Business features ( What does the project do ？)
 Two 、 Project structure ( Composed of subsystems , User and function )
 3、 ... and 、 The core module of the project ( The module you are responsible for testing )
 Four 、 The core business process of the project ( a key )
 5、 ... and 、 Technical structure of the project 

Software quality model

double V Model （ Documents corresponding to the test phase ）

Test categories  

1） Divide according to the test method

 Black box testing ： The most basic function test , Don't care about internal code implementation , Only verify the correctness of input and output .
 White box testing ： Based on logic drive or based on code testing , Open the implementation inside the code , To study the correctness of the interface or specific implementation in the source code .
 Grey box testing ： A test in between .

2） Divide according to the test objectives

 A functional test ： Test the functions of products and modules 
 Performance testing ： Test the performance of the system 
 Pressure test ： Test the load capacity of the software or system , Dig for hidden dangers 
 Compatibility test ： Test the compatibility between products and hardware and software , For example, the compatibility of software on different Android models .
 Safety test ： Find software security problems in different ways , Like information leakage 、 Illegal use 、 Vandalism and so on .
 Other special tests ： For example, weak network test 、 Power consumption test 、 Fluency test and so on 

3） Divide according to the software development stage

 unit testing ： White box test the independent modules in the program , The purpose is to test the correctness of the basic components of software 
 Integration testing ： Through the combination test of unit modules , The purpose is to verify whether the interface between unit modules is correct 
 The system test ： Test the whole system completely , Verify the correctness and compliance of the whole system 
 regression testing ： When software changes , Verify the functional modules that may be affected by this change 
 The acceptance test ： The last phase of testing , Ensure software quality before software release or launch 

4） Other common test concepts

 Smoke testing ： Smoke test is a simple test of the most basic functions of the software , A low cost way to determine whether software is testable 
     Smoke testing comes from hardware testing , When the circuit board is ready , First, there will be a power up , If there is no smoke, the next test will start , Otherwise, the product does not meet the most basic quality requirements , It needs to be remade .
​
 Exploratory testing ： Exploratory is more dependent on the personal experience or expertise of the tester , It depends on the subjective initiative of the tester .
     The importance of exploratory testing can be found in the field of game testing , Thousands of players will play games in unexpected ways in various unexpected environments , So the tester of the game should not only master the testing methodology of the system 、 Beyond advanced testing tools , But also have rich experience in the game and explore the test thinking .

α Testing and β test

α test	β test
Bring users to the developer's environment , The number of users is relatively small , Time is more concentrated	Users test in different places , The number of users is relatively large , Time is not concentrated
Testing and development are present	Test and development not present
It is an informal acceptance test	It is an informal acceptance test

Testing process

Requirements review

Test plan and scheme

Use case design and review

  Use case execution

Defect management

Test report

White box testing

 Coverage from high to low ：
     Path coverage -- Go through every combination of every road 
     Conditional combination covering -- The combination of each clause in each judgment should cover 
     Conditional judgment covers -- Combination of conditional coverage and judgement coverage 
     Conditional coverage -- The difference of each clause in each judgment TRUE、FALSE Take it all once 
     Judge coverage -- Be able to take at least one in each judgment TRUE, And at least once FALSE
     Statement override -- Conditions and execution statements cover 

Interview questions

Coupon test point

 Can superposition be used 
 Whether to reuse 
 Can I use it after expiration 
 Whether the effective time can be used 
 issue 100 Zhang Youhui's words , More than 100 coupons can still be received 
 Whether the same person can receive the same type of coupon multiple times , If a person receives it many times , Use up one , The quantity should be reduced by one grade 
 Used coupons , After overtime payment , If the coupon is valid , Can go back the same way , Can still use 
 If the coupon has expired when it is returned , This needs to be displayed according to the demand , And cannot be used again 
 Expired coupons , Cannot display in the list of coupons to be used 

How to test payment business ？

 Based on the payment scenario in the previous project , At that time, the test was divided into two ways . Because of our payment channels : WeChat 、 Alipay 、 The bank chooses at will , The test interface is not opened , Only real payments can be made . So the first way to use : After confirming the order, modify the order amount to 1 Cents , Test the jump after successful payment . Other abnormal conditions can be tested normally : If the balance is insufficient 、 Password error, etc .  Based on interface test level , use mock Analog interface mode , Simulate various abnormal returns of the bank , Check whether the corresponding response processing of our system is correct .

Give you a website, how do you test ？

①： First, find the requirement description 、 Website design and other related documents , Analyze test requirements 
②： Make a test plan , Determine test scope and test strategy , It generally includes the following parts ： Functional test , Test the interface , Performance testing , Database test , Safety test , Compatibility test 
③： Design test cases ：
-  Functional tests can include , But not limited to the following aspects ： Link test ; Whether the link jumps correctly , Whether there are empty pages and invalid pages , Whether there is incorrect error information returned, etc ; Submit functional tests ; Whether multimedia elements can be loaded and displayed correctly ; Multilingual branch   Whether it can correctly display the selected language, etc 
-  Interface testing can include but not limited to the following aspects ： Whether the style of the page is uniform , beautiful . Is the page layout reasonable , Whether the key content and hot content are outstanding . Whether the control works normally . For space that must be installed but , Does it provide the function of automatic download and installation . Text check .
- ( Finally added ) Performance testing is generally considered from the following two aspects ： Pressure test , The load test , Strength test  .
-  Database testing needs to decide whether it needs to be carried out . Generally, database needs to consider connectivity , Access to data , Verification of data content .
- ( Finally added ) Safety test ： Basic login function check ; Is there an overflow error , Cause system crash or permission disclosure ; Check the common security problems of related development languages , for example  SQL  Injection, etc. ; If you need advanced security testing , Make sure to get help from a professional security company , Outsourcing testing , Or get support .
- ( Finally added ) Compatibility test , According to the description of the requirements , Identify supported platform combinations ： Browser compatibility ; The compatibility of the operating system ; Software platform compatibility ; Database compatibility .
④： Carry out tests , And record defects . Reasonably arrange and adjust the test progress , Get the resources needed for the test ahead of time , Establish a management system （ for example , Requirements change 、 risk 、 To configure 、 Test documentation 、 Defect report 、 Human resources and so on ）
⑤： Review regularly , Evaluate and summarize the test , Adjust the content of the test .

No requirement document , How would you perform the test ？

 If there is no requirement document, I will start from the following aspects :
1. Sort out the test demand tracing table according to the customer's function points 
2. According to the developers Software Specification List Organize our functional test points 
3. Carry out project cross sectoral seminars 
4. Testers sort out use case requirements and submit questions to the project team and customer representative for reply 
5. Project internal use case review 
6. Email and customer representative to confirm some controversial issues 
7. project Demo And some developed systems 
8. Refer to similar products of the same industry and competitors 
9. The test of cross module should pay attention to 
10. Consult some customer needs and questions 

Give you an object （ glass 、 vase 、 pen 、 Table ） How do you test ？

 Whatever it is , They are designed from the following dimensions :
1、UI
2、 function 
3、 performance 
4、 Security 
5、 Interface 
6、 Ease of use 

 give an example , The interviewer asked you how to measure a cup , At least write 20 Test cases ：
1. A functional test ：
 Mainly focus on the basic functions of the water cup 
    1.1  Whether the water cup can hold water normally 
    1.2  Whether the water cup can drink water normally 
    1.3  Whether the water cup has a lid , Whether the cover can cover normally 
    1.4  Whether the water cup has thermal insulation function , Whether the insulation function is normal 
    1.5  Whether the water cup will leak , Cover and check whether there will be water leakage after tightening the cover 
2.ui test ：
 Mainly focus on the appearance of the water cup 、 Color 、 Design, etc 
    2.1  Whether the appearance is complete 
    2.2  Whether the appearance is comfortable 
    2.3  Whether the color matching and use make people feel comfortable 
    2.2  Whether the appearance and size of the cup are moderate 
    2.3  Whether the cup has a pattern , Whether the pattern is easy to wear 
3. Ease of use test ：
 Mainly focus on whether the water cup is convenient to use 
    3.1  Is it convenient to drink water from a water cup 
    3.2  Is it convenient to pick up and put down the water cup , This will be derived from the test of the shape of the water cup 
    3.3  Is it convenient for the water cup to hold water 
    3.4  Whether the water cup is convenient to carry 
    3.5  Whether the water cup has anti-skid function 
    3.6  When the water cup is filled with low-temperature or high-temperature water , Whether it will make your hands feel uncomfortable 
4. Performance testing ：
    4.1  When the cup is filled with water , Whether it will leak out 
    4.2  Maximum use times of water cup 
    4.3  Whether the thermal insulation of the water cup meets the requirements 
    4.4  Whether the cold resistance of the water cup meets the requirements 
    4.5  Whether the heat resistance of the water cup meets the requirements 
    4.6  When the cup falls , Whether it can be used normally 
    4.7  When the water cup is placed for a long time , Whether there will be leakage 
5. Safety test ：
 Mainly focus on the appearance of the water cup and whether toxic substances are released under various abnormal conditions 
    5.1  When the cup is full of hot water , Whether the water cup will be hot 
    5.2  When the cup is filled with water , Whether it will produce toxic substances 
    5.3  Put the water cup under zero , Whether it will produce toxic substances 
    5.4  Put the water cup in a high temperature environment , Whether it will produce toxic substances 
6. Interface （ The cup didn't think of how to associate with the interface ）
7. Compatibility test ：
 Mainly focus on whether the water cup can hold other liquids , If the juice 、 gasoline 、 Alcohol, etc 
8. Portability testing ：
 Mainly focus on the placement environment of the water cup, etc 
    6.1  Put the water cup in a normal temperature environment , Whether the use is normal 
    6.2  Put the water cup in a subzero environment , Whether the use is normal 
    6.3  Place the water cup in an environment higher than normal temperature , Whether the use is normal 

How to perform compatibility tests ？-web Compatible and app compatible

（1）Web  Compatibility test 
① Start with manual testing , Test engineers test mainstream browsers and common operating systems, test main process and main interface , See if there is a problem with the main process and the main interface , If there is a problem , So record  bug  situation , And browser model and version , And the operating system , Locate exactly  bug  Cause of occurrence , Submit  bug, Tell the developer to modify . All mainstream devices need to be tested , Only focus on the main process and the main boundary   Noodles , After all, there are not many main processes and interfaces in each system , So the workload is still tolerable .

（2）APP  Compatibility test 
①：APP  Compatibility testing and  Web  The test is similar , Start with manual testing , Test engineers use test equipment to test the main process and main function , Test the main interface ; Collect all the different types of test equipment that can be collected, test the main process and main interface , Look at the main process and main interface   Is there a problem , If there is a problem , Considering the utilization rate of equipment and other factors , See if you need to adjust , if necessary , So record  bug  Situation and test equipment model and operating system , Locate exactly  bug  Cause of occurrence , Submit  bug, Tell the developer to modify .

② Second, with the help of third-party testing tools , about  APP  Compatibility test for , Baidu public testing platform and cloud testing platform are recommended , I often use cloud measurement platform , These two testing tools include Android and  iOS  Test of ; The tests are complete , Including functional testing 、 Depth compatibility test 、 Performance testing 、 Network environment test , It can also simulate a large number of user tests ,, You can also import your own test cases for functional testing , It also includes tests by test experts , Of course, it costs money to find experts . Basic compatibility testing doesn't cost money ; The test engineer packed the  apk  perhaps  IPA  file , Upload to the test platform , Select the device model to be tested , Just start the task ; Wait for a while , You don't have to stare while you're waiting , You can do other jobs 
 do . A test report will be generated after the test is completed , You can view the error page and error log , If you need to adjust , So submit  bug, Tell the programmer to modify it .

Demand changes , What would you do with ？

 There are two situations 
1、 The corresponding modules of the requirements change have not been tested yet 
    1.1  Evaluate whether the man hours brought by the power module corresponding to the demand change are greater than the original test man hours of the module 
    1.2  If the test time of the original module is exceeded , The following points need to be considered to affect the test plan , See if it can be digested internally within the scope of the original plan ： Work overtime 、 Coordinate resources 、 Analyze whether some test time can be adjusted according to the existing tested modules 、 If all methods have been considered, feedback to the test leader or project manager for negotiation 
2、 The corresponding modules of the requirements change have been tested 

How often do version iterations ？ How to do regression testing ？

 It is generally divided into large version and small version , The large version is mainly a new function of product planning 、 new business , Minor versions are mainly some historical function optimization and defect repair versions .
 Large versions are generally 2-3 Once a month . Small versions are available every week .
1、 Defect regression ： Trigger the defect to see if the defect has been repaired ;
2、 Return of historical function ： Confirm the functional scope affected by this version iteration with the project manager and the developer , For the affected functional scope and core business processes 、 Key points , Select positive use cases for regression testing ; At the same time, use the idle time of version iteration , Realize the regression test of historical functions UI automation 

If you submit a defect, development doesn't think it is a defect. How will you deal with it ？

 Individuals in previous tests , This problem rarely occurs . Generally, I will confirm repeatedly before submitting defects , We will also try our best to ensure the efficiency and clarity of the defect amount .
 If this happens , First, I will find the corresponding Developer , Ask why the other party refuses or doesn't think it is a defect .
 If you find obvious problems in the description of the other party , And there is clear evidence that the situation will show the demand, and even reconfirm it on the spot .
 If there is no problem in the process of explaining and understanding , Or there is no clear error in the understanding of requirements , That proves that there is ambiguity in the understanding of requirements , Go directly to the product or project manager to confirm and reach a consensus .

There's not enough test time , The project must go online again , What would you do with ？

 There's not enough testing time here , There are many possible causes , If the quality of development or defect repair is not high , The test cannot be successfully executed .
 In addition, the change of demand leads to unreasonable plan control and so on , But whatever the reason , It is a fact that there is not enough objective time .

 Then I usually deal with it in the following ways :
 First, quickly count the remaining testing workload , Whether the problem can be solved by working overtime or coordinating resources , Ensure that the project goes online .
 Second, whether it can be based on the project , Current testing of each module , To adjust the assignment of the original test plan . If some modules have no major problems , Whether the risk is controllable . Reduce testing hours .
 Third, whether we can borrow the simple test tasks of the product and development sharing part 
 Fourth, whether there is an alternative online solution for the original complex business functions 
 Fifth, whether it can occupy part of the product acceptance time 
 Sixth, whether some functions can be cut 

How to ensure the coverage of test cases ？

1. Before writing test cases , Get familiar with the project first , See if there is a problem with the relevant requirements documents （ Unclear function description , Design logic defect ）, If you have any questions, ask relevant designers or developers .
2. Adopt the test case design method : Such as decision table 、 Equivalence class 、 The boundary value 、 Flow chart, etc 
3. Organize use case review , To check for omissions and make up for deficiencies 

Are there any serious problems in the production environment ？ If so, what are the ways to reduce the risk ？

1. In previous project testing experience , There have been no serious problems online for the time being .
2. If there are serious defects , I'll think about some questions , See if you can reduce the risk :
     First of all : First confirm the cause of the problem , If it is a code logic error , Prove missing test - Then we need to strengthen the test 、 Strengthen the review of test cases 
     second : If it's missing code , Submit after test , Strengthen the control of code sealing board , Before going online, you must synchronize the latest code , Test to confirm .
     Third : If the requirement implementation is wrong , Strengthen demand review .
     Fourth : Gray scale is adopted , First, the large version is only open to some users , Stable and then fully upgraded .

How many test environments do you have , What are the differences ？

 There were three test environments in the previous project , Test environment , Return to environment , Pre release environment .

 Test environment , That is, we test the working environment of our classmates , Generally, the test students will deploy themselves , Then test in this environment .bug After repair , You need to update the test environment to return to bug.

 Return to environment , Return to bug Environment , It's actually our test environment , Test on a test environment 、 Regression test bug.

 Pre release environment , Transition from test environment to production environment . The test environment may be limited , Some processes or data are not tested , It can be verified in the pre release environment , So as to ensure the on-line quality of products , Software test environment includes hardware environment and software environment ,

Have you ever deployed a test environment , Briefly describe how to deploy ？

 Check the server 》 Install middleware 》 Upload version package 》 Database initialization 》 Modify the configuration file 》 Restart the service 

 In previous projects , The application service architecture used by our system is :Linux+Nginx+Tomcat+Mysql.

 Before entering the test , The whole server architecture has been built in the development , Therefore, the corresponding middleware and tool environment do not need to be redeployed .
 At that time, I went to the deployment process , Mainly to update some new test versions . From git Get the source code of the development above to my local computer , And use the compilation and packaging commands provided by the development , Enter the path where the source code is located , perform mvn clean install You can get a deployable source package ,(TARGET)*****( You can name yourself , For example, call your project's English abbreviation ).war file .
 adopt SSH Remote connection tools MobaXterm Upload the source code to Linux Test server .
 Stop the test environment tomcat service , Back up the original test war package .
 Upload the just uploaded ***.war Move to tomcat The specified project deployment Directory webapps, Restart through tomcat/bin In the catalog startup.sh Start the server .
 Finally, go to the local machine to access the test domain name address , If the access is successful, the deployment is successful .
 In addition, I have learned jenkins Can perform continuous build deployment mode . If necessary, it can be used simply .

Fiddler What to do ？ How to analyze the captured data information is correct ？ If it's encrypted content, how do you handle it ？

1、 Analyze whether the defect is a front-end problem or a back-end problem .
 for example : Request address for order submission ：
①  The interface organizes the submission of order commodity data , Click on 【 place order 】, Trigger send request 
②  Background code for processing , After processing , Return order related data . The returned data is determined by the developer （ Demand to determine what data to return ） The order no. 、 Order amount 
 For example, the order amount displays an error in the interface , Grab and submit order response data , Check whether the total amount of the order in the interface return information is correct . If the total order amount in the interface is correct , It's the front-end problem , If the total order amount in the response message is wrong , It's the back-end problem .

2、 The front end makes corresponding restrictions on the input information , It doesn't mean that the back-end code is also limited , Each request address corresponds to IT People can directly skip the front page to operate . Verify whether the back-end has corresponding restrictions on abnormal input .

3、 Interface test tests the implementation of each request . The development of some companies did not prepare interface documents , You can get the specific interface address through the packet capture tool .

4、 Do the weak network test of mobile terminal 

Have you ever done a weak network test , Simply put ？

 First let the mobile phone and Fiddler Connect to the same network ;
 Then the mobile phone sets up an agent , proxy server IP For the computer IP, The port number is FIddler Default port for 8888, If it is HTTPS Agreed , Mobile phone needs to be installed Fiddler Certificate ;
 then Fiddler Enable the weak network related settings ,Rules->Performance-> Check  Simulate Modem Speeds, stay Rules—>Cutomize Rules Set upload and download parameters , Thus, weak network test can be carried out ;

Fiddler How to grab Apple mobile phone bag ？ Describe the process ？

 Based on Apple mobile phone capture :
1、 stay Fiddler In the configuration item, you need to set a tick to grab HTTPS, Automatic download HTTPS certificate 
2、 Open the network service listening port : Check Allow remote computers to connect, The port number can default to 8888
3、 open iphone browser , Enter in the address field http://ip( Computer ip):8888(fiddler The default port in ), Click on “FiddlerRoot certificate” Installation certificate 
4、 Set up iphone agent : Mobile connection wifi after , open wifi details , Slide to... At the bottom of the screen http agent , Click to enter and change to “ Manual ”, Set up ip（ Computer ip） And port (fiddler Medium 8888) After the certificate saving method is enabled ： Set up —— Universal —— About the machine —— Certificate trust settings 

Have you made a test plan ？ What does the test plan contain ？ Based on what to make the test plan ？

 In our project, the test plan mainly covers : Test range 、 Test resources 、 Task assignment 、 Stage task completion time node , Occasionally a risk assessment is added 、 Test environment and other related instructions .

 Generally, it will be based on the requirements document , Confirm the test point of the test scope , Disassemble the copy 、 Development plan document 、 product / The target launch time of the operation , And the current testing human resources , To make a test plan .

How does your company manage defects ？ What is the defect handling process ？

1. The tester finds and confirms the defect , Record defects in Zen , Assign it to the designated module developer . For example, the priority or defect level is relatively high , At the same time, the corresponding developers will be directly notified to repair as soon as possible .

2. Developers go to Zen to get defects , Analyze defects and deal with them . When the developer handles it and thinks it has been solved , You can set the status of this defect to : Repaired , And return it to the tester .

3. The tester enters the system to check the defects , And test and verify defects . If the defect still exists after retesting , The tester passes the defect back to the developer , And set the defect status to “ Reopen ”. If the tester confirms that the defect has been solved after retesting , Set the defect status to “ closed ”.

4. If the test manager receives a notice of rejection of a defect , Verify the defect , If it really cannot be counted as a defect , Close defects , Set the defect status to “ closed ”. If you think it is indeed a defect , Modify defect description , And reassign it to the development manager , And set the defect status to “ newly build ”.

How to evaluate the priority and severity of defects ？

 priority : It refers to the sequence of developing and repairing defects , Severity level : It refers to the severity of the impact of the found defects on the product quality 
（ It should be noted that , The development will make reference according to the priority , Determine the repair order . So high priority is not necessarily a fatal defect ）

 priority ：
     high （P1）： Serious defects , Affect the purpose of the test or product , Priority needs to be given to .
         Such as ： The copyright of the product has not been corrected 、 Technical incorrect content, etc . The application package version is incorrect 、 Failure to install results in failure to test 、 Flash back 、 Collapse, etc 
     in （P2）： Scenarios or features that are not so critical to the product .
         Such as ： Errors found in subtitles 、 Legacy from the historical version bug etc. .
     low （P3）： It doesn't have much impact on the use of the product .
         Such as ： Found in the low usage page bug、 Rarely used functions, etc . Words overlap 、 Typos, etc UI Defects in , Difficult to operate .

 Severity level ：
    A class - Fatal defect （Fatal）： Cause the system or application to crash 、 crash 、 Or cause data loss , Complete loss of main functions , This module and related modules are abnormal .
    B class - Serious defects （critical）： The main function of the system is lost 、 Data can't be saved . Such as fatal error statement , Program interface error and other constraints 
    C class - General defects （major）： The secondary function is not fully realized, but it does not affect the use . If the prompt information is not accurate , Or poor user interface , Operation time, etc ,
    D class - Minor defects （Minor）: Make the operator inconvenient , But it does not affect the operation and execution of the function , As wrong as a word 、 The interface is not standard 
    E class - Opinion optimization （Enhancemental）： The improvement suggestions of the problem proposer on the test object .

What are the standards for passing the version test ？

1、 The requirements in the requirements specification must be fully implemented and tested 
2、 Test case execution rate 100%
3、 No general 、 serious 、 Fatal grade defect 
4、 Communicating with the product or project manager about the remaining defects can delay the handling 

How will you deal with defects found in the production environment ？

⑴  In the company's defect management system （ Such as ： ZenTao ） Record the defect 
    1.bug Grade 
    2. Provide necessary screenshots and logs log Information (tail -200f log.txt)
⑵ bug Information positioning （ front end bug Or the back end bug,sql problem ？）——  Narrow the scope of the problem 
⑶  Reproduce in the test environment bug
    1. Can't emersion ： It may be caused by the version upgrade ,（ Contact operations 、 product ） Whether you need to go back to the last safe and stable version 
    2. It can be reproduced ： Call for development 、 product 、 Operation and maintenance estimate bug Solution time 
    3. The solution time is short ： Repair as soon as possible , Return as soon as possible , Verify online as soon as possible 
    4. It takes a long time to solve ： Contact the operation and maintenance department to go back to the last safe and stable version 
⑷ bug Analysis and summary 
    1. The test is not in place （ Update test cases ）
    2. Emergency change （ Strive for test resources to include test time ）
    3. Differences between software and hardware in the environment （ Add online regression test cases ）

In your project （ Based on your own project ） How many test cases are written in ？ How many defects are found ？

1 Projects around : In the last project, I wrote 1300 Multiple test cases , Among them, a total of 300 Left and right bug

How to evaluate the quality of a project or version ？ What are the criteria for launching the project ？

 From functionality 、 Ease of use 、 reliability 、 Compatibility 、 Maintainability 、 Portability , These dimensions determine the quality of software 

 Online standards 
(1)  All functions defined in the software requirements analysis specification have been implemented , All the performance indexes meet the requirements .
(2)  The errors found in the acceptance tests have been corrected , The repair rate of defects at all levels is up to the standard 
(3)  There is no residual emergency for all test items 、 Severity error .
(4)  Requirements analysis document 、 Design documentation and coding implementation are consistent .
(5)  The acceptance test pieces are complete （ test plan 、 The test case 、 Test log 、 Test notice 、 Test analysis report , Software installation procedure to be accepted .）

How do you perform the requirements review in your company ？ Have you raised any questions ？ What should testers pay attention to in the requirements review process ？

-  Before the meeting ,  First, specify the time to participate in the meeting , Location and personnel ,  And give notice ,  Development and testing need to be familiar with the requirements in advance , The mark is not clear ,  doubt ,  Suggested places ,  When waiting for the meeting ,  Improve meeting efficiency .
-  In the meeting ,  Raise questions and suggestions about the needs ,  And record the questions raised , To avoid omitting ,  Adopt modification suggestions as needed , Ensure that participants have a consistent understanding of requirements .  When there are many objections ,  Consider whether to solve it now or make an exception, and arrange a meeting to solve it .
-  After the meeting ,  The product modifies the requirements document according to the review opinions ,  Finally, a unified 、 Send out standard requirements documents for confirmation .  If the review fails , Then it may need to be revised for a second review , Ensure the integrity of requirements 、 accuracy 、 Understanding consistency .
-  To ensure the efficient conduct of the meeting , Pay attention to controlling the meeting time 、 Discussion focus, etc , So as not to delay the progress , Key problems cannot be effectively solved .

Occasionally in the test environment BUG, What would you do with ？

-  When bug When it appears , Grab log Or screenshots , The video leaves evidence 
-  Record the front environment , Operation steps , And used data ,  Try to reproduce bug
-  Analyze the severity of the problem , And the analysis and repair time of synchronous development , Test evaluation test duration . If the scope of influence is large and the repair time is long , It is recommended to rollback the code . Otherwise, directly repair, verify and republish 
-  If it cannot be reproduced ,  Then ask the developer to help reproduce ;  With the help of developers, it still fails to reproduce ,  Consider bug Definition of actual impact bug The severity level of ,  Whether it can be repaired later 

Test shift right and test shift left , Which technologies are used ？

 Moving left is more about making the test work ahead , At the same time, the technical requirements , And have a deeper understanding of the development service architecture , Such as interface testing technology 、 Unit testing technology ,
 At the same time, based on the quality system , The previous stage of the project should be controlled more deeply : Deep understanding of needs , Ensure high quality ,
 Development quality delivery also needs to be more stringent , Such as developing self-test 、 The output quality of the deliverables in the development process ： Interface document 、 Design document .
 If you move to the right, I think it can be UI Automation technology 、 Release risk control ( Grayscale online and test )、 Version differentiation check and other technologies .
 Whether it is left or right, it is to ensure the quality of the project , Based on personal words, now for *** More study time is invested .

Have you ever tested the backstage , Under the simple said ？

 Many students have encountered this problem , First, make a clear . Back end subsystem front end and business back end , And technical practice background ( In fact, it is the application server level ).
 To put it bluntly, what the interviewer wants to ask here is nothing more than the test of background service , That covers a wide range , Interface 、 performance 、 unit testing 、 database 、 cache 、 Test of search engine and so on , All belong to this category , Many people don't know how to answer this question , Actually extract two good or mastered contents from them to explain .

Sealing test 、 Internal measurement 、 Public survey

 Only technicians can test in terms of Technology ;
 Most of the participants in the internal test are game makers , Operators and businesses that produce and operate Games , And some ordinary players , The account number of ordinary players needs special application or invitation , And don't save id Data such as ;
 The public beta game is in the free stage , Most people can play   Unlimited accounts , Public beta generally does not delete numbers ; After the public test, the official operation will be charged