Fundamentals of software testing

The basic chapter

The life cycle of software testing
How to describe a bug
How to define bug The level of
bug Life cycle of
What to do if there is a dispute

The life cycle of software testing

1、 Demand analysis
2、 plan 【 Time , personnel , The direction and scope of the function 】
3、 Design 【 function , frame , Algorithm 】
4、 code
5、 test
6、 Operation and maintenance

1. Demand analysis ： Verify the correctness and rationality of the requirements , And at this stage, you can start to refine requirements , Prepare for writing test cases
2. plan ： Determine the number of people tested 、 Time 、 Environmental Science 、 Equipment, etc
3. Design / code ： Test design is to write test cases according to requirements
4. At this time, the development has been completed , Execute test case , Verification function ,
In the process of verifying the function , May come across The seven emotions that software functions do not conform to requirements , That is to say BUG 了 .
therefore , The tester will put this BUG hand Developer .
Wait until the developers have handled it , Our testers have to verify it .
5： Operation and maintenance ：
1、 How many test cases have been written , How many test cases were executed .
2、 The remaining test cases , Why not finish it .
 
3、BUG Number .
4、 Resolved BUG Number
5、 The legacy of the BUG, And Solutions .
 
6、 The scope and function of this test should be clearly stated

describe BUG

To show developers .
written words and oral describe , It's all there .
besides , also ZenTao ,jira,tapd.
 
But actually , We have a special BUG Management tools .
Inside this tool , It will bring BUG What needs to be described , It's very clear

Describe a BUG Several specific steps are needed :

Test version number

Test environment

Test data

The correctness of test data itself has a crucial impact on our test process , First If a correct data can't pass, it means there is BUG, If a wrong data can be logged in, it also indicates that it exists BUG, In this way, we can test faster through the test data

testing procedure

Pass the test step , Quickly find one BUG, Better be bug Find the location or specific information to communicate with developers

test result

Don't see the result , How do we know if the verified software function is correct ？
Take the expected results And The actual result Compare , If the match , Indicates that the software function has been realized , conversely , The software function implementation fails .
So developers know , Where does he need to pay attention

The attachment 、 Error log 、 Error screenshots and so on can help us locate and solve bu7、 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

BUG The level of ( understand )

commonly
The secondary function is not realized , Or something wrong , But it does not affect the system , The system can run stably
 
Suggest
This type of bug, It may not be written in the requirements . It will only affect the user experience .
such as ：
1、 The interface layout is very frustrating , Not in line with the public's aesthetic 、
2、 The displayed information is not wrapped

BUG Life cycle of

Simply speaking ：BUG Life cycle of Namely BUG Of Various living conditions .
● 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

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 ：
The tester is responsible for each BUG A new version containing the changed code must be taken for regression testing , Make sure the same problem doesn't happen again , To close the defect .
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 and Developer conflicts , How to deal with ？- Interview questions

1、 Check , See what you think of BUG Is your description clear
 
2、 Convince developers from a user perspective
Developers should be made aware of Bug Possible troubles to users , In this way, developers can
More actively 、 Modify with high quality Bug.
Because sometimes , Really some bug It can be changed but not changed .
But it was changed , The user experience will be very good .
and , There are some bug The reason is because It is not clearly described in the requirements document ！
although The software requirements yes The user needs Further refinement of , But sometimes , The product manager is not very considerate .
Or to say , What to do without a product manager ？
Let's take an example
3、BUG The grading should be justified 【 According to the company's specifications 】
If you just feel this BUG Very serious , Developers must not do it ！
He works for the company , Not for you .
 
4、 Keep improving Their own Business level , and Technical level .
Not only can we find BUG, And be able to locate .
Can also propose solutions
【 These abilities , Work for a long time , Nature also has 】
 
5、 When developers don't accept , Don't quarrel ,
Maybe you've had several rounds of communication , But developers still refuse to accept . At this point, you can initiate Bug review .
Talk to the product manager about , A tripartite meeting will be held later 、
Testers , Developer , Product managers will discuss this together bug The ultimate solution .

QQ Login test cases