《程序功能测试》课件全套 项目1-6 测试需求分析-测试报告撰写

项目一测试需求分析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表示，确保在a

和b

中必须且只能有一个值为1。要求约束用R表示，强调a

和b

的值必须相同。如果a

为1，则b

也必须为1；如果a

为0，则b也必须为0。126同样地，输出结果之间也存在约束，称为强制约束，用M表示，强调如果a

为1，则b

必须为0；如果a

为0，则b

必须为1，如图所示。127 因果图中的强制约束关系三、使用因果图法设计测试用例的步骤首先，仔细审阅需求规格说明书，以识别原因（即“输入”）和预期的结果（即“输出”）。输入条件通常指需求规格说明书中描述的用户或系统对软件的各种输入要求；输出条件通常指需求规格说明书中描述的软件在接收到特定输入条件后的行为或状态改变。其次，利用因果图将识别的输入和输出进行图形化表示。在某些情况下，由于特定的语法或环境限制，某些输入组合或输入与输出之间的关系可能不适用，这时需要用特定符号来标注这些约束。再次，将构建的因果图转化为决策表，详细列出各种输入组合及其对应的输出。最后，依据决策表中的信息来设计具体的测试用例，确保覆盖所有可能的情况。128这里以一个在线音乐平台的会员激活功能为例，给出使用因果图法设计测试用例的具体过程。假设该功能要求用户输入的激活码首个字符为M或N且第二个字符为字母时，获得高级会员订阅；如果第一个字符不是M或N，则显示错误信息（激活码格式错误）；如果激活码第一个字符是M或N，但第二个字符不是字母，则获得标准会员订阅。1291. 识别输入和输出（“原因”和“结果”）原因有3个，c1（激活码第一个字符是M）、c2（激活码第一个字符是N）、c3（激活码第二个字符是字母）。结果有3个，e1

为显示错误信息（表示激活码格式错误）；e2为获得高级会员订阅；e3

为获得标准会员订阅。1302. 根据原因和结果画出对应因果图（1）激活码中如果第一个字符不是M或N，则显示错误信息（表示激活码格式错误），如图所示。131根据原因和结果画出对应因果图1（2）激活码中如果首个字符为M或N，且第二个字符为字母，在这种情况下可获得高级会员订阅，如图所示。（3）如果激活码中第一个字符是M或N，但第二个字符不是字母，则获得标准会员订阅，如图所示。132根据原因和结果画出对应因果图2根据原因和结果画出对应因果图3因此，最终汇总得到结果，如图所示。增加异约束，得到下图。133不带约束的因果图带有约束的因果图3. 将构建的因果图转换为决策表因果图的“原因”对应决策表中的“条件桩”（c1、c2、c3），“结果”对应决策表中的“动作桩”（e1、e2、e3），那么根据图3-14可以看出，条件桩有3个，分别为c1（激活码第一个字符是M）、c2（激活码第一个字符是N）和c3（激活码第二个字符是字母），假设每个原因可标记为“是”或者“否”，规则一共有23=8个，其中c1

和c2

不可能同时为“是”，二者是异的关系；动作桩有3个，分别为e1（显示错误信息，表示激活码格式错误）、e2（获得高级会员订阅）、e3（获得标准会员订阅）。根据上述分析得到初始决策表，见下表。134135初始决策表其中由规则1和规则2可以看出，只要c1（激活码第一个字符是M）和c2（激活码第一个字符是N）为“否”，无论c3（激活码第二个字符是字母）为“是”还是“否”，结果均为e1（显示错误信息，表示激活码格式错误），因此规则1和规则2可以进行约简。规则7和规则8中，要求c1（激活码第一个字符是M）和c2（激活码第一个字符是N）均为“是”不符合客观逻辑并且不满足异约束的条件，即c1和c2

