完整课件-软件测试技术.ppt

1、软件测试技术授课：孔春波 软件的缺陷-BUG恐怖的BUG恐怖的BUG 千年虫问题.爱国者导弹防御系统.火星登陆事故.高铁的自动闭塞系统.软件测试的发展国内测试行业现状11%38%51%独立设置软件测试部门的调查独立设置软件测试部门的调查有专门的测试工具开发部门有专门的测试技术研究部门没有专门的测试技术部门国内测试行业现状1:19%1:215%1:320%1:412%1:5以上17%无测试人员27%测试人员与开发人员比例测试人员与开发人员比例测试人员现状 基础知识不够扎实 专业技术不够精通 没有建立起相对完整的测试体系概念国内软件测试未来发展 职业重视程度正在快速提高 企业对高质量的测试工程师需

2、求量越来越大 短期将出现测试工程师严重短缺的现象技术要求 腾讯技术要求 腾讯技术要求 百度技术要求 迅雷测试人员要掌握的技术 1.系统编程语言：C/C+,JAVA，C#.2.脚本语言：PERL,RUBY,PYTHON 3.软件架构,UML 4.数据库 5.网络协议，操作系统 6.人机交互认知 编写文档的能力 测试技术 测试工具课程目标本课程是计算机或软件专业课程，重在培养我们的实践能力，适应软件企业的工作环境和业界标准，并和国际先进的软件开发理念和测试技术保持同步。通过本课程的学习，了解并掌握软件产品质量保证的基本思想和科学体系、软件测试技术的基本内容，以及软件测试的方法、技术和工具的使用，为

3、全面掌握软件技术和软件项目管理打下坚实的基础 课程内容有效的测试策略、方法和技术测试计划和测试用例的设计测试自动化的引入、应用 测试团队的建立和测试项目的管理更清楚、准确地报告测试缺陷 对软件产品质量的正确评估软件测试和质量保证的关系和区别 课程培养方向-测试工程师 Test engineer-QA工程师/经理 QA Engineer/Manager-软件工程过程组成员 The member of SEPG-项目经理 Project manager-程序员 Programmer-软件分析师 Software Analyst-软件咨询顾问 Software Consultant-授课的层次 Kn

4、ow What 某领域基本知识点的掌握 Know How 可以活用学到的知识来解决实际问题 Know Why 了解各种知识之后的复杂交错的因果关系，一切都是那么有条理，因此可能解决更大更复杂的问题 Care Why(创新)软件产品也需要创意和洞察先机我们短期努力 可以达到Know Why的阶段 Case Why（创新）则需要多年的实际开发经验并具有敏锐的市场商业头脑才能做到。参考书籍n 软件测试Ron Patton 机械工业出版社n 软件测试教程 宫云战 机械工业出版社 联系方式 电子邮件： 移动电话：13607483030你相信你能或者不能你都是对的软件测试综述内容 软件概念和特点 软件危机

5、 软件测试的产生 软件测试的定义 软件测试的发展和前景软件的概念 GB/T 17544-1998：信息处理系统的所有或部分程序、规程、规则和任何相关的文档的集合 程序：源程序目标程序 源程序：高级语言、汇编语言编写的程序 目标程序：源程序经编译或解释加工以后可以由计算机直接执行的程序 文档：用自然语言或形式化语言所编写的文字资料和图表，用来描述程序的内容、组成、设计、功能规格、开发情况、测试结果及使用方法软件的特点 计算机软件是工具，同时也是作品，是工具性与作品性紧密结合的智力成果 计算机软件开发工作量大，成本高，但复制容易，成本极低 计算机软件具有无形性，可以多次使用，但商业寿命较短软件危机

6、 落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象 如何开发软件，怎样满足对软件日益增长的需求 如何维护数量不断膨胀的已有软件 软件危机的表现 对软件开发成本和进度的估计很不准确 成本高，进度拖延信誉低 赶进度，节约成本质量低 用户对“已完成的”软件系统不满意 对用户需求模糊，匆忙开始，开发和用户交流不充分 软件产品质量常常靠不住 软件质量保证刚出现，质保技术刚应用，没有坚持贯彻软件危机的表现 软件常常不可维护 错误难改正，程序难适应新硬件环境，难新增功能 软件通常没有适当的文档资料 软件成本在计算机系统成本中所占比例逐年上升 硬件成本降

