使用ACC编写测试计划

动机

测试计划是用来指导测试实施的, 在实践中, 不妨先考虑如下的几个问题:

• 在什么时候开始编写测试计划? 一般用多长时间来制作出一个测试计划?
• 在你的项目中结束时的测试计划和最初的差异多大? 你会化多少时间来维护测试计划?
• 你觉得测试计划有用吗?
• 如果仅有很少的资源可用, 你会如何分配测试资源?

如果上述问题能够引发你的思考, 说明你是本文的读者之一.

一份适用的测试计划

考虑到项目自身的特殊性, 测试计划的编写都有"此时此地"的特质. 但是这并不妨碍我们先定义一个"好用的"测试计划的通用标准:

• 简单直接, 没有冗余的累述
• 易于维护和扩展, 在简单直接的基础上, 便于在已有的维度上扩展
• 可以用来直接指导测试. 测试计划中包含测试用例

使用ACC编写测试计划

ACC是Attribute-Component-Capability的缩写, 同时也ACC也暗示了编写测试计划的顺序.

列举产品特性(Attribute)

每个产品都有其特性, 这个特性用来描述其和同类产品的区别. 你可以将其理解为产品核心价值. 一般来说都是形容词. 这部分的效率应该是: 10个特性/10~20分钟

如何得到产品特性?

• 产品文档
• 产品经理
• 开发人员
• 市场和运营
• 其他广告文书等

列举产品模块(Component)

每个产品都会由一系列的模块组成, 列出来这些模块. 一个需要注意的问题是粒度, 不要分的太琐碎, 保持一个完整的交互单元是最好的. 比如一个博客系统可以大致分成: 新建文章, 浏览, 评论等等.

如何得到产品的模块?

• 开发人员
• 对于产品的使用经验

列举功能(Capability)

将前两步得到的产品特性和模块组成一个矩阵, 就像下图的表:

acc.png

表中的数字代表你能想到的功能数量. 你在这一步的任务就是尽可能多的列举每个表格中产品应该具备的功能.

• 如果你的发现有的功能无处填写, 那么就意味着你可能需要添加Attribute或者Component了
• 如果某一个表格中所记载的功能太多了, 远远大于其他的表格, 同样意味着可续需要拆分Attribute或者Component.
• 如果有的表格是空的, 不用担心, 可能这个模块中没有功能会反应当前这个产品特性.

同样将你想到的功能整理成一张表单, 可能会是这样:

list.png

测试分级

从两个维度来评估每一个表格的重要性: 频度和影响.

• 频度是如果这个表格中的功能的用户使用频度如何, 很多, 多, 少, 很少.
• 影响是用来评估这个表格中的功能如果出现问题的话, 用户对产品的信心的影响大小: 再也不用了, 抗议, 吐槽, 忍了.

综合上面两个维度的思考, 将表格分成3个或更多的级别: 很重要, 重要 , 一般, 不重要... 一定要用颜色由深到浅, 标识出来:

prio.png

不建议使用完全量化的方法去衡量, 毕竟这是一个相对问题, 我们只需要分清楚谁跟谁比更重要就好了.

测试分级是一个渐进的讨论过程, 做好分级以后尽快发出去, 获得其他人的反馈

如果有可能, 你需要尽可能多的考虑如下人员的意见:

• 产品经理
• 开发人员
• 更高级的管理层
  针对不同的分级, 我们需要采取不同的测试策略和资源投入: 主测, 外包, 天使测等

一些想法

ACC是谷歌测试的一个比较好的实践, 特别是对于互联网产品, 快速有效实用. 实际使用中需要注意的是一定要落地成可以指导测试的具体功能, 必要时需要补充用户的使用场景. 同时, ACC也可以帮助PD, 开发更好的认识产品, 便于统一思路.