《软件测试（第2版）》高职全套教学课件

软件测试（第2版）全套可编辑PPT课件1软件测试基础知识2黑盒测试3白盒测试4性能测试/CONTENT目录5缺陷报告、分析及处理6API测试7自动化测试8软件产品测试与验收/CONTENT目录9测试实例———黎明资产管理系统模块1软件测试基础知识1.1软件测试的起源与发展1.2软件测试的定义和目标1.3软件测试的方法和技术1.4常见的软件测试模型1.5软件测试的原则

1.6软件测试的一般流程1.7企业测试举例软件是人们工作和学习的好助手,人们平时常用的软件包括Windows操作系统、Office办公软件、QQ和微信等。软件是通过软件开发流程开发出来的产品,它是计算机系统运行的指令、数据和相关文档的集合,即软件等于程序、数据加上文档。程序是事先按照预定功能、性能等要求设计和编写的指令序列;数据是使程序正常处理信息的数据结构及信息表示;文档是与程序开发、维护和使用有关的技术数据和图文资料。软件测试是伴随着软件的产生而产生的。早期的软件规模都很小、复杂程度较低,软件开发的过程混乱无序、相当随意,测试的含义比较狭窄,开发人员将测试等同于“调试”,目的是纠正软件中已知的错误经常常由开发人员自己完成这部分工作。对测试的投入极少,测试介入也较晚经常常是等到形成代码,产品已经基本完成时才进行测试。1.1软件测试的起源与发展到了20世纪80年代初期,IT行业进入了大发展时代,软件趋向大型化、高复杂度,软件的质量越来越重要。这时,一些软件测试的基础理论和实用技术开始形成,并且人们开始为软件开发设计了各种流程和管理方法,软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程,以结构化分析与设计、结构化评审、结构化程序设计及结构化测试为特征。1983年，电气电子工程师学会（IEEE）提出的软件工程术语中给软件测试下的定义是：“使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。它是帮助识别开发完成(中间或最终版本)的计算机软件(整体或部分)的正确度、安全度和质量的软件过程。”这个定义明确指出:软件测试的目的是检验软件系统是否满足需求。它是帮助识别开发完成(中间或最终版本)的计算机软件(整体或部分)的正确度、安全度和质量的软件过程。”1.1软件测试的起源与发展1.2软件测试的定义和目标1.2.1软件测试的定义软件测试是一种系统性的活动,它涉及运行软件或系统的过程,以此来评估其功能、性能和质量,目的是发现潜在的问题或错误。作为软件开发生命周期中的一个重要环节,软件测试旨在确保软件能够按照预期的方式正常运行。1.2软件测试的定义和目标1.2.2软件测试的目标软件测试的主要目标包括以下几点。(1)发现缺陷(2)验证功能正确性(3)评估软件质量(4)提高开发效率(5)验证需求(6)提高可靠性(7)优化用户体验(8)保障安全性1.3软件测试的方法和技术

软件测试发展至今,已经形成一个庞大的系统工程,有许多常用的测试方法,如黑盒测试、白盒测试和自动化测试等,其种类和名称十分庞杂。因此需要对软件测试的方法进行类型上的划分,便于明确测试过程、完成哪些操作步骤以及需要达到的测试目标,尽量保证测试的完整性。按照不同的分类标准可以将软件测试分为很多不同的种类,如图1-1所示。图1-1软件测试分类1.3软件测试的方法和技术

黑盒测试和白盒测试是软件测试中常用的两种方法,它们分别从不同的角度对软件进行测试。它们的主要区别在于测试人员在测试过程中需要对软件内部具体实现细节的了解程度不同,如图1-2所示。图1-2黑盒测试和白盒测试

1.3.1黑盒测试和白盒测试1.3软件测试的方法和技术

1.黑盒测试黑盒测试是一种基于软件外部行为和规格要求的测试方法。在这种测试中,测试人员不需要了解软件内部的具体实现细节,而是仅根据软件规格或需求文档来设计测试用例,通过输入数据并观察输出结果来验证软件的正确性和功能完整性。黑盒测试的特点如下。1.3.1黑盒测试和白盒测试（1）聚焦于软件的功能和规格要求,不关注其内部实现。（2）不需要程序员的专业知识,测试人员可以独立进行测试。（3）测试用例的设计主要基于等价类划分、边界值分析和错误推测等技术。（4）旨在发现软件的功能问题,如输入验证、功能逻辑错误等。（5）常用的技术和方法包括功能测试、界面测试、配置测试、性能测试和安全测试等。1.3软件测试的方法和技术

2.白盒测试白盒测试是一种基于对软件内部结构、逻辑和代码的理解来设计测试用例并进行测试的方法。测试人员通过访问和分析源代码、控制流图及路径覆盖等信息,从内部的角度来评估软件的质量,从而揭示潜在的错误和缺陷。白盒测试的特点如下。1.3.1黑盒测试和白盒测试（1）需要测试人员具备一定的编程和代码分析能力,能够理解软件的内部实现。（2）能够深入软件的内部逻辑,如发现隐藏的边界条件、错误路径和异常情况。（3）旨在检测软件的结构性问题,如逻辑错误、代码覆盖不全等。1.3软件测试的方法和技术

1.功能测试功能测试旨在验证软件的各项功能是否均按照规格要求正确运行。这种测试通常基于软件的需求规格和功能规格文档来设计测试用例。功能测试的主要目标如下。（1）验证软件的功能是否符合用户需求和规格要求。（2）检查软件的输入和输出是否正确。（3）确保软件的各项功能能够稳定、正常地工作。（4）发现并报告功能缺陷、逻辑错误和算法问题等。功能测试涵盖以下方面的测试:基本功能、边界条件、异常情况、用户界面、数据输入验证、功能组合和功能交互等。1.3.2功能测试、性能测试和安全测试1.3软件测试的方法和技术

2.性能测试性能测试旨在评估软件在各种负载情况下的性能表现和可靠性。该类型的测试有助于确定软件在正常和峰值负载下的响应时间、吞吐量、稳定性和资源利用率等方面的表现。性能测试的关注点如下。1.3.2功能测试、性能测试和安全测试(1)测试软件在不同负载情况下的响应时间和吞吐量。(2)确认软件在长时间运行时的稳定性和可靠性。(3)评估资源的利用率,如内存、CPU和网络带宽等。(4)进行负载均衡和容量规划等。性能测试包括负载测试、压力测试、容量测试、稳定性测试和配置测试等。1.3软件测试的方法和技术

3.安全测试安全测试旨在评估软件系统的安全性,以发现潜在的安全漏洞和脆弱性,并确保软件对潜在攻击有足够的抵御能力。安全测试的重点如下。(1)检查软件的认证和授权机制,以防止未经授权的访问。(2)发现和修复潜在的漏洞,如输入验证、数据处理和访问控制等。(3)评估软件的加密和数据保护机制,以确保数据的机密性和完整性。(4)进行安全漏洞扫描和渗透测试等。安全测试包括网络安全测试、应用程序安全测试、数据安全测试和身份验证/授权测试等。1.3.2功能测试、性能测试和安全测试1631.3软件测试的方法和技术

