用例需要动态设计更新

        移动互联网时代，版本快速迭代，不像之前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，哈哈

        至此，项目圆满结束了，用例的设计工作也算顺利完成了。当然，具体操作需要根据各自的项目场景和覆盖粒度进行调整。