测试中的一些常见问题的分析

形象类问题：---不专业、用户不信任
　　1、不符合用户操作习惯。如，快捷键定义不科学、不实用(键位分布不合理、按键太多，甚至没有快捷键)。
　　2、不够专业，缺乏基本知识，而又没有高手检查。
　　3、界面中英文混杂，经常弹出莫名其妙的信息，而且还拼错单词
　　4、SETUP界面：CopyRight 1994-1996（？这里没有看懂，难道是应该是CopyRight ©1994-1996？）；缺省认为用户使用某种分辨率；
　　5、说明书或帮助的排版格式不专业：中英文搭配不对、标点符号全角半角部分、没有排版准则…
　　6、程序名/路径名是程序员的名字、或没有安装程序、或安装程序不完善(丢掉一些必要的模块或文件)
　　7、界面元素参差不齐，文字不能完全显示，TAB时鼠标乱走。
可用性问题：---用户无法使用或不方便使用
　　"用户比开发或测试人员在接触界面上要花费更多时间。表面上不重要的方面的影响会变得越来越大，最终甚至会掩盖了产品得有用得方面。"
　　下面是一些用户界面错误的例子：
　　1、输入无合法性检查和值域检查，允许用户输入错误的数据类型，并导致不可逆料的后果
　　2、界面中的信息不能及时更新，不能正确反映数据状态，甚至对用户产生错误的误导。如：数据库中剩余记录个数；参数设置对话框中的预设值
　　下面是一些低效的用户界面的例子：
　　1、表达不清或过于模糊的信息提示
　　2、要求用户输入多余的、本来系统可以自己得到的数据。如：服务是否启动，安装后用户要手动修改某些配置文件。
　　3、为了达到某个设置或对话框，用户必须做许多冗余操作。如，对话框嵌套层次太多。
　　4、不能记忆用户的设置或操作习惯，用户每次进入都需要重新操作一次初始环境。
　　5、使用不完善的功能且不给用户以恰当的提示。
　　6、不经用户确认就对系统或数据进行重大修改
稳定性问题：---影响用户正常工作
　　1、不可重现的死机，或不断申请但不完全释放资源，系统性能越来越低
　　2、主系统和子系统使用同样的临界资源而互相不知道。如：使用同样的类名或临时文件名、使用同样的数据库字段名或登录帐号。
　　3、不能重现的错误，许多与代码中的未初始化变量(在Debug时一般是缺省初始化的)有关，有些与系统不检查异常情况(如内存申请不成功、网络突然中断或长时间没有响应)有关。
其他问题：
　　1、文档匮乏：无标准；无新功能使用方法；无版本改动说明。我们不仅要认为没有说明文档的产品不是是一个完整的产品，也要认为没有说明或没有正确说明的功能是一个没有完全实现的功能，因为用户无法用得起来。
　　2、运行时不检查内存、数据库或硬盘空间等
　　3、无根据地假设用户环境：硬件/网络环境；有些动态库；安装程序换台机器不正确；假设网络随时都是连通的
　　4、提供的版本带病毒，或根本无法安装，或没有加密
　　5、提供Debug版本给测试组或测试用户，或项目组与测试组使用不同版本
　　6、用户现场开发和修改，又没有记录和保留
　　7、错误反复出现，改动得不彻底、或版本管理出现混乱
　　8、错误越改越多，改动得不彻底、或改动得不小心
　　9、版本中部分内容和接口倒退
　　10、有些选项永远是灰的；有些选项、菜单项在该灰时还不灰，并且还能状态显示
　　11、资源没有和代码分离，不同语言版本间不能平滑转换
　　12、缺少第三方产品的评估：广告管理系统2000年问题
　　13、产品配合不利，准备当作一套产品或方案推出，互相之间却各不负责，(没有整个项目负责人，是面向组织的而不是面向产品或方案的)。
产生这些问题的部分可能的原因：
　　1、修改Bug的人考虑得不够周全，也可能是没有能力考虑周全---不懂全部程序
　　2、问题留给测试组去发现的心态----不仔细测试、不小心修改、甚至不全面改(不彻底)
　　3、自己不会用，不了解产品的用法。
　　4、没有从用户使用的角度考虑设计、编码与测试

说明：原文：http://hi.baidu.com/cnstone/blog/item/86a35e82b61093a20df4d25a.html，原文名为《测试中常见问题分析及对策》，但是我觉得好像文中没有说明对策，所以我没有完全转载全部的，而且也改了标题；将“期望项目组关注的一些问题 ”改为“产生这些问题的部分原因”；将“更多地从用户使用的角度考虑设计、编码与测试”改为“没有从用户使用的角度考虑设计、编码与测试 ”。郑重申明：转载和修改该文章仅系个人学习使用。