Software testing - Fundamentals

Review the last blog : software test - Concept

One : What is demand ?
It can meet the user's expectations or the documents stipulated in the contract ( standard , standard , contract ) Conditions and permissions required , Including user requirements and software requirements
The user needs :
This requirement is rough , Direct implementation will be difficult , Because he has no details , Generally, he has the demand put forward by Party A , Software requirements are required to implement and standardize the details of user requirements , Turn user requirements into a concrete and realizable process document
The software requirements :
It is converted from user requirements , It is the refinement of user requirements , Enable the specific implementation details and specifications of user requirements
Two : What is? BUG?
1: If and only if Software requirements exist and are reasonable , If the software function does not conform to the software requirements specification , It's a software error (BUG)
2: If the software requirements specification ( Software requirements document ) non-existent , User needs exist and are reasonable , If the user requirements do not conform to the software functions , Let's say it's a software error (BUG)
3、 ... and : What is a test case ?
A set of collections initiated to the system under test , This set of collections contains Test environment , Test data , testing procedure , Expected results ( Remember these four ), There are also functional modules to be tested , Priority, etc …
Four : The life cycle of software development ?
Software life cycle refers to the time from the assumption of software products to the end when software is no longer used . If you think of software as a living thing , Then the software life cycle can be divided into 6 Stages , namely Demand analysis 、 plan 、 Design 、 code 、 test 、 Operation and maintenance .
5、 ... and : Software development 5 Big model ?
1: Waterfall model
The problems in the early stage of the project will not be found until later , It is suitable for projects with stable demand
2: Spiral model
Strong anti risk ability , It is applicable to large projects , High risk projects
3、4： The incremental 、 Iterative model
Strong anti risk ability
5: Agile model
Light document , Light process , Heavy target , Re output , Embrace change ( Able to adapt to changes in demand )
6、 ... and : Two models of software testing ?
1:V Model
Strong stage independence , The early demand analysis and design stage correspond to the later test stage one by one , Every stage of the early stage , It is the basis of each test stage in the later stage , The problems in the early stage will not be found until the later project test , Cause the problem to lose the opportunity to correct in time
2:W Model
Also called Double V Model ( Every stage of development V, Each stage of the test V) Early test intervention , Intervene in the demand phase , The downside is the serial process , Unable to adapt to changes in demand , Agile models are not supported

1: The life cycle of software testing

You may also be asked what the software testing process is ?
Demand analysis --> test plan --> Test design / Test Development --> The test execution --> Test evaluation

Demand analysis :
Analyze the correctness of requirements , rationality ; Refine requirements , Find the test item , Write test cases
test plan :
Consider the number of people tested , Test environment , Test time , Test equipment, etc
Test design / Test Development :
Write test cases according to requirements
The test execution :
Development has been completed here ; We are going to execute test cases , Verify whether the function is perfect , Yes BUG Just submit BUG, verification BUG
Test evaluation :
How many test cases have been written , How many , How many test cases are left , How many? BUG Number , Solved BUG Number , The legacy of the BUG And Solutions , Test scope and test function, etc

2: How to describe a BUG

Our testers just want to find out BUG Communicate with developers to solve the problem BUG, So how can we clearly describe a BUG It's important

1: Problem version found
Developers need to know which version of the problem is , To get the corresponding version of the code to reproduce the fault . And the version identification is also conducive to statistics and analysis of the quality of each version
2: Test environment
Environment is divided into hardware environment and software environment
If it is web project , Software devices : The operating system needs to be described , Browser version ( Which browser ,IE, firefox ,Chrome,edge,Safari, quarks , Sogou etc. ) etc. , Hardware device : Client operating system , The computer version , Model, etc
If it is app project , Software devices : Need to describe the system ( Android ,IOS, Hongmeng , Saipan et al ), System version number, etc , Hardware device : Need to describe the model 、 The resolution of the 、 Operating system version, etc . Detailed environment description is conducive to fault location .
3: Test data
Through the test data, developers can repair problems more quickly
4: testing procedure
At which step of the operation BUG, Let the developers see it and then solve it
5: Test the actual results and expected results
Compare the final actual results with the expected results , Find out what should be achieved but not achieved , Solve
6: The attachment , Error log , Error screenshots and so on
Through the exchange of information to developers so that faster solutions BUG
7: other
Some companies have other requirements , For example, the classification of faults ： Functional failure , Interface failure , Compatibility failure, etc . There are priority categories , Those that seriously affect the test and need to be modified by developers first , You can set the priority to high .
8: Don't put more than one BUG Put it together
When the fault caused by the same code cannot be confirmed , Don't put bug Put them together and submit …
wait , In short, it is necessary to describe clearly to the developers BUG Can be solved more quickly BUG

