这里是一个例子，展示了一个在线商店具有的能力。
- 从购物车里增加或删除物品。这是Cart（购物车）组件在满足直观的UI（Intuitive UI）特质时的一个能力。
- 获得信用卡和验证数据。这是Cart组件在满足便利（convenient）特质和集成（Integrated）特质（如与支付系统集成）时的一个能力。
- 使用HTTPS处理钱款交易。这是Cart组件在满足安全（secure）特质时的一个能力。
- 基于购物者正在浏览的商品提供建议。这是Search组件在满足便利（convenient）特质时的一个能力。
- 计算送货成本。这是UPS集成组件在满足快速（fast）和安全（secure）特质时的一个能力。
- 显示剩余库存。这是Search组件在满足便利（convenient）和精准（accurate）特质时的一个能力。
- 推迟购买。这是Cart组件在满足便利（convenient）特质时的一个能力。
- 根据关键字、SKU和类目搜索商品。这是Search组件在满足便利（convenient）和精准（accurate）特质时的一个能力。一般情况下，我们倾向于把每一种搜索当作一个单独的能力。
显然你会发现大量的能力。当你感到正在列出所有可测之处的时候，说明你已经掌握了ACC的精髓，那就是快速简明的列出保证待验证系统能正常运转的那些最重要的能力。
能力一般是面向用户的，表达的是用户眼里系统的行为，往往比特质和组件都要多很多。ACC的前两步遵循简洁法则，而能力则应当描述系统的完整功能，因此基于应用的功能丰富性和复杂性，能力在数量上可以很大。
就我们在Google 涉及的系统而言，大型复杂应用拥有成百上千个能力（例如，Chrome OS有300多项能力），而较小的应用则有数十个能力。当然，只有几个能力的产品也是有的，往往只需要开发人员自己或少数早期用户做一些测试就行了。因此，当所测产品的能力少于20个时，可能需要反思一下自己在这个项目中的意义。
能力最重要的一个特点是它的可测试性。这是我们用主动语态来表达能力的主要原因。它们是动词，因为我们为了完成某个动作，我们不得不编写测试用例去验证这个能力得到了正确的实现，而用户将因为这个特性而喜欢这个产品。后面我们将讨论如何把能力转换成测试用例。
能力最重要的一个特点是它的可测试性。
在罗列能力时，应该达到什么样的抽象级别呢？这在Google TE中存在很大的争议。依其定义，能力不是原子动作。一个能力可以描述任意数量的用例。在之前描述在线商店的例子中，能力描述并没有限定购物车中的商品或一个搜索的结果，而只是表达了用户可能会做的事情。这是有意的，因为太多的细节会导致长篇大论。穷尽所有可能的搜索和购物车配置来完成测试是不可能的。因此，我们在把能力转换成测试用例的时候，只会重点考察那些实际使用的测试场景。
能力描述并不是测试用例，不会包含实际测试所需要的一切信息，例如特定的值和具体的数据。能力只要说明用户可以购物，而测试用例则要指定他们买什么东西。能力是软件可以提供或者用户可能要求的动作的一般性概念，是抽象的，测试和价值隐含其中，但它们不是测试本身。
还是以Google Sites为例，图3.5给出了一个以特质为x轴，组件为y轴的表格。通过这种方法，能力被映射到特质和组件。首先，注意大量的单元格是空的。这很正常，因为不是每个组件对每个特质都有影响。对Chrome来说，只有一部分组件对快速或安全性负责；而其他组件对这些特质却没有影响，对应的单元格就为空。空单元格表示我们不必测试这个特定的特质组件对。
▲图3.5 在GTA中，能力被关联到特质和组件
能力表的每一行或列表示按某种方式相关联的一个功能切片，是将应用功能分解为多个可测试的活动的一个好办法。测试经理可以把每一行分给一个测试小组，或者针对一行或一列进行深度的bug大扫除。行或列也是探索式测试的极好目标，每个探索式测试人员负责不同的行和列，就可以有效避免重叠，并达到更高的覆盖度。
