《Google软件测试之道》章节试读

《Google软件测试之道》的笔记-第2页 - Google软件测试之道读书笔记

Patrick Copeland（Google测试和部署技术架构师）说：
* 一个团队能编写出高质量软件的唯一途径是全体成员共同对质量负责，包括产品经理、设计师、开发人员、测试人员等所有人。
* 达到此目标的最好方式是使测试人员有能力将测试变成代码库的一个实际功能，而测试功能的地位应该与真实客户看到的任何其他功能同等重要。

《Google软件测试之道》的笔记-测试工程师的工作 - 测试工程师的工作

p123
你可能是一个TE
本部分讲述确认自己是否合适TE的若干场景，很有用

《Google软件测试之道》的笔记-第23页 - 2.1 SET的工作

开发团队在寻求测试帮助的时候，有义务让测试人员相信他们的产品是令人兴奋且并充满希望的。在Chrome OS的开发总监给我们介绍他们项目、进度和发布计划时，我们也要求提供当前已有的测试状态、期望的单元测试覆盖率水平、以及明确在发布过程中各自承担的责任。
“让测试人员相信他们的产品是令人兴奋且并充满希望的” 觉得这个很重要啊……

《Google软件测试之道》的笔记-第143页

HGTS：Flash占据了YouTube内容和UI的一大部分，它怎样测试的呢？你们是否有某种通过Selenium测试Flash的秘籍？
Apple：不幸的是，没有。有的只是大量的艰苦劳动。Selenium在某些方面有帮助，因为我们的JavaScript API是暴露的，可以利用Selenium来进行调用测试。我们使用了一个图像比较工具pdiff来测试缩略图、最后一屏（end of screen）的渲染。我们还使用了大量的HTTP流代理来监听流量，这样就可以了解页面变化的更多信息。我们使用As3Unit和FlexUnit来加载播放器来播放不同的视频，以及触发播放器事件。关于验证，我们可以使用这些框架来验证软件的各种状态、完成图像对比。我想说这就象变戏法一样，但实际上是大量代码铺就的。

《Google软件测试之道》的笔记-第8页

SET写代码的目的是可以让SWE测试自己的性能

《Google软件测试之道》的笔记-第36页 - Quality != Test

" Quality cannot be tested in". Quality is not equal to test. Quality is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other.
Google Test Rule NO.1: to merge development and testing so that you cannot do one without the other. build a little and then test it. Build some more and test some more. The key here is who is doing the testing. Quality is more an act of prevention than it is detection. Quality is a development issue, not a testing issue. Testing must be an unavoidable aspect of development, and the marriage of development and testing is where quality is achieved.
在产品开发过程中，开发和测试缺一不可。
Roles we need to figure out: the software engineer (SWE) and the software engineer in test (SET) as well as test engineer (TE). SETs are partners in the SWE codebase, but are more concerned with increasing quality and test coverage than adding new features or increasing performance. SETs write code that allows SWEs to test their features. Test engineers is related to the SET role. but it is a different focus. It is a role that puts testing on behalf of the user first and developer second. TEs spend a good deal of their time writing code in the form of automation scripts and code that drives usage scenarios and even mimics the user. They also organize the testing work of SWEs and SETs, interpret test results, and drive test execution, particularly in the late stages of a project as the push toward release intensifies. TEs are product experts, quality advisers, and analyzers of risk. Many of them write a lot of code; many of them write only a little.
在这里，开发和测试不是根据“是否需要写代码”而区分。而是根据工作性质“开发产品和测试产品”区分。测试开发工程师，不单只是测试功能，还需要研究开发测试工具，完成测试脚本。 而测试工程师，着重于站在用户的角度去测试一件产品。
Unfortunately, we have never actually seen that developers and testers exist as part of the same product team.

《Google软件测试之道》的笔记-第10页 - 1.4 爬走跑

