登入  |  English
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 原網站預計持續維運至 2021年底,網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
新聞

臭蟲不一定隨機出現

◎本文翻譯自 Dr. Dobb's bloggers,原作者為 Andrew Koenig:
https://www.drdobbs.com/cpp/not-all-bugs-are-random/240165035

上星期我開始討論起白箱測試 (white-box testing),由於有時候從外面很難一眼看出軟體是如何出錯的,因此這個方法有其重要性。

白箱測試之所以重要還有另一個理由:透過觀察程式的結構,我們有時能預測出可能發生錯誤的情況。只看程式的外部行為也許不能發現這些情況。也就是說,我們可能忽略了檢查程式在這些特定情況下的行為是否正確。

當然,這種狀況有某些容易預測。舉例來說,假如有個程式處理 n 個項目的集合,兩種顯而易見要測試的狀況就是 n = 0 與 n = 1。不過,其他類似狀況也許需要檢查程式內部。像是,只要程式依據程式輸入的某些面向,例如大小,來決定使用一種或多種演算法時,我們都應該確認這支程式在接近決策邊界雙邊時能順利運作。我看過相當多程式會對輸入資料行大小或姓名長度,設定長度的限制。在遇上與限制等長,或長度比限制多(或少)一個單位的輸入時,有太多這類程式就會出錯。如果你藉由查看程式碼了解有哪些限制,會讓測試接近這些限制的案例簡單許多。

當程式偵測到發生問題並嘗試重複其作業時,是另一種可以加以預測的錯誤。例如說,如果發生的是永久性的故障時,該怎麼辦?程式會無限制重試下去嗎?我記得在到處都有網路的時代之前,有一支程式,會透過電話線把資料傳給另一台電腦。如果接收端的電腦回報錯誤,發送端電腦會結束連線,等一下,然後再次嘗試傳送資料。

這套方式看來有效且穩固,足以應對傳輸錯誤。不過,程式作者不知道的是,為了節省資源,之後釋出的作業系統會對檔案大小設加上限。這個限制是可以設定的,不過其預設值太小,所以許多情況下用戶傳送的檔案會大於此預設值。如果發送端的檔案大於接收端的檔案大小限制,當檔案內容超過限制時,接收程式就會出錯,並以為發生 I/O 錯誤,然後回報給發送電腦。接著,發送端會關閉連線,等待,然後重試。接收端會建立暫存檔案收下這些資料,然後整件事會不斷重演。

換句話說,增加限制檔案長度的作業系統功能,反而耗用更多資源。嘗試把一個檔案傳送到有小檔案大小限制的電腦,會造成傳送失敗的無限迴圈,阻礙兩台機器間的進一步通訊,同時緩慢地接收端的磁碟空間。

雖然這些問題很嚴重,之所以進行白箱測試還有一個更為重要的理由:安全性。安全性臭蟲比起效能臭蟲,更難以在測試中發現的原因是,事先假設安全性臭蟲會被惡意利用。許多安全性臭蟲事實上是沒能正確實作“不論該程式輸入為何,都不應該做某件事”這種形式的需求。黑箱測試 (Black-box testing) 一般只能驗證程式會做什麼,而不是程式不會做什麼。不過,經由適當結合白箱測試與插碼測試 (instrumentation),我們可以更有自信地宣稱,至少沒有某些特定類型的安全臭蟲存在。




自由軟體鑄造場電子報 : 第 237 期 Gnome、KDE 與 Cinnamon 的平鋪視窗控制

分類: 自由專欄