软件测试第1章

1、 高等院校计算机系列课程软件测试软件测试教材 软件测试技术，21世纪高等院校计算机系列教材 作者：曲朝阳等编著，出版社：中国水利水电出版社，2006-8-1，ISBN：7508439295 参考教材 软件测试教程 重点大学计算机教材 作者：宫云战 主编 ，出版社：机械工业出版社 ，2008-9-1，ISBN：711124897 参考教材 软件测试 作者：美Paul .Jorgensen 译者：韩柯 杜旭涛 出版社：机械工业出版社 原出版社： CRC 参考教材 计算机 软件测试技术郑人杰清华大学出版社，1990。参考教材 软件测试教程 作者: 贺平出版社: 电子工业出版社页数: 319定价: 2

2、9.0出版时间: 2005-06-01 教学目标 了解软件测试的基本原理和基本概念 掌握基本的软件测试方法和技术 提高软件质量控制的意识和素质 培养工程实践及团队合作精神评分标准 上机实践：熟练运用软件测试的方法和技术，在对实际程序进行测试，同时遵照软件文档规范提交设计文档、源程序和测试报告 (20%) 平时出勤及课堂练习(10%) 期末考试-闭卷考试(70%)软件错误无处不在只要是人编写的软件，就不能避免软件错误的发生。软件错误的案例(1) 迪斯尼的狮子王游戏 时间：时间：1994199419951995 背景：迪斯尼公司首次进军儿童游戏市场，市场宣传力背景：迪斯尼公司首次进军儿童游戏市场，

3、市场宣传力度很大，前期销售情况很好度很大，前期销售情况很好 出现的问题：该游戏在一些出现的问题：该游戏在一些PCPC机上无法玩机上无法玩 原因：迪斯尼公司没有对市场上已经投入运行的原因：迪斯尼公司没有对市场上已经投入运行的PCPC机型机型进行调研，并且进行测试，导至该游戏只在程序员开发进行调研，并且进行测试，导至该游戏只在程序员开发游戏的系统上可以运行，但在大众使用的常见系统中无游戏的系统上可以运行，但在大众使用的常见系统中无法运行法运行 结果：迪斯尼公司不得不承担客户的投诉、产品退货、结果：迪斯尼公司不得不承担客户的投诉、产品退货、更换光盘、以及又一轮的调试、修改和测试的所有费用更换光盘、以

4、及又一轮的调试、修改和测试的所有费用。软件错误的案例(2) Intel奔腾浮点除法软件缺陷 时间：时间：19941994 背景：背景：IntelIntel发布的一款新处理器发布的一款新处理器 问题：在装有这款处理器计算机的计算器中执行算式问题：在装有这款处理器计算机的计算器中执行算式“(4195835/3145727)(4195835/3145727)3145727-41958353145727-4195835”不等于不等于0 0 原因：老式奔腾原因：老式奔腾CPUCPU的浮点除法软件有缺陷的浮点除法软件有缺陷 结果：结果：IntelIntel事实上在芯片发布之前，已经发现了这个事实上在芯片发

5、布之前，已经发现了这个缺陷，但认为不严重，没有修正。被外界发现后，试缺陷，但认为不严重，没有修正。被外界发现后，试图掩饰。最终，迫于舆论压力公开道歉，花费图掩饰。最终，迫于舆论压力公开道歉，花费4 4亿美元亿美元更换老芯片。更换老芯片。软件错误的案例(3) 美国航天局火星极地登陆 时间：时间：19991999年年1212月月3 3日日 背景：火星极地登陆飞船在试图登陆火星表面时背景：火星极地登陆飞船在试图登陆火星表面时失踪。失踪。 问题：某一个数据位被意外复位问题：某一个数据位被意外复位. . 原因：测试过程分两组：一组是测试飞船脚的落原因：测试过程分两组：一组是测试飞船脚的落地打开过程；另一

6、组是测试飞船打开后的着陆过地打开过程；另一组是测试飞船打开后的着陆过程；前一组没有注意数据位是否被置位，因为这程；前一组没有注意数据位是否被置位，因为这不是他们负责的范围。而后一个组在每次测试之不是他们负责的范围。而后一个组在每次测试之前又重置计算机，清除所有的数据位。双方独立前又重置计算机，清除所有的数据位。双方独立工作都很正常，但两个组没有进行集成测试。工作都很正常，但两个组没有进行集成测试。 结果：飞船坠毁结果：飞船坠毁软件错误的案例(4) 千年虫 时间：时间：2020世纪世纪9090年代年代 背景：随着背景：随着2121世纪的到来，很多的计算机系统都面临世纪的到来，很多的计算机系统都面

7、临着着“千年虫千年虫”的危害的危害 问题：这样就导致问题：这样就导致20002000年以后的年份的记录出现问题，年以后的年份的记录出现问题，如如0000年是指年是指19001900还是还是20002000？ 原因：原因：2020世纪世纪7070年代时，由于计算机存储空间很小，年代时，由于计算机存储空间很小，并且十分昂贵，所以在计算机中记录时间采用了并且十分昂贵，所以在计算机中记录时间采用了“偷偷懒懒”的方式，例如将的方式，例如将19731973缩减为缩减为7373 结果：世界各地为了更换和升级系统，花费了上百亿结果：世界各地为了更换和升级系统，花费了上百亿的美元的美元软件错误的案例(5) 爱国

