建站
咨詢
售后
建站咨詢
新聞中心
故障模型是將測試人員的經驗和直覺盡量歸納和固化，使得可以重復使用。測試人員通過理解軟件在做什么，來猜測可能出錯的地方，并應用故障模型有目的地使它暴露缺陷。下面介紹功能測試中故障模型的建立。
創(chuàng)新互聯(lián)是一家集成都網站建設、做網站、網站頁面設計、網站優(yōu)化SEO優(yōu)化為一體的專業(yè)網站設計公司，已為成都等多地近百家企業(yè)提供網站建設服務。追求良好的瀏覽體驗,以探求精品塑造與理念升華,設計最適合用戶的網站頁面。 合作只是第一步，服務才是根本,我們始終堅持講誠信，負責任的原則，為您進行細心、貼心、認真的服務,與眾多客戶在蓬勃發(fā)展的市場環(huán)境中,互促共生。
1. 概述
故障模型是軟件測試的基礎，也是一個判斷測試方法是否成熟的重要標志。在測試的過程中，要確保每一個目標狀態(tài)都被測試，那么測試必須是系統(tǒng)的；為了最終定位軟件缺陷，所以測試必須是集中的；測試需要使用大量的測試用例和重復性測試，因此測試必須是自動的。若要滿足上述三個測試條件，我們必須建立故障模型。
故障模型是將測試人員的經驗和直覺盡量歸納和固化，使得可以重復使用。測試人員通過理解軟件在做什么，來猜測可能出錯的地方，并應用故障模型有目的地使它暴露缺陷。它具有一定的形式和足夠的信息對錯誤進行預測，因此對測試人員來說，構造一個準確的故障模型，是選擇測試策略、設計測試用例和測試執(zhí)行的基礎。在建立故障模型時，希望故障模型在框架上是通用的，但是建立具體的故障模型時一定要針對具體的軟件類型、應用環(huán)境、甚至開發(fā)工具才有意義。一個成熟的故障模型必須具備下列條件：
1）該模型是符合實際的：大多數系統(tǒng)中存在的故障都可以用該模型來表示；
2）模型下的故障個數是可容忍的：模型下的故障個數一般和系統(tǒng)的規(guī)模是成線性關系；
3）模型下的故障是可以測試的：存在一個算法，利用該算法可以檢測模型中的每一個故障。
本文將從軟件的功能和技術特點出發(fā)，如軟件的輸入、輸出、數據以及處理等，分析在軟件功能測試過程中，我們通常應建立的故障模型及按照故障模型所提供的缺陷類型尋找盡量多的缺陷。
2. 輸入型故障模型
主要是對用戶的各種輸入進行建模，因為用戶的輸入是無法預期的，可能的組合狀態(tài)也是千變萬化。軟件功能除了能讓正確的輸入得到正確的輸出之外，還必須對非法和不合邏輯的輸入進行處理，防止因數據異常造成不可挽回的錯誤。典型的建模方法有：
1）使用非法數據：從輸入數據的類型、長度、邊界值等方面考慮，測試軟件是否允許不正確的輸入進入系統(tǒng)并進行處理，是否有錯誤處理代碼，代碼是否正確。
2）使用默認值輸入：檢測軟件中所使用的變量是否初始化，是否將非法數據默認為合法邊界內的某個合理值。
3）使用特殊字：檢測軟件是否正確處理了特殊字符和數據類型。
4）使用使緩沖區(qū)溢出的合法輸入：輸入超過允許的最大長度的數據，檢測軟件是否檢查字符串/緩沖區(qū)的邊界。
5）使用可能產生錯誤的合法輸入組合：測試多個輸入值的組合，確認這些值的組合是否會互相影響而引起軟件失效。
6）重復輸入相同的合法輸入序列：檢測軟件是否考慮了循環(huán)處理的邊界。
3. 輸出型故障模型
軟件的輸出通常是最直觀也是用戶最關注的，輸出型故障模型就是從軟件輸出角度出發(fā)，分析造成故障的可能原因。例如通過一個正確的輸入在不同情況下產生不同輸出的情況可以對輸入和輸出的關系進行進一步驗證；可采用列舉等方法，強制軟件產生不符合業(yè)務背景知識的無效的輸出，從而進行處理，規(guī)避不必要的錯誤；強制修改輸出的屬性、查看輸出結果，測試初始化代碼和修改代碼是否同步；檢查用戶界面刷新情況，在不同的操作下測試界面刷新時間是否正確、界面刷新區(qū)域計算是否正確。
在大多數的軟件中，功能輸出的正確與否直接決定了軟件實現(xiàn)的好壞，輸出型故障模型所覆蓋的故障也占有相當大的比例。因此，我們在測試過程中應建立這種故障模型，從故障結果進行分析，判斷造成故障的影響因素。
4. 計算型故障模型
對于部分軟件程序，常需要進行大量的計算，因此該模型應該盡可能包括關于計算方面的各種錯誤。包括變量的定義與使用方面的錯誤；數據的冗余；數組變量的越界錯誤；數據類型不匹配的錯誤；還有數據操作方面錯誤，包括函數調用參數傳遞錯誤、賦值語句錯誤等。
在建立計算型故障模型的時候，要定義數據并且對這些數據執(zhí)行各種故障操作，盡可能使模型比較完善。體現(xiàn)在功能層面上，可以使用非法的操作數和操作符組合來驗證計算要求的合法性、強制使計算結果溢出考慮數據結構存儲的正確性、同時對數據進行操作檢測數據共享性等方法來建立故障模型。
5. 流程型故障模型
這是一種程序控制流的故障模型，是對在程序中同樣占很大比例的循環(huán)結構和分支結構建立的模型。循環(huán)故障主要包括永不循環(huán)故障和死循環(huán)故障，這主要是由循環(huán)條件錯誤引起的。循環(huán)條件的錯誤中包括變量錯誤和運算符錯誤，在未執(zhí)行循環(huán)之前，循環(huán)變量的初值設置出錯以致永不循環(huán)；進入循環(huán)以后，循環(huán)變量的值不作修改以致發(fā)生死循環(huán)。
而分支故障則包括判定條件故障和謂詞結構故障，由于判定條件的出錯或者變量初值設置錯誤而導致不執(zhí)行分支結構；對于進入了分支結構的執(zhí)行，可能因為謂詞的錯誤而提前退出分支結構。
由此可知，流程型故障模型很可能是由一串連續(xù)的故障所組成的。因此在軟件功能測試中，我們可以通過判斷軟件流程是否正確執(zhí)行、功能分支是否覆蓋全面、循環(huán)操作是否正常結束等方法來檢測軟件流程的正確性。
6. 資源型故障模型
資源型故障模型是在文件系統(tǒng)超載、系統(tǒng)介質忙或不可用、介質損壞等情況下，運行被測程序進行測試。此類故障模型的建立通常需要輔助測試工具進行環(huán)境的模擬。當磁盤負荷到達一定程度或可用物理資源十分有限時，系統(tǒng)進程十分容易進入“死鎖”狀態(tài)或出現(xiàn)不可恢復的錯誤。產生死鎖的根本原因在于系統(tǒng)提供的資源個數少于并發(fā)進程所要求的該類資源數。顯然，由于資源有限，不可能為所有要求資源的進程無限制地提供資源。
但是，可以采用適當的方法，以達到消除或規(guī)避“死鎖”的目的。因此判斷軟件在何種操作下會導致“死鎖”以及軟件對介質損壞的糾錯能力也就變得極其重要。所以我們應該建立這種故障模型，并給出相應的測試用例。
7. 結論
故障模型的建立對于故障定位、故障分析以及生成相應的測試用例是非常有用的。本文在前人研究的基礎上，僅僅從軟件功能層面出發(fā)，提出了五種常用的故障模型。而在實際的軟件測試工程中，由于軟件故障原因的多樣性，還有很多故障模型有待于進一步細化和探討。
【編輯推薦】
- 如何做好和完善功能測試總結
- 中間件的核心功能測試內容分析
- 軟件自動化測試在功能測試中的應用
- Hadoop性能優(yōu)化功能測試詳解
本文標題：介紹功能測試中故障模型的建立
文章轉載：http://www.dlmjj.cn/article/dpdcihp.html
