《Google软件测试之道》—第1章1.5节测试类型

本节书摘来自异步社区《Google软件测试之道》一书中的第1章1.5节测试类型，作者【美】James Whittaker , Jason Arbon , Jeff Carollo，更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.5　测试类型
Google并没有使用代码测试、集成测试、系统测试等这些命名方式，而是使用小型测试、中型测试、大型测试这样的称谓（不要和敏捷社区发的那些T恤型号混为一谈），着重强调测试的范畴规模而非形式。小型测试意味着涵盖较少量的代码，其他的测试类型以此类推。Google的三类工程师都会去执行其中的任何一种测试，无论是自动化的还是手动的。测试的规模越小，就越有可能被实现成为自动化的测试。

提示
Google并没有使用代码测试、集成测试、系统测试这些命名方式，而是使用小型测试、中型测试、大型测试这样的称谓，着重强调测试的范畴规模而非形式。
小型测试__一般来说（但也并非所有）都是自动化实现的，用于验证一个单独函数或独立功能模块的代码是否按照预期工作，着重于典型功能性问题、数据损坏、错误条件和大小差一错误（译注：大小差一（off-by-one）错误是一类常见的程序设计错误）等方面的验证。小型测试的运行时间一般比较短，通常是在几秒或更短的时间内就可以运行完毕。通常，小型测试是由SWE来实现，也会有少量的SET参与，TE几乎不参与小型测试。小型测试一般需要使用mock和fake（译注：mock对象是指对外面依赖系统的模拟，在运行时刻可以根据假设的需求提供期望的结果。fake对象是一种虚假的实现，内部使用了固定的数据或逻辑，只能返回特定的结果。更多参见http://stackoverflow.com/questions/346372/whats-the-difference-between-faking-mocking-and-stubbing）才能运行。TE几乎不编写小型测试代码，但会参与运行这些测试，来诊断一些特定错误。小型测试主要尝试解决的问题是“这些代码是否按照预期的方式运行”。

中型测试__通常也都是自动化实现的。该测试一般会涉及两个或两个以上，甚至更多模块之间的交互。测试重点在于验证这些“功能近邻区”之间的交互，以及彼此调用时的功能是否正确（我们称功能交互区域为“功能近邻区”）。在产品早期开发过程中，在独立模块功能被开发完毕之后，SET会驱动这些测试的实现及运行，SWE会深度参与，一起编码、调试和维护这些测试。如果一个中型测试运行失败，SWE会自觉地去查看分析原因。在开发过程的后期，TE会通过手动的方式（如果比较难去实现自动化或实现的代价较大时），或者自动化地执行这些用例。中型测试尝试去解决的问题是，一系列临近的模块互相交互的时候，是否如我们预期的那样工作。

大型测试__涵盖三个或以上（通常更多）的功能模块，使用真实用户使用场景和实际用户数据，一般可能需要消耗数个小时或更长的时间才能运行完成。大型测试关注的是所有模块的集成，但更倾向于结果驱动，验证软件是否满足最终用户的需求。所有的三种工程师角色都会参与到大型测试之中，或是通过自动化测试，或是探索式测试。大型测试尝试去解决的问题是，这个产品操作运行方式是否和用户的期望相同，并产生预期的结果。这种端到端的使用场景以及在整体产品或服务之上的操作行为，即是大型测试关注的重点。

注意
小型测试涵盖单一的代码段，一般运行在完全虚假实现（fake）的环境里。中型测试涵盖多个模块且重点关注在模块之间的交互上，一般运行在虚假实现（fake）环境或真实环境中。大型测试涵盖任意多个模块，一般运行在真实的环境中，并使用真正的用户数据与资源。
小型、中型、大型等描述术语是什么并不重要，怎么称呼它们也都可以，只要大家都一致认可。重要的是，在Google测试人员使用统一术语来谈论他们测试的是什么，以及这些测试范围是如何划分的。一些雄心勃勃的测试者有时会说到第四级别的测试，即被称为“超大型测试”，公司里的其他测试同仁会认为这是一个超大级别的系统测试，涵盖所有的功能且运行时间会非常长。对于一些术语，不需要用过多的文字去解释，按照字面意思就可以理解，这样做是最好的。

我们的测试对象以及测试范围的大小是动态变化的，不同产品之间的区别也比较明显。Google喜欢频繁地发布，并快速地从外部用户那里得到产品的真实反馈，然后再迭代开发出新功能。Google积极努力地开发用户非常感兴趣的产品特性，并尽可能早地提供一些功能给用户使用。另外，我们也在避免做一些用户不想要的产品特性，这就要求我们要非常及时地把用户和外部开发者一起拉进来参与，这样可以更有利于判断我们发布的产品是否满足用户的真正需求。

最后，关于自动化测试和手动测试的比例，对于所有的三种类型测试，当然更倾向于前者。如果能够自动化，并不需要人脑的智睿与直觉来判断，那就应该以自动化的方式实现。但在一些情况下需要人类智慧的判断，例如，用户界面是否漂亮、保留的数据是否包含隐私等，这些还是需要手动测试来完成。

注意
对于所有的三种类型测试，当然更倾向于前者。如果能够自动化，并不需要人脑的智睿与直觉来判断，那就应该以自动化的方式实现。
正如上文中提到的，同时也是值得重点关注的一点，Google也有大量的手动测试，有些使用脚本的方式在记录（译注：scripted case，把每一个步骤都记录下来的用例表示方式。注意，这里scripted case，不是指通过脚本实现的自动化用例，这里只是强调一种case的实现方式），而另外一些使用探索式的方法，这些测试都在被密切地关注，以后可能被自动化方式所替代。通过使用定位点击的验证方式、录制技术等可以把一些手动测试转变成自动化测试，这些自动化测试在每次建立之后都会重复地回归运行，而手动测试更倾向于关注于新功能。我们甚至把开bug和日常的手动工作都自动化实现了，例如，如果自动化用例运行失败，系统会自动检查到最后一次代码变更的内容，这些变更极有可能是造成失败的罪魁祸首。系统会自动给代码变更的提交者发送一封邮件，并新开一个bug来记录这个问题。将自动化做到，力争克服“人类智慧的最后一英寸”这也是Google的设计理念与目标，也正是正在构建之中的下一代测试工具的努力方向。

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。