7、低，开发人力增加，通货膨胀，软件规模增大，数量急剧增加，软件成本占系统成本90软件危机产生的原因 软件本身存在着复杂性 与软件开发人员和所使用的方法、技术有关科学技术发展计算机广泛应用要求软件跟上开发大型软件软件技术发展复杂程度高研发周期长正确性难以保证软件危机软件测试的发展软件测试的产生软件危机能够解决吗？没有银弹！软件测试的产生 社会的发展与进步，信息化产业的飞步增长，软件系统越来越大，软件中存在的问题也越来越多软件测试的产生 需要第三方平衡开发人员和用户 技术员：用什么技术实现需求、展现自己的实力、不关心对用户使用有什么弊端 用户：是否满足需求、是否易用、不关心开发人员用什么难度技术实现

8、三个角度看测试 公司经济角度 以最少人力，物力和时间找出软件中潜在的各种错误和缺陷 通过修正各种错误和缺陷提高软件质量 回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险三个角度看测试 客户角度 是以评价一个程序或者系统属性为目标的活动 对软件质量的度量与评估，以验证软件的质量满足用户的需求的程度 为用户选择与接受软件提供有力的依据三个角度看测试 开发技术角度 通过分析错误产生的原因，可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进 通过对测试结果的分析整理，可以修正软件开发规则，为软件可靠性分析提供依据软件测试的定义 1979年，Glenford Myers

9、，The Art of Software Testing：为了发现错误而执行程序或者系统的过程 1980年，在美国俄勒冈计算机会议上软件测试被正式确认为软件工程的一部分软件测试的定义 1983年，Bill Hetzel在软件测试完全指南(Complete Guide of Software Testing)一书中指出：测试是以评价一个程序或者系统属性为目标的任何一种活动 1983年，IEEE软件工程标准术语：使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别软件缺陷的定义 缺陷缺陷 软件未达到产品说明书中已标明的功能软件未达到产

10、品说明书中已标明的功能 软件出现了产品说明书中指明不会出现的错误软件出现了产品说明书中指明不会出现的错误 软件功能超出了产品说明书指明的范围软件功能超出了产品说明书指明的范围 软件未达到产品说明书虽未指出但应达到的目软件未达到产品说明书虽未指出但应达到的目标标 软件测试员认为软件难以理解，不易使用，运软件测试员认为软件难以理解，不易使用，运行速度缓慢，或者最终用户认为该软件使用效行速度缓慢，或者最终用户认为该软件使用效果不好果不好测试与调试的区别测试调试完成任务发现程序中的缺陷定位并且解决程序中的问题执行人测试人员 黑盒单元、集成测试 开发人员执行周期贯穿整个软件开发生命周期一般在开发阶段软件

11、测试过程及分类本节内容 测试过程 测试的分类 按测试的方法分类 按测试的阶段分类软件测试的过程测试需求的分析和确定测试计划测试执行测试记录和缺陷跟踪回归测试测试总结报告测试过程 1.测试需求 需求文档的测试测试过程 2.测试的计划 对测试过程的整体设计 确定测试范围 制定测试策略 安排测试资源 进度制定 风险评估，应对策略测试过程 3.测试设计及用例 测试设计 用例设计 用例评估测试过程 4.测试的执行 用例的选择（难的？复杂的？优先级高的？）测试环境的搭建 每日构建测试过程 5.测试的记录和跟踪 Bug记录 Bug管理 Bug的报告（沟通，评审，提交)Bug的跟踪测试过程 5.回归测试 再测

12、一次？测试过程 6.测试总结和报告 缺陷的分类报告（类型，区域，状态，趋势）客观全面的报告生成（人员，用例，功能覆盖，时长）经验总结软件测试的分类-按方法 静态与动态测试 静态测试不运行程序 动态测试运行程序，需要准备测试数据软件测试的分类-按方法 黑盒测试、白盒测试、灰盒测试y=2x？y=x2软件测试的分类-按方法 冒烟测试 对每一个新编译的需要正式测试的软件版本，确认软件基本功能正常，可以进行后续的正式测试工作 回归测试 在修改程序以后，重新测试先前的测试以保证修改的正确性软件测试的分类-按方法 功能测试与性能测试 根据软件产品特性、操作描述和用户方案测试软件产品的特性和可操作行为以确定满

