软件测试第01章PPT课件

1、教材 软件测试佟伟光 主编人民邮电出版社，2008-5 软件测试（原书第二版）： Ron Patton著，张小松等译 机械工业出版社，2006-4第1页/共121页关于职业毕业后，你的理想职业是什么？ProgramManagementProductManagementUserEducationLogisticsManagementDevelopmentTestingCommunicationA Team:第2页/共121页第3页/共121页2007中国软件测试从业人员调查报告第4页/共121页2007中国软件测试从业人员调查报告第5页/共121页2007中国软件测试从业人员调查报告 测试人员与

2、开发人员比例“调研数据显示， 2007 年软件测试从业人员所在公司测试人员与开发人员的平均比例为1： 4 1： 5， 与国外软件业1： 1 相差甚远， 表明国内软件测试人才需求和职业发展潜力巨大”。第6页/共121页2007中国软件测试从业人员调查报告第7页/共121页2007中国软件测试从业人员调查报告第8页/共121页2007中国软件测试从业人员调查报告第9页/共121页2007中国软件测试从业人员调查报告第10页/共121页2007中国软件测试从业人员调查报告第11页/共121页2007中国软件测试从业人员调查报告第12页/共121页第第 1 章章 软件测试概述 1.1 软件、软件危机、

3、软件工程 1.2 软件缺陷与软件故障1.3 软件质量与质量模型 1.4 软件测试 1.5 软件测试人员的基本素质第13页/共121页 软件测试是软件工程的一个重要部分，是确保软件工程质量的重要手段。 最近几年来，由于软件工程的复杂度的不断增强，更由于软件的工业化发展趋势，软件测试得到广泛的重视。第14页/共121页软件的四个发展阶段（1） 早期阶段计算机的主要用途是快速计算，软件编程简单，不存在什么系统化的方法，开发没有任何管理，程序的质量完全依赖于程序员个人的技巧。（2） 第二阶段多用户系统引入了人机交互的新概念，实时系统需要从多个源收集、处理数据，从而使得进程以毫秒而不是分钟来进行，在线存

4、储的发展产生了第一代数据库管理系统。 在这个时期，出现了软件产品和软件作坊的概念，设计人员开发程序是为了用户更好地使用计算机，人们开始采用软件工程的方法来解决软件危机问题。第15页/共121页软件的四个发展阶段（3） 第三阶段分布式系统极大地提高了计算机系统的复杂性，特别是微处理器的出现和广泛应用，孕育了一系列的智能产品。软件开发技术的度量问题受到重视，著名的有软件能力成熟度模型 CMM等。（4） 第四阶段是强大的桌面系统和计算机网络迅速发展的时期，面向对象技术在许多领域迅速取代了传统软件开发方法，专家系统和人工智能软件终于走出实验室进入了实际应用，虚拟现实和多媒体系统改变了与最终用户的通讯方

5、式，出现了并行计算和网络计算的研究。 软件下一个阶段是什么样子？第16页/共121页1.1 软件、软件危机、软件工程 1.1.1软件、软件危机、软件工程的基本概念 1.1.2软件工程的目标及其一般开发过程 1.1.3 可供选择的软件过程模型第17页/共121页1.1.11.1.1软件、软件危机、软件工程的基本概念 计算机软件：是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合 软件危机：在计算机软件的开发和维护过程中所遇到的一系列严重问题，软件生产与市场需求出现极不适应的严重现象 软件工程：应用计算机科学、数学及管理科学等原理开发软件的工程第18页/共121页软件

6、的特点1.软件是逻辑的，而不是物理的产品。2.软件没有明显的制造过程。3.软件在运行和使用期间，存在退化问题。软件产品硬件产品第19页/共121页软件的特点4.大多数软件是自定的，而不是通过已有构件组装而成的。5.软件成本相当昂贵。IBM360研制人员最多时可达1000多人，耗时四年，费用为5亿美元。Vista 耗时近六年，费用60亿美元。 6.软件本身是复杂的。软件比任何其他人类制造的结构更复杂，这使得软件产品难以理解和维护。第20页/共121页软件危机软件危机爆发于20世纪60年代末期，至今依然困绕着我们，软件危机的具体表现如下：1. 软件开发的进度难以控制，经常出现经费超预算、完成期限一

