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

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

 (2013-11-13 12:55:46)

转载▼

分类： 笔记

最近看了《Google软件测试之道》

喜欢google是从喜欢他们涂鸦开始的，其他的有搜索、chrome浏览器、gmail邮箱，还有日历等。当看到他们制作有趣的涂鸦时，总是禁不住想：是什么样的脑袋才会想出这许多种有趣的表达方式？能想出这些涂鸦的他们，工作氛围是怎么样的呢？

知道这本书，是从同事微博上。然后看到了淘宝测试的推荐，同时也看到了测试管理层的推荐语。很早前有接触过淘宝的测试，大体上了解过他们的测试流程。也听闻过他们那段时间在学习编程，做接口测试、自动化测试等等。所以很好奇，他们所推崇的测试是怎么样的呢？

自己对于测试职业的发展有点迷茫，再加上上述原因，这本书正是我所需要的。

原书为《How Google Tests Software》,出版于2012.4.2；看的是中文版，出版于2013.10。

//最初的内容，来自James Whittaker发表在Google Testing Blog上“How Google Test Software”系列文章。

书的内容主要是讲了Google测试团队中的角色分类，及各角色的工作内容，还包括对Google有重要影响的测试人士的访谈，以及Google测试团队的发展历程。

Google的测试团队的角色有：软件测试开发工程师(SET,Software Engineer in Test)、测试工程师(TE,Test Engineer)、测试工程经理(TEM,Test Engineer Manager)，往上还有测试总监等。在Google做测试的，不仅只限于测试团队，还包括软件开发工程师(SWE,Software Engineer)。在Google内，在“质量保证是由项目组里所有人共同责任”上，达成共识，并在实际研发过程中已经实现了项目成员间的有效合作。

 

各角色的工作(以下为摘录)

  Google的SWE，就是功能开发人员，负责客户使用的功能模块开发，他们编写功能代码及这些功能的单元测试代码。

　Google的SET，就是测试开发人员，部分职责是在单元测试方面给予开发人员支持，另一部分职责是为开发人员提供测试框架，以方便他们编写中小型测试，用以进行更多质量相关的测试工作。

  Google的TE，就是用户开发人员，负责从用户的角度来思考质量方面各种问题。从开发角度来看，他们编写用户使用场景方面的自动化用例代码；从产品角度看，他们评估整体测试覆盖度，并验证其他工程师角色在测试方面合作的有效性。

 

 

TE的工作(以下为摘录)

TE以对某种特定的产品最适合的方式，来发现软件中风险最大的地方，并尝试减少或消除它。如果需要做SET的工作，TE就去做；如果需要代码审查，那就只管去做。如果缺少测试工具，那就花一些时间在上面。

   接下来，同一个人还会在项目的其他时段去领导探索式测试，或者管理内部试用版的测试工作。在不同项目阶段，SET和TE的重点不同，早期的工作涉及更多的面向SET的任务，而项目后期才是面向TE的任务。还有一些情况是TE的个人选择，在不同的角色间切换。

 

   TE在进入产品时，SWE和SET已经在测试技术和质量方面做了大量的工作，这些可以作为TE的工作起点，同时需要考虑以下一些问题：

l  当前软件的薄弱点在哪里？

l  有没有安全、隐私、性能、可靠性、可用性、兼容性、全球化和其他方面的问题？

l  主要用户场景是否功能正常？对于全世界不同国家的用户都是这样吗？

l  这个产品能与其他(软件和硬件)互操作吗？

l  当发生问题的时候，是否容易诊断问题所在？

当然这是一个不完全列表。所有这些加起来，构成发布待评估软件的风险概要。TE并不需要自己去解决所有这些问题，但必须保证这些问题被解决掉，他们可以请其他人帮忙评估还有多少工作需要去做。TE的根本使命是保护用户和业务的利益，使之不受到糟糕的设计、令人困惑的用户体验、功能bug、安全和隐私等问题的困扰。在Google，TE是一个团队中全职地负责从整体角度发现产品或服务弱点的唯一角色。因此，与SET相比，TE的工作并不是那么确定。TE会介入项目的各个阶段：从产品的构思阶段到第8个版本，甚至是照看一个已经下线的项目。一个TE同时参与几个项目也很常见，尤其是那些具备安全、隐私或全球化等专门技能的TE。