1.静态测试静态测试是在不运行实际软件的情况下,对软件的设计、文档和代码进行检查和分析的方法。它主要关注软件的静态属性,如结构、语法、规范和设计等,以发现潜在的问题和缺陷。静态测试的特点如下。1.3.3静态测试和动态测试(1)没有实际去执行软件代码。(2)静态测试主要基于软件文档、源代码和模型来进行验证和评估。（3)目标是发现潜在的缺陷、错误和安全漏洞等。(4)静态测试可以包括代码审查、文档审查、模型验证、静态分析等技术和方法。1.3软件测试的方法和技术

1.静态测试1.3.3静态测试和动态测试静态测试的优势在于可以尽早发现问题,从而有效降低缺陷修复的成本。它不仅能帮助我们发现设计的缺陷、逻辑错误、命名不规范和未使用的变量等问题,还能确保代码遵循既定的标准和最佳实践。静态测试通常需要开发人员、质量保证团队或专门的审查小组来执行。1.3软件测试的方法和技术

2.动态测试动态测试是一种在运行实际软件时,对软件的行为和功能进行验证和评估的方法。该方法通过模拟用户的实际操作和使用场景,来检查软件的实际执行结果和输出是否符合预期。动态测试的特点如下。1.3.3静态测试和动态测试（1）需要执行实际的软件代码。（2）动态测试基于输入数据和操作流程来验证软件的功能和行为是否符合预期。（3）目标是发现实际运行中的错误、异常情况和功能问题。（4）动态测试可以包括单元测试、集成测试、系统测试和验收测试等。1.3软件测试的方法和技术

1.3.3静态测试和动态测试静态测试和动态测试是软件测试过程中常用的两种方法。静态测试在不执行实际软件代码的情况下,通过检查和分析设计、文档和代码来发现问题;而动态测试是在执行实际软件代码的情况下,通过验证和评估软件的行为和功能来发现问题。这两种测试方法对于提高软件质量、发现潜在错误和确保软件符合预期都是至关重要的。在实际测试中,通常需要同时使用静态测试和动态测试两种方法,以提供更全面和有效的测试覆盖。1.3软件测试的方法和技术

1.3.4单元测试、集成测试、系统测试和验收测试按照测试阶段可以将软件测试分为单元测试、集成测试、系统测试和验收测试。这种分类方式与软件开发过程相对应,目的是验证软件开发各个阶段的成果是否符合预期要求。单元测试是软件开发的第一步测试,目的是验证软件单元是否符合软件需求与设计要求。单元测试大多是开发人员进行的自测。（1）单元测试集成测试是将已经被测试过的软件单元组合在一起以测试它们之间的接口,用于验证软件是否满足设计要求。在持续集成(continuous

integration,CI)的场景中,常见的测试方式包括冒烟测试和回归测试。（2）集成测试1.3软件测试的方法和技术

1.3.4单元测试、集成测试、系统测试和验收测试系统测试是在完成集成测试之后,把软件部分与系统的其他组成部分包括硬件、外部软件、操作人员等结合起来,在实际运行或模拟环境下对计算机系统进行的一系列严格有效的测试,以发现潜在的问题。系统测试包括恢复测试、安全测试、压力测试等类型。（3）系统测试验收测试主要是对软件产品说明进行验证,逐行逐字地按照说明书的描述对软件产品进行测试,确保其符合用户的各项要求。（4）验收测试1.3软件测试的方法和技术

1.3.5手工测试与自动化测试

根据自动化程度的不同,可以将软件测试分为手工测试与自动化测试。手工测试是指测试人员逐条执行代码来完成测试工作。然而,手工测试相对耗时费力,并且在测试人员处于疲惫状态时很难保证测试的效果和准确性。相比之下,自动化测试是借助脚本、自动化测试工具等手段完成相应的测试工作,它也需要人工的参与。1.4常见的软件测试模型1.瀑布模型传统的瀑布模型包括项目计划—需求分析—软件设计—程序开发—软件测试—集成维护这几个阶段。由于这个模型难以适应频繁变化的需求,现在已经不常用,但是模型中这几个阶段都很有代表意义,对后面的模型有一定的参考价值。(1)项目计划阶段(2)需求分析阶段主要是制订项目总体研发计划,树立项目里程碑节点,输出项目计划书。明确用户的需求定义,并对这个定义进行清晰地描述,是充分理解用户需求,描述产品功能的重要阶段,这个阶段会输出产品的需求规格说明书。(3)软件设计阶段会根据需求的定义来确定产品实现的方案,包括软件和硬件的结构定义,组建模块的实现方法,接口、界面和数据的组织方式,这个阶段会输出包括概要设计、详细设计在内的多份说明书。1.4常见的软件测试模型1.瀑布模型(4)程序开发阶段(5)软件测试阶段这个阶段是开发团队根据需求定义和设计要求具体实现产品,根据编程规范,构建组件模块,最后输出产品版本。这个阶段是通过独立的测试小组或QA团队评估产品是否满足需求定义,最后输出测试结果报告。(6)集成维护阶段产品经过测试后,交付给用户使用,开发人员根据用户的使用情况,对产品进行维护,并进行必要的修改和升级等操作。1.4常见的软件测试模型2.V模型V模型使用范围最广,它是从瀑布模型演化而来的,包括需求分析—概要设计—详细设计—软件编码—单元测试—集成测试—系统测试—验收测试这几个阶段,如图1-3所示。图1-3V模型

1.4常见的软件测试模型2.V模型V模型按图1-3中箭头的方向指出了不同阶段的顺序和依赖性。每个阶段的分工和解决的问题不同。01(1)单元测试和集成测试检测程序是否满足设计要求。02(2)系统测试03(3)验收测试在功能、性能这些质量特性上是否满足系统要求的指标。确定软件是否满足用户的需求及合同的规定。1.4常见的软件测试模型3.W模型W模型其实是双V模型,它的设计思想是并发执行软件测试与软件开发。开发与测试并行,有利于尽早发现问题,有利于及时了解项目的测试风险,及早地执行相应的应对方案,加快项目的开发进度。W模型存在的缺点是整个开发阶段仍然是串行的,上一阶段未完全完成,无法进入下一阶段,不支持敏捷模式的开发。W模型如图1-4所示。图1-4W模型

1.4常见的软件测试模型4.X模型X模型的基本思路是分离出多个程序片段,并对各片段独立地进行编码和测试,此后进行频繁的交接,再通过集成,最终合成可执行的程序。已经通过测试的程序可以进行封版提交给用户,也可以作为更大集成的一部分。X模型的右下方还定位了探索式测试,探索式测试是不进行事先计划的特殊类型的测试,能够帮助测试人员在测试计划之外发现更多的错误。X模型如图1-5所示。图1-5X模型

1.4常见的软件测试模型5.H模型H模型强调把测试分为测试准备和测试执行两个阶段,如果其他流程的进展使测试点准备就绪,测试执行活动就可以进行。在H模型中,测试是一个完全独立的模型,因此可以与其他流程交叉进行,也便于尽早地执行测试。H模型如图1-6所示。图1-6H模型

