测试策略

The development of a test strategy is a multi-step process of analysis:

1. Analyze requirements.

2. Assess risk.

3. Define scope of testing.

4. Determine test approach.

5. Determine entry and exit criteria.

一个测试策略的设计是一个多步骤的分析过程：

1. 分析需求。

2. 评估风险。

3. 定义测试范围。

4. 确定测试方法。

5. 确定进入和退出条件。

Once the requirements and risks of a project are well-understood, the next step in test planning is to determine the test strategy. The test strategy answers

1

the following questions: Why are we testing? What do we plan to do? What do we plan not to do?

只要项目的需求和风险被准确理解，测试计划的下一步就是确定测试策略。测试策略解决下列问题：为什么我们要测试？我们要做些什么？我们计划不做些什么？

Your test strategy must include a clear definition of the scope of your testing. Your scope may be determined in part by your team's responsibility. A large development project may have multiple test teams working on it, each of which is responsible for a different aspect of the project. Even a small project has different levels of test, as described in the module Test Levels and Activities. Your scope includes the levels of test that you cover.

你的测试策略必须包括你对测试范围的一个明确定义。你的范围可能部分取决于你团队的责任。在大型发展项目里，可能有多个测试团队同时工作，每一个小组负责项目的不同方面。像在测试阶段和活动中描述的一样，即使是很小的项目，也有不同程度的测试。你的范围包括你负责的范围内的测试阶段。

The scope of your testing is also affected by the scope and nature of the project itself. For example, the scope of testing may be smaller for a small service release to an existing product than for a new product.

你的测试范围也会因为项目本身的范围和性质而受到影响。例如，对于一个新产品来说，一个准许生产的产品中的一个小服务的测试范围更小。

2

To determine the test approach, ask questions like these for each of the project features and attributes:

 What testing is planned for this feature or attribute?

 What customer problem does this feature solve?

 What announcement claims will we be making about this feature?

 What automation will we used to develop the tests for this feature?

要确定测试方法，为检测项目的功能和属性，必须提出下列问题，：

1、为测试功能或属性，要进行怎么样的测试？

2此功能解决客户的哪些问题？

3针对这个特点，我们要做出怎样的报告？

4我们将用什么自动化工具或技术来进行这项功能的测试？

To determine when to start and end testing, identify entry and exit criteria by answering the following questions:

为了决定何时开始和结束测试，根据下列问题的答案，确定进入和退出条件：

3

 During the development process, can the tests we've defined be executed in an effective and efficient manner?

 As the product continues to progress, when are we are finished?

1在开发过程中，我们定义的测试能否以有效和高效的方式执行？

2随着产品的不断发展，我们什么时候能够完成？

In order for entry and exit criteria to be effective, they must have three common attributes.

 Entry and exit criteria must be meaningful.

 Entry and exit criteria must be measurable.

 Entry and exit criteria must be achievable.

为了进入和退出条件能够生效，就必须有3个共同属性。

进入和退出标准，必须是有意义的。

进入和退出标准，必须是可衡量的。

进入和退出标准，必须是可实现的。

4

课程目标

After completing this lesson, you will be able to:

Define the scope of testing

Determine your test approach

Determine when to start testing and when the testing is complete

学完这一课后，你将能够：

定义测试范围

确定你的测试方法

确定何时开始测试以及何时完成测试

Throughout this course, you will have an opportunity to gain hands-on practice with various software test activities. We will use the following fictional scenario to provide context for our examples and exercises.

在整个过程中，你将有机会获得各种软件测试活动的实际操作。我们将使用下面的虚构场景，为我们的例子和练习提供场景。

Project background

5

The Arizona Weather Watcher group is a volunteer organization of professional and amateur weather watchers across Arizona. They hold biannual meetings to share ideas and observations.

项目背景

亚利桑那州的气候观察组是由亚利桑那州的专业和业余的气候观察家志愿者组成的。他们一年举行两次会议，来交流想法和意见。

The Arizona Weather Data Project

At the last meeting, it was determined that the group would attempt a long-standing goal. Since the group's inception, there has been a strong desire to amass a continuously updated database of weather data for all of Arizona. The Weather Watchers have decided that, with the Internet providing easy access, the time is right to attempt this project.

亚利桑那州的气象资料项目

上一次会议确定了该小组将尝试一个长期目标。从小组成立以来，积聚所有亚利桑那州的天气数据成为一个不断更新的数据库的强烈愿望及一直存在。天气观察家决定，既然互联网提供了方便，那么是时候尝试这个项目了。

The web tool they want to create will enable group members across Arizona to submit their local weather observations to a central database. This project is called

6

the Arizona Weather Data Project.

Many of the examples and exercises in this course refer to this background material.

他们想创建的网络工具，可以使整个亚利桑那州小组的成员能够提交当地天气观测的数据到一个数据库。这个项目就被称为亚利桑那州气象数据项目。

许多这个课程中的例子和练习是指此背景。

