雖然技術人員和技術主管們都希望提高應用程序的性能，但團隊不能因為過分關注性能而影響最終用戶的響應時間。測量最終用戶真實響應時間的唯一方法就是在全國或全球各地建立服務器，然后定期訪問一個網頁，如每隔15~30分鐘。這就是所謂的真實瀏覽器性能測試，也是種監控Web應用程序運行狀況的長期方法。它可以最有效地確定一個Web應用程序的運行性能。通常，這些過程由第三方公司執行，他們會代表客戶在指定的位置執行測試。 Keynote和 Gomez就是兩家能夠提供這種服務的著名公司。對于大多數公司而言，建設這種基礎架構的成本可能太高了，而且需要投入大量的資源，但是回報甚微。因此，最好是使用一些專業公司提供的服務，他們的核心競爭力就是提供Web性能監控和測試服務。
生產環境測試并不一定意味著要將新產品發布到生產環境中執行，因為如果出現問題，則可能會破壞品牌形象。如果給現有網站引入一個新特性，或者修改其中一個重要部件，那么最好先導入一小部分流量將網站的新特性或修改部分交付這部分用戶使用。應用程序在內部通過了全面測試之后，最好要分析用戶流量對新應用程序、網站或特性的影響。這種方法一定要謹慎使用，因為這個特性只讓少數用戶測試過，這并不代表全負載運行不會出現問題。這種方法的效用主要在于，它可以為我們提供以下數據
只有在生產負載下才會發生的錯誤和行為；
知名度數據有多少用戶愿意和喜歡使用這個新特性；
性能標準。
這種方法可以用流量匯集技術實現，即讓負載均衡程序根據URL導入一部分流量。例如，包含新代碼的Web服務器或應用服務器可能有個URL: /beta/player。該可能位于一個服務器群的10101000阿絡中。大多數負載均衡程序都可以配置為只允許一定比例的流量或會話進入包含新應用程序或模塊的應用程序或Web服務器。
在受控的生產環境測試設置中收集到一些性能和日志數據之后，我們就可以分析這些數據，將它們與內部測試和合成測試的結果進行比較。
如果測試對象不是現有網站制作的一個新特性，而是一個全新發布的網站，那么測試就更加重要了。許多新建或全新的網站都需要加入一個邀請頁面，然后邀請一部分用戶試用它們的服務。問題在于，這些用戶是經過選擇的，他們知道自己是Bea測試用戶，他們的作用是幫助開發者修改錯誤，協助最終正式發布。執行密集內容測試和少量生產環境測試，然后將生產使用及錯誤數據與內部測試數據進行比較，這個過程完全相同；它們的區別在于新網站的訪問限制是通過一個選擇加入列表來控制的，而不是使用自動化的負載均衡和根據一些條件(如年齡)來識別用戶的標記系統。
本文地址：http://knowyourextract.com//article/4527.html
