[翻譯]基於使用者體驗的效能測試：第一章 介紹

著作權聲明：基於分享的精神，為了有更多的測試同行能從中受益，本文可以被轉載。請在轉載時保留此著作權聲明，並保證文章的完整性，但不得用於任何商業用途或其他以盈利為目的的用途。

原文名稱：User Experience, Not Metrics
原文作者：Scott Barber
原文出處：http://www.perftestplus.com/resources/UENM1.pdf

譯文名稱：基於使用者體驗的效能測試
翻譯：pent
譯文地址：http://www.cnblogs.com/pent/archive/2007/07/01/802096.html 

 

第一章 介紹

隨著越來越多的人依託互連網從事日常業務操作，應用程式的效能在成功的電子商務解決方案中變得至關重要。為了確保成功，很多公司開發了工具和方法來測試和調整應用程式的效能。但這些工具和方法基本上都是關注在系統度量上的最佳化，而非使用者體驗。《User Experience, Not Metrics》系列文章將對如何確定真正的使用者體驗，以及使用Rational Suite TestStudio測試載入器，以一套行之有效方法對應用程式效能調優的相關方面進行討論，側重於終端使用者的效能體驗上。在本簡介中，旨在對整個系列文章中的相關概念和術語進行介紹。

1.       簡介

有多少次因為網頁速度太慢，你被迫終止了該任務並選擇了其它網站？大約有46％的消費者會因為網站過於技術化或者效能問題而選擇了離開。換言之，如果你的網站速度太慢客戶就會離去，這是所有的互連網使用者都熟知的道理。這時你的第一想法不是“哎呀，不知道網站的輸送量怎樣”，而是“簡直太慢了!我可沒有時間在這裡等，到別處去吧”。現在想想，人們離開你的網站是否因為效能問題？

基於此，使用者不會在乎你的輸送量、頻寬或每秒點擊率等指標，他們只要一個良好的使用者體驗。市場上有大量的書討論了如何設計良好的效能，還有更多的書把重點放在如何使得網站更加直觀、生動、令人愉悅和易於操作上。關於速度的好處也討論過，但如何真正預知並調優系統來提高使用者體驗呢？那就是直接的使用者體驗測試了。有兩種方法做到這一點。可以把網站直接投入到能夠進行資料擷取和系統調優的生產環境中，並祈禱你的網站不會太慢或崩潰。另一種明智的選擇是類比真實的多使用者活動，進行重複的測試和調優，最後再投入到生產環境中。這聽起來是一個簡單的選擇，但如何準確地類比真實的多使用者活動呢？這就是本文嘗試著去解答的問題。

2.       術語和概念

理解以下的術語和概念對於理解後續的文章非常重要。

效能測試（Performance Testing）：通過運行實際所期望的使用者模式，確定和消除應用程式或系統的瓶頸的過程。見圖1。

 

工作量分布（Workload Distribution）：系統中一組使用者功能操作的一種體現，有時被理解為使用者群模式。以一個零售網站的一天中使用方式為例，大部分的使用者在購物，還有的在搜尋特定的商品，有的在結賬並最終離開網站，同時可能也有管理員在更新商品價格。負載分布是基於一段時間內使用者執行特定功能的比例。在以上的例子中其負載分布可能是：購物－83％，商品搜尋－5％，結賬－10％，後台管理－2％。

從使用者體驗的角度來看，效能目標（Performance Goals）可以表示為執行預定數量的並發使用者時所允許的最大回應時間。

回應時間（Response Time）是從終端使用者的角度來衡量的。例如，從使用者點擊登入按鈕到下一頁面完全載入的時間。

會話期間（Session Duration）是單個使用者在一次網站訪問過程中的所有期間總量，會話期間因使用者類型而異。

並發使用者數（The number of Concurrent Users）是特定時間點上實際訪問網站或活躍會話的總使用者數。

每小時的使用總量（Total Hourly Usage）是一小時內訪問網站的期望使用者數，通過將會話期間乘以並發使用者數計算得到。

基準（Baselines）在此理解為用於時間比較起點的單使用者、單指令碼的測試。

使用者延遲（User Delay）是插入指令碼的一段等待時間，以便當指令碼回放時和實際使用者有相同的步調。