1.5软件测试的原则1.测试应基于用户需求所有的测试工作都应该建立在满足用户需求的基础上,从用户的角度来看,最严重的错误就是软件无法满足需求。应按照用户的需求配置环境,按照用户的使用习惯进行测试并评价结果。如果系统不能完成用户的需求和期望,那么这个系统的研发就是失败的。同时,在系统中发现和修改缺陷也是没有任何意义的。在开发过程中用户的早期介入和接触原型系统就是为了避免这类问题发生的预防性措施。1.5软件测试的原则2.测试要尽早进行并不断迭代由于软件的复杂性和抽象性,在软件生命周期各阶段都可能产生错误,所以不应把软件测试仅仅看作软件开发的一个独立阶段,而应当把它贯穿到软件开发的各个阶段中去。在需求分析和设计阶段就应开始进行测试工作,编写相应的测试计划及测试设计文档,同时坚持在开发各阶段进行技术评审和验证,这样才能尽早发现和预防错误,杜绝某些缺陷和错误,提高软件质量。尽早开展测试准备工作以使测试人员能够在早期了解到测试的难度,预测测试的风险,有利于开发人员制订出完善的计划和方案,提高软件测试及开发的效率,并规避测试中存在的风险。尽早开展测试工作有利于测试人员尽早发现软件中的缺陷,大大降低错误修复的成本。测试工作进行得越早,越有利于提高软件的质量,这是预防性测试的基本原则。1.5软件测试的原则3.穷举测试是不可能由于时间和资源的限制,穷举测试(各种输入和输出的全部组合)是不可能的,测试人员可以根据测试的风险和优先级控制测试的工作量,在测试成本、风险和收益之间取得平衡。此外,应避免冗余测试。1.5软件测试的原则4.遵循GoodEnough原则GoodEnough原则是一种权衡投入/产出比的原则：不充分的测试是不负责任的，而过分的测试是一种资源的浪费，同样也是一种不负责任的表现。测试不充分无法保证软件产品的质量,但测试投入过多会造成资源的浪费。随着测试资源投入的增加,测试的产出也是增加的,但当投入达到一定的比例后,测试的效果就不会明显增强了。这个原则实施的困难之处在于如何界定什么样的测试是不充分的,什么样的测试是过分的。针对这种情况,测试人员最好制定最低测试通过标准和测试内容,然后具体问题具体分析。1.5软件测试的原则5.缺陷要符合“二八”定理缺陷的“二八”定理就是在一般情况下,软件80%的缺陷会集中在20%的模块中,缺陷并不是平均分布的。存在这种现象的原因是:对一个程序模块进行测试,已发现的错误数越多,其中存在的错误概率也就越大。错误集中发生的现象可能与程序员的编程水平和习惯有很大的关系。因此,在测试时要抓住主要矛盾,如果发现某些模块比其他模块具有更多的缺陷,那么要投入更多的人力重点测试这些模块以提高测试效率。1.5软件测试的原则6.杀虫剂悖论杀虫剂用得多了,害虫就会产生免疫力,杀虫剂就发挥不了效力。在测试中,同样的测试用例被反复使用时,发现缺陷的能力就会越来越差。这种现象的主要原因在于测试人员没有及时更新测试用例,同时对测试用例及测试对象过于熟悉,形成了思维定式。要想避免这种情况,就要不断对测试用例进行修改和评审,不断增加新的测试用例,这样软件中未被测试过的部分或先前没有被使用过的输入组合就会被重新执行,从而发现更多的缺陷。1.6软件测试的一般流1.6.1评测测试需求在软件测试前需编写一份软件需求规格说明书检查清单,目的是确保测试的全面性和准确性,以满足软件需求的验证和评估。注意,评测测试需求并不是需求分析,而是测试人员在制订测试计划之前先对软件需求规格说明书进行评测,按检查项逐项检查和判断,从而得出前期需求分析的过程和结果的评价,活动产出的结果是一张检查表,如表1-1所示。表1-1软件需求规格说明书检查列表1.6软件测试的一般流1.6.1评测测试需求检查表的设计可以从以下几个方面考虑。（1）确保需求理解的一致性。（2）验证需求可测性。（3）检查需求的完整性和一致性。（4）确保需求追踪和变更管理。1.6软件测试的一般流1.6.2制订测试计划

测试计划一般要包括以下内容。(1)确定测试内容(2)制定测试规则(3)设定测试环境(6)风险管理(5)计划实施(4)安排测试任务1.6软件测试的一般流1.6.3设计测试用例1.目的和作用编写测试用例主要是为了进行软件的测试,发现潜在的问题和缺陷,并评估系统的性能、功能和质量。这是测试过程中重要的一环,对于确保系统的质量和稳定性至关重要。1.6软件测试的一般流1.6.3设计测试用例2.测试用例编写规范1)常用字段(1)用例编号。由名称和数字构成,具有唯一性。(2)用例标题。为测试用例赋予一个有意义的标题,并要简洁明了。(3)前置条件。指明执行测试用例所依赖的前置条件,在执行用例之前需要满足的环境或数据设置。(4)输入。指明输入参数和约束条件。(5)测试步骤。指明测试的具体步骤和操作,以及所需的输入和预期输出。(6)预期结果。明确用例执行后预期得到的结果或期望的行为。(7)执行结果。记录实际执行测试用例后的结果,包括实际输出和实际行为是否符合预期。(8)是否通过。即测试是否通过的状态标记,如“通过”“失败”“跳过”等,以便于跟踪和管理用例状态。1.6软件测试的一般流1.6.3设计测试用例2.测试用例编写规范1)常用字段一般将测试用例设计成表格形式,如表1-2所示。以上测试用例字段并不是一成不变的,项目团队可根据项目的实际需求和团队的实践经验进行适当调整和补充。编写规范的测试用例有助于跟踪测试进度和结果。表1-2测试用例示例

1.6软件测试的一般流1.6.3设计测试用例2.测试用例编写规范2)自动化测试如果使用自动化测试工具或平台,可将数据参数化,即针对需要多次重复执行的用例,尽量使用参数化的方式来提高测试的覆盖度。将测试数据和参数从测试用例中分离,减少用例的重复编写。例如,要测试用户登录功能,可以在测试前准备好测试数据集,如表1-3所示。表1-3测试数据集

