动机

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

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

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

一份适用的测试计划

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

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

使用ACC编写测试计划

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

列举产品特性(Attribute)

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

如何得到产品特性?

产品文档

产品经理

开发人员

市场和运营

其他广告文书等

列举产品模块(Component)

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

如何得到产品的模块?

开发人员

对于产品的使用经验

列举功能(Capability)

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

acc.png

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

如果你的发现有的功能无处填写, 那么就意味着你可能需要添加Attribute或者Component了

如果某一个表格中所记载的功能太多了, 远远大于其他的表格, 同样意味着可续需要拆分Attribute或者Component.

如果有的表格是空的, 不用担心, 可能这个模块中没有功能会反应当前这个产品特性.

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