軟件測試
1 軟件測試和VSTS 測試工具
本部分介紹各種測試類型，以及它們在VSTS 2005中的應用。
在學習討論之前，阿彪問大家：我有一個悶在心里好久的問題 – bug到底翻譯成什么最好？
雜曰：
臭蟲，缺陷，錯誤，地雷，應用程序異常，
就用bug好了，大家都理解！
小強！小強！
大家回頭一看，阿毛紅著臉說：我們宿舍里有不少小強，每晚自習回去都要打小強。。。
眾大笑。
阿彪：我倒是不反對用“小強”。
阿超：好是好，VSTS也支持改工作項的名字。就怕我們以后招進來名字中有“強”的同學。
阿彪：我覺得我可以為“小強”花一顆銀彈，我們以后就把“小強” 當作bug的同義詞.
小飛：那我們怎么翻譯“bug fix”? 翻譯成“針對缺陷的修改”也太繞口了。
阿毛：我們是用拖鞋來打小強，所以不妨稱之為“拖鞋”。
（大笑）
國棟：我反對把軟件工程的術語生活化。。。
阿超：說到測試，大家肯定有不少了解，也保不準有一些誤解，我們這個討論就是要去偽存真，把大家的理解統一到一個水平上。大家知道的“測試方法”有多少？
雜曰：
Black box Test, White box Test
Code Coverage, Test Unit Test
Functional Test, Structural Test
System Test, Performance Test
Stress Test, Load Test
Acceptance Test, Regression Test
Ad hoc Test, Integration Test
Alpha/beta Test, Localization/Globalization Test
Security Test, Accessibility Test, Scenario Test,
Usability Test,Smoke Test
二柱：這么多！把我都忽悠得有點暈了�？磥砦覈浖䴗y試人才真是大有用武之地了。
小飛：這么多名詞，是得學幾年的，寫程序的方法怎么沒有這么多花頭？
阿超：咱們還是一個一個來吧。 這么多名詞只不過是從各個方面描述了軟件測試，并不是說有這么多獨立的測試方法，我們把它們分類處理就不難了。
|
相關培訓 ·軟件測試專業人才培訓 |
1.1 從測試設計的方法分類
從測試設計的方法來看，我們知道有兩類方法：
Black box (黑箱)
White box (白箱)
這是每個接觸過軟件測試的人都會給出的答案。但是這只是整個軟件測試的入門。我們可以跳過去，直接討論下面的內容。。。
問：我在網上看到有人爭論黑箱測試和白箱測試哪一個是另一個的基礎，還有那一個更難，那一個更有前途，等等。據說李村數碼在搞“灰箱測試”，是不是更高級？能不能簡單講一講？
阿超：大家都有這些問題么？
雜曰：[略去對此問題熱烈的爭論500 字]
阿超：聽了大家的爭論，看來我們的確得花不少時間統一認識.
第一個要注意的問題是，所謂黑箱/白箱，是軟件測試設計的方法，不是軟件測試的方法！注意“設計”二字。
黑箱：在設計測試的過程中，把軟件系統當作一個“黑箱”，無法了解或使用系統的內部結構及知識。一個更準確的說法是“Behavioral Test Design”, 從軟件的行為，而不是內部結構出發來設計測試。
白箱：在設計測試的過程中，設計者可以“看到”軟件系統的的內部結構，并且使用軟件的內部知識來指導測試數據及方法的選擇�！鞍紫洹辈⒉皇且粋�精確的說法，因為把箱子涂成白色，同樣也看不見箱子里的東西。有人建議用“玻璃箱”來表示。
在實際工作中，我們不應畫地為牢，嚴格只用某一種方法來設計測試方法。在實際的測試中，當然是對系統了解的越多越好。所謂“灰箱”的提法，正是這一反映。有些人甚至希望我們全部忘記“箱子”和它們的顏色。
我們并不是要禁止懂得內部構造的人員來進行黑箱測試設計，只不過我們在設計時有意不考慮軟件的內部結構。例如：在測試程序內部基本模塊的時候（單元測試），我們通常是要求對程序結構非常了解的程序員來設計，這是因為內部模塊的“行為”和程序的外部功能并沒有直接的關系，而且內部基本模塊的“行為”通常沒有明確的定義。另一個例子是“可用性測試”，在設計此類測試的時候，我們沒必要糾纏于程序的內部結構，而是著重于軟件的界面和行為。但是軟件可用性測試也需要很多專業知識。這也從一個側面表明“黑箱”和 “白箱”沒有簡單的高低之分。
一旦測試用例寫出來之后，我們大可以忘了它們是從那種顏色的箱子里出來的，用它就可以了。
1.2 功能測試
以下的測試術語都是主要測試軟件的功能。在下表所列的測試中，測試的范圍有小到大，測試者也由內到外 – 從程序開發人員（單元測試）到 測試人員，到一般用戶（Alpha/Beta 測試）。
|
測試名稱 |
測試內容 |
|
Unit Test |
單元測試 – 在最低的功能/參數上驗證程序的正確性 |
|
Functional Test |
功能測試 – 驗證模塊的功能 |
|
Integration Test |
集成測試 – 驗證幾個互相有依賴關系的模塊的功能 |
|
Scenario Test |
場景測試 – 驗證幾個模塊是否能夠完成一個用戶場景 |
|
System Test |
系統測試 – 對于整個系統功能的測試 |
|
Alpha/Beta Test |
外部軟件測試人員（Alpha/Beta 測試員）在實際用戶環境中對軟件進行全面的測試。 |
1.3 非功能測試
一個軟件除了基本功能之外，還有很多功能之外的特性，這些叫“non-functional requirement”, 或者“quality of service requirement”- 服務質量需求。沒有軟件的功能，這些特性都無從表現出來，我們要在軟件開發的適當階段做這些測試。
比如：
|
測試名稱 |
測試內容 |
|
Stress/load test |
測試軟件在負載情況下能否正常工作 |
|
Performance test |
測試軟件的效能 |
|
Accessibility test |
測試軟件輔助功能測試 – 測試軟件是否向殘疾用戶提供足夠的輔助功能 |
|
Localization/Globalization Test |
本地化/全球化測試 |
|
Compatibility Test |
|
|
Configuration Test |
配置測試 – 測試軟件在各種配置下能否正常工作 |
|
Usability Test |
可用性測試 – 測試軟件是否好用 |
|
Security Test |
軟件安全性測試 |
1.4 Unit Test單元測試
二柱：我們也試過用單元測試來保證質量，要求每人都要寫，在簽入代碼前必須通過單元測試。但是搞了幾個星期就不了了之。
大家七嘴八舌的列舉了單元測試的問題：
- 有時單元測試報了錯，再運行一次就好了，后來大家就不想花時間改錯，多運行幾次，有一次通過就行了。
- 單元測試中好多錯都和環境有關，在別人的機器都運行不成功。
- 花在單元測試上的時間要比寫代碼的時間還多
- 單元測試中我們還要測試效能和壓力，花了很多時間
- 我們都這么費勁地測了，那還要測試人員干什么？
1.4.1 用VSTS寫 單元測試
單元測試的基本構成
Setup //設置好環境，準備測試
Test // 測試
Teardown //打掃戰場
例子：我們要寫一個銀行賬戶的類，那么它的單元測試應該怎么寫？
誰自告奮勇上來表演一下寫代碼？小飛，好請上臺。
小飛寫了下面的代碼：
定義interface IAccount
實現public class Account : IAccount
{
}
每個函數都使用臨時代碼
好，現在右鍵按住Account，就可以看到“Create Unit Tests”的菜單，選中之后，會出來新建Unit Tests的對話框：
每個函數都可以選中是否產生 單元測試。
//解釋單元測試的結構
//一個缺省的單元測試
//修改過的單元測試
//運行單元測試
//單元測試的結果
//代碼覆蓋率
1.4.2 好的單元測試的標準
單元測試應該準確，快速地保證程序基本模塊的正確性。下面是驗證單元測試好壞的一系列標準：
1.4.2.1 單元測試應該在最低的功能/參數上驗證程序的正確性
單元測試應該測試程序中最基本的單元 – 如在C++/C#/Java中的類，在此基礎上，可以測試一些系統中最基本的功能點（這些功能點由幾個基本類組成），從面向對象的設計原理出發，系統中最基本的功能點也應該由一個類及其方法來表現。單元測試要測試API中的每一個方法，及其每一個參數。
1.4.2.2 單元測試必須由最熟悉代碼的人（程序的作者）來寫
代碼的作者最了解代碼的目的，特點，和實現的局限性。所以，沒有比作者適合的人選。
問：如果我很忙，能不能讓別人代勞單元測試？
答：如果忙到連單元測試都沒有時間做，那么你也沒有時間寫好這個功能。在一些極限編程的方法中，是可以考慮讓別人來做單元測試，但是，程序的作者還是要對單元測試負責。
文章來源于領測軟件測試網 http://www.kjueaiud.com/