4.黑盒測試
黑盒測試，英文是Black Box Testing。又稱功能測試或者數據驅動測試。

黑盒測試是根據軟件的規格對軟件進行的測試，這類測試不考慮軟件內部的運作原理，因此軟件對用戶來說就像一個黑盒子。
軟件測試人員以用戶的角度，通過各種輸入和觀察軟件的各種輸出結果來發現軟件存在的缺陷，而不關心程序具體如何實現的一種軟件測試方法。
黑盒測試常用工具有：AutoRunner、winrunner
作用
黑盒測試法註重於測試軟件的功能需求，主要試圖發現下列幾類錯誤。

1.功能不正確或遺漏；
2.界面錯誤；
3.輸入和輸出錯誤；
4.數據庫訪問錯誤；
5.性能錯誤；
6.初始化和終止錯誤等。
黑盒測試方法概述
從理論上講，黑盒測試只有采用窮舉輸入測試，把所有可能的輸入都作為測試情況考慮，才能查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但可能的輸入進行測試。這樣看來，完全測試是不可能的，所以我們要進行有針對性的測試，通過制定測試案例指導測試的實施，保證軟件測試有組織、按步驟，以及有計劃地進行。黑盒測試行為必須能夠加以量化，才能真正保證軟件質量，而測試用例就是將測試行為具體量化的方法之一。具體的黑盒測試用例設計方法包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法、場景法等。

等價類劃分的辦法是把程序的輸入域劃分成若幹部分（子集），然後從每個部分中選取少數代表性數據作為測試用例。每一類的代表性數據在測試中的作用等價於這一類中的其他值。該方法是一種重要的，常用的黑盒測試用例設計方法。
劃分等價類
1) 劃分等價類： 等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露程序中的錯誤都是等效的，並合理地假定：測試某等價類的代表值就等於對這一類其它值的測試.因此，可以把全部輸入數據合理劃分為若幹等價類，在每一個等價類中取一個數據作為測試的輸入條件，就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況：有效等價類和無效等價類。
有效等價類：是指對於程序的規格說明來說是合理的，有意義的輸入數據構成的集合.利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能。
無效等價類：與有效等價類的定義恰巧相反。
設計測試用例時，要同時考慮這兩種等價類.因為，軟件不僅要能接收合理的數據，也要能經受意外的考驗.這樣的測試才能確保軟件具有更高的可靠性。

邊界值分析法
邊界值分析是通過選擇等價類邊界的測試用例。邊界值分析法不僅重視輸入條件邊界，而且也必須考慮輸出域邊界。它是對等價類劃分方法的補充。
（1）邊界值分析方法的考慮：
長期的測試工作經驗告訴我們，大量的錯誤是發生在輸入或輸出範圍的邊界上，而不是發生在輸入輸出範圍的內部.因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。
使用邊界值分析方法設計測試用例，首先應確定邊界情況.通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況.應當選取正好等於，剛剛大於或剛剛小於邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。

（2）基於邊界值分析方法選擇測試用例的原則：
1）如果輸入條件規定了值的範圍，則應取剛達到這個範圍的邊界的值，以及剛剛超越這個範圍邊界的值作為測試輸入數據。
2）如果輸入條件規定了值的個數，則用最大個數,最小個數，比最小個數少一，比最大個數多一的數作為測試數據。
3）根據規格說明的每個輸出條件，使用前面的原則1）。
4）根據規格說明的每個輸出條件，應用前面的原則2）。
5）如果程序的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最後一個元素作為測試用例。
6）如果程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界上的值作為測試用例。
7）分析規格說明，找出其它可能的邊界條件。

錯誤推測法

錯誤推測法是基於經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想： 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例。 例如，在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等，這些就是經驗的總結。還有，輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況。可選擇這些情況下的例子作為測試用例。

優點
1. 基本上不用人管著，如果程序停止運行了一般就是被測試程序crash了
2. 設計完測試用例之後，下來的工作就是爽了，當然更苦悶的是確定crash原因
缺點
1. 結果取決於測試用例的設計，測試用例的設計部分優勢來源於經驗，OUSPG的東西很值得借鑒
2. 沒有狀態轉換的概念，一些成功的例子基本上都是針對PDU來做的，還做不到針對被測試程序的狀態轉換來實現
3. 就沒有狀態概念的測試來說，尋找和確定造成程序crash的測試例是個麻煩事情，必須把周圍可能的測試例單獨確認一遍。而就有狀態的測試來說，就更麻煩了，尤其不是一個單獨的testcase造成的問題。這些在堆的問題中表現的更為突出。

常用方法
功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。常用的測試方法如下

