做了4個迭代的性能測試， 在沒有需求的情況下步步艱辛，把代碼和框架獨立開發從0到一萬多行代碼的測試工具（腳本），作為性能測試工具佼佼者Lr，我時而拿他作參考，山寨了它很多 東西，同時帶有很多疑問對它實現性能測試的原因渡過了為期3個月的性能測試之旅。以下是我對比測試腳本和LR所得出的詳細問題：
1、如何計算每秒處理包的數量
我針對這個曾經研究了很久。在多線程的情況下，壓服務器的時候，是專門建立一個線程去采集這些信息，還是說在每個線程里面實現這個時間。后來我采取了后者。因為在到達了某項瓶頸之后，這段時間的變化是很小但是也不能忽略了。
例如下面的偽代碼1：
EachThread:
BeginTime = time.time()
Count = 0
While point:
If RevPackage() == true:
Count = Count + 1
EndTime = time.time()
Runtime = BeginTime – EndTime
EachsecondRpackage = float(Count) / float (Runtime)
EachsecondRpackage = SumAll(EachsecondRpackage) |
偽代碼2：
Count = 0
EachThread:
global Count
While point:
If RevPackage() == true:
加鎖
Count = Count + 1
解鎖
TraceThread:
Time.sleep(runtime)
EachsecondRpackage = Count / runtime |
第一種，是每個線程自己算時間，然后在point為true的時間內算出每秒的收到的包，然后把所有線程的包加起來。第二種是線程不做任何算法操作。讓 單獨線程來做。第一種的好處是數值很準確，同時沒有在關鍵點用了影響性能的鎖。第二種則對總執行時間的統計很準確，但是里面用了鎖。就2種來說一般第一種 用比較多，但是假如在延時比較大的發包或者關注整體事件流用的過程中，第二種的算法比較準確些（注意有時候延時越小不代表壓力越大）。這里我帶有的疑問 是，lr他是如何設定這個TPS的數字呢？是否2種結合還是只用了其中一種？
說到了鎖，在很多性能測試中都會和數據庫打 交道。我們當然想建立n多線程去沖擊數據庫（無論數據庫是不是被測系統），但是數據庫本身能夠接受的線程就是有限制，而且其限制很低，雖然我們在數據庫的 操作用線程鎖是可以，但是造成個缺點是假如事件流很多，創建虛擬數據，和下發及時命令再帶多并發的操作時，這個鎖就會讓很多線程（尤其是延時小的線程）會 卡在某個事件流的點上，導致socket斷了。也影響數據結果（因為不知道算出來數據是否有別的事件導致出現誤差）。解決方法是盡量不影響測試的情況下把 能做的數據庫數據先做了，實時的數據庫建議先在某個點做集合點，統計夠了再做壓力沖擊。這里就用了Lr的集合點概念，注意的還是算平均值的開始和結束事件 要抓準。
說到數據庫，假如你的db知識不是很牛的話測試數據lr是個好首選，但是一些復雜情況下我們不是每種用例都適用Lr測試。這時候你需要非常清晰的了解你的測試需求。下面的偽代碼：
Python:
for i in range(1000):
cursor.execute(SQL); |
C++:
For (I = 0;i<1000 ;i++)
{
cursor.execute(SQL);
} |
SQL:
FOR i IN 1 .. 1000 LOOP
(SQL)
commit;
END LOOP;
這里用了py和C++，還有數據庫本身的循環，3種循環用的時間都是不一樣。SQL的最快，C++其次，然后是PY，不同被測系統的需求用不同的方 式測試性能，假如你直接測試數據庫某個存儲過程，則能用SQL就用SQL，或者其他語言調用的時候循環都要用SQL的，對比被測產品調用SQL的話，則拿 其中一種語言對比調用被測產品和直接調用數據庫的差別。對于LR的疑問它假如測試出很多SQL的性能指標后，到底它是如何解決我上面提到的問題呢？
說到循環，每次我們做完測試報告寫完宣講時，開發人員總會問這個瓶頸是產品的瓶頸，還是你測試腳本的瓶頸？所以作為測試用腳本語言當然是首選， 但是腳本語言的效率不高是弱點，所以每次用腳本語言做多線程壓力測試的時候，每個關鍵的循環盡量調用C++等效率高的語句來做，同時注意調用時間。LR這 塊其實用的時候偏事件流的方式做，所以像這種變態的壓其實比較少。
說到多線程，這是我研究Lr比較多的一個地方。當我自己寫腳本的時候經常會深入研究不同操作系統不同硬件對線程的利用率的影響，還有線程鎖，和 該不該配合隊列，進程來做測試。當然理想是越多測試機做分布式，甚至用云臺來做更好。但是現實情況你不僅僅考慮開多少個線程多少個測試機，而是說100個 線程用1臺機器跑，和用10臺機器跑的差別，測試產品瓶頸首先要測試網絡，系統的瓶頸。一臺機器假如到達了50個線程和100個線程所出的吞吐量是一樣的 話，那么這臺機器最佳啟動線程是50個。我聽說Lr有隊列有線程有進程一起配合的情況下做制作并發測試。我也按照他的負載測試方式設計腳本，但是即使是云 臺也存在分析操作系統和硬件的弱點，假設lr在單臺服務器做1000（假設數據）個并發（不考慮多條件）的話，它到底是怎么實現并發的？
說到了最關鍵的操作系統，網絡，硬件這塊了。很多時候我們高科技的性能測試產物—性能報告變成廢鐵的。就是這3個造成。linux我最高記錄并 發10800個線程（4cpu虛擬雙倍），win7最高記錄2100個線程（雙核），這個僅僅是好看的記錄，沒了！因為我們IO口就這么大，磁盤讀寫能力 最大限制，網絡帶寬也有限制，所以上面開到的線程當然可以增加壓力，但是在沒窮到只剩1~2測試”服務器”的情況下，最好不要用一個方法，畢竟10臺吊絲 臺式強過1臺高富帥服務器做客戶端。同時雖然云計算其中一個概念是虛擬化計算，但是并不代表你每個測試機都把資源利用做虛擬機來做壓力，因為最關鍵的線 程，虛擬機本身的軟件和操作系統也消耗了一些線程的地盤，所以利用虛擬化計算做測試，需要謹慎。還有一點就是性能命令top，ps，sar等等的數值，你 要注意那些有用，哪些相對準確，雖然linux提供了很多性能命令，但是不代表他們之間是一模一樣的。當然lr也是靠人工配合分析組網，測試機的性能。
最后說下你分析和出測試報告。lr的報告很華麗，很多專用性能測試名詞都打上一堆，可愛的老大最喜歡看這個賺獎金的東西。但是實事求是的大牛沒 那么容易騙過，把公司網絡，各個資源都用上來做性能測試肯定要看到有意義的東西。我腳本投入了很多excel圖表（交互式調用偷懶），來幫我做出很多圖。 性能測試最重要是分析，我上面說的很多技術都為了準確獲得數據分析而設計的。所以現在性能測試從單機到分布式到云都往精確這個關鍵點發展。很多次帶著報告 面對各部分的開發老大，作為一個小QC如何把上百兆的日志和數據理出來跟這些高手報告需要注意很多細節。為什么這個階段曲線會不沒規律？什么是瓶頸？有沒 問題？這些數據作為參考數據還是代表有問題？系統該不該優化？下一個迭代的任務和程序設計如何做？這些都必須自己理清楚。對比Lr，唯一的優勢就是這些數 據我都知道怎么抓來的，但是要比上這個權威的工具，還是需要繼續努力縮小差距。
下一個階段不再是怎么去查詢瓶頸，怎么去發現bug為主，因為敏捷到了接近尾聲的時候，我需要變成選型工程師的角色，優化程序框架和處理，分析操作系統是主要任務，來為我們的產品節約成本，是性能測試的其中一個因素之一。
版權聲明：本文出自 acbennn 的51Testing軟件測試博客：http://www.51testing.com/?299791
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。