[來自 移山之道 第 13 章]

13.8? 測試計劃

測試不是在所有的開發工作完成之后才進行，而是與開發幾乎同步進行的。一個軟件項目的各個功能都可以有自己的測試計劃，它們可以在不同的階段發揮作用。但是針對整個項目的總測試計劃（又叫測試總綱）要在計劃階段大致定下來，并指導所有測試工作的進行。

那測試總綱到底講什么呢？

測試計劃描述了一次測試活動的主要方面：為什么（Why），測試什么（What），誰來測試（Who）和什么時候測試（When），詳細地說，包括以下方面：

（1）測試的總體策略和方法。

（2）測試日程安排：何時開始什么樣的測試。

（3）質量目標：測試要達到什么樣的目標才能算通過——這個目標也決定了“驗收測試”的標準。

（4）資源：需要多少人力、物力來達到質量目標。

（5）測試變量矩陣：我們的系統需要支持多少種操作系統、瀏覽器，以及其他影響功能的變量？

關于這一點，阿亨有一天晚上和大牛在頂球酒吧暢談理想，講到激動處，夜不能寐，勾畫了這樣的測試矩陣（見表13-4）。

阿亨把這個計劃拿給大家討論，大家在驚嘆之余，紛紛懷疑我們是否有能力完成這么多種類型的測試。畢竟是184 320種組合！這時候，阿超建議大家看看團隊的遠景和各種情況所占實際用戶的比率，來決定我們真正需要支持的測試矩陣是什么。

經過分析和討論，大家逐條精簡，結果如下：

a. 用戶類型不變。

b. 屏幕分辨率降到兩種，手機屏幕不要了，我們暫時不在手機上測試。

c. 屏幕DPI不測試高級DPI（屏幕 | 屬性 | 高級 | DPI 中可以設置DPI以提高顯示效果）。

d. 操作系統只測試3種，二柱強烈支持Linux，同時考慮到一些高收入的網民可能會用Linux操作系統，保留Linux。

e. 操作系統的語言只支持3種，這并不是網站內容的語言，而是操作系統的默認語言。

f. 網絡速度3種，無線網絡的速度介于撥號與ADSL之間，可以忽略。

g. 瀏覽器的版本，經過激烈的討論，瀏覽器從5種變為3種。

總計648種組合，如表13-5所示。

?

?

表13-4? 宏偉的測試矩陣

?	用戶 類型	屏幕 分辨率	屏幕DPI	操作系統	操作系統 默認語言	網絡速度	瀏覽器	Flash	JavaScript	Cookie	組合 總數
變量 數目	4	4	2	6	6	4	5	2	2	2	184320
?	商戶	800像素×600像素	正常	WindowME	中文（簡體）	撥號	IE6	支持	支持	支持	?
?	用戶	1024像素×768像素	高級DPI	WinXP	中文（繁體）	ADSL	IE7[1]	不支持	不支持	不支持	?
?	瀏覽者	1280像素×1024像素	?	WinVista	英語	局域網	Opera	?	?	?	?
?	管理員	手機屏幕	?	Win Server 2003	日語	無線網絡	Safari	?	?	?	?
?	?	?	?	Linux/Unix	阿拉伯語	?	Firefox	?	?	?	?
?	?	?	?	Mac	西班牙語	?	?	?	?	?	?

?

表13-5? 精簡后的測試矩陣

?	用戶 類型	屏幕 分辨率	操作系統	操作系統 默認語言	網絡速度	瀏覽器	組合 總數
變量數目	4	2	3	3	3	3	648
?	商戶	800像素×600像素	WinXP	中文（簡體）	撥號	IE6	?
?	用戶	1024像素×768像素	WinVista	中文（繁體）	ADSL	IE7	?
?	瀏覽者	?	Linux/Unix	英語	局域網	Firefox	?
?	管理員	?	?	?	?	?	?

有了這樣的測試矩陣，測試人員在設計與執行測試的時候就能夠按照矩陣進行全面的測試。同時要指出的是，不同組合的重要性是不一樣的，我們最主要的測試環境還是：用戶 + 1204像素×768像素 + WinXP + 中文 + ADSL + IE6。必須先保證網站在主要的測試環境下能正常運行。

---

[1] 這個表還沒有考慮IE8/9。

[來自 移山之道 第 15 章]

15.2? 測試的文檔

九條：測試工作是不是有很多文檔要寫？

阿亨：各類人員都有文檔要寫，但是在敏捷模式中，我們要堅決避免為了寫文檔而寫文檔。要寫真正有用的、重要的文檔，如下所示：

在計劃階段，我們就要制定測試計劃（Test Plan），特別是測試總綱。然后還要寫測試設計規格說明書（TDS）、測試用例（Test Case）、程序錯誤報告（Bug Report）和測試報告（Test Report）。它們之間的關系如圖15-1所示。

