一盏小灯 关于自动化测试的问与答

Jerry li · January 30, 2019 · 1286 hits

前言:

自动化测试是测试行业里一个古老的话题。简单总结一下自己的一些思考。

问题1: 什么是自动化测试?

自动化测试是软件测试的其中一种手段。特定是在于自动化:

  • 自动化执行:以程序的方式替代手工执行用例步骤。所以一条用例可以完全自动化执行。

  • 自动化记录执行结果:执行过程中可以通过断言来判断用例是否执行成功,并将结果记录下来。

  • 自动化触发:通过与Jenkins 等 CI 工具集成,可以根据条件自动触发任务执行,完成测试。

个人观点:自动化不是什么神秘、高大上的技术,归根到底还是一种测试手段。

问题2: 什么情况下适用自动化测试?

自动化测试的目的是以机器执行,节省人工执行的成本,所以测试执行的次数、频率越高,越能体现自动化的价值。常见的使用场景:

  • 迭代次数较多的项目。这样每次在迭代开发时,都可以发挥自动化的作用,快速回归测试,发现问题。

  • 长期维护的项目。项目上线运行过程中可能需要进行一些优化和bug 修复,在版本更新时自动化测试也可以节省一部分的手工测试工作。

个人观点:只要是有重复性的执行(即使可能只跑3-5次)或者是需要跟进维护的项目,都有自动化的价值。

问题3: 自动化测试=UI 自动化吗?

虽然提到自动化测试就会想到QTP、 selenium 等UI 自动化测试工具,但自动化测试的范畴并不局限于UI自动化:

  • UI 自动化。与用户场景以及传统的黑盒手工测试场景最为贴近,常见的工具有QTP、selenium等。

  • 接口自动化。随着微服务框架的流行,前后端、甚至后端不同服务间的开发分离,接口的功能稳定越来越重要。因此越来越多的测试团队开始重视和搭建接口自动化框架。常见工具有jmeter、loadrunner、postman、python request 等。

  • 单元测试自动化。单元测试也是自动化的一种,可以在代码编译期间完成对应的测试,快速发现问题。

  • 性能测试、兼容性自动化。目前主流的 app 都需要在云测平台上进行兼容性测试,其实所在的就是兼容性、性能的自动化。

  • 数据自动化生成。有时候因为业务需要,需要制造大批量的数据,这时可以编写一些相关的脚本,快速生成。

个人观点:任何重复劳动,都可以想办法用工具来辅助。

问题4: 自动化测试可以替代手工测试吗?

自动化测试能否代替手工测试,取决于以下几个条件:

  • 自动化用例的执行是否可靠?即设置的断言是否完整、测试结果是否可信。

  • 自动化用例的健壮性是否足够?即能否保障频繁的重复执行 。

  • 自动化用例的覆盖面是否足够?正常情况下是没办法把所有的场景都在自动化用例中实现(受编写用例、维护用例的成本限制)的,所以常见是把重要功能用自动化用例覆盖,配合部分人工执行,来完成回归测试。

个人观点:自动化测试是手工测试的辅助手段,两种可以结合起来使用。

问题5:项目时间紧的情况下,能不能做自动化测试?

这是很多团队或者测试人员拒绝使用自动化测试的理由:都在加班测试了,哪有时间做自动化?

但其实自动化是一种提高测试效率(机器执行比手动执行效率高)、确保测试覆盖面(手动执行可能会受疲劳因素的影响导致漏测,而机器可以保障设计的用例一定会执行)的工具,合理地使用自动化测试,可以把测试人员从重复、枯燥的执行中解放出来(不能完全解放,也能节省一部分的工作量),把精力投入到其他的方面。

个人经验:抽出半天时间把基本功能用例转换成自动化用例,可以节省不少的回归工作!

问题6:这个自动化测试工具可以解决我们的所有问题吗?

这是另一个拒绝使用自动化测试的常见理由:你的框架或者工具不完美,我不想用。

没有任何一种工具可以完美解决你所有的痛点。只要能解决对你最重要的其中一个痛点,就值得去推行,然后在实用中发现自己的需求和更多痛点,不断改进。

个人观点:勇敢迈出第一步最重要。

问题7:自动化测试根本发现不了bug ,价值不大。

针对这种想法,可以延伸到这个问题:

  • 测试的根本目的是什么? 是为了发现bug ,还是为了确保大部分使用场景下没有bug?

  • 平时做的回归测试会发现很多bug 吗? 如果没有bug ,是不是就没有价值?假如自动化测试执行了100个用例,没有发现bug ,是不是代表这100个用例没有价值?

个人观点:测试的目的是质量保障,就是保障正常场景没有问题;只要验证了对应的点,就产生了价值。

问题8:你不是做了自动化测试吗?为什么还会有bug 漏测?

自动化测试本质上还是测试用例的另一种执行方式。因此如果测试用例覆盖面不够,不管是手动执行还是自动化执行,都不能避免漏测。

个人观点:自动化测试不是万能。自动化省下来的时间,还是要花在进行更多手动测试上。

问题9:自动化不就是简单录制和写一些代码嘛,没什么技术含量。

自动化测试的入门介绍往往是很简单的,QTP 的录制回放、selenium的各种语言版本 helloworld教程,都能在很短时间里照着实现。

但当你在慢慢做下去的时候,就会遇到以下的问题:

  • 为什么用例有时报错,有时又问题? 这是用例健壮性需要好的设计。

  • UI 改了一个界面的按钮,要修改十几个用例? 这是用例结构需要设计合理。

  • 200个用例跑了2个小时? 用例的执行效率需要提高。

  • 用例跑完之后不好统计结果? 需要合理的报告统计。

个人观点:talk is cheap, show me the code!

问题10:不就是敲代码吗,找个应届生两个月就入门了;还是先把用例设计什么的基本功做好吧!

各种测试工具和用例设计一样都是测试的基本功,都可以为提高测试效率和质量保障起作用。

个人观点:技多不压身;在测试行业,仅有一技之长是不够的。

No Reply at the moment.
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up