测试发布过程：
金丝雀版本：每日构建的版本，用于排除一些明显不合适的版本，象煤矿井里的金丝雀
开发版本：开发人员日常使用的版本，一般每周发布一个，通过了一系列的测试
测试版本：通过了持续测试的版本。通常是近一个月内最稳当的版本，可以被挑选为内部尝鲜（dog food）。（也可以给一些特殊的外部合作伙伴使用测试）
beta或发布版本：非常稳当的测试版本演变而来，并经历了内部使用和通过了所有质量考核的一个版本，也是对外发布的一个版本。
测试类型：
小型：覆盖单一的代码段，一般运行在完全虚假实现的环境里。 mock等方式。一般都是自动化实现。————可以理解为单元测试、代码测试
中型：覆盖多个模块且重点关注模块之间的交互上，一般运行在虚假实现的环境或真实环境。尽可能的也自动化。----可以理解为模块测试、集成测试
大型： 覆盖任意多的模块，一般运行在真实的环境中，并使用真正的用户数据和资源，或是通过自动化，或是探索性测试，着重用户测。------可以理解为系统测试、发布测试
小型中型--set介入多
中型大型--te介入多

《Google软件测试之道》的笔记-第179页 - 测试工程经理 - 获得项目和人员

工程师只要在当前的项目工作了18个月以上就可以自由离开，而不需要获得当前经理和未来经理的许可负面因素是有经验的员工也可能转到其他团队。这对测试工程经理提出的要求是不能过于依赖于某些成员。不能仅仅依赖于某位明星测试人员，那些促成这位测试人员成为明星的东西，必须要沉淀成可用的工具，或者总结成一套方式，这样就可以帮助其他人也能走上这条成为明星的道路。
对于非明星软件公司，这也是可借鉴的相当聪明和有魄力的管理方式。既然人员变化总是存在可能的，不如积极面对，以免风险发生时，除了加薪许诺外就不知所措。
项目被个别人绑架，不但增加了人员流失带来的风险，项目本身也容易僵化，而个人被项目绑架后，发展也越发有限，从而又增加了流失的可能性。

《Google软件测试之道》的笔记-第76页 - 第三章 TE 测试工程师

一种面向用户的测试角色，用户开发者
职责基本描述：
1、测试计划（ACC特质 组件 能力）和风险分析（两个因素：失败频率【罕见、少见、偶尔、常见】 影响【最小、一些、最大】GTA： google test analytics）
2、评审需求、设计、代码和测试
3、探索式测试
4、用户场景
5、编写测试用例（GTCM google测试用例管家）
6、执行测试用例
7、众包crowdsourcing
8、使用统计
9、用户反馈
google的bug管理流程特殊之处：
1）数据库完全开放
2）所有人都提交bug
3）不存在正式的自顶向下的确定bug优先级的流程
google feedback（百度倾听？？）
TE
能够在已有的代码中寻找错误，迅速理解可能的软件失效模式，但并不关心从头编写这块代码或者做修改
更愿意到slashdot和news.com去阅读其他人的代码
会阅读一份未完成的产品规格说明书，添加剩余部分，完成这份文档
梦想参与的产品带给人们的生活带来巨大的影响
惊骇于某个网站的用户界面，怀疑它怎么可能会有用户
为数据的可视化感到幸福不已
发现自己狠乐意在现实世界里和人交流
心中的领导力：辅助其他工程师的创意
当被询问产品是否可以上线时，你可能会说：我觉得可以了

《Google软件测试之道》的笔记-第9页

看了序和前言，很幽默，很幽默啊！

《Google软件测试之道》的笔记-第178页 - 第四章 测试工程经理