7、再拖延的现象。2. 软件需求在开发初期不明确，导致矛盾在后期集中暴露，从而对整个开发过程带来灾难性的后果。3. 由于缺乏完整规范的资料，加之软件测试不充分，从而造成软件质量低下，运行中出现大量问题。第21页/共121页软件工程的概念 1983年，IEEE的定义：软件工程 是研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件，即把工程化应用到软件上。 第22页/共121页 一个软件产品从形成概念开始，经过开发、测试、使用和维护，直到最后退出使用的全过程称为软件生存周期。 软件生存周期根据软件所处的状态，以及软件开发活动的目的和任务，可划分为若干个阶段。一般软件生存周期包括软件定

8、义、软件开发、软件测试、软件使用与维护等几个部分。1.1.21.1.2软件工程的目标及其一般开发过程 第23页/共121页软件生存周期 软件生存周期是指软件产品从考虑其概念开始到该软件产品交付使用，直至最终退役为止的整个过程，一般包括：1. 计划2. 分析3. 设计4. 实现5. 测试6. 运行与维护第24页/共121页 可行性分析的任务是了解用户的要求及实现环境，从技术、经济和社会等几个方面研究并论证软件系统的可行性。 需求分析的任务是确定所要开发软件的功能需求、性能需求和运行环境约束，编制软件需求规格说明、软件系统的确认测试准则。软件的性能需求包括软件的适应性、安全性、可靠性、可维护性错误

9、处理等。 1软件定义第25页/共121页 软件开发是按照需求规格说明的要求，由抽象到具体，逐步生成软件的过程。软件开发一般由设计、实现和测试等阶段组成。 2软件开发第26页/共121页 软件需经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。 整个测试过程分单元测试、集成测试、系统测试以及验收测试四个阶段进行。 测试的方法主要有白盒测试和黑盒测试。3软件测试第27页/共121页 软件的使用是在软件通过测试后，将软件安装在用户确定的运行环境中移交给用户使用。软件的维护是对软件系统进行修改或对软件需求变化做出反应的过程。 4软件使用和维护第28页/共121页软件开发过程中存在各种复杂

10、因素，为了解决由此而带来的种种问题，软件开发者们经过多年的摸索，给出了多种实现软件工程的方式软件过程模型，如瀑布过程模型、螺旋过程模型和增量过程模型等。 1.1.3 可供选择的可供选择的软件过程模型软件过程模型第29页/共121页 瀑布过程模型反映了人们早期对软件工程的认识水平，是人们所熟悉的一种线性思维的体现。 瀑布过程模型强调阶段的划分及其顺序性、各阶段工作及其文档的完备性，是一种严格线性的、按阶段顺序的、逐步细化的开发模式，如图1-1所示。 1瀑布过程模型第30页/共121页软件开发模型软件开发模型o 大棒模式大棒模式o 边写边改模式边写边改模式o 流水模式（瀑布模式）流水模式（瀑布模式

11、）o 螺旋过程模式螺旋过程模式o 增量过程模式增量过程模式o 快速原型过程模式快速原型过程模式第31页/共121页边做边改模型 （Build-and-Fix Model）在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改，如图所示：第32页/共121页图1-1 瀑布过程模型 第33页/共121页 螺旋过程模型的基本思路是，依据前一个版本的结果构造新的版本，这个不断重复迭代的过程形成了一个螺旋上升的路径，如图1-2所示。2螺旋过程模型第34页/共121页图1-2 螺旋过程模型 第35页/共121页 有些时候可能会用一种几乎连续的过程小幅度地推进项目，这就是增量