Throughout this module, you will be documenting your Test Plan for the Arizona Weather Data Project using the Rational Unified Process (IRUP) Master Test Plan Microsoft Word template available on the download page.

在这个模块的整个过程中，你将利用在下载页面下现成的Rational统一过程（IRUP）Master Test Plan Microsoft Word模板，记录亚利桑那州气象数据项目的测试计划。

The Arizona Weather Data Project (AWDP) consists of a web-based tool that allows volunteers across Arizona to submit local weather observations.

亚利桑那州的天气数据项目（AWDP）里有一个基于网络的工具，使得分布在亚利桑那州的志愿者可以提交当地的气象观察资料。

As you learned in Principles of Test Management, you can subdivide a test plan to better manage varying levels of detail and change. Since the Arizona Weather Data Project team is relatively small, you need to create only one test

7

plan.

正如你在测试管理原则中学到的，你可以细分测试计划，来更好地处理细节和程度的层次多样性。由于亚利桑那州气象数据项目团队比较小，你只需要创建一个测试计划。

Sections of this module refer you to the section numbers and section titles from the IRUP Master Test Plan template.

这个模块的部分，指的是IRUP主测试计划模板里的章节数和标题。

Developing a Test Strategy

制定一个测试策略

Once the requirements and risks of a project are well understood, the next step in test planning is to detemine the test strategy. The test strategy answers the following questions at a level that is useful to project managers, management, and members of your test teams:

当需求和项目的风险被充分理解后， 测试计划的下一步是确定测试策略。在对于项目经理，管理人员和你的团队人员是有用的水准上，测试策略回答了一下问题：

Why are we testing?

What do we plan to do and what do we plan not to do?

8

How will we do our testing?

The development of a test strategy is a multi-step process of analysis:

我们为什么测试？

我们计划做什么以及不做什么？

我们将如何做测试？

一个测试策略的形成是一个多步骤的分析过程：

Developing a Test Strategy,continued

制定一个测试策略，续

You already learned how to perform Step 1: Analyze Requirements. You learned how to evaluate functional requirements and nonfunctional requirements and how to develop use cases and use-case models. You learned how to refine bad requirements. You also learned how to perform Step 2: Assess Risk.

你已经学会了如何执行第1步：需求分析。你学过了如何评估功能需求和非功能需求，以及如何制定用例及用例模型。你也学过了如何改进不健全的需求。还学习了如何执行第2步：评估风险。

In this lesson, you will learn how to do steps 3 through 5 of developing a test

9

strategy as follows:

在这一课，你将学习创建一个测试策略的第三个步骤到第五个步骤，如下所示：

Step 3: Define the scope of testing

Step 4: Determine your test approach

Step 5: Determine when to start testing and when the testing is complete

In test strategy development, the first (and in some projects the most important) step is to clarify the testing scope for the project.

第3步：定义测试范围

第4步：确定你的测试方法

第5步：确定何时开始测试和结束测试。

在创建测试策略时，第一个（在一些项目中最重要的）步骤是阐明项目的测试范围。

Defining the Scope of Testing

定义测试范围

You must clearly define the scope of your testing. Your scope may be

10

determined in part by your team's responsibility. A large development project may have multiple test teams working on it, each of which is responsible for a different aspect of the project. Even a small project has different levels of test, as described in the module Test Levels and Activities. Your scope includes the levels of test that you cover.

你必须明确定义你的测试范围。您的范围可能部分取决于你的团队的责任。你的范围可能部分取决于你团队的责任。在大型发展项目里，可能有多个测试团队同时工作，每一个小组负责项目的不同方面。像在测试阶段和活动中描述的一样，即使是很小的项目，也有不同程度的测试。你的范围包括你负责的范围内的测试阶段。

The scope of your testing is also affected by the nature of the project itself. For example, the scope of testing may be smaller for a small service release to an existing product than for a new product. Make testing scope decisions consciously. Decide which features or functions to test, which products or product combinations to test and which not to test. Be sure to use well-informed risk assessments to understand the risk relative to what you are not testing.

您的测试的范围也受到项目本身性质的影响。例如，对于一个新产品来说，一个已存在产品的一个小服务的测试范围可能会更小。清晰地决定测试范围。决定测试哪些功能或特征， 哪些产品或产品组合进行测试了，而哪些没有进行测试。对于与你没有测试的部分相关的那些风险，一定要信息全面的了解和评估它们。

7．Communicating Testing Scope Decision

11

Communicate scoping decisions to the rest of the project team for their understanding, discussion, and agreement. While it may be easier to proceed quickly in cases in which you have immediate agreement, discussions often have the important side-effect of identifying unspoken assumptions that the project team may hold regarding testing. These discussions can also be helpful in identifying the role that project team members expect testing to play throughout the project lifecycle. Examples of questions to discuss include the following:

为了他们的理解，讨论和赞成，要向项目组成员传达与范围有关的决定。在你们迅速达成一致的情况下，可以比较容易的进行，讨论对于鉴定项目组关于测试可能持有的未说出的假设往往有重要的侧面影响。这些讨论也有助于确定项目小组成员在整个项目生命周期中期望承担的角色。讨论的问题例子包括以下内容：

