Created by: reyoung

需求

Paddle目前提供了很多Demo，但是并没有测试每一个版本对于每一个demo的行为是否发生了变化。所以，就会发生类似于单元测试都通过，但是确实Paddle的行为有了一些细微改变，导致训练结果有变化，以及内存泄露等问题。

所以我们需要一个回归测试，来确定在每一个版本之间，demo的行为不会有什么重大变化。需要监控Demo的:

• 训练误差下降情况
• 测试误差下降情况
• 训练速度
• 内存使用情况
• 显存使用情况
• CPU使用情况等

同时，这个回归测试应该可以在任何地方都能运行，而不是仅仅被QA运行。因为，如果回归测试出错了，我们需要自己运行回归测试复现这个错误。或者，如果用户发现一个错误(例如某个demo的训练无法收敛)，那么我们可以提供我们的回归测试结果给用户，让用户对比具体是哪里有问题。

整体思路

如果是需要在任何地方都能够运行，那么最好还是在一个Docker的container里面。因为这样的话，我们可以完全屏蔽操作系统的差异，都可以运行linux。如果未来需要在macos或者windows下跑回归测试，那也可以使用vagrant这种虚拟机管理工具。总之，第一个想法就是，我们要屏蔽操作系统的差异。防止某一个操作系统上多了一个库或者少了一个库就让回归测试不正常。

前期，我们可以使用简单的Docker来做这个事情。对于docker镜像的话，有三个事情，需要完成:

• 编译Paddle二进制
  • 这里不能直接用docker hub上的镜像，因为docker hub的镜像只能从github上拉去版本，而不能直接通过volume mount本地的文件。
• 书写一些监控的代码
  • 比如输出 CPU占用率，内存使用情况等等
  • 同时，解析paddle的日志文件，解析对应的cost，错误率等等。
• 执行demo

这三个步骤中，前两个是运行每一个demo都会执行的东西，所以，可以将他们放到另一个Docker镜像中，然后在执行每个demo的镜像中，继承之前的镜像。

比如，在基础镜像中，提供一些bash函数，例如

# 编译安装paddle
function build_install_paddle(){}

# 在每个pass结束后的回调
function on_pass_end(){}
...

第二个镜像中，只需要处理如何运行demo就可以了。

我们可以使用docker的volume 将 Paddle的源码置入docker镜像中，并且编译安装。再使用volume将需要输出的日志和统计信息输出到镜像外部即可。

整体运行方式可以使用crontab来做。每天晚上执行一次就行了。

另外，其实整体回归测试可以在Docker in Docker里面执行。这样更方便管理。