How to do functional testing? The basic method and application details of functional testing

For more autumn recruiting dry goods, check it out on the Easy Game Academy app! https://game.academy.163.com/ssi/app/?referrer=csdn

Introduction: The test engineer is like a sharp-eyed butler. To ensure the quality of the game, repeated tests are required. This time, Netease game test engineer Baozi will explain some basic methods of functional testing and how to apply them to the game.

The following is a sharing record:

1. How to do functional testing?

Game function testing is to verify the functions of the product, design test cases, and test item by item to check whether it meets expectations. Generally, we divide functional testing into the following steps:

1. Develop a test plan;

2. Design test cases: include what to test, in what scenario and under what environment;

3. Perform tests and generate test reports;

Among them, the most core is the second step. Simply put, how do I test these things, and how do I ensure that I can find as many problems as possible after the test, so as to solve the BUG. Next, I will talk about specific cases in detail.

As shown in the figure, this is a leaderboard gameplay. I can challenge people who rank higher than me, and challenge the opponent's defensive lineup. If I succeed in the challenge, my ranking will be exchanged with the other party. The summary of the rules is as follows. The rules are simplified here. In fact, a leaderboard rule cannot be so simple.

 

Everyone can think about what you think needs to be tested for such a gameplay rule.

When we follow up this gameplay test, we will find that this gameplay is naturally divided into 3 modules: registration, challenge, event end & settlement. We will test these 3 modules separately.

The first module, registration module

There are two conditions for the registration module, one is the level condition and the other is the maximum number of people.

Only players above level 20 can participate, and 1000 people are limited to sign up. The program will write: 

This involves a boundary value problem. In the number limit, if the count is the number of players who have registered before signing up, it is less than the number. If the player finishes the registration and then compares, the equal sign is added here. From the perspective of code writing, the boundary is prone to problems, so we have to test both the boundary value and the vicinity of the boundary value.

The second module, challenge activity

The challenge has the following processes. Initiate a challenge, the challenger ranks high, the challenge is established; otherwise, the challenge is impossible, and so on to form a clear process.

In this place, each branch must be covered during testing to detect whether there are BUGs.

The third module, the settlement module

Reward settlement is settled according to the ranking, the top ten king gift packages, 11-100 diamond gift packages. When we did the test, we found that these rankings were divided into three regions. 

We can think that the rankings in the three regions are equivalent. That is to say, among the 1-10, if the rewards obtained by randomly selecting a ranking are correct, the rewards for the remaining 9 rankings are also correct. Therefore, the 1000 rankings are regarded as three intervals, and a ranking is randomly selected from each interval for testing, so we can use equivalence division plus boundary value to test.

Is this test enough?

We just assumed that players follow the steps step by step, but some players will encounter many other situations. Therefore, when we are testing, we have to think more than the players, to prevent "sao operation" in advance, to test Whether the game function is normal.

For example, the player dropped during the challenge, the player’s game account was topped, or during the challenge, the opponent’s ranking changed again. What kind of handling methods the game should adopt in these situations is also what we do What needs to be considered when testing, this is what functional testing needs to do.

There are many methodologies for functional testing. In addition to the boundary values, branch coverage, and equivalence classes just mentioned, there are many other methods, but they are always the same. They are all to find the points that are prone to problems and execute these use cases. .

Two, white box testing

Black box testing and white box testing

What is black box testing? We can think of a piece of software as a black box. We don’t know what’s going on in it, but we just design the input and check whether the output meets expectations. This is black box testing.

The corresponding is white box testing. The difference between white box testing is that we all know the logic inside the box. 

White box testing method

Unit testing and integration testing

Unit testing and integration testing are both for code testing. Assuming that a function is a unit, we test the detailed units one by one, and finally put all the units together for integration testing. 

For example: draw cards. How many steps does the card draw? Burning incense and praying, this is the player's process. What is the process of the program code? First deduct the coupon, then randomly, and finally issue the card. The random process will generate a card pool, and finally calculate the probability. In this way, each subdivision module is clear, and the entire card drawing test will first test each point separately, and then test the entire card drawing function.

