不得不說，這次有點標題黨。其實我們也一直在尋求一整套的解決方案來達到提高團隊的自驗證能力的目的，但是目前使用的方式也只是屈指可數。下面我就說說我目前學習到的，希望和大家一起討論并修改。（先寫個大概，這兩天發燒拉肚子，沒力氣）
1. 靜態代碼分析
這個要靠靜態代碼分析工具來實現。目前有很多的靜態代碼掃描工具，可以進行詞法分析，語法分析，語意分析等。還可以自定義各種各樣的復雜的規則去對代碼進行分析。
靜態代碼分析是編寫代碼時可謂最靠前的一種質量保障了，它可以幫助我們在編寫完代碼后第一時間就得到代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結構的合理性等方面的分析結果；可以發現違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的問題，包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等內容。
2. 單元測試覆蓋率
這個也要靠工具來解決。目前的靜態代碼分析工具也有可以提供檢查單元測試覆蓋率的功能。單元測試覆蓋率分為代碼行覆蓋率和代碼分支覆蓋率兩種，只有兩種都達到足夠的比例才能說明我們的代碼在單測上已經有了足夠的覆蓋。這在回歸的工作中顯得尤為重要。在有些公司，單元測試代碼會由開發人員和測試人員共同完成。
3. 規范開發人員自測
這個要靠測試人員在開發人員提測前提供自測case給開發人員。自測case需要測試人員對需求絕對的熟悉，內容應該涵蓋本次迭代的所有功能點及流程點。但是要注意的是，不要將所有的細節都寫入自測case，比如UI的細節等，要不開發人員會占用大量的時間來測試細節而影響開發，導致收效甚微。
4. 持續集成+自動化測試
這個也是測試人員的主要工作。試想一下，每次開發人員部署完代碼就會自動跑一遍回歸測試，接下來我們要做的只是等待測試的結果，有問題就解決，沒問題就ok了，爽不爽？
自動化測試可分為UI測試，接口測試等。可以靠很多工具實現。
5. 手工回歸+功能測試
這點就逃不了了，很多有關用戶體驗等目前只能通過人來驗證，這要靠我們測試人員的測試用例來覆蓋。
