Software testing, starting from scratch: Required for beginners

Introduction

A few years ago, after graduating from school, my first job was software testing. At that time, most software companies in China had no idea about software testing. In addition to the Computer Software Testing Technology compiled by Zheng Renjie, there were almost no books related to software testing in the bookstore, software testing is only listed as a chapter in software engineering textbooks. Therefore, I have no idea about software testing. However, before the formal start of the job, the company provided a two-week system software testing technology training, which will be of great guiding significance for the next software testing work. Now, I continue to engage in software testing training and consulting services. In this process, I have witnessed the confusions faced by many new users who are involved in the software testing industry, no system training, no knowledge of software testing, no knowledge of the test or how to start the test. The following are some solutions for the above situation.

O test preparation

At the beginning of the testing work, the software testing engineer should understand what the purpose of the software testing work is. If you submit this question to the project manager, he will often answer the following question: "discovering all bugs in our products is your purpose ". As a beginner in software testing, how can we discover all bugs? How do I start testing? Even if you are dealing with a very small software project, the problems that need to be considered for testing are also in all aspects, including the hardware environment, operating system, software configuration environment of the product, product-related business processes, user concurrency capacity, and so on. Where should I start?

O learn from experienced testers

If you are in a software company with standardized operation and have an independent software testing department, standardized software testing procedures, and software testing technology, congratulations! You can ask the test Manager to assign experienced testers as your business mentor, he will list the directories of software testing technology-related books, software testing process-related documents, and product business-related documents. He will be familiar with software testing under the guidance of his business mentor. In fact, many software companies with standardized operating standards have solidified the above-mentioned Master's apprenticeship approach into the process.

If you are in a software enterprise with a blank software test, congratulations! You can create your own software testing business here. Of course, the premise is that the boss truly realizes the importance of software testing and actually needs to improve the quality of the product. At this time, you can go to software testing forums and related websites in China to find software testing resources. In this case, the self-learning ability and understanding of technology are crucial.

O reading software testing books

Nowadays, there are more and more software test books in Chinese versions, some of which are written by Chinese people and some are translated as foreign classics. You can go to www.chinapub.com or www.cnforyou.com to find books related to software testing. At present, many software testing books have been introduced from abroad, but after being translated into Chinese, the translation quality has a great impact on the reading effect.

O Report Form in the read-only defect tracking database

If your company already has a software defect tracking library, whether it uses commercial tools, such as ClearQuest, testdirecter, or open-source tools such as Bugzilla and mantis, this is irrelevant. The defect Report Form in the defect tracking database is valuable. The problem report form in the defect tracking database is a centralized embodiment of the performance of software testing engineers, and also a centralized embodiment of software product problems. In general, the most important parts of the defect report form include: The first part is the environment for discovering the defect, including the software environment and hardware environment; the second part is the basic description of the defect; the third part is how the developer solves the defects. By carefully analyzing the three parts of the above defect report, you may have absorbed the experience of other software testers and mastered the common basic problems of software products. This is a good way to rapidly improve software testing experience.

O historical test cases for read-only products

If your company has a test case management system, reading the software test cases of related products is a shortcut to quickly improve the test case design level. Reading Test cases are also skillful. Test Case writing generally includes test case items and test cases refined according to Test Case items. The following is an example. "Test the user login function" is a test item. The purpose of this test item is to test whether the user login function is correct and whether the normal login function can be completed, whether to handle exceptions for illegal user names and passwords. Therefore, a number of test cases can be designed based on the test case items. In most cases, the test case items and test cases are one-to-multiple relationships.

Through the read-only test case project, you can master the functional points from which you should start future testing. Through the read-only software test cases, you can learn how to design software test cases based on the functional points to be tested, including how to determine test case input, test case operation steps, and test case output results.

In short, reading the excellent software test cases designed by other software testers is a good way to improve their own test case design level.

O learn product-related business knowledge

Software testers should not only master the knowledge of software testing technology, but also learn product-related business knowledge. This is a good understanding. If you are engaged in financial software testing, you must learn financial knowledge. If you are engaged in communication product testing, the relevant communication theoretical knowledge is also necessary; if you are engaged in testing banking software, the banking business process is also an indispensable knowledge point.

Therefore, when learning software testing technology, do not ignore the learning of product-related business knowledge. If you are a software testing technical expert but have no knowledge about the product business, you can only test pure software defects, and face the existing product business-related defects, it is likely to be a blind eye. In this way, the effect of software testing will be greatly reduced.

O recognition test requirements

Identifying test requirements is the first step in software testing. It would be nice if developers could provide complete Requirement documents and interface documents. You can design test cases based on the input, processing, and output of each function project described in the requirement document. If a developer does not provide a software requirement document, what should I do? The following are several effective methods:

O actively obtain requirements

Developers generally do not better consider Software Testing. Without the mandatory provisions of the development process, they are generally reluctant to provide any development documentation, even if there are mandatory provisions, the requirement document may not really guide the software system testing. Therefore, testers must exert their own initiative to communicate with relevant software development project managers and software developers, understand the main functions of software implementation, and record collected information. In general, developers save some simple process documents even if they do not provide the relevant requirement documents, and take the initiative to ask the developers for these documents, which can be used as a reference for testing. In addition, you can communicate with technical support staff of the company. Technical support staff are the closest people to users. Therefore, you can get first-hand user experience through communication, the test process is closer to the user.

When relevant information is obtained, what are the requirements analyzed? How can I communicate with developers? In fact, as long as you grasp the key points of requirement analysis, you can solve the problem: input, processing, output, performance requirements, and running environment. The following analyzes each project one by one:

Software input: all possible inputs related to the requirement, input Source, number of input parameters, measurement unit of input parameters, time requirements of input parameters, accuracy of input parameters, and valid input range of input parameters. In the test case design, this part serves as the basis for test case input.

Processing: describes all the operations performed on the input data and how to obtain the output. The tester can understand the handling process. When a bug is found during the testing process, it is of great help to locate the root cause of the problem if they have an in-depth understanding of the handling process.

Software output: Describes the output results of each requirement, including the output location (such as computer monitors, printers, files ), number of output parameters, measurement unit of output parameters, time sequence of output parameters, accuracy of output parameters, valid output range of output parameters, and error messages. In the test case design, this part serves as the expected output of the test case.

Performance requirements: performance requirements related to this requirement, such as "a graphic interface prompting users to withdraw money within three seconds after an ATM withdrawal card is inserted ". The limit of 3 seconds is the basic performance requirement.

Operating Environment: environment required for software running, including requirements for hardware platforms, operating systems, databases, and other supporting software.

O confirm the priority of the requirement

It is necessary to confirm the priority of the requirement. If the product progress is tight, the tester can consider the priority of the requirement items with high testing priority. If the progress permits, if the progress of a requirement item with a low testing priority is not allowed, the requirement item with a low testing priority will be abandoned. If a software company has standardized process support, developers should determine the priority of the requirement when providing the software requirement document. However, if developers do not provide basic software requirement documents, how can they determine the priority of software requirements? In this case, the priority of the requirement can only be completed by the tester.

O Contact Groups added to the development team

Testers need to be familiar with the tested products. However, the products are constantly changing during development. If the software development team has a set of change control procedures, testers will be familiar with product changes. If there is no change control, it is necessary to adopt other soil methods. If the company has an automated office system, the Lotus Notes system may be used, or the e-mail system may be used. The tester should join the developer's contact group. When developers discuss issues by email and notify technical meetings, testers can be informed in time and participate in technical meetings of developers if necessary. Even if the company has a software change control process, joining the Development Contact Group is also a good habit.

O adjacent to developers

It is recommended that the testing staff be adjacent to the development staff. My test team was once in an adjacent office with the development team. The relationship between the developers and the testers was very harmonious. I am a good friend of everyone. Regardless of the activities of developers, testers can obtain information immediately. Whether engaged in software testing or other work, maintaining a good personal relationship with colleagues in the upstream and downstream links of the work is very convenient for the work. Generally, a company has a department wall. Good interpersonal relationships are one of the ways to break through the department wall. It is necessary to recommend the testing staff to be adjacent to the development staff.

O Test Case Design

After the test requirements are collected, start the test design. What is a test case? A test case is a document that describes input, action, or time, and an expected result. The purpose is to determine the application.ProgramWhether a feature of is working normally. To design a test case, consider the following:

O basic format of Test Cases

The basic elements of a software test case include the test case number, test title, importance level, test input, operation steps, and expected results.

Test Case Number: the number of test cases have certain rules, such as the number of the system test case definition rules: PROJECT1-ST-001, naming rules are the project name + test phase type (system test phase) + id. Define the test case number to facilitate searching for test cases and tracking test cases.

Test title: description of the test case. The title of the test case should clearly express the purpose of the test case. For example, "test the software response when a user enters an incorrect password upon Logon ".

Important level: defines the priority level of test cases, which can be divided into two levels: "high" and "low. Generally, if the priority of a software requirement is "high", the priority of the test case for this requirement is also "high"; otherwise,

Test input: provides various input conditions for test execution. Determine the input of the test case based on the input conditions in the requirement. The input of test cases is highly dependent on the input in the software requirement. If the input in the software requirement is not well defined, a great obstacle will be encountered in the test case design.