不能同时为1，故去除。根据上述决策表的约简规则，可得到精简后的决策表，见下表。136137决策表4. 依据决策表中的信息来设计覆盖所有有效场景的测试用例用决策表法设计的测试用例见下表。138用决策表法设计的测试用例项目四测试执行139140任务1执行GUI测试任务2执行兼容性测试任务3执行回归测试执行GUI测试任务11411. 了解GUI测试的测试要点与常见错误。2. 能执行GUI测试。142测试人员在接受测试任务时，发现iceCMS内容管理系统需满足用户对于界面元素外观、布局及行为等方面的需求，因此，本任务要求针对iceCMS内容管理系统项目开展GUI测试。以下表所示的文章管理模块下创建文章功能的GUI测试用例为例，按照测试用例中的测试步骤，验证其图形用户界面的实际结果是否与预期的界面设计相吻合，验证与用户的交互操作是否正确，记录测试实际结果，并给出测试结论。143144创建文章功能的GUI测试用例执行测试，其实就是执行测试用例的过程，按照测试用例中描述的测试步骤操作，操作后所得的结果称为实际结果。测试结果的判定，需要将执行所得的实际结果与测试用例中的预期结果相比较，若二者一致则认为测试通过，若二者不一致则认为测试不通过，即存在缺陷，如图所示。145146GUI测试，即图形用户界面测试，属于测试类型的一种。GUI测试的对象主要为软件的图形用户界面功能，其更关注用户界面的交互性和可用性，以确保软件的用户界面友好、易于操作，并符合用户期望。测试结果一、GUI测试要点1. 常见的界面元素及其通用标准（1）文本框文本框具有可输入性，当光标移动至文本框时，光标的形状由箭头变为I形，如图所示。（2）单选框如图所示为单选框，支持使用鼠标单击选择若干选项中的一项。147文本框单选框（3）复选框如图所示为复选框，支持使用鼠标单击选择若干选项中的多项。148复选框（4）下拉列表如图所示为下拉列表，一般会有下三角按钮，单击下三角按钮即可显示下拉列表中的所有选项。149下拉列表（5）按钮如图所示为按钮，支持单击以实现表单提交、取消或其他操作。按钮上应清晰描述其所实现的功能，避免误导操作。（6）对话框如图所示为对话框，每个对话框都应有对话框名称，并支持最小化、最大化/还原、关闭等操作。150按钮对话框2. GUI测试开展角度（1）从元素外观角度测试元素外观的关注点主要包括字体类型与大小、控件大小与比例、形状、色彩等，需保证每个元素的用途明确，符合相关标准和规范。可重点关注元素外观的以下方面：是否为规定字体；字体颜色是否正确；控件大小是否与整体界面协调；控件形状是否清晰简洁、易于识别；颜色搭配是否合理美观，与整体界面风格是否一致。151（2）从元素布局角度测试元素布局的关注点主要包括元素位置、排版、对齐与间距等，以达到界面直观、灵活、舒适的要求。可重点关注元素布局的以下方面：界面元素位置是否合理，是否符合用户使用习惯；控件或图形之间是否对齐和保持一致的间距；文字间距和行间距是否合理统一；导航菜单是否明显、易于识别；层次结构是否使用户能够轻松理解和操作界面。152（3）从元素行为角度测试元素行为的关注点主要包括焦点获取、提示提醒、默认值、快捷键等，以保证用户友好交互。可重点关注元素行为的以下几方面：对话框大小是否可调节；操作结果是否给出合理提示与反馈；提示信息的内容是否合理；菜单导航是否能正确引导用户到指定界面；通用快捷键是否可以正常使用。153（4）从元素内容角度测试元素内容的关注点主要包括文字使用与表达等，需确保无错别字、用语简洁友好、表达准确等，以保证用户正确使用。可重点关注元素内容的以下几方面：导航菜单中各级目录表述是否正确；元素内外文字是否存在错别字；提示与反馈是否准确；对话框标题是否正确。154二、GUI测试中常见的错误1. 混淆复选框和单选框复选框和单选框是两种不同的控件，但在GUI设计中有时会被错误地使用或混淆。复选框用于选择多个选项，常用方形表示，而单选框用于从多个选项中选择一个，常用圆形表示，如图所示。155二、GUI测试中常见的错误1. 混淆复选框和单选框复选框和单选框是两种不同的控件，但在GUI设计中有时会被错误地使用或混淆。复选框用于选择多个选项，常用方形表示，而单选框用于从多个选项中选择一个，常用圆形表示，如图所示。复选框和单选框2. 术语使用前后不一致在GUI设计中，使用不规范或不统一的术语可能会导致用户产生混淆。3. 出现错误的提示信息针对用户的错误操作给出合理的提示信息有助于引导用户执行正确操作，而给出错误的提示信息会适得其反。4. 功能错误或遗漏如果说用户体验因人而异、不便于衡量，那么功能的完整性和正确性则有统一标准，需确保需求规格说明书中定义的功能均被完整且正确地实现。156三、GUI测试步骤GUI测试应遵循整体测试流程，属于完整测试中的一部分。首先，在测试需求分析阶段需明确测试目标，即确定对哪些GUI事件进行测试。其次，进行GUI测试用例的设计与执行。最后，完成GUI测试部分的总结。不过，GUI测试也存在特殊难点。在测试用例设计阶段，其用例设计比其他功能测试更复杂，难点在于预期结果与测试步骤的定义复杂。通常情况下，输入事件无固定顺序，导致输入场景难以全面覆盖，并且部分预期结果很难确切表达。在测试用例执行阶段，GUI测试也会受到用户操作习惯的较大影响，如操作顺序、快捷键使用等。157四、GUI测试案例1. 测试需求分析根据需求规格说明书，对计算器程序进行GUI测试，验证其图形用户界面是否符合界面设计要求，是否能正确处理与用户的交互。计算器界面设计原型图如图所示。可以对计算器包含元素的外观、布局、行为及内容等开展GUI测试，包括文本框、下拉列表、对话框及整体布局。158计算器界面设计原型图2. GUI测试执行计算器各项元素的整体布局实现如图所示，基本与需求规格说明书中的原型图一致，所包含的各项元素、大小、位置及整体颜色搭配合理。个别元素有所差异，如切换计算器模式的下拉列表、文本框、个别按钮的颜色等。159计算器各项元素的整体布局实现对于计算器模式的切换功能，实现效果变更为侧边导航栏，如图所示。该变更不影响功能实现，并且导航按钮更直观，经项目组协商同意该实现方案。160计算器模式切换功能实现对于计算器文本框，实现效果模糊了边缘，如图所示，但经测试仍具备输入功能，并且将光标移动至文本框时，形状可正常变化。从整体布局及美观角度考虑，该实现方案可行。161计算器文本框实现对于计算器对话框，实现效果与原型图保持一致，如图所示，符合对话框实现的基本要素，测试通过。对于计算器各项元素的行为反馈进行测试，均能得到正确反馈，各元素内容描述清晰、表达准确，可以正常使用。162计算器对话框实现综上所述，计算器界面的各项元素布局与交互均满足测试需求，GUI测试用例结论为“通过”，计算器GUI测试用例结果见下表。163计算器GUI测试用例结果执行兼容性测试任务21641. 了解兼容性测试的策略和类型。2. 能执行兼容性测试。165测试人员在接受测试任务时，发现iceCMS内容管理系统需满足用户在Windows与macOS操作系统，以及Chrome、Firefox、Safari浏览器中操作的需求，因此，本任务要求针对iceCMS内容管理系统项目开展兼容性测试。以下表所示的文章管理模块下创建文章功能的若干兼容性测试用例为例，按照测试用例中的测试步骤，验证软件是否能在不同操作系统、不同浏览器中正常运行，记录测试实际结果，并给出测试结论。166167兼容性测试用例168兼容性测试用例169一、兼容性测试策略1. 向上兼容向上兼容也称向前兼容，是指旧版本的软件能够在新版本的硬件或操作系统上运行。2. 向下兼容向下兼容也称向后兼容，是指新版本的软件能够在旧版本的硬件或操作系统上运行。二、兼容性测试的类型1. 软件兼容性测试软件兼容性测试主要用来验证不同软件之间能否正确实现信息交互与共享，重点考虑操作系统兼容及浏览器兼容。目前常用的操作系统有Windows、macOS、Linux等，常用的浏览器有Chrome、Safari、Edge、Firefox、IE等，如图所示。170常用的操作系统与浏览器此外，还需要考虑不同版本的操作系统和浏览器，即使是同一操作系统或浏览器，不同版本之间也可能存在兼容性问题。因此，在进行软件兼容性测试时，通常需要对多个版本进行测试，可以考虑不同的操作系统、相同操作系统的不同版本、不同类型的浏览器、相同类型浏览器的不同版本等各种组合场景。1712. 硬件兼容性测试硬件兼容性测试也称配置测试，主要考虑不同的硬件配置对软件运行的影响。常见的计算机硬件配置包括主板、显卡、声卡、网卡、内存、显示器等。1723. 数据共享兼容性测试为提升软件的可用性，软件常常需要和其他软件进行数据传输与共享。通常情况下，数据共享兼容性测试可以重点考虑以下几个方面，以Word 2016版本为例展开说明。（1）复制、剪切与粘贴是用户最常使用的功能之一，是指在不同应用间的数据共享。如图所示为网页与Word文件之间的数据共享，从网页中复制的文字，可以在Word文件中实现粘贴。173复制与粘贴（2）文件的导入与导出是软件与自身其他版本及其他软件保持数据兼容的方式。若文件的数据格式符合通用标准，则可以被其他软件读取，也可以打开其他软件生成的文件。如图所示为Word 2016版本可以导入其他版本的Word文件，或者文本文件；可以将当前Word文件导出为其他版本的Word文件，或者PDF文件，使用PDF阅读器打开。174文件的导入与导出三、兼容性测试案例1. 测试需求分析根据需求规格说明书中的描述，对小游戏程序进行兼容性测试，用于验证其是否兼容不同的操作系统、是否兼容同一操作系统的不同版本、是否兼容不同类型的浏览器。根据需求规格说明书中的要求，需要考虑以下组合情况，见下表。175兼容性测试场景2. 兼容性测试执行兼容性测试需要在上表所列的组合场景中，分别对目标程序进行测试，查看小游戏程序在不同环境下的运行情况。原则上，兼容性测试内容可覆盖小游戏程序的所有功能测试用例，以确保小游戏程序在各种场景下的所有功能都可以正常运行。但在实际测试中，往往优先挑选与核心功能及显示效果相关的测试用例执行测试，这样可以尽可能地降低兼容性测试的工作量，规避风险。176执行回归测试任务31771. 了解回归测试的概念、作用与策略。2. 能执行回归测试。178针对iceCMS内容管理系统项目的测试已接近尾声，测试人员在测试过程中发现一些缺陷，并且开发人员已完成缺陷修复（缺陷处理流程详见项目五）。为确保开发人员对代码的前期修改未引入新缺陷、保障产品最终质量，需要针对iceCMS内容管理系统项目开展回归测试。本任务要求以文章管理模块下的创建文章功能为例，制定回归测试的策略，选取相关测试用例并再次执行，记录测试实际结果，最终给出测试结论。179180一、回归测试的概念与作用在生活中偶尔会遇到这样的情况：原本水管漏了一处，对其进行修补后，此处虽已修好，但看似没有关联的另一处开始漏水。软件领域也是如此，修复一处缺陷后，往往会引发其他新缺陷。也就是说，对软件的改动往往会带来一定的风险。遗憾的是，复杂的软件几乎时刻都在改变，可能有缺陷需要修复、有需求需要调整、有技术的更新或软硬件的升级，而软件每次的改变都会引入潜在的风险，即产生新的缺陷。为了避免缺陷此起彼伏的情况，仅仅测试被修复的缺陷是否解决远远不够，还需要对软件其他功能进行测试，保证其他功能正常运行而未受到此次修改的影响，从而抑制潜在风险的发生，这就是回归测试的核心价值。回归测试是指在软件测试过程中，若因修复缺陷或新增功能对软件进行了修改，则需要重新运行之前的测试用例，以确保新的修改没有引入新的问题，并且原有功能仍能正常工作。回归测试的目的是保障软件在迭代过程中的持续稳定性和功能一致性。181二、回归测试的策略1. 再测试全部用例该策略是将项目中所有测试用例重新执行一遍，是最安全、稳妥的方法，能对被测软件进行全面检验。无论是验证缺陷是否修复，还是确认其他功能是否未受影响、可正常工作，该方法都十分有效。由于无须对测试用例进行额外处理，该方法几乎可以适用于所有场景，但测试成本会随项目规模不同而存在明显差异。若项目规模较大、测试用例数量较多，此方法会带来极大的工作量，受预算和进度限制，往往难以有效实施。1822. 基于风险选择测试为降低回归测试成本，可以选择一部分测试用例来进行回归测试。选择时可以基于一定的风险标准，优先选择那些功能受影响可能性较大的用例。例如，某功能曾因出现过缺陷而被修改，那么选择回归测试用例时，可以优先选择该功能所涉及的用例，以及与该功能相关联模块的用例，即可能被修改部分影响到的用例，被影响的可能性越大，越应优先选择。1833. 基于操作选择测试该策略优先选择针对核心功能或用户高频使用功能的测试用例，将风险出现的级别和频次降低，有助于尽早发现对软件可靠性会产生重大影响的缺陷。在上述回归测试的策略中，再测试全部用例的策略显然是最安全的策略，但由于测试成本最高，所以在实际实施过程中往往会倾向于选择适当的策略进行缩减的回归测试。需要注意的是，回归测试使用的用例数量越少，隐藏的风险可能就越多，因此，需要权衡回归测试的成本和收益，以决定回归测试的范围和深度。184三、回归测试案例1. 测试需求分析本案例是对检索小程序进行回归测试，用于验证需求和功能是否完整，前期修改是否会引入新的缺陷。2. 回归测试执行由于临近软件发布日期，剩余时间不足以执行全部测试用例，所以挑选了部分测试用例用于回归测试。挑选测试用例的原则：与检索小程序核心功能相关的测试用例及曾经测试未通过的测试用例。根据项目规模，将回归测试安排在最后一轮测试之后执行。185项目五缺陷管理186使用禅道管理缺陷任务

