愿和我一样读过这本书的人有所共鸣或者启发，愿没读过这本书的人，能获得一点点收获。。。

说到软件测试工程师，首先我们需要明白一个问题，软件测试工程师的职责是什么？

关于这个话题，不同的人有不同的定义；抛开这个话题，说说Google是怎么定义以及Google的TE是如何工作的。

软件测试工程师（Test Engineer）：简称TE，评估软件应用对用户的影响以及软件产品整体目标上的风险的一种面向用户的测试角色。

1、TE何时进入项目

首先需要明确一点：并不是所有的项目都需要TE的介入；比如：

①试验性阶段、尚无明确目标或需求的早期产品，TE很少参与，甚至不参与；

②产品有很大可能被取消，项目被终止（只有一个概念或没做通过最终立项），或者功能还没定型等；

③即使已经确定要发布某个产品、项目，在研发的早起阶段，功能需求还在不断变更，最终功能列表和范畴还没确定，TE一般也没有太多工作需要进行；

因此，选择合适的阶段测试进入项目，很重要！一般来讲，给一个项目配备多少TE，以及何时介入，取决于项目风险、重要程度以及投资回报率。

2、当TE进入项目时，需要考虑什么

①当前软件的薄弱点在哪儿；

②有没有安全、隐私、性能、可靠性、可用性、兼容性以及其他的问题；

③主要用户场景是否正常？对用户来讲是否都是这样？

④这个产品可以和其他平台、产品（软件硬件）互操作吗？--个人理解：上下兼容，跨平台甚至更广阔的领域

⑤如果出现问题，能否容易找出问题所在并且快速解决？--个人理解：风险预估和防范机制

这几点只是不完整的几点，TE也并不需要自己去解决这些问题，但必须保证这些问题被解决！！！

TE的根本使命：保护用户和业务的利益，使之不受糟糕的设计、令人困惑的用户体验、功能BUG、安全和隐私等问题的困扰。

3、TE的职责描述

①测试计划和风险分析

②评审需求、设计、代码和测试--个人理解：目前来讲，国内大部分的测试接触代码还是很少的，但代码是测试发展的一个必然趋势

③探索式测试

④用户场景

⑤编写测试用例

⑥执行测试用例（包括提交BUG、跟踪、协助沟通修复以及回归等等）

⑦使用统计（测试每个阶段的版本迭代、BUG数量、质量指标、用时等等数据信息）

⑧用户反馈（这对于优化产品，提供更好的服务很重要）

4、测试计划

在每个项目中，最重要的产物，是代码！因此，每个技术项目团队，都需要对编码保持敬意。

测试计划的意义：在项目执行中发挥核心作用，在软件的生命周期内持续有效，时刻代表最新的产品功能，指导项目进展，可以帮助新加入的工程师快速跟上项目进展等。

优秀的测试计划应该有的一些特性：

①及时的更新

②描述软件产品的目标和卖点

③描述软件的结构、各种组件和功能特性的名称

④描述了软件的功能和操作简介

⑤描述了必须执行的测试点

⑥对测试工作提供有用的信息，帮助确定进展以及覆盖率的不足

ACC分析方法：即Attribute Component Capability,特质、组件、能力。这是从Google众多测试团队实践中总结的一个优秀流程，受众较多，搜索“Google Test Analytics”即可找到。

ACC指导原则如下：

①避免散漫的文字，使用简明的列表

②不必推销（测试计划的受众是工程师）

③尽量简洁（测试计划的大小和测试问题的规模有关，和作者的写作欲望无关）

④渐进式的描述（make it flow）：测试计划的每个部分应该是前面部分的延伸

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

⑥最终结果应该是测试用例（测试计划最直接的体现就是可以清楚的指导测试用例的编写）

A：代表特质（Attribute）

在设计测试计划或者做ACC分析时，必须先确定该产品对用户、对业务的意义；比如：为什么开发它？能带来什么价值？怎样吸引客户？核心竞争力是什么？等等

特质代表了产品的品质和特色，是区别于竞争对手的关键。

C:代表组件（Component）

