Brief description of test methods for game software
1.The definition of the test
If you give a definition, the test work is to solve the problem of predicting the unusual problems encountered by the players, and it is also a long-term observation task of constantly debugging and balancing. No matter what time period, functions are implemented, internal measurement, and open beta. The test should be divided into two parts of hardware and software testing.
2.hardware problem
The BUG part of the hardware refers to the bug that causes the game process to fail. Deadlocks, screen errors, and other hard problems. This problem can only occur if the game is played according to a certain process. However, some advanced bugs that will continuously increase the burden on the server should not be tested in the short term. For this kind of problem that arises when there is a computer, now the game has a LOG function that can automatically record the problem during the production process, and most of the bugs that appear are resolved by the program department. Part of the LOG functionality can be retained to the official client to collect new issues that are constantly being generated as the client is upgraded. It should not be within the scope of this discussion.
3.Software problem
Most of the software's logic will be performed later, such as open beta. It is the numerical adjustment of various functions. It mainly defines a balance for the world of the game. In addition to the primary value set, there are very few internal testers who can test a function ten million times. So it is possible to produce a cat-like tiger reunion, this classic fable. Planning and related testers should pay attention to this part of the test principles and methods.
The testing of this part of the problem, like hard issues, requires certain processes and requirements. The specific process is based on specific games. Most of the problems are split and stored. However, there are several points that remain unchanged.
(1) The goal of balance
First of all, don't go to see if the player's professional skills are enough. What powerful skills, physical strength, etc. will be obtained. First understand the relationship between the relationships between races, the complement of occupations, and the mutual relations of various roles in this world. What is the position in the entire world? Is it reasonable enough for ordinary people to measure the logic in reality? This role is Is the game reasonable? Only then do you need to balance each race, every occupation, and every role. Finally to one by one role test. Some people may say that this is part of the planning and discussion of the early stage. That's right, because the test has already begun in the mind of planning.
The process defined here is exactly the opposite of the real world. The real world is a summation of the overall balance, and the game world must define the balance and then arrange the world into a balanced state.
(2) Classification
The severity of the problem should also be clearly defined during the test. The more things a value affects, the higher its severity level. The entire attribute structure of the current MMRPG is basically similar to the tree structure, and there are some staggered branches and leaves between them. Power, the most basic role attribute, is the root. Other attributes that such attributes affect, eventually reaching the outcome of the game, the completion of the task, and so on. The level of these attributes is naturally very clear. The root is the highest and the foliage is the lowest. And trimming trees never starts from the root.
Between the severity levels can be divided from high to low, roles, items, skills. To correct these three categories of attributes, try to fix them within your own scope. Don't think about starting at other levels, let alone at a higher level than before. In these properties, there are also various properties that need to be divided and tested according to the specific game. Although the property distance is here, the task is also the same, and the interrelated task network is also very important. Only the changes before the property are less.
(3) Record, adjust, summarize
Soft issues should have enough document data to record as hard problems, and it is also convenient to rethink the effects of past values. This should also be all documentation should have, and record the work of each critical update. Adjustments Sid Meier said that each adjustment should be more. In this way, you can see the huge differences in values and find the right ones. This is almost a word that anyone who knows Sid Meier knows.
Most of the time, the content of the test will be directly modified according to your own ideas. Even if you record it, you just have to change it. In fact, many times these changes have certain rules, and some amendments often do not change anything. A little more time to discuss whether or not everyone has corrected according to the original goals will make more reasonable use of the remaining time test. Similarly, the summary after all is completed will also avoid the need for a lot of revisions in the next production.