• Will developers be expected to prove they have done a certain amount of

unit testing before they can submit code?

• Is the project manager expecting to supplement the test team with

contractors or developers during times of schedule pressures?

开发人员被期望能够证明他们已经做了一定量的单元测试，才可以提交代码吗？

当项目时间压缩时，项目经理希望给测试团队补充合约人或者开发人员吗？

The process of communicating testing scope decisions sets appropriate expectations, in advance, for what testing and the test team can and cannot do for

12

the project. These issues are best discussed in advance, rather than at the time of a crisis or conflict.

在通信测试范围决定的过程里设置适当的预期，更进一步，预期测试和测试团队对于这个项目，什么可以做什么不能够做。这些问题最好事先讨论，而不是直到危机或冲突的发生了才去讨论。

8. Identifying Scope: Test Levels and Focus Areas

确定范围：测试阶段和重点区域

You can categorize testing activities into levels, with each level focused on an aspect of the application or code. Each level is responsible for a set of focus areas; you need to analyze and assess these focus areas as part of determining the testing strategy.

您可以根据每个阶段对于应用和代码的侧重方面把测试活动分类成阶段。每一阶段负责一系列重点领域，你需要把分析和评估这些重点领域作为确定测试策略的一部分。

9

Functional Verification Test Focus Areas

功能验证测试重点领域

The set of focus areas for Functional Verification Testing (FVT) are:

13

功能验证测试（FVT）的重点领域设置：

10

System Verification Test Focus Areas

系统验证测试重点领域

The set of focus areas for System Verification Test (SVT) are:

系统验证测试（SVT）的重点领域设置：

You'll notice that some of the same focus areas appear for both FVT and SVT. The emphasis, however, is different in each case. Let's look at the Regression focus area. The FVT team regression tests individual functions, such as login. The SVT team regression tests the system as a whole. For example, the SVT team might rerun load and stress tests.

你会发现，同样的一些重点领域会在FVT和SVT里同时出现。，但是重点是，在每种情况下是不同的。让我们来看看回归重点领域。FVT工作组对个别功能进行回归测试，例如登录功能。 SVT团队的回归测试是测试整个系统。例如，SVT的团队可能再次执行的负载和压力测试。

11． Test Inclusions

测试包含的活动

14

Once you have determined the scope of your testing, you are ready to document the scope. Open the IIRUP Master Test Plan template you downloaded earlier in this module and review sections 1.2 and 4.

Section 1.2: Scope

Use this section to define the levels of test that you will perform, as well as the levels of test you will not perform. Be sure to review section 4 prior to completing section 1.2 to avoid duplicating information or presenting it in the wrong location.

Section 4: Overview of Planned Tests

Use this section to document the features and attributes that you plan on testing. (We will document features that you do not plan on testing later in this lesson.)

一旦你决定了你的测试范围，您就可以记录你的范围。打开在本模块中你早些时候已下载的IIRUP主测试计划模板，回顾第1.2和第4部分。

第1.2节：范围

利用本部分定义你将要执行的测试阶段，以及不执行测试的阶段。一定要事先复习第4部分完成第1.2节，以避免重复信息或出现在错误的位置。

第4部分：回顾测试计划

15

使用此部分记录你计划测试的的功能和属性。（在这一课的后面，我们将记录你不准备测试的功能。）

Section 4.1: Outline of Test Inclusions

A good way to document test inclusions is to use the results of the risk analysis produced earlier in the planning process.

For the AWDP Test Plan, you can use the table that you created in the Test Planning and Risk Analysis module almost directly. Add one column titled \"Additional Information\" to capture the logic behind the analysis. Use the new space to explain why a certain feature or attribute was given a particular impact level and likelihood so that a reviewer understands and can evaluate the assessment.

Click on Test Inclusions for an example.

4.1节：测试包含活动的大纲

一个记录测试活动的好办法是利用之前在规划过程中产生的风险分析的结果。

对于AWDP测试计划，你几乎可以直接使用你在测试规划和风险分析模块中创建的表格。添加一名为“补充信息”的列，捕捉分析背后的逻辑。使用这块新空间，来解释为什么某些特征或属性被给予了特别的影响程度和可能性，以便审阅者能够理解和评价评估。

点击测试活动，举一个例子。

16

12． Test Exclusions

测试排除

Section 4.2: Outline of Other Candidates for Potential Inclusion

There may be some features or attributes that you suspect need to be tested but will require more investigation or insight. List those in this section using the same format as test inclusions, but use \"Additional Information\" as a place to document the reasons why this feature or attribute is considered under potential inclusion.

第4.2节：其他候选的潜在活动的大纲

可能有一些功能或属性，你觉得可能需要进行测试，但将需要更多的调查和了解。在本部分中使用与测试包含活动相同的格式列出它们，但要使用“补充信息”一列记录为什么此功能或属性被列入潜在活动的原因。

