創造和使用工具以及創造和使用方法，是人類是區別於其他動物的顯著特徵之一。但我們的大學教育往往只側重知識傳播，忽視工具和方法論的教育。在這裏我總結一下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單點登錄的方法是最好的，省得在一堆密碼間跳來跳去。
# 需要注意對新員工的培訓，保證所有人都能以正確的方法使用整套的工具
# 借用任老闆(正非)的話：職業化就是規範化、表格化、模板化、數據化、流程化
# 任何工作都應該是一個持續優化，不斷改進的過程，教條是不好的，借用敏捷宣言：以人爲本。再借用任老闆的話：先僵化，再優化。