请裁剪图片
10人推荐
图书: Google软件测试之道
选择文件
作者:
出版社:
简介: 《google软件测试之道》从内部视角告诉你这个世界上知名的互联网公司是如何应对21世纪软件测试的独特挑战的。《google软件测试之道》抓住了google做测试的本质,抓住了google测试这个时代最复杂软件的精华。《google软件测试之道》描述了测试解决方案,揭示了测试架构是如何设计、实现和运行的,介绍了软件测试工程师的角色;讲解了技术测试人员应该具有的技术技能;阐述了测试工程师在产品生命周期中的职责;讲述了测试管理及在google的测试历史或在主要产品上发挥了重要作用的工程师的访谈,这对那些试图建立类似google的测试流程或团队的人受益很大。 展示全部
收起
简介:
收藏
8281
推荐
推荐语 10
测试需要很强的逻辑思维。
2016-06-16 18:19
李金文前端 冰冻三尺,非一日之寒
关于Google软件测试的图书,有空可以学习下。
2016-05-20 14:08
很经典的图书,提到的很多测试细节适合去实践体会~
2016-05-18 19:08
Ren 地球第一特殊群体
已经翻过几遍的测试书籍,每次读都有很多新的认知,国外的测试思想与方法还是与国内有差别的,不过现在国内的测试环境和方法越来越成熟,测试者行业也更加受重视,从某种程序来讲,测试可以说是最接近项目体验的一个环节。在测试过程不断发现新问题,去帮助优化项目。
2016-05-03 10:25
Defense 仰望星空,脚踏实地
测试会成为项目进展的重要环节,其系统性、缜密性是直接借鉴的,从事测试的朋友可学习下。
2016-04-28 21:32
不错的书,从测试集合到具体的测试方法,讲解得很详细,涵盖了主流互联网公司的测试流程。
2016-04-28 21:28
小海 走自己的路
不得不承认,google软件测试的很多思想与敏捷开发都有相同之处,特别是针对项目的质量审核上,把控得是非常严格的,其中关于测试方式的介绍还是值得去学习。
2016-04-01 18:32
寒夜孤星 专注IT运维,拒绝熬夜
算是行业内比较经典的一本书,谷歌在测试这方面一直都很规范的流程。其中提到的黑盒测试的整体流程与用户体验测试,都是很值得学习的。
2016-03-04 17:14
Hatu 徘徊于移动互联网之间
这本书是几年前看的,年底去翻翻,依旧可以找到很多经典的地方。谷歌在软件测试中分的层次与规范化的流程,都值得学习,更重要的是测试思想的提认知。
2016-02-02 10:17
Timekr 沉着冷静
这本书是公认的测试经典图书,国内很多优秀测试人员都了解过。作者是谷歌工程总监,主要介绍了谷歌产品测试的整体流程,以及作者对测试方向的一些看法。包括测试人员在互联网团队的运作模式都有重要说明。值得说明的是,书中最后一部分穿插了很多访谈,阐述了谷歌一线的一些测试经验和方法。不过也提出了谷歌测试的缺陷,可见也并没有完美的测试,都是在不断改进中.
2015-11-24 10:34
添加知识点
知识点 5
第1章 google软件测试介绍 1  1.1 质量不等于测试 5  1.2 角色 6  1.2.1 软件开发工程师(swe) 7  1.2.2 软件测试开发工程师(set) 7  1.2.3 测试工程师(te) 8  1.3 组织结构 9  1.4 爬、走、跑 10  1.5 测试类型 12第2章... 展示全部
收起
第1章 google软件测试介绍 1
  1.1 质量不等于测试 5
  1.2 角色 6
  1.2.1 软件开发工程师(swe) 7
  1.2.2 软件测试开发工程师(set) 7
  1.2.3 测试工程师(te) 8
  1.3 组织结构 9
  1.4 爬、走、跑 10
  1.5 测试类型 12
