@import url(http://m.tkk7.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

　事情的起因是這樣的：

　　上周三下午要出去打個電話，經過小會議室門口的時候測試負責人叫住我問有事嗎？小A做的性能測試出現了點問，要我幫忙分析一下。打完電話后到小會議室與小A、測試負責人一起看小A的性能測試出現了什么問題。小A說她對X項目進行了性能測試，但是結果與現在線上的差距特別大，線上入庫是10條/秒，而她測試的結果是3-4條/秒，對于她測試得出來的結果項目的負責人很不認同，認為是她做錯了，而她又找不出來問題出在哪，她很郁悶。

　　接下來是我們的一段對話

　　我：小A，你說一下這次性能測試，是對哪幾個點做的，場景都是啥樣的？

　　小A：主要是兩個點，一個是單一場景針對短信入庫的，場景設計的是30、50、100條數據并發持續2個小時，是根據線上前段時間出現的問題發3萬條短信，結果處理的時間特別長這個問題設計的；另外一個是將接收到的不同類型的短信入庫，是個混合場景，場景是短信2條、彩信1條、WAPPUSH1條、EMN1條，這些數據并發，持續2個小時。

　　我：問一下，線上對于短信發送真實操作場景是什么樣子的呢？

　　小A：這個我不知道啊，反正我只知道現在線上要求1個小時內必須把這些短信發完，線上現在預計的入庫量是10條/秒。

　　我：好吧，換個問法，X系統小A你最熟了，線上的這個問題，有大量的數據過來，X系統 對這些數據是怎樣處理然后入庫的呢，是一批一批的處理，還是一條一條的處理呢，如果是一批一批的處理，對于這一批數據是怎樣處理的呢，是同時處理掉，還是一條一條的數據。

　　小A：這個我不清楚，要不一會兒我去問一下開發的吧。

　　我：我再問一下，現在搭建的這套測試環境，各個機器的配置是怎么樣的？和線網的機器配置差距有多大？線網的帶寬是多少？現在測試環境的帶寬是多少？線網是有負載均衡的，有VPN通道的，測試環境上有這些嗎？

　　小A：tomcat的機器是一臺服務器，4核的，另外兩臺數據庫還有LR加壓機都是實體機。線網的機器配置我不知道，測試環境也是100兆帶寬，負載均衡啥的測試環境都做不了。

　　我：線網帶寬是千兆的，測試環境的百兆帶寬不全是給你來測試用的，公司上班時間所有同事辦公還占用一部分帶寬呢。線網的數據庫做過一次優化的，有幾個參數是調整過的。

　　我覺得這次問題的分析可以從幾個方面來入手查，第一，場景設計，我從開發的那里了解到線上真實的情況是沒有并發的，只是一條一條的來處理，處理的數據量是3萬條，1個小時處理完，是我們自己的要求。所以場景可以重新設計，設計成沒有并發，處理3萬條數據；第二，測試腳本的性能，測試腳本里的代碼可能本身響應時間就長；第三，機器配置、網絡帶寬，查看現在測試機的配置與線網比相差多少，這些能不能想辦法進行一下換算，結果可能有誤差，如果找到依據，看看誤差能控制在多少范圍內。

　　小A：我覺得腳本代碼不是問題，我就是這樣寫的都能執行過去，能執行過去為啥就會有問題呢。線上真實的操作那在那臺服務器上還可能有別的省發短信呢，對那臺服務器還有影響呢，那臺服務器的配置好可能還有別的省來占用呢，所以機器配置也不應該是問題。帶寬我覺得也不是問題，公司百兆的帶寬也夠用了呀，我在測試的時候也沒發現網絡上哪里出現了問題，CPU占用率呀都非常少的。

　　我：......無語

　　對于性能測試，到底應該怎樣做，會用了工具（最著名的是LR）就會了性能測試了嗎？NO，NO，NO

　　我認為：

　　前期分析：

　　分析業務：分析用戶群，業務真實使用和操作情況。比如在哪個時間段哪個操作會多，哪個操作會少，怎樣來操作，是會有很多人一起對系統發起請求呢（所謂的并發），還是數據量很大，但是都是一個請求一個請求過來的，很持續很長時間嗎（比如8個小時都在做這樣的操作），還是主要是對一定的數據量操作的（比如處理完幾十萬條數據后任務就完成了），每次只有一個場景嗎，還是是個混合場景都有，如果是混合場景，那么各個場景的比例大約是多少呢。線上已經有多少數據量了？預期要達到多少數據量？

　　分析環境：線上系統環境是什么樣子的？有負載均衡嗎？有多次轉發嗎？......機器配置是什么樣子的，每臺機器上都有哪些服務？線網的帶寬是多少？是專用的嗎？搭建的測試環境和線網真實的環境有多大的差距，帶寬是多少，是專用的嗎？測試環境不可能與線網環境是一模一樣的，有辦法換算嗎？誤差大約是多少？

　　分析團隊成員：給你配備的配合的開發人員了嗎？與你配合的開發人員靠譜嗎？你的團隊里有性能測試的高手嗎？團隊對這個項目的性能測試支持嗎？

　　時間分析：測試的時間充足嗎？哪些是必須測的，哪些是可以不測的。

　　測試執行：

　　有了前面的詳細的分析之后，才能整理出測試需求、設計測試方案、編寫測試用例、編寫測試腳本、設計出合理的測試場景，才能執行測試。

　　結果分析：

　　測試出了結果，不能就算完事了，把結果丟給別人讓別人分析查找原因，那不是高手，真正的高手是可以分析出問題在哪里，是什么原因產生的，怎樣優化。簡單的幾個切入點可能從服務器系統CPU、內存等等，數據庫中SQL執行速度，數據庫CPU、內存等入手。查看事務平均響應時間是否在可控范圍內，每秒處理的事務數怎樣等等。借用一些工具查看操作數據庫的SQL執行情況等等。

　　總結一下，性能測試個人認為最重要的不是使用工具，而是測試前的分析和結果的分析，前面的分析夠透徹才能保證后面做的是對的，而不是一上來就是用工具，就大并發，只有大量的并發才是性能測試，一定得根據現實的真實使用情況來做才可以，違背了現實做再多也是無用。每次一聽到有開發的對我講你幫我們做一下性能測試吧，弄個幾萬的壓一下，我就特無語。

天貓 軟件自動化測試開發