軟件功能性測試21個故障模型(15-21)

 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錯誤。

Ø        測試知識儲備:全面掌握被測軟件的需求,瞭解文件讀寫需要的權限。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章