[software testing] how to sort out your testing business

In daily testing work , I wonder if you will have the habit of combing your own test business . Personally, I think it's worth doing , It's best to cultivate a habit .

One 、 Why comb the business ？

Because in business testing , As a tester , It is very important to be familiar with the business you are responsible for , And through phased combing and summary , It can make your business knowledge precipitate systematically .

When asked about the test focus of this business system ？ How to overcome difficulties ？ Why design like this and so on , It can output in an orderly way .

Or, , When your task needs to be handed over , Or need someone to support your business , You can confidently throw the document away , Pat your chest and say ： Look at it once and you'll know .

Similarly, we usually do business , Similarly, there is not much output from other technical layers , That's why someone can take A, Someone can only take C One of the reasons .

in addition , When you have a variety of business precipitation , You can even extract a lot of commonality , Let's call it “ methodology ” Well .

Two 、 Sort out the framework

There are so many advantages , How to sort it out ？ Here I refer to the conventional service system , Write some ideas ( frame ), For reference only .

1. Test scenarios

This part can sort out the test scenarios of the business system .

You can highlight the core test scenarios , With a full number of test cases . If the use case has subsequent iterations , It can also be classified according to time and content , Put it here .

2. Business

Here you can sort out more business segments . such as ：

1) A variety of configurations

Various background configurations involved in business 、 Backstage address 、 Configure the scope of influence 、 Must or must not be configured 、 Configuration order 、 Special precautions, etc .

2) front end

What are the front-end functions of the product involved 、 Important links 、 The main front-end interaction and so on .

3) The core processes

Sort out the core business processes , It can include the operation process for users , And the corresponding interactive interface .

in addition , You can draw the core business flow chart by hand , General products will give , But I have time to draw a picture myself , One more time in my mind, more profound , There may be surprises to supplement the test design .

Another key point is the processing process of business data , If it involves other things like kafka、es、 Cache and other middleware , The details of data processing can also be sorted out .

4) Troubleshoot problems

In the test work, we will encounter miscellaneous problems , Draw out some typical questions , Record the troubleshooting methods and possible factors , Convenient for yourself and others to view .

3. System

The business layer has sorted out , It's time to focus on the application service layer .

1) Application sites

You can go down from the entrance , Sort out the sites under the business system , The service name 、 Function and other information .

2) Interface and log

Here you can summarize the interface documents , Classify according to different situations , Anyway, the purpose is to efficiently view the corresponding documents .

How to view the critical logs during the testing process is also important , Understanding interface interaction , Troubleshooting is very helpful . Different processes can be recorded here , Sites involved , If you filter logs and other information .

3)MQ news

Record the interaction MQ What are they? ,topic、 Different tag What is the role of 、 Message body, etc .

4) Exception mechanism

Record the exception handling mechanism of the system , Common, such as timeout 、 retry 、 compensate 、 Get the bottom and so on .

4. data

To the data layer , I can't open it mysql 、 cache 、mongoDB wait .

Sort out the database names , What to deal with , Core tables and key fields , For example, some order types 、 Status and so on .

redis these nosql database , Sort out the important key、field、value wait .

5. Security

For example, the authentication mechanism of the interface , Some details of the interface involving more complex encryption processing .

There are also some concurrent operation class controls that can be sorted out .

6. performance

It is usually the performance of single interface and link scenarios .

1) Interface performance

such as ： The most intuitive interface for front-end user experience 、 Create a single interface 、 Detail interface 、 Preprocessing interface, etc .

2) Link performance

The core link scenario , String together for pressure measurement .

3) Current limiting

If the current limiting scenario is involved , The factors considering current limiting can be further sorted out , Trigger mechanism , Means of treatment, etc .

7. Data analysis

The data is diverse , For example, log data 、 Buried point data 、 Or the data on the large screen of the background Kanban , List the points of concern , And the normal trend of the data 、 Abnormal trends .

8. Monitoring and alarming

It is usually the focus of the test after moving to the right , You can monitor services running online , Monitor some conventional indicators of the core business interface . In addition, it is also necessary to monitor the number of different types of logs in the log system .

If the operation and maintenance supporting system is relatively complete , We can configure it after testing ourselves , If not , Take an active part in it .

9. Emergency plan

Some core business systems , There may also be emergency plans for extreme situations . For example, computer room switching 、 Disaster recovery plan, etc .