8、者导弹防御系统炸死自家人 背景：海湾战争时导弹防御系统背景：海湾战争时导弹防御系统 问题：软件系统缺陷问题：软件系统缺陷 原因：系统时间的累计错误，延时原因：系统时间的累计错误，延时1414个小时，造成跟个小时，造成跟踪系统失去了准确度。踪系统失去了准确度。 结果：爱国者导弹炸死结果：爱国者导弹炸死2828名美军士兵。名美军士兵。软件测试工程师，需要具备哪些软件测试工程师，需要具备哪些能力？能力？ 通用技能上：1.基本计算机知识（操作系统，数据库，通讯协议原理，熟悉至少一门编程语言）2.基本软件测试知识（各种测试理论，测试方法论，测试用例编写，缺陷界定标准，软件质量评估）3.简单项目管理知识软

9、件测试工程师，需要具备哪些软件测试工程师，需要具备哪些能力？能力？ 性格上：有牛皮糖属性的为佳，越“不要脸”越好测试工程师提交的BUG越多，意味着研发工程师工作质量越差，需要返工的工作量也越大，甚至会影响绩效，所以测试工程师有时候很容易得罪研发部门。一个可以相对坚持原则（比如3级BUG以上一定要改），又能拉下脸和不愉快的研发工程师保持较好关系的测试工程师，会对项目质量起到很关键作用。软件测试工程师，需要具备哪些软件测试工程师，需要具备哪些能力？能力？ 你不是产品，但你知道产品是怎么工作的； 你不是运营，但你知道用户关心什么； 你不是开发，但你知道开发同事怎么工作； 你不是设计，但你有你对交互逻

10、辑的理解； 你不是销售和编辑，但你熟悉产品业务。第一章 概述 本章要点本章要点 l 软件测试的发展历史；l 软件测试技术的分类方法；l 软件测试原则；l 软件测试的定义；l 软件测试同软件开发之间的关系；l 软件测试与开发模型；l 软件测试工作流程。 本章目标本章目标 u 了解软件测试的发展历程和行业现状；u 掌握软件测试技术的分类；u 理解软件测试的目的和软件测试原则，以及了解人们对软件测试行业的错误认识；u 掌握软件测试中的基本定义、基本知识;u 理解软件开发与软件测试的关系。 1.1软件测试的发展历程及现状软件测试的发展历程及现状 1.1.1软件测试的发展历程软件测试的发展历程 20世纪

11、50-60年代，软件仍然处于次要位置,测试理论和方法的发展比较缓慢。 70年代以后，软件技术的成熟和完善使得软件测试的规模和复杂度加大，软件测试也逐渐形成了一套完整的体系，逐渐走向规范化。 如今对软件质量的要求越来越高，质量的控制已经不仅仅是传统意义上的基于代码运行上的测试。软件测试已经是一个基于整个软件生命周期的质量控制活动。1.1软件测试的发展历程及现状软件测试的发展历程及现状 1.1.2软件测试的现状软件测试的现状 与一些发达国家相比，国内测试工作还存在一定的差距。国内测试人员所占比例小。 微软的开发工程师与测试工程师的比例是1 : 2,国内一般公司是6 ：1. 与发达国家相比，我们的差

12、距主要在测试意识，测试理论的研究，测试工具软件的开发以及从业人员的数量等方面。1.1软件测试的发展历程及现状软件测试的发展历程及现状 近年来，随着软件外包行业的兴起，国近年来，随着软件外包行业的兴起，国内软件质量保证的意识也在加强。占整体内软件质量保证的意识也在加强。占整体外包业务外包业务85%85%的对日软件外包中主要的工作的对日软件外包中主要的工作就是软件测试。就是软件测试。 IBMIBM，百度，华为，惠普，盛大，百度，华为，惠普，盛大，联想等大型联想等大型ITIT企业均表示出对成熟软件测企业均表示出对成熟软件测试人员的期盼。试人员的期盼。 1.2 1.2 什么是软件测试什么是软件测试（s

13、oftware testingsoftware testing） 1.2.11.2.1软件测试的定义软件测试的定义 根据侧重点的不同，主要有以下三种观点： 1）“使用人工或自动手段运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别”，该定义明确地提出了软件测试以检验是否满足需求为目标。 2）“软件测试是为了发现错误而执行程序的过程”，明确提出了“寻找错误”是测试目的。 3）从软件质量保证的角度看：是一种重要的软件质量保证活动，其动机是通过一些经济、高效的方法，捕捉软件中的错误，从而达到保证软件内在质量的目的。 最终目的是验证软件是否按着预期运行。

14、测试过程中的活动包括“分析”软件（静态测试）和“运行”软件（动态测试）。 也有人认为软件测试（software testing）就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。 软件测试有两个基本职责：确认：保证开发过程中软件符合产品说明书的过程验证：保证最终产品满足用户要求的过程 经常会确认了但没有验证，例如1990年哈勃天文望远镜事件。 注意：区分软件测试和软件调试。 1，调试分析和定位BUG，不能完全代替测试。 2，调试是为了使软件正确运行，测试是找错误。 3，调试对象是源代码，测试的对象是开发过程各个阶段的所有产品。 1.2.21.2.2软

