這就是物理實驗嗎？
從事科研工作的人對這種“實驗”嗤之以鼻。這樣做除了應付一下教育部一點價值都沒有。
科學研究是要探索未知的世界，并沒有一個先知可以斷言某件事情，而我們不經證實就奉為真理。出發點不同，行為的效果便大相徑庭。要探索未知的世界，除了試驗既定的路線外，還須廣歷不同的路線，獲得大量的信息來了解世界的真相；反之僅僅是重復的話，只需要走固定的步驟，如果結果不同還要想方設法為預期結果辯護，實在是南轅北轍。
有人會問，科學家重復同行的實驗又作何論？那時實驗結論尚未成為公論，需要重復已有實驗，并輔以新的實驗來證實懷疑；也有挑戰現有理論，改變條件試圖證明新的理論。這些都是為了探索證實未知的世界，出發點大不一樣。
那么，軟件測試是為了探索世界還是重復檢驗呢？
有人認為，程序員寫的代碼，設計目的是明確的，所用技術是清晰的。只要有領域內的專家，所有軟件行為都是可預期的，軟件測試就是例行公事再確認一下。
早期的計算機工作者的確是這樣的，他們都是領域內的專家，根據代碼能夠準確指出程序的行為。如果說他們是上帝，程序就是他們完美的伊甸園，什么都在計劃之內。
然而時過境遷，現在的軟件團隊里面不可能所有人都是專家，也不是所有領域都有專家。除了火箭控制之類要求高可靠性的系統，大多數的軟件都是由非專家編寫出來的。所以程序員不一定知道哪里有死鎖和餓死，不一定知道哪里有資源泄漏，不一定知道哪里有兼容性問題。他們可能還是上帝，只是做出來的不再是伊甸園了。以今天軟件系統的復雜度而言，每個團隊都維護一大堆上帝成本太高。
因此，程序員很多對他們作品的假設，未經證實之前不一定正確：
“這個列表會列出所有結果” -- 沒有或者很多結果的時候呢？
“這個列表不會有重復的對象” -- 刪除A之后添加A，且異步的刪除失敗的時候呢？
“這個列表的輸出不會錯的“ -- 多個數據源同時對其輸入大量的數據呢？
這個結論會導致軟件測試的一個可怕悖論：測試用例不少是來自程序員的假設，不正確的假設使得這些用例可能是不正確或無意義的。
這正是很多測試書籍介紹的邊界、性能、壓力、可擴展和安全測試的由來：正是需要檢驗那些假設的真實性。
但是事情還沒完。 [Page]
測試員也不是上帝，他們做出來的也不是伊甸園。
如果程序員的產出是代碼和bug修復，測試員的產出就是測試用例和bug報告。
我們剛才忽略了bug報告。
bug報告有兩個最重要的部分，重現步驟和錯誤細節。而其中出現的不正確的假設和推理主要有三種：
如果A在B之前出現，A是B的原因
如果A和B同時出現，A與B有因果關系
如果A被證實是B的原因，A是B的唯一原因
我用一個幾周前碰到的例子來說明不正確的假設和推理的影響。
用戶報告說產品彈出了空白的窗口，于是登記一個bug，還沒有重現步驟
到用戶的機器（繁體中文Vista）上證實了某個插件開啟和關閉后，這個bug出現和消失（事情很順利吧），于是添加重現步驟：“繁體中文Vista，安裝某插件，出現空白窗口；卸載或關閉插件后癥狀消失“
程序員說肯定是瀏覽器插件改變了某處打開窗口的行為，代碼沒有料到這一點，測試員覺得有道理
回到辦公室在自己的Vista和XP上試圖重現，失敗，更堅定是繁體中文Vista的問題
于是在繁體中文Vista上試圖重現，失敗，傻眼，只好修改重現步驟，暫時去掉繁體中文Vista的字樣
呼吁大家幫忙重現
好消息傳來，在一臺Vista Business Edition上得以重現，于是添加到重現步驟中
在另外兩臺Business Edition上嘗試，一個能重現，另一個不能，又傻眼了
懷疑是CPU或內存負荷造成的競爭條件，發現不能重現的機器和第一臺能重現的一樣，繼續傻眼
連Windows 2003 Server都能重現，無限傻眼
可能是插件版本的問題，發現所有地方都是安裝最新的版本
程序員修復之后，所有地方都不重現了，不過被告知離發布時間太短，這個修復不添加到發布版本里了，改為寫在已知問題里面
開始仔細檢查系統、瀏覽器和插件的設置
好了，到現在為止13還在進行中。但是請留意幾個細節：
12證實了3，如果到此為止，從4到11都不做，那么在用戶數不清的平臺組合下重現步驟就是個大笑話。錯誤假設3是一個危險的誘惑。
4、7、10都是有可能停止實驗的地方，那樣13就永遠不會啟動，離真正原因更是遙不可及。錯誤假設1和2都是危險的誘惑。
程序員不一定能做到3，那么在13之前得到的重現步驟都是在把程序員引入歧途。即使修復了，由于不了解真正原因，13所發現的特殊設置可能使這個bug沉渣泛起。 可見，反映真相的全部是重現步驟的靈魂，因為程序員構建出來的世界是未知的，我們需要知道哪些假設還是正確的，哪些已經不正確了。 [Page]
那么反映全部真相就是測試員要做的全部嗎？
請注意還有錯誤細節。這通常是幫助程序員定位錯誤的數據，一般是反映出錯時系統各方面的狀態。
很多軟件系統在開發階段都會輸出log，測試員也被要求在bug報告里面提供log。
只是我見過的一個bug報告，把幾乎所有東西，包括幾百MB的log和crash dump都放進去。程序員看了半天愣是找不著北。后來的事實證明，只要再多做一個改變了條件的實驗，問題根源就馬上出現在一行log里面了（也就是說，程序員也知道這里要檢驗一些假設，關鍵是測試員要接觸到）。未經篩選的大量信息等于沒有信息。運用邏輯推理定位根本原因是探索未知世界的重要工作。測試員的懶惰浪費了程序員的大量時間。這如同羅列大量的數據，卻不告訴讀者要反映的意思蘊含在哪里一樣。所以，你會發現，軟件測試其實和科研實驗，不僅僅是物理，甚至與化學、生物、醫學實驗，有著高度的相似性。
有人會問，如果每個假設都要驗證，測試工作量豈不是很大？
其實，這正是計算機工業發展的標志，從匯編語言、操作系統、高級程序語言到各種框架、架構，都是在使軟件開發更專注于有價值的部分，而不用關注早已驗證的部分。你不用關心內核/用戶態轉換的假設，因為有system API的承諾；你不用關心其他模塊的實現假設，因為有對接口協議的承諾。但是很多來源于這個軟件本身的假設，并沒有經過驗證，這些才是我們需要關注的假設。
而正是這些假設來源于軟件本身，測試員需要從外到內全面了解整個軟件，才能找到全部假設并一一加以驗證。這同時也是白箱測試和黑箱測試并存的原因：只觀察軟件外部，不能檢驗內部實現的假設；只觀察軟件實現，不能檢驗用戶交互的假設。
最后，有一個相通的問題，如果現有高考制度的弊端看成是一個bug，你又可以改變不同條件檢驗你的設想，你將通過哪些實驗找出根源所在？
我在《讀者》2007年第12期看到一篇文章，它所列出來的高考制度相關因素之多，會令你覺得需要做的實驗實在是一個天文數字。這會令你覺得，從事計算機行業比起從事行政管理，實在是要簡單不少。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/