測試架構師

轉載自：http://blog.163.com/tech_qa/blog/static/130176349200991611173682/

在測試行業幹了有些年了，如今中國帶領一個測試架構師團隊。回想當年幹了一年軟件測試後，發如今中國幾乎沒有什麼軟件測試的招聘信息，感到將來的迷茫。在迷茫中動搖過，痛苦過，甚至短暫離開過一線測試工做，但一直都仍是圍繞着軟件測試這條主線在工做和發展，也許命中註定應該走下去吧。從一個普通的軟件測試工程師，走到了自動化測試工程師，系統測試工程師，測試諮詢，測試服務，一個測試架構師，帶領一個測試架構師團隊，親自領導和負責一個大產品線70多測試人員的測試技術規劃和測試質量改進，所帶測試架構師團隊覆蓋的測試人員達100人。

 

 

若是把測試的能力分爲工程能力與研究能力，那麼我在從事測試架構師以前的能力應該大部分都是工程能力，51testing上99％的文章應該都屬於工程能力，傳統測試活動更多側重單個測試實現技術。而從事測試架構師後主要須要的能力應該是研究能力，更多側重對整個產品或產品線當前版本，將來版本的測試技術規劃和測試技術儲備，攻關。從測試技術，測試質量角度推進公司質量的不斷改進。

 

 

 

 

測試架構師必須具有的第一個能力：「準確的商業理解力。」

 

 

    最近看到1篇關於測試架構師介紹的文章，文章中的測試架構師原型來自微軟，其描述的工做內容讓很多國內的測試同業非常羨慕，但又以爲好像離咱們中國人很遠。不知咱們中國的測試工程師能作嗎？個人答案是Yes。

 

由於，我如今就在中國帶領着一個測試架構師團隊。瞭解本身所在公司測試架構師團隊的運做和工做內容(後續將陸續與你們分享)，雖然咱們以前也從未接觸過微軟的測試架構師。但隨着公司業務的擴大，業務的須要驅動了咱們公司內部有一小部分人擔當起了測試架構師的職責，其title來源也是有其偶然性。本來公司中測試工程師往上發展就是系統測試工程師，系統測試工程師再往上應該叫什麼呢？最後參考軟件開發的title，就開創性的在公司內部叫測試架構師。並開始從事了不少從公司層面而僅非單個測試經理層面所須要的新的測試工做職責，例如：領導負責一個產品線或一個大產品的測試技術規劃，early testing，系統測試工程師的培養，與開發架構師一塊兒設計和改進架構的設計質量，測試執行活動質量的審查保障，親自指導重點測試方案的設計，爲了避免斷下降公司研發成本而進行新測試技術研究實踐和推廣，基於風險的測試，基於模型的測試，安全性測試，兼容性自動化測試，分佈式自動化測試，性能壓力測試，需求測試等專項測試技術領域的研究，並支撐新領域重點市場項目活動等等。

 

與微軟的共性是咱們的測試架構師都再也不親自寫自動化測試腳本，不親自寫測試工具的代碼。但咱們會從項目初始即項目需求和架構設計階段就開始考慮將來的自動化測試框架，針對具體的產品特色，思考選擇最合適的自動化測試語言；在架構設計中充分考慮如何支撐將來更高的自動化測試率，讓架構設計調整具有高的可測試性率；因爲參與早期的設計方案討論選型，能提早識別和規劃好將來產品測試組所須要提早準備的測試實現技術。並親自帶着測試工程師提早進行測試技術儲備。固然咱們也經常親自去實施一些測試活動：如設計測試工具的架構（主要考慮將來擴展性和更好知足測試需求），而後交給專門的測試工具開發團隊來實現；或親自設計壓力測試方案；親自研究安全性測試策略和方案。推廣方式，主要是親自實踐各類新測試技術後，再帶着測試人員在實戰中掌握相關的方法。

 

咱們大部分的測試架構師都是寫過自動化測試腳本或程序的，只是如今的工做因爲須要咱們去思考太多的東西，因此沒有一丁點精力來編碼。特別是負責一個產品線的測試架構師，因爲負責多個產品，還要抽取產品間的共性測試技術，要創建起產品線的測試架構圖，統一產品間的測試技術，統一測試方案的設計質量標準，須要具有更強的抽取共性的能力。同時，還須要能在短時間內快速瞭解和識別影響產品成敗的關鍵測試技術，由於並非全部產品都是性能壓力測試就是最重要的。例如：某產品線有9個產品，有的產品最須要保障的是可靠性（性能，可用性不是關鍵）；有的產品最須要保障的倒是可用性，而不是可靠性；有的產品最須要保障的是安全性，而不是性能；有的產品最須要保障的是可移植能力和可集成能力，而不是性能。那麼相應的每一個產品測試用例設計就會有所側重，例如：對於重視可移植能力和可集成能力的產品，測試架構師就應該幫助測試人員系統地作好這2個領域的測試用例。

 

