尷尬的性能測試崗位——順便聊聊「點點點」

性能測試工做不尷尬，可是性能測試崗位很尷尬。

從我這裏的講述中，但願你也能看到其餘測試工做的影子，但願你對「點點點」再也不迷茫再也不抑鬱。

本身水平有限，望你們多多批評。

性能測試的工做內容

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

• 和需求提出方溝通要測什麼，測試的目的等，是否真正須要性能測試。討論測試的方案是否可行，好比一個頁面圖片是否是能夠過濾掉，單壓一個接口是否是就能夠了。
• 肯定測試的環境，測試的人都是誰，測試的時間，同時誰來準備測試數據。
• 根據測試工具如Jmeter或者LoadRunner等等肯定寫腳本，調通腳本。
• 執行腳本即壓測，同時觀察壓測的現象。壓測中要本身掌握控制壓測的時間和量，時間短了不行，量過大太小都不行。
• 分析壓測的現象，本身能分析最好，本身分析不了就找別人分析，現象是否達標。
• 若是不達標，要定位性能瓶頸問題，這是最考驗技術功力的。
• 將性能瓶頸問題的修復作迴歸測試。通常或者是改代碼或者是改環境配置。
• 發送測試報告。

最有含金量的部分

• 第一無疑是分析壓測現象和性能調優，包括環境調優。
• 第二是討論溝通需求，不過每每實操中這一步都很水，主要是由於測試沒啥話語權。
• 第三是寫腳本和準備數據和準備環境（若是有）。
• 第四是執行腳本時配置的併發數等參數及其含義。

性能測試報告

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

• 系統性能很差還在修改中，這時候不用發測試報告，還沒改好呢發什麼報告浪費你們時間。
• 系統性能好了才須要發送測試報告，性能都好了啊，其實解釋一下數據就好了。

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

裏面的折線圖重要嗎？已經不重要啦，調優的時候真的重要，但出報告的這個時候這些指標咱們已經不頭疼不care了。
裏面的數據結果集重要嗎？重要，因此要醒目。

因此對測試報告，最重要的就是數據結果集展現，就那麼兩行結束，其餘都是輔助，來證實測試報告的高大上，來證實性能測試工做的難度和工做量。
因此懂行的不管誰最關心的應該是調優，那些僅僅關心測試報告形式內容的甚至窮追不捨的通常都很low。

前期性能測試需求的溝通

網上去搜這個，確定是一堆要點而且要有數據計算，好比全天的用戶量是多少，用戶的活躍時間在哪裏，高峯用戶量是多少，二八法則等等。
實際上這些都是很理想化的東西，真正壓測起來確定會變成：性能越高越好。
這個也是好理解的，誰都想要最好的，同時最後越過最優性能才知道系統瓶頸在哪裏才能調優。
因此，懂行的不管誰最關心的應該是極限壓力測試，容量測試僅僅是附屬品，任何僅僅糾結於容量測試的通常都很low。

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

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

性能調優的通常內容

性能調優的技術棧

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

• 底層Linux。
• 基本硬件知識，SSD和磁盤，CPU和內存知識。
• 虛擬化技術。
• 網絡協議，網絡基礎。
• 關係型數據庫，NoSQL，隊列，文件服務器。
• JVM，即Java語言的特性。
• 線程和進程
• 系統架構知識
• 語言算法
• 公司業務

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

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

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

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

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

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

聊聊測試和開發的關係

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

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

開發不屑於作的

開發根本瞧不上的，就是這活若是開發本身幹了人家是以爲浪費時間的。
典型的是「點點點」這種工做，還有各類外包測試同窗乾的活。
固然「點點點」這種工做也能點出門道，這後面提，這裏領會精神。

開發能作可是沒時間作的

性能測試，部分自動化測試工做屬於此類。
這也說明了，若是你性能優化水平很low，那開發原本沒時間作的讓你給整成不得不作了，能給你好臉色嗎？
一些簡單的自動集成，自動化部署環境，自動化接口測試等，人家開發本身能作只不過交給你了而已。

開發不必定能作好的

測試開發，部分自動化測試，測試架構師。
測試開發各類工具平臺，開發真不瞭解需求啊，而開發能力你們又是平手，那他真沒把握搶測試開發的飯碗。
自動化測試用例代碼雖然通常，可是用例真心複雜，思惟仍是要有的，而且極可能存在語言不一樣，通常作不了。

能督促開發工做的

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

總結

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

測試工做如何值錢

全方位的測試用例設計

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

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

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

簡單來講，你要測出開發想不到的地方，「點點點」也會值錢。

技術能力強

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

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

開發對待技術的優點每每是深度，測試每每是廣度。這個不展開討論了，你們應該有共識。
固然這個須要長時間的積累，技術無止境。

溝通能力強

很少解釋了，測試比開發更須要溝通能力。

業務

你要知道了解開發也掌握不到的業務，好比開發只知其一不知其二的這類。
固然業務很虛，我立刻解釋爲何。

對測試來講，業務爲何很虛

並不是針對全部的行業，也並不是針對全部的測試人。這裏只談談通常狀況。

開發流程

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

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

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

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

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

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

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

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

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

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

業務會因跳槽而拋棄

不解釋了，太虛。

聊回性能測試的尷尬

• 性能測試是開發有能力作可是沒時間作的。
• 性能測試幾乎不涉及業務。

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

同時性能測試工做時間是高度集中和高度碎片化的，每每這個崗位在公司內是做爲兼職。

最後

性能測試要求高可是每每不值錢，但願你們據個人思考能獲得一二。

但願各位對性能測試工做有個認識，同時也能理解什麼樣的測試崗位纔有可能值錢。
但願各位「點點點」再也不輕易迷茫抑鬱。

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

須要軟件測試資料的小夥伴，能夠來加羣：747981058。羣內會有不按期的發放免費的資料連接，這些資料都是從各個技術網站蒐集、整理出來的，若是你有好的學習資料能夠私聊發我，我會註明出處以後分享給你們。