【无标题】

SET

好的SET需具备的特质（后续补充）

1、一个好的SET不仅要具有更宽广的整体产品视野，而且在产品的整个生命周期里对产品及功能特性做充分理解。
SET在团队中有一个巨大的优势，就是拥有产品方面最广阔的视野。
2、一个优秀的SET会把非常专业的广阔视野转化成影响力，在开发人员所编写的代码上产生深远的影响力。
3、SET应会做代码复用和模块交互方面的设计。
在设计阶段，SET在推进项目的同时也可简化相关项目成员的工作。
4、优秀的SET在审阅设计文档过程中应始终保持强烈的目的性，需完成特性的目标。
1）完整性，找出文档中残缺不全或需特殊背景知识的地方，增加更多细节或外部文档链接后续可帮助新人了解该文档内容。
2）正确性，看是否有语法、拼写、标点符号等错误（尤其阅读代码时）。
3）一致性，确保配图和文字描述一致。
4）设计，文档中的一些设计要经过深思熟虑。考虑可用资源，目标是否可顺利达成？使用何中基础技术框架？期望的设计在框架方面使用方法是否正确？设计是否太过复杂？可简化嘛？太简单？是否还需增加内容？
5）接口与协议，文档中使用的协议是否有清晰定义？是否完整地描述理论产品对外的接口与协议？接口协议的实现是否与他们期望的一致？与其他产品标准是否同一？
6）测试，系统或文档中描述的整套系统的可测试性如何？是否新增测试钩子（test hook）？指为测试而增加一些接口，用以显示系统内部状态信息，需要则应添加至文档中。系统设计是否考虑到易测试性？是否可使用 已有的测试框架？预估在测试方面都需要做哪些工作，并增加至设计文档中。

SET是第一个实现所有接口和协议的人。
在系统真正搭建起来前，集成测试的运行依赖这些接口实现，为尽早地开始做集成测试，SET针对各个模块的依赖提供了mock或fake的实现，虽功能模块代码还没实现，集成测试代码已经可开始编写。
注意：集成测试总是依赖mock和fake。

2.1.7自动化计划

自动化上投入的越多，维护的成本就越大，在系统升级变化时，自动化也会更加不稳定。因此，规模更小且目的性更强的自动化计划，并存在可提供帮助的测试框架，这些会吸引SWE一起参与测试。

SET的时间，本应投入在提高质量方面，而不是过于花费在维护不稳定的端到端的测试套件上。

SET在计划中涵盖自动化（mock、fake和框架）之外，还要包括如何公开产品质量方面的信息给所有关心的人。SET通常使用报表和仪表盘来展示收集到的测试结果以及测试进度。通过整个过程简化和信息公开透明化，获取高质量代码的概率会大大增加。

只有能加速开发过程的自动化测试才有意义，测试不应拖慢开发速度。所以自动化必须与开发过程真正的集成在一起，并使之成为开发过程的一部分，而不是孤立存在。

通用的测试框架摆阔：代码编译、测试执行、结果分析、数据存储、报表展示。

2.1.11测试大小的定义

1、小型测试
验证一个代码单元的功能，一般与运行环境隔离，运行无需外部依赖。一般集中精力在函数级别的独立操作与调用上。小型测试会尝试走遍单独函数的所有路径。
2、中型测试
验证两个或多个模块应用之间的交互。主要目标是验证指定模块之间的交互，Google之外，中型测试经常被称为“集成测试”。一般由SET来组织运行中型测试。中型测试，孤立使用模拟技术（mock）来解决外部服务的依赖问题，不强制，如处于性能开率可不使用模拟技术。轻量级的虚假实现（fake），如常驻内存的数据库，在不能使用mock的场景下课用来提升性能。
3、大型测试
Google之外常称为“系统测试”或“端到端测试”。验证系统作为一个整体是如何工作的。涉及应用系统的一个或所有子系统，从前端界面到后端数据储存。
代码变更（CL）
小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告；大中型测试带来整体产品质量和数据验证。
单一的测试类型不能解决所有项目的需求，通常结合使用。
检验一个项目力小型测试、中型测试和大型测试之间的比率是否健康，一个好的办法就是使用代码覆盖率。其可针对小型、中大型分别单独产生报告。
总体经验法则，70/20/10:70%小型，20%中型，10%大型。若一个项目是面向用户的，拥有较高的集成度，或者用户接口较复杂，就应该有更多的中型和大型测试；若是基础平台或面向数据的项目，例如索引或网络爬虫，则最好有大量的小型测试，中性测试和大型的数量要求会少很多。

2.1.14测试运行要求

Google测试执行系统为公用环节，要求测试本身满足以下条件：
1.每个测试和其他测试相互独立，使它们能以任意顺序执行
2.测试不做任何数据持久化方面的工作。测试用例离开测试环境时，要保证测试环境状态与测试用例开始执行前状态一致。

在持续集成系统中使用更加只能的分析工具与云计算平台，让整个运行过程更加迅速和稳定。