《算法之魂》

• 
  

  《Google 软件测试之道》

• P2：维持任何事情的惯性导致任何变革都变得非常困难

• P5：最开始设计创建的时候就是错的，那它永远不会变成正确的
• P8-P9：SET 主要职责：让开发者可以很容易地编写测试代码，从而达到独立功能模块的质量要求
  • 不是简单的被告知某个项目急需发布就可以通过测试。我们有自己的选择决定的优先级，在可靠性、安全性等问题上都不会妥协，除非碰到更重要的事情。
  • P21：SET 软件工程师，能尽早的介入开发流程，但不是通过“质量模型”和“测试计划”的方式，而是通过参与设计和代码开发的方式
  • P25：代码复用和模块交互方面的设计由 SET 来做，而不是 SWE
  • P26：技术审阅关注点（这里需要反复斟酌）
    • 完整性
    • 正确性
    • 一致性
    • 设计
    • 接口与协议
    • 测试
• P15：
  • 测试代码：去破坏，怎样写测试代码用以扰乱分离用户及其数据
  • 功能代码：去创建，重点考虑用户、使用场景和数据流程
• P24：尝试去文档化我们将要去做的事情，我们尝试去保证我们早期做的决定长期看来也是正确的
• P41：自动化测试不仅仅是自动化测试程序的编写，必须要去考虑如何编译测试程序、执行、分析、存储和报告测试运行结果，这些都是自动化测试会遇到的挑战
• P48：代码覆盖率：检查一个项目里小型测试、中型测试、大型测试之间的比率是否健康
• P130：工作的乐趣和产品的巨大影响力，很大程度上产生于一群志趣相投的工程师彼此协作，在强大的基础计算架构上成就神奇
• P145：对管理层的建议：给工程师留一些自由呼吸和实验的时间，他们会给业务和客户一个惊喜
• P151：自动化测试结果的误报，会导致开发和测试失去耐心，干脆忽略掉测试结果
• P167：坦诚的指出某些领域或组件的测试不应该由我负责，而应该由他们自己负责的时候，开发反而更看重我的工作了。很多测试人员试图避免自我宣传，避免公开讨论他们不会测试的东西，担心这让做会使人轻看测试的价值。但事实缺恰恰相反，开发会因此尊敬你
• P171：质量是大家的共同责任，没人能置身事外。任何工程师都可以测试任何机器上的任何代码
• P174：敢于扔掉过时的东西。如果测试或自动化过于难以维护，不如放弃它并试着去实现更有韧性、更好的东西
• P178：资源紧缺问题不能简单的通过增加人手来解决，使用工具化的方式将其流水线化。没用的自动化测试会被弃用，不能发现回归问题的测试根本不会被编写。不允许不必要的工作存在，也不需要不产生价值的改进。
• P186：
  • 为少量用户放出一个版本，获得必要的反馈，然后再为大量的自动化测试进行投资
  • SET 应该牢记测试应该是开发工程师的工作，而他们自己应该专心让测试称为开发人员工作中的一环。我们通过工具帮助开发人员做到这一点，而且让开发人员在维护开发代码的同时也负责维护测试代码。
• P187：更专注于预防 BUG，而不是检测 BUG。自动化测试在代码提交之前更早地执行，避免大量质量不佳的代码污染项目
• P219：测试并不能保证质量。质量是内建的，而不是外加的。因此保证质量是开发者的任务，这一点毋容置疑。这就带来了第一个致命缺陷；测试成为了开发的拐杖。我们越不让开发考虑测试的问题，把测试变得越简单，开发就越来不会去做测试
• P220：所有测试产物的价值，在于它们对代码的影响，进而通过产品来体现