测试入门.pptVIP

软件测试目的 测试是一个为了寻找错误而运行程序的过程 一个好的测试用例是只可能找到迄今为止尚未发现错误的用例 一个成功的测试是揭示了迄今为止尚未发现的错误的测试 软件测试方法分类 错误分级－严重性 错误分级－优先级 我们也把发现的错误按优先级分为三种： 1.高：立即修改； 2.中：必须修改，但不一定马上修改； 3.低：允许不修改； 一般来说是越影响用户接受或使用该产品的错误优先级越高。 常见问题 下面将列出一些问题，他们具有一些特征： 显而易见的 开发时容易被忽略 容易避免 容易修改 但是对于测试人员或用户来说可能却是非常头痛和不方便的 形象类问题 形象类问题（续） 可用性问题 可用性问题（续） 稳定性问题 其他问题 1.文档匮乏：文档不标准；无新功能使用方法；无版本改动说明。我们不仅要认为没有说明文档的产品不是是一个完整的产品，也要认为没有说明或没有正确说明的功能是一个没有完全实现的功能，因为用户无法用得起来。 2.运行时不检查内存、数据库或硬盘空间等； 3.假设用户环境（硬件/网络环境、软件环境等、配置等）； 4.安装困难，或根本无法安装等； 5.提供的应用程序带有病毒； 6.程序不经调试，或提供Debug版本给测试组或测试用户； 7.用户现场开发和修改，没有修改记录和保存版本； 其他问题（续） 8.错误反复出现，改动得不彻底、或版本管理出现混乱； 9.改动时不小心，导致错误越改越多； 10.版本中部分内容和接口倒退； 11.状态没有正确变更（有些选项永远是灰的，有些选项、菜单项在该灰时还不灰）； 12.资源没有和代码分离，不同语言版本间不能平滑转换； 13.模块（子系统）间接口不一致； ………… 期望项目组关注的一些问题 1.修改Bug 时考虑得不够； 2.将问题留给测试人员去发现的心态（不仔细测试、不小心修改、修改不彻底）； 3.更多地从用户使用的角度考虑设计、编码与测试； 4.程序可重用性问题（很多不同的功能写在一个应用程序内）； 5.开发过程中人员变动； 6.项目负责人对于BUG 的跟踪； 这类问题一般是表面上的，技术含量不高，但是给予用户的感觉往往是软件不够专业…… 1.不符合用户操作习惯。如，快捷键定义不科学（不易理解、与系统快捷键冲突等）、不实用(键位分布不合理、按键太多，甚至没有快捷键等)； 2.风格的统一性；对于同一个系统，同一系统环境下的应用程序出现不同的界面风格和操作风格，对用户来说是一大考验，对开发者来说是专业性和正规性的表现。 3.界面中英文混杂，经常弹出莫名其妙的信息，甚至还拼错单词； 4.提示、标题等不够专业，或各处描述不一致； 5.界面元素的位置：缺省认为用户使用某种分辨率，导致在其他分辨率下显示不正常； 6.说明书或帮助的排版格式不专业：中英文搭配不对、标点符号全角半角部分、没有排版禁则… 7.程序名/路径名不规则（比如为程序员的名字等）； 8.没有安装程序、或安装程序不完善(丢掉一些必要的模块或文件)； 9.界面元素参差不齐，文字不能完全显示，TAB键顺序与使用顺序不一致等； ………… 用户比开发或测试人员在接触界面上要花费更多时间。错误和低效的用户界面的影响会变得越来越大，最终甚至会掩盖了产品有用的方面。 下面是一些用户界面错误的例子： 1.输入无合法性检查和值域检查，允许用户输入错误的数据类型（有时只需要选择合适的输入控件即可，比如日期用专门的日期输入控件），并导致不可逆料的后果； 2.界面中的信息不能及时更新，不能正确反映数据状态，甚至对用户产生错误的误导（如：记录个数、参数设置对话框中的缺省值等）； 下面是一些低效的用户界面的例子： 1.表达不清或过于模糊的信息提示； 2.要求用户输入多余的、本来系统可以自己得到的数据（如：安装后用户要手动修改某些配置文件）； 3.为了达到某个设置或对话框，用户必须做许多冗余操作（如对话框嵌套层次太多）； 4.不能记忆用户的设置或操作习惯（如用户每次进入都需要重新操作一次初始环境）； 5.使用不完善的功能且不给用户以恰当的提示； 6.不经用户确认就对系统或数据进行重大修改； 往往是在设计时考虑不周而造成的一些问题。 1.不可重现的死机，或不断申请但不完全释放资源，系统性能越来越低； 2.主系统和子系统使用同样的临界资源而互相不知道（如：使用同样的类名或临时文件名、使用同样的数据库