网站建设的好处论文发帖平台

　　测试用例覆盖不全面的解决方法

　　问题分析

　　在测试用例设计过程中，容易出现思维受限或者需求盲区，我们不可能完全覆盖用户使用的所有场景，编写测试用例的时不可能把所有的场景都能想周全，把所有的场景下的情况都写成测试用例去模拟、去覆盖这也是不太现实的。

　　改进措施

　　·用例设计开始之前，列思维导图

　　通过思维导图列出业务流程，前、后端接口逻辑。然后按照PRD和交互文档，依照UI界面切分成大的功能块，然后在大功能块，然后在大功能块再切成小功能块，最后到功能点，每个功能点通过UI、基本功能、边界、内存、数据、交互、接口逻辑等维度开展用例设计导图，并列出需找产品、开发确认的疑点。

　　

　　· 用例设计完成后组织用例评审

　　a. 组织开发、产品进行测试用例评审，并抛出用例设计时的疑问，通过产品实现角度、数据存储、用户、产品体验角度对用例进行评审完善补充。

　　b. 组织测试组内提前预审测试用例也是非常必须的，对于正式用例评审前会组内进行预审，在版本结束后组织全量用例集合入也会进行串讲用例，特别是一些经验老道或者业务熟悉的老司机们，可以在用例评审上快速的帮忙指出用例的遗漏点，有助于测试人员打开思路，尽可能多的覆盖用户场景，值得注意的是用例评审上遇到不确定的，应立即记录下来作为待办项，结束后及时找相关人员确认，避免猜测不确定。

　　· 总结用户反馈、完善测试用例流程 - 下钻测试用例构建以有备无患

　　a. 产品测试发布上线后，对于用户反馈的缺陷，如果缺陷是因为场景设计不全引起的，我们先分析出现问题的场景是必现还是偶现，如果是必现，我们可以通过和技术同学沟通，确认该场景的一些具体复现步骤，确认引入原因，解决方案。

　　b. 对于线上如果出现缺陷需要对测试用例完善：除了补充该场景case外，考虑一些和该场景相关联的场景，将多种场景下测试用例及时完善、评审，增加到用例库中去。

　　c. 针对线上缺陷分析其具体原因做复盘总结，关注线上问题反馈群，及时发现问题、定位问题、分析原因，判断是否为老逻辑引入还是新功能引发问题，精准化补充对应的用例，针对特别场景补充接口自动化、防资损数据狗校验、全量用例集合BVT用例。