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

4.1 元件化測試的過程改進方向

4.1.1 過程改進

元件化測試本身基於敏捷的思路，發揮測試人員的全程參與能力以及對產品的控制力度。將會結合目前已經形成的測試過程不斷完善。實現測試驅動設計，測試驅動開發的過程。我們最應該落實的首要是：rd應該提供什麼。我們應該如何做。這個應該在整個敏捷過程中不斷明確與打通。

4.1.2 意識轉變

從功能、程式碼的測試意識向加強產品設計、開發、評估的意識轉變。測試的範疇應該更多的納入產品設計的內容與產品評估的內容。這個是一件很困難的事情，但這部分應該嘗試。

4.1.3 技術積累

從整個產品團隊角色，應該儘量避免qa的角色邊緣化，從整個技術發展角度，測試應該形成自己的技術文化與思路。

4.2 元件化測試的技術方向

4.2.1 建模技術方向

建模過程梳理，目前對應的主要是流程模型的建立。


 

建模幾個關鍵標準：（具體技術標準參見wiki文件）

1、 不同粒度的流程與功能在不同級別進行劃分

2、 相同功能屬於同一層次結構

3、 粒度細的流程模型應該對應於具體的功能，對於low level的流程模型，測試方法應該是固定的。(自動化方案也是固定明確的)

其中3是核心。

4.2.2 自動化的方向（意外的驚喜？）技術的低耦合性

標準模型的元件化例項：

A、 對應於目前的元件化測試平臺—主要解決建模與模型分析的方法。

B、 對應於一套自動化框架（從產品特點來看，應該是基於資料驅動）

C、 資料，過程工具的整合維護。

從調研分析可以看到，技術的高耦性會必然帶來失敗。因此，元件化發展時將盡量採取技術低耦合的方式進行。上述三個框圖內容彼此應該是可拆解與組合的。

由於模型建立時基於功能類聚的準則。因此，對於細粒度的模型來說，對應於非常具體的功能，也就是對應於同樣的操作序列，同樣的測試方法，同樣的驗證過程。不同的只是資料而已。資料驅動的良好嫁接。

是意外還是必然？ 從基於模型測試的本身來說，必然會出現這種邏輯，模型是根據當前元件特點建立的，方法上必然具有天生的一致性。這也是模型驅動測試開發的關鍵。

4.3 元件化測試的風險評估

4.3.1 質量風險

基於模型分析的方法覆蓋率已被證明比手工測試建立更加徹底。（注意，這裡的模型包括狀態圖，流程圖，UML圖的形式。 IBM用的較多的是UML圖）

從目前元件化測試的實際結果來看，覆蓋率的提升也在40%左右。

但是有一點前提依賴: 需要經驗豐富的測試人員或者產品工程師進行建模。人的能力挑戰是一大風險。

4.3.2 技術風險

目前模型測試技術研究方面是不算太成熟的，對於資料分析，產品評估方面的方法沒有十分適合的技術，這個存在未知風險。摸索的結果可能完全錯誤。這一點我們希望能儘量參考業界研究，包括建模方法，分析方法。避免彎路。

同時，對於以前的測試模式，方法工具，人員能力都提出挑戰。這個有較高代價,困難重重. 而模型測試本身又需要一定的學習成本。這一塊得挑戰不言而喻。

前途美好，道路曲折。

4.3.3 組織風險

過程改進可能面臨的排斥，主要是敏捷思想帶來的排斥。

4.3.4 規模失控風險

規模失控包括模型失控與case失控。

1、 case失控。包含兩個方面。Case爆炸與無效case。這個對於狀態圖來說非常明顯。微軟spec是個解決方案，但是如何與我們的產品結合是個難題。對於流程圖模型來說，經過人工分析抽象後，case爆炸不會存在。無效case不會出現。這種擔心小很多。

2、 模型失控。主要是模型的複雜度與數量。 這個要注意一個前提，模型測試之初是為了解決複雜大型系統的測試而誕生的。因此模型的建立必須是簡單，明瞭。高度抽象的。這個依賴於測試人員建模過程的分析與把握。

4.4 元件化測試的收益分析（具體參見wiki總結）

4.4.1 質量方面

基於模型分析的方法覆蓋率已被證明比手工測試建立更加徹底。（注意，這裡的模型包括狀態圖，流程圖，UML圖的形式。 IBM用的較多的是UML圖）

以目前受益分析來看，覆蓋率比以前提升在40%左右。

4.4.2 效率方面

以敏捷的思路來做，專案週期縮短是必然的。

後續主要是在元件分析與元件自動化方面獲得較大效率提升。

4.4.3 敏捷過程的完全實施與優化

1、前期介入（建模）

2、測試驅動設計，開發（基於模型驅動）

3、迭代開發

4、維護的極低成本（模型可以更好的應對需求設計變動帶來的修改代價）

4.4.4 產品設計與產品評估的嘗試（產品價值）

1、 產品設計bug在試行與實際執行的幾個專案中都有出現，2-4個不等。本身數量不大，但是意義很大，出現了就是好的。在鍛鍊大家的這種意識。

2、 產品評估嘗試。如何進行產品評估，google在微模型的架構下進行驅動開發，rd與測試人員的產品設計與評估方面的區分被弱化。而這一塊目前我們並沒有嘗試。

4.4.5 技術/流程導向性

1. 技術導向性希望能形成一定的測試方法沉澱。

2. 流程導向性希望能促進測試人員的產品全過程參與能力。

作者：sevensky615

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

【關注百度技術沙龍】

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