《HowGoogleTestsSoftware》读书笔记 - 草稿

        公司图书馆新进了一些书，冲着对GOOGLE测试的好奇，我挑选了《How Google Tests Software》这本书，本书主要讲述的是这些年GOOGLE测试变革的心路历程以及一些变革中的实例。看的过程中，结合在华为的工作经历，感触良多。GOOGLE作为全球互联网业界的老大，对比作为传统行业翘楚的华为，很多工作方式都是互通和重合的，但由于行业的不同，很多做法也是有所区别。

质量不等于测试

        第一章让我感触最深的一节是：质量不等于测试。GOOGLE目前是没有独立的测试团队，GOOGLE在 2011年左右决定解散测试团队，全面融合到研发团队中，开发人员需要同时拥有和测试的技能；仅仅保留少量的非常专业的测试顾问，负责超大型项目的测试设计，或者是研发团队测试能力建设工具。他们这种做法的主要思路就是做大组织的解耦，按照业务模块即最终的业务目标和结果划分成足够小的业务单元，让业务单元自运作起来。只有这样才能充分激活组织活力，保证组织高效。跟美国的要州权，不要大政府是一个道理。

      在华为，代码质量的第一道测试是在开发团队。华为是非常注重单元测试，在这个阶段，开发每开发一个模块时，会设计对应的单元测试用例代码，编写MOCK对象代码，做LLT（low level testing）。当耦合模块完成后，几个开发人员会针对耦合点合作设计用例，有时候项目的对应TE也会参与用例设计，配合开发人员完成耦合测试。开发人员参与的测试阶段一般都是在功能编码期。并且在功能编码完过程中，部门每天都有每日构建，本地环境编译不了的代码是根本不敢上库的，因为每天的四点，CI会针对库内最新代码进行编译构建（如果发现编译不过，上错代码的人将会受到项目经理的警告，年度绩效会受影响），然后将该版本发送到自动化测试环境进行测试，一般一个流程是8小时左右，第二天上班的时候，上过代码的人会主动查看自动化测试情况，查看前一天上传代码是否有影响现有的测试用例；如果有问题，立刻定位，定位后会在本地进行编译和用例测试，保证问题解决。这个是开发参与测试的每日活动。

测试角色

        GOOGLE没有专属的测试团队，因此参与到这个项目的所有人都要承担相应的测试任务，GOOGLE公司把涉及到测试活动的人分成四种角色：，SWE，SET 、TE、TEM。SWE是单纯的功能开发开发人员，他们的工作是实现用户所使用的功能代码，他们主要测试职责是编写测试代码，包括测试驱动的设计、单元测试、参与构建各种大小规模的测试等，属于整个项目测试的前锋军。SET是软件测试开发工程师，也是一个开发角色，但是其工作重心在可测试性和通用测试基础框架上，主要职责是编写测试工具，自动化测试用例，接口测试代码以及配合TE做一些“破坏性”的测试代码等工作，其实他和SWE的工作职责是想溶合的。测试工程师（TE ）是一个和SET关系密切的角色，有自己不同的关注点，把用户放在第一位来思考，代表用户的利益，其主要职责是大型测试的设计者和执行者，同时他也会参与到代码检视和代码分析修改中，和SWE最大的不同是TE是在研发后期才介入到项目，而SWE是贯穿整个研发周期。TEM是测试工程经理，他将分别致力于支持用户的TE和编写测试代码的测试开发工程师、功能开发工程师联系起来，作为独立贡献者的一个技术岗位，负责所有的支持团队（开发、产品管理、产品发布、文档等）之间的联络。

        华为参与测试分布和职责和GOOGLE是大同小异的，但是区别于不同行业，华为有一个比较重要的角色 TSE（测试系统架构师），他们会根据市场的需求以及各通信峰会得到的信息和需求，对需求进行分析分解，并建立对应的项目算法模型，找相关的研发人员进行算法实现和可测性分析，在这个阶段已经基本上测试了方案的可实现性，到了TR3（详细设计阶段），他会针对这个项目的主体流程对TE进行串讲，再由TE们反串讲，然后再引导TE们和开发人员对接，对首版自动化用例编写用例，由SWE们编写自动化测试代码。这样随着TR3阶段的完成，自动化测试代码已经基本成型，手工测试人员也能完成高质量的测试用例，保证系统的完成性和稳定性。最重要的，当时的一个项目团队是一体的，开发和测试结果是向同一个产品经理（这个产品经理一般都在研发和测试工作过，并且在市场呆过，了解客户痛点）汇报的，这样也能保证对等性。这一点，GOOGLE的整体流程也是基本相识，也许只有做到对同一个人负责，才能更好达到目标上的统一。

版本的设置

        GOOGLE的研发模式是标准的敏捷开发模式，GOOGLE对于他们版本的形象定义：爬、走、跑。Google最初的版本只包括最基本的使用功能，然后不断收集用户反馈迭代升级的方式提高产品质量，并且在每次迭代的过程中都非常注重质量。一个产品在发布给用户使用之前，一般都要经历金丝雀版本（最基本的，用来筛掉明显不适宜功能的版本）、开发版本（开发人员日常使用的版本）、测试版本（通过了持续测试的版本，可用作内部尝鲜）和beta或发布版本（对外发布的第一个版本），利用这种模式，保证应用程序能尽早得从内部用户那里得到关于这些版本的质量反馈，这样就为GOOGLE的软件系统上线提供良好的测试验证机会。

        华为受限于行业模式，虽然这几年也在大力的推广敏捷开发和敏捷测试，但是其实也是在螺旋开发模型下的各个迭代版本中实行敏捷开发。虽然不是那么正宗，但是也为华为快速实现功能，占领市场立下了汗马功劳，并且不断尝试新的版本继承模式，记得在2012年时我所在的产品组建开始尝试one track模式，两个产品版本同时进行，新的功能在老的版本中更好地兼容，新的版本不用再对老功能进行冗余开发，既能保证产品能快速推广到市场，也能保证后续老的版本更好的升级。缩短了开发时长，也保证各个版本的可持续发展和平滑升级。

        阅读还在继续，感触也是不由而发，读英文原版书确实很让人奔溃，但是也是一种对自己的挑战。但是可以通过书获取业界最in的行业知识，技术知识，也是很快乐的一件事情，希望图书馆能有更多这么好的书籍，也希望大家能抽出时间去阅读这些大家的作品。