【文档说明】第六章软件测试课件.ppt，共(62)页，443.001 KB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-45246.html

以下为本文档部分文字说明：

第六章软件测试主要内容测试概论测试计划的编写测试用例的编写错误分类和错误跟踪系统的作用错误跟踪文档错误报告的生命周期和缺陷追踪因为开发工作的前期不可避免地会引入错误，测试的目的是为了发现和改正错误，这对于某些涉及人的生命安全或重要的军事、经济目标的项目显得尤其重要。例如，1

963年美国飞往火星的火箭爆炸，原因是FORTRAN程序：DO5I=1，3误写为：DO5I=1.3损失1000万美元。测试概论测试的目的（1）系统地找出软件中潜在的各种错误和缺陷。（2）跟踪修正软件缺陷（3）验证修正的软

件缺陷（4）证明软件的功能和性能与需求说明相符合。测试的目的是发现程序中的错误，是为了证明程序有错，而不是证明程序无错。测试概论什么测试为了发现程序中的错误而执行程序的过程。具体地说，软件测试是根据软件开发各阶段的规格说明和程

序的内部结构而精心设计出一批测试用例，并利用测试用例来运行程序，以发现程序错误的过程。测试的评判好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；成功的测试是发现了至今为止尚未发现的错误的测试。软件测试流程项目需求项目分析项目计划项目启动会议前期准备

与设置测试版本传递内部计划与进度里程碑测试周期实施测试测试管理执行测试测试项目报告测试质量保证项目收尾审查客户满意度调查最终提交测试文档软件测试过程创建测试计划构建测试环境执行软件测试处理测试结果软件测试过程制定测试计划设计测试用例执行测试撰写测试报告修正软件缺陷回归测试

测试需求分析软件需求测试概要设计测试单元测试集成测试系统测试Alpha测试Beta测试验收测试软件测试与开发的阶段关系软件需求文档软件验收测试软件设计规格软件系统测试软件框架设计软件集成测试软件详细设计软件单元测试软件编码PM

/市场/用户PM、架构师架构师高级程序员程序员程序/测试人员测试人员测试人员用户/测试人员程序员软件测试的基本原则1、尽量不由程序设计者进行测试。2、关键是注重测试用例的选择。输入数据的组成（输入数据、预期的输出结果）既有合理输入

数据，也有不合理的输入数据。用例既能检查应完成的任务，也能够检查不应该完成的任务。3、充分注意测试中的群集现象。程序中残存的错误数目与该程序中已发现的错误数目成正比。4、严格执行测试计划，排除测试的随意性。5、应当对每一个测试结果做全面检查。6、妥

善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。黑盒测试概念及方法黑盒测试是以用户的观点，从输入数据与输出数据的对应关系出发进行测试的，它不涉及到程序的内部结构。-很明显，如果外部特性本身有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。例如:实现一个网页的功

能,功能测试不关心它用什么语言编写的,只关心功能是否实现。程序P=f(I,O)输入I输出O特点：被测程序被当做一个无法打开的黑盒子。测试者无需了解程序的逻辑结构。过早的了解程序内部的情况会给黑盒测试带来负面的结果黑盒测试有两种基本方法通过测试在进行通

过测试时，实际上是确认软件能做什么，而不会去考验其能力如何。软件测试员只运用最简单，最直观的测试案例。在设计和执行测试案例时，总是先要进行通过测试。在进行破坏性试验之前，看一看软件基本功能是否能够实现。-失败测

试在确信了软件正确运行之后，就可以采取各种手段通过搞“垮”软件来找出缺陷。纯粹为了破坏软件而设计和执行的测试案例，被称为失败测试或迫使出错测试。失败测试通常有竞争条件，重复，压迫等测试，例如，多次启动关闭程序，内存不足，磁盘空间不够等。黑盒测

试有两种基本方法具体的黑盒测试方法等价类划分边值分析错误猜测黑盒测试的两个阶段第一个阶段新功能(NewFeature)测试阶段对新功能和新加代码的测试的原则:对软件要实现的主要功能进行测试，如果符合要求的简单的测试失败,那么将是一个很严重的问题，意味着主要程序的失败。对主要功能展

开最大范围的测试，要进行快速的测试但是不是深度测试.如果经过了以上两条基本测试,那么我们要用比较有挑战性的测试用例来进行进一步的测试。选择边界值进行测试。进行探索性测试。第二个阶段回归测试第二个阶段回归测试(Regressi

on)阶段.回归测试的两个目标:-检测已经修复的问题(bug)是否又重现了。-测试修复问题时有没有带来新的问题。回归测试测什么?-新修复的bug(测是否修复)。-以前修复的bug(测是否重现)。-基本功能的回归测试(测是否被破坏)。

