晨读系列（一）之《Google软件测试之道》

工作十个月以后一个观念在我心里越发清晰：要写出在日常操作场景下不出错的代码真的很难。
尽管每次上线前都会进行测试行为，但是随机测试往往难以覆盖所有的环境和场景，所以找了本关于测试的书来看，顺手记录下在阅读过程中的一些让我印象深刻的点。

软件工程师角色划分

在谷歌，软件工程师主要划分为三种角色：SWE（软件开发工程师）、SET（软件测试开发工程师）和TE（测试工程师，也称用户开发工程师）。三种角色都要求具备一定的开发能力，但是从左到右，开发工作占的比重越来越少，测试工作以及对产品端到端负责的比重越来越大，对综合能力的要求也越来越高。作为TE，他们要懂产品，要为用户负责，要能写代码，还能写测试用例，发现代码中的问题。

代码审查

新加入Google的SWE和SET都需要通过持续提交优秀的CL，来获取一个“可读性”方面的代码审查资格。可读性与编程语言有关，Google内部主要的编程语言C++、Java、Python和JavaScript都有不同的可读性要求。有经验和值得信赖的开发人员，会得到“可读性”的资格，大家同心协力确保整个代码库看起来像是由一个人编写的一样

用代码规范和代码审查来保证代码的可读性和精简度，认真地花半个小时或一个小时来做代码检视，那真的很值得，尤其是团队里有新成员的时候。

测试是什么？

（1）为在制约质量和快速发布之间寻找平衡的焦虑寻找答案
（2）测试与开发的区别在于，开发思考地如何高效地建设，而测试的思路是如何去快速破坏。

什么时候开始测试？

（1）对于外包项目或者小团队中的产品来说，从开发的那一刻起就要开始测试，对于此类团队来说，更重要不是怎么测试，而仅仅是开始测试
（2）对于大公司里的探索性产品来说

在其研发的早期阶段，功能还在不断变化，最终功能列表和范畴也还没有确定，TE通常没有太多的工作可做。早期过度地投入测试意味着资源的浪费，尤其是在SET已经深度介入的时候。过早完成的测试产物可能会被丢弃，也可能出现最糟糕的情况：虽然继续维护，但是毫无附加价值。早期的测试计划需要较少TE，而在产品接近尾声、寻找bug变得更加紧急的时候，需要较多的资源投入到测试上进行探索式测试。

如何测试？

（1）在测试之前需要思考一个问题：对被测试系统来说，最重要的是什么？

对被测系统来说，什么是最为重要的东西？”对搜索来说是性能，对新闻来说是时效性，对地图来说是综合性和完整性。

然后确保你的大部分精力是花在检验产品的核心能力上。
（2）70%的单元测试 + 20%的集成测试 + 10%的系统测试
（3）漫游测试。预设你的角色和你面临的场景，在使用产品完成这个场景的过程中测试到所有相关的功能，这里的概念看起来跟敏捷开发中的user story 有些像，因此不妨可以把它看成一个大的user story。
以前端监控产品为例，用户在使用过程中，可能会使用工具来定位自身的性能问题，因此用户会从访问记录进入，通过排序或筛选查看性能较差的访问，点击进入访问详情，查看访问瀑布图找到耗时较多的资源，同时也可能会关注资源数量、大小和访问者地域等信息。之后可能还会针对性能设置告警，进而去操作跟告警相关的功能。
（4）吃狗粮。用通俗的话来讲就是自己使用自己的产品，书中提到一个很有意思的例子

Android团队在这方面有更勇敢的尝试，所有核心开发团队成员的手机上都安装有每日构建的版本。这样做是为了减少往代码库中提交有问题的代码，一旦安装了错误代码，手机甚至都无法使用其基本功能，例如和家人通话。

（5）20%的用例覆盖80%的场景，剩下的使用手工测试的方式来完成
（6）找到测试的离合点

有可能由于架构的变化导致全部工作作废。若等待太久，则又可能错失测试良机而导致没有充分测试。测试驱动开发是不错的方法。

关于自动化测试

自动化测试听起来是一个非常美好的东西，它似乎能帮我们cover很多问题，让我们放心的把代码推到线上。但是对于所有要使用自动化测试的团队来说，有两个问题必须要解决：
（1）大部分开发人员甚至还不太会手工测试这些应用，更不用提自动化测试了。
（2）为了保障一行代码的稳定性和准确性，我们可能要使用两到三行的测试代码。而且这些测试代码跟业务代码一样，也需要人来维护，也可能会存在问题。
由此，当真正要去做自动化测试的时候，会发现工足量非常大，而且需要很多知识的学习。所以其实大部分公司的自动化测试（如果有的话）比手工测试并高明不到哪里去，挂在流水线上的大量测试用例反而经常会拖慢版本上线的速度。

确保自己修复的是重要的问题-DDD（缺陷驱动开发）

我使用了一个被称为DDD的流程，缺陷驱动开发。我总是宣称WebDriver是完美无瑕的，一旦用户发现了一个bug，我就立刻去修复它，然后再宣布它没有问题了，更加完美无瑕。这样的话，可以确定我修复的bug是一些人们真正关心的bug。这对于改善一个已有产品是非常有用的，这可以确保你是在修复最重要的bug，而不是修复人们并不关心的bug。

质量是所有人的事情而不只是测试团队的事情

我们在日常工作中经常面临的一个困境是，测试和开发要为所有的bug买单（不管是用钱还是用绩效）。一旦线上出了问题，对代码质量与用心程度的强调似乎再怎么用力都不会过。所以，我经常在工作中被强调要注意代码质量，要上一点心。
我时常会考虑这样一个问题，那些说这些话的人说完之后对问题的解决起到了什么帮助？我如何能从“注意代码质量，上点心”这几个字里面真正地提升自己的业务能力，保障产品工作的能力？思前想后，无计可施。问题很明了了，通过此种泛泛而谈并不能解决甚至缓解当前的问题。真正有帮助的是流程、制度、方法论以及全员参与。团队里的每个人都为产品的质量负责，要去使用甚至体验自己的产品（dogfood），发现问题要有工单追踪，要有详细的描述让开发可以迅速定位以及复现问题，要落实到人，要有反馈，要有复盘会议找到当前的问题，避免类似的事情再次发生。这些都是要靠良好的制度和规则来保障。引用书里的原话就是：

一个团队能编写出高质量软件的唯一途径是全体成员共同对质量负责，包括产品经理、开发人员、测试人员等所有人。

百分之二十的自由时间

这个词在书里出现了很多次，也是一个让我印象十分深刻的规则。谷歌的工程师可以用百分之八十的时间服务一个产品，剩下的百分之二十服务另一个产品，然后过一段时间再反过来。同样，他也可以用百分之二十的时间来做自己感兴趣或者能对团队乃至公司带来收益的事情。在这样的大环境下，就会不断有解决问题的工具出现，比如谷歌用于缺陷管理和自动化测试的BITE、QualityBot、RPF等，所有的工具都是用来解决日常工作流中的特定问题或痛点。活下来的项目慢慢长大，就会有更多的角色参与，让产品快速成长。这一段读下来，对那种自由、蓬勃的氛围仰慕不已。