我當測試總監的那幾年

作者 | 王曄倞

責編 | 郭 芮

今天來跟大家聊下我當年做測試的一些經歷。

每次問我有關職業發展的問題時，我都會反問兩個問題。一是你當下最喜歡做的工作是什麼，二是你當下最擅長做的工作是什麼。

面對這兩個問題，大部分人的回答都很相似。先是一愣，然後含含糊糊的說三個字 「不知道...」 或 「沒想過...」。

的確，吃喝玩樂，娶妻生子，才是大多數人的基本訴求，什麼理想與目標，似乎都不是你蹦一下就能夠得到的，這種感覺像極了一頭拉磨的驢子，只能蒙著眼睛不停的向前跑，否則就會挨鞭子。

我常說，哪有什麼人生規劃，都是歷史機緣的巧合罷了。

就像我的簡歷，凡是看過的人都會問：「你做過測試？為什麼會選擇去做測試呢？」

選擇？對很多人來說，職業生涯的發展真的是選出來的嗎？一切都是被迫的，一切都是莫名其妙的。

以前我曾說過自己帶著兩年的創業史，身背近五十萬的債務，來到了大智慧辦理入職手續，開始了新的人生。

這段台詞非常耳熟，像極了小時候看到的童話小說，王子和公主從此過上了幸福快樂的生活，恩愛一生。

很可惜，人生畢竟不是小說，把一個人寫死了，還可以用某個場景讓他復活。

相信大部分的人都有過走投無路的經歷，在殘酷的現實面前，什麼理想，什麼目標，都變得毫無價值，能活下去，才是當務之急。

2011年底，那場創業悲劇，讓我和我的家人幾乎陷入了萬劫不復的地步。

在公司開始清盤的第二周，有位朋友給我介紹工作，說是大智慧在招聘架構師，對口研發中心的HRBP正好是他女朋友，問我有沒有興趣。

這真是天無絕人之路，來早不如來得巧，關係那麼鐵，我自認為八九不離十。

「太感謝了，沒想到就我這點破事，你還掛在心上了。」

「先別忙著謝，有個事情要先說下，這個正在招聘的崗位歸屬測試團隊，也就是說，如果你過去，職位最多是測試架構師……」，電話那頭的聲音顯得有些無奈。

「不知道你是否在意？聽說這個崗位他們招了半年，一直不理想，我覺得你肯定能夠勝任。」

對當時的我來說，與崗位和職務相比，收入與穩定性對我的吸引力更大。

「無所謂，幫我安排面試吧，」這種爽快程度，連我自己都不敢相信。

「你下午就過去吧，我女朋友那邊已經給你安排好了。」

以前的我從來都不信什麼牛鬼蛇神，也不信小說上那種純情的完美結局，但此時此刻，我似乎感覺面對未來以後充滿了希望，但又無法面對。

面試進行了2個小時，面試官是當時的測試總監，近四十的年紀，說話很穩重。

在談話中，我們交流了有關阻抗測試的各種問題，並探討了一些傳統測試轉型的方法。

這方面的記憶力是我的強項，至今我任然記得一些：

1、只能發現問題，無法解決問題

測試環節，常常在代碼編寫之後，就算測試小夥伴的能力再強，通過九牛二虎之力測試了致命性問題，但為時已晚，要想重新折回頭處理其中的問題是要花費一些時間和精力的，降低了交付效率，如果不打回修復，則無法保證質量。

2、有能力的不願意做測試

從事測試工作的小夥伴，一般都沒有研發能力，有研發能力的一般也不會來做測試，畢竟無論從地位，還是收入，開發都要比測試高一些。

這就形成了馬太效應，好的越好，差的越差。

3、業務測試與業務驗證，傻傻分不清

通常情況下，討論需求的時候，業務方都會叫上開發，畢竟需要開發去實現，但絕不會叫測試。

這裡會形成一種尷尬，因為測試員不可能理解所有的代碼，而且沒有參加需求環節，所以漏掉一些重要的測試是很有可能的。但業務方不會遺漏，畢竟這是他們的工作核心。

因為，我們經常會碰到，測試沒測出的問題，卻在業務驗證時發現了。

然後有趣的場景出現了，業務怪開發，開發怪測試，測試直喊冤枉。

4、測試環境是世界級難題

測試環境，是每家公司最頭痛的問題。比如測試通過，生產報錯，再比如測試人員編寫的測試是依賴的文檔或其他東西，而不是代碼，配置和數據存在任何不一致的地方的時候，就會造成問題。

另外，如果測試不是自動進行的，那麼極有可能不會被頻繁、經常性地進行，這大大降低了發現環境問題的可能性。

