Test business sorting
In daily testing, I don’t know if you have the habit of sorting out your own test business. I personally think this is worth doing, and it is best to develop it into a habit.
1. Why sort out the business?
Because in business testing, as a tester, it is very important to be familiar with the responsible business, and through phased sorting and summary, your business knowledge can be systematically accumulated.
When asked what the focus of this business system is on? How to overcome difficulties? Why do you need to design this way and other issues, you can output it in an orderly manner.
Or, when your task needs to be handed over, or if someone needs to support your business, you can confidently throw the document over, pat your chest and say: You will know after reading it.
Everyone is doing business normally, and there is not much output from other technical levels. This is one of the reasons why some people can get A, but some people can only get C.
In addition, when you have accumulated a variety of businesses, you can even extract many general things, which will be called "methodology".
2. Clarify the framework
There are so many advantages, how to sort it out? Here I refer to the regular service system and write some ideas (frameworks) for reference only.
1. Test scenario
This part can organize the test scenarios of the business system.
You can focus on posting core test scenarios and include a full range of test cases. If the use cases have subsequent iterations, they can also be classified according to time and content, and put it here.
2. Business
Here you can organize more segments of the business. for example:
1) Various configurations
Various background configurations, background addresses, configuration impact scope, non-essential configurations, configuration sequences, special attention items, etc. involved in the business.
2) Front end
What are the front-end functions of the product involved, important links, main front-end interactions, etc.
3) Core process
To sort out the core process of the business, it can include the operation process for users and the corresponding interaction interface.
In addition, you can draw a core business flow chart by yourself. Generally, the product will give it, but if you have time to draw it yourself, you will have a deeper time in your mind. Maybe there will be unexpected discoveries to supplement the test design.
Another key point is the processing process of business data. If other middleware such as kafka, es, cache and other middleware are involved, the details of data processing can also be sorted out.
4) Problem troubleshooting
In the test work, you will definitely encounter miscellaneous problems. You will find some typical problems and record the inspection methods and possible factors to facilitate yourself and others to view them.
3. System
After sorting out the business layer, you should pay attention to the application service layer.
1) Application site
You can sort out information such as each site, service name, function and other information under the business system from the entrance downward.
2) Interface and log
Here you can summarize the interface documents and classify them according to different situations. Anyway, the purpose is to efficiently view the corresponding documents.
How to view critical logs during the testing process is also important, and it is very helpful for understanding interface interaction and troubleshooting problems. Here you can record different processes, sites involved, logs and other information.
3) MQ message
What are the MQs that record interactions, topics, what are the functions of different tags, message bodies, etc.
4) Exception mechanism
Record what abnormal handling mechanisms are available in the system, such as timeout, retry, compensation, guarantee, etc.
4. Data
When we reach the data layer, we can't open mysql, cache, mongoDB, etc.
Clarify the database names, what to deal with, core tables and key fields, such as some order types, status, etc.
Redis these nosql databases to sort out important keys, fields, values, etc.
5. Safety
For example, the authentication mechanism of the interface, some details of the interface involving more complex encryption processing.
There are also some concurrent operation controls that can be sorted out.
6. Performance
Usually the performance of single-interface and link scenarios.
1) Interface performance
For example: the most intuitive interface for front-end user experience, single interface, detailed interface, preprocessing interface, etc.
2) Link performance
The most core link scenarios are stringed together for pressure testing.
3) Current limit
If the current limit scenario is involved, we can further organize the factors that consider current limit, trigger mechanisms, processing methods, etc.
7. Data Analysis
Data are diverse, such as log data, buried data, or data on the backend kanban screen, listing the points that need to be cared for, as well as the normal and abnormal trends of the data.
8. Monitor and alarm
Usually, it is the point of focus after moving right to test, which can monitor the services running online and monitor some conventional indicators of the core business interface. In addition, it is also necessary to monitor the number of logs in different types of log systems.
If the operation and maintenance supporting system is relatively complete, we can configure it by testing ourselves. If not, actively participate.
9. Emergency Plan
Some core business systems may also have emergency plans for extreme situations. For example, computer room switching, disaster recovery plan, etc.
The above is the detailed content of practical skills for software testing business sorting. For more information about software testing business sorting, please pay attention to my other related articles!