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

以下是看完Google软件测试知道之后书中摘录以及整理的笔记.主要摘录自己认同的,有启发性,指导性的内容.并且适当对书中的内容做了一些整理,欲看全部内容请购买原版图书

第一章:Google软件测试介绍

1.Google的测试团队并非雄兵百万,我们更像是小而精的特种部队,我们依靠的是出色的战术和高级武器

2.在Google,写代码的开发人员也承担了测试的重任.质量从来就不仅仅是一些测试人员的问题,每个写代码的开发者本身也是测试者,质量在名义上也是由这样的开发测试组合共同承担

3.Google团队由SWE(软件开发工程师), SET(测试开发工程师),TE(测试工程师)组成

4.在Google,对于一个测试人员,如果在某个产品中工作满18个月之后,就可以无理由地自愿转岗到其他产品

5.Google从来不会在一次产品发布中包含大量的功能,在一个产品的基本核心功能实现之后,就立刻对外发布使用,然后从用户那里得到真实反馈,再进行迭代开发,产品的发布经历金丝雀版本(每日构建)->开发版本(一般每周一次)->测试版本(基本上是最近一个月的最佳版本)->Beta或发布版本

6.Google的测试类型有

• 小型测试:用于验证单独函数或独立功能模块,一般需要使用mock和fake.小型测试由SWE完成,TE可能会参与运行,小型测试都是自动化实现的
• 中型测试:通常也是自动化实现的,一般会涉及两个或两个以上模块之间的交互.SET会驱动这些测试的实现及运行,SWE会深度参与,一起编码维护这些测试.在第二章讲到,它也被称为"集成测试"
• 大型测试:使用真实用户使用场景和实际用户数据,大型测试关注的是所有模块的集成,但更倾向于结果驱动,验证软件是否满足最终用户的需求.所有三种工程师角色都会参与到大型测试之中,通过自动化测试或者是搜索式测试.它也被称做系统测试,端到端测试

对于所有的三种类型测试,Google更倾向于做自动化测试,当然Google也有大量的手动测试.它更倾向于测试新功能,用户体验,隐私之类东西

 

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

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的招聘要求:是一个编码能力很强的程序员,可以写功能代码,也是一个很强的测试者.可以测试任何产品,有能力管理他们自己的工作和工具.有技术上的好奇心也很重要

 

第三章:测试工程师

1.TE对产品的贡献很大,它首先是工程师的一部分,Google的TE综合了开发者仰慕的技术能力和以用户为中心检查软件质量而对开发者产生一定制约的能力

注:关于这一点,在后来讲到TE招聘的时候,书中有着并不完全一致的论述,P122关于TE招聘是这样描述的:

• 编程知识是必须的,但只限于那些完成前述TE工作需要的水平:修改而非创建代码,设计端到端的用户使用场景的能力等.再加上TE工作本身需要的一些特定的能力,如沟通,系统级别的理解以及用户同理心
• 早期为改善TE面试流程而进行的努力折腾过很多测试人员...

2.如果产品有很大的可能被取消,或者还没有吸引用户使用,或者功能还没有定型,那么测试工作一般都应该由产品的开发人员自己完成

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

• 当前软件的薄弱点在哪里
• 有没有安全,隐私,性能,可靠性,可用性,兼容性,全球化和其他方面的问题
• 主要用户场景是否功能正常
• 这个产品能和其他产品(硬件或者软件)互操作吗
• 当问题发生的时候,是否容易诊断问题所在

TE并不需要自己去解决所有这些问题,但必须保证这些问题被解决掉,TE在测试计划及测试完整性上必须更加系统和周密,重点在真实用户的使用方式和系统级别的体验上

4.如果项目刚刚开始,测试计划是第一优先级.TE职责的一般性描述

• 测试计划和风险分析
• 评审需求,设计,代码和测试
• 探索式测试
• 用户场景
• 编写/执行测试用例
• 使用统计/用户反馈

5.测试人员不该对测试文档过于珍爱,糟糕的测试用例会被抛弃,而最后留下来的是更好的测试用例

6.Google称为的风险分析实际上是基于对软件能力排优先级[p90]

7.影响风险的因素很多,在google我们确定了两个要素:失败频率和影响

• 失败频率:罕见->少见->偶尔->常见
• 影响:最小->一些->较大->最大

8.风险缓解:风险不大可能彻底消除,一种极端的缓解方法是去掉风险最大的组件

• TE更主要的工作是暴露风险.如果不能全测,就测试最重要的,这是一个原则

9.如果有可能的话,我们还会尝试更换不同的测试人员来执行这些场景(用户故事),尽可能地增加不确定和视角

