工件:
|
![]() |
关于实现测试设计规范以启用其执行的逐步指令。 |
---|---|
角色: | 实施者 |
可选/发生: | 取决于开发人员测试的范围和详细程度:对子系统测试而言,将进行所需数目、有适当覆盖范围的测试;对较小的组件而言,通常仅对其关键方面进行测试。 |
模板和报告: |
|
示例: | |
UML 表示: | 不适用。 |
更多信息: |
活动输入: | 活动输出: |
开发人员测试的目的在于以高效且有效的方式提供所需测试的子集的实施。
每个开发人员测试应考虑包括以下各项在内的各个方面:
这些属性均无 UML 表示。开发人员测试的正式程度是不同的,因此在实施中可能将略去或加入以下一些信息。通常,要测试的组件越大、越重要,那么需要在开发人员测试维护中投入的工作就越多。
属性名 | 简述 |
---|---|
名称 | 用于标识该开发人员测试的唯一名称。 |
描述 | 对开发人员测试的内容的简短描述,通常提供关于复杂性和范围的某个高级别的指示。 |
目的 | 对此开发人员测试代表什么、为何重要的说明。 |
从属的测试和评估项 | 映射到特定元素(例如需要参考的个别需求)的某种形式的可跟踪性或依赖关系。 |
前置条件 | 在执行开发人员测试之前必须达到的开始状态。 |
指令 | 关于执行手动测试的逐步指令,或机器可读指令(执行时,以与以下操作相似的方式激励软件:将由相应的参与者(人类或其它)执行这些操作)。 |
观测点 | 开发人员测试指令中的一个或多个位置,在此,将观测系统状态的某方面且通常将观测值与期望的结果相比较。 |
控制点 | 开发人员测试指令中的一个或多个位置,在此,系统中的某情况或事件可能发生且需要考虑该情况或事件,以确定要遵循的下一条指令。 |
日志点 | 开发人员测试指令中的一个或多个位置,在此,将记录执行测试脚本状态的某方面,以供未来参考。 |
后置条件 | 执行开发人员测试之后,系统必须处于的结果状态。 |
在与需要测试的软件组件相同的时限中创建大多数开发人员测试。开发组件之后,则开发由变更请求驱动的测试,若测试目标仅仅是在可控性更好的环境中再现缺陷,那么大多数情况下,这些测试的生命期都相当短。
实施者 角色主要负责该工件。这些职责包括:
整体目标是实现简单且高效的开发人员测试框架。对“仅执行一次”的测试而言,应避免大多数的文档开销。应特别关注用作以下各项的回归测试的那些测试:子系统,或是那些在文档、可维护性、效率、有效性和强健性方面更“易于变化”的组件。
Rational Unified Process
|