15、件测试生命周期软件测试生命周期 测试的生命周期（software testing life cycle）分为几个阶段（如图1-1所示 ）。 前三个阶段就是引入程序错误阶段； 后三个阶段就是清除程序错误的阶段。 需求规格说明设计编码测试缺陷分类缺陷分离缺陷排除修复错误错误错误错误错误错误错误错误3(失效)图1-1 测试生命周期 1.2.3 1.2.3软件开发与测试模型软件开发与测试模型 下面我们将介绍几种典型的软件开发与测试模型。 一、软件开发模型一、软件开发模型1 1、大爆炸模型、大爆炸模型 一大堆能量（这里指开发软件所需的人力和物力）放在一起，巨大的能量进行释放，通常的结果可能是产生了优秀的

16、软件产品或成为一堆“废品”（不成功的软件）。 优点：思路简单，计划、进度和正规开发过程几乎没有，所有的精力集中在开发软件和编写代码上,通常可能是开发者的“突发奇想” 缺点：开发过程是非工程化的，随意性大。由于软件已经完成，不可能回头修复已经无法挽回的问题，软件测试的工作其实只是向用户报告发现的问题。 关于测试：有的较简单，有的则非常困难。测试工作妨碍软件的交付，测试越深入，就会发现越来越多的缺陷，实际中测试几乎不作。 1.2.3 1.2.3软件开发与测试模型软件开发与测试模型 一、软件开发模型一、软件开发模型1 1、大爆炸模型、大爆炸模型 1.2.3 1.2.3软件开发与测试模型软件开发与测试

17、模型 一、软件开发模型一、软件开发模型瀑布模型瀑布模型瀑布模型是将软件生命周期的各项活动，规定为按照固定顺序相连的若干个阶段性工作，形如瀑布流水，最终得到软件产品。 问题定义分析研究需求分析软件设计编码测试维护定义阶段开发阶段维护阶段瀑布开发模型瀑布开发模型 1.2.3 1.2.3软件开发与测试模型软件开发与测试模型一、软件开发模型一、软件开发模型瀑布法瀑布法 优点：易于理解；调研开发的阶段性；强调早期计划及需求调查；能够确定何时能够交付产品及何时进行评审与测试。 缺点：需求调查分析只进行一次，不能适应需求变化；顺序的开发流程，使得开发中的经验教训不能反馈到该项目的开发中去；不能反映出软件开发

18、过程的反复与迭代性；没有包含任何类型的风险评估；开发中出现的问题直到开发后期才能够显露，因此失去及早纠正的机会。边写边改法 采用边写边改法的软件开发通常只是有了比较粗略的想法就开始进行简单的设计、然后进行较长的反复编写、测试与修复，是一个循环的过程。在认为无法更精细的描述软件产品要求时，就发布产品。 优点：能够较为迅速的展现成果，适合需要快速制作而且用完就扔的小项目，如示范程序、演示程序等。缺点：其编码和测试可能将是长期的循环往复的过程。 产品说明书代码编制、测试、修复代码编制、测试、修复 最终产品快速原型模型快速原型模型 快速原型模型的第一步是建造一个快速原型，实现客快速原型模型的第一步是建

19、造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。价，进一步细化待开发软件的需求。 通过逐步调整原型使通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产什么；第二步则在第一步的基础上开发客户满意的软件产品。品。 需求分析需求分析原型开发原型开发原型评价原型评价最终设计最终设计系统实现系统实现用户反馈用户反馈螺旋模式法螺旋模式法 螺旋模式是瀑布模式与边写边改演化模式相结合，并加

20、入风险评估所建立的软件开发模式。 每一个螺旋周期，为开发的一次迭代在每次迭代中，没有固定定义的软件活动，而是根据需要选择。将开发活动与风险分析相结合，用于降低和控制风险。软件开发与软件测试的关系测试与开发各阶段的关系测试与开发各阶段的关系软件测试与软件开发过程的关系需求分析说明书详细设计说明书源程序代码单元测试集成测试系统测试概要设计说明书 1.2.3 1.2.3软件开发与测试模型软件开发与测试模型 一、软件开发与测试一、软件开发与测试V V模型模型 在传统开发过程中测试不受重视，仅把它作为在需求分析、概要设计、详细设计及编码之后的一个阶段。尤其在瀑布模型中。 V模型，描述了一些不同的测试级别

21、， 级别对应的生命周期中不同的阶段， 这些测试阶段和开发过程期间存在对应关系。 用户需求获取需求定义需求分析需求分析书概要设计概要设计书详细设计详细设计书编码程序软件产品可交付软件系统测试已确认软件确认测试已集成软件集成测试已测试模块单元测试需求分析评审评审评审评审评审评审评审评审 V模型示意图 二、软件开发与测试二、软件开发与测试WW模型模型 开发的每一个环节都可能产生错误，如果坚持各个阶段的技术评审,就能够尽早发现和预防错误。 W 模型，形象地说明了软件测试与开发的这种同步性。 W模型的优点在于，每个软件开发活动结束后就可以执行相应的测试，如：在需求分析结束后，就可以进行需求分析测试。 需

