Google软件测试之道

 

三种角色：

(1)SWE(Software engineer)：是一个传统上的开发角色，他们的工作是实现最终用户所使用的功能代码。SWE需要编写与测试代码。包括测试驱动的设计、单元测试、参与构建各种大小规模的测试等。

(2) SET(Software engineer in test)：也是一个开发角色，只是工作重心在可测试性和通用测试基础框架上。更加关注质量的提升和测试覆盖率的增加。SET写代码的目的是为了让SWE测试自己的功能。部分职责是在单元测试方面给予开发人员支持，另外一部分职责是为开发人员提供测试框架，以方便他们编写中小型测试。

(3) TE(Test engineer): 测试工程师，把用户放在第一位来思考，TE组织整体质量实践，分析解释测试运行结果，驱动测试执行，构建端到端的自动化测试。TE是真正的产品专家、质量顾问和风险分析师。从开发的角度来看，他们编写用户使用场景方面的自动化用例代码；从产品的角度看，他们评估整体测试覆盖度，并验证其他工程师角色在测试方面合作的有效性。

SET主要关注对象是开发人员，SET的主要职责是让开发者可以很容易的编写测试代码，从而达到独立功能模块的质量要求。

TE的主要职责是专注用户的测试。

 

测试的规模：

(1) 小型测试: 单元测试，通过自动化方式实现。是由SWE来实现，也会由少量的SET参与，TE几乎不参与小型测试。一般使用mock(mock对象是对外面依赖系统的模拟，在运行时刻可以根据假设的需求提供期望结果。)和fake(fake对象是一种虚假的实现，内部使用了固定的数据或逻辑，只返回特定的结果。)。

(2) 中型测试：集成测试，通常也都是自动化实现的。SET会驱动这些测试的实现及运行。SWE会深度参与。

(3) 大型测试：系统测试或端到端的测试。验证软件是否满足最终用户的需求。所有的三种工程师角色都会参与到大型测试之中。

各种测试规模的益处：

(1) 小型测试

•   可以很快的运行完毕，因此在有代码变更的时候就可以立即运行，从而可以较早地发现缺陷并提供及时的反馈。
• 在所有的环境都可以可靠地运行。
• 有较小的测试范围，这样可以很容易地做边界场景与测试条件的测试。
• 使用mock或fake华宁，可以不与真实的环境同步。
• 由于范围比较小，出现bug可以很容易的定位。

(2) 中型测试

• 由于不需要使用mock技术。且不受裕兴时刻的限制，因此该测试是从大型测试到小型测试的一个过渡。
• 运行速度相对较快，可以频繁地运行他们。但是运行速度没有小型测试快。
• 可以在标准得开发环境中运行。
• 依赖外部系统，因此它们本身就有不确定性。

(3) 大型测试

• 测试最根本最重要的：在考虑外部系统的情况下应用系统是如何工作的。
• 由于对外部系统有依赖，因此也是不确定性的。
• 很宽的测试范畴意味着如果测试运行失败，寻找精准失败根源就会比较困难。
• 测试数据的准备会非常耗时。
• 大型测试属于较高层次的操作，如果想要走到特性的代码路径区域是不切实际的，而这一部分却是小型测试的专长

总结：小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告；大中型测试带来了整体产品质量和数据验证。

检验一个项目的里小型测试、中性测试和大型测试之间的比率是否健康，一个好办法是使用代码覆盖率。

几种不同类型测试比率：70%的单元测试、20%的中型测试、10%的大型测试。

 

 

测试开发工程师的职责：

设计文档评审：需要考虑整个系统的可测试性？系统的可测试性如何评估。

自动化计划：在自动化上投入的越多，维护的成本就越大。在系统升级变化时，自动化也会更加不稳定。在端到端的自动化测试上过度投入，常常会把你与产品的特定功能设计绑定在一起，这部分测试在整个产品稳定之前都不会特别有用。

测试执行：测试自动化不仅仅是自动化测试程序的编写。如果想让这些测试程序更有价值，必须要去考虑如何编译测试程序，执行、分析、存储和报告所有的测试运行结果。因此一个可以做代码编译、测试执行、结果分析、数据存储、报表展示的通用测试框架逐渐形成了。

 

依赖树分析：分析每次变更可能影响的用例，然后只回归该部分的用例即可。

 

测试运行要求：

(1) 每个测试和其他测试之间都是独立的，使他们就能够以任意顺序来执行。

(2) 测试不做任何数据持久化方面的工作，在这些测试用例离开测试环境的时候，要保证测试环境的状态与测试用例开始执行之前的状态是一样的。

保证测试环境的有效性。

 

________________________________________________________________________________________________________________________

 

 

1 ST的主要工作职责：

测试计划 & 风险分析

评审需求、设计、代码&测试

探索式测试

用户场景

编写测试用例

执行测试用例

覆盖度报告

众包

使用统计

用户反馈

 

2 测试设计：

