Functional test report

Original link: https://my.oschina.net/niepanLs/blog/3010204

Based on the " do not write test reports, how to stand out from the test team ," " write functional test report of " self-summary written. 

The summary more growth!

What is a test report?

1, Description: refers to the process of testing and the results of written documentation of the findings and defect analysis, provide the basis for remedying the problem of software quality, while laying the foundation for acceptance and delivery of software.

ps.

• [Testing and analysis of the test results, as well as on-line license]
• [In fact, the content of the test report templates are basically those, but in the actual testing process, usually the reader how to organize content structure, making the report: developers, test managers, product managers, project leaders would like to be able to see at a glance to understand the content of the test report is the most noteworthy]

2, components:

• Outline
• Test Range
• Testers
• Test progress
• Test Results
• Defect Analysis
• Test results (in short: whether to allow on-line)

 

Functional test report basic information is as follows:

1, introduction

1.1 Background

This test report xx system test report, this report aims to sum up the testing process and test results of the test phase of the analysis, whether the purpose of describing the system requirements.

The report is expected to participants, including testers, test managers, project managers, SQA personnel and other quality control personnel, development, operation and maintenance, product.

ps.

• Test manager: the write control test report is correct and complete.
• Operation and maintenance: the test results to determine whether the line can be.
• Product: Test range covers the entire demand.

pps.

• Test plan: written test supervisor. 
• Test Report: Test to write (write good or bad, reflects the value of one of their own).

1.2 References

1. "Requirements specification"
2. "Prototype map"
3. "Defect records"
4. "Test case"
5. "Test Plan"
6. Etc. (basically contains the software development life cycle stages, all of the output documents)

2, testing the basic information

2.1, the test range

Test Range

product	Module	Sub-module	Features	Test Points	priority	Test Engineer

ps.

• Test points: not the same as the test case title;
• Priority: you must be familiar with the needs to understand what is the core, basic, secondary;
• Test range (from product specifications, demand, e-mail, sales, implementation, customer service ......)

pps.

• No single product is 100% bug-free.
• Guarantee without departing from the demand, relatively plain bug does not appear.
• Accidental bug, the bug can not guarantee that will not dig there.

2.2, test case design ideas

Test case design ideas

Test Type	Test case design methods and ideas
function test	Reference documentation requirements, the use of equivalence classes, boundary value, the scene method, error estimation method to write test cases and test.
UI testing	Reference prototype drawing on page copy, links, pictures, icons, etc. interface testing
Compatibility Test	Use IE8,9,10, chrome, firefox mainstream browser compatibility test (according to the kernel to distinguish different browsers)

2.3, the test environment

• Hardware environment
• Software Environment
• Network topology

3, test results and defect analysis [Highlights]

3.1, the implementation and testing records

3.1.1 Test Organization

Testing Organization

project manager	Software Engineer (Development)	Test Engineer	Business leader (Product Manager)

• Software / Test Engineer: all the developers / testers, even if only output one line of code to be written on (online have a problem, need to refer to these people).

3.1.2, the test time

test stage	plan Starting time	plan End Time	actual Starting time	actual End Time	Planned effort (person / day)	Actual workload (person / day)

• Derived from the test plan. Test start time: start measuring mention.
• Functional testing, interface testing, test report need to write separate article just functional test report.

3.1.3, smoke situation

Smoke test	time	Whether by	If not passed, please write the reason

• After mentioning that measure, as long as there is any problem, we must mention the bug.

3.1.4, test statistics

The total number of cases	The number of executable	The number of unexecuted	The number of successful	The number of failures	Case success rate

• The total number of cases: the total number of use cases, the total number for all writing.
• Executable:
• Not taken: test environment interface barrier. This is rarely the case.
• The number of cases of successful success rate = / executable number.

3.2 defects Statistics and Analysis

• Defect Summary: This lists the actual number of defects found, the number of solved defects, number of defects remaining (unresolved defects).
• Defects: defects found during testing by defect type, severity classification statistics: defects found during testing of its functionality step by step, stage test for statistical analysis software defects tendencies and the main reason.
• Residual defects and unresolved issues affecting the situation of the remaining functions of the system defect analysis: unresolved issues impact on the project.
• We recommend the use of "bug state statistical" Report Analysis bug.

3.2.1 defects summary

{Pie chart, may be derived from tapd}

The project found that the total number of defects: X, the number of defects resolved: X, the number of residual defects: X.

3.2.1, defect analysis

3.2.1.1, by defect type:

{pie chart}

The project has x number of functional problems, and secondly, there are x-page optimization, safety-related, design flaws there are x, x number of others have. The bug comes from a large number of functional modules, accounting for xx%, there are x number of optimization problems, reaching xx%.

3.2.1.2, by severity:

{pie chart}

The disadvantage of this project, a large number of defects is a general, a small part belongs to optimize defect, very few serious flaws.

3.2.1.3, distributed by function:

{pie chart}

bug occurs in the x, x, x ... module mostly small portion at x, x, x module

3.2.1.4, according to the testing phase:

{pie chart}

Smoke test V1.1, the first round of V1.1, V1.2 second round, a third round of V1.3, bug occurs in a large number of V1.1, V1.2 least partially, V1.3 little

4, test results and recommendations

4.1, risk analysis and recommendations

Risk: test environment interface barrier, can not be changed frequently xx module bug rate in the test environment test test time constraints demand higher

4.2, test results

The project according to business needs and feedback from developers, product managers, covering all the test requirements, all cases have been completed in a test environment to verify xx.

Xx a total effective cases, the implementation rate of xx%, the success rate of xx%, to close the defect rate of xx%, current defect had been repaired and back off.

Unresolved bug (deferred treatment, will not be resolved, we will not deal with, etc.) and have product managers, development engineers to communicate, do not affect the basic functions of this on-line.

In summary, xx project, version Vxx, reach xx projects to test on-line standards, you can publish.

Note, when the demand is not clear: product manager must go, do not know where to understand, to get an accurate inaccuracies, can not take place is not clear Chu perform the test, write test cases.