1、分享
1.1 測試環境搭建
在我們進行性能測試之前，通常需要搭建一個供測試用的環境，使用這個環境來錄制腳本，根據在這個環境下執行測試的結果，得出最終的測試結論。
有些時候，測試環境就是生產環境，例如：一個新的項目上線前進行的性能測試，通常就是在未來的生產環境下進行的。在這種情況下，可以排除測試環境與生產環境差異帶來影響，測試結果相對比較準確。
反之，如果測試環境與生產環境不是同一環境，這個時候，為了保證測試結果的準確性，需要對生產環境進行調研。在搭建測試環境時，盡量保證搭建的測試環境和生成環境保持一致（環境主體框架相同，服務器硬件配置相近，數據庫數據相近等）。
另外，最好輸出一個測試環境搭建方案，召集各方參加評審確認。同時，在測試方案、測試報告中，對測試環境進行必要的闡述。
1.2 并發量計算及場景設計
首先，在確定場景及并發量之前，需要對業務進行調研，調研的對象最好是業務部門，也可以通過數據庫中心查詢數據，進行輔助。
場景選取一般包括：登陸場景、操作頻繁的核心業務場景、涉及重要信息（如：資金等）業務場景、有提出明確測試需求的業務場景、組合場景等。
每個場景的并發量，需要根據業務調研的結果進行計算。可以采用并發量計算公式：C=nL / T 進行計算（其中C是平均的并發用戶數，n是平均每天訪問用戶數，L是一天內用戶從登錄到退出的平均時間（操作平均時間），T是考察時間長度（一天內多長時間有用戶使用系統））。
每個場景的思考時間，也可以通過業務調研獲得。
另外，也可以采用模擬生產業務場景TPS（每秒通過事務數）的方式，來確定場景。相比上一種方式，模擬生產業務場景TPS，能更加準確模擬生產壓力。本次ERP性能測試采用的就是這種方式：首先，通過調研確定業務高峰時段，各核心業務TPS量及產生業務單據量。然后，通過調整組合場景中，各單場景的Vusr（虛擬用戶數）和Thinktime（思考時間），使每個場景的TPS接近業務調研所得到的TPS量，每個場景相同時間（即高峰時間段長度）通過事務數接近調研業務單據量，從而確定一個，可以模擬生成環境壓力的基準場景。最后，通過成倍增加虛擬用戶數，來形成2倍場景、3倍場景等。（注：在ERP性能測試組合場景調試過程中，我們發現：各個單場景TPS會受到其他場景的影響（例如：某一個單場景虛擬用戶數增加，其他場景TPS就好跟著變化）。因此，建議大家在確定場景并發量時，如果場景比較復雜，最好采用第一種方式）。
最后，同樣需要制定場景設計方案，召集相關部門進行評審。
1.3 測試框架搭建
在環境搭建完成、場景設計方案確定之后，下一步工作就是創建腳本。
創建腳本通常有兩種方式：錄制和手工編寫。前一種方式相對比較容易，只需要使用測試工具，進行相關操作即可生成腳本。后一種則相對比較麻煩，需要搭建一個腳本執行的框架，編寫各場景對應的代碼。
首先，關于測試框架，簡單來說就是一個程序運行的環境。以java語言為例：我們都知道，一個簡單的java小程序，它要運行起來，我們先要安裝JDK（我們可以把它看成是一組API，也可以說是一些java Class），它提供了編譯Java和運行Java程序的環境。同理，我們現在想要編寫測試腳本，實現特定的功能，那么首先也需要搭建一個可以讓它運行起來的環境。
在搭建環境過程中，需要咨詢對生產環境框架非常熟悉的工程師，了解整個環境運行的機制。測試框架搭建完成條件：測試腳本在該框架下運行，可以實現登錄應用服務器，執行基本業務操作（可以通過在數據庫中，查詢生成數據進行驗證），登出應用服務器。
具體以ERP性能測試框架為例：通過調研分析得出：
1）測試腳本執行需要使用1.4版本jdk；
2）金蝶client端程序運行，jar包調用先后順序：sp→path→common→client ；
3）金蝶client端與應用服務器建立連接過程：獲取客戶端元數據（調用MetaDataLoaderFactory.setClientMetaDataPath()方法）→獲取啟動模塊（調用SystemEntry.instance.setStartMode()方法）→初始化系統（調用SystemEntry.instance.initSystem()方法）→登陸應用（調用SystemEntry.instance.login()方法）；
4）金蝶client端登出應用服務器方法SystemEntry.instance.logout()。
根據以上幾條，我們編寫調試出登陸腳本，然后加入具體的業務代碼之后，又順利開發調試出某個基礎資料新增腳本（因為金蝶體系固定，基礎資料調試通過，代表其他業務功能也可以調試通過），這樣整個框架就基本搭建完成。
具體的測試環境搭建細節，參見“ERP性能測試框架搭建”。
1.4 測試腳本開發/調試
測試框架搭建完成之后，就可以開始腳本的開發調試工作了。
首先，這部分工作需要交給，各個業務模塊開發員來完成，因為每個模塊的代碼，只有負責的開發員最熟悉。
在腳本開發前，需要對開發員進行一個簡單的培訓，將我們測試的大體背景、目標等告訴他們，同時，可以規定一些腳本編寫規范（如關聯數據庫表，核心業務代碼行數等注釋，為后期場景執行做準備等）。培訓完之后，開發人員先在BOS里面進行開發調試，調試通過后，進行簡單調整，然后復制到loadrunner中（Init和end中存放登陸、登出代碼，詳見“ERP性能測試框架搭建”）即可。
下面，簡單講講腳本開發細節：
金蝶代碼可以分為三種：1、客戶端代碼；2、服務器端代碼；3、共用代碼。客戶端代碼由UI界面發布后生成，通常它的功能是獲取界面數據、對數據進行校驗，增加界面控件監聽（如：監聽新增按鈕，當其被點擊后，調用遠程接口，向數據庫中新增數據），顯示界面等。服務器端代碼是實體（金蝶元數據，用于建立UI、Query等跟數據庫的交互關系）發布生成的，通常可以在里面進行二次編碼，實現具體業務功能，供不同客戶端調用。共用代碼包括接口類、值對象類、枚舉類等一些服務器端、客戶端需要共用的代碼。
目前，ERP開發主要是進行客戶端代碼（*UI.java）及服務器端代碼* （ControllerBean.java）二次開發，而服務端代碼已經部署到服務器上，我們的測試腳本開發只需要編寫客戶端部分即可。當然，客戶端部分可能有很多業務對應的方法，我們不是每個都必須調用，可以根據實際情況進行刪選。一般情況，輸入校驗（insertVerify()）、核心業務（新增、修改、刪除、查詢監聽方法）都必須寫進腳本。
另外，實際業務數據是通過界面輸入，我們腳本開發可以將數據寫死，然后進行參數化即可。
1.5 場景調試/執行
腳本開發完成后，進入場景調試執行階段。
場景調試執行分為：單場景執行、組合場景執行。
首先，我們在單場景執行階段，需要對腳本進行參數化、添加事務、集合點、檢查點、思考時間等操作，注意，如果想要真實模擬生成壓力，需要對所有核心字段進行參數化（如出發部門、到達部門、單據編號、操作人等）。
然后，執行組合場景時，需要對各單場景，在組合場景中的執行結果進行驗證，需要對數據流進行監控，保證參數化數據量充足；可以通過修改每個單場景的虛擬用戶數和思考時間，來調整TPS。
最后，不論是單場景、還是組合場景，執行過程中，都會產生很多的臟數據，每次執行場景后，都需要對這些臟數據進行清理。本次ERP性能測試采用了，一種新的臟數據清理方法：數據庫閃回。
數據庫閃回，首先，需要對數據庫進行設置，開啟閃回服務，設置閃回空間大小；然后，可以通過一系列的操作，完成數據庫閃回：
1）關閉數據庫（srvctl stop database -d erp -o immediate）；
2）進入SqlPlus（sqlplus / as sysdba）；
3）歸檔模式啟動數據庫（startup mount）；
4）執行閃回操作（flashback database TO TIMESTAMP to_timestamp（'2012-04-12 15：10：00'，'yyyy-mm-dd hh24：mi：ss'））；
5）打開數據庫（alter database open resetlogs）
1.6 性能監控分析
在場景執行過程中，可以通過使用性能監控工具，對應用服務器、數據庫服務器進行監控，一般使用nmon。事務響應時間、通過率等過程記錄可以使用loadrunner進行監控。數據庫性能可以使用SQL腳本執行進行監控。
對于一些比較專業的性能指標，比如：本次ERP性能測試需要監控的主實例JVM情況，可以交給數據中心或者開發部門。
性能測試執行過程中，發現環境性能問題后，通常會進行一些調整，這個時候，盡可能將之前執行過的場景重新執行，并進行監控。
關于分析，原則上是需要各個部門共同參與，最好每次舉行一個分析會，召集相關人員參加，并對分析結果進行討論。
1.7 結果報告
在場景執行完成，測試分析結束后，開始進行測試報告編寫。測試報告編寫，要將重點內容放在最前面，要有具體的結果（目標是什么？結果是怎樣？性能是否滿足要求？），而不能只是分散的結果統計。
2、展望
2.1 業務調研及場景確定
現在，業務調研還存在問題：1）沒有真正調研業務部門，都是通過查詢數據庫，或者通過各種其他途徑推算；2）沒有形成一個很好的調研流程及方案；場景方面，并發量、思考時間因為調研不全的等原因，無法準確的確定。這些在后期性能測試過程中，都需要去探索、總結。
2.2 場景監控與分析
目前，場景監控經常出現我們測試一個部門監控，其他部門參與不夠的情況。場景結果也沒有得到很好的分析。其原因，一方面，是我們的技能水平需要提高，另一方面，是如何有效的將各個部門組織參與進來。這些都是我們未來需要進行研究、提升的地方。