13、足设计需求 评价软件产品与性能需求是否符合（包括负载测试、强度测试、数据库容量测试、基准测试等）软件测试的分类-按方法 压力测试和负载测试 获取系统正确运行的极限，检查系统在瞬间峰值负荷下正确执行的能力 用于检查系统在使用大量数据的时候正确工作的能力，即检验系统的能力最高到什么程度 负载测试是通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力软件测试的分类-按方法 配置测试 检查计算机系统内各个设备或各种资源之间的相互连接和功能分配中的错误 文档测试 检查文档的正确性、完备性、可理解性 兼容性测试 测试软件是否和系统的其他与之交互的元素之间兼容软件测试的分类-按方法

14、安全性测试 检查系统对非法侵入的防范能力，检查系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞 恢复测试 检查系统的容错能力 可移植性测试 测试软件是否可以被成功移植到指定的硬件或软件平台上软件测试的分类-按方法 引导测试 软件开发中，验证系统在真实硬件和客户基础上处理典型操作的能力 外包测试中，是客户检查软件测试公司测试能力的一种形式 随机测试 没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试软件测试的分类-按方法 手工和自动测试 手工测试是采用人工手动的方式执行测试 自动化测试是使用自动化测试工具来进行测试，不需要人工干预，主要用在GUI、性能等测试中 通过测试失败测

15、试 使用满足不满足需求的数据测试系统 错误猜测 通过直觉发现程序中的错误和缺陷的能力软件测试的分类-按方法 易用性测试 主要从使用的合理性和方便性等角度对软件系统进行检查 安装测试 确保软件在正常情况和异常情况的不同条件下都能进行安装 界面测试 测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字图片组合是否完美，操作是否有好软件测试的分类-按阶段 单元测试 针对每一个程序模块进行正确性检查，检查各个程序模块是否正确的实现了规定的功能 集成测试 在单元测试的基础上将已经通过测试的单元模块按照设计要求组装成系统或子系统进行测试，找出被测系统组件之间关系和接口中的错误 非增式集成

16、增式集成 自顶向下 自底向上软件测试的分类-按阶段 确认测试 由集成测试进入系统测试之前，需要对软件是否可以进入系统测试进行评价，这个称为确认测试 测试所开发的软件是否能按用户提出的要求运行 软件配置审核保证软件配置的所有成分都齐全，各方面质量都符合要求 系统测试 与计算机硬件、外设、支持软件、数据、人员等其他元素结合，在实际运行环境下的测试软件测试的分类-按阶段 验收测试验收测试 测试测试内测内测 测试测试公测公测共享资源 公共邮箱： 6dao16 课件,笔记会放在邮箱的网盘中 作业,实验报告按班级打包以邮件方式发送到这个邮箱软件测试的目的和原则目的 建立软件的信心理件软件测试目的 验证（V

17、erfication）：软件生命周期的各个阶段，用下一个阶段的产品来检查是否满足上一个阶段的规则 确认(Validation)：软件生命周期的各个阶段，检查是否满足需求阶段定义的各项规格和要求。原则 Good Enough原则：投入与产出平衡 Pareto原则：二八原则 尽可能早的开展测试 错误多的地方多投入 同化问题：交叉测试，利用不同人的观点问题:软件测试的目的？软件测试是否发现所有的BUG？测试人员在进行测试的时候遵循什么原则？软件测试开始的时间？软件测试的过程测试需求的分析和确定测试计划测试执行测试记录和缺陷跟踪回归测试测试总结报告测试需求对需求文档的测试或评审 需求的测试是重点需求5

18、6%设计27%编码10%其他7%缺陷比例缺陷比例需求可能存在的问题 需求文档编写有问题、功能不明确，流程不清晰，不正确占50%余下50%是需求的遗漏造成的检查的要点对于需求文档，应该遵循尽早测试的原则完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。正确性：每一项需求都必须准确地陈述其要开发的功能。一致性：一致性是指与其它软件需求或高层(系统，业务)需求不相矛盾。可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简

19、洁明了的用户性的语言表达出来。健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好(f

20、i n e-g r a i n e d)的方式编写并单独标明，而不是大段大段的叙述。另外应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度需求文档检查步骤尝试理解需求规格说明书原始需求文档检查列表讨论、评审、修订需求文档检查列表序号 检查项检查结果说明1是否覆盖了用户提出的所有需求项是否NA 2用词是否清晰，语义是否存在有歧义的地方是否NA 3是否清楚地描述了软件系统需要做什么及不做什么是否NA 4是否描术了软件使用的目标环境，包括软硬件环境是否NA 5是否对需求项进行了合理的编号是否NA 6需求项是否前后一致，彼此不冲突是否N