3: How to define BUG The level of ( Every company is different , Understanding can )

1: collapse (Blocker)
Problems that hinder development or testing ; Cause system crash 、 crash 、 Dead cycle , Cause database data loss , Connection error with database , Loss of primary function , Problems such as missing basic modules . Such as ： Code error 、 Dead cycle 、 Database deadlock 、 Important first level menu functions cannot be used, etc （ This problem rarely occurs , Once this happens online , The current version should be aborted immediately , Back to a stable version ）.

2: serious (Critical)
Loss of main functions of the system 、 Database save call error 、 Loss of user data , The first level function menu cannot be used, but it does not affect the test of other functions . The functional design is seriously inconsistent with the requirements , The module cannot start or call , Program restart 、 Automatically quit , Call conflict between associated programs , safety problem 、 Stability, etc . Such as ： After the data in the software is saved, an error is displayed in the database , The function required by the user is missing , Program interface error , Numerical calculation, statistical error, etc （ If this level problem occurs, you can continue the version test without affecting other functional tests ）.

3: commonly (Major)
The function is not fully realized, but it does not affect the use , There are defects in the function menu, but it will not affect the stability of the system . Such as ： Long operation time 、 Long query time 、 Format error 、 Boundary conditions are wrong , Delete no confirmation box 、 There are too many fields in the database table ( This problem exists most in the actual test ）

4: secondary (Minor)
Interface 、 Performance defects , Suggestion questions , It does not affect the execution of operation functions , Schemes that can optimize performance, etc . Such as ： Wrongly written characters 、 The interface format is not standard , Show overlapping pages 、 What should not be displayed should be hidden , Unclear description , Prompt missing , The words are not arranged in order , Incorrect cursor position , The user experience is not good , Schemes that can optimize performance, etc （ There are many such problems at the beginning of the test , Low priority ; There are fewer problems later in the test , Should be handled in a timely manner ）

4: BUG Life cycle of

From description BUG Then to solve BUG, Every company , Every tool pair bug The definition of life cycle is different ,( The figure below is for reference only )

● New: Newly discovered Bug, Decide whether to assign developers to modify without review .
● Open： Confirmation is Bug, And think it needs to be modified , Assign to the appropriate Developer .
● Fixed: After the developer makes the modification, it is marked as the modification status , To be verified by the regression test of the tester .
● Rejected： If not Bug, Refuse to modify .
● Delay: If you think it doesn't need to be modified or can't be modified for the time being , Modify later .
● Closed： Modify the state of Bug It is verified by the regression test bin of the tester , Then close Bug.
● Reopen： If verified Bug There is still , You need to reopen Bug, Developers re modify .
invalid bug：open->closed, open-rejected-closed

The defect status change process may differ from the actual practice of each project team . And it needs to be used in combination with the actual development process and collaborative process .

for example , The tester found something new Bug, It must be reviewed by the test team leader before deciding whether to Open And assign it to developers . Testers Open Of Bug Can be assigned directly to Bug The person in charge of the corresponding program module , It can also be required to submit them to the development director first , After being reviewed by the development director, it is decided whether to assign it to developers for modification . Bug There are some basic principles that should be followed for tracking and status changes ：

1: For each defect modification, the tester must take a new version containing the changed code for regression testing , Make sure the same problem doesn't happen again , To close the defect .
2: For rejected and delayed modifications Bug, It needs to be passed, including tester representatives and developer representatives 、 Representatives of users （ Or someone who represents the user's perspective ） Review of .

If because BUG What if there is a conflict with developers — How to solve ?

1: Check , See if it's your problem , Is it right? BUG Didn't describe it clearly

2: Convince developers from a user perspective
for example : The demand requires that you can upload pictures as avatars , But no format is defined . Developers are limited to uploading only png Format . Consider it from the perspective of users ：png,jpg That format is more ？ Do you want the user to convert the format and then upload ？
Or upload pictures , When choosing 1.png,2.png,2-2.png Click a delete button , The effect is that all three are deleted , The user only wants to delete one …

3:BUG The grading should be justified ( According to the company's specifications )
BUG When grading , Not only reference BUG Level , Also need to consider BUG Whether it will affect the process , Often the user's BUG The level is different from ours , The positioning level needs to be considered from the perspective of users .( Don't be serious if you think it is serious , If it's not serious, it's not serious )

4: Continuously improve their business and technical level
We can not only find BUG, And it can also locate , Can also propose solutions , This will make people more convinced , So as to improve their authority

5: Don't quarrel , Talk to the product manager
Maybe you've had several rounds of communication , But developers still refuse to accept . At this point, you can initiate Bug review . Through tripartite meetings ( Testers , Developer , The product manager ) Will discuss this BUG The ultimate solution