1.6软件测试的一般流1.6.3设计测试用例2.测试用例编写规范3)正确性和完整性（2)测试用例要满足完整性,参照以下做法。首先,完整分析需求,对系统的每个功能点编写相应的测试用例。确保每个功能都有一个或多个测试用例,覆盖正常、异常和边界条件。其次,关注功能的边界条件,即输入的上下限或边界值。(1)测试用例要满足正确性,参照以下做法。首先,应该基于清晰、详细的需求规格来编写。仔细分析和理解需求,确保所有功能需求和业务场景都有相应的测试用例覆盖。其次,按照真实的业务场景设计测试用例。1.6软件测试的一般流1.6.3设计测试用例2.测试用例编写规范4)可读性测试用例应具备良好的可读性和可维护性,使得其他人能够轻松理解和执行这些用例。采用清晰的语言描述和良好的结构化,避免冗余和重复。5)持续更新随着项目的进行和需求的演化,测试用例需要持续更新和维护,保持与实际系统的一致性。1.6软件测试的一般流1.6.3设计测试用例3.测试用例的管理测试用例的管理是测试过程中非常重要的一环,它可以帮助团队有效组织、跟踪和执行测试工作。常可以使用Excel电子表格管理测试用例,在前面已经举例说明。这类非专业的测试用例管理软件存在一些优点和缺点优点是简单易用,可批量操作数据。缺点为:基于文件形式存储,分布零散;无法有效统一用例规范;版本管理混乱,可追溯性差;缺少对团队协作支持。1.6软件测试的一般流1.6.3设计测试用例3.测试用例的管理可以使用专门的测试用例管理工具,如TestRail、TestLink和Zephyr等,方便进行在线操作和版本管理,一些项目管理工具也具有类似功能。测试用例管理工具一般具有以下功能。(1)测试用例管理(2)用例库和目录结构(3)用例属性和标签(4)版本控制(5)用例批量导入和导出(6)用例执行和跟踪(7)用例评审和审查(8)用例维护和更新(9)用例复用和参数化(10)用例报告和统计1.6软件测试的一般流1.6.4执行测试执行测试就是按照测试用例进行测试的过程,这是测试人员最主要的活动阶段。在执行测试时要根据测试用例的优先级进行。执行测试过程看似简单,测试人员只要按照测试用例完成测试工作即可,但实际并非如此。测试用例的数目非常多,测试人员需要完成所有测试用例的执行,每一个测试用例都可能会发现很多缺陷,测试人员要做好测试记录与跟踪,衡量缺陷的质量并编写缺陷报告。当提交后的缺陷被开发人员修改后,测试人员需要对其进行回归测试。如果系统对测试用例产生了缺陷免疫,测试人员则需要编写新的测试用例。1.6软件测试的一般流1.6.5编写测试报告

测试报告是对一个测试活动的总结,对项目测试过程进行归纳,对测试数据进行统计,对项目的测试质量进行客观评价。不同公司的测试报告模板不同,但测试报告的编写要点都是一样的,一般都是先对软件进行简单介绍,然后说明这份报告是对该产品的测试过程进总结,对测试质量进行评价。一份完整的测试报告必须包含以下几个要点。(1)引言(2)测试概要(3)测试内容及执行情(4)缺陷统计与分析(5)测试结论与建议1.7企业测试举例

泉州银行自成立至今已有二十多年历史,是本书编写过程中的合作企业。银行软件系统十分复杂,包含几十个乃至上百个子系统。每个业务流程通常需要跨越多个子系统来完成,因此,确保各模块功能的正确性以及系统整体的稳定性显得至关重要。随着业务的不断扩展和新功能的不断开发,泉州银行对软件测试领域的需求日益增长,同时对软件测试的严格性要求也不断提升。为了高效推进软件测试工作,泉州银行信息技术部下设需求与测试中心,专职负责软件技术的测试工作。该中心下设系统集成测试组、性能测试组及自动化测试组等。各组的职责分别是:系统集成测试组负责测试需求的深入分析,通过等价类划分、边界值分析和判定表等技术测试手段,按照需求对软件进行全面测试;性能测试组负责系统的性能评估与测试;自动化测试组负责开发与维护自动化测试脚本,旨在提高测试效率和覆盖率。通过合理的部门划分和科学规范的工作流程,泉州银行能够高效地进行系统集成测试、性能测试任务,确保系统稳定、安全地运行。1.7企业测试举例

图1-7是在银行现场拍摄的照片,可见员工统一着装,十分整齐。图1-7泉州银行信息技术部的需求与测试中心工作现场小结本模块主要介绍了软件测试的基础知识,首先介绍了软件测试的发展过程;其次介绍了软件测试的定义和目标;接着介绍了软件测试的方法和技术,如黑盒白盒测试、常见的软件测试模型及软件测试原则;并比较详细地讲解了软件测试的一般流程和编写测试用例的规范做法。读者在学习完本模块的知识之后,能对软件测试有比较直观的认识,也能为其后续学习打下基础。模块2黑盒测试2.1等价类划分法2.2边界值分析法2.3因果图法与决策表2.4正交实验设计法2.1

等价类划分法2.1.1使用等价类划分法的步骤一个程序可以有多个输入,等价类划分法就是将这些输入数据按照输入需求进行分类,并将它们划分为若干个子集,这些子集即为等价类,在每个等价类中选择有代表性的数据设计测试用例。例如,将实数的平方根运算函数设计为y=sqrt(x),假设x的约束为(0≤x≤10),这样x就可以分为3个等价类,包括x<0、0≤x≤10、x>10。2.1

等价类划分法2.1.1使用等价类划分法的步骤使用等价类划分法测试程序需要经过划分等价类和设计测试用例两个步骤,具体介绍如下。1.划分等价类软件不可能只接收有效、合理的数据,还可能面临意外情况,如用户可能输入无效和不合理的数据。软件只有经受了这样的考验,才能说明它可靠。因此,等价类要区分有效等价类与无效等价类两种情况。有效等价类是针对软件规格说明而言的,是符合程序要求、合理且有意义的输入数据。无效等价类是针对软件规格说明而言的,是不符合程序要求、不合理或无意义的输入数据。2.1

等价类划分法2.1.1使用等价类划分法的步骤1.划分等价类如何确定等价类是等价类划分法的重要问题,一般在划分等价类时需要遵守以下原则。若规格说明要求输入值是一个输入取值范围或有限数量的值,则可以将输入数据划分为一个有效等价类和两个无效等价类,有效等价类为指定的取值区间,两个无效等价类分别为有限区间两边的值。例如,某程序要求输入值x的范围为[1,100],则有效等价类为1≤x≤100,无效等价类为x<1和x>100。（1）按区间划分若程序要求输入值是一个“必须成立”的情况,则可以将输入数据划分为一个有效等价类和一个无效等价类。例如,某程序要求密码包含字母、数字,长度大于8位,则正确的密码为有效等价类,错误的密码为无效等价类。（2）按限制条件或规则划分2.1

等价类划分法2.1.1使用等价类划分法的步骤1.划分等价类若程序要求输入数据是一组可能的值,或要求输入值必须符合某个条件,则可以将输入数据划分为一个有效等价类和一个无效等价类。例如,某程序要求输入数据必须是以数字开头的字符串,则以数字开头的字符串是有效等价类,不是以数字开头的字符串是无效等价类。（3）按数值划分若等价类中每个输入数据在程序中的处理方式各不相同,则可将该等价类划分成更小的等价类。（4）细分等价类2.1

等价类划分法2.1.1使用等价类划分法的步骤2.设计测试用例根据测试用例的完整性分为四种:弱一般等价类测试、强一般等价类测试、弱健壮等价类测试、强健壮等价类测试。健壮是指要考虑无效值。强是指要考虑组合情况,使用笛卡儿积算出测试用例个数。下面以某城市电话号码为例来说明:某城市电话号码由三部分组成。区号:空白或四位数字;前缀:221~229开头的3位数或231~239开头的3位数;后缀:4位数字。根据上述信息划分等价类,如表2-1所示。表2-1某城市电话号码划分等价类2.1