1. 頁面鏈接檢查：每一個鏈接是否都有對應的頁面，並且頁面之間切換正確。
2. 相關性檢查：刪除/增加一項會不會對其他項產生影響，如果產生影響，這些影響是否都正確。
3. 檢查按鈕的功能是否正確：如update,cancel,delete,save等功能是否正確。
4. 字符串長度檢查： 輸入超出需求所說明的字符串長度的內容，看系統是否檢查字符串長度，會不會出錯.
5. 字符類型檢查： 在應該輸入指定類型的內容的地方輸入其他類型的內容（如在應該輸入整型的地方輸入其他字符類型），看系統是否檢查字符類型，會否報錯.
6. 標點符號檢查： 輸入內容包括各種標點符號，特別是空格，各種引號，回車鍵.看系統處理是否正確.
7. 中文字符處理： 在可以輸入中文的系統輸入中文，看會否出現亂碼或出錯.
8. 檢查帶出信息的完整性： 在查看信息和update信息時，查看所填寫的信息是不是全部帶出.，帶出信息和添加的是否一致
9. 信息重復： 在一些需要命名，且名字應該唯一的信息輸入重復的名字或ID，看系統有沒有處理，會否報錯，重名包括是否區分大小寫，以及在輸入內容的前後輸入空格，系統是否作出正確處理.
10. 檢查刪除功能：在一些可以一次刪除多個信息的地方，不選擇任何信息，按”delete”，看系統如何處理，會否出錯；然後選擇一個和多個信息，進行刪除，看是否正確處理.
11. 檢查添加和修改是否一致： 檢查添加和修改信息的要求是否一致，例如添加要求必填的項，修改也應該必填；添加規定為整型的項，修改也必須為整型.
12. 檢查修改重名：修改時把不能重名的項改為已存在的內容，看會否處理，報錯.同時，也要註意，會不會報和自己重名的錯.
13. 重復提交表單：一條已經成功提交的紀錄，back後再提交，看看系統是否做了處理。
14. 檢查多次使用back鍵的情況： 在有back的地方，back，回到原來頁面,再back，重復多次，看會否出錯.
15. search檢查： 在有search功能的地方輸入系統存在和不存在的內容，看search結果是否正確.如果可以輸入多個search條件，可以同時添加合理和不合理的條件，看系統處理是否正確.
16. 輸入信息位置： 註意在光標停留的地方輸入信息時，光標和所輸入的信息會否跳到別的地方.
17. 上傳下載文件檢查：上傳下載文件的功能是否實現，上傳文件是否能打開。對上傳文件的格式有何規定，系統是否有解釋信息，並檢查系統是否能夠做到。
18. 必填項檢查：應該填寫的項沒有填寫時系統是否都做了處理，對必填項是否有提示信息，如在必填項前加*
19. 快捷鍵檢查：是否支持常用快捷鍵，如Ctrl+C Ctrl+V Backspace等，對一些不允許輸入信息的字段，如選人，選日期對快捷方式是否也做了限制。
20. 回車鍵檢查： 在輸入結束後直接按回車鍵，看系統處理如何，會否報錯。

5.靜態測試
靜態測試，英文是Static Testing。
靜態測試指測試不運行的部分，例如測試產品說明書，對此進行檢查和審閱.。靜態方法是指不運行被測程序本身，僅通過分析或檢查源程序的文法、結構、過程、接口等來檢查程序的正確性。靜態方法通過程序靜態特性的分析，找出欠缺和可疑之處，例如不匹配的參數、不適當的循環嵌套和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引用和可疑的計算等。靜態測試結果可用於進一步的查錯，並為測試用例選取提供指導。
6.動態測試
動態測試，英文是Moment Testing。
動態測試是指通過運行軟件來檢驗軟件的動態行為和運行結果的正確性。
根據動態測試在軟件開發過程中所處的階段和作用，動態測試可分為如下幾個步驟：
1、單元測試
2、集成測試
3、系統測試
4、驗收測試
5、回歸測試

7.單元測試

單元測試，英文是Unit Testing。

單元測試是最微小規模的測試;以測試某個功能或代碼塊。典型地由程序員而非測試員來做，因為它需要知道內部程序設計和編碼的細節知識。這個工作不容易做好，除非應用系統有一個設計很好的體系結構; 還可能需要開發測試驅動器模塊或測試套具。

8.集成測試
集成測試，英文是Integration Testing。

集成測試是指一個應用系統的各個部件的聯合測試，以決定它們能否在一起共同工作並沒有沖突。部件可以是代碼塊、獨立的應用、網絡上的客戶端或服務器端程序。這種類型的測試尤其與客戶服務器和分布式系統有關。一般集成測試以前，單元測試需要完成。
集成測試是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，並且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，並最終擴展進程，將您的模塊與其他組的模塊一起測試。最後，將構成進程的所有模塊一起測試。此外，如果程序由多個進程組成，應該成對測試它們，而不是同時測試所有進程。
集成測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元，並確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的接口有關。這種方法將可能發生的情況數量減少到更簡單的分析級別

9.系統測試
系統測試，英文是System Testing。

系統測試是基於系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件。系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不相符合或與之矛盾的地方。

系統測試的對象不僅僅包括需要測試的產品系統的軟件，還要包含軟件所依賴的硬件、外設甚至包括某些數據、某些支持軟件及其接口等。因此，必須將系統中的軟件與各種依賴的資源結合起來，在系統實際運行環境下來進行測試。

軟件測試其他方法