转：google测试分享-分层测试

原文： http://blog.sina.com.cn/s/blog_6cf812be0102vctg.html

上一次分享了google测试分享-SET和TE，有一些自动化测试的细节没有说清楚，那这次会把google的分层自动化测试描述的更详细。

 

为了让这些blog分享更有逻辑性，我打算分几个专题来分享google测试相关的测试理念。

google测试分享-SET和TE

google测试分享-分层测试

google测试分享-GTA

google测试分享-测试经理

google测试分享-问题和挑战

google测试分享-未来测试 

 

     作为互联网产品来说，我们可以认为产品一直都在beta阶段，为什么这么说。两个原因一个是是我们需要用户的真实体验来告诉项目团队这个产品的质量到底怎么样，另外一个就是我们一旦发现影响较大的bug，我们可以很快的fix bug，让产品体验得到迅速的提升。

 

      在互联网产品的新项目启动过程中，google为了让SET和TE都能在项目中发挥更大的价值，同时为了让开发人员具有很高的测试意识和质量意识，特意将项目的测试阶段分成三个阶段：

小型测试：主要包括单元测试、模块测试，使用mock、fake 等技术来完成，这个阶段SET通常会参与进来，但是开发人员仍然是测试的主力，TE却很少参与。测试执行都是自动化测试执行。

中型测试：主要包括组件测试、特殊区域的集成测试、功能交互的集成测试，这个阶段部分是自动化测试执行，部分是手工测试执行。

大型测试：主要包括长链路的集成测试、系统测试。从真实用户的角度，使用真实的数据进行用户体验性的测试。这个阶段的测试耗时较长，大部分是手工测试，考虑整体产品的服务质量。

 

      在项目测试计划过程中，会对小型、中型、大型测试做一个比较详细的区分，也就是测试范围的确定，这三个类型的测试的比例很关键，不同项目也是不一样的，一个判断是否健康的标准是看代码覆盖率。总体上，70/20/10原则：70%是小型测试、20%是中型测试、10%是大型测试。面向用户的、基础平台的会不一样。下面详细的说明在不同类型的测试活动上，开发、SET、TE是如何紧密的合作的。

 

     小型测试阶段，开发人员主导测试代码的编写和测试执行。SET和开发人员一起进行单元测试的测试设计，部分功能的测试代码编写，帮助做可测试性上的分析。开发写代码是创建、考虑用户、使用场景和数据流程上，而测试是破坏、扰乱分离用户及其数据，所有写功能代码和测试代码的思维是不一样的。CI起来后的小型测试的测试执行也是由开发人员主导的，小型测试在每次code commit后的执行情况都需要开发人员主动去了解并保证所有小型测试的结果都是PASS。其实这里面还包括code review，每个checkin的代码都需要经过SET和开发人员的code review。所以Change list里面显示的不仅仅是功能代码，还包括测试代码。

 

      中型测试阶段，SET主导测试代码的编写和测试执行。对于一个产品的CI来说，小型测试和中型测试的测试代码持续执行和回归由开发人员、SET、TE共同负责，并不是说由某一个角色来负责。其实也就是说TE也会参与中型测试的测试代码的维护和运行工作。对于复杂系统来说，中型测试的测试覆盖率可能会更高，SET参与的力度会更大。这个阶段，和我们国内通常做的接口测试有很多相似之处，接口测试其实包含单个重要接口的接口测试和多个接口之间的集成接口测试。对于阿里来说，上层业务基本上就做单个重要接口的接口测试，而针对中心级别的底层系统，更多的是多个接口之间的集成接口测试。

 

     大型测试阶段，主要是TE主导系统级别的自动化测试和手工测试。大型测试的优点就是能够真正的站在用户的角度去使用产品，体验产品，总体上把控产品的功能和性能等其他特性（这个正好是TE很擅长的能力）。当然缺点就是发现bug后，精准的找到失败的原因比较困难；另外一个就是测试数据准备工作比较耗时，很难走到特定的代码路径区域（较多的异常else语句）。需要强调的是这些手工执行的case并不仅仅是TE来执行，项目组的其他成员包括PM、PD、开发人员、SET都会得到手工执行case的执行任务，总体策略和结果分析由TE全程把控。

 

     产品总体质量的dashboard需要展示每次build测试结果、测试进度、自动化测试机构、代码覆盖率。开发人员甚至比SET更加关注CI的结果，而国内的开发人员很少主动关心CI结果，很多时候都是被测试人员通知到，然后还看心情。针对于复杂的系统，我们都需要建立构建依赖规则（记得之前淘宝测试开发了一个dependence系统，将系统之间的依赖关系全部映射出来，跟进code change来实时通知回归机制，挺好的事情，不知道后面为啥没了），通过代码变更的地方，来找到本次修改需要run的测试集；比如通用库上代码变更、一个依赖项目上代码变更等，使持续集成和错误定位更加精准。

 

     这里面可以发现google的测试阶段的划分和分层和大部分互联网公司是一致的，但是google会更加强调小型测试阶段的投入产出比，使用自动化测试手段来使用代码去测试代码，增加确定性和持续性，相比于手工测试而言。另外一个不同点就是google的开发对CI后的结果的重视程度也远超与国内开发人员，最近几年自动化测试的发展很快，国内很多测试团队都写了很多自动化测试代码并CI起来了，但是CI结果的利用以及完善和维护没有跟上来，很多大公司也存在这样的问题，他们更多的是关心编写了测试代码，关心自己有能力编写代码，而不去关心维护测试代码，不去关心测试代码有没有发挥它应有的价值。

 

     个人认为真正的测试架构师可以轻松的把任何一个SUT分层测试策略规划出来，甚至在架构和功能细节上进行细分，让分层测试更加的有效和合理，从而体现整个产品的质量控制计划的完美性，当然也会参与需要用到的测试工具的架构技术和思路上的指导。在SET和TE做的都比较不错的才可以把这个任务做的那么完美，否则只会写代码的人、只会黑盒系统测试的人都无法对SUT进行彻底的理解，并快速的给出最佳的分层测试方案。

 

      这里说到的分层测试策略和计划，这些都应该在项目测试计划里面体现出来的，下一个主题会分享google是如何做测试计划和风险风险的。 也就是google测试分享-GTA。