測試的行業(yè)危機

入職華為以來，一直做的是測試工作，這種危機感在近幾年愈發(fā)強烈，一直想總結(jié)一下，但又擔心總結(jié)不好，動搖軍心。但該面對的早晚要面對，需改變的也要盡早改變，一定要有革自己命的勇氣。

危機的預兆

舉兩個測試行業(yè)危機的例子：

一個是外部例子。近期參加了幾個測試行業(yè)交流，測試技術(shù)分享方面并沒有什么新的發(fā)展，還是自動化、APP 測試能力技術(shù)分享。業(yè)界的測試專家也普遍進入一個迷茫期，很多測試專家轉(zhuǎn)型敏捷教練、DevOps 流程專家。和幾個專家聊了一下，也普遍感覺近幾年業(yè)界對測試的關(guān)注已經(jīng)逐步偏弱。

另外一個是內(nèi)部的例子。華為 2017 年應屆生招聘已經(jīng)啟動，在啟動材料中，明確說明華為已經(jīng)取消了軟件測試工程師的崗位，HR 認為現(xiàn)在的軟件需要全棧工程師，開發(fā)工程師也需要具備自測的能力。

危機產(chǎn)生的原因

測試行業(yè)發(fā)展的頂峰應該在 2000 年后，Google 測試體系大肆宣傳的那幾年，市面上到處都是 Google 測試的書籍，自動化測試能力也得到業(yè)界的高度認同，整個 IT 界都在推廣自動化，一個測試專家僅靠自動化能力就會獲得比較高的薪資。而近幾年隨著軟件技術(shù)的快速發(fā)展，技術(shù)知識越來越容易獲取，技術(shù)的迭代周期也不斷加速，技術(shù)門檻也越來越低。在這種大背景下，專職測試的必要性也在不斷受到挑戰(zhàn)，特別對于一些創(chuàng)業(yè)類的小型公司，在沒有專職測試的條件下，產(chǎn)品也能得到市場的認可。

隨著軟件開源社區(qū)的快速發(fā)展，軟件工具的易用性也在不斷加強，各類開發(fā)和測試框架層出不窮，技術(shù)人員可以很方便的使用框架代碼實現(xiàn)自己的需求，按照公司的說法是我們無需自己造輪子。各種輪子的使用，讓業(yè)務開發(fā)變得更加便捷，這也是為什么華為的軟件可以使用大量合作的原因，也許不久的將來，這個行業(yè)真的會變成勞動密集型行業(yè)，未來受到?jīng)_擊的可能不僅僅是測試和運維，開發(fā)一樣存在在行業(yè)危機。

軟件工程方法也在不斷演進。以近期盛行的 DevOps 為例，該流程倡導一種全功能團隊的運作模式，團隊中的各個角色分工相對模糊，開發(fā)需要投入自測和運維，這種開發(fā)模式體現(xiàn)了及時響應，及時改進的快速迭代思想，提升了對開發(fā)的要求，但是對于運維和測試角色，造成了一定沖擊。

傳統(tǒng)的軟件測試，特別是通信類產(chǎn)品和大型的 To B 類軟件，對交付質(zhì)量較高，有很高的門檻。一個測試專家需要了解無線交換、數(shù)通網(wǎng)絡、小型機、軟件、各類信令。專家到各地開局時，往往是單槍匹馬，一人搞定，受到辦事處同事的敬仰膜拜。記得有次給客戶演示 VPN 短號，業(yè)務服務器故障一直無法定位，征得客戶的同意，直接在交換上做了一個號碼變換，先解決演示的問題，當時測試人員要求的技術(shù)廣度遠超于開發(fā)人員。

但是近幾年，通信業(yè)已經(jīng)無法阻擋軟件化的趨勢，隨著 CT 技術(shù)門檻也在不斷降低，華為也正喊出了 CT 轉(zhuǎn) IT 的口號。軟件的微服務、云化等技術(shù)，讓測試人員工作也不斷簡化，很多新來的同事對直接使用計算云部署環(huán)境，對物理服務器的了解也是一知半解，在知識廣度方面可能和開發(fā)持平，而在深度方面，又不如開發(fā)，測試技術(shù)不在存在門檻，角色的必需性正在不斷的弱化。

