【CheckList】精简用例,提升执行效率,减少漏测(总结篇) | 您所在的位置:网站首页 › 功能测试用例设计思路是什么意思啊 › 【CheckList】精简用例,提升执行效率,减少漏测(总结篇) |
第一篇:梳理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%的时间。 结合我们多个版本的经验使用,用例筛选与预留做的好,在执行中会获得很大的收益
具体示例做法截图:
|
CopyRight 2018-2019 实验室设备网 版权所有 |