组件是构成待建系统的模块，在特质被识别后确定，组件是使一个软件之所以如此的关键代码块；实际上，它们是测试人员所要测试的对象。

C：代表能力（capability）

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

能力一般是面向用户的，表达用户眼里系统的行为，它最重要的一个特点是它的可测试性。

关于能力点分析的一种方法：

上图是一个以特质为X轴、以组件为Y轴的表格，通过这种方法将功能点映射到特质和组件上。其中有很多空格，它表示：只有部分组件对该特质有影响（不是每个组件都对特质有影响）；

能力表的每一行或列表示按某种方式相关联一个功能点切片，这样可以将应用功能分解为多个可测试点的好办法；单元格中的数字表示该组件满足此特质能力的数量，数字越大，该交叉点需要

测试的测试点越多，这些能力点可以方便指定组件/特质对的需要的测试；可以以这些功能点直接涉及测试用例，或将它们组合成更大的用例或测试场景。

注意以下几点：

①每个功能点至少对应一个用例

②重要的功能点对应多个用例

③并非所有的功能点都是同等重要的，区分优先级很重要

PS：你能想象到的一个软件产品的特质、组件、能力点，都有什么？下面列举一些Google+的ACC分析例子：

Google+特质：--（通过经理层等管理层讨论即可决定）

Social（社交）：支持用户分享信息和状态 --分享

Easy（轻松）：用户凭直觉即可完成各种操作 --操作习惯

Relevant（相关）：只显示用户感兴趣的信息 --用户关注点

Extensible（可扩展）：能否与其他类似平台、第三方服务和应用集成 --扩展性

Private（隐私）：不能泄露用户数据 --安全隐私性

Google+的组件：（通过阅读设计文档即可确定）

Profile（个人资料）：已登录用户的个人信息和偏好设置 --我的，个人中心模块

People（好友）：用户已经添加的好友

Stream（信息流）：帖子、评论、通知、照片等组成的信息流 --动态

Circles（圈子）：将联系人按照朋友、嫁人、同事等进行分组

Notifications（通知）：推送消息、转发、艾特等有关于用户本身的消息

Posts（帖子）：来自用户及其联系人的文章、随笔等

Comments（评论）：帖子、文章、照片、视频等的评论

Photos（照片）：用户及其联系人上传的照片等 --上传下载等功能

Google+能力点（功能点）：

关联上面的Google组件模块，其中包含的功能点有很多，下面就每个组件列举一下：

profile：个人设置、创建、信息更新、分享、个性化、个人数据安全隐私、权限等

people：社交圈子、可扩展性、过滤、筛选、授权等

stream：信息服务的上下层、圈子分层、增删改查等动作

other：按钮、链接、文件等上传下载分享等功能点（功能点太多，这里只是简单列举。。。）

5、风险分析

△没有完美的软件产品应用，风险无处无时不在！

定义：确认风险的过程称之为风险分析；

常识性的关于风险的一些因素：

①哪些事件需要担心

②这些时间发生的可能性、概率有多大

③一旦发生，对客户、业务、公司有什么影响

④有什么缓解防范机制

⑤缓解措施有多大的成功率

⑥处理这些失败的成本消耗

⑦恢复过程的难易程度

⑧事件是一次性问题还是会再次发生......

总结：影响风险的因素很多，关键性的有两个因素：失败频率（frequency of failure）和影响（impact）;风险是一个定性的相对值，而不是一个定量的绝对值。

GTA（Google test analytics：Google测试分析，一个方便数据输入和风险可视化的web应用，感兴趣的可以去搜索看看）中风险发生频率有4个预定义值：

罕见（rarely）：发生故障的可能性极小，发生后恢复也很容易

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

偶尔（occasionally）：故障情形容易想象、场景有点复杂，该功能点比较常用

常见（often）：该能力所属的特性使用量大、复杂度高、问题频发

关于一些风险分级说明：

最小（minimal）：用户甚至不会注意到这个问题

一些（some）：可能会影响用户的一些问题；一旦发生，重试或恢复机制即可解决问题

较大（considerable）：故障导致组件使用受阻

