1、测试规模分类

在Google里面，测试分为以下三种：

小型测试

小型测试是为了验证一个代码单元的功能，一般与运行环境隔离，它是不需要依赖于外部，一般集中于函数级别的测试，即我们平时所说的单元测试。

中型测试

中型测试主要是验证两个或以上模块或应用间的交互，它一般通过mock对其他外部环境进行隔离，即我们平时所说的“集成测试”，只是这里的集成测试更多是需要验证的那些模块的集成，其他外部依赖一律通过mock进行隔离。

大型测试

大型测试主要是系统级别的测试，主要验证系统作为一个整体是如何运作的（这里包含了涉及到该业务功能的所有上下游系统如何协同工作），是我们平时所说的“端到端测试”。

在Google，针对不同测试规模有相对明确的时间及资源使用情况的定义。

针对不同测试规模的测试执行时间的目标与限制

针对不同测试规模的资源使用情况

Google通用测试框架利用上述测试规模的定义，去优化整个平台运行的测试调度。如测试人员把这个测试在平台上打完标签（小中大型测试）并执行测试任务，如平台发现测试超时或资源消耗超过这个测试所定义的资源限度，则会自动取消这个测试任务并生成错误报告，这样可以迫使工程师提供合适的测试规模标签。

2、测试规模的优缺点

每种测试规模肯定会带来相应的一些好处，这里罗列一下具体的优缺点。

在Google中，虽然有很多不同类型的项目，但是针对上述所说的三种测试类型总体上还是有一定的经验法则，即70/20/10原则：70%是小型车上，20%是中型测试，10%是大型测试。（这个是不是有点跟Martin Fowler的测试金字塔不谋而合）

3、测试认证

很多开发同学觉得测试工作是测试人员的事情，但是这事在Google则是通过另外一种方式推广，其中的关键方法被称为一个叫“测试认证”（Test Certified）的计划。

当我们在团队中尝试去推开测试实践的时候发现真的太难了，后面想了一下是否跟以下问题有关：

为了解决以上问题，我们是否可以借助以下办法去在一定程度上解决。

1、建立一系列测试相关的指标，如紧急投产率、一次构建失败率（当然这个构建过程包括代码构建和冒烟测试自动化）；

2、引进Google这样的测试认证，通过测试认证的阶梯，我们给团队一个清晰的实现目标的层级结构；同时，针对做得好的个人或团队，给与荣誉和物质上的激励。

参考：