关于界面的一些bug被开发人员轻视的问题

Erin_gy

这个问题不知道发在这里是否合适，还是请大家给些建议！
在测试过程中，我特别注重页面上的一些bug，因为我认为用户界面的好坏直接影响系统使用者的第一印象。
因此，在功能实现之余，常常要求研发人员修改页面上的bug，比如某个输入项没有垂直居中，某个输入框的长度设置的不合理等等一些小问题。这些页面上的小问题使得开发人员很反感，他们认为这些bug提出来没有任何意义，在一定程度上说是没有水平，我听到他们说这些就非常生气。
我不知道，我是否真的没有必要提这些问题，请大家指点一下，谢谢！

shanxi

如果头重视用户体验就坚持
如果否，除非特严重的否则就不要纠缠下去

Erin_gy

您的意思是以后这些非严重的页面的bug就不要提出来吗？还是说照旧提出，对于是否修改可以不管呢
您也清楚开发人员只是按照demo来做，但是我们公司由于不规范，对于demo根本不评审，页面布局是否合理等等一些问题都没有考虑，仅仅是做出来后让用户看看样品，之后直接提交给开发人员按照demo来开发了。
因此，我看到一些页面上不合理的地方就很郁闷，不知道是否提出来sdlkfj7

scarlett

我以前做过日本外包的一个测试。他们对界面上的要求非常严格。字体的大小。颜色。还有错误信息。页面样式等等。小到字体是否是全角半角，前后是否多了一个空格等都要测试。他们提出来的一个观点就是。用户并不十分了解具体你的业务逻辑是怎么处理的。但是他们对页面是否友好。对他来说是否习惯。等等。要求会比较高一些。这也就是所谓的第一印象。如果第一印象都不好。后面的做的再好也会直接扣掉你的分数。不过，现在公司并不注重这个。他们觉得就页面上的一点小问题。不值得斤斤计较。。。但是我觉得做为一个测试人员来说，要能够站在客户的角度去把好质量关，就算是这些小问题，也要尽量去争取，我想你坚持的话，还是有点用的。毕竟页面上面的改动工作量也不算大吧。。。哎。不过做起来难啊。

ieee

还是要看用户的要求和本公司对待该问题的习惯处理方法,如果从客户到管理者对界面细节都不在乎的话,那提也是白提,建议故障单还是要提,改不改请开发经理定夺,尽量不要与开发人员有太多争执,这样不利于长期合作

kevin_park315

提UI的错误其实很简单，但要根据项目的阶段去提不同的UI问题。这里就有一个策略问题，前期你不要提，当主要功能实现以后在提，而且要分等级。到软件开发结束后，也就是功能都实现，开始Fix bug时，在把小的UI问题提出来。一般开发的不回为难你，到哪个时候。你想，他连功能还没有coding完，能关心UI 问题吗。 聪明点，学会他们的工作方式。sdlkfj5

kevin_park315

关于UI设计不合理的问题，坚持一个原则：不要提。
这个是问题分析很难，从设计上讲是UI design的人负责，你很难去跨部门处理这样的问题。尤其是客户的东西。在一个问题是，不合理是你个人看法，不是一个科学的东西。你要让他们去该，就不是开发的人能帮你解决的问题。

wangpeixian

好多高手在里面啊,我还是刚进来的,不过我的好奇心吸引我来看了,因为我也想知道答案

pigpigpig444

启发式评估法则(HE)是对界面设计的可用性进行分析的技术　通常用来在开发的早期阶段，评估人员对界面进行评判
１系统状态的可见性　　　比如装软件的时候有进度条　如果没有　用户可能以为死机　很久都不动
２系统与真实世界的匹配　比如中国日期是yy/mm/dd　欧洲国家就是mm/dd/yy
３系统使用的自由度    　　比如一个程序在进行一个操做　没有返回退出等放弃操做按纽
４一致性和符合标准　　
５预防错误的发生　　　　比如要求输入信息　用户输入无效信息　在按确定前给出提示
６以认知取代记忆　　　　比如步骤２的输入需要步骤１结果　那么应该将步骤１显示在屏幕上　而不是要用户去记住
７弹性与效率　　　　　　快捷方式
８美学及最低要求设计　　比如最大的就是最重要的　如此心理暗示
９帮助用户识别诊断修复错误　同HE1　可以看作其一个子集
１０帮助和说明文档　　除了上手就能用的软件都需要

LZ提出UI的时间貌似晚了点　
呵呵开发人员一般都会对自己提出问题的测试人员反感的　给他们增加工作量　好好沟通吧

残月弯刀

我认为，比较严重的界面问题就直接提一个bug单，如果不是很严重，就提到建议单里去sdlkfj2

sunshine_1003

学习领会/。。

119139107

BUG是要提的  好好跟开发人员沟通吧  这是我们必须做的事情