與以前使用性能工具和終端性能測試做的方式不同，自己親自部署的性能環境對性能測試的理解，還有測試的經驗以及對性能測試開發的一些功底都是一個考驗，因為這次是從一行代碼都沒有到個人發布的第一版性能測試程序（用例）間解決很多難題，所以趁現在有空閑時間備忘下這次做偏網絡性能測試的經歷。
設計階段的時候一定需要弄清楚這次性能測試的目的和要點。與用lr的web網頁性能測試不同，我是測試更底層或者說是網絡層的性能。與手工測試不同，做性能測試務必有需求，即使沒有需求都需要組織會議來自己定制一套需求。在做性能測試的經驗中，70%~80%是做和開發組相似的工作，所以沒有需求的話，寫著寫著就會融入自己的主觀誤區，很容易寫出來的東西根本不符合項目組的要求，尤其是做socket的編程。對于網絡相關的測試，不用太過于關注一些平常web性能的指標，最重點關注是每秒的處理數，服務器的極限值，模擬真實的流程還有根據這些設置值來定制出一個產品的性能說明書。主要的設計參考為同類產品的對比，主流服務器的性能指標，還有產品的峰值。
部署性能測試開發階段需要根據你的設計和項目組或你自身水平（實際項目由我個人弄）來評定需要那些東西來做開發活動。對于測試開發來說，偏應用的語言和腳本是相對好用的。大多情況下我會選擇做常鏈接不錯的java和資料充足的python腳本來制作測試開發，假如是有圖形界面的話C++和java是比較好的選擇。為什么我會重點提這3個語言，我經歷過的自動化組雖然不是全部都用以上的語言，但是在google強大的開源帝國中提供了很多自動化測試框架和模塊（例如安卓的java robotium，C++的GoogleTest，支持很多API和多個linux支持的python）本身就帶有優勢。重點在于這3個語言對oracle或其他數據庫都有很好的交互，性能測試很少不和數據庫打交道。其次也可以選擇你很熟悉的語言做自動化。
開發環境搭建階段，做測試核心之一的就是返回結果來對期望結果進行匹配，你獲取結果的地方最多就是在服務器端，很多時候我們在windows開發，獲取結果在linux服務器，所以搭建開發環境對編譯器，對打包的工具，對一些項目組現有的工具，還有各自操作系統帶有的小工具都要進行考量。必要時甚至可以用lr和QTP來輔助。同時要對項目的協議進行分析，解析包，把底層交互的接口都編寫完整，當然項目組做了給你更加好。
程序設計階段，好比做C++開發和數據庫開發的理念不同，做測試開發也有著不同的理念。我們本身是測試代碼，在我此次項目經歷考量的最多就是操作系統，編譯器，公司網絡，本身語言對網絡方面的性能和限制。我們做的不是安全防御，不是應用系統，最終目的是提出一個說明書和提交bug，所以我們需要知道我們執行程序發現的問題是產品問題還是上述問題，即使用lr測試也是如此。這里說下幾個理論：我們的程序做到什么程度？平臺化？程序化？腳本化？因為負責的只有我一個人，所以只做到腳本化。還有腳本的分布。因為我們是用例，而且大多是性能用例，不像別的功能用例自動一個個串行執行。所以在我選擇了功能強大的語言時我的測試腳本分為應用層（執行用例的函數），特性層（linux，windows，數據庫，網絡編程的特性函數），忽略底層（因為語言已經封裝很好） ，然后因為性能用例的特征做了一個選擇的接口層（每次每臺測試機只執行一個性能用例），然后根據用例的目的進行分類，測試模擬真實環境的性能指標用例，測試負載的峰值指標用例，測試壓力的用例（分測試客戶端用例和備用客戶端用例，往往壓力掛了，自主開發的主用例很難再去給壓壞的服務器做判斷）
測試的部署階段，當你的用例第一版正式投入測試的時候，需要關注的是：你實現壓力的方式，綜合客戶端和綜合服務器的限制。例如lr這樣的性能工具是怎么做到超越一般的并發數的，是靠巧妙的編程方式還是通過提供的服務器，在我自己弄整個過程，我大概也摸清了一小部分lr的底。除了評估出各方面性能所需要準備的測試機外，最重要是如何以最小的代價抓出最多的bug日志，打印日志算是一個影響機子性能的關鍵點。
總結：下一步不管網頁相關的性能是由我做還是使用lr工具，最重要還是要提高代碼的函數通用性，我經歷的測試組的代碼很多封裝的慘不忍睹，因為很多測試人員測試時抽空出來寫自動化用例不可能會像開發那么專心。其次是繼續提升自己對操作系統，數據庫和網絡本身的一些基本配置問題要更加了解，我提交很多致命單往往都是很簡單的東西造成的。最后要按需求走，每做一個改動和新增要知道自己測試和發現的是自己的程序性能問題，還是局域網絡問題，或者是原生產品操作系統問題，排除完后提交bug。
小數據：總編寫時間3~4個星期的腳本在一個迭代中發現了15個嚴重級別或以上的單。自己編寫性能腳本效率在初中期開發其實不比lr差。