What is the last thing test developers want to do? That must be non-refactoring.
Why? Because refactoring means that the programmer has to personally recall that he had to rethink all the functions of all the code, all the functions, all the layers, all the modules and all the functions of the test platform.
Not to mention that the cost is close to re-developing a set of projects, it is enough to let people collapse once again by carefully recalling the nightmare once again.
Leaders generally don't realize these. At the beginning of the development of the test platform, they will let you do it as soon as possible, and use it in a hurry. Wait for it to be used well, and then give you various upgrade requirements, maybe which requirement just needs to refactor the bottom layer of the platform.
The next step is to see how to do it efficiently and safely. The most important thing is to save brain cells!
1. Clarify the purpose of reconstruction and the real needs!
Note that this is the real demand. Compared with the original demand, it is necessary to analyze it more deeply to understand the real purpose of the user. Note that this purpose is what the user sees, not necessarily the project code as well.
Maybe you don't understand what this means. Let me give an example: users want all the data on your platform to be divided into multiple groups. The normal understanding from the naked eye is that the data is divided into multiple groups and stored in different places. In fact, what we need to do is to put different labels on these data in the original database, and then when the front end is displayed, we can distinguish the labels to display. And that's the real need.
2. Hierarchical statistics for the entire project
First layer the project, such as data layer, view layer, business layer, physical file layer, front-end components, etc. Then start to count each data of each layer, whether it needs to be changed, and how?
For example, the data layer is to study all the data tables and which tables need to be changed. Don't be in a hurry, take notes first. Because refactoring is a relatively important thing, if half of the changes are found to be wrong, it will really suffer.
Then there is the business layer, which starts to traverse all functions to see if they need to be modified. A simple solution here is to first classify all functions according to "add, delete, modify, check, and special functions". Then roughly think about which functional classes this refactoring focuses on. For example, in the example I gave above, grouping data is actually labeling different diseases. Then the classification considerations are:
1. Added: It needs to be labeled, so it needs to be modified
2. Check: It needs to be distinguished according to the label, so it needs to be modified
3. Change: If the label can be changed, then it needs to be moved. Otherwise, don't change it.
4. Delete: When deleting, you don't need to look at the label at all, just look at the data id, then you don't need to move.
3. On data link transmission, ensure smooth upstream and downstream.
Continuing from the previous article, after we have thought about each function/module of each layer, the next thing to look at is whether they can be connected smoothly between these modules/layers.
Therefore, it is necessary to focus on the newly added/decreased fields during the data transmission process, such as the parameters in the routing controller, and the request parameters of each interface, such as the data flow between the backend and the frontend, such as the data between the components of the frontend vue interact.
4. Dirty data problem
Under such large-scale refactoring, dirty data is hard to avoid. In particular, pay attention to old data, and consider in detail whether the old data can be used normally in the new architecture. For example, if you add a field in a database table, the previous data does not have this field, if you do not design a default value. Then there is a high probability that it will become a None type, and your front and back ends have never considered None, and there is no corresponding treatment. Naturally, an error will be reported, and these old data will become dirty data.
You either design the default value at the beginning, or design the sql batch script that follows.
Then there is the question of comparing the old and new data, to ensure that the newly created data has exactly the same performance as the old data. A more convenient way to test this is to compare and test two terminals, one with old data and one with new data. Different performance is a bug.
5. Full regression testing
Everyone should know that after a large-scale refactoring, bugs are bound to exist, there is no doubt about this. Enterprise-level software can even break out with hundreds of bugs. Even for a simple test platform, there are more than a dozen bugs that appear due to this refactoring, which are all too normal.
So adjust your mentality, don't be afraid of trouble, it is very necessary to conduct a complete regression test!
Finally, I would like to thank everyone who has read my article carefully. Watching the rise and attention of fans all the way, there is always a need for ritual exchanges. Although it is not a very valuable thing, if you can use it, you can take it directly.
These materials should be the most comprehensive and complete preparation warehouse for friends who do [software testing]. This warehouse has also accompanied me through the most difficult journey. I hope it can also help you! Everything should be done as early as possible, especially in the technology industry, and the technical foundation must be improved. I hope to be helpful…….