Section 4.3: Outline of Test Exclusions

These are features or attributes that you have determined have a low enough priority to accept the risk of not developing and executing tests. Use the \"Additional Information\" column for the justification to exclude this testing. For example, in the Arizona Weather Data Project application, there is a \"Save Draft\" option on the data submission form. A possible justification for not testing the

17

\"Save Draft\" option is the fact that the form does not take very long to complete, and most users would finish entering their observations without the need to save their work along the way.

Click on Test Exclusions for an example.

4.3节：测试排除大纲

有些功能或属性，你已经确定它们具有足够低的优先度，可以不发展和执行测试。使用“补充信息”的列解释为什么不需要进行测试。例如，在亚利桑那州气象数据项目应用中，有一 个“保存草稿”的资料提交表单选项。不对 “保存草稿”进行测试的合理理由是，该表不需要很长时间才能完成，而且大多数用户无需一直保存他们的工作就可以完成观察数据的输入。

点击试验排除的一个例子。

13

Determining the Test Approach 确定测试方法

The next step in the process of defining your strategy is to determine your test approach.

确定策略进程的下一步是要确定你的测试方法

18

14

Determining the Test Approach, continued 确定测试方法，继续

For effective testing, the challenge is to take the prioritized list of features and attributes that were developed based on risk mitigation and assess them against the list of test focus areas, making sure to cover all of the areas.

为了有效的测试，面临的挑战是采用功能和属性的优先级列表，优先级列表是基于风险缓解和对重点领域的测试评估，并且要确保涵盖所有领域。

Recall that the focus areas for Functional Verification Test are:

• Mainline functions

• Error conditions

• Recovery

• Basic usability

• Accessibility

• Global enablement

19

• Vulnerability

• Regression

回想一下，在功能验证测试的重点领域是：

主线功能

错误条件

恢复

基本可用性

可用性

全球可用

漏洞

回归

The focus areas for System Verification Test are: • Load and stress

20

• Regression

• Recovery

• Migration

• Usability

• Serviceability

• Functional completeness

• Hardware and software interaction

• 系统验证测试的重点领域是：

• 负载和压力

• 回归

• 恢复

• 迁移

• 可用性

21

• 使用能力

• 功能完整性

• 硬件和软件的相互作用

整理到这里

Taking this approach allows you to concentrate the testing effort to deliver the most benefit. For each of the features and attributes, ask these questions to determine the test approach:

• What testing is planned for this feature or attribute? When answering this

question make sure to ask it for each of the focus areas in your test level. For example, does this feature need to be tested for global enablement? Does this feature need to be stress tested? Is this a feature that is likely to be vulnerable to hackers?

• What customer problem does this feature solve? This will help you decide

where to focus the testing for this feature.

• What announcement claims will you be making about this feature? This

question will help ensure that you are verifying what marketing is saying.

• Will this feature be verified by the execution of the regression tests only? If

so, why?

22

• What automation will be used to develop the tests for this feature?

Remember that time and resource will have to be factored into the plan for designing/developing the automation and potentially learning new tools.

You may want to add questions to this list that are specific to your environment. The important thing is to have a list so that you do not miss important considerations.

采取这种方法可以让您专注的测试工作，以提供最大的利益。对于功能和属性，每年提出这些问题，以确定测试方法：

是什么样的测试计划在此功能或属性？回答这个问题时，请务必请在您的测试级别的重点领域来进行。例如，此功能需要为全球启用测试？此功能需要的压力测试？这是一个功能，很可能会受到黑客的攻击？

客户的哪些问题此功能解决？这将有助于您决定在何处集中对这一功能的测试。

公告要求什么，你又对这项功能？这个问题将有助于确保您正在核实营销是说什么。

此功能将被核实的回归测试执行而已？如果是这样，为什么？

什么自动化将用于开发此功能的测试？请记住，时间和资源将被纳入计划之内设计/开发的自动化和潜在的学习新的工具。

您可能需要添加到这个列表的问题是特定于您的环境。重要的是有一个列表，以便您不会错过重要的考虑因素。

23

15

Different Test Levels, Different Test Strategies 不同的测试级别，不同的测试策略

The scope for your Arizona Weather Data Project (AWDP) Test Plan includes two different levels of test: Functional Verification Test (FVT) and System

Verification Test (SVT). Different levels of test can require different test strategies.

Let's look at an example for each of these levels: FVT and SVT. We will use features and attributes from the prioritized list that we developed in the Test Planning and Risk Analysis module.

您的亚利桑那州气象数据项目（AWDP）测试计划的范围包括两个不同层次的测试：功能验证测试（FVT）和系统验证测试（SVT）的。不同级别的测试可能需要不同的测试策略。

让我们来看看为各层级的例子：FVT和SVT。我们将使用优先列表，我们在测试规划和风险分析模块开发的功能和属性。

16

Example: Test Approach for the AWDP Login Feature 例如：测试的AWDP登录功能的方法

