关于如何提高回归效率的讨论

大概三周前，推送了一篇关于验证回归的文章：

原创 | 蚁群算法在验证用例自动化回归中的应用

，文章被转发到了验证工程师群，引起了小范围的讨论和质疑，比如有人问这样做的实际意义是什么？和现有的lsf有什么不一样？更多的做法难道不是让脚本自动从用例池中选择用例来回归吗？

这个方法或许有很大的局限性：假设回归任务只在一台服务器上执行，或者没有部署lsf的多个服务器上。实际上我使用这个方法的场景就是仅仅有一台服务器。

以往的回归方法是给进程平均分配用例个数，再高级的可能就是根据字典序或其他排序方式，将用例维护到一个队列中；然后，让让脚本自动从队列中取用例，完成一个删除一个。但是，不管哪种都有一定的随机性。而如果我们已经获得了用例的执行时间，那么这些时间是否可以用来指导我们后面的工作呢？基于这些思考，才有了这么一个蚁群算法的应用。这种方法可以和刚刚提到的脚本回归结合起来，将优化后的序列送给脚本，让脚本控制进程的运行，每个进程再从若干个序列中调度用例进行回归。

兼听则明，因为公众号读者中不排除有一部分是刚接触或对验证感兴趣的同学，下面列举下群聊中大家提到的一些方法或者观点，希望对大家有所帮助。

>>队列不是跑完一个丢一个吗？为什么要算法丢？

是想让每个队列的总耗时尽可能相同。

>>bsub是不是已经实现了“多进程运行，一个进程结束后，自动从任务队列取下一个job”？

>>open lava 应该是free的吧，也支持ssh、rsh。还提供权限控制、任务监控啥的

>>小公司可能并没有集群lsf这些软件，其实也可以shh / rlogin实现类似的功能

>>弄个qsub好了，开源的，跟lsf一样

>>python的multiprocessing不就能实现么？能实现刚刚所说脚本所有功能，

>>vmanager了解一下。

>>vmanager可以管理第三方验证工具的执行和结果吗？

好像不行，他的filter都是跟验证工具绑定的，不过可以自己写filter

>>我记得Filter可以自己补充脚本的。

-END-