等价类划分法2.1.1使用等价类划分法的步骤2.设计测试用例1)弱一般等价类“弱”表示测试用例只需覆盖3个输入条件的所有有效等价类,不用考虑它们之间的组合,“一般”表示只考虑有效等价类,因此最少只需要2个测试用例即可满足弱一般等价类测试的要求。上面例子弱一般等价类的用例为ace、bde,具体测试的数据如表2-2所示。表2-2弱一般等价类测试用例2.1

等价类划分法2.1.1使用等价类划分法的步骤2.设计测试用例2)强一般等价类“强”表示测试用例需覆盖3个输入条件的所有有效等价类的可能组合,“一般”表示只考虑有效等价类。区号有2个有效等价类,前缀有2个有效等价类,后缀有1个有效等价类,因此共需要2×2×1=4个测试用例才能满足强一般等价类的测试要求。因为只有区号有两个维度,其他都是一个维度,测试用例数量恰好跟弱一般等价类相同。上面例子弱一般等价类的用例为ace、ade、bce、bde,具体测试的数据如表2-3所示。表2-3强一般等价类测试用例

2.1

等价类划分法2.1.1使用等价类划分法的步骤2.设计测试用例3)弱健壮等价类“弱”表示测试用例只需覆盖3个输入条件的所有有效等价类,不用考虑它们之间的组合,“健壮”表示不仅要考虑有效类,还需考虑无效类。在弱一般等价类的基础上,增加输出为无效值的10种情况。注意在编写测试用例时,每个用例输出只覆盖一个无效值,其余是有效值,具体测试的数据如表2-4所示表2-4弱健壮等价类测试用例

2.1

等价类划分法2.1.1使用等价类划分法的步骤2.设计测试用例4)强健壮等价类“强”表示测试用例需覆盖3个输入条件的所有有效等价类的可能组合,“健壮”表示不仅考虑有效类,还需考虑无效类。参考表2-1,其中区号有2个有效等价类、3个无效等价类;前缀有2个有效等价类、4个无效等价类;后缀有1个有效等价类、3个无效等价类,因此共需要(2+3)×(2+4)×(1+3)=5×6×4=120个测试用例才能满足强一般等价类的测试要求。上述例子介绍了如何使用等价类划分法设计测试用例,方法重点在于如何划分有效等价类和无效等价类。等价类粒度划分的粗细也很重要,粒度越粗,设计测试用例越少;粒度越细,设计测试用例越多。一般来说,粒度越细能发现更多问题,但是带来了更多的测试用例。2.1

等价类划分法2.1.2实例:三角形问题的等价类划分

三角形问题是测试中广泛使用的一个经典案例,下面按照以下几个步骤使用弱健壮等价类方法来设计测试用例。(1)按照输入条件建立有效等价类和无效等价类,列出所有划分出的等价类。(2)为每一个等价类设置一个唯一的编号。(3)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步骤,直到所有的有效等价类都被覆盖为止。(4)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步骤,直到所有的无效等价类都被覆盖为止。2.1

等价类划分法2.1.2实例:三角形问题的等价类划分

1.划分等价类它要求输入a、b、c这3个正数作为三角形的三条边,要判断三角形的性质。三条边长对应的3个数决定了三角形是一般三角形、等边三角形、等腰三角形,还是无法构成三角形。如果使用等价类划分法设计三角形程序的测试用例,首先需要将所有输入数据划分为不同的等价类。对该案例进行分析,程序要求输入3个数且是正数,在输入3个正数的基础上判断这3个数能否构成三角形,如果能构成三角形,那么再判断它构成的是一般三角形、等腰三角形还是等边三角形,如此可以按照下列步骤将输入情况划分为不同的等价类。2.1

等价类划分法2.1.2实例:三角形问题的等价类划分

1.划分等价类（1)判断三个数是否是正数,可以将输入情况划分为1个有效等价类和3个无效等价类,下列表述中表达式中的||表示用例是并列关系,&&表示用例是同一用例关系。3个数都是正数,a>0&&b>0&&c>0。①有效等价类任意一个数小于等于0,a≤0||b≤0||c≤0。②无效等价类2.1

等价类划分法2.1.2实例:三角形问题的等价类划分

1.划分等价类（2)在输入3个正数的基础上,判断3个数能否构成三角形,可以将输入情况划分为3个有效等价类和3个无效等价类,具体如下。任意两个数之和大于第三个数,a+b>c||a+c>b||b+c>a。①有效等价类任意两个数之和小于等于第三个数,a+b≤c||b+c≤a||c+a≤b。②无效等价类2.1

等价类划分法2.1.2实例:三角形问题的等价类划分

1.划分等价类(3)在3个数构成三角形的基础上,判断这3个数能否构成等腰三角形,可以将输入情况划分成3个有效等价类和1个无效等价类。其中有2个数相等,a=b||a=c||b=c。①有效等价类3个数均不相等,a!=b&&b!=c&&c!=a。②无效等价类2.1

等价类划分法2.1.2实例:三角形问题的等价类划分

1.划分等价类(4)判断这3个数能否构成等边三角形,有1个有效等价类和3个无效等价类,具体如下。3个数相等,a=b&&b=c&&a=c。①有效等价类3个数不相等,a!=b||b!=c||c!=a。②无效等价类2.1

等价类划分法2.1.2实例:三角形问题的等价类划分

2.设置等价类编号上述分析一共将三角形输入划分成了18个等价类,给这些等价类确定编号并建立等价类表,如表2-5所示。表2-5三角形输入等价类表2.1

等价类划分法2.1.2实例:三角形问题的等价类划分

3.设计新用例不断设计新的测试用例,使其尽可能多地覆盖尚未被覆盖的有效等价类,直到所有的有效等价类都被测试用例覆盖为止。接下来设计测试用例,设计测试用例的原则是:用尽可能少的测试用例覆盖尽可能多的等价类。既要考虑输入情况的全面性,又要考虑对有效等价类的覆盖情况。在设计新的有效等价类的测试数据时,增加等价类的覆盖范围,包括更多的有效等价类的编号,在这个例子中因为有效等价类存在递进关系,所以使得测试数据变得更加特殊化。根据表2-1中的有效等价类设计测试用例,如表2-6所示。表2-6设计了6组测试用例覆盖了全部有效等价类。表2-6覆盖有效等价类的测试用例

2.1

等价类划分法2.1.2实例:三角形问题的等价类划分

4.覆盖所有无效等价类不断设计新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,直到所有无效等价类都被覆盖为止。无效等价类测试用例的设计原则与有效等价类测试用例的设计原则相同,无效等价类的测试用例如表2-7所示。表2-7无效等价类的测试用例2.1

