Software test design and software test parts management
This article is copyrighted by the Computer World News. Please be sure to ask the author to agree.
(Dai Jinlong Xie Min Shen Xuefang)
More and more software companies have realized that software testing in the important position in software quality management, and began to build their own software test team. This is undoubtedly a far-reaching significance for the improvement of software product quality and the medium and long-term development of the enterprise.
However, for a particular software project, how should the test team rationally plan to arrange software testing? How do I quickly improve the level of the next software project test after completing the test of a certain number of software projects? These two issues are very practical for software test teams that have just been established or established. The former is related to the software test design, belongs to "near worry"; the latter is related to software test parts management, belongs to "Watch". The purpose of this article is trying to "solve problems" for the person in charge of these test teams, providing decision-making reference views.
1. Do a good job in software test design, exclude "near worry"
As mentioned above, the test team establishes an ignition, and it will encounter such a problem: "How should I reasonably arrange software testing? Testing Technology Forestlin President, excessive testing will result in rising test costs, and insufficient testing will cause some important defects left in the project. Some companies' test supervisors have worked privately, I think this may have a certain universality. Indeed, it is necessary to have enough technical capabilities and actual experience to identify a specific software project. Some qualifications that Shangliang's test team need to help this, to solve the urgentity.
To answer this question, we must first talk from the "life cycle of software test activities". A typical software test activity is roughly divided into "test plan à test design à test execution à test summary and improvement" four links [Note: Some technical articles have increased a link after the test design is: test environment Construction, the author believes this is also a way to divide. Among them, the test plan session gives a macro guidance and budget for specific test activities, including: 1. Defining the demand item for the development team and user for testing; 2. Defining tests may experience the phase, test type, Testing the techniques and tools that are generally adopted, the test passes the standards, etc .; 3. Determine the test collaboration needs. If you need temporary experts, test progress and development schedule coordination, test activities and user existing interface relationships, etc .; 4. Rough estimation test needs. The simulation approximation can be made according to the data of the similar items, or it can be exported from the project size according to a certain algorithm; 5. Determine the resources required to be equipped with test activities (such as people, venues, hardware and hardware, etc.). The test design link is further refined and analyzed on the basis of the Test Plan "link, thereby developing a process for testing strategies, testing programs and test cases for each test activity. Typically, this part of the work proposed by the test personnel is quite high, and the parties that are the least easy to grasp, which will be discussed in detail below. The test execution is the output generated by the test design, performs the corresponding test activity, finds and reports the process of corresponding errors and defects, of course, including some open tests that do not use test examples, such as GUI testing, and more. The test summary and improvement is to collect the relevant test parts generated by the above three links (such as test documentation, test scripts, test tools and testing work lessons, etc.), incorporating the test team knowledge base for easy testing The team can better conduct test parts, thus promoting the continuous optimization and improvement of testing.
It is a brief introduction to the life cycle of the test activity. Need to be reminded that certain concepts may differ slightly in a particular area. For example, in some large projects, the document generated by the test plan is "test outline" and the high-level "software test plan", and the file generated in the test design link is for a system, a certain module underlayer Test Plan, Test Scheme, etc. These differences do not affect the discussion of test design and test parts management. With the front floor, we can start discussing the big problem of software test design. The test design is actually further refined to the high-level test plan (including test outline), which is specific to form a process for test strategies, test programs, and test cases for specific items.
1.1 test strategy design
The problem to be solved by the test strategy is based on test requirements, resource equipment and engineering environment, and form a technical route for testing work due to local prevention test technology. We know that it is not responsible for a small project to do a big test. Similarly, it is also irresponsible for a large project. Or more professional, for ordinary commercial software with less than 5 people, the key points should be used to capture system testing (including functional testing, performance testing, and GUI testing, etc.), instead of being lined up, face (such as design verification) Confirmation, code review and unit testing can be compressed as appropriate). For medium-sized commercial software for a workload close to 30 people, it is generally necessary to complete demand verification, design verification, unit testing, integration test, system testing, and acceptance testing, not only paying attention to system testing, ignoring other parts. The above discussion is the reference system with the number of people, this is not absolute. For example, user needs are often more important considerations. If users want software to have a good human-machine interaction interface, at this time, it should be considered to use the fast prototype generation tool to confirm the user interface design, and the user wants software There is better robustness, at this time, you should consider the corresponding load testing and recoverable testing. In addition, resource equipment is also important consideration. A team of very few team members must assume a software testing of a medium-sized project, which is almost impossible. However, the high level of individual enterprises can send such an unrealwerable task for cost consideration or technical insemination. At this time, negative dendering is the following policy, to make full use of test outsourcing, test collaboration (such as dividing personnel from other departments), put the priority relatively low part, leaving the core, the highest priority Some, organize testers for professional testing.
The test strategy design is an art, because it is a "thickness of" thickness "under the actual interaction of test experience and the actual interaction of specific project projects. It is multiple factors (test demand, test resource allocation, project size, similar project test strategy reference, etc. The result of the integrated role. It is very difficult to do design work for testing strategies. A good test strategy design should be able to answer the following questions: (1) Do you have the best balance between test costs and test expectations? (2) Whether to achieve the best balance between test requirements and test activity arrangements? (3) Is the technical route formed by the policy design to achieve the best balance between the actual quality of the project and the company's quality committee? (4) Does the technical route formed by the strategy design are feasible? Is there a design basis? and many more. For a more shallow test team, it may be difficult to achieve this realm in the early stage of the team. However, there is no need to worry too much and worry. With the accumulation of different project testing experience, many obstacles will gradually eliminate, which will eventually reach the realm of "chest".
1.2 test plan design
After testing strategy design, the test work technology route for a specific project is formed. The next test team entered the design phase of the test plan. The test solution is further refined to the technology route. For a certain technical route, a small software project test work must focus on "Function Test and Acceptance Test". Then the test plan design phase must define which features need to be tested and how to test, which part (software? User manual? Operating guide) needs to do acceptance and use in what form to do an acceptance test (Review? BETA test? Or Live testing? Etc.). The design of the test solution should be fully considered in the cost and technical feasibility in addition to the various attributes of the objects, executives, test progress, and release standards of each test activity. A good test program always follows the following design principles: (1) The effectiveness of test costs and testing work is in an optimum ratio; (2) The specific test activities are clear, the target is clear, the content is complete; (3) test means It is feasible; (4) The result of the test can be used to guide the product quality improvement. The author noted that some companies had a misunderstanding of subsection (3), and a batch of automated test tools that blindly purchased, but they did not understand operation, or they were not suitable for their development environment. These issues should work hard during the design of the test plan.
In the specific design of the test scheme, some problems and obstacles are often exposed. The most common thing is to have more roles, and less testers. The fundamental way to solve this problem is to recruit test talents and build an efficient test team. However, far water is not thirsty. If your test team encounters such embarrassment, then you need to consider the change of the changes: the outsourcing and outsourcing and outsiders mentioned earlier are a good treatment. In addition, it is recommended that you consider automatic test tools, certain tools do reduce your working pressure (such as automatic integration tools to achieve daily construction, pressure test tools can alleviate the pressure you write simulated concurrent programs). In addition to the problem of human hand, it is also important to understand the expertise of each member of your test team. Some project test programs are designed very well, but due to lack of corresponding quality test team members to take the corresponding roles in the test plan, the test plan can only be stranded indefinitely, and the result can't. In addition, the test plan designer should also refer to the software development management class document, which is synchronized with the development of time schedule, and should be synchronized with the development of development. If the development schedule changes, the corresponding test schedule should be adjusted in time.
1.3 test case design
The test case design is more meticulous to implement the technical part of the test solution. The relevant design technology has been relatively mature [Note: Some branches of the current test case design are still research hotspots]. On the market, the theoretical work on test cases is also dazzling. The following table lists various types of test case design techniques, and the author does not intend to introduce one by one, but select several representative methods based on test practices and personal orientations, for readers for reference. Interested readers can further refer to some books.
Projects and Category Black Box Test (Functional) White Box Test (Structured) Other Common Reference Unit Interfaces and Functions Description Specifications Documents, do not need to understand the internal structure of the measured unit; reference detailed design specifications documentation, control code, test How to work inside the mesh; emphasize personal experience, speculation or select a method of selecting special values. Specific Category Software Design Export Test Equivalence Class Division Boundary Value Analysis Decision Table Drive Test Causes Based on State Test ... Path Test Control Structure Test Logic Overlay Insert ... Error Guess Special Value Test
Among them, the use of equivalence classification methods commonly used in black box testing is as follows:
First divide the input domain of the program into several intervals, then select a few representative data as a test case from each interval. Since the number is too large, the exhaustive test is generally impossible to implement, so we tend to choose a part from a large number of possible data as a test case. When using equivalence classification methods, two equivalents are usually involved: effective equivalents and invalid equivalents. As the name suggests, the effective equivalence class is the specific reasonable input data set for the specification; invalid equivalence class is an input data set for unreasonable or invalidation of the program specification manual. We should take into account these two situations when designing test cases. At the same time, pay attention to a test case can only cover an invalid equivalence class. This makes it easy to position to prevent another error from covering another error. For example, the specifications of the program are specified in the specification of the program, ... "each type of technology book 10 to 50, ..." Not a science and technology book), and ignore the number of books (5 is not 10 to 50). Another commonly used test case design method in black box test is a boundary value analysis. Its thinking is as follows:
Boundary value analysis is a test case design technology for supplemental equivalence classification, which selects a set of test cases to check whether the boundary value is in line with the corresponding specification. Because the boundary of the input domain is more prone to errors than the middle, we introduce boundary value analysis methods that often find more software defects and errors.
The steps of using boundary value analysis are: Select the boundary value of the equivalence class -> Export the test case from the input domain.
[Example] A is a real number, between 10 and 100, use the method of boundary value analysis to design test data.
The test data is: 9.9, 10.1, 20, 99.9, 100.1.
Regardless of the black box test, it may ignore the logical error, potential destructive execution process, redundant program code or simple typing error, while white box testing can further discover them, find out the code hierarchical error And defects. White box test case design includes a wide variety, here the author only introduces the path test method.
Before designing the path-related test case, you should first analyze the inner logical structure of the program: find the execution portal of the program, then track the various branch statements and judgment statements experienced in the program, until the exit of the program. Then set a different case test case for each branch and judgment statement, and sequentially traverse, and a finer sub-case is sequentially sequentially sequentially sequentially, and the sequence is sequenced until the program ends or arrives at the outlet. Careful readers may find that this method is actually arranged and combined with various possible conditions of branch and judgment statements in the program body. For small program modules, this is feasible, however, for more complex program modules (especially for exceptions frequently used frequently in the object language, this method is minimal. Therefore, many variants such as functional point coverage, statement coverage are thus derived from this method. These methods have better reference value for designing white box test cases.
2, do a good job in software test parts, eliminate "happiness"
How to effectively manage the test parts, which is one of the important factors affecting the efficiency of the test team and the overall level. In the case where the project is small and less functional, the test work may be normal, but if the test team should test multiple projects at the same time, the scale of each project is relatively large, and there are many testers involved, in this case Under the efficiency of testing, the efficiency of testing may be greatly reduced: If the tester finds the test script when performing an automated test, the test data is sometimes mismatched at all, or many defect reports are actually repeated. and many more. These typical low-efficiency events are mostly caused by the management of test parts. In addition, the test parts management have an increasing long-term significance for the overall level of the team. If a test team does not analyze after completing a project's test work, it will not be accumulated, the test case, test plan, etc. will not be accumulated, then this team may be in a lower level, can't Migrating similar items to the current project, and new members of the test team cannot obtain the knowledge accumulation of the previous people through the test parts management library. So, how should the test team do a good job in testing? Before talking about this problem, you must first understand the concept of the test piece. In this article, the test parts generally refer to all input and output data (including team self-developing test automation) that must be controlled or worth inclusive in the test team knowledge base in all manual testing and automated test activities. Its epitaxial can be represented by the following figure:
Tester test input test output test outline test plan test case test script scheme policy specification document test tool test record test summary test results defect report test work log test analysis data test evaluation data project experience and lessons
In the above test parts, automated management has been better implemented: test case automation management, test defect (report) tracking management. In addition to this test piece, there is no corresponding dedicated management tool, and the author recommends that the configuration management tool (such as CVS) is used to complete the automation management of them. Below, the author will briefly introduce these automation management tools. [Since the test defect tracking management is discussed in detail in the second topic, this part of this part is omitted. ]
2.1 Test case management system
A medium-sized test software, there is often tens of thousands of test cases, and if not specifically managed, testers will soon be submerged in the ocean of test documents and test cases. Test case designers need to understand which modules or components have been designed. Which modules or component test cases are required to design, and the test executive needs to be explicitly told. "What I want to test today? How much do you need to implement? Test case? ", Etc. Based on these needs, people have developed a test case management system. The purpose of using this system is to manage the efficiency of test activity to improve the design, implementation and execution results of the project's test case.
There are a lot of test case management systems (such as minimally invasive test case management systems, etc.), readers in need can choose to purchase on the basis of completing market research. The author simply introduces a general process of the test case management system.
A typical test case management system adopts the following workflow: Set basic parameters → login system → Select item → New module node → New demand → Add test case → audit test case → Add test group → new test plan → Execute test → test results View → statistical analysis. The roles involved include test team leaders, test designers, test executives, system administrators, test reviewers, and more. Among them, the test designer has permission to write test cases, and the test executive is responsible for the implementation of test cases, which is the main body of the test case management system.
2.2 Configuration Management
In addition to test cases, testments other than test defect reports can be managed using configuration management. There are two optional configuration management methods here.
One is to save the logical set of the test piece (referred to as a test piece) as a configuration item in the configuration library (that is, packing the test packet into a file). Each test piece group has its own version information, and the various test parts that make up the test piece group do not have its own version information. The tester can remove any version of the test piece group (including the modified and unmodified test) that you have modified and unmodified by the modified and unmodified test items can be removed from the configuration library as needed. Because this way is simple, and the possibility of an error version of the test piece is relatively small, it applies to the configuration of the management system is immature or just enabled. Another way is to use a single test piece as a configuration item, each test piece has its own version information. This approach needs to be baselined on the test set or multiple test components. Through baseline operation, it is convenient for testers to take out all test parts corresponding to different versions of the system. This approach can be used in this way, which may result in a version of the test parts that is used, so this approach is suitable for situations with a relatively complete configuration management system.
Regardless of the way we use it to configure it, we have to pay attention to the update of the test parts. If the configuration management system is not perfect, then set some simple rules to avoid two or more people attempt to modify the same configuration item.
With regard to the storage of the test parts, it should be noted that the physical location of each test piece must be specified in the configuration library. If the first management method is used, it is necessary to specify the directory hierarchy in each test piece group to avoid unnecessary reconstruction when file copying and movement.
2.3 Reuse and migration of test parts
Another more important value of the test parts management work is that the test piece can be reused, and the experience and knowledge containing the test piece can be obtained and migrated to the current project later. The overall level of test team is largely increasingly effective in team internal knowledge transfer. Since the test parts management library records the test technology adopted by each project, this is a very valuable resource for the newcomers in the team, even for the old man who has worked for many years, it should also refer to this knowledge. The library, because the reuse of the test can effectively avoid duplication of labor. In addition, it is recommended that the person in charge of the test team brings a lot of ways to learn, learn and use the test parts library, and encourage team members to improve the test parts.