第2章 软件测试开发工程师 15
  2.1 set的工作 17
  2.1.1 开发和测试流程 17
  2.1.2 set究竟是谁 21
  2.1.3 项目的早期阶段 22
  2.1.4 团队结构 23
  2.1.5 设计文档 24
  2.1.6 接口与协议 26
  2.1.7 自动化计划 27
  2.1.8 可测试性 28
  .2.1.9 set的工作流程:一个实例 31
  2.1.10 测试执行 41
  2.1.11 测试大小的定义 42
  2.1.12 测试规模在共享测试平台中的使用 45
  2.1.13 测试规模的益处 46
  2.1.14 测试运行要求 48
  2.2 测试认证 54
  2.3 set的招聘 62
  2.4 与工具开发工程师ted mao的访谈 68
  2.5 与web driver的创建者simon stewart的对话 70
第3章 测试工程师 75
  3.1 一种面向用户的测试角色 75
  3.2 测试工程师的工作 76
  3.2.1 测试计划 79
  3.2.2 风险 94
  3.2.3 测试用例的生命周期 104
  3.2.4 bug的生命周期 109
  3.2.5 te的招聘 121
  3.2.6 google的测试领导和管理工作 128
  3.2.7 维护模式的测试(maintenance mode testing) 131
  3.2.8 质量机器人(quality bot)实验 134
  3.2.9 bite实验 145
  3.2.10 google test analytics 154
  3.2.11 零成本测试流程 159
  3.2.12 外部供应商 163
  3.3 与google docs测试工程师林赛·韦伯斯特(lindsay webster)的访谈 165
  3.4 与youtube测试工程师安普·周(apple chow)的访谈 170
第4章 测试工程经理 177
  4.1 测试工程经理的工作 177
  4.2 获得项目和人员 179
  4.3 影响力 180
  4.4 gmail测试工程经理ankit mehta的访谈 182
  4.5 android测试工程经理hung dang的访谈 188
  4.6 chrome测试工程经理joel hynoski的访谈 192
  4.7 测试总监 197
  4.8 搜索和地理信息测试总监shelton mar的访谈 198
  4.9 工程工具总监ashish kumar的访谈 201
  4.10 印度google测试总监sujaysahni访谈 205
  4.11 工程经理brad green访谈 209
  4.12 james whittaker访谈 212
第5章 google软件测试改进 219
  5.1 google流程中的致命缺陷 219
  5.2 set的未来 221
  5.3 te的未来 222
  5.4 测试总监和经理的未来 223
  5.5 未来的测试基础设施 224
  5.6 结论 225
附录a chrome os测试计划 227
  a.1 测试主题概述 227
  a.2 风险分析 228
  a.3 每次构建版本的基线测试 228
  a.4 最新可测试版本(last known good,lkg)的每日测试 229
  a.5 发布版本测试 229
  a.6 手工测试与自动化测试 229
  a.7 开发和测试的质量关注点 230
  a.8 发布通道 230
  a.9 用户输入 230
  a.10 测试用例库 231
  a.11 测试仪表盘 231
  a.12 虚拟化 231
  a.13 性能 231
  a.14 压力、长时运行和稳定性测试 231
  a.15 测试执行框架(autotest) 232
  a.16 oem厂商 232
  a.17 硬件实验田 232
  a.18 端到端测试自动化集群 232
  a.19 测试浏览器的应用管理器 232
  a.20 浏览器的可测试性 233
  a.21 硬件 234
  a.22 时间线 234
  a.23 主要的测试驱动力 236

  a.24 相关文档 236

附录b chrome的漫游测试 239

  b.1 购物漫游 239
  b.2 学生漫游 240
  b.3 国际长途电话漫游 241
  b.4 地标漫游 241
  b.5 通宵漫游 242
  b.6 公务漫游测试 243
  b.7 危险地带漫游 243
  b.8 个性化漫游 244