21、A 7是否清楚说明了系统的每个输入、输出的格式，以及输入输出之间的对应关系是否NA 8是否清晰描述了软件系统的性能要求是否NA 9需求的优先级是否合理分配是否NA 10是否描述了各种约束条件是否NA 编写测试用例需求规格说明书测试用例虚拟软件产品测试人员开发人员“预演”测试测试用例编号：Input_001测试优先级：中测试目的：验证业务单据数据的查询正确性标题：业务单据查询步骤：1.打开查询界面 2.输入查询条件 3.确定并提交查询 4.查看并验证返回的信息还有.除了文档检查和测试用例外，可以通过用户调查和利用现存产品对需求进行测试一些技术建议 熟悉UML 测试前了解软件系统对应的行业 多熟悉

22、需求:温伯格的探索需求设计前的质量 Exploring Requirements:Quality Before Design 测试计划的编写 测试用例设计的方法软件测试的过程测试需求的分析和确定测试计划测试执行测试记录和缺陷跟踪回归测试测试总结报告测试计划制定可行的计划 凡是预则立，不预则废项目的关键项目成功的四大要素时间成本范围质量测试计划的作用 内部作用：作为测试计划的结果，让相关人员和开发人员来评审 存储计划执行的细节，让测试人员进行评审 存储计划进度表，测试环境等更多的信息 外部作用：给顾客信心 交待测试过程，人员，资源，使用工具测试计划的设计与实现取得需求文档取得需求文档确定测试策略

23、确定测试策略确定测试系统确定测试系统测试设计和实现测试设计和实现复查测试计划复查测试计划预估测试工作量预估测试工作量需求规格说明书1.测试的范围（将要测试什么）2.测试方法（如何完成测试）3.测试入口/退出条件和质量检查点4.自动化策略1.测试构架2.测试环境3.测试配置1.确定任务2.预估工作量3.确定时间进度计划1.编写策略、系统、工作量和时间进度文档2.与项目团队一起复查测试计划IEEE定义的测试计划 测试计划：一个叙述了预定的测试活动范围、途径、资源及进度安排的文档。它确定了测试项、被测特征、测试任务、人员安排以及与计划相关的风险。三要素：时间 资源 范围 其他方面 策略 风险控制测试

24、计划内容 5-1 确定测试范围 5-2 制定测试策略 5-3 测试资源安排 5-4 进度及安排 5-5 风险及对策5-1确定测试范围 明确哪些要测，哪些不要测，比如大部分软件系统不需要测硬件 不要忽略了用户手册，安装包，数据库等信息，这些也决定产品好坏 某些阶段的测试或者某些内容的测试可以简化 当对原有系统进行修改升级时，某些测试不需要 某些测试根本不可能进行5-2 制定测试策略测试策略（1/4）确定测试顺序 先测优先级最高的需求 对新功能和修改功能的代码进行测试 运用等价划分技术和边界值分析技术减少测试工作量 测试那些最有可能出现问题的地方 关注用户最常使用的功能和配置情况等测试策略（2/4

25、）确定测试方法对需求文档进行静态测试，主要采用审查走查的方法验证需求的完整性、一致性可行性需求分析阶段白盒测试方法由程序员完成编码和单元测试阶段黑盒测试方法设计用例时注意等价划分和边界值方法集成测试阶段黑盒测试方法测试工具，进行自动化测试，包括系统的功能和性能测试系统测试阶段动态、黑盒测试方法由用户来进行验收测试阶段测试策略（3/4）测试标准 入口标准：描述在开始之前需要做哪些工作 出口标准：描述在怎样的情况下可以结束测试 暂停/继续测试：描述如果缺陷妨碍测试进行下去，会发生什么事情。如果情况很糟，无法执行计划的测试，则应暂停测试，等完成修复工作后，再完成测试工作。通过/失败标准 执行每项测试

26、应该有一个明确的预期结果。如果得到了预期的结果，测试就通过。否则表示测试失败。测试策略（4/4）自动化测试工具的选择 是否使用自动化测试工具，哪个阶段用什么工具 好处：能够很好进行性能测试和压力测试 能够改进回归测试 能够缩短测试周期 能够提高测试工作的课重复性 测试软件的编写5-3 安排好测试资源 根椐测试对象的复杂度、质量要求，结合经验数据对测试工作量进行评估 注意：每个测试项最好安排不少于两人，以便交叉测试5-4 安排测试进度5-5 计划风险 项目计划变更、测试资源不能到位可能产生风险 实际操作时的建议：建立后备机制，让后备测试人员参与项目例会，评审，培训，交流等活动复查测试文档 详细描

