51Testing软件测试论坛

标题: 测试注意细节 [打印本页]

作者: clement 时间: 2005-7-15 09:28
标题: 测试注意细节
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 ]

作者: xiaoxue1027 时间: 2005-7-15 09:33
不错，顶一下

作者: clement 时间: 2005-7-15 09:37
标题: 不错，顶一下
不错，顶一下

作者: crilrose 时间: 2005-7-15 09:43
强烈支持！

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

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

作者: flytigerboy 时间: 2005-8-17 09:12
谢谢楼主，收藏先！

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

作者: hxe324 时间: 2005-8-17 21:01
写得不错啊！

作者: dongxiaoxiao 时间: 2005-8-18 10:32
个人意见，虽然有的地方表达的不是很清晰，但还是有参考价值的！
楼主辛苦了！谢谢！嘿嘿！

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

作者: 自得其乐 时间: 2005-9-2 13:40
非常好，顶！！！

作者: zhengyh1980 时间: 2005-9-4 10:57
不错
不错
不错
辛苦了

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

作者: snail2011 时间: 2005-9-6 14:18
真拿这个没有办法。这个也是经常出现的问题，不知道大家谁有更好的解决方法，提供一下下。

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

作者: 雪儿185 时间: 2005-10-13 17:30
真的不错，让我也学到了不少知识。谢谢！！！！！！！！！！！！1

作者: tiansm 时间: 2005-10-30 08:39
标题: 不断的找研发人员,直到他怕你为止
不断的找研发人员,直到他怕你为止.我就这样做,后来还是他们投降了,不过感觉很累,有时吃力不讨好.

作者: 983221wy 时间: 2005-11-21 09:38
谢谢！！

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

作者: 天上一颗星 时间: 2006-1-13 09:35
楼主总结的不错，受益匪浅啊！
在我们这里，如果时间允许的话，对于这些细节开发人员都会认真地去改。
可是到最后项目不能按时完成，而且大家改bug改的很烦的时候，就不会再去理它了。
如果不是特别严重的错误（这个程度当然得看项目领导的理解），有时候选择不改未必也不是一件好事。因为修改一个bug可能会引起很多其他未知的问题出现呢

[ 本帖最后由天上一颗星于 2006-1-13 09:36 编辑 ]

作者: DaisyJ 时间: 2006-1-18 15:55
有同感，开发人员对于易用性的问题通常并不真正地重视，提的时候他们也听，可是能看出来实际上是不当一回事的。但在用户那里，用起来别扭的软件肯定不是好软件

作者: amanda1981 时间: 2006-2-5 17:11
8错

作者: fengk0918 时间: 2006-2-6 17:00
确实经常会遇到这样的情况啊~~~！呵呵~~~！谢谢啦~~~！

作者: fazi1223 时间: 2006-2-7 14:17
非常不错，楼主是个资深测试员吧，总结的很全面，谢谢啦。

作者: qqzxiaoyan 时间: 2006-2-7 17:09
不错不错

作者: peterbobo 时间: 2008-12-16 08:49
不错，顶一下

作者: sunjr 时间: 2009-3-14 22:12
楼主辛苦了！谢谢！嘿嘿！

作者: 6739 时间: 2009-3-17 10:50
楼主辛苦了！谢谢！

作者: glacier678 时间: 2009-3-31 17:02

相当的好呀

作者: hdtest001 时间: 2009-4-15 10:44
工作上这些问题大多数都不被开发接受因为有些系统要求还不是那么高用的人也不多要是大型的项目就要严谨了小的一般能过得去就差不多了
谢谢楼主的分享！

作者: moujingjing 时间: 2009-4-17 16:03
标题: 不错不错
楼主写的很多都是我们实在工作中存在的问题，辛苦了。

作者: x1j2l3 时间: 2009-4-17 17:35
很牛啊居然是几年前的帖子

作者: jessies 时间: 2009-5-5 15:56
部分值得参考，但是有些表达显得过于模糊
对于上面说的有些页面的小问题，开发会拒绝修改，我也遇到过，但是可能公司氛围的差异，我仅仅说说一下我们的处理方式。
一般易用性的问题，我觉得绝对影响用户体验和感受的，会和交互设计工程师沟通，必须需要修改的，我们会登记bug，然后存在打开bug的情况项目不允许发布的。
如果不存在交互工程师，并且沟通了，项目经理也觉得需要修改，一般来说这些问题修改起来也不是很麻烦，你多和开发沟通，bug一直打开，并且坚持自己的观点，那么最后一般能够解决的
项目时间很紧张，并且问题不是很严重，那么考虑发布时间，有些问题留待下次修复、
....很多问题都需要按照场景进行处理，但是我坚持一个观点，就是不管是易用性还是其他方便的，只要PM认可了这是bug，那么我一定会坚持到底。

作者: 丫崽儿 时间: 2009-6-12 11:41
同意20# 这上面好多问题开发都不管.....看见我都怕

作者: 丫崽儿 时间: 2009-6-18 14:49
赞1
！！

作者: sunny1979 时间: 2010-3-4 11:31
支持,谢谢

作者: 蓝色迷走 时间: 2010-3-7 01:44
细节决定成败

作者: maclehappy13 时间: 2010-3-7 20:06
写的不错，LZ的辛苦值得肯定

作者: kielyn778885 时间: 2010-3-10 14:22
不错不错！顶！

作者: 123我 时间: 2010-5-10 17:38
标题: 3q
3q

作者: tmg 时间: 2011-3-9 16:37
谢谢

作者: ruirui。 时间: 2011-4-8 09:26
学习了

作者: ruirui。 时间: 2011-4-8 09:27
多谢LZ分享

作者: ruirui。 时间: 2011-4-8 09:28
回复 20# whoisangle
你要有足够说服程序员的理由 ~~

作者: longxiyang 时间: 2011-5-10 16:27
感觉还不错，支持一下

作者: trmery 时间: 2011-6-7 14:26
收藏着学习下

作者: 我的兔宝宝 时间: 2011-6-8 11:09
找领导。

作者: swl0376 时间: 2012-9-9 15:16
回复 1# clement

楼主写的很多都是我们实在工作中存在的问题，辛苦了。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)