《程序功能测试》课件 项目4-6 测试执行-测试报告撰写

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

491. 了解缺陷报告与处理流程。2. 掌握缺陷管理工具——禅道的使用方法。50测试人员在执行iceCMS内容管理系统中的文章管理功能测试时，发现若干Bug。其中一个Bug的描述如下：在创建文章时，需求规格说明书要求轮播图只能上传JPG/PNG格式的图片，但实际测试中发现，系统并未对图片格式进行校验，非JPG/PNG格式的图片也可上传成功（记为Bug1）；另一个Bug的描述如下：在创建文章时，若未填写“分类”字段，提交时会弹出“失败，请检查网络连接”的错误弹窗，而“分类”字段属于非必填项，既不应进行非空校验，错误提示信息也不合理（记为Bug2）。51本任务要求针对iceCMS内容管理系统项目测试过程中产生的缺陷进行有效识别与报告，使用缺陷管理工具——禅道对上述两个典型Bug的完整生命周期进行跟踪管理，从而规范测试流程，提升测试效率。52一、缺陷报告在缺陷的处理流程中，初始的缺陷报告是驱动其状态流转的原点，也是核心。缺陷报告是测试人员的工作成果之一，通过缺陷报告，测试人员可以准确描述程序中存在的缺陷，并告知开发人员发生的问题。它是测试人员和开发人员之间重要的沟通工具，有助于保障软件质量。缺陷报告通常应包含以下构成要素，见下表。5354缺陷报告的构成要素55根据缺陷特点的不同，上表中列举的缺陷报告的构成要素可以略作取舍。其中，重现步骤是开发人员正确理解缺陷的关键要素之一，对其进行有效描述至关重要。假定开发人员收到以下缺陷描述：“在文本框中输入内容后，界面就开始出现一些奇怪的反应。”开发人员大概率会陷入沉思：“是哪个界面的文本框？输入了什么内容？奇怪的反应具体是什么？应该从何着手修复这个缺陷？”56从上述例子可以看出，如果测试人员对缺陷的描述含糊不清，可能会被开发人员误认为不属于缺陷而拒绝修复，或者认为该缺陷不够重要而选择延期修复，甚至不知所措。因此，一份优质的缺陷报告要求测试人员能够准确、清晰地描述缺陷，为开发人员或其他缺陷处理人员提供充足的信息，来决定应采取何种措施。以下是有效描述缺陷应遵循的基本原则。1. 准确完整准确完整是指描述的细节要准确，信息要完整，并且不会引发歧义；必要时可提供日志、截图等辅助信息，使开发人员能够准确理解并定位问题。2. 简明扼要简明扼要是指仅描述缺陷必需的信息，突出关键信息，避免冗长描述。3. 可再现可再现是指提供详细的重现步骤，确保开发人员依据这些步骤能再次触发缺陷。574. 单一性单一性是指每份缺陷报告仅描述一个缺陷。实践证明，若在一份缺陷报告中上报多个缺陷，真正被解决的可能只有第一个，其他缺陷很可能被忽略，并且不利于缺陷跟踪。5. 客观性客观性是指以事实为依据，客观描述缺陷，避免主观臆断和猜测，不做个人评价。5859下表展示了一份在测试某系统登录功能时提交的缺陷报告。缺陷报告示例二、缺陷的处理流程缺陷一经发现，便开启了从激活状态到关闭状态的生命周期，并在测试人员、开发人员、产品经理等角色间展开不同状态的流转。下图展示了一个基本的缺陷处理流程。60基本的缺陷处理流程在上述处理流程中，缺陷首先由测试人员发现，再由测试人员报告给指定的开发人员（或开发组长）处理，此时缺陷处于激活状态。当开发人员修复程序后，缺陷处于已解决状态，并重新回到测试人员手中。测试人员对处于已解决状态的缺陷进行验证，若确认该缺陷已被修复，则关闭该缺陷，此时缺陷处于已关闭状态。61一般情况下，缺陷会如上述基本处理流程所述，简洁快速地走完整个生命周期。但实际工作中，缺陷处理流程往往更复杂，需考虑更多情况。下图描述了一个更为常见的缺陷处理流程。62常见的缺陷处理流程在该流程中，缺陷同样从被测试人员发现并激活开始，但被指派的开发人员（或开发组长）未必会立刻处理，而是会先对缺陷进行审核，判断其是否真实有效，以决定是否接受。若经审核，缺陷属于重复缺陷或并非真正意义上的缺陷，开发人员则会拒绝处理，直接将该缺陷调整到已解决状态；若确认缺陷需要修复，开发组长会进一步判断是否立即修复。若需立即修复，则由指定开发人员处理，修复完成后将缺陷调整至真正的已解决状态；否则会延期处理。无论哪种解决方式，缺陷最终都会流转至测试人员手中再次确认，若缺陷已解决，测试人员会关闭缺陷，处理完成；若经测试验证，缺陷仍未修复，测试人员会重新激活缺陷，使其再次回到开发人员手中，循环上述流程，直至测试确认缺陷已修复，才会关闭缺陷，结束处理流程。63从上述流程中可以看出，当测试人员所提缺陷不合理、不全面或不应被认定为缺陷时，开发人员可以不予解决。但有些情况下，即使缺陷属实，也并不一定会被及时修复，有以下原因。1. 时间不充足如果因缺陷导致产品无法如期发布带来的损失大于缺陷本身，那么会优先发布产品，而缺陷将被延期修复。2. 修复风险太大程序之间往往存在着千丝万缕的关系，如果为了修复一个缺陷反而会引出更多的缺陷，那么在时间紧迫的情况下，修复缺陷便显得得不偿失。643. 不值得修复有些缺陷对用户的使用影响可能微乎其微，开发人员则会将精力投入其他优先级更高的缺陷修复。由于上述3种原因或其他原因，经由产品经理等项目相关人员共同决策，缺陷可能不会被及时修复，但由于缺陷依然存在，所以无法将其调整至已关闭状态，因此，有时会用延期来标示此时的缺陷状态。65缺陷可能在整个生命周期中经历众多状态，有时顺利流转，有时甚至会循环回去、重新流转，常见的缺陷状态及描述见下表。不同公司、不同缺陷管理工具对于缺陷状态、缺陷处理流程、缺陷操作权限等方面的要求都不尽相同。66常见的缺陷状态及描述三、缺陷管理工具的使用缺陷管理作为软件开发流程中的重要环节，为提高缺陷跟踪效率、促进团队协作与沟通、降低管理成本并提升软件质量，使用缺陷管理工具十分必要，它为团队提供了高效、准确、可靠的缺陷跟踪管理解决方案。缺陷管理工具有很多，如Bugzilla、Jira、禅道及部分公司的自研工具等。禅道是一款优秀的国产开源项目管理软件，集项目管理、产品管理、质量管理等功能于一体，覆盖项目、产品、开发、测试等管理核心流程。禅道的测试功能可以独立出来，用于缺陷（Bug）管理，具体操作步骤可分为创建产品、创建（提）Bug、处理Bug。67使用禅道管理Bug的步骤如下。1. 创建产品禅道作为项目管理软件，在其设计理念下，应以产品维度进行任务管理，Bug则关联于产品。因此，为进行后续的Bug管理，应先在禅道中创建产品。如图所示为禅道中的产品列表。68禅道中的产品列表2. 创建Bug在产品维度下可以创建Bug。在禅道中创建Bug时，除了影响版本和Bug标题为必填字段外，其余字段均可选填，如图所示。在禅道中，还可以自定义选择缺陷报告的构成要素。69创建Bug在创建Bug时，测试人员应客观地填写Bug的基本信息，包括Bug标题、Bug类型、严重程度、优先级等，尤其注意重现步骤的描述应准确、简洁，便于开发人员正确理解Bug；必要时可填写发现Bug时使用的操作系统或浏览器，并在附件中添加相关的截图、日志文件等。测试人员在创建Bug时，可在当前指派中选择指定人员处理Bug（一般为开发人员），如上图所示。被指派人员会收到系统消息提醒，并在自己的Bug列表中看到该Bug。若不清楚如何指派，该字段可暂时留空，后续再补充。703. 处理Bug使用缺陷管理工具的好处是，它能根据不同角色的操作自动进行Bug状态流转，并向相关人员发送系统通知提醒。在禅道中，Bug的状态包括激活、已关闭、已解决，如图所示；基本处理流程如下：创建Bug→确认Bug→解决Bug→验证并关闭Bug。71禅道中Bug的状态开发人员接收到Bug后，可进行如下操作。（1）确认Bug。开发人员确认Bug，表示已成功接收，等待解决。确认Bug时，若发现该Bug应由其他人负责，可重新指派，也可调整Bug类型及优先级，如图所示。72确认Bug（2）解决Bug。Bug的解决方案如图所示。无论是顺利解决，还是因某种原因延期处理，Bug都会再次被指派给测试人员进行验证，此时Bug状态自动流转为已解决。测试人员接到指派后，可根据Bug的修复情况选择关闭Bug或再次激活Bug。由此可见，禅道覆盖了大部分常见的Bug处理流程，同时支持自定义流程节点及操作权限。73Bug的解决方案项目六测试报告撰写74撰写测试报告任务

751. 了解测试报告的基本概念与组成。2. 能撰写测试报告。76测试任务接近尾声，测试人员需以测试报告的形式向项目组汇报本次测试的结论。本任务要求针对iceCMS内容管理系统项目的测试过程进行总结分析，包括测试项目的概要描述、测试过程的回顾、测试完成情况及缺陷的统计与分析、测试过程的总结与建议等，并以文档形式完成测试报告的撰写。77一、测试报告概述1. 缺陷相关案例当测试执行阶段即将结束时，测试人员需对当前的测试活动进行总结，对测试过程进行归纳，对测试数据进行统计，即撰写测试报告。撰写测试报告的目的是确保项目相关人员了解软件的测试状况与质量水平，相关人员可根据测试报告评估被测软件的质量，发现潜在问题与风险，进而决定产品是否可以发布。7879测试报告是测试过程中的重要文档，在保证软件质量、提升用户体验、辅助项目决策、跟踪缺陷修复进度、评估测试有效性以及文档归档等方面都具有重要作用。二、测试报告的组成1. 测试概