After reading this article, I found that my test cases were written in garbage

Test case writing is the most basic ability of test skills , Everyone should have more or less their own habits and ways of thinking about writing use cases , Here we share some experience in requirements analysis and writing use cases , Mainly for functional testing , Aimed at Minimize the possibility of test omission , And for new students , Hope to achieve the effect of getting started . Finally, I will share a gadget , When sorting out some complex business requirements , Can assist in rapid analysis .

01、 How to disassemble requirements

The proposal of a requirement must be accompanied by the expectation of the optimization of the existing system , Generally speaking, there are these types ：

• New functions to meet the needs of business development

• Function optimization , It aims to improve the existing deficiencies and details that affect business development

• Meet regulatory policies

• System level optimization , It does not involve the business level , May be SQL Optimize 、 Code refactoring and so on

• Online problem

• Interface , Including those provided by other systems and those provided by itself to other systems

• Timing task , Asynchronous task

For different types of requirements , Our coping styles will also be different , Each of the following points will be explained one by one based on these types .

1、 New function

Generally speaking , Such functions will try to avoid affecting the original functions , Therefore, the correlation influence coefficient is the lowest among several types , The following ideas can be followed for disassembly ：

• Understand the background of requirements , Quickly browse the requirements , Sort out the included menus 、 modular 、 Pages and page controls ;

• Clarify business logic and data entry control ;

• Roughly divide test cases according to the characteristics of requirements / Test specifications of test points , Generally, there may be these kinds ： technological process 、 page / Control operation 、 Data presentation 、 Calculation logic 、 Ease of use 、 Compatibility, etc .

2、 Function optimization

The correlation influence coefficient of such functions is high , In addition to analyzing from the demand level , Development design is also the key to assist test case design .

• Understand the background of requirements , Clarify the optimization points ;

• The test is based on your understanding of the system , Or system documents and other materials , Preliminarily compare the differences before and after the change , And list ;

• Communicate with developers to develop design ideas , Understand the code 、 Change points at the database level , Evaluate possible impact points , And list ;

• According to the above test focus , Divide test characteristics .

3、 Meet regulatory policies

Such needs are generally urgent , The probability may be a function point such as uploading data or logic control , When analyzing requirements Focus on data validation .

• Understand the background of requirements , Clarify the optimization points ;

• List data types according to requirements 、 Regulatory control trigger time point, etc ;

• Analyze yourself , Or whether there is any connection with the development communication , If it exists, follow “ Function optimization ” Class requirements continue to be analyzed ;

• According to the above test focus , Divide test characteristics .

4、 System level optimization

Such requirements are proposed by the development , Generally, in order to improve the efficiency of code execution 、 Improve code reusability 、 Reduce code complexity, etc , Will have a related impact on existing functions .

• Communicate with the developer about the optimization plan , A certain Understand the cause and effect of modification , There are any unclear concepts to break the casserole and ask the end , Because any doubt point may affect the subsequent use case design ;

• Confirm the verification method , It may traverse through page functions 、SQL Execution efficiency 、 Page response time, etc ;

• according to 1） Analyze the optimized functions , It is simply an improvement in efficiency , It also affects the implementation of the original function , If it is the latter , You may need to traverse this function , according to “ New function ” Class requirements continue to be analyzed ;

• According to the above test focus , Divide test characteristics .

5、 Online problem

Online questions can be roughly divided into emergency and commonly Two levels

①  The emergency level has blocked the business , Data modification is required 、 Configuration modification 、 A small number of code modifications were launched on the same day

②  The general level is that there is no blocking effect on the business for the time being , And the specific reasons may not have been analyzed , It will not be repaired on the same day .

• Quickly find the problem and understand the phenomenon and operation steps , And reproduce it in the test environment ;

• If it can be reproduced and caused by the recent online function , It is necessary to first analyze the causes of test omission , If it is a historical problem , You need to understand the reason why this problem is triggered and the analysis results of the development code ; If it cannot be reproduced , It is most likely to be the problem of configuration and data , Non test omission ;

• If code changes are made, fix , According to “ Function optimization ” Class requirements continue to be analyzed , Generally, there are few code changes , But in this case, the test time may be very little , It is necessary to accurately locate the code change point and narrow the test scope .

6、 Interface

This type is general More emphasis on the verification of data combination , The test proportion on the interface is low , Therefore, the division of test specifications will be more formatted .

• Understand the background of requirements , Clarify the optimization points ;

• List the combination of input and output parameters according to the interface document ;

• Determine the frequency of interface calls , If the frequency is high, there may be other potential testing needs ;

• Determine whether the data is landing （ Stored in the local database ）, if , You need to list the landing fields and data processing methods , If inserted 、 to update 、 The respective processing methods in the case of deletion ;

• Determine whether the data is used for page presentation , if , You need to list the fields and forms of display ;

• Determine whether the interface is used to trigger the entry of another function , if , You need to enumerate the interface call points , And enumerate the relationship between interface data and another function ;