12、过程模型，如图1-3所示。 3增量过程模型第36页/共121页 增量 日历时间 分析 编码 测试 增量 1 交付客户 设计 分析 设 计 编码 测试 增量 2 交付客户 分析 设计 编码 测试 增量 3 交付客户 分析 设计 编码 测试 增量 n 交付客户 图1-3 增量过程模型 第37页/共121页o 快速原型过程模型首先是快速进行系统分析，在设计人员和用户的紧密配合下，快速确定软件系统的基本要求，尽快实现一个可运行的、功能简单的原型系统，然后通过对原型系统逐步求精，不断扩充完善得到最终的软件系统。4快速原型过程模型第38页/共121页1.2 软件缺陷与软件故障 1. 什么是软件缺陷和软件故

13、障 软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。 软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态，此时若无适当措施(容错)加以及时处理，便产生软件失效。第39页/共121页2. 软件缺陷和软件故障案例1.美国迪斯尼公司狮子王游戏软件兼容性问题2.美国航天局火星登陆事故3.跨世纪“千年虫”问题4.爱国者导弹防御系统5.“冲击波”计算机病毒6.Windows2000中文输入法漏洞7.金山词霸出现的错误第40页/共121页软件缺陷产生的原因第41页/共121页软件缺陷的修复费用￥1￥10

14、￥100￥1000+费用开发阶段说明书设计编码测试发布第42页/共121页 软件复杂性 交流不够、交流上有误解或者根本不进行交流 程序设计错误 需求变化 时间压力 代码文档贫乏 软件开发工具3.软件产生错误的原因第43页/共121页1.3 软件质量与质量模型 软件质量是软件的生命，它直接影响软件的使用与维护。 通常软件质量由以下几方面进行评价。第44页/共121页 软件需求是衡量软件质量的基础，不符合需求的软件就不具备质量。设计的软件应在功能、性能等方面都符合要求，并能可靠地运行。 软件结构良好，易读、易于理解，并易于修改、维护。 软件系统具有友好的用户界面，便于用户使用。 软件生存周期中各阶

15、段文档齐全、规范，便于配置、管理。第45页/共121页 软件的质量因素很多，如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等。 软件质量因素也称为软件质量特性，反映了质量的本质。讨论一个软件的质量，问题最终要归结到定义软件的质量特性。第46页/共121页 面对众多的质量因素如何取折衷，这实际上就是区分质量因素对软件质量影响程度轻重的问题，这个问题已经有了解决方案，即软件质量模型。 图1-4所示为McCall软件质量模型，质量模型中的质量概念基于11个特性之上，这11个特性分别面向软件产品的运行、修正、转移。第47页/共121页图1-4 McC

16、all质量模型第48页/共121页 图1-5所示为ISO/IEC 91261991标准规定的软件质量度量模型。它由3层组成，其中第1层称为质量特性，第2层称为质量子特性，第3层称为度量。 第49页/共121页软件质量 质量特性 质量子特性 度量 功能性 适合性 准确性 互操作性 依从性 安全性 可靠性 成熟性 容错性 易恢复性 可使用性 易理解性 易学习性 易操作性 效率 时间特性 资源特性 可维护性 易分析性 稳定性 易变更性 易测试性 可移植性 适应性 易安装性 遵循性 易替换性 度 量 由 使 用 单 位 自 行 决 定 图1-5 ISO软件质量度量模型 第50页/共121页 图1-6所

17、示为新的ISO/IEC 9126软件质量模型，软件质量包括“内部质量”、“外部质量”和“使用质量”三部分。图1-6 新的ISO/IEC 9126软件质量模型第51页/共121页 所谓的内部质量是从内部观点出发的软件产品特性的总体，是针对内部质量需求被测量和评价的质量。 内部质量特征主要包括：可维护性、灵活性、可移植性、可重用性、可读性、可测试性、可理解性。第52页/共121页 外部质量的定义是：软件产品在规定条件下使用时满足需求的程度。外部质量是从外部观点出发的软件产品特性的总体，它是当软件执行时，更典型地是使用外部度量在模拟环境中，用模拟数据测试时，所被测量和评价的质量，即在预定的系统环境中