27、述工作的范围 估计定义测试用例和实施测试所需工作 确定所需资源（人、硬件、软件和工具）为各个人物分配资源 制定进度表 确定进度安排或质量风险 制定解决风险的应急计划 追踪项目进展并采取纠正措施 在适当的时候重新定制 向整个项目提供测试状态的可视性 对失败或堵塞测试纠正后重新测试 测试计划是一份描述软件测试工作的目标、策略、方法和重点的文档 测试计划的准备过程是思考检查并确认一个软件产品的可接受性的一个有用的方法测试计划测试计划文档测试计划的目的尽早地明确测试工作内容（范围）、测试工作的方法以及测试工作所需要的各种资源。所有涉及到测试工作的人员，尽快将下一步测试工作需要考虑的问题和准备的条件落实

28、。测试计划工作的重点在于：对当前工作任务的准备和规划以及信息的交流。增强测试计划的实用性 坚持“5W1H”规则，明确内容与过程 采用评审和更新机制，保证测试计划满足实际需求 测试计划和测试策略测试计划注意事项测试计划编写6要素？（5W1H）为什么要进行这些测试为什么要进行这些测试相应文档，缺陷的存放位置，测试环境等相应文档，缺陷的存放位置，测试环境等测试不同阶段的起止时间测试不同阶段的起止时间测试哪些方面，不同阶段的工作内容测试哪些方面，不同阶段的工作内容项目有关人员组成，安排哪些测试人员进行测试项目有关人员组成，安排哪些测试人员进行测试如何去做，使用哪些测试工具以及测试方法进行测试如何去做，

29、使用哪些测试工具以及测试方法进行测试测试的设计及测试用例测试用例的作用 交付给顾客的产品一部分，提高产品可信度 做内部使用，在代码未完成前，准备好，在代码开发或结束后可以快速投入测试基于需求的测试用例设计 验证需求是否正确，完整性，无二义性，并且逻辑一致 从“黑盒”角度设计出充分并且必要的测试集 基于需求的测试需要工具支持，比如QC（QualityCenter）测试用例设计 等价类划分法 边界值分析法 基本路径分析法 因果图法 场景设计法 错误猜测试 正交分解法测试的设计及测试用例黑盒测试用例的设计测试用例的作用 交付给顾客的产品一部分，提高产品可信度 做内部使用，在代码未完成前，准备好，在代

30、码开发或结束后可以快速投入测试基于需求的测试用例设计 验证需求是否正确，完整性，无二义性，并且逻辑一致 从“黑盒”角度设计出充分并且必要的测试集 基于需求的测试需要工具支持，比如QC（QualityCenter）测试用例设计 等价类划分法 边界值分析法 因果图法 基本路径分析法 场景设计法 错误猜测试 正交分解法.黑盒测试的基本概念 黑盒测试是从一种从软件外部对软件实施的测试，也称功能测试或基于规格说明的测试。其基本观点是：任何程序都可以看作是从输入定义域到输出值域的映射，这种观点将被测程序看作一个打不开的黑盒，黑盒里面的内容(实现)是完全不知道的，只知道软件要做什么。因无法看到盒子中的内容，

31、所以不知道软件是如何实现的，也不关心黑盒里面的结构，只关心软件的输入数据和输出结果。黑盒测试的基本概念 黑盒测试是从用户观点出发的测试，其目的是尽可能发现软件的外部行为错误。在已知软件产品功能的基础上，检测软件功能能否按照需求规格说明书的规定正常工作，是否有功能遗漏；检测是否有人机交互错误，是否有数据结构和外部数据库访问错误，是否能恰当地接收数据并保持外部信息（如数据库或文件）等的完整性；检测行为、性能等特性是否满足要求等；检测程序初始化和终止方面的错误等。黑盒测试的基本概念 黑盒测试着眼于软件的外部特征，通过上述方面的检测，确定软件所实现的功能是否按照软件规格说明书的预期要求正常工作.两个显

