簡介
自動化測試管理平台TestMP特性
TestMP主要包含以下特性：1. 實時更新自動化測試用例文檔與指標,以代碼為中心進行用例管理。
綁定測試用例文檔和自動化代碼，隨代碼運行實時更新。自動化測試用例的運行歷史被測量和記錄，數據集中形成幾個直接清楚的度量指標。
2. 自動生成度量報告，反映總體質量水平與測試情況。
測試用例指標匯總後形成的度量包括：項目健康度、測試有效性、耗時與穩定三個方面。報告可由負責人對各項目簽署“通過”或“不通過”，並傳送至相關各方。
3. 面向對象的測試數據存取和組裝服務，靈活地管理和復用測試數據。
通過標籤對測試數據分類，並存入數據倉庫，在代碼中使用API獲取滿足條件的數據。獲得的測試數據是原類型的對象，無需組裝；也可合併多個數據。
4. 任務驅動的測試環境管理與過程集成，調度本地/遠程腳本，建立流程。
定義任務對測試環境進行管理，可根據時間調度，並綁定多個主機上的可執行命令與腳本。任務引擎包含多個執行緒，以並發方式運行，通過控制台追蹤。
思想
測試用例管理
對於一個新項目，QA通常會首先為新特性創建手工測試用例，為了之後維護方便，也通常將這些用例存放在一張Excel表或者一個專門的測試用例管理系統里。而在項目進行過程中或之後，具備自動化測試能力的QA團隊會將手工測試用例轉化為代碼，加入套件(Suite)中，用於之後的回歸。以往我們認為手工測試用例與自動化代碼之間存在聯繫，但並不緊密：
1. 手工測試用例文檔很容易閱讀，可以幫助學習業務，但因為維護不夠靈活，很難跟上快速的變化。依賴手工測試用例對項目進行回歸又是及其痛苦的。
2. 自動化測試代碼可以很明顯的提升效率，但不容易閱讀。因為人們通常缺少更新代碼注釋的動力（沒什麼外人會用到，老鳥又不依賴它），久而久之我們不知道那一堆自動化用例究竟測了些什麼，導致通過率逐步走低，又無人維護。自動化測試最終土崩瓦解。
這似乎是一種宿命般的失敗。有些團隊希望建立自動化測試體系，卻從一開始就遇到類似的問題，導致進展緩慢，無法持續向老闆秀出效果，最終又退縮回原點。
原因是什麼？怎么去破解這個困局呢？
1. 用例文檔不應該與自動化代碼分離，而應存在於代碼中，隨著代碼的變化而及時更新。
2. 用例文檔應該簡潔，可以自我組織與管理，並以一種清晰的結構被展現和分享。
3. 自動化測試用例的運行歷史應該被測量和記錄，數據可以集中形成幾個直接清楚的度量指標，反映一個周期內的平均質量水平。
4. 度量指標應該可以形成簡潔好看易懂的質量報告，向相關各方展示測試工作對產品關鍵方面的評測結果。
TestMP的測試用例管理和度量按照以上四點，為破局提供了一種解決方案。
測試數據管理
測試用例執行所需要輸入的數據，以及所依賴的環境數據，都可以被稱作測試數據。任何自動化測試都離不開測試數據，但很少人會在實施自動化早期發現測試數據管理的重要性。最常見的做法是在自動化測試代碼中硬編碼數據，或使用一組XML或者Excel檔案作為數據源。這種做法的缺點是不夠靈活和智慧型，還不足以適應自動化代碼快速增長和變更的現實。例如某大型網站的測試團隊，維護著一套Web自動化功能測試代碼，這套代碼負責對該網站多個國家/地區站點進行回歸，使用到的測試數據包括商品信息、測試賬號、商品評論等等，一個數據多個版本。隨著自動化測試代碼不斷的擴充與增長，發現了以下問題：
1. 很難對數據進行查找，導致無法復用已有的數據。
2. 無法方便地添加、刪除和更新測試數據。
3. 無法方便地實現腳本化的數據校驗和管理。
另一個例子如某個國內公司的業務團隊，處於自動化測試體系建設的起步階段，希望首先對業務服務層的接口建立自動化測試。接口測試的代碼邏輯很簡單，難點在於如何準備測試數據，其中最明顯的問題是：接口參數對象有比較複雜的結構和繼承關係，如果使用傳統的測試數據存儲方式，需要對每個用例重複創建某一部分屬於父類的數據，而且需要有專門代碼組裝為符合參數類型的對象後才能使用。
問題的癥結在哪裡呢？我們認為測試數據的管理需要系統化和服務化：
1. 測試數據的重要性和體量，需要一個專門的系統進行管理，可以使QA方便地查找滿足特定條件的數據，以及添加、更新和刪除數據。
2. 測試數據管理系統提供遠程訪問API，使得可以腳本化地操作被組織起來的數據，實現多種管理，例如數據校驗等。
3. 足夠智慧型的API，可以根據用戶指定的類型自動將原始數據轉換為該類型的對象實例，而不需要用戶編寫額外代碼進行複雜的轉換工作。
4. 足夠智慧型的API，可以根據用戶需要，將多個數據片段組裝為指定類型的數據對象，使得某些共享數據片段可以一次添加，多次復用。
TestMP自動化測試管理平台就是按照以上四點，為測試數據管理提供了一種解決方案。
測試環境管理
首先要說明一點，由測試人員獨占和負責配置的環境才是真正的測試環境，沒有真正的測試環境，自動化測試也就無從談起。只有讓測試人員決定是否變更環境配置，是否部署新版本的軟體包，才有可能使測試活動順利進行，較少被意外活動干擾。從現實經驗看，成功建立自動化測試體系的測試團隊往往和開發人員處於平等的地位，並有能力完全負責測試環境的維護和軟體包的部署，其它人員對測試環境的任何改動都是嚴格禁止的；而實施失敗的測試團隊則比較弱勢，無法做到擁有真正的測試環境，這種情況下手工測試都會經常遇到干擾而暫停，自動化測試體系也就無從談起了。測試環境的管理與軟體的集成過程相互關聯，典型地包括以下活動：
1. 同步測試環境與生產環境。當涉及到同一產品的多個研發團隊時，保證測試活動開始前所有的軟體包版本與生產環境一致。
2. 構建一個或多個需要測試軟體包。
3. 部署測試包到集成測試環境。
4. 驗證測試包的有效性，包括是否有包缺失，是否有多餘包，版本是否正確等。
5. 驗證依賴的第三方環境是否正常運行。
6. 啟動自動化測試用例集，可能需要多次疊代直到消除誤報。
7. 監控測試運行期間的環境狀態，包括CPU使用率、記憶體占用率等。
這些活動是可以通過腳本流程化的，很可能一個團隊正在編寫或已經有了大量的與測試環境配置相關的腳本。如果將這些分散的腳本集中管理，既可以一鍵執行，又能夠根據時間調度，對測試環境的管理就會更加靈活。另外這種集中管理和調度也使我們能夠提供一致的環境狀態報告，方便與相關人員分享。
Jenkins和Hudson這一類CI工具是一種選擇，但更偏向於驅動一個過程，而不是面向環境的，對分布在不同主機上的各類腳本進行管理也很不方便，因此需要使用者做更多適配工作。
TestMP自動化測試管理平台的測試環境管理模組定義了環境(Environment)，主機(Host)，任務(Task)，執行緒(Execution)，追蹤(Trace)等元素，由用戶建立其中聯繫。例如一個Environment可能包含多個Task，Task包含多個Execution，Execution映射到Host上的一個命令或腳本，執行過程中和之後可以獲得Trace，最終生成測試環境的狀態報告。由此可見TestMP的測試管理是圍繞測試環境建立和驅動測試流程的，這也是它與CI工具的區別。
