这几天在抽空读一本新书，久负盛名的《google软件测试之道》。之前在网络上一点一点地看过它的英文版，很受触动，还做了很长的读书笔记，现在看到了中文版，才恍觉之前的好些理解存在不恰当的地方，英文读写能力真是个硬伤。。
这本书很多让我惊奇的地方，可以说刷新了从业这么久的三观。例如它说测试团队真正的定位在于提高“工程生产力”，google内部只有非常少的专职测试人员，有的是具有测试视角的研发团队，和兼具研发能力的测试工程师，还有具有用户视角的产品经理。由于人员的精简，因此尤其注重优先级的安排，充分运用各种技术手段，创建高影响力、低阻力的实践活动。作者提到，让测试员工保持昂扬的斗志和充沛的精力是非常重要的。在现有工作中，自己一直纠结没有充分的测试时间和充足的测试人员，认为研发总是压榨测试，为做不到充足的测试而抱怨，自己钻进了一条走不通的死胡同。看到书里的描述，顿时觉得自己把方向想反了，还沉浸在过去几十年老旧的测试理念中无法自拔。测试和开发，只是视角不同，能力上并不应该有差别。觉得测试时间不足，问问自己，自己的测试开发能力跟上了吗？充分运用了各种测试技术和测试手段了吗？测试用例优先级和设计合理吗？测试热情是否充沛？产品成熟后，是否引入了自动化测试？测试不应该成为研发的阻碍，敏捷测试强调的是持续集成测试，测试和开发是密不可分的一个整体，“质量更多的是一种预防行为，而不是检测。质量是开发过程的问题，而不是测试问题。“这些话，给了我现实工作中莫大的指引。
从书中看出，google的各种框架已经非常成熟了，开发也有一整套的google准则，一切都已高效、优质为目标。代码从产生，就在不停的做测试，这个过程，很多是有完善的自动化机制触发的，例如代码提交后，自动编译、自动测试，甚至可以自动上报缺陷。从函数级别的小型测试，亦即单元测试，到侧重接口交互的中性测试，然后是系统测试，最后进入灰度测试，通过后，才发布beta版本。测试无处不在，测试团队的工作就是编写及维护各种测试功能代码，重复且单调的工作都交给机器，人工只测新功能和探索性测试。感觉google的测试就像一个高度工业化的流水线，前面经过大量的机器检测，最后一道是人工的鉴别，最终出来的就是完善的成品，持续集成，快速迭代，如此才有高效的生产力啊！
关于自动化，书里提到，”在端到端的自动化测试上过度投入，常常会把你与产品的特定功能设计绑定在一起，这部分测试在整个产品稳定之前都不会特别有用。“因此，引入自动化的时机比较重要，只有重要且稳定的产品，才有自动化的必要，减少不必要的自动化代码维护开销。
目前看到这里，一个比较深的感触就是，要切实提高自己的代码开发能力，不能在以测试为借口，看看这个圈子里，有很多具备完美编程能力的测试员，测试的进阶，要以代码编程能力为跳板，否则，就永远只能成为鼠标党！！！