翻译：测试成熟度模型集成（TMMi）（12）

PA 2.2 Test Planning
PA 2.2 测试计划
Purpose
目标
The purpose of “Test Planning” is to define a test approach based on the identified risks and the defined test
strategy, and to establish and maintain well-founded plans for performing and managing the testing activities.
测试计划的目标是在已识别的风险和已定义的测试策略基础上定义测试方法，并建立和维护有依据的计划来执行和管理测试活动。
Introductory Notes
介绍性说明
After confirmation of the test assignment, an overall study is carried out regarding the product to be tested, the
project organization, the requirements, and the development process. As part of test planning, the test approach is
defined based on the outcome of a product risk assessment and derived from the test strategy. Depending on the
level and type of risks, it is decided which requirements of the product will be tested, to what degree, how and
when. The objective is to provide the best possible level and type of coverage to the parts of the system with the
highest risk level. Based on the test approach the work to be done is estimated and as a result the proposed test
approach is provided with clear cost. The product risks, test approach and estimates are defined in close cooperation
with the stakeholders. Testers should not take these decisions themselves. The test plan will either
confirm, or explain non-compliance, with the test strategy. Within test planning, the test deliverables that are to be
provided are identified, the resources that are needed are determined, and aspects relating to infrastructure are
defined. In addition, test project risks regarding testing are identified. As a result the test plan will define what
testing is required, when, how and by whom. Finally, the test plan document is developed and committed upon by
the stakeholders. The test plan provides the basis for performing and controlling the testing activities. The test plan
will usually need to be revised, using a formal change control process, as the project progresses to address
changes in the requirements and commitments, inaccurate estimates, corrective actions, and (test) process
changes.
在确认测试任务分配后，一个总体的学习要被执行，包括要测试的产品，项目组织，需求和开发过程。作为测试计划的一部分，来源于测试策略，并基于产品风

险评估，测试方法要被定义。根据不同的水平和风险类型，它决定哪些产品需求要测试，到什么程度，如何以及何时。目的是给系统的最高风险级别提供最有可

能的级别和覆盖类型。基于测试方法，已完成的工作要被评估，以此为结果，要提供费用清晰的建议测试方法。产品风险，测试方法和评估被定义在相关人员的

紧密合作上。测试人员不应该自己做决定。测试计划于测试策略一起，确认或者解释不遵守部分。在测试计划里，将要提供的测试交付被明确，需要的资源被确

定，基础设施的相关方面被定义。另外，测试计划风险被明确。因此，测试计划将会定义测试需要什么，什么时候测，如何测以及由谁来测。最后，测试计划文

档有相关人员制定和实施。测试计划为执行和控制测试活动提供了依据。测试计划通常需要加以修订，使用正式的变更控制流程，随着项目的进展，以解决需求

和承诺的变更，不准确的估计，纠正措施的变化，以及（测试）过程中的变化。
Scope
范围
The process area “Test Planning” involves performing a product risk assessment on the test object and defining a
differentiated test approach based on the risks identified. It also involved developing estimates for the testing to be
performed, establishing necessary commitments, and defining and maintaining the plan to perform and manage the
testing. A test plan is required for each identified test level. At TMMi level 2 test plans are typically developed per
test level.
测试计划过程域包括执行测试对象的产品风险评估，在已确定风险基础上定义不同的测试方法。它也包括将要执行的测试的开发评估，建立必要的承诺，定义和

维护计划以执行和管理测试。测试计划需要每个明确的测试级别。在2级TMMi，测试计划被制定在在每个测试级别上。
Specific Goal and Practice Summary
具体目标和实践综述
SG1 Perform a product risk assessment
SP 1.1 Define product risk categories and parameters
SP 1.2 Identify product risks
SP 1.3 Analyze product risks
SG1 执行产品风险评估
SP 1.1 定义产品风险类别和参数
SP 1.2 确定产品风险
SP 1.3 分析产品风险
SG2 Establish a test approach
SP 2.1 Identify items and features to be tested
SP 2.2 Define the test approach
SP 2.3 Define entry criteria
SP 2.4 Define exit criteria
SP 2.5 Define suspension and resumption criteria
SG2 建立测试方法
SP 2.1 确定要测试的项目和功能
SP 2.2 定义测试方法
SP 2.3 定义进入标准
SP 2.4 定义退出标准
SP 2.5 定义中止和恢复标准
SG3 Establish test estimates
SP 3.1 Establish a top-level work breakdown structure
SP 3.2 Define test lifecycle
SP 3.3 Determine estimates of test effort and cost
SG3 建立测试评估
SP 3.1 建立高层工作分解结构
SP 3.2 定义测试生命周期
SP 3.3 确定测试投入和费用的评估
SG4 Develop a test plan
SP 4.1 Establish the test schedule
SP 4.2 Plan for test staffing
SP 4.3 Plan stakeholder involvement
SP 4.4 Identify test project risks
SP 4.5 Establish the test plan
SG4 制定测试计划
SP 4.1 建立测试时间表
SP 4.2 测试人员计划
SP 4.3 计划相关人员参与
SP 4.4 识别测试项目风险
SP 4.5 建立测试计划
SG5 Obtain commitment to the test plan
SP 5.1 Review test plan
SP 5.2 Reconcile work and resource levels
SP 5.3 Obtain test plan commitments
SG5 获得测试计划承诺
SP 5.1 评审测试计划
SP 5.2 调和工作和资源水平
SP 5.3 获得测试计划承诺