测试经理
作为独立贡献者的一个技术岗位，负责所有支持团队（开发、产品管理、产品发布、文档）之间的联络。需要同时具备SET\TE的技能。
第一 去了解你的产品 第二 知人善用
google员工通常每隔18个月就可以自由选择一个不同的项目，工程经理可以发布空缺职位
确保测试团队有影响力是测试工程经理的责任
每个工程师的个人目标都应该是建立影响力。年度评审和晋升中，影响力是一个非常重要的因素。
创造价值，并持续创造价值
google流程中的致命缺陷：
1）测试成了开发的拐杖
2）开发和测试的组织结构分离，测试人员更关注自己的角色，而不是他们的产品
3）测试人员往往崇拜测试产物胜过软件本身
4）产品经过 最严格的的测试发布以后，用户多大可能能仍然发现测试中遗漏的问题，答案是：几乎必然发现
SET的未来————开发
TE的未来——安全工程师，测试活动的管理者、测试设计师
我们熟知和喜爱的测试方式即将终结。敏捷开发、持续集成、早期用户介入、众包测试、在线软件交付

《Google软件测试之道》的笔记-第128页 - 3.2.6 gogle的测试领导和管理工作

google的管理核心：领导力和洞察力、协商、外部沟通、技术水平、战略规划、招聘和面试、完成团队绩效考核

《Google软件测试之道》的笔记-第16页 - 第二章 SET

提升代码可测试性，提供自动化测试建议，构建持续测试环境
测试认证 类似敏捷CI成熟度模型 分为5级

《Google软件测试之道》的笔记-第141页

在测试上难以自动化的软件，很难成为好的软件。
除此之外，安排好优先级，寻找小成本大回报的自动化项目。一定要记住自动化并不能解决所有问题，尤其是前端项目和设备测试。

《Google软件测试之道》的笔记-第134页 - CHROME 浏览器测试相关章节

质量机器人：Quality Bot
chromebot：利用数据中心的空闲机器周期，在成千上万的虚拟机上启动大量的chrome浏览器，去爬取成百上千万的URL，初期，用于发现崩溃问题非常好使，后期数量减少，启动另外一个DOM。
BITE：Browser Intergrated Tes Enviroment 浏览器集成测试环境，把尽可能多的测试活动、测试工具、测试数据集中到浏览器和云里，并在上下文中呈现相关信息，从而减少分散操作的麻烦，使得测试工作更高效。
chrome OS测试计划：
1 基于风险
2 自动化硬件测试组合
3 支持快速迭代
4 开放测试用例和工具
5 chrome os的主要浏览器平台
6 测试提供数据
7 可测试性和乘数效应
测试团队推动风险分析，达成以下目标：
1 保证产品的质量风险被周知
2 保持测试团队始终仅关注ROI最高的任务
3 保证存在一个质量和数据评估框架——————质量标准？？
chrome的漫游测试（？？ 还不是很理解）
购物漫游
学生漫游
国际长途电话漫游
地标漫游
通宵漫游
公务漫游
危险地带漫游
个性化漫游

《Google软件测试之道》的笔记-第13页

如果能够自动化，并不需要人脑的睿智与直觉来判断，那就应该以自动化的方式实现

《Google软件测试之道》的笔记-第5页 - 1.1 质量不等于测试

质量不是被测试出来的，但未经测试也不可能开发出有质量的软件
测试是开发过程中比不可少的一部分，当开发过程和测试一起携手联姻时，即是质量达成之时（持保留态度）
三种google中的角色：swe 软件开发工程师 set软件测试开发工程师 te测试工程师——————工程生产力团队 EP

《Google软件测试之道》的笔记-第158页

我首先会让我的团队思考，“对被测系统来说，什么是最为重要的东西？”对搜索来说是性能，对新闻来说是时效性，对地图来说是综合性和完整性。每个应用都有其最重要的属性。类似的，对系统基础架构来说，数据完整性对存储最为重要，可扩展性对网络系统最为重要，利用率对任务管理系统最为关键。当你分清了你要测试的特定产品的关键因素以后，就要把你的大部分精力集中在检验系统的核心能力是不是能够满足这些关键属性要求上。
当这些重要的事情搞定以后，再去关心那些简单的事情（用户界面这些锦上添花的东西）。还要关注那些核心的不容易改动的方面（如性能设计），而不对那些很容易修改的方面花费太多精力。如果你过早报告关于字体的bug，我就会担心你是不是没有搞清楚事情的优先次序。