显然，在不同的项目中，TE的工作内容也会有较大的不同。一些TE会在编码方面投入较多的时间，但主要是写中到大型的测试(如端到端的用户场景)而非小型测试。其他一些TE会检查代码和系统设计以确定失效模式，并寻找导致失效的错误路径。在这种情况下，TE可能会去修改代码，但这与从头编写代码是不同的。TE在测试计划及测试完整性上必须更加系统和周密，重点在真实用户的使用方式和系统级别的体验上。TE擅长发现需求中的模糊之处，分析沟通不明确的问题。

成功的TE游走于这些微妙且敏感的地方，有时候还要与个性很强的开发和产品人员打交道。一旦找到薄弱点，TE就会通过测试使软件出错，然后与开发、产品、SET一起推动解决这些bug.

 

TE的工作经常需要去打破常规流程。TE可以在任何时间进入项目，必须迅速评估项目、代码、设计和用户的当前状态，然后决定首要的关注点。如果项目刚刚开始，测试计划是第一优先级。有时，TE在产品后期被拉进来帮助评估项目是否可以发布，或者在beta版本发布之前确认还有哪些主要的问题。当TE进入了一个新被收购的应用或缺少相关应用经验的时候，他们经常会先去做一些不怎么需要计划的探索性测试。有时，项目已经很久没有发布了，只是需要去做一些修饰、安全补丁或界面更新，这需要迥然不同的方法。

在Google,TE需要在不同的项目中做不同的事情。我们经常将TE的工作描述为“从中间开始”，因为TE必须保持足够的灵活，能够迅速融入一个产品团队的文化和现状。如果做测试计划已经来不及了，那就干脆不做了。如果一个项目最需要的是测试，那就做一个简单够用的指导性计划。

以下是关于TE职责的一般性描述：

l  测试计划和风险分析

l  评审需求、设计、代码和测试

l  探索性测试

l  用户场景

l  编写测试用例

l  执行测试用例

l  众包(crowdsourcing,是互联网带来的新的生产组织形式。一个公司或机构把过去由员工执行的工作任务，以自由自愿的形式外包给非特定的(通常是大型的)大众网络的做法)

l  使用统计

l  用户反馈

 -----------------------------------题----外----话-----------------------------------------

 

一本书看下来，对于Google测试团队的每个角色都要求会编码这点，因为很早前就听说过，所以没有感到不解。令我印象深刻的，是Google的一种测试计划的替代方法—ACC(Attribute Component Capability,即特质、组件、能力)分析。

----------------------------------------------------------------------------------------------

特质是系统的形容词，代表了产品的品质和特色，是区别于竞争对手的关键，也是人们选择你的产品而不是竞争对手的产品的原因。

组件是构成待建系统的模块，是使一个软件之所以如此的核心要素和代码块。

能力是系统的动词，代表着系统在用户指令之下完成的动作。它们是对输入的响应、对查询的应答以及代表用户完成的活动。

ACC的指导原则如下：

l  避免散漫的文字

l  不必推销

l  简洁。测试计划并没有长度的要求。计划的大小与测试问题的规模有关。

l  不要把不重要的、无法执行的东西放进测试计划。相关人员毫不关心的东西，就一个词也不要出现。

l  渐进式的描述。测试计划的每个部分应该是前面部分的延伸，以便读者可以随时停止阅读并且对产品的功能有一个初步的印象。

l  指导计划者的思路。一个好的计划过程能帮助计划者思考产品功能及其测试需求，从而有条不紊地从高层概念过渡到可以被直接实现的低层细节。

l  最终结果应该是测试用例。在计划完成的时候，它不仅要清楚地描述要做什么样的测试，并且还可以清楚地指导测试用例的编写。

 

示例：确定Google+的特质、组件和能力(简略版)

l  Google+特质

Social(社交)：支持用户分享信息和状态。

Expressive(表达)：用户可以通过各种方式表达自我。

Easy(轻松)：凭直觉即可完成各种操作。

Relevant(相关)：只显示用户关心的信息。

Extensible(可扩展)：能够与Google既有特性、第三方网站和应用集成。

Private(隐私)：不能泄露用户数据。

l  Google+组件(通过阅读架构文档确定)

Profile(个人资料)：已登录用户的个人信息和偏好设置。

People(人)：用户已经加了的好友。

Stream(信息流)：帖子、评论、通知、照片等组成的信息流。

Circles(圈子)：将联系人按照朋友、同事等所作的分组。

Notification(通知)：表示你在某篇帖子里被提到了。

Interests or +1(感兴趣)：用户对喜欢的表达。

