曾夢想仗劍走天涯，現在卻因Bug想回家，揭秘程式設計師最難忘的那些Bug

●　 Anutthara 的缺陷

有一個缺陷讓我銘記了四年，至今不能忘卻。我們進行的 工作 是本地化 測試 ，為了使使用者可以在不同語言的 作業系統 中安裝我們的產品。當我在對一產品進行 Beta 版測試時，我將該產品安裝在了日語  Windows  2003 (W2K3) 作業系統上，並測試了其基本功能，完全沒有碰到問題。當然，它在英語 W2K3 系統上也執行得非常好。所以我們對這次測試的整個感覺非常不錯。

 

接著我們即進入迴圈測試，我將該產品安裝在了一臺德語系統的機器上，並試圖開始執行某一版本。就在此時，機器突然崩潰了！程式碼開始比對硬編碼“Administrator”用於確認使用者是否擁有管理者許可權。這個缺陷之所以沒有在日語 系統測試 中出現，是因為在日語系統中使用者組未進行本地化翻譯，仍舊保留為“Administrator”，而德語系統中則被翻譯為“Administrat?n”。我從中瞭解到對於硬編碼檢查的重要性，不能因為單單在一個平臺上透過本地化測試，即認為 其他 平臺也能正常執行。儘管我們現在已經發現了一籮筐的問題，但仍不能確保是否會有落網之魚。

●　Bruce Shankle 的缺陷

在 Windows 95 的年代，我還是一個 beta 測試人員。這是我第一次在微軟的平臺上看到回收站。出於好奇，我想嘗試一下它的恢復功能（在 DOS 環境中存在一些恢復功能，但要求您記得 FAT 檔案系統中需要恢復的檔名的第一個字母。有時這個功能很好用，但是我不常用），於是開始拖動桌面上的回收站，然後把它放進了自己的圖示內。就在此時，系統突然奔潰了。

●　Vamshidar Rawal 的缺陷

現象：

Office 線上主頁的 RTW 版本總是會出現有些功能無緣無故失靈的情況。儘管多次除錯，仍不明問題所在。

原因：

RTW 版本釋出前的功能測試階段，測試人員未能發現問題，且測試環境也沒有模擬產品的實際執行環境。所有的功能都被作為單元進行了單元測試，儘管他們每個功能獨立工作都沒有問題，但一起工作時就說不定了。

問題：

問題就出現在實際執行環境中。由於硬體平衡器（H/W）會識別所有的需求，然後將其傳送給伺服器執行，包括我們為每個功能所設定的 Cookie/Header，且平衡器對於 cookie 的尺寸存在限制條件，不能超過 4KB，而當我們所有的功能都同時執行時，則就超出了這一限制。平衡器為了保持正常工作會對 Cookie 進行截斷，使其尺寸小於 4KB。所以就會出現有些功能由於缺少 Cookie 需求而不能正常執行的情況。

結果：

我們立即修復了這一問題，對原先的 Cookie 進行了修改，使其大小不再超標。

經驗總結：

1、測試環境需模擬產品的實際執行環境，特別要注意平衡器的環境要求。

2、功能測試時，不僅要對單個功能進行測試，也要將功能整體連同整個產品一起測試。

這個缺陷的發生，讓我們對於如何編寫和使用 Cookie 有了更深入的瞭解，同時也幫助我們在隨後的兩個版本測試中發現了更多的潛在問題。

● 減小 Cookie 的尺寸可以提高產品的效能，同時提升終端使用者的體驗。

● 削減不必要的 Cookie 內容，使其尺寸控制在合理的範圍內。

●Vamshidar Rawal 的缺陷

現象：

我們將程式碼設定成在特定的跟蹤頁面執行時標，以自動檢測實際終端使用者在站點下載所用的時間（7*24小時）。結果顯示無論是否是高峰時期或週末，下載時間能控制在限時 20 秒之內的機率只有 25%。我們對此束手無策，找不出其中的原因，這對於我們終端使用者的使用體驗無疑是一種打擊。

原因：

我們幾個月後才開始理出頭緒。透過一段時間對網站終端使用者實時使用情況的觀察，竟然發現一個月內會出現兩個特殊時間段，在這兩個時間段內下載時間會由原先的 20 秒下跌至 5 秒。這一現象引起了我的注意，是什麼導致了這兩個特殊時間段的產生？在這兩個時間段內發生了什麼？後來終於得知在這兩個時間段內，我們會進行半個月一次的網站更新，加入新的內容或程式碼。在這期間，我們的操作團隊會佔用一半的伺服器資源，直至更新完成。而就在這個時間段內，長時間的下載問題也得到了解決。我們驚奇地發現在只有半數的伺服器工作的情況下，網站竟然執行得更好。

問題：

◆ 最終，大多數的跡象指向了真正的問題所在：唯一的 OLEDB 連線字串數量，它自建立之初就一直位於前端訪問伺服器上。

◆ 我們有 42 個前端訪問（FE）伺服器對應 28 個後端訪問（BE）伺服器，共包含 47 個語言資料庫（DB）。

◇ 所以每個 FE 伺服器都須建立並一直使用唯一的 DB 連線字串，則唯一的 DB 連線字串的總數量可達 28*47 = 1316 個。

◇ 問題是這個唯一的連線字串的總數量遠遠超過了限定值（約 100 個）。

◆ 在網站更新期間，FE 伺服器對應的 BE 伺服器的數量縮減到原先的一半（21 個 FE 伺服器對應 14 個 BE 伺服器，包含 47 個 DB）。

◇ 這也使唯一的連線字串的數量減少了一半（14*47 = 658 個）。

◇ 同時也提高了網站的效能，將原先 20 秒的延時縮短為 5 秒左右。

結果：

