第二章： 软件测试开发工程师
对于功能代码而言，思维模式是创建，重点在考虑用户、使用场景和数据流程上；对于测试代码来说，主要思路是去破坏，怎样写测试代码 用以扰乱分离用户及其数据。由于我们的假设的前提是在一个童话般的理想开发过程里。所以我们或许可以分别雇佣不同的开发工程师：一个写功能代码，而另一个思考如何破坏这些功能（功能开发（SWE）、测试开发(SET)）
互联 公司的乌托邦式
功能开发人员在编写功能代码的时候，测试开发人员编写测试用例，但我们还需要第三中角色，一个关心真正用户的角色：用户开发人员，他们需要解决的主要问题是面向用户的任务，包括用例、用户故事、用户场景、探索性测试等。用户开发人员关心这些功能模块如何集成在一起成为一个完整的整体，他们主要考虑系统级别的问题，通常情况下都会从用户角度出发，验证独立模块集成在一起之后是否对最终用户产生价值。 Googled TE就是用户开发人员，负责从用户的角度来思考质量方面的各种问题。
2.1 SET的工作
公开的代码库、和谐的工程工具、公司范围内的资源共享，成就了丰富的google内部的共享代码库与公共服务
工程师需要遵守这些规则：
- 所有工程师必须复用已经存在的公共库，除非在项目特定需求方面有很好的理由
- 共享代码、首要考虑容易找到和可读性
- 公共代码尽可能地被复用且相对独立
- 如果一个工程师对公共代码库有某些更好的解决方案，他需要去重构已有的代码，并合并到新分支上
Google产品的构成
- 良好测试的独立库
- 一个在可读性和可复用性方面都不错的公共服务库
- 一套覆盖所有重要构建目标的单元测试套件
2.12 SET究竟是谁
SET 软件测试开发工程师，使测试人员能尽早介入到开发流程中去，但不是通过质量模型和测试计划方式
- SET需要熟悉了解所负责的系统设计
- SET早期提出的建议会反馈在文档和代码里
- 作为第一个审阅设计文档的人，SET对项目的整体了解程度超过技术负责人
2.16 接口和协议
为了能够尽早可以运行集成测试，针对依赖服务，SET提供了mock和fake
2.17 自动化计划 自动化投入的越多，维护的成本也就越大，在系统升级变化时，自动化也会更加不稳定，规模更小且目的性更强的自动化计划，并存在可以提供帮助的测试框架，这些会吸引SWE一起参与测试、
SET除了在这个计划中涵盖自动化之外，还要包括如何公布产品质量信息给所有关心的人。在Google、SET使用 表和仪表盘(dashboard)来展示收集到的测试结果以及测试进度。通过将整个过程简化和信息公开透明化，获取高质量代码的概率会大大增加。
2.18 可测试性
SET的第一要务就是可测试性。SET在扮演一个质量顾问的角色，提供程序结构和代码风格方面的建议给开发人员，这样开发人员可以更好地做单元测试。同时提供测试框架方面的建议，使得开发人员能够在这些框架的基础上自己写代码。
小结：
- Google的SET角色的要求挺高的，不仅需要懂得技术，还需要拥有更宽广的产品视野，熟悉代码架构
- 质量信息公开透明化，如我们的dashboard（pds大电视）
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！