Getting Started with beginners: Software testing starts from scratch (author: Wang Wei)

Getting Started with beginners: zero-based software testing

Author: Wang Wei

This article is for the novice software testing, from the pre-test preparation, test requirements collection, test case design, test case execution, test results analysis several aspects of the recommendations and methods. In view of the current situation of software development and testing in China, this paper provides several software testing focus points for novice software testing.

"keywords" software testing, test cases, test requirements, test results analysis

　　 Introduction

A few years ago, after graduating from school, the first job was software testing. At that time, most of the domestic software companies have no concept of software testing, bookstore in addition to Zheng written "Computer Software testing Technology", almost no other software testing related books, software testing only in the software engineering textbooks as a chapter listed, therefore, I know nothing about software testing. However, before formally embarking on the job, the company provides a two-week system of software testing technology special training, for the next software testing work has a great guiding significance. Now, I continue to engage in software testing training and consulting services, in the process, witnessed a lot of software testing novice faced with the confusion, they first involved in the software testing industry, no system training, no knowledge of software testing, neither know what to test, and do not know how to start testing. Here are a few solutions to the above situation.

　　 Test prep Work

At the beginning of the test, the software Test engineer should figure out what the purpose of the software testing work is. If you give this question to the project manager, he will often answer: "Discover all the bugs in our product, that's what you're working for." As a novice in software testing, how can I find all the bugs? How do I start a test job? Even in the face of a very small software project, testing needs to consider all aspects of the problem, including the hardware environment, operating system, product software configuration environment, product-related business processes, the user's concurrent capacity and so on. Where should we start?

　　 learn from experienced testers

If you enter a operating standard software company, has an independent software testing department, standardized software testing process, software testing technology has a certain accumulation, then, congratulations! You can ask the Test manager to appoint an experienced tester as the business mentor for your work, which lists the software test technology related books catalogue, the software test process documentation catalog, the product business-related documentation catalog, and is familiar with the work of the software testing under the guidance of the business mentor. In fact, in many of the operating standards of the software companies, the above-mentioned Master apprentice way to solidify into the process.

If you enter a software testing a blank software enterprise, then, also congratulate you! You can start your own software testing business here, of course, if the boss does realize the importance of software testing, the real need to improve the quality of the product. At this time, can go to the domestic Software Testing forum and related websites to find software testing resources, in this case, self-learning ability and the understanding of technology is crucial.

　　 read the books about software testing

Now, the Chinese version of the software test books more and more, some people write their own, there are some translation of foreign classics. You can find books related to software testing at the site of www.chinapub.com or www.cnforyou.com and other online purchase books. At present, the software test books introduced from abroad have many classics, but, after translating into Chinese, the quality of translation has a great influence on the reading effect.

　　 problem Report form in the daytime Defect tracking library

If your company already has a software defect tracking library, it doesn't matter whether you are using tools such as ClearQuest, Testdirecter, or Bugzilla, Mantis and other open source tools, which are valuable in the defect tracking library. The problem report in Defect Tracking Library is a concentrated embodiment of the performance of software test engineers, and also the focus of software PRODUCT problems. In general, the most critical parts of the Defect report form include: The first part is the environment that discovers the defect, including the software environment, the hardware environment, etc. the second part is the basic description of the defect, and the third part is the developer's solution to the defect. By careful analysis of the three parts of the defect report, you have already absorbed the work experience of other software testers and mastered the common basic problems of software products. This is a good way to quickly improve the experience of software testing.

　　 Historical test cases for the related products of the daytime

If your company has a test case management system, the software test cases for day-related products are a quick way to quickly improve the design of test cases. The daytime test case is also tricky. Test case writing typically includes test case items and test cases that are refined based on the test case items, as illustrated below. The "Test User Login feature" is a test item that is designed to test whether the user is logged on correctly, is able to perform normal logon functions, is able to handle illegal user names and passwords, and so on. Therefore, according to this use case item, you can design several test cases, in most cases, test case items and test cases are a one-to-many relationship.

With the daytime test case project, you can learn which feature points should be used for the future testing work, and through the daytime software test case, you can understand how to carry out the design work of the software test cases according to the function points tested, including how to determine the input of the test case, the procedure of the test case and the output of the test case.

In short, the excellent software test cases designed by other software testers are a good way to improve the design level of their use cases.

　　 Learn about product-related business knowledge

Software testers should not only master the knowledge of software testing technology, but also learn about the business knowledge related to the product. This is very good understanding, if engaged in the financial software testing work, must study the financial knowledge, if engaged in the communication product test work, then the related communication theory knowledge also must, if is engaged in the Bank software test, the bank's business process is also the indispensable knowledge point.

Therefore, in the study of software testing technology at the same time, do not neglect product-related business knowledge learning. If you are a software testing technology experts, but the knowledge of the product business, then can only test out the pure software defects, and the face of the present product business-related defects, it is likely to be blind, and so on, the effect of software testing will be greatly discounted.

