自动化测试中的那些误解和偏见

自动化测试是手工测试的唯一出路么？当我想到这个问题时候，我也觉得好笑。医生是护士唯一的出路么？将军是士兵的唯一出路么？

因为最近混了一些论坛以及群看别人的讨论。发现好多人认为自动化测试是测试人员的唯一出路。

工人是农民的唯一出路么？也许是，农民工。为什么想到这个问题，因为发现很多人就是这么认为的，而且认为是唯一出路。

对测试和质量认知有误解的，远不止这个。

有一些公司，比如一些初创公司，对测试人员的考核，非要靠一个硬性的指标，比如：Bug 率,Bug 遗漏率,测试开发比,自动化测试率; 我不知道这些比例是如何计算出来的。

Bug 率：我搜索一下还真有这玩意。 流行的公式主要以下两个： 观点一、bug率=bug数/代码行数 观点二、bug率=bug数/功能点数 我不知道哪个公司蛋疼得统计这玩意。出现bug的因素有很多，比如历史遗留问题，架构设计局限，需求的理解，项目进度，项目资源等。 从考核标准上来说，Bug率数值越小就说明越好，基于这个结果，会引导团队成员做出一些对长远和整体效率无益的行为，例如：

增大基数，增加无意义代码

把定长循环分开写，写成顺序方法

把可配置信息写死到代码中

大量的复制、粘贴代码

重新发明各种轮子

Bug 遗漏率： 质量从来不是测出来的。 系统质量是要靠上游工程做出来的，而且上游的工作质量会更为重要，上游的问题的影响范围将更广，对效率和价值的影响更大，应该是我们重点关注的地方。仅仅依赖下游工程(种种测试)来把质量关，是十分低效，而且代价是非常昂贵的。

开发测试比：

这个比例并不太能说明测试人员的效率，或者公司对质量的重视程度。 基本上每家公司都是不一样的。这个原因有很多，公司传统，领导风格，人员素质，工作内容，等等……如果离开了当前公司的这个Context去谈开发测试比，并没有太多的意义。就譬如说两家公司的开发测试比都是3:1，但是其中一家公司的可能很糟蹋，另一家很高效。谈这个开发测试比例，最好是在相同的类型的公司（创业型VS大公司），相同的行业（互联网VS传统），人员素质在同一个水平，等等。在这些前提条件下，如果发现自己的所在的组织的效率不如其他公司，可以参考同行有什么好的实践，取其精华去其糟粕。开发测试比例只是浮云，整个组织的效率才是关键。

自动化测试率： 对于快速迭代的互联网公司来说，这个还真不好弄，除非你不迭代，测稳定的版本。像以前的传统的大型项目，发布周期特别长，可以弄弄。或者你有足够多的资源，足够人员来弄这个，而且这个是滞后的，可能你某个功能自动化起来了，某次迭代又改得面目全非，投入产出不成比例。而很多人误解就是，自动化测试比例越多，就证明效率越高，越能节省人工。有公司大言不惭的说，我们的自动化测试率是100%。对于简单的测试，可能录制就能达到，真正复杂一点的，你敢全面用自动化来测试么？

OK, 既然把自动化测试抬得如此高，我们来看看自动化测试是何方神圣。

自动化测试的优点：

1、对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。

2、可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。

3、可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。

4、更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例（把节省的人力投入到更有意义的用例设计上） 　　将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。

5、测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。（脚本的复用性）

6、测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。

7、增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。

自动化测试的缺点：

1、不能取代手工测试

2、手工测试比自动测试发现的缺陷更多，自动化测试不容易发现新的BUG

3、对测试质量的依赖性极大（理解：自动化测试脚本的正常运转前，需要先经过功能测试的通过）

4、测试自动化不能提高有效性（理解：主要从维护脚本的花费资源上来看，并不能节省资源）

5、工具本身并无想像力综上所述，可以归结自动化完成不了的，手工测试都能弥补，两者有效的结合是测试质量保证的关键。

自动化测试，说白了，就是监视开发有没有在开发新功能的时候，把老功能弄坏了。 有了自动化，可以做老功能的回归测试，这样测试人员就可以花更多的精力测试新feature. 自动化测试的本质是发现变化的东西对不变东西的影响。

我们来看几个实际的例子： 1、有项目来了，测试小李手工测试与自动化用例同步进行。导致测试排期紧张。这是没必要的，因为自动化不是要跟上变化的东西，恰恰要测那些不变的东西。

2、老大要求每晚都运行一遍自动化用例或者把用例运行100次，因为他觉得自动化用例运行的越多收益越大。这也是没必要的，因为不变的东西证明一次和证明一百次的结果是一样的。

3、某个公司有专门的测试开发职位。其它的业务小组都是独立的。这个测试开发，就没有啥活干。可业务小组的手工测试做不完，回归次次还得手工，业务小组没法指望测试开发帮忙干活，他们不是一个组的，测试开发也不知道哪些业务是可以自动化的，也不会下沉到业务小组里面去。效率一点都没提升，自动化测试就是个花瓶。