32、著的优点：黑盒测试与软件具体实现无关，所以如果软件实现发生了变化，测试用例仍然可以使用；设计黑盒测试用例可以和软件实现同时进行，因此可以压缩项目总的开发时间。黑盒测试的基本概念 穷举输入测试是不现实的。这就需要我们认真研究测试方法，以便能开发出尽可能少的测试用例，发现尽可能多的软件故障。常用的黑盒测试方法有等价类划分、边界值分析、决策表测试等，每种方法各有所长，我们应针对软件开发项目的具体特点，选择合适的测试方法，有效地解决软件开发中的测试问题。等价类划分 等价类划分法是一种典型的黑盒测试方法，它完全不考虑程序的内部结构，只根据程序规格说明书对输入范围进行划分，把所有可能的输入数据，即程序输入

33、域划分为若干个互不相交的子集，称为等价类，然后从每个等价类中选取少数具有代表性的数据作为测试用例，进行测试。等价类划分 等价类划分方法 所谓等价类是指输入域的某个互不相交的子集合，所有等价类的并便是整个输入域。1划分等价类（1）有效等价类 检验程序是否实现了规格说明预先规定的功能和性能。（2）无效等价类 检查软件功能和性能的实现是否有不符合规格说明要求的地方。等价类划分方法2常用的等价类划分原则（1）按区间划分（2）按数值划分（3）按数值集合划分（4）按限制条件或规则划分（5）细分等价类等价类划分方法 在确立了等价类之后，可按下表的形式列出所有划分出的等价类表：等价类表 同样，也可按照输出条件

34、，将输出域划分为若干个等价类。输入条件有效等价类无效等价类等价类划分方法3等价类划分测试用例设计 在设计测试用例时应同时考虑有效等价类和无效等价类测试用例的设计。根据等价类表设计测试用例，具体步骤如下：（1）为每个等价类规定一个唯一的编号。（2)设计一个新的测试用例，尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到测试用例覆盖了所有的有效等价类。（3)设计一个新的测试用例，使其覆盖并且只覆盖一个还没有被覆盖的无效等价类。重复这一步，直至测试用例覆盖了所有的无效等价类。等价类划分 等价类划分法的测试运用 三角形问题的等价类测试 【例例】三角形问题是软件测试文献中使用最广泛的一个例子。输入三

35、个整数a、b和c分别作为三角形的3条边，通过程序判断由这3条边构成的三角形类型是：等边三角形、等腰三角形、一般三角形或非三角形（不能构成一个三角形）。等价类划分法的测试运用三角形问题可以更详细地描述为：输入3个整数a、b和c分别作为三角形的三条边，要求a、b和c必须满足以下条件：Con11a10 Con 21b100 Con 31c100 Con 4ab+c Con 5ba+c Con 6ca+b如果a、b和c满足Con1、Con2和Con3，则输出为4种情况之一：如果不满足条件Con 4、Con 5和Con 6中有一个，则程序输出为“非三角形”。如果三条边相等，则程序输出为“等边三角形”。如

36、果恰好有两条边相等，则程序输出为“等腰三角形”。如果三条边都不相等，则程序输出为“一般三角形”。等价类划分法的测试运用2保险公司人寿保险保费计算程序的等价类测试【例例2】某保险公司人寿保险的保费计算方式为：保费投保额保险费率 其中，保险费率根据年龄、性别、婚姻状况和抚养人数的不同而有所不同，体现在不同年龄、性别、婚姻状况和抚养人数，点数设定不同，10点及10点以上保险费率为0.6%，10点以下保险费率为0.1%；而点数又是由投保人的年龄、性别、婚姻状况和抚养人数来决定，具体规则见表。年龄性别婚姻状况抚养人数20394059其它MF已婚未婚1人扣0.5点，最多扣3点6点4点2点4点3点3点5点等

37、价类划分法的测试运用 分析程序规格说明中给出和隐含的对输入数据的要求，可以得出：年龄：一位或两位非零整数，取值的有效范围为199。性别：一位英文字符，只能取 M或F 值。婚姻：字符，只能取已婚或未婚。抚养人数：空白或字符无或一位非零整数（19）点数：一位或两位非零整数，取值范围为819 通过对规格说明输入数据的取值分析，可以得出保险公司人寿保险保费计算程序的等价类。等价类划分法的测试运用等价类测试存在两个问题：一是规格说明往往没有定义无效测试用例的期望输出应该是什么样的。因此，测试人员需要花费大量时间来定义这些测试用例的期望输出。二是强类型语言没有必要考虑无效输入。传统等价类测试是诸如FORT

