一種測試方向的探討-基於模型測試調研引發的思考-1

1.1 敏捷是一種態度

敏捷是目前組內嘗試開發模式。結合實際操作，總結一下看法，敏捷更多的在提倡一種理念與態度，而非技術本身。

1.1.1 技術角度分析 

從技術角度來講，敏捷本身並未提供或定義具體的方法。敏捷更多的是在提倡一種更快更高效得開發模式，來縮短產品上線週期。如被經常提及的提前介入，迭代開發，更多溝通，測試驅動設計，測試驅動開發等等。

1.1.2 產品流程角度分析

從整個產品設計流程上來說，敏捷要求處於流程後期的參與者對於產品的參與度與貢獻度更大。因為產品的末端參與者通常處於比較被動的角色，這種被動性是產品週期縮短的天然屏障。這勢必對測試人員提出最大的挑戰。如何主動前期介入，如何更有效的介入，如何成為推動產品週期的動力，如何驅動設計與開發。這個是敏捷測試的核心價值。

1.1.3 敏捷的誤區

敏捷本身提倡更簡單的流程，更高效的工作。但通常實踐時經常出現2大誤區：

1、很多事情不做就是敏捷了。敏捷的核心是化繁為簡，不是直接刪除。 （調研的過程中發現不少rd的意識是隻寫程式碼，別的不提供。Qa的意識是當前專案快速over，產品維護並不考慮。這個不僅給測試帶來較大麻煩。對於產品的迭代開發來說更是一個噩夢。） 敏捷的過程需要整個產品團隊保持遠見，保持對持續整合，迭代開發的高度關注。不僅是為了現在更快，而是為了將來越來越快。

2、敏捷對於流程，技術，文件的要求變得更高（更簡單與高效），而不是一部分人認為的降低。

1.2 模型驅動是一種過程+方法

模型驅動是伴隨著整個軟體物件的複雜性，規模型，不可控性，自動化迫切性，分散式等要求越來越高而誕生的。模型驅動核心是對產品物件建立模型，通過模型驅動設計，開發與測試。方法本身天然包含對整個產品開發過程的梳理與重構。

1.2.1 從過程角度分析

模型驅動希望在產品設計階段，產品週期的所有參與人員進行模型制定。測試人員在專案啟動時介入，進行產品bug（mrd bug），設計bug（架構bug，文件bug，思路bug）的發掘（這一點基於bug發現的越遲，代價將成指數級增長的原理。）。提倡更多的溝通，降低產品升級的影響，讓迭代開發變得更高效。

1.2.2 從技術方法角度分析

模型驅動包含建立模型，分析模型，翻譯模型，執行，結果對比等階段。建立模型的思想是核心。業界比較成熟的建模方案包括（基於狀態機，基於資料流，基於產品邏輯，基於馬爾科夫模型等等。） 通常會提供建模到自動化執行的一系列解決方案。

總結:敏捷體現的是一種態度，基於模型測試是敏捷思想的方法實踐，元件化測試只是模型測試的一個分支。

1.3巧合還是必然的一致?(組織與技術的雙重挑戰)

1.3.1 更短的時間更完美的產品

產品最終服務於使用者。從純商業角度看，追求收益是最終目標。具體的技術表現就是更短的時間，更完美的產品。因此無論敏捷還是模型驅動測試在這一點上應該是高度一致的。

圖表 1敏捷思想=〉模型驅動=〉元件化測試

1.3.2敏捷與模型驅動對比分析

圖表 2敏捷與模型驅動對比分析

總結：組織與技術的雙重挑戰。無論敏捷還是模型測試帶來的衝擊，我們需要做好準備.　

作者：sevensky615

 

【本文首發於：百度測試技術空間】http://hi.baidu.com/baiduqa/blog/item/72cbd18b2c05f0bf0f24440e.html

【關注百度技術沙龍】

本文轉自百度技術51CTO部落格，原文連結：http://blog.51cto.com/baidutech/743246，如需轉載請自行聯絡原作者