一盏小灯 2019 TesterHome 广州第一期沙龙--一些感想

Jerry li · May 05, 2019 · Last by Jerry li replied at May 07, 2019 · 1934 hits

前言

上周冒着大雨到唯品大学旁听了2019 TesterHome 广州第一期沙龙。这期沙龙的三个主题自己的工作中都或多或少有接触到,受益良多。把自己的感想记录一下。

关于接口自动化

第一个主题是关于接口自动化测试的实践。正好过去半年自己的团队也正在做接口自动化相关的工作,也用jenkins+pytest+allure 搭建起了一套每日运行的接口自动化框架,所以其中的收益和难点,自己也有遇到过。在听这段分享的过程中,其实也在对我们的框架搭建进行一个简单对比和工作回顾。

1.效率的提升:

分享中提到通过自动化测试,可以很大程度提升回归测试的效率。以往需要逐个功能点点点去进行回归测试,现在只需启动测试,然后等待一段时间即可看到完整的报告。这是生产力促进生成效率的体现,也是做自动化最大的价值所在。

2.关于全数据自动化校验:

分享中一个比较吸引我的点是全数据自动化校验的方案:

  • 使用同一套参数先后发起两次请求,并对比其中返回值。将其中没有变化的参数,和有发生变化的参数分别保存起来,作为以后回归测试的验证模板。

正好我们的接口测试框架中也有做这部分的设计:

  • 同一个接口,使用同一套参数分别请求生产环境和测试环境,并对比两个环境的返回值。如果返回值中不变的参数是符合预期的,则认为这个接口在测试环境与生产环境一致; 否则,说明测试环境的接口发生了变动。

这里共同的逻辑就是:假定生产环境的接口返回值是正确的(已通过了功能测试),并先后请求两次后,将对应的值进行对比后生成验证模板。

扩展: 如果接口文档设计比较完整,我们可以在开发之前就填写好对应的参数模板,直接作为开发阶段的测试用例进行执行,而无需根据生产环境的接口作为参考值。

3.对工作的启发

  • 优化对返回值校验的方案。

- 造数平台及对外服务化:为整个研发团队提供服务。

关于引流压测

第二个主题是线上引流压测的实践。我们在日常工作中也会对部分功能进行压测,但和大厂的压测相比,差距明显:

1.数据真实性

我们日常工作中的测试数据,往往是模拟的单一假数据;线上引流,使用的是线上真实产生的数据。虽然经过了脱敏,但数据真实性、完整性、丰富度上,都比我们模拟构造的数据要强很多。

2.环境差异

我们日常的压测,通常是找一台内部的测试服务器来进行压测;而分享中提到了很多关于环境的模拟,如下游接口返回时间的模拟;redis 等服务的模拟预热;使用mock 模拟下游服务等。环境越接近生产环境,测试结果的准确性也越高,参考的价值越大。

3.资源差异

大厂可以长期投入几个测试资源去持续开发、维护一套压测系统,而我们小团队只能在满足日常迭代开发的空闲时间里去做一些简单的研究和工作。其实听完这个分享后启发很大,有很多思路;但在目前的团队中,只能先挑重要的做起来,其余的还是有心无力。

4.对性能工作的启发

  • 测试数据:使用更丰富、更完整的测试数据,尽量贴近生产场景
  • 压测环境:用mock 、预热等方式模拟更贴近生产的运行环境

关于云测平台

我们日常工作也有使用到云测平台:android 包升级之后,传到阿里云测上用免费的额度跑一遍,然后把对应的报告发给开发,检查一下对应日志是否有异常; 同时测试人员也简单看下报错、闪退、截图等。

但这个云测平台的分享,要解决的问题和大部分中小公司都不一样:真正意义上的云真机-- 不仅要是特定的机型,还需要有特定的运营商网络。

然后分享内容主要是关于如何克服各种难点的:网络、流畅度、音视频传输,等等。只能带着羡慕的眼光膜拜一下,一般的公司是没有这个成本资源做这些的。

或者什么时候可以对外开放,让我们这种小团队也能共享真正意义的云真机?

总的感想

1.小团队的大而广 vs 大团队的专而精

小团队由于资源有限,往往每个人都被迫要做到大而广:

  • 测试业务覆盖面大
  • 测试范围涉及度广
  • 什么都要做,但是没有资源、精力做到精致

大团队:

  • 允许投入专业团队、小组做专业的事情,例如上面的云测平台、引流压测平台
  • 业务容错率更低、用户数量级更高,对于测试的精细度要求更高

2.效率优先

不管是小团队还是大团队,其实大家做的事情都是为了提高工作效率:

  • 小团队优先做接口、UI自动化,提升业务回归测试的效率
  • 大团队可以开发出效率更高的工具供不同的业务部门使用,提升整个业务体系的效率

3.回归自动化测试的本质

在分享过程中,听到不少的问题:

  • sql 注入属于接口测试吗?
  • 收集到真机奔溃的日志有什么用?
  • 在敏捷开发的模式下,如何推动自动化测试?

其实按我的理解,这三个主题,大家在做的都是回归测试的自动化(从接口、性能、兼容性等不同角度的自动化回归测试),因此都要回到回归测试和自动化测试的角度来解读:

  • 回归测试的目的是验证原有功能是正确的,而不是为了找到新的bug(期望找到新的bug,还是要在功能测试、设计用例的时候下功夫)
  • 自动化测试的范围要经过筛选,而不是直接全部功能测试用例的自动化实现(投入产出比和运行效率、维护成本)
  • 自动化测试最终目的是提高效率,是加分项;不要因为要做自动化而忽视了常规的功能测试
  • 测试工具没有最好,只有最适合自己。因此每个团队在全盘推广之前,还是要先做好试点和研究。

