Path:
Home >
GB/T >
Page217 > GB/T 38634.3-2020
Price & Delivery
US$2039.00 · In stock · Download in 9 secondsGB/T 38634.3-2020: Systems and software engineering - Software testing - Part 3: Test documentation
Delivery: 9 seconds. True-PDF full-copy in English & invoice will be downloaded + auto-delivered via email. See
step-by-step procedureStatus: Valid
| Std ID | Version | USD | Buy | Deliver [PDF] in | Title (Description) |
| GB/T 38634.3-2020 | English | 2039 |
Add to Cart
|
12 days [Need to translate]
|
Systems and software engineering - Software testing - Part 3: Test documentation
|
Click to Preview a similar PDF
Basic data
| Standard ID | GB/T 38634.3-2020 (GB/T38634.3-2020) |
| Description (Translated English) | Systems and software engineering - Software testing - Part 3: Test documentation |
| Sector / Industry | National Standard (Recommended) |
| Classification of Chinese Standard | L77 |
| Classification of International Standard | 35.080 |
| Word Count Estimation | 110,168 |
| Date of Issue | 2020-04-28 |
| Date of Implementation | 2020-11-01 |
| Quoted Standard | GB/T 38634.2 |
| Adopted Standard | ISO/IEC/IEEE 29119-3-2013, MOD |
| Issuing agency(ies) | State Administration for Market Regulation, China National Standardization Administration |
| Summary | This standard specifies the software testing documentation template. The test document is the output of the specified process in GB/T 38634.2 test process. This standard applies to testing in all software development life cycle models, and documentation templates can be used in any organization, project, or small-scale testing activity. This standard applies to, but is not limited to, testers, test managers, developers and project managers, especially those responsible for the governance, management and implementation of software testing. The documents described in this standard may be published in multiple versions. However, the handling of multiple versions of documents is outside the scope of this standard, as this is a configuration management issue. |
GB/T 38634.3-2020: Systems and software engineering - Software testing - Part 3: Test documentation
---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Systems and software engineering - Software testing - Part 3.Test documentation
ICS 35.080
L77
National Standards of People's Republic of China
System and software engineering software testing
Part 3.Test Document
2020-04-28 released
2020-11-01 implementation
State Administration for Market Regulation
Issued by the National Standardization Management Committee
Table of contents
Preface Ⅲ
Introduction Ⅳ
1 Scope 1
2 Compliance 2
3 Normative references 3
4 Terms and definitions 3
5 Organizational testing process documentation 6
5.1 Overview 6
5.2 Test policy 6
5.3 Organizational Testing Strategy 8
6 Test management process documentation set 12
6.1 Overview 12
6.2 Test plan 12
6.3 Test status report 17
6.4 Test completion report 18
7 Dynamic Test Process Document Collection 20
7.1 Overview 20
7.2 Test design specification 21
7.3 Test case specifications 23
7.4 Test procedure specification 27
7.5 Test data requirements 29
7.6 Test environment requirements 31
7.7 Test data preparation report 33
7.8 Test environment preparation report 34
7.9 Measured results 35
7.10 Test results 36
7.11 Test execution log 36
7.12 Test event report 38
Appendix A (informative appendix) Document overview and outline 41
Appendix B (Normative Appendix) The mapping between GB/T 38634.2 normative requirements and the information items of this part 48
Appendix C (informative appendix) Example overview 53
Appendix D (informative appendix) Test policy 54
Appendix E (Informative Appendix) Organizational Test Strategy 56
Appendix F (Informative Appendix) Test Plan 59
Appendix G (informative appendix) Test status report 70
Appendix H (Informative Appendix) Test Completion Report 73
Appendix I (Informative Appendix) Test Design Specification 75
Appendix J (Informative Appendix) Test Case Specification 81
Appendix K (Informative Appendix) Test Procedure Specification 86
Appendix L (informative appendix) Test data requirements 89
Appendix M (Informative Appendix) Test Environment Requirements 91
Appendix N (informative appendix) Test data preparation report 92
Appendix O (Informative Appendix) Test Environment Preparation Report 93
Appendix P (informative appendix) Measured results 94
Appendix Q (informative appendix) Test results 95
Appendix R (informative appendix) Test execution log 97
Appendix S (Informative Appendix) Incident Report 98
Appendix T (informative appendix) The mapping between this part and existing standards 99
Appendix U (informative appendix) Structure changes of this part compared with ISO /IEC /IEEE29119-3.2013 101
Reference 105
System and software engineering software testing
Part 3.Test Document
1 Scope
This part of GB/T 38634 specifies the software test document template. The test document is the output of the specified process in the GB/T 38634.2 test process.
Figure 1 gives an overview of the specific test documentation set.
This section applies to testing in all software development life cycle models. The document template can be used in any organization, project or small-scale testing activities.
This section applies to but is not limited to testers, test managers, developers and project managers, especially those responsible for governance, management and implementation of software testing.
The documents described in this section may be published in multiple versions. However, the handling of multiple versions of documents does not belong to the scope of this section, because it is a configuration management issue.
2 Compliance
2.1 Intended use
The requirements of this part are contained in Chapter 5, Chapter 6, and Chapter 7.This section provides many suitable for the entire software life cycle
Requirements for testing documents. Special projects or organizations may not need to use all the documents specified in this section. Therefore, the implementation of this part
Often includes selecting a set of documents suitable for the organization or project. Organizations can declare compliance with this part in two ways. full compliance or
Tailoring meets. Consistency requirements can be put forward for the organizations, projects, multi-supplier projects and services identified in the conformity declaration.
The information items declared in Chapter 5, Chapter 6, and Chapter 7 of this part correspond to the information items in GB/T 38634.2.Appendix B is the regulation
The normative appendix outlines the normative requirements for establishing the information items defined in Chapter 5, Chapter 6, and Chapter 7 of this part in GB/T 38634.2.
For ease of reference, each document in this section is described as a separate hardcopy document. The document title and content provided in this section can be
In order to modify (add, merge or rename), it is not necessary to use the nomenclature of specific records in Chapter 5, Chapter 6 and Chapter 7 to declare it
Compliance. If the document is not published but provided in electronic form, divided into separate documents or volumes, or combined with other documents into one document, the
Compliance with regulations for the document.
2.2 Types of compliance
2.2.1 Overview
The following types of compliance shall be declared, and the selected type of compliance shall be stated in the compliance document.
2.2.2 Full compliance
The minimum set of required information items is all the information items specified in Chapter 5, Chapter 6, and Chapter 7.
Note. Even if there is no declaration of full compliance with this section, you can also declare full compliance with the selected document.
2.2.3 Tailoring compliance
The test document content defined in Chapter 5, Chapter 6 and Chapter 7 can be based on GB/T 38634.2 and/or the specific organization or project
Need to be tailored. When tailoring is required, if the information item is not defined in Chapter 5, Chapter 6, and Chapter 7, a reason needs to be provided.
All tailoring decisions should document their reasons, including consideration of any applicable risks. Tailoring decisions should be approved by stakeholders.
Tailoring compliance can be achieved in the following ways.
a) Tailor the process and activities according to Chapter 2 of GB/T 38634.2 to determine the minimum test document set required;
b) Determine the minimum test documentation set required according to the needs of the specific organization and/or project;
c) According to specific organization and/or project needs, determine the minimum set of information items required in the document.
Note 1.In projects, especially those that use agile development methods, the documents in this section can be tailored to allow them to be replaced by others.
One way (such as oral or slide presentation) for compression or presentation.
Note 2.Different document names can be used, but when doing so and need to prove its compliance, usually between this part and local use
Line mapping to help with compliance assessment.
3 Normative references
The following documents are indispensable for the application of this document. For dated reference documents, only the dated version applies to this article
Pieces. For undated references, the latest version (including all amendments) applies to this document.
GB/T 38634.2 System and Software Engineering Software Testing Part 2.Test Process (GB/T 38634.2-2020,
ISO /IEC /IEEE29119-2.2013, MOD)
4 Terms and definitions
The following definitions and terms apply to this document.
4.1
results of testing
The behavior set or condition set of the test item, or the related data or condition set of the test environment that can be obtained as a result of the test execution.
Examples. output to hardware, changes to data, generation and display of reports, and sending of communication messages.
4.2
Coverage item
See test coverage item (4.15).
4.3
expected results
According to specifications or other sources, the expected behavior of the test item that can be obtained under specific conditions.
4.4
Feature set
The set of test conditions including the tested item can be collected from the aspects of risk, demand, function, model, etc.
Note. It may be all the features of the item (its full feature set), or a subset (functional feature set, etc.) identified for a specific purpose.
4.5
Incident report
Documentation of the occurrence, nature and status of the event.
Note. Event reports are also called exception reports, error reports, defect reports, error reports, problem reports, etc.
4.6
Organization level test specification
A document that provides information for an organization's testing. The information is not specific to a specific project.
Example. The most common examples of organization-level test specifications are organization-level test policies and organization-level test strategies.
4.7
Organizational testing strategy
Provide documentation of general requirements for performing tests for all projects in the organization, and provide details on how to perform tests.
Note 1.It is consistent with the organization-level testing policy.
Note 2.An organization can have multiple organization-level testing strategies to deal with projects with different backgrounds.
4.8
Product risk
The product may have the risk of defects in some specific aspects of its function, quality or structure.
4.9
Project risk
Risks related to project management.
Examples. manpower shortage, strict deadlines, changes in demand.
4.10
Regression Testing
A test executed after the test item or its operating environment is modified.
Note. The adequacy of the regression test case set depends on the test item itself and the modification of the test item or operating environment.
4.11
retest
Re-execute the test cases whose test results are "failed" to evaluate the effectiveness of corrective measures.
4.12
Test case
A collection of preconditions, inputs (including operations, if applicable), and expected results, used to drive the execution of test items to meet test goals,
Test objectives include correct implementation, error identification, check quality and other valuable information.
Note 1.The test case is the lowest test input level of the test sub-process. (That is, test cases cannot be divided into more detailed test cases)
Note 2.The prerequisites of test cases include test environment, existing data (such as database), software testing, hardware, etc.
Note 3.Input is the data information used to drive test execution.
Note 4.Expected results include passed criteria and failed checks.
4.13
Test case specification
A document set consisting of one or more test cases.
4.14
Test completion report
A summary report describing the completed tests.
Note. The test completion report is also called the test summary report.
4.32
Test strategy
Part of the test plan. Used to describe the method of testing a specific test item or test sub-process.
Note 1.Test strategy and organization level test strategy are different.
Note 2.The test strategy usually describes some or all of the following. the test practices used, the test sub-processes implemented, the retest and regression
Trial design technology and corresponding test completion criteria, test data, test environment and test tool requirements, and expectations of test deliverables.
4.33
Test tracking matrix
Documents, spreadsheets, or other automated tools used to identify related items in the documentation set and software (such as test-related requirements).
Note 1.The test tracking matrix is also called verification cross-reference matrix, demand test matrix, demand verification table, etc.
Note 2.Different test tracking matrices may have different information, formats and levels of detail.
4.34
test
A series of activities to discover and/or evaluate the attributes of one or more test items.
Note. Test activities can include test planning, preparation, execution, reporting and management activities, which are directly related to testing.
5 Organizational testing process documentation set
5.1 Overview
The organization-level test specification describes the information of the organization-level test and does not depend on the project. Typical examples of it in the organization-level testing process include.
---Test policy;
---Organizational testing strategy.
The complete template of the document will be explained in text in 5.2 and 5.3.Appendix A provides a short description for each document. Appendix D
And Appendix E respectively provide examples of test policies and project examples of organization-level test strategies.
5.2 Test policy
5.2.1 Overview
The testing policy defines the purpose and principles of software testing applicable within the organization. It defines what the test should be done, but does not elaborate
Explain how to perform the test. The test policy provides a framework for establishing, reviewing, and continuously improving the organization's test policy.
A.2.2 provides an overview of the organization-level test policy, and D.1 and D.2 provide examples to demonstrate how two different projects develop an organization-level test policy.
5.2.2 Document summary information
5.2.2.1 Overview
Document summary information is used to identify the document and describe the source and history of the document.
Note. If the content of the document is saved in an electronic form (such as a database), you can put the document information in the front or middle of the document.
5.2.2.2 Unique identifier of the document
Uniquely identifies the version of the document.
Example. The unique identifier may include the title, publication date, version, and/or status of the document (such as draft, reviewed, revised, final version).
5.2.2.3 Publishing organization
Explain the organization responsible for the preparation and release, possibly including the author.
5.2.2.4 Approval authority
Declare the designated personnel responsible for reviewing and signing documents (possibly in electronic form), as well as relevant review and management personnel.
5.2.2.5 Revision description
It is used to record the revision record of all the changes since the document was generated.
Example 1.A list should be included, including the unique identifier created for each document, the reason for the change relative to the earlier version, and the name of the person who made the change
And role descriptions.
Example 2.The reason for the change may include review comments, group review, and system changes. The change personnel may be the document author, project manager, and system administrator.
5.2.3 Introduction
5.2.3.1 Overview
Provide explanatory information about the surrounding and structure of the document.
5.2.3.2 Scope
Identify the coverage of the target area through the document, and describe all the inclusion relations, exclusion relations, assumptions and/or restrictions.
5.2.3.3 Reference documents
List referenced documents and identify repositories of system, software, and test information. These references can be classified as "external" references (from the organization
External) and "internal" references (from within the organization).
Example. Reference documents can be data from policies, plans, procedures, and other sources.
5.2.3.4 Glossary
A thesaurus is provided, which includes any terms, acronyms and acronyms used in the document.
Note. This part may be an appendix, or it may be another document that provides general vocabulary. The whole or part of the glossary can be online, and the first word
The list of parent abbreviations is also available online, in the form of a separate test-specific vocabulary or merged into a larger organizational vocabulary (not only
Only include vocabulary related to the test).
5.2.4 Test policy description
5.2.4.1 Test objectives
Describe the goals, objectives, and overall testing scope within the organization. State why the organization conducts the test and the goals they expect to achieve.
5.2.4.2 Test process
Determine the testing process on which the organization will be based. It may include a specific reference document that provides details of the testing process.
Example. GB/T 38634.2 is such a document. The details of the activities in the testing process can be described in more detailed testing process documentation.
5.2.4.3 Test organization structure
Determine the role and structure of the testing organization. It may be necessary to use a diagram to display the hierarchy of the test organization or a table to display specific information.
5.2.4.4 Tester training
Explain the training and certification required for personnel working in the testing organization.
5.2.4.5 Tester Ethics
Determine the organizational ethics that testers need to follow.
5.2.4.6 Standard
Explain the standards used within the testing organization.
5.2.4.7 Other related policies
Determine the policies that affect the testing organization.
Example. A policy statement might look like this. Testing needs to comply with the quality policy.
5.2.4.8 Measuring the value of testing
Explain how the organization determines the return on investment for testing. Determine the purpose of measuring the value of the test.
5.2.4.9 Test asset archiving and reuse
Explain the organization's position on the archiving and reuse of test assets.
5.2.4.10 Test process improvement
Explain the methods to ensure continuous improvement of the testing process.
5.3 Organizational testing strategy
5.3.1 Overview
An organization-level testing strategy is a technical document that provides guidance on how to test within the organization, for example, how to implement the test
The goals specified in the policy.
The organization-level testing strategy is a general document at the organizational level, which provides some scope of guidance for the project, but it is not aimed at specific
Body project.
For small or highly similar organizations, a single organization-level testing strategy may cover all testing activities. in case
An organization develops in a series of obviously different ways, it may have more than one organization-level testing strategy, for example, the organization also has security
Key products and safety non-critical products, or using the agile V-model development model at the same time, may also be large enough to have its own strategy.
If there is no separate test policy, the organization-level test policy can include the content of the test policy.
An organization-level testing strategy includes the identification of related sub-processes and the corresponding strategy description. If each test sub-process corresponds to the strategy
If the instructions are completely different, the organization-level test strategy document may be divided into multiple sub-parts to correspond to each independent test sub-process. specific
The description is shown in Figure 2.
A.2.3 gives an overview of the organization-level test strategy. E.1 and E.2 give two different project examples to demonstrate how to use
Organizational testing strategy.
5.3.3 Introduction
5.3.3.1 Overview
Provide explanatory information about the surrounding and structure of the document.
5.3.3.2 Scope
Identify the coverage of the target area through the document, and describe all the inclusion relations, exclusion relations, assumptions and/or restrictions.
5.3.3.3 Reference documents
List referenced documents and identify repositories of system, software, and test information. These references can be classified as "external" references (from the organization
External) and "internal" references (from within the organization).
Example. Reference documents can be data from policies, plans, procedures, and other sources.
5.3.3.4 Glossary
A thesaurus is provided, which includes any terms, acronyms and acronyms used in the document.
Note. This part may be an appendix, or it may be another document that provides general vocabulary. The whole or part of the glossary can be online, and the first word
The list of parent abbreviations is also available online, in the form of a separate test-specific vocabulary or merged into a larger organizational vocabulary (not only
Only include vocabulary related to the test).
5.3.4 Organization-level test strategy description of the project scope
5.3.4.1 Overview
The policy defines the specified scope. This article mainly includes some strategic requirements, these requirements for all test sub-subjects of a given project
The process is suitable and all within the scope of the strategy. If necessary, this article may also include part of the policy.
5.3.4.2 General risk management
Explain general risk management methods used to guide testing activities.
5.3.4.3 Test selection and priority
Introduced the organization to select and determine the priority of test execution by prioritizing test procedures. Test procedures include priority test cases,
These use cases are obtained from the priority feature set through priority test conditions and coverage items.
5.3.4.4 Test Document Set and Report
Identify the documents that the entire test project is expected to generate during testing. Introduce the time of completion of each document and the related approval process.
This document is closely linked to the testing process specified in the policy.
5.3.4.5 Test automation and tools
Describes the automated testing methods within the organization. Determine the test tool used during the test.
Examples. may include test management tools, test execution tools, performance testing tools, information security testing tools, and usability testing tools.
5.3.4.6 Configuration management of test work products
Explain the configuration management to be implemented for the work products under test; explain how to identify, track and store these work products
And provide it to stakeholders.
5.3.4.7 Event management
Explain how to manage events during testing, or quote other descriptions.
5.3.4.8 Test sub-process
Identify specific test sub-processes that are executed as part of the test and are within the scope of the strategy.
5.3.5 Organizational test strategy description of specific sub-processes
5.3.5.1 Access and access criteria
Specify a criterion for the point in time at which the test activities of a defined test sub-process should be started and stopped.
A test sub-process includes the following processes.
---Test design and implementation;
---Establishment and maintenance of test environment;
---Test execution;
---Test event report.
Different access and access criteria can be defined separately for each sub-process, or some sub-processes can be selected for definition, or it can be
Define the entire sub-process as a whole.
5.3.5.2 Test completion criteria
Introduce how the organization judges that the test activity of the test sub-process has ended.
5.3.5.3 Test Document Set and Report
Determine the test document set used to test the test activities of the sub-process, including test reports.
Describes the preparation time of each document or report and the related approval process. This is closely related to the testing process stipulated by the policy.
5.3.5.4 Degree of independence
Establish the level of independence of the personnel performing the test. Explain how the test team achieves technical, management and financial autonomy.
5.3.5.5 Test design technology
Determine the specific test design techniques used during test design and implementation in the test sub-process.
5.3.5.6 Test environment
Determine the test environment for the test sub-process; it can explain where to perform the specific test type, and explain the team or
者organization. It can also indicate the source of the test data, the location of the special type of test data, and the team or organization responsible for the test data.
5.3.5.7 Metrics to be collected
Describes the metrics for which values need to be collected in the activities of the testing process.
5.3.5.8 Retest and regression test
Determine the strategies, conditions and activities used in the retest and regression testing of the test sub-process.
6 Test management process documentation
6.1 Overview
The documents developed in the test management process include the following types.
---Test Plan;
---Test status report;
---Test completion report.
The full document template with explanation can be found below. Appendix A provides a brief description for each document. Appendix F~
Appendix H provides examples of test plans, test status reports, and test completion reports for sample projects.
6.2 Test plan
6.2.1 Overview
The test plan describes the decisions made during the initial planning and is re-planned as part of the control activities.
The test plan provides a ...
...
