前情回顧
前面幾期我們談及了如何將測試的介入時間提前， 從而提早發(fā)現(xiàn)問題， 提早解決， 并介紹了兩個實踐：持續(xù)集成和測試先行。這個兩個一個是從業(yè)務(wù)上面預(yù)防問題， 一個是從技術(shù)方面提早發(fā)現(xiàn)問題。是質(zhì)量內(nèi)建中用于提早發(fā)現(xiàn)問題的常用實踐。
但貌似這些實踐都著力于測試之外的范圍， 是否有著力于測試本身的招式去將軟件測試做的更加完善， 有效。這期， 我們就來感受一下軟件測試本領(lǐng)域的內(nèi)卷 -- 測試用例版本管理
通常我們的測試用例， 本質(zhì)上是對軟件需求的各個功能點展開與組合。開始， 在需求逐步增加的情況下，這是很容易的。一般的實踐中測試用例分兩種：
測試需求類型的測試用例
測試動作類型的測試用例
測試需求類型的測試用例描述的是需要測試什么， 例如：測試登錄頁面-進入登錄頁面-進行登錄-查看結(jié)果 這是很不專業(yè)但是很常見的測試用例書寫方法， 寫這種用例的好處就是可以快速的生成成噸的用例的測試不同的功能點。
測試動作類型的測試用例則描述的是怎么測試， 例如：瀏覽器中輸入www.xxxx.com/Login
用戶名輸入框輸入xxx, 密碼輸入框輸入yyyy,點擊登錄；期望：頁面會跳轉(zhuǎn)至www.xxxx.com/Dashboard
這顯然就描述了測試中需要執(zhí)行的步驟，無任何歧義，任何人都可以拿來執(zhí)行；這樣的好處明顯就是可以消除功能測試中用例執(zhí)行的不確定性， 使測試時執(zhí)行的用例即是測試設(shè)計時所想
然而隨著功能點的增加，測試用例根據(jù)功能點變化是指數(shù)級的，一個功能點下會根據(jù)不同的測試精度設(shè)計N條用例， 測試精度越高， 那單個功能點產(chǎn)生的測試用例就越多。
如果這個功能點發(fā)生正刪改的話， 那么就會產(chǎn)生對測試用例維護維護工作。依照不同的測試用例精細(xì)度產(chǎn)生的工作量也不一樣。如果多個功能發(fā)生修改的話會讓維護測試用例這個工作變得更加困難。所以讓測試用例保持新鮮度（實時吻合當(dāng)前的功能）是非常大的挑戰(zhàn)。
如何解決？
在實際的修改過程中， 我們通常會遇到兩個困難點：1.用例多 2.定位難
在指數(shù)型的用例爆炸時，即使識別出了需要修改的用例，因為種種原因， 可能是設(shè)計過為精細(xì)或者功能點組合過于復(fù)雜， 導(dǎo)致有很多條需要修改。
因為要修改的用例太多，這個時候的反應(yīng)要么就是花時間去重新寫用例，要么就是迫于壓力，采用能測則測，能舍則舍的方法去測試， 這時的測試用例聊勝于無， 如果錯將已經(jīng)失效的用例當(dāng)成正確的執(zhí)行要么就是誤報，要么就是漏報。
最好的解決方法是按照模塊去規(guī)劃，不斷的將測試用例進行原子化處理，使用業(yè)務(wù)逐級下分的方式，這里有個坑，就是往往一個測試的集合是多個人編輯的， 有可能存在放錯地方問題，這個問題也很好解決：套用開發(fā)的實踐-code review，來個testcase review ， 一天一個高產(chǎn)的測試工程師也就是60個用例，假設(shè)一組有5個測試， 300條用例，灑灑水啦
有了原子化的測試用例， 當(dāng)一個功能點發(fā)生變更的時候， 只需要根據(jù)變更的功能點廢棄或者重構(gòu)某個節(jié)點即可， 由于用例是原子性的， 重構(gòu)的成本為所有情況中最小
所以針對用例多 這個業(yè)務(wù)痛點場景， 原子分類法的效果如下：
此外，也可是使用模糊用例的方法， 很多小微的項目為了響應(yīng)這已知的變化通常會將用例寫的比較粗糙， 或者僅僅是記錄測試的思路， 有的是畫一個腦圖，梳理用戶故事， AC等等， 然后介于AC之后的方向繼續(xù)發(fā)散，得到一些沒有步驟但是明確要測試什么的一個文檔。這個文檔的形式有很多， 總體的特點就是可以一目了然的看到所有功能。
對于實際測試時， 需要根據(jù)當(dāng)前的思路繼續(xù)即興發(fā)散， 得到一個相對比較準(zhǔn)確的結(jié)果。
這種方法也無疑會減少因功能變更導(dǎo)致的用例失效， 畢竟“你變?nèi)文阕儯?意識在中線”
對于由于用例的分配和知識散點的出現(xiàn)， 會導(dǎo)致在功能點發(fā)生變化的第一時間， 無法精確定位到對應(yīng)的測試用例，這個時候就會有第一時間找不到，測的時候碎一地的結(jié)果。
這時除了上面提到的原子分類法可以解決歸類找到對應(yīng)的測試用例以外，可以使用測試用例管理工具來快速的查到你需要修改的用例， 例如，zephyr, testhub, Ones testcase， 禪道，云效， tapd等等， 通過搜索對應(yīng)的關(guān)鍵字可以非?？焖俚恼业侥阆胍薷牡膯栴}，甚至有些功能可以直接將用例關(guān)聯(lián)到需求上， 需求變更后直接通過需求下鉆的方式就可以順路去修改即可
好了， 到了這里也列舉出了幾個常用的基礎(chǔ)方法，用來解決用例多， 改用例困難的問題， 每種方法都能解決一個或者多個問題， 不過要解決定位難和用例多的問題， 貌似必須要采取多種方法混合的策略， 是否有一個通過的方法，或者是否有更高效的方式去管理測試用例呢， 有的， 這就是今天的主角--測試用例的版本管理
是想有這樣的一個用例發(fā)展圖：
看起來與開發(fā)中的版本管理如出一轍：
這樣做的好處
使用軟件開發(fā)的版本管理策略管理測試用例， 本質(zhì)上是使測試用例有了版本的概念：
這樣可以：
記錄用例的歷史變化
可以隨時隨地的將用例恢復(fù)到任意一個時間點
支持同時對多個不同需求或者不確定需求進行測試設(shè)計，保證了測試設(shè)計的進度
可以多人協(xié)作， 一起去review用例，使得測試更加完備
可以隨時的將幾個分支進行合并， 強制去除無效的用例
雖然對于版本管理這個技能很多測試都還不具備，但有很多工具可以幫助測試完成對應(yīng)的設(shè)計， 且版本管理目前的學(xué)習(xí)成本很小。
值得一提的是， 測試用例管理的方法可以是一個方法論， 并結(jié)合上面提到的工作進行混合模式， 這樣就有了測試用例管理的proplusmaxultra的版本了（笑）
下期預(yù)告 :
版本管理固然重要， 目前所有的實踐都是散兵游勇， 下期， 我會介紹測試流程的編排，從整體上和大家一起討論如何優(yōu)化測試流程和測試流程的本質(zhì)。