最大（maximal）：发生的故障会永久性损害产品、公司声誉，并造成无法挽回的损失（用户流失等严重问题）

关于风险分析的一个行之有效的办法：

基于TE的输入以及上面提到的关于特质和组件的一组列表，可以生成一个风险区域的热图：

表中的单元格以红色、黄色、绿色高亮显示，分别表示响应组件在各交叉点的风险级别；风险级别是TE已经输入的值的一个简单判断。

该表格代表了该产品可测试能力以及风险，他们的风险级别一般是由开发人员、PM、测试甚至经理总监一起来评定审核（不同角色评判角度不同），一旦认同，接下来就是风险预防和缓解。

6、风险缓解

首先需要明白一点：风险永远不可能彻底消除！如何预防缓解风险，可以参考如下几点：

①可以围绕风险等级高的能力点编写测试用例，从中拆分、确定风险等级低的使用场景，然后反馈到开发团队，有针对性的增加约束、提示；

②对风险按照等级高低做记录，设计回归测试用例，以确保问题重现时可以被捕捉到；

③设计和运行会引发故障的用例，以便推动开发团队实现实时恢复和版本回滚；

④对风险组件或者场景进行监听、报警，以便更早的检测到故障；

PS:具体的缓解措施取决于应用本身以及对于安全性的期望值。TE的主要职责就是主动去暴露风险，根据风险等级，按照从高到低测试，如果时间不够，先测试风险最大的。

还有一点：按照项目类型和进度给出是否可以发布的建议，这是TE的责任，这一点完全可以利用风险热图来完成。

△TE与风险

①对于任何在GTA（前面有提到）矩阵中显示为红色高风险的能力点和特质的一组件对，一定要设计一些列的测试用例或有针对性的场景去主动发现、暴露风险；--责任、职责

②认真了解分析SET和SWE已经完成的测试工作，评估这些测试对GTA所暴露风险级别的影响（测试力度是否足够？是否需要增加额外的测试？）；--评估力度并给出是否进行下一步建议

③分析每个高风险的特质--能力对的相关BUG，保证回归测试用例的存在和有效性（BUG倾向于在代码发生变更时重现）--做好记录，回归

④仔细思考高风险的区域，考虑可能的版本回滚和恢复机制；

⑤尽可能多的引入相关各方，学会利用团队的力量；

⑥如果时间范围内还没有足够的测试或者缓解措施，经常出问题，那么应该考虑努力去说服相关同事，做好备用措施！

PS：对于风险级别较低的点，可以尝试探索性测试。。。

7、测试用例

基于我们前面的诸多分析准备工作， 其结果都是输出一个可行的有效的测试用例。

Google比较常见的用例管理工具：GTCM（Google Test Case Manager）

设计测试用例的目的是什么呢？→→发现缺陷，主动暴露风险，也就是我们俗称的BUG；

8、bug的组成和生命周期（其中很少有必选的项，可以根据自身及团队需要抉择）

Assigned to（Assignee，被指派者）：负责采取下一步动作的人 --可选项

CC（抄送）：当一个问题被创建或修改，需要通知的一个或多个人 --可选项

Attachments（附件）：关于某个问题，相关的描述文件 --可选项

Blocking（阻塞）：该bug被修复后才能被修复的其他bug的ID --可选项

Depends On（依赖）：该bug依赖其他的bug的ID→→其他bug被修复前，该bug无法修复 --可选项

Change（变化）：该bug最后的修改日期和时间 --只读

Changelists（变更列表）：处理该问题的一个或多个变更列表（CL）编号 --可选项

Component（组件）：与此bug有关的或者有需求的实体（创建时需要指向组件的完整路径） --必选项：准确的描述

Created（创建于）：该bug的创建日期 --只读

Found In（发现于）：发现问题时的软件版本号等 --可选项

Last modified（最后修改）：该问题的任一一堆被修改的最后日期 --只读

Notes（备注）：问题本身及其处理过程中的注解的详细描述 --可选项

Priority（优先级）：bug的重要程度 --必填

Reportde by（Reporter：报告者）：谁发现或者谁提出的这个bug --只读

