成為測試架構師必須具備的三大能力（2）
測試架構師必須具備的第二個能力：區分測試重點和測試難點！
重點和難點兩個詞匯有時能代表同樣的方向，有時卻是相差較遠的方向。
為什么我要把是否有能力區分測試重點和測試難點作為測試架構師必備的第二個基本能力。因為，我曾在某產品線對測試活動的質量進行抽查時，與每個產品的系統測試工程師進行了溝通，發現只有一名有6年經驗的系統測試工程師在我的的啟發下，分清了自己所負責產品的測試重點和測試難點。而其他的系統測試工程師一直都把測試難點誤當成了測試重點，作為他技術攻關工作的主力方向。甚至從來沒有真正思考過什么測試技術才是自己所負責產品決定成敗的測試重點，只是簡單地把自己在工作中碰到的所不具有的測試技術都當成測試重點，其實很多都只是測試難點。的確，在某些產品測試難點和測試重點剛好重合。雖然某些產品測試重點在技術上并不難，但是卻需要我們把測試重點部分的工作質量做到***，時間和資源投入最多，而不要把有限的資源投入到測試難點的工作中去。我很認同華為任正非對華為工程師的要求“要做工程商人”，我們其他公司的工程師同樣應該以商業目標為自己的技術工作目標，不應唯技術論，越新的技術，越難的技術就越愿意投入。測試工程師同樣要心中一直有一個目標指引著自己的所有技術工作方向。這個目標就是我測試架構師日記中***篇談到的“準確的商業理解力”告訴你的工作目標。
由于項目中每個人的分工不同，因此不可能每個測試人員一開始就能知道自己工作的商業目標是什么，所以也不用去責怪大家。可是領導產品的測試架構師不能準確的識別或培養其他測試工程師具備識別測試重點和測試難點的能力，那么注定這個測試團隊的工作不但質量保障會打折扣，而且會浪費不少組織的資源和成本。
因為資源和時間是有限的，而***工作的追求是無限的。因此，我們如何在有限的資源和時間下，保障基本的質量目標，并盡可能提升質量目標。就需要在分清測試重點后，優先針對測試重點目標進行系統地測試技術研究，測試技術攻關，測試資源主要投入。對于非測試重點的測試難點部分就要降低優先級，放在***考慮。
測試架構師的工作應該牢牢抓住真正的測試重點來開展，甚至在整個產品測試組都方向錯誤時，要能從商業角度幫助測試組改變觀點。那么當從測試經理到普通工程師都誤理解了測試重點時，測試架構師應該如何來啟發他們呢?我這里就分享一個案例吧：
在一次到產品測試組進行測試活動質量抽檢時。我們問測試經理，你們產品測試目前***的需求是什么?他說是如何進行壓力測試和性能測試，希望我們測試架構師團隊能在此領域多給予支持。我心里知道：他所負責的產品特性核心不是性能和壓力測試，但我沒有反駁他。而是繼續問他下一個問題：“你覺得會讓你產品未來應用時商業失敗的***擔心是什么?”他想了想說：“不能對客戶的生產系統產生破壞，讓客戶的業務中斷。”“依據我們的經驗，與客戶生產系統交互的模塊雖然是個小模塊，但是在其他產品上經常出現內存泄露的故障從而破壞了生產系統。那你針對該小模塊做過哪些系統地測試?有無專門進行內存泄露的測試，因為內存泄露對客戶生產系統的破壞***。”我問到。這時此測試經理才恍然大悟，這個對生產系統質量影響***的小模塊居然沒有系統地進行過深入全面的測試。我這時告訴他 “你之所以開始說性能和壓力測試是你的重點需求，是因為你們組里沒有在性能和壓力測試方面的積累，有工作開展的難處，這是困擾你的困惑。但是你的產品形態的質量不是性能或所謂壓力測試來保障的，而是需要不對生產系統產生破壞。因此，你唯一能破壞生產系統的那個小模塊應該是你整個產品中質量***的模塊，也應該是測試最全面最深入的模塊，你的技術力量應該主要投到這個地方”。后來，針對該小模塊我們進行專項內存泄露的測試，結果發現了好幾個內存泄露的大bug，這些bug每一個都是會導致客戶生產系統中斷的殺手。
測試架構師不是團隊中專門解決測試難點的專家，而是識別測試重點，并支撐測試重點工作的專家。“區分測試重點和難點的能力”不是測試架構師獨有，系統測試工程師和測試工程師一樣可以具有。與***篇“準確的商業理解力”一樣，第二篇要做的是：做正確的事。
【編輯推薦】