4、某个业务小组准备开展UI自动化，测试A担当重任。结果追求代码的完美，每次还需要code review, 层层封装，代码进展特别缓慢，过不久，整个业务全部重新推倒，case完全没法用。对领导可以说实现了多少自动化，有多么漂亮的代码，代码库里面可查。可其他人继续苦逼的做着手工，就连回归也一点没有减轻负担。

5、某个SQA, 对测试开发说，你给我开发一个系统，要方便我统计质量度量数据，需求么，自己想，一个星期交货。结果可想而知。

我们对自动化测试的各种偏见，是因为我们对它的定位不准确。 要么我们将其割裂开来，一个专门的职位，独立于项目组外。 要么分配的任务，无法度量并且超过开发的能力。 要么追求代码上的数量，而实际没什么效果。

如果写个小工具，能辅助提高测试效率，算不算自动化测试？ 如果写个代码，能造一些测试数据，算不算上自动化测试中的一部分？ 其实自动化测试，就是一种测试手段，只是用代码来代替人工。 如果你会自动化测试技巧，不去了解业务，就不知如何将手工测试case转化成自动化测试case. 如果你很精通业务，不了解技术，也就不知道如何能实现将重复的手工测试解放出来。

所以，手工测试和自动化测试是不能分割开的。如果有技术，又做着重复的手工，就一定会思考，如何将其自动化。

手工测试可以转化为自动化测试，但不是唯一出路。做手工测试的，必须要有将其转化为自动化的能力。做自动化的，必须有项目业务背景。

自动化应该是审视软件研发活动的每一个环节，去发现那些可以被工具化自动化的重复性活动，然后去实现。广义的自动化应该包括但不限于以下环节： 测试环境的搭建和管理 测试环境的检查，监控和报警 测试代码的编译和测试构建 测试代码的静态检查和报警 测试用例的分发和执行 测试结果的保存与管理 测试报告的生成 测试优先级的建议

自动化的成本与收益（ROI）

一个过于简化的公式可以这样写：

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

或者如果假设迭代次数和维护次数近似相等，这个在某些情况下可以成立，比如一个比较新的产品： 自动化的收益 = 迭代次数 * (全手动执行成本 - 维护成本) - 首次自动化成本

解读： 自动化的收益与迭代次数成正比 自动化收益可能为负数：即当自动化成本和维护成本比手动执行成本还高时 很多时候自动化成本并不比手动成本高，但是维护成本很高 为什么强调过于简化，因为这里的自动化收益仅仅考虑时间和资源成本的节省。好的自动化带来的迭代周期的缩短，是可以缩短项目周期，在某些时候能变不能做为能做，进而带来的机会收益是巨大的，也是很难量化的。这个就要求决策者对软件工程和自动化有比较正确的直觉和理解。片面追求自动化的资源节省，或者要求精确量化自动化的收益，本人觉得都不可取。

推论1：什么项目适合自动化 下面几种情况比较适合自动化： 回归测试为主的Support Engineering项目，即需要长期做支持维护的产品。或者有过去版本需要长期做支持维护的产品。这种产品（比如企业软件，操作系统等）一个版本在发布之后往往需要支持好多年，做bug fix和patch。这个时候每次小版本的开发都会增加迭代次数，并且每次产品变动都非常有限，维护成本相对偏低，自动化收益就非常好。这也是很多企业级软件或者硬件产品有专门自动化团队的原因。因为产品的支持维护开发的回归测试基本靠自动化 接口比较稳定的产品， 手动测试特别费时费力，甚至无法达到测试目的的项目。比如压力测试，大数据或者大量重复数据测试，必须有自动化工具的支持

推论2：自动化的介入时间点 一个项目的初期可能不太适合自动化。因为项目初期用户界面和接口没有稳定，自动化代码会被动的被要求频繁改变，维护成本非常高。自动化收益不好。而反而手动测试能够快速发现问题，反馈给开发人员。而到了项目后期和维护期，自动化再介入为回归测试做准备，可以最大化自动化收益。

推论3：自动化的程度和自动化率 这里自动化的程度是指整个软件研发活动中引入自动化的程度。推论2中说，有些项目早期可能不太适合高度自动化，但是项目早期仍然可以选定某些环节进行自动化。比如稳定的公用接口，软件的编译和部署，环境的搭建等从一开始就比较稳定的部分。

自动化率同样也要看产品和项目的特性，对于产品的UI部分如果会频繁改动，可以做比较低的自动化。对于接口比较稳定的服务组件可以提高自动化率。

你有什么样的团队，工具和基础设施 其实这个因素是做所有事情都必须考虑的。自动化测试本身就是软件开发。好的自动化测试框架，架构设计很重要。这些会决定自动化的开发成本和维护成本。这些都要求很强的开发能力。如果你的团队只有很有限的开发能力，那么怎么去做自动化，是做最原始的录制回放，还是数据驱动。复杂自动化也需要良好的基础设施支持。比如你有很好的DevOps的虚机管理系统，就不用自己去开发，省下的资源和人力也是很可观的。 工具是另外一块，如果公司有实力支持商业测试软件和管理软件，就可以降低编程要求（当然这会带来一些其他问题）。如果没有办法用商业工具，只能考虑开源和自己开发，这个对自动化测试开发的能力要求就高。总之必须选择和团队，技能储备，基础设施与工具匹配的自动化策略。

