效能測試工作不尷尬，但是效能測試崗位很尷尬。

從我這裡的講述中，希望你也能看到其他測試工作的影子，希望你對“點點點”不再迷茫不再抑鬱。

自己水平有限，望大家多多批評。

效能測試的工作內容

這方面的資料很多了，我也不是權威，說不全的。
大致流程：

• 和需求提出方溝通要測什麼，測試的目的等，是否真正需要效能測試。討論測試的方案是否可行，比如一個頁面圖片是不是可以過濾掉，單壓一個介面是不是就可以了。
• 確定測試的環境，測試的人都是誰，測試的時間，同時誰來準備測試資料。
• 根據測試工具如Jmeter或者LoadRunner等等確定寫指令碼，調通指令碼。
• 執行指令碼即壓測，同時觀察壓測的現象。壓測中要自己掌握控制壓測的時間和量，時間短了不行，量過大過小都不行。
• 分析壓測的現象，自己能分析最好，自己分析不了就找別人分析，現象是否達標。
• 如果不達標，要定位效能瓶頸問題，這是最考驗技術功力的。
• 將效能瓶頸問題的修復做迴歸測試。一般或者是改程式碼或者是改環境配置。
• 傳送測試報告。

最有含金量的部分

• 第一無疑是分析壓測現象和效能調優，包括環境調優。
• 第二是討論溝通需求，不過往往實操中這一步都很水，主要是因為測試沒啥話語權。
• 第三是寫指令碼和準備資料和準備環境（如果有）。
• 第四是執行指令碼時配置的併發數等引數及其含義。

效能測試報告

實操中，測試報告往往是很水的一個環節。兩種情況討論：

• 系統性能不好還在修改中，這時候不用發測試報告，還沒改好呢發什麼報告浪費大家時間。
• 系統性能好了才需要傳送測試報告，效能都好了啊，其實解釋一下資料就行了。

那麼對測試報告的核心要求很簡單，就是：介面精美權威高大上。

裡面的折線圖重要嗎？已經不重要啦，調優的時候真的重要，但出報告的這個時候這些指標我們已經不頭疼不care了。
裡面的資料結果集重要嗎？重要，所以要醒目。

所以對測試報告，最重要的就是資料結果集展示，就那麼兩行結束，其他都是輔助，來證明測試報告的高大上，來證明效能測試工作的難度和工作量。
所以懂行的無論誰最關心的應該是調優，那些僅僅關心測試報告形式內容的甚至窮追不捨的一般都很low。

前期效能測試需求的溝通

網上去搜這個，肯定是一堆要點並且要有資料計算，比如全天的使用者量是多少，使用者的活躍時間在哪裡，高峰使用者量是多少，二八法則等等。
實際上這些都是很理想化的東西，真正壓測起來肯定會變成：效能越高越好。
這個也是好理解的，誰都想要最好的，同時最後越過最優效能才知道系統瓶頸在哪裡才能調優。
所以，懂行的無論誰最關心的應該是極限壓力測試，容量測試僅僅是附屬品，任何僅僅糾結於容量測試的一般都很low。

同時測試地位的侷限，面對一些明顯是不合理的高要求根本沒有反駁的餘地，答應就是了，等著現實打臉就好了。
其實也沒啥討論計算的地方，總結一下，前期的需求溝通，往往就是知道要測什麼了，告訴開發預期不要太高，就這樣。

例如，我曾經遇到前端每傳入一批新引數就要在資料庫中建立新表，就這種奇葩的架構方案還要高效能，我也是答應而已，坐等現實啪啪打臉。

效能調優的一般內容

效能調優的技術棧

簡單說說效能測試的核心，效能調優包括環境調優。這裡不教你怎麼調優，而是聊聊調優的技術樹。
以Java為例，看看調優要掌握什麼：

• 底層Linux。
• 基本硬體知識，SSD和磁碟，CPU和記憶體知識。
• 虛擬化技術。
• 網路協議，網路基礎。
• 關係型資料庫，NoSQL，佇列，檔案伺服器。
• JVM，即Java語言的特性。
• 執行緒和程序
• 系統架構知識
• 語言演算法
• 公司業務

看到這一堆，你發現了什麼？

• 我根本就沒提測試工具的使用！神聖的Jmeter LoadRunner Locust等等這些哪去了？
• 和開發的技術要求基本一樣，甚至包括部分運維的技術樹，甚至超過開發的技術寬度。

說實話，某些開發的Jmeter用的比測試還666666，難不成技術樹裡我還得寫上IDEA/Eclipse嗎？一個工具而已。

一個性能測試沒有效能調優能力會怎麼樣

簡單暴力的就是沒地位，這種技術水平的地位甚至都不如Jmeter一個軟體。

• 出了問題背鍋肯定有你。
• 得了榮譽大頭肯定沒你。
• 平時交流diss的就是你。
• 要點兒資源特別費勁。
• 學習的態度吧，人家開發忙起來了根本顧不上你。

