決定軟件測試的那只無形的手 軟件測試
我在微軟亞洲工程院從事測試工作已經有兩年了。兩年間走了很多彎路，但也學習了很多無法從書本上知道的知識，有了一些關于測試的思考和心得，于是打算寫出來與大家一起分享。這次我想談論的話題是：是什么在決定著軟件測試的設計與決策？
測試新手的困惑
讀研的時候，我曾經讀過一些有關測試的書籍（也許有些人會覺得我奇怪，因為大多數CS和EE身的人都更喜歡做開發，而通常會把測試當作“第二志愿”或者根本不予考慮）。但是到了微軟以后，我卻發現真正的測試工作與那些書上所寫的內容總是有些差別。這種差別總是讓人感到很茫然，甚至泄氣，因為它會影響我們做決策時的信心。特別是被老板或者老資格的員工challenge時，這種缺乏信心的表現就會更加明顯。下面舉兩個典型的有關實際與書本的差別的例子：
· 很多測試理論都指出，編寫詳細而完整的測試文檔是測試設計與實現的第一步，也是最重要的一步。通常要求每個測試用例都要有詳細的測試用例文檔。而實際工作中的測試文檔則相對簡單了許多，有時只是包括測試用例名稱的列表，沒有詳細的針對測試用例的描述。而與此同時，所有的測試都要求實現自動化，所有的測試用例都包含在測試程序中，而在很多測試理論中，自動化測試只是一種輔助的測試手段，并不是必須的。如果按照一般的測試理論，新手在工作計劃中規劃很長時間用于編寫測試文檔，而同時又忽略了測試自動化，那么這個工作計劃將很難被認可并通過。
· 大多數測試理論都很少對壓力測試有太多的論述，從我的理解看來似乎壓力測試并不是一種非常重要的測試。而實際工作中，壓力測試是僅次于功能測試的一種測試，通常說來程序在經過基本的功能測試并達到一定的測試通過率以后，壓力測試便會開始（在此之前壓力測試程序必須準備就緒），并且持續不斷一直到程序被發布。如果按照一般的測試理論，新手沒有給予壓力測試足夠的重視，或者在時間的安排上過于靠后，那么這個工作計劃也將很難被認可并通過。
不僅如此，不同的測試小組之間對同一種測試的設計和實現通常也會有些許的出入，比如：
· 在有些測試小組內，性能測試被當作一項非常重要的測試；而在其他的測試小組內，性能測試只在每個milestone的結尾才會手動的運行一次。
這些現象都令人非常困惑。我時常會問自己這樣一個問題：
如果有一天我領導一個測試小組接手一個新的產品項目，或者在已有的產品上增加新的功能，我應該如何設計實現針對這個產品的測試？在有爭議的問題上我又應該依據什么做出決策？顯然，這個時候照搬書本上的或者其他測試小組的best practice是有一定危險的。
其實，這個問題的實質就是要回答“是什么在決定著軟件測試的設計與決策”。
軟件測試背后的那只無形的手 – 商業利益與商業效率
針對這個問題，我一直在思索，都沒有得到滿意的答案。直到有一次我去美國總部出差，在那里我通過和美國總部的同事交談，得到了答案：
決定測試的設計與決策的是其背后的商業利益和商業效率的考量。
簡單的說，就是測試工作的投入和產出決定了測試的設計與決策。
· 測試的商業利益 = 測試的產出 – 測試的投入
· 測試的商業效率 = 測試的商業利益 ÷ 測試的投入 × 100%
為了形象的解釋這個觀點，首先把我們自己想象成一個軟件公司的CEO，在俯視公司全景的同時，思考這樣兩個問題：
· 公司為什么要雇傭大量的軟件測試工程師，并且人數逐年遞增？
· 公司為什么每年要為測試部門提供大筆的預算，并且還逐年追加投入？
原因只有一個，那就是與對測試部門的投入相比，測試部門能夠減少費用支出或者避免損失。當然，從另一個角度想這其實就是在創造價值，就是測試的產出，而且這個產出一定要高于對測試部門的投入，并且其商業效率應該不低于軟件投資的平均資產增值率。否則，我們將有理由直接將測試部門從公司的部門列表中刪掉，并省下這筆投入。
所以，說測試能夠保證軟件的質量也好，說測試能夠提高客戶滿意度也好，其實這些都是測試在整個軟件商業鏈條中的一種價值的體現，但并不是軟件測試存在的根本原因。如果測試的商業利益是負的，或者測試的商業效率低于平均的軟件投資的平均資產增值率，那么這樣質量應該沒有哪個軟件企業愿意去保證，這樣的客戶滿意度也沒有哪個企業愿意去提高。
真實的測試案例
以下是幾個真實的測試設計與決策的案例。一年前，我到美國總部的測試實驗室去了解那里是如何在Windows Mobile和CE上測試射頻驅動程序（此驅動程序用于驅動手機或嵌入式設備上的射頻電話模塊）的。在那里我得到了對這些案例的正確解讀。
自動化測試VS完備文檔。
在實驗室中，我見到了我所見過的最大的自動化測試系統。所有的功能測試都是通過這種自動化系統完成的。系統由數量巨大的測試設備和中心測試驅動服務器組成，測試人員只要通過遠程的客戶端安排自動化測試任務并將之提交到中心測試驅動服務器上即可，其余的工作將由中心測試驅動服務器完成。這個過程包括搜索處于空閑狀態的測試設備，啟動并控制測試設備，并在測試完成后收集日志數據信息和計算測試通過率。
這時，我突然想到了我先前的疑惑——為什么與編寫完備的測試文檔相比，我們在實際工作中更看重測試的自動化？我的美國同事給我的回答是：運行成本的原因。編寫完備的測試文檔自然是能夠幫助測試小組完整的記錄所有的測試用例，但是對于一個在操作系統上起著重要作用的驅動程序而言，每周兩次的回歸測試是才是保證驅動程序質量的根本手段�？梢韵胂�，如果沒有自動化測試，而是依據文檔中的測試用例，這種頻繁的回歸測試將會消耗多少人力物力。而與此同時，自動化的測試程序和用例使用統一的測試框架，并且輔助以相當的注釋，這樣測試程序和用例的代碼本身已經能夠很好的說明測試用例的詳細信息，所以在文檔中便不再需要重復的詳細信息了。
龐大到不可思議的壓力測試系統。
在實驗室中，我見到了我所見過的最大的壓力測試系統。這個系統整整擺滿了三排鐵架子，幾乎占了整個實驗室的四分之一的位置。架子上除了幾臺用于日志數據分析的服務器以外，剩下的全都是各種各樣的手機或者嵌入式系統。架子上沒有測試驅動服務器，因為測試驅動服務是通過網絡由中心測試驅動服務器提供的，這種服務是所有測試系統共享的。這些設備自動化的從中心測試驅動服務器得到壓力測試用例集，并自動運行13小時左右的壓力測試，與此同步的是產生的日志數據將通過中心測試驅動服務器傳輸給日志分析服務器用于錯誤分析。當測試結束或者有不可恢復的程序錯誤或者系統錯誤出現時，測試設備將停止測試，并由中心測試驅動服務器撲捉這種事件，在經過適當的記錄和處理后測試設備將被重置，并且準備進行下一次壓力測試。這樣龐大的壓力測試系統令我產生了疑問——為什么我們需要如此大力度的壓力測試？花費如此多的人力物力是否值得？
我從美國同事那里得到的答案是這樣的。其實開始的時候并沒有這樣龐大的壓力測試系統。和許多其他項目的壓力測試類似，針對射頻驅動程序的壓力測試也只是在一兩種嵌入式系統上進行，而且根本沒有手機參與其中。但是，從后來的用戶反饋中發現，在很多手機和嵌入式系統上都存在著長時間反復使用電話功能后電話短信功能失靈的現象，而在已有的壓力測試過程中并沒有發現類似的問題。來自OEM的壓力越來越大，OEM的反饋表明這個問題增加了他們通過入網測試時的難度，使得研發成本增加了很多，與此同時，客戶服務部門也在抱怨此類問題加重了他們的日常工作。問題已經變得很嚴重了，于是這個測試小組做了一個決定，擴大壓力測試的范圍、頻度和力度。從此，很多手機和嵌入式系統就逐步的加入了這個壓力測試系統。另外，原先的系統中是沒有日志數據分析服務器的，但是隨著測試設備的日益增多，在海量的日志數據中捕捉出錯信息的工作也變得越來越繁重，測試小組無法再提供更多的人力用于分析這些日志數據。于是又有人提議架設一臺能夠用于分析日志數據的服務器，程序由測試開發工程師設計和編寫，并負責日常維護。后來，隨著測試設備的繼續增加，一臺服務器不能滿足其要求了，于是又增加了幾臺，直到今天的規模。在這個系統投入測試后的一段時間內，很多非常難于發現的bug浮出了水面，在修正了這些bug后先前提到的問題就基本絕跡了。
很明顯，建立如此龐大的壓力測試系統的真正原因是OEM和客戶服務部門由于驅動程序穩定性差而產生的巨大費用造成的。從測試原理本身或者測試小組對于產品質量的理解出發并不能支持建立這樣大的壓力測試系統，所以說這個測試系統是商業利益驅動的。
非常簡單的性能測試。
在實驗室中另一個讓我感到驚奇的是實驗室中沒有用于測試射頻驅動程序性能的任何設備，而就在這個實驗室的另外兩個架子上卻擺滿了用于測試另一個模塊的性能測試系統。這在驅動程序的測試實踐中實在是不多見的。很難想象，一個驅動程序沒有自動化的性能測試系統對其進行測試。
對于這個問題，美國同事的解釋是：的確沒有自動化的性能測試系統，但是性能測試在每個milestone結束時會由測試小組中的一名測試開發工程師手動完成。如此處理的主要原因是，從以往的測試數據看來，驅動程序不是其所在的功能調用棧中的性能瓶頸，并且射頻驅動程序的性能明顯比瓶頸的性能高很多。所以在沒有很大的結構變動的情況下，性能通常不會成為嚴重影響程序質量的因素，所以性能測試就如此簡單了。當然，如果射頻驅動程序是整個功能調用棧的性能瓶頸的話，結果就會大不相同了。
很明顯，簡化性能測試的真正原因是對非瓶頸模塊的性能測試和優化不會對功能調用棧整體的性能產生貢獻，當然這樣的投入也幾乎不會有大的商業價值的產出，所以，簡化性能測試并維持一個最基本的性能測試便是最佳的選擇。
其實，從更高的角度觀察，整個軟件產業都是商業性的，所以作為其重要組成部分的軟件測試也必然帶有商業性，但這恰恰是不容易發現的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/