壓力測試專家可能會辯論說測試腳本開發這種層次的詳述僅僅是一項額外的工作，并不會增加項目的價值。如果我們的目標是進行壓力測試的話，我會認同這種說法。在本系列的第一章中，壓力測試定義為“在不包括用戶延遲的高用戶負載下，各種腳本的組合測試，但對確定用戶體驗并不合適”�；仡櫟谝徽�，本系列專注于外部用戶的性能體驗與客戶滿意度之間的聯系。作為負載測試的一部分，確定用戶體驗的關鍵是模擬個別用戶的行為模式，而壓力測試并不需要關注這些。（請閱讀《網站壓力測試》（Website Stress-Testing），該書對兩者的區別做了明確的說明）。下文將論述如何將這些個別用戶模式應用到用戶組（群）中。
本系列的第二章論述了如何模擬個別用戶延遲，類似的，本文將同樣的基于在Noblestar多年的測試經驗并以TestStudio進行示范。本文適用于TestStudio所有等級的用戶，但更適用于中高級用戶。我建議你將本文提到的觀點應用到一個你清楚其用戶負載、用戶模式和用戶體驗度量的網站上進行有效性驗證，將用戶體驗結果與實際結果進行比較。
1.確定用戶模式為了準確地收集到用戶體驗度量，你必須在適當的時間，將適當的壓力應用到系統適當的部分上。這聽起來好像很復雜，但實際并非如此。你可以從確定個別的用戶模式開始。我會介紹一些不同的方法，并以在線書店為例說明如何確定用戶模式。
假設你是書店的經營者，希望從性能視角來了解用戶在網站上購書的情況。首先需要回答一個問題：有一個回頭客（return user）登錄網站后想買一個最新的暢銷書New York Times，他需要通過哪些頁面來完成？我們可以得到如圖1的購書路線圖（如何生成這個圖將在下文詳細論述）。
圖1 購買小說的主要路線圖上圖的例子中，所有用戶從首頁開始，通過三種方式其中的一種來進行：
搜索書名或作者 到小說分類中慢慢查找 直接在暢銷書閃爍的鏈接中找到它每種路徑的用戶比例上圖已經標示出來了，所有用戶都買了書。這是一個非常簡單的例子，但這些概念可以很容易地應用到復雜的情況。注意，上圖每條路徑確定了一種活動，但并未包括活動的具體步驟或訪問的頁面。
上圖的實現方法對你的測試目的來說也許已經足夠準確，但也許不夠。方法如下：在為此模型選擇了購書網站作為例子后，我認為最通常的用戶活動就是買書了。接著訪問這個網站，找出買書的所有可能的路徑，以一個網站用戶或測試者的身份，通過自己的經驗和直覺，評估自己訪問每條路徑的可能性。最后完成了上面的圖形。
運用你的直覺和最佳猜測的方法，有兩方面的好處：（1）在用科學的方法識別用戶模式之前，已經對網站有了一個直觀的感受；（2）以此來驗證用更科學的方法獲得的用戶模式，也很有意義。由于我無法獲取到更科學的信息（例如日志文件，流量監控軟件，系統設計文檔，系統管理權限等等），所以我只能到此為止，但你可以做得更好。
如果你正在進行一個真實的測試，那么可以用以下的任一種方法來測定用戶模式：
如果測試的是一個已發布的網站，那么可以通過流量監控軟件（如WebTrends、LiveStats）的統計信息來測定實際的數據和分布情況。這些軟件在正確配置之后，能夠以易于理解的圖表方式告訴你每種用戶活動的比例和行為路徑。如果沒有流量監控軟件的話，也可以通過日志文件中的頁面點擊信息來測定用戶活動分布。第四章將會對此進行更詳細的論述。 如果有網站技術規格說明書的話，它會告訴你用戶最可能進行哪些活動，以及用戶期望在哪些導航路徑的指引下進行操作。有時功能測試腳本或測試用例也有助于用戶活動和路徑的確定。這些資料不會直接告訴你實際上用戶是如何瀏覽網站的，但你能夠間接地知道系統是如何與用戶進行交互的。 如果測試的網站是新開發的從來沒有發布過，那么你可以嘗試著從相似網站的管理員處收集到用戶使用模式的信息。當然，這類網站通常最有可能的就是你們的競爭對手，因此它們的管理員可能并不會那么合作。 如果以上三種方法都行不通的話，你可以進行簡單的內部實驗，通過員工、客戶、朋友或家庭成員的幫助來測定不同用戶是如何瀏覽網站的。如我在第二章提到的，對于從沒有發布過的網站來說，我發現這是一種非常高效的數據收集方法，同時也是驗證使用其它方法收集到的數據的一種有效途徑。
110593_200903180940061oQv8
文章來源于領測軟件測試網 http://www.kjueaiud.com/