24

One of the high-priority line items for the AWDP is the \"login\" feature. The basic functionality of the login feature will be tested as part of FVT. You can use an outline like the one below to gather the information you need to document your test approach in your Master Test Plan.

In this example, the answers to the questions What testing is planned for this feature or attribute? and What automation will be used to develop the tests for this feature? are captured under the heading Approach to Testing. The answer to

the question What customer problem does this feature solve? under the heading Overview or Brief Description.

Recall that your test approach should address situations that are specific to your environment. In this example, the fact that the authentication function is using services provided by another group is called out under the heading Assumptions/Issues Specific to this Feature.

高优先事项AWDP行项目之一是“登录”功能。在登录功能的基本功能将受到考验，作为FVT的一部分。您可以使用类似下面这一收集需要的信息记录你对你总的测试方法测试计划纲要。

在这个例子中，对什么进行测试，此功能或属性的计划问题的答案？和什么自动化将用于开发此功能的测试？被捕获的标题下的测试方法。对这一问题的客户的哪些问题不解决这一功能的答案？的标题下概述或简要说明。

回想一下，您的测试办法应处理的特殊情况对您的环境。在这个例子中，一个事实，

25

即验证功能是由另一组使用所提供的服务被称为假设项下出/这一问题的具体特征。

Feature Name: Login

Lead Developer: Sue

Lead Function Tester: Javier

Lead System Tester: Thelma

Overview or Brief Description: A user is required to log in using their registered userid (email address) and password.

Approach to Testing: Develop a set of automated tests to test the ability to log in valid users that are registered. Drive error paths by logging in with invalid userids and passwords.

Assumptions/Issues Specific to this Feature: Authentication using the userid and password is provided by an external service that will be called. It is assumed that this function already has been thoroughly tested and supported. We will not do vulnerability testing on entering userids and passwords.

功能名称：登录

铅开发商：苏

26

铅功能测试仪：哈维尔

铅系统测试仪：塞尔玛

概述或简要说明：用户需要登录使用其注册用户名（电子邮件地址）和密码。

测试方法：制定了一套自动化测试，测试的能力，有效用户登录注册的。在使用无效的用户id和密码记录器的错误路径。

假设/这个问题的具体特征：身份验证使用用户ID和密码是由外部提供服务，将被调用。据推测，这一职能已经过彻底测试和支持。我们不会在进入用户id和密码的漏洞测试。

17

Exercise 1: Test Approach for Concurrent Users Feature 练习1：测试方法为特征并发用户

Another of the requirements for the AWDP system is that 1500 users can access the tool concurrently. This attribute will be tested as part of SVT.

在对AWDP系统的要求另一个原因是，1500用户可以访问该工具同时进行。此属性将被测试作为SVT的一部分。

19

27

Documenting the Test Approach 记录的测试方法

Section 5 of the IIRUP Master Test Plan provides you with a template for documenting your test approach. Section 5 includes these headings:

5.1 Measuring the Extent of Testing

5.2 Identifying and Justifying Tests

5.3 Conducting Tests

The IIRUP template is just that, a template. Teams modify the template to suit their needs. For a small project, you may choose to document your test approach by line item or feature as shown in the screen capture.

As you can imagine, this level of detail would quickly become cumbersome for a large project. A better approach for a large project is to manage this detail in a spreadsheet. In this case, the test plan includes a high level overview of the test approach with a reference to the more detailed spreadsheet. Creating feature or iteration test plans in addition to the Master Test Plan can also be very useful for a larger project.

科IIRUP主测试计划5提供了一个模板，用于记录您的测试方法。第5节包含以下标题：

28

5.1测程度测试

5.2中说明和测试

5.3进行测试

该IIRUP模板的只是，一个模板。团队修改模板以适应他们的需要。对于一个小项目，你可以选择你的文件按项目测试方法或功能如屏幕捕获所示。

你可以想象，这种详细程度将迅速成为累赘一项庞大的工程。一个大型项目的更好的方法是，以管理电子表格这一细节。在这种情况下，测试计划包括一个以电子表格的更详细的参考测试方法高层次的概述。创建功能或除主测试计划的迭代测试计划也可以是非常有用的一个较大项目。

20

Determining Entry and Exit Criteria for Testing 确定进出境检验标准

As part of the test strategy, you determine when to start testing by identifying Entry Criteria and when the testing is complete by identifying Exit Criteria.

作为测试策略的一部分，您决定何时首先确定入学标准和测试时，通过识别出口标准的完整测试。

29

21

What do Entry and Exit Criteria do for You? Entry Criteria and Exit Criteria answer the following questions:

• As a product moves through the development process, can the tests that we

have defined for each level or iteration be executed in an effective and efficient manner?

• How will we know when are we finished testing a particular level or iteration?

In order for entry and exit criteria to be effective, they must have three common attributes:

• Entry and exit criteria must be meaningful.

o

Each criterion should exist for a specific reason.

o

A cause and effect should be shown or implied.

o

They should aid in risk assessment.

