Function test process in software testing

　　 Function testing process in software testing

　　1. test plan , It mainly gives some guidelines for the following testing work , It can't be written into a plan for leaders to see , But write a plan that is seen by the people who do it

　　 It may contain ：

　　i. Test team personnel and division of labor ( To determine when a defect occurs during testing 、 When testing environment preparation and other problems, you can find the designated personnel )

　　ii. Test start and end time ( Ideally , Don't make too tight arrangements , Rush will certainly result in delay or incomplete testing , Unfortunately, the gap between ideal and reality is stipulated to be very large )

　　iii. Test environment configuration ( What kind of hardware conditions , Whether the network 、 Equipment etc. , At what address does the system access , Access right 、 Prediction and preparation of test data used )

　　iv. Test what to say clearly , Here I suggest that a simple test outline be included in the test plan , On the one hand, leaders can see how detailed your plan is , On the other hand, the outline can be a good basis for writing use cases

　　v. How to test should be clear , If you only do system testing , Then it is necessary to write clearly, do not do integration testing , If integration testing is required , You need to write clearly the integration order . In addition, if performance evaluation is required 、 file 、 Other tests should also be written in this plan , Although this plan is generally aimed at functional testing , But if there are other tests , Also write it down and schedule it , Relevant plans for corresponding tests shall also be indicated

　　vi. After the test ( Explain to what extent the test can be ended , You can't wait until you find all the defects , Because it will be ten thousand years ), Allow defects to remain in the system , We just need to find out how much this degree is left

　　

　　

　　2. The test case ： This document , It mainly describes the specific test steps , But in practice , At least for now in my project , Because of time , Few write , Even if it's written , It's basically not used in the test , Most of the projects here are measured directly , It's all based on my personal experience ( I would like to thank the leaders for their trust in my erbaodao Technology [email protected]_). But I want to say that in fact, he is very important , Maybe you don't need to write in detail , But it is absolutely necessary to straighten out the thinking through such steps , The quality and practicality of this document , It directly determines whether you can “ With the least amount of work ( Quantity and time ), Find as many defects as possible as soon as possible ”, Writing this document requires some test methods and theories , Such as equivalence class division 、 The boundary value 、 This watch, that watch .

　　3. Defect record ： It is the most frequently used document in the process of functional testing , Used to record defects found during testing , And the developer shall take it as the basis for modifying defects , And the main basis for the modified tester to carry out the back test

　　a) Of course, this article is also helpful to analyze the existing problems of developers “ Error cluster ” The phenomenon , Summarize the error prone areas , Do more in-depth testing on the parts with many defects , And remind developers to avoid defects

　　b) Guidelines for filling in defect records ：

　　i. Defect level ( That is, the severity ), Generally defined by the company , Classify the defects found , In order to determine the priority of modification

　　ii. bug classification ： Distinguish where it happens , It's functional , Or performance , It's about effectiveness Or other problems , And bug Together , Used to decide bug Modification requirements for |

　　iii. bug state ： It's a sign bug The current situation of , Identify whether it has been disposed of ( The closed position ),

　　iv. These indicators are generally uniformly defined by the company ( The general standards are similar ), It will also be used for project measurement

　　c) Precautions when using defect records ：

　　i. describe bug There are three elements ： Where is the , What circumstance ( Premise ) Next , What kind of problem happened

　　ii. You can use screenshots 、 Reference location 、 Modules, etc bug, The purpose is to enable developers to reproduce immediately through your description bug, Even if it can't reproduce , It can also let developers know where the error is

　　iii. The defect report should be completed by developers and testers , The tester shall urge the developer to fill in the form so as to test the subsequent back test work

　　iv. If it is filled in while executing the use case bug The report , The last column of the use case can generally fill in the execution result of the use case , If the use case has unexpected results , Then record the problem in the defect record , In this case, the number of the use case can be referenced in the defect record

　　4. Test summary report ： It is used to report and summarize the execution results of project test work , List and count relevant test data , Compare and analyze the data, that is, the problems existing in the work, and give tips for the follow-up work , And record the remaining problems

　　a) Another function of the summary report is to tell the members of the project team that the system has been tested according to the requirements of the test plan , And has reached the... Specified in the test plan “ Test end condition ”, It can be proved that the system has reached the quality expected by the test plan

　　 This test summary needs to record the results of all tests of the project , In addition to functional testing , Performance tests will also be included

　　 For more information on testing techniques, please pay attention to ： Shenzhen duosurveyor software and Technical Service Co., Ltd