测试人员在工作中被要求写测试计划，是一件很平常的事情，但是很多人并不想写。测试计划的生命周期实在太短，很大程度仅代表一个里程碑，写完评审通过，基本没有人会再去关心和呵护。
项目时间很长，有时间和精力去维护测试计划，那是非常理想的状态。很多时候刚写完，项目就会出现各种计划内或计划外的变更，除非被强制要求，不然不会有人主动地不断维护测试计划。
很多时候感觉测试计划就像以前家里的古董落地钟，很大一个，（排除坏了的情况）不受任何约束地提醒人们现在是几点，非常的有计划性，但是严重不符合现代人对钟表的标准。
最近在看《Google测试之道》这本书，里面提到一个测试计划的替代方法ACC（Attribute Component Capability，即特质、组件、能力）。
ACC标准：
避免散漫的文字，推荐使用简明的列表，冗词赘句容易误读，只列出要点和事实就行了；
不必推销，受众人群是工程师；
简洁，计划的大小与测试问题的规模有关，与作者的写作欲望无关。
不要把不重要、无法执行的东西放进测试计划；
渐进式的描述（make it flow)。测试计划的每个部分应该是前面部分的延伸，以便读者可以随时停止阅读并且对产品的功能有一个初步的印象。
指导计划者的思路。一个好的计划过程能帮助计划着思考产品功能及其测试需求，从而有条不紊地从高层概念过度到可以被直接实现的低层细节。
最终结果应该是测试用例。在计划完成的时候，它不仅要清楚地描述要做什么样的测试，并且还可以清楚地指导测试用例的编写。做出一个不直接指导测试的计划纯粹是在浪费时间。
目标
对测试的计划（the planning of tests）而言，它显然应该让我们清楚地知道需要编写哪些测试用例。当你正好处于“完全了解需要编写哪些测试”这一点时，才算完成了测试计划。
三个维度
ACC通过指导计划者依次考察产品的三个维度达成这个目标：
1、描述产品目标的形容词和副词
2、确定产品各部分、各特性的名词
3、描述产品实际做什么的动词
A代表特质（Attribute）：
代表了产品的品质和特色，是区别于竞争对手的关键。
特质：简单（1-2小时完成）、精确（确保文案和营销信息被团队普遍认同）、变化（不必担心遗漏）、短小（数量方面十二个以内）
C代表组件（component）：
组件是系统的名词，在特质被识别之后确定。组件是构成待建系统的模块，正是测试人员要测试的对象。识别组件，一样要确保短小的列表。
！不必担心完整性。整个ACC过程的要点是快速行动，动态迭代。
C代表能力（capability）：
能力是系统的动词，代表着系统在用户指令之下完成的动作。它们是对输入的响应、对查询的应答，以及代表用户完成的活动。
能力一般是面向用户的，表达的是用户眼里系统的行为，往往比特质和组件都要多很多。ACC的前两步遵循简洁法则，而能力则应当描述系统的完整功能，因此基于应用的功能丰富性和复杂性，能力在数量上可以很大。
能力最重要的一个特点是它的可测试性。
网友评论