第1章 软件测试概述

第1章软件测试概述 1 1软件测试的背景1 2软件缺陷1 3软件测试的复杂性与经济性分析1 4软件测试的认识1 5软件测试人员的素质 1 1软件测试的背景 1 1 1软件测试发展历史1 1 2软件测试的现状 1 1软件测试的背景 随着软件产业的日益发展 软件系统的规模和复杂性与日俱增 软件的生产成本和软件中存在的缺陷故障造成的损失也大大增加 甚至会带来灾难性的后果 软件产品不同于其他科技和生产领域 它是人脑的高度智力化的体现 由于这一特殊性 软件与生俱来就有可能存在着缺陷 在开发大型软件系统的漫长过程中 面对纷繁复杂的各种现实情况 人的主观认识和客观现实之间往往存在着差距 开发过程中各类人员之间的交流和配合也往往并不是尽善尽美的 1 1软件测试的背景 如果不能在软件正式投入运行之前发现并纠正这些错误 那么这些错误最终必然会在软件的实际运行过程中暴露出来 到那时 改正这些错误不仅要付出很大的代价 而且往往会造成无法弥补的损失 软件的质量就是软件的生命 为了保证软件的质量 人们在长期的开发过程中积累了许多经验并形成了许多行之有效的方法 但是借助这些方法 我们只能尽量减少软件中的错误和不足 却不能完全避免所有的错误 如何防止和减少这些可能存在的问题呢 答案是进行软件测试 测试是最有效的排除和防止软件缺陷与故障的手段 并由此促进了软件测试理论与技术实践的快速发展 新的测试理论 测试方法 测试技术手段在不断涌出 软件测试机构和组织也在迅速产生和发展 由此软件测试技术职业也同步完善和健全起来 1 1 1软件测试发展历史 软件测试是伴随着软件的产生而产生的 在软件行业发展初期 软件规模较小 复杂程序较低 软件开发的过程比较混乱 相当随意 这一阶段还没有系统意义上的软件测试 更多的是一种类似调试的测试 测试用例的设计和选取也都是根据测试人员的经验随机进行的 大多数测试的目的是为了证明系统可以正常运行 当时对测试的投入较少 测试介入的也较晚 一般是等到代码形成 产品已经基本完成才进行测试 1 1 1软件测试发展历史 直到20世纪50年代后期 随着计算机软件的发展 用于计算机编程的各种高级语言相继诞生 程序的复杂性远远超过了以前 测试的重点也逐步转入到使用高级语言编写的软件系统中来 尽管如此 由于受到硬件的制约 在计算机系统中 软件仍然处于次要位置 软件正确性的把握仍然主要依赖于编程人员的技术水平 测试活动始终落后于开发活动 因此 这一时期软件测试的理论和方法发展比较缓慢 1 1 1软件测试发展历史 到了20世纪70年代以后 计算机处理速度迅猛提高 存储器容量快速增加 软件在整个计算机系统中的地位也越来越重要 随着软件开发技术的成熟和完善 软件的规模也越来越大 复杂度也大大增加 因此 软件的可靠性面临着前所未有的危机 给软件测试工作带来了巨大的挑战 很多测试理论和测试方法应运而生 逐渐形成了一套完整的体系 也涌现了一批出色的软件测试宗师 1 1 1软件测试发展历史 1972年 软件测试的先驱者BillHetzel博士在NorthCarllina大学举行了第一次以软件测试为主题的正式会议 此后软件测试的会议就如雨后春笋般出现 1981年 BillHetzel博士开设了一门公共课 结构化软件测试 StructuredSoftwareTesting 1983年 他将软件测试定义为 评价一个程序和系统的特性或能力 并判断它是否达到预期的结果 软件测试就是以此为目的的任何行为 他的思想的核心观点是 测试方法是试图验证软件是 工作的 所谓 工作的 就是指软件的功能是按照预先的设计执行的 以正向思维 针对软件系统的所有功能点 逐个验证其正确性 软件测试业界把这种方法看作是的软件测试的第一类方法 1 1 1软件测试发展历史 软件测试的第二类方法代表人物是GlenfordJ Myers 他认为测试不应该着眼于验证软件是工作的 相反应该首先认定软件是有错误的 然后用逆向思维去发现尽可能多的错误 他还从人的心理学的角度论证 如果将 验证软件是工作的 作为测试的目的 非常不利于测试人员发现软件的错误 1979年 他提出了对软件测试的定义 测试是为发现错误而执行的一个程序或者系统的过程 这个定义 也被业界所认可 经常被引用 1 1 1软件测试发展历史 在产业界 从20世纪70年代后期到20世纪80年代中期 很多软件企业成立了QA或者SQA部门 后来QA的职能转变为流程监控 包括监控测试流程 而测试 Testing 则从QA中分离出来成为独立的组织职能 到了20世纪80年代初期 软件和IT行业进入了大发展 软件趋向大型化 高复杂度 软件的质量越来越重要 这时 一些软件测试的基础理论和实用技术开始形成 并且人们开始为软件开发设计了各种流程和管理方法 软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程 以结构化分析与设计 结构化评审 结构化程序设计及结构化测试为特征 1 1 1软件测试发展历史 如今在软件产业化发展的大趋势下 人们对软件质量 成本和进度的要求也越来越高 软件质量的控制已经不仅仅是传统意义上的软件测试 传统软件的测试大多是基于代码运行的 并且常常是软件开发的后期才开始进行 但大量研究表明 设计活动引入的错误占软件开发过程中出现的所有错误数量的50 65 因此 越来越多的声音呼吁 要求有一个规范的软件开发过程 而在整个软件开发过程中 测试已经不再只是基于程序代码进行的活动 而是一个基于整个软件生命周期的质量控制活动 贯穿于软件开发的各个阶段 1 1 2软件测试的现状 在我国 软件测试目前还没有形成一个真正的产业 尚处于起步阶段 根据51testing组织得到的 2009年中国软件测试从业人员调查报告 可以看出 软件测试从业人员所在公司成立的时间在5年以上的比例为58 集中分布在应用软件行业 电信 互联网服务行业 公司多为私营或集体所有制企业 且比例逐年增加 调查显示虽然国内IT软件开发企业对软件测试认识比较淡薄 公司测试人员与开发人员的比例主要分布在1 3 1 4之间 较国外1 1比例相距甚远 但是国内IT企业也逐步开始重视软件测试团队的建设 在IT企业中 一些知名企业已经将软件测试作为企业未来发展的一个板块 参与2009年调查的软件测试从业人员中 73 的人所在公司具有独立的测试部门 专职测试人员也呈逐年上升趋势 1 1 2软件测试的现状 总之 国内软件行业普遍规模偏小 缺乏大型软件产品经验 开发过程不够规范 这决定了国内软件测试行业与一些发达国家相比还存在一定的差距 其实 这与中国整体软件的发展水平是一致的 因为我国整体的软件产业水平和软件发达国家的水平相比有较大的差距 而作为软件产业重要一环的软件测试 必然也存在着不小的差距 但是 我们在软件测试实现方面并不比国外差 国际上优秀的测试工具 我们基本都有 这些工具所体现的思想我们也有深刻的理解 很多大型系统在国内都得到了很好的测试 1 2软件缺陷 1 2 1软件缺陷案例分析1 2 2软件缺陷的定义1 2 3软件缺陷产生的原因1 2 4软件缺陷的修复费用 1 2 1软件缺陷案例分析 软件是由人编写开发的 是一种逻辑思维的产品 尽管现在软件开发者采取了一系列有效措施 不断地提高软件开发质量 但仍然无法完全避免软件 产品 会存在各种各样的缺陷 软件中存在的缺陷有时会造成相当严重的损失和灾难 下面以4个软件缺陷的案例来说明 美迪斯尼公司的狮子王游戏软件bug 美航天局火星登陆探测器缺陷 北京奥运会门票暂停第二阶段的门票销售 诺基亚Series40手机平台存在缺陷 兼容性 衔接性 访问量大 漏洞 1 2 1软件缺陷案例分析 1 2 2软件缺陷的定义 对于软件存在的各种问题在软件工程或软件测试中都可以称为软件缺陷或软件故障 软件缺陷即计算机系统或者程序中存在的任何一种破坏正常运行能力的问题 错误 或者隐藏的功能缺陷 瑕疵 缺陷会导致软件产品在某种程度上不能满足用户的需要 对于软件缺陷的精确定义 通常有以下5条描述 1 2 2软件缺陷的定义 软件未达到产品说明书要求的功能 软件出现了产品说明书指明不会出现的错误 软件功能超出了产品说明书规定的功能 软件未实现产品说明书虽未明确指出但应该实现的目标 软件难以理解 不易使用 运行缓慢或者最终用户认为使用效果不好 1 2 2软件缺陷的定义 为了更好地理解上述5条描述 我们以计算器软件为例进行说明 计算器的产品说明书声明它能够准确无误地进行加 减 乘 除运算 当你拿到计算器后 按下 键 结果什么反应也没有 根据第 条规则 这是一个缺陷 假如得到错误答案 根据第 条规则 这同样是一个缺陷 若产品说明书声明计算器永远不会崩溃 锁死或者停止反应 当你任意敲键盘 计算器停止接受输入 根据第 条规则 这是一个缺陷 1 2 2软件缺陷的定义 若用计算器进行测试 发现除了加 减 乘 除之外它还可以求平方根 说明书中从没提到这一功能 根据第 条规则 这是软件缺陷 软件实现了产品说明书未提到的功能 若在测试计算器时 发现电池没电会导致计算不正确 但产品说明书未指出这个问题 根据第 条规则 这是个缺陷 第 条规则是全面的 如果软件测试员发现某些地方不对劲 无论什么原因 都要认定为缺陷 如 键布置的位置极其不好按 在明亮光下显示屏难以看清 根据第 条规则 这些都是缺陷 1 软件本身文档错误 内容不正确或拼写错误 数据考虑不周全引起强度或负载问题 对边界考虑不够周全 漏掉某几个边界条件造成的错误 对一些实时应用系统 保证精确的时间同步 否则容易引起时间上不协调 不一致性带来的问题 没有考虑系统崩溃后在系统安全性 可靠性的隐患 硬件或系统软件上存在的错误 软件开发标准或过程上的错误 1 2 3软件缺陷产生的原因 1 2 3软件缺陷产生的原因 2 团队工作系统分析时对客户的需求不是十分清楚 或者和用户的沟通存在一些困难 不同阶段的开发人员相互理解不一致 软件设计对需求分析结果的理解偏差 编程人员对系统设计规格说明书中某些内容重视不够 或存在着误解 设计或编程上的一些假定或依赖性 没有得到充分地沟通 1 2 3软件缺陷产生的原因 3 技术问题算法错误 语法错误 计算的精度问题 系统结构不合理 造成系统性能问题 接口参数不匹配 导致模块集成出现问题 1 2 3软件缺陷产生的原因 软件缺陷是由很多原因造成的 将诸多原因如规格说明书 系统设计结果 编程的代码等归类起来比较后发现 规格说明书是软件缺陷出现最多的地方 如下图所示 1 2 3软件缺陷产生的原因 软件产品规格说明书为什么是软件缺陷存在最多的地方 主要原因有以下几种 由于软件产品还没有设计 开发 完全靠想象去描述系统的实现结果 所以有些特性还不够清晰 用户一般是非计算机专业人员 软件开发人员和用户的沟通存在较大困难 对要开发的产品功能理解不一致 需求变化的不一致性 用户的需求总是在不断变化的 这些变化如果没有在产品规格说明书中得到正确的描述 容易引起前后文 上下文的矛盾 对规格说明书不够重视 在规格说明书的设计和写作上投入的人力 时间不足 没有在整个开发队伍中进行充分沟通 有时只有设计师或项目经理得到比较多的信息 1 2 4软件缺陷的修复费用 软件通常要靠有计划 有条理的开发过程来实现 从开始到计划 编程 测试 到公开使用的过程中 都有可能发现软件缺陷 软件缺陷造成的修复费用随着时间的推移呈指数级地增长 当早期编写产品说明书时发现并修复缺陷 费用可能只要10美元甚至更少 同样的缺陷如果直到软件编写完成开始测试时才发现 费用可能要100 1000美元 如果是客户发现的 费用可能达到数千甚至数百万美元 下图所示为软件缺陷在不同阶段发现时错误修正后的费用情况 1 2 4软件缺陷的修复费用 1 3软件测试的复杂性与经济性分析 1 3 1软件测试的复杂性1 3 2软件测试的经济性1 3 3软件测试的充分性准则 1 3软件测试的复杂性与经济性分析 人们通常认为软件工程中程序的开发是一个复杂而困难的过程 需要投入大量的人力 物力和时间 而测试程序则比较容易 不需要花费太多的精力 并且通过测试可以找到所有的软件故障 这其实是人们对软件开发过程理解上的一个误区 在实际的软件开发过程中 软件测试作为现代软件开发工业的一个非常重要的组成部分 正扮演着越来越重要的角色 随着软件规模的不断扩大 如何在有限的条件下对被开发的软件进行有效的测试已经成为软件工程中一个非常关键的课题 1 3 1软件测试的复杂性 软件测试是一项细致并且需要具备高度技巧的工作 稍有不慎就会顾此失彼 发生不应有的疏漏 针对下面几个问题的分析充分说明了软件测试的复杂性 1 不可能对程序实现完全测试在实际的软件测试工作中 完全测试是不现实的 所谓完全的测试 就是让被测程序在一切可能的输入情况下全部执行一遍 通常也称这种测试为 穷举测试 1 3 1软件测试的复杂性 穷举测试会引起以下几种问题 测试所需要的输入量太大 测试的输出结果太多 软件执行路径太多 软件的规格说明书存在主观性 没有一个客观的标准 从不同的角度来评判 软件缺陷的标准是不同的 1 3 1软件测试的复杂性 加法的测试 穷举法 输入合理数据 1 0 1 1 1 2 计算器能处理的数字是32位 所以要一直输入到1 99999 99999 共32个9 接下来 继续输入2 0 2 1 2 2 直到输入2 99999 99999 共32个9 依次类推 加法的输入还在继续 输入不合理数据 1 a jpkl o9 jsfw 16 这样的测试情况可能出现无穷多个 1 3 1软件测试的复杂性 按照上述思路一个一个的测试 单是加法的输入就接近无穷多个 使得在理论上根本无法进行穷举测试 在实际的使用过程中 测试人员还要考虑到包括随机出现的各种突发情况 比如用户不小心撞到键盘引起某个误操作 GlenfordJ Myers在1979年描述了一个只包含loop循环和if语句的简单程序 可以使用不同的语言将其写成20行左右的代码 但是这样简短的语句却有着十万亿条路径 面对这样一个庞大的数字 即便是一个有经验的优秀的软件测试员也需要十亿年才能完成全部测试 而且在实际应用中 此类程序是非常有可能出现的 1 3 1软件测试的复杂性 2 杀虫剂现象软件中存在的故障现象与发现的故障数量成正比 1990年 BorisBeizer在其编著的 SoftwareTestingTechniques 第二版 中提到了 杀虫剂怪事 一词 同一种测试工具或方法用于测试同一类软件越多 则被测试软件对测试的免疫力就越强 这与农药杀虫是一样的 老用一种农药 则害虫就有了免疫力 农药就失去了作用 在现实当中 往往是发现了一个故障以后 很可能会接二连三地发现更多的软件故障 有这样一个现象值得我们去重视 47 的软件故障 是由用户发现的 是与系统中的4 的程序模块有关 因此 经测试后的程序中隐藏的故障数目与该程序中发现的故障数目成正比 1 3 1软件测试的复杂性 产生杀虫剂现象的可能原因是由于开发过程中各种各样的主客观因素 再加上不可预见的突发性事件 软件测试员采用同一种测试方法或者工具不可能检测出所有的缺陷 为了克服被测试软件的免疫力 软件测试员必须不断编写新的测试程序 对程序的各个部分进行不断测试 以避免被测试软件对单一的测试程序具有免疫力而使软件缺陷不被发现 因此 根据经验 我们应当对故障集中的程序模块进行重点测试 越是问题多的模块 越是要花更多的时间和代价来测试 以此会达到更好的测试效果 太少的测试是不负责任 过多的测试是一种浪费 100 的测试是不可能的 图1 3最优测试量 1 3 1软件测试的复杂性 3 软件测试的代价 1 3 1软件测试的复杂性 4 不能修复所有的软件故障在软件测试中还有一个严峻的现实 即使花再多的时间和代价 也不能够使所有的软件故障都得到修复 但这并不能说明测试就是失败的 在实际操作过程中 测试人员要进行正确的判断 合理的取舍 根据风险分析来决定哪些故障需要修复 哪些故障可以不修复 即并不是所有的软件缺陷都需要被修复 1 3 1软件测试的复杂性 当确定是软件缺陷时 若出现以下情况 软件缺陷就不能被修复 不会引起大的问题 为了防止整个系统由于局部修复而出现某些问题 在特殊情况下 不常出现的小问题可以暂时忽略 修复所冒的风险太大 由于软件本身各个模块之间有着千丝万缕的联系 使得单一修复某一段代码可能会产生更多的大量未知故障 所以在某些情况下不修复反而是最保险的做法 没有足够的时间去修复 在商业活动中 为了能及时交付软件产品 当部分软件缺陷没有足够的时间修复 又不会对软件的正常运行产生大的影响时 就只能在说明书中列出可能出现的缺陷 可以不算成故障的缺陷 某些特殊的缺陷有时从另一个方面看可以理解成一种新的附加功能 这是大多数商务软件在处理一些特殊缺陷时采取的做法 1 3 2软件测试的经济性 测试工作在整个项目开发过程中占有重要地位 从软件工程的总目标出发 测试的经济性要求充分利用有限的人力和物力资源 高效率 高质量地完成测试 在软件测试过程中 必须考虑它的经济性 考虑应该按照什么样的原则进行测试 以实现测试成本与测试效果的统一 为了降低测试成本 在选择测试用例时要遵守以下原则 被测对象的测试等级应该取决于