在做性能測試的時候，發現自己原來寫的有些東西還是有參考價值的，特共享給大家。
1.1.1. 培訓時間、地點
時間：2008-3-19日至2008-3-23日，共5天，每天上課時間：900－12：30 1：30-5：30 。
地點：海淀區企業培訓中心 ，北京市海淀區中關村南大街3號海淀科技大廈5層。
1.1.2. 培訓單位、人員構成
本次培訓參與的單位有四川某國防物理研究院、大唐、北大方正、大連東軟、解放軍某部隊、海關總署信息中心、安徽軟件測評中心、成都軟件測評中心等16家單位。
這次培訓人數共21人次（中間臨時增加2人次）。大家總體水平相當，大部分人員從事性能測試有1－2年經驗，除了個別學員對工具應用不熟練以外，大部分學員都已經熟練使用Loadrunner性能工具，主要問題在於故障定位上面；大家共同有一個概念就是：軟件越來越複雜、測試越來越難、問題越來越難定位。
1.1.3. 培訓內容
|
培訓時間 |
培訓內容 |
|
2008-3-19 |
軟件測試管理 （關於測試的基本流程、軟件生存週期各階段的測試管理。包括QC測試管理工具的使用。） |
|
2008-3-20 |
軟件性能測試基本理論和loadrunner的使用。 （介紹各種性能測試類型和性能測試策略。） |
|
2008-3-21 |
數據庫的基本理論、oracle數據的優化和loadrunner的高級應用。 |
|
2008-3-22 |
J2EE系統的性能測試 （J2EE系統架構介紹和常用的J2EE架構測試工具介紹和應用。） |
|
2008-3-23 |
軟件性能測試案例剖析、測試經驗交流、測評培訓考試。 |
1.2. 培訓收穫和感受
通過這次培訓，總體感受有如下幾點：（下面簡要描述，詳細內容會在“問題和建議方案”中說明）
1， 老師的理論和實際應用水平相當高，測試工作的流程很清晰，測試什麼，怎麼測試一清二楚 。
2， 軟件測試工作是一個系統工程，每一種測試類型都可以劃分測試需求分析、測試計劃、測試執行、缺陷管理幾個階段，爲此，我們需要有一套合乎自己的測試流程，按部就班，絕對不能隨意浮躁。
3， 測試過程中，測試人員心中一定要有一根弦，時刻想到軟件的質量、項目的進度、項目的成本、測試的風險。
4， 性能測試是軟件測試的一種，同樣有軟件測試的幾個階段，在性能測試過程中，我們一定要在測試之前，對系統有個很好的分析，充分和用戶、開發人員、實施人員溝通性能低下的有關症狀，不要測試一開始就對系統加壓，導致事倍功半，性能測試分析重於測試過程。
5， 通過這次培訓，個人掌握了一些常用的軟件性能測試工具，測試工具對於初學者來說，是相當有用的，能夠很好的輔助測試人員診斷系統問題的大致方向。尤其是oracle的性能監控，不需要測試人員編寫大量的SQL腳本。本次培訓也對loadrunner的高級應用有了較好的掌握，如：關聯技術和web組件分析。
1.3. 問題和建議方案
通過這次培訓，也認識到公司測試工作中存在的一系列問題，主要如下（因爲個人水平等原因，中間表述不當之處，懇請諒解）：
1.3.1. 測試工作流程不清晰
“測試工作流程不清晰”大家可能已經意識到這個問題，但是個人認爲有必要去強調。目前往往系統一上來，直接進入測試執行階段，測試工作階段不明確，在前期的測試需求分析、測試計劃的設計工作上下的功夫不夠，沒有很好的執行測試需求分析＝》測試計劃＝》測試執行＝》缺陷管理這樣一個過程。這樣將導致測試會出現遺漏和過多的反覆。該測試的地方沒有測試到，而部分模塊可能反覆無意義的測試。
對於這個問題：
1， 目前部門領導要求測試人員在TestDirector上編寫測試用例，保證測試覆蓋率。
2， 建議經常性的對測試人員灌輸測試階段、測試流程意識，減少測試工作的隨意性。
3， 建立階段性檢查機制，對於階段性檢查不通過的，不能進入下階段工作，否則上階段存在的問題會帶入下階段。
1.3.2. 測試需求與測試計劃階段要加強
上面提到了測試流程不清晰的問題，主要還是體現在測試前期工作沒有得到重視，測試人員對測試需求與測試計劃階段工作做得不好，測試人員對需求的可測性、測試點把握不夠，不知道系統預期要是個什麼樣子，一旦系統原型出來了以後，測試人員容易被系統所限制住，沒有去從用戶的角度思考問題；在做測試計劃的時候，沒有從項目的進度、質量、成本、風險的全局去考慮，往往只關注測試的時間點，沒有去考慮測試的重點、測試的目的、測試結束的準則、測試的技術難點在哪裏、具體的測試策略、每個測試階段應該關注哪些內容？在培訓期間，老師多次講述了一個概念，就是測試需求和測試計劃的成敗決定了整個測試工作的成敗。
對於這個問題，建議：
1， 加強對測試需求分析、測試計劃編寫的培訓工作，選取有經驗的測試人員對個別系統進行測試需求分析、測試計劃講解，提高測試人員的測試需求分析能力、測試計劃編寫能力；
2， 執行測試需求、測試計劃的評審制度。
3， 要求測試人員嚴格按照測試作業指導書執行；
1.3.3. 測試人員定位不夠明確
因爲公司目前採用的是項目跟蹤制，基本上是一個項目一個測試人員進行跟蹤測試。這樣，一個測試人員需要完成一個項目的測試需求、測試計劃、測試執行、缺陷管理整個過程，實際上，這有不合理的地方。測試的前期工作是需要測試設計人員來做，後期工作是測試執行人員來做的。因爲前期的測試設計工作需要有較高的分析能力，目前公司部分測試人員的水平是達不到的，如果水平較低的測試人員去做測試分析，勢必影響了後面的測試執行，這樣存在一個人員定位不明確的問題。
針對這個問題，個人建議：
1， 在相同人力資源的情況下，多個測試人員交叉測試一個項目，能力強的，做測試分析和計劃工作，能力弱的做測試執行工作，相互檢查和監督。就像多個程序員可以開發一套系統，多個測試員同樣可以測試一個系統。
2， 嘗試採用測試項目管理制度，把測試當作一個項目來管理，保證測試人員角色明確。
3， 測試人員能力提升、團隊建設是當務之急。
1.3.4. 加強oracle方面的學習
在培訓過程中，老師列舉了大量的性能測試案例，有一大半是數據庫上面出現了問題。特別是oracle數據庫出現了性能瓶頸，大部分是開發人員在SQL編寫的時候沒有考慮周到。
對於這個問題：
1，除了加強oracle數據庫的學習，沒有別的辦法；
1.4. 測試經驗共享
通過課時和老師的互動，以及個人平時的經驗，下面我對怎麼做好性能測試做了一些經驗共享：
1， 做性能測試之前，務必多瞭解客戶要求的性能指標，找出系統的性能測試點。做性能測試需求時，一定要儘可能考慮最壞的情況。如分析出某個系統的“最大訪問量日”後，還得分析出“最大訪問量日”那天的高峯期。
2， 性能測試的主要策略有三個步驟（根據系統情況選擇下面的幾個步驟）：
A：模擬試驗室環境，主要保證錄製測試腳本的正確性；主要功能的正確性；錄製出符合用戶業務流程、訪問習慣的腳本，因爲一到了後面執行測試時，腳本錄製往往就沒有時間了。
B：上線前的機房環境，主要是避開網絡的影響，找出系統的最優配置。
C：試運行環境，需要把網絡的因素考慮進去，把防火牆、交換機等設備加上。同時需要考慮別的系統接口的性能，做聯合調試和調優。
3， 在執行性能測試之前，先需要對系統的配置進行檢查，包括硬件和軟件，對於不合理的配置，需要先做調優以後再測試，否則對於性能本身很低下、系統配置不合理的系統，測試就失去意義。
4， 在用測試工具做性能測試時，先務必保證腳本的正確性，該做參數化處理的地方需要做參數化處理，對於服務器返回來的變量（如：sessionID）該做關聯的做關聯，腳本的正確性是後面測試成功的基礎。
5， 對於不停機的系統，一定要做疲勞強度的測試，測試的重點一般主要在內存泄漏上。
6， 對於分佈式部署系統的性能調優，先得確定問題的大方向，如：問題是出現在web服務器、還是應用服務器、還是數據庫服務器，問題一層一層的排除。在確定了某一層以後，然後看是否是系統資源的問題，還是系統配置的問題，逐步深入找到瓶頸。
7， 在測試時，一定要考慮基數數據對系統性能的影響，數據庫中有1萬條記錄和有100萬條記錄的性能肯定是不同的。在準備性能測試數據時，和功能測試的情況差不多，要分不同的數據類型、不同的數據大小（如：附件上傳和下載）、不同的交易類型來準備，以保證最大限度的模擬實際情況。
8， 系統調優的重點：
A：數據庫方面：主要是數據庫內存配置、SQL優化、SQL事件跟蹤。SQL優化是先優化語法，在優化業務方面。大的數據表不要放到一個表/磁盤中，該分區就分區。部分表根據情況適當的建立索引。對於大數據量的歷史數據表，該建立離線數據庫的建立離線數據庫。
B：系統資源方面：一般還是從大方面入手，CPU利用率、可用物理內存、磁盤處理時間，只有大的方面有問題，纔去跟蹤下去。
C：web服務器上面：主要是JVM的配置情況、線程池、數據庫連接池的配置。
D：網絡：帶寬和吞吐情況；
E：應用程序：主要看事務處理時間，看大部分事務處理是否分佈在平均事務處理時間附近。其他得問題則A-D入手。對於具體得類/方法處理效率可以通過BCI技術（字節碼插入）跟蹤，其他的就是系統設計的問題。
9， 性能測試需要重點關注幾個指標：
A：併發用戶數：反應的是用戶容量；
B：平均響應時間：反應的是系統的服務等級（參照微軟的：3-5-8原則）；
C：交易吞吐量：系統每秒處理的能力；
10， 最後一點，也是最重要的一點：性能測試的大忌就是急躁，對測試結果需要仔細的分析，找出相應的原因。
