展开全部

主编推荐语

从内部视角告诉你,这个世界上知名的互联网公司是如何应对21世纪软件测试的独特挑战。

内容简介

每天,Google都要测试和发布数百万个源文件、亿万行的代码。数以亿计的构建动作会触发几百万次的自动化测试,并在好几十万个浏览器实例上执行。面对这些看似不可能完成的任务,谷歌是如何测试的呢?

《Google软件测试之道》抓住了Google做测试的本质,抓住了Google测试这个时代最复杂软件的精华,描述了测试解决方案,揭示了测试架构是如何设计、实现和运行的,介绍了软件测试工程师的角色;讲解了技术测试人员应该具有的技术技能;阐述了测试工程师在产品生命周期中的职责;讲述了测试管理及在Google的测试历史或在主要产品上发挥了重要作用的工程师的访谈,这对那些试图建立类似Google的测试流程或团队的人受益很大。
  
最后,《Google软件测试之道》还介绍了作者对于Google测试如何继续演进的见解、Google乃至整个业界的测试方向的一些预言,相信很多读者都会感受到其中的洞察力,甚至感到震惊。本书可以作为任何从事软件测试人员到达目标的指南。
  
《Google软件测试之道》适合开发人员、测试人员、测试管理人员使用,也适合大中专院校相关专业师生的学习用书,以及培训学校的教材。

目录

  • 版权信息
  • 版权声明
  • 内容提要
  • 对本书的赞誉
  • 致中国读者
  • 译者序
  • 《Google软件测试之道》业界热评
  • 关于这本书
  • 致谢
  • 前言
  • 第1章 Google软件测试介绍
  • 1.1 质量不等于测试
  • 1.2 角色
  • 1.2.1 软件开发工程师(SWE)
  • 1.2.2 软件测试开发工程师(SET)
  • 1.2.3 测试工程师(TE)
  • 1.3 组织结构
  • 1.4 爬、走、跑
  • 1.5 测试类型
  • 第2章 软件测试开发工程师
  • 2.1 SET的工作
  • 2.1.1 开发和测试流程
  • 2.1.2 SET究竟是谁
  • 2.1.3 项目的早期阶段
  • 2.1.4 团队结构
  • 2.1.5 设计文档
  • 2.1.6 接口与协议
  • 2.1.7 自动化计划
  • 2.1.8 可测试性
  • 2.1.9 SET的工作流程:一个实例
  • 2.1.10 测试执行
  • 2.1.11 测试大小的定义
  • 2.1.12 测试规模在共享测试平台中的使用
  • 2.1.13 测试规模的益处
  • 2.1.14 测试运行要求
  • 2.2 测试认证
  • 2.2.1 与测试认证计划创始人的访谈
  • 2.3 SET的招聘
  • 2.4 与工具开发工程师Ted Mao的访谈
  • 2.5 与Web Driver的创建者Simon Stewart的对话
  • 第3章 测试工程师
  • 3.1 一种面向用户的测试角色
  • 3.2 测试工程师的工作
  • 3.2.1 测试计划
  • 3.2.2 风险
  • 3.2.3 测试用例的生命周期
  • 3.2.4 bug的生命周期
  • 3.2.5 TE的招聘
  • 3.2.6 Google的测试领导和管理工作
  • 3.2.7 维护模式的测试(Maintenance Mode Testing)
  • 3.2.8 质量机器人(Quality Bot)实验
  • 3.2.9 BITE实验
  • 3.2.10 Google Test Analytics
  • 3.2.11 零成本测试流程
  • 3.2.12 外部供应商
  • 3.3 与Google Docs测试工程师林赛·韦伯斯特(Lindsay Webster)的访谈
  • 3.4 与YouTube测试工程师安普·周(Apple Chow)的访谈
  • 第4章 测试工程经理
  • 4.1 测试工程经理的工作
  • 4.2 获得项目和人员
  • 4.3 影响力
  • 4.4 Gmail测试工程经理Ankit Mehta的访谈
  • 4.5 Android测试工程经理Hung Dang的访谈
  • 4.6 Chrome测试工程经理Joel Hynoski的访谈
  • 4.7 测试总监
  • 4.8 搜索和地理信息测试总监Shelton Mar的访谈
  • 4.9 工程工具总监Ashish Kumar的访谈
  • 4.10 印度Google测试总监SujaySahni访谈
  • 4.11 工程经理Brad Green访谈
  • 4.12 James Whittaker访谈
  • 第5章 Google软件测试改进
  • 5.1 Google流程中的致命缺陷
  • 5.2 SET的未来
  • 5.3 TE的未来
  • 5.4 测试总监和经理的未来
  • 5.5 未来的测试基础设施
  • 5.6 结论
  • 附录A Chrome OS测试计划
  • A.1 测试主题概述
  • A.2 风险分析
  • A.3 每次构建版本的基线测试
  • A.4 最新可测试版本(Last Known Good,LKG)的每日测试
  • A.5 发布版本测试
  • A.6 手工测试与自动化测试
  • A.7 开发和测试的质量关注点
  • A.8 发布通道
  • A.9 用户输入
  • A.10 测试用例库
  • A.11 测试仪表盘
  • A.12 虚拟化
  • A.13 性能
  • A.14 压力、长时运行和稳定性测试
  • A.15 测试执行框架(Autotest)
  • A.16 OEM厂商
  • A.17 硬件实验田
  • A.18 端到端测试自动化集群
  • A.19 测试浏览器的应用管理器
  • A.20 浏览器的可测试性
  • A.21 硬件
  • A.22 时间线
  • A.23 主要的测试驱动力
  • A.24 相关文档
  • 附录B Chrome的漫游测试
  • B.1 购物漫游
  • B.2 学生漫游
  • 建议的测试方面
  • B.3 国际长途电话漫游
  • 建议的测试方面
  • B.4 地标漫游
  • 建议的测试方面
  • B.5 通宵漫游
  • 建议的测试方面
  • B.6 公务漫游测试
  • Chrome里的工具
  • B.7 危险地带漫游
  • Chrome OS中的危险地带漫游测试
  • B.8 个性化漫游
  • 定制Chrome的方式
  • 附录C 有关工具和代码的博客文章
  • C.1 使用BITE从bug和冗余的工作中解脱出来
  • C.2 发布QualityBot
  • C.3 RPF:Google的录制回放框架
  • C.4 Google测试分析系统(Google Test Analytics)——现在开源了
  • 附录D 术语表
  • 欢迎来到异步社区!
  • 异步社区的来历
  • 社区里都有什么?
  • 购买图书
  • 下载资源
  • 与作译者互动
  • 灵活优惠的购书
  • 纸电图书组合购买
  • 社区里还可以做什么?
  • 提交勘误
  • 写作
  • 会议活动早知道
  • 加入异步
展开全部

评分及书评

4.4
5个评分
  • 用户头像
    给这本书评了
    4.0
    从测试角度看系统

    有启发的 7 句话:1. 质量不等于测试 2. 经验法则,即 70/20/10 原则:70% 是小型测试,20% 是中型测试,10% 是大型测试 3. 如果你不能在几分钟内列举出特质,说明你还没有足够的理解你的产品,还不能有效地测试它 4. 资源越少,目标越明了 5. 晋升取决于员工对项目产生的影响力 6. 探索式测试是深入学习理解一个产品的最佳途径 7. 测试的价值是在于测试的动作,而不是测试产物重点整理 :1. 质量不等于测试。当你把开发过程和测试放到一起,就像在搅拌机里混合搅拌那样,直到不能区分彼此的时候,你就得到了质量 2. 测试是开发过程中必不可少的一部分,当开发过程和测试一起携手联姻时,即是质量达成之时 3. 软件测试开发工程师(SET):SET SWE 在代码库上的合作伙伴,与增加功能性代码或提高性能的代码的 SWE 相比,SET 更加关注于质量的提升和测试覆盖率的增加。SET 写代码的目的是可以让 SWE 测试自己的功能 4. 测试工程师(TE):TE 把用户放在第一位来思考。TE 组织整体质量实践,分析解释测试运行结果,驱动测试执行,构建端到端的自动化测试 5. 资深管理者一般都来自产品经理或开发经理,而不是来自于测试团队。在产品发布时,优先考虑的是功能是否完整和易用性方面是否足够简单,却很少考虑质量。作为同一个团队,测试总是在为开发让路 6.Google 经常在最初的版本里只包含最基本的可用功能,然后在后继的快速迭代的过程中得到内部和外部用户的反馈,而且在每次迭代的过程中都非常注重质量。一个产品在发布给用户使用之前,一般都要经历金丝雀版本、开发版本、测试版本、beta 或正式发布版本 7. 在理想情况下,一个完美的开发过程是怎样进行的呢?测试先行,在一行代码都没有真正编写之前,一个开发人员就会去思考如何测试他即将编写的代码。他会设计一些边界场景的测试用例,数据取值范围从极大到极小、导致循环语句超出限制范围的情况,另外还会考虑很多其他的极端情况。这些测试代码会作为产品代码的一部分,以自检代码或单元测试代码的形式与功能代码存储在一起。对于此种类型的测试,最合适且最有资格去做的人,其实就是编写功能代码的人 8. 编写功能代码和编写测试代码在思维方式上有着很大的不同 9."百分之二十的贡献"(译注:"百分之二十时间" 是指 Googler 称为的 "业余项目"。这并不是一个炒作的概念,而是官方真正存在的,允许所有 Googler 每周投入一天时间在他的日常工作之外的项目上。每周四天工作用来赚取薪水,剩下一天用以试验和创新 10. Google 的四大主要开发语言:C++JavaPythonJavaScript11. Google 在平台方面有特定的目标,就是保持简单且统一开发工作机和生产环境的机器都保持统一的 Linux 发行版一套集中控制的通用核心库一套统一的通用代码、构建和测试基础设施;每个核心语言只有一个编译器与语言无关的通用打包规范文化上对这些共享资源的维护表示尊重且有激励 12. 小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告;大中型测试会带来整体产品质量和数据验证 13. 经验法则,即 70/20/10 原则:70% 是小型测试,20% 是中型测试,10% 是大型测试。如果一个项目是面向用户的,拥有较高的集成度,或者用户接口比较复杂,他们就应该有更多的中型和大型测试;如果是基础平台或者面向数据的项目,例如索引或网络爬虫,则最好有大量的小型测试,中型测试和大型测试的数量要求会少很多 14.SET 的面试重点在考察候选人如何思索问题的解决方案,而不是解决方案本身的实现上有多么高雅 15.TE 在进入产品时,需要考虑问题:当前软件的薄弱点在哪里?有没有安全、隐私、性能、可靠性、可用性、兼容性、全球化和其他方面的问题?主要用户场景是否功能正常?对于全世界不同国家的用户都是这样吗?这个产品能与其他产品(软件和硬件)互操作吗?当发生问题的时候,是否容易诊断问题所在?16. 如果你不能在几分钟内列举出特质,说明你还没有足够的理解你的产品,还不能有效地测试它 17. 在软件测试中,按照一个常识性的过程来理解风险,参考的因素:哪些事件需要担心?这些事件发生的可能性有多大?一旦发生,对公司产生多大影响?一旦发生,对客户产生多大影响?产品具备什么缓解措施?这些缓解措施有多大可能会失败?处理这些失败的成本有哪些?恢复过程有多困难?事件是一次性问题,还是会再次发生?18. 测试完整的页面并把错误定位到元素的级别,而非页面级别 19. Google 名言:资源越少,目标越明了 20. Google 允许工程师尝试新鲜的想法,只要他们知道如何衡量成功 21. 想成为优秀的测试工程经理:了解你的产品知人善用 22. 晋升取决于员工对项目产生的影响力 23. 团队打算做太多的东西的时候,就好像你要同时做五件事情,但是每件只能完成 80% 的时候,我就会要求他们退回来重新安排优先级。把你需要做的事情减少到两到三件,但都能完成到 100% 24. 保持技术敏锐度并像工程师一样:在与开发工程师和测试开发工程师团队沟通的过程中,想做一些技术工作,就必须尽量排除管理方面带来的干扰 25. 探索式测试是深入学习理解一个产品的最佳途径 26. 收纳一个工具到中央工具库里的标准:必须对生产力有极大的提升作用对大部分 Google 工程师来说都是适用的 27. 测试人员往往崇拜测试产物(test artifact)胜过软件本身。测试的价值是在于测试的动作,而不是测试产物

      转发
      评论
      用户头像
      给这本书评了
      5.0
      测试感悟

      读完这本书让我受益非浅,对测试领域有了更深的认识,我们最终服务的是产品,而不是局限于自己目前所做的一部分,从开始产品的需求分析,制定各个部门的产品的计划,测试初期是完全吃透产品需求说明书以至于后续制定测试计划,提取要点,编写测试用例,提交缺陷,回归等一系列流程,中途不断跟研发、产品确认需求等,以及模拟用户场景进行测试。最终将产品交付于客户,后续的敏捷迭代等需要亲力亲为。而读完此书我深刻体会到测试行业必不缺少,敢于挑战敢于创新,一定会有回报 ,这本书讲究如何做好测试的思维以及做好测试软件开发的思维

        转发
        评论

      出版方

      人民邮电出版社

      人民邮电出版社是工业和信息化部主管的大型专业出版社,成立于1953年10月1日。人民邮电出版社坚持“立足信息产业、面向现代社会、传播科学知识、服务科教兴国”,致力于通信、计算机、电子技术、教材、少儿、经管、摄影、集邮、旅游、心理学等领域的专业图书出版。