上上下下

最近应领导的要求，整合了一下现阶段的测试流程，

使之形成一套流畅的自动化系统，减少人为的干预，

还有添加更为人性化的 UI 以及详细的功能模块，

最终目标是一次投入，今后只需要很少的维护就可以达到现在的测试目的。

这样就可以为将来的新流程留出足够的资源来实施。

下面简单介绍一下这个系统的设计过程：

首先需要设计为一个简单的分布式系统，前端有web UI 允许用户输入并控制相关的测试流程，

后台有服务来分派来自用户的任务给终端的 agent， agent 是执行任务的终端，每一个agent都可以执行多种不同的任务，但是多种任务不一定可以同时运行在同一台agent上。将来也可能会添加其他不同的任务，也可能添加更多的agent进来，所以要有这方面的可扩展性。

于是，在设计之初，我便自然而然的使用了自上而下的设计方法，先把问题分解，从顶端抽象出任务类，继而是继承自任务类的各种具体任务类。然后是执行这些任务的具体行为类，行为类共同继承同一个接口，这些接口比较讨厌，因为要把所有的任务统筹考虑，然后抽象成一个共同的接口。

再然后是数据流程和业务流程，画图，然后根据图再进一步将其中的模块分解为一个个可以编码的类和方法集合。

感觉这样做确实很自然，而且思考起来也很流畅，犹如行云流水一般就搞定了。但是当进行到后面，越来越具体的时候，各种实现的细节便开始不断的影响着最初的设计思路，一些技术细节更是会让之前的设计出现一些 stupid 的实现，并且，由于自上而下的进行，很可能已开始的设计没有那么好，那么细致，以至于后面面对具体问题的时候可能需要进行一些改动！总之是有利也有弊吧。

后来我又尝试了一下自下而上的思路，先从具体问题入手，然后再往上去考虑通性，没想到可以收到奇效。 当然这也与得益于开始的思路，最后，通过自下而上先从具体问题入手，再加上之前通盘的考虑，整个系统比以前要简洁多了，看上去也更舒服一些。

结论呢，就是无论是自上而下，还是自下而上，都具有其特点，都可以帮助你把问题解决的更为圆满。同时，通过这两种不同的思路，可以帮你以不同的视角去观察所要完成的系统，发现一些问题，找到方法去解决之。