附录c 有关工具和代码的博客文章 245

  c.1 使用bite从bug和冗余的工作中解脱出来 245
  c.2 发布qualitybot 247
  c.3 rpf:google的录制回放框架 249
  c.4 google测试分析系统(google test analytics)——现在开源了 251


附录d 术语表 257

收起
22个月前 大纲 499次浏览/0评论
测试计划是整个测试流程最为关键的一步,也是在正式测试之前首先要制定的工作。它的好处是显而易见的,通过完整的测试计划使得项目审核更加的规范,以此来达到高质量的项目版本。我们可以看到,对于项目早期而言,测试人员的工作通常是编写各种文档类的工作,并没有进入具体的开发,这和国内的测试环境也是一致的。这种文档... 展示全部
收起

测试计划是整个测试流程最为关键的一步,也是在正式测试之前首先要制定的工作。它的好处是显而易见的,通过完整的测试计划使得项目审核更加的规范,以此来达到高质量的项目版本。

我们可以看到,对于项目早期而言,测试人员的工作通常是编写各种文档类的工作,并没有进入具体的开发,这和国内的测试环境也是一致的。这种文档的起步绝大多数是根据需求文档来定义,如测试用例的制定、测试不同环境的考虑都将纳入计划当中。

可能多数人认为测试只是普通的检测bug,查找问题。实际上,规范的测试会避免很多项目的漏洞,至少在发布之前,它是可以通过一套流出化的程序指出程序错误的地方。

图示是谷歌测试流程的基本部分,可以看出测试的严谨性。不过这种测试方式更主要的是针对程序层面,也就是以流程化的角度去看待。而实际上,很多测试人员不仅担当程序的测试,也常常会以用户的角度去测试,也就是真实的使用场景。这种方式也许是无规则的,但却在某些方面得到新的优化方式。

收起
22个月前 测试流程 ·计划 | 第 3 章 572次浏览/0评论
项目版本指的是项目从起步到最终正式上线所涉及的阶段,在每个阶段中,都会有相应的版本定义。谷歌测试流程关于这篇重点介绍了版本的定义问题,规则如下:金丝雀版本:指的是每日需要构建的版本,目的是为了排除不适宜的版本,从每日的构建版本发现项目的流程问题,一般来说,此版本的发布者只有工程师才具备,要求比较严格... 展示全部
收起

项目版本指的是项目从起步到最终正式上线所涉及的阶段,在每个阶段中,都会有相应的版本定义。

谷歌测试流程关于这篇重点介绍了版本的定义问题,规则如下:

金丝雀版本

指的是每日需要构建的版本,目的是为了排除不适宜的版本,从每日的构建版本发现项目的流程问题,一般来说,此版本的发布者只有工程师才具备,要求比较严格。

开发版本

针对开发人员经常使用的版本,特点就是具备一定的项目功能,而且这种功能是经过测试的。工程师会经常使用这个版本,目的是为了更好的检测项目问题,保证它满足正常的业务需求。需要指出的是开发版本不能满足正常的项目需求,则会返回到金丝雀版本。

(备注:在谷歌项目流程中,开发版本一般为一周)

测试版本

测试版本可以看作为开发版本质量更高一层的版本,在这个阶段内,测试版本已经基本具备完善的功能使用与体验,也可提前被内外部成员使用该项目版本,具有良好的稳定性。

beta或发布版本

由测试版本演变而来,并经过不断使用,当达到所有质量考核后,即可发布,也常常被称为对外发布的第一个版本。


可以看出,从项目的实施一直到最终的上线,的确是经过了相对完善的流程。相对国内的测试环境而言,可能只存在于测试版本与上线版本。不过好的流程可以借鉴,毕竟测试始终是非常重要的环节。