聊聊測試和開發的關係

以效能測試，效能調優為起點，從工作重合度這個角度聊聊測試和開發的關係。

測試說俗了，就是給開發擦屁股的。
這裡思考下如何擦的都滿意，那塊給你擦，為什麼給你擦（捂臉）。

開發不屑於做的

開發根本瞧不上的，就是這活如果開發自己幹了人家是覺得浪費時間的。
典型的是“點點點”這種工作，還有各種外包測試同學乾的活。
當然“點點點”這種工作也能點出門道，這後面提，這裡領會精神。

開發能做但是沒時間做的

效能測試，部分自動化測試工作屬於此類。
這也說明了，如果你效能優化水平很low，那開發本來沒時間做的讓你給整成不得不做了，能給你好臉色嗎？
一些簡單的自動整合，自動化部署環境，自動化介面測試等，人家開發自己能做只不過交給你了而已。

開發不一定能做好的

測試開發，部分自動化測試，測試架構師。
測試開發各種工具平臺，開發真不瞭解需求啊，而開發能力大家又是平手，那他真沒把握搶測試開發的飯碗。
自動化測試用例程式碼雖然一般，但是用例真心複雜，思維還是要有的，並且很可能存在語言不同，一般做不了。

能督促開發工作的

質量專員，安全測試，白盒測試。
開發之前我就告訴你這麼做有質量風險，你這種架構不安全，得改的這類的。
白盒測試如程式碼覆蓋率的測試，不是說隨便發個報告就可以了，而是真的看到程式碼的缺點。
不過質量專員很虛，這裡不做深入探討。
安全測試我還不夠了解，感覺也稍微虛。

總結

最值錢的其實就是後兩種，越是開發做不了的越值錢。

測試工作如何值錢

全方位的測試用例設計

千萬不要小瞧測試用例的設計，一個登入頁面的測試用例設計甚至能寫出來上百種（舉例而已領會精神）。
而用例設計需要考慮的包括但不限於：

• 安全測試用例
• 效能壓力測試用例
• 相容性測試用例
• 弱環境測試用例
• 特殊功能性測試用例

這需要測試人員對架構，業務，效能，安全，瀏覽器/手機客戶端等等要有一個充足的瞭解。
就算不充足，至少有些方面要有比開發瞭解。

簡單來說，你要測出開發想不到的地方，“點點點”也會值錢。

技術能力強

粗暴的理解，就是，無論什麼時刻，懟開發不帶慫的。

就說效能調優吧，你能直接找出效能瓶頸，甚至以此diss開發水平，指導開發的修改方式，我覺得就不簡單了。

開發對待技術的優勢往往是深度，測試往往是廣度。這個不展開討論了，大家應該有共識。
當然這個需要長時間的積累，技術無止境。

溝通能力強

不多解釋了，測試比開發更需要溝通能力。

業務

你要知道了解開發也掌握不到的業務，比如開發只知其一不知其二的這類。
當然業務很虛，我馬上解釋為什麼。

對測試來說，業務為什麼很虛

並非針對所有的行業，也並非針對所有的測試人。這裡只談談一般情況。

開發流程

一個正常的開發流程，需求的路徑從上到下有：

• 需求提出方
• 產品經理
• 開發
• 測試

很簡單就能看到，測試存在於業務的底層。

談談測試比開發懂業務的可能性

是可能的。
但是想一下，需求是產品經理給開發和測試的，你懟開發，開發說是產品讓這麼幹的，然後你懟產品？
有了業務矛盾，開發會聽測試的還是產品的？

談談測試比產品懂業務的可能性

• 需求本身就是產品自己提的

人家自己創造出來的業務，被你測試給生生懟回去了，可能嗎？

• 需求是來自需求方提的，產品設計的

你測試和需求方溝通過了？你要懟，可能嗎？

業務會因跳槽而拋棄

不解釋了，太虛。

聊回效能測試的尷尬

• 效能測試是開發有能力做但是沒時間做的。
• 效能測試幾乎不涉及業務。

就這兩點，除非效能測試人有特別高超的技術能力，其餘都不會受內部重視。

同時效能測試工作時間是高度集中和高度碎片化的，往往這個崗位在公司內是作為兼職。

最後

效能測試要求高但是往往不值錢，希望大家據我的思考能得到一二。

希望各位對效能測試工作有個認識，同時也能理解什麼樣的測試崗位才有可能值錢。
希望各位“點點點”不再輕易迷茫抑鬱。

同時，薪水和崗位是匹配的，技術能力不能完全決定薪水高低。
這裡也是粗淺的分析思考，技術不能萬能的，但沒有技術是玩不轉的。

需要軟體測試資料的小夥伴，可以來加群：747981058。群內會有不定期的發放免費的資料連結，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。