Resolution（解决方案）：验证者最终决定的解决方案 --可选项

Severity（严重性）：该bug在多大程度上影响产品的正常使用 --必填（一般分为导致系统无法使用、高、中、低、对系统无影响五个等级）

Status（状态）：bug的当前状态 --必填（新建、已指派、已接受、不修复、已修复、以后修复、已确定、已验证、已关闭等状态）

Summary（摘要）：关于该bug描述性的摘要 --必填（尽量做到准确概括）

Targeted To（目标）：该bug在哪个版本号被修复 --可选项

Type（类型）：问题的来源类型 --必填（缺陷、需求、客户问题、内部问题、流程等）

Verified In（验证于）：问题修复被验证的软件版本号 --可选项

Google最常用的BUG管理工具：Buganizer，可以将其理解为一个典型的bug数据库。

说到这里，有个问题；测试最重要的一面是什么？是确认！！！

软件产品是否达到用户预期和需求设计，很重要！！！

△TE的未来

最近听到看到很多人说软件测试的工作越来越不好找，主要表现在于学历要求越来越高，经验要求越来越多，以及个人技能和综合能力；其实优秀测试工程师的需求之大，前所未有。

我们现在所从事的测试工作，或国内大环境下的测试工作，都是传统意义上的测试，常规性的基本都是设计用例、执行、回归等工作，他们实际上已经有了更为全面且更为低成本的形式。

这种机会很大程度来源于软件交付领域技术上的进步。在过去，软件每周或每月构建一次并需要经过痛苦的集成过程，其中TE都是在发现bug以及尽量模仿用户操作，交付上线后直接

面对的可能是几万甚至几百上千万的用户，一旦发生问题，那么这种我们俗称的生产事故会带来比较严重的后果，可现在已经不这样了。

通过互联网交付，意味着我们可以选择某一部分用户进行发布（PS：说到这里想起某个群里的Nero大佬之前说过一种发布方式：灰度发布；感兴趣的可以搜索了解一下），可以迅速

响应这部分用户的反馈，并及时解决更新，bug寿命缩短到了几十分钟甚至几分钟！研发团队可以快速构建快速交付、修改、重新迭代交付，让很多可能会发生在用户层的问题在用户接触到

之前就已经被解决；这也是一种更好的软件交付和用户反馈机制。

问题的关键就在于：企业希望用哪种方式测试自己的软件应用？

高薪聘请资深测试专家，尽力模仿用户场景？还是激励大量的真实用户发现并报告实际的BUG？随着互联网不断发展和平民化，允许真实用户更早访问软件，激发用户报告问题的时机和

成本越来越低，也越来越容易；而且，每日更新甚至小时级别的更新，已经不是什么太困难的事情。这种可以预见到的环境下， 作为一个TE，是该思考自己的职业规划了。

如果按照本书来说，未来可能TE会变成这种样子：

转变成测试设计，少量的测试设计师快速的规划处测试范围、风险热图和应用程序逻辑路线等，然后内部试用者、可信赖的测试者、早期用户或者其他外包测试人员提交反馈，由测试

设计师来评估覆盖率，计算风险影响，确保出现的问题不断减少，并相应的作出调整。。。

当然，这需要很多的专业技能以及经验：比如安全性隐私性、性能、探索式测试，设计开发对应的工具来统计收集这些数据，但实际工作中并没有设计用例、执行用例的测试行为。。。

一些题外话：

在看到TE的未来这段内容之前，个人感觉，Google的测试领先的，更多的是技术上的创新、新技术的运用、流程标准化、模块化等方面，但我看到这里，有种彗星撞地球的感觉，脑海里

仿佛整个世界都被重新设计一样。

可能在国内这种大环境下时间久了，失去了想象和更大的思考能力，可能现在作为一个TE，短时间内无法改变所处的环境，但抱有期待，并为之努力，做好准备，永远是必须的。

写在博客内的文字，永远无法表达看纸质书看到这些内容的震撼；希望看到这里的人，都能有所收获。。。

转载请注明出处，商用请征得作者本人同意，谢谢！！！