读者提问：开发说这不是 BUG，怎么办？
阿常回答：那你觉得是 BUG 吗。
首先，测试要有自己的判断，不能开发说啥就是啥。
其次，我们来看看 BUG 常见的四种类型：代码错误、界面优化、设计缺陷、需求问题。
一、代码错误
代码错误，即功能错误（功能没有实现）。
如果判断下来是这类问题，测试可以在需求文档中找到描述该功能的地方，用记号笔着重划线标记，再传给开发看，相信开发立马就准备修这个 BUG了。
二、界面优化
界面优化问题，即页面显示问题（比如错别字、排版、布局、字体大小等）。
如果判断下来是这类问题，我们可以找 UED 确认是否需要修改（错别字不用说，必须要改），UED 会从用户体验的角度来判断是否需要做界面优化，一般如果改动难度不大，开发也是愿意修改的。
三、设计缺陷
设计缺陷，即没有按照需求文档去实现功能。
如果判断下来是这类问题，我们可以找产品一起沟通，功能是实现了，但跟原本需求设计不符合，看看产品能不能接受这个结果，这样的实现业务是不是也能接受。
如果业务可以接受，产品也点头认可，那这就不作为 BUG；如果业务不能接受，产品明确要求开发必须按照需求文档来实现，那这就是 BUG，开发必须修改。
四、需求问题
需求问题，即需求设计不合理。
如果判断下来是这类问题，我们一般不称之为 BUG，而叫它【需求改进】，这时【需求改进】我们应该提给产品，而不是提给开发。
看完今天的分享对你是不是有所启发呢，有任何想法都欢迎大家一起探讨交流。
