SERVICE


云启未来,智造互联
企业上云升级,助力企业腾飞

济南网站建设公司把所有代码块都进行了条件分析,对它进行进入测试。

发布时间:2019-11-24 11:52:21您的位置: > 网站建设最新签约客户 > 正文



我们的本意是想通过工具帮助测试人员更好完成测试工作,但是我们不想增加额外成本,所以我们把上面部分功能进行模块化拆分,每一步可能是一个命令,一个接口,可以嵌入到CI的过程当中,我们开始嵌入到Jenkins,后来又对接了集团的云平台,因为我们将功能进行了服务化,可以很方便的和外部系统进行对接。

下面跟大家交流一下工具在我们测试工作当中的一些应用情况,下面是一个示例,某天下午我收到的开发的提测,他告诉我这个需求已经部署到测试环境,我可以进行测试了。

我们先来说说这个需求的背景,我们是做汽车电商的部门,基本业务形态是可以在网上买一些汽车相关的产品,比如买一个汽车的抵扣券,你花100块钱买一个2千块钱抵扣券,你出示券码可以在总车款抵扣两千块钱,就像之前团购的餐券线上购买线下消费。
但是汽车电商略有不同,因为它还需要支付大额的尾款,比如说支付20万尾款,这个支付过程时间有可能会比较长,比如有些顾客需要刷好几张卡,如果其中一个卡出问题还需要解决一下,所以支付系统给我们提了一个需求,需要在他刷第一笔款时把券码锁住,避免打款过程中,券码状态发生改变。

这是他大体的需求,从技术维度来讲需要我们提供一个接口,我们对接口进行测试,按照常规测试,与开发聊很多开发的设计和我们需要测试的东西,既然是要试用新工具,那我决定这次换一个方式开始这个任务,我没有找开发直接聊,而是拉了项目覆盖率报告,我们发现都是红色的,这代表什么?代表着这个分支没有被测试过,因为还没有进行测试。

第二个现象是这个项目的覆盖率报告只有一个类被显示了出来,这说明开发只修改了这一个类,所以济南网站建设公司的测试范围就被控制在了这一个类以内,这就达到了缩小测试范围的目的。然后我们再去分析改的这部分代码,我们发现这就是是一个spring MVC编写的接口的代码,前面是各种参数校验,后面是对券码的操作逻辑。

我们先进行冒烟测试,就是拿开发给我们一个URL 和demo参数进行调用,我们将接口测试的数据录入我们自研的接口测试平台并运行,发现接口给我反馈了错误代码4207(提车码不正确)-不可冻结。按照之前的方法我们会直接扔给开发让他们查找原因,现在我们换了一个方式,我们没有直接扔给开发,而是拉了一次覆盖率报告,报告中绿色代表的是被执行,黄色代表部分被执行。我们发现逻辑已经进入了这个方法,然后在第三个IF判断时候进入了报错逻辑,并抛回了错误信息,这个过程有一点像开发的Debug,我们看语句块进入逻辑,发现是券码状态有问题,我推断可能开发给我测试数据时候,可能已经用这个参数进行了自测,已经变成冻结状态了,我再次冻结自然可能就有问题了,我分析出问题的原因,其实问题已经解决一大半了,怎么解决呢,因为我们还有解冻接口,我用同样的参数调用了解冻接口,我发现成功了,说明我们的推断是正确的。

我们继续验证,济南网站建设公司再次调用冻结接口,我发现这次冻结成功了,发现我们的推断是完全正确的。

我们再拉一下覆盖率数据,我们发现已经跳出了上一次把我们扔出去的逻辑,然后进行到底部也就是主逻辑,我们发现这个方法完全被执行了,这个节点在测试中其实很重要,叫做主流程跑通。有些质量要求级别低的项目主流程跑通是可以上线的。




但是我们这时候拉取了整个项目覆盖率情况,我们发现只有62%,我主流程跑通了,但是覆盖率只有一半多一点,这个数据当然不是很理想,没有关系,我们进一步去分析原因,我们需要分析的是里面的红色部分,我们发现红色部分都是异常情况的判断,说第一个校验的是参数合法性,这段逻辑无法进入是因为我们参数合法的,我要进去很简单,我将参数改成非法就可以了,所以我把其中一个参数APPID改为不合法,然后再去调用,我发现有一些不同,给我返回了一个类似Json的信息,但是内部是空白的,这应该是有问题的,因为一个接口可以返回正确也可以返回错误,但是返回空白一定是不正确的,所以我就把问题反馈给开发,开发直接问我哪一个方法你知道吗,我直接把方法贴给对方,因为我跟进覆盖率报告,分析的就是代码级别的东西,所以他根据你贴的代码,就不需要调试直接就定位到问题了,然后修复了该问题。

