【读书笔记】Google软件测试之道

一、谷歌的软件工程师分工

1、SWE，Software Engineer

是注重于业务代码开发的工程师，着重于实现用户所需要的功能，为传统的开发角色。

2、SET，Software Engineer in Test

是注重于测试框架和可测试性的开发工程师，从增加可测试性和质量提升的角度参与代码开发。

3、TE，Test Engineer

把用户放在第一位考虑，代表用户的利益，话费大量时间在模拟用户使用场景和自动化脚本、代码编写，对运行结果进行分析、解释和测试。

二、SET的工作

1、参与开发和测试流程，指导单元测试，编写mock、fake工具，也可以编写中大型测试。

2、需要同时对代码开发和测试有所了解

3、项目早期阶段无需介入，仅需要在项目正式确立后参与

4、比起SWE，需要有更加广阔的事业，在产品的整个证明周期对产品和功能特性有充分的理解

5、熟悉系统的设计文档，并对设计文档进行审阅，能够尽早地介入项目并建立和TWE之间的协作关系

6、熟悉接口和协议，比如google protocal buffer，使用工具对接口和协议进行审查

7、编制自动化计划，切记自动化投入越多，维护的成本也就越高

8、作为质量顾问的角色，保证产品的可测试性，编写测试框架，为SWE编写测试代码提供帮助

面试挑选SET的方法：

1、SET不仅是个编程能力出色的程序员，也是一个可以测试任何产品的测试者，不仅可以看到树木，也可以看到整片森林，看到小段函数原型或API时就可以想到使用这段代码的各种方法还有如何破坏这段代码。

2、比起对复杂问题解决的正确性和优雅性，更倾向于考核他们对编码和质量的看法，考察他们如何思考问题的解决方案，而不是纠结解决方案本身。 思路>方案，开阔的思路和好奇心

三、TE的工作

TE是一种面向用户的测试角色，可以被称为用户开发者，早期会做一些面向SET的工作，后期只是面向TE的工作。

测试计划是最早出现、最先被以往的测试产物。

ACC，Attribute Component Capability，特质、组件、能力，是一种测试计划的替代方法，相见“Google Test Analysis”，指导原则：

1、避免散漫的文字，使用简明的列表

2、不必推销

3、简洁

4、不要把不重要的、无法执行的东西放进测试计划

5、渐进式的描述（Make it flow）

6、指导计划者的思路，从高层次概念过度到底层细节

7、最终结果是测试用例

对于“能力”，非常重要的一点是它具备可测试性。

四、工程经理的工作

构建低成本测试的方法：

1、建立测试计划（GTA）

2、测试覆盖度

3、bug评审

4、探索式测试

5、bug提交

6、bug分析和调试

7、部署新版本重复上述操作

接手新项目时，需要先思考对于被测系统来说，什么是重要的？验证核心能力是第一步，其次关注那些核心的不容易改动的东西（如性能设计），而不是浪费过多的时间在很容易修改的地方。

试着多从自动化、手工测试发现的bug出发，生产出新的测试用例，使用这些用例来守护我们的产品。

一些经验教训：

1、并不是所有的自动化工具都是好的，假如这个手工操作本来就是不合理的，将其自动化也只是让原本错误的事情继续错误下去，这时应该回过头来想想，是不是可以有一些别的方法

2、测试人员依赖的自己所拥有的技术能力，通过测试资源的稀缺获取开发人员的帮助并不断测试优化，优先考虑自动化，还有快速迭代、集成并获取用户反馈的能力。

总结下来是四点：技能、稀缺性、自动化和迭代集成。

3、James Whittaker的其他书籍：《Exploratory Tetsing》《How to Break Software》

五、Google软件测试改进

现有的谷歌测试流程可以概括为：让每个工程师都注重质量。让代码从一开始就可以变得更好，版本质量更高，系统测试可以关注真正面向用户的问题。

未来的发展方向：

SET，将会逐渐和SWE同化，测试的技能被逐步平均地分散在了每个开发工程师身上，不再区分产品的功能点开发还是测试开发。

TE，面向互联网的软件因为有着成千上万的用户，通过交付的加速，通过迅速的版本交付和用户反馈响应，我们可以大大地降低真实用户反馈问题后带来的风险，从而逐步抛弃原有让高级探索式测试专家模拟用户行为来对系统进行测试的方法。

测试工程，会逐步转型成测试设计，少量的测试设计师快速地划出测试范围、风险热图和应用程序的漫游路线。通过执行测试人员的反馈，由测试设计师来评估覆盖率，计算风险影响，确保发现的问题不断减少，然后调整对应的测试活动。同时识别需要专业技能的地方，比如安全、隐私、性能和探索性测试，安排人员执行这些测试。