商業使用者的需求主要表現為對功能的要求。系統的非功能特性則由架構師負責，包括：效能表現、靈活性、持續正常工作時間、技術支援資源等。但是，對非功能性的初始測試往往被拖到開發周期的最後階段，有時還由開發團隊來操刀，這樣的錯誤屢見不鮮。
造成這種現象的原因有很多，有人覺得在還沒有實現客戶要求的功能之前，考慮系統的響應速度與靈活性無異於紙上談兵；或者面對複雜的環境和測試望而卻步；再不就是覺得產品的早期版本不會承擔太重的工作負荷。
但是在專案週期的最後階段才關注效能問題，會導致我們錯失大量歷史資訊，這些資訊包含效能變化的細節。如果效能是架構設計的重要指標，就應該盡早展開效能測試。在採用敏捷方法開發的專案中，如果以兩周為乙個迭代週期，我認為效能測試的開始時間最遲不能晚於第三次迭代。
為什麼要提前展開效能測試？首先，如果效能表現大幅下滑，你至少能找到下滑是由哪些變化引起的。當系統出現效能問題時，你只須檢查最近的變化，而不用全盤考整個架構。盡早反覆的開展效能測試可以縮小問題的可疑範圍。
專案伊始的測試資料雖然不能用於效能診斷，但它們至少提供了乙個起始基準。這些趨勢資料將為今後診斷和解決效能問題提供重要依據。
這樣做還可以驗證架構和設計是否符合實際效能要求，尤其對效能要求苛刻的系統，驗證的早晚直接關係到能否及時交付專案。
眾所周知，堅持技術測試是需要耐心和毅力的，無論是搭建合適的測試環境，採集適當的資料集，還是編定必要的測試用例，都須要投入大量的時間。提前開展效能測試，能讓你有條不紊地逐步完善測試環境，為解決效能問題節省下大量的時間和精力。
效能學習 效能關注指標
qps 原理 每天80 的訪問集中在20 的時間裡，這20 時間叫做峰值時間。公式 總pv數 80 每天秒數 20 峰值時間每秒請求數 qps 機器 峰值時間每秒qps 單台機器的qps 需要的機器 每天300w pv 的在單台機器上，這台機器需要多少qps？3000000 0.8 86400 0....
效能測試需要關注的效能點
我們站在管理員的角度考慮需要關注的效能點 1 相應時間 2 伺服器資源使用情況是否合理 3 應用伺服器和資料庫資源使用是否合理 4 系統能否實現擴充套件 5 系統最多支援多少使用者訪問 系統最大業務處理量是多少 6 系統效能可能存在的瓶頸在 7 更換那些裝置可以提高效能 8 系統能否支援7 24小時...
效能測試關注點
作為軟體測試人員，我們經常會遇到壓力測試 穩定性測試 功能測試 效能測試 相容性測試等等，有時在工作中潛移默化的就已經在使用這些測試方法中包含的點，但是我們沒有太在意去總結梳理，那麼每個測試方法的關注點是什麼？如 在效能測試的過程中我們應該最該關注什麼？等等的思考呢，經過幾次的總結，今天首先將效能測...