10年经验之谈:4步解决测试与开发人员有争议的bug问题! |
您所在的位置:网站首页 › 解决bug的正确方式是什么意思 › 10年经验之谈:4步解决测试与开发人员有争议的bug问题! |
“开发认为不是bug,测试如何处理?”很多面试中,测试工程师都会被问到这个问题,不仅仅是面试,工作中测试人员也会遇到这类问题,甚至可能由于某种原因,无论是开发人员还是开发经理就是不愿修改程序,那该如何处理这个棘手的问题呢? 首先,当与开发出现分歧意见后,测试工程师应首先做如下分析: 一、问题确认与评估再次论证该问题确实是程序缺陷,并评估该缺陷的重要程度并对其分类。比如可存在以下分类: 1、设计文档范围内的功能性缺陷 2、影响到程序的安全性和稳定性缺陷 3、界面缺陷 4、一般性错误(如未考虑边界检查等) 5、边缘死角,规律不明显,不太容易重现的错误 6、兼容性错误(例如旧机型、CPU\MEM,旧标准等等) 7、安全性或易用性等的修改建议 ……(可扩展) 二、明确Dev不修改该缺陷的确切原因比如可存在以下原因: 1、规律不明显,不好重现 2、dev认为是不影响主要功能的一般性bug,因时间处于版本的稳定期,担心牵一发动全身引起更多错误 3、调用了第三方组件或库函,是第三方程序存在的缺陷 4、存在技术难点 5、设计本身存在问题,程序逻辑是正确的,但实现结果并非用户所需(换言之,dev说这是设计问题,不是程序问题) 6、Dev的个人主观意见: 该瑕疵可以容忍,没必要修改 修改该瑕疵会引起更大的问题 7、Tester和dev对错误的理解有分歧: tester理解错误,该问题并不是bug tester没有说服dev这是个bug ……(可扩展) 三、具体问题具体分析分析完第一、二步之后,也就基本上明确了问题的争议焦点,然后具体问题具体分析。分析什么Bug会让开发认为不是bug? 测试人员描述不清晰 工作中也有测试人员把某些“Bug操作步骤”描述的只有自己看得懂,开发人员按照步骤复现Bug不知所云,搞错了问题所在。 解决方法: 修改Bug操作步骤:清晰描述、无歧义、无冗余步骤,要达到即使给一个不懂的人去重现这个Bug,也能按照你的操作步骤复现。 难以复现的Bug不是所有的问题都能用同样的操作步骤来复现的,有的Bug概率出现甚至偶现,或者是只在测试环境里出现。 解决办法: 针对难以复现的Bug,需要保存截图或者记录log保留证据;对于只在测试环境下才会出现的,找研发在测试环境进行确认。这类Bug要慎重对待,规避风险。 有争议的Bug有争议的Bug多发生于建议类型的Bug:与同类软件不符、易用性、美观性等类型的Bug。 解决办法: 这种问题是否要修改需要根据公司的项目类型进行讨论。开Bug评审会,在开发能实现的情况下说出自己的理由,改善产品。 功能性Bug与需求不符、与原型设计不符。有时候研发对需求没有深入了解可能会忽略或者搞错个别功能。 解决办法: 拿证据(需求、设计说明书)给他看,这种bug自然合情合理。 四、发挥TM与PM的沟通职责强调沟通 TM和PM有团队沟通的职责。在bug分类、指派和反馈过程中出现有争议的问题时,TM和PM有责任和义务进行干预。根据问题的重要程度和轻重缓急,采取不同的方式进行沟通,达成一致的解决意见,解决方法形成备忘录。 对因各种原因继续保留在发布版本中的bug,尤其可能影响功能的,应予以说明,提醒用户绕过。 经验教训库:这里的每个内容都是一个你犯过的错误,你在这里也记录的总结和反思;随着系统开发不断往前迭代,BUG的内容也会越来越丰富,沉淀了越来越多的经验,帮助我们了解错误原因所在,避免再犯。必须要说的是,一个团队要强大起来,先从自己的BUG系统开始做起。 下面有我近几年的收集和整理,整体是围绕着【软件测试】来进行整理的,主体内容包含:python自动化测试专属视频、Python自动化详细资料、全套面试题等知识内容。 关注微信公众号【程序员二黑】即可领取Python自动化测试超硬核资源啦 |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |