谈谈我在自动化测试中遇到的坑

作者/分享人:梅子
向 Ta 提问
10年网络安全产品测试,目前是研发经理,还做过点产品经理。《测试架构师修炼之道》作者,《ios取证实战》译者。绘画爱好者。喜欢涂鸦和彩铅。

本场 Chat 并不打算谈具体的某项自动化技术,这类文章已经很多了不是吗?我想你也不想花十多元来看我再写一遍网上就能轻易找到的那些内容。我只想谈谈我在做自动化测试时的四次经历,谈谈在这个过程中,我是如何把自己带到坑里,再哭着爬出来,泪眼汪汪的又掉入新的坑的故事……最后,我将告诉你我对这些失败经验的思考和总结。

希望我的这些经验,能够帮你少进几个坑。

实录提要:

  • 自动化测试的投入产出比怎么计算?怎么衡量?
  • 如果要达到公司级的自动化测试平台要做哪些准备?
  • 用例覆盖率是如何计算的以及计算时有哪些需要注意的点?
  • 对于敏捷开发中的自动化测试如何定位?
  • 敏捷中的自动化测试如何保证用例的高可用?
  • 做自动化的项目是如何将自动化提前到项目初期的,从流程中做了哪些改进?
已有143人预订
预订达标
文章出炉
交流日期
     
