[轉載]軟體功能性測試21個故障模型

標籤：

非本人原創，從51Testing軟體測試網載入，再次感謝原創

 

測試的目標是要發現錯誤，因此在編寫測試案例的時候也要遵循這個目標，盡量在軟體的最薄弱環節多編寫測試案例。雖然測試時有很多單個輸入變數、多個輸入變數的組合，但優秀的軟體測試人員不會依靠運氣，他們有著豐富的經驗和直覺，可以從中找到哪些是需要進行測試的，哪些不需要測試，哪些操作可能會引起軟體失效。把這些測試人員的經驗和直覺盡量歸納和固化，就形成了一些故障模型。故障模型指明了故障是如何以及為什麼會在軟體執行時引起軟體失效。在測試過程中，我們可以按照這些故障模型所提供的缺陷類型和尋找該類缺陷的方法找到盡量多的缺陷。

1、輸入非法資料

1.1 缺陷產生原因

開發人員通常用以下3種技術來處理非法輸入：

◆ 防止不正確的輸入進入被測軟體。過濾掉不正確的輸入，只允許合法輸入通過介面。

◆ 輸入了不正確的資料後，軟體提示錯誤資訊，拒絕不正確的輸入。

◆ 允許不正確的輸入進入系統並進行處理，軟體失效時調用例外處理常式，顯示一些錯誤資訊。

可見開發人員除了編寫主要的功能代碼外，還必須編寫對非法輸入的檢查代碼，這些代碼經常被遺忘，或者編寫完這部分代碼後，開發人員很少認真檢查，導致處理非法輸入經常出錯。

1.2 如何發現這類問題

進行測試時從輸入值的屬性出發，一般考慮以下三點：

◆ 輸入類型：鍵入無效的類型常會產生錯誤資訊。

◆ 輸入長度：對於字元型，鍵入太多的字元常會引出錯誤資訊。

◆ 邊界值：輸入邊界值或超過邊界值的資料。

1.3 測試方法小結

◆ 應用場合：GUI的輸入。

◆ 測試方法：分別從輸入資料的類型、長度、邊界值等方面進行考慮。

◆ 測試資訊檢查：

● 錯誤資訊和錯誤要一致。

● 錯誤資訊的內容為空白，使用者不知道為什麼出錯。

● 顯示的錯誤資訊是給開發人員調試使用的，例如“Error 5-unknown data”，開發人員可以通過該資訊很容易找到錯誤類型，但是使用者根本不明白，不知道做錯了什麼。

◆ 測試知識儲備：牢記各基礎資料型別 (Elementary Data Type)的邊界值。

2、輸入預設值

2.1 缺陷產生原因

一旦軟體中使用了變數，就必須賦給初始值，如果在賦值之前就使用了這些變數，軟體就會失效，正確地使用變數的順序是：聲明變數à給變數賦值à使用變數。通常會由於以下兩個原因使變數的預設值不正確：

◆ 給變數賦值這一步經常會被開發人員不經意地路過。

◆ 開發人員有時不確定到底要賦什麼初始值，就隨便給了一個值，但使用者並不認可該值，這種情況下，軟體並不一定會失效，但對使用者的使用會帶來很多不便。例如某程式把列印預設輸出份數設定為2份，會給使用者造成很大麻煩。

2.2 如何發現這類問題

確定應用軟體中所使用的資料有以下一些基本原則：

◆ 尋找選項按鈕、配置面板、安裝螢幕等。這種螢幕上顯示的資料常常在應用程式的許多地方用到。

◆ 查閱原始碼的資料聲明部分（如果可以得到）。

◆ 確定了要測試的資料，可以通過以下操作來強制使用或不使用預設的值：

● 接受軟體顯示的預設值。有時軟體需要使用者輸入一個值，如果沒有輸入任何值，軟體就可能失效。這時可以只是簡單的單擊“確定”按鈕來接受預設值，完成這個功能測試。

● 鍵入空值。刪掉預設值，使輸入欄位變成空值。

● 將預設值改為另一個值，這樣會使應用程式以不同的值來運行。

● 將輸入值改為另一個值，然後再變以空值。

一個好的軟體會這樣處理以上情況，將輸入的不合法內容預設為合法邊界內的某個合理值，或者返回錯誤提示資訊。

2.3 測試方法小結

◆ 應用場合：需要有預設值的地方。

◆ 測試方法：分別從選項按鈕、配置面板、安裝配置、開始介面等方面進行考慮，強制使用或不使用預設值等。

