第6节 自动化测试的价值

小宇所在的自动化突击队，在经历了半年的攻坚、兴奋、持续维护之后，大家集体陷入疲惫状态，leader莎姐及时发现了这种现象，带领大家就几个问题进行了深刻的反思。

1．传统的自动化价值有哪些？

一些“敏捷理论”里是这样说的：“在传统的瀑布式开发里，自动化测试的推行，是一种进步；而在敏捷研发模式里，自动化是必不可少的基础。”

□ 自动化测试能提高效率，缩短测试工作时间。

□ 自动化测试和人工测试相比，每一次的测试执行操作都是固定的，非常忠实、可靠。

□ 自动化测试能加大每一轮回归的力度，从而提升测试覆盖率。

□ 自动化测试具备更好地重现软件缺陷的能力，因为它有很强的一致性和可重复性。

从以上的声音出发，很容易得出一个结论，自动化测试能节省人力，能缩减测试人员的投入，能增强测试有效性。它不仅能为老板省钱，也比人做得更好。

传统自动化ROI（成本与收益）的公式也是这样写的：

自动化的收益=迭代次数×全手动执行成本—首次自动化成本—维护次数×维护成本

或者如果假设迭代次数和维护次数近似相等，这个公式在某些情况下可以成立，比如一个比较新的产品：

自动化的收益=迭代次数×（全手动执行成本—维护成本）—首次自动化成本

正因为有这些光环，所以自动化测试的价值很容易说服老板们。

从这个公式里也很容易看到，实际上传统的自动化ROI分析，主要是基于把自动化测试定位在回归测试执行者的角度。

然后，这里实际上有一个很大的前提。也是传统的自动化理论“赖以生存”的基础。这个前提就是“测试做得越多越好”。老板们对测试覆盖率的理解，分子是指测试或自动化测试跑过的用例数，分母是产品所有的功能对应的测试用例。

这个理解仅对于一个全新的、第一次做的项目或产品，是正确的；但对后续的“迭代”和“增量版本”来说，也是合理的吗？前面我们已对回归测试做过分析，在回归测试中，有很大一部分是因为项目团队及测试人员的“不放心”，因为不放心进行测试，冗余比例是非常高的。也就是说，我们上述的自动化ROI计算公式，收益很大一部分也是来自于这里。

2．回过头来重新思考，自动化测试的价值到底在哪里？

谈到这个话题，我们需要先温习一下自动化测试的定义。

传统的自动化测试，通常是指测试过程被自动化。简单说就是把手工测试的用例让机器去做。

广义的自动化测试应该包括：

□ 测试环境的搭建和管理；

□ 测试环境的检查、监控和报警；

□ 测试代码的静态检查、编译和构建；

□ 测试场景的构造，测试数据的自动化准备；

□ 测试用例的分发和执行；

□ 测试结果的保存与管理；

□ 测试报告的生成；

□ 测试优先级的建议。

从自动化测试的类型上，可划分为：

□ 单元测试；

□ 代码静态检查，文件检查，签名校验，证书检查；

□ 接口自动化测试，又分本地接口测试和服务接口测试；

□ UI自动化测试（包括Web UI，Windows/手机/Pad/智能硬件等终端UI）；

□ 性能测试（本地性能测试和服务性能测试）。

在项目测试的实战中，这里所有的广义自动化类型和内容都有可能被使用到，并且被使用时的场景都是不一样的。例如UI自动化帮助我们回归；静态检查、接口测试、性能自动化测试，做到了人工测试无法测试到的场景；所有这些自动化测试都有可能在开发人员还没有移交给测试人员的时候，就开始介入到测试工作中去，提早发现问题。

好的自动化测试不能仅仅考虑时间和资源成本的节省收益；好的自动化测试应该能带来迭代周期的缩短，从而缩短项目周期；好的自动化测试应该能让某些时候变不能做为能做，进而带来的机会收益是巨大的。

总结一下自动化测试可能的价值：

1）帮助回归、节省人力。

2）构建人工测试无法构建的场景、数据准备，或执行一些人工测试做不到的测试用例，有效提升测试覆盖率。

3）前置测试，让测试和开发有可能并行，提升项目敏捷度，降低测试独占周期。

3．找到方向

但是，不管自动化测试有多大的价值，从本质上来说，它只不过是按照人工设置的场景按部就班地去执行，说白了是执行工具而已。所以，着急补齐的并不是自动化测试，而是如何缩减回归测试的范围，如何让不能做的测试变得能测，进而再考虑如何让自动化测试发挥最大价值。

测试独占周期是指从开发正式将版本、迭代、需求移交给测试开始，到版本达到待发布状态的时间长度，这个周期内包括测试活动，也包括开发活动（如修改测试出来的Bug，开发一些临时变更或新增的需求等）。

