电话:020-66888888
04 为什么要做自动化测试?什么样的项目适合做
作者:admin 发布时间:2020-10-17 19:48

  16 脑洞大开:GUI测试还能这么玩(Page Code Gen + Data Gen + Headless)?

  32 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(上)

  33 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(下)

  39 从小作坊到工厂:什么是Selenium Grid?如何搭建Selenium Grid?

  在上一篇文章中,我为你介绍了什么是单元测试,以及如何做好单元测试,今天我来跟你聊聊什么是自动化测试,为什么要做自动化测试,以及什么样的项目适合做自动化测试。

  不管你是刚入行的小白,还是已经在做软件测试的工作,相信你一定听说过或者接触过自动化测试。那么,自动化测试到底是什么意思呢?

  ,对于最常见的 GUI 自动化测试来讲,就是由自动化测试工具模拟之前需要人工在软件界面上的各种操作,并且自动验证其结果是否符合预期。

  你是不是有点小激动?这似乎开启了用机器代替重复手工劳动的自动化时代,你可以从简单重复劳动中解放出来了。但现实呢?

  自动化测试的本质是先写一段代码,然后去测试另一段代码,所以实现自动化测试用例本身属于开发工作,需要投入大量的时间和精力,并且已经开发完成的用例还必须随着被测对象的改变而不断更新,你还需要为此付出维护测试用例的成本。

  当你发现自动化测试用例的维护成本高于其节省的测试成本时,自动化测试就失去了价值与意义,你也就需要在是否使用自动化测试上权衡取舍了。

  为了让你更好地理解自动化测试的价值,即为什么需要自动化测试,我先来跟你聊聊自动化测试通常有哪些优势:

  版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。

  某些手工测试团队考核的标准就是找到的bug个数,个数越多绩效越好。而开发人员开发的代码,在一些问题上算不算bug有不同的见解。然后就开始扯皮了。

  作者回复: 以缺陷数量来衡量测试的绩效是不可取的,而且还会激化测试和开发之间的矛盾。

  执行次数肯定是远大于5次的,毕竟开发和维护成本都要算进去,收益远超手工测试时才会考虑去做。除非是“面子工程”,用来应付某些场合。

  不过还是很好奇作者的“5次”这样一个分水岭是怎么来的,是否依据经验总结得来。

  作者回复: 5次完全完全是经验值,因为这个主要取决于自动化测试的开发成本,如果你有很好的框架,自动化用例开发的成本比较低,那么这个值就会偏小,如果有你的测试框架很低效,那么开发自动化用例的代价就很大,那么这个值自然就好大

  作者回复: 你说的是正确的,commit之后通常会自动触发静态代码扫描和单元测试,如果两周都通过后、通常会执行自动部署,然后还会自动执行smoke和e2e测试,这些都是自动化的范畴,后面的一篇文章会专门来讨论这个

  作者回复: 是的,你说的这个是很多公司都有的典型问题,懂自动化的不懂业务,懂业务的不懂自动化,必须要让两者能够有机的结合,否则效率很难提高,之前有提BDD其实就是为了解决这个问题,但实际落地过程中大量的mapping又引入了很多新问题

  自动化测试如果由自动化测试架构工程师来牵头实现,辅以业务功能的开发或测试人员构成核心团队,这样的企业级自动化测试的成本和收益应该是线.测试架构师负责企业级核心代码的复用设计及实现,2.项目团队内负责功能共用模块的抽取,3.两者结合建立自动化测试数据池仓库的建立,4.结合项目具体情况做自动化代码实现的二次设计。

  作者回复: 这种短期项目就不太适合自动化测试,对于这类项目的测试重点可以放在如何设计有针对性的测试用例上面,建议可以开展手工探索式测试

  自动化的出发点是提高效率和质量监控。盲目追求所谓的“全自动化”往往得不偿失,应根据项目实际情况做出选择。可退而求其次选择“半自动化”测试,辅助手工测试来提升效率,比如开发小工具来做资源的整合(脚本执行结果自动同步案例管理系统及缺陷系统、批量执行案例生成可视化报告、表断言检查、依赖开源框架搭建性能测试平台等)。

  作者回复: 这应该不是你一个人会有这种感觉,因为第4-6讲不是基于黑盒来谈测试的,而是从软件实现的内部,即从白盒的视角来谈测试,所以需要你具有一定的代码能力,至少能够明白一门高级语言。但是你也不用太担心,因为基于代码的测试我们后面还会有专门的篇幅,那边我会以更多的实例来讲解,希望能够对你有帮助

  作者回复: 你说的是很典型的案例,但是还是建议有最基本的GUI测试当作smoke来用,保证产品基本功能的可用性

  作者回复: 是的,非常对,尤其是数据参数又很多的时候,这个问题会更突出,后面文章我会专门来讲这块

  作者回复: 这个就是目前比较流行的做法,最理想的情况是工程效能团队可以提供更好的工具去支持开发自己做测试,比如提供方便的测试数据准备工具,测试执行服务等等

  我做自动化测试有8年了,从通信到传感器到现在的车联网。通信领域就非常适合做自动化,无非就是造包解包,各种场景都是可以模拟的,可以说自动化覆盖率基本达到百分百

  测试数据的自动化在自动化测试的维护成本中有着举足轻重的作用,我认为测试数据的多样化和自动化也会给自动化测试带来了探索性和智能化的契机……

  我想说尽管是软件产品,它在不断发展过程中,也有项目迭代非常忙的时候,比如测试时间只有不到5天,质量的方针仍然定为接口测试为主,导致最终线上bug率很高,但是至今TL仍意识不到这个问题,规定一个月要写20个接口的自动化测试用例(补齐老用例),并把此列入绩效考评,可这是按量来的事么,测试人员不去看代码实现逻辑,简单的通过入参返回值去写用例,覆盖率难以提升,最终只能收效甚微,变成面子工程。

  作者回复: 一定不是为了测试而去测试,测试的根本在于寻求最高效的方法去发现尽可能多的问题,如果单单以用例数量做为衡量标准一定会本末倒置,用例不在于多,而在于针对性和全面性

  结合用例和脚本自动生成计划,GUI和API都可以减少编写成本,不过个人对于智能技术在这里会是一个很重要的应用场景,具体怎么落地还没想明白,但大家可以多沟通研究下。

  作者回复: 你说的很在点子上,后面的一篇文章就会专门讨论这个话题,后续我也还会在适当的时候来谈“如何自动化你的自动化测试”

  作者回复: CI/CD应该属于devops的范畴,CI/CD往往是自动化测试的发起者,关于广义的我自动化测试,在下一篇文章中我会详细来展开

  1.一直有推进自动化用例覆盖率,但是经常改动的部分需要自动化用例频繁同步更新,不经常改动的部分,自动化的必要性又不大;

  2.GUI 改动多,但是实施难度大,就好比茹老师提到的图形验证码的例子;

  3.测试开发和业务测试是分开的,导致懂业务的不懂实现,懂实现的不懂业务;

  1.优先考虑 P1 优先级的用例覆盖,以及需要经常回归的功能点的自动化用例覆盖;

  3.测试开发负责架构实现,并设计好必要的分层,业务测试负责自动化函数需求的提出和调用;