22、求测试需求分析功能测试概要设计设计测试详细设计单元测试编码系统测试验收确认测试确认集成测试集成图1-3 W模型示意图 三、软件开发与测试三、软件开发与测试HH模型模型 与前两种模型相比，H模型充分地体现了测试过程。 1、 软件测试不仅仅指测试的执行, 还包括很多其他的活动。 2、软件测试是一个独立的流程, 贯穿产品的整个开发周期, 与其它流程并发进行。 3、软件测试要尽早准备, 尽早执行。 测试准备测试执行测试流程其他流程测试就绪点图1-4 H模型示意图 4、软件测试根据被测物的不同是分层次的. 不同层次的测试活动可以是按照某个次序先后进行的, 但也可能是反复的。 1.2.4 1.2.4与软件

23、测试相关的术语与软件测试相关的术语 1.错误（Error） 程序员在编写代码时会出错，我们把这种错误称之为bug。随着开发过程的进行，错误会不断的放大。 2.缺陷(Default) 缺陷是错误的结果，更精确的说是错误的表现。 包括过错缺陷和遗漏缺陷。 过错缺陷：信息输入到了不正确的表现形式中 遗漏缺陷：没有输入信息 3.失效（Failure） 在缺陷运行时，常常会发生失效的情况。一种是过错缺陷对应的失效；一种是遗漏缺陷对应的失效。 4.测试（Test） 测试是一项采用测试用例执行软件的活动，在这项活动中某个系统或组成的部分将在特定的条件下运行，然后要观察并记录结果，以便对系统或组成部分进行评价

24、。 5.测试用例(Test Case) 测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。 6.回归测试（Regression testing） 回归测试的目的是为了测试由于修正缺陷而更新的应用程序，以确保彻底修正了上一个版本的缺陷，并且没有引入新的软件缺陷。 回归测试可分为：回归测试可分为： 完全回归测试完全回归测试 严重性高严重性高 部分回归测试部分回归测试 时间紧张，测试内容过多时间紧张，测试内容过多 1.31.3软件测试技术分类软件测试技术分类 从不同的角度，可以把软件测试技术分成不同种类， 一 、从是否需要执行被测软件的角度，可分为静态测试和动态测试。 比如检查二手车

25、，看车漆属于静态测试，发动听音则属于动态测试。 静态测试 那些不利用计算运行被测程序，而是通过其他手段达到测试目的的方法称作静态测试。 几种静态测试 代码检查：以小组为单位阅读代码 代码走查：在检查的基础上，还要执行逻辑运行 桌面检查：由一个人进行的代码检查与走查 同行评分：不为发现错误，对代码自己质量进行评价 动态测试 动态测试的对象：必须是能够运行的程序。 通过输入测试用例，并对实际输出结果和预期输出结果进行比较分析，从而发现错误的测试属于动态测试。 黑盒测试和白盒测试就属于动态测试。 二、从软件测试用例设计方法的角度，可分为黑盒测试（Black-Box Testing）和白盒测试（Whi

26、te-Box Testing）。黑盒测试：又叫功能性测试，测试人员只需知道软件要做什么？无法看到软件如何运行。目的是检查程序各个功能是否实现。白盒测试：测试人员可以访问代码，并通过检查代码线索来协助测试。目的是检查内部操作是否按规定执行，功能是否得到充分使用。 三、按照软件测试的策略和过程分类，软件测试可分为单元测试(Unit Testing)：针对每个单元的测试，是测试的最小单位。集成测试(Integration Testing)：主要检查与软件设计相关的程序结构问题。确认测试(Validation Testing)：测试程序能否满足所有功能和性能的需求。系统测试(System Testin

27、g)：测试软件与系统的其他部分的协调性。验收测试(Verification Testing)：从用户角度进行测试。 1.4 1.4软件测试的目的软件测试的目的 测试真正的目的是使我们通过对软件错误的原因和分布进行归纳，来发现并排除当前软件产品的缺陷，对在需求和设计过程中存在的问题查缺补漏，从而确保软件产品的质量。 测试的目标： 1)软件测试是为了发现错误而执行程序的过程。 2)测试是为了证明程序有错，而不是证明程序无错。 3)一个好的测试用例在于他能发现至今未发现的错误。 4)一个成功的测试是发现了至今未发现的错误的测试。 软件测试不只是软件测试人员的工作，也是软件开发人员和软件使用者的工作。

28、 1.51.5软件测试的原则软件测试的原则 1.5.1 1.5.1尽早地和不断地进行软件测试尽早地和不断地进行软件测试 缺陷存在放大趋势。需求阶段缺陷概要设计阶段缺陷详细设计阶段缺陷代码阶段缺陷放大n1倍放大n2倍放大n3倍图1-5 缺陷放大模型 问题发现越早，解决问题的代价就越小，这是软件开发过程中的黄金法则。 1.5.21.5.2不可能完全的测试不可能完全的测试 对一个程序进行完全测试就是意味着在测试结束之后，再也不会发现其它的软件错误了。这是不可能的。主要原因有以下几点： 一、不可能测试程序对所有可能输入的响应。 1，对所有有效输入 2，对所有无效输入 3，对所有编辑过的输入（如Back

29、space反复编辑） 4，对所有输入时机的变化 （输入的随机中断） 无法进行完全测试的例子程序PXYZ若X、Y为所有可能的整数 在字长32位机上测试X1、Y1 Z1 Xn、Yn Znn = 232232 = 264 1.84 1019 1.5.21.5.2不可能完全的测试不可能完全的测试 二、不可能测试到程序每一条可能的执行路径 M1D1D2D3D4M2M3M4M5M6M7D5=20次循环次数01220独立路径数51+52+53+5211014(1百万亿)每个测试用例（考虑、执行、验证结果）5分钟共需测试时间10亿年 1.5.21.5.2不可能完全的测试不可能完全的测试 三、无法找出所有的设计

