单元格中的数字表示该组件满足此特质的能力的数量。因此，这个数越大，该交叉点需要的测试点就越多。例如，Page View组件有3个能力影响到Sharing这个特质。
- 协作者都有权限访问相关文档。
- 与另外一个协作者分担页面管理责任。
- 查看一个页面中协作者的位置。
这些能力点可以很方便地指定Page View / Sharing这个组件/特质对需要的测试。我们可以直接为这些能力点编写测试用例，或者将它们组合成更大的用例或测试场景来测试能力的组合。
书写良好的能力需要一些训练。下面是一些能力应该满足的特性以供参考。
（1）一个能力点应当被表达为一个动作，反映了用户使用被测应用完成一定的活动。
（2）一个能力点应当为测试人员提供足够的指导，用以理解在编写测试用例时涉及到的变量。例如，使用https处理钱款交易这个能力，需要测试人员理解系统支持何种类型的钱款交易、如何验证交易是通过https进行的。显然，这里有很多工作要做。如果某些钱款交易有被遗漏的可能（如被某个测试新人），那么就一定要把这个能力复制多份，以便能明确的展示各种交易类型。如果不会发生遗漏，原来的抽象程度就足够了。同样的，如果https是大家都理解的东西，那这个词无需额外解释。千万不要掉进把一切东西都当作能力记录下来的陷阱。能力应当是抽象的，把更多的细节留给测试用例或者探索式测试吧（将这些细节留给测试人员，为从不同角度理解能力和编写测试用例留下了自由发挥的空间，这有助于提高测试的覆盖度）。
（3）一个能力应当与其他能力组合。实际上，一个用户故事或用例（或你选择的其他术语）可以用一系列能力来描述。如果一个用户故事无法用现有的能力来表达，那说明你遗漏了一些能力，或者能力描述的抽象程度太高了。
用一系列能力来描述用户故事，这个中间步骤可以为测试带来更大的灵活性。事实上，在Google有几个团队，在与外包接洽或者组织众包型的探索式测试时，更愿意使用比较一般性的用户故事，而不是太细节的测试用例。很细致的测试用例反而会导致外包人员在一遍又一遍的重复执行时产生厌倦感，而用户故事则为确定具体行为留出了更大的余地，从而使得测试更加有趣，较少因为枯燥、死板地执行导致产生错误。
不管最终目标是用户故事、测试用例还是两者兼有，这里是一些从能力到测试用例的一般性指南。记住这些只是目标，而非绝对标准。
- 每个能力都应该链接到至少一个测试用例。如果能力有足够的重要性被记录下来，也应该有足够的重要性被测试。
- 很多能力需要多个测试用例。每当输入、输入顺序、系统变量、使用的数据等存在变化的时候，就需要编写多个测试用例。How to break software一书中提及的攻击，Exploratory Software Testing一书中提及的漫游，都可用来指导测试用例的选择或思考哪些数据和输入最有可能发现一个bug。
- 并非所有的能力都是同等重要的。流程的下一步（在下一节中描述）讨论通过关联风险来区分能力的重要性这一问题。
本文选自《Google软件测试之道》第三章，本站经人民邮电出版社和作者的授权，近期将进行部分章节的连载，敬请期待！
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
相关文章：