1871. 了解缺陷报告与处理流程。2. 掌握缺陷管理工具——禅道的使用方法。188测试人员在执行iceCMS内容管理系统中的文章管理功能测试时，发现若干Bug。其中一个Bug的描述如下：在创建文章时，需求规格说明书要求轮播图只能上传JPG/PNG格式的图片，但实际测试中发现，系统并未对图片格式进行校验，非JPG/PNG格式的图片也可上传成功（记为Bug1）；另一个Bug的描述如下：在创建文章时，若未填写“分类”字段，提交时会弹出“失败，请检查网络连接”的错误弹窗，而“分类”字段属于非必填项，既不应进行非空校验，错误提示信息也不合理（记为Bug2）。189本任务要求针对iceCMS内容管理系统项目测试过程中产生的缺陷进行有效识别与报告，使用缺陷管理工具——禅道对上述两个典型Bug的完整生命周期进行跟踪管理，从而规范测试流程，提升测试效率。190一、缺陷报告在缺陷的处理流程中，初始的缺陷报告是驱动其状态流转的原点，也是核心。缺陷报告是测试人员的工作成果之一，通过缺陷报告，测试人员可以准确描述程序中存在的缺陷，并告知开发人员发生的问题。它是测试人员和开发人员之间重要的沟通工具，有助于保障软件质量。缺陷报告通常应包含以下构成要素，见下表。191192缺陷报告的构成要素193根据缺陷特点的不同，上表中列举的缺陷报告的构成要素可以略作取舍。其中，重现步骤是开发人员正确理解缺陷的关键要素之一，对其进行有效描述至关重要。假定开发人员收到以下缺陷描述：“在文本框中输入内容后，界面就开始出现一些奇怪的反应。”开发人员大概率会陷入沉思：“是哪个界面的文本框？输入了什么内容？奇怪的反应具体是什么？应该从何着手修复这个缺陷？”194从上述例子可以看出，如果测试人员对缺陷的描述含糊不清，可能会被开发人员误认为不属于缺陷而拒绝修复，或者认为该缺陷不够重要而选择延期修复，甚至不知所措。因此，一份优质的缺陷报告要求测试人员能够准确、清晰地描述缺陷，为开发人员或其他缺陷处理人员提供充足的信息，来决定应采取何种措施。以下是有效描述缺陷应遵循的基本原则。1. 准确完整准确完整是指描述的细节要准确，信息要完整，并且不会引发歧义；必要时可提供日志、截图等辅助信息，使开发人员能够准确理解并定位问题。2. 简明扼要简明扼要是指仅描述缺陷必需的信息，突出关键信息，避免冗长描述。3. 可再现可再现是指提供详细的重现步骤，确保开发人员依据这些步骤能再次触发缺陷。1954. 单一性单一性是指每份缺陷报告仅描述一个缺陷。实践证明，若在一份缺陷报告中上报多个缺陷，真正被解决的可能只有第一个，其他缺陷很可能被忽略，并且不利于缺陷跟踪。5. 客观性客观性是指以事实为依据，客观描述缺陷，避免主观臆断和猜测，不做个人评价。196197下表展示了一份在测试某系统登录功能时提交的缺陷报告。缺陷报告示例二、缺陷的处理流程缺陷一经发现，便开启了从激活状态到关闭状态的生命周期，并在测试人员、开发人员、产品经理等角色间展开不同状态的流转。下图展示了一个基本的缺陷处理流程。198基本的缺陷处理流程在上述处理流程中，缺陷首先由测试人员发现，再由测试人员报告给指定的开发人员（或开发组长）处理，此时缺陷处于激活状态。当开发人员修复程序后，缺陷处于已解决状态，并重新回到测试人员手中。测试人员对处于已解决状态的缺陷进行验证，若确认该缺陷已被修复，则关闭该缺陷，此时缺陷处于已关闭状态。199一般情况下，缺陷会如上述基本处理流程所述，简洁快速地走完整个生命周期。但实际工作中，缺陷处理流程往往更复杂，需考虑更多情况。下图描述了一个更为常见的缺陷处理流程。200常见的缺陷处理流程在该流程中，缺陷同样从被测试人员发现并激活开始，但被指派的开发人员（或开发组长）未必会立刻处理，而是会先对缺陷进行审核，判断其是否真实有效，以决定是否接受。若经审核，缺陷属于重复缺陷或并非真正意义上的缺陷，开发人员则会拒绝处理，直接将该缺陷调整到已解决状态；若确认缺陷需要修复，开发组长会进一步判断是否立即修复。若需立即修复，则由指定开发人员处理，修复完成后将缺陷调整至真正的已解决状态；否则会延期处理。无论哪种解决方式，缺陷最终都会流转至测试人员手中再次确认，若缺陷已解决，测试人员会关闭缺陷，处理完成；若经测试验证，缺陷仍未修复，测试人员会重新激活缺陷，使其再次回到开发人员手中，循环上述流程，直至测试确认缺陷已修复，才会关闭缺陷，结束处理流程。201从上述流程中可以看出，当测试人员所提缺陷不合理、不全面或不应被认定为缺陷时，开发人员可以不予解决。但有些情况下，即使缺陷属实，也并不一定会被及时修复，有以下原因。1. 时间不充足如果因缺陷导致产品无法如期发布带来的损失大于缺陷本身，那么会优先发布产品，而缺陷将被延期修复。2. 修复风险太大程序之间往往存在着千丝万缕的关系，如果为了