bug复现率=要求复现BUG数/总bug数
背景
软件测试中提Bug，作为每个测试人员都应该遇到过，那每个测试人员可能也会遇到不停帮开发复现Bug的问题。如果Bug复现对环境要求不高，那复现成本还是比较低的，那如果环境复杂，那复现成本还是比较高，那如何提交BUG有效性，来规避帮开发复现Bug的问题呢？
闭环思维
本人认为具有闭环思维能提高解决、分析问题的效率，何为闭环思维呢？个人给出的定义是：
对一件事物进行剖析重组，实现事物头尾相互映照，由头尾互推的思维模式。
闭环思维为Bug分析中的应用
随着系统架构的越来越复杂，传统BUG模板已经无法满足，以下是仓单bug模块：
上述模板为例，如果提供的步骤只是前段业务层面的点击，然后界面功能不可用的复现步骤，在当前系统架构下，开发让复现问题那是必不可少的，因为提供的信息太少了。
使用闭环思维来剖析不过，个人认为应该在上述bug模板上再增加如下模块：
- 前端请求：给出界面操作请求接口信息，辅助前端开发人员定位问题；
- 后台日志：用来添加对应操作后台服务日志信息，提供更详细信息，帮助开发解决问题信息
- 问题分析：测试人员给出自身分析定位过程，帮助开发提高解决问题效率。
上述模块能形成一个完整的证据链，果因、因果形成闭环相互印证。通过界面功能错误-》前端开发人员通过前端请求模块确认是否是后台数据交付出现问题-》后台开发人员通过后台日志查看后台错误信息-》测试人员提供的问题分析模块对开发人员有引导和借鉴意义。通过三个模块形成一个思维闭环，能有效减少bug复现率高的问题。
以上都是个人意见，如果有异议欢迎探讨