◆ 測試知識儲備：全面理解需求規格說明書中對預設值的要求；同時深刻理解被測軟體的行業背景。

3、輸入特殊字元集

3.1 缺陷產生原因

應用程式接受字串輸入，如果程式沒有針對特殊輸入進行特殊編程，那麼就有可能導致程式

掛起，主要包括以下3種情況：

◆ 字元集包括一般字元和特殊字元。例如，ASCII字元集包括一般字元和特殊字元。應用程式有時只能處理一般字元，當輸入特殊字元時就會出現錯誤。

◆ 實現應用程式的程式設計語言有特定的處理一些字元和字串的方法。例如，C語言把\n、++和&這樣的字元用於特殊目的。如果將這些字串鍵入到對話方塊中，程式必須進行錯誤處理，否則容易產生錯誤。

◆ 應用程式有時也使用設定名稱、系統對象和程式的保留字元串集合。只要在程式中使用了這些字串，就可能導致失效。

3.2 如何發現這類問題

◆ 根據被測軟體所處的作業系統、使用的程式設計語言、字元集等資訊列出表格，通過測試小組的討論，標明應用表格中的哪些字元和資料類型作為輸入來測試。

◆ 根據經驗，軟體很少會因為這種操作而崩潰，通常它會掛起沒有響應。

3.3 測試方法小結

◆ 應用場合：需要接受字元輸入的地方。

◆ 測試方法：根據被測軟體的具體情況輸入非法字元。

◆ 測試知識儲備：儘可能多地了多地瞭解字元集、程式設計語言和作業系統中的保留字元串及其特定含義，可以使我們更好地分辨這類缺陷。

4、輸入使緩衝區溢位的資料

4.1 缺陷產生原因

開發人員沒有考慮傳送給記憶體緩衝區的字串的大小。如果緩衝區只能保留固定長度的字串，輸入更長的字串就會改寫其他的記憶體儲存單元，引起作業系統強制性地終止應用程式。

4.2 如何發現這類問題

當應用程式允許輸入字母、數字時，通過GUI控制項（如文字框），或者通過API調用的參數來進行這種測試。

◆ 首先弄清楚要測試的輸入欄位的長度，輸入最大字串測試。

◆ 輸入一個比最大字串長的字串，應用程式可能出現錯誤提示資訊，提示不允許輸入；或者輸入了更長的字串使應用程式崩潰。

4.3 測試方法小結

◆ 應用場合：需要接受字元輸入的地方。

◆ 測試方法：根據被測軟體的具體情況輸入最大字串或輸入一個比最大字串更長的字串。

◆ 測試知識儲備：儘可能多地和開發人員討論，以瞭解和確定輸入欄位的合理長度。

5、輸入產生錯誤的合法資料群組合

5.1 缺陷產生原因

測試多個輸入值的組合，每個輸入值已被單獨測試過，但是這些值的組合可能會互相影響而引起軟體失效。

5.2 如何發現這類問題

首先要確定測試哪些輸入組合，並弄清楚它們之間的“關係”。如果具備以下任一特性，就可以認為這些變數是有“關係”的。

◆ 描述的是有關單個內部資料結構的屬性和內容。例如，輸入面板需要使用者輸入列表的“行”和“列”，這時測試人員要輸入單個內部資料結構“列表”的屬性“行和列”。

◆ 一起用在了一個計算中，也就是將多個輸入用做一個內部計算的運算元，因此這些輸入變數具有了相互“關係”。

5.3 測試方法小結

◆ 應用場合：輸入值之間存在依賴關係。

◆ 測試方法：輸入可能是存在問題的組合值。

◆ 測試知識儲備：儘可能多的內部資料結構的屬性和內容，並與開發人員探討，以確定輸入的資料值。

6、產生同一個輸入的各種可能輸出

6.1 缺陷產生原因

單個輸入產生多種輸出的情況與先前的輸入和被測系統的狀態都有關係。例如，在文文書處理程式中單擊“關閉”按鈕，如果檔案被編輯且未被儲存，程式將提示是否儲存檔案。如果檔案已被儲存過，則檔案直接關閉。

6.2 如何發現這類問題

測試人員必須具有關於被測系統軟體的業務方面的知識，具備各種程式文檔，明確一個輸入可以產生何種輸出。我們可以據此列出關於程式輸入與輸出的一個列表，然後進行測試。

6.3 測試方法小結

◆ 應用場合：同一輸入對應多個輸出的情況。

◆ 測試方法：測試輸入對應的每一個輸出。

