這個文章主題在我自己的看板裡面躺了很久了，其實並不是不想寫，而是一直沒有勇氣來寫。最近鼓起勇氣，為當今測試技術的持續高溫澆澆水，文章中如果有些不妥當那麼請你看看一樂，切莫對號入座。
測試技術和團隊、業務成熟度是相互依存不可分割的
故事: 公司內部開始推行容器平臺，這對於測試來說是一個很好的技術變革。DevOps流水線的支持更容易讓測試工程師掌握測試的主動權，更容易實現持續測試。當我們容器平臺基本可以在測試環境投入使用的時候，團隊內部一個技術負責人不知道用何種方法說服老闆要進行一次故障演練，要把阿里巴巴的chaosblade在內部用起來，要實現老闆一個電話，系統就可以製造一個故障然，來看看全部團隊從發現故障到恢復服務的速度。這個時候整個容器平臺上都沒有一套可以順利走通全套業務的一套測試環境。為了迎合老闆的要求，我們加班加點完成了測試環境業務服務的部署和調試，又投入了7天的人力為故障演練做好的技術支持，最後因為技術部的自研APM無法ready而擱淺。
故事就是故事，但是故事中的問題卻體現了當今很多人為了在工作中為了表現自己的獨到見解而浪費了大量的公司資源做了一些過度的測試。當今測試技術發展快速，有很多傳統的測試技術進步神速，比如性能測試逐漸發展到了全鏈路行壓測，自動化測試技術發展的測試平臺。除此之外還有很多新的測試技術，混沌工程、雲真機平臺、智能化測試等待，我相信每一個測試人看到一個新技術都想上手試一試，那種手癢心癢的感覺是每一個技術人都無法控制的。但是並不是每一個先進的測試技術都是適合你的團隊的，上面的故事2就是這個問題，我們叫故障演練也好、叫軍演也好，但是這麼好的技術、方案並不是隨時都可以用的，而是需要團隊、項目、技術都到了一定的成熟的才能發揮對應的價值，太早的將這些技術投入工程製品流程中無異於拔苗助長。
任何一個團隊的成熟，都會經歷無序最後走向持續的過程，那麼我把團隊的成熟度和技術投入之間的關係做了一個粗略的總結，這也是我個人從業經歷的一些總結。
每個團隊都是從混亂無序開始的，這個時候環境濫用、研發技術混亂、業務不斷變化，沒有版本控制、沒有測試流程，團隊中的小夥伴都是救火隊員的角色，滅火和創造任務並重。在這個階段，任何測試技術的應用都不是必要的，也不能快速的解決問題，建立一套大家統一遵守的流程規範，解決無序的混亂狀態比任何一個測試技術的投入都行之有效。
當我們建立起了內部的研發流程、測試流程、版本迭代規範等一系列的行為規範和流程後，我們就進入環境穩定、技術統一、穩定持續交付業務需求的階段。這個時候，測試技術最應該解決的就是提高效率的問題，自動化測試可以降低迴歸測試工作量，已經固化下的業務邏輯越來越多，自動化測試逐漸佔據了迴歸測試的主導地位。性能測試、兼容性測試逐漸的推廣開，不斷地推動業務系統的穩定和持續發展。
當我們建立起一套行之有效的測試效率解決方案的時候，我們會逐漸的迎來產研技術的普遍升級，這裡包含了容器、devops的廣發推廣，這也為持續測試提供了前提條件，這個時候測試技術會面向穩定、高效的方向發展。全鏈路壓測、混沌工程、雲真機平臺等開始大面積落地應用。
由此可見，團隊、業務的成熟度是決定合適應用更對的測試技術的重要的參照物。
測試技術要站在業務之上做選取
故事:那是眼看著就快要過年前的幾個星期的一個週五，突然就被拉進一個wx群。群還沒來得及修改名字，裡面就一頓消息刷屏。在我第一次進入群裡，就看見有人再說年底集團年會會有搶購類業務需要性能測試。當我看瀏覽完我收到的消息後，我發現群名也修改成“XXXX年會性能測試”。既然有性能測試需求，作為質量負責人的我一定要第一時間跟緊，馬上組織內部成立性能測試支持小組，並且按照群裡給出的業務梳理場景，安排下趕緊找業務方獲取併發量的一些輸入信息。一個小時候，兄弟們都回來了每個人都懵X的說，業務說沒有搶購場景。當我找到性能測試發起人一頓XXYY後，無奈對方手握上方寶劍，無力反駁。為了支持，我們還是按照所有設計業務入口Nigx最大訪問量放大了一倍的方式，進行了性能測試，小夥伴們周麼全部加班，週一給出了性能測試報告以及是否需要性能優化的結論。實際年會那天，全部系統超級穩定，性能如絲般順滑，資源特沒有超過20%的數值出現。
故事中無疑就是一次過度測試的典型故事，性能測試的發起人根本對業務完全不瞭解就擅自決定測試，測試過程中我們投入了大量的人力、物力完成了一個性能測試，最後測試完成後對實際業務並無價值。
總結
故事就是為了講清內容，那麼在當前測試技術火熱的時期，測試技術本身並沒有錯，使用技術的人、時機卻讓測試技術變成了既能提質量效能也能阻礙質量效能的一把雙刃劍。