在测试层级的划分方面我们没有采用代码级、集成级、系统级这样的分类方式，取而代之的小测试、中测试、大测试，这样做是为了强调测试的规模而不是外在形式。小测试只会覆盖一小撮代码，然后是中、大测试。不论是SWE、SET、还是TE，都会执行这三类的测试，可能是通过自动化的方式开展也可能是手工的方式。
小测试通常（但不总是）通过自动化的方式来运行，它只会运行一个函数或一个模块的代码。通常他们都是由SWE或SET来完成编写的，他们的运行可能会需要mock环境，TE通常会在需要诊断一个具体问题的时候直接拿过来运行。对于小测试来说他们关注的是些典型的问题，如数据损坏、错误条件或一个错误。一个小测试要回答的问题是：代码是不是完成了它应有的功能。
中测试可以被自动化也可以是手工的，他们通常包含两个或多个功能，并特别的关注功能之间的交互。曾经有SET把这种测试描述成“测试一个功能和它的近邻”。对于一个产品的周期中，在单独的各功能的实现过程这个阶段，SET会驱动这种测试的开发（为了让SWE能方便的编写“中测试”做准备）；这种测试的大量编写、调试、维护工作则是SWE的事情。如果测试失败，工程师会自己去搞定它。在开发阶段的后期，TE会手工执行（当这个测试不容易自动化，或者自动化的代价太大时）或自动化的执行他们。中测试要回答的问题是一组邻居功能是不是能完成他们应有交互任务。
Large Tests。大测试覆盖三个或更多的功能，并且要尽可能的代表真实的用户场景。怎么来对一个集成了所有功能的场景来设计case这个或许有疑问，大师大测试都是结果导向的，比如软件是不是能有满足用户的预期？三个角色都会参与大测试的编写，从自动化测试到探索性测试所有的事情都要完成。大测试要回答的问题是：产品是不是完成了用户预期的功能。
语言上的称谓具并不重要，重要的是Google的测试人员有这么个共同语言并且知道他们每个测试代表的范围。当一些激进测试人员谈论第四类测试的时候，他们值得实际上是一种能够涵盖所有功能的系统测试，而且这个测试要跑很长的时间。
我们要测试什么以及测试多少，这后面的驱动力量是动态变化的，而且产品之间也有不同。Google更倾向于频繁的发布，把产品推向用户，然后从用户收集反馈并迭代。基本想法就是一旦我们开发了一个产品或一个现有产品的新功能，就立即把他推向用户，这样用户就能第一时间从中受益。这就需要我们把用户和外部开发者在前期就纳入进来，这样我们就能清楚我们做的东西是不是已经达到目的了。
最后，对自动化和手工测试的混合来说，自动化毫无疑问是最推崇的，不管是在大中小的测试中。如果它能够被自动化，并且过程中不需要人的智慧和灵感的介入，它理所当然要被自动化。只有在需要人来做判断的情况下才考虑手工来做，比如：UI的美观性、暴露一些数据会构成隐私问题。
最后，对自动化和手工测试的混合来说，自动化毫无疑问是最推崇的，不管是在大中小的测试中。如果它能够被自动化，并且过程中不需要人的智慧和灵感的介入，它理所当然要被自动化。只有在需要人来做判断的情况下才考虑手工来做，比如：UI的美观性、暴露一些数据会构成隐私问题。
尽管说了这么多，你必须要晓得Google要做大量的手工测试的，可能是写脚本方式也可能是探索性方式，但即便如此这些测试也是在自动化的监视下完成的——工业化的脚本录制技术可以把手工测试转换成自动化测试脚本，这些脚本就可以在每次构建后来执行，以此来最小化回归测试的开销，并且把人力集中到那些新问题上。我们也自动化了bug的提交和手工测试任务指派。比如：如果有个自动化测试失败了，系统会确定最后的代码更改位置（这里最可能是出现问题的地方），然后发邮件给其作者并记录一个bug。The ongoing effort to automate to within the “last inch of the human mind” is currently the design spec for the next generation of test engineering tools Google is building.（within在这里应做动词“把XX融入”来讲，大概意思是：正在努力的方向是“自动化人类的每个想法”，也就是人只要一想出来怎么测试，然后就可以立即把这个想法自动化，这是Google在建设的下一代测试工具）
下一篇将是关于SET的工作的。
