Two small cases

Today we have learned two small cases. In fact, I am very inspired by my work. I will record my cases and experiences here and hope to help others.

Case 1:

In the test system, the tester finds that the system a and system B communicate through the bus, and sometimes the timeout phenomenon occurs. After feedback on development, development is hard to reproduce. According to the brief analysis, it is considered that the performance of the testing system is not good, and it is guaranteed that this problem does not occur on the bus used for system communication in the production system. The tester strengthened the performance test intensity and found that the timeout was not reproduced in the performance test scenario after the hardware was improved. Finally, the defect was rejected. After the result reaches the production level, the timeout occurs again and has a certain impact on the core business (thanks to the remedy ). Finally, the use of production data analysis results in performance problems when some packets are too long.

 

Analysis:

Although the performance test simulates the peak pressure, it does not use real production data. The test data does not contain the data generated when the production system is small. During performance testing, it is possible to select data similar to the production data or directly use the random data copied by the production system to detect problems more effectively.

Although the tester detected the problem and had a chance to reproduce it, he did not go into the bug. In fact, if there is not much progress pressure, developers should be promoted to find the root cause, which is particularly important in the test of the core transaction system. Most companies with a certain scale will have a hierarchical definition of the system, a higher level of the system, if such an "issue" does not meet the test export conditions.

 

Case 2:

After a new feature is launched, it finds a profit vulnerability and has to temporarily perform a manual purge transaction (fortunately, the income integration system can detect it in time ). The reason for this benefit vulnerability is that some users have used an edge feature of the current system more than a decade ago (which has not been used yet) to break the integrity of existing services. It is preliminarily inferred that it is the work of a veteran.

 

Analysis:

When a system is complex to a certain extent (often involving multiple subsystems), after years of continuous modification and operation, business integrity will surely be broken. This example is not uncommon. For example, I have a clear impression: Do you still remember the marketing of hundreds of packages that Unicom used in the past few years? The complexity cannot be controlled, leading to many bugs, including many original system stealth bugs, which have to be fixed in the end. In May June this year, I also experienced such a bug on a medium-sized e-commerce website. The website temporarily engaged in promotions, combined sales, and bought a high-discount book with a specified book, the discount will increase by 15 percentage points. After you select to specify a book, go to the settlement page and delete the matched book. The discount for 15 points is still there.

How can this problem be solved? You can think of the following methods:

1. For legacy systems: conduct regular business integrity checks on Ba to identify the potential impact of business crossover. This is actually quite difficult to do. For large systems, it is particularly important to develop ba That is proficient in both upstream and downstream businesses. Looking for external experts to help with business penetration testing is also a good way. Security Testing is very effective, and there are also mobile teams in the financial industry. Have you ever seen Shi tailong and Arnold take the film "golden shell" over the past two years?

2. large-scale automated regression testing is also a good method. Of course, a specific part of regression testing cases are "scenario test cases" (we generally call it long process cases or end-to-end business cases ).

3. Adopt a business modeling method. Such as the UML series and BPMN, both of which can identify business relevance and Business intersection information to a certain extent, help testers design such integrated test cases (sometimes called compatible test cases and associated test cases ).

4. scenario-based test analysis modeling method, State Transition Graph Method, and model-based testing (State Transition Graph Method is a common implementation form of model-based testing) it is a good way to deal with the rolling evolution process of such business-intensive products.

5. real-Time Systems (flight control, machine control), medical equipment, money-related, high-traffic, and inventory-related systems should perform transparent tests on the areas with the highest risk, otherwise, nothing will happen.