软件测试培训
达内IT学院
400-111-8989
软件测试培训
如果测试和开发有关于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
……(可扩展)
三、具体问题具体分析
分析完第一、二步之后，也就基本上明确了问题的争议焦点，然后具体问题具体分析。
1、如果dev认为不好重现，则tester有责任和义务找到更简洁有效的重现规律。
2、如果tester没有说服dev认识到这是个缺陷，则需要拿出强有力的证据(测试用例、设计文档、错误现象等)来证明。
3、对于第三方库函bug,或技术难点导致的bug,则坚持原则--宁缺勿滥，必要时宁可封掉该功能。
4、针对错误的设计、不能说服的dev主观理解、改动隐患，以及稳定期等特殊情况，则可通过TM进行多方沟通。
四、发挥TM与PM的沟通职责
强调沟通
TM和PM有团队沟通的职责。在bug分类、指派和反馈过程中出现有争议的问题时，TM和PM有责任和义务进行干预。根据问题的重要程度和轻重缓急，采取不同的方式进行沟通。如出现“三”中3、4类较大争议的问题，可通过会议研讨等形式召集多方进行论证，并达成一致的解决意见，解决方法形成备忘录。
对因各种原因继续保留在发布版本中的bug,尤其可能影响功能的，应予以说明，提醒用户绕过。
预约申请免费试听课
填写下面表单即可预约申请免费试听！ 怕学不会？助教全程陪读，随时解惑！担心就业？一地学习，可全国推荐就业！
下一篇：一个UI BUG引发的血案
-
扫码领取资料
回复关键字：视频资料
免费领取 达内课程视频学习资料
Copyright © Tedu.cn All Rights Reserved 京ICP备08000853号-56 
京公网安备 11010802029508号 达内时代科技集团有限公司 版权所有
选择城市和中心
北京
黑龙江省
吉林省
内蒙古
河北省
陕西省
江苏省
上海
湖北省
四川省
重庆
湖南省
江西省
贵州省
云南省
广西省
广东省
海南省
台湾