◆ 測試知識儲備：全面理解需求規格說明書中的內容，找出輸入與輸出之間的關係。

7、輸出不符合商務規則的無效輸出

7.1 缺陷產生原因

有時開發人員也可能對業務瞭解不深刻，對有些問題也是一知半解，因此編寫出的軟體就會產生不符合商務邏輯的問題。另外在絕大多數情況下開發人員會忽略處理沒有遵循一般規則的輸入，如果不對這些特殊情況進行編程處理，軟體就會產生錯誤的結果。

7.2 如何發現這類問題

◆ 測試人員應該儘可能地學習的涉及問題的領域。

◆ 有時在列舉出無效輸出後，也很難知道哪些輸入組合能強制這些輸出產生。這時測試人員必須先要確定哪些輸入與輸出有關，然後用產生意外結果的輸入組合進行測試，測試過程中要注意輸入執行順序，用不同的順序執行可能得到不同的結果。如果不能強制無效的輸出產生，就說明軟體沒有這方面的缺陷。

7.3 測試方法小結

◆ 應用場合：強制產生不符合業務背景的知識。

◆ 測試方法：列舉出所有的無效輸出，然後逐一測試。

◆ 測試知識儲備：全面理解需求規格說明書中的內容，熟悉行業背景知識。

8、輸出屬性修改後的結果

8.1 缺陷產生原因

輸出常常具有可修改的屬性，如顏色、形狀、維數及大小等，使用者可以修改這些屬性。在這種情況下，開發人員必須編碼、設立初始或預設屬性值，然後編碼允許使用者編輯這些屬性。當使用者改變了這些屬性後，內部的相應變數值也隨著變化，再次進行處理時，這些值沒有被重新恢複為預設值，輸出的屬性就被強制改變了。

8.2 如何發現這類問題

該測試方法可以使用在那些輸出具有可編輯性、可修改性的功能中。測試人員首先要仔細瞭解能夠產生的輸出，特別要注意具有可編輯屬性的輸出。測試人員的任務就是強制每個輸出產生，並編輯其屬性，然後再次強制輸出產生。

8.3 測試方法小結

◆ 應用場合：輸出的結果，可以由使用者修改屬性得出。

◆ 測試方法：強制每個輸出產生，並編輯其屬性，然後再次強制產生輸出。

◆ 測試知識儲備：全面理解需求規格說明書中的內容，瞭解能夠產生的輸出。

9、螢幕重新整理顯示

9.1 缺陷產生原因

通常GUI軟體會產生重新整理問題，因為GUI在對視窗進行覆蓋、移動和調整大小時，必須重新整理螢幕才能使對象重新顯示。但是如果經常重新整理，容易減慢應用程式的運行速度；如果不重新整理，又會影響使用者對程式的使用，使使用者必須停止工作，去尋找重新整理的方法才可以繼續工作。所以開發人員有時候不能很好地確定什麼時候需要重新整理，需要重新整理多大範圍的地區，這就發生了令人煩惱的重新整理問題。

9.2 如何發現這類問題

測試重新整理問題的方法是增加、刪除稱移動螢幕上的對象，這樣會使某些對象重新顯示。如果不能正確、及時地進行重新顯示，就產生了軟體缺陷。我們可以通過以下幾個方法來檢查重新整理：

◆ 從起始位置移動對象。先移動一點，然後增加移動幅度；先移動一次或兩次，然後多次移動，確保覆蓋了所有地區。

◆ 從覆蓋對象的邊界開始一點點覆蓋，使其中一個對象遮住別一個對象。

◆ 使用不同類型的對象。如果應用程式支援多種類型的對象，如文字物件、繪圖物件等，就把這些不同對象混在一起使用。

9.3 測試方法小結

◆ 應用場合：一個對象包含在另一個對象中，拖動被包含對象時，可能出現重新整理問題。

◆ 測試方法：增加、刪除和移動螢幕上的對象。

◆ 測試知識儲備：全面理解需求規格說明書中的內容，瞭解程式中對象之間的關係。

10、資料結構溢出

10.1 缺陷產生原因

所有資料結構的大小都有上限。一些資料結構會逐步增加長度以充滿機器記憶體容量或磁碟空間，而其它資料結構具有固定的上限。開發人員經常對有關資料結構的內容進行編碼，忘記結構本身的物理局限。

10.2 如何發現這類問題

◆ 確定資料結構的界限，嘗試將過多的值輸入資料結構。應該特別注意界限為資料類型的邊界256、1024、32768等上溢的測試。

