對CheckList的執行發起的思考？

（1）功能越來越多，CheckList越補充越多，執行CheckList時間越來越長，如何減少上線的驗證時間？
（2）減少上線驗證的時間外，如何保證質量？上線后少出現漏測？
（3）用例如何劃分，方便后期新人員查看與維護（補充和篩減等）？
（4）用例如何統計，方便根據用例條數評估執行時間？

?

預期的收益與目標

（1）根據不同的版本執行不同的CheckList用例，減少驗證時間
（2）保證所有功能的主流程與功能均包含，避免上線后的遺漏
（3）用例按模塊進行劃分。模塊中在按照功能點進行劃分編寫用例。方便維護
（4）通過某種方式記錄所有模塊的用例條數，在用例進行更新后及時同步數據，已數據來判斷上線時的工作量。
（5）能盡快的完成上線，且需要保證線上用戶的使用質量

解決思路：

? ? ?將CheckList進行分類，根據不同的分類在不同的情況下分別執行對應的類別。定期性的執行全CheckList用例，保證在之前版本中出現一些細微的改動被遺漏掉的可能性。依此來減少用例的執行時間。又之前的全用例執行4小時縮短到2小時。同時也保證了主功能模塊的功能正確性，避免對用戶的使用上造成不便引來不好的投訴反饋等。

實現方式：
　　CheckList的分類，共三類且共同遵守的原則為：根據功能模塊的分配優先級

　　CheckList_完整版：

　　　　所有功能模塊用例，用例較全，所需執行時間長，可定為3個版本一執行完整版用例等。

　　CheckList_精簡版：

　　　　包含所有功能模塊，用例主要涉及到主功能模塊或層級較淺為1到2級的用例。對于重點模塊及用戶常使用的模塊可進行稍微的細化。保證用戶在使用時出現功能不可點擊、閃退、白屏等問題。用戶不常用的模塊可進行較粗糙的用例編寫。因此不需要太精細，大膽的刪除不必要的用例。因為在功能測試時，對于模塊的驗證一定是細而全面的。所以在CheckList時只是作為再次的走查校驗。在小版本更新迭代時，用例執行選擇“精簡版用例”。依此來縮短執行時間。
　　

　　ReviewList_線上：

　　　　包含所有功能模塊，用例整體性較粗糙。在生產環境用來執行。目的是為了再次確認預發布、測試環境的改動未影響到線上，也再次確保了線上質量的可靠穩定性。一般由于測試環境和預發布環境的某些限制，導致某些功能不能執行，此部分的功能也會遺留到生產環境進行驗證。

?

用例的精簡方法：

（1）采用先減后加，放開膽子去刪的思路，后面再查缺補漏即可
（2）針對1級用例中與當前版本不符的用例進行降級。確定好它的等級并進行標注。
（3）針對2級用例的篩減，一般來說2級用例是量最大的，1級和3級用例都只占一小部分而已。此部分要做到大膽的刪減，原則是只留屬于主路徑和重要的異常路徑，其他全部降為3級

?

用例的評審：

目的：用例夠精簡且不會遺漏
具體做法：
（1）主路徑：

　　打開app，檢查每個模塊的用例，app中能看到的所有入口必須涵蓋在1級用例中。

（2）用戶常用場景：

　　將用戶常用場景按照模塊列出來，對照相對應的用例，1,2級用例必須全部涵蓋。

（3）運用集體智慧：

　　人的經驗轉換，一起共同測試的同學聚在一起，按照模塊一起review用例，覺得哪里有遺漏，按照經驗什么地方經常出問題，是否需要增加用例，討論之后覺得合理的加入。

（4）線上缺陷&線上反饋：

　? ? 版本發布后，根據線上缺陷&線上反饋來檢查，是否是測試用例遺漏造成的，分析線上缺陷的根因，根據嚴重等級和用戶反饋數來決定是否要添加用例，以及應該添加到哪個階段最合適。

后期的維護：

（1）線上bug跟進，看是否有bug是因為精簡用例而造成的缺失，分析并查缺補漏
（2）根據版本中功能的增加，應用上面的方式進行用例的精簡與統計。

總結（實現方式后的收益與目標）：

　　小版本的發布：
　　用例條數：由原來的用例數減少了50%的執行量。
　　執行用例時間：在原來的執行時間上至少縮減了50%的時間。

　　結合我們多個版本的經驗使用，用例篩選與預留做的好，在執行中會獲得很大的收益

?

具體示例做法截圖：

　　

　　

　　

?

轉載于:https://www.cnblogs.com/syw20170419/p/11234678.html

總結

以上是生活随笔為你收集整理的CheckList 如何梳理可减少上线的验证时间（总结篇）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。