《Google软件测试之道》的笔记-第25页 - 2.1 SET的工作

审阅设计文档时应该有一定的目的性
point：完整性、正确性、一致性、设计、接口与协议、测试

《Google软件测试之道》的笔记-第12页 - 1.5 测试类型

mock对象是指对外面依赖系统的模拟，在运行时刻可以根据假设的需求提供期望的结果。fake对象是一种虚假的实现，内部使用了固定的数据或逻辑，只能返回特定的结果。
对这两个不是很理解……

《Google软件测试之道》的笔记-第6页

质量不等于测试。当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量

《Google软件测试之道》的笔记-第127页 - 测试工程师 - TE的招聘

TE面试的最后一环是看候选人是否具有“Google味儿”。拿自己面试中常问的问题和Google味儿匹配一下:
1. 有好奇心，充满热情的工程师，不满足于简单完成分派的工作。
问题：有没有什么工作或任务，当时因为时间或者其他原因，很遗憾没有做好的？如果现在有机会，你打算如何做？
2. 与现实世界和计算机科学团体紧密联系的人，如参与开源项目，或者通用化自己的工作
以提高复用性的人。
问题：如何获取业界资讯？有没有订阅或者follow的博客，微博，微信或者常去的社区？你开发必备的工具是什么？
3. 与他人和睦相处，合作愉快的人。
问题：你理想的团队什么样？
4. 愿意持续学习和成长的人。
问题：如果现在你有一段空闲时间，你打算学习什么或者读什么书？
5. 带来新鲜思想和经验的人。
问题：针对高级人员，如果让你负责一个项目的技术或者团队，你打算如何做？

《Google软件测试之道》的笔记-第9页 - Google软件测试介绍

质量不等于测试，没有哪个软件质量是测出来的，如果开始就是错的，怎么测试也不能保证质量是正确的。但是，没有测试过的软件质量也是无法保证的，测试时保证软件的重要方法和实践，但不是决定性的以及根本性的。
软件开发的三个角色：
SWE（Software engineer）：软件开发工程师，其关注对象是需求，功能，如何实现它。
SET（Software engineer in Test）：软件测试开发工程师，其关注的对象是SWE以及其生产出的功能代码，单元测试，测试文档等，主要工作是提供测试框架，使SWE的工作更高效。
TE（Test engineer）：测试工程师，其关注对象是最终的系统，从用户的角度去测量软件质量，并验证SWE以及SET的测试。
资深管理者一般都来自产品经理或开发经理，而不是来自测试团队。
测试团队独立存在的部门，是与其他专注领域团队平行的一个组织，其成员以租借的形式进入产品团队。其会根据产品的优先级，复杂度，并与其他产品实际比较之后，来决定分配测试人员。
在Google有一个广泛接受的做法：对于一个测试人员，如果在某个产品中工作满18个月，就可以无理由地自愿转岗到其他产品，当然，这个转岗不是强制性的。

《Google软件测试之道》的笔记-第14页 - 第一章 Google软件测试介绍

通过使用定位点击的验证方式、录制技术等可以把一些手动测试转变成自动化测试，这些自动化测试在每次建立之后都会重复地回归运行，而手动测试更倾向于关注于新功能。
现在所接触到的测试基本都是手动测试，想多学习一点关于自动测试的方法，这里提到的定位点击的验证方式、录制技术，之后找时间多了解一点

《Google软件测试之道》的笔记-第148页

我喜欢由快速迭代和高质量带来的挑战。这两者相互矛盾但又都很重要。我喜欢由快速迭代和高质量带来的挑战。这两者相互矛盾但又都很重要。我喜欢由快速迭代和高质量带来的挑战。这两者相互矛盾但又都很重要。