关于《谷歌测试秘诀》的一点笔记，我其实都不记得书名到底是不是这个了（摊手

谷歌测试秘诀（james总结的）：技能，稀缺性，自动化和快速迭代，集成获得用户反馈的能力

一个管理者对一个项目测试的经验：

• 使用与应用程序开发语言相通的编程语言来编写测试
• 让负责开发新特性的人同事负责响应的测试执行，要对漏掉的测试负责
• 关注测试基础设施建设，让测试的编写和执行非常容易
• 20%用例尽量覆盖80%场景，并让着20%自动化，剩下的收工
• 速度是王道，进行性能分析以便证明给所有人看
• 与开发团队的沟通
• 创新精神

2.1 SET的工作

1.审阅设计文档

• 完整性：文档中不全的，或是需要特殊背景知识的地方，鼓励文档作者添加更多细节，或者外链解释。
• 正确性：检查细节错误
• 一致性
• 设计：技术框架设计，是否可简化设计
• 接口与协议：对外接口，数据格式
• 测试：整套系统的可测试性，是否需新增testing hook（为测试而增加的接口）

2.自动化测试

易出错接口隔离，公开产品质量给关注的人

3.避免冲突

** 获取未使用的端口，并让被测系统动态绑定到该端口

• 执行测试前，为用例在临时目录下创建目录和文件，并使用独一无二的目录名
• 每个测试运行在自己的数据库实例上，使用和环境隔离的目录和端口，这些都由测试执行系统来控制

3 关于TE（testing engineer）

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 用户反馈

1.测试计划特征

• 及时更新
• 描述了软件的目标和卖点
• 描述了软件的结构，组件和功能特性的名称
  （从测试角度看，也要考虑测试计划的投入和价值产出是否匹配）
• 不必花过多时间撰写，必须随时可以被修改
• 应该描述必测点
• 应该在测试中提供有用的信息，从而帮助确定进展以及覆盖率上的不足

2.ACC （attribute component capability，一种测试计划的替代方法）

• 简明的列表，列出要点和事实
• 不必推销
• 简洁，计划大小只与测试问题规模有关
• 不重要的，无法执行的不要放进测试计划
• 渐进式描述
• 指导思路
• 测试用例，不止是计划，还要有用例
  描述产品目标的形容词和副词，确定产品各部分各特性的名词，描述产品做什么的动词
  结合GoogleTestAnalytics
  GAT可以测试结果加入风险预估中
  eg:
  示例：确定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：对照片的查看限制在希望的范围内。

3.风险

• 风险分析
  1，那些事情需要担心
  2，这些事情发生的可能性
  3，一旦发生，对公司有多大影响
  4，一旦发生，对客户有多大影响
  5，产品具备什么环节措施
  6，这些缓解措施有多大可能会失败
  7，处理这些失败的成本有哪些
  8，恢复过程有多困难
  9，时间是一次性问题，还是会在发生
• 影响风险的要素：失败频率（罕见>少见>偶尔>常见）和影响（最小>一些>较大>最大）
• 缓解风险
  1，围绕风险大的能力点编写用户故事，并从中确认低风险的使用场景，然后反馈给开发团队，请他们有针对性的增加约束
  2，编写回归测试用例，以确保问题在冲显示可以被捕捉到
  3，编写和运行引发故障的测试用例，来推动开发实现恢复和回滚的特性
  4，插入监听代码（instrumentation and watchdog code）一遍更早检测到鼓掌
  5，插入代码监听软件，发现旧版本间的行为变化以发现问题回归

总结，acc可以用来确定一系列的能力点，按风险排序，然后分配给所有质量伙伴（dogfood用户，外包测试人员，中保测试人员，swe，set等）这样更高效

bug相关的一些字段

• assigned to-指派给
• CC-抄送
• attachment
• blocking-阻塞
• depends on
• changed
• changelists
• component-组件
• found in
• last modified
• notes

零成本测试

• GAT测试计划
• 测试覆盖度（bot抓取所有不同，灰常快）
• bug评审（BITE提供原有bug信息以及上下文信息）
• 探索性测试（外包和早期用户完成）
• bug提交（BITE）
• bug triage和调试（开发者，测试经理看bug趋势图并分析bug数据或是重放）
• 部署新版本并回到第一步

“渲染代码”