03月08日
03月22日
03月29日 20:30
查看文章评论/提问
baobao
我赞成按照软件架构分层做自动化测试 请教作者一个问题 自动化测试的投入产出比怎么计算?怎么衡量? 除此以外 如果要达到公司级的自动化测试平台 要做哪些准备?只是招聘会做工具或者封装aw的测试开发人员应该是不够的吧
梦婷
所以这真的是需要所有人配合的事,开发,运维,测试,大家同心协力才能搞成的事
梦婷
接上条,触发我们的预发自动化,预发过了,性能回归过了,自己上线。线上有我们定期轮询的自动化,万一出问题,5分钟爆出来,立马回滚。因为我们充分相信我们的自动化,所以测试的主要工作在于随需求变更维护自动化,定位自动化问题,测试资源不足时,开发同学甚至都帮我们改脚本(不要惊讶,这是真的,当然,他们的ut也很完善)。这样我们就可以针对api那一层的系统做到1:15甚至1:20的测试开发比,同时全年没有p1/p2故障
梦婷
然后我的问题是,我是命好遇到了个很配合的开发leader,如果开发运维都不配合,梅子会怎么做?再就是,我们能做到这样是因为我们的系统只依赖数据源,对那些依赖超级多的系统,要做到数据固化环境固化降低定位成本,除了用mock(依赖多的时候用mock好伤)或者在setup的时候做很多这种数据准备环境准备的事(准备时间太长我接受不了,毕竟15分钟必须要让开发得到反馈他的这次提交有没有大问题能不能部署到测试环境)有没有成本更低的方法
刘炜
你说的坑我基本上都踩过[吐],还有一点我觉得就是自动化测试,自动化测试要顶层设计,从需求层面就考虑可测试性,这点项目往往不重视,导致做ST级自动化时受到可测试性的制约,使得自动化实现难度增大,用例不稳定,UT,FT级的自动化也会随着代码框架的设计受影响,一个特性前期不考虑设计和可测试性,流程耦合严重,也是很难做UT,FT
梅子: 对。这两天正在总结可测试性方面的内容,哈哈
梦婷
非常赞同梅子写的这些,想当初我们为了做自动化,一开始是因为Kpi,完全本着覆盖率去,框架选的java+testng或者ruby+xunit,环境依赖测试环境。做出来的东西跑起来很多都因为环境里数据变了或者环境问题,定位的成本太高。后来有幸遇到一个非常有质量意识的开发leader,配合我们一起做新的自动化框架设计,要达到的目的:摆脱对不稳定测试环境的依赖,摆脱对java这种很重的语言的依赖,要让新进来的测试同学开发同学很快上手写用例要能做到真正的持续集成
梦婷
接上条,再加上我的私心(我就是比较讨厌ruby有木有),最后选了python+shell+robotframework+jenkins,开发的系统设计升级,增加对文本型输入数据的支持(以前只支持mysql),我们用文本把数据固化,每次代码改动直接shell打包,部署到自动化回归环境,然后python+robotframework写脚本,打tag管理case,用jenkins做集成,自动化通过以后我们就能相信新系统没有p1-p3的问题,直接触发部署到测试环境,性能环境,然后性能回归开始,开发看到自动化过了,低级别项目自己在测试环境测下,上预发
鬼焱
1.用例覆盖率是如何计算的以及计算时有哪些需要注意的点 2.若一条自动化测试用例覆盖了点ABC,功能用例三条分别覆盖以上三点,这种情况会对用例进行修改么,若修改,偏向做拆分还是聚合?Why? 3.对于Dev beta preview以及online,其中preview和online使用同一套库,这种环境结构,您比较偏向在哪个环境做自动化?Why?
紫贝壳
你好,梅子,对于敏捷开发中的自动化测试你会如何定位?回归还是验证功能?敏捷开发强调迅速反应,所以需求,接口在每次的迭代都有可能改变,一直有个疑问,敏捷中的自动化测试如何保证用例的高可用?自动化应该在何时开始(需求变化快且没有评审阶段)?
依旧四三
关于金字塔,我个人还是比较认同这种模式的,虽然从实施上来说,有不少的外围限制环境会导致实施难度非常高,但结果应该是相对好的,就像谷歌的测试文化,它更多的是偏向于在开发前期阶段,通过搭建更完善的底层测试框架等等手段,去解决一些问题,那么对于您所说的金字塔需要一定的上下文,这个能不能再详细的说一下,谢谢!
狗一样男人
用例尽可能解耦的话会导致运行效率变慢,如何兼顾效率和稳定性
HJ
自动化切入的时间点也很重要。在项目初期,产品软件没有成型,功能没有实现,没有办法做自动化;项目结束才做,自动化当然也就失去了很多意义;所以只能在项目最忙的中期开展,要说服管理者和工程师,为什么在最忙的时候还要抽调人手去开发自动化的工具,真心不容易。
凌俣Linty™
正如作者提到的check 部分很难把握一样,那么请问关于断言的部分,有效等价的用例和无效等价的用例应该用什么样的比例关系呢?如果项目中出现了过多的非预期结果,应该如何解决呢?多谢。
廖浩 Sugie_🚀
如果是这样的情况:创业团队,初期的产品开发并没有专职测试,靠开发跑最基本的UT,产品跑场景测试,这么搞了几个月,直到测试人员加盟——也仅仅是一个测试人员。这样的团队,产品开发的节奏不能慢下来,测试需要尽快对已有的功能做测试,还要兼顾新功能的测试。我知道对于不少测试团队,这是常见情况。请问梅子,如果是你来到这个团岛,你会对这样的团队测试工作做怎样的安排?自动化测试对于这样的初创团队是必要的吗?
HJ
目前测试自动化在大家看来多少有些神话的色彩,特别是当大部分人在做手动测试,少数人在做自动化时,非常常见的是大家觉得自动化很高大上,希望去做自动化的事情,甚至会产生不平衡的心理。梅子如果遇到过这个问题是在团队中如何处理的?
你可能还喜欢
Service Mesh 在华为公有云的实践
田晓亮
从零开始,搭建 AI 音箱 Alexa 语音服务
Mike
Web 安全恩仇录:再谈逻辑漏洞
肖志华
如何用 Vue 实现前端权限控制(路由权限 + 视图权限 + 请求权限)
雅X共赏
智能增长:如何用大数据和人工智能实现业务体量的增长
蒋凡
有关 Mock 的是是非非
思考的犀牛
微信扫描登录