第五章unix系统的详细的命令.ppt

第五章 系统测试 主要内容：系统测试至少占据了制作过程的一半工作量，是成功地开发信息系统的重要保证之一。本章将对系统测试的方法和技术做一系统地介绍。 5.1 系统测试概述 测试的错误定义： “测试是证明程序中不存在错误的过程”、 “程序测试的目的是要证明程序正确地执行了预期的功能”、 “程序测试的过程是使人们确信程序可完成预期要完成的工作过程”。 测试的定义：为了发现错误而执行程序的过程。 成功的测试：查出新错误的测试是成功的测试。 失败的测试：没有发现错误的测试则是失败的测试。 5.1.1 测试的基本方法 黑盒测试（Black_Box testing） 把程序看成是一个黑盒，完全不考虑程序内部结构和内部特性而进行的测试 白盒测试（White_Box testing） 允许人们检查程序的内部结构，是测试者从检查程序的逻辑着手，得出测试数据，进行测试的过程 5.1.2 测试的基本原则 1、确定预期输出（或结果）是测试数据准备必须的一部分 2、程序员应避免测试自己的程序 3、程序设计机构不应测试自己的程序 4、彻底检查每个测试结果 5、对非法的和非预期的输入情况，也要像对合法的、预期的输入一样，编写测试数据 6、检查程序是否做了要做的事仅是成功的一半，另一半是看程序是否做了不要它做的事 7、一定不要扔掉测试数据 8、在进行测试设计时不要设想程序中不会查出错误 5.1.3 测试的基本手段 人工测试 程序审查会 人工运行 计算机测试 测试所要遵循的步骤： 1、设计测试数据 2、进行模块测试 3、进行高级测试 测试模型： 5.2 人工测试 5.2.1 程序审查会 程序审查会（Code Inspections）是让小组成员阅读程序代码而进行的一系列步骤和查找错误的办法。 组成：（四人组成） 调解人1人：（质量检查工程师） 能力强的程序员担任，他不是被检查程序的作者，无需熟悉该程序的细节。 负责为审查会分发材料，安排并主持会议，记录所有已查出的错误，并保证这些错误随之得以改正。 程序员1人： 是被审查程序的作者， 系统分析或设计人员 负责对程序的结果进行评审， 测试专家。 负责对整个测试过程和结果进行评审。 程序审查会的工作过程是： 会前准备： 调解人在会议开发之前（前几天），把这个程序清单和设计规范分发给小组的其他成员 会议任务： 1、请程序员逐个语句地讲述程序的逻辑结构。大家提出问题加以追究，以断定错误是否存在。 2、根据常见程序错误检验单分析程序。 会期： 90分钟至120分钟之间 注意的问题： 程序员： 错误： 程序员把审查会看成是对他的人格的攻击，采取自卫态度，那么审查过程就没有什么效果。 正确： 抱着虚心的态度参加会议，用正确的和建设性的眼光看待审查处理， 审查会的目的： 发现程序中的错误，从而改进他的工作质量。 审查会的结果应该只限于与会者知道。如果部门或组织的经理使用了审查会的结果，那么这种审查过程马上就会失去意义。 检验单包含的经常出现的软件错误： 数据引用错误 数据说明错误 计算错误 比较错误 控制流程错误 接口错误 输入/输出错误 其它检查 …… 5.2.2 人工运行 人工运行 要求与会者当“计算机”。 被指定为测试员的人要携带一组写在纸上的测试数据来参加会议，这些测试数据都是这个程序或模块的输入情况及期望的输出中的典型代表。 会议期间，要人动脑筋运行每一个测试数据。沿着程序逻辑把这些测试数据走一遍，在纸上或黑板上监视追踪程序的状态。 组成：（3至5人） 一人起类似于程序审查会中调解人的作用； 一人当秘书，他负责记录发现的错误； 一人进行测试，称他为测试员。 其他人为： 一个具有丰富实践经验的程序员、一个程序语言专家、一个新程序员（以便提供新鲜的无偏见的意见）、最终将维护这个程序的人、从事别的项目的人或者是程序小组中的另外一个程序员。 会前准备： 提前几天提供资料以便仔细研究程序 会议内容： 与会者当“计算机” ，运行每一个测试数据。沿着程序逻辑把这些测试数据走一遍，并监视追踪程序的状态。 会期： 持续1至2小时而不间断的会议 注意的问题： 与会者态度极其重要 与会者应该评论程序而不是评论程序员。 不能把错误看作由于程序员的弱点所造成，而应该把它看成由于程序开发的困难而固有的。 对错误要追根到底 5.2.3 静态检验 静态检查 可看作一个人参加的程序审查会，或一个人参加的人工运行。 一个人读程序，依照查错表来检查程序或用测试数据把程序“走”一遍。 5.3 测试数据的设计 5.3.1 逻辑覆盖测试（白盒测试方法） 例： 两个判定（菱形部分）和四个条件（A1、B=0、A=2、X1） 5.3 测试数据的设计 5.3.1 逻辑覆盖测