How testers write functional test cases

        

Catalog

1 Select tool

2 Design principles

Principle one ： Heavy logic , Tap

Principle two ： Source first

Principle three ： Avoid using use cases as base requirements

Principle four ： Standing on the user's side does not mean giving up business

Principle 5 ： Test point is not equal to test step

Principle six ： Where to come from , Remember to come back

Principle seven ： The types of tests should not be confused

Principle eight ： Use case design is also formatted

3 Summary

---

         If you are a newcomer to the testing industry , The first thing is to learn to write test cases , Test cases include functional use cases 、 Interface use cases, etc , Today, let's focus on functional use cases .

1 Select tool

         The tools most companies use to write functional use cases are xmind, It is a mind mapping tool , It's more convenient to use , There are many shortcut keys to use , Than traditional excel More concise , I recommend you to use xmind8, It's free. , Others are charged , Download address ：XMind download

2 Design principles

         The use case design principle is high coverage ,90% It covers the scenarios that may be involved in the business , The rest 10% It is added during the test , The reason why we can't reach 100%, Because even if we are familiar with and understand the business well enough , It's hard to think of a comprehensive .

Principle one ： Heavy logic , Tap

         Many testers write use cases , First of all, write everything you can on the page , What effect does this dot achieve , What effect does that little bit achieve , Finally, let's look at UI, Here we need to align , The picture can't be blurred , So the use case is designed , Obviously not possible , Lack of scenario testing , The more scenes are covered , produce bug The less likely it is . We take a module that we often get “ Shopping cart page ” For example , The shopping cart includes ： List of goods 、 payment , It is divided into this 2 A module , Let's take a look at the comparison of two use case designs ：

Point and click use cases
​

Scenario based use cases

         I simply listed , Welcome to add ～

         From the above two figures , We can see that , The use cases with obvious scenarios are clearer , More comprehensive , Focus on business logic , Think of scenarios that are relevant to the current test point , We all need to think about , It's not just a click operation .

Principle two ： Source first

         What is the source , We can use data sources as sources , You can also use the entrance as a source , To put it simply , The module you tested has several entries , Where did the data come from , Let's continue to use the above shopping cart to write use cases ：

          As shown in the figure , Think about where the data comes from , Put it first in use case design , The first thing to think about is how to deal with data , Where does the data of these pages come from .

Principle three ： Avoid using use cases as base requirements

         Several interns I have taken , When they start writing use cases , When the first edition was sent to me , It looks like a lot of words at a glance ,xmind There are many, many lines on , The layman seems to think this child paper is good , Very serious , The demand is also comprehensive , An expert looks at , This is not a test case , This is writing requirements , Write the product requirements in three sentences into three use cases , Some even copy the text of the requirements document , This is not called a test case , This is called base demand . Test cases write test points one by one , The test points are scenarios , To put it simply, you need to test what points in the business . for instance , Let's compare ：

         Batch export , This is what the requirements document says ： You can export the data within the current search range , Support real-time export excel Formatted data , The exported data fields include ： The order number 、 Exchange code ......

Demand based use cases

  

Test pointwise use cases

 

          Compare the above two use cases , The obvious difference is that in the first edition, the requirements are split , Changed the presentation format , In the second edition, the requirements are split , What points need to be tested , This makes it much clearer .

Principle four ： Standing on the user's side does not mean giving up business

         The test session has a sentence that is familiar to my heart ： The test should be conducted from the perspective of users . There is nothing wrong with this sentence , It also inspired many testers , It also harmed many testers . The intern I brought , Many of them told me that I should think from the perspective of users , In this way, how do I feel about users , Whenever this time I ask ： How many users can you stand on ？ Most of the time , From the user's point of view , In fact, it is based on personal usage habits , Your usage may represent 1000 Users , even to the extent that 10000 Users , But you don't represent millions of users , We also don't have the energy and ability to really think about the perspective of these users , Therefore, from the perspective of users, it is not equal to considering users , We should start from the business , Consider its rationality and complexity , For example, a jump can pay , Let the user jump to the settlement desk page three times , It's obviously unreasonable , In the use case design process, we will also encounter such inappropriate requirements , There may be a better way to implement it , It can also be provided to the product through experience suggestions , This is the real user perspective .

Principle 5 ： Test point is not equal to test step

         Especially in xmind When writing on , Don't talk about a test point in many lines , It must be one test point per line , Hold at most 3 Column left and right , Not more than 5 Column . Remember to use xmind The aim is to be portable 、 distinct , Not writing test steps , Is writing a test point , As a test role , What points need to be considered , If you want to write test steps , There is no need to write on it , Maybe “ ZenTao ” More appropriate , And we are not allowed to spend so much time on the steps , It is reflected in the coverage rate . Take the shopping cart as an example , Edit the shopping cart list ：

Step by step use cases

Test pointwise use cases
 

Principle six ： Where to come from , Remember to come back

         This principle is quite familiar to us , Everyone who enters the test class should understand this truth , Just like monk Tang took scriptures from the West , Explain where you came from and where you went , But unlike Tang Monk , Remember to go back to the origin , Never go too far , Forget the original intention . In professional terms , To form a use case closed loop .

         Take the shopping cart as an example , After knowing the source of the use case , You know where you came from , So where to go , Is to enter the payment link , Jump to the settlement desk , Payment to order page, etc , After these operations are verified , To return to the shopping cart page , Then there are test points at this time ： Pay for successful items to be emptied from the shopping cart, etc , This forms a closed-loop link , It will not be missed .

Principle seven ： The types of tests should not be confused

         Functional test cases focus on business , When many people can't say which points to test , Just test the performance 、 Load tests and so on are also added together , Especially during the interview , This is not to say that these are not functional tests , Just different test types . Many companies , Especially big companies , Performance testing is performed as a single testing strategy , It will not be put in the functional test alone , Whether it is the popular link pressure test or the manual execution of the pressure test script , All are executed on the basis of stable function realization , So try not to confuse .

Principle eight ： Use case design is also formatted

         Write in the following format , Can guarantee 90% No problem , Try to write ：

3 Summary

The use case design is written here , Let me summarize ：

1. Use case design is the main play of testers
2. The design principle never changes , Find the one that suits you according to your personal habits
3. Tools are not the point , Use case format should be mastered

Next, I will introduce the implementation principles of use case review and use case implementation in detail , Gradually guarantee product quality from different stages .