　　 Identify test requirements

Identifying test requirements is the first step in software testing. It would be nice if the developer was able to provide complete requirements documentation and interface documentation. You can design test cases according to the input, process, and output of each feature item described in the requirements document. What if the developer does not provide documentation for the software requirements? Here are a few effective ways to do this:

　　 proactively acquire demand

Developers often do not consider software testing better, and if there are no mandatory requirements for the development process, they are usually reluctant to provide any development documentation, and even if there is a requirement, the requirements document may not really guide the software system testing effort. As a result, testers need to be motivated, communicate with the relevant software development project managers and software developers, understand what the main features of the software implementation are, and record the information collected. In general, even if the developer does not provide the relevant requirements documentation, it will save some simple process documentation and proactively ask the developer for these documents, which can be used as a reference for testing. In addition, can communicate with the company's technical support staff, technical support staff is the most close to the user, therefore, through communication can get first-hand user experience, in the process of testing will be more close to the user.

When you get the relevant information, where do you analyze the requirements? How do I communicate with developers about requirements? In fact, as long as the need to grasp a few key points of demand analysis can solve the problem: input, processing, output, performance requirements, operating environment, the following for each project analysis:

Software input: All possible inputs related to this requirement can be considered in terms of input source, number of input parameters, Unit of measurement of input parameters, time requirement of input parameters, accuracy of input parameters and valid input range of input parameters. In a test case design, this part of the content is used as the basis for the test case input.

Process: Describes all the operations performed on the input data and how to get the output. Testers understand the process can be, in the testing process to find the BUG, if the process of understanding in depth, to locate the source of the problem is a great help.

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

Performance requirements: Performance requirements related to this requirement, such as "after inserting an ATM card, a graphical interface prompting the user for withdrawals is displayed within 3 seconds." 3 seconds This limit is the basic performance requirement for demand.

Operating environment: The environment required for the operation of the software, including requirements of the hardware platform, operating system requirements, database requirements, and other related supporting software requirements.

　　 identify the priority of the requirement

It is necessary to confirm the priority of the requirements, if the product progress is tight, the tester can consider the priority test priority requirements, if the progress is allowed, then in the test of low-priority requirements, if the progress is not allowed, then discard the test priority low requirements. If a software company has a normative process support, the developer should prioritize the requirements in the documentation when providing documentation for the software requirements. But how can developers be expected to prioritize software requirements if they don't even provide the basic software requirements documentation? If so, the priority of the requirement can only be done by the tester.

　　 Join the Development Group Mail Group

Testers need to be proficient in the product being tested, but the product is often constantly changing during development. If the software development team has a set of change control processes, testers will be familiar with the product changes. If there is no change control, then other soil methods will be used. If the company has an automated office system, perhaps using a Lotus Notes system, perhaps the use of an e-mail system, testers should be added to the developer's Mail group. When the developer discusses the issue through the mail, notifies the technical meeting, the tester can know in time, if necessary, can participate in the developer's technical meeting. Even with the software change control process in the company, it's a good practice to join the development Mail group.

　　 neighbor to the developer

It is recommended that testers and developers be neighbors. My Test team was with the development team in the adjacent writing room, the developer and the tester's relationship is very harmonious, cast off the colleague relations, everyone is a good friend. Regardless of the developer's activities, testers are able to get information the first time. Whether engaged in software testing work, or engaged in other work, with the work of the upstream and downstream colleagues to maintain a good personal relationship to the work has great convenience. In general, there are departmental walls inside the company, and good interpersonal relationship is one of the means to get through the department wall. It is necessary to suggest to the leader that testers and developers are neighbors.

test Case Design

After the test requirements have been collected, test the design. What are test cases? A test case is a document that describes an input, action, or time, and an expected result, to determine whether an application's characteristics work properly. The following questions need to be considered for designing test cases:

　　 basic format for test cases

The basic elements of a software test case include a test case number, a test title, an important level, a test input, an action step, and an expected result, described below.

Use Case number: The number of test cases has certain rules, such as the number of system test cases to define the rule: project1-st-001, the naming convention is the project name + Test phase type (System test phase) + number. Define test case numbers to facilitate the search of test cases and facilitate the tracking of test cases.

Test title: A description of the test case, and the test case title should clearly express the purpose of the test case. For example, "when the user enters the wrong password when logging in, the software responds."

Important level: Defines the priority level of the test case, which can be broadly divided into "high" and "low" two levels. In general, if the software requirement has a high priority, the test case priority for that requirement is also high, and vice versa,

Test input: Provides various input conditions in the test execution. The input to the test case is determined based on the input criteria in the requirement. The input of the test case is very dependent on the input of the software requirements, and if there is not a good definition of the input of the requirements in the software requirements, then the test case design will encounter a great obstacle.