18、运行时可能达到的质量水平。 外部质量特征主要包括：正确性、可用性、效率、可靠性、完整性、适应性、精确性、坚固性。 第53页/共121页 使用质量的定义是：在规定的使用环境下软件产品使特定用户在达到规定目标方面的能力。它是从用户观点出发，来看待软件产品用于特定环境和条件下的质量，反映的是从用户角度看到的软件产品在适当系统环境下满足其需求的程度。 使用质量用以下质量特征表述:有效性、生产率、安全性、满意程度等。第54页/共121页1.4 软 件 测 试 1.4.1软件测试的定义及目的 简单地说，软件测试就是为了发现错误而执行程序的过程。 第55页/共121页 在IEEE提出的软件工程标准术语中，软

19、件测试被定义为：“使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别。” 软件测试是与软件质量密切联系在一起的，归根结底，软件测试是为了保证软件质量。 第56页/共121页 软件测试是一个找错的过程。软件测试的过程亦是程序运行的过程。程序运行需要数据，为测试设计的数据称为测试用例。测试用例的设计原则是尽可能暴露程序中的错误。第57页/共121页 软件是由人来完成的，所有由人做的工作都不会是完美无缺的。软件开发是个很复杂的过程，期间很容易产生错误。无论是软件从业人员、专家和学者做了多大的努力，软件错误仍然存在。因而大家也得到了一种

20、共识：软件中残存着错误，这是软件的一种属性，是无法改变的。所以通常说软件测试的目的就是为了发现尽可能多的缺陷，并期望通过改错来把缺陷统统消灭，以期提高软件的质量。一个成功的测试用例在于发现了至今尚未发现的缺陷。第58页/共121页 软件测试的目的是以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。 第59页/共121页1.4.2 软件测试的原则 o 1.所有的测试都应追溯到用户需求o 2.把“尽早和不断地测试”作为开发者的座右铭o 3.程序员应该避免检查自己的程序，测试工作应该由独立的专

21、业的软件测试机构来完成o 4.pareto原则o 5.设计测试用例时，应该考虑各种情况第60页/共121页o 6.对测试错误结果一定要有一个确认的过程o 7.制定严格的测试计划o 8.完全测试是不可能的，测试需要终止o 9.注意回归测试的关联性o 10.妥善保存一切测试过程文档第61页/共121页 不可能对程序进行完全测试 无法显示潜伏的软件缺陷 软件测试的风险 难以描述的软件缺陷 产品说明书不断变化 杀虫剂现象 软件缺陷不能得到修复第62页/共121页不可能对程序进行完全测试 输入量太大 输出结果太多 软件实现途径太多 软件说明没有客观标准第63页/共121页不可能测试到程序对任何可能输入的

22、响应要对所有有效的输入进行响应要对所有无效的输入进行测试要对所有编辑过的输入进行测试要对所有输入时机的变化进行测试第64页/共121页要对所有有效的输入进行响应以一个完成两个一位或两位数相加的小程序为例有效输入数对：199*199=39601 第65页/共121页要对所有无效的输入进行测试字母，控制字符，数字与字母组合过长的数，问号等所有能敲得出来的第66页/共121页要对所有编辑过的输入进行测试 如果允许对数据进行编辑确保能够将每一个数，字母或别的任何东西修改成其他任何数 检验重复的编辑操作，系统是否会崩溃第67页/共121页要对所有输入时机的变化进行测试 要对任何时间点上往程序中输入数据时

23、产生的效果进行测试（不是在要求输入时才输入） 在系统忙时输入 敲特殊键第68页/共121页不可能测试到程序每一条可能的执行路径 程序路径可以通过在代码中从程序开始到结束进行跟踪第69页/共121页路径测试举例电话接线1（空闲）2（响铃）2（响铃）3（接通）5（挂机-断线）3（接通）4（保持通话）5（挂机-断线）4（在线）5（挂机-断线）6（等待信号）第70页/共121页执行的路径 在线等待存储到“堆栈”(接通)取出删除 电话空闲清空堆栈以防某一操作忘记清除自身信息 例外：在线等待挂断消息未删除挂断次数30次堆栈发生溢出接线员电话停止服务第71页/共121页无法找出所有的设计错误 如果一个程序能

