Google的软件测试之道-学习笔记

第1章 Google软件测试介绍

1.Google是一家以创新和速度为基础的公司，

1. 快速地发布有用的代码、
2. 迭代地增加早期用户希望使用的功能——最大化用户反馈。
   ——这样的环境下，测试会变得灵活，测试和开发会交织在一起无法区分彼此。

2.测试不是教条式的，不能成为导致创新和开发过程变慢的阻碍。

3.如果你是工程师，那么你同时也是一名测试人员；如果你的头衔有测试字样，你的任务就是怎样使哪些头衔上没有测试的人可以更好地去测试。

4.开发对质量负责，质量是一种预防行为，而不是检测
——这样可以有效减少测试人员的数量。

5.三个职位

1. 软件开发工程师 SWE
   实现最终用户所使用的功能代码，并实现测试用例的代码
   ——增加功能性代码或提高代码性能。
2. 软件测试开发工程师 SET
   工作重心在可测试性和通用（自动化）测试框架上
   ——关注质量提升和测试覆盖率的增加，为了让SWE更好地测试自己的功能。
3. 测试工程师 TE
   把用户放在第一位来思考，代表用户利益
   ——模拟用户的使用场景和编写自动化脚本，构建端到端的自动化测试（关注性能、安全性、国际化、访问权限等方面）。

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

1.理想情况下，完美的开发过程：测试先行

1. 在没有代码之前，开发人员就去思考如何测试他即将编写的程序；
2. 另外一些依赖于外部设施的测试，在你需要时，这些设施可以随时被使用。

2.区分功能开发人员和测试开发人员：

1. 功能代码：思维模式是创建，重点在考虑用户、使用场景和数据流程上；
2. 测试代码：思路是破坏，怎样写测试代码用意扰乱分离用户及其数据。

3.开发背景：单一的公开代码库
——工程师可以从容的在不同项目之间切换，几乎不需要学习成本；
并且对于有需求的工程师，所有源代码都是开放的，带来极大的可复用性。

• 当代码库修改时，需要测试所有受影响的部分重新测试，保证项目的“绿色”。
• 一个完整的Google产品由三部分组成：
  1. 一个经过良好测试的独立库；
  2. 一个可读性与复用性方面都不错的公共服务库；
  3. 一套覆盖所有重要构件目标的单元测试套件。

4.自动化计划

• 规模小目的性强的测试计划，并存在可以提供帮助的测试框架，可以使SWE更愿意参与和帮助SET的工作，且参与测试；不要过分地想得到一个端到端的自动化测试。
• 在端到端的自动化测试上过度投入，往往会将测试与产品的特定功能绑定在一起，而这部分的测试在整个产品稳定之前都不会特别有用。

5.可测试性
SET的任务是编写测试框架，保证SWE代码的可测试性。

6.测试规模

1. 小型测试——单元测试
   集中在函数级别的独立操作与调动上；
   在代码变更时就能立即执行，容易隔离错误，从而较早地发现缺陷并提供及时的反馈。
2. 中型测试——集成测试
   目标是验证指定模块之间的交互。
3. 大型测试——系统测试
   验证系统作为一个整日是如何工作的；
   对外部有依赖，具有一定的非确定性，精准寻找失败根源会比较困难。

7.测试不做任何数据持久化方面的工作。在这些测试离开测试环境的时候，要保证测试环境的状态与测试用例开始执行之前是一样的。

8.测试认证级别
——参与的团队对使用各级别标准作为可度量的团队目标，引起各团队对测试的兴趣。

• 在真正实施过程中，可以根据实际执行情况更新级别标准，定制化一些多数团队可以满足的标准，避免两级别之间跨度太大，打击积极性。

9.SET的招聘

• 重点考察候选人如何思索问题的解决方案，而不是解决方案本身的实现上有多么高雅。
• 应该先把问题搞清楚，并且从最重要的地方开始入手（如：列举最重要的测试用例）。
  ——花几分钟提问，了解需求文档（编码方式、函数名称命名规范、返回值类型、是有定义模糊的点）
• 其次可以关心扩展性、复用性、安全性

1. 扩展性：什么情况下可能会用到这样的函数模比较大的场景下适合吗（while(true)循环模拟长时间运行、在并发线程中调用该函数）li>
2. 复用性：函数是否可以表现为更通用的形式（通过参数传入）li>
3. 安全性：非法输入现异常时如何返回li>

9.不要忽视一些看不见的功能，如可用性和响应速度。

10.缺陷驱动开发：一旦用户发现了一个bug就立即去修复它，这样可以确定修复了的bug是人们真正关心的bug。

第3章 测试工程师

1.早期过度地投入测试意味着资源的浪费。在研发的早期阶段、功能还在不断地变化，过早地完成的测试产物可能会被丢弃，也可能花时间维护了毫无附加价值的东西。

2.TE的根本实名是保护用户和业务的利益，使之不受到糟糕的设计、令人迷惑的用户体验、体验bug、安全和隐私等问题的困扰。

3.TE的工作内容

1. 一些TE主要写中到大型的端到端用户场景测试；
2. 一些TE会检查代码和系统设计以确定失效模式，并寻找到导致失效的错误路径。

