qileilove

          blog已經轉移至github,大家請訪問 http://qaseven.github.io/

          從開發人員角度看待性能基準測試

            對一個開發人員來說,除了保質保量按時完成功能需求外,非功能也不可忽視。
            決定一個軟件的成敗往往是非功能性需求比如性能,若是用戶體驗不好那么必定是個失敗的作品。
            那么一個開發人員如何去做關于自己模塊又或者整體的基準性能測試呢?以下將從測試的切入點和具體測試的指標來說明。
            切入點:
            通常,基準性能測試有兩個切入點,一方面可以通過從整體系統的角度做一個全棧式(即打通上下各層)的性能測試用于發現整體系統的性能瓶頸點,另一方面又可以具體到某個層或者模塊進一步分析性能問題。
            測試目標:
            從定量工具的角度來說性能測試一般關注以下3點:
            1. 單位時間內系統處理請求、事務的次數:比如測試模塊的接口性能,可以針對一個接口調用N次并求平均值。
            2. 響應時間(延遲):目的是求出最大響應時間和最小響應時間,并對響應性能做一個預估用百分法來表示。比如對一個接口或協議發起請求10次,若有一次響應時間大于10ms,其他都小于10ms,那么可以說針對該接口有90%的概率系統響應時間小于10ms,當然要求準確的話需要更多地測試。
            3. 吞吐量:這里的指標常有如IOPS,常見于測試存儲系統的性能測試用于發現系統最大流量。
            從測試價值的角度來說性能測試還需要以下2點:
            1. 可伸縮性
            可伸縮性需要和單純的性能測試區別開,當系統只有一個訪問者無其他負載的情況下為單純的性能測試,若有性能問題可從代碼、設計上分析研究。而伸縮性指得是在整個系統負載變化的情況下(比如增加訪問者并發量),要求系統保持一定的性能(響應時間、吞吐量)。測試過程中可以嘗試對測試環境的硬件進行擴展(垂直、橫向擴展都行),看性能是否能夠在持續增壓的條件下滿足性能需求。在持續對系統增加并發訪問量的情況下通過查看系統的持續響應時間基準測試結果發現系統的設計缺陷。從一定層度上來講,系統的伸縮性在設計上就已決定。
            2. 并發性
            對于并發通常有各種理解,但是對于系統性能測試領域來說,更準確地評判服務器的并發性指得是高峰時期單位時間內的請求數。對我們來說更多應該關注的是工作的并發量,比如同時處理請求的線程數或連接數。并發測試更多地是以一種輔助的手段配合性能測試,比如通過并發的手段持續加壓達到測試系統伸縮性的目的。

          posted on 2014-03-13 11:26 順其自然EVO 閱讀(260) 評論(0)  編輯  收藏 所屬分類: 性能測試

          <2014年3月>
          2324252627281
          2345678
          9101112131415
          16171819202122
          23242526272829
          303112345

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 光山县| 广平县| 乌拉特后旗| 平原县| 安福县| 巴彦县| 澄城县| 海城市| 黄平县| 富锦市| 鄢陵县| 华坪县| 吴忠市| 南昌市| 蓝田县| 赤城县| 大同县| 武强县| 方正县| 云林县| 咸阳市| 双桥区| 永吉县| 黔西| 华池县| 马龙县| 南召县| 南皮县| 宝兴县| 龙岩市| 志丹县| 安阳县| 且末县| 泌阳县| 江口县| 甘孜| 曲阜市| 金华市| 灵宝市| 毕节市| 南和县|