Two-year mobile phone software testing work summary

From: http://blog.sina.com.cn/s/blog_48f5a98701000ajc.html

The following is my understanding of the testing work and some explanations:

I. Prerequisites

1. Cultivate personal qualities:

A. He is cautious and enthusiastic about his meticulous work.

B. The spirit of exploration breaks down the sandpot and asks the question to the end.

C. Pursue Perfection, creative thinking, and come up with creative or even extraordinary means to find defects.

D. Be good at expressing opinions, organizing languages, and describing the operation process should be easy to understand.

2. Understand the responsibilities:

A. Compilation of test cases and plans and coordination of test resources and quality.

B testing execution, some automated tests and performance tests.

C. Support for field tests in foreign countries, in China, and abroad.

Ii. Purpose

The purpose of the test is to discover as many defects as possible. This concept is easy to accept, but it is difficult to implement it in practical work, because the purpose of the test is often positioned as "proving that the software is okay ". Whether the software quality is good can be reflected only after production.

It is very important to understand the purpose of testing correctly. If the purpose of the test is to show that there are no defects in the program, the tester will move closer to this goal, and therefore subconsciously design many test examples that are not easy to expose errors, these test cases prove that the software has implemented the expected functions, and such a test is not true. The successful test is to discover the defects that have not been found so far.

Iii. Test Procedure

1. Project Requirement Review:

A review principles: Check the correctness, non-ambiguity, integrity, consistency, enforceability, verifiable, corrective, and traceable requirements. Do not just check the surface text and interface of the document. think deeply about whether the function is logical and dare to ask questions.

B. review key points: whether to describe the attributes of the input/output values, such as the boundary value, measurement unit, and timing requirements. Whether to clearly describe the processing status and return value of the connection between the software module and the module. Whether the special nouns are consistent or not.

2. Develop a test plan

A. Divide the test project and clarify that a test task should be completed at a certain time. Test phase and personnel allocation should be subdivided as much as possible.

B. Understand, collect and organize the resources required for testing.

C. Create conditions for testing success as defined by available metrics.

3. Design test cases:

A basic elements: test Purpose, prerequisites, input data, operation process, and expected response.

B. Different test cases should have different purposes and should not be redundant.

C. In addition to common data, the design test case also needs to consider the limit value, boundary value, repetition value, 0 value and negative value, that is, different test cases require different types of data values for testing.

D When designing test cases, note that, in addition to the overall process and function, pay attention to various aspects such as strength testing, performance testing, stress testing, boundary value testing, stability testing, and security testing.

4. Test process

A integration test: when some program modules are integrated, test whether they can run normally.

System B testing: it refers to testing based on Module Testing and unit testing. Measure the test taker's knowledge about system functions and performance. The purpose is to test whether the software meets all requirements (including functional and non-functional requirements ).

C Performance Test: test the software running time, response time, function call frequency and nesting, CPU usage, data throughput, auxiliary storage area, and processing accuracy.

D compatibility comparison test: for example, the SIM card, tcard, audio, video, and other compatibility comparison tests.

E standby current test: The purpose is to test the battery time. The standby current diagram also shows the stability of internal software.

F automated testing: the instrument is used to simulate the user's use process, and the mobile phone operates normally. In fact, automatic testing is to hand over a lot of repetitive work to a computer, which can save a lot of time, cost, personnel and resources.

G site testing: tests are conducted for communication networks, such as calls, information, and Internet access. tests are conducted in different network environments to test the communication performance.

H CTA, FTA, GCF prediction:

CTA prediction: Mainly used to test the RF Characteristics of mobile phones, also known as RF indicators. In general, CTA is the network access authentication for communication devices.

FTA prediction: full type approval ). Pre-test of GSM authentication.

GCF prediction: pre-test for GSM and WCDMA authentication.

I regression testing: A retest performed when the defect is corrected or the software function or environment changes. The difficulty of testing is that it is difficult to determine which content should be retested.

J factory test: perform various tests based on the test cases designed for Factory standard indicators. If one indicator fails, it cannot pass the factory test. Factory test examples include switch-on, call, special button, menu, accessory, and standby current.

(Test focus: Focus on this project, such as music phones, movie phones, photo phones, smartphones, and game phones. Test the function from the user's usage point. Tests the key modules based on users' purchase ideas. Load Testing, stress testing, usability testing, installation and upgrade/uninstall testing, and security testing are also required during the testing process .)

5. defect description

A basic requirements: accurate, concise, complete, and standardized.

B. Key Points of error Description: The title should clearly indicate the key points of error. The operation process should describe the entire test process, including the working environment and the running conditions of the testing machine, and provide as much relevant information as possible; the actual running results and expected results should also be specified accordingly. It is best to store trace or log information in real time.

6. Test report and evaluation

Key points of a model: title, version number, tester, statistical data, probability, and personal evaluation of this version test.

