阅读有关Google软件测试的笔记

以下是阅读Google软件测试后的摘录和完成笔记. 主要摘录是我同意，启发和指导的内容. 并正确整理了本书的内容. 有关内容，请购买原始书

第1章: Google软件测试简介

1. Google的测试团队不是一百万士兵，我们更像是小型而精巧的，我们依靠出色的战术和先进的武器

2. 在Google，编写代码的开发人员还承担测试的责任. 对于某些测试人员而言，质量绝不是问题. 每个编写代码的开发人员也都是测试人员，质量也很重要. 这种开发和测试的结合是共同承担的

3. Google团队由SWE（软件开发工程师），SET（测试开发工程师），TE（测试工程师）组成

4. 对于Google的测试人员来说，如果他在某产品中工作了18个月，就可以无缘无故地自愿转移到其他产品

5. Google从来没有在产品版本中包含大量功能. 产品的基本核心功能实现后，立即发布以供使用，然后从用户那里获得真正的反馈，然后进行迭发. 发布经验Canary版本（每日构建）->开发版本（通常每周一次）->测试版本（基本上是上个月的最佳版本）-> Beta或发行版

6. Google的测试类型可用

对于所有三种类型的测试软件测试相关书籍，Google都喜欢进行自动化测试. 当然，谷歌也有很多手动测试. 它更喜欢测试新功能，用户体验，隐私等

第2章: 软件测试开发工程师

1. 本书讨论了编写功能代码和测试代码之间的区别: 对于功能代码，思维模式是创建，着重于考虑用户，使用场景和数据流. 对于测试代码软件测试相关书籍，主要思想是销毁如何编写测试代码以扰乱用户及其数据的分离. 因此有必要区分开发工程师和测试开发工程师，因为他们的思维方式是不同的

2. 所有工程师都必须重用现有的公共图书馆，并且必须对公共通用模块进行审查

3. 在构建系统之前，根据需要运行静态代码分析工具

4. 在采访SET时，代码要求与SWE的招聘要求相同，并且SET还需要知道如何测试他们编写的代码.

5. 在项目测试的初始阶段强调测试是非常愚蠢的（产品概念尚未完全确定要成型）

6. 所有Google项目都有设计文档，这是一个动态的，不断更新的文档

7.SET是第一位审查所有设计文档的人. 审查设计文件的要点:

8. SET时间有限，有太多事情要做. 尽早提供可行的自动化测试计划是一个很好的解决方案

9. 对端到端自动化测试的过度投资通常会使您束缚于产品的特定功能设计，在整个产品稳定之前，这部分测试将不会特别有用

10. 在Google，我们关注代码的可读性，并确保整个代码库看起来像是由一个人编写的. Google内部的主要编程语言是C ++，Java，Python和Javascript. 可读性要求

11. 只有可以加速开发过程的自动化测试才有意义，并且测试不应减慢开发速度. 话虽如此，因为Google坚持要迅速发布该项目

12. 将代码更改提交到版本控制系统后，所有测试将自动运行

13.70 / 20/10原理: 对应于小型测试，中型测试和大型测试. 当然，这个比例不是固定的

14. Google试运行的要求

15. 对于每个重要的缺陷修复，必须添加一个测试用例以与之对应

16. Google对SET的招聘要求: 具有强大的编码能力，可以编写功能代码和强大的测试人员的程序员. 可以测试任何产品，并具有管理自己的工作和工具的能力. 技术好奇心也很重要

第3章: 测试工程师

1. TE为产品做出了很大贡献. 首先是工程师的一部分. Google的TE集成了开发人员欣赏的技术技能以及以用户为中心的软件质量检查能力，并对开发人员有一定的限制p>

注意: 关于TE招聘，这本书中没有完全一致的讨论.P122用以下方式描述了TE招聘:

2. 如果产品可能被取消，或者尚未吸引用户，或者功能尚未完成，则测试工作通常应由产品开发人员完成

3. TE进入产品时要考虑的问题:

TE不必自己解决所有这些问题，但必须确保解决了这些问题. TE在测试计划和测试完整性方面必须更加系统和透彻，重点在于真实用户的使用和系统级的经验Up

4. 如果项目刚刚开始，则测试计划是第一要务. TE职责的一般说明

5. 测试人员不要过多地珍惜测试文档，不良的测试用例将被丢弃，最后剩下的是更好的测试用例.

6. Google进行的风险分析实际上是基于软件功能的优先级[p90]

7. 有许多因素会影响风险. 在Google，我们确定了两个因素: 失败频率和影响

8. 缓解风险: 不可能完全消除风险，一种极端的缓解方法是删除最具风险的组件

9. 如果可能的话，我们还将尝试替换不同的测试人员来执行这些方案（用户案例），以尽可能提高不确定性和视角

10. Google的TE为应用程序编写了大量的测试用例，有些测试用例准确地描述了输入和数据，有些测试用例的描述是通用的

11. Android团队是依赖手动测试的较大团队之一

12. 当错误的速度超过修复错误的能力时，许多团队根本不会开发新功能

13. Google的错误管理

14. 对于测试人员来说，找到错误并花一些时间来品尝它们很重要.

15. 测试的重要方面是确认崩溃程序并不总是我们的目标. 使用极端的输入数据测试软件并使其出错是很有趣的，但是使用极端的输入数据会更有趣. 反复测试输入以模拟实际使用场景，以确保在这些常规条件下软件不会出错. 条件. 在面试期间，我们将寻找这种积极的测试概念

16. TE通常被视为不需要编写太多代码的SET. 实际上，他们可以看到那些整天埋在代码中的人永远看不到的东西

17. 管理人员有责任避免开发重复的测试框架，或避免在小型测试中投入过多的资金

18. 效果评估: Google员工应该设定比预期更高的目标. 如果一个人实现了所有目标，那意味着他的目标还不够高

19. 消除手动测试用例的准则:

第4章: 测试工程经理

1. 我们对测试工程经理的期望: 相关项目中最强大的产品专家

2. 您不能过分依赖项目中的某些成员，而不仅仅是依靠星级测试人员

3. 测试工程经理必须努力在团队中找到良好的方法和工具，并与其他团队共享.

4. 最有力的问题是“为什么”

5. 用错误的人来填补配额总是比等待正确的人更糟糕

6. Gmail测试经验:

7. Android测试经理Huang Dang的访谈:

8. 大多数Google测试人员精通Python，他们开发了PyAuto测试库

9. 詹姆斯: 我发现没有比开发工具更好的方法来激发测试人员的创造力和提高测试团队的士气

第五章: Google软件测试和改进

1. Google继续区分开发和测试不是最佳选择

2. 谁在进行测试并不重要，关键在于测试已经执行

3. 通过Internet交付软件意味着我们能够选择一些要发布的用户，响应这些用户的反馈并迅速对其进行更新. 开发人员与最终用户之间的沟通与合作障碍不再存在

4. TE的未来: 测试工程师将转变为测试设计，少数测试设计师会快速计划测试范围，风险热图和应用程序漫游路线. 然后，内部测试人员，可信任的测试人员，早期用户或众包测试人员提交反馈，测试设计人员将评估覆盖范围，计算风险影响，并确保不断减少发现的问题.

5. 几十年来一直保持死亡的测试教条无异于雕刻船

吐槽:

本书前两章的“注意”部分几乎从本书中抄袭而来. 我觉得没有必要刻意在书中用“得”标出很多地方，例如P3“测试必须变得异常灵活”.

最后，尽管只是笔记，但在转载时必须记住要注明出处

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/ruanjian/article-216998-1.html