琪恋网站建设,网站 mip,wordpress模板不显示文章页,哪些网站适合瀑布流对CheckList的执行发起的思考#xff1f; #xff08;1#xff09;功能越来越多#xff0c;CheckList越补充越多#xff0c;执行CheckList时间越来越长#xff0c;如何减少上线的验证时间#xff1f;#xff08;2#xff09;减少上线验证的时间外#xff0c;如何保证… 对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
