測試部日常工作所需的工具流程及模板

創造和使用工具以及創造和使用方法，是人類是區別于其他動物的顯著特征之一。但我們的大學教育往往只側重知識傳播，忽視工具和方法論的教育。在這里我總結一下IT行業測試部門所需要的工具平臺及相關流程和方法。

=測試部需要建設的工具平臺=

* 缺陷跟蹤平臺

缺陷也就是bug,也有叫MR(Modify Requirement)的，是測試工程師日常工作成果的最直接的展現。提交bug時邏輯清楚敘事通順是首要的，有點像是寫一篇記敘文，時間地點人物起因經過結果都應該有。常見的缺陷跟蹤平臺有Bugzilla,Clearquest,Jira,Redmine等。一般的缺陷跟蹤平臺都會提供項目管理、版本管理、模塊管理、自動Email通知、權限管理、自定義參數等功能。我認為一個好的缺陷跟蹤平臺應該是簡潔、直觀、迅速、易上手的。如果能提供排序，匯總，圖形化那就更好了。缺陷管理平臺作為測試團隊和其他團隊之間最重要的接口，應該融入到公司的整體IT環境里去，IT部門需要保證各團隊訪問的便利性，以便促進團隊間交流的效率。如果一個產品經理不關心產品的缺陷情況，就不是一個合格的產品經理。

* 知識管理平臺

知識管理平臺用來在團隊內部和團隊間分享產品知識和心得。IT行業人員的流動率出了名的高，因此一個好的知識管理平臺對團隊健康成長是非常有必要的。Wiki由于有便利的更新功能，可以保持文章的常用常新，因此幾乎成為知識分享的標準平臺，完全可以淘汰論壇，SVN等等工具。在一個有一定積累的知識管理平臺上，從市場到研發，產品上下游幾乎所有人都能從中受益。常見的Wiki工具有Mediawiki,Confluence等。

* 自動化測試平臺

自動化測試對于代碼重構、版本間的回歸測試是非常重要的。可以說，敏捷開發模式之所以興起，完全是因為自動化測試技術的Open和進步。尤其對一個生命周期比較長、版本比較多的產品來說，自動化測試是非常重要的防火墻。自動化測試的本質是以軟件測試軟件，因此需要以軟件工程的方法對待。幾乎所有編程語言都有其對應的xUnit自動化測試框架，但是需要注意的是并不是只有單元測試才能做自動化，IT，SIT, SVT階段都可以做自動化，需要根據產品特點，選擇產品不同階段自動化測試的方法。

* 探索測試平臺

很多測試工程師都會發現，有時候根據spec和plan做測試發現的bug，還不如發散測試和探索測試發現的多，因此好的探索測試平臺是很有必要的。探索測試平臺應該是一個工具平臺，解決測試環境的仿真問題，需要持續的將適用和好用的工具加到平臺下來。探索測試平臺應該和自動化測試平臺形成良好的互動，將好的工具持續引入自動化測試平臺中。

* 持續集成平臺

持續集成平臺的建設可以大量提高軟件發布過程的效率，減少人為錯誤。持續集成的的目標是更快，更全，更直觀。代碼的checkout、編譯、發布、部署，測試、報告，每一步都有巨大的效率提升空間，自動化everything。常見的持續集成平臺有Jenkins/Hudson,CruiseControl，Bamboo等等。軟件改變世界，工具改變世界。

* 輔助工具平臺

輔助工具平臺用來輔助測試工程師日常工作，比如用例設計，文檔檢查，時間規劃，郵件處理，IM,截圖工具等。團隊應該盡量使用同一套工具，遵循同樣的配置，以減少不必要的交流和誤解

* 版本管理平臺

腳本，文檔和工具都應該版本化管理，個人推薦Git,相比于Svn，少了很多的.svn文件夾，copy起來方便很多

* 用例管理平臺

在團隊規模日益膨脹，用例和版本日漸增多的時候，建設一個用例管理平臺就非常有必要了。常見的用例管理平臺有testlink，testcenter等，可選范圍還是比較小的。相比于Excel強大的穩定性和易用性，不建議在測試管理平臺上直接寫用例，無窮無盡的麻煩，使用一個Excel用例文檔到用例管理平臺的輔助導入工具是最好的。

=測試部日常工作所需流程=

* 任務分解流程

愛因斯坦說，把復雜的事情做簡單，我理解意思就是分解。現代社會的特征就是分工更細，1+1>>>2的團隊才是優秀團隊。因此建立一個分等級的專家團隊，各展所長，保證每個人無論本領經驗如何都能最大程度發光發熱，這也是華為團隊成功的法寶之一吧。

* 缺陷處理流程

每個團隊的資源都是有限的，大多數時候我們并不能等到所有缺陷都解決了才去發布產品，因此如何處理和評價缺陷事關產品整體，會涉及到市場，研發，測試等各個團隊，需要明確的流程來保障

* 產品發布流程

在產品發布前，通常需要確認所有的風險都已規避，所有相關的資料手冊都已完備，最終版本和需求匹配，這也是牽扯公司很多部門和環節的事情，因此，產品發布應該建立一套強流程的規范，協調不同團隊間工作的順序展開

* 用例及腳本維護流程

敏捷開發的理念之一就是輕文檔重交流，這是因為維護文檔的狀態常新是一件很麻煩的事情，如何保證用例、腳本的一致性，如何保證網上問題的閉環，這些都是測試團隊需要注意的問題，因此，在一個統一的流程下操作是很有必要的

* 新員工培訓流程

對于新員工的培養，一定要建立一系列明確的目標，需要掌握哪些工具、模板、流程、資源，如果事先做好培訓計劃和流程，可以省很多事情哦

* 文檔的Review流程

文檔是最能反應工程師職業化素養的輸出，邏輯和語言都是需要訓練才可掌握的東西，沒有經過Review的文檔都是不合格的文檔，Review的過程即可以查漏補缺，也可以統一口徑。對于測試部主導輸出的文檔，都應該規定何時何人用何種方法Review，從哪里來到哪里去，這些都應該有明確的流程和制度來保障。

* 工作狀態匯報及跟蹤流程

周報，日報，重點任務，甘特圖，里程碑，這些東東都用起來吧，習慣成自然

=測試部常用模板=

* 測試用例模板,計劃/需求/報告模板

* 周報/日報/任務跟蹤模板

=需要注意的事情=

# 這些平臺及流程的建設并不只是測試部門的事，應該盡量融入公司整體的IT環境，比如Email系統，身份管理等，用SSO單點登錄的方法是最好的，省得在一堆密碼間跳來跳去。

# 需要注意對新員工的培訓，保證所有人都能以正確的方法使用整套的工具

# 借用任老板(正非)的話：職業化就是規范化、表格化、模板化、數據化、流程化

# 任何工作都應該是一個持續優化，不斷改進的過程，教條是不好的，借用敏捷宣言：以人為本。再借用任老板的話：先僵化，再優化。