测试人员对 RUP 四个阶段的贡献[3] 软件测试
测试设计和实现
测试人员的一项主要任务是测试脚本的设计和实现。在迭代开发中，这是由为当前迭代安排的场景所驱动的。测试脚本必须开发成能够将应用程序推到正确的“屏幕”或其他应用程序模式。测试数据必须开发成可以在此处执行应用程序，并且验证必须设计成可以核对应用程序的行为。
如果使用了自动化的测试工具，那么此时会提出某种考虑，关于该测试用例是否是好的自动化候选或者是否应该手动执行。
测试执行
执行测试来确定每个验证点的通过或失败状态。执行手动测试意味着有方法地遵守测试实现提示并适当地观察和注意结果。
执行自动化的测试意味着安排正确的系统初始条件，然后调用脚本回放工具。在控制初始条件时，我们希望管理测试过程中什么数据处于什么状态。该需求也适用于手动测试，区别在于测试人员可以“照顾”交互并且经常让测试不工作来工作于未初始化的开始条件周围。
回归和测试脚本维护
迭代开发的一个明确的任务是需要为每个新的迭代再次运行旧的测试。这种对现有测试集的重复执行称为回归测试，是一个显露出自动化测试的好处和负担的活动。好处：因为另一种是手动测试，很明显的耗费时间的活动。负担：因为自动化的脚本经常需要仔细的修改来服务于下一个构建。测试脚本维护，和脚本回放调试器，对测试人员来说将会是非常熟悉的。测试人员将会及早并且使用减少脚本退化的测试工具，了解如何减少维护工作。
缺陷跟踪和分辨
缺陷跟踪和分辨活动是测试人员都知道的。测试行为总是揭示缺陷或问题，并且必须勤奋地跟踪每个事故来进行分辨。首先，分辨通常需要在实验室中复制的错误，但至少是处于这个原因，即 SEI Capability Maturity Model Integration (CMMI) 要求项目团队实现配置管理以达到有威信的“可重复级别, 级别 2”。只有通过将所有开发文件置于该控制下，并且用材料清单描述每个构建，开发人员才可能有许多机会重复所有已知的事件并因此能够满足该标准。
为了提高项目角色之间缺陷信息的共享，用开发人员使用的同样的配置管理和缺陷跟踪环境来装备测试人员是合理的。
针对进展的量度
我们已经回顾了测试人员在构建阶段所做的事情。我们如何将其转化为进展的量度呢?有多种描述恰当的技术， 3 以下的处理是可以借鉴的。
完成百分比
度量进展的一个过分简单但特别实际的方法是利用“完成百分比”作为量度。如果有人考虑通过测试的场景的流程，我们可以考虑构造一组检查点，表 1 中所显示的一个实例。
表 1：测试流中的检查点 检查点 描述
被识别的场景 放弃用例分析。被识别的可选流和例外流的有趣的组合。在精化阶段的末尾完成 80%。
详细的场景 使对象与所描述的事件顺序协作。
文章来源于领测软件测试网 https://www.ltesting.net/