Action steps: Provides steps for testing the execution process. For complex test cases, the input to the test case is divided into several steps, which are detailed in the procedure.

Expected Result: Provide the expected results of the test execution and the expected results should be based on the output from the software requirements. If the actual test results are inconsistent with the expected results during the actual testing process, the test does not pass, whereas the test passes.

The design of the software test case is mainly from the above 6 domains, combined with the corresponding software requirements document, can design a more comprehensive and reasonable test case on the basis of mastering certain test case design method. Specific test case design methods can be found in the relevant test books, white-box test methods and black-box test methods in the vast majority of software testing books are described in detail, here do not repeat.

　　 reuse test Cases for the same type of project

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

In general, each software company's project can be divided into a number of 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 into software structure, such as b/s architecture software, c/s architecture software, embedded software and so on. Reference to the same category of software test cases, there will be a lot of reference. If you have similar software systems in your company, don't forget to refer to the relevant test cases. If the system is very close, even simple modifications to the test case can be applied to the software currently being tested. "Take doctrine" can greatly open the test case design ideas, but also can save a lot of test case design time.

　　 using existing software checklist

In the above section, different software types are divided according to different rules. Each type of software has a certain test specification, for example, the WEB software system in the system testing process, there will be a series of paradigms, such as for the Cookie will have a lot of testing points. When designing test cases, it may be advisable to search the Internet for related checklist, but there is little information in this area at home and abroad, even if there is no special system. You can find a rough checklist, and then, in the design of the test case, constantly improve it as the basis for the next test case design.

　　 strengthen the review of test cases

After the test case is designed, it is best to increase the review process. Peer review is a CMM3 level of KPA, if because the company did not pass the CMM3 level, it is inappropriate to conduct peer review. Test cases should be reviewed by product-related software testers and software developers, submitted for review, and then updated with review comments. If you take this step seriously, many of the problems in the test case will be exposed, such as use case design errors, omission of use case design, redundancy of use case design, insufficient use case design, etc., if the peer review is not sufficient, in the process of test execution, the above should be found during the review phase of the test case-related issues, Can cause a lot of trouble to test execution, even causing test execution to hang.

　　 defining the order in which test cases are executed
　
During the test case execution, you will find that each test case has special requirements for the test environment or has a special impact on the test environment. Therefore, defining the order in which test cases are executed has a significant impact on the execution efficiency of the tests. For example, some exception test cases will cause the server to restart frequently, each time the server restarts will consume a lot of time, resulting in this part of the test case execution also consumes much time. Then in the orchestration of test case execution order, you should consider putting this part of the test case in the final execution, if the test progress is very tight, if the time to perform this part of the consumption of the exception test cases, the test execution time is too much, the test case execution progress is still slow, This will affect the mood of the testers, which leads to a hasty test of the subsequent test cases, so that the test case leakage, error detection is unavoidable, seriously affecting the software testing effectiveness and progress. Therefore, it is necessary to reasonably define the order of execution of test cases.

　　 test Case Execution

After the test case has been designed, the next task is to test execution, and the following questions should be noted in the test execution:

Build a software test environment and execute test Cases

During test case execution, setting up a test environment is the first step. In general, after the software PRODUCT is submitted for testing, the developer should submit a product installation guide detailing the software and hardware environment in which the product is running, such as requiring that the operating system is a Windows PACK4 version, the database is SQL Server 2000, and so on, in addition, The detailed installation instructions for the tested software product should be given, including the installation procedure, the configuration method of the relevant configuration file and so on. For complex software products, especially software projects, if there is no installation guide for reference, in the process of building a test environment will encounter various problems.

If the developer refuses to provide the relevant installation instructions, the test staff can ask the developer for assistance when they encounter problems in the test, it is important to record the developer's approach to the problem, and avoid the same problems to consult the developers again, which will incur the resentment of the developers. It also lowers the level of developer acceptance of testers.

　　 questions to be aware of during test execution

After the test environment is built, the test cases are executed one by one, based on the defined test case execution order. There are several issues to be aware of during test execution:

Full-scale observation of test case execution results: During test execution, can the test case execution be considered successful when the actual output of the test is consistent with the expected output from the test case? The answer is no, even if the actual test results are consistent with the expected results of the test, check the operation logs, system run logs, and system resource usage of the SOFTWARE PRODUCT to determine if the test case is successful. All-round observation of the output of software products can reveal a lot of hidden problems. Before, when I was testing the embedded system software, after executing a test case, the actual output of the test case is exactly the same as the expected output, but when the CPU occupancy rate was found, the CPU occupancy rate was up to 90, and then after analysis, the software ran a number of 1ms timers, a lot of consumption CPU resources, and then by adjusting the timer to 10ms, the CPU occupancy rate dropped to 7. If the observation point is single, the problem of serious resource depletion can not be found.

