《How Google Test》读书笔记（一）

《How Google Test》这本书自2012年出来到现在已经有近6年了，和我初入测试行业一样的年龄。可惜最近才读到，不过每个阶段读相同的书总会有不同的收获。这次读书也只是蜻蜓点水式的，但想到这几年的经历，不免也有一些共鸣和思考。

1 测试是独立的部门，与产品部门是平行的。测试人员以租借的方式进入产品团队，不直接向产品团队汇报。

这是我在此书中第一章介绍谷歌软件测试中摘出来的。我一度认为测试应该与开发在同一部门或同一战线，共荣辱共发展，把开发的作品当做自己的产品，这样会让团队成员更加具有凝聚力，产品质量自然也会相对良好一点。这也许和我曾处的环境相关。那个时候没有更多的想法，就是一心想将“自己的产品”尽量减少差错。谷歌独立的测试部门，与我目前的环境又比较相似，因此，看到这个情况，里面吸引我继续看下去，我想知道不一样的架构会产生什么样的结果。

2 测试在某个产品满18个月就可以转岗到其他产品。

这一点，我想是对一个测试人员更多的机会和更大的考验。一个优秀的测试人员不应该仅局限在一个产品中，多元化的环境能更全面的激发潜力。当然了，对于国内大多数的中小企业内部可能并没有这样的机会去转岗其他产品。

3 核心功能后立即发布给用户，然后再进修迭代开发。经历金丝雀版、开发版、测试版、beta版、正式发布版。

事实也是如此。没有用户真枪实战的测试确实可能会遗漏一些重要的、不符需求的（很多时候的需求并不明确或者是比较隐含的需求并没有挖掘出来）的问题。重要的是用户测试也是需要讲究方式方法，因为我们不能让任何一个客户承担一点点的风险，毕竟到最后风险会转嫁到我们自身。

4 每日构建——排除过滤明显不适宜的版本。

这个方法个人觉得适用于任何规模、任何环境的开发和测试，并且非常实用。

5 开发版本——每周发布一个。

谷歌是每周发布一个版本，应该是属于敏捷开发的一个步骤。这也启发我，今后的测试也依然可以围绕定期发布版本来进行。权当做一个规矩。

6 Google并没有使用代码测试、集成测试、系统测试这些名称，而是小型测试，中型测试，大型测试。测试规模越小越容易实现自动化测试。

测试的分类也是根据企业情况来决定的吧。像谷歌这样的大公司，项目多，进度快的，就分成了大中小三类。而我们这样的中小企业几乎都是功能测试为主，其他测试辅助或者不辅助的形式。因此自动化测试就失去了机会。

7 能够自动化，那就应该以自动化的方式实现。手动测试更倾向于新功能。

这点毋庸置疑的。无论那个行业哪个岗位都是向着智能化傻瓜化发展的。虽然目前大部分的自动化测试都是需要付出不成比例的成本代价，但是长远看来仍然是好处多多。这点也是我尝试记录的出发点，时刻提醒自己需要自动化~