In fact, many testing problems are caused by the design of the system itself. For example, a highly coupled system always affects the whole system. How do you ask others to distinguish public modules? The interfaces of public packages are always changing. How do you maintain the modules that call these interfaces? Developers, especially designers, often overlook the "testability" of software because it has low visibility from the customer's perspective. Why do we require testing throughout? It means that everyone should pay attention to the "testability" of all submitted artifacts from the beginning to the release. Okay, after solving this problem, we can look at what strategies can be adopted from a testing perspective, starting with regular manual testing. 1. Assume that the public module changes the implementation method but does not change the signature interface. This is easy to handle and can be done by unit testing. Personally, I always believe that a complete and high-quality unit test suite is crucial to ensuring product quality. As long as the original unit tests pass 100%, we have reason to trust that the current code is still reliable. Risk: Low 2. The interface of a single public module is changed, but it does not affect the interfaces of other modules. It is recommended to do a full set of unit tests, find all modules with calling relationships from the index, and do integration tests and regression tests. Risk: Medium 3. Multiple public modules are changed at the same time, which is common in large-scale system reconstruction, such as the application of new design patterns. This kind of change is not recommended as a last resort because the risk is too great. If this really happens, we can only retest as comprehensively as possible based on the actual situation. It is recommended that when designing test cases, you must grade them according to their severity. When testing, proceed from high to low to reduce potential losses. It is also recommended to build indexes for use cases and code modules. Test cases related to code changes should be upgraded to high priority. Risk: High 4. For new public modules, after good unit testing and interface testing, comprehensive system testing can be done on the test cases with the highest priority, and other test cases can be treated as the third Third-party modules (assuming no defects) to handle. Risk: High Speaking of automated testing, usually we don’t pay special attention to the execution overhead of automated testing because it is often executed at night. So we don't care much about redundancy, but attach great importance to the coverage and independence of use cases. For example, the operations we often do for business objects are C (increase) R (read) U (write) D (delete). From an automation perspective, the typical test scenario is: 1. C->validation 2 . C->R->validation 3. C->U->validation->R->validation 4. C->D->validation 5. C->U->validation 6. C->D->C ->validation It is easy to see that the redundancy is very high. Copyright statement: Original work, reprinting is allowed. When reprinting, please be sure to indicate the original source of the article, author information and this statement in the form of a hyperlink, otherwise legal liability will be pursued.