關於對測試金字塔的理解收穫共享
前段時間去了51testing聽了2天課，講課老師是從微軟外聘的，中間提到一個測試金字塔的問題，把我原來的一些疑惑、觀點進行了很好的解釋和印證，道理很簡單，但不是每個測試人員都能理解透，故把收穫共享一下。
金字塔的結構如下：
金字塔分爲5層，最一層的是單元測試，是針對類庫和程序集來進行測試；第二層爲組件級的測試，我的理解是dll和接口級的測試；第三層爲服務級的測試，像我們做GIS的，可以理解爲地圖服務，定位服務等；第四層爲界面級的測試（如自動化UI測試）；最上面一層爲手動測試，運行已經集成的系統，手工對系統的運行結果和預期結果比較。
摘自老師網站，地址：http://www.qathinker.com/（基於敏捷開發的大型軟件自動化測試架構）
觀點一：測試越往下面測試的效率越高，測試質量保障程度越高，如下圖示：
越往底層，測試的效率更高，程序的bug歸根結底需要落到每個類上面，當保證了每個類的穩定後，越往上層就是集成的問題了。邏輯性bug在類庫做組件內部解決。
舉例說明：
我曾經參與一個項目，某個系統每次一測試，都能發現大量的bug，對這個系統幾乎快喪失信心，後來我把這個事情反饋給項目組的開發經理，這個開發經理把它的代碼拿到後，直接看底層代碼的邏輯，重新整理了各個類庫之間的邏輯，加強單元測試的覆蓋率。然後把系統給我的時候，發現原來很多bug自然沒有了，質量很快就上來了，對系統有信心得多，有些地方我也偷了懶（不測也是提高測試效率的手段嘛）。
越往底層測試，測試效率更高的還有一個方面最能體現，就是自動化測試。像單元測試，只要class中的方法參數不變，類庫的名稱不變（這些一般也是不會變的），這樣自動化的測試腳本就不需要變化。而越往上層，自動化測試效果不會太好，尤其是系統界面經常變化的，造成自動化測試腳本的維護工作量非常大。據我所知，在界面層的自動化測試，除了office軟件做得好的外，其他好的案例非常少。
觀點二：測試越往下面測試的成本越低。
Bug越早發現，損失就越小，成本也越低，這個應該是測試人員的共識了。同樣道理，從這個金字塔也符合這個規則，也就是說這個金字塔是符合軟件開發流程的，按照瀑布模型來說，單元測試往往是項目測試最前期的，到了界面測試了手工測試階段，系統已經集成了。這個時候發現問題，如果這個系統很大的話，可能在問題定位上就得發不少時間，比在一個類中定位問題，花費的時間絕對多的多。
我自己也經歷過一個事件，某住房補貼軟件在刻了5000張光盤後，被測試人員發現了一個嚴重bug，這個直接影像到補貼金額的準確性，導致5000張光盤重新刻錄。好在光盤還沒有發出去，否則後面的麻煩事估計公司得專門成立一個部門來解決了。
觀點三：測試越往下面，職業發展前景越好，同時也回答了測試人員是否需要開發功底的問題:
越往金字塔底層，測試的技術含量要求更高，測試人員的核心競爭力更大，薪酬當然要高一些，如果從技術方向來說，可以做高級測試工程師、測試架構師都有可能。老師給我們講了一個微軟測試人員人數變化的例子，在微軟早期，也有不少手工測試的人員，這些人員也是不需要編寫代碼的，由於微軟從事的產品爲主的公司，這些手工測試人員根本無法滿足測試工作要求，逐步推行自動化測試，隨着自動化測試的深入，到了2003年左右，不懂開發的測試員已經遠遠少於有開發功底了，到了2008年左右，不懂開發的測試員已經消失了。
隨着自動化趨勢的加強，希望網上對於測試人員是否需要懂開發的爭論希望少一些吧，也希望認爲因爲測試比開發簡單的才加入測試隊伍的，如果你到現在還一直這麼認爲的話，我奉勸你儘早放棄測試工作。
需要補充說明的是，手工測試並不是完全丟棄的，因爲測試一定要站在用戶的角度，站在業務層的角度。越往金字塔的上層，在測試時越能體會到用戶感受，特別是項目型公司，我這裏強調的只是從測試比重分佈不同而已（要加重底層的測試比例）。