Abstract: The test report documents the test process and results, analyzes the problems and defects found, and provides a basis for correcting the quality problems existing in the software, it also lays the foundation for Software acceptance and delivery. This article provides a test report template and an example guide on how to compile it.
Keyword test report Defect
Body
The test report is the Final Document Output in the test phase. A good test Manager should be able to write documents. A detailed test report contains sufficient information, including Product Quality and test process evaluation, test report based on test data collection and final test result analysis.
The following uses a general test report template as an example to describe how to write a test report.
Part I Homepage
0.1 page content:
Confidentiality level
Generally, the test report is used after the internal test is completed, so the confidentiality level is medium. If the test report is available to users and more users, the confidentiality level is low, highly classified test reports are suitable for internal R & D projects and projects involving the confidentiality Industry and Technology copyrights.
XXXX Project/System Test report
Report No.
Internal numbers available for the index or serial numbers required by the user for distribution submissionDepartment Manager ______ Project Manager ______
Development Manager ______ test Manager ______ XXX company XXXX Organization (this includes the user organization and the company that develops the system)
Xxxx-xx
0.2 format requirements:
The title is generally roughly formatted as a single character (for example, a single character), bold,, and centered
The subtitle is roughly a small one (such as No. 2) bold,, and centered
Other words are in the center of the group.
0.3 version control:
Version author time change Summary
New/changed/reviewed
Part II Introduction
1.1 Writing Purpose
The purpose of this test report is to indicate the intended audience.
Example: This test report is a test report of the XXX project. It aims to summarize the testing results in the test phase and describe whether the system meets the requirements (or achieve the xxx functional goals ). Expected reference personnel include users, testers, developers, project managers, other quality management personnel, and senior managers who need to read this report.
Tip: Generally, users are interested in the test conclusion. Developers want to obtain the product development quality information from the defect results and analysis, the Project Manager attaches great importance to the cost, resources, and time of testing, and the senior manager hopes to read simple charts and compare them with other projects in the same direction. This section describes the specific reason why a person of the type can refer to chapter XXX on the xxx page of this report. The more readers you report, the more important your work will be, the premise is that you must make readers feel that your reports are valuable and worth a little time to pay attention.
1.2 Project Background
Briefly describe the project objectives and objectives. If necessary, a brief history is included. This part does not require mental work and can be copied directly from the requirement or tender documents.
1.3 SYSTEM INTRODUCTION
If the design specification has this part, copy it. Note that the necessary framework and network topology are eye-catching.
1.4 terms and acronyms
List the terms and acronyms used to design the system/project. Technical Terms and synonyms must be clearly stated so that no ambiguity can be found during reading.
1.5 references
1. requirements, design, test cases, manuals, and other project documents are all references within the scope.
2. National Standards, industry indicators, company specifications and quality manuals used for testing, etc.
Part III test Overview
A Brief Introduction to the test, including the Declaration, test scope, and purpose of the test, mainly the test description. (Other test Manager and quality personnel attention)
2.1 Test Case Design
This section briefly introduces the design of test cases. For example, Division of equivalence classes, boundary values, causal factors, and the use of such methods (3-4 sentences ).
Tip: If you can describe the design, it is easy for other developers and test managers to have a general concept for your case design. By the way, it is also advantageous to write some unconventional design methods here. At least you can understand the design technology of the test manager before seeing the test conclusion, the key test part must have two or more different use case design methods.
2.2 test environment and Configuration
This section briefly introduces the test environment and its configuration.
Tip: The list is as follows. If the system/Project is large, list it in a table. Database Server Configuration
CPU:
Memory:
Hard Disk: available space
Operating System:
Application Software:
Machine Network Name:
Lan address:
Application Server Configuration
.......
Client Configuration
....... You can also use the corresponding table for network devices and requirements. For a three-tier architecture, you can list the relevant configurations based on the network topology.
2.3 testing methods (and tools)
This section briefly describes the methods (and tools) used in the test ).
Tip: it is mainly black box testing. The testing method can be written into the testing focus and the testing mode, so that you can clearly know whether important testing points and key blocks are missing. The tool is optional and should be described when the test tool and related tools are used. Pay attention to whether it is a self-production or manufacturer, and the version number. After the test report is released, you must avoid copyright issues for most tools.
Part IV test result and Defect Analysis
This is the most exciting part of the test report, which summarizes various data and measures, measurement includes the measurement and Capability Evaluation of the test process, the quality measurement of software products, and the product evaluation. For projects that do not require process measurements or are relatively small, such as submitting user test reports during acceptance and testing reports for small projects, process measurements can be omitted; if CMM/ISO or other engineering standard processes are used, test reports that require process improvement suggestions and references-primarily used for internal testing improvement and defect prevention mechanisms-are listed as process measurements.
3.1 test execution and records
Describe the test resource consumption and record the actual data. (Test and Project Manager attention)
3.1.1 testing organization
A simple test group architecture diagram can be listed, including:
Test Group architecture (such as grouping and user participation)
Test Manager (lead)
Major testers
Participants
3.1.2 test time
Lists the test span and workload. It is best to differentiate the test document and activity time. Data is available for process measurements.
For example, xxx sub-system/sub-function
Actual Start Time-actual End Time
Total working hours/total working days
Total task start time and End Time Total
For large systems/projects, the total investment of resources should be counted in the end. If necessary, the cost column should be added so that managers can clearly know how much manpower they have spent to complete the test.
Testing personnel cost tool equipment other fees Total
When collecting data, you can calculate the average input time and total time of an individual, the average input time and total time, and the time/person spent at each function point.
Total number of test cases written by the person in use Total
The data used for process measurement includes document productivity and test execution rate.
Productivity use cases/Write Time Use Cases/average execution time Total
3.1.3 test version
The version of the test is provided. If it is the final report, it is possible to report the number of tests and the number of regression tests. Listing the table list makes it easy to know the test frequency of that subsystem/sub-module. For subsystems/sub-modules with multiple regression, this will attract developers' attention.
3.2 coverage analysis
3.2.1 requirement coverage
The requirement coverage rate refers to the ratio of tested requirements/functions to all requirements/functions in the requirement specification, which usually reaches the goal of 100%.
Requirement/function (or number) test type passed remarks
[Y] [p] [N] [N/A]
Based on the test results, the conclusion of passing each test requirement is given by number. P indicates partially passed, N/A indicates that the test is not available or the use case is not applicable. In fact, the demand tracking matrix lists the one-to-one cases to avoid omission. This table serves to convey the test information of the requirement for inspection and review.
Requirement coverage rate: Y items/total demand count × 100%
3.2.2 test coverage
Demand/function (or number) Use Case count execution not executed/missed test analysis and causes In fact, the test cases have recorded the expected results. The test defects indicate the data of the tested results and the deviation from the expected results; therefore, there is no need to include more detailed descriptions of defect records and deviations for each number here. The purpose of the list is to better view the test results.
Test Coverage Rate Calculation executions/Total cases × 100% 3.2 defect statistics and analysis
Defect statistics mainly involve the quality of the tested system. Therefore, this Part has become the focus of developers and quality personnel.
3.3.1 Summary of defects
Tested system test regression test total Total
By severity
Severe, minor By defect type
User interface consistency function algorithm interface document User Interface others Distribute by function
Function 1 function 2 function 3 function 4 function 5 function 6 function 7 It is best to give a pie chart and column chart of the defect for intuitive viewing. As the saying goes, a chart is better than a thousand words. The icon allows readers to quickly obtain information. In particular, managers at all levels do not have time to read articles one by one. Legend
3.3.2 Defect Analysis
This section comprehensively analyzes the defects and other collected data.
Comprehensive Defect Analysis
Defect discovery efficiency = Total number of defects/during testing
Average indicators can be obtained by specific personnel
Case Quality = Total number of defects/total number of test cases × 100%
Defect density = Total number of defects/total number of functional points
Defect density can be used to obtain the distribution of Defects of various functions or requirements of the system. Based on this analysis, developers can find that the most functional/demand defects are found, in this way, you should avoid and pay attention to the implementation of future development. test experience shows that the more defects there are, the more hidden defects there are.
Test Graph
Describe the number of defects in the tested system every working day/week to obtain the trend and trend of defects. Summary of Important Defects
Defect No. Brief description analysis result remarks 3.3.3 residual defects and unsolved problems
Residual Defects
No.: Bug no.
Defect Summary: facts described by the defect
Cause Analysis: describes how to cause defects, the consequences of defects, and the causes of software limitations and other restrictions.
Preventive and improvement measures: compensatory measures and long-term strategies
Unsolved Problems
Function/test type:
Test results: deviations from the expected results
Defect: Detailed Description
Comment: What are the impacts of these problems?
Part V test conclusions and suggestions
This section is a summary of the report. After analyzing the above process and defects, this section is divided into the project manager, department manager, and senior manager. Please make a clear conclusion.
4.1 test conclusion
1. test execution (security, reliability, maintainability, and functionality can be added)
2. control measures and effectiveness of test risks
3. test whether the target is completed
4. test whether the application passes
5. Can I enter the project objectives of the next stage?
4.2 suggestions
1. Describe the Software defects and Deficiencies exposed by the test, and the possible impact on the implementation and operation of the software.
2. Potential defects and follow-up work
3. Suggestions on Defect modification and Product Design
4. Suggestions for process improvement The content of the test report is similar. For some test reports, Parts 4 and 5 may be merged to list test items, defects, Analysis and Suggestions one by one. This method is also common, this template is for reference only, especially in third-party evaluation reports.
References:
Practical Software Testing Methods and Applications: E-Industry Press |