管理层的理解程度和支持 这个就不再展开。我见过很糟糕的情况，一个带好几百人兼顾产品技术的VP，越3到4级直接给测试团队提技术需求和建议。你说是做还是不做，怎么做？还有一个团队，自动化测试人员从来没有写过Java或者其他OO语言的程序，被要求从头设计自动化框架，那就是一场灾难。还有一个团队，管理层几次要求更换自动化工具，相当于整体重写自动化脚本。

自动化测试是一个很专门化的领域，自动化测试又是对工程师的技术广度深度要求很高的工作。对于团队管理和决策者来讲，请不要简单化和孤立看待自动测试。最重要的是确保听取真正理解产品，团队和自动化测试的技术人员的判断。

OK, 以下是用Airtest录制的微信小程序自动化测试。

自动生成的代码如下

# -*- encoding=utf8 -*-
__author__ = "anderson"

from airtest.core.api import *


from poco.drivers.android.uiautomation import AndroidUiautomationPoco
poco = AndroidUiautomationPoco(use_airtest_input=True, screenshot_each_action=False)
from airtest.cli.parser import cli_setup

if not cli_setup():
    auto_setup(__file__, logdir=True, devices=[
            "Android:///",
    ])


# script content
print("start...")
poco("android.widget.LinearLayout").offspring("com.tencent.mm:id/dcj").child("android.widget.FrameLayout").child("android.widget.FrameLayout").child("android.widget.FrameLayout").offspring("com.tencent.mm:id/v").child("android.widget.LinearLayout").child("android.widget.RelativeLayout")[1].offspring("com.tencent.mm:id/jq").click()
poco("android.widget.LinearLayout").offspring("com.tencent.mm:id/dcj").child("android.widget.FrameLayout").child("android.widget.FrameLayout").child("android.widget.FrameLayout").offspring("com.tencent.mm:id/v").child("android.widget.LinearLayout").child("android.widget.RelativeLayout")[2].offspring("com.tencent.mm:id/jq").click()
poco("android.widget.LinearLayout").offspring("com.tencent.mm:id/dcj").child("android.widget.FrameLayout").child("android.widget.FrameLayout").child("android.widget.FrameLayout").offspring("com.tencent.mm:id/v").child("android.widget.LinearLayout").child("android.widget.RelativeLayout")[3].offspring("com.tencent.mm:id/jq").click()
poco(text="京豆").click()
poco("android.widget.LinearLayout").offspring("com.tencent.mm:id/dcj").child("android.widget.FrameLayout").child("android.widget.FrameLayout").child("android.widget.FrameLayout")[1].child("android.widget.RelativeLayout").child("android.widget.FrameLayout")[0].offspring("com.tencent.mm:id/ph").click()


# generate html report
# from airtest.report.report import simple_report
# simple_report(__file__, logpath=True)

如何看待这种录制的自动化？个人觉得，在资源缺乏的情况下，这种自动化测试也是很管用的。

为什么对自动化有这么多误解？ James Bach 曾经在一篇博文提到，自动化测试这个名字是非常有误导性的。它让一般的人误以为就是测试完全被自动化了，就像一个自动的咖啡机一样，我只需要把杯子放在那里，按一个button就够了。James说更加准确的叫法应该是“工具辅助的测试”。当然他还有另一层意思，就是好的测试用例是没有办法100%被自动化的，测试人员的经验，逻辑判断和探索性的测试方法都不能被有效自动化。我非常同意这个观点。

作为管理者，就想有个简单的KPI考量机制来考核人。所以会指定一些指标来考核。 作为测试人员，也希望自己的工作更加有价值，自己更加具有竞争力，都会觉得自动化测试是一个比手工测试更体面，更有前途的职位。所以自动化测试能力也是衡量体现自己能力的一种表现。

想做有效的管理，就很难绕开度量的问题。在选择度量指标上，大部分管理者总是倾向于关注容易度量的指标，而忽略难以度量的指标。但是容易度量的指标不一定是重要的，难以度量的反而可能是重要的。 软件开发产出最直观的结论就是一行行代码，实际上代码行数的多少并不代表价值的多少，自动化case的数量并不能说明质量的好坏。当考核不合理导致出现大量的复制，不合理的设计，大量的冗余，不但难以理解和维护，甚至没有实际运行起来。这样就造成大量的时间浪费，同时也造成质量的严重腐化。

说了这么多，提高整个组织的效率才是关键。不管你实现了多少自动化，不论你用何种手段实现自动化，测试的宗旨是在有限的时间和资源内，将可能存在的质量风险尽可能早的暴露出来，并且协助开发尽快解决。