• Entry and exit criteria must be measurable.

o

If it cannot be measured, it is not useful.

30

o

It should never be subjective.

o

The status is calculated using empirical data.

• Entry and exit criteria must be achievable.

o

The criteria must be realistic, not unobtainable.

Never carry forward a criteria that has never been met; it dilutes the effectiveness of the other criteria.

入学标准和退出条件回答下列问题：

通过发展进程中的产品移动，我们可以为每个级别或迭代定义的测试执行有效和高效的方式？

我们如何知道我们完成测试某个特定水平或迭代？

在进入和退出条件才能有效，就必须有3个共同的属性：

进入和退出标准，必须是有意义的。

每个标准应该存在的具体原因。

因果应表明或暗示。

31

他们应该帮助风险评估。

进入和退出标准，必须是可衡量的。

如果它不能衡量，它是没有用的。

它不应该是主观的。

状态为计算经验数据。

进入和退出标准，必须是可以实现的。

该标准必须是现实的，不是不能实现的。

从来没有发扬一个从未达到的标准，它淡化了其他标准的效力。

22

Determining Entry Criteria 确定入学标准

When determining entry criteria, document what is required by a team to begin testing and proceed efficiently and effectively with a manageable amount of risk. The criteria should be discrete and easily measured. They should also be used to determine an acceptable amount of risk. For example, ask the question:

32

If these criteria are not met, what could happen and what would the result be?

Assign a risk assessment value to each criterion. Refine this value over time and is use it to identify productive recovery actions. When determining risk, it is important to total the individual risk assessment values to get a complete understanding of the entire situation. The risk determination is important because if an entry criterion is not met, it does not mean that the test organization stops working.

在确定入学标准，文件什么是需要一个团队开始测试和进行有效的风险管控的有效。该标准应是离散的和容易衡量。他们应该也可以用来确定一个可接受的风险金额。举例来说，提出这个问题：

如果这些条件得不到满足，会发生什么和什么结果呢？

指定一个风险评估值为每个标准。随着时间改进此值，并用它来确定生产恢复操作。在确定风险，重要的是总的个人风险评估的价值得到了整个局势的全面了解。风险的决心非常重要，因为如果一个项目不符合标准的，但这并不意味着测试机构停止工作。

Entry criteria being met is really a checkpoint that shows the overall status of a product. Higher levels of risk indicate that the testing may not be optimally effective, which increases the risk that targeted problems will escape to the field. For example, if some of the planned functionality is not delivered on schedule, the risk is increased as the amount of time available to test that functionality is reduced. The risk is increased further if testing of other planned functionality is

33

dependent on the piece that is delayed.

Once the team understands the objectives, you can ask the following question to start establishing good entry criteria:

For entry criteria, what has to have happened so that we can begin, be effective and efficient, and proceed with a manageable amount of risk?

入 学条件得到满足实在是一个检查点，显示了产品的整体状态。风险水平较高的测试表明，就不能很好的效益，从而增加有针对性的风险问题，将逃往外地。例如，如 果计划中的某些功能不能如期交付的风险有所增加的时间来测试该功能数额减少。风险是进一步增加，如果计划中的其他功能测试是在这片延迟依赖。

一旦球队了解的目标，可以提出以下的问题开始建立良好的入学标准：

入境标准，有什么事情，以便我们能够开始，是有效的和有效率，并进行风险管理的数额？

23

Evaluating Ideas for Entry Criteria 评价理念的入学标准

As the team brainstorms, list ideas for potential entry criteria. Assess each idea and make sure that it is meaningful, measurable, and achievable.

34

Example 1: A member of the team suggests that, as an entry criterion, \"A specific set of variations defined in an earlier test level must run successfully.\"

Make sure that you can defend why these variations must run and quantify the risk of continuing should any of them fail. Avoid ambiguous criteria such as \"Function Test must be 80% complete.\" This criterion is ambiguous because it does not specify which 80% must be complete. Also, if there are a lot of tests, the failing 20% could impact your ability to make progress. It is better to specify which variations must execute successfully.

随着球队的奇思妙想，为潜在的入学标准清单的想法。评估每个想法，并确保它是有意义的，可测量的和可以实现的。

示例1：对小组成员建议，作为项目的标准，“一个在早些时候测试级别的定义必须成功运行一套具体的变化。”

请 确保您可以保护这些变化的原因必须运行和量化应继续他们任何失败的风险。避免出现诸如“功能测试，必须完成80％含糊的标准。”这一标准是模糊的，因为它 没有具体说明，其中80％必须是完整的。此外，如果有很多的测试，20％失败的可能影响您的能力取得进展。这是更好地指定的变化，必须成功执行。

Example 2: A member of the team suggests that, as an entry criterion, \"A specific set of tests, sometimes called an acceptance test, must be executed successfully.\"

35

Make sure that you can defend each of the tests and can quantify the risk of continuing should a given test fail.

Example 3: A member of the team suggests that, as an entry criterion, \"The test plan must be reviewed and approved.\"

