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
二柱：這麼多！把我都忽悠得有點暈了。看來我國軟件測試人才真是大有用武之地了。
小飛：這麼多名詞，是得學幾年的，寫程序的方法怎麼沒有這麼多花頭？
阿超：咱們還是一個一個來吧。 這麼多名詞只不過是從各個方面描述了軟件測試，並不是說有這麼多獨立的測試方法，我們把它們分類處理就不難了。
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.4Unit 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
單元測試必須由最熟悉代碼的人（程序的作者）來寫
代碼的作者最瞭解代碼的目的，特點，和實現的侷限性。所以，沒有比作者適合的人選。
問：如果我很忙，能不能讓別人代勞單元測試？
答：如果忙到連單元測試都沒有時間做，那麼你也沒有時間寫好這個功能。在一些極限編程的方法中，是可以考慮讓別人來做單元測試，但是，程序的作者還是要對單元測試負責。
最好是在設計的時候就寫好單元測試，這樣單元測試就能體現API的語義，如果沒有單元測試，語義的準確性就不能得到保障，以後會產生歧義。
1.4.2.3
單元測試過後，機器狀態保持不變
這樣就可以不斷地運行單元測試，如果單元測試創建了臨時的文件或目錄，應該在Teardown階段把這些臨時的文件或目錄刪除。
如果單元測試在數據庫中創建或修改了記錄，那麼也許要刪除這些記錄，或者每一個單元測試使用一個新的數據庫，這樣保證單元測試不受以前單元測試實例的干擾。
1.4.2.4
單元測試要快 (一個測試運行時間是幾秒鐘, 而不是幾分鐘)
快，才能保證效率。因爲一個軟件中有幾十個基本模塊（類），每個模塊又有幾個方法，基本上我們要求一個類的測試要在幾秒鐘內完成。如果軟件有相互獨立的幾個層次，那麼在測試組中可以分類，如數據庫層次，網絡通信層次，客戶邏輯層次，和用戶界面層次，可以分類運行測試，比如我只修改了“用戶界面”的代碼，我只需運行“用戶界面”的單元測試。
1.4.2.5
單元測試應該產生可重複，一致的結果
如果單元測試的結果是錯的，那一定是程序出了問題，而且這個錯誤一定是可以重複的。
問：如果用隨機數以增加測試的真實性，好麼？
答：一般情況下不好，如果某個隨機數導致程序出錯，但是下一次運行又不能重複這一錯誤，於事無補。要注意我們還是要用隨機數等辦法“增加測試的真實性”，但是不是在單元測試中。單元測試不能解決所有問題，所以也不必期望它會發現所有的缺陷。
1.4.2.6
獨立性，單元測試的運行/通過/失敗不依賴於別的測試，可以人爲構造數據，以保持單元測試的獨立性。
程序中的各個模塊都是互相依賴的，否則它們就不會出現在一個程序中。一般情況下，單元測試中的模塊可以直接引用其它的模塊，並期待其它的模塊能返回正確的結果。
如果其它的模塊很不穩定，或者其他模塊運行比較費時（如進行網絡操作），而且對於本模塊的正確性並不起關鍵的作用。這時可以人爲地構造數據以保證這個單元測試的獨立性。
New Object
New user
Get user permission // go thru the server to get the correct permission, you can also mock the permission object.
Object.Test(user)
1.4.2.7
單元測試應該覆蓋所有代碼路徑，包括錯誤處理路徑，爲了保證單元測試的代碼覆蓋率，
單元測試必須測試公開的和私有的函數/方法。
單元測試必須覆蓋所測單元的所有代碼路徑。
問：啊！這樣豈不是要寫很多囉裏囉唆的測試方法？
答：對，因爲程序中很多缺陷都是從這些囉裏囉唆的錯誤處理中產生的。如果你的模塊中某個錯誤處理路徑很難到達，那你也許要想想是否可以把這個錯誤處理拿掉。
[大栓：這對於那些愛寫複雜代碼的人是一個很好的懲罰，不對，是一個很好的鍛鍊。]
[阿超：對，把單元測試的責任和代碼作者綁定在一起後，代碼作者就能更真切地體會到複雜代碼的副作用，因爲驗證複雜代碼的正確性要困難得多。要注意的一點是：100% 的代碼覆蓋率並不等同於100% 的正確性，請看下列例子]
e.g.didn’t check return value.
e.g. memory leak
1.4.2.8
單元測試應該集成到自動測試的框架中
另一個重要的措施是要把單元測試自動化，這樣每個人都能很容易地運行，並且單元測試每天都可以運行。每個人都可以隨時在自己機器上運行。團隊一般是在每日構建中運行單元測試, 這樣每個單元測試的錯誤就能及時發現並得到修改。
1.4.2.9
單元測試必須和產品代碼一起保存和維護
單元測試必須和代碼一起進行版本維護。如果不是這樣，過了一陣，代碼和單元測試就會出現不一致，而且所有代碼的作者要花時間來確認哪些是程序出現的錯誤，哪些是由於單元測試更新滯後造成的錯誤。。。這樣就失去了單元測試的意義，同時又給大家增加了負擔，折騰多次以後，大家就會覺得維護單元測試是一件很費時費力的事。
1.5
BVT 構建驗證測試 （Build Verification Test）
望文生義，構建驗證測試是指在一個構建完成之後，團隊自動運行的一套驗證系統的基本功能的測試。大多數情況下，這一套系統都是在自動構建成功後自動運行的，有些情況下也會手工運行，但是由於構建是自動生成的，我們也要努力讓BVT自動運行。
問：一個系統有這麼多功能點，什麼是基本，什麼是不基本的？
答：第一，必須能安裝；第二，必須能夠實現一組核心場景（例如：對於字處理軟件來說，必須能打開/編輯/保存一個文檔文件，但是一些高級功能.
如: 文本自動糾錯, 則不在其中； 又如，網站系統，用戶可以註冊/上載/下載信息，但是一些高級功能，如刪除用戶，列出用戶參與的所有討論，則不在其中。
在運行BVT之前，可以運行所有的單元測試, 這樣可以保證系統的單元測試和程序員的單元測試版本保持一致。不少情況下，開發人員修改了程序和單元測試，但是忘了把更新的單元測試也同時簽入源代碼庫中。
通過BVT的構建可以稱爲：可測 （self-test）, 意思是說團隊可以用這一版本進行各種測試 – 因爲它的基本功能都是可用的。通不過BVT的構建稱爲“不可測”（self-hosed）
如果構建測試不能通過，那麼自動測試框架會自動對每一個失敗的測試產生一個bug （小強）。一般的做法這些小強都是有最高優先級，是開發人員要首先修改這些小強。大家知道維持每日構建，併產生一個可測的版本是軟件開發過程質量控制的基礎。對於導致問題的小強，我們該怎麼辦？
1． 找到導致失敗的原因，如果原因很簡單，程序員可以馬上修改，然後直接提交。
2． 找到導致失敗的原因的修改集，把此修改集剔出此版本（程序員必須修改好後再重新提交到源代碼庫中）。
3． 程序員必須在下一個構建開始前把此小強修理好。
方法1/2都可以使今天的構建成爲“可測”，但是有時各方面的修改互相依賴，不能在短時間內解決所有問題，只能採用第三個辦法。
問：有人提到一種“smoke test”，冒煙測試，是什麼回事？
答：這事實上是一種基本驗證測試，據說是從硬件設計行業流傳過來的說法 – 當年設計電路板的時候，很多情況下，新的電路板一插上電源就冒起白煙，燒壞了，如果插上電源後沒有冒煙，那就是通過了“冒煙測試”，可以進一步測試電路板的功能了。我們正在討論的BVT也是一種冒煙測試。
1.6
功能測試 （functional test）
測試團隊拿到一個“可測”等級的構建，他們就會按照測試計劃，測試各自負責的模塊和功能，這個過程可能會產生總共10來個bug，也可能產生100個以上的bug，那麼如何保證我們有效地測試了軟件，同時我們在這一步怎樣衡量構建的質量？
在MSF敏捷模式中，我們建議還是採用場景來規劃測試工作
在“基本場景”的基礎上，我們把所有系統目前理論上支持的場景都列出來，然後按功能分類測試，如果測試成功，就在此場景中標明“成功”，否則，就標明“失敗”，並且把失敗的情況用一個（或幾個）“小強”/bug來表示。
當所有的測試人員完成對場景的測試，我們自然地就得出了一個表：
場景ID 場景名 測試結果 Bug/小強id
3024 用戶登錄 成功
3026 用戶按價格排序 失敗 5032
3027 用戶按名字搜索 失敗 5033
…
… … …
這樣我們就能很快地報告“功能測試56% 通過”等等。如果所有場景都能通過，（有些情況下可以把此標準從100% 降低到90% 左右）則這個構建的質量是“可用”，意味着這一個版本可以給用戶使用。 這種情況下，客戶，合作伙伴可以得到這樣的版本 – 這也是所謂“技術預覽版”，或“社區預覽版”的由來。
但是，有一個重要的問題要大家注意“可用”，並不是指軟件都沒有bug，而是指在目前的用戶場景中，按照場景的要求進行的操作，都能得到預期的效果。
1． 目前還沒有定義的用戶場景中，程序質量如何，還未得而知。
a. 場景中沒有考慮到多種語言設置
2． 不按照場景的要求進行的操作，結果如何，還未得而知。
a. 如：在某一場景中，場景規定用戶可以在最後付款前取消操作，回到上一步，如果一個測試人員發現在反覆 提交/取消同一訪問多次，然後網頁出現問題，這並不能說明用戶場景失敗，當然這個極端的bug也必須找出原因並在適當的時間改正。
這種測試有時也被稱爲“acceptance test”, 因爲如果構建通過了這樣的測試，這一個構建就被測試團隊“接受了”。 同時，還有對系統各個方面進行的“接收”測試，如測試系統的全球化，或者針對某一語言環境做的測試。
1.7
Ad hoc Test, Exploratory Test “探索式”的測試
“Ad Hoc” 原意是指 “特定的，一次性的”。
什麼叫“特定”測試？或者“探索式”的測試？
就是爲了某一個特定目的進行的測試，就這一次，以後一般也不會重複測試。在軟件工程的實踐中，“ad hoc”大部分是指隨機進行的，探索性的測試。
比如：測試人員阿毛拿到了一個新的構建，按計劃是進行模塊A的功能測試，但是他靈機一動，想看看另一個功能B做得如何，或者想看看模塊A在某種邊界條件下會出現什麼問題，於是他就“ad hoc”一把，居然在這一功能模塊中發現了不少小強。
“ad hoc”也意味着測試是嘗試性的，“我來試試，在這個對話框中一通亂按，然後隨意改變窗口大小，看看會出什麼問題…”， 如果沒問題，那麼以後也不會再這麼做了。
一般情況下，測試人員不會花很多時間進行特定測試，但是在一些缺乏管理的團隊中，很多時候測試人員不知道自己此時應該做什麼，只好做一些看似“ad hoc” 的測試，比如隨機測試各個功能的各個方面。這些測試理論上都應該由測試管理人員規劃好屬於各個功能模塊的測試用例中。
在一個團隊中，“ad hoc”太多是一個管理不好的標誌，因爲“ad hoc”是指那些一時想到要做，但是以後也沒有計劃經常重複的測試計劃。
問：我聽說有人是“ad hoc”測試的高手，這是什麼意思？
答：有很多測試人員會按部就班地進行測試，但是還有一些人頭腦比較靈活，喜歡另闢蹊徑，測試一些一般人不會想到的場景，這些人往往會發現更多的小強。開發人員對這樣的“ad hoc”高手是又愛又恨。
問：同時看問題要分兩方面，有些“ad hoc”發現的小強在正常使用軟件中幾乎不會出現，我們要不要花時間“ad hoc”
答：現在一些成功的通用軟件的用戶以百萬計，按部就班的測試計劃很難包括很多實際的場景，這時，“ad hoc”測試能夠發現重要的問題；另外一些風險很大的領域，例如安全性，一旦出了問題，威脅就會相當大，這時要多鼓勵一些“ad hoc”測試，以彌補普通測試的不足。從這個意義上說，“ad hoc”測試可以用來衡量當前測試用例的完備性，如果你探索了半天，都沒有發現什麼在現有測試用例之外的問題，那就說明現有的測試用例是比較完備的。
“ad hoc”測試的測試流程是不可重複的，因爲它的測試都是“特定”測試，沒法重複。由於這一原因，“ad hoc”測試不能自動化，就這一點而言，還達不到CMM的第二級 – 可重複級。
作爲管理人員來說，如果太多小強是在“ad hoc”出來的，那我們就要看看測試計劃是否基於實際的場景，開發人員的代碼邏輯是否完善，等等。同時，要善於把看似“ad hoc”的測試用例抽象出來，包括到以後的測試計劃中。
1.8
Regression Test迴歸測試
問：我聽說不少關於Regression Test的介紹，但是它到底是怎麼“迴歸”法？迴歸到哪裏去？我還是沒搞懂。
答：Regress的英語定義是：return to a worse or less developed state.? 是倒退，退化，退步的意思。
在軟件工程中，如果一個模塊或功能以前是正常工作的，但是在一個新的構建中出了問題，那這個模塊就出現了一個“退步”- regression, 從正常工作的穩定狀態退化到不正常工作的不穩定狀態。
在一個模塊的功能逐步完成的同時，和此功能有關的測試用例也同樣在完善中。一旦有關的測試用例通過，我們就得到此模塊的功能基準（baseline）.?
在某某版本，某某模塊的某某測試用例是通過的！
如果測試人員發現了在新的構建版本某個測試用例失敗了，這就是一個“倒退”，在新版本上運行所有已通過的測試用例以驗證沒有“退化”情況發生，這個過程就是一個“regression test”.? 如果這樣的“倒退”是由於模塊的功能發生了正常變化（由於設計變更的原因），那麼測試用例的基準就要修改，以和新的功能保持一致。
?
針對一個bug fix （拖鞋），我們也要作Regression Test，
a) 驗證新的代碼的確把缺陷改正了，
b)同時要驗證新的代碼沒有把模塊的現有功能破壞，沒有regression。
所以我不也知道“迴歸測試”是如何的“迴歸”，我們可以理解爲“迴歸到以前不正常的狀態”。
迴歸測試最好要自動化，因爲對於每一個構建都要運行所有迴歸測試，以保證儘早發現問題。
1.9
Scenario/integration/System Test? 場景/集成/系統測試
在軟件開發的一定階段，我們要對一個軟件進行全面和系統的測試，以保證軟件的各個模塊都能共同工作，在各方面都能滿足用戶的要求。這時的測試叫系統/集成測試。
問：什麼時候做系統測試？是不是越快越好？
答：原則上是當一個模塊穩定的時候，就可以把它集成到系統中，和整個系統一起進行測試，通常在軟件產品需要階段性發布的時候。
問：有一種叫Scenario Test, 是什麼意思?
答：就是以場景爲驅動的集成測試，關於“場景”，大家可以看專門的介紹。這一方法的核心思想是：當用戶使用一個軟件的時候，他/她並不會獨立使用各個模塊，而是把軟件做爲一個整體來使用的。我們在做場景測試的時候，就需要考慮在現實環境中用戶使用軟件的流程是什麼樣，然後模擬這個流程，看看軟件能不能達到用戶的需求。這樣，能使軟件符合用戶使用的實際需求。
用一個數字照片編輯軟件爲例，這個軟件的各個模塊都是獨立開發的，可是用戶有一定的典型流程，如果這個流程走得不好，哪怕某個模塊的質量再高，用戶也不會滿意。
1.把照相機的儲存卡插入電腦
2.程序會跳出窗口提示用戶導入照片
3.導入照片
4.對照片進行快速編輯
a.調整顏色
b.調整亮度，對比度
c.修改紅眼
5.把其中幾幅照片用email發送
這裏面每一步出了問題，都會影響用戶對這一產品的使用，同時這裏面各個模塊的用戶界面如果很不一致（即使是ok/cancel按鈕的次序不同），用戶使用起來也很不方便。這些問題都是在單獨模塊的測試中不容易發現的。
1.10
Performance Test 效能測試
用戶使用軟件，不光是希望軟件能夠提供一定的服務，而且還要求服務的質量要達到一定的水平，軟件的效能， 是這些“非功能需求”，或者說“服務質量需求”的一部分。
效能測試要驗證的問題是：
軟件在設計負載內能夠提供令用戶滿意的服務質量。
1．在設計負載內 – 我們要定義什麼是正常的設計負載
2．令用戶滿意的服務質量 – 我們要定義什麼樣的質量是令用戶滿意的
設計負載 – 從需求說明出發，得出系統的正常負載。例如，一個購物網站，客戶認爲正常負載是每分鐘20次客戶請求。
用戶滿意的質量 – 同一個購物網站，如果客戶定義滿意爲：每個用戶的請求都能在2秒鐘內返回結果。
我們可以逐步細化 –
設計負載的細化，上面我們只提到“20次客戶請求”，那這些客戶請求到底是什麼，我們可以按照請求發生的頻率來分類：
1． 用戶登錄 （10%）
2． 用戶查看某商品詳情（50%）
3． 用戶比較兩種商品（10%）
4． 用戶查看關於商品的反饋（20%）
5． 用戶購買商品（5%）
6． 所有其他請求（5%）
服務質量的細化 – 有些請求，是要對數據作“寫”操作，可以要求慢一些，比如“用戶購買商品”，這一服務質量請求可以放寬爲3秒鐘。
除了用戶體驗到的“2秒鐘頁面刷新”目標外，效能測試還要測試軟件內部各模塊的效能，這要求軟件的模塊能報告自身的各種效能指標，通過perfmon? 或其它測試工具表現出來。
和別的測試不同，效能測試對硬件要有固定的要求，而且最要每次測試在相同的機器和網絡環境中進行，這樣才能避免外部隨機因素的干擾，得到精準的效能數據。
同時，效能測試的結果應該成爲“發佈指南”的一部份，給客戶發佈和改進系統提供參考。
在VSTS中如何進行效能測試在以後會詳細講解。
1.11
Stress Test壓力測試
壓力測試嚴格地說不屬於效能測試。壓力測試要驗證的問題是：
軟件在超過設計負載的情況在仍能夠返回正常結果，而沒有產生嚴重的副作用或崩潰。
問：爲啥不要求軟件在這種情況下仍然在2-3秒鐘內返回結果？
答：因爲我們做不到。
注意，我們在這一部分要求“正常結果”，啥叫“正常”？我們也要和客戶達成一致。比如，同一個購物網站，所有請求都能在網絡返回“超時”錯誤前返回，就可以認爲是“正常”。 或者網站返回“系統忙，請稍候”，也是正常結果。但是，如果用戶提交的請求一部分執行，另一部分沒有執行；或者用戶信息丟失，這些都是不正常的結果，應該避免。
那我們怎麼增加負載？對於網絡服務軟件來說，主要有下面兩個方面：
1． 沿着用戶軸延長
我們用剛纔的購物網站爲例，正常的負載是20請求/分鐘，如果有更多的用戶登錄，怎麼辦？那麼負載就會變成30，40， 100請求/分鐘，或更高
2． 沿着時間軸延長
做過網絡服務的同事都知道，網絡的負載有時間性，負載壓力波峯和波谷相差很大，那麼如果每時每刻負載都處於峯值，程序會不會垮掉？這就是我們要作的第二點，沿着時間軸延長。
與此同時，我們可以減少系統可用的資源，來增加壓力。
注意，壓力測試的重點是驗證程序不崩潰或產生副作用。在超負載的情況下，我們的程序仍然能夠正確地運行，而不會死機。在給程序加壓的過程中，程序中的很多“小”問題就會被放大，暴露出來。 最
常見的問題是
內存/資源泄露，在壓力下這會導致程序可用的資源枯竭，最後崩潰。
一些平時認爲“足夠大/足夠好”的算法實現會出現問題。
進程/線程的同步死鎖問題，在壓力下一些小概率事件會發生，看似完備的程序邏輯也出現了問題。
在VSTS中如何進行壓力測試在以後章節中會詳細講解。
1.12
Alpha Test, Beta Test
在開發軟件的過程中，開發團隊希望讓用戶直接接觸到最新版本的軟件，以便從用戶那裏收集反饋，這時開發團隊會在開發過程中讓特定的用戶（alpha/beta用戶）使用正處於開發過程中的版本，用戶會用特定的反饋渠道（email, BBS）與開發者討論使用中發現的問題，等等。這種做法成功地讓廣大用戶心甘情願地替開發團隊測試產品並提出反饋。最近有些開發團隊增加了反饋的密度，不必再等到Alpha或者Beta發佈，而是不斷地把一些中間版本發佈出去以收集反饋，美其名曰“技術預覽版本”或“社區預覽版本”。
1.13
Usability Test可用性測試
小燕問：作爲測試人員，我們是不是也要作可用性測試?
答：測試人員，以及其他的團隊成員都可以對軟件的可用性提出意見，包括用bug的形式放在在TFS中。軟件的可用性不神祕，就是讓軟件更好用，讓用戶更有效地完成工作。
但是我覺得“可用性測試”似乎更多地用來描述一套測試軟件可用性的過程，這個過程一般不是由測試人員來主導的，而是有對軟件設計及可用性有很多研究的“可用性設計師”來實行。網絡上有許多關於這方面的文章，大家可以參考。
1.14
Bug Bash
問：我們已經講得太多的測試了，好像微軟還有一個叫“bug bash”的活動，是啥意思？
答：簡而言之，就是大家一起來找小強的活動 – 小強大掃除。一般是安排出一段時間（一天），所有測試人員（有時也加入其他角色）放下手裏的事情，專心找某種類型的小強。然後結束時，統計並獎勵找得最多的，和最厲害的小強的員工。這種活動，如果運用得好，有下面的作用：
鼓勵大家做探索試的測試，開闊思路。
鼓勵測試隊伍學習並應用新的測試方法，例如在做完“軟件安全性測試”培訓後，立馬做一個針對“安全性”的小強大掃除.
找到很多小強，讓開發人員忙一陣子
當然，小強大掃除也有一些副作用：
擾亂正常的測試工作
如果過分重視獎勵，會導致一些數量至上，濫竽充數的做法。
兩個細節是：
1．一定要讓“小強大掃除”有明確的目標，明瞭的技術支持。
2．一定要讓表現突出的人介紹經驗，讓別人學習。
要記住，最好的測試，是能夠防止小強的出現。
2總結和思考
2.1十八般兵器
阿毛：超總, 我的腦袋好像裝不下了!? 聽了這麼多，我感覺像是身上扛着十八般兵器，累得半死，但是不知道什麼時候，對哪一種敵人用哪一種兵器，能不能總結一下!
阿超：好，我們用軟件開發的生命週期來說明一下不同的測試在不同階段的使用：
遠景和計劃階段：
測試只是處於計劃階段，同時要收集用戶對於軟件非功能性的需求，如效能，可用性，國際化等。一些“小強大掃除”的類型也可以在這個時候初步安排。
開發階段：
開發人員要寫單元測試， 測試人員要寫BVT。
對於每一個成功的構建，測試人員要運行功能測試/場景測試，同時建立迴歸測試基準以便開始迴歸測試。各類測試人員要進行探索式測試。
隨着軟件功能的逐步完善，測試人員要進行集成測試。這時，團隊可以開展對程序非功能性特性的測試，如效能/壓力測試，國際化/本地化測試，安全性測試，可用性，適用性測試等。在這個時候，可以考慮分析各個模塊的代碼覆蓋率，以增加測試的有效性。根據計劃，各種類型的“小強大掃除”會以適當的頻率發生。
穩定階段：
到了一個開發階段的尾聲，這時測試團隊就可以依據以前制定的驗收標準，對軟件逐項進行驗收測試。按照測試計劃，各個方面的測試都會宣佈“測試完成”- 所有想到的測試都做了，所有問題都發現了。在此階段，團隊也可以把軟件發佈給外部進行alpha/beta測試。
一般情況下，測試隊伍要把迄今爲止發現的所有小強都從新試一次，確保它們都在最後的版本中被清除了，沒有一個“迴歸”出現。
發佈階段：
測試隊伍要把儘可能多的測試用例自動化，併爲下一個版本的測試工作做好準備。
2.2
構建的質量
1．編譯失敗
2．可測/不可測
3．可用/不可用
2.3
問題
2.3.1
如果連續幾天都不能產生“可測”版本，怎麼辦？
提示：可以在下一個構建版本中限制簽入的數量，只接受那些高等級的修改，在一般的做法中，導致“不可測”的小強的嚴重性是1，必須在下一個構建開始的時候得到改正。
