測試之道，從哪裏來，到哪裏去？

這裏不談哲學，也不是無的放矢，而是有感而生。這要回到兩個月前，看到兩篇文章：

• 軟件測試人，大家在逐漸失去一些東西
• 測試十二年-六道輪迴後的初心可否找回

做者都是一線的資深軟件研發人員，瞭解測試的過去，但更受目前測試現狀的煎熬：

• 面對這些被測對象，大家的質量理念是什麼？

• 不知道後來人會怎麼評價這一段歷史，從質量技術人的角度看，理論與應用不但停滯不前、還在不斷後退「追求形，忽略神，當心技術革命的坑」

• 測試用例，一個熟悉而又陌生的名詞

• 大部分人對於測試生涯、測試價值、測試發展、測試方向都有一種悲觀的預感。

• 咱們都是不敢正視這些問題的，由於咱們會被完全戰勝

• 有沒有去思考測試自己的核心定位，測試自己的經驗教訓究竟是什麼？

• 測試的目的和初心究竟是什麼？

• 咱們還能找回初心嗎？

• 還能靜下心來思考咱們真的是正確的作測試嗎？

• 真的只有這樣的一條路嗎？咱們還能有其餘的路嗎？

• ......

纔有瞭如文章標題那樣的演講。

軟件開發模式、技術和環境進步很快，但軟件測試則感受進步較慢、****比較被動，這其中的緣由可能不少，軟件測試的從業人員少，研究軟件測試的人更少、在軟件測試上的投入也比較低。

1. 今天的軟件測試如何呢？

積極的一面：

• 重視持續集成（CI）建設、關注DevOps

• 很是關注自動化測試（TA）

• 多數公司建成（TA）測試平臺

• 開始大量使用開源測試工具

• 代碼靜態分析有較大提高

• 大數據、雲平臺的測試初有成效

• 軟件測試社區活躍

• …..

負面（主要問題）：

• 公司的質量基建年久失修

• 內建質量文化沒有造成，缺陷預防作得較差

• 熱衷於招測試開發、重複造輪子，但TA成效低

• 熱衷技術，而缺少對測試自身的思考

• 面對軟件開發新模式缺少應對策略，如敏捷測試是形似而神不似

• 介入研發深度不夠，測試效率偏低

• 許多困惑依舊困擾很多測試人員

• ……

大多數測試人員還有下列困惑：

• 測試與開發有沒有界限？

• 誰來作測試更好？

• 如何更好地開展測試活動？

• 如何快速反饋質量？

• 測試效果的度量？

• 測試有沒有發展前途？

• ……

再舉一個例子，自動化測試是你們最爲關心的、最願意投入的部分，但成效很低。例如：國際上調查報告顯示：

 

根據國內今年的調查結果，顯示國內TA情況更糟糕：

 

 

若是在深刻TA的投入產出（RoI），可能就更糟糕。在TA上投入很大，而收益很低，特別是在需求不穩定、變動頻繁的狀況下，收益更不明顯。

2. 從新找回測試的初心

——按時交付用戶滿意的產品

 

（許多測試人員不瞭解 軟件質量模型 ，這是很可怕的）

如何找回初心？就是要多思考思考測試自身的問題——測試的質量（充分性）和測試的效率，從下列這些方法不斷思考如何作好軟件測試：

• 如何作好軟件測試的策劃、分析、設計、執行、評估、管理？

• 如何從被測對象——產品自身來提升其可測試性？

• 如何在組織中營造良好的質量文化？

• 如何制定有效的測試策略？

• 如何運用好測試方法、技術、工具？

• 如何創建穩定的、和開發環境集成的基礎設施？

• .....

 

測試是不能窮盡的，無論採用什麼技術和工具，測試老是有風險的，咱們就要去思考如何下降測試風險，包括測試輸入、操做和上下文（應用場景）、業務規則組合、環境的多樣性、Test Oracle的啓發性等：

 

提及測試金字塔，十有八九會提到這個：

 

這裏實際是展現了自動化測試（投入）策略，但測試不僅有一座金字塔，還有兩座更爲重要的金字塔：

 

由於常常感覺到很多測試人員忽視測試需求分析、缺少測試分析和設計的思路，甚至本末倒置，一上來就討論功能及其測試用例，忽視業務、忽視用戶行爲、應用場景的分析，而產品最終是須要知足業務需求、知足用戶的需求，能適應不一樣的應用場景。測試設計的確重要，須要依賴所設計的測試用例（測試腳本）來執行測試，測試的覆蓋率體如今測試用例的覆蓋上，但沒有測試分析做爲基礎，測試設計會忽視某些測試區域、測試風險等。若是按照右邊金字塔這樣的分析設計之路去探索、逐步細化、逐步擴展，測試的充分性就有良好的保證。

1. 測試的明天

當咱們迴歸初心，在今天快速發展、激烈競爭的環境下，還會遇到一些新的挑戰：

• 極速測試

• 高度的自動化

• 開發者自測（賦能、責任心）

• 大規模系統的複雜性

• 新技術

• ……

如何應對這些挑戰呢？

（這裏省去一萬字，如文化與流程重構、技術提高、開發與測試的融合 ... ）

1) 契約驅動測試（CDT）

• 下降服務集成的難度，將其分解爲單元測試和接口測試

• 團隊能以一種離線的方式完成驗證, 並將聯調的成本幾乎降到零

• 基於契約讓接口的變動有跡可循

• 經常使用的CDT框架 Janus、Pact、Pacto和Spring Cloud Contract

1. MBT的高度自動化, **幫助咱們克服下列問題：

• 自動化程度低

• 模糊的需求

• 有限的測試覆蓋率

• 測試數據瓶頸

• 某些組件沒法正常工做

1. 端到端的、全覆蓋的TA

• ATDD/BDD、需求可執行

• 全SDLC

• Harness/高度集成

• 跨平臺

• 可測試性保障

• 支持CD、DevOps

  image

4）AI助力測試

• 智能的單元測試

• 智能的UI/API測試

• AI驅動的腳本生成

• 優化或補充測試用例

• 質量風險評估的自我調整

• 缺陷診斷機器人（DDB）

• 測試環境的智能運維

• ……

5）總結：測試發展趨勢

• ATDD/BDD/RBE，需求即測試~完全左移

• CI/DevOps: 測試與開發、運維更加融合

• 分層測試、API/契約驅動測試

• ET + TA: 更有效的測試策略

• 藉助MBT+AI，高度、智能的自動化測試

• 高度的可視化、集成化的過程監控、在線測試與實時反饋

• 測試人幹更具創造性、綜合性分析建模的工做

結語：

跟你們推薦一個學習資料分享羣：718897738，裏面大牛已經爲咱們整理好了許多的學習資料，有自動化，接口，性能等等的學習資料！人生是一個逆水行舟的過程，不進則退，我們一塊兒加油吧！本文轉載自微信公衆號，若有侵權，請聯繫刪除！