上一篇里我們討論了
測試的必需性，如果大家目前還在公司里做著測試的
工作，那就說明還是落在必需的范圍里面，或者至少一段時間是吧。那接下來我們看下既然需要做測試，需要做哪些事情。
基于我自己的一些理解和觀察，我試圖把測試工作的層次分成三個階段，越到后面涵蓋的范圍越廣。這里討論的一些做法可能更偏向于
互聯網方面的測試，特別是第三個階段。
對于一個城市，假設我們的工作目標是提升環境的質量，減少垃圾。那么我們可以做什么？
首先，我們可以請很多環衛工人，出去打掃各個街道，這個馬上就有了效果，環境變得更干凈了。但是還不夠好的地方是明天還是有很多東西需要打掃，治標不治本，只要一停下來立馬回到之前的狀況。
接下來，我們往前面想一想，為什么有那么多垃圾呢？其中一個方面是很多人亂扔垃圾。所以更進步一點的方案是，對于亂扔垃圾的人有些約束或者懲罰，比如抓到了曝光或者罰錢，這樣扔垃圾的人會變少。
再然后，我們發現即使做到了上面，還是有不少垃圾，而且上面強制的方案也帶來不少的反感。我們需要更深層次的思考，為什么會有那么多垃圾？是因為垃圾桶太少？設計得不合理？如果是這樣，就需要從其他公共設施方面做一些改進了。
對于我們的測試工作，也是有類似的思路，只不過細節上要考慮更多。
第一個階段：發現和解決bug的階段
這個階段的思路基本上盡可能發現更多的bug，見一個滅一個，來兩個滅一雙。
發現bug，解決后驗證bug，沒有任何根源性的推動，或者推動的效果不好。
這個階段，測試工作主要集中在發現bug，要做好這個，需要多個方面的努力，比如下面這些：
- 更高效的發現bug，考驗測試設計的能力。
這方面有非常多的方法和技巧，以及經驗，這里不細說。
- 發現bug之后如何清晰的描述，定級，以及跟進和驗證。
這個看似簡單，但是你會發現很多測試工作做了幾年的人這樣的基本功還是不夠扎實。也可能沒有受到過很好的訓練或者一直沒有人指導。
- 對業務和架構的理解能力。
沒有這方面的能力，很難發現一些深層次的bug。而這樣的能力對于快速
學習和一些技術基礎也有不低的要求。
- 發現bug之后如果舉一反三的盡早發現更多類似的bug。
大家看到的很多經典的測試書籍講的基本都是這個階段做的事情，比如Software Testing，How We Test Software at Microsoft，以及探索性測試相關的書籍，都是專注在如何更高效的發現缺陷。
上面這些東西都是一個業務測試人員的基本功。看似簡單，但是做好并不是一件容易的事情。也許這些事情一點都不cool，不sexy，甚至去做職級評審的時候不占優勢，但是對于系統質量的提升，是切切實實帶來很大幫助的，其工作的價值應該得到認可。但是如果一直停留在這個階段，就陷入到上面例子中說的掃馬路的階段，因為如果沒有其他方面的改變，每次都有那么多的bug。
不過很多時候，我們的測試停留在這個階段也是因為現狀，考慮下這樣的情況：
- 開發基本不自測，甚至沒有自測的環境，特別是涉及多個系統的對接。
- 提測后很多基本的功能都不能正常使用
-
項目管理比較混亂，但是最終的發布日期又被老大們定死，所以測試時間常常被壓縮
而且，而且沒有對于開發人員的質量方面的考核，那么很長一段時間，我們的測試將處于這個初級階段。
我相信目前還有不少的團隊是處于這樣疲于應對的情況下，不只是小公司，可能一些大公司的部分項目也是如此。隨著整個研發體系的發展和深入，我們應該有更高的追求。
第二個階段：質量的管理
在第一個階段中，可能有一些人會停下來想：我們一直這樣下去也不是個辦法？有沒有更好的做法呢?
最直接會想到的就是，怎么讓別人少丟垃圾，讓本身的bug就更少一些。如果我們做的工作只是發現bug解決bug，那么就是一個消耗戰。不能形成一個良性的循環，就不能持續的優化，工作的長期累積價值就體現不出來。
這個階段核心的思路是對缺陷做分析和考核，并做研發流程中主要問題的梳理和改善。
常常做的事情可以從下面幾個方面來看：
1. 做質量數據的統計和分析
收集的數據很多，常見的有：
- 外網的bug情況，包括事故，及影響的程度
- 測試階段的bug數量，分布（按系統，團隊，開發個人），嚴重程度，bug的類別等維度
- bug的橫向跨團隊和系統的對比，縱向的和歷史情況對比
- 版本發布的情況，代碼變更行數的情況
從這些數據的收集中就能發現很多問題，比如問題集中在哪里，哪些模塊，哪些人，哪些類別等等，以及有沒有改善。
2. 問題的追溯和對于開發的考核
這個方面也許有一些爭議，但是我還是覺得這個是一個很重要的方法。光靠觀念和自覺是不夠的，必需要有一定的反饋機制，就好比交規一定是配合著扣分和罰款等手段，否則記錄闖紅燈有什么意義呢？而且現實的來說，這些方法起到約束的作用，也是一種心理暗示，要做自己做的東西負責，也便于養成好的習慣。
通常的考核指標涉及這些方面：
- 編譯失敗次數的考核
- 外網事故和bug的數量
- 測試階段的bug，特別是基礎功能bug和嚴重bug
粗略的列了這么多，其實可以有很多，比如配置文件改錯的情況，漏提測文件的次數等等。
這里也許有很多的討論，但是讓我們看看一個實際的例子。下圖是某個系統的編譯失敗的情況，在11月份的時候提出要統計并公開（并無懲罰條款）編譯失敗的情況，包含到開發的團隊和個人等明顯，12月份開始出現了明顯的下降并穩定了。這個圖隱藏了一些細節，如果剔除其他因素只看開發代碼原因的編譯失敗則更明顯，特別是后面有懲罰機制之后，進一步下降。
編譯失敗大幅的下降一方面是節省了大家的時間，另一方面其實也是提高了版本質量，想想如果有很多的編譯失敗，而且是到提交測試的階段，這樣的代碼質量能好嗎？是可能做過自測嗎? 有了這樣的機制，至少會更仔細一些。
對于bug方面其實也是一樣，如果開發在乎（或者被迫在乎）外網bug或者被測試發現的bug數量，他寫代碼的時候一定會更仔細，也會做些簡單的自測，讓提測的質量更高，提高了整個研發系統的效率，同時也是提升了質量，因為quality must be built in。
我個人的經驗，作為測試人員幾乎同時面對過兩個開發團隊，一個有上述的考核，一個沒有。表現出來的版本質量和對質量的關注完全不一樣，而且前者也并沒有出現開發和測試的對立，以及測試不敢提bug等負面的情況。
3. 對于測試的考核
除了對于開發的考核，同樣也有對于測試的考核，這樣也更加的公平。
測試的考核通常考慮下面的指標：
- 漏測：絕對數量或者漏測率
- 版本的工作量和測試效率
- 發布延期的情況
如果測試有這樣的壓力，也需要不斷努力去發現更多的bug。
說起考核，總有人覺得這不符合智力勞動的情況，或者互聯網的作風，其實不太理解為什么會這么覺得，放眼望去，有什么工作不被考核呢，sales要背quota，為什么軟件開發和測試不能對自己的工作的質量負責呢？當然，具體的指標如何去定才更合理那是另一個要去考慮的。
換個角度來看，適當的壓力（不應該導致焦慮和扭曲的做法），其實是讓一個人表現最好的狀態。
4. 推動開發的自測
這個問題一向是個老大難問題。愿意自測的開發團隊你不用太多的推動，不愿意做的推動也很難，或者你無法判斷他有沒有做自測。而且這方面，通常取決于開發負責人的觀念和態度。
如果是介于之間的，我們可以做一些事情，比如：
- 統計測試階段的bug中，屬于開發可自測發現的比例。通過這個可以看有多少bug是不應該到測試階段的，以及橫行縱向的對比。當然這個標準要自己拿捏。
- 給出一個自測的checklist。開發在提交前要完成這個list并正式的給出報告。這個方式我們曾經在一個項目中用過，效果不錯，基本功能都通過這個保證了，前提是開發負責人認可。
- 有一套自動化驗收的用例，可以掛接到自動部署之后或者daily build。前提是我們的自動化要足夠的問題，效果才會好。
這個階段除了業務測試的努力，也體現出了QA的價值。這里的QA是指質量管理，有的地方叫SQA，專注在質量度量和研發流程的管理上。
到這個階段，發現事情順了很多，質量也有更大程度的提升，并有改善額趨勢。
第三個階段：推動全面的質量提升
到上面第二個階段，我們發現質量有了一定的提升，但是還是有不少的問題，而且有些問題需要我們把思路和眼界拓寬來看。這里討論的一些東西可能更適合互聯網的產品。
這里列一些我們可以去做的事情，受限于個人的經驗，可能還很片面。
1. 研發流程的梳理
其實在階段2的時候也可能有些團隊已經開始做這樣的事情，因為在分析質量和效率問題的時候，我們發現很多問題不單純是代碼的問題，可能還涉及研發流程的很多方面，比如：
- 需求不清楚
- 跨團隊的配合問題
- 代碼版本管理
- 技術方面的評審和大家的理解
所以整個研發流程的規范和梳理，以及配合對應的需求和版本管理的系統也是非常的必要，實際中發現效果也是比較的明顯。而且還有一點體會，在接手一個很混亂的狀況時，這樣角度的數量和調整比技術方案的引入更重要和切中要點，能從40分到60分，技術是往80分走的過程效果更明顯。
2. 提交測試前后做的一些事情
- 代碼的靜態掃描
這個方法很多的團隊都在做，但是實際的效果似乎差別很多，而且ROI也很難說，不過從方法本身來說還是值得去做的，對測試人員也提出來更高的要求。
- code review
這個開發應該要做，特別是開發間的交叉review，非常的有幫助。不過這個也和自測一樣，取決于開發負責人的態度。另外，測試也應該去做，特別是對于diff 代碼的review，我們檢查做了大概兩個月的時間，發現還是非常的有收獲。發現了一些黑盒難以發現的問題，以及開發的代碼夾帶，并且對于這個版本影響范圍的評估也更準確。但問題是短期會花費測試更多時間，以及需要測試人員有一定的技術能力。