如果您現在正在使用微軟的.NET 2005平臺進行開發，您應該也會使用Team Foundation 進行原始碼控制，工作指派與跟蹤。而Team Foudation Source Control是MS Source Safe的擴充套件，功能也更強大（不過大家都反映很不穩定，偶爾會把你的程式碼覆蓋掉讓你鬱悶一把），更重要的是我們可以使用微軟提供的Version Control Object Model（版本控制物件模型）進行程式設計，擴充套件VSTF原有功能或開發一些自定義的元件。

然而，同Source safe一樣，當代碼遷出一直到遷入這一過程中，出現了一個空白，通常情況下不能對使用者操作進行有效跟蹤。解決的辦法至少有兩種：一種是擴充套件

這裡要著重討論的就是第二種方式，描述一下該工具開發中的一些細節問題，我們為該工具取了一個名字，稱為“測試管理中心(TestCenter)”。

2.相關流程

                圖1 TestCenter-功能異常單處理流程

3.典型場景

3.1 程式設計師根據工作項遷出程式碼（After Check Out）

               圖2 程式設計師在TestCenter的操作

前置條件：
1．程式設計師獲得特定工作項，並根據工作項遷出程式碼，修改程式碼並編譯程式碼。
用例描述：
1． 程式設計師登入TestCenter客戶端介面，填寫/選擇任務及工作項等資訊。
2． 程式設計師登入TestCenter客戶端介面，上傳編譯好的dll檔案。
3． 程式設計師確認在TestCenter客戶端所做的操作並提交。
4． TestCenter會根據程式設計師提交的資訊按照預定的規則通知測試人員。
後置條件：
    1．程式設計師在TestCenter客戶端完成操作後，TestCenter會進行響應並給出提示。

3.2 測試人員測試程式碼（Before Check In）

                       圖3 測試人員在TestCenter的操作

前置條件：
1．測試人員必須首先收到全部更改已經提交的通知
用例描述：
1．測試人員登入測試管理中心TestCenter，將所有相關dll檔案下載到本地目錄
   此時可以進行整合測試
2．測試人員根據測試結果登入測試管理中心，提交操作流轉策略：
   如果測試成功，系統可以郵件方式通知程式設計師遷入程式碼
   如果測試不成功，系統可以郵件方式通知高階程式設計師進行Debug或者直接通知程式設計師進行Debug
後置條件：
    1．TestCenter對測試人員在客戶端介面上的操作進行響應/傳送郵件通知等

4.工作項(WorkItem)狀態管理

        由於測試管理中心的系統邊界侷限於程式設計師遷出程式碼到遷入程式碼以及測試人員根據工作項獲取程式碼並測試程式碼這一階段，因此測試管理中心本身並不能直接控制VSTF中的工作流流程也不能對程式設計師的程式碼產生任何影響，因此只能對程式設計師的工作項和測試人員工作項的狀態進行操作。實際上，這將引發VSTF內建的一種事件處理即WorkItemChangedEvent。這裡TestCenter修改VSTF工作項狀態，從而能在VSTF歷史記錄或報表中反映出程式設計師的更改操作。

4.1 程式設計師工作項的狀態變化

圖4 程式設計師工作項的狀態變化

說明：程式設計師獲得分配的工作項，遷出程式碼準備操作，此時相應的工作項處於啟用狀態。當程式設計師修改了程式碼，完成編譯並進行本地測試後登入測試管理中心，提交所屬任務和對應工作項的資訊，並將生成的dll上傳到資料庫中儲存，此時相應工作項處於非啟用狀態。如果測試人員測試通過，程式設計師會收到通知（郵件或口頭的），此時程式設計師可以將程式碼遷入並將工作項關閉表明該工作項已經完成；如果測試沒有通過，程式設計師也會得到通知，並將工作項重新啟用並重新修改程式碼然後登入測試管理中心，再次提交資訊，直到測試通過遷入程式碼完成工作項為止。

4.2 測試人員工作項的狀態變化

圖5 測試人員工作項狀態的變化

說明：與此同時，測試人員也有與某一任務關聯的工作項，當程式設計師提交了所有與之相關的dll後，測試人員將會收到郵件通知，此時其工作項是啟用的。接下來，測試人員將dll下載到本地並進行整合測試，如果測試通過，則通知程式設計師遷入程式碼，同時設定自己工作項狀態，關閉工作項。否則，在測試人員反覆下載dll並測試過程中，其工作項一直處於活動狀態。
注意：這裡存在一個工作項狀態更新同步的問題，一個典型的場景是：程式設計師A修改完程式碼編譯並上傳自己的dll後，TestCenter會將其工作項的狀態設定為“已完成”。然而，程式設計師A可能以前打開了工作項瀏覽器，上面顯示的工作項狀態仍為啟用，這是因為該瀏覽視窗沒辦法實時動態的將資料庫中工作項記錄的改變反映在前端，這可能會對程式設計師A產生錯誤的影響。解決辦法就是程式設計師需要經常手工重新整理自己的工作項瀏覽器。

5. 資料結構

5.1 程式設計師操作記錄實體

圖6 TestCenter記錄程式設計師操作資訊的實體

圖7 TestCenter記錄測試人員操作資訊的實體

• 工作項記錄實體WorkItemRecords      

         該結構中記錄有關程式設計師在測試管理中心填寫的相關資訊以及對相應工作項和程式檔案狀態與控制的資訊。資料字典如下：

• 上傳檔案記錄實體ArchiveRecords

        該結構中儲存上述一個工作項記錄對應的所有上傳檔案資訊。這裡一個任務的一個工作項記錄一定對應一  個程式設計師，但一個程式設計師可以對應一個任務的多個工作項或者多個任務的多個工作項。上傳檔案資訊包括上傳檔案在相應儲存區的路徑，檔名的集合等，資料字典如下：

5.2 測試人員操作記錄實體

• 測試記錄實體TestRecords

       該結構中儲存測試人員在測試管理中心操作的相關資訊，控制對應工作項是否滿足遷入策略，允許程式設計師遷入程式碼或者引發事件通知高階程式設計師重新Debug。資料字典如下：

6. TestCenter整體解決方案

圖8 測試管理中心TestCenter解決方案示意圖

         測試管理中心(TestCenter)基於C/S架構，由一個WinForm的使用者操作介面作為客戶端以及一個WebService的Controller作為服務端構成。管理員也可以方便地通過Web Page訪問服務端進行配置操作，同樣的客戶端也可以擴充套件為通過Browser完成原來WinForm介面的所有操作。
         當程式設計師根據具體工作項將程式碼遷出並進行修改，完成編譯後直接在VS.NET IDE中開啟TestCenter的客戶端視窗，這是因為該TestCenter客戶端程式已經作為外掛(Plug-in)形式整合在IDE環境中。
此時，程式設計師在TestCenter客戶端介面上輸入或者選擇相應的工程專案資訊，任務資訊以及工作項資訊，並指定自己將要上傳的Dll路徑和名稱等。在確認並提交自己的操作後，客戶端將使用者資訊傳送給WebService服務端，服務端負責將這些資訊存入資料庫並按照定義的規則（邏輯）進行處理，如設定本次操作工作項在TestCenter中的狀態，通知測試人員等。如果所有的程式設計師都完成了這一批次的操作，服務端將通過郵件伺服器向對應的測試人員傳送郵件進行通知。
        測試人員同樣可以通過TestCenter客戶端瀏覽某項任務對應所有工作項完成情況列表。當所有工作項已完成一批次的更改操作併發送郵件通知測試人員時，測試人員應能夠將與這些工作項相關的並上傳到伺服器端的DLL檔案下載到本地進行整合測試。如果出現異常無法完成測試或者測試過程中出現邏輯上的錯誤則在TestCenter客戶端視窗中進行資訊填寫以及確認操作。此時，客戶端也會將相關資訊傳送給WebService服務端由服務端進行工作項狀態更改等設定，並通過郵件伺服器向程式設計師傳送異常或錯誤通知。程式設計師重新修改程式碼、編譯並登入TestCenter客戶端迭代地進行操作。如果測試通過，TestCenter客戶端同樣會將測試人員提交資訊傳送給服務端，服務端也會通過郵件伺服器通知所有程式設計師遷入程式碼。

7. TestCenter系統架構

圖9 TestCenter系統結構圖

• XMLConfigurationManager配置管理層

            TestCenter本身要將程式設計師和測試人員的操作資訊記錄到資料庫中，同時對Team Foundation Server的連線資訊以及其他一些配置資訊儲存在XML配置檔案中並進行動態讀取或者修改，因此配置管理層也就作為整個系統的最底層為以上各層提供基礎資訊服務。

• DataEntity資料實體層

            該層負責將TestCenter的資料表對映為資料實體，同時也是客戶端與服務端進行資料互動的載體。客戶端UI層引用該層的dll，將使用者的操作資訊填充到實體物件中並呼叫Web Service的方法交由服務端處理。

• DataEntity Service/Business Rule實體服務及業務規則層

            該層其實分為並列的兩個部分，實體服務部分實際上是對下層資料實體層CRUD操作的實現，當然我們可以利用各種成熟的ORMaping工具具體實現這一部分。而另一部分則要完成具體的業務規則處理，比如判斷什麼時候通過郵件伺服器給測試人員或者程式設計師傳送郵件，郵件的內容如何等等。

• Business Facade 業務外觀層

             由於業務層包含許多處理邏輯，全部通過Web Service暴露出去顯然是不合適的。這樣我們有必要在業務層的上面再作一層包裝，並暴露為web method。這樣客戶端只需要呼叫數量有限的服務介面就可以了，至於具體的處理邏輯則全部交給業務層去做。

• UI使用者互動層

             顯然，TestCenter的客戶端介面就構成了UI層，除了剛才提到的負責收集使用者操作資訊外，還有一個重要的職責就是進行各種資訊的驗證。比如，異常單及工作項資訊是否填寫/選擇，內容是否符合處理邏輯等等。這樣一來，UI層的任務並不輕鬆，但是有效的保證了服務端各層處理的正確性。