In the daily test work, I do not know whether we will have the habit of combing their test business. I personally think it’s worth doing, and it’s best to make it a habit.
First, why to comb the business?
Because in business testing, as a tester, it is very important to be familiar with the business in charge, and through periodic sorting and summary, you can systematically precipitate business knowledge.
When asked what is the test focus of this business system? How to overcome the difficulties? Why this design and so on, can be orderly output.
Or, when you need a handover or need someone else to support your business, you can confidently throw the document over, pat yourself on the back and say, “Just read it.”
Similarly, everyone is doing business and there is not much output from other technical layers, which is one of the reasons why some people get A’s and others get C’s.
In addition, when you have multiple businesses, you can even refine a lot of general things, let’s call them “methodologies.”
Second, comb the framework
So many advantages, how to comb? Here I refer to the conventional service system, write some ideas (framework), only for reference.
1. Test scenario
This section can sort out test scenarios for business systems.
You can highlight the core test scenarios with full test cases. If the use cases have subsequent iterations, they can also be categorized by time and content and placed here.
2. The business
This is where you can sort out more specific areas of the business. Such as:
1) Various configurations
Background configuration, background address, impact range, mandatory/optional configuration, configuration sequence, and special items related to services.
2) the front end
What front-end features are involved, important links, major front-end interactions, etc.
3) Core processes
The core flow of a service can include the operation flow for users and corresponding interfaces for interaction.
In addition, you can draw the core business flow chart by hand, which will be provided by general products. However, if you have time to draw it by yourself, it will be more profound in your mind. Maybe there are unexpected discoveries to supplement the test design.
There is also a focus on the processing of business data. If other middleware such as Kafka, ES, caching, etc. is involved, the details of data processing can also be sorted out.
4) Troubleshooting
There will be miscellaneous problems in the test work, take out some typical problems, record the means of investigation and possible factors, convenient for yourself and others to view.
3. The system
Once the business layer is sorted out, it’s time to focus on the application service layer.
1) Application site
You can sort out the information of each site, service name and function under the service system from the entry down.
2) Interface and log
Here you can summarize the interface documents and classify them according to different situations. Anyway, the purpose is to view the corresponding documents efficiently.
It is also important to view critical logs during testing to understand interface interactions and troubleshoot problems. Here can record the different processes involved in the site, if filtering logs and other information.
3) MQ messages
Note what MQ interactions are, topic, what the different tags are for, message body, and so on.
4) Exception mechanism
Make a note of the system’s mechanisms for handling exceptions, common ones such as timeouts, retries, compensation, backstops, and so on.
4. The data
When it comes to the data layer, mysql, cache, mongoDB, etc.
Sort out the database names, what to process, the core tables, and key fields, such as some order types, status, and so on.
Redis these noSQL database, comb important key, field, value and so on.
5. Security
Such as the authentication mechanism of the interface, some interface details involving more complex encryption processing.
There are also controls for concurrent operation classes that can be sorted out.
Performance of 6.
Typically the performance of single interface and link scenarios.
1) Interface performance
For example: front-end user experience of the most intuitive interface, order interface, detailed interface, pre-processing interface and so on.
2) Link performance
The most core link scenarios are strung together for pressure measurement.
3) the current limit
If traffic limiting scenarios are involved, you can further clarify the factors to consider traffic limiting, trigger mechanisms, and processing methods.
7. Data analysis
The data is diverse, such as log data, buried data, or background kanban large screen data, lists the points of concern, as well as the normal trend of data, abnormal trend.
8. Monitor and alarm
This is usually the point of focus after the test is moved right to monitor the services running online and some general metrics of the core business interface. In addition, it is 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 test ourselves to configure, if not, actively participate in it.
9. Emergency plan
Some core business systems may also have contingency plans for extreme situations. For example, switching equipment rooms and disaster recovery plans.