◆ 對於下溢的測試，可以嘗試多刪除一個資料，例如當結構為空白時，嘗試再刪除，或者添加一個資料，嘗試刪除兩個資料時的情況。

10.3 測試方法小結

◆ 應用場合：程式中存在數組。

◆ 測試方法：嘗試將過多的值輸入資料結構，測試上溢；對於下溢的測試，可以嘗試多刪除一個資料。

◆ 測試知識準備：全面理解需求規格說明書中的內容，確定資料結構的界限。

11、資料結構不符合約束

11.1 缺陷產生原因

在編程過程中對內部資料結構都有所約束，包括大小、維數、類型、形狀、螢幕上的位置等。我們測試的重點就是使用者能夠設定的屬性，這些屬性使用了一組參數來約束。在建立資料項目和隨後對資料項目進行修改的任何時刻都要對資料屬性的約束進行檢查。初始化代碼中修改後的代碼有錯誤，在修改錯誤的時候只修改了初始化部分，而忽略了對其他部分的修改，使得其修改不完全，不徹底。

11.2 如何發現這類問題

◆ 確認候選資料，並列出其可修改的屬性。對每個屬性列出有效值的允許範圍、約束的條件等。

◆ 確定所有可修改屬性的功能位置。

◆ 對資料進行初始化，改變每個屬性以確定是否正確進行了約束。

如果資料約束遭到破壞，可能導致系統崩潰，或者表現為回應時間延遲，錯誤資訊不正確以及使用錯誤資料產生的無效輸出。

11.3 測試方法小結

◆ 應用場合：應用程式內部的資料結構存在約束。

◆ 測試方法：破壞內部資料結構的約束。

◆ 測試知識儲備：全面理解需求規格說明書中的內容，確定內部資料結構的所有約束。

12、運算元與操作符不符

12.1 缺陷產生原因

幾乎每個運算子都有它無效的運算元，對於具體的操作符，開發人員在使用它們時，必須編寫錯誤檢查代碼。例如：除以零的問題。

12.2 如何發現這類問題

找到程式中包含的資料或輸入（即運算元）的計算（即操作符）、數學運算式（即操作符和運算元的組合）及對圖形的操作。另外，對多個運算元進行組合也更容易發生錯誤。例如，字元和數字都可以使用“+”操作符。對字元通過“+”把它們連成一串；對數字通過“+”來進行加法運算。如果系統嘗試把字元和數字相加，即進行相互矛盾的操作，就會引起軟體失效。

12.3 測試方法小結

◆ 應用場合：需要進行數值計算的程式或圖形操作的程式。

◆ 測試方法：對於數值計算考慮運算元和操作符之間的限定關係，對於圖形計算還要考慮各種輸入資料之間的組合關係。

◆ 測試知識儲備：全面掌握被測軟體中操作符對運算元的要求。掌握不同的操作符和運算元具有的不同的有效和無效的取值範圍。

13、遞迴調用自身

13.1 缺陷產生原因

函數有時會遞迴調用自身，如果不限制執行次數，遞迴就會出現問題，它不斷地調用自身，很快地佔用機器資源，最終產生溢出，使程式崩潰或掛起。產生這類問題的主要原因是開發人員沒有編碼來保證迴圈和遞迴調用的終止，通常是在迴圈的開始或結束時缺少檢查條件。

13.2 如何發現問題

在軟體中尋找可以使用遞迴調用的功能。這時可以製作一個列表，標明軟體中可能嵌入遞迴的功能的列表，然後自己引用自己來檢查程式是否能正確處理。

13.3 測試方法小結

◆ 應用場合：需要和其它對象進行互動的地方。

◆ 測試方法：考慮對象的自我互動或複製。

◆ 測試知識儲備：全面掌握被測軟體的需求。

14、計算結果溢出

14.1 缺陷產生原因

當所有的輸入和資料都有效時，計算的最終結果也可以是無效的。所有變數都有範圍範圍，有時開發人員在執行計算時會忘記檢查這些上限。

14.2 如何發現這類問題

一次又一次地執行計算或使用很大或很小的輸入和資料進行計算，重點測試資料類型的初始值或邊界值附近的值。

14.3 測試方法小結

◆ 應用場合：應用程式執行能夠匯出待產生結果並進行內部儲存的計算。

◆ 測試方法：強制資料產生上溢或下溢。

◆ 測試知識儲備：全面掌握被測軟體的需求，瞭解計算變數的上下限。