我们再次用同样的参数组合调用了一下冻结接口,发现反馈给了我们想要的东西,同时开发也表达了他比较激动的心情。为什么会这样?因为你给他减少了工作量,他不需要去调试,不需要重复做你做过的事情了,所以代码级别的一个沟通就会给他省掉很多工作量。

我们如法炮制,把所有代码块都进行了条件分析,对它进行进入测试。

这个校验的是提车码不存在的情况,我们把提车码改成不存在的场景也进入了。这个校验的是提车码的有效期,我们把时间改成过期也可以进入这个逻辑。

其实操作都差不多,就是根据它的条件进入反面的逻辑就能进入到相关逻辑,这是一个信息的状态,这是订单类型,我们改成非法类型也可以进入,非法校验确实很多。当我们把所有非法校验进行了一个测试以后,我们这时候拉取覆盖率报告,发现基本上全变成绿色了,因为所有逻辑我们都进行了覆盖,下面仅有两行红色,我们发现其实是一个异常捕获,就是当你逻辑进行不可预知异常才会进入,这是一个破坏性测试,比如中间掉一个接口报错了,然后我们就会进入这个异常捕获,理论上也可以进入的。

这时候我们再拉一次项目级别覆盖率数据,我们发现自解码已经到97%,分支已经到83%,我们认为这还是不错的覆盖率数据,并且红色部分我们也进行了合理化解释,所以我们觉得这是比较理想的测试结果。

我们复盘一下这个过程,这个工具到底帮助我们提升了什么?首先我前面故意找了一个我不是很熟悉的隔壁组项目来做的。开发只给了我一个URL和Demo参数,我发现我最后得到了一份很丰富的测试用例,我跟测试人员聊了,其实真的是按照传统方式测的话可能其中很多的前置条件还会漏掉,一些异常情况会进入不了。

所以第一个收益是在我不了解一个业务逻辑情况下我完成了测试,并且这个测试是相对全面的。

第二个收益是我在前面测试所有参数组合都录入到我们系统当中,当我需要回归这个接口的时候可能只需要运行上面录得所有接口参数组合就可以了,但是这里我想说的并不是自动化测试,当你多次迭代后,如果你自动化测试没有进行及时的更新,那自动化测试的效果就会越来越差,这时你就会发现自动化的测试的作用会被逐渐消磨掉,我们发现覆盖率监控可以解决这个问题,我们每次执行自动化测试都会关注它的覆盖率。假如说这一次是98%,下次执行是济南网站建设公司发现覆盖率变成了60%,一定是开发加了新逻辑,而你的自动化测试没有更新,那就需要你对自动化用例进行更新了,所以等于我们加入了一个自动化测试用例效果的监控机制。

再说第三个收益,我们在整个用例设计过程当中是有依据的,我们不会随意的删减有效用例,也不会做一些多余的无效覆盖,我们把这叫做精准化测试思想,大家可以看到精准化测试思路在我们测试流程当中,对我们的帮助是多方面的。

再来说说我们的愿景,我们更深层次的复盘了我们的整个流程,发现中间这个工具只是帮助我们去分析了一些东西,但是具体分析和操作还是需要人力去完成的,我们就在想其中一些工作量是不是还可以继续交给工具。我们既然拿到操作覆盖率,我们反过来想我们是不是能够建立代码节点与用例集、用例组的关系,就是当代码改变时候我可以映射出我需要执行的哪些用例。当我们采集到这个关系以后,我们用DIFF引擎把差异代码分析出来,我们直接映射到的就是我们用例级别的测试方案了。

大家会觉得有一点天方夜谭,我们开始也这么想,因为等于把测试策略交给机器去做,我们对这个方案也是充满了顾虑,所以我们加了图中最下面这一行,我们把推荐的用例执行过程进行监控,并根据监控结果回过头来查找推荐本身是否存在缺陷,假如说缺陷是用例不完整造成的,那我们就补充用例,如果关系有问题我们就进行关系调优,最终形成一个自我优化的闭环。

梦之网科技
本文网址:http://www.mzwkj.com/qianyue/1010.html

济南梦之网科技:济南网站建设,济南网站设计公司,网站建设开发公司,专业网站制作公司,拥有专业的技术团队,一流的服务团队.专业团队为您提供网站设计,网站定制服务,公众号应用开发,微信小程序开发,为用户提供成套解决方案,智能农业物联网系统