前言
    效能測試的工作的有效開展，離不開效能測試工作正式開展之前的精心準備工作。由於效能測試工作自身的特點，往往呈現出倒金字塔的結構。一但一個依賴條件準備失當，由此引發的系列事項都有可能推倒重來。故而在效能測試的準備過程中，每一個步驟都得做好細緻的考量後，穩紮穩打的逐步推進。而不是一旦接到效能測試任務後，就拿起工具風風火火的開始操弄起來，最終耗費了大量時間做的確是無用功，或者效率低下，最終不得不草草收場。今天就來八一八效能測試開始前的一系列準備工作，掛一漏萬，歡迎同行斧正。
   
需求確認
    效能測試準備的第一事項是發起者（可能是客戶，可能是產品/專案經理）提供的效能測試需求。沒有很好的理解需求就開始做效能測試，就像是無源之水。本來要做壓力測試的，結果沒很好的理解需求，做成了疲勞測試這種事情，就是前期沒有和發起者做好溝通導致的，雖然費勁了氣力，然而卻不被買賬。
    前期針對性能測試的需求調研進行充分的溝通確認，是保證效能測試過程有效開展的重中之重，這點怎麼強調都不過分。但也不是說非得死扣每一個細節，到底多大的併發量才合適，需要持續壓力多少時間什麼的都確認的清清楚楚之後才能開展效能測試，有時候這個度也是一個經驗積累判斷的過程，究竟多詳細才好也是靈活掌握。
    一些基本的背景資訊確實得明確落實，是專案經理想知道現在的系統，在怎樣的硬體條件限定下，究竟能承載多少使用者的業務量？還是說客戶需要知道業務密集發生時，我的核心業務在現有的環境下是否能有效開展，或者是找出現在程式過慢的瓶頸問題所在。這種針對性能測試定基調的事項一定是越早確定越好。
    另外強調一點，一般效能測試的發起方大多都不是專業的效能測試人員，在測試目的描述上面很可能不是如上文舉例所說的那麼明確，此時就得發揮性能測試人員自身的主動性，去溝通，調查瞭解，不要等著別人給你提供，別人的專職不在這兒，不可能對效能測試如測試人員一般上心，最多想起來的時候問一句怎麼樣了？效能測試新人，往往在目標，詳細需求都還沒確定下來就開始準備測試，最後得到的結果基本都不理想的最主要原因估計就在這兒。
   
測試方案
    接下來的工作則是要制定詳細的測試方案。設定效能測試場景，是單場景執行還是混合場景執行？單場景要測試哪些功能？混合場景有哪些功能需要涵蓋進來，各佔多少比例？
    如果是上線前的效能的測試，混合測試中各種功能的佔比也是越接近實際使用過程中的比例越好。如果佔比失調，測試的效果就要大打折扣。由於還沒有相關的統計資訊，一般都採用80/20原則。
    要是在已經上線的專案上開展效能測試，最好還是先調查清楚各測試項的實際佔比來確定，最簡單的統計方式就是把系統業務活躍時間段內的日誌拿到進行彙總統計，拿熟悉的指令碼語言寫個指令碼，分分鐘就統計出來了。
    還有一個注意事項就是加壓策略，根據測試目的不同，是逐步加壓到一定的虛擬使用者數穩定執行，還是一直穩定加壓，直至系統拐點，根據測試目標的不同，加壓的策略也是需要仔細確定。這個將來有機會再展開講，一兩句話也說不清楚。
   
硬體
    硬體最好是越接近真實環境越好，最好是真實的生產環境上測試。
    但現實往往是測試環境和實際環境有較大差異，這種情況下也並不說效能測試就沒辦法開展了。此時就需要基於目標環境，合理配置測試硬體環境。效能測試結果則是在測試機器效能的基礎之上進行合理的估算，計算出實際環境的業務承載能力。
    除了常見的資料庫伺服器，應用伺服器，測試客戶端機器效能的考量外，網路環境、頻寬、網路延遲也是在效能測試過程中需要充分考量的。
    如果測試環境有虛擬化主機，關於硬體資源的設定也是需要仔細設定，避免因為設定不當導致主機之間的效能互相之間受到影響。
   
