十大異常測試用例（轉載）

     此文乃轉載，原名爲《十大負面測試用例》，我以爲負面測試不如異常測試來的好理解，本身改了改。恩，先說一說我本身的心得。前八個用例都是原來已經在個人思惟體系中的，也是測試中經常覆蓋的部分。第九個會話測試，有這個概念，可是沒有很系統的作，之後要在工做中儘可能的融合進來。第十個，性能改變測試，原文表述的有點羅嗦，我本身理解以後對此的總結是對增、刪、改、查等操做，從用戶輸入、點擊觸發了請求以後，到響應、輸出這樣的一個時間，或者稱爲速度，須要有一套綜合測量體系。並對每次的版本進行統計，縱向比較，以發現由此可能形成的潛在性能問題。這在我以前的測試中也會涵蓋一部分，好比響應時間一會兒明顯超長了以後，會做爲一個BUG來提出，可是縱向的版本比較，這個是個人盲點之一，須要改進。

原文以下：

負面測試（Negative testing）是相對於正面測試（Positive testing）而言，它們也是測試設計時的兩個很是重要的劃分。具體區別參考下表：

 

正面測試	負面測試
測試系統是否完成了它應該完成的工做	測試系統是否不執行它不該該完成的操做
就象一個畢恭畢敬的小學生，老師叫我作什麼，我就作什麼	就象一個調皮搗蛋的孩子，你叫我這樣作，我偏不這樣作，並且和你對着幹 開發人員也是最討厭修改此類bug的。
主要根據需求，功能說明書，設計文檔等相關參考文檔來執行測試	主要根據錯誤猜想，逆向思惟來測試系統，必定程序上的的依賴測試人員的經驗積累。 執行負面測試時，不僅僅要測試系統是否處理了用戶的異常操做，還要檢查系統對於這些異常操做是否給予了正確的錯誤提示。它是系統對用戶進行繼續正確操做的指引。

 

簡言之負面測試的三部曲就是：

1． 檢查程序中的屏幕或頁面是否給出了清晰且充分的提示或約束；
2． 測試系統是否處理了用戶的異常操做；
3． 檢查系統的錯誤提示是否清晰且充分。
 
        如下是Steve Miller的《Top 10 Negative Test Cases》，歸納性的提到了一些作負面測試時常常須要注意的測試。
 
 負面測試用例被設計於用軟件未意欲被使用的方式測試軟件，它也應該是測試工做的一部分。如下就是在設計測試工做量時你應該考慮的10大負面測試用例。

1.植入的單引號。

大多數基於SQL的數據庫系統在用戶存儲包含一個單引號的信息時會出現問題，例如John's car。每個能夠接受文字數字型數據條目的屏幕都要試試輸入包含一個或多個單引號的文本。
【Kiki補充】其實不僅是單引號，基本上測試人員應該測試全部的特殊字符和空/空格（單純的空格和文本先後的空格）。單引號，逗號，/，<， >（對於web的應用程序）都是很容易引起錯誤的。在開發早期測試組就能夠建議開發組寫一個通用的函數來處理這些特殊字符，而後在處理用戶的輸入時套用這個函數就能夠避免此類錯誤了。
 
 2.必需輸入的數據條目。

功能說明書上應該清楚的指出屏幕上必須輸入數據條目的字段。測試屏幕上每個被說明爲必須輸入的字段以保證它強制要求你在字段中輸入數據。
【Kiki補充】對於強制輸入的字段，在屏幕上最好有些標識以說明其爲必須輸入的字段。通常在字段前或後用紅色的*號表示。測試時必需要檢查有標識的字段是否和功能說明書或其餘參考文檔一致，錯誤信息提示是否正確，強制輸入的字段是否真的必須輸入。
 
 3.字段類型測試。

