测试计划是最早出现,最先被遗忘的测试产物.在项目早期,测试计划代表了对软件功能的预期.但是,除非得到持续的关注,它会很快随着新代码的完成,功能特性的改变以及设计的调整而过期.伴随着计划内或计划外的变更,维护一份测试计划是要花费大量精力的,除非多数项目的成员会定期查看,否则测试计划并没有什么价值.

      后面这一点是测试计划真正的杀手:试问在产品的整个生命周期中,测试计划能在多大程度上作为测试活动的指导?测试人员会不断参考计划来安排一个应用的测试吗?会要求开发人员在功能增加或修改时去更新测试计划吗?在开发经理管理todo列表的时候,他们会在桌面上打开一份测试计划吗?在进展沟通会议上,测试经理会经常参考测试计划的内容吗?如果测试计划真的重要,那么所有这些事情应该每天都会发生.

     理想情况下,测试计划应当在项目执行中发挥核心作用,应当在软件的整个生命周期中持续有效:随着代码库的更新而更新,时刻代表最新的产品功能,而不是停留在项目开始阶段时的样子.他应该可以帮助一个新加入的工程师迅速跟上项目进展.

    下面是我们希望测试计划中具有的一些特性.

• 及时地更新
• 描述了软件的目标和卖点
• 描述了软件的结构,各种组件和功能特性的名称
• 描述了软件的功能和操作简介
• 不必花过多的时间去撰写,必须随时可以被修改
• 应该描述必测点
• 应该能在测试中提供有用的信息,从而帮助确定进展以及覆盖率上的不足.

   ACC(Attribute Component Capability,即特质,组件,能力.这是一种测试计划的替代方法)分析是一个从许多Google测试团队的最佳实践中总结出来的,并被专业人士在各种产品领域里倡导的流程.

   ACC的指导原则如下.

• 避免散漫的文字,推荐使用简明的列表.
• 不必推销.
• 简洁
• 不要把不重要的,无法执行的东西放进测试计划.
• 渐进式的描述
• 指导计划者的思路
• 最终结果应该是测试用例

    最后一点非常重要:如果测试计划没有把测试用例应该怎么执行描述的足够详细,它就没有达到预先设定的帮助测试的本义.对测试的计划而言,他显然应该让我们清楚地知道需要编写哪些测试用例.当你正好处于"完全了解需要编写哪些测试"这一点时,才算完成了测试计划.

   ACC通过指导计划者依次考察产品的三个维度达成这个目标:描述产品目标的形容词和副词;确定产品各部分,各特性的名词;描述产品实际做什么的动词.这样,我们通过测试完成的就是验证这些能力能正常运作,产品各组件能满足应用的目标.

1.  A代表特质(Attribute)

• 简单
• 精确
• 变化
• 短小

    2. C代表组件(component)

     组件是系统的名词,在特质被识别之后确定.组件是构成待建系统的模块,例如在线商店的购物车和结账系统,Word处理器的格式化和打印功能等.组件是使一个软件之所以如此的关键代码块.实际上,他们正式测试人员要测试的对象.

    3. C代表能力(capability)  

    能力是系统的动词,代表着系统在用户指令之下完成的动作.他们是对输入的响应,对查询的应答,以及代表用户完成的活动.事实上,这正是用户选择一个软件的原因所在:他们需要一些功能而你的软件提供了这些功能.

 

参考书籍:Google的软件测试之道