讀理工科的人多多少少做過物理實驗，從中學到大學有數不清的機會。對照書本的步驟一項一項做下來，看到預期的結果就收工走人，不然就找原因直到得到正確結果為止。
這就是物理實驗嗎？
從事科研工作的人對這種「實驗」嗤之以鼻。這樣做除了應付一下教育部一點價值都沒有。
科學研究是要探索未知的世界，並沒有乙個先知可以斷言某件事情，而我們不經證實就奉為真理。出發點不同，行為的效果便大相徑庭。要探索未知的世界，除了試驗既定的路線外，還須廣歷不同的路線，獲得大量的資訊來了解世界的真相；反之僅僅是重複的話，只需要走固定的步驟，如果結果不同還要想方設法為預期結果辯護，實在是南轅北轍。
有人會問，科學家重複同行的實驗又作何論？那時實驗結論尚未成為公論，需要重複已有實驗，並輔以新的實驗來證實懷疑；也有挑戰現有理論，改變條件試圖證明新的理論。這些都是為了探索證實未知的世界，出發點大不一樣。
那麼，軟體測試是為了探索世界還是重複檢驗呢？
有人認為，程式設計師寫的**，設計目的是明確的，所用技術是清晰的。只要有領域內的專家，所有軟體行為都是可預期的，軟體測試就是例行公事再確認一下。
早期的計算機工作者的確是這樣的，他們都是領域內的專家，根據**能夠準確指出程式的行為。如果說他們是上帝，程式就是他們完美的伊甸園，什麼都在計畫之內。
然而時過境遷，現在的軟體團隊裡面不可能所有人都是專家，也不是所有領域都有專家。除了火箭控制之類要求高可靠性的系統，大多數的軟體都是由非專家編寫出來的。所以程式設計師不一定知道**有死鎖和餓死，不一定知道**有資源洩漏，不一定知道**有相容性問題。他們可能還是上帝，只是做出來的不再是伊甸園了。以今天軟體系統的複雜度而言，每個團隊都維護一大堆上帝成本太高。
因此，程式設計師很多對他們作品的假設，未經證實之前不一定正確：
「這個列表會列出所有結果」 -- 沒有或者很多結果的時候呢？
「這個列表不會有重複的物件」 -- 刪除a之後新增a，且非同步的刪除失敗的時候呢？
「這個列表的輸出不會錯的「 -- 多個資料來源同時對其輸入大量的資料呢？
這個結論會導致軟體測試的乙個可怕悖論：測試用例不少是來自程式設計師的假設，不正確的假設使得這些用例可能是不正確或無意義的。
這正是很多測試書籍介紹的邊界、效能、壓力、可擴充套件和安全測試的由來：正是需要檢驗那些假設的真實性。
但是事情還沒完。
測試員也不是上帝，他們做出來的也不是伊甸園。
如果程式設計師的產出是**和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沉渣泛起。
可見，反映真相的全部是重現步驟的靈魂，因為程式設計師構建出來的世界是未知的，我們需要知道哪些假設還是正確的，哪些已經不正確了。
那麼反映全部真相就是測試員要做的全部嗎？
請注意還有錯誤細節。這通常是幫助程式設計師定位錯誤的資料，一般是反映出錯時系統各方面的狀態。
很多軟體系統在開發階段都會輸出log，測試員也被要求在bug報告裡面提供log。
只是我見過的乙個bug報告，把幾乎所有東西，包括幾百mb的log和crash dump都放進去。程式設計師看了半天愣是找不著北。後來的事實證明，只要再多做乙個改變了條件的實驗，問題根源就馬上出現在一行log裡面了（也就是說，程式設計師也知道這裡要檢驗一些假設，關鍵是測試員要接觸到）。未經篩選的大量資訊等於沒有資訊。運用邏輯推理定位根本原因是探索未知世界的重要工作。測試員的懶惰浪費了程式設計師的大量時間。這如同羅列大量的資料，卻不告訴讀者要反映的意思蘊含在**一樣。
所以，你會發現，軟體測試其實和科研實驗，不僅僅是物理，甚至與化學、生物、醫學實驗，有著高度的相似性。
有人會問，如果每個假設都要驗證，測試工作量豈不是很大？
其實，這正是計算機工業發展的標誌，從組合語言、作業系統、高階程式語言到各種框架、架構，都是在使軟體開發更專注於有價值的部分，而不用關注早已驗證的部分。你不用關心核心/使用者態轉換的假設，因為有system api的承諾；你不用關心其他模組的實現假設，因為有對介面協議的承諾。但是很多**於這個軟體本身的假設，並沒有經過驗證，這些才是我們需要關注的假設。
而正是這些假設**於軟體本身，測試員需要從外到內全面了解整個軟體，才能找到全部假設並一一加以驗證。這同時也是白箱測試和黑箱測試並存的原因：只觀察軟體外部，不能檢驗內部實現的假設；只觀察軟體實現，不能檢驗使用者互動的假設。
最後，有乙個相通的問題，如果現有高考制度的弊端看成是乙個bug，你又可以改變不同條件檢驗你的設想，你將通過哪些實驗找出根源所在？
物理實驗與軟體測試
讀理工科的人多多少少做過物理實驗，從中學到大學有數不清的機會。對照書本的步驟一項一項做下來，看到預期的結果就收工走人，不然就找原因直到得到正確結果為止。這就是物理實驗嗎？從事科研工作的人對這種 實驗 嗤之以鼻。這樣做除了應付一下教育部一點價值都沒有。科學研究是要探索未知的世界，並沒有乙個先知可以斷言...
軟體測試實驗1
實驗1 實驗題目 一 實驗目的 實驗所要達到那些目的 1 理解邊界值測試的原理和方法。2 掌握由邊界值產生測試用例的方法。二 實驗內容或實驗過程 實驗所做的內容 1 由給定軟體規格說明書寫出源程式並執行。見附錄1 2 用健壯邊界值方法產生測試用例。3 執行軟體，輸入測試用例並記錄結果。4 分析結果，...
軟體測試黑盒測試實驗心得 如何學習軟體測試
1.什麼是軟體測試 軟體測試是在測試中識別軟體產品和服務的準確性和質量的過程。顯然，它的誕生是為了驗證產品是否滿足客戶的特定先決條件 需求和需求。在一天的工作結束前，確定特定的最終目標並測試執行乙個框架或應用程式，以指出其錯誤 錯誤或缺陷。測試的職責是找到bug並指出問題問題，並給dev 開發人員 ...