?

?
?

?

?

?

?

?

?

?

?

圖15-1? 測試工作中的文檔

?

測試計劃和測試總綱主要說明產品是什么，要做什么樣的測試，時間安排如何，誰負責什么方面，各種資源在哪里，等等。這些在第14章已經講過。

我們不是為了寫文檔而寫文檔，寫文檔的目的是要解決問題。到底這些文檔會解決什么問題呢？

?

?

15.3? 測試設計說明書（TDS）

正如開發人員有功能設計說明書，測試人員也要有設計測試說明書。這就是告訴測試人員要如何設計測試。

阿毛：我們在哪里可以找到模板？有了模板就好辦了。

阿亨：我們不要一味地依賴于模板，不要被模板淹沒了。

對于一個功能，或者相關聯的一組功能，TDS主要要描述這些重要的內容：

（1）功能是什么。

（2）要測試哪些方面？有沒有預期的Bug比較多的地方（對于測試矩陣有沒有要修改的地方）？

（3）如何去測試（什么具體方法，如何做測試自動化，準備什么樣的測試數據等）？

（4）功能如何與系統集成，如何測試這一方面？

（5）什么才叫測試好了（Exit Criteria）？

阿毛：有些功能還沒有寫好，我怎么能知道這些功能的具體情況?

阿亨：TDS應該在功能實現之前，就要根據功能的spec寫好，并通過同事的復審[1]。

?

15.4? 測試用例（Test Case）

有了TDS，我們就可以按照TDS 的描述，對每一個功能點進行具體的測試了。具體地說，測試用例描述了如何設置測試前的環境，如何操作，預期的結果是什么。一個功能的所有測試用例合稱為這個功能的測試用例集（TEST Suite）。

九條：對于一個功能，用戶可能的輸入千差萬別，我是不是得寫成千上萬個測試用例？

阿亨：沒必要，我們可以把紛繁的情況歸類到幾個類型中。例如，用戶登錄時的情況，我們可以將其歸為以下幾類：

（1）正確輸入（用戶輸入了合法并正確的用戶名和密碼），預期結果是用戶能夠正常登錄。

a. 用戶名又有多種情況（數字、字母、中文）。

b. 用戶登錄“記得我的賬戶和密碼（remember me）”功能可以正常使用。

c. 用戶的密碼是否隱式顯示，轉送。

（2）錯誤輸入，預期結果是系統能給出相應的提示。

a. 用戶名不存在；

b. 用戶名含有不符合規定的字符（控制字符、腳本語句等）；

c. 用戶名存在，但密碼錯誤（具體測試時、可以輸入空、超長字符串、大小寫錯誤等）。

15.5? 錯誤報告（Bug Report）

在測試中，如果發現問題，我們就得報告，在移山過程模型中，“Bug”是第二個工作項類型。在這一階段，我們就主要用Bug進行交流。

在以前的“二人合作”一章中，有些團隊成員已經互相找過Bug，但是當時項目相對簡單，對Bug的格式并未做嚴格要求。在一定規模的軟件項目中，我們要求一個好的錯誤報告要能做到：

（1）Bug的標題，要簡明地說明問題。

（2）Bug 的內容要寫在Description中，包括

a. 測試的環境和準備工作；

b. 測試的步驟，清楚地列出每一步做了什么；

c. 實際發生的結果；

d. （根據spec和用戶的期望）應該發生的結果。

（3）如果需要其他補充材料，例如相關聯的Bug、輸出文件、日志文件、調用堆棧的列表、截屏等，都要保存在Bug 相應的附件或鏈接中。

（4）還可以設置Bug 的嚴重程度（Severity）、功能區域等，這些都可在不同的字段中記錄。

下面是九條創建的一個Bug：

標題：掛了

內容：我今天在玩移山購物網的時候，發現移山網站掛了。

這個Bug的問題在于對問題的描述不明確，讓開發人員無從下手。小飛拿到這個Bug，也是哭笑不得，試了試移山的各個頁面，好像也都正常。他于是把這個Bug又推給九條，“哪里掛了？”

過了一會兒，九條回復“在我的機器上是掛了”。

小飛跑到九條的座位上，想看看“犯罪現場”。

九條：我剛把機器重啟動……

兩人等到啟動完畢，打開網頁，發現一切正常。

九條：（納悶了）昨天晚上的確是掛了。網頁上還有一些錯誤信息。我當時正在干什么來著，好像是在留言或在論壇上發帖子，我現在也記不清了。讓我再玩玩，等碰到了再叫你。

阿亨：這樣九條浪費了兩個人各一個小時的時間。最后什么進展也沒有。一個好的Bug應該是這樣的：

?

標題：購物網站的某個具體頁面（URL），在回復中如果提交大于100KB的文字的時候出錯。