商業成功的核心競爭力是什麼？測試技術和測試資源是否能真正地保障或支撐商業成功的核心競爭力？這些都是測試架構師須要準確識別的，若是測試架構師識別錯誤了，那麼有可能在須要重點保障的領域，測試技術和測試資源投入不足，致使最後產品的商業競爭力得不到支撐，得不到質量保障。例如：某產品對外宣傳是業界可靠性最高的產品，但是測試人員在測試活動中慣性地把主要精力都花在了性能測試中，對各類異常的測試驗證並非業界最豐富的。結果在與業內其餘產品比較的第三方測試報告中，該產品的可靠性得分卻並非第一，雖然性能是第一，但該產品在特定的重視可靠性的市場中基本失去了商業競爭力。

 

某美國公司的一款產品在傳統行業中主要功能基本雷同，如何才能與相似產品拉開距離，突出競爭力。後發現產品的用戶在使用產品時普通操做時間都較長，所以爲了縮短用戶的操做時間，該公司決定在產品的可用性領域重點投入設計，核心競爭力是解決用戶的可用性問題。其測試團隊把大部分的測試設計精力也放在了可用性的測試活動中，構建了業界很是豐富的可用性測試用例，這些測試用例的場景超過了產品設計考慮的原有場景，並最終經過測試驅動設計，與產品設計師一塊兒不斷改進產品的可用性。最後不但提供了業界可用性最強的產品，並且其可用性功能的穩定性質量也很是高。測試活動從效率和質量角度支撐了產品的商業成功。

 

因此，若是你的公司正準備招募測試架構師，請第一考評他的能力應該是他的商業理解力。具備該能力的測試工程師知道如何選擇：作正確的事！確保事半功倍。而不具有該能力的測試工程師能夠成爲系統測試工程師，由他來保障正確的把事作好！

 

測試架構師必須具有的第二個能力：「區分測試重點和測試難點」

 

 

 

重點和難點兩個詞彙有時能表明一樣的方向，有時倒是相差較遠的方向。

 

爲何我要把是否有能力區分測試重點和測試難點做爲測試架構師必備的第二個基本能力。由於，我曾在某產品線對測試活動的質量進行抽查時，與每一個產品的系統測試工程師進行了溝通，發現只有一名有6年經驗的系統測試工程師在個人的啓發下，分清了本身所負責產品的測試重點和測試難點。而其餘的系統測試工程師一直都把測試難點誤當成了測試重點，做爲他技術攻關工做的主力方向。甚至歷來沒有真正思考過什麼測試技術纔是本身所負責產品決定成敗的測試重點，只是簡單地把本身在工做中碰到的所不具備的測試技術都當成測試重點，其實不少都只是測試難點。的確，在某些產品測試難點和測試重點恰好重合。雖然某些產品測試重點在技術上並不難，可是卻須要咱們把測試重點部分的工做質量作到最佳，時間和資源投入最多，而不要把有限的資源投入到測試難點的工做中去。我很認同華爲任正非對華爲工程師的要求「要作工程商人」，咱們其餘公司的工程師一樣應該以商業目標爲本身的技術工做目標，不該惟技術論，越新的技術，越難的技術就越願意投入。測試工程師一樣要心中一直有一個目標指引着本身的全部技術工做方向。

 

因爲項目中每一個人的分工不一樣，所以不可能每一個測試人員一開始就能知道本身工做的商業目標是什麼，因此也不用去責怪你們。但是領導產品的測試架構師不能準確的識別或培養其餘測試工程師具有識別測試重點和測試難點的能力，那麼註定這個測試團隊的工做不但質量保障會打折扣，並且會浪費很多組織的資源和成本。

 

由於資源和時間是有限的，而完美工做的追求是無限的。所以，咱們如何在有限的資源和時間下，保障基本的質量目標，並儘量提高質量目標。就須要在分清測試重點後，優先針對測試重點目標進行系統地測試技術研究，測試技術攻關，測試資源主要投入。對於非測試重點的測試難點部分就要下降優先級，放在最後考慮。

 

測試架構師的工做應該緊緊抓住真正的測試重點來開展，甚至在整個產品測試組都方向錯誤時，要能從商業角度幫助測試組改變觀點。那麼當從測試經理到普通工程師都誤理解了測試重點時，測試架構師應該如何來啓發他們呢？我這裏就分享一個案例吧：

 

  在一次到產品測試組進行測試活動質量抽檢時。咱們問測試經理，大家產品測試目前最大的需求是什麼？他說是如何進行壓力測試和性能測試，但願咱們測試架構師團隊能在此領域多給予支持。我內心知道：他所負責的產品特性核心不是性能和壓力測試，但我沒有反駁他。而是繼續問他下一個問題：「你以爲會讓你產品將來應用時商業失敗的最大擔憂是什麼？」他想了想說：「不能對客戶的生產系統產生破壞，讓客戶的業務中斷。」「依據咱們的經驗，與客戶生產系統交互的模塊雖然是個小模塊，可是在其餘產品上常常出現內存泄露的故障從而破壞了生產系統。那你針對該小模塊作過哪些系統地測試？有無專門進行內存泄露的測試，由於內存泄露對客戶生產系統的破壞最大。」我問到。這時此測試經理才恍然大悟，這個對生產系統質量影響最大的小模塊竟然沒有系統地進行過深刻全面的測試。我這時告訴他「你之因此開始說性能和壓力測試是你的重點需求，是由於大家組裏沒有在性能和壓力測試方面的積累，有工做開展的難處，這是困擾你的困惑。可是你的產品形態的質量不是性能或所謂壓力測試來保障的，而是須要不對生產系統產生破壞。所以，你惟一能破壞生產系統的那個小模塊應該是你整個產品中質量最高的模塊，也應該是測試最全面最深刻的模塊，你的技術力量應該主要投到這個地方」。後來，針對該小模塊咱們進行專項內存泄露的測試，結果發現了好幾個內存泄露的大bug，這些bug每個都是會致使客戶生產系統中斷的殺手。

