zoukankan      html  css  js  c++  java
  • 结对测试算法性能优化(用例设计层面)

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

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

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

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

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

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

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

    671万数据!

    parewise根本处理不动。

    该怎么处理?

    调整用例设计。

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

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

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

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

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

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

    该怎么处理?

    还是回到用例设计。

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

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

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

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

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

    def parewise(dx, mode=2):
        """
        :param dx:
        :param mode: 1开发 2上线
        :return:
        """
    

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

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

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

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

  • 相关阅读:
    python数据结构之字典
    Python数据结构之列表
    使用QrCode生成二维码
    JavaScript在不同环境下的全局对象
    记一次使用 removeEventListener 移除事件监听失败的经历
    Model、View、ViewModel结构以及全局视图模型注入器的说明
    MVVMLight介绍以及在项目中的使用
    WPF/Silverlight深度解决方案:(一)解锁被Storyboard束缚的关联属性
    进程发送消息
    .net4.0中wpf单例启动
  • 原文地址:https://www.cnblogs.com/df888/p/11747637.html
Copyright © 2011-2022 走看看