在敏捷尚未盛行，職能分工當道的時代，這些似乎都是測試團隊的死穴。

而在他們眼裡，只要能找到一位具有豐富架構經驗的 『冤大頭』，並組建一個測試架構部，這些問題應該都會迎刃而解。

就這樣，我稀里糊塗的成為了那個 『冤大頭』。

之前也曾與朋友聊起過這段經歷，有朋友說，這些問題用敏捷和DevOps就能解決，用不起來是企業文化的問題，找誰來都只能填坑，起不了什麼作用。

一切脫離時代背景的評價，都是耍流氓。

在當時，知道敏捷的人不少，了解DevOps的人也挺多，但真正能體系化將這兩樣東西落地的企業卻很少。理論大家都懂，但如何在現有基礎上逐步實踐落地，並取得想要的成果，沒一個人能說得明白。

而且，伴隨著交付壓力的增大，研發與測試之間的交流越來越少，所以想通過一些方法，打通交流的障礙。

第一階段：應用與基礎的測試分離

在入職後的半年裡，我的主要工作是參與各測試團隊的工作，一來混熟人頭，二來熟悉業務與現有工作模式。

半年後，我開始與測試總監一起，針對一系列問題進行改進。

先來說說組織結構。

大智慧的系統是建立在C/S架構之上的，所以研發被天然的分割成 「前端」 與 「後端」，又因公司業務分為 「股票實時行情」 與 「金融數據服務」 兩個板塊，把 「後端」 分為行情服務端與數據服務端。

當時的組織架構採取的是職能式組織模式，既然研發被分成為三個團隊，測試也只能緊隨其後。

與客戶端、行情服務端相比，數據服務端的問題就顯得非常多。

以上交所Level-2行情為例，業務場景固化，無論接入協議，還是數據加密，都是非常公開且成熟的技術，而且需求變更少，改動不頻繁，只要沒有新市場接入，一年到頭幾乎沒幾個需求。

反觀數據服務端，連續幾年公司都重金投入，不僅先後併購了幾家數據供應服務商，還對外喊出了 「天天發版」 的口號，氣勢一浪高過一浪。

這下可苦了研發與測試的小夥伴們，由於併購的公司技術棧各有不同，這家用SQLServer，那家就用MySQL，這家用Java，那家就用C++，環境與集成類的問題層出不窮，為了趕進度，只能鬍子眉毛一把抓，管他什麼應用還是框架，拼湊拼湊，跑通了就上，報錯？拉下來改改，接續上。

一般說，遇到這種緊耦合的情況，就只剩 「拆」 這一條路。

為了不對現有業務的迭代速度造成影響，與研發團隊設立了兩條拆分原則：

• 原有業務：如有需求調整，強制遷移至新架構，並將基礎與應用進行分離。
• 新增業務：基於新架構，並將基礎與應用進行分離。

經過半年的折騰，無論老業務還是新業務，大部分核心部分基本都已遷移至新架構上。

隨即，數據服務測試團隊也被拆分成 「基礎測試」 與 「應用測試」，一個保障基建，一個保障業務。

就因這一波操作，經公司領導決定，將 「基礎測試」 與 「應用測試」 劃歸我的名下。

我就這樣，莫名其妙的睡了一覺，醒來的時候變成了測試經理。

第二階段：嘗試集成測試驅動開發

工作與生活差不多，煩心事總是一波接著一波。

某天午後，領導找我談話，說開發、測試與運維之間相互推諉的情況日趨嚴重，想聽聽我有沒有好建議。

咱是讀過孫子兵法的人，一聽就明白了。立即搬出一番DevOps的方案，領導聽了連連擺手，說：「這種大而全的東西少拿來忽悠，來點實際的吧。」

我一愣，想了想說：「要不拿我的兩個團隊來試點，再不改變現有流程的情況，嘗試測試驅動開發怎麼樣？」

領導笑了，點了點頭，說：「嗯，你很主動，大膽去干吧，我支持你！」

尼瑪，我感覺這根本不是談話，分明是挖了個坑讓我自己跳。

什麼叫測試驅動開發？

對敏捷比較熟悉的同學，相信一定聽說過TDD（Test-Driven Development）。

大致是說在明確要開發某個功能後，在開發功能代碼之前，先編寫測試代碼，然後編寫功能代碼並用測試代碼進行驗證，如此循環直到完成全部功能的開發。

在技術圈，很多人都討厭這種看似完美的理論，因為與現實中的情況距離太遠。因為還以黑盒測試為主要手段的我們，就單單 「編寫測試代碼」 這一項，就會把我們擋在門外。