• TE擅长发现需求中的模糊之处，分析沟通不明确的地方。
• “从中间开始”：TE必须保持足够灵活，能够迅速融入一个产品团队的文化和现状。

4.伴随着计划内或计划外的变更，维护一份测试计划是要花费大量精力的，除非多数项目的成员会定期查看，否则测试计划并没有什么价值。

5.ACC（Attribute Component Capability）特质、组件、能力
描述目标的形容词和副词；确定产品各部分、各特性的名词；描述产品实际做什么的动词。

1. A特质（Attribute）
   代表了产品的品质和特色，是区别于竞争对手的关键。
2. C组件（Component）
   组件是构成待见系统的模块。
3. C能力（Capability）
   代表系统在用户指令下完成的动作，是对输入的响应、对查询的应答、以及代表用户 完成的活动。
   能力是面向用户的，表达的是用户眼里系统的行为，往往比特质和组件都要多很多。

• 公式：组件（C）执行某种功能来满足产品的某一特质（A），这个活动的结果是向用户提供某种能力（C）。
• 目的：快速建明的列出保证待验证系统能正常运转的最重要的能力。
• 将能力转化为测试用例时，重点考虑实际使用的测试场景。
• 展示形式：特质-组件表，对应框内填写所有能力。

6.风险分析
给ACC定义的所有特性排优先级。

• 衡量要素：失败频率（frequency of failure）和影响（impact）
  ——风险是定性的相对值，仅需要识别一个能力与另一个能力相比的风险大小。

• 展示形式：在特质-组件表上生成区域风险热图。

• 风险缓解：风险处理顺序的原则为先测风险最大的。

• 测试人员可以根据风险热图，结合项目类型（对风险能够容忍的程度），给出产品是否可以发布的建议。

• 高风险的能力点和特质-组件对，一定要编写一系列用户故事、用例或者有针对性行动的测试之道。

7.10分钟测试计划

• 一些测试计划描述了本来不必记录的简单事实，或者给测试人员提供了日常工作并不需要的细节，所以给测试计划瘦身，只列出绝对必要的东西，把细节留给测试执行者而不是测试计划者。

1. 使用类似ACC的方法，速记列表，而不是大段文字；
2. 列出特质和组件，并开始描述能力（足够大的能力集合是创建用户故事或测试用例的良好起点）。

8.编写用户故事时，我们仅从用户界面角度出发关注产品，而绝不应该描述技术性内容。

9.众包测试
选取一部分对测试懂行的高级用户，在不同的硬件和环境组合下测试软件。

• 优点：大众用户除了带来大量的硬件和配置，还能提供多种不同的视角；
• 缺点：需要一定时间来学习被测应用，并跟上其更新的步伐。

10.管理测试用例
Google工具：GTCM（Google Test Case Manager）主要用于管理手工测试用例。

• Google的任何人都可以发现并 告bug（终端用户也可以通过工具提交针对某个产品的bug）。
• 项目可以根据bug统计的数据展示，找出一些规律：

1. 有些项目，手工测试总量未增加，但总覆盖率在增加
   ——改团队使用了更多的自动化、众包、探索性测试。
2. bug优先级月底，重要性也就越低，平均修复响应时间也就越长。
3. 许多团队在bug到达的速度超过了其修复能力的时候，干脆选择不再进行新功能特性的开发。
   • 不存在正式的自顶向下的确定bug优先级的流程，各团队bug的优先级评定由团队自主决定。
   • 对于用户提交的bug，会使用聚类算法来自动识别重复记录并确定最频繁的问题（精简到10个左右的主要、共性的问题）。

11.当发现了bug需要考虑的问题：

1. 它是否在用户可达之路上li>
2. 这些路径被走到的可能性有多大li>
3. 除了发现bug的这条路径，是否还有更多的路径也会导致相同的问题li>
4. 是否存在可能影响数据或者其他应用的副作用li>
5. 是否存在隐私、安全、性能，或者可访问性方面的影响li>

12.TE的招聘

• 测试最重要的一面是做确认，一个应用是否达到用户预期又一遍的测试用以模拟真实的使用场景，确保在这些通用条件下，软件运行不会出错。
• TE需要适应几乎所有的产品和角色，从构建工具、接洽客户、到跨团队和依赖的协调等，TE通常能比SET站得更高、看的更远，能够理解各种设计问题和风险。

1. TE发现用户界面问题，从系统整体或竞争者产品角度思考问题；
2. SET专注于高质量的、可测试的、可复用的模块，以及自动化。

在设计测试用例时，不能只追求数量，而应该先提出一些问题来更全面的了解要测试的部分

1. 在尝试破坏软件的同时，也需要验证它是否能正常工作；
2. 从最显而易见的简单输入开始，可以尽快地发现大bug；
3. 首先关注功能性测试，再给出其他方向（UI、安全、兼容、本地化、性能）。

• 功能性测试中，更懂技术的候选人，会询问数据的规格说明，进而围绕极限点进行边界测试——不仅仅给出“长字符串”这一个抽象的概念，而是给出具体长度（如：int值测试2的32次方）。
• 最优秀的候选人还有可能会意识到系统是有状态的，测试必须将先前输入考虑在内（如：先执行失败用例，再执行成功用例）。