B currently, there are basically templates in the test report. If not, pay attention to the above points.

7. Communication

Some problems may be the way out with the programmer's design, or even some small problems. We should give full play to our communication skills, be good at expressing opinions, and show why Software defects must be fixed, and demonstrates the proof-of-concept through actual demonstration.

8. Summary

In short, we should try our best to achieve the "80-20" principle during this testing process. In the analysis, design, and implementation phases, review and testing can discover and avoid 80% bugs, the system tests can find out 80% of the remaining bugs. The final 5% bug may only be exposed after a large range of users are used for a long time. Because the test can only identify as many errors as possible, and cannot ensure that all errors can be found. In general, 80% of defects are concentrated in 20% of key business modules.

Iv. Consequences of testing omissions

If Software defects are left behind and moved to the customer, the result is a costly telephone or on-site support cost, which may also require repair, retest, and release of new products, even worse, the product will be recalled or even sued by the customer. This cost is very high, almost times the geometric progression of defects being modified internally.

Philip Crosby, the father of quality, divides the cost of quality into two categories: Integration cost and non-integration cost. Integration cost refers to the full cost associated with one-time plan and execution test, which is used to ensure that the software is performed as expected. If a defect is discovered and the defect is solved through a series of defect processing procedures, the cost is not integrated. In his work, Philip Crosby elaborated on the sum of the internal integration fee and the internal non-integration fee, which is far less than the external, that is, the customer's non-integration fee.

In short, Software defects must be solved internally as much as possible, which is of great benefit to save costs and increase product awareness.

The following are my opinions on the problems in current testing and department management:

1. I did not perform the test according to the test case. Because there are too many test cases, and the test time is short and there are few human resources, I just went through the basic test cases. This is a waste of writing test cases. In this case, we need to strictly execute the test cases and manage them in a unified manner. The execution results should be summarized and a score should be given for this test. Each test phase should be improved.

Two test cases should have two versions. One is for the programmer to execute (generally within 20 test cases, which is basic and does not take much time. Ensures the efficiency of versions and reduces the number of publications .) Before each program compilation, the programmer should execute it by himself. The other is for the tester. The test examples should be detailed and should be updated in a timely manner. One person is divided into two modules and the test will take about one week to perform a cross-test on the test examples. Test tasks should also be replaced within a certain period of time to avoid repeated tests. Tasks effectively restrict idle testers and enhance the timeliness and working atmosphere. This will be necessary if the last regression test should cover all the test cases.

3. We recommend that you add testers to a successful project. The ratio of developers to testers should be. At present, our ratio is less than/2, which can inhibit the development process and quality of a project.

4. Developers will gradually influence the tester's thinking and ability to judge defects, especially for the same platform. The same group of developers and the same group of testers have been working together for a long time, many problems are originally defects. Because testers use software "naturally", they will not be treated as defects, especially with developers' explanations and persuasion. Assimilation may start with a "vicious circle": testers will help developers explain the rationality of each defect and will not find any problems in a round of tests. When recruiting new personnel, different test project teams can rotate to test different products, which can be avoided. At the same time, we recommend that you release a beta version of the product. More people can test it to discover more problems.

5. In the system test phase, many low-level defects may occur, indicating that the test object is unqualified and fails to meet the test standards. If there are many simple defects found in the system stage (that is, there should be no defects), it is best to stop the test and switch it to the developer for testing, and immediately modify the problems found, this is because the cost of testing personnel is high, and the progress of repeated interactions will be delayed. We recommend that you establish a pre-test system: conduct spot checks on the core modules before the system test. If there are many problems (for example, each core module finds more than 10 defects on average), you can stop this test, the system test can be started only when fewer problems are found after the test.

6. The number of testers is low. We recommend that you set up a daily training institution which is organized by each group for the first half an hour before the end of each day (this time is always time-consuming ), at this time, we will summarize the testing results of each day for each group and conduct discussions between the group and the group, which will help improve the testing skills.

7. Avoid having special skills in the hands of a single user. There are two main methods: the first is to establish a good learning environment within the tester, so that everyone can learn from each other, in this way, some special technologies won't be mastered by one person, and most members are willing to learn from each other and improve themselves. The second is to manage knowledge in the Organization, the technology is precipitated as knowledge, so that new employees can easily get started when taking over the work and quickly adapt to the environment through learning. In addition, you must pay attention to the standardization of work. For example, the formation of as many documents as possible can reduce the loss caused by employee resignation.

Disadvantages:

I like to test new projects, because I can discover many problems and have a pleasure. The more I test, the more I feel passionate, I will always have a good experience. However, this is my weakness. This means that when I encounter a stable project, I cannot use that test passion. Instead, I feel that the software is stable and there is no problem. It will subconsciously move closer to this goal, and the test results will not be able to complete the test task well.