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

Finding bug in software testing is the responsibility of the position itself, so for many newcomers and newcomers, this process will be a little difficult, after all, there is not much project experience, and it is often painful to find bug quickly.

Then I will use my own experience to popularize how to quickly find out the shortcomings or defects of the system at work.

1. Be familiar with the products you make

Whether you are Dev, Test or PM, the more products you develop, the better. You should not only be familiar with your own modules, but also be familiar with other modules related to your modules and how they cooperate with each other. For example, how a field in the database is used by each module, which helps you to find Bug at the design stage and minimize the cost of repair.

Similarly, you need to be familiar with previous versions of this product, because products that are not backward compatible and upgraded may be difficult to gain user approval. In the course of testing, if you find that your product is not compatible or inconsistent with the previous, 80% of the cases, this is a Bug.

2. Discover Bug as soon as possible

As we all know, the cost of Bug repair is exponentially related to the time it takes for Bug to be found. The sooner you start looking for Bug, the more Bug you can find and the greater your contribution to the project.

3. Review other people's Bug every day

If your team does not have daily Bug Report, I suggest you build one, in fact, there should be no technical difficulty, through the Bug tracking system API or database, you can get the data you want, so that the whole team by learning to check other people's Bug every day, you can more easily find Bug, will not find that kind of Duplicated Bug. Now people often come to me and ask me if a Bug is a known problem, because I watch Bug Report every day.

4. Prepare more test patterns in your daily life

Pattern is a very fashionable word because it is very useful. In daily testing, prepare more test patterns, you will have a very big surprise, sometimes using a pattern, you can find 10 or so Bug is not impossible. For example, use special characters as input data; disconnect the network to see if UI will Crash; whether each string prompt is localized in the localized version

5. Multi-test the cooperation between each module

The testing between modules is often the weak point in our testing, but the cooperation between modules is very important for users. Often, a data is legal in module A, but illegal in module B. it is necessary to find out the data, which is often Bug.

6. Write automatic test code

I'm sure you don't want to do the same thing every day. It's so boring, it's an insult to your wisdom. But once we didn't do these tests, suddenly one morning, we found that the function of our product that used to work well had suddenly stopped working, so everyone was in a mess, someone was in a hurry to fix it, and someone was looking for whose Check in it was.

7. View the product code

By looking at the product code, you can often find some Dead Code or logical Bug that you can't find through manual testing.

How to write a use case for the first time?

There are many friends who write use cases for the first time and do not know where to start. Although some companies have given relevant documentation, they are still not easy to write. There are many ways to write use cases: function-oriented use cases (boundary values, equivalence classes, etc.), user-oriented use cases (scenario method), the combination of users and functions to guide use cases.

So for the first time to write use cases, how to write use cases efficiently? What should I pay attention to?

First, the function-oriented use case is to write the use case according to each function that the system needs to achieve, such a use case focuses on the functional implementation, but does not take into account the relationship between each function, so although the use case has reached functional coverage, it does not necessarily achieve logical coverage, so this method is usually used in combination with other methods. Function-oriented use cases are the most commonly used method in the early stages of each use case writer.

Second, according to the user's habit, the user-oriented use case is to take each purpose of the user using the system as a goal, and to design the test case based on the realization of each goal, but to design this kind of use case, the first writer, there may be a lot of confusion (write down what confusion I had when I first wrote it, and what kind of solutions I took to solve these puzzles.)

1. What should I do as a first step in writing a use case?

To understand the system, first of all, from the point of view of testing, we deeply understand each function and business logic of the system, and draw the business logic diagram (that is, what the system can do).

Secondly, from the user's point of view, list the purpose of the user using the system (that is, what do the user want to do when using the system? )

2. How to determine the user's goal?

Can not determine the user goal, may be caused by two reasons: a > not familiar with the system, b > do not understand the user background. For the first reason, it's your own reason, you have to look back at the documentation, and for the second reason, you can infer what the user can do from what the system can do, and then summarize what the user might want to do. of course, the premise is that you are already familiar with the system.

3. What will I do this month?

How to sum up when you just entered the testing industry (using test management tools to summarize):

1) classify and export all the defects in the test management tool, summarize which modules are easy to produce which defects, and focus on the defects that you have not found or considered.

2) if the first level of testing newcomers starts with executing use cases, then the second level is writing test cases. Take a detailed look at the use cases in the test management tool several times, learn other people's use case writing methods and ideas, free time can try to write their own, to see where the gap between their own and others written use cases, so as to continue to improve. Important instructions; focus on the study of use case writing methods and ideas, rather than mechanically.

3) enter some testing forums, share your confusion and experience with you, and make continuous progress in your study.

Summary:

As the so-called kung fu is outside the poem, there is so much theoretical knowledge about testing. After mastering the theoretical knowledge, you have to constantly participate in the project. Practice one project to exercise your ability to discover Bug. Even if you take a random test, a good test and a bad test, their ability to find problems is completely different. The above is completely personal understanding, may not be on the table, you look at the officials, when watching, please give a lot of advice.

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.