谷歌没有使用单元测试、集成测试、系统测试等这些命名方式，而是使用小型测试、中型测试、大型测试这样的称谓，着重强调测试的范围规模而非形式。小型测试意味着涵盖叫少量的代码，其他的测试类型以此类推。谷歌的三类工程师都回去执行其中的任何一种测试，采用自动化或者手工的形式。测试的规模越小，就越有可能被实现成为自动化脚本。
小型测试一般来说（但也有例外）都是自动化实现的，用于验证一个单独函数或独立功能模块的代码是否按照预期工作，着重于典型功能性问题、数据验证、错误条件和大小写错误等方面的验证。小型测试的运行时间一般比较短，通常在秒级或者更短的时间内疚可以运行完毕。通常，小型测试有SWE来实现，偶尔也会有SET参与，而TE则几乎不会参与。小型测试一般需要使用mock和fake才能运行。小型测试主要解决的问题是“这些代码是否按照预期的方式运行”。
中型测试通常也都是自动化实现的。该测试一般会涉及两个或两个以上，甚至更多模块之间的交互。测试重点在于验证这些“功能近邻区”之间的交互，以及彼此调用时的功能是否正确。在产品的早期开发过程中，在独立模块功能被开发完毕之后，SET会驱动这些测试的实现及运行，SWE会深度参与，一起编码、调试和维护这些测试。如果一个中型测试运行失败，SWE会自觉地去查看并分析原因。在开发过程的后期，TE会通过手动的方式（如果比较难实现自动化或者自动化成本太高）或者自动化地执行这些用例。中型测试尝试去解决的问题是“一系列邻近的模块交互的时候，是否如我们预期的那样工作”。
大型测试涵盖三个或以上的功能模块，使用真实用户场景和实际用户数据，一般可能需要消耗数个小时或更长的时间才能运行完成。大型测试关注的是所有模块的集成，倾向于结果驱动，验证软件是否满足最终用户的需求。所有的三种工程师角色都会参与到大型测试之中，或是通过自动化测试，或是通过探索式测试。大型测试尝试去解决的问题是“这个产品操作运行方式是否和用户的期望相同，并产生预期的结果”。
最后，关于自动化测试和手工测试的比例，对于所有的三种
网友评论