1.        表达不清或过于模糊的信息提示，不该有的罗嗦提示；
2.        界面中的信息不能及时更新，退出后重新进入才刷新；
3.        允许用户输入错误的数据类型，更甚至能保存；
4.        经常弹出莫名其妙中英文混杂的信息，而且还拼错单词、别字；
5.        界面元素参差不齐，文字不能完全显示，TAB时鼠标乱走；
6.        不能记忆用户的设置或操作习惯，用户每次进入都需要重新操作一次初始环境；
7.        不可重现的死机，或不完全释放内存资源，系统性能越来越低；
8.        修改后的bug会再次出现，修改得不彻底；
9.        把用户想象得很完美，过多地从用户角度去设计、测试；
10.        不符合用户操作习惯。如快捷键定义不科学、不实用，甚至没有快捷键；
11.        将简单功能复杂化，设计上一个较常见的问题；
12.        没有对输入输出做出响应，如果没有，保管80％以上的用户会对软件产生怀疑：怎么没有响应？还要等多久？
13.        删除某些重要数据时，要有必要的提示信息；
14.        没有对已经打开的文件进行检查，程序不能保证会对同一个文件在某个时刻做出不同修改所带来的后果。所以，决不允许同一文件同时被打开两次甚至更多，在导入数据时常出现此问题；
15.        不一致的操作规则（如保存规则），不一致的名词信息；
16.        主次窗口经常发生倒置；
17.        输入错误的数据后，系统不能自动更正错误的数据；
18.        性能不容乐观，每步操作程序响应时间一般不应超过3秒，查询不超过5秒（确实海量数据，要有等待进度提示）；
19.        发生未预料到的错误，程序可能与错误数据一起工作并最终产生的错误结果；
20.        没对各种数据限制其上下限，致使操作中出现不必要的错误；
21.        由于使用了舍入的计算方法，很可能因为计算方法不同产生错误数据；
22.        不准确的简化特征描述，而忽略了重要条件，以致于引发歧义，因此应注意每一个微不足道的细节；
23.        与其它软件的兼容性，如杀毒软件、输入法、office等；
24.        对各种空数据的业务记录，对以后的操作造成巨大威胁；
25.        反复操作同一按钮或功能，会出现意想不到的结果；
26.        不能查询到上次或刚刚完成的数据；
27.        荒谬的精度输出级别，要是说2.6加上5.3等于7.9000000或者说1.201+4.01等于5.21100022都是很愚蠢的；在最终输出的结果中，程序应该按照规定的格式和精度输出最后的数据；
28.        没对变量做好初始化工作，乐观的认为初始为零或空，导致操作时报初始化失败；
29.        各种按钮或提示信息，由于窗口还原只显示一部分，甚至用户根本找不到；
30.        显示列表信息没按用户习惯进行排序；

[ Last edited by clement on 2005-7-15 at 09:35 ]

不错，顶一下

不错，顶一下

强烈支持！

就测试而言，细节是一个可以衡量你跟别人做的不一样的东西。
另外说句题外话，楼主贴的图片非常有意义，有个小小的建议：就是把图片大小改小一点或者尽量不要贴这么大的图片，这样大家看到帖子的速度会提高很多～

拜托  ,你写东西的时候能不能先自己整理一下 啊, 你知道这样 让人看了很摸不着头脑.而且看的人也迷迷糊糊的.你写的第一点 "表达不清或过于模糊的信息提示，不该有的罗嗦提示." 是从正面讲的．可是第三点　＂  允许用户输入错误的数据类型，更甚至能保存＂　　你说的是应该这样做呢　　还是不应该这样处理的呢　？　　你要说清楚嘛　　！！你至少该这样讲：  允许用户输入错误的数据类型，但是保存时回提示错误信息，并刷新成原来默认的样子．

谢谢楼主，收藏先！

不错不错，：），比较全哦，：）。看很多可以归结为易用性问题吧？呵呵，现在易用性测试越来越重视了，不过可惜很多开发人员却往往认为这些是可有可无的小问题，没什么价值，气愤啊

写得不错啊！

个人意见，虽然有的地方表达的不是很清晰，但还是有参考价值的！
楼主辛苦了！谢谢！嘿嘿！

通常开放人员对于这类的问题都是拒绝修改的，他们主要侧重于对功能需求bug的修改，关于类似易用性的问题，他们虽然在沟通的时候承认很重要，但是在修改的时候却依然不肯改，（我们项目经理也是开发人员之一）请问楼主怎么看这个问题？

非常好，顶！！！

不错
不错
不错
辛苦了

这些易用性的问题的确是个头疼的问题，一般没有上级的指导程序员是不会改的，我认为这要看上级主管的关注程度，有的主管一点都不关注，认为这样不会给程序造成什么错误，就没有必要修改。

真拿这个没有办法。这个也是经常出现的问题，不知道大家谁有更好的解决方法，提供一下下。

我们公司也是的，因为没有硬性的要求。对于这些小细节，改与不改，都要看这个开发人员的合作程度了。所以很郁闷阿。。。

真的不错，让我也学到了不少知识。谢谢！！！！！！！！！！！！1

不断的找研发人员,直到他怕你为止.我就这样做,后来还是他们投降了,不过感觉很累,有时吃力不讨好.

谢谢！！

有些时候，比如加点什么能够让用户使用更为方便，俺提了，也说了，可是程序员认为那个不是错误，就不搭理俺啊。测试也不是那么容易，你找出来了，客客气气地说了，没人里你啊。