专项测试怎样才“好玩”
01 关于测试分层
为什么我不吐槽那位产品经理呢?实际上,很多测试人员也没搞清楚在UI测试层我们应该做些什么。如上图,对于左边的测试金字塔,我相信很多测试人员都很清楚,也很向往自己的团队真的能够做到。但是呢,对于每一层的目标是否清楚?我见过很多人,在单接口测试时,断言做得很简单,而在多接口的场景测试中,加入了大量的非业务断言。在UI自动化中,去做很多数据校验,导致代码臃肿,变得难以维护。如上述两种情况,怎么能算是做好“分层”呢?所以应该对齐下右边的目标是什么。单元测试:在笔者接触的团队中,做好单元测试的人非常少,所以这方面的实践也比较少。简单而言,对于单元测试,其实和业务的关联性并不太大。在这一层,主要验证的是代码的逻辑是否存在问题,关注语句覆盖、判定覆盖、条件覆盖、路径覆盖等内容。(如有不对,请指教,这方面确实经验少。)接口测试:接口测试主要分两类:单接口测试及多接口场景测试。先说第一种,对于单接口的验证,主要集中在接口的返回结构是否与文档定义是否相一致,是否能满足业务需求。同时也关注异常入参、非法入参时,接口是否能正常捕获异常,返回业务可接受的信息(直接抛出代码异常非常不可取,用户体验极差,还有安全风险)。最多,再校验下数据是否正确(理论上数据返回的正确与否应该在数据层做验证,考虑到实际情况,可以放到单接口用例中去做验证)。再说说第二种:多接口场景测试,在这类测试中,我们应该更关注于接口间的数据传递、数据状态是否正常,数据流转是否正常。断言应该更集中于那些和业务形态相关的字段上,而不是过多地去校验一些没有变化的数据。为什么呢?因为数据结构等问题应该在单接口中被验证,而不是耦合到这里来。这样做的好处是,当接口发生变更后,我们只需要更新单接口的用例即可,如果影响到接口间的调用,再更新场景接口即可,(通常接口的变更不应该影响到已有业务的调用。即使有影响到,我们也能够快速分析出来,而不是混合在一起,不知道是哪里出了问题)脚本的可维护性会大大的增强。UI测试:等到了UI层,我们已经不再需要关注业务数据的正确性了,因为在接口层已经做了保证,如果发现问题,应该去补充接口用例,而不是在UI层去校验这些内容。在UI层,我们应该关注的是页面元素是否正常展示,按钮是否可用,交互是否能够正常跳转等体验性的问题。
02 做好专项测试
在梳理清楚了分层测试的基本思路后,我们再来聊聊专项测试,专项测试一般是指基于某些特别明确的目标而进行的测试。从这个角度上讲,接口和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。
其他专项测试:还有诸如兼容性测试、兼容性测试、健壮性测试等等,就不展开介绍了。
小 结
基于分层测试思路,我们在做专项测试时,需要有针对性地去做验证。其实每个专项展开来讲,都会有很多的内容,本文篇幅有限,主要思考的还是如何去开展这些专项测试,至于工具的使用,现在有太多的工具可选择了。以终为始,希望测试同行们在提升代码能力的同时,不忘初心,记住我们是为了什么目标而开展专项测试,不要让技术偏离业务,而成为炫耀的存在。