Specific Practices by Goals
目标的具体实践
SG 1 Perform Product Risk Assessment
SG 1 执行产品风险评估
A product risk assessment is performed to identify the critical areas for testing.
产品风险评估被执行来明确测试的关键区域
SP 1.1 Define product risk categories and parameters
SP 1.1 定义产品风险类别和参数
Product risk categories and parameters are defined that will be used during the risk assessment.
在风险评估期间使用的产品风险类别和参数被定义。
Typical work products
典型工作产品
1. Product risk categories lists
2. Product risk evaluation and prioritization criteria
1. 产品风险类别清单
2. 产品风险评估和优先级标准
Sub-practices
子实践
1. Determine product risk categories
A reason for identifying product risk categories is to help in the future consolidation of the test tasks
into test types in the test plans.
Examples of product risk categories include the following:
? Functional risks
? Architectural risks
? Non-functional risks, e.g. usability, efficiency, portability, maintainability, reliability
? Change related risks, e.g. regression
1. 决定产品风险类别
明确产品风险类别的原因是在未来测试任务变化时帮助进入测试计划的测试类型。
产品风险类别实例包括如下：
 功能性风险
 结构性风险
 非功能性风险，如可用性，有效性，可移植性，可维护性，可靠性
 变更相关的风险，如回退
2. Define consistent criteria for evaluating and quantifying the product risk likelihood and impact
levels
3. Define thresholds for each product risk level
2. 为评估和测量产品风险可能性和影响水平定义一致的标准
3. 定义每个产品风险级别的阙值
Risk level is defined as the importance of a risk as defined by its characteristics impact and likelihood.
For each risk level, thresholds can be established to determine the acceptability or unacceptability of
product risk, prioritization of product risks, or trigger of management action.
风险级别根据风险的重要性，其特有影响和可能性来定义。对于每个风险级别，阈值被建立以确定产品风险的可接受或不可接受，产品风险的优先级，或管理行

为的引发。
SP 1.2 Identify product risks
SP 1.2 明确产品风险
Product risks are identified and documented.
产品风险被明确和记录。
Typical work products
典型工作产品
1. Identified product risks
1. 明确产品风险
Sub-practices
子实践
1. Identify and select stakeholders that need to contribute to the risk assessment
2. Identify product risks using input from stakeholders and requirements documents
1. 识别并选择参与风险评估的相关人员
2. 利用相关人员和需求文档的输入明确产品风险
Examples of product risk identification techniques include the following:
? Risk workshops
? Brainstorming
? Expert interviews
? Checklists
? Lessons learned
产品风险识别技术实例包括如下：
 风险研讨会 脑力激荡 专家访谈 检查清单 吸取的经验教训
3. Document the background and potential consequences of the risk
4. Identify the relevant stakeholders associated for each risk
5. Review the identified product risks against the test assignment
3. 记录背景和潜在风险后果4. 确定每个风险级别的相关人员5. 审查测试任务已明确的产品风险
SP 1.3 Analyze product risks
SP 1.3 分析产品风险
Product risks are evaluated, categorized and prioritized using predefined categories and parameters.
利用预定义的类别和参数对产品风险进行评估，分类以及确定优先级。
Typical work products
1. Product risk list, with a category and priority assigned to each risk
典型工作产品
1. 产品风险清单，并附有分配到每级风险的类别和优先级
Sub-practices
子实践
1. Analyze the identified products risks using the predefined parameters, e.g. likelihood and impact
2. Categorize and group product risks according to the defined risk categories
3. Prioritize the product risks for mitigation
4. Establish a horizontal traceability between products risks and requirements to ensure that the
source of product risks is documented
5. Generate a requirements / product risks traceability matrix
6. Review and obtain agreement with stakeholders on the completeness, category and priority level
of the product risks
7. Revise the product risks as appropriate
Examples of when product risks may need to be revised include the following:
? New or changing requirements
? Change of the software development approach
? Lessons learned on quality issues in the project
1. 利用预定义的参数，如可能性和影响，分析已明确的产品风险
2. 通过已定义的风险类别，对产品风险分类，分组
3. 优先考虑产品风险缓解
4. 在产品风险和需求之间建立横向的追溯，以确定产品风险的源头被记录
5. 生成一个需求/产品风险的可追溯模型
6. 评审并获得相关人员在产品风险的完整性，类别和优先级方面的一致同意
7. 适当的时候修订产品风险
何时需要修订产品风险包括如下：
 新建或者改变需求
 软件开发方法改变
 项目中质量问题的经验教训