拖延了将近半年的草稿，断断续续的写完了。之前草草翻看完这本书，关注点主要在TE上，而关于SET的部分则只是浏览，最近后知后觉，又翻出了这本书，重新看了一遍，又有新收获。

就说说Google的SET是如何做的，以及个人的一些思考和收获吧，寥有慰藉。。。

Google的测试流程可以简练的概括为：让每个工程师都注重质量。而在工作流程引入过程中也伴随着一些致命的缺陷，下面简述下Google是如何解决以及其测试流程的是如何进化的。

①、测试并不能保证产品质量。需要一直谨记的一点：质量是内建的，而不是外加的；

②、软件开发的最终目的，是完成一个产品，由谁完成不重要，应该模糊角色，关注产品；

③、软件测试本身高于测试的产物，谁在测试不重要，关键是进行了测试。

一个理想完美的开发过程，是怎样的？

测试先行，在编写代码之前，开发人员思考如何测试他即将编写的代码，设计一些边界场景测试用例，数据取值范围极大极小，导致循环语句超出范围等其他极端情况；

这些测试代码作为产品代码的一部分，以单元测试代码形式与功能代码存储在一起，这种类型的测试，最有资格最适合去做的人，就是编写代码的人。

一个理想的测试过程，是怎样的？

做测试，有时候需要利用很多的外部基础设施，比如数据库，比如工具等，用专业的术语来讲，就是测试框架（test harnesses）、测试通用设施（test infrastructure）、

模拟设施（mock）和虚拟设施（fake）；

在测试过程中需要的时候，都需要出现在面前任由使用。

△ mock：指对外依赖系统的模拟，运行时可以根据假设的需求提供期望的结果。

△ fake：一种虚假的实现，内部使用固定的数据或逻辑，只能返回特定的结果。

功能开发人员SWE和测试开发人员SET的区别：

SWE：思维逻辑是创建，重点在于考虑用户、使用场景和数据流程的实现上

SET：思维逻辑是破坏，考虑怎样写测试代码用以扰乱分离用户及其数据

完美的软件开发过程，还需要一个角色，就是用户开发人员TE；一个真正关心用户，从用户角度考虑软件产品质量的角色。

用户开发人员需要做的是面向用户的任务：用例、业务逻辑、用户场景、探索式测试等，关注这些功能模块如何集成，验证每个模块的功能，以及集成后的作用包括对用户最终产生的价值。

这就是理想状态的软件开发过程，但实际上这种情况不存在，Google也只是接近，仅此而已！

个人感触：软件开发是一个严谨的过程，需要多方面协同配合，需要尽力提升效率，无缝沟通，但不能过于盲目追求，实际工作中影响因素太多，找到平衡点才是重点。。。

一、SET的工作范畴

1、开发和测试过程

在Google，测试工作是由整个工程师团队负责，而不仅仅是头衔带“测试”的工程师。

工程师的交付物是即将发布的代码，代码的组织形式、开发过程、维护是日常工作的重点。

Google多数代码放在同一个代码库里，并使用统一的一套工具。这套工具支撑着Google的构建和发布流程。

这样做的好处在于：

①团队成员可以毫不费力的完成代码入库、提交、执行测试、创建版本等任务；

②单一的代码库模式，使工程师可以在项目中的切换几乎不需什么成本；

③提高效率，减少了项目失败的几率和节省成本；

2、设计文档

Google所有项目都有设计文档，这是个动态的文档，随着项目演化在不断的保持更新。

作为一个SET，可以在项目初期阶段就加入项目，完成一些重要且有影响力的工作。SET在团队中有巨大的优势，即：把非常专业的广阔视野转化成影响力。

一般而言，代码复用和模块交互方面的设计由SET来做，而不是SWE；而在设计阶段，SET在推进项目同时也可以简化相关项目成员的工作。

在Google，SWE完成最初的设计文档后，一般都会期待SET来审核这些设计文档，下面是这么做的一些原因：