內容有以下幾點：

環境：在Windows XP下，使用IE7。允許Cookie。購物網的版本是1.2.40。

重現步驟：

（1）用[用戶名，密碼] 登錄。這一用戶在系統中是一般用戶。

（2）到某一產品頁面（鏈接為：……）。

（3）選中一個帖子，例如：帖子號為579。

（4）回復帖子，在內容中粘貼100KB的文字內容（文本內容見附件）。

結果：

網站出錯，錯誤信息為：[略]

預期結果：

網站能完成操作，或者提示用戶文本內容過大。

[在附件中加入100KB的文本文件]。

測試人員還可以附上其他分析，應該鼓勵測試人員追根溯源。

如果看到這樣的報告，那么開發人員就能夠很快地重現這一問題，從而有效地分析和解決問題。

15.6? 測試修復，關閉缺陷報告

當開發人員修復了一個缺陷并簽入代碼后，一個新的構建就會包含這一個修復（Bug fix）。測試人員所要做的就是驗證修復，并且搜尋有無類似的缺陷，驗證修復有沒有導致其他的問題（回歸，regression），了解修復的影響（是對一個簡單的顯示文字的修改，還是內部算法的改變），并且檢查系統的一致性是否受影響（例如：修改了默認的/是/否/取消/選擇次序，要檢查整個產品中其他的對話框是否遵循同一模式）。

在完成了測試之后，測試人員可以關閉缺陷報告，同時在“歷史（History）”這一欄內說明是如何做的驗證。

當測試人員驗證了一個Bug被正確修復了之后，還要考慮是否把這一個Bug變成一個測試用例，這樣可以保證以后的測試活動會包括這個Bug描述的情況。這是一個很重要的步驟。

15.7? 測試報告（Test Report）

在一個階段的測試結束后，我們要報告各個功能測試的結果，這就是測試報告。移山公司不喜歡過多的文檔，我們就不必寫洋洋萬言的報告了，只需簡單地列出一些數字即可，如：

對于某一功能，我們要收集下列數據：

（1）多少測試用例通過？

（2）多少測試用例失敗？

（3）多少測試用例未完成？

（4）多少在測試用例之外的Bug被發現？

所有功能的測試報告相加，我們就能得到整個項目的統計信息。這樣的信息能幫助我們從宏觀上了解還有多少事情沒辦完，各個功能相對的質量如何。

15.8? 運用測試工具

前面說了這么多理論和規定，我們看看實際工作如何進行。VSTS既然是一套軟件工具，它一定有一些幫助測試人員的工具。Visual Studio 2005/8 的眾多套件中，有一款是：Visual Studio Team Edition for Software Tester。我們在這里也簡單地介紹基本工具的使用。

15.8.1? 運用工具記錄手工測試

不管多少人，多少文章描述了“測試自動化”及其前景，這些自動化的東西最初還是得有人“手動”地進行。下面的步驟演示了如何創建手工測試。

（1）在VSTS（有Team Edition For Tester 套件）中，新建一個項目，在Visual C# 或其他類型中，選中Test。填入適當的項目名字和解決方案的名字，可以把它加入源碼控制中。我們會看到新的項目新建了不少文件（如圖15-2所示）。其中有UnitTest1.cs，我們之前已經談過。另一個文件是ManualTest1.mht。

圖15-2? 創建新的測試項目

（2）打開ManualTest1.mht，你會看到它是模板（又一個模板），在這個文件中，你可以填入下面的內容：

a. 測試的標題（Test Title）——簡明的標題。

b. 測試的詳情（Test Details）——測什么。

c. 測試的對象（Test Target）——測試什么功能。

d. 測試的步驟（Test Steps）——提供詳細的測試步驟和每一步期望的結果。

e. 修改的記錄（Revision History）——對這一測試進行修改的歷史記錄。

九條：不就是這樣一個簡單的文件么，我自己不用寫也可以記住。

阿亨：好記性不如爛筆頭，當測試矩陣有上百個可能的設置，產品又日趨復雜的時候，我們需要把一些手工測試記下來。另外，如果來了個新手接班，項目移交，怎么辦？

15.8.2? 運用工具記錄自動測試

對于網絡程序，我們可以把對網頁的訪問和操作像錄音一樣錄下，“錄音”主要是記錄HTTP請求的URL，以及header和body中的各個參數。記錄是否成功取決于服務器返回的狀態碼。當然，我們也可以自己定義pass/fail的條件。這樣以后測試的時候重新放錄音帶即可。

操作：鼠標右鍵選中測試項目，選擇 Add | Web Test（如圖15-3所示）。

圖15-3? 新增加一個 Web Test

Internet Explorer 就會打開，同時Web Test Recorder 也會激活[2]，

?

