测试中常见问题分析及对策

我们一般把发现的错误bug(我们也称为缺陷defect)按严重性分为4类：
死机(系统崩溃或挂起)
致命(使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的)
严重(系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果，如：显示不正确但输出正确)
一般(界面拼写错误或用户使用不方便)。

我们也把发现的错误按优先级分为三种：高、中、低：一般是越影响用户接受或使用该产品的错误优先级越高。
但下面，将不对所有的问题进行列举和分析，而只是列出一些显而易见的、容易被项目组忽略的错误，这些错误可能是容易修改的、或是容易避免的，但是对于测试组或用户来说可能却是非常头痛和不方便的。

形象类问题：---不专业、用户不信任

　　1、不符合用户操作习惯。如，快捷键定义不科学、不实用(键位分布不合理、按键太多，甚至没有快捷键)。

　　2、不够专业，缺乏基本知识，而又没有高手检查。

　　3、界面中英文混杂，经常弹出莫名其妙的信息，而且还拼错单词

　　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、更多地从用户使用的角度考虑设计、编码与测试