《Google软件测试之道》 第一章google软件测试介绍

      软件测试之前一直以为是件非常简单的事，在实际工作中往往存在漏测，或者是方案设计不完善的问题，导致后期维护成本非常高，入职的时候导师推荐看《Google测试之道》,当时推荐给我的是英文版的，但是看了两页后放在那里再也没看过了，趁今年春节翻起这本书，受益匪浅，真的堪比武侠小说，无论是从事软件研发还是软件测试的朋友们非常推荐去看看这本书，如果有需要电子版的小伙伴可以给我留言，我私法给你，以下是个人笔记及参考网友的笔记，同理与原文会有出入的地方。建议感兴趣的伙伴阅读原文书籍！

一、质量不等于测试

质量不是被测出来的：未经测试也不可能开发出有质量的软件。为了保证产品的质量，google目标是测试开发同时开展。

    1、开发对质量的责任：写一段代码后立刻测试，完成了更多的代码就做更多的测试；质量像是预防行为（质量是开发过程的问题，不是测试问题）；

    2、测试：线上bug重重，就会回滚版本；判断预防工作做得怎么样（开发的测试，能不能确保不会出现回滚级别的bug发生）。

二、角色

1、软件开发工程师SWE：实现最终用户所使用的功能代码，创建设计文档、选择最优的数据结构和整体架构、代码实现和代码审核。

      编写测试代码：测试驱动的设计、单元测试、参与构建各种大小规模的测试。增加功能性代码或是提高性能的代码。

      质量责任：对他们编写、修复以及修改的代码承担质量责任（容错设计、故障恢复、测试驱动设计、单元测试）。

2、软件测试开发工程师SET：

      工作重心：保证SWE开发的功能模块具有可测试性：参与设计评审，观察代码质量与风险；可能会重构代码，编写单元测试框架和自动化测试框架。通用测试基础框架。

      负责提供测试支持：

      有个测试框架：可以把新开发的代码隔离，通过模拟真实的工作运行环境和代码提交队列来管理代码的提交。

      关注：质量提升和测试覆盖率的增加。

      写代码的目的：可以让SWE测试自己的功能。

3、测试工程师TE

      专注用户角度的测试：

       花大量时间模拟用户的使用场景和自动化脚本或代码的编写上。

       是否满足性能期望，在安全性、国际化、访问权限等方面是否满足用户的要求。

       工作：组织整体质量实践（把SWE和SET编写的测试分类组织起来），分析解释测试运行结果，驱动测试执行，构建端到端的自动化测试。

三、组织结构

1、大多数公司：

       资深管理者一般来自产品经理或开发经理，而不是来自测试团队。

       产品发布时，优先考虑的是功能是否完整和易用性方面是否足够简单，很少考虑质量。

       作为同一个团队，测试总是在为开发让路：“行业充斥着各种有缺陷、早产的产品”的问题所在；质量不行就再发布一个补丁包。

2、Google组织汇报关系：

       划分不同的专注领域：客户端、地理、广告等（开发工作汇报给这些专注领域的管理者）。

       测试是独立存在的部门：工程生产力团队

• 以租借的方式进入产品团队：

       1)      做提高质量的相关工作，或者公开一些不可接受的缺陷率数据；

       2)      不是直接向产品团队进行汇报，不能因项目急需发布就能通过测试（可以事先协商。有自己选择决定的优先级，在可靠性、安全性上的问题不会妥协）；

       3)      可以让SET和TE保持新鲜感和忙碌，一个好的想法可以快速在公司内部蔓延

• 会根据不同产品团队的优先级、复杂度，并与其他产品实际比较之后，再来分配测试人员(可能会搞错，但总体上来说会保持实际需求与不明确需求之间的某种平衡)。

四、爬走跑

1、Google产品经常在最初版本里只包含最基本的可用功能

      在后续的快速迭代中得到内部和外部用户的反馈。

      每次迭代都非常注重质量。

      产品发布前，会经历金丝雀、开发、测试、beta或正式发布版本。

2、金丝雀版本

      每日要构建的版本（核心开发团队成员都会安装）：

       这个版本可能无法使用应有的基本功能；

       安装了错误代码，手机甚至无法使用基本功能；

       用来排除过滤明显不适宜的版本：

       构建失败，意味着流程可能出现严重问题

3、开发版本

      每周发布，该版本有一定功能并通过一系列测试：产品相关工程师会安装。不能满足日常真实工作需求，会打回金丝雀版本：工程团队会花时间重新评估。

4、测试版本

      通过了持续测试，近一月里的最佳版本。有持续的优良表现，会作为beta测试的候选版本。

5、beta或发布版本

      对外发布的第一个版本：经历了内部使用和通过所有质量考核。

五、测试类型

      使用称谓：小型测试、中型测试、大型测试。强调测试的范畴规模而非形式；规模越小，越可能被实现成自动化的测试。

1、小型测试

       验证一个单独函数或独立功能模块的代码是否按预期工作。一般是自动化实现：

       1）几秒或更短的时间就能运行完毕。

       2）SWE实现，也会有少量SET参与。

      使用mock，在fake（虚假实现）环境中运行。

2、中型测试

     验证功能模块间的交互和彼此调用时的功能是否正确。通常也是自动化实现：

     1）独立模块开发完后，SET会驱动这些测试的实现及运行，SWE会深度参与，一起编码、调试维护这些测试。

      2）运行失败，SWE会自觉去查看分析原因。

      3）开发后期，TE会通过手动的方式或自动化执行这些用例。

     一般运行在虚假实现（fake）环境或真实环境中。

3、大型测试

      涵盖多个模块，关注所有模块的集成，倾向于结果驱动，验证软件是否满足最终用户的需求。或是通过自动化，或探索式测试：三种工程师都会参与；需要消耗数个小时或更长时间。一般运行在真实环境中，并使用真正的用户数据和资源

六、案例分析

如下代码块中是否存在异常，当然如果从代码检视的维度看肯定是有缺陷的，1）未对代码进行注释，存在魔鬼数字；2）不符合代码规范；

message AddUrlRequest{
    required string uri = 1;
    optional string comment =2; 
}