自动化测试的分类

本节以不同的视角重新审视测试象限。先来仔细看看象限图，如下图所示：

 

 

我们将支持团队的两个象限（象限一和象限二）标记为使用自动化。在象限四中，从技术视角来看，用于评价产品的工具通常也需要自动化。采用自动化业务测试工具来支持团队。只有象限三----评价产品的业务测试----没有标记为使用自动化。工具对于某些测试来说还是有用的，比如，自动化可以创建好测试数据和用户场景对日志进行分析。

请通过每个象限来识别每个项目（甚至是每个迭代）所需的各种自动化工具。仔细检查每个象限并给出所需工具的清单。假设我们准备重新设计UI，看看象限一，怎么能做测试先行呢？我们知道如何对表现层进行单元测试么?需要新的工具完成这项任务么？看看象限二，我们需要作出原型：仅仅写在纸上就行了么？还是需要创建一个Oz类型活动向导？需要使用什么工具创建可执行的业务测试来指导开发呢？需要更新或是替换掉现有的回归测试脚本么？我们知道象限三中有一个活动叫做可用性测试。这需要提前做好测试。我们希望通过工具追踪用户活动，这样就可以进一步分析这些活动了。看看象限四，我们发现负载测试脚本使用的还是旧的UI，因此不得不花些时间将其更新到新的UI上。

正如第三部分所强调的，象限的顺序与测试的顺序没有什么关系。在准备好每类测试所需的工具清单后，我们会考虑何时进行测试，这样就会提前准备好自动化工具。比如，某个团队重新设计了一个新的架构并打算尽快运行可伸缩性测试。这样，他们就需要在项目第一个迭代中花些时间来寻找或是实现性能测试工具。

象限有助于我们了解所需的工具，但各个层次上有这么多自动化工具，我们该何去何从呢？因此有必要了解不同类型的测试所适用的地方以及如何组织这些测试。为了快速、频繁的交付价值，自动化需要高度的ROI。测试金字塔可以帮助我们优化对测试的投入。