收起
22个月前 测试 ·项目流程 | 第 2 章 639次浏览/0评论
在这个知识点中,主要阐述下谷歌的整体测试类型。其测试类型从层级上分为:小型测试、中型测试、大型测试。这种现象可能会令同行感到诧异(大多数还是集成测试、系统测试等以属性来开始分类,只能说各有优劣)。这种层次的关系其实是从整体的范畴进行定义的。可能多数朋友会认为这种测试顺序与高低有关,其实不然,的确是根... 展示全部
收起

在这个知识点中,主要阐述下谷歌的整体测试类型。


其测试类型从层级上分为:小型测试中型测试大型测试


这种现象可能会令同行感到诧异(大多数还是集成测试、系统测试等以属性来开始分类,只能说各有优劣)。这种层次的关系其实是从整体的范畴进行定义的。可能多数朋友会认为这种测试顺序与高低有关,其实不然,的确是根据每种测试方法的特定而定义的,下面会重点说明。


小型测试


这是原书中对小型测试的定义。可以看出小型测试的几个特点:时间短、自动化(并非所有)。从这种维度来看,与单元测试有着相近的属性,都是为了快速验证某个功能是否达到效果而处理的。


中型测试

中型测试会注重业务之间的交互。对于测试刚入门的朋友,大多数做的可能是小型测试,但是往往遇到的问题是往往单独测试某个节点没有问题,但当测试并行模块或有关系的业务时,则会出现不同的测试结果,这种现象也很正常。因此在做测试用例的时候可以采用并行的方式处理,而非单一地测试某种业务模块。


大型测试

对于大型测试而言,其判断方式为真实的用户场景,采用的数据也相对真实。特点一般是“耗时长、业务多、人多多”,因为的确是从整体的角度去测试,所有不可避免的涉及多种测试人员。它的目的也很好理解,既测试的结果是否与真实的用户目标一致,从某种程度上而言完全是以用户的角度去整体看待。这确实也是大型测试的重点。

收起
22个月前 测试类型 ·用户目标 | 第 1 章 444次浏览/0评论
在项目的发布前期,软件质量的确占着举足轻重的位置。对于项目质量而言,它更注重的是自身能被正常的使用,至少从整体的流程上不出现大的问题。然而这种质量的检测本身就是一件比较棘手的事情,而随着项目的实施,很多人会认为质量是被经过测试出来的。实际上,质量与测试是紧密结合的关系,好比工程师开发出一套系统,本身... 展示全部
收起

在项目的发布前期,软件质量的确占着举足轻重的位置。对于项目质量而言,它更注重的是自身能被正常的使用,至少从整体的流程上不出现大的问题。然而这种质量的检测本身就是一件比较棘手的事情,而随着项目的实施,很多人会认为质量是被经过测试出来的。

实际上,质量与测试是紧密结合的关系,好比工程师开发出一套系统,本身就会对软件的质量进行负责,而测试人员更多的是进行检测,不会对质量本身就关联的职责,是相辅相成的。

在谷歌的测试流程当中,以质量与测试为基点,概述了整体的测试流程,即使现在看来,这种流程也是非常值得借鉴的。写一套代码测试该项,完成更多的代码做更多的测试,循循渐进。而并非整体开发完再进行测试。这种好处是显而易见的,一方面,短暂的测试流程逐步积累会更早发现问题,另外一方面,不会因为后期的全局测试导致质量把关不到位。

事实上,国内的测试环境还是属于起步阶段,很多流程并不是那么规范,但依旧可以摸索出更为合理的方式。

总之,测试是项目开发中必不可少的一项,就像原文讲的那样:“当开发过程与测试一起联姻时,即是质量达成之时”。


 

收起
22个月前 测试 ·软件质量 | 第 1 章 475次浏览/0评论
扩展阅读 1
添加扩展
提交
取消
作者:
0/100
123

确定
取消
用户名不正确!
下次自动登录
添加到资源集
+创建资源集
取消
确定
新建资源集 ×
标题:
描述:

返回
创建
×
创建资源集目前仅对内测用户开放,点击获取内测权限。