Tools for white box testing

Static code inspection and code coverage testing

What are the common tools for white box testing? Static code inspection and code coverage testing.

What is static code inspection? It is static checking when the code is not running, which is similar to checking your own code after you finish your homework, but it is inefficient and difficult to check for problems. So everyone invented different tools to check whether their code is correct. 

In our daily communication, when we judge whether a person’s grammar is correct, we will subdivide the language into words and then put them into grammatical formulas. Then the code inspection is similar. We divide the source code into word streams and perform grammatical analysis. This is a very superficial principle, but it is actually very complicated, so tools are very important, which can save us a lot of time and find problems that we can't find. 

The second is the code coverage test. The code coverage test is the opposite of the static code inspection, which is to check for problems during code execution.

Suppose there is an old-fashioned proposal code that requires that the suitor must be a male character, and the suitor must be a female character. How do we test it? As long as you run all the code when you run the code, to achieve complete coverage, there is no problem.

Some will also require decision coverage, or even condition coverage, so the complexity will be slightly higher. The more difficult thing is to cover multiple conditions, which means that every combination of conditions must be covered.

Of course, there are many places that cannot be covered by the tool, and it does not mean that the code logic is no problem if it reaches a certain coverage of 100%. At this time, we all need to be more thoughtful and use more methods to cover and test, which involves deeper content.

The above are the methods and concepts of white box testing.

Three, perception

Finally, I will share some metaphysical things. After so many years of testing, I will share some insights with you.

Is it possible to fully test? For example, can a calculator be fully tested? That is impossible, because the input and output of the calculator cannot be exhaustively listed. So you need to design test cases to find the problem as much as possible.

In addition, not all software defects have to be fixed. Ideally, it is the best to fix all bugs, but this is difficult to achieve in reality. We have to consider costs and benefits. Cost is time, manpower, and risk, and benefits are quality, safety, experience, and reputation. Only after making the cost and benefit and weighing, can you decide whether to fix a certain defect.

People often ask the difference between game testing and software testing. In addition to functional testing, mobile game testing is actually very complicated, including playability, balance, pressure, performance, safety, and other tests. There is no way to talk about them here.

To give a simple example, for example, a dungeon can only be played by people who are good at all servers, then this dungeon is invalid. Although it has no bugs, it does not meet the playability. For example, in MOBA games, a new hero is very powerful, unmatched, and unreasonable. This is a problem of balance.

The second point is that mobile game testing has more difficult automated testing. First, it is technically difficult, and secondly, the randomness of the game makes the design of the automated process more difficult.

Fourth, the development trend of testing

Finally, I will share with you the development trend of testing. At first, it was verification-oriented, that is, as long as it has been verified. Going to the vandalism-oriented, such as vending machines, it is not enough to just verify that you can buy drinks. Some buyers may kick it, and it will not be damaged even through wind and rain, so it is necessary to do such a violent test.

However, people later discovered that extreme conditions are not the part that everyone cares about most. Everyone is more concerned about the overall quality assessment of the product, such as the durability of the product, the environment in which it is prone to problems, etc., so gradually quality assurance requires a more comprehensive quality assessment. .

Now, as people generally realize that the earlier the problem is discovered, the lower the cost of repair. An important trend is to stifle defects in the cradle by means of processes, specifications, etc., which is oriented to defect prevention.

Observing the game development model, we will find that the workflow is from designer, to development, to testing. But because testing is a downstream stage, the later a problem is discovered, the harder it is to modify it. In fact, testing should be involved earlier. For example, in the design stage, problems can be found and raised from the numerical value and from the overall architecture to reduce repair costs and prevent larger problems.

For more autumn recruiting dry goods, check it out on the Easy Game Academy app! https://game.academy.163.com/ssi/app/?referrer=csdn

Guess you like

Origin blog.csdn.net/NetEase_Game/article/details/108596521