等价类划分法2.1.3实例:银行转账的等价类划分银行转账是人们经常进行的操作,现在可以通过个人计算机或手机App进行操作。但是每天转账金额有上限,即转账额度。假设某银行已经开发了一款软件实现用户自助转账功能,要求转账笔数不限,但是每天转账上限为5万元整。如果是当天的第1笔转账,那么只需考虑转账上限5万元和账户余额;如果是第n笔转账,还需增加限制,即转账总额不能超过5万元。因此,需要分别设计两个情况的等价类。（1)第1笔转账,可将转账功能划分为1个有效等价类和2个无效等价类,具体如下。①有效等价类:0<提现金额≤Min(50000,余额)。②无效等价类:提现金额≤0。③无效等价类:提现金额>Min(50000,余额)2.1

等价类划分法2.1.3实例:银行转账的等价类划分(2)第n笔转账,可以将提现功能划分为1个有效等价类和2个无效等价类,具体如下。①有效等价类:0<提现金额≤Min[(50000-已转账金额),余额]。②无效等价类:提现金额≤0。③无效等价类:提现金额>Min[(50000-已转账金额),余额]。根据上述分析,银行转账功能一共可以划分为6个等价类,如表2-8所示。表2-8银行转账的等价类表

2.1

等价类划分法2.1.3实例:银行转账的等价类划分建立了等价类表,接下来设计测试用例进行测试,假如现在银行账户中有60000元余额,则覆盖有效等价类的测试用例与覆盖无效等价类的测试用例如表2-9和表2-10所示。表2-9和表2-10共设计了6个测试用例,这些测试用例覆盖了全部等价类,基本可以检测出转账功能所存在的缺陷。表2-9覆盖有效等价类的测试用例

表2-10覆盖无效等价类的测试用例2.2边界值分析法边界值分析法是对软件的输入或输出边界进行测试的一种方法,它通常作为等价类划分法的一种补充,其理论基础是假定大多数的错误是发生在各种输入条件的边界上的,如果边界附近的取值不会导致程序出错,那么其他取值导致程序出错的可能性很小。边界值分析法是在等价类的边界上执行软件测试工作的,测试用例都是设计在等价类的边界上。在等价类中选择边界值时,如果输入条件规定了取值范围或值的个数,则要对边界值及其两边的数分别进行测试。例如,输入姓名(1~20个字符),要求测试0、1、2个字符和19、20、21个字符;某商品信息查询系统,每页最多显示10条商品信息,就应该准备足够的商品信息,使能够查询出9、10、11、1、0条商品记录。边界值和等价类的区别在于,边界值分析不是从某等价类中随便找一个作为代表,而是这个等价类的每个边界都要作为测试条件。2.2.1边界值分析法概述2.2边界值分析法如果软件要求输入或输出是一组有序集合,如数组、链表等,则可选取第一个和最后一个元素作为测试数据。如果被测试程序中有循环,则可选取第0次、第1次与最后两次循环作为测试数据。常见的边界值如下。(1)文本框接收字符个数,如用户名长度、密码长度等。(2)报表的第1行和最后1行。(3)数值元素的第1个和最后1个。(4)循环的第1次、第2次和倒数第1次、倒数第2次。边界值分析法只在边界取值上考虑测试的有效性,相对于等价类划分法来说,它执行起来更加简单易行,但缺乏充分性,不能整体、全面地测试软件,因此它只能作为等价类划分法的补充测试。2.2.1边界值分析法概述2.2边界值分析法在2.1.2节中,我们学习了三角形问题的等价类划分,在等价类划分中,除了要求输入数据为3个正数外,没有给出其他限制条件,如果要求三角形边长取值范围为1~10,则可以使用边界值分析法对三角形边界边长进行测试,在设计测试用例时,分别选择1、2、5、9、10作为测试数据,其中,选择5作为取值范围内的任意一点,三角形问题边界值分析测试用例如表2-11所示。2.2.2实例:三角形问题的边界值分析表2-11三角形问题边界值分析测试用例

2.2边界值分析法2.2.3实例:银行转账的边界值分析

在2.1.3节中,我们学习了银行转账案例的等价类划分,每天银行转账笔数不限,转账上限为5万元。分别设计两种情况的等价类:如果是当天的第1笔转账,金额数介于0和Min(50000,余额)之间;如果是第n笔转账,金额数介于0和Min[(50000-已转账金额),余额]之间。假设银行账号中的余额为4万元,在进行边界值分析时,如果是第一次转账,边界值为0和Min(50000,40000),即0和40000,则分别对0和40000两个边界值进行测试,分别取-1、0、1、20000、39999、40000、40001七个值作为测试数据;如果是第n次转账,已经转出10000元,账号余额为30000元,边

界

值

为0和Min(50000-10000,30000),即0和30000,则分别对0和30000两个边界值进行测试,分别取-1、0、1、20000、29999、30000、30001七个值作为测试数据;如果银行账号的余额大于5万元,就按上述方法设计测试用例。2.2边界值分析法2.2.3实例:银行转账的边界值分析

根据上述分析,设计银行转账边界值分析测试用例,如表2-12所示。由表2-12可知,一共设计了21个测试用例来测试银行转账金额的边界值,这些测试用例基本覆盖了全部边界值,具备检测边界可能存在的缺陷的能力。表2-12银行转账边界值分析测试用例2.3因果图法与决策表2.3.1因果图法1.因果图因为输入、输出之间的逻辑关系有时比较复杂,所以习惯用图示的方式及因果图来表达。通常,因果图中使用了一些简单的逻辑符号和直线将因(输入)和果(输出)连接起来,一般用ci

表示因,用ei表示果。各节点可以取“0”或“1”,其中“0”表示状态不出现,“1”表示状态出现。ci

