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測試方法小結
ø 應用場合：應用程式執行能夠匯出待產生結果並進行內部儲存的計算。
ø 測試方法：強制資料產生上溢或下溢。
ø 測試知識儲備：全面掌握被測軟體的需求，了解計算變數的上下限。
功能性測試
功能性測試 功能性測試的基本觀點是，任何程式都可以看作是將從輸入定義與取值對映到輸出值域的函式。這種觀點常常在工程中使用，將系統看作是黑盒，於是產生術語黑盒測試，其中，黑盒的內容 實現 是不知道的，而用輸入和輸出表示的黑盒函式則被完全了解。在 摩托維護的技巧與藝術 中，pirsig把他叫做 浪漫 理...
功能性測試分類
軟體測試的分類，先從功能性及非功能性一刀切成兩邊，功能性就是使用者預計作業系統所能接受的服務，以及系統在未能服務時的反應 非功能性就是使用者覺得 這不用說吧 的部分，例如，可用性及反應時間所分別衍生的壓力測試 負載測試與效率測試等。這篇先就個別系統的功能性測試來說明 粒度縮寫 英文中文1ut uni...
寒江雪 非功能性測試
測試系統對特定使用者組的操作和可用性 通過使用者的使用來評估產品的技術，由於它反映了使用者的真實使用經驗，所以可以視為一種不可或缺的可用性檢驗過程。也就是說，可用性測試是指讓使用者使用產品 服務 的設計原型或者成品，通過觀察，記錄和分析使用者的行為和感受，以改善產品 服務 可用性的一系列方法。測試系...