今天接着上一篇//www.greatytc.com/p/bcda928981cd，从第2章：软件测试开发工程师的2.1.9（SET的工作流程：一个实例）开始~
9）SET的工作流程：一个实例
该实例讲述了如何使用Protocol Buffer定义数据和接口的设计、如何使用C++语言编写源码和测试代码、如何将测试代码加入构建规则，最后形成CL提交审核的整个流程。
10）测试执行
只有能加速开发过程的自动化测试才有意义，测试不应拖慢开发的速度。因此，一个可以做代码编译、测试执行、结果分析、数据存储、报表展示的通用测试框架逐渐形成，工程师专注于测试程序的编写、运行的细节留给通用基础执行框架。
11）测试大小的定义
a）小型测试
小型测试是为了验证一个代码单元的功能，一般集中精力在函数级别的独立操作与调用上。在Google之外，小型测试通常就是单元测试。小型测试范畴隔离且没有外部依赖，这让小型测试可以在很短时间内就运行结束。
b）中型测试
中型测试是验证两个或多个模块应用之间的交互。在Google之外，中型测试也称集成测试。一般是由SET来组织运行中型测试。小型测试会尝试走遍单独函数的所有路径，而中型测试的主要目标是验证指定模块之间的交互。
c）大型测试
在Google之外，大型测试也称系统测试/端到端测试。大型测试在一个较高层次上运行，验证系统作为一个整体是如何工作的。
12）测试规模在共享测试平台中的使用
Google不同的测试项目共享测试平台，有可能同时并发提交到Google测试执行系统的项目有多个。一些测试可能极度消耗资源，使得公用测试机器处于不可用状态。因此，Google测试执行系统利用测试规模的定义，把运行较快的任务从较慢的任务中挑选出来。Google测试执行系统在发现任何测试超时，会把这个测试任务取消并报告这个错误。这迫使工程师提供精准的测试规模标签。
13）测试规模的益处
各测试规模的优缺点，见图：
a）大型测试
对外部有依赖，非确定性强；测试数据的准备非常耗时；测试失败根源较难定位。
b）中型测试
运行速度相对较快；可在标准的开发环境中运行；依赖外部系统有不确定性。
c）小型测试
运行速度很快；所有的环境均可运行；测试范围较小，可很容易地做边界场景与错误条件测试；使用mock或fake，可不与真实环境同步。
Google有许多不同类型的项目，这些项目对测试的需求也不同，小型、中型、大型测试之间的比例随着项目团队的不同而不同。这个比例并不固定，总体上有个经验法则，即70/20/10原则：70%小型测试，20%中型测试，10%小型测试。
14）测试运行要求
由于Google的测试执行系统是一个公用环境，因此要求：
测试之间相互独立，能以任意顺序来执行；
测试不做任何数据持久化方面的工作，即在测试用例离开测试环境时，要保证测试环境的状态与测试用例开始执行之前的状态一致。
另外，测试用例要求可“并发”，如果存在两个测试需同一个端口、同一个目录、操作同一张表可能会导致用例失败。
一个持续集成系统，如果测试失败，为了精确定位哪次代码变更导致测试用例运行失败，可利用依赖分析技术寻找所有可能受影响的模块，针对一个代码变更只运行受影响模块的测试。
a）对于通用代码库上的变更
此时，所有的测试均需要运行。
b）对于一个依赖项目上的代码变更
只需要运行受影响的模块，即运行buzz_client_tests即可。
今天到此为止，下篇从测试认证开始读起~
今天读完的感受是：更清楚了测试规模的意义，重温了自动化中该注意的点，另外，从整体项目的角度，项目流程、修改后的测试方面也得到了新的认识~
