关于实现测试设计规范以启用其执行的逐步指令。
角色: 实施者 
可选/发生: 取决于开发人员测试的范围和详细程度:对子系统测试而言,将进行所需数目、有适当覆盖范围的测试;对较小的组件而言,通常仅对其关键方面进行测试。
模板和报告:
     
示例:
     
UML 表示: 不适用。
更多信息:  
活动输入:   活动输出:  

目的 回到页首

开发人员测试的目的在于以高效且有效的方式提供所需测试的子集的实施。

简述 回到页首

每个开发人员测试应考虑包括以下各项在内的各个方面:

  • 基本计算机硬件需求;例如,处理器、内存、硬盘存储器、输入/输出接口设备。
  • 基本底层软件环境;例如,操作系统和诸如电子邮件或日历系统的基本生产力工具。
  • 附加的专用输入/输出外围硬件;例如条形码扫描仪、收据打印机、收款机和传感器设备。
  • 用于专用输入/输出外围硬件的必需软件;例如驱动程序、接口和网关软件。
  • 促进测试、评估和诊断活动所需的软件工具的最小集合;例如,内存诊断、自动测试执行等等。
  • 硬件和软件选项的必需配置设置;例如视频显示器分辨率、资源分配、环境变量等。
  • 必需的“预先存在”消耗品;例如已填充的数据集、收据打印机记录以及类似物品。

属性 回到页首

这些属性均无 UML 表示。开发人员测试的正式程度是不同的,因此在实施中可能将略去或加入以下一些信息。通常,要测试的组件越大、越重要,那么需要在开发人员测试维护中投入的工作就越多。

属性名 简述
名称 用于标识该开发人员测试的唯一名称。 
描述 对开发人员测试的内容的简短描述,通常提供关于复杂性和范围的某个高级别的指示。 
目的 对此开发人员测试代表什么、为何重要的说明。 
从属的测试和评估项 映射到特定元素(例如需要参考的个别需求)的某种形式的可跟踪性或依赖关系。 
前置条件 在执行开发人员测试之前必须达到的开始状态。 
指令 关于执行手动测试的逐步指令,或机器可读指令(执行时,以与以下操作相似的方式激励软件:将由相应的参与者(人类或其它)执行这些操作)。 
观测点 开发人员测试指令中的一个或多个位置,在此,将观测系统状态的某方面且通常将观测值与期望的结果相比较。 
控制点 开发人员测试指令中的一个或多个位置,在此,系统中的某情况或事件可能发生且需要考虑该情况或事件,以确定要遵循的下一条指令。 
日志点 开发人员测试指令中的一个或多个位置,在此,将记录执行测试脚本状态的某方面,以供未来参考。 
后置条件 执行开发人员测试之后,系统必须处于的结果状态。 

 

计时 回到页首

在与需要测试的软件组件相同的时限中创建大多数开发人员测试。开发组件之后,则开发由变更请求驱动的测试,若测试目标仅仅是在可控性更好的环境中再现缺陷,那么大多数情况下,这些测试的生命期都相当短。

职责 回到页首

实施者 角色主要负责该工件。这些职责包括:

  • 根据设计规范,以高效且有效的方式开发测试
  • 遵循已定义的指南,以确保测试是可维护的且与其它测试保持一致
  • 管理变更
  • 确定需要维护的测试,并清除或标记在目的和时间上有所限制的测试
  • 确定重用和简化的机会

定制 回到页首

整体目标是实现简单且高效的开发人员测试框架。对“仅执行一次”的测试而言,应避免大多数的文档开销。应特别关注用作以下各项的回归测试的那些测试:子系统,或是那些在文档、可维护性、效率、有效性和强健性方面更“易于变化”的组件。



Rational Unified Process   2003.06.15