最近在做接口自动化的工作,做了很久,做了很多用例,但是感觉对测试工作没有任何帮助,有点迷惑,特来讨教。

首先我们公司是做大数据,卖数据库产品的,公司体量很一般。
个人其实测试理论很薄弱,只会执行上面给的任务,现在赶鸭子上架,闷头搞了很多,还是不得要领。
涉及到的接口主要是检索,会有很多入参,出参数据量也很大,接口内部的数据处理逻辑还是有点繁杂的,接口间的关联性不是很大。
首先,生产环境不让跑,只有测试环境可供部署,数据跟线上差异很大,线上环境,老板一万个不允许!
目前的策略,在测试环境Daily,上线前在测试环境跑一遍。然后大部分问题就是,环境崩了啊,服务挂了啊,在刷数据啊,去维护用例啊。
然后,这样做了很久,我不知道自己在干嘛了。这一套做下来,感觉好像没有任何用。
我有很大的疑惑
1、自动化用例最大的作用不应该是监控么,每天在测试环境巡检有什么意义呢。
2、迭代发布的时候跑一遍。在什么情况下,这一个环节能在测试环境反馈出问题?更何况,改动的地方经过了测试,甚至自动化用例也重新设计维护了,几乎100% ok的,没改动的地方,它能发生什么呢?这一环节,难道不也应该是去针对线上发布么,去验证发布有没有问题么…
3、关于校验方法,全字段校验不现实,数据每天都有可能不一样;或者说通过写sql去完整实现开发的逻辑,查询到后台的值,去替换预期值,再。。。这也不现实。
我目前设计了很多种方法,做到了通用,查一个人,就check有没有这个人,也有去做数据库查询但更多的也仅仅是简单的count(*)。但是在这种情况下,我又对上面说的那条,作为上线前的保证,产生了更大的质疑。我觉得,要依靠它替代测试,那接口的后台逻辑全都要,至少针对当前字段的,得摸清,并用同样的逻辑在用例里实现才可以,这个定制程度就高了,用框架是做不出来的。
鉴于以上种种,我觉得目前我做的这么多东西,除非接口不通了,不然好像确实没得什么用,以下想了几种情况:
1、某开发,睡觉时摁到了delte却没人发现(不存在)
2、代码有复用,改了一块儿,别人那儿没改(还不一定能发现)
3、其它莫名奇妙的多因素引起的bug导致接口不通
目前扑在上面一个季度多,丝毫没感觉到用处在哪,请教了同事领导,但都没有较好的指点,我已经有点怀疑自己了。

1 Like

从量变到质变需要一个过程,这期间一年左右的积累,还是必要的。超过了,就得深入进去了。

这种测试也是很经典的测试场景,把业务逻辑和算法摸清楚是其实就可以提高能力。

老板不让跑,说明有他的业务考量,也可能是对的。如果线上不让跑,你可以搭建stage预发布环境,结合线上流量同步来充分的模拟线上环境。

这也侧面说明了,你们需要独立搭建一套预发布环境。

自动化测试的最大作用仍然还是测试,监控只是一个作用之一。你的巡检在测试环境就相当于是简单的冒烟,也有价值,只是要排除误报。预发布环境也需要巡检的,产生不了作用是因为误报太多,而误报多的原因就是你们没有独立的预发布环境,

建设你有个100个功能,发布后没问题,接着研发更新版本,你100个功能手工测试的成本,可以通过自动化替代。如果代码出问题,你的自动化测试用例就可以以最低的成本发现问题。回归测试是自动化的价值之一。

如果发现不了bug,你需要做出判断,是你们的研发团队很牛逼没bug,还是你的自动化测试用例设计有问题,或者是你们的自动化测试滞后于手工测试,bug被手工测试提前发现了?就算不在线上运行,自动化测试依然是可以发现bug的。

自动化测试和手工测试本质都是测试,只是执行形式不同。大部分公司的自动化测试问题之一就是自动化测试很简单,没有手工测试那么深入完备。

全字段检验是必要的,数据不一样你怎么知道是对,还是错,所以才是需要校验的。比如百度的搜索,出来100页记录,还是出来101页记录,虽然每个记录都对,但是数据量不对,其实就是一个很大的问题。代表了召回率的问题。

自己写sql判断也是有问题的,因为你自己写的可能也有bug,用一个可能有bug的算法去检验另外一套可能有bug的算法,是一个办法,但不是一个稳妥的办法。

一般的做法

  • 测试场景设计,你得自己维护一套完备的测试数据模型,利用这套数据去校验各方面的结果。比如测试百度,我们得自己设计10000条原始数据,其中100条是我们故意插入的跟特定关键字相关的数据,然后检索,判断搜索到的结果是不是全部找到,判断每条数据与原始数据是否一致等等。
  • 利用diff对比,跟类似算法进行对比,比如用百度的搜索结果和google的搜索进行结果测评,看谁更精准。你设计一套sql,本质是类似的。这个是参考方法之一,有我前面提到的问题,不能作为主要方法。
  • 全量回归结合基准测试,每次跟上个版本对比,每次更新,检索的结果跟以前有什么变化,指标是提升,还是下降。其实是就是自身跟自身的历史版本对比。可以快速发现问题。

从你的做法来看,你的测试设计肯定是没法发现深层次的bug的。比如你们的代码出问题,有些数据查不出来,你只判断了查出来的结果是正确的,却没去判断是不是还有数据没有查出来。还包括性能,如果性能下降了,你其实也没测试。到时候上线了肯定会引发问题。每个字段你也没深刻检查。

至少我能看到的改进点就有如下几个

  • 你可以从你们的历史bug和历史故障去看看,这些问题的形成原因,并设计对应的测试用例
  • 构建自己的基准测试数据体系,构建经典测试场景
  • 看你的算法是不是可以用简单的类似算法进行参考检验,用近似sql也是一种对比方法
  • 构建预发布环境
  • 建立全量回归基准测试体系
  • 完善你们的自动化测试断言
  • 自动化测试要用在手工测试之前
2 Likes

非常感谢思寒老师指点迷惑,以上老师指出的几点感觉还需要吸收跟理解,我决定暂时停下无脑的制作与维护,思考下改进方向与策略。

关闭