Operation Procedure: Provides steps for testing and execution. For complex test cases, the input of test cases must be completed in several steps, which are listed in detail in the operation steps.

Expected results: provide the expected results for test execution. The expected results should be obtained based on the output in the software requirements. If the actual test results are inconsistent with the expected results, the test fails. Otherwise, the test passes.

The design of software test cases is mainly based on the above six fields, combined with the corresponding software requirements documents, on the basis of understanding certain test case design methods, A comprehensive and reasonable test case can be designed. For specific test case design methods, see relevant test books. White-box test methods and black-box test methods are described in detail in most software test books.

O reuse test cases of the same type of project

If I look far away, it is because I stand on the shoulders of giants-Newton.

Generally, each software company's project can be divided into several fixed categories. Can be divided by business type, such as ERP software, Product Data Management Software, communication software, geographic information system software, etc.; can be divided by software structure, such as B/S architecture software, C/S architecture software, embedded software, and so on. It is of great significance to refer to the test cases of software of the same category. If the company has similar software systems, do not forget to use the relevant test cases for reference. If the system is very similar, you can even apply the software that is currently being tested after a simple modification to the test case. "Ism" can greatly broaden the idea of test case design and save a lot of test case design time.

O use existing software Checklist

In the preceding section, different software types are divided according to different rules. Each type of software has certain testing specifications. For example, a Web software system has a series of paradigms during system testing. For example, there will be many testing points for cookies. When designing test cases, you may wish to search for related checklists on the Internet. However, there are very few domestic and foreign websites that have such materials. Even if there are such materials, they are not special systems. You can first find a rough checklist, and then constantly improve it when designing test cases to serve as the basis for the next test case design.

O enhance the review of test cases

After the test case is designed, you are advised to add a review process. Peer review is a kPa of the Level 3 CMMs. It is inappropriate for the company to conduct peer review if it fails to pass the Level 3 CMMs. Test cases should be reviewed by product-related software testers and software developers, submitted for review comments, and updated based on the review comments. If you carefully perform this step, many problems in the test cases will be exposed, such as incorrect use case design, missing use case design, redundant use case design, and inadequate use case design. If your peer reviews are inadequate, in this case, the problems related to the test cases that should have been found during the review phase during the test execution process may cause great trouble to the test execution and even cause the test to be suspended.

O Define the execution sequence of Test Cases

During the execution of test cases, you will find that each test case has special requirements on the test environment or has a special impact on the test environment. Therefore, defining the execution sequence of test cases has a significant impact on the test execution efficiency. For example, some abnormal test cases cause frequent server restart, which consumes a lot of time for each restart, resulting in a lot of time for this part of test case execution. When arranging the execution sequence of test cases, you should consider putting these test cases at the end of the execution. If the test progress is very tight, if the execution of this part of the time-consuming abnormal test cases is prioritized, the progress of the test case execution is still slow when the test execution time is over half, which affects the mood of the test personnel, this will lead to the rush to test the subsequent test cases. This will inevitably lead to missed or missed test cases, seriously affecting the software testing results and progress. Therefore, it is necessary to reasonably define the execution sequence of test cases.

O test case execution

After the test case is designed, test execution is the next step. During the test, pay attention to the following issues:

O build a software test environment and execute test cases

Building a test environment is the first step during test case execution. Generally, after a software product is submitted for testing, the developer should submit a product Installation Guide to specify the software and hardware environment for running the software product in details, for example, the operating system is required to be Windows 2000 pack4 and the database is SQL Server 2000. In addition, detailed installation instructions for the tested software products should be provided, including installation steps and configuration methods of related configuration files. For complex software products, especially software projects, if no installation guide is provided as a reference, various problems may occur during the establishment of the test environment.

If the developer refuses to provide relevant installation instructions, the tester can ask the developer for help when a problem is encountered during the Setup test. At this time, the developer must record the solution to the problem, avoid asking developers for the same question again, which will lead to developers' dislike and reduce developers' acceptance of testers.

O precautions during testing and execution

After the test environment is set up, the test cases are executed one by one based on the execution sequence of the defined test cases. Pay attention to the following issues during testing:

Comprehensive Observation of test case execution results: when the actual test output result is consistent with the expected output in the test case, can the test case be considered successful? The answer is no. Even if the actual test result is the same as the expected test result, check the operation log, system operation log, and system resource usage of the software product, to determine whether the test case is successfully executed. A comprehensive observation of the output of software products can discover many hidden problems. In the past, when I tested embedded system software and executed a test case, the actual output of the test case was exactly the same as the expected output, but when querying the CPU usage location, it was found that the CPU usage was as high as 90%. Later, after analysis, several 1 ms timers were started during software operation, consuming a lot of CPU resources. Later, by adjusting the timer to 10 ms, the CPU usage is reduced to 7%. If the observation point is single, this serious resource consumption problem cannot be found.

