聊聊追求測試技術導緻過度測試

這個文章主題在我自己的看闆裡面躺了很久了，其實并不是不想寫，而是一直沒有勇氣來寫。最近鼓起勇氣，為當今測試技術的持續高溫澆澆水，文章中如果有些不妥當那麼請你看看一樂，切莫對号入座。

測試技術和團隊、業務成熟度是互相依存不可分割的

故事: 公司内部開始推行容器平台，這對于測試來說是一個很好的技術變革。DevOps流水線的支援更容易讓測試工程師掌握測試的主動權，更容易實作持續測試。當我們容器平台基本可以在測試環境投入使用的時候，團隊内部一個技術負責人不知道用何種方法說服老闆要進行一次故障演練，要把阿裡巴巴的chaosblade在内部用起來，要實作老闆一個電話，系統就可以制造一個故障然，來看看全部團隊從發現故障到恢複服務的速度。這個時候整個容器平台上都沒有一套可以順利走通全套業務的一套測試環境。為了迎合老闆的要求，我們加班加點完成了測試環境業務服務的部署和調試，又投入了7天的人力為故障演練做好的技術支援，最後因為技術部的自研APM無法ready而擱淺。

故事就是故事，但是故事中的問題卻展現了當今很多人為了在工作中為了表現自己的獨到見解而浪費了大量的公司資源做了一些過度的測試。當今測試技術發展快速，有很多傳統的測試技術進步神速，比如性能測試逐漸發展到了全鍊路行壓測，自動化測試技術發展的測試平台。除此之外還有很多新的測試技術，混沌工程、雲真機平台、智能化測試等待，我相信每一個測試人看到一個新技術都想上手試一試，那種手癢心癢的感覺是每一個技術人都無法控制的。但是并不是每一個先進的測試技術都是适合你的團隊的，上面的故事2就是這個問題，我們叫故障演練也好、叫軍演也好，但是這麼好的技術、方案并不是随時都可以用的，而是需要團隊、項目、技術都到了一定的成熟的才能發揮對應的價值，太早的将這些技術投入工程制品流程中無異于拔苗助長。

任何一個團隊的成熟，都會經曆無序最後走向持續的過程，那麼我把團隊的成熟度和技術投入之間的關系做了一個粗略的總結，這也是我個人從業經曆的一些總結。

每個團隊都是從混亂無序開始的，這個時候環境濫用、研發技術混亂、業務不斷變化，沒有版本控制、沒有測試流程，團隊中的小夥伴都是救火隊員的角色，滅火和創造任務并重。在這個階段，任何測試技術的應用都不是必要的，也不能快速的解決問題，建立一套大家統一遵守的流程規範，解決無序的混亂狀态比任何一個測試技術的投入都行之有效。

當我們建立起了内部的研發流程、測試流程、版本疊代規範等一系列的行為規範和流程後，我們就進入環境穩定、技術統一、穩定持續傳遞業務需求的階段。這個時候，測試技術最應該解決的就是提高效率的問題，自動化測試可以降低回歸測試工作量，已經固化下的業務邏輯越來越多，自動化測試逐漸占據了回歸測試的主導地位。性能測試、相容性測試逐漸的推廣開，不斷地推動業務系統的穩定和持續發展。

當我們建立起一套行之有效的測試效率解決方案的時候，我們會逐漸的迎來産研技術的普遍更新，這裡包含了容器、devops的廣發推廣，這也為持續測試提供了前提條件，這個時候測試技術會面向穩定、高效的方向發展。全鍊路壓測、混沌工程、雲真機平台等開始大面積落地應用。

由此可見，團隊、業務的成熟度是決定合适應用更對的測試技術的重要的參照物。

測試技術要站在業務之上做選取

故事:那是眼看着就快要過年前的幾個星期的一個周五，突然就被拉進一個wx群。群還沒來得及修改名字，裡面就一頓消息刷屏。在我第一次進入群裡，就看見有人再說年底集團年會會有搶購類業務需要性能測試。當我看浏覽完我收到的消息後，我發現群名也修改成“XXXX年會性能測試”。既然有性能測試需求，作為品質負責人的我一定要第一時間跟緊，馬上組織内部成立性能測試支援小組，并且按照群裡給出的業務梳理場景，安排下趕緊找業務方擷取并發量的一些輸入資訊。一個小時候，兄弟們都回來了每個人都懵X的說，業務說沒有搶購場景。當我找到性能測試發起人一頓XXYY後，無奈對方手握上方寶劍，無力反駁。為了支援，我們還是按照所有設計業務入口Nigx最大通路量放大了一倍的方式，進行了性能測試，小夥伴們周麼全部加班，周一給出了性能測試報告以及是否需要性能優化的結論。實際年會那天，全部系統超級穩定，性能如絲般順滑，資源特沒有超過20%的數值出現。

故事中無疑就是一次過度測試的典型故事，性能測試的發起人根本對業務完全不了解就擅自決定測試，測試過程中我們投入了大量的人力、物力完成了一個性能測試，最後測試完成後對實際業務并無價值。

總結

故事就是為了講清内容，那麼在目前測試技術火熱的時期，測試技術本身并沒有錯，使用技術的人、時機卻讓測試技術變成了既能提品質效能也能阻礙品質效能的一把雙刃劍。