軟體
    相應的軟體平臺一類的東西也是接下來需要確定下來的東西。比如作業系統的型別和版本，資料庫的型別和版本。如果測試目標中已經確定是哪種環境下，則儘量按照既定目標中的來配置，避免因為不一致而導致測試結果的偏差。待測軟體的部署工作也是效能測試人員需要熟知的一個事項。沒準因為版本不太穩定，一天換好幾個版本也說不定。這塊多說一句，有條件用指令碼部署的儘量用指令碼。雖然編寫除錯指令碼需要耗費一定的時間。但好處就是避免人工操作引入錯誤，比如測試半天了才發現數據庫沒還原什麼的問題。用指令碼的話，一個雙擊，一條命令就搞定了。還有就是做好待測軟體的版本記錄。哪次測試是用的哪個版本的程式要保留好記錄，避免因為版本反覆更迭，導致結果記錄混亂。最後，用來做效能測試的主機上無關程式均應停止。避免因為運行了其他的程式對效能測試過程造成影響，特別是像防毒軟體防火牆之類會對網路傳輸進行監聽的軟體應儘量關閉。
   
效能測試工具
    效能工具的選型，往往是沒的選，要麼就是用工業標準LoadRunner一類的商業軟體，要麼因為授權問題用JMeter一類的開源軟體。
    商業軟體的優勢是資源充足，需要什麼材料，開啟搜尋引擎基本上都能找到相關的資訊，實在找不到還可以聯絡原廠做支援。劣勢是費用高昂，不多虛擬使用者的授權就需要大筆的費用開支，不是一般的企業所能承擔的。用盜版的話，效能測試報告為了規避法律風險，也要把工具的一些標誌性的資訊去掉，內部看看的話也都沒問題，一旦要對外發布，就存在一定的商務風險。
    退而求其次，改用開源的軟體之後，費用倒是不成問題，但相關的資源搜尋起來就比較費勁。最近這幾年還好一點，常用的開源效能測試工具有了一定的使用者基礎，相關的問題也能通過搜尋詢問解決一部分。但如果是社群中沒有人遇到過的問題，或是無論怎麼搜都沒個的結果問題，好死不死這問題卡住效能測試的關鍵節點。能繞過去的問題還好，繞不過去就讓人慾哭無淚了。成了出了問題不知道該找誰。
    最近看到一種效能測試工具的商業模式，像HyperPacer一類的：軟體免費提供下載，升級。但效能測試過程中遇到的問題的協助解決，或做定製化開發則需要一定的費用。說新其實說新也不算太新，Red Hat一類的Linux發行版早就是這麼玩兒了。就是不知道能折騰出多大的市場了。嘗試一下倒也不錯，到底有一個團隊做支援，還是會心安一些。
   
測試資料
    如果有一定數量的歷史資料，效能測試的資料準備還略微好做一些。常用的手段就是寫SQL資料翻倍之類的方式使資料達到測試所需的量級，如果對錶結構不是太熟悉的測試人員，還需要聯絡相關的開發人員協助此項工作。
    要是還沒有上線的專案，沒有歷史資料，此時就需要生造資料。往往會出現一些資料分佈不合理一類的情況，這裡就需要提前聯絡相關的業務人員對資料的量級做一個預估，最大程度的減少資料偏差。
    若是資料表之間還存在關聯引用的話，無論以上的哪種方式造數，都要儘量保持資料關聯的準確性，例如主子表之間的關聯，一條主表資料平均關聯幾條子表資料一類的設定也是要提前做好調研的事項。

指令碼錄製開發
    以上全部準備停當，就得開始用工具錄製除錯指令碼了。因為cookies，session id一類的東西，需要對錄製下來的指令碼進行引數化處理，多個不重名的使用者，選項之類的也需要引數化。這塊得對效能測試工具和相關的背景知識相當瞭解，否則就會耗費大量的時間在指令碼除錯方面。所以在效能開始之前，要對效能測試軟體的相關設定和待測軟體系統都有一定程度的瞭解後，再開始著手測試，所謂磨刀不誤砍柴工。待到指令碼除錯完畢，場景都逐一按照方案正確設定儲存後。正式的效能測試總算能有條不紊的開始了。