對乙個開發人員來說，除了保質保量按時完成功能需求外，非功能也不可忽視。
決定乙個軟體的成敗往往是非功能性需求比如效能，若是使用者體驗不好那麼必定是個失敗的作品。
那麼乙個開發人員如何去做關於自己模組又或者整體的基準效能測試呢？以下將從測試的切入點和具體測試的指標來說明。
切入點：
通常，基準效能測試有兩個切入點，一方面可以通過從整體系統的角度做乙個全棧式(即打通上下各層)的效能測試用於發現整體系統的效能瓶頸點，另一方面又可以具體到某個層或者模組進一步分析效能問題。
測試目標：
從定量工具的角度來說效能測試一般關注以下3點：
1. 單位時間內系統處理請求、事務的次數：比如測試模組的介面效能，可以針對乙個介面呼叫n次並求平均值。
2. 響應時間（延遲）：目的是求出最大響應時間和最小響應時間，並對響應效能做乙個預估用百分法來表示。比如對乙個介面或協議發起請求10次，若有一次響應時間大於10ms，其他都小於10ms，那麼可以說針對該介面有90%的概率系統響應時間小於10ms，當然要求準確的話需要更多地測試。
3. 吞吐量：這裡的指標常有如iops，常見於測試儲存系統的效能測試用於發現系統最大流量。
從測試價值的角度來說效能測試還需要以下2點：
1. 可伸縮性
可伸縮性需要和單純的效能測試區別開，當系統只有乙個訪問者無其他負載的情況下為單純的效能測試，若有效能問題可從**、設計上分析研究。而伸縮性指得是在整個系統負載變化的情況下（比如增加訪問者併發量），要求系統保持一定的效能（響應時間、吞吐量）。測試過程中可以嘗試對測試環境的硬體進行擴充套件（垂直、橫向擴充套件都行），看效能是否能夠在持續增壓的條件下滿足效能需求。在持續對系統增加併發訪問量的情況下通過檢視系統的持續響應時間基準測試結果發現系統的設計缺陷。從一定層度上來講，系統的伸縮性在設計上就已決定。
2. 併發性
開篇 從開發人員的角度理解產品經理
首先需要宣告的是，我只是乙個普通的開發人員，但是我希望自己的目標是成為乙個擁有暫時軟體工程功底的，能夠駕馭創新產品，引領團隊的產品經理。本文只是個人的一點隨想，以及閱讀他人著作的一些感悟，尚不成熟，僅在這裡做個記錄而已，牛人不要見笑。從我做研發的經歷來探索產品經理的特質 1 解決方案而不是功能模組。...
測試人員如何贏得開發人員的尊重
看到這個標題，如果你認為我在痴人說夢，那麼請一定仔細閱讀本文。你還在認為測試和開發是天生的一對冤家，有不可調節的矛盾，是對立的兩面麼？開發 的天職是構建程式，測試則恰恰相反，是從事破壞活動。其實從另外乙個角度講，矛盾的兩者又是對立的統一面 共同為了把產品的質量提高。有的時候我們抱怨開 發團隊不夠重視...
測試人員和開發人員應該如何溝通
其實作為測試和開發來說，兩方類似於建築方和質檢方，乙個實現建築高樓大廈，另乙個針對質量不合格的進行拆除。所以，兩方有矛盾是再正常不過的事情，但通過下面的一些建議，在換位思考的角度去理解下開發人員的情況，那麼很多問題自然可以化為無形。1.要懂得尊重對方。開發是一件需要全面和綜合考慮的工作，開發工作中，...