Make sure that you can defend why the test plan must be approved, and can quantify the risk to the test if the plan is not approved.

例2：对小组成员建议，作为项目的标准，“一组特定的测试，有时也被称为的验收，必须执行的成功。”

确保您能捍卫每个测试和可量化的持续应给定的测试失败的风险。

例3：对小组成员建议，作为入门标准“的测试计划必须经过审查和批准。”

请确保您可以保护为什么测试计划必须获得批准，可以量化的风险的考验，如果计划未获批准。

24

Determining Exit Criteria 确定退出标准

When determining exit criteria, identify what must be accomplished for the

36

test effort to be complete for a particular test level or iteration. Agree up front with the project manager what needs to be done for the test effort to be complete. Remember that you must state the goals and objectives in measurable terms.

Associate meeting your exit criteria with another aspect of the project. For example, associate the system test exit with a product ship decision or customer entry criteria. That will cause others outside of your team to feel a sense of urgency to ensure that your exit criteria are met. It will also help you to justify requests for help where needed.

Once the team understands your testing objectives, you can ask the following question to start establishing good exit criteria:

How do we know when we are done?

在确定退出标准，确定哪些必须为测试工作完成的针对特定测试级别或迭代完成。同意与项目经理所需要做的测试工作完成前要完成。请记住，你必须明确的目标和可测量的目标。

副会见该项目的另一个方面，你的退出条件。例如，系统关联的产品或客户决定船舶入出境的标准测试。这将导致你的团队以外的其他人感到一种紧迫感，以确保您退出条件得到满足。它还将帮助您在正当理由需要帮助的请求。

一旦球队明白你的测试目标，可以提出以下的问题开始建立良好的退出标准：

37

我们怎么知道我们什么时候完成？

25

Evaluating Ideas for Exit Criteria 评价标准的退出思路

As the team brainstorms, list ideas for potential exit criteria. Assess each idea and make sure that it is meaningful, measurable, and achievable. Some potential ideas for exit criteria are:

• All tests are successfully executed. The definition of \"successfully\" needs to

be documented and well understood. If a severity 3 defect blocks a test and it is determined that that defect will not be fixed, you must determine and agree upon the status of the test and it must be in line with allowing this exit criteria to be met.

• All severity 1 and 2 defects are closed and all severity 3 and 4 defects have a

documented disposition. Modify this one to fit the requirements of your product.

• Use entry criteria for a later test level. For example, if Function Test requires

that certain code analysis tools are executed and the results reviewed and approved, then you can use this approach to exit Unit Test.

随着球队的奇思妙想，为潜在的退出条件清单的想法。评估每个想法，并确保它是有意义的，可测量的和可以实现的。出境标准的一些潜在的想法是：

38

所有测试成功执行。在定义“成功”需要记录和很好的理解。如果一个严重缺陷3块一个测试和决心，这一缺陷不会是固定的，你必须确定和商定的测试状态，它必须符合与允许这种退出的标准得到满足。

所有的严重性1和2缺陷封闭，所有的严重性3和4的缺点，有记录的处理。修改此一个适合你的产品的要求。

在以后的测试级别使用入学标准。例如，如果功能测试要求，某些代码分析工具，执行和结果的审查和批准，那么你可以使用此方法退出单元测试。

26

Example of Exit Criteria: Functional Verification Test 出入境示例标准：功能验证测试

As an example, consider the following exit criteria for Function Verification Test:

• Successful exposure and execution of all FVT functional scenarios or tests

(workloads, thrashers, test cases, etc)

• Successful exposure and execution of any recovery scenarios

• A technical risk assessment of the outstanding scenario failures and open

problems will be performed prior to entry to the SVT level. The assessment should

39

occur at a point when the majority of testing planned for this level has been attempted. The technical risk assessment will analyze the current failing scenarios and open problems to articulate risk impact on the following phase of testing and actions to be taken to mitigate the risk(s).

Are these criteria measurable? Meaningful? Achievable? How could they be improved?

作为一个例子，考虑是否功能验证测试退出标准如下：

成功接触和所有FVT功能情况或测试（负载，脱粒机，测试用例等执行）

成功的揭露和执行任何恢复方案

一个优秀方案的失败和开放问题，技术风险评估前进行进入SVT的水平。评估应发生在当大部分这个水平测试计划1点被尝试。技术风险评估，分析目前没有开放的情况和问题，阐明风险的测试和行动的影响下阶段将要采取的减轻风险（拧）。

这些标准是衡量？有意义吗？实现？怎样才能改善呢？

27

Assigning Risk Assessment to Entry and Exit Criteria 分配风险评估，以进入和退出标准 40

Once you have selected the criteria, review each one and assign it a risk assessment. At this level, assign a simple low, medium, or high level of risk to the product should a specific criterion not be met. Be realistic in your assessment. Remember that when you are making the actual assessment, you need to look at the situation as a whole; for example, a large number of low risks could mean that there is a significant problem.

