決定軟件測試的那只無形的手[1] 軟件測試
我在微軟亞洲工程院從事測試工作已經有兩年了。兩年間走了很多彎路，但也學習了很多無法從書本上知道的知識，有了一些關于測試的思考和心得，于是打算寫出來與大家一起分享。這次我想談論的話題是：是什么在決定著軟件測試的設計與決策?
測試新手的困惑
讀研的時候，我曾經讀過一些有關測試的書籍(也許有些人會覺得我奇怪，因為大多數CS和EE身的人都更喜歡做開發，而通常會把測試當作“第二志愿”或者根本不予考慮)。但是到了微軟以后，我卻發現真正的測試工作與那些書上所寫的內容總是有些差別。這種差別總是讓人感到很茫然，甚至泄氣，因為它會影響我們做決策時的信心。特別是被老板或者老資格的員工challenge時，這種缺乏信心的表現就會更加明顯。下面舉兩個典型的有關實際與書本的差別的例子：
· 很多測試理論都指出，編寫詳細而完整的測試文檔是測試設計與實現的第一步，也是最重要的一步。通常要求每個測試用例都要有詳細的測試用例文檔。而實際工作中的測試文檔則相對簡單了許多，有時只是包括測試用例名稱的列表，沒有詳細的針對測試用例的描述。而與此同時，所有的測試都要求實現自動化，所有的測試用例都包含在測試程序中，而在很多測試理論中，自動化測試只是一種輔助的測試手段，并不是必須的。如果按照一般的測試理論，新手在工作計劃中規劃很長時間用于編寫測試文檔，而同時又忽略了測試自動化，那么這個工作計劃將很難被認可并通過。
· 大多數測試理論都很少對壓力測試有太多的論述，從我的理解看來似乎壓力測試并不是一種非常重要的測試。而實際工作中，壓力測試是僅次于功能測試的一種測試，通常說來程序在經過基本的功能測試并達到一定的測試通過率以后，壓力測試便會開始(在此之前壓力測試程序必須準備就緒)，并且持續不斷一直到程序被發布。如果按照一般的測試理論，新手沒有給予壓力測試足夠的重視，或者在時間的安排上過于靠后，那么這個工作計劃也將很難被認可并通過。
不僅如此，不同的測試小組之間對同一種測試的設計和實現通常也會有些許的出入，比如：
· 在有些測試小組內，性能測試被當作一項非常重要的測試;而在其他的測試小組內，性能測試只在每個milestone的結尾才會手動的運行一次。
這些現象都令人非常困惑。我時常會問自己這樣一個問題：
如果有一天我領導一個測試小組接手一個新的產品項目，或者在已有的產品上增加新的功能，我應該如何設計實現針對這個產品的測試?在有爭議的問題上我又應該依據什么做出決策?顯然，這個時候照搬書本上的或者其他測試小組的best practice是有一定危險的。
其實，這個問題的實質就是要回答“是什么在決定著軟件測試的設計與決策”。
軟件測試背后的那只無形的手 – 商業利益與商業效率
針對這個問題，我一直在思索，都沒有得到滿意的答案。直到有一次我去美國總部出差，在那里我通過和美國總部的同事交談，得到了答案：
決定測試的設計與決策的是其背后的商業利益和商業效率的考量。
簡單的說，就是測試工作的投入和產出決定了測試的設計與決策。
· 測試的商業利益 = 測試的產出 – 測試的投入
· 測試的商業效率 = 測試的商業利益 ÷ 測試的投入 × 100%
為了形象的解釋這個觀點，首先把我們自己想象成一個軟件公司的CEO，在俯視公司全景的同時，思考這樣兩個問題：
· 公司為什么要雇傭大量的軟件測試工程師，并且人數逐年遞增?
· 公司為什么每年要為測試部門提供大筆的預算，并且還逐年追加投入?
文章來源于領測軟件測試網 http://www.kjueaiud.com/