測試人員就可以按照場景測試網站的各項功能了，同時注意到Web Test Recorder 會記錄每一個網頁的地址，以及可能的參數。

測試人員可以進一步增加測試的內容（如圖15-4所示）。

圖15-4? 進一步增加Web Test 的功能

其中值得提出來的是，測試人員可以選中“Generate Code”，生成測試腳本，可以在腳本一級開發測試。測試人員可以用腳本建立循環測試，或者根據某一步測試的結果選擇不同的測試分支（path），更加靈活。另外，我們還可以用C#作為測試代碼的語言，這個比其他通用工具的腳本強大許多，這也是用VSTS做測試的好處之一。

不同的測試可以把不同的次序結合起來運行，測試人員可以用“Ordered Test”來管理這樣的測試集合。可以用和創建Web Test 類似的方法創建 Ordered Test。

15.8.3? 如何測試效能

除了功能方面的測試外，我們還要測試那些“服務質量”。如效能測試、負載測試、壓力測試。我們在第7章中講到了這三種測試的區別。在Stone 項目中，以產品搜索為例，這三種測試的區別如下：

效能測試[3]：在100個用戶的情況下，產品搜索必須在3秒鐘內返回結果。

?

負載測試：在2 000個用戶的情況下，產品搜索必須在5秒鐘內返回結果。

?

壓力測試：在高峰壓力（4 000個用戶）持續48小時的情況下，產品搜索的返回時間必須保持穩定。系統不至于崩潰。

?

?

我們可以舉一個現實生活中旅客列車的例子：

效能測試：在80%上座率的情況下，期望：列車按時到達，并且乘客享受到優質服務。乘務員不要太累。

負載測試：在100%上座率的情況下，期望：列車大部分按時到達，乘客享受到基本服務。乘務員的疲勞在可恢復范圍內。

壓力測試：在高峰壓力是200%上座率，全國鐵路系統增加20%列車，持續15天的情況下，期望：列車能到站，乘客能活著下車，系統不至于崩潰。乘務員也能活著下車。

?

效能、負載、壓力這些方面的測試會產生很多數據，這些數據最好保存在數據庫中，以便于跟蹤分析。這些數據為以后做網站容量規劃（Capacity Planning，又稱容量規劃，能力規劃）提供重要的依據。

在VSTS中，效能和壓力測試都可以用“Load Test”來實現，Load Test 牽涉到許多因素，因此我們需要按部就班地設置，如圖15-5所示。

負載測試的一個核心概念是“場景”，這和軟件設計的場景有所區別，它主要包含負載測試的各種參數：

（1）停頓時間（Think Time）：在每次請求之間和一批測試之間的停頓。

圖15-5? 創建負載測試向導

（2）負載模型（Load Pattern）：模擬的用戶量是恒定在一個數值的（如：總是30 個用戶），或者是分級進行的（如：開始是5個用戶，每分鐘增加10個用戶，直到最高50個用戶）。

（3）測試混合模型（Test Mix）：此次負載測試要運行多少種測試，每種測試所占的比例是多少。

（4）瀏覽器混合模型（Browser Mix）：各種瀏覽器的選擇及比例。

（5）網絡混合模型（Network Mix）：各種帶寬的網絡及比例。

設置場景后，下一步要決定我們收集什么樣的效能數據（Performance Counter），這時候，我們可以收集代理機器（Agent，模擬的服務請求從這里發出）和控制機器（Controller）的效能數據，更重要的是收集網絡服務器的效能數據（如圖15-6所示）[4]。

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

圖15-6? 收集效能數據

這些效能數據會反映在負載測試中。

最后一步是設置運行負載測試中的各種參數。

圖15-7是一個網絡負載測試運行的結果圖。

九條：數據太多了，我看這個表有點頭暈，比打麻將要看的數據多多了。

阿亨：的確，網絡應用的負載測試是一個復雜的領域，我們要下一番苦功把它掌握。一般把所有數據都保存到數據庫中，以便將來做分析。但是我們還是要明確測試的目標：看看網絡服務器能否在規定時間內處理用戶的請求，服務器上有沒有出現錯誤。這兩種數據都能夠馬上得到。

圖15-7? 負載測試運行結果

---

[1] TDS應該在設計階段完成，為了描述的方便，作者把大部分和測試相關的內容放到這一章。

[2]在Vista系統中，可能需要以管理員身份運行VSTT。

[3] 要注意，有些項目定義這里的“時限”是服務器處理的時間，不包括數據在網絡傳輸的時間，和客戶端瀏覽器（如：IE）顯示內容的時間，移山公司使用這樣的約定。

[4] Controller 和 Agent 要安裝VSTS 的特定組件后才能使用。

總結

以上是生活随笔為你收集整理的现代软件工程讲义 8 稳定阶段 (测试的计划和执行)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。