這驅使我們不得不對 FE 和 BE 伺服器進行重新的佈局和連線，以減少連線字串的數量。我們最終決定在 FE 和 BE 伺服器中間新增 6 個伺服器，來解決連線字串超限的問題。

◆ 現在我們有 42 個 FE 伺服器 — 6 個搜尋網路伺服器 — 28 個 BE 伺服器（47 個 DB）。

◆ 每個 FE 上的連線字串數量遞減為 42 * 6 = 252 個。

◆ 下載時間長的問題也徹底得到了解決，無論何時都能達到亞秒級標準。

經驗總結：

網站發生的問題不可能被完全模擬，且幾乎不容易排除。

必須考慮到實際工作環境的每個方面。

如果沒有考慮周全，工作環境的任何部分都可能，且必將影響到網站的效能和終端使用者體驗。

●Xu 的缺陷

自從我筆記本的記憶體由 1GB 提升至 2GB 後執行得一直很好，直到我發現有時會出現 XP 不能響應我的休眠請求，不能關閉的情況。它會一直處於“儲存個人設定”的狀態。有一天我在沒有完全確認它完全關閉的情況下，就把它放入了電腦包。半小時後，當我再次取出它時，它竟然熱得燙手。我開啟它，發現電源仍未用完。所以我猜測它的電源是處於關閉狀態的。慶幸的是，功能未受到影響。但是我又擔心它那麼熱容易被燒壞。儘管我在網上一直搜尋相關資訊，且安裝了一些包試圖想解決之一問題，可是始終不管用。

●Scott Banning 的缺陷

一年半前我發現我們的產品會存在這樣的問題：當使用者使用特定場景處理邊界線時，更新不能同步進行。客戶也反映過類似的問題。但是我們的產品快釋出了，如果要修復這一缺陷，勢必會打破現有的平衡，需要再進行大量的返工，且客戶的反饋也不多，所以我們暫且把它擱置了，標記為未修復。大約一個月後，我再次啟用它，並指出客戶的反饋，但最終還是未修復。至今這個缺陷仍有待解決。這個缺陷一直讓我感到非常沮喪。

● Siderite 的缺陷

我這一缺陷並非來源於我們的程式碼，而是來源於如 Javascript 引擎或 。Net 架構這類承載程式碼的東西。那次我正在測試一個應用程式，該程式引入了一個新的日曆控制器。測試工作耗費了我大量的時間和精力，我非常擔心它是否可以順利執行。只要一想到老闆可能點到一個有問題的鍵，我就寢食難安。

但是問題還是出現了！

有一個特定的時間——夏令時，如能完整地設定這一天的年月日，且將地點設定為我的家鄉——羅馬尼亞，則能正常執行。倘若未設定地點，僅設定年月日，日曆控制器就會顯示為該天的前一天，23 點整。幾經測試都是同樣的結果。我嘗試將預設的 0 時設定為 12 時，之後這一缺陷就再也沒有出現過，我猜測這可能是由於 Windows 某種型別的更新所引起的。

● Alan Myrvold 的缺陷

我碰到缺陷總會很興奮，尤其是那些對我有益的缺陷。

幾年前，我在一個商業軟體公司測試資料探勘軟體。這聽上去不錯，儘管我大學的專業是統計，而非電腦科學，但也總算有點接近。該軟體會從大量的資料來源讀取資料，包括 。CSV 檔案。我發現從某些中等大小的檔案中讀取資料的時間會比預期長。於是我將這個缺陷記錄下來，並計劃進行更多的測試。

Stephan 是開發部的領軍人物，和他共事是我的榮幸。他在軟體設計、編碼方面都很在行，為人也很和善，總能耐心解答他人的問題，受到測試人員的尊敬。他看了看我的缺陷，又看了一下程式碼，堅決表示這個由第三方編寫的程式碼看上去是正確的。當讀取資料時，程式將資料列入一個紅黑色的樹列，從 Stephan 那裡得知這是一種資料結構，用於有效地儲存二進位制樹。當我問到它的工作原理時，Stephan 借了本書給我，是 Cormen et al 的 Introduction to Algorithms（演算法入門）影印本。

程式依舊執行得不順暢。於是我對這些檔案按正序、隨機以及倒序的順序分別進行了效能測試，發現同樣的檔案按不同的順序進行測試的結果竟然大相徑庭。於是我開始對讀取的資料進行除錯，因為我不能接觸到原始碼，所以只能逐個分解並跟蹤資料流。我在紙上仔細地畫出了讀取資料時所構建的樹結構圖，並注意到它正好與紅黑色樹的需求相沖突，儘管原始碼看上去是沒有問題的。我編制了一份正確的演算法實現，待 Stephan 仔細審閱後終於得到認可。

經驗總結：

◆ 手動測試時，旁人的觀點很有可能幫助您發現原先被忽略的缺陷。

◆ 在沒有原始碼的情況下也能進行除錯，儘管會比較困難。

◆ 看上去正確的程式碼也可能是錯誤的。

◆ 電腦科學的知識可以幫助測試人員。

● Eric Sink 的缺陷

我曾碰到過這樣一種產品，它能使其他應用程式崩潰。

開始，我們覺得這是難以置信的。人們紛紛打電話到我們的服務中心，抱怨使用我們的產品導致了其它程式的崩潰。但是這種崩潰又是不可重現的，而且這整件事情聽起來也有點荒謬。如果正巧其他的應用程式崩潰的時候，而我們的產品正在執行，這因果關係又如何能判斷呢？

但最終證實這是千真萬確的。當我們的一個對話方塊操作失敗時，有時候確實會引發其他應用程式的奔潰。

加我VX：ww-51testing   回覆關鍵詞“測試”領取限量軟體測試學習資料哦~~