开发说这不是BUG，怎么办

读者提问：开发说这不是 BUG，怎么办？

阿常回答：那你觉得是 BUG 吗。

首先，测试要有自己的判断，不能开发说啥就是啥。

其次，我们来看看 BUG 常见的四种类型：代码错误、界面优化、设计缺陷、需求问题。

一、代码错误

代码错误，即功能错误（功能没有实现）。

如果判断下来是这类问题，测试可以在需求文档中找到描述该功能的地方，用记号笔着重划线标记，再传给开发看，相信开发立马就准备修这个 BUG了。

二、界面优化

界面优化问题，即页面显示问题（比如错别字、排版、布局、字体大小等）。

如果判断下来是这类问题，我们可以找 UED 确认是否需要修改（错别字不用说，必须要改），UED 会从用户体验的角度来判断是否需要做界面优化，一般如果改动难度不大，开发也是愿意修改的。
 

三、设计缺陷

设计缺陷，即没有按照需求文档去实现功能。

如果判断下来是这类问题，我们可以找产品一起沟通，功能是实现了，但跟原本需求设计不符合，看看产品能不能接受这个结果，这样的实现业务是不是也能接受。

如果业务可以接受，产品也点头认可，那这就不作为 BUG；如果业务不能接受，产品明确要求开发必须按照需求文档来实现，那这就是 BUG，开发必须修改。

四、需求问题

需求问题，即需求设计不合理。

如果判断下来是这类问题，我们一般不称之为 BUG，而叫它【需求改进】，这时【需求改进】我们应该提给产品，而不是提给开发。

看完今天的分享对你是不是有所启发呢，有任何想法都欢迎大家后台私信阿常，一起探讨交流

。

转发、点赞、在看三连走起，感谢支持。

程序员阿常

十年职场历程，拥有丰富的软件测试经验，以及项目管理经验。