華為測試人員的現(xiàn)狀

華為大部分部門的測試開發(fā)比在 1：3 或 1：4 這個比例，這在業(yè)界是比較高的，比例高有兩方面原因，一方面是和我們的通信軟件質(zhì)量要求比較高有關(guān)，需要多輪的驗證，需要大型解決方案的交付。另外一方面和華為的 IPD 流程相關(guān)，大量的測試交付件，大量的評審和會議，為了確保大家步調(diào)的一致性，行管部門還是定期進行飛檢和數(shù)據(jù)晾曬。嚴謹?shù)牧鞒瘫Ｕ弦彩怯欣斜祝瑥暮锰巵砜?，可以確保軟件的質(zhì)量不會出現(xiàn)大的問題，適合軟件開發(fā)的大兵團運作，弊端來看，嚴重影響到軟件的生產(chǎn)效率。

從華為對測試角色的定位看，測試需要承擔三種職能角色，一種是管控角色。測試人員就像就像沙丁魚箱中的鯰魚一樣，不斷的通過各種數(shù)據(jù)，各流程，驅(qū)動上游團隊持續(xù)的保持活躍，進行相關(guān)的改進。并且測試作為研發(fā)的一個環(huán)節(jié)，本身也要提供相關(guān) TR 點的素材，配合提供項目的各類測試交付材料。在大型的團隊中，這部分的流程和數(shù)據(jù)還是非常受到領導重視，因此也產(chǎn)生了很多華為自有測試員工，過于投入流程和數(shù)據(jù)，而忽略業(yè)務本身的現(xiàn)象。

第二種角色是質(zhì)量服務角色。就是測試要對產(chǎn)品投入實際的測試執(zhí)行工作，發(fā)現(xiàn)版本的質(zhì)量問題。在華為傳統(tǒng)觀念中，測試部應該對產(chǎn)品的質(zhì)量負責，負責的重要標準就是測試部需要對版本進行一次完整測試，需要輸出相關(guān)結(jié)論。在華為和開發(fā)和測試分工中，也是基于一種不信任的配合關(guān)系，測試人員不需要關(guān)注開發(fā)測試過程中已經(jīng)驗證了什么，版本轉(zhuǎn)測試后，測試必須完整版本驗證工作，從部門的角度給出最終的結(jié)論。而這種測試定位，在互聯(lián)網(wǎng)領域中，已經(jīng)逐步的弱化，只有關(guān)鍵的產(chǎn)品才會投入專職的測試專家進行測試設計和執(zhí)行工作。

第三種是工程能力角色，類似 Google 的工程生產(chǎn)力部門，定位為提升研發(fā)過程效率和質(zhì)量，輸出相關(guān)工具和方法的支撐，提升整個研發(fā)過程的測試效率。目前這部分的專家主要集中在 2012 實驗室和幾個大產(chǎn)品線的工具部。而產(chǎn)品測試（業(yè)務測試）投入的能力建設，主要集中在 DFX 的特性測試以及自動化能力方面。

對于華為傳統(tǒng)的 To B 類產(chǎn)品，測試投入的 1、2 兩個角色職能的工作非常多，也占用了業(yè)務測試團隊的大量時間，特別對于具體的測試執(zhí)行，各產(chǎn)品線業(yè)務測試投入大量合作員工進行基礎的測試保障。對于工具和測試能力的提升，2012 實驗室的測試行業(yè)投入較多，在 6+1 測試工具有了一些成果，但是能力和業(yè)務還是有一定的脫節(jié)，行業(yè)專家不會介入業(yè)務太深，業(yè)務定制化的測試需求也較多，導致很多實際的業(yè)務測試效率問題，仍然需要業(yè)務自身解決。

我所在的云服務屬于公司內(nèi)少有的 To C 類產(chǎn)品。我們所有的產(chǎn)品都是無需向運營商交付的，對自有業(yè)務需求的控制比 To B 產(chǎn)品好太多，也可以在我們自有的環(huán)境上進行灰度發(fā)布，Beta 測試，很多快速交付的實踐都在產(chǎn)品中落地，因此可以做到每月至少一次的迭代發(fā)布。

但是對于云服務測試來講，也仍然面臨的較多的問題。我們的測試開發(fā)比在 1：7 到 1：10，基本上一個人負責一個或者多個模塊的測試，在華為的質(zhì)量體系下，我們也是要遵從華為一些質(zhì)量交付件，例如云服務需要與 EMUI 進行版本的配套，相關(guān)的測試交付還是要參考 IPD 的流程，所以在流程工作的投入上，測試人員投入的仍然很多，各類的會議也是很多。安全交付件更是如此，這是公司的紅線。在組織職責方面，測試和開發(fā)的組織職責也可以相對獨立，不存在開發(fā)自測交付的概念，在版本交付后，所有的測試的工作需要測試部獨立承擔，包括外部采購的合作項目，可能開發(fā)需要投入一個 PM，但是測試要完成所有驗收。未解決測試執(zhí)行覆蓋的問題，也是大量使用了合作員工，合作自有比也超過 5：1，合作的流失和培養(yǎng)一直都是歷史難題。

因為團隊規(guī)模比較小，能力建設方面也主要采用合作的模式，依賴外部的測試能力和 2012 的團隊，來推進云測， 6+1 等方面工作合作，測試的重點依然的是自動化，DFX 等方面。而對于業(yè)務體驗等方面關(guān)注的力度并不足。交付類測試仍然是我們工作的主要方向。

業(yè)務測試人員的發(fā)展方向

雖然前面講了很多測試的危機和問題，但是從行業(yè)發(fā)展的必要性來講，測試是質(zhì)量的重要保障，測試行業(yè)不可能被淘汰，我們只需要考慮如何讓我們的行業(yè)價值更高，讓自己不會被這個時代所拋棄。

公司一直倡導的都是工匠精神，但是軟件行業(yè)和傳統(tǒng)的手藝不同，我們所使用的工具在不斷的變化，十幾年前，我們還在使用 Basic、Pascal，但是現(xiàn)在已經(jīng)是 Java 的天下了，軟件的工匠精神不是比拼的是對語言和工具的熟悉，更多的在于軟件系統(tǒng)的經(jīng)驗。

測試的定位，不是僅僅發(fā)現(xiàn)版本的問題，或者做簡單測試技術(shù)工具的投入，而是應該定位更高一層，測試是整個產(chǎn)品的質(zhì)量守護者，需要具備提前預防質(zhì)量風險的能力，應該具備推進產(chǎn)品測試技術(shù)改進的能力，也應該具備產(chǎn)品研發(fā)過程中（含開發(fā)環(huán)節(jié)）測試效率提升的能力。測試能真正從客戶角度去看待和發(fā)現(xiàn)問題，并推動客戶質(zhì)量滿意度的不斷提升。這個定位很高，實現(xiàn)過程也很難，我們現(xiàn)在普通的測試人員 80% 都是在測試的具體執(zhí)行和一堆的事務性工作上，每日都在加班加點，很少有沉下心來分析問題的根因，通過學習不斷尋找技術(shù)改進的方向。

從測試技術(shù)發(fā)展來看，測試的工具化或自動化肯定是未來的趨勢，自動化的比例會不斷的提升，但是機器的自動化短期內(nèi)無法實現(xiàn)完全脫離測試人員的，仍然需要人工接入進行相關(guān)的自動化設計。從執(zhí)行的特點看，測試分為兩類，一類是固定場景的驗證，一類是未知場景的探索。

