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

　對一個開發人員來說，除了保質保量按時完成功能需求外，非功能也不可忽視。

　　決定一個軟體的成敗往往是非功能性需求比如性能，若是使用者體驗不好那麼必定是個失敗的作品。

　　那麼一個開發人員如何去做關于自己子產品又或者整體的基準性能測試呢？以下将從測試的切入點和具體測試的名額來說明。

　　切入點：

　　通常，基準性能測試有兩個切入點，一方面可以通過從整體系統的角度做一個全棧式(即打通上下各層)的性能測試用于發現整體系統的性能瓶頸點，另一方面又可以具體到某個層或者子產品進一步分析性能問題。

　　測試目标：

　　從定量工具的角度來說性能測試一般關注以下3點：

　　1. 機關時間内系統處理請求、事務的次數：比如測試子產品的接口性能，可以針對一個接口調用n次并求平均值。

　　2. 響應時間（延遲）：目的是求出最大響應時間和最小響應時間，并對響應性能做一個預估用百分法來表示。比如對一個接口或協定發起請求10次，若有一次響應時間大于10ms，其他都小于10ms，那麼可以說針對該接口有90%的機率系統響應時間小于10ms，當然要求準确的話需要更多地測試。

　　3. 吞吐量：這裡的名額常有如iops，常見于測試存儲系統的性能測試用于發現系統最大流量。

　　從測試價值的角度來說性能測試還需要以下2點：

　　1. 可伸縮性

　　可伸縮性需要和單純的性能測試差別開，當系統隻有一個通路者無其他負載的情況下為單純的性能測試，若有性能問題可從代碼、設計上分析研究。而伸縮性指得是在整個系統負載變化的情況下（比如增加通路者并發量），要求系統保持一定的性能（響應時間、吞吐量）。測試過程中可以嘗試對測試環境的硬體進行擴充（垂直、橫向擴充都行），看性能是否能夠在持續增壓的條件下滿足性能需求。在持續對系統增加并發通路量的情況下通過檢視系統的持續響應時間基準測試結果發現系統的設計缺陷。從一定層度上來講，系統的伸縮性在設計上就已決定。

　　2. 并發性

　　對于并發通常有各種了解，但是對于系統性能測試領域來說，更準确地評判伺服器的并發性指得是高峰時期機關時間内的請求數。對我們來說更多應該關注的是工作的并發量，比如同時處理請求的線程數或連接配接數。并發測試更多地是以一種輔助的手段配合性能測試，比如通過并發的手段持續加壓達到測試系統伸縮性的目的。