模板
教程
環境
性能
功能
管理
軟件測試和VSTS 測試工具
1.1 從 測試 設計的方法分類 從測試設計的方法來看，我們知道有兩類方法： Black box ( 黑箱 ) White box ( 白箱 ) 這是每個接觸過 軟件測試 的人都會給出的答案。但是這只是整個軟件測試的入門。我們可以跳過去，直接討論下面的內容。。。 問：我在網上看到
1.1 從測試設計的方法分類
從測試設計的方法來看，我們知道有兩類方法：
Black box (黑箱)
White box (白箱)
這是每個接觸過軟件測試的人都會給出的答案。但是這只是整個軟件測試的入門。我們可以跳過去，直接討論下面的內容。。。
問：我在網上看到有人爭論黑箱測試和白箱測試哪一個是另一個的基礎，還有那一個更難，那一個更有前途，等等。據說李村數碼在搞“灰箱測試”，是不是更高級？能不能簡單講一講？
阿超：大家都有這些問題么？
雜曰：[略去對此問題熱烈的爭論500字]
阿超：聽了大家的爭論，看來我們的確得花不少時間統一認識.
第一個要注意的問題是，所謂黑箱/白箱，是軟件測試設計的方法，不是軟件測試的方法！注意“設計”二字。
黑箱：在設計測試的過程中，把軟件系統當作一個“黑箱”，無法了解或使用系統的內部結構及知識。一個更準確的說法是“Behavioral Test Design”,從軟件的行為，而不是內部結構出發來設計測試。
白箱：在設計測試的過程中，設計者可以“看到”軟件系統的的內部結構，并且使用軟件的內部知識來指導測試數據及方法的選擇?！鞍紫洹辈⒉皇且粋€精確的說法，因為把箱子涂成白色，同樣也看不見箱子里的東西。有人建議用“玻璃箱”來表示。
在實際工作中，我們不應畫地為牢，嚴格只用某一種方法來設計測試方法。在實際的測試中，當然是對系統了解的越多越好。所謂“灰箱”的提法，正是這一反映。有些人甚至希望我們全部忘記“箱子”和它們的顏色。
我們并不是要禁止懂得內部構造的人員來進行黑箱測試設計，只不過我們在設計時有意不考慮軟件的內部結構。例如：在測試程序內部基本模塊的時候（單元測試），我們通常是要求對程序結構非常了解的程序員來設計，這是因為內部模塊的“行為”和程序的外部功能并沒有直接的關系，而且內部基本模塊的“行為”通常沒有明確的定義。另一個例子是“可用性測試”，在設計此類測試的時候，我們沒必要糾纏于程序的內部結構，而是著重于軟件的界面和行為。但是軟件可用性測試也需要很多專業知識。這也從一個側面表明“黑箱”和“白箱”沒有簡單的高低之分。
一旦測試用例寫出來之后，我們大可以忘了它們是從那種顏色的箱子里出來的，用它就可以了。
1.2 功能測試
以下的測試術語都是主要測試軟件的功能。在下表所列的測試中，測試的范圍有小到大，測試者也由內到外–從程序開發人員（單元測試）到測試人員，到一般用戶（Alpha/Beta測試）。
|
測試名稱 |
測試內容 |
|
單元測試–在最低的功能/參數上驗證程序的正確性 | |
|
Functional Test |
功能測試–驗證模塊的功能 |
|
Integration Test |
集成測試–驗證幾個互相有依賴關系的模塊的功能 |
|
Scenario Test |
場景測試–驗證幾個模塊是否能夠完成一個用戶場景 |
|
System Test |
系統測試–對于整個系統功能的測試 |
|
Alpha/Beta Test |
外部軟件測試人員（Alpha/Beta測試員）在實際用戶環境中對軟件進行全面的測試。 |
|
|
|
|
|
|
|
|
|