對于固定場景的驗證，有預期的輸入和輸出，無論是接口測試還是 LLT （底層測試），都是具備這個特點。測試人員的重點是將具體的場景抽象為自動化用例，提升回歸測試的工作效率。對于基于 UI 的自動化，因為產(chǎn)品可能存在較大變動，UI 識別也存在部分確定性，我們可以量力而行或盡可能抽象為接口自動化。在自動化工作中，測試要對開發(fā)有足夠的可測試性要求，產(chǎn)品具備良好的代碼解耦的架構(gòu)。

對于未知場景的探索，主要是針對沒有對應測試設計的測試驅(qū)動?？梢苑譃楣ぞ哳惖淖詣踊剿鳎缥覀兪謾C可靠性測試使用的 monkey，以及安全測試的 fuzzy 等。測試的場景由工具生成和決定。另外一種是人工的探索測試，這個概念近幾年也比較盛行。但個人認為這種在可行性上還是有一定難度，對測試人員的經(jīng)驗要求較高，目前我們也并沒有組織，主要通過 Beta 測試，引入大量普通用戶完成各類場景的探索。

任何測試都是不能 100% 發(fā)現(xiàn)問題，網(wǎng)上問題的發(fā)生也是很難避免，測試需要盡量降低網(wǎng)上問題的級別和發(fā)生概率，并且需要具備較高質(zhì)量風險防范的意識，對于高風險產(chǎn)品必須有雙重（或三重）的防范機制。例如我們做一個支付類產(chǎn)品，可能會在存在某些質(zhì)量問題，導致用戶未支付的情況下，支付狀態(tài)進行了更新（這個例子可能大家感覺不會出現(xiàn)，但是現(xiàn)實中有各類可能）。測試人員必須對產(chǎn)品提出，有額外的管控系統(tǒng)，對賬號進行準實時的核查比對，確保收支一致?；ヂ?lián)網(wǎng)有過類似的安全，2012 年某東積分兌換 BUG 的問題轟動一時。好的測試專家需要像扁鵲大哥一樣，盡可能的識別和規(guī)避可能的質(zhì)量風險。

測試人員的技能模型應該保持多樣性的發(fā)展，在廣度方面不斷延伸，深度方面可以選擇一兩項技術(shù)進行不斷挖掘。有三點需要測試重點關(guān)注：

編碼能力：特別對于新員工，這個能力是與開發(fā)有共同語言的基礎。測試人員需要了解對應業(yè)務的代碼框架，構(gòu)建工具，以及 LLT 測試，持續(xù)推動開發(fā)過程中的改進，能給予代碼提出測試建議，將質(zhì)量構(gòu)建在開發(fā)階段。

組網(wǎng)能力：測試需要對系統(tǒng)的組網(wǎng)，以及實際的部署情況有清晰的技術(shù)理解，這樣才能發(fā)現(xiàn)更多的質(zhì)量問題和隱患。這個說起來是比較簡單，但是如果做到深入的了解，還是有很高的技術(shù)難度，例如我們現(xiàn)在各個業(yè)務使用的 CDN 和 DNS，如何組網(wǎng)可以讓我們的系統(tǒng)體驗會更快更好。用戶使用的 UC、QQ 瀏覽器等是具備緩存加速，在緩存場景下是否會對某些業(yè)務特性產(chǎn)生影響。

業(yè)務能力：測試不能脫離業(yè)務，這也是為測試人員未來轉(zhuǎn)型產(chǎn)品經(jīng)理或其他崗位的一個必備能力。無論開發(fā)還是測試，能在整個職業(yè)生涯中，堅持到底的，是少之又少。大型產(chǎn)品線如有測試系統(tǒng)部之類的部門，如果脫離業(yè)務，純粹投入技術(shù)規(guī)劃或流程規(guī)劃，往往會逐步被產(chǎn)品邊緣化。

產(chǎn)品會有各類的隱患和問題，測試人員如果長期只發(fā)現(xiàn)簡單的 BUG，不僅會讓技能水平下降，而且會失去對工作的興趣，我們只有通過工具或技術(shù)不斷解決問題，才能挖掘測試工作的樂趣。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。