Posts(帖子)：来自用户及其联系人的文章。

Comments(评论)：帖子、照片、视频等的评论。

Photos(照片)：用户及其联系人上传的照片。

l  Google+能力

Profile：

Social：与好友和联系人分享个人信息和偏好设置。

Expressive：用户可以创建虚拟世界里的自己。

Expressive：用Google+表达你的个性。

Easy：很容易输入和更新信息，并传播开来。

Extensible：按照适当的访问权限传递个人信息给有关应用。

Private：确保用户可以保护自己的隐私数据不被泄露。

Private：只与已被批准的、适宜的它方分享数据。

People：

Social：用户可以将其他用户的朋友、同事和家人添加为好友。

Expressive：其他用户的个人资料是个性化的，易于区分。

Easy：提供方便用户联系人管理的工具。

Relevant：用户可以根据一定的条件过滤联系人列表。

Extensible：只给有受权的服务和应用提供联系人数据。

Private：确保只有经过批准才能看到用户的联系人数据。

Stream:

Social:将社交网络的更新通知到用户。

Relevant:可以过滤掉用户不感兴趣的更新。

Extensible：将信息流更新传给其他服务和应用。

Circles：

Social:根据社交背景将联系人分组到不同的圈子。

Expressive：可以基于用户背景创建新的圈子。

Easy：方便联系人的添加、更新和删除。

Easy：方便创建和修改圈子。

Extensible：将圈子数据传递给有关服务和应用。

Notifications：

Easy：简洁的显示通知。

Extensible：将通知传递给其他服务和应用。

Hangouts：

Social：用户可以对圈子中的好友发送群聊邀约。

Social：用户可以将群聊公开。

Social：其他人可以在他们的信息流中得到群聊通知。

Easy：几次简单的单击就可以创建和参与一个群聊。

Easy：一次点击就可以关闭视频和音频输入。

Easy：额外的用户可以被加入进行中的群聊。

Expressive：在加入群聊之前，用户可以预览自己的形象。

Extensible：用户在视频群聊中可以通过文本交流。

Extensible：YouTube中的视频可以放到群聊中。

Extensible：可以在Setting中配置和调整有关设备。

Extensible：没有摄像头的用户可以仅通过音频参与。

Private：未经邀请，不能参与群聊。

Private：未经邀请，不会收到群聊通知。

Posts：

Expressive:通过Buzz表达用户的想法。

Private：帖子限制在希望的范围内。

Comments：

Expressive：通过评论表达用户的想法。

Extensible：将评论数据公布给其他服务和应用。

Private：评论限制在希望的范围内。

Photos：

Social：用户可以与联系人和好友分享照片。

Easy：用户可以轻松的完成照片上传。

Easy：用户可以轻松的从其他来源导入照片。

Extensible：与其他照片服务集成。

Private：对照片的查看限制在希望的范围内。

-----------------------------------题----外----话-----------------------------------------

 看完这个，让我想起，之前我在使用思维导图分析需求时，抓关键字及功能点范围划分的办法，有点相似。照书上所说，可以直接根据ACC来写用例。在以前的测试中，我可以直接按照根据需求写的思维导图(不过还是需要进行改进，具体分为需求版的，和用例版的思维导图)来执行测试。

 

测试时写的思维导图，对于我来说，相当于一个测试指导文件了。具体内容包括：

l  需求：需求提出方，提出缘由，指出需求文档及相关资料所在。

l  背景：写出项目人员组成(PD、项目经理、前后台开发、测试)及分工模块，还有项目里程碑及测试卡点。

l  需求分析：由需求文档、原型图及其它一些项目相关文档或者会议记录、谈话内容(一切可以了解需求的地方)得来。

    需求点的划分，按照前后台、模块或者是操作流程来划分，不一而足，怎么划分清晰怎么来。

----------------------------------------------------------------------------------------- 

风险分析：

l  哪些事件需要担心？

l  这些事件发生的可能性有多大？

l  一旦发生，对公司产生多大影响？

l  一旦发生，对客户产生多大影响？

l  产品具备什么缓解措施？

l  这些缓解措施有多大可能会失败？

l  处理这些失败的成本有哪些？

l  恢复过程有多困难？

l  事件是一次性问题，还是会再次发生？

       风险分析的目的不是要给出一个精确的值，而是要识别一个能力与另一个相比风险是大是小。=>可以判断以何种顺序测试哪些能力。Google确定了两个要素来判断风险：发生频率和影响。

          发生频率：