15、資料共用或關聯功能計算錯誤

15.1 缺陷產生原因

通常對孤立的功能進行測試時不會發生很多缺陷，而當把單獨的功能和同一軟體中的其它功能結合時，就可能出現很多軟體缺陷。這種缺陷的產生往往是在兩個或更多的功能使用了共用資料集，而每個功能允許使用的資料範圍不同引起的。例如，一個功能可能會將某資料項目設定為特定大小，然而另一個功能卻允許該資料項目的大小可以超過第一個功能的處理能力。開發人員根本沒考慮到該資料項目在其它功能處也可以修改，他們只是編碼保證在該功能中資料的合法性，而當使用該資料時，沒有再編碼來檢查可以使用的範圍；而此時，另一個功能修改了共用資料，當再使用這些資料時就產生了缺陷。

15.2 如何發現這類問題

當應用程式在同一時間完成一個以上的功能或當一個以上的功能在同一時間處於運行狀態時，就可以使用該方法進行測試。利用一個功能影響輸入、輸入資料或另一個功能的計算。在測試前要確定哪些功能是相互依賴或共用資料的：

◆ 能應用同樣輸入的每個功能。如果這些功能有相互重疊的輸入欄位，就可能存在互動問題。

◆ 有類似的輸出產生功能。如果某些功能結合起來產生單個輸出，就說明這些組件之間存在關係，應該被一起測試。

◆ 一個功能被包含在另一個功能的計算中。例如要測試滑鼠選取對象的功能，不僅要測度滑鼠選取螢幕上的文本的功能，還可以把包含超連結文本、粗體、斜體、符號及圖形元素放在一起，測試滑鼠選取這些元素的功能。

15.3 測試方法小結

◆ 應用場合：一個以上的功能在同一時間處於運行狀態。

◆ 測試方法：以點代面，重點測試某一功能，對可能與這個功能相連的其它功能附帶測試。

◆ 測試知識儲備：全面掌握被測軟體的需求，在測試之前對被測功能之間的依賴關聯有所掌握，另外還需要對共用資料有所掌握。

16、檔案系統超載

16.1 缺陷產生原因

開發人員可能會忘記編寫代碼處理滿狀態的檔案系統，忽略了諸如CreateFile，WriteFile等作業系統API的錯誤檢查代碼，沒有這樣的代碼，當顯示滿狀態的檔案系統時，API調用就會失敗，軟體就會在沒有任何警告的情況下崩潰。

16.2 如何發現這類問題

建立滿容量或近乎滿容量的檔案系統，然後強制執行各種通過輸入或輸出訪問檔案系統的操作；或者開啟足夠多的檔案，開啟檔案時會強製備份建立的副本，從而佔用雙倍的儲存空間，這種操作達到一定程度時，會達到該系統的容量，於是就能測試應用程式處理超載狀態的檔案系統的能力。（通常通過磁碟配額實現）

16.3 測試方法小結

◆ 應用場合：系統較大，運行時需要較大的空間。

◆ 測試方法：強制磁碟系統滿容量或容量小於等於被測軟體運行時所需容量後，運行被測軟體或利用測試載入器類比磁碟狀況。

◆ 測試知識儲備：全面掌握被測軟體的需求，瞭解被測軟體處理超載狀態的檔案系統的能力。

17、介質忙或不可用

17.1 缺陷產生原因

當多個應用程式同時訪問硬碟（或其它儲存空間），作業系統為提供多請求服務會慢下來，並且必須對應用程式進行編程以處理這些延遲，當延遲變得很長時，沒有對這些錯誤進行響應的應用程式就會出現錯誤。

17.2 如何發現這類問題

通過啟動大量應用程式，強制它們都開啟並儲存檔案使檔案系統處理繁忙狀態；或者同時下載大量檔案也可以使後台擁擠；檢查被測軟體能否正確處理這種情況，應用程式應該給出錯誤資訊或等待批示，提示使用者正在處理。

17．3測試方法小結

◆ 應用場合：應用程式的運行需要消耗大量記憶體或運行時需要其它相關軟體同時運行。

◆ 測試方法：啟動大配量序或利用測試載入器類比磁碟狀況。

◆ 測試知識儲備：全面掌握被測軟體的需求，瞭解被測軟體運行時對系統的要求。

18、介質損壞

18.1 缺陷產生原因

◆ 損壞的介質可能會使作業系統傳回錯誤碼，這些錯誤碼沒有在應用程式中編程處理。

