《谷歌软件测试之道》读书笔记 是编者的感悟

1、我们并不在意产品少了一个很酷功能，我更在意产品的可靠性和稳定性。

2、质量不是被测试出来的，未经测试也不可能开发出有质量的产品。

应用举例：
产品质量是生产出来的，不是检验出来的。” 美国质量管理大师威廉•爱德华兹•戴明的这句质量名言指出：只有在生产过程中的每个环节严格按照生产工艺和作业指导书要求进行，才能保证产品的质量。如果忽略过程控制，只靠检验是不可能保证产品质量的，因为质量检验只能剔除次品和废品，并不能提高产品质量。
（各个流程要规范！开发流程等触类旁通，可以回答领导问为什么没有测试出来的问题）

3、如果不需要人脑来判断（如界面是否美观，数据是否包含隐私）那就应该自动化。

4、只有在软件产品变得重要的时候质量才显得重要。

（但是现在小公司没有不重要的产品）

5、有义务让测试人员相信他们的产品是令人兴奋的。

（并没有兴奋，发工资就好，可能是小公司的原因）

6、测试的自动化计划必须，让开发相信合情合理且有影响力。

（这个是有道理的，开发是相信你的，比如一个抑制告警的需求，是否抑制的判断和服务器当前时间有关，让开发出接口返回 true or false 来判断是否进行了抑制）

7、改了代码就应该进行相应的测试。

（很难做到）

8、保证每条用例是独立的。用例在执行后和执行前的测试环境是一致的。

（做到了独立运行，没做到用例在执行后和执行前的测试环境是一致的）

9、在研发的早期阶段，功能还在不断变化，最终功能列表和范畴还没有确定，te 通常没有太多的工作可以做。

（甚至功能是口头描述的！）

10、如果软件深受人们喜爱，大家就会认为测试所作所为是理所应当的；如果软件很糟糕，人们可能就会质疑测试工作。但其实也没人真正想去了解测试到底做了什么。

和测试人员相比，开发人员有一个优势就是他们的工作产物是每个人都真正关心的。开发人员编写代码，构建用户期望的、能为公司赚钱的应用。很明显，代码是项目过程中产生的最重要的文档。
然而，测试人员要处理的是真正的文档和其他临时性的事物。在项目的早期阶段，测试人员编写测试计划；然后，他们创建和执行测试用例，编写 bug 报告；接下来是准备覆盖度报告，收集用户满意度和软件质量数据。在软件成功发布（或失败）之后，很少有人会问及测试产物是什么。如果软件深受人们喜爱，大家就会认为测试所作所为是理所应当的；如果软件很糟糕，人们可能就会质疑测试工作。但其实也没人真正想去了解测试到底做了什么。
测试人员不应该对测试文档过于珍爱。软件开发过程充满了痛苦的挣扎：编码、评审、构建、测试、一轮接一轮的开发等，在这个过程里实在很难有时间坐下来欣赏一下测试计划。糟糕的测试用例不会受到足够的关注和改善，它们只会被抛弃，而最后留下来的是更好的测试用例。大家的关注点集中在不断增长的代码库，这才是最重要的东西，理应如此。

11、如果不能全测，就先测最重要的，也是风险最大的。

（认同）

12、ACC:A（Attribute ）C(Component) C（ Capability）分析是围绕特质、组件、能力。

（特质 Attribute 是此品的竞争力，核心功能。组件 Component 我理解的是功能模块如联单功能；能力 Capability 是具体实现的每个小功能 显示、搜索、查询等）

13、协商:不可能什么都测，测试是无止境的，要掌握拒绝的艺术，以理服人。

（需要学习）

14、bite（Browser Integrated Test Environment，浏览器集成测试环境）

(在网站上显示哪里有 bug，并可以快速提交 bug 和显示此页面的 bug,很有意思。)

15、坦诚给开发指出不应该由你测试的东西或领域。

（真诚点好。内心要真诚；对方期许要沟通；社会规范要遵守。）

16、在谷歌技术能力是测试人员得以发挥影响力的关键。会编码才能当一等公民。

（想看一等公民还要看测试负责人强硬不，是否具有话语权，当然会编码成了标配了）

17、质量是大家共同的责任。

（有的公司认为是自己的责任）

18、应该进行探索性测试

（很少探索）

19、应该用 20% 的用例覆盖 80% 的场景。

（不然 需求的改变会有一壶喝的，会浪费很多时间）

20、测试首先是专家级的用户。--首先得了解被测系统

（不理解很难的啦，无法开展好的测试）

21、对于被测系统来说，什么是最为重要的东西？

数据的准确性。对于搜索是性能，对新闻来说是时效性，对地图来说是综合性和完整性。
（我司的特点就是核对对数据，数据要对）

22、测试人员需要关注自己的产品，软件开发的目的不是编码，不是文档，不是测试，而是完成一个产品。

（太多产品了，疲于奔命，开发了都没有用，但是 zf 就是要，公司可以收到回款。）

23、最后一个致命缺陷也许是最深刻的。产品经过最严格的测试发布以后，用户有多大可能仍然发现测试中遗漏的问题？答案是：凡乎必然发现。我们谁都没见过哪个产品能够避免漏测问题所带来的困扰（无论在 Google 还是其他地方）。

（确实是，发现这种问题首先检查测试用例，再去沟通是否漏测，开发如何产生的 bug）

感悟：认知提升了才能明白自己哪里欠缺，应该往哪里使力，工作时间每天潜水都会看下社区，收获很多，感谢所有社区的参与者，贡献者。