Enhance the entry and exit criteria by using metrics. Hone the risk assessment values using historical data. Good defect management can provide historical data to show defect trends indicating areas of risk. For example, review the

customer-reported defects to identify problems that were missed during previous testing. Customer-reported defects can help you better understand what

functionality is most important to the customer. Defect analysis using Orthogonal Defect Classification (ODC) can be particularly helpful in determining exit criteria.

一旦你选定的标准，审查每一个和它分配一个风险评估。在这个层面上，指定一个简单的低，中，或者该产品的风险高，应一个具体的标准没有得到满足。现实中你的评价。请记住，当你作出实际评估，你需要看整个情况，例如，低风险，大量可能意味着有一个很大的问题。

提 高利用指标进入和退出条件。骨的风险评估值使用的历史数据。良好的缺陷管理可以提供历史数据显示缺陷趋势标明风险领域。例如，审查客户报告的缺陷，以确定 那些在先前的测试错过的问题。客户报告的缺陷，可以帮助您更好地了解什么样的功能是最重要的客户。缺陷分析使用正交缺陷分类（失聪）可特别有助于确定退出 条件。

41

In addition, consider what could be required from the prior process step to reduce risk and prevent defects from escaping. For instance, function test can require that development inspect all code, run code coverage tools during unit test and achieve a realistic but quantified level of coverage, use static analysis tools, and so on.

Be sure that both the project team and the test team collect the data you need to measure whether your criteria have been met. The key to making that determination is data.

此外，可以考虑一下从以前的处理步骤所需的降低风险，防止他们逃跑的缺陷。例如，功能测试可以要求发展检查所有的代码，在运行单元测试代码覆盖工具，实现覆盖现实而量化级别，使用静态分析工具，等等。

可以肯定，无论是项目团队和测试团队收集你需要的数据来衡量你的条件是否已经满足。对作出这一决定是数据的关键。

29

Documenting Entry and Exit Criteria 记录进入和退出标准

The practice of establishing good entry and exit criteria is applicable to all levels of testing. It guarantees that you apply proper focus to the most important

42

activities at the correct time. With today's environment demanding aggressive development schedules, there is constant pressure to start and end because the date to start or end has come. Good criteria help to manage that situation. If a date cannot be moved, entry and exit criteria can help you to quantify the increased risk and potentially help you to identify ways to mitigate that risk. Good criteria can also help determine where to focus resources and energy and ensure that time and effort are spent on valuable tasks.

Document your work in Section 6: Entry and Exit Criteria of the IIRUP Master Test Plan template.

建立良好的进入和退出条件的做法是适用于所有级别的测试。它保证您应用在正确的时间正确的焦点，最重要的活动。在今天的环境要求积极发展的时间表，有不断 的压力，因为开始和结束的日期开始或结束已经到来。良好的标准，有助于管理的情况。如果一个日期不能移动，进入和退出标准可以帮助您增加的风险量化和潜在 的帮助您确定如何缓解这一风险。良好的条件还可以帮助确定在哪些方面注重资源和能源，确保时间和精力都用在有价值的任务。

您的文件在第6个工作：出入境的IIRUP主测试计划标准模板。

30

Documenting Risks, Dependencies, Assumptions, Constraints 记录风险，相关性，假设，约束

43

Document any remaining information from your earlier risk assessment, including your contingency plans, in Section 12 of the IIRUP Master Test Plan template. Also document Dependencies, Assumptions, and Constraints in this section.

Documenting dependencies requires an understanding of the critical path of the project and the availability of key resources.

A complete list of assumptions identifies all expectations that negatively impact the project if they are proved incorrect.

Listing constraints identifies limits you must live with and their impact on the project.

Together these factors reveal the boundaries and choices that influence the management of the test plan.

文件从您刚才的任何风险评估剩余的信息，包括您的应变计划，科IIRUP总测试计划12，模板。同时文件的依赖，假设，并在本节约束。

记录依赖需要对项目的关键路径的理解和关键资源。

假设一个完整列表列出了所有人的预期带来负面影响的项目，如果他们被证实不正确。

上市约束识别您的生活必须和他们对项目的影响。

44

这些因素共同揭示了边界和选择影响了测试计划管理。

31

Lesson Summary In this lesson you learned that:

• You must clearly define the scope of your testing. Your scope may be

determined in part by your team's responsibility, the different levels of test to cover, and the nature of the project itself.

• The test approach is developed by creating a list of questions specific to your

environment.

• Identifying Entry and Exit Criteria will help you determine when to start

testing and when the testing is complete.

• The IIRUP Master Test Plan template is used to document your Test Plan.

在这一课你了解到：

你必须明确你的测试范围。您的范围可能部分取决于你的团队的责任，对不同层次的测试覆盖，以及项目本身的性质。

测试的取向是通过创建一个特定的问题清单，以您的环境。

45

确定进入和退出标准将帮助您确定何时开始测试，当测试完成。

在IIRUP主测试计划的模板是用来记录您的测试计划。

46