《Google软件测试之道》读书笔记

  • 质量不是被测试出来的、但未经测试也不可能开发出有质量的软件

  • 一个产品在发布给用户使用之前，一般都要经历“爬、走、跑”的模式

    1. 金丝雀版本：每日构建一个，用来排除过滤一些明显不适宜的版本

    2. 开发版本：每周发布一个，日常工作使用，可以持续对这个版本进行测试

    3. 测试版本：工程师日常使用最稳定、通过持续测试的版本

    4. beta或正式发布版本：非常稳定的测试版本、并且通过了质量考核、对外发布的第一个发布

  • 开发人员、测试人员以及开发测试的职责划分

    SET也是开发角色

    1. 100%时间在编写代码，SET和SWE是合作伙伴

    2. 工作重心在可测试性和通用测试基础框架

    3. 参与设计评审

    4. 为了增加可测试性，甚至会对代码重构

    5. 关注质量提升和测试覆盖率增加

    TE是

    1. 产品专家，质量顾问和风险分析师

    2. 大量时间在模拟用户的使用场景的代码上。

  • 组织结构

 

 

    1. 测试是独立的部门（工程生产力团队），以租借的方式进入产品

    2. 不同项目组的借调，时刻保持新鲜感，也方便好的测试想法快速蔓延。

    3. 推广创新技术，直接借调创新的发明者是一个很好的办法

  • 测试类型

    1. 经验法则，即70/20/10原则：70%是小型测试，20%是中型测试，10%是大型测试。

    2. 如果面向用户，集成度高，用户接口复杂，增加中大型测试比例。

    3. 基础平台或面向数据，增加小型测试比例。

  • 只有软件产品变的重要的时候质量才显得重要

  • 产品早期一般不投入测试（可能重新设计），正式批准后，才会寻求测试资源。

  • 项目都需要有设计文档，包括但不限于以下各点：

    1. 实现目标

    2. 背景

    3. 团队成员

    4. 系统设计

  • 在设计阶段，SET会做一些类似代码复用和模块交互方面的设计，在推进项目的同时也可以简化相关项目成员的工作

  • SET需要熟悉了解所负责的系统设计，带着目的性去审阅相关的设计文档，然后提出相应的意见或建议，目的性主要包括以下几点：

    1. 文档完整性：找出文档中一些需要补充的背景知识等，需要做到的程度为新人也能够通过文档清晰地了解项目。

    2. 文档正确性：检查文档是否有语法、拼写、标点符号等方面的错误。

    3. 文档一致性：检查文档是否存在图文不符、主题与内容不一致。

    4. 设计：检查文档的设计可行性、实用性以及可完善性。

    5. 接口与协议：检查文档中的接口协议是否有清晰的定义、是否符合标准。

    6. 测试：考虑系统设计的可测试性、易测试性，预估相应的测试工作。

  • 试图自动化所有端到端的测试用例，是一个常见的错误（SWE也不会感兴趣） 自动化投入越多，维护成本越大。自动化计划，应该规模更小，目的性更强 端到端的自动化测试投入过度，会把产品特定功能绑定在一起，产品稳定之前都不会特别有用。SET应该投入到提高质量，而不是维护不稳定的测试套件上。

  • Google的TE综合了开发者仰慕的技术能力和以用户为中心检查软件质量而对开发者产生一定制约的能力。

  • TE在进入产品时，需要考虑以下一些问题。

    1. 当前软件的薄弱点在哪里？

    2. 有没有安全、隐私、性能、可靠性、可用性、兼容性、全球化和其他方面的问题？

    3. 主要用户场景是否功能正常？对于全世界不同国家的用户都是这样吗？

    4. 这个产品能与其他产品（软件和硬件）互操作吗？

    5. 当发生问题的时候，是否容易诊断问题所在？

  • TE的职责

    ①测试计划和风险分析

    ②评审需求、设计、代码和测试--个人理解：目前来讲，国内大部分的测试接触代码还是很少的，但代码是测试发展的一个必然趋势

    ③探索式测试

    ④用户场景

    ⑤编写测试用例

    ⑥执行测试用例（包括提交BUG、跟踪、协助沟通修复以及回归等等）

    ⑦使用统计（测试每个阶段的版本迭代、BUG数量、质量指标、用时等等数据信息）

    ⑧用户反馈（这对于优化产品，提供更好的服务很重要）

  • 优秀的测试计划应该有的一些特性：

    ①及时的更新

    ②描述软件产品的目标和卖点

    ③描述软件的结构、各种组件和功能特性的名称

    ④描述了软件的功能和操作简介

    ⑤描述了必须执行的测试点

    ⑥对测试工作提供有用的信息，帮助确定进展以及覆盖率的不足

    ACC分析方法：即Attribute Component Capability,特质、组件、能力

  • 风险分析

    △没有完美的软件产品应用，风险无处无时不在！

    定义：确认风险的过程称之为风险分析；

    常识性的关于风险的一些因素：

    ①哪些事件需要担心

    ②这些时间发生的可能性、概率有多大

    ③一旦发生，对客户、业务、公司有什么影响

    ④有什么缓解防范机制

    ⑤缓解措施有多大的成功率

    ⑥处理这些失败的成本消耗

    ⑦恢复过程的难易程度

    ⑧事件是一次性问题还是会再次发生......

    总结：影响风险的因素很多，关键性的有两个因素：失败频率（frequency of failure）和影响（impact）;风险是一个定性的相对值，而不是一个定量的绝对值。

  • GTA（Google test analytics：Google测试分析，一个方便数据输入和风险可视化的web应用，感兴趣的可以去搜索看看）中风险发生频率有4个预定义值：

    罕见（rarely）：发生故障的可能性极小，发生后恢复也很容易

    少见（seldom）：少数情况下会发生故障，但在使用场景复杂度不高（或使用频率较低）的情况下，发生的可能性非常小

    偶尔（occasionally）：故障情形容易想象、场景有点复杂，该功能点比较常用

    常见（often）：该能力所属的特性使用量大、复杂度高、问题频发

  • 关于一些风险分级说明：

    最小（minimal）：**用户甚至不会注意到这个问题

    一些（some）：可能会影响用户的一些问题；一旦发生，重试或恢复机制即可解决问题

    较大（considerable）：故障导致组件使用受阻

    最大（maximal）：发生的故障会永久性损害产品、公司声誉，并造成无法挽回的损失（用户流失等严重问题）

  • 首先需要明白一点：风险永远不可能彻底消除！如何预防缓解风险，可以参考如下几点：

    ①可以围绕风险等级高的能力点编写测试用例，从中拆分、确定风险等级低的使用场景，然后反馈到开发团队，有针对性的增加约束、提示；

    ②对风险按照等级高低做记录，设计回归测试用例，以确保问题重现时可以被捕捉到；

    ③设计和运行会引发故障的用例，以便推动开发团队实现实时恢复和版本回滚；

    ④对风险组件或者场景进行监听、报警，以便更早的检测到故障；

    PS:具体的缓解措施取决于应用本身以及对于安全性的期望值。TE的主要职责就是主动去暴露风险，根据风险等级，按照从高到低测试，如果时间不够，先测试风险最大的。

    还有一点：按照项目类型和进度给出是否可以发布的建议，这是TE的责任，这一点完全可以利用风险热图来完成。

  • △TE与风险

    ①对于任何在GTA（前面有提到）矩阵中显示为红色高风险的能力点和特质的一组件对，一定要设计一些列的测试用例或有针对性的场景去主动发现、暴露风险；--责任、职责

    ②认真了解分析SET和SWE已经完成的测试工作，评估这些测试对GTA所暴露风险级别的影响（测试力度是否足够？是否需要增加额外的测试？）；--评估力度并给出是否进行下一步建议

    ③分析每个高风险的特质--能力对的相关BUG，保证回归测试用例的存在和有效性（BUG倾向于在代码发生变更时重现）--做好记录，回归

    ④仔细思考高风险的区域，考虑可能的版本回滚和恢复机制；

    ⑤尽可能多的引入相关各方，学会利用团队的力量；

    ⑥如果时间范围内还没有足够的测试或者缓解措施，经常出问题，那么应该考虑努力去说服相关同事，做好备用措施！

    PS：对于风险级别较低的点，可以尝试探索性测试。。。

  • bug的组成和生命周期（其中很少有必选的项，可以根据自身及团队需要抉择）

    Assigned to（Assignee，被指派者）：负责采取下一步动作的人 --可选项

    CC（抄送）：当一个问题被创建或修改，需要通知的一个或多个人 --可选项

    Attachments（附件）：关于某个问题，相关的描述文件 --可选项

    Blocking（阻塞）：该bug被修复后才能被修复的其他bug的ID --可选项

    Depends On（依赖）：该bug依赖其他的bug的ID→→其他bug被修复前，该bug无法修复 --可选项

    Change（变化）：该bug最后的修改日期和时间 --只读

    Changelists（变更列表）：处理该问题的一个或多个变更列表（CL）编号 --可选项

    Component（组件）：与此bug有关的或者有需求的实体（创建时需要指向组件的完整路径） --必选项：准确的描述

    Created（创建于）：该bug的创建日期 --只读

    Found In（发现于）：发现问题时的软件版本号等 --可选项

    Last modified（最后修改）：该问题的任一一堆被修改的最后日期 --只读

    Notes（备注）：问题本身及其处理过程中的注解的详细描述 --可选项

    Priority（优先级）：bug的重要程度 --必填

    Reportde by（Reporter：报告者）：谁发现或者谁提出的这个bug --只读

    Resolution（解决方案）：验证者最终决定的解决方案 --可选项

    Severity（严重性）：该bug在多大程度上影响产品的正常使用 --必填（一般分为导致系统无法使用、高、中、低、对系统无影响五个等级）

    Status（状态）：bug的当前状态 --必填（新建、已指派、已接受、不修复、已修复、以后修复、已确定、已验证、已关闭等状态）

    Summary（摘要）：关于该bug描述性的摘要 --必填（尽量做到准确概括）

    Targeted To（目标）：该bug在哪个版本号被修复 --可选项

    Type（类型）：问题的来源类型 --必填（缺陷、需求、客户问题、内部问题、流程等）

    Verified In（验证于）：问题修复被验证的软件版本号 --可选项

    Google最常用的BUG管理工具：Buganizer，可以将其理解为一个典型的bug数据库。

     

    说到这里，有个问题；测试最重要的一面是什么？是确认！！！

    软件产品是否达到用户预期和需求设计，很重要！！！

  • 应该按照什么的结构顺序写用例和进行测试，思考为什么要这么写用例，怎么提升产品质量、考虑维护测试的长期性、全局思考、全面看待产品

  • 专注于预防 bug 而不是检测 bug，这为我们带来了巨大收益。我们推动自动化测试在代码提交之前更早地执行，避免了大量质量不佳的代码污染项目

  • Google测试的秘方：技能（测试人员的技术能力）、稀缺性（获得开发人员的帮助）、自动化、迭代集成

  • google的测试流程概况：让每个工程师都注重质量

    • 测试成了开发的拐杖（测试变得越简单，开发越不会去做测试）

    • 测试人员更关注自己的角色，而不是他们的产品

    • 测试人员崇拜测试产物胜过软件本身（所有测试产物的价值，在于他对代码的影响，再通过产品来体现）

    • 产品经过最严格的测试发布以后，用户有多大可能仍然发现测试中遗漏的问题？答案是：几乎必然发现

  • 更少关注测试流程，更多关注产品本身

posted @ 2020-06-03 12:00  cfYu  阅读(340)  评论(0)  编辑  收藏  举报