24、够准确地实现规格说明的要求，不再做其他任何事情，程序就是符合规格说明的 规格说明本身包含着错误 如：2+2=5第72页/共121页不能采用逻辑来证明程序的正确性 计算机根据逻辑规则进行操作，程序是以精确语言来表达的。如果程序组织得好，你就能够判断程序在不同条件下的状态，并能够通过跟踪程序的逻辑结构来证明这些判断是正确的。 这样仅能确认程序内部的一致性。第73页/共121页软件测试是有风险的行为 无法完全测试，就是选择了风险 每一个软件项目都有一个最优的测试优化测试量优化测试量测试费用测试费用遗漏软件遗漏软件缺陷数目缺陷数目测试前测试前测试后测试后测试工作量测试工作量数量数量第74页/共121页

25、测试无法显示潜在的软件缺陷 软件测试可以报告已经发现的软件缺陷，却无法报告潜伏的软件缺陷 唯一的方法是继续测试，尽可能找到新的错误第75页/共121页软件缺陷越找越多 软件缺陷有聚集或集中的特点，找到一个就有可能找到一群。 原因如下： 程序员怠倦 程序员往往犯同样的错误 某些软件缺陷其实上是大灾难的灾难第76页/共121页杀虫剂现象 软件测试要经过多个测试周期，该发现的软件缺陷都被发现了，在测试下去也不会有新的发现了 解决方法就是不断编写新的不同的测试用例庄稼害虫农药抗药性软件BUG测试？第77页/共121页并非所有的软件缺陷都能修复 没有足够的时间 不算是真正的软件缺陷 修复的风险太大 不值

26、得修复第78页/共121页难以说清的软件缺陷 软件的缺陷没有人发现 判断是否为软件缺陷的依据就是软件缺陷的定义第79页/共121页 软件测试过程模型是对测试过程一种抽象，用于定义软件测试的流程和方法。 随着测试过程管理的发展，软件测试专家通过实践总结出了很多很好的测试过程模型。这些模型将测试活动进行了抽象，并与开发活动有机的进行了结合，是测试过程管理的重要参考依据。1.4.3 1.4.3 软件测试模型第80页/共121页o V模型是最具有代表意义的测试模型 ，反映出了测试活动与分析设计活动的关系。o V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能

27、的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。1 1模型第81页/共121页图1-7 软件测试V模型第82页/共121页2模型o W模型由两个V字型模型组成，分别代表测试与开发过程。o W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。第83页/共121页图1-8 软件测试W模型第84页/共121页3模型o H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。o H模型揭示了软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程

28、并发地进行。第85页/共121页图1-9 软件测试H模型第86页/共121页4其他模型o 除上述几种常见模型外，还流传着其他几种模型，例如X模型、前置测试模型等。o X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最综合成为可执行的程序。o 前置测试模型体现了开发与测试的结合，要求对每一个交付内容进行测试。第87页/共121页1.4.4 1.4.4 软件测试的分类o 1按测试方式分类o 静态测试o 动态测试o 2按测试方法分类按测试方法分类o 白盒测试o 黑盒测试第88页/共121页3按测试过程分类o 单元测试o 集成测试o 系统测试o 验收测试第89页/共1

29、21页4按测试目的分类o 功能测试o 健壮性测试o 接口测试o 性能测试o 强度测试o 压力测试o 用户界面测试o 安全测试o 可靠性测试o 安装/反安装测试o 文档测试o 恢复测试o 兼容性测试第90页/共121页1.4.5 软件测试流程1.制订测试计划2.测试设计3.测试准备和建立环境4.执行测试5.测试评估6.测试总结第91页/共121页1.4.6 1.4.6 软件测试发展历程和趋势 在早期的软件开发过程中，测试的含义比较窄，将测试等同于“调试”。 直到1957年，软件测试才开始与调试区别开来，成为一种发现软件缺陷的活动。 直到20世纪80年代早期，软件测试不再单纯是一个发现错误的过程，