①SET需要熟悉了解所负责的系统设计；

②SET早期提出的建议会反馈在文档和代码里，这样也增加了SET的整体影响力；

③SET需要对项目的整体了解度达到甚至超过项目负责人；

④在项目的初期，与相应的开发工程师建立良好的工作关系；

SET审阅设计文档都需要有一定的目的性，需要完成特定的目标，下面是一些审阅时需要注意的重点：

完整性、正确性、一致性、设计、接口与协议、测试

3、可测试性

产品开发过程中，SWE和SET精密配合。SWE编写产品代码并测试，SET编写测试框架，为SWE提供测试代码方面的帮助，质量由SWE和SET共同承担。

SET的第一要务是可测试性，SET则扮演一个质量顾问的角色，提供程序结构和代码方面的建议给开发人员，使得开发人员可以更好的进行单元测试；同时SET也提供测试框架方面的建议，

使得开发人员可以再这些框架的基础上自己写测试。

为了使SET也成为源码的拥有者之一，Google把代码审查作为开发流程的中心。

4、自动化测试

自动化测试不仅仅是自动化测试程序的编写，它首先必须产生价值。

必须去考虑如何编译测试程序、执行、分析、存储和报告所有的测试运行结果，这些都是测试自动化想真正发挥作用面临的挑战。

除了正确的编写自动化程序外，还要使工程师的注意力转移到在实际项目中如何更大的发挥自动化测试的价值上。只有能加速项目进程的自动化测试才有存在的意义，测试不应拖慢开发速度。

因此，自动化测试应该与开发过程真正集成在一起，并使之成为开发过程的一部分，而不是孤立它。

功能代码从不是真空一样的孤立存在，测试代码也是如此。

一些个人思考：目前国内，或者说我个人接触到的自动化测试（常见的UI、接口、单元），都是将其与开发独立开来，不能说这种做法是对是错，但总觉得有点用力过猛了。。。

特别是UI自动化，嗯，selenium自动化，貌似很火的样子，新人菜鸟小白，开发转测试的，遇到职业瓶颈的，好多人在学，不知道学了能真正在工作中用到的又有几个？

个人的观点是：学到的东西要能产生价值，学以致用！坦白地讲，我们学习这些知识，还是为了应付工作中遇到的问题，而不是盲目跟风（曾经我也盲目的跟风了一段时间。。。）

5、测试规模大小的定义及相关

在Google，小型测试（单元测试）主要关注函数级别的独立操作和调用上面，是为了验证一个代码单元的功能；中型测试（集成测试）验证两个或以上的模块应用见的交互；

大型测试（系统测试/端到端测试）是为了验证整个系统作为一个整体是如何工作的。

小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告，大中型测试带来整体产品质量和数据验证。

单一的测试类型不能解决所有项目需求，因此需要将不同类型的测试维持在一个比例。Google的经验是70/20/10原则：即70%小型测试，20%中型测试，10%大型测试。

当然，这个比例不是固定的，需要根据项目的具体情况来上下浮动调整，比如：

①某个项目是面对用户的，有较高的集成度，或用户接口比较复杂，则应该有更多的大中型测试；

②如果是基础平台或面向数据的项目，比如索引或网络爬虫，则小型测试应占到更多的比例；

写在末尾：这是第三次翻看《Google软件测试之道》，每次翻看都有不一样的收获，博客里只能列举一些相对来说比较实用的可参考性的内容，其实这本书中，每个章节后面都有

一些和Google的工程师的访谈内容，蛮有意思的，建议有兴趣的童鞋可以买纸质书去看看。虽然电子书可能相对更方便。

但个人感觉，电子书只能作为工具书，而纸质书更方便阅读中的思考和总结，做注释，或许也有点成就感吧。。

何况是《Google软件测试之道》这本值得多次反复阅读的书呢。。。

《Google软件测试之道》测试开发工程师