软件测试的基础理论.ppt

软件测试基础理论 1 软件缺陷含义2 软件缺陷的案例3 软件缺陷的定义4 软件缺陷的种类5 软件缺陷的级别判定6 软件缺陷的原因7 软件缺陷的组成8 软件测试的分类9 软件测试流程10 软件测试模型11 单元测试的时间如何把握 软件的质量就是软件的生命 为了保证软件的质量 人们在长期的开发过程中积累了许多经验并形成了许多行之有效的方法 但是借助这些方法 我们只能尽量减少软件中的错误和不足 却不能完全避免所有的错误 如果把所开发出来的软件看作一个企业生产的产品 那么软件测试就相当于该企业的质量检测部分 简单地说 我们在编写完一段代码之后 检查其是否如我们所预期的那样运行 这个活动就可以看作是一种软件测试工作 新的测试理论 测试方法 测试技术手段在不断涌出 软件测试机构和组织也在迅速产生和发展 由此软件测试技术职业也同步完善和健全起来 1 软件测试的含义 人们常常不把软件当回事 没有真正意识到它已经深入渗透到我们的日常生活中 软件在电子信息领域里无处不在 现在有许多人如果一天不上网查看电子邮件 简直就没法过下去 我们已经离不开24小时包裹投递服务 长途电话服务和最先进的医疗服务了 然而软件是由人编写开发的 是一种逻辑思维的产品 尽管现在软件开发者采取了一系列有效措施 不断地提高软件开发质量 但仍然无法完全避免软件 产品 会存在各种各样的缺陷 2 软件缺陷案例 下面以实例来说明 1 迪斯尼的狮子王游戏软件缺陷 1994年秋天 迪斯尼公司发布了第一个面向儿童的多媒体光盘游戏 狮子王动画故事书 TheLionKingAnimatedStorybook 尽管已经有许多其他公司在儿童游戏市场上运作多年 但是这次是迪斯尼公司首次进军这个市场 所以进行了大量促销宣传 结果 销售额非常可观 该游戏成为孩子们那年节假日的 必买游戏 然而后来却飞来横祸 12月26日 圣诞节的后一天 迪斯尼公司的客户支持电话开始响个不停 很快 电话支持技术员们就淹没在来自于愤怒的家长并伴随着玩不成游戏的孩子们哭叫的电话之中 报纸和电视新闻进行了大量的报道 后来证实 迪斯尼公司未能对市面上投入使用的许多不同类型的PC机型进行广泛的测试 软件在极少数系统中工作正常 例如在迪斯尼程序员用来开发游戏的系统中 但在大多数公众使用的系统中却不能运行 2 爱国者导弹防御系统缺陷爱国者导弹防御系统是里根总统提出的战略防御计划 即星球大战计划 的缩略版本 它首次应用在海湾战争中对抗伊拉克飞毛腿导弹的防御战中 尽管对系统赞誉的报道不绝于耳 但是它确实在对抗几枚导弹中失利 包括一次在沙特阿拉伯的多哈击毙了28名美国士兵 分析发现症结在于一个软件缺陷 系统时钟的一个很小的计时错误积累起来到14小时后 跟踪系统不再准确 在多哈的这次袭击中 系统已经运行了100多个小时 3 千年虫问题20世纪70年代早期的某个时间 某位程序员正在为本公司设计开发工资系统 他使用的计算机存储空间很小 迫使他尽量节省每一个字节 他将自己的程序压缩得比其他任何人都紧凑 使用的其中一个方法是把4位数年份 例如1973年 缩减为2位数 73 因为工资系统相当信赖于日期的处理 所以需要节省大量的存储空间 他简单的认为只有在到达2000年 那时他的程序开始计算00或01这样的年份时问题才会产生 虽然他知道会出这样的问题 但是他认定在25年之内程序肯定会升级或替换 而且眼前的任务比现在计划遥不可及的未来更加重要 然而这一天毕竟到来了 1995年他的程序仍然在使用 而他退休了 谁也不会想到如何深入到程序中检查2000年兼容问题 更不用说去修改了 估计全球各地更换或升级类似的前者程序以解决潜在的2000问题的费用已经达数千亿美元 3 软件缺陷的定义从上述的案例中可以看到软件发生错误时将造成灾难性危害或对用户产生各种影响 软件缺陷 bug 即计算机系统或者程序中存在的任何一种破坏正常运行能力的问题 错误 或者隐藏的功能缺陷 瑕疵 缺陷会导致软件产品在某种程度上不能满足用户的需要 对于软件缺陷的准确定义 通常有以下5条描述 1 软件未实现产品说明书要求的功能 2 软件出现了产品说明书指明不会出现的错误 3 软件超出实现了产品说明书提到的功能 4 软件实现了产品说明书虽未明确指出但应该实现的目标 5 软件难以理解 不易使用 运行缓慢或者终端用户认为不好 4 软件缺陷的种类软件缺陷表现的形式有多种 不仅仅体现在功能的失效方面 还体现在其他方面 软件缺陷的主要类型有 功能 特性没有实现或部分实现 设计不合理 存在缺陷 实际结果和预期结果不一致 运行出错 包括运行中断 系统崩溃 界面混乱 数据结果不正确 精度不够 用户不能接受的其他问题 如存取时间过长 界面不美观 5 软件缺陷的级别 1 软件缺陷的级别作为软件测试员 可能所发现的大多数问题不是那么明显 严重 而是难以觉察的简单而细微的错误 有些是真正的错误 也有些不是 一般来说 问题越严重的 其优先级越高 越要得到及时的纠正 软件公司对缺陷严重性级别的定义不尽相同 但一般可以概括为4种级别 致命的 致命的错误 造成系统或应用程序崩溃 死机 系统悬挂 或造成数据丢失 主要功能完全丧失等 严重的 严重错误 指功能或特性没有实现 主要功能部分丧失 次要功能完全丧失 或致命的错误声明 对用户的操作有很大影响普通的 不太严重的错误 这样的软件缺陷虽然不影响系统的基本使用 但没有很好地实现功能 没有达到预期效果 如次要功能丧失 提示信息不太准确 或用户界面差 操作时间长等 轻微的 一些小问题 对功能几乎没有影响 产品及属性仍可使用 如有个别错别字 文字排列不整齐等 除了这4种之外 有时需要 建议 级别来处理测试人员所提出的建议或质疑 如建议程序做适当的修改 来改善程序运行状态 或对设计不合理 不明白的地方提出质疑 6 软件缺陷的原因软件缺陷的产生 首先是不可避免的 其次我们可以从软件本身 团队工作和技术问题等多个方面分析 比较容易确定造成软件缺陷的原因 归纳如下 技术问题算法错误 语法错误 计算和精度问题 系统结构不合理 造成系统性能问题 接口参数不匹配出现问题 7 软件缺陷的组成我们知道软件缺陷是由很多原因造成的 如果把它们按需求分析结果 规格说明书 系统设计结果 编程的代码等归类起来 比较后发现 结果规格说明书是软件缺陷出现最多的地方 见图1 1 图1 1软件缺陷构成示意图 8 软件测试的分类从不同的角度 可以把软件测试技术分成不同种类 1 从是否需要执行被测软件的角度分类从是否需要执行被测软件的角度 可分为静态测试 StaticTesting 和动态测试 DynamicTesting 顾名思义 静态测试就是通过对被测程序的静态审查 发现代码中潜在的错误 它一般用人工方式脱机完成 故亦称人工测试或代码评审 CodeReview 也可借助于静态分析器在机器上以自动方式进行检查 但不要求程序本身在机器上运行 按照评审的不同组织形式 代码评审又可分为代码会审 走查以及办公桌检查 同行评分4种 对某个具体的程序 通常只使用一种评审方式 动态测试的对象必须是能够由计算机真正运行的被测试的程序 它分为黑盒测试和白盒测试 也是我们下面将要介绍的内容 2 从软件测试用例设计方法的角度分类从软件测试用例设计方法的角度 可分为黑盒测试 Black BoxTesting 和白盒测试 White BoxTesting 黑盒测试是一种从用户观点出发的测试 又称为功能测试 数据驱动测试和基于规格说明的测试 若测试用例的设计是基于产品的功能 目的是检查程序各个功能是否实现 并检查其中的功能错误 则这种测试方法称为黑盒 白盒测试基于产品的内部结构来进行测试 检查内部操作是否按规定执行 软件各个部分功能是否得到充分利用 白盒测试又称为结构测试 逻辑驱动测试或基于程序的测试 即根据被测程序的内部结构设计测试用例 测试者需事先了解被测试程序的结构 3 从软件测试的策略和过程的角度分类 按照软件测试的策略和过程分类 软件测试可分为单元测试 UnitTesting 集成测试 IntegrationTesting 确认测试 ValidationTesting 系统测试 SystemTesting 和验收测试 VerificationTesting 单元测试是针对每个单元的测试 是软件测试的最小单位 它确保每个模块能正常工作 单元测试多数使用白盒测试 用以发现内部错误 集成测试是对已测试过的模块进行组装 进行集成测试的目的主要在于检验与软件设计相关的程序结构问题 集成测试一般通过黑盒测试方法来完成 确认测试是检验所开发的软件能否满足所有功能和性能需求的最后手段 通常采用黑盒测试方法 系统测试的主要任务是检测被测软件与系统的其他部分的协调性 验收测试是软件产品质量的最后一关 这一环节 测试主要从用户的角度着手 其参与者主要是用户和少量的程序开发人员 9 软件测试流程 10 软件测试过程模型 瀑布模型V模型W模型H模型 瀑布测试模型 瀑布模型特点 线性化模型各阶段划分明确基于文档的驱动严格的阶段评审 V模型 V模型是最具有代表意义的测试模型 V模型是软件开发瀑布模型的变种 它反映了测试活动与分析和设计的关系 从左到右 描述了基本的开发过程和测试行为 非常明确地标明了测试过程中存在的不同级别 并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 箭头代表了时间方向 左边下降的是开发过程各阶段 与此相对应的是右边上升的部分 即各测试过程的各个阶段 V模型存在一定的局限性 它仅仅把测试过程作为在需求分析 概要设计 详细设计及编码之后的一个阶段 容易使人理解为测试是软件开发的最后的一个阶段 主要是针对程序进行测试寻找错误 而需求分析阶段的隐藏的问题一直到后期的验收测试才被发现 在V模型中增加软件各开发阶段应同步进行的测试 被演化为一种W模型 开发是 V 测试也是与此相重叠的 V W模型体现了 尽早地和不断地进行软件测试 的原则 W模型 相比于V模型 W模型更科学 W模型可以说是前者自然而然的发展 它强调 测试伴随着整个软件开发周期 而且测试的对象不仅仅是程序 需求 功能和设计同样要测试 测试与开发是同步进行的 从而有利于尽早地发现问题 以需求为例 需求分析一完成 我们就可以对需求进行测试 而不是等到最后才进行针对需求的验收测试 测试不仅仅是评定软件的质量 测试还可以尽可能早地找出缺陷所在 从而帮助改进项目内部的质量 H模型 单元测试的时间如何把握 如果按照项目时间这样划分 1 3计划和设计 1 6实现 1 4组件测试 1 4系统测试 则在 代码实现 中 不仅要包含Coding的时间 而且要包含单元测试的时间 他们的比例大概是1 3的时间做东西 2 3的时间做检查 这样才能保证 零件质量 单元测试不是为了增大自己的工作量 而是减少你未来的工作量 否则 从工程学上来说 或者有过真正工程经验的人 都知道其质量保证是掩耳盗铃 最终将自食其果 哪些函数无需做单元测试 这个函数是不是简单到一眼就能检查出输出和起征点的错误 如果的确是 那么这个函数不用做单元测试 有些公司和员工为了敷衍了是做一些 伪单元测试 有点形而上学 根本不是高效的单元测试 哪些函数需要做单元测试 1 逻辑或算法复杂 函数内部逻辑或算法很复杂 判断条件 循环 停顿跳转很多 一眼看不出输入什么结果 那么需要做单元测试来验证期望的输出 2 涉及很多对象 单元测试一定要做 因为能够有效的发现和隔离依赖项 有助于更好的解耦 一个紧耦合的系统的确很难做单元测试 需重构 3 抛出异常或捕捉异常 任何函数如果存在内部断点或跳出点 一定要做单元测试模拟程序内部跳转和停止的情况 4 越底层函数越需要单元测试 指的是系统越底层的函数 越核心的函数 越需要单元测试 反之 越高层的 比如UI层 越不要单元测试 记住 不要去测试类中的每个方法 挑选以上几种函数进行测试 而且要根据需求来测试这个类对外所能提供的功能 这些功能可能是其中的几个重要方法 可能需要类中的几个方法协作 可以对这几个方法进行测