回归测试的重要性-保证软件的质量,帮助下一个版本制定计划。测试的基本文档每个测试过程的基本文档包括:•《测试计划》：指明测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档。•《测试方案》：指明为完成软件或软件集成特性的测试而进行的设

计测试方法的细节文档。•《测试用例》：指明为完成一个测试项的测试输入，预期结果，测试执行条件等因素的文档。•《测试规程》：指明执行测试时测试活动序列的文档。•《测试报告》：指明执行测试结果的文档。测试计划(TestPlan)的编写测试计划的概念测试计

划文档的内容测试计划的概念测试计划是描述软件测试努力的目标、范围、方法和焦点的文档。准备测试计划的过程是完整考虑软件产品可接受评价努力的一个有用的方法。完整的文档将有助于测试组之外的人理解为什么要进行软件正确性检测，并且如何进行检测。测试计划应当足

够完整但也不应当太详尽，以致在测试组之外没有人会读它。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和

重要环节。测试计划来源于测试需求基于测试需求测试计划文档内容《测试计划》文档应该包括如下内容：-目标-概述-组织形式-角色及职责-测试对象-测试通过/失败的标准-测试挂起的标准及恢复的必要条件-测试任务安排-应交付的测试工作产品-工作量估计《测试计划》文

档内容（1）目标•表示该测试计划所应该达到的目标。概述•项目背景：项目的主要功能特征，体系结构，简要历史等。•范围：指明该计划的使用对象，范围。组织形式•表示测试计划执行过程中的组织结构及之间的关系，以及所需要的组织的独立程度。•同时指出测试过程与其他过程（开发，管理，）

间的关系。•还包括沟通渠道等。《测试计划》文档内容（2）角色与职责-定义角色及其职责，在每个角色与测试任务之间建立关联。测试对象列出所有将被作为测试目标的测试项测试通过/失败的标准指明了判断/确认测试何时结束，以及所测试的应用程序

的质量。可以直接陈述，也可以引用其他的文档。至少应该说明：什么将被测试？度量尺度是如何建立的?使用了哪些标准对度量进行评价?《测试计划》文档内容（3）测试挂起的标准以及恢复的必要条件-指明挂起全部或部

分测试项的标准,并指明恢复测试的标准及其必须重复的测试活动。测试任务安排明确测试任务。对于每个任务说明：-任务-方法和标准-输入/输出-时间安排-资源-风险和假设-角色和职责《测试计划》文档内容（4）应交付的测试工作产品•指明应该交

付的文档，测试代码及测试工具，一般包括测试计划，测试方案，测试用例，测试规程，测试日志，测试事故报告，测试总结报告，测试输入以及测试输出，测试工具。工作量估计•给出前面定义任务的人力需求及总计。测试计划文档举例（1）测试计划文

档举例（2）测试计划文档举例（3）测试用例(TestCase)的编写什么是测试用例黑盒测试用例的设计方法《测试用例》文档什么是测试用例一个测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。-一个测试用例应当

有完整的信息，如：测试用例ID号，测试用例名字，测试用例的目的，测试条件、输入数据需求、步骤和期望结果。选择测试用例是软件测试员最重要的一项任务，不正确的选择可能导致测试量过大或过小，甚至测试目标不对。测试用例的设计

方法等价类划分方法边界值分析方法错误推测方法因果图方法判定表驱动分析方法功能图分析方法等价类划分方法–定义是一种典型的黑盒测试方法，用这一方法设计测试用例可以不用考虑程序的内部结构，只以对程序的要求和说明，即《需求规

格说明书》为依据，仔细分析和推敲说明书的各项需求，特别是功能需求，把说明中对输入的要求和输出的要求区别开来并加以分解。注意：由于穷举测试的数量太大，以致于无法实际完成，促使我们在大量的可能数据中选取其中的一部分作为测试用例。等价类划分方法–方法等价类划分的办法是把程序的输入

域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能出现同样的错误。使

用这一方法设计测试用例，首先必须在分析需求规格说明的基础上划分等价类，列出等价类表。-在考虑等价类划分时，先从程序的功能说明中找出每个输入条件，然后为每个输入条件划分两个或更多个等价类。等价类划分方法–两种等价类有效等价类和无效等价类：-有效等价类是指对程序的规格说明是有意义的、

合理的输入数据所构成的集合。-无效等价类是指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。边界值分析方法边

