决定要使用的工作产品以及使用这些工作产品的方式。除了确定要使用的工作产品之外,定制每个要使用的工作产品来适应项目需求也很重要。
下表指定了建议使用哪些“测试”工作产品,以及其中哪些被认为是可选的(即,只能在某些情况下使用)。关于其他的定制注意事项,请参阅工作产品描述页面的定制部分。
工作产品
|
用途
|
定制(可选,建议使用)
|
测试评估摘要
|
总结主要由管理团队和测试团队以外的其他项目干系人使用的测试结果。
|
建议大多数项目使用。
在项目文化相对不很正式的情况下,适合于只是记录测试结果,而不创建正式的评估摘要。 在其他情况下,测试评估摘要可以作为其他评估工作产品(例如迭代评估或复审记录)的一部分而包括在内。
|
测试结果
|
该工作产品是由一个或多个测试日志中的原始数据而确定的分析结果。
|
建议使用。大多数测试团队都为测试结果保留了某种形式的适度详细的记录。 这里通常直接记录手动测试结果,并与从自动测试中提取的测试日志相结合。
在某些情况下,测试团队将根据测试日志直接生成测试评估摘要。
|
测试日志
|
测试执行期间的原始数据输出,通常由自动测试生成。
|
可选。
许多执行自动测试的项目将有某种形式的测试日志。项目之间的区别在于,确定了测试结果之后,是保留还是废弃测试日志。
在以下情况下您可以保留测试日志:您需要满足某些审计需求,您想要执行关于原始测试输出数据如何随时间变化的分析,或者您对于可能需要您提供的所有分析的开始不确定。
|
测试套件
|
用来将个别的相关测试(测试脚本)组合到有意义的子集中。
|
建议大多数项目使用。
对于定义所有测试脚本执行顺序(这些执行顺序对于正确进行测试是必需的)也是必需的。
|
测试构想列表
|
这是一系列的枚举构想,通常已部分形成,被视为要开展的有用测试。
|
建议大多数项目使用。
在某些情况下,只是非正式地定义这些列表,一旦从中定义了测试脚本或测试用例,就废弃这些列表。
|
测试策略
|
就如何针对目标系统的一个或多个方面来开展测试工作定义策略计划。
|
建议大多数项目使用。
在大多数情况下,建议您针对每个项目或项目的每个阶段制定一个测试策略。 作为一种选择,您可以在适当的情况下重用现有的策略,或者您可以基于正在开展的测试的类型进一步细分测试策略。
|
测试计划
|
定义更细化的测试目标、目的、动机、方法、资源、进度表和工作产品,它们都用于管理迭代。
|
建议大多数项目使用。
建议对每个迭代制定单独的测试计划,以定义特定的、细化的测试策略。 作为一种选择,您可以将测试计划作为迭代计划的一部分而包括在内。
|
测试计划
|
定义控制某一阶段或整个生命周期的高级测试目标、目的、方法、资源、进度表和工作产品。
|
可选。对大多数项目有用。
主测试计划为在软件开发生命周期的大部分时间内耗费的测试工作定义高级策略。 作为一种选择,您可以将测试计划作为软件开发计划的一部分而包括在内。
考虑除“迭代”测试计划外,是否还维护“主”测试计划。主测试计划主要包含后勤和流程制定信息,这些信息通常与整个项目生命周期相关,因此在迭代之间不大可能发生变化。
|
测试脚本,测试数据
|
测试脚本和测试数据是测试的实现或实施,其中测试脚本体现过程方面,而测试数据体现定义特征方面。
|
建议大多数项目使用。
项目之间的差别在于处理这些工作产品的正式程度。在某些情况下,这些工件是不正式和暂时的,而测试团队是根据其他条件来判断的。
在其他情况下(尤其是对于自动测试),测试脚本和相关的测试数据(或数据的某一小部分)被视为测试工作的主要可交付件。
|
测试用例
|
定义一组特定的测试输入、执行条件和预期结果。
记录测试用例,这样就可以复审它们的完成情况和正确性,并在计划和执行实施工作之前考虑测试用例。
这在输入、执行条件和预期结果特别复杂时最有用。
|
建议:对于大多数项目,如果开展特定测试所需要的条件很复杂或广泛,那么您应定义测试用例。 如果测试用例是合同所要求的可交付件,您也需要记录测试用例。
在大多数其他情况下,建议您维护测试构想列表和已实施的测试脚本,而非详细的文本测试用例。
有些项目将只是在较高层面上概括测试用例,而将细节延至测试脚本中描述。 另一种常用风格是将测试用例信息作为注释记录在测试脚本中。
|
工作负载分析模型
|
一类专门的测试用例。用来定义有代表性的工作负载,以允许评估与在负载内的系统操作相关联的质量风险。
|
建议用于大多数系统,尤其是那些必须评估负载内性能的系统,或者是存在与负载内系统操作相关联的其他重大质量风险的系统。
对于将在单机目标系统上部署的系统,通常不需要。
|
设计模型中的可测性类
实施模型中的可测性元素
|
如果项目必须制定其他重大而专门的行为来适应并支持测试,可通过将可测性类包括在设计模型中并将可测性元素包括在实施模型中,来表示这些关注问题。
|
在需要时使用。
存根是一类常见的测试类和测试组件。
|
测试自动化体系结构
|
使用许多不同的体系结构视图来描绘系统的不同方面,对测试自动化系统进行体系结构性概述。
|
可选。
建议用于这样的项目,其中的测试体系结构比较复杂,有大量人员来协作构建自动化测试,或者预期要长期维护测试自动化系统。
在某些情况下,这可能只是白板上的一幅图,该图主要是为要咨询的各关注方而记录的。
|
测试接口规范
|
为了测试(可测性)起见,按分类器(特别是类、子系统或组件)定义一组必需的行为。常见的类型包括测试访问、存根行为、诊断日志记录和测试预测。
|
可选。
在许多项目中,对于类和用户界面等的可视操作的测试,也存在足够的可访问性。
创建测试接口规范的一些公共原因包括 UI 扩展(这些扩展允许 GUI 测试工具与接口和诊断消息日志记录例程交互),尤其是对于批处理。
|
此部分提供一些指南,以帮助您决定应如何复审测试工作产品。 对于通用指南,请参阅指南:复审级别。
缺陷
对缺陷复审的处理极度依赖于环境,不过它们一般是作为非正式、内部正式或外部正式工作来对待的。此复审流程常常由缺陷跟踪系统中的工作流程管理强制实行,或至少辅助其实行。
一般而言,复审的正式程度常常与感受到的缺陷严重性或影响有关,不过诸如项目文化和形式程度之类的因素常常会影响复审处理的选择。
在有些情况下,您可能需要考虑将缺陷(也称为症状或故障)的处理与故障(实际的错误来源)的处理分开来。 对于小型项目,您通常可以通过只跟踪缺陷来进行管理,并隐式地处理故障。
不过,随着系统复杂性的增长,将缺陷的管理与故障的管理分开来可能是有益的。例如,同一个故障可能会造成若干个缺陷。 所以,如果故障已解决,则有必要找出所报告的缺陷并通知提交这些缺陷的用户,只有在分别标识缺陷和故障的情况下才有可能进行该操作。
测试计划和测试策略
在测试占有重要地位的任何项目中,您将需要某种形式的测试计划或策略。 通常,您需要有针对每个迭代的测试计划和某种形式的主控测试策略。作为一种选择,您可以创建和维护主测试计划。
在许多情况下,这些工作产品的复审结果为不正式;也就是说,它们已经过复审,但未正式核准。如果测试可视性对于测试团队以外的项目干系人很重要,它应该被视为内部正式,或甚至为外部正式。
测试脚本
测试脚本通常被视为不正式,也就是说,它们由测试团队中某名成员核准。 如果测试脚本要供许多测试人员使用,并由许多不同的测试共享或复用,则它们应被视为内部正式。
测试用例
测试用例由测试团队创建,且(根据环境)通常使用非正式流程进行复审,或者根本不复审。
在适当情况下,测试用例可以由其他团队成员核准,在这种情况下它们可被视为内部正式,或由外部项目干系人核准,在这种情况下它们将是外部正式。
作为一般试探性方法,建议您只计划正式地复审有必要复审的测试用例,这些测试用例通常将限制为代表最重要测试用例的一小部分。
例如,如果客户要在产品发行之前验证产品,则可选择某一部分测试用例作为该验证的基础。这些测试用例应被视为外部正式。
设计和实施中的测试工作产品
可测性类是在设计模型中找到的,而可测性元素是在实施模型中找到的。 还有另外两个相关(尽管不是特定于测试)的工作产品:设计模型中的包和实施模型中的子系统。
这些工作产品是设计工作产品和实施工作产品,不过,创建它们是为了支持软件中的测试功能。 正常情况下,它与设计工作产品和实施工作产品保存在一起。 请记住,以适当方式命名或标记它们,使它们能明确地与核心系统的设计和实施分开来。
按照设计和实施工作产品的复审过程来复审这些工作产品。
在进入每个迭代时,请努力提前确定将如何判断测试工作已足够,以及度量判断的依据是什么。 与负责做出核准决策的个人或小组讨论,确定这一事项。
以下是处理迭代核准的示例方法:
-
项目管理团队核准迭代,并通过复审测试评估摘要来评估测试工作。
-
客户通过复审测试评估摘要来核准迭代。
-
客户根据展示的结果(该展示演习所有测试的某一部分)来核准迭代。这部分测试应预先定义并由各方达成一致,最好是在迭代早期。 这些测试被视为外部正式,常常被称为验收测试。
-
客户通过开展他们自己的独立测试,来核准系统质量。同样,这些测试的性质应预先明确定义并由各方达成一致,最好是在迭代早期。 这些测试被视为外部正式,常常被称为验收测试。
这是个重要的决定 - 如果您不知道目标是什么,您就无法达到目标。
|