Shulou(Shulou.com)06/01 Report--

Bug is like a spoiled child who gets a lot of attention. They were born silently in the developer's IDE, but they caused an uproar at the moment of appearance. "--the Life of bug

Bug's birth certificate.

September 9th, 1945, three o'clock in the afternoon. Lieutenant Harper is leading her team to build a computer called Mark II. This is not a complete electronic computer, it uses a large number of relays, an electro-mechanical device. The second World War is not over yet. Harper's team worked day and night. The computer room is an old building built during World War I. It was a hot summer, the room had no air conditioning and all the windows were open to dissipate the heat.

Suddenly, the Mark II crashed. The technician tried many ways and finally located the error of the No. 70 relay. Harper looked at the faulty relay and found a moth lying in the middle, killed by the relay. She carefully clipped the moth out with the camera, pasted it into the event log book with transparent tape, and marked "the first example of finding a bug."

From then on, people jokingly called computer errors bug.

The Life cycle of bug in Software testing

For testers, the life cycle of bug is generally divided into: discovery bug- > submit bug- > verify bug, so how to reflect the professionalism of testing in these three phases?

Phase 1: discovering bug

1. Make full use of the 80-stroke-20 rule

The 80th rule, also known as the Martley law, the twenty-eighth law, the Pareto law, the most labor-saving law, the imbalance principle, the Jewish law.

The 80 per cent rule reveals that 80 per cent of results come from only 20 per cent of actions, reflecting the "universal truth" of the imbalance between input and output.

In general, the 80 stroke 20 rule applies to the following software test scenarios:

80% of software defects exist in 20% of software code ("clustering" phenomenon of software defects)

80% of software defects are attributed to 20% of software defects ("clustering" phenomenon of software defects)

Review and testing in the analysis, design, and implementation phases can only identify and avoid 80% of software defects, while system testing can only identify 80% of the remaining Bug.

2. Communicate effectively with developers

Effective communication with developers can not only communicate personal friendship, but also obtain development-related knowledge, but also get information beneficial to software testing.

3. Test from different angles

From the perspective of management, we need to understand the priority of the tested products in many products of the company, so as to achieve the effectiveness of software testing, that is, to ensure the effectiveness of software defects.

From the developer's point of view, we learned that the developers think that the development of those modules in the software products are difficult and lack of confidence, so as to quickly locate our testing focus.

From the end customer's point of view, try to find as many software defects as possible from their existing usage habits and possible problems, that is, user experience.

4. Choose a simple and effective testing tool

For example, link testing of web pages, if you choose some easy-to-use link testing tools, can not only improve coverage, but also find more software defects.

5. Conduct a special test

For example, installation test, uninstall test, double (multi) byte test, query test, upload attachment test, shortcut key test, UI overall style test (including buttons, success messages, warnings), and so on.

6. Refer to the unit test results

It can help us locate the focus of software testing, spend less time, and find out more software defects.

7. Refer to the software defects reported by other testers

Everyone's thinking is limited, and we can refer to the software defects reported by other testers to get new testing ideas, so as to find software defects that have not been found before.

8. Error inference method

For people with certain software testing experience, it is a quick method to find more software defects in a short time, which reflects the value of experience.

Phase 2: submit the bug

1. Make sure the bug is valid.

The submitted Bug must be valid, so we are required to confirm when submitting the Bug:

During the delivery of ①, the tester needs to classify and submit the Bug according to the set module.

The type of ② Bug defaults to UI problem, function problem, crash problem. You cannot make a mistake when submitting Bug.

Whether the ③ requirements are clear, whether the prerequisites are met, whether the input data is correct, whether the operation steps are clear, and whether the Bug is unique

④ avoids submitting such a design, operation error, duplicate, known Bug

⑤ spends as little time as possible on boundary values and page display, and talks more about business logic functions and interaction testing.

two。 Write a bug description.

1) bug describes accurate, unambiguous, detailed and concise testing steps.

2) ensure that the content of each field is consistent with the actual phenomenon. For example: version, recurrence rate, etc.

3) for problems with low recurrence rate, provide some reference information as much as possible: screenshots, videos, logs, possible steps, possible causes, etc. (if you can locate the cause of the problem by various means, the developer will be impressed.)

4) for special test scenarios, with relevant data, such as 1024kb pictures, etc.

Phase 3: verify bug

1. Confirm the recurrence premise and operation procedure of bug.

two。 Confirm the cause and repair method of bug.

1) identify the causes of bug, draw analogies, and analyze the possible problems in other modules.

2) accumulate testing experience and expand testing ideas through the causes of bug.

3) through the modification method of bug, analyze whether the modification can fix the problem? Will it give rise to other problems?

4) accumulate bug experience, quickly locate problems and provide solutions when follow-up related problems are found

3. Confirm the regression scope and use cases of bug.

Based on a clear understanding of the causes and repair methods of bug, the regression scope is confirmed according to business association and functional module association to ensure that bug repair is comprehensive and does not cause new bug.

Summary:

Bug is so strange that not every bug has to go through all the processes. Every step has its difficulties. Some bug is difficult to locate the incident point, such as multithreading, and some bug in asynchronous logic is difficult to analyze, mostly because you can't understand the code; some bug is difficult because you dare not change it, and that is because your modification plan has not been fully analyzed.

Welcome to join the 51 software testing family, where you will get [latest industry information], [free test tool installation package], [software testing technology], [job interview skills]. 51 learn and grow with you! Looking forward to your joining: QQ Group: 755431660

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.