10.Google的TE为一个应用编写大量的测试用例,有些测试用例精确地描述了输入和数据,也有些测试用例的描述是笼统的

11.Android团队是几个比较大的依赖于手工测试的团队之一

12.许多团队在bug到达的速度超过了其修复能力的时候,干脆不进行新功能特性的开发

13.Google的bug管理

• bug数据库完全开放,任何员工能看到任何项目的任一bug
• 所有人都提交bug,即使不属于一个产品团队
• 不存在正式的自顶向下的确定bug优先级的流程,google把此事留给各个团队自主决定

14.测试人员发现bug,花些时间细细品味,这一点很重要.

• 是否在用户可达之路
• 是否还有更多的路径导致相同的bug
• 是否存在可能影响数据和其他应用
• 将bug加入回归测试集,并尽可能把它自动化

15.测试重要的一面是做确认,使程序崩溃并不总是我们的目标.以极端的输入数据来测试软件并使之出错,这很有意思,但更有意思的是用不那么极端的输入,一遍又一遍地测试用以模拟真实的使用场景,确保这些通用条件下,软件的运行不会出错.在面试时候我们会寻找这种正面的测试观

16.TE经常被看着是不怎么写代码的SET.事实上,他们能看到那些整天埋头于代码的人绝不会看到的东西

• 那些能反驳或者质疑规格说明的候选人,往往在工作中有优异的表现
• 我们需要有好奇心,充满热情的工程师
• 我们需要的是愿意持续学习和成长的人

17.经理们有责任去避免开发重复的测试框架,或是过多的投入在小型测试上

18.绩效考评:Googler应该制定比预期能力更高的目标.如果一个人达到了他的所有目标,那说明他的目标还不够高

19.淘汰手工测试用例的指导方针:

• 总是通过的测试,淘汰.在高优先级的测试都来不及做的时候,淘汰低优先级的
• 确保正确理解即将被淘汰的测试用例
• 把释放出来的时间用于测试自动化,高优先级的测试和探索式测试
• 抛弃可能发生过误报或者行为反常的自动化测试

第四章:测试工程经理

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

2.在一个项目中不能过于依赖某些成员,不能仅仅依赖于某位明星测试人员

3.测试工程经理必须努力发现团队里的好方法,好工具,并分享给其他团队

4,最有力的问题是"为什么"

5.选用不合适的人来填充名额永远要比等待合适的人员更糟糕

6.Gmail的测试经验:

• 不要把所有的精力都放在前端
• 使用与应用程序开发语言相同的编程语言来编写测试
• 20%的用例覆盖率80%的使用场景,把这20%自动化而别管剩下的

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

• 我要求所有的测试人员都成为产品专家
• 所有的事情都是价值驱动的
• 探索式测试是深入学习理解一个产品的最佳途径
• 大量重复性的工作不适合手工测试

8.大多数的Google测试人员都非常精通Python,他们开发了测试库PyAuto

9.James:我发现没有比开发工具更能激发测试人员的创造性和提升测试团队的士气了

 

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

1.Google继续区分开发与测试已经不是最好的选择了

• 某种程度上我们已经把测试变得太轻松,把开发养得太懒了
• 测试人员更关注自己的角色,而不是他们的产品.健康组织的一个标志是,人们会说"我为Chrome工作",而不是"我是测试"
• 测试人员往往崇拜测试产物(测试用例,计划,bug报告)胜过软件本身
• 产品经过最严格的测试发布以后,用户依然必然会发现测试中遗漏的问题

2.是谁在做测试并不重要,关键是进行了测试

3.通过互联网交付软件,意味着我们有能力选择部分用户进行发布,响应这部分用户的反馈,并迅速进行更新.开发者和最终用户之间沟通合作的障碍不复存在

4.TE的未来:测试工程师会转型成测试设计,少量的测试设计师快速地规划出测试范围,风险热图和应用程序的 漫游路线.然后,内部试用者,可信赖的测试者,早期用户或者众包测试者提交反馈,由测试设计师来评估覆盖率,计算风险影响,确保发现的问题不断减少

• 他们可以识别需要专业技能的地方,比如安全性,隐私,性能和探索式测试,并安排具有专业技能的人通过众包的形式完成工作
• 他们的工作中没有测试用例的编写,执行,没有实际的测试行为
• 他们会变成测试活动的管理者

5.继续死守已存在数十年之久的测试教条无异于刻舟求剑

 

吐槽:

1. 书中前两章的"注意"部分几乎都是从书中copy的,感觉没必要刻意再标识出来
2. 书中好多处本来应该用"得","地"的地方都写成"的",比如P3"测试不得不变的异常灵活"

最后,虽然只是笔记,但是转载的时候还是要记得注明出处