《程序功能测试》课件 项目1-3 测试需求分析-测试用例设计

项目一测试需求分析12任务1初识测试任务2分析测试需求初识测试任务131. 识别软件中的缺陷。2. 了解测试的概念及作用。3. 掌握测试的分类及基本流程。4测试人员需要对缺陷及测试的相关概念有初步的认知，以便为后续测试任务的开展奠定基础。因此，本任务需要测试人员能够识别基本的缺陷，并确认其类型、严重程度及优先级；能了解常见的测试分类，并针对不同的测试场景选择适合的测试方法。5一、缺陷的概述1. 缺陷相关案例（1）微软蓝屏事件2024年7月19日，微软Windows系统因安全服务商CrowdStrike的软件错误更新，叠加系统兼容问题，引发全球大规模蓝屏事件。67此次微软蓝屏事件波及不少国家和地区，影响全球近千万台使用Windows操作系统的设备，导致航空公司、银行、电信公司、媒体机构、健康医疗机构等陷入混乱。在这次事件中，全球范围内的许多用户在安装了最新的安全补丁后遇到系统崩溃，计算机显示蓝屏错误，如图所示，无法正常启动或运行。这一缺陷主要源于安全补丁中包含了与Windows操作系统中某些组件不兼容的驱动程序，触发了系统级的错误保护机制，从而引发了“蓝屏死机”问题，而该错误在补丁发布前未能被充分检测到，且在兼容性测试中未及时发现。8微软蓝屏事件9（2）12306网站崩溃自2014年12月21日起，12306网站开始销售2015年除夕火车票。作为官方网络购票渠道，网站随即迎来抢购火车票的高峰。但与往年类似，这款斥资开发的网站未能抵御流量压力，页面刷新缓慢，连续查询时提示“刷新失败”，甚至在关键时刻突然强制用户退出登录。无独有偶，2023年9月15日，正值中秋国庆黄金周铁路售票高峰期，大量旅客通过12306网站和App抢购火车票，再次遭遇系统崩溃故障。据网友反映，12306账号反复登录失败、乘车人列表加载不出来、余票显示与实际库存不一致等问题频发，如图所示。10从缺陷的角度分析，12306网站频频崩溃，是面对瞬时过大的访问量，服务器负载超出设计上限的性能缺陷。12306网站崩溃2. 缺陷的定义缺陷是指软件产品中存在的与预期功能或规范不符的问题或错误。这些缺陷可能导致软件行为偏离设计要求，影响用户体验，甚至引发系统崩溃或安全漏洞。IEEEStd729—1983标准对缺陷有明确界定：从产品内部来看，缺陷是软件开发或维护过程中存在的错误、疏漏或逻辑偏差；从产品外部来看，缺陷是系统未能实现预设功能，或功能运行结果违背用户需求的现象。更具实践指导意义的说法如下：执行测试用例过程中，若软件实际运行结果与预期结果不一致，则判定存在缺陷。实践中，人们常用Bug指代软件或程序中的缺陷。113. 缺陷的类型（1）功能缺陷功能缺陷是指软件未实现需求规格说明书中指定的功能，或功能实现与用户期望、业务需求不符。（2）性能缺陷性能缺陷是指软件运行速度慢、响应时间长，或在高负载或大数据量场景下表现异常。12（3）兼容性缺陷兼容性缺陷是指软件无法在预设的操作系统、浏览器、设备上正常运行，或与其他应用程序或系统不兼容。（4）界面缺陷界面缺陷是指用户界面不够直观，导致用户难以理解和使用软件。（5）安全缺陷安全缺陷是指软件存在可能被黑客、恶意程序等利用或攻击的安全隐患。134. 缺陷的严重程度和优先级（1）缺陷的严重程度用于描述缺陷对软件质量的影响大小，通常可以分为致命、严重、一般、建议4个级别，具体内容见下表。14缺陷的严重程度及具体内容（2）缺陷的优先级用于表示修复缺陷的紧迫程度，通常分为立即解决（P1）、高优先级（P2）、中优先级（P3）、低优先级（P4）4个级别，具体内容见下表。15缺陷的优先级及具体内容一般而言，缺陷的严重程度与优先级关联性较强，如某种特定操作会引发系统崩溃的缺陷，那么该缺陷的严重程度为致命，优先级通常为P1，即严重程度高的缺陷往往优先级也高。然而，并不是所有严重程度高的缺陷都会立即被赋予最高优先级。相反，有些严重程度较低的缺陷可能会因为特定的原因而被赋予较高的优先级。严重程度与优先级作为缺陷的两个重要属性，将出现在缺陷报告中，为修复缺陷的开发人员提供重要参考。16二、测试的概述1. 测试的简介软件测试的发展过程经历了几个重要的阶段，如图所示，每个阶段都标志着软件测试在理念、方法和技术上的进步。以下是软件测试发展过程中的6个关键时期。17软件测试的发展过程（1）调试时期早期的软件大多是结构简单、功能单一的小规模软件，开发人员通常在编写代码的过程中“顺便”进行一些简单的测试，以确保程序能够正常运行。此时的测试几乎可以等同于调试，目的是验证程序是否满足了基本需求。（2）证明时期1973年，软件测试领域的先驱BillHetzel博士认为：“软件测试是对程序或系统能否完成特定任务建立信心的过程。”也就是说，此时的软件测试重点在于验证软件是正确的。18（3）破坏时期1979年，软件测试领域的代表人物G.J.Meyers博士认为：“软件测试是为了发现错误而执行程序的过程。”也就是说，此时的软件测试不再着眼于验证软件是正确的，而是首先认定软件是错误的，然后用逆向思维去发现尽可能多的错误。19（4）标准时期经过20世纪70年代的百家争鸣，20世纪80年代软件测试终于正式走上历史舞台，拥有了属于自己的行业标准。1983年，电气与电子工程师学会（IEEE）对软件测试做出了定义：软件测试是使用人工或自动的手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。此后，软件测试逐渐成为一门专业，需要运用专门的方法和手段，需要专门人才和专家来开展。20（5）预防时期软件测试行业不断发展，形成了越来越多的优秀理念与技术。不断涌现的各种测试工具，掀起了自动化测试的浪潮，其应用程度不断提高。20世纪90年代末兴起的敏捷开发模式，使得软件的开发与测试的界限逐渐模糊，如测试驱动开发（test-drivendevelopment，TDD）中提到的“开发未动，测试先行”，将测试活动前置，通过预防手段加强质量管理。21（6）智能时期近年来，随着人工智能（AI）、大数据、云计算等新兴技术的广泛应用，软件测试行业也迎来了新的发展机遇。AI测试及大数据测试等智能化测试手段可以自动生成测试用例、预测缺陷、优化测试策略，提高测试的准确性和效率，为软件质量的保障和提升发挥重要作用。222. 测试的作用对于开发人员而言，测试用于确保软件质量，避免潜在错误，可提供反馈以改进设计和修复问题。对于测试人员而言，测试可用于验证软件是否满足客户需求，揭示潜在问题，提高软件质量。对于用户而言，测试可以确保软件满足期望，可靠且安全，从而提高用户体验和满意度。23三、测试的分类1. 按照测试技术分类（1）黑盒测试黑盒测试也称功能性测试，其目的是检查软件或程序的各种功能能否实现。黑盒测试，顾名思义是将软件或程序看作一个只有输入与输出的黑盒子，只关心输入的数据经过处理后能否输出预期的结果，并不关心软件或程序的内部如何实现，如图所示。24黑盒测试（2）白盒测试白盒测试也称结构性测试，其目的是检查软件或程序内部的逻辑处理是否正确。白盒测试，顾名思义是将软件或程序看作一个透明的盒子，测试人员可以清楚地了解软件或程序的内部结构，如图所示。25白盒测试（3）灰盒测试灰盒测试是一种介于黑盒测试和白盒测试之间的软件测试方法，它关注输出对于输入的正确性，同时也关注程序内部表现，但这种关注不像白盒测试那样详细。这种方法结合了黑盒测试的用户视角和白盒测试的内部知识，使得测试人员可以利用程序内部的一些信息，来设计测试用例，提高测试的效率和有效性。262. 按照测试目的分类（1）功能测试功能测试是众多测试类型中最基本的测试，主要根据需求规格说明书或者测试需求，验证被测软件或程序的功能是否符合需求规格。换句话说，功能测试需要验证的是软件或程序“能不能用”。（2）性能测试性能测试用来测试软件在不同使用场景下的运行性能，评估软件在不同负载条件下的响应时间、吞吐量和资源利用率等性能指标。换句话说，性能测试需要验证的是软件“在某种特定场景下”能否正常使用。27（3）兼容性测试兼容性测试主要检验软件在不同硬件平台、操作系统、应用软件环境中是否能够顺畅运行，并确保其交互性和信息共享功能的稳定性与可靠性。换句话说，兼容性测试需要验证的是软件“在某种特定环境下”能否正常使用。28（4）GUI测试GUI测试主要用于评估软件的用户界面设计、交互流程是否符合用户的习惯和需求，以提高用户体验和满意度。换句话说，GUI测试需要验证的是软件“好不好用”。（5）回归测试回归测试是指修改程序代码后，测试人员重新进行测试，以确认原有的缺陷已经消除并且没有引入新的缺陷。回归测试是测试过程中确保软件持续稳定性和一致性的重要环节。293. 按照测试阶段分类（1）单元测试单元测试也称模块测试，是对软件中最小可测单元进行的测试，最小可测单元可以是一个模块、一个类、一个方法等，其目的在于验证软件各个单元模块的正确性。单元测试通常由开发人员自行验证。（2）集成测试集成测试也称组装测试，通常是将已经通过单元测试的模块组合在一起开展的测试，重点测试模块间的接口功能是否正确。30（3）系统测试系统测试是对已经完全集成好的软件进行的整体性测试，包括对其功能、性能、兼容性、硬件适配、网络等全方位的测试，旨在验证软件是否满足用户需求。（4）验收测试验收测试旨在向软件的需求方展示该软件满足其用户需求，往往会有非测试人员参与验收测试。314. 按照被测软件或程序是否运行进行分类按照被测软件或程序是否运行分类，可以将测试分为动态测试与静态测试。（1）动态测试动态测试是指在软件运行时进行的测试，它需要实际执行程序代码，重点关注软件的实际行为是否符合预期。（2）静态测试静态测试是指在不运行代码的情况下检查和评审软件源码、文档和设计，其主要目的是发现并消除错误或不一致之处，从而提高软件质量。32四、测试的基本流程1. 分析测试需求分析测试需求是开启测试的起点与基础。当测试人员或测试团队接收到测试任务后，首先需要对待测目标进行测试需求的提取与分析：有时测试需求为软件或程序的全部需求，有时测试需求仅为软件或程序的部分需求，因此，需提前明确测试对象及测试工作的范围与重点。通常情况下，测试需求来源于需求规格说明书，其中详细描述了软件各项功能需要达成的目标，为测试的各项工作开展提供依据，换句话说，没有测试需求就无法判断测试结果是否正确。33在分析测试需求的过程中，测试人员还可以发现需求中不合理的地方，如需求描述不完善、有歧义、优先级安排不够合理等。此时，大多数公司会安排测试需求评审会议，通过与项目相关人员沟通，确定所有的测试需求都是可核实的、明确的、可测试的，为后续的测试计划制订以及测试用例设计打好基础。342. 制订测试计划制订测试计划的目的在于制订一个完整且详细的工作计划，为后续的测试工作开展提供指导。测试计划中通常包括测试目标、测试范围、测试方法、时间安排、资源分配、风险评估等内容。由于测试计划的制订往往需要丰富的测试经验用于需求评估、资源整合、风险预测等方面，因此，通常由有经验的测试负责人或管理者负责制订。经验尚浅的测试人员只需了解测试计划包括哪些内容，通过测试计划掌握并组织自己的测试任务即可。随着经验的不断积累，逐步具备独立制订测试计划的能力。353. 设计测试用例测试用例是测试过程中最为核心的内容。无数的经验表明，盲目地开始测试并不是最好的做法，提前为不同功能模块、功能点设计好测试用例（包括测试步骤、测试数据、预期结果等），这样可以有效地指导后续测试的执行，提高测试效率。测试用例示例见下表。36测试用例示例4. 执行测试执行测试其实就是按照测试用例进行测试的过程，这是测试人员最主要的活动阶段，大多数的测试新手都是从执行测试入门的。测试执行过程看似简单，仅需按照测试用例中描述的测试数据和测试步骤执行操作即可，但要想提升测试执行效率，还应掌握一些策略和技巧。同时，执行测试的目的是寻找软件或程序中的缺陷，因此，测试人员在执行测试过程中应做好测试结果的记录，若遇到缺陷则应做好缺陷的跟踪与管理。375. 撰写测试报告在测试阶段的末期需要撰写测试报告，用于对整个测试活动的总结、测试过程的归纳、测试数据的统计与分析、被测目标的质量评估。测试报告将给出被测目标是否符合发布标准的结论，为项目相关人员的发布决策提供参考。38分析测试需求任务2391. 能提取测试需求。2. 能对测试需求进行分析。40项目组计划开发iceCMS，以便于用户管理网站的文章和资源等多种内容。系统包括内容管理功能，允许用户自定义文章等内容并进行增、删、改、查操作；用户管理功能，用于管理后台用户，包括添加用户、删除用户、修改用户和分配权限；数据统计功能，用于分析网站访问量和用户行为；资源管理功能，方便用户快速整合各类资源数据。此外，iceCMS还将提供圈子管理功能，以社区互动的形式提升用户体验。iceCMS用于提高内容发布和管理的效率，同时提升网站的用户体验。iceCMS的首页如图所示。41本任务要求对iceCMS进行测试需求分析，以创建文章功能模块为例，明确测试任务的范围、类型、标准等，为后续测试计划制订与测试用例设计奠定基础。42iceCMS的首页软件需求定义的是目标软件系统要实现的功能，而业界并没有关于测试需求的明确定义，通常情况下认为测试需求是在测试开展初期确定的测试范围。获取测试任务后，测试人员需分析测试需求，明确被测对象的功能与用途，主要包括以下内容。431.明确哪些功能点需要测试，哪些功能点不需要测试。2.明确哪些功能点的优先级高，哪些功能点的优先级低。3.明确每个功能点需要测试到什么程度。4.了解需要开展哪些类型的测试。测试需求分析是软件测试的重要环节，它涉及对软件需求的深入理解、分析和细化。通过解决上述问题，可以对测试的规模、复杂度、风险等进行初步的评估，以便为后续的测试计划制订、测试用例设计等测试工作提供准确、全面的指导。44一、测试需求的提取1. 原始需求原始需求通常来自客户或业务部门的初步想法或要求，可能是非正式的、模糊的或高层次的描述，没有具体的技术细节或实现方式。2. 需求规格需求规格说明书是对原始需求进一步详细化和明确化的文档，描述了系统应具备的功能要求、性能要求、用户界面设计、数据流程等方面的详细信息，是开发团队和测试团队之间的共同参考依据。45针对上述原始需求“客户需要一个书架”，需求规格说明书可以定义为客户需要一个三层、每层至少能承重15kg、颜色为深棕色并且适合放在办公室特定角落的书架（高度为80cm、每层宽度为60cm、深度为30cm）。这些信息构成了需求规格说明书，详细说明了书架应具备的功能以及外观设计，需求规格如图所示。46需求规格3. 开发需求开发需求是从需求规格中提取出具体实现细节和技术要求的任务清单，一般有明确的实现方式，包括技术栈的选取、数据库的设计等。针对上述需求规格，需要购买足够多的木材和其他材料，确保它们的质量能够承受规定的图书重量；需要选择合适的工具和技术来切割、打磨及组装木材；还需要安排时间对木材上色和进行干燥处理。这些步骤构成了开发需求，即实际建造书架所需的具体工作和资源，开发需求如图所示。47开发需求4. 测试需求测试需求需要从测试角度考虑，重点关注可度量、可实现、可验证等几个方面。在进行测试需求提取时，由于存在参考多个需求来源的情况，可能存在重复和冗余，因此，需要对其进一步整理，如删除重复的测试需求、合并相似的测试需求等。48二、测试需求的分析通常情况下，测试需求需要进一步细化为若干独立的测试项或测试点，每个测试页或测试点仅包含针对一个功能点的测试，便于后续测试用例的设计以及测试细节的确认。测试需求的细化分析过程可以从质量要求出发来开展。质量要求可参考软件质量模型，如图所示为软件质量模型（ISO/IEC25010），该模型描述了功能适用性、性能效率、兼容性、交互能力、可靠性、安全性、可维护性、灵活性、无害性9个质量特性，每个质量特性都包含一系列子特性，用于更详细地描述软件在该特性方面的表现。4950软件质量模型（ISO/IEC 25010）1. 功能性测试需求分析功能性是软件质量模型的若干质量特性中最为基础、最为核心的一个特性，因此，功能性测试需求分析也是测试需求分析的重点。针对从各项需求来源中提取到的测试需求，此处将侧重功能性需求，并进行进一步的分析与细化。根据iceCMS的需求规格说明书可知，该系统包含4个功能模块，分别是内容管理、圈子管理、资源管理、用户管理。针对用户管理模块，可进一步细化，分为管理员信息与角色管理，其中角色管理可进一步细化，分为增加角色、删除角色、编辑角色、查询角色4个子功能需求。51根据需求文档的描述，针对上述测试项还可进行更加细致地分析，这里不再继续展开说明。总的来讲，测试人员可以根据需求规格说明书中的系统功能结构图或根据需求描述自行绘制系统功能结构图，一步步深入分析并细化各个测试需求，直至得到一系列可验证、可测试的测试项。522. 非功能性测试需求分析对于软件质量模型中提及的除功能适用性之外的兼容性、可靠性、安全性等质量特性，可统称为非功能性质量特性。对于不同的软件系统，非功能性的质量要求或多或少都会存在，但会因不同的项目类型、应用领域、用户群体而产生较大差异。53项目二测试计划制订54制订测试计划任务

551. 了解测试计划的概念。2. 掌握根据需求文档设计测试计划的方法。3. 能为iceCMS内容管理系统制订测试计划。56测试团队在开展iceCMS内容管理系统的测试任务时，发现需要根据测试任务确定一系列问题，包括该测试任务的测试时间、人员投入、责任分工、资源工具、风险评估等。本任务要求为iceCMS内容管理系统项目制订测试计划，覆盖程序功能测试。测试计划将描述各测试阶段的工作职责、所需资源、责任分配及预期结果，通过规范化的测试流程，给出解决测试问题的策略，提高测试效率。57一、测试计划的基本概念测试计划是对测试工作进行精心规划和部署的重要文档，它对测试活动的顺利实施至关重要。IEEE软件测试文档标准29119中定义：“测试计划是一份文档，它详细描述了软件测试活动的范围、目标、策略等关键要素，并作为软件验证与确认活动整体计划的一部分。”测试计划是指导软件测试工作的重要文档，它对测试工作进行全面细致的规划和安排。5859测试计划类似旅行计划。在旅行之前，需要规划路线和准备必需品，甚至要提前考虑可能遇到的问题和解决方案。同样，在进行软件测试时，也需要制订计划来确保一切按照预期进行。测试计划包含了测试的所有重要信息，比如要测试什么、怎样测试、用什么工具测试，以及期望得到的结果。这就像是一份详尽的旅行清单和行程表，用来确保旅途中的每一步都清晰明确，从而使整个测试过程更加顺利和高效。二、测试计划的内容1. 测试目标测试目标用来明确测试的目的，比如要检查软件的性能、安全性以及易用性等。2. 测试范围测试范围用来确定要测试软件的哪些部分。3. 测试方法测试方法是测试时采用的技术手段及所需工具。604. 时间安排时间安排是制定一张时间表，明确每个测试任务的开始时间、结束时间。5. 资源分配资源分配用来确定需要多少人力资源、环境资源、工具资源等参与具体的测试任务。人力资源主要描述测试所需人员及职责。环境资源主要描述硬件资源和软件运行环境；工具资源主要描述辅助测试的软件工具等。6. 风险评估风险评估是预先识别可能遇到的问题并制定相应的解决措施。61三、测试计划的模板测试计划的制订通常通过模板来完成，由于不同公司的业务侧重点不同，采用的测试计划模板也略有差别。常见的测试计划模板如下。626364项目三测试用例设计6566任务1初识测试用例任务2使用等价类划分法设计测试用例任务3使用边界值分析法设计测试用例任务4使用决策表法设计测试用例任务5使用因果图法设计测试用例初识测试用例任务1671. 了解测试用例的基本概念。2. 能设计测试用例。68测试团队在开展iceCMS内容管理系统的测试任务时，需要根据需求规格说明书设计和实施一套准确且全面的测试用例，并制定一套完整的测试步骤。这样可以更加系统地检测软件中的问题并协助开发团队修正，从而提升软件的整体质量。本任务要求为iceCMS内容管理系统项目首页上方的导航部分设计测试用例，包括用例编号、用例标题、测试目的、前置条件、测试步骤、预期结果等，以提升软件测试效率和质量，确保软件产品满足用户需求和业务目标。69一、测试用例的概述根据IEEE标准对测试用例的正式定义：测试用例是一组输入数据、执行前提条件和预期结果，其目的是验证被测软件或系统的一项特定功能。测试用例是设计一个场景，使软件在该场景下按照与需求规格说明书一致的期望结果运行。它是根据测试需求分析得出的、用于功能验证的输入和输出的组合，是软件测试的基础工作产物。70二、测试用例设计规范一个好的测试用例应包含两部分内容：一部分用于分类、整理、跟踪和维护测试用例，具体包括功能模块、项目编号、项目名称、测试人员、项目经理、版本号、测试日期等与需求无直接关联的内容；另一部分是测试用例的核心，是根据需求设计的内容，具体如下。用例编号：唯一标识每个测试用例的编号。用例标题：简明描述测试用例。测试目的：明确测试用例的目标或者验证测试用例的功能。前置条件：测试开始前必须满足的条件。7172测试步骤：详细的操作步骤，包括输入数据和执行的操作。预期结果：执行测试步骤后期望得到的结果。实际结果：执行测试步骤后实际得到的结果，或者写明是否与预期结果一致。一般来说，测试人员会根据功能模块将测试用例整理成表格形式，见下表。测试用例设计模板使用等价类划分法设计测试用例任务2731. 掌握等价类划分法的内容和步骤。2. 能运用等价类划分法设计测试用例。74测试团队在开展iceCMS内容管理系统的测试任务时，已掌握测试用例包含的内容，但面对测试用例数量较多的测试对象时，无法实现穷举。因此，需要一种能精简测试用例的方法——等价类划分法，以减少测试用例数量，同时保证测试的全面性。本任务要求采用等价类划分法为iceCMS内容管理系统项目中充值中心功能设计测试用例，确保用最少的测试用例覆盖所有测试场景，提高测试效率。7576一、等价类划分法概述等价类划分法是把所有可能的输入数据划分为若干部分，从每一部分中选取少量具有代表性的数据作为测试数据。划分后，每一类的代表性数据在测试中的作用与该类中的其他值相同。等价类划分法旨在以最少的测试用例覆盖最多的测试场景，避免冗余，提高测试效率。等价类划分法类似将一堆不同的苹果按照特点分组，每个篮子里的苹果具有相似特点。这样只需从每个篮子里选一个苹果品尝，就能推断出其他苹果的味道。在软件测试中，测试人员无须测试所有可能的数据，只需测试每个“等价类”中的代表性数据，即可有效检查程序运行情况，从而节省时间和精力，提升测试效率。使用等价类划分法设计测试用例时，需先确定等价类的类型，再遵循相关原则，才能设计出测试用例。77二、等价类的类型通常，等价类可以分为有效等价类和无效等价类。有效等价类是指对规格说明有意义、合理的输入数据。无效等价类是指对规格说明无意义、不合理的输入数据。正确划分等价类可大幅减少测试用例数量，使测试更准确、高效。划分时需同时考虑有效等价类和无效等价类。78三、等价类划分的原则1. 限定范围或数量的情况若规定“年龄必须为1～100岁”，则1～100岁为有效等价类（符合年龄规则）；所有不在此范围内的年龄（如0岁、101岁）为无效等价类。2. 处理多个输入值的情况若程序需处理多个特定输入（如A、B、C），则每个输入值（A、B、C）分别构成一个有效等价类；所有非A、B、C的输入是无效等价类。793. 规定了特定输入集合的情况若规定输入必须是特定值（如“只能输入红、绿、蓝”），则这些指定值构成有效等价类；任何非红、绿、蓝的输入均为无效等价类。4. 输入必须符合特定规则的情况例如规则“密码必须包含数字和字母”，则符合该规则的所有密码为有效等价类。不符合规则的密码（如仅含数字或仅含字母）为无效等价类。5. 分析需求规格说明书测试人员需详细阅读软件需求规格说明书，找出所有可能的输入情况及分类，为等价类划分提供依据。80四、用等价类划分法设计测试用例的步骤确定等价类后，需建立等价类表，列出所有划分出的等价类，为设计测试用例提供依据。具体操作步骤如下：首先对程序的输入数据进行分析，确定测试对象，将每个测试对象划分为若干等价类；其次从每个等价类中选择代表性数据作为测试用例；最后编写这些测试用例，确保覆盖所有有效和无效等价类，以此检验程序在不同数据集合下的表现。这一过程可确保软件在各种预期及非预期的输入条件下均能正确执行。81用有效等价类设计测试用例时，应尽可能覆盖尚未被覆盖的有效等价类，以避免冗余。随着测试用例的增加，部分有效等价类可能已经被覆盖，此时无须再为该等价类单独设计用例。具体例子如下。假设测试人员为某网站的用户登录功能设计测试用例，登录表单包含用户名（5~30个字符，无非法字符）和密码（5~30个字符，包含字母和数字）两个字段。设计用户名为合法长度的有效等价类测试用例时，可设定用户名为validUser、密码为StrongPass123。该用例已验证用户名和密码的有效性，后续无须再单独测试其他符合条件的用户名，也无须重复验证密码的有效等价类。82用无效等价类设计测试用例时，应使每个用例仅覆盖一个尚未被覆盖的无效等价类。这样可确保每个无效等价类都得到充分测试，同时避免因多个无效等价类同时存在于一个用例中而导致的错误屏蔽问题，有助于提高测试的准确性和效率。83通过这样设计测试用例，测试人员能更快速地定位和修复系统中的错误。最终整理得到用等价类划分法设计测试用例的步骤，如图所示。84用等价类划分法设计测试用例的步骤假设有一个简单的应用程序，它接收一个年龄值（整数），并根据年龄判断用户的生活阶段。用户输入年龄后，程序返回对应的生活阶段，包括儿童（0～12岁）、青少年（13～17岁）、成年（18～64岁）、老年（65岁以上）。1. 确定测试对象在这个例子中，测试对象是“年龄值”，且该值为整数。852. 确定等价类确定有效等价类：根据应用程序的需求，年龄可划分为4个生活阶段，每个阶段都对应一个有效等价类，见下表。86有效等价类划分3. 设计有效等价类测试用例设计测试用例时，需确保每个用例覆盖一个未被覆盖的有效等价类，直到所有有效等价类均被覆盖。4个有效等价类测试用例见下表。874个有效等价类测试用例4. 设计无效等价类测试用例设计测试用例时，需确保每个用例仅覆盖一个未被覆盖的无效等价类，直到所有无效等价类均被覆盖。3个无效等价类的测试用例见下表。883个无效等价类的测试用例使用边界值分析法设计测试用例任务3891. 掌握边界值分析法的概念。2. 能运用边界值分析法设计测试用例。90测试团队在开展iceCMS内容管理系统的测试任务时，已掌握使用等价类划分法设计测试用例的过程，但还需进一步关注边界附近的情况，因为在边界附近往往会产生较多问题，所以需要一种能完善特殊边界场景测试用例的方法——边界值分析法，以保证测试质量，提升测试有效性。本任务要求采用边界值分析法为iceCMS内容管理系统项目中的充值中心功能设计测试用例，以更有效地发现程序中边界附近的逻辑错误。9192一、边界值分析法概述无数的测试实践表明，大量故障往往发生在输入值域或输出值域的边界上，而非其内部。因此，针对各种边界情况设计测试用例，通常能取得很好的测试效果。边界值分析法特别关注输入和输出的边界情况。就像篮球场一样，球员在场地内移动时一切正常，但接近边界时可能犯规——软件处理边界值时也可能出现类似错误。边界值分析法就是检查这些边界情况，确保软件能正确地处理“边界”问题，既不出现错误，也不遗漏关键场景。这种方法通常与等价类划分法结合使用，后者如同在篮球场上划分不同区域，帮助理解程序在不同场景下的行为。理解了边界值分析法的基本概念之后，关键步骤是确定具体边界条件，确保测试用例覆盖所有可能导致错误的极限情况。93二、边界条件的确定边界条件在计算机编程和软件测试中是指那些位于输入或输出范围极限的情况。这些条件通常特别重要，因为软件在处理极限值时很可能出错。在测试过程中，需测试刚好等于边界值、刚好高于边界上限的值和刚好低于边界上限的值、刚好高于边界下限的值和刚好低于边界下限的值。在软件开发中，边界条件的错误处理可能导致程序崩溃、输出错误或安全漏洞。因此，软件测试中理解并正确处理边界条件是确保软件质量的关键。94三、边界值分析法的原则1. 范围的边界例如月份取值范围为1～12，可测试合法值1、2、11和12，非法值0、13；若程序要求“在1～10中选择数字”，则需重点检查1和10（边界值），还有比1小的0、比1大的2、比10小的9和比10大的11。2. 个数的边界假设盒子最多可放10个苹果，可尝试放0个、1个、9个、10个、11个苹果，测试盒子的处理能力（注：个数不可为负数，故排除-1个）。953. 有序范围的边界如同检查珍珠项链的第一颗和最后一颗珍珠是否牢固，需测试有序序列的起始和结束位置。4. 内部结构的边界若游戏有多个关卡，需检查第一关和最后一关是否能正常运行。5. 其他边界条件就像侦探一样，需找出并检查那些不明显的边界条件。通过此类测试，可尽可能确保软件在所有场景下正常运行。96四、用边界值分析法设计测试用例的步骤在边界值分析法中，确定边界条件后，需创建边界值表，详细记录软件功能或字段的边界点，包括刚好等于边界值、刚好高于边界上限的值和刚好低于边界上限的值、刚好高于边界下限的值和刚好低于边界下限的值。这些边界值将作为测试用例的设计基础，用于检测软件在边界情况下的表现，以发现和修复仅在极端情况下出现的缺陷。97边界值分析法的步骤如下：首先，基于程序规格说明，识别所有测试对象，确定输入或输出数据的边界条件；其次，对于每个边界条件，选择边界值及其紧邻的值作为测试用例；最后，执行这些测试用例，确保软件能正确处理边界值及接近边界值的情况。以下以“根据年龄来确定生活阶段”为例，展示采用边界值分析法设计测试用例的过程。假设有一个简单应用程序，它接收整数年龄值，根据年龄判断用户生活阶段：儿童（0～12岁，包括0岁和12岁）、青少年（13～17岁，包括13岁和17岁）、成年（18～64岁，包括18岁和64岁）、老年（65岁及以上）。981. 确定测试对象和边界条件测试对象为整数年龄值，确定边界条件见下表。99确定边界条件2. 确定边界值及边界情况根据边界值分析原则，各阶段的边界值及边界情况见下表。100边界值及边界情况3. 设计测试用例根据边界条件和边界情况，设计测试用例，见下表。101测试用例102测试用例使用决策表法设计测试用例任务41031. 掌握决策表法的概念。2. 能运用决策表法设计测试用例。104测试团队在开展iceCMS内容管理系统的测试任务时，已经掌握了使用等价类划分法和边界值分析法设计测试用例的过程，但是还需要进一步考虑测试对象之间相互影响和制约的情况，因此，需要一种能清晰表示测试对象之间关系的测试用例设计方法——决策表法，来帮助测试人员快速理清复杂的业务规则，完成测试用例设计。本任务要求采用决策表法为iceCMS内容管理系统项目中的修改密码功能设计测试用例，以进一步提高测试质量。105106一、决策表法概述在所有的黑盒测试方法中，基于决策表（也称判定表）的测试是最为严格、逻辑性最强的一种。决策表是分析和表达多个逻辑条件下执行不同操作情况的工具。想象一下，一张清单上列出了许多不同的情况（就是人们常说的“逻辑条件”），然后对于每种情况，决策表会告诉测试人员应采取哪些行动，这就像是一个复杂问题的“指南”，能帮助人们根据不同的情况做出正确的决定，比如可以根据不同的天气情况（是否下雨）来决定是否带伞。二、决策表的组成和原则决策表详细列出了在不同条件下应采取的行动，帮助测试人员设计出能够应对各种情况的测试用例。这里以天气情况（是否下雨）来决定出门是否需要带伞为例，来描述决策表的4个组成部分和多个规则，如图所示。107决策表的组成1. 条件桩在条件桩中列出所有影响决定的条件，例如，在决定是否带伞时会考虑外面是否在下雨。2. 条件项条件项是针对条件桩给出的条件，列出所有可能的取值，例如，针对“下雨”条件，可能的情况为“是”或者“否”。1083. 动作桩在动作桩中列出问题规定的可能采取的操作，例如，在下雨的条件下，可以选择带伞。4. 动作项动作项指出在条件项的各种取值情况下应采取的动作，例如，如果外面在下雨（条件项为“是”），就应带伞（动作项）。109将任何一个条件组合的特定取值及其相应要执行的动作称为一条规则。在决策表中，贯穿条件项和动作项的一列就是一条规则。每一列就像是一条指令，它告诉人们在某些特定条件（条件项）下应做什么（动作项）。就好比“如果今天下雨（条件项），那么带伞出门（动作项）”，每一列都是一个这样的“如果……那么……”的指令，详细内容如上图所示。110三、用决策表法设计测试用例的步骤当确定决策表的组成后，需要建立决策表，再根据决策表设计测试用例。具体操作步骤如下：首先，详细分析程序的功能需求和规则说明，识别出所有可能的条件桩和相应的动作桩，确定每个条件桩的条件项（即条件的可能取值），进而确定规则的个数；然后，根据这些条件桩、动作桩及条件项创建初始决策表，该表应列出所有可能的条件组合及它们各自对应的动作结果，其中每一行代表一个决策规则，显示在特定条件组合下应采取的动作；接着，将初始决策表按照一定规则进行精简，得到最终的决策表。111之后，基于这个决策表设计测试用例，以确保软件在所有可能的决策情况下都能做出正确的响应。通过这些步骤，决策表法能够帮助测试人员全面覆盖软件的决策逻辑，确保逻辑的正确性和完整性。这里仍以天气情况（是否下雨）来决定是否需要带伞为例，给出构造决策表的具体过程。如果下雨且有伞，则应带伞出门；如果下雨且没有伞，则应买伞出门或不出门；如果不下雨，无论是否有伞都不需要买伞，也不需要带伞出门。112决策表的构造过程如下。1.确定规则的个数。对于本案例有2个条件（是否下雨、是否有伞），每个条件都有2个取值，故有2×2=4种规则。2.列出所有的条件桩和动作桩。本案例中条件桩有2个（是否下雨、是否有伞），动作桩有3个（带伞出门、买伞出门或不出门、正常出门）。3.先填入条件桩，在本案例中条件桩为是否下雨和是否有伞，再填入对应的条件项，条件项为“是”或“否”。1134.填入动作项和动作桩，在本案例中动作桩为带伞出门、买伞出门或不出门、正常出门，根据条件组合确定对应的动作项。最终得到决策表，见下表。114天气情况（是否下雨）决策表5.简化决策表，合并相似规则。在决定决策表里规则的数量时，需要根据具体情况进行分析。通常情况下，规则的总数是由所有条件取值的组合（即数学里的笛卡儿积）决定的。但有时直接计算出的规则过多，部分规则可合并。合并规则的方法很简单，若多条规则的动作结果相同，且仅部分条件取值不同，则可合并为一条规则。合并后的规则中，用“—”符号表示该条件的取值不影响最终结果（即无关条件）。这就好比在做选择题时，如果几个选项的答案相同，可合并成一个问题，不用分开考虑。这样能使决策表更为简洁，也更容易使用。115通过本案例的规则3和规则4可以看出，只要不下雨，无论是否有伞，都可正常出门。因此，这两条规则可以合并。最终的决策表见下表。116天气情况（是否下雨）简化决策表6.根据决策表生成测试用例。一条规则对应一条测试用例，规则中的条件桩及条件项对应测试用例的输入条件；动作桩及动作项对应测试用例的预期结果。最终的测试用例见下表。117根据天气情况（是否下雨）决策表生成的测试用例使用因果图法设计测试用例任务51181. 掌握因果图法的概念。2. 能运用因果图法设计测试用例。119测试团队在开展iceCMS内容管理系统的测试任务时，已经掌握了使用决策表法设计测试用例的过程，但是需要进一步考虑测试对象之间的逻辑依赖关系。因此，需要一种能清晰表示出测试对象之间的因果逻辑的方法，即因果图法，使得复杂的业务逻辑和决策过程得以简化和可视化。本任务要求采用因果图法为iceCMS内容管理系统项目中的用户登录功能设计测试用例，帮助发现因逻辑错误或条件遗漏导致的缺陷。120121一、因果图法概述在所有的黑盒测试方法中，基于决策表（也称判定表）的测试是最为严格、逻辑性最强的一种。决策表是分析和表达多个逻辑条件下执行不同操作情况的工具。想象一下，一张清单上列出了许多不同的情况（就是人们常说的“逻辑条件”），然后对于每种情况，决策表会告诉测试人员应采取哪些行动，这就像是一个复杂问题的“指南”，能帮助人们根据不同的情况做出正确的决定，比如可以根据不同的天气情况（是否下雨）来决定是否带伞。二、因果图的基本符号和约束因果图是一张连线图，用来表示事物之间的“因果关系”，用4种不同的符号表示4种不同的关系。图中的每一条线都连接着两个点：左边的点代表输入状态（用ci

表示，也就是“因”），右边的点代表输出状态（用ei

表示，也就是“果”）。122在因果图中，每个输入状态点或输出状态点只有两种可能的状态：0或者1。如果一个点的状态为0，意味着该状态没有出现；如果一个点的状态为1，则表示该状态已出现。通过这种方式，可以清楚地看到不同的输入状态是如何影响输出状态的。下图中各符号的含义如下。123因果图中的关系a）恒等b）非c）或d）与上图a表示恒等。若c1

为1，则e1

为1；若c1

为0，则e1

为0。上图b表示非（~）。若c1

为1，则e1

为0；若c1

为0，则e1

为1。上图c表示或（∧）。若c1、c2

或c3

中至少有一个为1，则e1

为1。若c1、c2、c3

都为0，则e1

为0。上图d表示与（∨）。若c1、c2

或c3

中至少有一个为0，则e1

为0；若c1、c2

和c3

都为1，则e1

为1。124在因果图的实际应用过程中，输入之间可能还存在着相互制约的关系，这种关系称为“约束”。因果图中共有4种约束关系，如图所示。125因果图中的4种约束关系a）异b）或c）唯一d）要求异约束用E表示，定义一个排他性条件，即在a

和b

中，要么a

为0，b

为1；要么a

为1，b

为0。或约束用I表示，指定a、b、c

中至少有一个值为1，不可能都为0。唯一约束用O表示，确保在