我在微軟亞洲工程院從事測試工作已經有兩年了。兩年間走了很多彎路，但也學習了很多無法從書本上知道的知識，有了一些關於測試的思考和心得，於是打算寫出來與大家一起分享。這次我想談論的話題是：是什麼在決定著軟體測試的設計與決策？
測試新手的困惑
讀研的時候，我曾經讀過一些有關測試的書籍（也許有些人會覺得我奇怪，因為大多數
cs和ee身的人都更喜歡做開發，而通常會把測試當作「第二志願」或者根本不予考慮）。但是到了微軟以後，我卻發現真正的測試工作與那些書上所寫的內容總是有些差別。這種差別總是讓人感到很茫然，甚至洩氣，因為它會影響我們做決策時的信心。特別是被老闆或者老資格的員工challenge時，這種缺乏信心的表現就會更加明顯。下面舉兩個典型的有關實際與書本的差別的例子：
不僅如此，不同的測試小組之間對同一種測試的設計和實現通常也會有些許的出入，比如： ·
在有些測試小組內，效能測試被當作一項非常重要的測試；而在其他的測試小組內，效能測試只在每個
milestone的結尾才會手動的執行一次。
這些現象都令人非常困惑。我時常會問自己這樣乙個問題：
如果有一天我領導乙個測試小組接手乙個新的產品專案，或者在已有的產品上增加新的功能，我應該如何設計實現針對這個產品的測試？在有爭議的問題上我又應該依據什麼做出決策？顯然，這個時候照搬書本上的或者其他測試小組的
best practice是有一定危險的。
其實，這個問題的實質就是要回答「是什麼在決定著軟體測試的設計與決策」。
軟體測試背後的那只無形的手– 商業利益與商業效率
針對這個問題，我一直在思索，都沒有得到滿意的答案。直到有一次我去美國總部出差，在那裡我通過和美國總部的同事交談，得到了答案：
決定測試的設計與決策的是其背後的商業利益和商業效率的考量。
簡單的說，就是測試工作的投入和產出決定了測試的設計與決策。
為了形象的解釋這個觀點，首先把我們自己想象成乙個軟體公司的
ceo，在俯視公司全景的同時，思考這樣兩個問題：
原因只有乙個，那就是與對測試部門的投入相比，測試部門能夠減少費用支出或者避免損失。當然，從另乙個角度想這其實就是在創造價值，就是測試的產出，而且這個產出一定要高於對測試部門的投入，並且其商業效率應該不低於軟體投資的平均資產增值率。否則，我們將有理由直接將測試部門從公司的部門列表中刪掉，並省下這筆投入。
所以，說測試能夠保證軟體的質量也好，說測試能夠提高客戶滿意度也好，其實這些都是測試在整個軟體商業鏈條中的一種價值的體現，但並不是軟體測試存在的根本原因。如果測試的商業利益是負的，或者測試的商業效率低於平均的軟體投資的平均資產增值率，那麼這樣質量應該沒有哪個軟體企業願意去保證，這樣的客戶滿意度也沒有哪個企業願意去提高。
真實的測試案例
以下是幾個真實的測試設計與決策的案例。一年前，我到美國總部的測試實驗室去了解那裡是如何在
windows mobile和ce上測試射頻驅動程式（此驅動程式用於驅動手機或嵌入式裝置上的射頻**模組）的。在那裡我得到了對這些案例的正確解讀。
自動化測試vs完備文件。
在實驗室中，我見到了我所見過的最大的自動化測試系統。所有的功能測試都是通過這種自動化系統完成的。系統由數量巨大的測試裝置和中心測試驅動伺服器組成，測試人員只要通過遠端的客戶端安排自動化測試任務並將之提交到中心測試驅動伺服器上即可，其餘的工作將由中心測試驅動伺服器完成。這個過程包括搜尋處於空閒狀態的測試裝置，啟動並控制測試裝置，並在測試完成後收集日誌資料資訊和計算測試通過率。
這時，我突然想到了我先前的疑惑——為什麼與編寫完備的測試文件相比，我們在實際工作中更看重測試的自動化？我的美國同事給我的回答是：執行成本的原因。編寫完備的測試文件自然是能夠幫助測試小組完整的記錄所有的測試用例，但是對於乙個在作業系統上起著重要作用的驅動程式而言，每週兩次的回歸測試是才是保證驅動程式質量的根本手段。可以想象，如果沒有自動化測試，而是依據文件中的測試用例，這種頻繁的回歸測試將會消耗多少人力物力。而與此同時，自動化的測試程式和用例使用統一的測試框架，並且輔助以相當的注釋，這樣測試程式和用例的**本身已經能夠很好的說明測試用例的詳細資訊，所以在文件中便不再需要重複的詳細資訊了。
龐大到不可思議的壓力測試系統。
在實驗室中，我見到了我所見過的最大的壓力測試系統。這個系統整整擺滿了三排鐵架子，幾乎佔了整個實驗室的四分之一的位置。架子上除了幾台用於日誌資料分析的伺服器以外，剩下的全都是各種各樣的手機或者嵌入式系統。架子上沒有測試驅動伺服器，因為測試驅動服務是通過網路由中心測試驅動伺服器提供的，這種服務是所有測試系統共享的。這些裝置自動化的從中心測試驅動伺服器得到壓力測試用例集，並自動執行
13小時左右的壓力測試，與此同步的是產生的日誌資料將通過中心測試驅動伺服器傳輸給日誌分析伺服器用於錯誤分析。當測試結束或者有不可恢復的程式錯誤或者系統錯誤出現時，測試裝置將停止測試，並由中心測試驅動伺服器撲捉這種事件，在經過適當的記錄和處理後測試裝置將被重置，並且準備進行下一次壓力測試。這樣龐大的壓力測試系統令我產生了疑問——為什麼我們需要如此大力度的壓力測試？花費如此多的人力物力是否值得？
我從美國同事那裡得到的答案是這樣的。其實開始的時候並沒有這樣龐大的壓力測試系統。和許多其他專案的壓力測試類似，針對射頻驅動程式的壓力測試也只是在一兩種嵌入式系統上進行，而且根本沒有手機參與其中。但是，從後來的使用者反饋中發現，在很多手機和嵌入式系統上都存在著長時間反覆使用**功能後**簡訊功能失靈的現象，而在已有的壓力測試過程中並沒有發現類似的問題。來自
oem的壓力越來越大，oem的反饋表明這個問題增加了他們通過入網測試時的難度，使得研發成本增加了很多，與此同時，客戶服務部門也在抱怨此類問題加重了他們的日常工作。問題已經變得很嚴重了，於是這個測試小組做了乙個決定，擴大壓力測試的範圍、頻度和力度。從此，很多手機和嵌入式系統就逐步的加入了這個壓力測試系統。另外，原先的系統中是沒有日誌資料分析伺服器的，但是隨著測試裝置的日益增多，在海量的日誌資料中捕捉出錯資訊的工作也變得越來越繁重，測試小組無法再提供更多的人力用於分析這些日誌資料。於是又有人提議架設一台能夠用於分析日誌資料的伺服器，程式由測試開發工程師設計和編寫，並負責日常維護。後來，隨著測試裝置的繼續增加，一台伺服器不能滿足其要求了，於是又增加了幾台，直到今天的規模。在這個系統投入測試後的一段時間內，很多非常難於發現的bug浮出了水面，在修正了這些bug後先前提到的問題就基本絕跡了。
很明顯，建立如此龐大的壓力測試系統的真正原因是
oem和客戶服務部門由於驅動程式穩定性差而產生的巨大費用造成的。從測試原理本身或者測試小組對於產品質量的理解出發並不能支援建立這樣大的壓力測試系統，所以說這個測試系統是商業利益驅動的。
非常簡單的效能測試。
在實驗室中另乙個讓我感到驚奇的是實驗室中沒有用於測試射頻驅動程式效能的任何裝置，而就在這個實驗室的另外兩個架子上卻擺滿了用於測試另乙個模組的效能測試系統。這在驅動程式的測試實踐中實在是不多見的。很難想象，乙個驅動程式沒有自動化的效能測試系統對其進行測試。
對於這個問題，美國同事的解釋是：的確沒有自動化的效能測試系統，但是效能測試在每個
milestone結束時會由測試小組中的一名測試開發工程師手動完成。如此處理的主要原因是，從以往的測試資料看來，驅動程式不是其所在的功能呼叫棧中的效能瓶頸，並且射頻驅動程式的效能明顯比瓶頸的效能高很多。所以在沒有很大的結構變動的情況下，效能通常不會成為嚴重影響程式質量的因素，所以效能測試就如此簡單了。當然，如果射頻驅動程式是整個功能呼叫棧的效能瓶頸的話，結果就會大不相同了。
很明顯，簡化效能測試的真正原因是對非瓶頸模組的效能測試和優化不會對功能呼叫棧整體的效能產生貢獻，當然這樣的投入也幾乎不會有大的商業價值的產出，所以，簡化效能測試並維持乙個最基本的效能測試便是最佳的選擇。
其實，從更高的角度觀察，整個軟體產業都是商業性的，所以作為其重要組成部分的軟體測試也必然帶有商業性，但這恰恰是不容易發現的。
軟體測試的有關概念
目的 驗證軟體有或沒有問題。原則 以客戶為中心，遵循軟體測試的規範，流程，標準和要求。使用者需求 可以簡單理解為甲方提出的需求，如果沒有甲方，那麼就是終端使用者使用產品時必須要完成的任務。該需求一般比較簡略。軟體需求 或者叫做功能需求，該需求會詳細描述開發人員必須實現的軟體功能。軟體需求是測試人員進...
軟體測試思考之手工測試
測試的工作，通常就是找bug，對於乙個bug，上的錯誤，屬於直接錯誤，改好 bug消失，測試就結束了，這是初級測試。如果要高階，要進行更加高階的思考，為什麼會產生這個bug，很多人直觀的覺得，產生bug不就是因為寫錯 了麼。然而現實工作中，我發現很多bug產生的原因，是因為開發不理解需求。這時候，我...
關於軟體測試的個人思考
最近拜讀了一本軟體測試入門級書籍 大話軟體測試 感覺受益良多。作為乙個還沒有入門的新手來說，這本書可以迅速幫助了解軟體測試領域的概況 思想 技術 管理等一些因素，使得新手能夠迅速的了解軟體測試這個行業。軟體測試，這個行業的誕生就是為了盡可能保障客戶在使用軟體時所蒙受的損失。總所周知，任何軟體都不可能...