自动化测试框架: 协同

近来，将我们的测试框架和市面上流行的测试软件做了对比，发现大家的想法都是一致的。我们也认识到，除了协同工作方面，其他方面还是做得非常好的。

办公协同？是的，Google已经退出在线版Office系列软件，而我们的测试框架也同样不能回避这个问题。一开始，我们是可能只有一两个人编写测试脚本，而且还可能两人商量着、研究着，因此开始时候，协同的需求并没有那么紧急。但随着脚本工程慢慢扩大（现在已经4000个测试步骤了），而两个人已经开始分工，各自负责各自的代码（一来两人的经验已经足够独立编写，而来如果不独立编写，进度就赶不上了）。协同一下子变成最最麻烦的事。

由于开始没有好好考虑过这个问题。解决方案有两个：

1.通过工程文件的合并。这是利用svn的Merge功能（或者WinMerge软件），因为工程文件的格式是xml的，可以比较出差异，这样只要有足够的耐心，绝对可以合并好。

2.通过IDE的脚本复制粘贴来完成合并。针对新建的或各自编辑的测试脚本，可以很方便地合并。只不过，如果针对细节做了小幅度修改，很难察觉并进行合并。

等到我们发现协同的问题的时候，参考编程语言中的协同方式，我们提出TestUnit的概念，类似于代码工程中的各个代码文件，这样大家可以将自己负责的模块独立成一个TestUnit，最后可以合并回去。

TestUnit中，重点考虑的是多人在自己的Unit中编辑TestStep的时候的ID分配问题，这里针对TestUnit提出了ID段的概念。假定TestUnit只有一个人编辑，这样我们在TestUnit创建的时候，就分配好范围为10万的段。这样就可以在约定上保障双方的TestStep不存在ID重复。这里面存在的可能性的重号，可以通过整体重新编号来解决。

这个并不是我们最满意的解决方法。我们考虑是否应该为测试脚本的IDE编写一个服务器，负责协同工作呢？一开始，我认为服务器会让一个软件依赖性增强，反而削弱了原有的灵活性。不过现在看来，这只是一个设计理念，而非设计原则。套用一句同事的话：有了网络版，软件才看上去像软件。也许在大部分人的眼中，都只是将单机的看成是工具罢了。

但是我确实不愿意编写一个服务器。我突然意思到其实消息队列（如微软的MSMQ）这种企业架构中常常出现的服务组件，其实正是我们这类软件在系统时候的服务器抽象。这让我对消息队列有了更深层次的理解。

我们以前编写服务器，第一想到的往往是自己软件的独特需求，反而容易忽略了服务器的本质所在。在这点上，协同和消息队列几乎是等价的。这就如Windows中的鼠标、键盘等操作系统为应用程序准备的进程消息队列。系统也正是通过这种类似的机制，完成了多个进程、窗体之间的协同。

采用消息队列实现的重点，是将自己的软件定义出操作接口。因为这将意味着从A系统中发生的变更a可以通过消息队列发送到B系统中，并将a变更更新到系统中。从而完成A和B之间的同步。真正难的地方还是在客户端！

关于TestUnit已经基本实现，而MQ还没有设计。在完成协同的需求之后，下面的需求可能是测试用例的管理。因为这段时间和大家讨论到这块，感觉非常有意义，当然了，那又会是一个大的话题了。