l  罕见(rarely)：发生故障的可能性很小，发生问题后的恢复也很容易。

l  少见(seldom)：在少数情况下会发生故障，但是在使用场景复杂度不高的情况下或使用率较低的情况下，发生的可能性非常小。

l  偶尔(occasionally)：故障的情形容易想像、场景有点复杂，而该能力是比较常用的。

l  常见(often)：此能力所属的特性使用量大、复杂度高、问题频发。

      影响：

    l  最小(minimal)：用户甚至不会注意到的问题。

    l  一些(some)：可能会打扰到用户的问题。一旦发生，重试或恢复机制即可解决。

    l  较大(considerable)：故障导致使用受阻。

    l  最大(maximal)：发生的故障人永久性的损害产品的声誉，并导致用户不再使用它。

#我们可以做什么：可邀请团队成员进行风险评估，包括开发人员、项目经理、销售人员、总监和VP

#我们可以做什么：风险缓解

ü  可以围绕风险大的能力编写用户故事，并从中确定低风险的使用场景，然后反馈到开发团队，请他们有针对性地增加约束；

ü  可以编写回归测试用例，以确保问题在重现时可以被捕捉到；

ü  可以编写和运行引发故障的测试用例，来推动开发实现恢复和回滚的特性；

ü  可以插入监听代码，以便更早地检测到故障；

ü  可以插入代码监听软件，发现新旧版本间的行为变化以发现回归问题。

 

 

谷歌的测试工具

BITE，神一样的存在。个人非常喜欢，有机会试试。下面是BITE工具的书中的介绍.

浏览器集成测试环境(BITE)，是一个开源的Chrome扩展，目标是解决网页测试体验问题。这个扩展必须连接到一个服务器，这个服务器提供你的系统信息和bug信息。获得这些信息以后，BITE有能力提交bug报告，选择相应的模板，并提供相关的网站信息。

提交bug的时候，BITE自动抓取屏幕快照、链接和问题所在的用户界面元素，然后附加在bug报告里。这就为负责分析和(或)修复这个bug的开发人员提供了丰富的信息，可以帮助他们发现问题的根源和影响因素。

需要复现一个bug的时候，测试人员往往需要努力回忆并准确记录每一步操作。而使用BITE，测试人员在页面上执行的每步操作都被自动记录成JavaScript并能在将来进行回放。这样，工程师就能快速判定在特定的环境下复现问题的步骤，或者判断某个代码变更是否修复了特定的问题。

