1. 程式人生 > >尷尬的效能測試崗位——順便聊聊 “點點點”

尷尬的效能測試崗位——順便聊聊 “點點點”

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

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

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

效能測試的工作內容

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

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

最有含金量的部分

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

效能測試報告

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

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

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

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

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

前期效能測試需求的溝通

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

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

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

效能調優的一般內容

效能調優的技術棧

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

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

看到這一堆,你發現了什麼?

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

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

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

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

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

聊聊測試和開發的關係

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

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

開發不屑於做的

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

開發能做但是沒時間做的

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

開發不一定能做好的

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

能督促開發工作的

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

總結

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

測試工作如何值錢

全方位的測試用例設計

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

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

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

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

技術能力強

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

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

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

溝通能力強

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

業務

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

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

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

開發流程

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

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

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

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

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

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

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

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

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

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

業務會因跳槽而拋棄

不解釋了,太虛。

聊回效能測試的尷尬

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

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

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

最後

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

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

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

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