界值分析：是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。实践证明，在设计测试用例时，对边界附近的处理必须给予足够的重视，为检验边界附近的处理专门设计测试用例，常常可以取得良好的测试

效果。边界值分析不仅重视输入条件边界，而且也从输出域导出测试用例。用等价类划分法和边界值分析法设计用例例:有效值:199x199=39,601•数据范围:0to99•可能输入数据:-99to–1无效值:

无穷大•100以上•-100以下•非数值边界值法用例表错误推测方法错误推测法:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.错误推测方法的基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,

根据他们选择测试用例。因果图方法因果图方法：前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等。考虑输入条件之间的相互组合,可能会产生一些新的情况.但要检查输入条件的组合不是一件容易的事情,

即使把所有输入条件划分成等价类,他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型）测试用例列表测试项目测试子项目用例编号

用例级别输入值预期输出实测结果备注测试项目1测试子项目1总数——————《测试用例》文档测试用例列表解释–项目/编号/级别测试项目：指明并简单描述本测试用例是用来测试那些软件项目，软件子项目或者软件特性。用例编号：对

该测试用例分配唯一的标志编号。用例级别：表明该用例的重要程度。（如果该用例没有通过的话，软件质量受到的影响。•1级：基本。用例涉及系统的基本功能，作为版本通过准则。项目如果不能通过这样的案例，需要考虑重新提交版本。•2级：重要。用例涉及单个版本特性。如果这个版本通不过，可以作为重要或者一般问

题提交报告。•3级：详细。用例反应的是某个单项功能的某个细节方面。比如：有关性能，极限，用户界面，„•4级：生僻。对应于比较生僻的预置条件和数据设置。对系统质量的影响不大。测试用例列表解释–输入/预期输

出/结果/备注输入值•列出执行本测试用例所需要的具体的输入值。可能的表示方式包括：直接输入；指明输入范围；引用常量表或事务文件；指明相关数据库；„预期输出值•描述被测项目或被测特性所希望或要求达到的输出或指标。如有需要，也要

列出描述预期输出数据的允许误差范围。对于复杂的数据，如数据库，也需要相应的描述。实测结果•在测试执行的时候填写，指明该测试用例是否通过。若否，需要列出实际测试时的测试输出值。备注•必要时，需要填写：特殊环境需求，特殊测试步骤要求

，相关测试用例等信息。测试用例列表解释–环境/步骤/其它特殊环境要求•包括：硬件需求，软件需求，其他需求。特殊测试步骤要求•指明执行本测试用例对相应的测试规程的任何特别的限制或要求。比如：初始化要求，人为干预，人观测和

判断的步骤，特殊的恢复步骤等。相关测试用例•列出必须先于本测试用例执行的测试用例。指明本用例和它们之间的依赖关系。错误分类和错误跟踪系统的作用软件缺陷(Defect)的定义为什么会出现软件缺陷软件错误的分类错误跟踪系统的作用软件缺陷(Defec

t)的定义符合下列五种情况之一的就可以认为是软件缺陷(defect):-软件未达到软件产品需求说明书指明的要求。-软件出现了软件产品需求说明书指明不会出现的错误。-软件功能超出软件产品需求说明书指明的范围。-软件未达到软件产品需求说明书虽未指明但

应达到的要求。-软件测试人员认为难以理解、不易使用、运行速度缓慢、或者最终用户认为不好的问题。软件错误的分类软件需求错误功能和性能错误软件结构错误数据错误实现和编码错误软件集成错误操作系统调用错误测试定义和

测试执行错误错误跟踪系统的作用便于集中管理，提高效率。有利于缺陷的清楚传达。便于查找和跟踪。对于大型软件的测试，报告的错误总数可能成百上千个，如果在没有错误跟踪系统的情况下，要求查找某个错误，简直是搜索者的恶梦，其难

度和效率可想而知的了。便于跟踪和监控错误的处理过程和方法。可以方便地检查处理方法是否正确，可以确定处理者的姓名和处理时间，作为工作质量的统计和考核的参考。安全性高，通过权限设置，不同权限的用户能执行不同操作，保证只

有适当的人员才能执行正确的处理。例如，测试工程师只能报告和验证错误，修复工程师能够修复错误。保证处理顺序的正确性，根据当前错误的状态，决定当前错误的处理方法。例如，如果是新报告的确认的错误，那么需要修复。如果是已经修复的错误，需要测试者

验证是否完全修复。便于项目结束后的存档。错误跟踪系统具有方便存储的特点，可以随时或在项目结束后存储，以备将来参考。错误跟踪文档根据测试项目的具体特点和测试要求，确定错误跟踪系统的具体组成结构和功能。通常错误跟踪文档包含：-字段内容-处理信息内容错误跟踪文