与ei之间有恒等、非(~)、或(∨)、与(∧)4种关系,如图2-1所示。图2-1因果图2.3因果图法与决策表2.3.1因果图法1.因果图图2-1中展示了因果图的4种关系,每种关系的具体含义如下。（1）（2）（3）（4）恒等非(~)或(∨）与(∧)若原因出现,则结果出现;若原因不出现,则结果也不出现。若原因出现,则结果不出现;若原因不出现,则结果出现。若几个原因中有一个出现,则结果出现;若几个原因都不出现,则结果不出现。只有几个原因都出现,结果才出现;若其中有一个原因不出现,则结果不出现。2.3因果图法与决策表2.3.1因果图法1.因果图为了表示原因与原因之间,结果与结果之间可能存在的约束条件,在因果图中可以附加一些表示约束条件的符号。某一软件用于统计体检信息,在输入个人信息时,性别只能输入男或女,这两种输入不能同时存在,而且如果输入性别为女,那么体检项就会受到限制。这些依赖关系在软件要求测试中被称为“约束”,从输入(原因)考虑,有4种约束,包括互斥(exclusiveor,E)、包含(in,I)、唯一(only,O)、要求(request,R);从输出(结果)考虑,还有一种约束屏蔽(mask,M)。约束的类别可分为4种,在因果图中,用特定的符号表明这些约束关系,如图2-2所示。图2-2多个输入之间的约束符号

2.3因果图法与决策表2.3.1因果图法1.因果图图2-2展示了多个输入之间的约束符号,这些约束关系的含义如下。（2）a、b和c中至少有一个必须是1,即a、b、c不能同时为0。E(互斥,异)（1）a和b中最多只能有一个为1,即a和b不能同时为1。I(包含,或）（3）a和b中有且仅有一个为1。O(唯一)（4）a和b必须保持一致,即a为1时,b也必须为1,a为0时,b也必须为0。R(要求)2.3因果图法与决策表2.3.1因果图法1.因果图上面这4种都是关于输入条件的约束,除了输入条件,输出条件也会相互约束,输出条件的约束只有一种M(mask,屏蔽),在因果图中,使用特定的符号表示输出条件之间的屏蔽约束关系,如图2-3所示。图2-3输出条件之间的屏蔽约束关系

2.3因果图法与决策表2.3.1因果图法2.使用因果图法设计测试用例的步骤使用因果图法设计测试用例需要经过以下几个步骤。（1)分析程序规格说明书所描述的内容,哪些是原因(输入条件或输入条件的等价类),哪些是结果(输出条件),并给每个原因和结果赋予一个标识符。（2)分析软件规格说明描述中的语义,找出原因与结果之间,原因与原因之间的对应关系,并根据这些关系画出因果图。（3)由于语法与环境的限制,有些输入与输入之间、输入与输出之间的组合情况是不可能出现的,为表明这些特殊情况,在因果图上用一些记号标明约束或限制条件（4)将因果图转换为决策表。决策表将在2.3.2小节中讲述。(5)把决策表的每一列拿出来作为依据,根据决策表设计测试用例。2.3因果图法与决策表2.3.2决策表决策表也称为判定表,其实质就是一种逻辑表。在程序设计发展初期,决策表就已经被当作程序开发的辅助工具来帮助开发人员整理开发模式和流程,因为它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确,利用决策表可以设计出用例集合。为了让读者理解前面所述的因果图和决策表的联系,下面通过一个常见的自动售货机的例子来说明。其规格说明如下:自动售货机可以接收1元、5元、10元等类型的纸币,投入金额不限。售货机内现有可乐和橙汁两种商品,价格均为3元,投入钱币之后按下“可乐”或“橙汁”按钮。若顾客投入的金额不足,则一个显示“金额不足”的红灯亮;若金额足够,则相应的饮料就送出来。同时更新投入售货机内金额的余额,顾客可继续选购,直到按下“结束购买”按钮。2.3因果图法与决策表2.3.2决策表根据上述规格说明分析出原因和结果及中间过程(节点)。原因如下。(1)未投币。(2)金额≥3元。(3)金额<3元。(4)按下“可乐”按钮。(5)按下“橙汁”按钮。(6)结束购买。结果如下。(1)“金额不足”灯亮。(2)送橙汁。(3)送可乐。(4)更新余额。(5)退钱。2.3因果图法与决策表2.3.2决策表分析出原因和结果后,接下来画出其因果图,如图2-4所示,其中设计2个中间状态节点。(1)按下“橙汁”或“可乐”按钮。(2)余额大于等于0。图2-4自动售货机因果图

2.3因果图法与决策表2.3.2决策表由于2与3,4与5不能同时发生,分别加上约束条件E。22与24、23与24为恒等关系,21与22,21与23为M约束关系,即若21为1,则22和23必为0,详细情况就不一一列举了,请读者查看图2-4。因果图法是一种非常有效的黑盒测试方法,它能够生成没有重复性的且发现错误能力强的测试用例,而且对输入、输出同时进行了分析。接下来将因果图转换为决策表,如表2-13所示。表2-13自动售货机决策表2.3因果图法与决策表2.3.2决策表在表2-13中,结果中的24行表示自动更新余额,与22和23列存在约束关系。阴影部分表示因违反约束条件而不可能出现的情况(删去)。第33列是条件6成立就表示结束,自动售货机退钱,其他条件下售货机不会退钱。最后可根据剩下的9列作为确定测试用例的依据。删除不成立的列之后,得到表2-14。表2-14删除不成立的列之后的决策表2.3因果图法与决策表2.3.2决策表再通过观察发现,只要未投币或余额少于3元,都是只输出21项(即余额不足),这样可以把第6、7、10、11列归为1列,将26、27归为1列,化简之后剩下5列。把序号和中间结果删除后,只剩下条件和结果,如表2-15所示。表2-15化简后的决策表因果图和决策表都可以反映复杂的输入/输出关系,两者各有特点,因果图以图例的形式直观地反映出输入之间及输入与输出之间的逻辑关系。相比于因果图,决策表能够把复杂的问题按各种可能的情况一一列举并形成表格,简明且易于理解,也能避免遗漏,因此,对于多逻辑条件下执行不同操作的情况,决策表使用得更多。2.3因果图法与决策表2.3.3实例:三角形问题决策表在测试用例中,三角形问题是一个经典案例,这里继续使用三角形讲解决策表的构建与测试用例的设计。三角形的三条边能否构成三角形?如果能,那么是构成一般三角形、等腰三角形还是等边三角形?据此分析,三角形问题有4个原因———是否构成三角形,a=b?,b=c?,c=a?;有5个结果———非三角形、不规则三角形、等腰三角形、等边三角形、不符合逻辑,据此写出初步决策表,如表2-16所示。表2-16三角形问题初步决策表

2.3因果图法与决策表2.3.3实例:三角形问题决策表接下来进行化简,在表2-16中的规则9~16列中,只要c1

为N,c2、c3、c4

取任何值结果都是e1,因此,c2、c3、c4

是无关项,可以将规则9~16列合并成一条规则。规则2、3、5列的用例不符合逻辑,无法构建,因此将其删除。这样化简后的结果剩下6种情况:1个等边三角形,3个等腰三角形,1个不规则三角形和1个无法构成三角形。这样就构成了6个测试用例,整理后的决策表如表2-17所示。表2-17整理后的决策表2.3因果图法与决策表2.3.3实例:三角形问题决策表根据表2-17写出6个测试用例,如表2-18所示。表2-18测试用例2.4正交实验设计法2.4.1正交实验设计法概述正交实验设计(orthogonalexperimentdesign)法是一种研究多因素多水平的设计方法,它是根据正交性从全面实验中挑选出部分有代表性的点进行实验,这些有代表性的点具备了“均匀分散,齐整可比”的特点,正交实验设计法是一种高效率、快速、经济的实验设计方法。日本著名的统计学家田口玄一将正交实验选择的水平组合列成表格,称为正交表。当软件测试用例数量太多时,一个非常自然的想法就是从中选择一部分有代表性的影响因素的组合进行实验。但是对于实验设计知识较少的实际工作者来说,如何有效地选择影响因素还是比较困难的。2.4正交实验设计法2.4.1正交实验设计法概述正交实验设计法包含3个关键因素,具体如下。指标因子因子的状态指标是判断实验结果优劣的标准。因子也称为因素,是指所有影响实验指标的条件。因子的状态也称为因子的水平,它指的是因子变量的取值。2.4正交实验设计法2.4.1正交实验设计法概述利用正交实验设计法设计测试用例时,可以按照以下步骤进行。（1)提取因子,构造因子状态表。分析软件的规格需求说明,得到影响软件功能的因子,确定因子可以有哪些取值,即确定因子的状态。例如,某高校学生成绩查询软件,设置完系、课程后,要通过“性别”“班级”“成绩”这3个查询条件对某门课程的成绩分布、男女比例或班级比例进行人员查询。性别分为“男”“女”,班级分为“1班”“2班”,成绩分为“及格”“不及格”。3个查询条件称为被测因素,每个因素有两个取值,称为水平值,所以全部测试用例的个数是2×2×2=8。据此构造该软件运行功能的因子-状态表,如表2-19所示。表2-19因子-状态表2.4正交实验设计法2.4.1正交实验设计法概述(2)加权筛选,简化因子-状态表。在实际的软件测试中,软件的因子及因子的状态会有很多,每个因子及其状态对软件的作用也大不相同,如果把这些因子及状态都划分到因子-状态表中,那么最后生成的测试用例会相当大,从而会影响软件测试的效率。因此,需要根据因子及状态的重要程度进行加权筛选,选出重要的因子与状态,以简化因子-状态表。加权筛选就是根据因子或状态的重要程度、出现频率等因素计算因子和状态的权值,权值越大,表明因子或状态越重要,而权值越小,表明因子或状态的重要性越小。加权筛选之后,可以去掉一部分权值较小的因子或状态,使得最后生成的测试用例集缩减到允许的范围。2.4正交实验设计法2.4.1正交实验设计法概述(3)构建正交表,设计测试用例。正交表的表示形式为L行数(水平数因子数)例如,L4(23)是最简单的正交表,它表示该实验有3个因子,每个因子有两个状态,也称为水平,可以做4次实验,如果用0和1表示每个因子的两种状态,则该正交表就是一个4行3列的表,如表2-20所示。表2-20L4(23)正交表

