前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >结对测试算法性能优化(用例设计层面)

结对测试算法性能优化(用例设计层面)

作者头像
dongfanger
发布2020-09-23 09:53:10
3400
发布2020-09-23 09:53:10
举报
文章被收录于专栏:dongfangerdongfanger

在《parewise算法性能优化》一文中,

对原来算法代码进行了一些优化,

对于笛卡尔积后千条数据,是能满足使用需要的。

但在实际业务中,会碰到百万数据。

比如某接口共18个参数,每个参数均可为空,其中8个只需要单个值,10个为多选项,需要多个值。

对于多选项,我的设计是,全选+随机n个多选(1<=n<=len-1)+空。

按照这个策略,笛卡尔积的结果就是38*210=6718464。

671万数据!

parewise根本处理不动。

该怎么处理?

调整用例设计。

1、为空的情况,单独一条用例,即可以为空的,全部设置为空。parewise就不考虑为空的情况了。

38*210就变成了28*110=256,一下量级骤减。

2、视需要添加特殊的参数组合。

即使这样优化了,也会产生几十种组合。

假如接口本身响应慢,那么脚本执行的耗时就比较长。

遇到上线前回归,等待,是一件很痛苦的事。

该怎么处理?

还是回到用例设计。

在开发阶段,跑几十种组合的脚本,从时间成本来看是完全可以接受的。

在上线阶段,时间紧迫,就会显得效率有些低。

而实际上,上线前回归阶段更像是一种冒烟。

是可以适当降低覆盖度,提供效率的。

于是解决方案就是,把parewise扩展为两种模式

代码语言:javascript
复制
def parewise(dx, mode=2):
    """
    :param dx:
    :param mode: 1开发 2上线
    :return:
    """

开发模式:就完完整整返回结果

上线模式:从结果当中,随机返回1条用于快速冒烟

当然,如果是回归要测修改引入,建议还是多花点时间,老老实实跑开发模式比较好。

版权申明:本文为博主原创文章,转载请保留原文链接及作者。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2019-10-27 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档