設計測試用例的過程中，同時需要關注的是測試數據的產生和維護。
在上一個測試用例的例子中，“特定告警的詳細內容”就是一個被選擇的測試數據，如何選擇具體的測試數據需要根據測試的具體需求而定，沒有統一的法則。但在設計測試用例時，一定要明確每個用例的數據需求并將這種需求綜合起來，并形成對測試環境的測試數據的維護策略，以便在測試用例執行時能順利進行。
一般而言，我們可以考慮初始測試數據的需求、考慮測試用例之間的依賴關系、記錄每個用例對數據的要求，然后最終確定需要哪些測試數據和如何維護測試數據。
4. 測試環境與測試工具
制定了合理的測試計劃、設計了滿足需要的測試用例之后，我們就可以開始著手準備測試環境和考慮如何在測試中運用測試工具了。
4.1. 測試環境
測試環境的部署和維護是一件需要詳細策劃的事情，部署了合理的測試環境是測試達到目標效果的前提條件。一般來說，在考慮部署和維護測試環境時，需要考慮以下內容：
測試網絡環境
性能測試一般都是在一個網絡中進行，可能是一個單獨的局域網，也可能是和生產環境相同的網絡，不管實際的情況如何，我們都必須評估網絡狀況是否會對我們的測試產生影響，也就是說，要保證網絡環境能夠較好地模擬實際網絡環境（包括網絡狀況、負載等）。當然，在我們的本次測試中，由于網絡狀況對我們的測試結果沒有什么影響，我們的測試是在一個接近生產環境的100M局域網中進行。
初始數據的準備
在執行測試之前，我們需要準備足夠支撐測試進行的初始數據，對本測試來說，初始數據包括靜態數據、程序運行時必須的配置數據、配置文件、用戶帳號信息等，建議將這部分數據按照不同的數據來源分別列出形成CheckList，這樣可以避免在測試過程中出現數據準備不充分的情況。
本測試中我使用的CheckList示例如表1所示：
表1 本測試中使用的測試環境CheckList
序號測試環境項目來源責任人預計完成時間是否已部署 1 數據庫靜態數據配置項 XXXX XXXXXXX 是 2 數據庫中的網元配置數據測試用例 XXXX XXXXXXX 是 3 WEB用戶信息測試用例 XXXX XXXXXXX 是 4 Unix用戶帳號信息配置項 XXXX XXXXXXX 否 5 模擬發送的話務數據測試用例 XXXX XXXXXXX 否 ……
…… …… …… …… …… 10 網元話務報告發送模擬程序測試用例 XXXX XXXXXXX 是 …… …… …… …… …… ……
除了測試環境CheckList外，還需要準備一份更詳細的文檔，詳細記錄每一個環境項目的實際數據，這樣的一份文檔一方面可以便于對數據的審查；另一方面，在測試過程中即使人員發生變動，新參與的成員也能很快熟悉整個測試環境。
測試數據的可恢復性
說到測試數據，就不能不提測試數據的可恢復性。在一次測試過程中，一個用例一般都需要被多次執行，但在多次執行同一個用例時，就必須保證每次執行用例時的環境一致，因此在準備好數據，執行用例之前，必須要計劃好測試完成后怎樣將整個測試環境中的數據恢復，在本次測試中，我們采用的是為每個測試準備一個“回滾”腳本，該腳本用來恢復數據至測試用例執行之前。
測試環境的時間同步
在性能測試中，尤其需要注意的是測試環境的時間同步問題。性能測試關注的是系統的總體性能表現，這些性能表現又需要通過各個模塊的響應時間來體現，在本次測試中，我們在應用程序中增加了部分測試代碼，測試代碼通過記錄關鍵操作的時間來完成性能指標的記錄。
基于以上的要求，整個測試環境中各臺計算機的時間同步就非常重要了，如果時間不同步的話，就會造成測試結果的不準確，尤其在本次測試中，部分測試指標要求到秒級，因此，我們必須要對整個環境進行一個精確的時間同步。
本測試的測試環境包括7臺HP小型機、兩臺WEB服務器、一臺Windows域服務器和15臺加入域的PC機，在時間同步方案上，我們以一臺小型機為主時間服務器，采用Windows域服務器作為Windows機器的時間服務器（域內的客戶機可以實現與域服務器的自動的時間同步），利用NTP協議在Unix主機和Windows域服務器之間進行時間同步，之所以采用NTP協議，主要是因為NTP是在Internet和Unix系統上被廣泛采用的協議，在Windows平臺上，也有基于NTP協議的開源軟件（NetTime）可以使用。
4.2. 測試工具
測試工具的評估和選擇是測試開始之前必須進行的工作。在機械工業出版社出版的《軟件測試自動化－引入，實施和管理》書中對測試工具的評估選擇、應用有詳細的描述，個人覺得這本書對于測試工具應用部分的說明非常不錯，強烈推薦這本書給對這部分感興趣的朋友。
本測試沒有使用商業測試軟件，主要原因在于以下幾點：
1、 測試時間資源：本測試安排的時間比較緊迫，沒有足夠的時間用商業測試工具進行錄制腳本、腳本調試維護等一系列的工作；
2、 測試工具的學習曲線：商業測試工具的應用需要一個學習曲線，整個測試團隊中只有一名成員具有足夠的技能，這是限制商業測試工具應用的極大障礙；
3、 費用：商業測試工具的授權費用是不能不考慮的，在我們這樣一個項目中（客戶端數量較大），商業測試工具的授權費很高，在合同中沒有包含這部分費用的情況下，由項目自身承擔這部分費用，顯然是不可能的；
4、 靈活性：測試實施過程中可能需要修改測試腳本，考慮到1、2的原因，可能通過Perl等腳本語言編寫的腳本更能滿足靈活性的要求。
最終在本項目中，我們采用了自行開發的測試適用本項目的測試工具，這些測試工具中的部分具有可重用性，部分是本項目專用的測試工具，實現測試工具的最終投入為2.4人月，其中可被重用的工具投入為1.4人月，不能重用的測試工具開發投入為1人月，從測試效果來說，這個投入是絕對值得的。
關于本測試中使用的自行開發的測試工具在本文中不準備進行詳細描述，需要說明的內容包括如下幾點：
1、 測試工具的需求需要根據測試需求來確定：在本項目中，主要是通過測試用例來確定，根據用例描述的場景確定需要的測試工具。例如，在本文的上篇中作為例子的測試用例，從該用例的“已通過模擬程序產生每秒300條告警的告警數據”描述中，我們可以明確需要一個能產生每秒300條告警數據的模擬程序，從“所有告警產生和呈現時間記錄在本地日志文件中”描述，我們可以明確該模擬程序還必須能夠記錄告警產生時間。當然，對測試工具的需求確定還必須結合其他用戶的需求。在本測試中，與該用例相關的測試工具被實現為一個可以根據用戶給定的文本文件發送告警數據的工具，通過參數可以指定工具發送告警的間隔以及是采用隨機還是定時的方式發送；
2、 測試工具的實現語言需要根據實際情況確定：測試工具的實現語言主要看項目成員對語言的熟悉程度以及是否需要在測試過程中修改測試工具。如果預計到在測試中需要修改測試工具，建議采用腳本語言來實現測試工具，例如在該測試中，我們的部分測試工具是采用C++語言實現的，部分測試工具是采用Perl實現的；
3、 測試工具本身也是配置項的一部分：測試工具也需要納入配置管理的范圍，一方面，測試工具的發布和更新必須按照項目的配置管理流程實現；另一方面，測試工具的開發過程必須符合項目的開發過程。為避免測試工具在使用中帶來混亂，這一點是必須要注意的；
4、 測試工具的開發需要從實際角度出發：千萬不要嘗試在一個項目中開發出一個強大和完善的測試工具，測試工具的開發要從實際出發，能滿足實際測試需求的測試工具就是好的測試工具。如果真的覺得有需要對測試工具進一步完善以利于重用，那也請在項目完成后再專門作為一個項目來專門完善測試相關的測試工具。
我們在把測試工具和測試環境同時包含在這一章中，最主要的原因是因為部署后的測試工具也屬于測試環境的一部分，測試工具的部署和維護也是測試環境部署和維護的一部分。
上面已經提到，測試工具本身也是配置項的一部分，測試工具的發布需要按照項目的配置管理流程實現，因此，對測試工具在測試環境上的部署需要按照配置管理流程來管理，同時，這也是測試環境部署和維護的一部分。在本測試中，要求測試工具來源于配置項的發布版本，對測試工具的變更需要進行記錄并納入配置項變更管理，唯一不同的是這個配置項的變更的發起人是測試工程師，審核人是測試負責人。
5. 測試實施
測試計劃、測試用例、測試環境都完成之后，就可以開始對測試進行實施了。測試實施在整個測試過程中并不是消耗資源最多的，有了詳細的測試用例之后，其實測試實施是一件“照葫蘆畫瓢”的簡單工作。
本章主要探討性能測試實施過程中需要記錄的信息（這部分內容其實應該是在測試計劃和測試用例中確定，但為了整個描述的連貫性，我把這部分內容安排在本章）。
本測試實施記錄的內容包括如下：
Unix主機
CPU使用率；
內存使用狀況；
Disk I/O；
數據庫服務器
Cache命中
Long Transaction
索引使用情況
數據庫進程CPU使用狀況
數據庫內存使用狀況
數據庫連接數量
應用服務器
MQ的主要進程內存使用狀況
MQ的進程數量
TEMIP主要進程內存使用狀況
WEB服務器
進程的CPU和內存使用狀況
Cache命中
平均響應時間等
對這些內容的記錄需要通過操作系統提供的性能觀測工具或是應用自身提供的性能觀測工具：
1、 在Unix環境中，可以用top、vmstat、iostat程序觀察需要記錄的內容，更好的方法是自己寫一個簡單腳本，把時間信息和輸出信息一同存入本地日志文件。在本測試中，我們用Perl和Unix的Shell腳本實現了對輸出信息的抽取和格式化，生成的記錄文件可以方便地被Excel等程序進行處理；
2、 對于數據庫環境，可以用Oracle自帶的性能監測工具或是第三方軟件（如TOAD等）觀察性能并存成文件；
3、 對WEB服務器，可以用WEB Server自帶的性能監測工具監測其性能。
6. 測試結果分析與測試報告
通過測試實施取得了數據之后，最后一步就是對測試結果進行分析了。對測試結果進行分析我個人認為是比較需要經驗的一個步驟。要對結果進行分析，首先需要非常明確獲取的每個數據的意義，然后根據數據測試目標，對數據進行詳盡分析，分析的目的是用數據說明測試目標。
本項目中使用的測試結果分析工具包括Excel、UltraEdit、vi和數據庫查詢工具等，vi和UltraEdit用來編輯測試過程中形成的記錄了測試結果的文本文件，數據庫查詢工具用來從數據庫中獲取測試結果，Excel用來對初步處理后的測試結果進行分析，Excel工具能導入具有一定格式的文本文件，并能根據數據生成各種統計圖形，在本測試中是主要的測試數據分析工具。當然，某些特殊的測試結果可能需要自行開發部分工具進行數據提取和處理。
測試報告至少應該包括以下幾部分的內容：
1、 測試環境描述；
2、 測試準備工作描述：在這部分中需要詳細說明測試方案，因為測試報告是要與用戶討論，經用戶簽字認可的，因此，在報告中詳細列出測試前的準備工作，包括測試方案、測試數據準備以及測試中記錄的數據、測試工具和腳本部署等，個人的感覺是這部分具體根據用戶的要求吧，在本測試中，用戶要求我們寫的非常詳細；
3、 測試范圍及內容：對本次測試能覆蓋的范圍進行說明；特別是要說明不包括在本次測試中的內容，以防以后有人說出“不是測試過了嗎？怎么還有XXXX問題”這樣的話：）
4、 測試結論：測試結論這部分需要詳細說明本測試的結論，包括測試用例執行情況統計、測試是否通過、測試中發現問題的處理方式和方法；
除此之外，還可以在測試報告中包括建議與計劃，用來說明該測試的后續工作安排和計劃；將測試用例的執行情況和每輪測試執行的詳細記錄作為附件附加到測試報告中。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
