針對B/S客戶端進行性能測試的時候，會遇到很多技術難點，往往成為性能測試的礁石。有些難題，雖然看起來是個小問題，但是如果沒有科學的解決辦法，往往會影響整個測試項目的進度，帶來很大的損失。
基于以往性能測試項目的經驗，本文總結了針對B/S客戶端進行性能測試時遇到的多個關鍵技術問題，愿與業內同行進行深入探討，共同提升測試能力。
1、性能測試腳本錄制最重要的地方
性能測試腳本錄制最重要的地方，個人認為有以下三個方面：
第一，在性能測試之前要先做程序的功能驗證。這是最開始要做的事情，要確保廠商程序的被測功能點都是正確的。功能驗證都不通過，性能測試所做的一切都沒有意義了，同時，功能驗證的過程也是熟悉業務的過程，對于測試工程師非常重要；
第二，參數化分析。雖然參數化本身非常重要，但是更重要的是參數化的分析，要分析哪些值需要做參數化，這才是關鍵；
第三，做關聯。做關聯可能是最難了，因為需要分析服務器返回的數據，要對程序的流程有個徹底的了解。做關聯的難點還是對程序流程的理解，并不是關聯本身。
2、測試腳本的第一次錄制
對B/S客戶端進行第一次腳本錄制，測試工程師需要注意以下幾個方面：
1）在測試腳本錄制之前，測試工程師應該已經對測試規范進行熟悉了，第一次腳本錄制的目的之一就是要按照測試規范實際進行一步步的操作，看看是否會遇到一些報錯的問題；
2）通過第一次腳本錄制，測試工程師需要了解被測程序的各個功能是否已經實現以及實現的方式是怎么樣的。雖然是性能測試，但是對于功能的理解，流程的把握是相當重要的；
3）B/S性能測試腳本里面，核心的問題就是要把參數化做好。所以第一次錄制腳本，測試工程師要仔細的觀察程序變化，要看一看哪些地方是需要做參數化的，以及做參數化的難易程度問題。
3、在測試腳本里找不到需要參數化的那個值
問題描述：按照測試規范的要求，需要對一個數值進行參數化，但是在腳本中沒有發現這個值，參數化無法進行。
解決方法：這是屬于廠商實現機制的問題，測試工程師需要和廠商進行溝通，讓廠商修改程序，使被參數化的值能夠在腳本中顯露出來，這樣，性能測試才可能順利進行。
4、參數文件里不能有空行
問題描述：在實際測試中，我們配置了11個參數文件，跑10個循環沒有錯誤，很正常，但是跑100個就報錯了。
解決方法：把報錯的鏈接從IE中打開，發現有幾個值是空的，因此而報錯。打開腳本，看參數文件，界面里顯示的確實是11個值，沒有更多的值了，但是從記事本里把參數文件打開，按Ctrl+A，發現在后面幾行里有空行，就是因為這個空行才報的錯。所以發現，參數文件里不能有空行，對于空行，系統也是識別的。
5、極限測試中測試終止條件必須定義明確
問題描述：起初，性能測試終止條件定義的是CPU的最高值以及事物通過率的最低值，后來發現這些條件其實都是很難達到的。尤其在極限測試的時候，終止條件顯得尤其重要，沒有終止條件就沒有辦法達到極限了。
解決方法：需要定義更細的終止條件，而且在一定的時間內能夠達到，要不然無法進行極限測試。
6、用LoadRunner監控Linux及Unix資源不穩定
問題描述：用LR監控Linux及Unix資源，有時監控會斷掉，就無法監控資源了
解決方法：有時候確實會出現這個問題，所以在實際測試中首先要用LR對服務器進行監控，同時使用服務器自身的NMON函數來收集數據，把應用服務器和數據庫服務器的CPU、內存、硬盤IO等的值都收集下來。
7、使用NMON函數要注意的事項
第一，NMON函數是在服務器端本地啟動的，所以每次使用都需要登陸到服務器把NMON打開。查看NMON是否打開的命令是：ps –ef|grep nmon。
第二，NMON函數的原理是把每次收集的數據都放到了一個文件里，所以每次開始新一輪的測試，都需要關閉上一次開啟的NMON，然后打開一個新的NMON，以便容易區分數據。
第三，要把時間校準好。作為控制臺的那臺測試機的時間、應用服務器的時間、數據庫服務器的時間，這三個時間要校準，沒有必要去確認哪個時間準確，需要做的是把這三個時間的差別算出來，要以做控制臺的測試機的時間為基準。