Strengthen the test process record: In the test execution process, must strengthen the test process record. If the test execution steps are different from those described in the test case, be sure to record it as the basis for updating the test case later, and if the SOFTWARE product provides logging functionality, such as a software run log, a user action log, a log file must be logged after each test case is executed, as a test process record, Once the problem is discovered, developers can use these tests to record a convenient location problem. Instead of having testers rebuild the test environment, reproduce the problem for the developer.

Timely confirmation of discovered problems: During the test execution, if the software defects are identified, then you can submit the problem report form without hesitation. If you find a suspicious problem and cannot locate it as a software defect, be sure to keep the site and then notify the developer to locate the problem on the spot. If a developer can confirm a software defect for a short period of time, the tester will cooperate, and if the developer locates the problem takes a long time, the tester should not delay their valuable test execution time, can let the developer record the re-issue of the test environment configuration, and then, Return to your development environment to reproduce the problem and continue to locate the problem.

Good communication with developers: during test execution, when you submit a problem report, you may be ruthlessly dismissed by the developer and refuse to modify it. At this time, only to the developer of the rationale, to be rational, there is a basis, persuasive. First of all, to define the standard principle of software defects, this principle should be recognized by both developers and testers, without the principle of co-approval, then the developers and testers dispute the problem is inevitable. In addition, testers plan to persuade developers to consider whether they can convince themselves to start communicating with developers before they can convince themselves.

　　 Update test cases in a timely manner

During test execution, you should be careful to update your test cases in a timely manner. Often in the test execution process, only to find that some of the test cases are missing, it should be timely supplement, often also found that some test cases in the specific implementation of the process is simply unable to operate, this time should be removed from this part of the case, you will find a number of redundant test cases can be completely replaced by a test case, Then delete the redundant test cases.

In summary, it is good practice to update test cases in a timely manner during test execution. Do not plan to update test cases uniformly at the end of the test execution, and if so, many of the test cases that should be updated will be missed.

　　 submit an excellent problem report form

The software test submits the problem report form and the Test daily, is the software tester's work output, is the test personnel performance concentrated embodiment. Therefore, it is important to submit a good report on the issue. The most critical domain of the Software test report is the "problem description", which is the basis for the developer to reproduce the problem and locate the problem. The description of the problem should include the following parts: Software configuration, hardware configuration, test case input, operation steps, output, output information of the device at that time and related logs, etc.

Software configuration: Includes operating system type version and patch version, current tested software version and patch version, related support software, such as database software version and patch version.

Hardware configuration: The configuration of the computer, mainly including CPU, memory and the relevant parameters of the hard disk, and other hardware parameters according to the actual situation of the test case added. If the network is used in the test, then the network networking situation, network capacity, traffic and so on. The hardware configuration is closely related to the type of product being tested, and it is necessary to record the hardware configuration accurately according to the situation.

Test case input \ Action step \ Output: This section can be filled out according to the description of the test case and the actual execution of the test case.

Output device output information: Output devices including computer monitors, printers, tapes and other output devices, if the display can be captured in the way of capturing the time, other output devices can use other methods to obtain the relevant output, in the problem report sheet to provide a description.

Log information: The specification of the software products will provide the operation of the software log and the user, the administrator's operation log, the tester should be executed after the test case software product run logs and operations log as an attachment, submitted to the problem report form.

Depending on the software product being tested, it is necessary to add the corresponding description in the "Problem description", which requires specific analysis of specific problems.

　　 Test Results Analysis

After the software test execution is finished, the test activity is not finished. Test results analysis is an essential part of the "basket, all in the shell," the test results of the analysis of the next round of testing work has great reference significance. In the previous test preparation, it is recommended that the tester be in the daytime Defect tracking library to check for software defects found by other testers. After testing, you should also analyze the software defects that you find, classify the defects that you have found, and you will find yourself submitting only a few categories of issues, and then you will find that the other testers who have completed the test execution work together, and you'll see that the categories of questions you submit are different from theirs. This is normal, people's thinking is limited, in the process of testing, each tester has his own problem of thinking of the blind area and test execution of the blind area, effective self-analysis and analysis of other testers, you will find their blind area, a targeted analysis of the blind area, will be in the next round of testing to avoid blind area.

　　 Summary：

Limited to the length of the article, this article is not likely to give a checklist-like guidance of the introduction of software testing novice. Whether engaged in software testing or other work, technical and technological problems can be obtained by querying the relevant software testing technology books, master a set of basic methodology is the most important. The above text is the author's experience in the accumulation of software testing, such as the discovery of the fallacy of the place please do not hesitate to point out.

Reprint: http://www.yesky.com/43/1946543.shtml

Getting Started with beginners: Software testing starts from scratch (author: Wang Wei)