4.别埋头做,多抬头看

别闭门造车,多看看别人做的事情。很多你苦思不得其解的难题,说不定别人会给你启示,甚至已经为你提供了解决方案。

写在最后

这是第二次参加广州的测试沙龙分享了,每一次听完分享都能得到不一样的启发。

非常感谢主办方、各位讲师和各位志愿者的付出。感谢社区提供的平台,祝社区越办越好!

共收到 19 条回复 时间 点赞

楼主写的很棒!

全数据校验数据比对方式,现场没来得及问,你搞清楚没?是直接两个文件比对么?还是把两个文件数据读出来,一行行去比对

Jerry li #3 · May 06, 2019 作者

我的理解是: 同样的参数,先后发两次请求,并对比两次的返回值,并生成下图的校验文件,里面记录了每个字段是否需要对比(第一行的 1和 0); 以后测试同一个接口时,把返回值和校验文件进行对比, 1 的就必须和文件保存的值完全一致, 0 的就可以不一致(即跳过)

Jerry li #4 · May 06, 2019 作者
nicklasyao 回复

看我上面的截图

说实话,我更多的想看到系统平台的实际演示;或者项目能够开源出来让大家一起研究,这种分享我看得一头雾水哎

Jerry li #6 · May 06, 2019 作者

可能因为这三个主题的分享内容我都有接触过吧, 感觉里面遇到的问题、思路、解决方法还是挺好理解的。 不过只看PPT 会比现场听到的信息少很多。
至于实际演示,这个涉及到一个是场地环境限制(不一定能接触到对应公司的内网),另一个也是机密信息,不一定方便透露。分享的目的,还是把新的思路、方法,以及取得的效果分享给大家。像我就从其中得到不少启发。

至于开源吧,这么庞大的系统一来脱敏、公司政策之类的不允许,二来那么多代码开源出来,不一定能起到多大的参考价值,毕竟不是所有团队都适合搭建和维护这么大的系统。

Jerry li 回复

这类校验对数据查询方面的重构回归很有效,请问一下对于插入和更新接口有什么比较好的方案吗?

Jerry li #8 · May 06, 2019 作者
AzoraLeo 回复

插入和更新的接口,返回的数据格式也是固定的吧? 例如code、msg等

Jerry li 回复

嗯,是这样,不过这种就只是格式的校验,不像查询一样还能校验值的正确性

Jerry li #10 · May 06, 2019 作者
AzoraLeo 回复

嗯,其实就像正常的接口测试一样,只从返回值是没办法判断数据是不是真正插入到数据库,对吧?

Jerry li 回复

是的,正常回归测试这样应该足够了,大规模重构的时候还是需要再看数据库数据的

感谢对广州沙龙的支持!

我们也有一直在收集小团队和落地容易的 topic ,但一直没找到合适的。如果您有兴趣,下半年的沙龙来分享一下?

Jerry li 回复

哈哈,楼主可能对我有点误解,我有到现场的,并且也认真听啦!接口自动化,云测也弄过
表扬一下阿里的同学,实力真的很强,很多问题回答的很专业!比如手机连接太多导致系统不稳定的问题,我们也遇到了,给了我们启示!阿里的同学好像之前在北京见过,不知道我说的对不对

说明你离全栈太远了。接口自动化怎么回声和重连。云测stf优先二次开发的点和node版本要求?

Jerry li #15 · May 06, 2019 作者
陈恒捷 回复

感谢邀请,不过我们现在做的事情比较杂,暂时没整理好可以分享的头绪 😂

从以往的经验来看,能在现场做到系统平台实际演示和甚至开源,这类极为稀少,属于可遇不可求。至今只遇到过一个技术导向型的国外创业企业有这种 topic 。

原因有几个:
1、包括唯品会、阿里在内的大公司,topic 分享公司内部都会严格把控。平台演示一般也就只能事先录制视频进行播放,现场演示由于网络、内网平台容易包含敏感信息等原因,至今我都没见到过。
2、目前国内大部分公司对开源比较谨慎,除了有意打造技术生态或者技术品牌,大多都没怎么开源。

这个现状暂时不大容易打破。如果您有能做到这方面的 topic,欢迎投递,来沙龙一起分享。

Jerry li 回复

没事,这个理解。您文中提到的接口测试框架,以及您以前在社区分享过的平台、框架以及在实际项目中的实践,其实都可以分享出来的。

如同沙龙开始介绍所说,人人都是老师,人人都是学生。我们期望把沙龙打造成一个大家不仅能通过其他人的分享收获启发,也能通过自己做分享收获分享的喜悦及和其他同学交流的机会。只要您的想法有意思,工具/框架在项目中有实践落地、产生价值,都欢迎来进行分享。

我没有抢到名额去参加,有点遗憾,最近公司的确有些忙,没有经常看testerhome了,不过从上面的讨论中,有些困惑我的地方,我终于得到了答案,去到现场我可能得到的更多,哎,甚是遗憾!

Jerry li #19 · May 07, 2019 作者
陈恒捷 回复

好,我先试着整理一下

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