在BITE中还包含了一个录制/回放(RPF)控制台，它将用户的手工测试自动化。和BITE的录制功能类似，RPF控制台会自动生成JavaScript代码，在将来可用于回放操作。另外，BITE的录制回放机制还是容错的。UI自动化测试有时候可能失败，而这时候往往是测试代码的问题而非产品问题。这种情况下，当BITE回放失败的时候，测试人员可以立即修复这个问题，他只需要在页面上重复操作一遍就行了。这时候没有必要去改动代码或者提交一个失败报告。如果你的脚本找不到要点击的按钮，你只需要再点一下就行了，脚本会被自动修复。当你必须要修改代码的时候，可以使用Ace(http://ace.ajax.org)作为内联编辑器，你可以实时修改你的JavaScript代码。

 

SETs 和 TEs的区别

SETs' roles and TEs' roles are related but different in fundamental ways. I've been both and managed both. Look at the lists that follow and find which description most fits you—maybe you should switch roles.

You might be an SET if

You can take a specification, a clean whiteboard, and code up a solid and efficient solution.

When you code, you guiltily think of all the unit tests you should be writing. Then, you end up thinking of all the ways to generate the test code and validation instead of hand crafting each unit test.

You think an end user is someone making an API call.

You get cranky if you look at a poorly written API documentation, but sometimes forget why the API is interesting in the first place.

You find yourself geeking out with people about optimizations in code or about looking for race conditions.

You prefer to communicate with other human beings via IRC or comments in check-ins.

You prefer a command line to a GUI and rarely touch the mouse.

You dream of machines executing your code across thousands of machines, beating up algorithms, and testing algorithms—showing their correctness through sheer numbers of CPU cycles and network packets.

You have never noticed or customized your desktop background.

Seeing compiler warnings makes you anxious.

When asked to test a product, you open up the source code and start thinking about what needs to be mocked out.

Your idea of leadership is to build out a great low-level unit test framework that everyone leverages or is highly exercised millions of times a day by a test server.

When asked if the product is ready to ship, you might just say, "All tests are passing."

You might be a TE if

You can take existing code, look for errors, and immediately understand the likely failure modes of that software, but don't much care about coding it from scratch or making the change.

You prefer reading Slashdot or News.com to reading other people's code all day.

You read a spec for a product that is half-baked, you take it upon yourself to fill in all the gaps, and just merge this into the document.

You dream of working on a product that makes a huge impact on people's lives, and people recognize the product you work on.

You find yourself appalled by some websites' UI and wonder how they could ever have users.

You get excited about visualizing data.

You find yourself wanting to talk to humans in meat space.

You don't understand why you have to type "i" to start typing in a certain text editor.

Your idea of leadership is nurturing other engineers' ideas and

challenging their ideas with an order of magnitude more scale.

When asked if the product is ready to ship, you might say, "I think it's ready."

 

It is important for testers to figure out who they are. Often, TEs are simply seen as SETs who don't code as much or as well. The reality is that they see things that people with their head in the code all day will never see. SETs should also realize they aren't TEs and let go of any guilt or pressure to find UI issues or think about the system overall or competitive products; focus instead on high quality, testable, and reusable modules and amazing automation.

It takes a diverse family of testers to raise an amazing product.

 

------------------------------------- 

后续关注：

how to break software

exploratory software testing

 

 

 

 

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

博客分类： 

· 软件测试

· 读书与计划

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"测试不得不变的异常灵活"

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

 

 

 

 

读《Google软件测试之道》的收获

 (2014-02-17 13:12:28)

转载▼

标签：  it   软件测试

读《Google软件测试之道》给我最强烈的感觉是：危机感。

James明确指出了，"我们熟知和喜爱的测试方式即将终结....软件开发的问题也已经彻底改变.继续死守已存在数十年之久的测试教条无异于刻舟求剑。"

1.与持续交付和敏捷开发方式相匹配的敏捷测试的基石就是自动化。自动化测试，将会成为主流。也就是说，作为一个测试工程师，如果不会写代码，不能编写自动化测试脚本，那么他/她就不具有测试工程师的“准入条件”，这样的只会纯手动测试的工程师，即将在不久的将来被淘汰。

虽然在刚毕业的前2年的时间里，我曾经做过开发工程师，但是已经接近10年没有写过代码了，我现在已经不具有coding能力。所以摆在面前的一个现实的问题就是：要么重新学习编程，要么面临被淘汰出局。

 

2.随着自动化测试时代的到来，大量依赖于手工的Regression测试，即将被自动化取代，人力资源得到解放。测试团队的规模，在未来会逐渐缩小。当然在某些特殊领域，或者开发的某些阶段仍然需要保留一定的手动测试（以探索性测试作为主要测试手段）。所以测试团队将只保留“测试专家”。测试专家不仅具有高超的测试能力，而且是产品专家。所以初级/中级测试人员，要么将自己升级成产品专家/测试专家，要么面临被淘汰的窘境。

由于做了几年Scrum Master （当时的工作重点是提升Scrum管理能力） , 最近2年中断了在测试方面的学习。现在回到测试这个角色，感觉自己在测试方面很多知识需要refresh。抓紧时间学习，提升自身测试能力，加深对产品的理解是当务之急。

 

以上2点都有些沉重，最后说一个轻松一些的收获吧！

书中提到的风险热图，是一个指导Test Strategy/Test Plan的好方法。根据不同Attribute/Component 的风险级别，来指导测试重点是一个有效方式。

在实际工作中，制定测试策略时，我对书中的风险热图进行了一些改进/变通。根据风险级别来选择测试覆盖率。风险越高，在test case的选择时，覆盖越大。

Risk	Selection Guidance	Comments
1	P1/P2/P3 Test Cases	Test Focus. Validate the full functions.
2	P1/P2/P3 Test Cases	Validate the full functions.
3	P1/P2 Test Cases	Validate the core/basic functions.
4	P1 Test Cases	Validate the core functions.

 

总之，作为一个测试从业人员，随着测试技术的发展，如果不抓紧时间学习新的技能，即将会在不久的将来被淘汰。当然转型从事其他角色的工作，也是不错的选择。例如SM, PO, PM 等等都是可以考虑的方向。但是无论哪个角色，都需要更丰富的技能，都是更高的挑战。

 

 可以参考一下文档链接：

http://download.csdn.net/detail/shenbin_45/6935889