所以，我們只能尋找一些適合我們當前技術實力的出路。

與其他公司一樣，我發現大部分的測試爆發點都集中在集成測試階段，舉個例子證實下。

案例：業務系統新上一個A功能，同時涉及客戶端、基礎與應用的修改與新增，結果如何呢？

從這張表中可以明顯看到以下幾點：

• 各開發都說自己做過了單元測試，並順利通過，所以我沒問題。
• 各測試都說自己跑過回歸測試，並順利通過，所以我沒問題。
• 每次提交，客戶端測試都在群里喊，請大家注意配置項的提交，沒人說話。

想起當時有小夥伴調侃過，說每個環節都說自己沒問題，但只要放在一起就出各種問題，難道是機房風水有問題？

顯然不是，那問題究竟出在哪裡呢？

又經過半年的折騰，對環境、配置與組織進行了一系列的調整：

我相信一句話，這世界上從來就沒有什麼救世主，你強了，你堅信了，困難就變弱了。

到2012年底，我們基本達成 「集成測試團隊驅動開發」 的效果，協助開發進行問題排查，並且取代了項目管理的工作。

又因這一波操作，經公司領導決定，將集成測試團隊也劃歸我的名下。

就這樣，我似乎又睡了一覺，醒來的時候變成了測試副總監。

第三階段：試圖統一流程與工作方式

三國演義開篇說，天下大勢，分久必合，合久必分。

隨著棘手問題的逐漸得到緩解，大家開始把注意力放在了流程與規範上。

當時，各測試團隊雖然名義上都歸屬於測試部，但基本都各自為戰，你有你的流程，我有我的套路。

比如上級想得到BUG修復率或提測效率這樣的報告，基本是不可能的。

另外，像測試流程不規範，測試文檔不健全、測試文檔也沒有控制和管理等問題也非常突出。

2013年初，經公司領導決定，將剩餘的客戶端、行情服務端這兩個測試團隊合併至我的團隊，成立新測試部門。

我的職務也從測試副總監，升為測試總監。

目標是在年底之前，完成新測試部門的崗位職能、測試流程、測試文檔規範、日常項目工作、部門考評機制以及測試部門人員技能與業務的培訓等多方面的規劃，為公司明年的產品戰略提供更高的質量保障。

回想當時的我，滿腦子裝的都是 「如何幫助研發團隊釋放潛力」 的激進辭彙。一拍腦袋，要求測試所有團隊將工作工具從 「Excel+腳本」 切換到Atlassian下。

或許是這一步邁得太大，而且在整個推進的過程中，我也非常強勢。

就這樣，惹惱了測試團隊中的一些老人，為此還吵過幾次，氣氛開始變得不愉快起來。

細心的朋友可能已經發現，不僅每個階段的涉及範圍都很廣，而且都牽涉到了組織結構的調整，那為什麼我還會推動的如此之快呢？

強勢與強壓，是我慣用的兩個手段。

在我心裡一直堅信，既然高層把這項艱巨的任務交給我，我就要不惜一切代價搞定。

現在回想起來，我像極了商鞅，改革是成功了，人也得罪光了，有人罩著你的時候，或許一切都顯得順風順水，一旦那個罩你的人不在了，你的死期也就到了。

2013年7月，大智慧已連續虧損幾年，業務低迷，人心惶惶，內部進行了一次結構調整，我受到牽連，被調到了一個新成立的部門，負責新技術的探索。

說白了，就是被踹了，被擼了。

2013年9月，我提交了離職申請，離開了大智慧。

一轉眼，六年過去了。

每次談起這段經歷，我都說，如果上天再給我一次機會重來，我應該會更圓滑一些，至少能讓 「審判日」 來得更晚一些。

人生沒有如果，只有後果和經歷，而經歷卻可以轉化為財富，為將來的職業生涯做好鋪墊。

有的人說，我身上的故事真多，感覺總寫不完。

有的人說，我可以去當編劇，故事編得很溜。

我只想說，我是個搞技術的，不會編故事，只不過天生臭脾氣，遇到的坎坷自然會多一些。

另外，我願意將這些事情記在心裡，再寫出來與大家分享。

如果你也願意，相信會比我更加精彩。

作者：王曄倞，18年IT從業經驗，現任職好買財富平台架構部技術總監，負責好買中間件及平台化的研發及運營，團隊管理和實施重大技術決策。曾任大智慧測試總監，在2年內帶領團隊自研了「大智慧雲測試平台」，通過平台化將金融數據服務業務從瀑布式逐漸轉型為DevOps。

聲明：本文為作者投稿，版權歸作者個人所有。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！