花了一周的时间艰难得把第一章看完了，看的过程中，同步回想华为的研发流程。GOOGLE作为全球互联网业界的老大，对比作为通信行业翘楚的华为，很多工作方式都是互通和重合的，但由于行业的不同，很多做法也是有所区别。

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

      在华为，代码质量的第一道测试是在开发团队。在华为的时候，我的岗位是软件开发人员，部门每天都有每日构建，本地环境编译不了的代码是根本不敢上库的，因为每天的四点，CI会针对库内最新代码进行编译构建（如果发现编译不过，上错代码的人将会受到项目经理的警告，年度绩效会受影响），然后将该版本发送到自动化测试环境进行测试，一般一个流程是8小时左右，第二天上班的时候，上过代码的人会主动查看自动化测试情况，查看前一天上传代码是否有影响现有的测试用例；如果有问题，立刻定位，定位后会在本地进行编译和用例测试，保证问题解决。这个是开发参与测试的每日活动。

      华为是非常注重单元测试，也就是GOOGLE说倡导的小型测试阶段，在这个阶段，开发每开发一个模块时，会设计对应的单元测试用例代码，编写MOCK对象代码，做LLT（low level testing）。当耦合模块完成后，几个开发人员会针对耦合点合作设计用例，有时候项目的对应TE也会参与用例设计，配合开发人员完成耦合测试。开发人员参与的测试阶段一般都是在功能编码期。

        完成各模块编码后，开发会提交TR4版本（IPD流程针对雏形产品的一个阶段版本，工程样机评审阶段），提交该版本时，各模块开发人员会针对负责模块的代码进行pclint，使用代码规范工具对代码进行代码规范检查，将不符合代码规范和有缺陷隐患的代码分析出来，让开发人员进行确认，尽可能在最早的时间发现越界或者空指针等低级bug。并且会结合测试的测试用例，对自己负责模块进行自验证，保证提交的版本不会出现block级的问题，导致项目延期。所以经过这样“折腾”的测试版本发出去，低级问题出现的概率就相对比较少了。

        对于测试何时介入到项目，华为和GOOGLE有不同的解读。因为GOOGLE没有专属的测试团队，因此公司把涉及到测试活动的人分成三种角色：SET，SWE，TE。SET是单纯的功能开发开发人员，他们主要涉及的测试活动是小型化测试，即单元测试，属于测试的前锋军；SWE是测试开发人员，贯穿整个产品开发周期的，主要职责是编写测试工具，自动化测试用例，接口测试代码以及配合TE做一些“破坏性”的测试代码等工作，其实他和SET的工作职责是想溶合的；TE是一个面向用户的测试角色，主要职责是大型测试的设计者和执行者，同时他也会参与到代码检视和代码分析修改中，和SWE最大的不同是TE是在研发后期才介入到项目，而SWE是贯穿整个研发周期。

        而在华为，测试团队会有一个TSE在TR1（需求评审和概念）阶段就进入这个项目，和SE，市场的人一起对需求进行分解，对实现进行规划和应用场景的划分，这个人对整个项目的业务流程特别了解，到了TR3（详细设计阶段），他会针对这个项目的主体流程对TE进行串讲，再由TE们反串讲，然后再引导TE们和开发人员对接，对首版自动化用例编写用例，由SET们编写自动化测试代码。这样随着TR3阶段的完成，自动化测试代码已经基本成型，手工测试人员也能完成高质量的测试用例，保证系统的完成性和稳定性。最重要的，当时的一个项目团队是一体的，开发和测试结果是向同一个产品经理（这个产品经理一般都在研发和测试工作过，并且在市场呆过，了解客户痛点）汇报的，这样也能保证对等性。这一点，GOOGLE的整体流程也是基本相识，也许只有做到对同一个人负责，才能更好达到目标上的统一。，

        阅读还在继续，感触也是不由而发，读英文原版书确实很让人奔溃，但是也是一种对自己的挑战。但是可以通过书获取业界最in的行业知识，技术知识，也是很快乐的一件事情，