ACC的指导原则如下。
- 避免散漫的文字，推荐使用简明的列表。并不是所有的测试人员都想当小说家，也不具备将一个产品的目标或测试需求表达成散文的技能。而且，冗词赘句容易误读，只列出要点和事实就行了。
- 不必推销。测试计划不是营销文案，既不是要讨论一个产品满足了多么重要的市场定位，也不是讨论这个产品有多么酷的功能。测试计划不是给客户或分析师看的，它的受众人群是工程师。
- 简洁。测试计划并没有长度的要求。它不是中学的项目作业，长度无关紧要，不是越长越好。计划的大小与测试问题的规模有关，与作者的写作欲望无关。
- 不要把不重要的、无法执行的东西放进测试计划。相关人员毫不关心的东西，就一个词也不要出现。
- 渐进式的描述（Make it flow）。测试计划的每个部分应该是前面部分的延伸，以便读者可以随时停止阅读并且对产品的功能有一个初步的印象。如果读者希望了解更多的细节，那么他可以继续读下去。
- 指导计划者的思路。一个好的计划过程能帮助计划者思考产品功能及其测试需求，从而有条不紊地从高层概念过渡到可以被直接实现的低层细节。
- 最终结果应该是测试用例。在计划完成的时候，它不仅要清楚地描述要做什么样的测试，并且还可以清楚地指导测试用例的编写。做出一个不直接指导测试的计划纯粹是在浪费时间。
做出一个不直接指导测试的计划纯粹是在浪费时间。
最后一点非常重要：如果测试计划没有把测试用例应该怎么执行描述得足够详细，它就没有达到预先设定的帮助测试的本义。对测试的计划（the planning of tests）而言，它显然应该让我们清楚地知道需要编写哪些测试用例。当你正好处于"完全了解需要编写哪些测试"这一点时，才算完成了测试计划。
ACC通过指导计划者依次考察产品的三个维度达成这个目标：描述产品目标的形容词和副词；确定产品各部分、各特性的名词；描述产品实际做什么的动词。这样，我们通过测试完成的就是验证这些能力（capabilities）能正常运作、产品各组件（component）能满足应用的目标。
1．A代表特质（Attribute）
在开始测试计划或做ACC分析的时候，必须先确定该产品对用户、对业务的意义。我们为什么要开发这个东西呢？它能带来什么核心价值？它又靠什么来吸引用户？记住，我们既不需要为这些问题做辩护，也不需要做什么解释，只要写下来就行了。我们可以假定产品经理和做产品计划的人，或者开发人员已经在这方面做了该做的事情。从测试的角度看，我们只需要确定并记下来，以备后续测试使用即可。
我们通过一个称为特质、组件、能力分析的过程来记录这些核心价值。
特质是系统的形容词，代表了产品的品质和特色，是区别于竞争对手的关键。在某种程度上，是人们选择你的产品而不是竞争对手的产品的原因。例如，Chrome的定位是快速、安全、稳定和优雅，这正是我们通过ACC记录的特质。之后，我们希望能够将测试用例关联到这些标签，这样，我们就会知道在验证Chrome的快速、安全等特质方面已经完成了多少测试。
特质是系统的形容词，代表了产品的品质和特色，是区别于竞争对手的关键也是人们选择你的产品而不是竞争对手的产品的原因。
一般来说，产品经理会整理一个系统特质的列表，测试人员通过阅读产品需求文档、团队愿景和使命声明，甚至是听销售跟潜在的客户描绘这个系统来确定这个列表。说真的，我们发现在Google里，推销员和产品传道士是极佳的特质来源。想象一下箱体广告或你的产品将要如何在QVC（译注：QVC是全球最大的电视与网络的百货零售商，含义是Quality质量、Value价值、Convenience便利，通过电视与网络购物服务直达美国8,000万户以上的家庭）上做宣传，你就会找到列出这些特质的感觉了。
本文选自《Google软件测试之道》第三章，本站经人民邮电出版社和作者的授权，近期将进行部分章节的连载，敬请期待！
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
相关文章：
