背景
我们在测试过程中往往使用不同的方式评估产品的质量，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。当我们的功能涉及到过量或者无法穷尽的数据时，我们需要针对功能策略或者涉及的算法进行评测。近期小编在的项目组有一个常用接口需要进行大量数据的评测，以往的评测方式已经不足以支持这次的评测需求，小编记录了下这次优化的迭代过程，一起来看看吧~
评测工具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. 最好能够实现评测数据格式的统一
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
