第第頁Java性能測試的四項(xiàng)原則次數(shù)基準(zhǔn)樣本1

1.0

0.5

2

0.8

1.25

3

1.2

0.5

平均

1

0.75

看起來樣本的平均值顯示有25%的提升，可事實(shí)證明樣本和基線有相同性能的概率是43%。也就是說57%的概率存在性能上的不同。43%是基于T檢驗(yàn)所得到的結(jié)果，T檢驗(yàn)主要用于樣本含量較?。ɡ鏽30），總體標(biāo)準(zhǔn)差未知的正態(tài)分布（資料）。t檢驗(yàn)是用t分布理論來推論差異發(fā)生的概率，從而比較兩個平均數(shù)的差異是否顯著。它與z檢驗(yàn)、卡方檢驗(yàn)并列?，F(xiàn)在的T檢驗(yàn)結(jié)果告訴我們這樣一個信息:：57%概率顯示樣本和基線存在性能差異，差異最大值是25%。也可以理解為性能差有57%的置信度向理想發(fā)現(xiàn)發(fā)展，結(jié)果有25%的改善。

在考量回歸測試的結(jié)果時，離開了統(tǒng)計(jì)分析的方法，而只關(guān)注平均值來做出判斷，含糊的理解這些數(shù)字的含義是不可取的。性能工程師的工作是看數(shù)據(jù)，理解這些概率，基于所有可用的數(shù)據(jù)確定在何處花時間。

盡早測試，經(jīng)常測試

第四個原則就是工程師應(yīng)該視性能測試是整個開發(fā)過程必要的部分，盡早進(jìn)行性能測試，經(jīng)常進(jìn)行性能的測試，是一個好的工程師應(yīng)該做到的。在代碼提交到代碼庫之前，就應(yīng)當(dāng)做性能測試，因?yàn)樾阅軉栴}也會導(dǎo)致回歸測試失敗。所以提早發(fā)現(xiàn)問題會提高整個項(xiàng)目的質(zhì)量，減小交付的風(fēng)險性。

在一個典型的項(xiàng)目開發(fā)周期過程中，項(xiàng)目計(jì)劃常常是建立一個功能提交的時間表，所有功能的開發(fā)必須要在某一個時間點(diǎn)全部提交到代碼庫中，在項(xiàng)目發(fā)布之前，所有的精力都致力于解決功能上的Bug，那么很有可能在這個過程中發(fā)現(xiàn)性能問題，這會導(dǎo)致兩個問題產(chǎn)生：

開發(fā)人員在時間的約束下不得不提交代碼以滿足時間表，一旦發(fā)現(xiàn)出嚴(yán)重的性能問題他們會非常畏懼，所以開發(fā)人員在測試開始的早期解決性能問題能夠產(chǎn)生1%的回歸測試代價，而如果開發(fā)人員一直在等待晚上的凍結(jié)功能開發(fā)的時候才開始檢查代碼將會導(dǎo)致20%的回歸測試的代價。

任何為解決性能做出的修改都有可能帶來巨大的成本，有時不僅僅是代碼的修改，更有可能是軟件架構(gòu)的修改。所以最好在軟件設(shè)計(jì)之時就充分的考慮到未來可能帶來的性能問題。

盡早測試性能有以下四點(diǎn)可作為指導(dǎo)：

提早準(zhǔn)備測試用戶以及測試環(huán)境的設(shè)計(jì)和創(chuàng)建；

性能測試應(yīng)該考慮盡量用腳本來完成；

通過性能監(jiān)控工具盡量收集有可能得到的運(yùn)行信息，為將來分析提供便利；

一定要在一個能真實(shí)模擬多數(shù)用戶的機(jī)器環(huán)境下進(jìn)行性能測試。

總結(jié)

最后，基于我們講過的方法作為基礎(chǔ)，構(gòu)建一個（自