30、而且包含软件质量评价的内容。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。第92页/共121页1.4.6 1.4.6 软件测试发展历程和趋势 20世纪90年代，测试工具终于盛行起来。到了2002年，Rich和Stefan在系统的软件测试一书中对软件测试做了进一步定义：“测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程”。这些经典论著对软件测试研究的理论化和体系化产生了巨大的影响。 近20年来，随着计算机和软件技术的飞速发展，软件测试技术的研究也取得了很大的突破第93页/共121页1.5 1.5 软件测试人员的基本素质软件测试人员应具备下列基本

31、素质：1具有良好的计算机编程基础2具有创新精神和超前意识3不懈努力，追求完美4具有很强的沟通和交流能力5具有整体观念，对细节敏感6团队合作精神第94页/共121页一个样例测试系列 假设程序及其描述 将输入的两个数相加，每个数包含一位或两位数字，程序对输入产生回应，并打印相加的结果。每输入一个数后，按键；要运行程序，键入ADDER。第95页/共121页第一个测试周期第96页/共121页第一步从一个显而易见的简单测试开始仅把2和3相加第97页/共121页你所做的系统的反应输入ADDER并按下屏幕空白。在屏幕顶部看到一个问号输入2在问号后出现2按下在下一行出现一个问号按下3在第二个问号后出现3按下在

32、第三行出现5。在其下两行出现另一个问号第98页/共121页第一次测试后屏幕的显示？2？35？第99页/共121页第一次测试后测试的问题报告尽管2+3=运行正确但仍有问题 设计错误：没有说明这是什么程序。如何得知采用的是正确的程序呢？ 设计错误：没有任何屏幕提示。如何得知将要做什么？如果输入一个错误的数字会怎样？提示应当在屏幕的显著位置显示，如简短的指令指示一样。第100页/共121页第一次测试后测试的问题报告 设计错误：怎样终止程序的运行？有关的提示也应当显示在屏幕上 编码错误：相加的和5没有与其他显示的数字排出一列。注：为每个错误提交一个问题报告第101页/共121页第二步 对还需要测试什么

33、做一些记录测试用例预期结果注释99+99198程序能相加的最大树对-99+-99-198规格说明并没有规定不能用负数99+-1485一个较大的被加数可能影响程序对加数的解释 -38+9961检验一个负数与正数相加5+99104一个较大的加数可能影响程序对被加数的解释9+9189是最大的一位数0+00程序在0上常失败0+2323程序将0看作一个特殊情况 -78+0-780应当作为被加数和加数进行测试第102页/共121页测试用例预期结果注释99+99198程序能相加的最大树对-99+-99-198规格说明并没有规定不能用负数99+-1485一个较大的被加数可能影响程序对加数的解释 -38+996

34、1检验一个负数与正数相加5+99104一个较大的加数可能影响程序对被加数的解释9+9189是最大的一位数0+00程序在0上常失败0+2323程序将0看作一个特殊情况 -78+0-780应当作为被加数和加数进行测试第103页/共121页寻找边界条件 如果预计两个测试 具有相同的结果，那么只用一个就行了 在选择一类测试的代表用例时，总选择那些认为程序最有可能失败的用例。规则 最佳测试：总在一类测试的边界处 ，一旦超出边界，程序的运行将发生变化 边界设定：非故意设定、不正确、绝大部分的缺陷所在和程序运行行为改变的地方 通过经验、阅读代码分析出边界，并在边界两侧都进行测试第104页/共121页第三步检查有效用例并观察发生了什么第105页/共121页测试结果 正数工作正常 0也工作正常 使用负数的测试都不能正常工作 输入第二位数字时宕机第106页/共121页第四步做一些“快速的”测试第107页/共121页 凭直觉，不停的测试 正式、非正式的测试 可能的结果：意外发现错误，系统崩溃 注意：为每次测试