38、RAN和COBOL这样的语言占统治地位年代的产物，那时这种无效输入的故障很常见。事实上，正是由于经常出现这种错误，才促使人们使用强类型语言。边界值分析法 大量的软件测试实践表明，故障往往出现在定义域或值域的边界上，而不是在其内部。为检测边界附近的处理专门设计测试用例，通常都会取得很好的测试效果。边界值分析法是一种很实用的黑盒测试用例方法，它具有很强的发现故障的能力。边界值分析法1边界条件 边界条件就是软件计划的操作界限所在的边缘条件。一些可能与边界有关的数据类型有：数值，速度，字符，地址，位置，尺寸，数量等。同时，考虑这些数据类型的下述特征：第一个/最后一个，最小值最大值，开始完成，超过/在内

39、，空满，最短最长，最慢/最快，最早/最迟，最高最低，相邻最远等。常见的边界值 对16-bit 的整数而言 32767 和-32768 是边界 屏幕上光标在最左上、最右下位置 报表的第一行和最后一行 数组元素的第一个和最后一个 循环的第 0 次、第 1 次和倒数第 2 次、最后一次边界值分析法 其实边界值和等价类密切相关，输入等价类和输出等价类的边界是要着重测试的边界情况。在等价类的划分过程中产生了许多等价类边界。边界是最容易出错的地方，所以，从等价类中选取测试数据时应该关注边界值。在等价类划分基础上进行边界值分析测试的基本思想是，选取正好等于、刚刚大于或刚刚小于等价类边界的值作为测试数据，而不

40、是选取等价类中的典型值或任意值做为测试数据。边界值分析法2边界值分析测试 这里讨论一个有两个变量x1和x2的程序P。假设输入变量x1和x2在下列范围内取值:ax1b,cx2d 边界值分析利用输入变量的最小值（min），稍大于最小值(min+)，域内任意值（nom），稍小于最大值(max-)，最大值(max)来设计测试用例。边界值分析法 对于一个n变量的程序，边界值分析测试会产生4n+1个测试用例。边界值分析法3.健壮性边界值测试 健壮性测试是边界值分析的一种扩展。变量除了取min，min，nom，max，max五个边界值外，还要考虑采用一个略超过最大值（max+）以及一个略小于最小值(min-

41、)的取值边界值分析法 健壮性边界值测试将产生6n+1个测试用例.健壮性测试最有意义的部分不是输人，而是预期的输出，观察例外情况如何处理。边界值举例边界值举例 250-500 边界值：边界值：249、250、251、499、500、501边界值分析法 边界值分析法的测试运用 1.三角形问题的边界值分析测试用例设计 边界值分析测试用例测试用例abc预期输出Test 1Test2Test3Test4Test560606050506060605050126099100等腰三角形等腰三角形等边三角形等腰三角形非三角形Test6Test7Test8Test960605050129910060605050等

42、腰三角形等腰三角形等腰三角形非三角形Test10Test11Test12Test1312991006060505060605050等腰三角形等腰三角形等腰三角形非三角形边界值分析法的测试运用加法器边界值测试用例设计【例例】加法器程序计算两个1100之间整数的和。对于加法器程序，根据输入要求可将输入空间划分为三个等价类，即1个有效等价类（1100之间），两个无效等价类（100）。但这种等价类划分不是很完善，我们只考虑了输入数据的取值范围，而没有考虑输入数据的类型，我们认为输入应为整数，但用户输入什么都有可能。边界值分析法的测试运用为此，我们可综合考虑输入数据的取值范围和类型划分等价类，其结果如下

43、表所示。加法器等价类编号输入条件所属类别编号输入条件所属类别11100之间整数有效等价类5非数值（字母）无效等价类2100整数无效等价类7非数值（空格）无效等价类4小数无效等价类8非数值（空白）无效等价类 边界值分析法的测试运用 加法器边界测试用例测试用例输入数据预期输出加数1加数2和Test115051Test 225052Test 39950149Test 410050150Test 550151Test 650252Test 75099149Test 850100150Test 9050提示“请输入1100间的整数”Test 10500提示“请输入1100间的整数”Test1110150