30、错误 四、不能采用逻辑来证明程序的正确性 1.5.3 1.5.3增量测试，由小到大增量测试，由小到大 测 试 时 间测 试 范 围可 用 资 源系 统 测 试集 成 测 试单 元 测 试单 元 测 试测试资源关系图 1.5.4 1.5.4避免测试自己的程序避免测试自己的程序 避免程序员测试自己的代码的主要原因： 1.程序员轻易不会承认自己写的程序有错误。 2.程序员的测试思路有局限性，在做测试时很容易受到编程思路的影响。 3.多数程序员没有严格正规的职业训练，缺乏专业测试人员的意识。 4.程序员没有养成错误跟踪和回归测试的习惯. 1.5.5 1.5.5设计周密的测试用例设计周密的测试用例 软件

31、测试的本质就是针对要测试的内容确定一组测试用例。测试用例至少应该包括如下几个基本信息： 1、在执行测试用例之前，应满足的前提条件。 2、输入（合理的、不合理的）。 3、预期输出（包括后果和实际输出）。 图1-8显示了一个典型的测试用例所应该具有的基本信息。测试用例ID：目的：前提：输入：预期输出：后果：执行历史：日期： 结果： 版本： 执行人：测试用例是测试工作的核心，应该尽量设计的周密细致，这样才能更好的保证测试工作的质量。 以一个实现登录功能的小程序为例，它允许用户选择城市和地区，输入自己的账号和密码。 通过Alt-F4组合键和“退出”按钮来终止程序，Tab键在区域中间移动。 操操 作作

32、员员 登登 录录 选 择 城 市 选 择 地 区 城 市地 区操 作 员密 码提 交退 出图1-9 登录窗口根据组成页面的具体元素，分别从几个方面做了一些比较全面的测试用例：操作员登录操作员登录选择城市选择地区城市地区操作员密码提交退出1. 下拉框和输入框测试用例 表1-1 下拉框和输入框测试用例测试内容测试内容输入操作输入操作预期输出预期输出实际结果实际结果下拉框下拉框未和后台数据库绑定未和后台数据库绑定（显示列表元素固定）（显示列表元素固定）不允许列表中出不允许列表中出现现NULLNULL现象，现象，固定固定“请选择请选择-”-”已和后台数据库绑定已和后台数据库绑定（显示列表元素活动）（显

33、示列表元素活动）不允许列表中出不允许列表中出现现NULLNULL现象，现象，固定固定“请选择请选择-”-”输输入入框框限定字符型限定字符型输入输入1212、6 6无无# #，* *等等错误提示错误提示限定型数字限定型数字输入输入测试数据测试数据无无1212月、月、7 7* *、0 0错误提示错误提示2、功能测试 （表1-2 功能测试用例）用 例应产生行为结果失败原因1.基本功能测试1.1在输入框内输入资料并且执行存储程序必须能够接受使用者的输入并且将输入值存在登录文件内1.2在输入框内不输入资料但执行储存程序必须能够检查使用者输入是否为空白，同时必须能够告知使用者原因1.3检查city字段储存

34、结果City字段输入 后存入cookies1.4检查area字段储存结果Area字段输入 后存入cookies储存结果1.5检查ID 字段储存结果ID字段输入 后存入cookies2.使用接口功能测试2.1检查输入字段的输入值必须组织使用者输入空白，同时部分字段只能输入数字2.2检查使用者接口的Tab Order所有的Tab Order必须按照正常顺序2.2检查所有的Button所有的Button必须能够起作用2.3检查所有的Hot Key所有的Hot Key必须能够起作用3、各种错误数据的测试表1-3 错误数据的测试用例测试内容测试内容输入操作输入操作预选测预选测试数据试数据预期输出预期输出

35、实际结果实际结果点击登录点击登录按钮按钮不完整的数据不完整的数据 CityCity，areaarea，I ID D，pswdpswd略略提示错误对话提示错误对话框框不正确的数据不正确的数据 CityCity，areaarea，I ID D，pswdpswd略略提示错误对话提示错误对话框框回车操作回车操作不完整的数据不完整的数据 CityCity，areaarea，I ID D，pswdpswd略略提示错误对话提示错误对话框框点击点击“退退出出”按钮按钮无无无无无无关闭当前应用关闭当前应用系统系统4、特殊测试 表1-4 特殊测试用例测试内容测试内容输入操作输入操作预选测试数预选测试数据据预期输出

36、预期输出操作焦点逃操作焦点逃逸逸连续连续TabTab切换，察看异常切换，察看异常无无焦点可准确回归焦点可准确回归当前操作窗口当前操作窗口分配内存不分配内存不足足启动多个应用程序或模拟启动多个应用程序或模拟多个程序运行多个程序运行无无是否可以正常运是否可以正常运行行网络断线网络断线切断网络连接切断网络连接无无是否可正常抛出是否可正常抛出异常异常 1.5.6 1.5.6注意错误集中的现象注意错误集中的现象 软件缺陷的“扎堆”现象的常见形式： 1、对话框的某个控件功能不起作用，可能其他控件的功能也不起作用。 2、某个文本框不能正确显示双字节字符，则其他文本框也可能不支持双字节字符。 3、联机帮助某段

