请允许我借用雷蒙德●卡佛1981年成名作《当我们谈论爱情时我们在谈论什么》的标题，作为敏捷测试专栏第四篇文章的标题。当然，也请原谅我在这个伟大标题下喃喃自语的私货。

　　在完成了本专栏的三篇文章之后，我感觉自己突然陷入了对敏捷测试的一些不同的思考。敏捷本无定式可循，不同的组织由于文化、产品和用户等的不同，在敏捷的具体做法上自然存在很大的差异——这本是敏捷实施中常态，但最近接触到不少敏捷组织中的测试管理者和测试工程师，大家对于如何在敏捷中做“好的测试”往往争执不下，尤其对于自动化测试，看法更是差异巨大。

　　按照本专栏的计划，本来第四篇文章会以“敏捷测试工程师的绩效”作为主题，但由于以上的原因，我最终还是选择了自动化测试这个主题来谈论敏捷测试。和前三篇文章相比，这一篇更像是杂感。

　　实际上，在本专栏的第二篇文章《自动化测试-敏捷测试的基石》中我已经就敏捷测试中的自动化测试进行了讨论，并给出了一些我认为合适的自动化测试测试策略和方法。为什么我们还需要用一篇文章来讨论自动化测试？ 自动化测试的具体做法肯定不止一种，自动化测试的技术和方法更是多如过江之鲫，但当我们谈论到自动化测试时，我们想传达的是究竟什么信息？

　　Cockburn在《敏捷软件开发》中提到“沟通的成功依赖于发送者和接收者有可以引用的共同体验”，因此当我们提到自动化测试时，就一定需要有共同的词汇表。首先，什么是自动化测试？对一些人来说，一提到自动化测试，第一个闪过脑海的念头就是QTP、WebDriver等自动化测试工具，以及依据这些工具建立的针对功能或是UI的自动化测试测试脚本，但其实这些只是自动化测试中的一小部分而已，在我看来，所有“使用机器的能力”对测试进行部分或全部自动化的操作都应该被叫做“自动化测试”。无论是针对代码中的类或是方法建立的单元测试，还是针对产品建立的需要人工参与的diff的方式，都是自动化测试的具体方法。对测试来说，自动化测试不是一个存在的目标，而仅仅是一种用以达成测试目标的手段。我们希望从自动化测试中得到什么？自动化测试覆盖率？自动化测试覆盖率是用来衡量自动化测试所占比例的一种手段，但这仍然不是我们在项目中开展自动化测试的目标。我们在项目中开展自动化测试，目标只能是“通过自动化测试提高测试或是产品的质量”。因此，在谈论自动化测试时，可以被称为目标的，只能是下面这几项：

　　1、在保证相同的测试覆盖率的情况下，减少人力资源的投入；

　　2、在相同人力资源投入的情况下，增加了测试覆盖率；

　　3、让测试的执行向上游移动，帮助开发者更早的发现产品中的问题，从而降低修复成本。

　　有了目标，剩下来的就是怎么做的问题。“减少人力资源的投入”是一个最容易被直观理解的自动化测试目标，因此，不少团队的做法就是“用自动化测试替代手工测试”，将原先需要手工执行的测试用例变成UI自动化测试用例，改由自动化测试工具来执行脚本。不能说，这种方式没有效果，但由于自动化测试在识别缺陷方面的有效性远远低于手工测试（从UI测试的角度来说，一个非“预期”产生的缺陷很难被自动化测试发现，而手工测试则能轻松的发现这个缺陷），而且由于UI本身的变化性，要想达到和手工测试相同的覆盖率，单纯的UI自动化测试往往很难证明自己的投资回报。

　　“增加测试覆盖率”是自动化测试可以产生收益的另一个方面。容易想到的例子是性能测试和模糊测试（Fuzz testing）。依靠机器的能力，模拟大量用户的并发，以及依靠机器的能力，基于规则产生大量随机数据并发送给服务器，用于检测服务器可能的安全性问题，在这些领域，自动化测试能带来明显的收益。但，当我说到“增加测试覆盖率”时，我所想要谈论的不仅仅是性能测试或是模糊测试这一类的针对应用某个质量属性的验证。在说到“覆盖率”时，我脑海中的另一个场景是“通过自动化测试覆盖应用中更多的接口和服务”——也就是说，通过自动化测试的方式覆盖那些在UI和功能测试无法或很难达到的部分。这一类的自动化测试可以与集成测试中的测试方式和方法进行类比，关注的是对子系统或是模块之间接口的验证。但作为自动化测试来说，关注的不仅仅是建立对接口和服务的验证脚本，往往还需要通过推动接口和服务设计的合理性，使得建立尽可能多和尽可能完善的接口/服务的自动化测试成为可能。假设我们要对某web应用的Frontend进行接口/服务级别的自动化测试，显然，在这个Frontend应用中存在很多接口和可以被解耦的服务。如果Frontend采用了类似Clearsilver+Java的开发方式，从理论上来说，这里存在一个天然的接缝：Clearsilver作为“模板系统”，提供的主要是展现页面的能力；Java代码则主要是业务逻辑实现；Java代码通过填充模板中的动态数据项来生成用户所能看到的页面。在这种模式下，如果能够推动应用具有良好的分层设计，使得Clearsilver端完全不包含逻辑实现，而且可以通过某种方式直接访问逻辑部分（Java代码）生成的所有动态数据，那么，在自动化测试中就可以考虑采用完全不同的方式验证模板部分和Java代码部分：用浏览器展现填充了数据的模板，基于图片比较的方式进行测试和diff；用数据验证或是diff的方式验证Java逻辑实现的正确性。通过这种方式，就能够为应用建立更多层次的验证和测试。这部分的自动化测试设计与实施通常同时伴随着可测试性设计。寻找应用中可能的测试点，改善应用的可测试性，进而为应用建立更多的不同测试的自动化测试，这就是“增加测试覆盖率”的一般方式。