44、提示“请输入1100间的整数”Test1250101提示“请输入1100间的整数”Test130.250提示“请输入1100间的整数”边界值分析法的测试运用 加法器边界测试用例测试用例输入数据预期输出加数1加数2和Test14500.2提示“请输入1100间的整数”Test15A50提示“请输入1100间的整数”Test1650A提示“请输入1100间的整数”Test1750提示“请输入1100间的整数”Test1850提示“请输入1100间的整数”Test19空格50提示“请输入1100间的整数”Test2050空格提示“请输入1100间的整数”Test2150提示“请输入1100间的整数”

45、Test2250提示“请输入1100间的整数”边界值分析法的测试运用 应用边界值分析法进行测试用例设计时，应遵循以下一些原则：（1）如果输入条件对取值范围进行了限定，则应以边界内部以及刚超出范围边界外的值作为测试用例。（2）如果对取值的个数进行了界定，则应分别以MAX、MAX-、MAX+、MIN、MIN-、MIN+个数作为测试用例。（3）对于输出条件，同样可以应用上面提到的两条原则来进行测试用例设计。（4）如果程序规格说明书中指明输入或者输出域是一个有序的集合，如顺序文件、表格等，则应注意选取有序集合中的第一个和最后一个元素作为测试用例。因果图法 等价类划分法和边界值分析方法都是着重考虑输入条

46、件，如果程序输入之间没有什么联系，采用等价类划分和边界值分析是一种比较有效的方法。但如果输入之间有关系，例如，约束关系、组合关系，这种关系用等价类划分和边界值分析是很难描述的，测试效果难以保障，因此必须考虑使用一种适合于描述对于多种条件的组合，产生多个相应动作的测试方法，因果图正是在此背景下提出的。进行因果图法处理 某软件规格说明书包含这样的要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。因果图法 因果图法的原理 1因果图因果图法的原理 因果图法的原理2因果图法测试用例的设计步骤:（1

47、）确定软件规格中的原因和结果。分析规格说明中哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。（2）确定原因和结果之间的逻辑关系。分析软件规格说明中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系画出因果图。（3）确定因果图中的各个约束。由于语法或环境的限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。（4）把因果图转换为决策表。（5）根据决策表设计测试用例。因果图法的测试运用 有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，

48、按下“可乐”、“雪碧”或“红茶”按钮，相应的饮料就送出来。若投入的是两元硬币，在送出饮料的同时退还5角硬币 投入1元5角硬币投入2元硬币按“可乐”按钮按“雪碧”按钮按“红茶”按钮 退还5角硬币送出“可乐”饮料送出“雪碧”饮料送出“红茶”饮料 已投币 已按钮 因果图决策表法 在所有的黑盒测试方法中，基于决策表的测试是最严格，最具有逻辑性的测试方法。决策表法 决策表法 1决策表 决策表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用决策表能够设计出完整的测试用例集合。决策表法决策表通常由条件桩、条件

49、项、动作桩和动作项4部分组成。条件桩 条件项 动作桩 动作项规则 决策表的组成 动作项和条件项紧密相关，指出在条件项的各组取值情况下应采取的动作。决策表法2决策表的构造及化简构造决策表可采用以下5个步骤：（1）列出所有的条件桩和动作桩。（2）确定规则的个数。（3）填入条件项。（4）填入动作项，得到初始决策表。（5）简化决策表，合并相似规则。因果图生成决策表因果+决策案例 中国象棋中走马的实际情况 如果落点在棋盘外，则不移动棋子；如果落点与起点不构成日字型，则不移动棋子；如果落点处有自己方棋子，则不移动棋子；如果在落点方向的邻近交叉点有棋子（绊马腿），则不移动棋子；如果不属于1-4条，且落点处无

50、棋子，则移动棋子；如果不属于1-4条，且落点处为对方棋子(非老将)，则移动棋子并除去对方棋子；如果不属于1-4条，且落点处为对方老将，则移动棋子，并提示战胜对方，游戏结束设计测试用例的方法原因：1.落点在棋盘上 2.落点与起点构成日字 3.落点处不为自己方棋子 4.落点方向的邻近交叉点有棋子 5.落点处无棋子 6.落点处为对方棋子（非老将）7.落点处为对方老将 l 结果：l 21不移动棋子 l 22移动棋子l 23移动棋子，并除去对方棋子 l 24移动棋子，并提示战胜对方，结束游戏设计测试用例的方法决策表的例子因果图法+决策表作业 某软件规格说明书规定：输入的第一个字符必须是#或*，第二个字符