13.Web测试
比较 页的DOM结构来判断是否加载正确（传统方式：比较截图图片，但有可能会被页面上的动态元素干扰）。

14.实现自动化并不代表测试人员无事可做了，他们可以更专注于需要开动脑筋的探索式测试、风险分析、关注用户等。

15.BITE浏览器集成测试环境（Browser Integrated Test Environment）
目标是把尽可能多的测试活动、测试工具和测试数据集中到浏览器和云里，并在上下文中呈现相关信息。

• 一个测试人员的很多时间花在了上下文切换和分析大量数据上。
• 工具帮助自动转化Bug，省去描述Bug、描述操作步骤、找对应HTML标签等步骤，并且还会以悬浮的形式展示当前页面已提交的所有Bug，防止重复提交。

16.参与一个新项目，需要做哪些准备p>

1. 站在用户的角度了解这个产品，可以作为用户去使用产品；
2. 从头到尾理解产品，看设计文档；
3. 关注项目的状态，特别是质量状态（了解Bug数量、问题的分组方式、已 告的Bug类型、最长时间未处理的Bug、最近一些Bug的类型等，以及Bug修复比例）；
4. 检查应用的代码库，和关联的单元测试，以及使用到的自动化测试，是否都有效；
5. 询问团队成员对测试的期望

正式开始测试工作p>

1. 把应用分解为合理的功能模块；
2. 根据风险，排列测试的优先级；
3. 按照优先级顺序更加细致地遍历所有模块，创建用户故事；
4. 通过再次检查Bug和应用来寻找覆盖度上的不足。

17.用仍在影响用户的陈旧Bug数量来衡量自己的影响力。

18.测试结束的标准：你有足够的信心，剩下的Bug都属于那些使用率较低、出问题之后对用户影响也较低的模块——这也是为什么要按照一定的优先级进行测试。

第4章 测试工程经理

1.测试工程经理是作为独立贡献者的一个技术岗位，负责所有的支持团队（开发、产品管理、产品发布、文档等）之间的联络。

2.必备素质：

1. 了解你的产品：
   对于被测产品的任何问题都应该达到专家级别，从用户界面到后台到数据中心实现，都应该了如指掌。
2. 知人善用
   资源紧缺能够促使项目的参与者职责明确，问题不能简单地通过增加人手来解决。不仅要让团队具有影响力，也要根据每位工程师的职位级别和具备的能力帮助他们发挥相应的能力。

3.不能仅仅依赖于某位明星测试人员，要把能促成这位测试人员成为明星的东西沉淀成可用的工具，或者总结成一套方法，这样可以帮助其他人也走上成为明星的道路。

4.经验丰富的测试工程经理绝不会把自己限制在自己的产品范围之内，他们在团队建设不断地交流，因为不想错过使用其他团队那些了不起的创新工具和方法（跨团队的交流必须建立在创新的基础之上）。

5.深入理解团队时，多想“为什么”
人们有时候做事只是因为看到别人这么多，或者他们测试某个特性的时候只是做那些他们知道怎么做的东西。

算好的答案：

1. 因为它能够提高产品的质量;
2. 因为它能提高工程师开发产品的效率。

6.当团队打算做的事情太多，但每件都只能完成80%时，需要退回来重新安排优先级。当需要做的事情减少到两三件，但都能完成到100%，这样团队才能获得真正的成就感。

7.先为少量用户放出一个版本，获得必要的反馈，然后在为大量的自动化测试进行投资（把复用率高的测试用例自动化）。过载编写测试，可能由于构架的变化导致全部工作作废。

8.团队成员素质：

1. 不会沉迷于系统的复杂性、遇到困难的问题时能够分解为可执行的步骤并最终解决；
2. 有执行力，会被紧迫感激发而不是吓跑；
3. 能够在创新和质量中掌握平衡，不应该只满足于发现更多的bug。

9.何时会建立手工测试文档p>

1. 有一个通用的用例，它可以被每次构建版本使用而且也是主要的测试路径；
2. 把每个功能点的特性作为指导原则记录下来，为后来的测试人员快速接手做准备。

第5章 Google软件测试改进

1.让每个工程师都注重质量，因为测试不能保证质量，质量是内建的，而不是外加的。

2.测试人员应该更关注产品，而不是自己的角色。

3.相对于被测代码来说，测试产物（测试用例、测试计划、bug 告）都是次要的，所有测试产物的价值，再与它们对代码的影响，进而通过产品来体现。

4.内部使用者、可信赖者、众包测试者，以及早期用户都可能比测试工程师更容易发现bug。

5.通过互联 交付软件，意味着可以选择部分用户进行发布，响应这部分用户的反馈，并迅速更新，这是一种更好的软件交付和用户反馈机制。

6.未来的测试人员将会尽可能多地共享代码、用例和bug数据，而来自 区的回 将是新的众包形式的测试和用例创建，以及友善的用户关系，这些比隐藏各种东西所获得的想象中的利益重要的多。