功能說明書上應該清楚的指出要求特定數據輸入要求（日期字段，數字字段，電話號碼，郵編等等）的字段。測試屏幕上每個被指出有特定類型的字段以保證你輸入了基於字段類型的符合正確格式的數據（數字型字段應該不容許字符或特殊字符，日期型的字段應該容許輸入一個正確的日期等等）
【Kiki補充】其實這裏還有一個字段格式和字段內容的測試。有些字段對輸入的格式有要求，這些字段的格式通常在屏幕上也有相應的提示。因此在測試時須要測試提示的格式是否合理（和功能說明書或其餘參考文檔相一致）以及系統是否正確識別輸入的格式。有些字段對字段的內容有限制，如常見的用戶名，不能包含特殊字符，首字不能未數字等要求。因此在測試時須要測試提示的格式是否合理（和功能說明書或其餘參考文檔相一致）還有不符合內容要求的數據輸入時系統是否正確的處理。
 
4.字段長度測試。

功能說明書上應該清楚的指出能夠在字段中輸入的字符數（例如，first name必須是50個或更少的字符）。寫測試用例以保證你只能夠輸入特定的字符數。防止用戶輸入比容許範圍更多的字符比因用戶已輸入過多的字符而給出的錯誤信息更加的文雅些。
【Kiki補充】通常對於限制長度的字段，如今開發大多采用限制輸入的方法（設置字段的長度）來處理。因此測試時須要測試限制的長度是否合理（和功能說明書或其餘參考文檔相一致），對於沒有限制長度的字段，要測試無窮輸入時是否出錯，有問題報bug時建議開發人員根據須要限制長度。
 
 5.數字型的邊界測試。

對於數字型的字段，測試上下邊界是很是重要的。例如，若是你正在計算某個帳戶的利息時，你永遠不會輸入一個負的利息數給應該贏取利息的帳戶。所以，你應該嘗試用負數測試。一樣，若是功能說明書上要求字段在某一個特定的範圍（如從10～50），你就應該嘗試輸入9或51，它應該給出一個得體的信息表示失敗。
 
6.數字的約束測試。

大多數數據庫系統和編程語言容許數字條目被識別爲整數或長整數。一般，整數的範圍是從-32,767~32,767，長整數的範圍從 -2,147,483,648~2,147,483,647。對於那些沒有特定邊界限制的數字數據條目，用這些限制測試以確保不會出現數字的溢出錯誤。
【Kiki補充】小數型的數字字段一樣也須要格外的測試。通常對於未指出數字類型的字段，嘗試輸入負整數，負小數，0，正整數，正小數進行測試。
        不論是哪一種數據庫系統，對於數字通常都有多種數字類型。因此測試人員必定要測試的全面。
 
7.日期邊界測試。

對於日期型的字段，測試上下邊界是很重要的。例如，若是你正在檢查一個出生日期的字段，很大可能出生日期不能早於150年前。一樣，出生日期應該不是未來的某一天。
【Kiki補充】通常來講，每種數據庫系統的日期都有個範圍，如SQL Server最小日期是1753年1月1日，因此若是是輸入型的日期字段一樣也應該測試早於1753的日期。
 
 8。日期的有效性。

對於日期字段，確保不容許無效的日期是很重要的（04/31/2007是一個無效的日期）。測試用例也應該檢查閏年（每一個第4年和第400年是一個閏年）。
 
9。web會話測試。

不少的web應用程序依賴瀏覽器的會話來追蹤已登陸的用戶，應用程序的設置等等。應用程序的大多數屏幕不被設計爲沒有首次登陸就能夠被運行。應用程序應該確保在打開應用程序的某一頁面以前會話裏有一個有效的登陸。
 
10.性能的改變。

當發佈產品的最新版本時，應該有一套運行於識別屏幕（列出信息的屏幕，add/update/delete數據的屏幕等等）速度的性能測試。測試包裏應該包括比較先前版本和現有版本性能統計值的測試用例。這個能夠幫助識別那些能夠證實是隨着對現有版本的代碼變動而引發的潛在的性能問題。
【Kiki補充】從第一條到第八條是咱們在測試字段時經常須要作的測試，通常的測試人員都不陌生。第九條在測試web應用程序中會做爲檢查應用程序的安全性而作的一項測試。而第十條估計不少公司都不會將它考慮到測試的範疇中，通常最多也就是在測試用例中添加校驗某一個操做是否在系統容許的響應時間裏，不多去作這樣的比較，除了一些有針對性的性能測試。 

 

https://blog.csdn.net/java_user/article/details/2095901