和测试人员相比，开发人员有一个优势就是他们的工作产物是每个人都真正关心的，代码是项目过程中的最重要的文档。

测试计划是测试最早出现的产物，也是最早被遗忘的测试产物。由于测试计划在项目早期产出，它会很快随着新代码的完成或者功能特性的变更及设计的调整而过期。

ACC：测试计划的替代方法。ACC通过指导计划者依次考察产品的三个维度达成这个目标：描述产品目标的形容词和副词；确定产品各部分、个特性的名词；描述产品实际做什么的动词。

A代表特质（Attribute）：

在做ACC分析时，需要明确该产品对用户、对业务的意义。我们为什么要开发这个东西？它能带来什么核心价值？它又靠什么来吸引用户？不需要对这些问题做辩解，直接写出来就行了。

特质是系统的形容词，代表了产品的品质和特色，是区别于竞争对手的关键。特性一般在几分钟内就可以列举出来。

比如chrome的特质：快速、安全、方便

C代表组件(component)

组件是系统的名词，在特质被识别之后去顶。组件是构成待测系统的模块。

例如：chrome的导航、收藏夹、扩展程序、web页面、设置、搜索等

组件不能太多，也不能太细。

C代表能力(Capacity)

能力是系统的动词，代表着系统在用户指令之下完成的动作。它们是对输入的响应、对查询的应答、以及代表用户完成的活动。也就是软件为用户提供了哪些功能。

能力是特性&组件交点。组件(Componet)执行某种功能(Capacity)来满足产品的一个特质(Attribute)。

例如：在线购物系统：从购物车增加或删除商品、获得信用卡和验证数据、使用HTTPS处理钱款交易、显示剩余库存、基于购买者正在浏览的商品提供建议。

能力最重要的伊特特点是它的可测试性。我们需要为每个能力编写对应的测试用例。一个能力可以有任意数量的测试用例。

能力描述并不是测试用例，能力是软件可以提供或者用户可能要求的动作的一般性概念，是抽象的，不会包含 实际测试所需要的一切信息，录入特定的值或者具体的数据。

 

component\AttributeAttribute1Attribute2component1capactiy1
capacity2capacity4component2capacity3capacity5

 

构建一张上述的ACC分析表格。

 

 

3 风险分析

影响风险的因素很多，试图精确地、定量地计算风险比环节风险还要麻烦。在google，评估风险主要是两个因素：

(1) 失败频率(frequency of  failure):

      罕见：发生故障的可能性很小，发生问题的回复也容易。

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

    偶尔：故障的情形容易想象，场景有点复杂，而该能力是比较常见的。比如：Chrome的Sync功能。

   常见：此能力所属的特性使用量大，复杂度高，问题频发。比如：chrome浏览器的web页面渲染。

(2) 影响(impact)

    最小：用户不会注意到该问题。

   一些：可能会打扰到用户的问题，一旦发生、重试或恢复机制即可解决问题。比如：refresh刷新按钮。

   较大：导致用户使用受阻。比如：chrome的扩展功能。

   最大：例如chrome的自动更新机制，一旦失败，就会导致关键性的安全升级无法进行。

可以将风险标注在ACC分析表格上。就会形成风险热区。

 

4 测试用例的生命周期

  谷歌的用例管理工具：GTCM(google test case Manager)

 

5 bug的生命周期

   谷歌使用的bug管理工具：Buganizer

   给bug制定优先级P0-P4.

   严重性：S0-S4

6 面试TE

测试一个web页面：上面有一个文本输入框，以及一个计数按钮，用于统计一个文本字符串中大写字母A出现的个数。

分析思路:

明确需求，输入框是否有字数限制、计算完成后文本是否会被移除、是否包括小写字母“a”。

(1) 功能测试

无效输入：null:0

有效输入：

“”:0，name:2(一个正常的字符串,合法的单次)，a:1(仅一个字符a)，b:0(不含有a字符), aa:2（连续的两个aa字符）,aba:2（a和a分别在第一个和最后一个,以寻找循环边界错误）,bab:1（a在中间），“  \n a”:1 (包含特殊字符)， <alter>abc</alert>:3(还有可执行字符) , 长字符串不包含a：0(长串的测试)，长字符串包含N个a：N(长串的测试)

(2) 高级测试

输入框是否太小

输入串的内容会被记载么

尝试复制和粘贴字符串

建议用真实数据做自动化测试，如从词典或者书本选择

计算足够快么

考虑这个应用能否在同一台机器上运行多个实例，会发生多个用户的串扰么？

(3) 更高级

计算会通过URL_encoded HTTP GET请求发送到服务器，字符串可能会在穿越网络时被截断。

建议将此应用参数化，可以支持对其他字母的计数。

HTTP post方法和参数会被黑掉么？也许会有安全漏洞

用脚本创建各种有趣的排列组合和字符串特性如长度，A的个数等的组合，自动生成测试输入和验证。