◆ 作業系統不能檢測出所有這樣的錯誤，作業系統自己也有錯誤或者損壞的介質損壞了部分作業系統。

18.2 如何發現這類問題

使用損壞了的介質，例如，刮傷、灰塵、磁幹擾等。檢查應用程式對錯誤的處理能力，應用程式可以對錯誤進行處理或者將問題告訴使用者，並要確保使用者資料檔案不丟失、為損壞。

18.3 測試方法小結

◆ 應用場合：應用程式對安全的要求較高，對災難恢複的要求較高。

◆ 測試方法：用實際損壞介質的方法測試應用程式。

◆ 測試知識儲備：全面掌握被測軟體的需求，瞭解被測軟體運行時對系統的要求。

19、檔案名稱不合法

19.1 缺陷產生原因

作業系統本身具有自己的檔案命名規範，例如，Dos的8.3格式。在Windows中，檔案名稱不能超過255個字元，並且檔案名稱不可以含有/ \ : < > ? * |這8個字元，以及AUX、COM1、COM2、COM3、COM4、CON、LPT1、LPT2、LPT3、LPT4、NUL及PRN這些作業系統保留字。

開發人員在應用程式中使用不相同的規則管理檔案名稱，當應用程式和作業系統使用的檔案名稱命名規則不一致的時候，就會發生問題。

19.2 如何發現這類問題

◆ 儲存檔案為作業系統不允許的檔案名稱，例如，檔案名稱中含有/ \ : < > ? * |這8個字元，測試應用程式是否不允許輸入包含這些字元的檔案名稱。

◆ 輸入一些應用程式不允許使用的檔案名稱，例如，使用過長的、含有特殊字元的、可能相互作用的字元作為檔案名稱，檢查應用程式能否識別該檔案。

19.3 測試方法小結

◆ 應用場合：幾乎所有涉及需要輸入檔案名稱功能的應用程式。

◆ 測試方法：輸入作業系統不允許的檔案名稱和應用程式不允許使用的檔案名稱。

◆ 測試知識儲備：全面掌握被測軟體的需求，瞭解作業系統和應用程式對檔案名稱的要求。

20、變更檔存取權限

20.1 缺陷產生原因

在作業系統中，可以設定不同使用者對不同的檔案具有不同的存取權限（如讀寫、唯讀等）。程式員必須在訪問檔案的函數中考慮檔案的存取權限，例如在每個檔案寫入之前檢查檔案的存取權限。如果沒有進行檢查，就會導致程式出錯。另外，如果檔案訪問失敗，程式員必須要有正確的錯誤的代碼，以保證程式可以正確捕獲所產生的錯誤。

20.2 如何發現這類問題

◆ 開啟兩個應用程式，關閉同一個檔案。例如，把同一個應用程式的不同版本安裝在同一機器上，在不同版本的應用程式中開啟和關閉同一檔案，或試著在某個應用程式中開啟在另一個程式中已開啟的檔案，這可能導致檔案存取權限的衝突。

◆ 開啟一個檔案，在作業系統中修改檔案的存取權限。有些作業系統允許許可權高的使用者控制一般使用者已經開啟的檔案。

20.3 測試方法小結

◆ 應用場合：需要對檔案進行讀寫操作的應用程式。

◆ 測試方法：修改檔案存取權限或使用低許可權的使用者訪問檔案。

◆ 測試知識儲備：全面掌握被測軟體的需求，瞭解讀寫檔案所需的許可權。

21、檔案內容受損

21.1 缺陷產生原因

開發人員編寫代碼來讀取和寫入檔案，他們也編寫代碼來調用系統API得到檔案指標，並開啟和關閉檔案。由於某些原因，這些系統API會失敗或傳回異常傳回值。如果開發人員沒有編寫代碼來驗證傳回的預期傳回值，則應用程式會由於無法處理異常而失敗。

21.2 如何發現這類問題

◆ 手工損壞檔案。從應用程式已建立的某個完整檔案開始對其進行編輯，改變檔案格式和內容。

◆ 使用測試載入器。類比CRC（迴圈冗餘校正）錯誤，或強制檔案API返回無效的返回碼。

21.3 測試方法小結

◆ 應用場合：需要對檔案格式和內容進行校正的應用程式。

◆ 測試方法：手工損壞檔案或利用測試載入器類比CRC錯誤。

◆ 測試知識儲備：全面掌握被測軟體的需求，瞭解檔案讀寫需要的許可權。

[轉載]軟體功能性測試21個故障模型