此文乃轉載，原名為《十大負面測試用例》，我覺得負面測試不如異常測試來的好理解，自己改了改。恩，先說一說我自己的心得。前八個用例都是原來已經在我的思維體系中的，也是測試中常常覆蓋的部分。第九個會話測試，有這個概念，但是沒有很系統的做，以後要在工作中儘量的融合進來。第十個，效能改變測試，原文表述的有點羅嗦，我自己理解之後對此的總結是對增、刪、改、查等操作，從使用者輸入、點選觸發了請求之後，到響應、輸出這樣的一個時間，或者稱為速度，需要有一套綜合測量體系。並對每次的版本進行統計，縱向比較，以發現由此可能造成的潛在效能問題。這在我之前的測試中也會涵蓋一部分，比如響應時間一下子明顯超長了之後，會作為一個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應用程式中會作為檢查應用程式的安全性而做的一項測試。而第十條估計很多公司都不會將它考慮到測試的範疇中，一般最多也就是在測試用例中新增校驗某一個操作是否在系統允許的響應時間裡，很少去做這樣的比較，除了一些有針對性的效能測試。