測試架構師不是團隊中專門解決測試難點的專家，而是識別測試重點，並支撐測試重點工做的專家。「區分測試重點和難點的能力」不是測試架構師獨有，系統測試工程師和測試工程師同樣能夠具備。與第一篇「準確的商業理解力」同樣，第二篇要作的是：作正確的事。

 

請繼續關注後續測試架構師應該具有的能力系列：

 

第三篇「全面，多樣化的產品經驗」

第四篇「參與產品架構工做的能力」

第五篇「識別產品測試組測試技術需求的能力」

第六篇「爲產品測試組提供測試技術解決方案的能力」

第七篇「測試技術解決方案的推廣能力」

第八篇「與周邊部門溝通配合能力」

第九篇 「創新解決方案能力」

第十篇 「領導力和影響力」

 

 

一網友郵件問我2個問題：測試架構師的價值怎麼量化體現？可否用最少的詞描述測試架構師對產品測試組支撐時最主要的工做目標是什麼？

 

問題1回覆：

你一切的活動提高產品線總體10％的的測試質量，10％的測試效率，你的價值就體現出來了。而不是親自作一個測試工具，或是作一個測試工具的架構，那是測試工具架構師所作的工做。

 

問題2回覆：

 

我思考後這樣總結：「指明測試方向，提高測試質量」；

  

具體點：

 

1.把握真正的商業質量目標，拉通產品線測試技術規劃，對產品線總裁負責，而不是隻對一個產品負責；

 

2.樹立最高的測試質量標杆，持續幫助產品測試組改進測試質量；

 

3.培養專項測試技術專家；經過培養和指導高級測試工程師來間接提高測試組的總體測試質量；

 

4.全部測試設計質量的把關；

 

更詳細些：

 

第一步：本身獨立分析每一個產品的商業目標；專家應該獨立思考，才能幫助產品測試組走到正確的方向上；

 

 第二步：以商業目標規劃本身的測試目標（測試重點）。思考要支撐商業競爭力，測試技術運做應該作哪些活動？

 

第三步：測試技術運做活動做爲後續具體操做的目標：既要考慮短時間見效目標，1－2個月的工做重點Top3就能夠了；又要考慮6個月內的工做重點；1－2年的長期工做目標。這樣纔會短時間利益和長期規劃都能照顧到。不會讓人以爲你的工做太好高騖遠。

 

第四步：規劃如何支撐測試技術運做活動的人員組織架構；人員應該是來自產品測試組的測試技術骨幹，他們既要負責好產品測試工做，又要能擔負起整個產品線的某個專項測試技術的統領責任。這樣在你的產品線中既不會失去產品測試支撐的主要目標，又不會失去跨產品統一規劃的目標。要培養起各領域的測試技術專家，可是你又不能作「甩手掌櫃」，你必需要指導和幫助這些專項領域的測試技術骨幹能作好他所負責領域的技術規劃，畫出每一個專項領域中各產品間技術的依賴圖，依賴圖出來了，你的技術研究工做的時間計劃也就出來了。

 

 第五步：就是執行你的規劃。這時你另外一個很是重要的做用就要顯現出來。你要樹立每種測試設計的質量標杆，你對各種測試設計方案的質量要求，經過言傳身教讓高級測試工程師提高本身的測試設計質量尺度，從而提高產品組的總體測試設計質量尺度。

 

第六步：在測試執行活動中，你應該每週到一線瞭解測試活動開展的困難，測試組不肯意應用新測試技術的困難和緣由是什麼？而後本身經過各類方法，如外部資源引入新的測試解決方案，不斷解決產品測試組新測試技術應用的困難。例如：某產品未很好的開展單元測試和TDD，有領導認爲是下面的人態度不行。結果經過一線溝通，才知道是由於開展單元測試要寫測試代碼，工做量太大，人力又不夠，因此沒怎麼開展。那我就應該從技術角度思考如何解決這個看似是人力資源的問題。經過與某測試工具供應商交流，得知一種新的思路：測試用例自動生成測試代碼的工具。這樣就能夠經過技術而非大量招人來解決產品組開展單元測試最大的困難：測試代碼編寫工做量大。單元測試天然就能夠開展起來了。

 

第七步：測試架構師要常常抽查一線的各種測試文檔，如：測試用例，測試報告，測試總結，bug報告等。這樣你才能知道當前一線的測試活動質量存在哪些問題？哪些是測試組須要改進和完善的地方，從而也找到本身的工做的研究方向。