在本系列文章中可能用到一些不同的人有不同理解的術語。這些術語說明如下。

負載測試（Load Test）是一種包括等待時間，準確類比目標使用者群操作的多使用者測試。負載測試可用於執行不同的使用者負載以擷取諸如網站所能支援的最大使用者數的資訊，（並以次判斷）是否能夠滿足預期的效能目標。

壓力測試（Stress Test）是由多個指令碼組成的在高使用者負載下，不包括等待時間的一種測試。這類測試對於評估系統在一定負載下的穩定性和功能性比較有用，但不適合於測定使用者體驗。

基準（Benchmarks），收集有關係統硬體、支撐軟體的度量指標。例如，可以通過基準測試訪問一個大圖片來測定Web伺服器的輸送量和每秒點擊率。

3.       系列文章概覽

本系列每月將會有一篇新文章發布。所有文章將包括所介紹的實際應用的方法和技術的討論、現實中的例子和（或）代碼樣本，以及“Now you try it”的練習。每篇文章都會被分成初級、中級還是專家級，這些等級通常指的是技術實現討論所需代碼的複雜性。每篇文章中提到的概念將適用於所有專業知識水平。下面簡要描述一下前12篇文章。

3.1.      類比真實使用者（Modeling Real Users）

確定真正使用者體驗的關鍵之一是有效類比實際的使用者和使用者群。本系列的前3篇文章將討論如何從應用程式的角度出發，使用Rational Test Studio來準確類比單個使用者或整個使用者群。相關主題包括：

Part 2: Modeling Individual User Delays

Part 3: Modeling Individual User Patterns

Part 4: Modeling Groups of Users

3.2.      （捕獲）有意義的時間

在類比實際使用者之後，從這些使用者的角度擷取系統（應用）的回應時間變得相當迫切。只是簡單的捕獲這些時間是不夠的。除非能夠解釋這些時間的模式，否則這些時間是沒有意義的。接下來的3篇文章討論了如何使用Rational Test Studio來捕獲和解釋真正的時間體驗。相關主題包括：

Part 5: What should I time and where do I put my timers?

Part 6: What is an outlier and how do I account for one?

Part 7: Consolidating and interpreting Times

3.3.      向干係人彙報（Reports to Stakeholders）

我不得不承認干係人和決策者需要測試報告，我們不能只是簡單地告訴他們測試結果是“行”或者“不行”。我們需要採集大量的資料並形成簡明、有意義的報告。這部分的文章將討論哪些測試類型將給干係人和決策者帶來更多的價值，以及如何使用Rational Test Manager來收集資料和產生各種摘要資訊。相關主題包括：

Part 8: What Tests add value to stakeholders?

Part 9: Summarizing across multiple tests with accuracy

Part 10: Creating a Degradation Curve

3.4.      進階主題

本系列的最後主題將圍繞一些曾經給作者帶來困擾的進階問題展開討論。這些文章採用案例研究的形式。每個案例研究概括了客戶問題的特殊需求、作者的形成解決方案的思維過程、可能的解決方案的要點，以及詳細描述了挑選辦法。相關主題包括：

Part 11: Handling Secure Session ID’s

Part 12: Conditional user path navigation (intelligent surfing)

Part 13: Working with Unrecognized Protocols

4.       小結

本系列文章是鮮明的：相對於當今的計量習慣，使用者視點是一種更加可靠的網站效能衡量的方式。這一系列的文章旨在教導讀者如何使用Rational Test Studio來類比多使用者的活動，以及一個經過驗證的最佳化終端使用者效能體驗的方法。本文將分享一些關於如何有效運用方法學，以及利用Rational測試載入器等有用的資訊，甚至是一些有用的貼士（Tips）來規避曾經令專家們也感到為難的問題。希望大家喜歡並保持關注。

5.       附錄（單詞）

User experience 使用者體驗

Application’s perspective 應用程式的角度

Fraction of an hour：以小時為單位的分數形式

Stakeholders 干係人

Concise and meaningful report 簡明、有意義的報告

imperative 緊急的、必要的

返回主題：[翻譯]基於使用者體驗的效能測試