Enhanced test process records: During the test execution, the test process records must be enhanced. If the test execution steps are different from those described in the test cases, they must be recorded as the basis for updating the test cases in the future. If the software product provides the log function, for example, software running logs and user operation logs must be recorded after each test case is executed as a test process record. Once problems are found in the future, developers can easily locate problems through these test records. Instead of setting up a new test environment for testers to reproduce the problem.

Identify detected problems in a timely manner: If Software defects are identified during testing, you can submit a report without hesitation. If a suspicious problem is detected and the software defect cannot be identified, the site must be retained and relevant developers should be informed to locate the problem on site. If the developer can confirm whether the problem is a software defect within a short period of time, the tester should cooperate. If it takes a long time for the developer to locate the problem, testers should never delay their valuable test execution time, so that developers can record the problematic test environment configuration, return to their development environment to reproduce the problem, and continue to locate the problem.

Good communication with developers: when a problem report is submitted during the test execution, the developer may reject the change. At this time, developers can only be rational, well-founded, and persuasive. First, we need to define the standard principles of Software defects, which should be recognized by both developers and testers. If there is no principle of mutual acceptance, the dispute between developers and testers is inevitable. In addition, before the tester tries to persuade the developer, he wants to determine whether to persuade himself first and then start communicating with the developer on the premise that he can persuade himself.

O Update test cases in a timely manner

During the test execution, you should promptly update the test cases. Some test cases are often missed during the test execution process. At this time, they should be supplemented in a timely manner. Sometimes, some test cases cannot be operated during the specific execution process, this part of cases should be deleted at this time. Some redundant test cases can be completely replaced by one, so redundant test cases can be deleted.

In short, it is a good habit to update test cases in a timely manner during test execution. Do not update the test cases after the test execution is completed. In this case, many test cases that should be updated are often omitted.

O submit an excellent problem report

Similar to the daily report, the issue report submitted for software testing is the work output of Software testers and is a concentrated embodiment of the testing staff's performance. Therefore, it is important to submit an excellent problem report. The most critical field of the software test report is "Problem description", which is the basis for developers to reproduce the problem and locate the problem. The Problem description should include the following parts: software configuration, hardware configuration, test case input, operation steps, output, output information of the current output device and related logs.

Software Configuration: includes the operating system version and patch version, the version and patch version of the currently tested software, and related supporting software, such as the database software version and patch version.

Hardware configuration: computer configuration, including CPU, memory, and hard disk parameters. Other hardware parameters are added based on the actual conditions of the test case. If the network is used in the test, the network networking, network capacity, traffic, and so on. The hardware configuration is closely related to the type of the tested product. You need to accurately and accurately record the hardware configuration based on the current situation.

Test Case input, operation steps, and output: This part can be filled in based on the description of the test case and the actual execution of the test case.

Output device output information: the output device includes a computer display, printer, tape, and so on. If the display is used, capture the screen to obtain the current information, other output devices can use other methods to obtain relevant outputs and provide descriptions in the problem report.

Log information: standard software products provide software operation logs and user and administrator operation logs. Testers should use the software operation logs and operation logs after the test cases are executed as attachments, submit it to the problem report form.

According to the different software products to be tested, you need to add the corresponding description in the "Problem description", which requires specific analysis of the problem.

O Test Result Analysis

After the software test is completed, the test activity is not completed. Testing Result Analysis is an essential part. "All the baskets are collected." The analysis of testing results is of great reference for the next round of testing. In the previous "test preparation", it is recommended that the tester read the defect tracking database and check the Software defects found by other testers. After the test, you should also analyze the Software defects you have found. For the types of discovered defects, you will find that the problems you have submitted are only fixed in a few categories. Then, summarize the problems found by other testers who have completed the test execution. You will find that the types of problems you have submitted are different from those of them. This is normal. human thinking has limitations. During the testing process, each tester has a blind zone for thinking about the problem and a blind zone for testing and execution, effective self-analysis and analysis of other testers, you will find your own blind spots, targeted analysis blind spots, will certainly be used in the next round of testing to avoid blind spots.

Summary:

LimitedArticleThis article does not provide a guide similar to checklist to get started with software testing. Whether engaged in software testing or other work, technical and technical problems can be obtained by querying relevant software testing technical books. Mastering a basic methodology is the most important. The above are the experiences accumulated by the author who is engaged in software testing. If you find any mistakes, please leave it blank.