問題:能否先簡單談談您在測試領域的工作經驗?和您對此領域的理解?
宗剛:我的工作經驗主要分成三個階段:
第一階段:民企開發Leader
畢業后做程序員,負責開發維護6個產品。解決過多次關鍵性能問題,其中有一次系統跑批2小時后死機,通過我的優化最后只需要15分鐘完成,協助業務部門打了一個大勝戰。06年開始在項目組自下而上推一些敏捷實踐。因為有開發編程以及敏捷工程的基礎,為我后期進行大型系統性能測試、優化、規劃以及提出全生命周期敏捷性能管理體系打下了堅實的基礎。
第二階段:創業公司負責人
和幾位朋友一起創業,負責公司兩個產品的運作,測試、開發、需求、業務、銷售、人力各種工作都干過。雖然結果不太理想,但這個階段磨練我從整體去看一個產品,從開發、測試、產品系統看問題,而不會局限于研發。
第三階段:惠普非功能技術負責人
到惠普后,作為團隊非功能技術負責人,推行敏捷軟件開發,推行安全測試,提出性能測試優化建模整體服務整體解決系統上線過程中的技術難題,提出全生命周期敏捷性能與容量管理體系解決系統整個生命周期的性能與容量難題,提出交維服務系統解決從研發到運維的技術、流程等問題。主要為國內金融、電信、政府核心系統進行非功能服務。曾在創金融領域全球最高TPS(HP開放平臺)的項目擔任性能技術專家?;萜帐且粋€很大的平臺,各種資源都有,性能測試工具、監控工具、刀片、小機、存儲、網絡、操作系統以及各種領域專家,最重要的是有很多大型應用系統的客戶,非常有利于性能技術成長。
對于測試領域的理解:
A、從測試領域職業發展來看,將來的測試有兩條比較好的出路,一條為業務專家,懂得某業務領域知識如金融、電信、建筑等等有行業壁壘的知識;另一條為測試技術專家,會編程是基礎,能夠做技術含量比較高的測試。原來主要點擊幾下鼠標的黑盒測試競爭會越來越激烈,由于知識壁壘有限,大量的高校畢業生輕易進入這個領域,很難出高薪。前幾年是測試領域的原始積累期,很多技術能力不強的人能成為領導、經理,將來這種可能性越來越小。
B、性能測試領域現在還缺少標準,市面上的培訓以及書籍多數以工具為主,沒有系統解決性能問題關注性能測試為主。
問題:能否簡述企業中性能測試現狀?
宗剛:從09年的淘寶雙十一導致多家銀行網銀系統宕機,到12306購票難,再到前不久聚美優品促銷活動剛開始就遭秒殺。根據Google的統計,如果網站打開慢每500毫秒,用戶訪問量將下降20%。根據Amazon統計,每慢100毫秒,交易額下降1%。這些事件和統計數據為大家敲響了警鐘,企業也會越來越重視性能測試。
企業性能測試常見問題:
A、缺少整體性能與容量管理策略,常常臨時抱佛腳,見過用20人年開發的系統上線之后系統性能完全無法瞞住要求,重新開發
B、UAT階段才做測試。為時太晚,很多問題這個階段無法解決或解決成本非常高
C、運維與研發缺乏互動。沒有形成生產與研發的閉環,測試結果脫離實際,見過通過大量性能測試的系統上線之后就宕機
D、缺少性能優化和規劃。只有性能測試報告,定位不了問題,提出不了建議,對于生產系統的容量和性能缺少規劃,不清楚系統的容量,無法支持有效的業務決策。
問題:能否描述一下性能測試人員的現狀?
宗剛:11和12年分別在北京、上海、深圳面試了近100位性能測試人員,主要的特點如下:
A、性能測試人員出身比較復雜,有開發經驗的人員能力和潛力都強于其他。由于性能測試項目比較少,所以不同角色的人遇到這種項目,就成為性能測試人員。由于性能測試對人員要求的技術比較高,相對之下有開發經驗的人員學習速度要快得多。就拿我自己舉例,由于有4年的開發經驗,通過兩個項目的實踐就可以靈活掌握性能測試,1年掌握的東西相當于沒有開發經驗的3年。
B、多數性能測試人員都以工具為主,缺少系統解決性能問題的能力。見過一個項目的性能測試人員只懂通過loadrunner設置場景發起壓力,根本不會性能監控和瓶頸定位,測試的數據壓倒生產庫都不知道。
C、從面試的整體來看北京的技術能力稍強于其它地區,基本上為北京>上海>深圳。
D、很多“資深”性能測試的人員由于停留于幾年以前會loadrunner就是專家的時代,技能沒有提升,陷入“上不去,下不來”的尷尬境地。
E、多數人員習慣于從測試看問題,缺少整體視角解決性能問題。個人建議從產品經理的角度看問題,因為一個產品其實就是一個小型企業,從這個角度看成本、創新、流程、質量就比較有意義,抓住了本質。
F、性能測試領域非常缺人才,缺少精通性能測試,同時熟悉各層性能優化的人才。見過好幾個企業有若干個OS、中間件、DB性能優化專家,但是解決不了性能問題,缺少整體貫通的人員。
問題:你如何理解性能測試在軟件生命周期中的位置?
宗剛:性能測試應該貫穿整個軟件的生命周期,從需求到架構到迭代到上線再到運維都和性能測試息息相關。下圖為借鑒了敏捷性能工程的思路整理出來的一個全生命周期性能管理圖。
主要分成4個大階段:
A、計劃階段:
編寫可測試的性能需求:詳細說明可落地可測試的需求,而不是籠統的寫著一天支持1.5億的交易,支持1億的用戶。
性能測試策略:需要提前考慮怎么進行性能測試,用什么工具?需要哪些培訓等等 在產品代辦列表里增加性能活動:由于性能測試一般實施周期比較長,建議單獨成為一個列表項。
B、架構評估:
在系統架構階段,在實現部分關鍵功能的情況下評估系統性能、容量、安全、可擴展性、穩定性等等是否滿足系統設計的需要,我們常常缺少這個階段的實踐,等系統開發結束才進行,常常為時已晚。在系統規劃時常常在缺少實際測試數據的時候拍腦袋規劃硬件,出現“大馬拉小車”的局面,架構評估的另一個作用是通過架構階段的評估為規劃提供數據支持。
原文轉自:http://www.blogjava.net/qileilove/archive/2013/04/16/397896.html