设计文档

项目发起人要做的第一件事情就是设计文档。
这是一个动态的文档。最早期的项目设计文档，主要包括项目的目标、背景、团队成员、系统设计。团队成员一起协同完成设计文档的不同部分。对于一些大规模的项目，需要针对主要子系统也创建相应的设计文档。在初期版本完成后，将来需要完成的工作清单也可作为项目路标。从这一点讲，设计文档必须经过相关技术负责人审核。作为SET，比较幸运的是在初期阶段加入了项目。SET在团队中有一个巨大优势，就是拥有产品方面最广阔的视野。通常代码复用和模块交互方面的设计会由SET来做，而不是SWE。

SET需要熟悉了解负责的系统设计，作为第一个审阅所有设计文档的人很了解项目整体，也有助于在在项目初期与开发工程师建立良好的工作关系。如何审阅？要点有：完整性，正确性，一致性，设计，接口与协议，测试。在SET与相应的SWE一起沟通文档的审阅结果时，关于测试工作量以及各个角色如何共同参与测试，会有个比较正式的讨论。

接口与协议
SET是第一个实现所有接口和协议的人，在系统真正搭建之前，集成测试的运行依赖于这些接口实现。为了能够尽早开始做集成测试，SET针对各个模块的依赖提供了mock或fake的实现。在任何阶段，集成测试总是依赖mock或fake，因为有了它们，一些依赖服务的期望错误场景和条件异常，比较容易产生。

自动化计划
尽早提供一个可实施的自动化计划，SWE不会被一个无所不包的设计所吸引，计划必须合情合理。规模更小且目的性更强的自动化，并存在测试框架，会吸引SWE一起参与测试。常见错误是在端到端的自动化测试上过度投入，会把你与产品特定功能设计绑定一起，这部分测试在整个产品稳定之前都不会特别有用。在google，SET用下面的方法：先把容易出错的接口隔离，针对它们创建mock和fake,控制接口之间的交互，确保良好的测试覆盖率。接下来构建一个轻量级的自动化框架，控制mock系统的创建和执行，把修改的代码提交之前运行相应的自动化测试，确保测试通过后才能被提交。SET除了自动化（mock,fake,框架）外，还要使用报表和仪表盘(dashboard)展示收集到的测试结果和测试进度。

Google软件测试之道（一）：软件测试开发工程师