37、文字的翻译包含了很多错误，与其相邻的上下段的文字可能也包含很多的语言质量问题。 4、安装文件某个对话框的“上一步”或“下一步”按钮被截断，则这两个按钮在其他对话框中也可能被截断。 1.5.7 1.5.7确认确认BUGBUG的有效性的有效性 有时候测试人员提交的BUG并不是真正的BUG。一般由A测试人员发现的BUG，一定要由另外一个B测试人员来进行确认，如果发现严重的BUG可以召开评审会进行讨论和分析。 1.5.7 1.5.7确认确认BUGBUG的有效性的有效性 有时候测试人员提交的BUG并不是真正的BUG。无效BUG来源构成图 1.5.8 1.5.8合理安排测试计划合理安排测试计划 合理的测试

38、计划有助于测试工作顺利有序地进行，要求: 结合多种针对性强的测试方法、 列出所有可使用资源， 建立一个正确的测试目标； 要本着严谨、准确的原则，周到细致地做好测试前期的准备工作，避免测试的随意性。尤其是要尽量科学合理地安排测试时间。 1.5.91.5.9回归测试回归测试 程序员修正BUG时，完全有可能会引入一处或多处错误。当需求变更时，对现有系统也会产生类似的波及效应，导致错误产生，这是因为错误具有关联现象。 因此，当程序改动时，需要进行多次回归测试以保证错误被正确关闭。 ABABCABCDEF基本结构（a）（b）（c）单纯依赖多重依赖复合依赖错误依赖关系1.5.91.5.9回归测试回归测试错

39、误具有关联现象（a）图中的A、B 关系表达为：A错误依赖于B错误的关闭而关闭。（b）图，A错误依赖于B错误和C错误的同时关闭而关闭。（c）图是（a）和（b）的复合方式，因程序中的错误存在着一对多，多对多的复杂关系而变得难以处理，并且有些错误关联和依赖关系处于隐性状态。 1.5.10 1.5.10测试结果的统计和分析测试结果的统计和分析 得出的测试结果中存在大量的正确的以及错误的输出信息，只有对这些输出信息进行深入地统计、分析和比较，才能够正确的鉴别测试后输出的数据，给出清晰的错误原因分析报告。当输出的信息很庞大时，我们可以借助专业的测试工具。 1.5.11 1.5.11及时更新测试及时更新测试

40、 设计用例后未及时测试，会造成文档过时现象。 有可能导致测试失败的原因还有很多，可大致归纳为如下几点： 1、测试团队管理者失职； 2、测试团队中沟通不好； 3、测试团队和项目团队沟通不良； 4、测试过程中，执行角色无准确定义； 5、测试团队缺乏良好的培训。 1.6 1.6软件测试工作流程软件测试工作流程 一般的软件测试总体工作流程如图1-12所示： 立项阶段需求阶段设计阶段编码单元测试阶段集成测试阶段系统测试阶段验收测试阶段结项总结阶段图1-12 软件测试工作总体流程图 1、需求阶段 需求阶段是软件测试活动的前提。需求阶段测试工作流程如图1-13所示： 需 求 工 作 培 训编 写 需 求业

41、务 、 用 户 、 功 能需 求 评 审需 求 规 格 说 明 书需 求 变 更需 求 变 更 记 录需 求 报 警总 体 测 试 计 划系 统 测 试 方 案需 求 报 警 信 号需 求 跟 踪 矩 阵进 入 下 一 阶 段需需求求阶阶段段测测试试工工作作流流程程图1-13 需求阶段测试活动流程图2、设计&编码阶段测试工作流程 图1-14 设计&编码阶段测试流程图上一阶段需求相关文挡概要设计评审详细设计单元测试方案编码单元测试测试抽检单元测试总结报告进入下一阶段集成测试方案自动测试方案抽象出验证标准设设计计& &编编码码阶阶段段测测试试工工作作流流程程以模块为

42、单位，不断循环 这一环节以模块为单位循环：单元测试方案制定编码单元测试是否通过测试抽检是否通过，重新编写没有通过单元测试和测试抽检的代码。最终形成一份单元测试总结报告。 3、集成测试、系统测试和验收测试阶段 该测试阶段流程如图1-15所示： 上一阶段集成测试方案集成测试系统测试申请测试部评估自动测试方案系统测试方案系统测试系统测试综合报告验收测试质量合格证书产品化工作产品工作报告测试工作总结集集成成、系系统统、验验收收测测试试阶阶段段图1-15 集成测试、系统测试和验收测试阶段流程图 1.7 1.7软件测试中的误区软件测试中的误区 误区1 调试和测试是一样的 1,软件测试是找出软件已经存在的错

43、误,而调试是定位错误,修改程序以修正错误. 2,软件测试从一个已知的条件开始,有预知的结局 而调试从未知的条件开始,其结局不可预知 3,软件测试可以计划,可以预先制定测试用例和过程,工作进度可以度量.而调试不能计划,进度不可度量. 4,测试的对像可以是文档和代码 而调试的对像只能是代码 . 1.7 1.7软件测试中的误区软件测试中的误区 误区2 软件测试在软件开发过程中并不重要 误区3 在软件开发结束之后进行测试 误区4 过分依赖Beta测试 误区5 过分依赖自动化测试 误区6 测试是可穷尽的 误区7 测试是证明软件的正确性 误区8 可以忽略测试的设计 1.8 软件测试过程1.8.1 制定测试

