专项测试怎样才“好玩”

2022-02-11   出处: 测试窝  作/译者:chenkl

今天的话题,从一个真实的故事说起。某年某月某日,笔者带团队去某BU做实施调研时,对方的产品经理提出了一个需求,他说:我们的团队目前没有专职的测试人员,希望借助平台的UI自动化能力,让业务人员也拥有测试的能力,能够参与到自动化测试当中去。然后就提出了一些“需求”:希望能够在页面上录入数据,能够自动验证数据是否正确,能够简单地维护页面元素就好,能够自动判断业务是否展示正常,能够……。你猜最后的结果是什么呢?嗯,什么也做不了。UI自动化又不是全能的,对吧。你以为我是要吐槽这位产品经理么?其实,不是的。

1. 关于测试分层

为什么我不吐槽那位产品经理呢?实际上,很多测试人员也没搞清楚在UI测试层我们应该做些什么。如上图,对于左边的测试金字塔,我相信很多测试人员都很清楚,也很向往自己的团队真的能够做到。但是呢,对于每一层的目标是否清楚?我见过很多人,在单接口测试时,断言做得很简单,而在多接口的场景测试中,加入了大量的非业务断言。在UI自动化中,去做很多数据校验,导致代码臃肿,变得难以维护。如上述两种情况,怎么能算是做好“分层”呢?所以应该对齐下右边的目标是什么。

单元测试:在笔者接触的团队中,做好单元测试的人非常少,所以这方面的实践也比较少。简单而言,对于单元测试,其实和业务的关联性并不太大。在这一层,主要验证的是代码的逻辑是否存在问题,关注语句覆盖、判定覆盖、条件覆盖、路径覆盖等内容。(如有不对,请指教,这方面确实经验少。)

接口测试:接口测试主要分两类:单接口测试及多接口场景测试。

先说第一种,对于单接口的验证,主要集中在接口的返回结构是否与文档定义是否相一致,是否能满足业务需求。同时也关注异常入参、非法入参时,接口是否能正常捕获异常,返回业务可接受的信息(直接抛出代码异常非常不可取,用户体验极差,还有安全风险)。最多,再校验下数据是否正确(理论上数据返回的正确与否应该在数据层做验证,考虑到实际情况,可以放到单接口用例中去做验证)。

再说说第二种:多接口场景测试,在这类测试中,我们应该更关注于接口间的数据传递、数据状态是否正常,数据流转是否正常。断言应该更集中于那些和业务形态相关的字段上,而不是过多地去校验一些没有变化的数据。为什么呢?因为数据结构等问题应该在单接口中被验证,而不是耦合到这里来。

这样做的好处是,当接口发生变更后,我们只需要更新单接口的用例即可,如果影响到接口间的调用,再更新场景接口即可,(通常接口的变更不应该影响到已有业务的调用。即使有影响到,我们也能够快速分析出来,而不是混合在一起,不知道是哪里出了问题)脚本的可维护性会大大的增强。

UI测试:等到了UI层,我们已经不再需要关注业务数据的正确性了,因为在接口层已经做了保证,如果发现问题,应该去补充接口用例,而不是在UI层去校验这些内容。在UI层,我们应该关注的是页面元素是否正常展示,按钮是否可用,交互是否能够正常跳转等体验性的问题。

2. 做好专项测试

在梳理清楚了分层测试的基本思路后,我们再来聊聊专项测试,专项测试一般是指基于某些特别明确的目标而进行的测试。从这个角度上讲,接口和UI也算是专项测试,一些常见的专项测试还包含:性能测试、安全测试、弱网测试、兼容性测试、健壮性测试等等。

接口专项测试:接口测试是测试人员接触、练习代码能力很好的一个入口。关于接口测试,可以参考笔者之前的文章(接口测试平台演进思考、你写的接口脚本合理么)。这里再说一点。接口测试是练习代码能力的一个入口,但现在大家好像都停在这个口子上了,各类接口平台层出不穷(某个200人群,据说基本上人手一个接口平台,吓得我差点退群),都在这里卷,并不是个好现象。测试环节中,还有很多痛点值得大家去解决的。比如测试数据管理、测试环境治理等,期待有新的东西出来。

UI专项测试:关于UI自动化测试的工具,可参考朱老师的文章(https://mp.weixin.qq.com/s/U769tMdt2dvrSccb5br1GA)。
工具并不是主要的,希望大家还记得上文提到的分层思路,做UI层做该做的事。从收益最大化模块入手,优先级:稳定模块 > 有影响风险的旧模块 > 新模块。并做好对于UI自动化测试的预期管理,它并不能一键傻瓜式地解决问题,需要有较好的前端规范,否则脚本维护会是个大问题。

性能专项测试:这些专项测试中,其实性能笔者是做得最久的,现在性能也得到了大家的关注。但是很多人对性能的基本概念理解存在偏差。例如,大家对“并发数”这个指标特别关注,动不动就上百万的并发(双11 才多少),太吓人了。实际上,除了某些特定的场景(抢红包、秒杀等活动),并发的意义并不大,持续压测的过程中,并没有严格意义上的并发(实际的业务中,大多数业务也没有严格的并发,而是持续不断产出压力),我们更多考虑的是TPS或者QPS能达到多少,这就又涉及到业务模型和测试策略的问题了。大家有兴趣可以看看老张的公众号(文末推荐)。

安全专项测试:安全测试需要更专业的技能和知识,一般是由专门安全团队定期进行验证的,这个已经脱离了一般的测试范畴了,简单地使用工具扫一扫,并不能算安全测试。笔者也没有深入了解过,有机会找个大牛写一篇。

弱网专项测试:虽然现在网络的速度在不断地提升,WIFI的覆盖率也在增加。大家似乎都很少遇到弱网的情况。但是在一些特别的场景下,比如人多的地方,比如车库等,还是会存在弱网的情况。所以弱网的专项测试还是非常有必要的。目前在测试移动设备上进行弱网络专项测试的方案主要有3种:

  • Fiddler等通过设备连接到PC上进行弱网络测试

  • ATC、Wetest-WiFi等在专有服务器上构建弱网络WiFi,移动设备连接该WiFi进行弱网络测试

  • 还有一种就是以APP独立存在,提供弱网络模拟服务,如弱网测试工具QNET。

其他专项测试:还有诸如兼容性测试、兼容性测试、健壮性测试等等,就不展开介绍了。

3. 小 结

基于分层测试思路,我们在做专项测试时,需要有针对性地去做验证。其实每个专项展开来讲,都会有很多的内容,本文篇幅有限,主要思考的还是如何去开展这些专项测试,至于工具的使用,现在有太多的工具可选择了。以终为始,希望测试同行们在提升代码能力的同时,不忘初心,记住我们是为了什么目标而开展专项测试,不要让技术偏离业务,而成为炫耀的存在。

今天就聊到这啦,接下来,我们聊点什么呢?敬请期待。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
161° /1613 人阅读/0 条评论 发表评论

登录 后发表评论