性能測試工作不尷尬，但是性能測試崗位很尷尬。
從我這裏的講述中，希望你也能看到其他測試工作的影子，希望你對“點點點”不再迷茫不再抑鬱。
自己水平有限，望大家多多批評。
性能測試的工作內容
這方面的資料很多了，我也不是權威，說不全的。
大致流程：
- 和需求提出方溝通要測什麼，測試的目的等，是否真正需要性能測試。討論測試的方案是否可行，比如一個頁面圖片是不是可以過濾掉，單壓一個接口是不是就可以了。
- 確定測試的環境，測試的人都是誰，測試的時間，同時誰來準備測試數據。
- 根據測試工具如Jmeter或者LoadRunner等等確定寫腳本，調通腳本。
- 執行腳本即壓測，同時觀察壓測的現象。壓測中要自己掌握控制壓測的時間和量，時間短了不行，量過大過小都不行。
- 分析壓測的現象，自己能分析最好，自己分析不了就找別人分析，現象是否達標。
- 如果不達標，要定位性能瓶頸問題，這是最考驗技術功力的。
- 將性能瓶頸問題的修復做迴歸測試。一般或者是改代碼或者是改環境配置。
- 發送測試報告。
最有含金量的部分
- 第一無疑是分析壓測現象和性能調優，包括環境調優。
- 第二是討論溝通需求，不過往往實操中這一步都很水，主要是因爲測試沒啥話語權。
- 第三是寫腳本和準備數據和準備環境（如果有）。
- 第四是執行腳本時配置的併發數等參數及其含義。
性能測試報告
實操中，測試報告往往是很水的一個環節。兩種情況討論：
- 系統性能不好還在修改中，這時候不用發測試報告，還沒改好呢發什麼報告浪費大家時間。
- 系統性能好了才需要發送測試報告，性能都好了啊，其實解釋一下數據就行了。
那麼對測試報告的核心要求很簡單，就是：界面精美權威高大上。
裏面的折線圖重要嗎？已經不重要啦，調優的時候真的重要，但出報告的這個時候這些指標我們已經不頭疼不care了。
裏面的數據結果集重要嗎？重要，所以要醒目。
所以對測試報告，最重要的就是數據結果集展示，就那麼兩行結束，其他都是輔助，來證明測試報告的高大上，來證明性能測試工作的難度和工作量。
所以懂行的無論誰最關心的應該是調優，那些僅僅關心測試報告形式內容的甚至窮追不捨的一般都很low。
前期性能測試需求的溝通
網上去搜這個，肯定是一堆要點並且要有數據計算，比如全天的用戶量是多少，用戶的活躍時間在哪裏，高峯用戶量是多少，二八法則等等。
實際上這些都是很理想化的東西，真正壓測起來肯定會變成：性能越高越好。
這個也是好理解的，誰都想要最好的，同時最後越過最優性能才知道系統瓶頸在哪裏才能調優。
所以，懂行的無論誰最關心的應該是極限壓力測試，容量測試僅僅是附屬品，任何僅僅糾結於容量測試的一般都很low。
同時測試地位的侷限，面對一些明顯是不合理的高要求根本沒有反駁的餘地，答應就是了，等着現實打臉就好了。
其實也沒啥討論計算的地方，總結一下，前期的需求溝通，往往就是知道要測什麼了，告訴開發預期不要太高，就這樣。
例如，我曾經遇到前端每傳入一批新參數就要在數據庫中創建新表，就這種奇葩的架構方案還要高性能，我也是答應而已，坐等現實啪啪打臉。
性能調優的一般內容
性能調優的技術棧
簡單說說性能測試的核心，性能調優包括環境調優。這裏不教你怎麼調優，而是聊聊調優的技術樹。
以Java爲例，看看調優要掌握什麼：
- 底層Linux。
- 基本硬件知識，SSD和磁盤，CPU和內存知識。
- 虛擬化技術。
- 網絡協議，網絡基礎。
- 關係型數據庫，NoSQL，隊列，文件服務器。
- JVM，即Java語言的特性。
- 線程和進程
- 系統架構知識
- 語言算法
- 公司業務
看到這一堆，你發現了什麼？
- 我根本就沒提測試工具的使用！神聖的Jmeter LoadRunner Locust等等這些哪去了？
- 和開發的技術要求基本一樣，甚至包括部分運維的技術樹，甚至超過開發的技術寬度。
說實話，某些開發的Jmeter用的比測試還666666，難不成技術樹裏我還得寫上IDEA/Eclipse嗎？一個工具而已。
一個性能測試沒有性能調優能力會怎麼樣
簡單暴力的就是沒地位，這種技術水平的地位甚至都不如Jmeter一個軟件。
- 出了問題背鍋肯定有你。
- 得了榮譽大頭肯定沒你。
- 平時交流diss的就是你。
- 要點兒資源特別費勁。
- 學習的態度吧，人家開發忙起來了根本顧不上你。
聊聊測試和開發的關係
以性能測試，性能調優爲起點，從工作重合度這個角度聊聊測試和開發的關係。
測試說俗了，就是給開發擦屁股的。
這裏思考下如何擦的都滿意，那塊給你擦，爲什麼給你擦（捂臉）。
開發不屑於做的
開發根本瞧不上的，就是這活如果開發自己幹了人家是覺得浪費時間的。
典型的是“點點點”這種工作，還有各種外包測試同學乾的活。
當然“點點點”這種工作也能點出門道，這後面提，這裏領會精神。
開發能做但是沒時間做的
性能測試，部分自動化測試工作屬於此類。
這也說明了，如果你性能優化水平很low，那開發本來沒時間做的讓你給整成不得不做了，能給你好臉色嗎？
一些簡單的自動集成，自動化部署環境，自動化接口測試等，人家開發自己能做只不過交給你了而已。
開發不一定能做好的
測試開發，部分自動化測試，測試架構師。
測試開發各種工具平臺，開發真不瞭解需求啊，而開發能力大家又是平手，那他真沒把握搶測試開發的飯碗。
自動化測試用例代碼雖然一般，但是用例真心複雜，思維還是要有的，並且很可能存在語言不同，一般做不了。
能督促開發工作的
質量專員，安全測試，白盒測試。
開發之前我就告訴你這麼做有質量風險，你這種架構不安全，得改的這類的。
白盒測試如代碼覆蓋率的測試，不是說隨便發個報告就可以了，而是真的看到代碼的缺點。
不過質量專員很虛，這裏不做深入探討。
安全測試我還不夠了解，感覺也稍微虛。
總結
最值錢的其實就是後兩種，越是開發做不了的越值錢。
測試工作如何值錢
全方位的測試用例設計
千萬不要小瞧測試用例的設計，一個登錄頁面的測試用例設計甚至能寫出來上百種（舉例而已領會精神）。
而用例設計需要考慮的包括但不限於：
- 安全測試用例
- 性能壓力測試用例
- 兼容性測試用例
- 弱環境測試用例
- 特殊功能性測試用例
這需要測試人員對架構，業務，性能，安全，瀏覽器/手機客戶端等等要有一個充足的瞭解。
就算不充足，至少有些方面要有比開發瞭解。
簡單來說，你要測出開發想不到的地方，“點點點”也會值錢。
技術能力強
粗暴的理解，就是，無論什麼時刻，懟開發不帶慫的。
就說性能調優吧，你能直接找出性能瓶頸，甚至以此diss開發水平，指導開發的修改方式，我覺得就不簡單了。
開發對待技術的優勢往往是深度，測試往往是廣度。這個不展開討論了，大家應該有共識。
當然這個需要長時間的積累，技術無止境。
溝通能力強
不多解釋了，測試比開發更需要溝通能力。
業務
你要知道了解開發也掌握不到的業務，比如開發只知其一不知其二的這類。
當然業務很虛，我馬上解釋爲什麼。
對測試來說，業務爲什麼很虛
並非針對所有的行業，也並非針對所有的測試人。這裏只談談一般情況。
開發流程
一個正常的開發流程，需求的路徑從上到下有：
- 需求提出方
- 產品經理
- 開發
- 測試
很簡單就能看到，測試存在於業務的底層。
談談測試比開發懂業務的可能性
是可能的。
但是想一下，需求是產品經理給開發和測試的，你懟開發，開發說是產品讓這麼幹的，然後你懟產品？
有了業務矛盾，開發會聽測試的還是產品的？
談談測試比產品懂業務的可能性
- 需求本身就是產品自己提的
人家自己創造出來的業務，被你測試給生生懟回去了，可能嗎？
- 需求是來自需求方提的，產品設計的
你測試和需求方溝通過了？你要懟，可能嗎？
業務會因跳槽而拋棄
不解釋了，太虛。
聊回性能測試的尷尬
- 性能測試是開發有能力做但是沒時間做的。
- 性能測試幾乎不涉及業務。
就這兩點，除非性能測試人有特別高超的技術能力，其餘都不會受內部重視。
同時性能測試工作時間是高度集中和高度碎片化的，往往這個崗位在公司內是作爲兼職。
最後
性能測試要求高但是往往不值錢，希望大家據我的思考能得到一二。
希望各位對性能測試工作有個認識，同時也能理解什麼樣的測試崗位纔有可能值錢。
希望各位“點點點”不再輕易迷茫抑鬱。
同時，薪水和崗位是匹配的，技術能力不能完全決定薪水高低。
這裏也是粗淺的分析思考，技術不能萬能的，但沒有技術是玩不轉的。
需要軟件測試資料的小夥伴，可以來加羣：747981058。羣內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。