辦公協同？是的，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還沒有設計。在完成協同的需求之后，下面的需求可能是測試用例的管理。因為這段時間和大家討論到這塊，感覺非常有意義，當然了，那又會是一個大的話題了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/