记录一次接口评测的优化
发布时间：2020-03-07 14:55:28 所属栏目：资源 来源：站长网
导读：背景 我们在 测试 过程中往往使用不同的方式评估产品的质量，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。当我们的功能涉及到过量或者无法穷尽的数据时，我们需要针对功能策略或者涉及的算法进行评测。近期小编在的项目组有一个常用接口
|
背景 我们在测试过程中往往使用不同的方式评估产品的质量，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。当我们的功能涉及到过量或者无法穷尽的数据时，我们需要针对功能策略或者涉及的算法进行评测。近期小编在的项目组有一个常用接口需要进行大量数据的评测，以往的评测方式已经不足以支持这次的评测需求，小编记录了下这次优化的迭代过程，一起来看看吧~ 评测工具v1版本： 描述：初始评测工具，集成在单元测试代码中，每次读取评测语料文件夹，每执行一条语料记录一次是否满足准确率条件，最终输出评测结果。 优点： 依赖项目，易操作。 缺点： 单元测试冗合度高，单独执行需要编译整个代码 同步操作执行效率慢 因为单进程且同步执行，执行周期过长，无法满足评测需求，因此需要对评测工具v1进行优化。 评测工具v2版本： 描述：重构评测项目，不依赖单元测试，直接调用评测接口；linux适配；由于评测接口涉及内存读写，目前只支持同步方式，因此编写调度脚本，使用python进程池，根据服务器最大cpu数，多进程执行评测语料。 优点： 1. 冗余度降低、编译快 2. 执行效率提升明显，同样的时间最多可以跑完 （n*最大cpu数）文件，效率提升多倍 3. 评测版本体积小，适配多个版本 缺点： 1. 评测未记录log，发现问题难以定位 2. 未统一格式，需要适配多种数据 评测工具如果没有log日志，一旦数据存疑，将花费大量的时间排查，并且这次需求需要针对不同的语料进行评测，并且为了后续的版本评测，工具的持久可用性，需要优化工具的输入输出接口统一格式。 评测工具v3版本： 描述：统一约定输入格式和输出格式，使用json传递信息，评测脚本不负责计算准确率，只用于记录运行日志，运行后使用日志信息，编写统计脚本，计算准确率等信息。 优点： 1. 格式统一，相当于编写了个工具库，用于适配多种情景数据 2. 日志记录清晰，可以很直观的看到，评测执行每一条语料的进行情况 缺点： 1. 不稳定，使用多种语料评测后，发现大语料容易导致稳定性问题，一旦触发崩溃，则会丢失文件，影响数据的准确性 处理崩溃的能力是评测工具很重要的一部分，不稳定的评测更是对结果造成严重的印象，因此下一次优化主要针对评测工具的稳定性进行处理。 评测工具v4版本： 描述：优化数据处理，每次读写1000条；过程中出现崩溃，更新重跑机制，每遇到崩溃，重跑一次，若成功则继续，若不成功则记录问题数据；更新用户数据的继承能力 优点： 1. 解决崩溃问题，并且能够反馈具体case 缺点： 1. 未记录崩溃栈，有些崩溃无法复现 总结 以上优化就足够完成这次的评测需求，要是想评测工具足够完美，后续我们还准备做以下优化 1. 完成堆栈信息的记录，方便定位崩溃问题 2. 将常用函数与配置文件挂钩，每次根据配置文件完成版本升级和自动化构建 总结： 后续如果要再进行评测工具的优化，需要考虑以下几点： 1. 能够提供足够数据量的支撑 2. 能够完成崩溃问题的处理 3. 最好能够实现评测数据格式的统一 （编辑：东莞站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |