测试计划以及ACC介绍

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

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

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

    下面是咱们但愿测试计划中具备的一些特性.

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

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

   ACC的指导原则以下.

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

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

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

1.  A表明特质(Attribute)

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

    2. C表明组件(component)

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

    3. C表明能力(capability)  

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

 

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