對于一個城市，假設我們的工作目标是提升環境的品質，減少垃圾。那麼我們可以做什麼？
首先，我們可以請很多環衛勞工，出去打掃各個街道，這個馬上就有了效果，環境變得更幹淨了。但是還不夠好的地方是明天還是有很多東西需要打掃，治标不治本，隻要一停下來立馬回到之前的狀況。
接下來，我們往前面想一想，為什麼有那麼多垃圾呢？其中一個方面是很多人亂扔垃圾。是以更進步一點的方案是，對于亂扔垃圾的人有些限制或者懲罰，比如抓到了曝光或者罰錢，這樣扔垃圾的人會變少。
再然後，我們發現即使做到了上面，還是有不少垃圾，而且上面強制的方案也帶來不少的反感。我們需要更深層次的思考，為什麼會有那麼多垃圾？是因為垃圾桶太少？設計得不合理？如果是這樣，就需要從其他公共設施方面做一些改進了。
對于我們的測試工作，也是有類似的思路，隻不過細節上要考慮更多。
第一個階段：發現和解決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，我們檢查做了大概兩個月的時間，發現還是非常的有收獲。發現了一些黑盒難以發現的問題，以及開發的代碼夾帶，并且對于這個版本影響範圍的評估也更準确。但問題是短期會花費測試更多時間，以及需要測試人員有一定的技術能力。
<a href="http://www.51testing.com/batch.download.php?aid=45052" target="_blank"></a>
釋出處在整個研發流程非常關鍵的節點，在這個點可以做很多的控制，也能發現很多的問題，對于測試團隊來說，從這裡可以發現很多的問題，做很多的提升，對自己和相關的合作團隊。
5. 外網的監控
發現釋出後的問題，持續營運過程中的問題，推動優化。
通常監控可以分幾個層面，粗淺的可以分成幾類：
- 運維層面的監控，比如機器，鍊路，資源使用，主要元件是否正常等。
- 業務名額的監控，比如來自點選率，bi系統等。
- 內建在産品裡面的監控代碼，我們稱之為子產品調用監控。這個是全量的，有次數，成功率，響應時間等角度。
- 測試層面的自動化監控，關于在接口和功能層面。這個是采樣的，但是從使用者的角度來監控。
以上這些監控都有對應的告警機制，可以第一時間發現問題，避免造成更大的損失。為了實作上面的監控需要做大量的工作，但是這些對于整個外網營運的品質非常的重要。
6. 外網事故和問題的收集，跟進和反向推動
和前面的思路一樣，如果隻是發現問題解決問題還是稍顯被動，那麼對于外網事故和問題的分析，還是有很多推動性的幫助。
7. 使用者的問題回報和滿意度
進一步的品質不隻是系統本身的品質，而是從使用者角度看到的品質，有時候這個可能稍微超出一些系統層面的問題，但是因為最終的品質還是使用者說了算，是以我們應該擴充下思路。收集這樣的問題的管道有很多
- 外網問題回報，比如來自客服系統的，使用者直接的回報，現在很多app上都有回報的功能。
- 論壇資訊的統計收集。我了解的另一個測試團隊，他們還專門開發了一個自動收集外部回報，以及過濾分析的系統來幫助他們及時的了解外包的問題回報。
<a href="http://www.51testing.com/batch.download.php?aid=45055" target="_blank"></a>
每次我們的思路跳出一些框框，都會有不同的領域。有點點哲學上的意味，很多領域做到後面，其實會超出那個領域本身的範疇。就好比高性能的汽車，到後面就不得不研究空氣動力學這個原本是和航空有關的東西。但是，這是否超出了本意，如果去看待，又是另一個問題。
其實這樣的三個階段也是一個粗略的劃分，并不一定要逐漸的來發展，其實都是一些具體的做法和實踐。以我目前經曆過的實踐隻想到這樣的層次，應該還有更進階的階段。
我們越到後面我們發現進一步的努力帶來的提升幅度其實不大。但是很多事情也是一樣，從85分到90分付出的努力可能比50到80分的努力還要大。另一個更有趣的是汽車的極速和馬力的關系，家用車100馬力開到180km/h是能做到的，但是超過時速300，每提升一點需要增加的馬力要大得多，到400以上，車時速每再增加一公裡，功率需要提升八馬力。這篇文章讀起來非常有意思， http://blog.sina.com.cn/s/blog_4d0109a301000ajz.html
寫到這裡，我們可以跳到整個公司或者業務的層面，來思考一些對于測試更深層次的問題:
測試團隊存在的價值和意義是什麼？
隻有對業務有明确的價值，業務測試，或者說整個測試團隊才有存在的意義。隻要業務ok，砍掉測試團隊也不是不可能。我們必須時不時的跳出我們自己的思維的圈子，站在整個事業部老大的角度來思考下測試的價值和意義。
在下一篇關于測試組織方面我們可以再讨論下這方面的内容。
還有一個體會：測試的水準反應整個研發體系的能力和水準。
如果我們的測試還專注在第一階段，那說明整個研發還比較初級，開發和測試都是溫飽的階段。當我們的測試人員不再趴在地上盯着最基本的功能品質的時候，才有可能擡起來看看更多有價值，有幫助和有長遠意義的工作，慢慢形成一個良性的循環。
最新内容請見作者的github頁：http://qaseven.github.io/