第一篇：梳理Checklist的时间分配问题
一、常见问题：
1、什么时候该补充Checklist？
2、Checklist应该写哪些用例？
3、每次更新Checklist后上传云盘的命名规则？
二、解决方案：
1、什么时候该更新补充Checklist？
这个问题的处理分不同的情况，每个情况的发生我们都有不同的处理方式去编写此次负责模块的Checklist。如下则是对此类情况作出的说明。
（1）项目未开始测试前补充
测试用例编写完成，p0 用例已输出，并且经过了评审，此时若负责的模块还未转测，则在此期间根据已完善的P0用例优先来更新一轮此模块的Checklist。如此操作则完成了大部分此次负责模块的Checklist的补充，待项目结束时若有中间变动的需求跟前期的不符，此时再次需要对Checklist做小的调整与优化补充即可，如此则完成了所有Checklist的此次模块编写。
（2）项目结束后预留时间补充
若此次负责的模块好多则比较杂，在用例评审完则进入了测试阶段，中间无空缺的时间来进行Checklist的补充，则在版本上线后，及时对主管或者项目经理说明下情况，此时将会对你手上的事项做对应的调整，预留出一定的时间对Checklist进行及时的补充。
（3）前后2个项目中穿插并行补充
前个项目已上线，也未空缺出时间来编写Checklist，但当前的项目已启动，因此这种情况下，若当前的项目对应测试用例已完成，但仍未有功能的转测，这时我们可对前个项目的模块做Checklist的补充，补充后再次启动当前项目的测试，顺序进入到测试阶段。
第二篇：在实际执行中的问题与解决方案
一、对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%的时间。
结合我们多个版本的经验使用，用例筛选与预留做的好，在执行中会获得很大的收益
具体示例做法截图：