档包含字段测试软件项目名称：每个要测试软件项目都有唯一的名称，有的公司对项目还有特定的编号。测试软件版本号：测试周期内，一般需要测试多个软件版本，报告错误时，一定要正确填写产生错误的软件版本号。测试者名称：便于分清责任，便于管

理。测试日期与时间：便于分析和统计错误报告信息。测试软件环境：包括操作系统和其他必要的软件程序。测试硬件环境：包括测试计算机和其他测试设备的配置信息。错误描述：简明的描述错误的特征，便于查询和快速浏览。错误标识编号(ID#)：每个

错误都有一个唯一的标识编号，方便查询。错误类型：根据错误类型，分配给适当的人员处理错误。错误级别：错误的严重程度和处理的优先级，优先处理高级别的错误。错误跟踪文档包含字段（续）错误状态：错误状态表明错误是否已经处理和将怎样处理，根据错误状态，采用适当的处理方法。错误处理者名称：

便于分清责任，便于管理。重现错误的操作步骤：便于重现错误，修复错误和验证错误。期望的结果：描述满足设计要求的结果。实际测试结果：描述实际测试后得到的结果。必要的附图：便于确认错误的表现形式和错误位置。错误跟

踪文档包含字段（处理信息）处理者姓名：便于分清责任，便于管理。处理时间：便于分析和统计错误报告信息。处理方法：描述处理错误使用的具体方法，便于分析和总结错误处理的有效方法。处理步骤：便于检查处理步骤是否有效。

处理注释：便于处理错误的人员之间交流处理建议。错误报告缺陷严重程度Critical不能执行正常工作功能或重要功能。或者危及人身安全。Major严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）Minor严重地影

响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）Cosmetic使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。Other其它错误。缺陷状态Submitted已提交的缺陷Open确认“提交的缺陷”，等待处理Re

jected拒绝“提交的缺陷”，不需要修复或不是缺陷Resolved缺陷被修复Closed确认被修复的缺陷，将其关闭缺陷起源Requirement在需求阶段发现的缺陷Architecture在构架阶段发现的缺陷Design在

设计阶段发现的缺陷Code在编码阶段发现的缺陷Test在测试阶段发现的缺陷缺陷来源Requirement由于需求的问题引起的缺陷Architecture由于构架的问题引起的缺陷Design由于设计的问题引起的缺陷Code由于编码的问题引起的缺陷Test由于测试的问题

引起的缺陷Integration由于集成的问题引起的缺陷软件缺陷的严重性和优先级严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。在软件测试中，软件缺陷的严重性

的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。确定软件缺陷优先级，更

多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。缺陷的严重性和优先级的关系缺陷的严重性和优先级

是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后

处理。但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。如何表示缺陷的严重性和优先级缺陷的严重性和优先级通常按照级别划分，各个公司和不同项目的具体表示

方式有所不同。为了尽量准确的表示缺陷信息，通常将缺陷的严重性和优先级分成4级。如果分级超过4级，则造成分类和判断尺度的复杂程度，而少于4级，精确性有时不能保证。一般的缺陷管理过程Tester发现Bug,登记到缺陷管

理系统->开发team讨论分配bug->开发责任人完成修改,到缺陷管理系统登记处理结果->tester确认处理结果->Bug被正确修复/Bug修复不成功，继续上述过程缺陷管理工具工具最基本要求能记录

问题点、能及时传达给相关人员，并监督他们都作了适当的处理，更高级的工具还涵盖了与需求、测试方案、代码、自动测试工具等环境的集成。文档记录式的Bug管理：Excel，Word最著名缺陷管理系统：开源：B

ugZilla；IBM：ClearQuest国内开源的BugFree管理工具-免费且开放源代码、基于Web的精简版Bug管理系统,由PHP编写，使用MySql数据库。国内开源的BugFree管理工具新建

Bug编辑Bug（更新Bug状态等）查看Bug解决Bug激活BugBug列表报表http://www.bugfree.org.cn/demo/国内开源的BugFree管理工具注意，一般系统中一个Bug有7种解决状态：ByD

esign-就是这么设计的，无效的BugDuplicate-这个问题别人已经发现了，重复的BugExternal-是个外部因素(比如浏览器、操作系统、其他第3方软件)造成的问题Fixed-问题被修理掉了。Tester要尽可能找到这种BugNotRepro-无法复现你这个问题，无效

的BugPostponed-是个问题，但是目前不必修理了，推迟到以后再解Won'tFix-是个问题，但是不值得修理了，不管它吧