2.4正交实验设计法2.4.1正交实验设计法概述(3)构建正交表,设计测试用例。上述成绩查询的例子中3个因子为性别、班级和成绩,用户名、密码和验证码都有两种状态,正常需要设计23=8个测试用例,而使用正交表只需要设计4个测试用例就可以达到同样的测试效果,因此,正交实验法是一种高效、快速、经济的实验设计方法。在表2-21中,3个因子的状态都为2,这样的正交实验比较容易设计成正交表,但在实际的软件测试中,大多数情况下软件有多个因子,每个因子的状态数目不一定相同,即各列的水平数不等,这样的正交表称为混合正交表,如L8(24

×41),这个正交表表示有4个因子有2种状态,有1个因子有4种状态。混合正交表可以通过以下方式确定测试用例的数目。2.4正交实验设计法2.4.1正交实验设计法概述(3)构建正交表,设计测试用例。①通过以下网址确定。/techsup/technote/ts723_Designs.txt。https://www.york.ac.uk/depts/maths/tables/orthogonal.htm。②参考其他数理统计方面的书籍。举例说明,打开/techsup/technote/ts723_Designs.txt,可以查询到不同因子数、不同水平数的正交表的值。查询24

×41

的正交表对应的n=8,结果如下。2.4正交实验设计法2.4.1正交实验设计法概述(3)构建正交表,设计测试用例。换成L8(24

×41)正交表,如表2-21所示。表2-21L8(24

×41)正交表

2.4正交实验设计法2.4.2实例:打印功能正交实验设计假设某打印软件的功能设置有以下4个。(1)打印范围:分全部、当前幻灯片、给定范围3种情况。(2)打印方式:有单面、双面(翻转长边)、双面(翻转短边)、手动双面4种情况。(3)打印颜色:有颜色、灰度、黑白3种设置。(4)打印方向:有横向、纵向两种情况。2.4正交实验设计法2.4.2实例:打印功能正交实验设计将其功能设置写成因素状态表,如表2-22所示。将文字描述转为字母符号,得到符号因素状态表,如表2-23所示。表2-22

因素状态表表2-23符号因素状态表2.4正交实验设计法2.4.2实例:打印功能正交实验设计分析表2-23,发现打印软件一共有4个被测参数,每个被测参数不完全一样,A和C有3个,B有4个,D有2个。结合分析结果选择正交表的依据如下。（1）正交表的因素≥4。（2）正交表至少有4个因素的水平数≥2。（3）行数取最小值。查表得到L16(45),如下所示。2.4正交实验设计法2.4.2实例:打印功能正交实验设计用字母符号替换该表中的状态,得到新的正交表,如表2-24所示。表2-24正交表

2.4正交实验设计法2.4.2实例:打印功能正交实验设计通过观察发现,4个因素只有一个的水平值是4,其他都小于等于3,所以设计用例行数为4×3=12,忽略第13~16行的测试用例。第5列不含测试因素,因此将其删除,最后把表中剩余的数字按状态均匀分布的原则填满。根据上述分析,整理后得到新的正交表如表2-25所示。表2-25新的正交表

2.4正交实验设计法2.4.2实例:打印功能正交实验设计根据表2-25写出12个测试用例,下面举例说明,如表2-26所示。表2-26测试用例1小结本模块主要讲解了黑盒测试常用的技术方法,包括等价类划分法、边界值分析法、因果图与决策表、正交实验设计法。读者要掌握每种测试方法的原理和测试用例的设计方法,这对后续学习实际的软件项目测试很有帮助。模块3白盒测试3.1用例设计3.2JUnit单元测试3.3使用PlantUML绘制流程图3.1用例设计白盒测试法大致分为静态分析方法和动态分析方法两大类。静态分析是一种不执行程序而进行测试的技术,主要目的是检查软件的表示和描述是否一致。动态分析是当软件系统在模拟或真实的环境中执行前、执行过程中和执行后,对其进行行为分析,它显示了一个系统在检查状态下是否正确。在动态分析技术中,最重要的技术是逻辑和路径测试。3.1用例设计下面分别按逻辑覆盖方法和路径测试方法介绍语句覆盖、判断覆盖、条件覆盖、判断条件覆盖、条件组合覆盖和路径测试覆盖方法。按覆盖程度的大小进行排列的顺序是:路径测试覆盖>条件组合覆盖>判定条件覆盖>条件覆盖>判断覆盖>语句覆盖。下文表达式和图中所涉及的符号说明如下。（1)T表示True,F表示False。（2)A和B分别表示关系表达式。（3)A||B表示A和B表达式之间是或的关系。3.1用例设计1.语句覆盖语句覆盖是使程序中每一条语句最少执行一次,但其覆盖标准无法发现判定中逻辑运算的错误。测试用例条件:A||B=T。假设存在如下程序逻辑,写出伪代码。IF(A||B)THEN执行P2路径代码;ELSE执行P3路径代码;ENDIF将伪代码转换成流程图,如图3-1所示。图3-1语句覆盖流程图3.1.1逻辑覆盖法3.1用例设计1.语句覆盖假设A=a>1&&b==0,B=a==2||x>1,则得出表3-1所示的语句覆盖分析表。表3-1语句覆盖分析表语句覆盖不用考虑语句之间存在的逻辑关系,因此不能发现其中存在的逻辑缺陷,举例来说,如果上述表格中的用例判定把a==2||x>1错写成a==2&&x>1,那么按表格的a、b、x的输入值,判定结果没有改变,无法发现判定式的错误。3.1.1逻辑覆盖法3.1