44、计划1.8.2 测试执行过程1.8.1 制定测试计划1 1、制定计划、制定计划本阶段的主要工作内容 对需求规格说明书的仔细研究 将要测试的产品分解成可独立测试的单元 为每个测试单元确定采用的测试技术 为测试的下一个阶段及其活动制定计划制定计划包括： （1）概要测试计划 （2）详细测试计划1.8.2 测试执行过程 1 1、测试执行过程的三个阶段、测试执行过程的三个阶段（1）初测期 测试主要功能和关键的执行路径，排除主要障碍。（2）细测期 依据测试计划和测试大纲、测试用例，逐一测试大大小小的功能、方方面面的特性、性能、用户界面、兼容性、可用性等等；预期可发现大量不同性质、不同严重程度的错误和问题。

45、（3）回归测试期 系统已达到稳定，在一轮测试中发现的错误已十分有限；复查已知错误的纠正情况，确认未引发任何新的错误时，终结回归测试。测试执行过程（续）初测期初测期功能冻结功能冻结代码冻结代码冻结回归测试期回归测试期细测期细测期0 020204040606080801001001201201401401601601 12 23 34 45 56 67 78 89 9 1010 1111 1212 1313 1414 1515 1616 1717 1818 1919出错数出错数时间时间三个测试期阶段图示2 2、集成测试过程中的两个重要里程碑、集成测试过程中的两个重要里程碑 在集成测试过程中的两个重

46、要的里程碑是功能冻结和代码冻结的确定。这两个里程碑界定出回归测试期的起止界限。 功能冻结(Function/Feature Freeze) 经过测试，符合设计要求，确认系统功能和其他特性均不再做任何改变。 代码冻结(Code Freeze) 理论上，在无错误时冻结程序代码，但实际上，代码冻结只标志系统的当前版本的质量已达到预期的要求，冻结程序的源代码，不再对其做任何修改。这个里程碑是设置在软件通过最终回归测试之后。测试执行过程（续）1.9 软件质量保证1.9.1 软件错误与质量保证1.9.2 软件质量管理1.9.3 软件能力成熟度模型1.9.4 ISO9000标准简介1.9.1 软件错误与质量

47、保证1.9.1.1 程序正确性情况1.9.1.2 软件错误类型1.9.1.3 程序中隐藏错误的估计1.9.1.1 程序正确性情况 程序编写无语法错误。 这是程序运行的最起码条件，否则无法通过编译程序的检查 程序执行中未发现明显的运行错误。 这是指程序运行时，没有因为产生过大或过小的数据、由于溢出而无法执行；也没有遇到死循环等情况 程序中无不适当语句。 程序尽管符合语法规则，也未出现运行错误，但有些语句不适当。例如，有的变量经过说明，但未曾引用。或有的变量未置初始值而被有引用，有的变量经过多次赋值，但未引用等程序正确性情况(续)程序运行时能通过典型的有效测试数据，得到正确的预期结果。 这说明程序

48、能够接受规格说明所规定的正常条件下的合理数据，并给出正确结果程序运行时能通过典型的无效测试数据，得到正确的结果。 程序能够接受规格说明中多规定的异常条件下的不合理数据，并给出正确结果程序运行时能通过任何可能给出的数据，给出正确的结果。1.9.1.2 软件错误类型和严重程度 根据错误的性质，我们可以将软件错误分为以下几种类型：软件需求错误软件需求制定的不合理或不正确，需求不完全，其中含有逻辑错误，需求分析的文档有误等。功能和性能错误功能或性能规定的有错误，或是遗漏了某些功能，或是规定了某些冗余的功能；为用户提供的信息有错，或者信息不正确；对意外的异常情况处理有误等。软件错误类型和严重程度(续)软

49、件结构错误程序控制流或控制顺序有误；处理过程有误等。数据错误数据定义或数据结构有误；数据存取或数据操作有误等。例如动态数据与静态数据混淆，参数与控制数据混淆等。软件实现和编码错误编码错，或按键错；违背编码风格要求或是编码标准的问题。包括语法错、数据名错、局部变量与全局变量混淆，或是程序逻辑有误等。软件错误类型和严重程度(续)软件集成错误软件的内部接口、外部接口有误；软件各相关部分在时间配合，数据吞吐量等方面不协调软件系统结构错误操作系统调用错或使用错、恢复错误、诊断错误、分割及覆盖错误，以及引用环境的错误等。测试定义与测试执行错误测试的错误往往被人们所忽略，它可能包括测试方设计与测试实施的错误

50、、测试文档的问题、测试用例不够充分等。软件错误类型和严重程度(续)错误分类错误数百分比需求错误13178.1%功能和性能错误262416.2%结构错误408225.2%数据错误363822.4%实现与编码错误16019.9%软件集成错误14559.0%系统结构错误2821.7%测试定义与测试执行错误4472.8%其他类型错误7634.7%软件错误分类统计软件错误分类统计软件错误类型和严重程度(续) 按错误发生的影响和后果，错误的严重程度可以分为如下几类：较小错误：这类错误只是对系统的输出结果有一些非实质性的影响，如输出的数据格式不符合要求中等错误：对系统的运行有局部影响。如输出的某一部分数据有

