移動互聯網時代，版本快速迭代，不像之前pc時代軟件更新慢，更新成本較大，出問題並且修復的代價也很大。移動互聯網時代，是允許帶着bug上線的，雖然我們評估有些bug對用戶影響很大，但有些漏網之魚的bug卻讓用戶苦不堪言。在分析很多線上問題的原因時，有些是粗心大意，有些是測試未覆蓋到，有些是需求理解錯誤。用例的設計非常重要，且需要在不同的階段去更新。
就以筆者跟進的項目爲例，整個項目過程大致分爲：需求評審---》技術方案評審---》測試用例編寫---》測試用例評審---》測試執行（使用各種手段：黑盒測試、灰盒測試、代碼走查）---》版本發佈，時常覺得測試就像是一個魚夫，怎麼把所有的魚（BUG）捕出來，減少漏網之魚，那麼捕魚的網就特別重要。而充當魚網的就是我們的測試用例，編織一張細密度的網至關重要。
測試用例在整個項目過程中，不是一成不變的，是隨着項目的推進逐漸完善的。筆者以爲測試用例的編寫、更新完成需要經歷4個階段。
1、第一階段，需求評審結束，開始織大網
需求、交互、視覺評審結束，以我的經驗來看，我一般寫用例是在需求、交互、視覺評審結束後開始動工。如果過早介入編寫用例，由於需求的變更，用例也會相應的變更，造成工作量的浪費。
有的項目交互、視覺評審與需求評審是分開的，可能間隔較久，可以根據實際情況調整用例編寫的時間。
需求評審後編寫的測試用例是基本功能點的，未考慮其技術實現，所以基本是黑盒。但也要包含正常流、異常流。稱這個版本的用例爲v1.0。
2、第二階段，技術方案評審結束
在筆者的項目中，我跟開發存在良好的配合，需要開發在編碼前編寫技術方案，技術方案主要包含模塊流程圖、時序圖、主要的類關係、數據處理等，在評審技術方案時，一方面會感覺到之前在需求時未考慮到的東西，對需求進行了完善，相應的測試用例也需要完善；另一方面，技術的實現不同，用例也需要相應的調整補充。稱這個版本的用例爲v1.1。
3、第三階段，測試用例評審
經過前2個階段，產生了較爲成熟的測試用例，需要召集項目組同學（pd、pm、對應模塊開發、ptm）一起評審，在評審的過程中，羣策羣力，對用例進行修補完善。稱這個版本的用例爲v1.2。
4、第四階段，測試執行
開發完成編碼及自測後，就會提交測試。以筆者的經驗來看，先會參照測試用例初步走一遍，進行第一輪bug轟炸。第二輪會仔細的對各個子模塊進行測試，同時會走查代碼，對重要的地方打斷點執行，這一步完成後，你會發現開發的代碼實現可能和設計有不一樣的地方，或者說開發在編碼時增加了各種if-else判斷，那測試用例需要對代碼中存在的邏輯但之前的階段未考慮到的。
除了走查代碼時對用例進行補充之外，隨着測試執行的深入，你對之前的邏輯可能理解得更深，或者使用探索式測試時，發現了通過當前用例不能發現的bug，相應的需要補充用例。稱這個版本的用例爲v1.3。
通過以上的階段，這份用例已經非常完善了，但是筆者覺得還沒有完，版本發佈後，我們需要時刻關注用戶的反饋，快速處理。so還有第5階段。
5、第五階段，線上問題收集，對漏掉的問題分析，確認是用例漏覆蓋的，補充到用例中，稱這個版本的用例爲v1.4。
如果有心去對比的話，你會發現v1.4版本的用例跟v1.0相比，補充了很多，而這些補充的用例幫助你發現了很多bug，哈哈
至此，項目圓滿結束了，用例的設計工作也算順利完成了。當然，具體操作需要根據各自的項目場景和覆蓋粒度進行調整。