专栏首页测试开发社区自动化测试中的那些误解和偏见

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

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

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

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

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

有一些公司,比如一些初创公司,对测试人员的考核,非要靠一个硬性的指标,比如: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的数量并不能说明质量的好坏。当考核不合理导致出现大量的复制,不合理的设计,大量的冗余,不但难以理解和维护,甚至没有实际运行起来。这样就造成大量的时间浪费,同时也造成质量的严重腐化。

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

本文分享自微信公众号 - 测试开发社区(TestDevHome)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-10-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Selenium Webdriver 3.X源码分析之DesiredCapabilities分布式测试解决方案

    > Selenium Webdriver 3.X源码分析系列第7篇,该系列原则上会将整个源码分享一遍

    苦叶子
  • DeepMind悄咪咪开源三大新框架,深度强化学习落地希望再现

    作为一种新兴的深度学习技术,采用 DRL 面临着简单实现算法之外的诸多挑战,如训练数据集、环境、监测优化工具和精心设计的实验,以简化 DRL 技术的采用。考虑到...

    AI科技大本营
  • 优秀工具 | WebCrack:网站后台弱口令批量检测工具

    在做安全测试的时候,随着资产的增多,经常会遇到需要快速检测大量网站后台弱口令的问题。

    7089bAt@PowerLi
  • A/B测试常见的10个错误

    这是 W. Edwards 的依据名言,它表明,A/B 测试对于做出良好的商业决策来说至关重要。在 Manomano,我们向数百万用户展示数百万 DIY 和园艺...

    AI研习社
  • Pytest之参数化(四)

    懂得UI自动化测试的人,应该都比较清楚ddt的模块,在一个测试场景中,如果是同样的测试步骤,那么使用ddt,就可以使用一个单个测试解决多个测试场景的...

    无涯WuYa
  • Spring Cloud Hystrix:服务容错保护

    在微服务架构中,服务与服务之间通过远程调用的方式进行通信,一旦某个被调用的服务发生了故障,其依赖服务也会发生故障,此时就会发生故障的蔓延,最终导致系统瘫痪。Hy...

    macrozheng
  • 技术分享 | 张贤国:给用户以完备体验的腾讯V265编码器

    ? 在超高清视频画质需求与网络带宽桎梏的博弈中,视频编码无疑是所有公司关注的重点,短短两年时间,腾讯自研服务端编码器V265从最初的原始框架,到现如今的大幅完...

    腾讯云视频
  • Kali Linux Web渗透测试手册(第二版) - 9.7 - 通过HTTP头利用漏洞

    发人员在编程输入验证代码时,往往把重点放在url和请求数据中,经常会忽略这样一个事实:整个请求的参数都可以被修改,所以cookie等http头很容易被插入恶意p...

    7089bAt@PowerLi
  • vue-cli3.0使用及部分配置详解

    让你选的,第一个是默认配置,一般选第二个,自己配置,这里选择最后一个。--------------------(文字对应上面图片)

    小蔚
  • 后selenium时代Web UI自动化测试框cypress

    优点:selenium 的 API 封装遵循 W3C 提供的 webdriver 标准,很好的支持主流浏览器chrome,firefox,IE,Safari等,...

    测试邦

扫码关注云+社区

领取腾讯云代金券