51、错误或出现冗余较严重错误：系统的行为由于错误的干扰而出现明显不合情理的现象。如开出0.00元的支票。系统的输出结果完全不可信赖。严重错误：系统运行不可跟踪，一时不能掌握其规律，时好时坏。非常严重的错误：系统运行中突然停机，其原因不明，且无法软启动。最严重错误：运行被测的软件导致环境遭到破坏，或者造成事故，引起生命、财产的损失。1.9.1.3 程序中隐藏错误-数量的估计 Seeding Model假设鱼塘中只有一个品种的鱼，目标是估计它的数目N方法：向鱼塘中释放Nt条带标记的鱼，使其与其他未作标记的鱼充分混合。几天后，再从池塘中取一些样本，并根据标记进行区别，得到带标记的鱼nt条，没有标记的n条

52、。如果这一取样是随机进行的，那么可以得到如下的关系ttttnnnNNNttNnnN 程序中隐藏错误数量的估计(续) Hyman的改进的方法（Hyman分别测试法） 两个（或多个）程序员一开始针对同一个程序分别独立的进行排错工作。假设这个工作大约需要4个月完成。在开始的几周内，由一位分析员来评价他们的工作，可以利用公式来估算错误的数量，这样的估算每隔几周就进行一次，直到得到满意的N为止。在过一个月或两个月后，让第二个人去做其他的工作，将工作移交给第一个人。这样在该承袭的排错工作完成1/4或1/2之后，就可以得到该程序错误数的合理估计值。程序中隐藏错误数量的估计(续) 由两个测试员同时互相独立地测

53、试同一程序的两个副本，用t表示测试时间（月），记t = 0时，程序中原有故障总数是B0；t = t1时，测试员甲发现的故障总数是B1；测试员乙发现的故障总数是B2；其中两人发现的相同故障数目是bc；两人发现的不同故障数目是bi。 在大程序测试时，头几个月所发现的错误在总的错误中具有代表性，两个测试员测试的结果应当比较接近，bi不是很大。这时有 程序中隐藏错误数量的估计(续) 如果bi比较显著，应当每隔一段时间，由两个测试员再进行分别测试，分析测试结果，估算B0。如果bi减小，或几次估算值的结果相差不多，则可用B0作为程序中原有错误总数的估值。 2 2个小组独立地测试同一个程序，第一组发现个小组

54、独立地测试同一个程序，第一组发现2525个错误个错误，第二组发现了，第二组发现了3030个错误，在个错误，在2 2个小组发现的错误中有个小组发现的错误中有1515个是共同的，那么可以估计程序中的错误总数是多个是共同的，那么可以估计程序中的错误总数是多少个？少个？程序中隐藏错误数量的估计(续) 如果bi比较显著，应当每隔一段时间，由两个测试员再进行分别测试，分析测试结果，估算B0。如果bi减小，或几次估算值的结果相差不多，则可用B0作为程序中原有错误总数的估值。 2 2个小组独立地测试同一个程序，第一组发现个小组独立地测试同一个程序，第一组发现2525个错误个错误，第二组发现了，第二组发现了30

55、30个错误，在个错误，在2 2个小组发现的错误中有个小组发现的错误中有1515个是共同的，那么可以估计程序中的错误总数是多个是共同的，那么可以估计程序中的错误总数是多少个？少个？答案：答案：2525* *30/15=5030/15=50 1.101.10一个贯穿全文的例子一个贯穿全文的例子 电厂两票管理系统电厂两票管理系统1.10.11.10.1系统简介系统简介 操作票、工作票（简称两票）是“电业(电厂)安全工作规程”中的核心内容之一，对保证电业安全生产具有重要的作用。操作票是保证正确电气倒闸（热机）操作的重要环节和前提条件，使用操作票的目的是为了保障人身与设备的安全，确保电气设备倒闸操作的正

56、确性，防止电气误操作事故发生。 工作票是保证电气(电厂设备)检修工作安全的重要措施，是检修人员在运行设备上或运行区域内进行检修和试验工作，以及做可能影响设备的正常运行或备用状态的其它工作的重要书面依据。“两票”的办理过程基本上都是开票、各部门负责人或三种人审批签字、工作结束、部门或厂部检查审核这样的一种线性办理过程。 电力部门分为水电、火电、供电三种类型，各厂、局要处理的两票类型通常有： 水电厂：电气一种工作票、电气二种工作票、水力机械工作票、一级动火工作票、二级动火工作票、电气倒闸操作票、继保安措票、脚手架工作单、水力机械操作票、溢洪闸门操作票 火电厂：电气一种工作票、电气二种工作票、水力机械工作票、一级动火工作票、二级动火工作票、电气倒闸操作票、继保安措票、脚手架工作单、热力工作票 供电局：电气一种工作票、电气二种工作票、水力机械工作票、一级动火工作票、二级动火工作票、电气倒闸操作票、继保安措票、脚手架工作单、 一种工作票、线路二种工作票。 为了使读者更好的了解两票系统以及后面各章节的内容，在这里对一些电力系统专业术语作如下解释： 一次图：电气主接线是由高压电器通过连接线，按其功能要求组成接受和分配电能的电路，成为传输强