《Google软件测试之道》读书笔记
《Google软件测试之道》读书笔记
质量不是被测试出来的、但未经测试也不可能开发出有质量的软件
⼀个产品在发布给⽤户使⽤之前，⼀般都要经历“爬、⾛、跑”的模式
1. ⾦丝雀版本：每⽇构建⼀个，⽤来排除过滤⼀些明显不适宜的版本
2. 开发版本：每周发布⼀个，⽇常⼯作使⽤，可以持续对这个版本进⾏测试
3. 测试版本：⼯程师⽇常使⽤最稳定、通过持续测试的版本
4. beta或正式发布版本：⾮常稳定的测试版本、并且通过了质量考核、对外发布的第⼀个发布
开发⼈员、测试⼈员以及开发测试的职责划分
SET也是开发⾓⾊
1. 100%时间在编写代码，SET和SWE是合作伙伴
2. ⼯作重⼼在可测试性和通⽤测试基础框架
3. 参与设计评审
4. 为了增加可测试性，甚⾄会对代码重构
5. 关注质量提升和测试覆盖率增加
TE是
1. 产品专家，质量顾问和风险分析师
2. ⼤量时间在模拟⽤户的使⽤场景的代码上。
组织结构
1. 测试是独⽴的部门（⼯程⽣产⼒团队），以租借的⽅式进⼊产品
2. 不同项⽬组的借调，时刻保持新鲜感，也⽅便好的测试想法快速蔓延。
3. 推⼴创新技术，直接借调创新的发明者是⼀个很好的办法
测试类型
神界2龙裔
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数量、质量指标、⽤时等等数据信息）
⑧⽤户反馈（这对于优化产品，提供更好的服务很重要）
优秀的测试计划应该有的⼀些特性：
①及时的更新
②描述软件产品的⽬标和卖点
③描述软件的结构、各种组件和功能特性的名称
④描述了软件的功能和操作简介0577是哪里的区号
⑤描述了必须执⾏的测试点
⑥对测试⼯作提供有⽤的信息，帮助确定进展以及覆盖率的不⾜
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的测试流程概况：让每个⼯程师都注重质量
测试成了开发的拐杖（测试变得越简单，开发越不会去做测试）
测试⼈员更关注⾃⼰的⾓⾊，⽽不是他们的产品
基金赎回几天到帐测试⼈员崇拜测试产物胜过软件本⾝（所有测试产物的价值，在于他对代码的影响，再通过产品来体现）
产品经过最严格的测试发布以后，⽤户有多⼤可能仍然发现测试中遗漏的问题？答案是：⼏乎必然发现
更少关注测试流程，更多关注产品本⾝

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。