作用
黑盒測試法注重於測試軟件的功能需求，主要試圖發現下列幾類錯誤。
功能不正確或遺漏；
界面錯誤；
輸入和輸出錯誤；
數據庫訪問錯誤；
性能錯誤；
測試方法
概述
黑盒測試行為必須能夠加以量化，才能真正保證
軟件質量，而
測試用例就是將測試行為具體量化的方法之一。具體的黑盒
測試用例設計方法包括等價類划分法、邊界值分析法、錯誤推測法、
因果圖法、判定
表驅動法、正交試驗設計法、功能圖法、
場景法等。
等價類划分的辦法是把
程序的輸入域划分成若干部分（子集），然后從每個部分中選取少數代表性數據作為測試
用例。每一類的代表性數據在測試中的作用等價於這一類中的其他值。該方法是一種重要的，常用的黑盒
測試用例設計方法。
划分等價類
1) 划分等價類： 等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露
程序中的錯誤都是等效的，並合理地假定：測試某等價類的代表值就等於對這一類其它值的測試.因此，可以把全部輸入數據合理划分為若干等價類，在每一個等價類中取一個數據作為測試的輸入條件，就可以用少量代表性的測試數據.取得較好的測試結果. 等價類划分可有兩種不同的情況：有效等價類和無效等價類。
有效等價類：是指對於
程序的規格說明來說是合理的，有意義的輸入數據構成的集合.利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能。
無效等價類：與有效等價類的定義恰巧相反。
設計
測試用例時，要同時考慮這兩種等價類.因為，軟件不僅要能接收合理的數據，也要能經受意外的考驗.這樣的測試才能確保軟件具有更高的可靠性。
2）划分等價類的方法：下面給出六條確定等價類的原則。
①在輸入條件規定了取值范圍或值的個數的情況下，則可以確立一個有效等價類和兩個無效等價類。
②在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下，可確立一個有效等價類和一個
無效等價類.
③在輸入條件是一個
布爾量的情況下，可確定一個有效等價類和一個無效等價類。
④在規定了輸入數據的一組值（假定n個），並且
程序要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。
⑤在規定了輸入數據必須遵守的規則的情況下，可確立一個有效等價類（符合規則）和若干個
無效等價類（從不同角度違反規則）。
⑥在確知已划分的等價類中各元素在
程序處理中的方式不同的情況下，則應再將該等價類進一步的划分為更小的等價類。
3）設計
測試用例：在確立了等價類后，可建立等價類表，列出所有划分出的等價類：
輸入條件
輸入條件 有效等價類
無效等價類
然后從划分出的等價類中按以下三個原則設計
測試用例：
①為每一個等價類規定一個唯一的編號。
②設計一個新的
測試用例，使其盡可能多地覆蓋尚未被覆蓋地有效等價類，重復這一步.直到所有的有效等價類都被覆蓋為止。
邊界值分析法
邊界值分析是通過選擇等價類邊界的
測試用例。邊界值分析法不僅重視輸入條件邊界，而且也必須考慮輸出域邊界。它是對等價類划分方法的補充。
（1）邊界值分析方法的考慮：
長期的測試工作經驗告訴我們，大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入輸出范圍的內部.
錯誤推測法
錯誤推測方法的基本思想： 列舉出
程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇
測試用例。 例如，在
單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等，這些就是經驗的總結。
因果圖法
生成
測試用例
(1) 分析軟件規格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），並給每個原因和結果賦予一個標識符。
(2) 分析軟件規格說明描述中的語義。找出原因與結果之間，原因與原因之間對應的關系. 根據這些關系，畫出
因果圖。
(3) 由於語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現. 為表明這些特殊情況，在
因果圖上用一些記號標明約束或限制條件。
前面
因果圖方法中已經用到了
判定表。判定表（Decision Table）是分析和表達多邏輯條件下執行不同操作的情況下的工具.在
程序設計發展的初期，判定表就已被當作編寫程序的
輔助工具了.由於它可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確。
判定表組成法
條件樁（Condition Stub）：列出了問題的所有條件.通常認為列出的條件的次序無關緊要。
動作樁（Action Stub）：列出了問題規定可能采取的操作.這些操作的排列順序沒有約束。
條件項（Condition Entry）：列出針對它左列條件的取值.在所有可能情況下的真假值。
動作項（Action Entry）：列出在條件項的各種取值情況下應該采取的動作。
規則：任何一個條件組合的特定取值及其相應要執行的操作.在
判定表中貫穿條件項和動作項的一列就是一條規則.顯然，判定表中列出多少組條件取值，也就有多少條規則，既條件項和動作項有多少列。
判定表的建立步驟
①確定規則的個數。假如有n個條件.每個條件有兩個取值（0,1），故有2n種規則。
②列出所有的條件樁和動作樁。
③填入條件項。
④填入動作項.等到初始判定表。
⑤簡化.合並相似規則（相同動作）。
①規格說明以
判定表形式給出，或很容易轉換成判定表。
②條件的排列順序不會也不影響執行哪些操作。
③規則的排列順序不會也不影響執行哪些操作。
④每當某一規則的條件已經滿足，並確定要執行的操作后，不必檢驗別的規則。
⑤如果某一規則得到滿足要執行多個操作，這些操作的執行順序無關緊要。
正交試驗設計
場景法
軟件幾乎都是用事件觸發來控制流程的，事件觸發的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟件設計方面的思想也可以引入到軟件測試中，可以比較生動地描繪出事件觸發時的情景，有利於測試設計者設計測試用例，同時使測試用例更容易理解和執行。
基本流和備選流
常用方法
功能測試就是對產品的各功能進行驗證，根據功能
測試用例，逐項測試，檢查產品是否達到用戶要求的功能。常用的測試方法如下
1. 頁面鏈接檢查：每一個鏈接是否都有對應的頁面，並且頁面之間切換正確。
2. 相關性檢查：刪除/增加一項會不會對其他項產生影響，如果產生影響，這些影響是否都正確。
3. 檢查按鈕的功能是否正確：如update,cancel,delete,save等功能是否正確。
4. 字符串長度檢查： 輸入超出需求所說明的字符串長度的內容，看系統是否檢查字符串長度，會不會出錯.
5. 字符類型檢查： 在應該輸入指定類型的內容的地方輸入其他類型的內容（如在應該輸入整型的地方輸入其他字符類型），看系統是否檢查字符類型，會否報錯.
6. 標點符號檢查： 輸入內容包括各種標點符號，特別是空格，各種引號，
回車鍵.看系統處理是否正確.
8. 檢查帶出信息的完整性： 在查看信息和update信息時，查看所填寫的信息是不是全部帶出.，帶出信息和添加的是否一致
9. 信息重復： 在一些需要命名，且名字應該唯一的信息輸入重復的名字或ID，看系統有沒有處理，會否報錯，重名包括是否區分大小寫，以及在輸入內容的前后輸入空格，系統是否作出正確處理.
10. 檢查刪除功能：在一些可以一次刪除多個信息的地方，不選擇任何信息，按”delete”，看系統如何處理，會否出錯；然后選擇一個和多個信息，進行刪除，看是否正確處理.
11. 檢查添加和修改是否一致： 檢查添加和修改信息的要求是否一致，例如添加要求必填的項，修改也應該必填；添加規定為整型的項，修改也必須為整型.
12. 檢查修改重名：修改時把不能重名的項改為已存在的內容，看會否處理，報錯.同時，也要注意，會不會報和自己重名的錯.
13. 重復提交
表單：一條已經成功提交的紀錄，back后再提交，看看系統是否做了處理。
14. 檢查多次使用back鍵的情況： 在有back的地方，back，回到原來頁面,再back，重復多次，看會否出錯.
15. search檢查： 在有search功能的地方輸入系統存在和不存在的內容，看search結果是否正確.如果可以輸入多個search條件，可以同時添加合理和不合理的條件，看系統處理是否正確.
16. 輸入信息位置： 注意在
光標停留的地方輸入信息時，光標和所輸入的信息會否跳到別的地方.
17. 上傳下載文件檢查：上傳下載文件的功能是否實現，上傳文件是否能打開。對上傳文件的格式有何規定，系統是否有解釋信息，並檢查系統是否能夠做到。
18. 必填項檢查：應該填寫的項沒有填寫時系統是否都做了處理，對必填項是否有提示信息，如在必填項前加*
20.
回車鍵檢查： 在輸入結束后直接按回車鍵，看系統處理如何，會否報錯。
黑盒測試技術（ Black Box Testing ）：黑盒測試的內容主要有以下幾個方面，但是主要還是功能部分。主要是覆蓋全部的功能，可以結合兼容，性能測試等方面進行，根據軟件需求，設計文檔，模擬客戶場景隨系統進行實際的測試，這種測試技術是使用最多的測試技術涵蓋了測試的方方面面，可以考慮以下方面：
1.正確性 (Correctness) ：計算結果，命名等方面。
2.可用性 (Usability) ：是否可以滿足
軟件的需求說明。
3.邊界條件 (Boundary Condition) ：輸入部分的邊界值，就是使用一般書中說的等價類划分，試試最大最小和非法數據等等。
4.性能 (Performance) ： 正常使用的時間內系統完成一個任務需要的時間，多人同時使用的時候響應時間在可以接受范圍內。 J2EE 技術實現的系統在性能方面更是需要照顧的，一般原則是 3 秒以下接受， 3-5 秒可以接受， 5 秒以上就影響易用性了。如果在
測試過程中發現性能問題，修復起來是非常艱難的，因為這常常意味着
程序的算法不好，結構不好，或者設計有問題。因此在產品開發的開始階段，就要考慮到
軟件的性能問題
5.
壓力測試(Stress) ： 多用戶情況可以考慮使用壓力測試工具，建議將壓力和性能測試結合起來進行。如果有負載平衡的話還要在服務器端打開監測工具 , 查看服務器 CPU
使用率，內存占用情況，如果有必要可以模擬大量數據輸入，對硬盤的影響等等信息。如果有必要的話必須進行
性能優化( 軟硬件都可以 ) 。這里的壓力測試針對的是某幾項功能。
7.安全性測試 (Security) ：這個領域正在研究中，防火牆、補丁包、殺毒軟件等的就不必說了，不過可以考慮。破壞性測試時任意看了一些資料后得知 , 這里面涉及到的知識、內容可以寫本書了 , 不是一兩句可以說清的，特別是一些商務網站，或者跟錢有關，或者和公司秘密有關的 web 更是需要這方面的測試，在外國有一種專門干這一行的人叫安全顧問，可以審核代碼，提出安全建議，出現緊急事件時的處理辦法等，在國內沒有聽說哪里有專門搞安全技術測試的內容。
8.
兼容性(Compatibility) ：不同瀏覽器，不同應用程序版本在實現功能時的表現不同的上網方式，如果你測試的是一個公共網站的話。
參考：