测试覆盖率传统上是指测试执行的用例总数除以所有测试用例总数，本书提到的“测试覆盖率”，区别于“传统测试覆盖率”，是指测试执行的用例总数/需要真正被执行的测试用例总数；区别在于分母并不包含因为“担心影响到”“害怕有问题”从而执行的大量低价值回归测试用例。

测试业界对测试用例的叫法可能存在不同，有些公司可能会称之为“测试案例”，或“案例”，这里统一称为“测试用例”，含义为测试执行的最小颗粒度，适用于手工测试和自动化测试。自动化测试的代码则称为“自动化测试脚本”或“自动化脚本”。

测试员之路在何方

一家节奏非常快的互联网企业，测试经理在逐个面试来应聘的候选人：

测试经理：“我们公司的交付速度非常快，每个版本需求虽然不多，但只有几个小时或1天的时间测试，如果你来承担这个工作，你会怎么做？”

A：“假如我很精通业务，了解需求，我会很有经验，知道这些需求大概会需要测试什么，所以我通常测试得很快”；

B：“我会要求开发哥跟我讲清楚，我需要测试什么，开发哥给我的测试建议非常重要，我根据建议，认真仔细地去测试，就能保质保量”；

C：“站在用户的角度去测试好了，我们抓准用户的需求，做好需求分析，就能更轻松地去测试”；

D：“其实测试没有那么复杂，就是一个鼠标点点，眼睛瞄瞄的工作而已”；

……

无论你是面试官还是被面试者，这样的问题都很常见。测试从业者在工作多年后，或多或少都会有职业困惑：

我是不是选错行业了？如果我当初选择做开发者，做产品经理，是不是现在会拿到更高的薪酬，获得更大的职业成功？

测试人员的未来和发展是什么？除了在管理职位上晋升到主管、经理、总监（好像也到头了），难道只能转项目经理、产品经理、产品运营，甚至是商务？（回音：还是选错行了……选错行了……错了……）

我们首先来问自己一个问题：“你为什么要选择做测试。”

估计抓十个人来回答这个问题，九个不会说实话。什么“我热衷于发现bug的乐趣”，“我的性格比较细心、耐心，适合做测试这个行业”，“测试能够让我开阔眼界”，等等。很多面试官在听到这个答案时，都是“会心一笑”，因为“你懂的”。真正的答案只有一个，测试的门槛看似比较低。不管你是否愿意承认，这的确是绝大部分人入测试者这一行的真正原因。

从大多数公司的发展过程来看，测试团队的发展也会大致经历以下4个阶段：

阶段一：公司刚起步，产品初创，需要先把东西做出来获得市场的初步验证，或获得投资人的认可。这个阶段往往还不需要测试人员，即使有也是个把人。

阶段二：公司开始快速扩张，不计研发成本，每天都在不断地招聘测试人员。

阶段三：经过快速扩张后，开始稳定运作，成本开始被考虑。技术部思考如何适度控制成本，如果少量裁员，最先考虑的往往是测试人员。

阶段四：开始严格控制各个环节的成本，老板们开始考虑把测试工作往上游转移。此时大量的新词汇开始进入测试人员的KPI中，例如推动单元测试、开发自测、控制递交测试质量、降低测试独占周期、提升敏捷度，等等。那如何将测试的工作往上游转移呢？

入门容易精通难，这是测试行业现状。从测试行业的从业人员分布来看，绝大部分是黑盒测试人员（以手工功能测试为主），少部分是测试分析人员、自动化测试人员、性能测试人员，只有极少部分的测试架构师、测试分析专家，如图1-1所示。

从一个职业发展的角度，衡量职业核心竞争力有多强，最重要的不是我做了多少年，而是我的工作是否可被轻易取代。所以如果有一天测试行业出现危机，首当其冲的就是金字塔底端的黑盒测试人员。实际上在许多互联网巨头公司中，这个情况已经开始发生了，这部分的人员已经开始被缩减，或被外包取代。

谈到这里，我们再来问自己一个问题，我们的核心竞争力在哪里？

有些人说，我比开发人员精通业务，我善于从用户的视角出发去考虑业务。但最精通业务的不应该是产品经理、产品运营、市场研究人员吗？这好像不算是测试的核心竞争力。

还有些人说，我比公司的业务方更懂技术。这听起来有一些道理，但实际上并不一定成立。要知道开发人员进行需求开发之前，也需要深入了解业务逻辑。的确有很多开发人员在这方面做得不够好，但我们的核心竞争力不应该建立在其他岗位做得很不足的基础上。

有些人说，从技能上来说，我和开发人员相比似乎没有什么太大优势；但在思想上，我才拥有测试思维，这是开发人员不具备的。开发人员来做测试不是能力问题，而是思想问题，这是最难以改变的。这一点听起来似乎的确很有优势。但我们测试人员中，开发技能最好的那一批去哪里了？很多情况下，他们都转去做开发了，并且比一般的开发人员做得更好，也很注重自己的代码质量，测试这些人提交的内容，你几乎很难发现bug。

那么，亲爱的读者，你的核心竞争力会在哪里呢？