• According to the above test focus , Divide test characteristics .

7、 Timing task / Asynchronous task

This kind is a little similar to the interface , Generally, it does not exist in the requirements document , It's a way to realize requirements when developing and designing . Usually deal with a large number of data , And the call frequency is not as high as that of the interface , These two tasks are generally In order to reduce the burden of the system processing data in real time

• Understand the data flow during task processing , Is there an intermediate table , And data landing

• Task trigger time

• State write back and retry mechanism

02、 How to combine test points and data

Understand the requirement type and write down the test specification 、 After the test point , It needs to be further refined into test cases , At this time, you may use many methods that you have heard , such as Equivalence class 、 The boundary value 、 outliers 、 Combine wait . You should find out , These methods are actually to help filter data , A means to control the number of use cases within a reasonable range . In a quick iteration of a version , Test time is precious , We are unlikely to design test cases for full coverage indefinitely , Therefore, we need to effectively combine test points and data , Convert a large test set into a smaller test set .

Take the most common user login system as an example ：

1、 For login operations

• Test features Yes ： User name input , Password input , Sign in

• Test data Yes ：

  Existing users , Users who don't exist , Users with special characters ;

  Password matching the user ,

  Passwords that do not match the user , Password containing special characters .

  Login as the trigger point for the expected result

• Value Yes ： Login successful , Username or password incorrect .

2、 The first step is to sort out the test characteristics and data , If full combination , There will be 18 Test cases , This function only considers the function test , There are too many such use cases . Imagine adding an input field , The number of use cases will multiply , In daily testing, the functional logic is more complex than this example in most cases , At this time, we need to simplify , Achieve as much test coverage as possible with the least use cases .

3、 First of all, we can find that there is Some combinations are invalid use cases , such as “ Users who don't exist , Passwords that do not match the user , Login successful ” This is invalid ; second , Some combinations can be divided into equivalence classes , That is, although the characteristic values are different , But the purpose of the test is the same , such as “ Users who don't exist , Passwords that do not match the user , Incorrect user or password ”、“ Users who don't exist , Password matching the user , Incorrect user or password ”, In fact, the purpose is to test the situation that users do not exist , Use case simplification can be carried out .

4、 thus , We can get a reasonable test case document , But here's the thing , While we simplify use cases , The coverage of the test path must be ensured , The change points involved must be tested , The above simplification process only cuts the part that has been tested repeatedly on the change point .

03、 Determine the test method

After the test case is determined , There is another important part , Determination of test methods , Including execution methods and data preparation . In daily tests , The more common method is to conduct manual testing , But in some cases , It is quite time-consuming to execute the samples through manual testing , In the process of rapid iteration , It will affect the test progress . In the execution phase , More commonly used are ： The interface test 、 White box testing 、 Database script etc. .

1、 Interface testing applies to requirements clearly defined as interfaces , And provides exposure to the outside service service , It is especially suitable for test cases with many combinations , Simple manual testing may involve long-term joint commissioning of related systems 、 Page flow traversal , And cover through interface testing , You can traverse these use case combinations in a short time , Quickly discover logical BUG, Finally, only in the joint commissioning 、 A few use cases can be executed in the page testing phase .

2、 White box testing is generally used in many development links , But in fast iteration projects , Often, the development of background logical methods is completed , But the page has not been developed yet , The use case cannot be executed from the interface , At this time, you need to use the white box test . The idea of interface testing is similar , But in this case, there is generally no exposure to the outside service service , Cannot call from the periphery , You need to write unit test calls into the project code . The rest is the same as the interface test .

3、 Database scripts are generally used in batch data preparation 、 Data batch modification , Quickly prepare test data . Understanding data flow and relationships is the basis for using this method , Simulate the trend of data in the system through database scripts , Output the data needed for the test . Interface testing can also achieve this goal in some cases .

04、PICT Combined case generation tool

PICT Can effectively follow Test in pairs Principle , Design test cases · In the use of PICT when , All parameters related to the test case need to be entered , To achieve the effect of quickly generating use cases , It can help us complete the work in the second major point , Greatly improve efficiency . But the use cases generated by tools are not completely reliable , Labor is needed review Check whether there are invalid use cases .

---

Learning resource sharing

Finally, thank everyone who reads my article carefully , Watching the rise and attention of fans all the way , Reciprocity is always necessary , Although it's not very valuable , If you can use it, you can take it

These materials , For doing 【 software test 】 For our friends, it should be the most comprehensive and complete war preparation warehouse , This warehouse also accompanied me through the most difficult journey , I hope it can help you ！ Everything should be done as soon as possible , Especially in the technology industry , We must improve our technical skills . I hope that's helpful …….

If you don't want to experience it again, you can't find information when you study on your own , No one answers the question , If you insist on giving up after a few days , You can add mine below qq Group discussion and Exchange , There are also various software testing materials and technical exchanges .