您现在的位置是：首页 >学无止境 >【软件测试】测试经验：「测试用例」设计、审查、管理网站首页学无止境
【软件测试】测试经验：「测试用例」设计、审查、管理
目录
一、测试用例的设计
（1）测试用例
① 测试用例的概念
- 测试用例是为某个特定目标而设计的，它是测试操作过程序列、条件、期望结果及相关数据的一个特定的集合
- 测试用例是用于验证软件功能或模块是否按照规定的要求正常运行的一系列步骤和输入数据，是软件测试的一个重要部分，用于检查应用程序的各种行为、功能和性能等方面，以确保其符合业务要求和用户期望
- 在软件开发过程中，测试用例通常在测试计划的基础上编写，测试计划包括测试目标、测试范围、测试方案、测试资源等，通过测试用例验证软件的特定方面的功能是否正确
- 测试用例可以是手动的，也可以通过自动化测试工具自动生成和执行
- 测试用例可以作为一个测试计划的量化指标，来衡量测试的完整性和准确性
② 测试用例的功能
- 重要参考依据
- 帮助实施有效的测试
- 知识传递的过程
- 重复使用
- 通过率
- 提供参考
- 评估测试
- 积累过程
③ 良好测试用例的特征
1. 可以最大程度地找出软件隐藏的缺陷
2. 可以最高效率的找出软件缺陷
3. 可以最大程度地满足测试覆盖要求
4. 既不过分复杂、也不能过分简单
5. 使软件缺陷的表现可以清楚的判定
- 测试用例包含期望的正确的结果
- 待查的输出结果或文件必须尽量简单明了
6. 不包含重复的测试用例
7. 测试用例内容清晰、格式一致、分类组织
④ 测试用例设计的概念
- 测试用例设计是软件测试中非常重要的一个环节，在设计用例之前，需要先完成需求评审和需求分析，可以先编写 XMind 测试点脑图，再设计测试用例
- 测试用例的设计，类似于软件产品的设计，可以考虑面向对象、面向结构或面向方法来实现其框架，然后在这框架下细化测试用例 —— 设计具体的测试用例
- 在设计测试用例时应该注意覆盖尽可能多的业务场景，以涵盖所有的功能和模块，同时确保测试用例的简洁明了和可重复性
- 在实际测试工作中，测试用例的设计、执行和管理都是非常重要的，他们可以帮助测试团队发现和定位软件中的缺陷和性能问题，提高软件质量和用户体验
（2）测试用例设计考虑因素
① 测试用例设计的主要影响因素
- 需求目标：是功能性的需求目标也是非功能性的需求目标。
- 用户实际使用的场景：从用户的角度来模拟程序的输入，包括用户的操作习惯，使产品更能贴近用户的需求；加强培养测试人员的用户体验意识，让他站在用户的角度去思考产品的每一个特性，确保为测试用例建立正确的判断依据。
- 软件功能需求规格说明书、产品设计文档等：是测试用例设计的主要参考文档，这些文档对产品特性的描述方法、格式和详细程度，也会影响到测试用例的设计。
- 测试的方法对测试用例的设计影响非常大：在测试用例的设计思路上，白盒测试方法和黑盒测试方法是从不同的哲学思想来解决问题的，前者从内部逻辑思路来考虑，后者从外部功能思路来考虑。
- 测试的对象：客户端软件和服务器端系统、分布式系统和集中式系统、异步系统和同步系统等，其测试用例的侧重点或测试剖面是不同的，它们从不同的侧面去发现软件系统的弱点或薄弱环节。
- 软件实现所采用的而技术：不同的技术，要进行不同深度的挖掘，而且采用的测试工具也不同。
② 测试用例设计的基本思想
- 设计测试用例时，要寻求系统设计、功能设计的弱点：测试用例需要确切地反映功能设计中可能存在的各种问题，而不要简单拷贝产品规格设计说明书的内容。
- 设计正面的测试用例，应该参照设计规格说明书，根据关联的功能、操作路径等设计：而对孤立的功能则直接按功能设计测试用例，基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达 100%。
- 设计负面的、异常的测试用例：如考虑错误的或者异常的输入，往往可以发现更多的软件缺陷，这显得更为重要；例如，在进行电子邮件地址校验的时候，考虑错误的、不合法的（如没有 @ 符号的输入）或者带有异常字符（单引号、斜杠、双引号等）的电子邮件地址输入，尤其是在做 Web 页面测试的时候，通常会出现因一些字符转义问题而造成异常情况。
（3）测试用例的架构
① 测试用例的架构
- 可以根据产品特性建立起测试用例之间的关系
- 容易常见为测试执行的任务
- 提高测试执行的效率
- 容易进行测试覆盖率的度量，提高测试的可视性
- 更容易操作测试用例的评审
- 更好地组织和维护测试用例
② 测试用例的框架设计方法
- 按测试类型设计的测试用例框架
- 按程序功能设计的测试用例框架
③ 测试用例的框架层次
测试用例分为多个层次是很明显的：
- 例如，在 “登录” 功能模块中，可以分为 3 个层次：
（4）测试用例的优先级
① 用例优先级的属性状态
- 研发自测：前后端提测前需完成的自测环节，在冒烟测试用例中抽取特别影响主流程的用例，让研发自测联调，自测用例通过后才允许开发提测，不达标可驳回研发全部提测任务；优先级无法自定义属性时，则默认是【研发自测】类型用例的 [高] 优先级状态
↓↓↓↓↓
- 冒烟测试：小版本确认测试（BVTs），一组你想先运行的以确定这个给出的小版本是否可以达到功能测试的测试用例，如果冒烟测试失败，也可以驳回研发的部分提测任务，但是其他主流程不影响的，依旧可以继续测试；优先级无法自定义属性时，则默认是【冒烟测试】类型用例的 [高] 优先级状态
↓↓↓↓↓
- 高：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合，凡是影响后续主流程测试的用例均属于高级别；默认是【功能测试 / 接口测试】类型用例的 [高] 优先级状态
↓↓↓↓↓
- 中：这是使给出的功能区域或功能变得更详细，检查功能的多数方面包括边界，错误和配置测试的测试用例，细节规范限制，不影响主流程测试的用例，但是必须在此迭代实现的功能；默认是【功能测试 / 接口测试】类型用例的 [中] 优先级状态
↓↓↓↓↓
- 低：这是通常最少被执行的测试用例，但这并不意味着这些测试都不重要，只是说他们在项目的生命期间里不是常常被运行，例如 GUI ，错误信息，可用性，压力和性能测试，不影响本次迭代上线功能、不影响主流程测试的用例，不需要在此迭代实现的功能，比如一些兼容问题，界面优化问题，提示语统一规范优化问题等，性能或压力测试一般会统一一个时间专门测试并且长期优化即延期测试，或者可延期实现的功能需求用例等，均属于低等级，可不执行或延期执行测试；默认是【功能测试 / 接口测试 / 兼容测试 / 性能测试 / 安全测试】类型用例的 [低] 优先级状态
② 分配用例优先级的方法
在测试实践中，测试用例的优先级常常被用于划分测试任务，优先执行关键的测试点和验证场景。在确定测试用例优先级时，需要考虑一些实际因素，如码农的意见、商业需求和时间限制等。可以根据以上方法之一进行优先级划分，以便于针对风险点、关键场景进行测试，使测试过程更高效、可控和可重复。
以下是一些分配用例优先级的常用方法：
风险优先：将测试用例按照风险程度进行优先级划分，即按照测试用例的风险等级，将优先级划分为高、中和低三个级别，并优先执行高风险用例。
功能优先：将测试用例按照功能点进行优先级划分，即将优先级划分为必须测、非常重要、一般重要和次要等级，并优先执行必须测和非常重要的测试用例。
时间优先：将测试用例按照时间优先级进行排序，检查截止时间更紧急的测试任务，并确定要在最短时间内修复的重要问题。
代码变更优先：将测试用例按照代码变更的频率进行划分，检查最近一轮代码更改的测试用例，并将其优先级设置得更高。
随意分配：
- 把所有功能性验证的测试标注为高优先级别
- 把所有错误和边界值或确认测试标注为中优先级别
- 把所有非功能性的测试标注为低优先级别
提升和降级：
1. 把功能性验证测试分为两组：重要和不是十分重要
- 将 “不是十分重要” 的功能性验证测试降级为中优先级别
2. 把错误和边界测试分成两组：重要和不是十分重要
- 把 “重要” 的错误和边界测试升级为高优先级别
3. 把非功能性测试分成两组：重要和不是十分重要
- 把 “重要” 的非功能性测试升级为中优先级别
4. 针对每组高，中和低优先级别的测试用例，重复划分和升级、降级流程真的达到一个点，可以在不同优先级别之间移动的测试用例的数量到最小
识别小版本验证测试用例：
1. 现在，为了确保小版本是可以测试的并准备好给小组其他成员开始测试，需筛选出必须在每个小版本中都检查的测试用例：
- 将分好优先级别的测试用例分成两组：严重和重要的
- 将 “严重” 的高优先级的测试用例升级为 BVT 优先级，即冒烟测试 “高” 优先级
2. 注意：不要先识别 BVT 测试用例！BVT 只是高优先级别测试用例的精选，它们已经被确定为对系统和测试是非常重要的。
3. 在这个流程的最后，就是要检查优先级别的百分比分布情况是：
注意：研发自测用例不计入占比中，因为这个是测试抽取部分冒烟用例给开发自测用的而已
- 冒烟测试（BVT） 为 10-15 %
- 高为 20-30 %
- 中为 40-60 %
- 低为10-15 %
4. 使用从 1 到 5 的一个刻度，从最严重到最少的严重程度，量化可靠性风险如下：
- 这个功能的失败将影响用户
- 这个功能的失败将给公司造成重大的影响
- 这个功能的失败将引起一个潜在的延期给客户
- 这个功能的失败对公司将有较小的影响
- 这个功能的失败没有任何影响
（5）测试用例设计原则
软件测试用例的设计遵守下列 4 步：
- 制定测试用例涉及的策略和思想，在测试计划中描述出来
- 设计测试用例的框架，也就是测试用例的结构
- 细化结构，逐步设计出具体的测试用例
- 通过测试用例的评审，不断优化测试用例
测试用例设计原则：
- 基于测试需求的原则：应按照测试类别的不同要求，设计测试用例。 如，单元测试依据详细设计说明，集成测试依据概要设计说明，配置项测试依据软件需求规格说明，系统测试依据用户需求（系统/子系统设计说明、软件开发计划等）。
- 基于测试方法的原则：应明确所采用的测试用例设计方法，为达到不同的测试充分性要求，应采用相应的测试方法。如等价类划分、边界值分析、猜错法、因果图等方法。
- 兼顾测试充分性和效率的原则：测试用例集应该兼顾测试的充分性和测试的效率；每个测试用例的内容也应完整，具有可操作性。
- 测试执行的可再现性原则：应保证测试用例执行的可再现性。
（6）测试用例的元素
① 测试用例的组成元素
一个测试用例包含了如下部分：
对一个特定的测试对象 (test object)，在规定的条件或环境下（前置条件和后置条件），输入一组输入数据或执行操作步骤后，生成一组相应的期望的结果。
测试用例 = <输入数据+，期望的结果+，测试对象，边界条件*>
② 测试用例的元素：5 W 1 H
测试目标：Why —— 为什么而测试？
- 功能 、性能、可用性、容错性、兼容性、安全性等
测试对象：What —— 测试什么？
- 被测试的项目，如对象、函数、类、菜单、按钮、表格、接口、整个系统等
测试环境：Where —— 在哪里测？
- 测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作系统、浏览器、通讯协议 等单机或网络环境
测试前提时间：When —— 什么时候可以测？
- 测试用例运行时所处的前提或条件限制
输入哪些数据：Which —— 那些数据？
- 在操作时，系统所接受的各种可变化的数据，如数字、字符、文件等
操作步骤：How —— 如何测？
- 执行软件和程序的先后次序步骤等，如打开对话框、点击按钮等
③ 每个测试用例应包括的要素
测试用例一般包括：
- 应用程序场景：测试用例所适用的应用程序场景，例如对某个特定的功能或特性的测试，【所属系统】[所属模块] 等
- 用例类型：研发自测、冒烟测试、功能测试、接口测试、性能测试、安全测试、兼容测试、软硬件结合测试等。
- 用例状态：正常、更新、废弃等，记录多版本的用例变更，需要只维护最新的用例，方便后续整合全部用例仅留正常与更新状态的用例。
- 测试用例优先级：测试用例的优先级，根据优先级，有些测试用例首先被执行
- 测试用例编号：是指为测试用例进行唯一标识和区分而设置的一种编号或标识符。测试用例编号通常包括字母、数字或符号等字符组合，用于标识和区分不同的测试用例。测试用例编号的设置可以在测试计划开始时进行规划，通常是根据测试用例的功能、模块或场景等特性进行编号，以便于测试人员进行快速识别和查找。测试用例编号应当相对简短，并注意具有描述性，方便测试人员理解，同时需要唯一且有序，以便于管理和追踪测试用例的执行和结果。测试用例编号可以使用Excel、测试管理工具等方式进行管理和维护。
- 测试用例名称：是指对测试用例进行命名和标识的一种方式，便于管理和组织测试用例。测试用例名称应当简明扼要、具有表达力和描述性，同时要遵循一定的命名规范和命名规则，使得测试用例名称可以清晰地表达测试用例的主要功能和场景。常见的测试用例命名规则包括使用动词加名词、使用模块加功能、使用场景加动作等方式，具体的命名规则可以根据团队需要进行定制。
- 前置条件：在执行测试用例之前需要满足的先决条件，例如需要特定的数据或前提条件；系统环境、初始化数据、测试工具、网络环境、系统状态、账号角色权限准备等
- 操作步骤：是指测试人员为了验证某一需求或功能是否正确而要执行的具体步骤。操作步骤应当是清晰明了且细致的，以确保测试人员按照规定的步骤执行测试用例，并能准确地记录测试结果。需要尽可能详细地描述每一步的操作和预期结果，以确保测试人员能够快速且准确地执行测试用例。同时，也需要考虑测试用例的可重复性和可维护性，以便于后续的测试维护和管理。
- 预期结果：测试用例在执行后所期望得到的结果，包括是否通过或失败，并在失败时描述可能的错误原因
- 执行结果：测试用例执行状态（测试通过/失败）、实际结果、测试环境状态等
- 测试执行者：测试人员名称
- 用例执行日期：测试人员执行测试用例的日期
- 测试用例设计者：用例编写人员名称
- 用例编写日期：用例编写人员编写测试用例的日期
- 所属版本号：测试用例所属的迭代版本号，方便多迭代进行用例更新与维护
⚫名称和标识：每个测试用例应有唯一的名称和标识符
⚫测试追踪：说明测试所依据的内容来源，如系统测试依据的是用户需求，配置项测试依据的是软件需求，集成测试和单元测试依据的是软件设计
⚫用例说明：简要描述测试的对象、目的和所采用的测试方法
⚫测试的初始化要求：前置环境准备、前置数据准备、测试账号权限角色限定等
⚫测试的输入：在测试用例执行中发送给被测对象的所有测试命令、数据和信号等
⚫期望的测试结果：说明测试用例执行中由被测软件所产生期望的测试结果，即经过验证，认为正确的结果；必要时，应提供中间的期望结果；期望测试结果应该有具体内容，如确定的数值、状态或信号等，不应是不确切的概念或笼统的描述
⚫评价测试结果的准则：判断测试用例执行中产生的中间和最后结果是否正确的准则；对于每个测试结果，应根据不同情况提供如下信息：
- 实际测试结果所需的精度
- 实际测试结果与期望结果之间的差异允许的上限、下限
- 时间的最大和最小间隔，或事件数目的最大和最小值
- 实际测试结果不确定时，再测试的条件
- 与产生测试结果有关的出错处理
- 上面没有提及的其他准则
⚫操作过程：实施测试用例的执行步骤；把测试的操作过程定义为一系列按照执行排列的相对独立的步骤，对于每个操作应提供：
- 每一步所需的测试操作动作、测试程序的输入、设备操作等
- 每一步期望的测试结果
- 每一步的评价准则
- 程序终止伴随的动作或差错指示
- 获取和分析实际测试结果的过程
⚫前提和约束：在测试用例说明中施加的所有前提条件和约束条件，如果有特别限制、参数偏差或异常处理，应该标识出来，并要说明它们对测试用例的影响
⚫测试终止条件：说明测试正常终止和异常终止的条件
④ 测试用例的范例
二、测试用例的审查
（1）测试用例的质量保证
- 首先，要对用户需求、服务质量要求、产品特性有深刻且全面的理解
- 其次，采取正确、恰当的方法进行用例设计
- 再者，按照测试用例的标准格式或规范的模板来书写测试用例
- 除此之外，对测试用例的检查、评审，也是一种提高测试用例质量的主要且有效的手段
测试用例的质量对确保应用程序的质量、应用程序的稳定性和成功交付任务至关重要。
以下是一些可行的方法来保证测试用例的质量：
设计全面和完整的测试用例：在设计测试用例时，必须考虑所有测试场景，包括正常流程和各种异常情况，以确保测试覆盖率、评估测试用例的有效性和准确性。
确保测试用例是可重复的：确保测试用例是可重复的，并且可以在任何时候重复使用。这有助于验证修复程序后的准确性，并确保完整和确认测试用例的一致性。
包括边界条件和错误情况：测试用例设计师需要针对涉及边界条件和错误情况的各种测试场景。这有助于发现代码问题和改进测试用例的有效性，并确保测试用例全面覆盖被测试的代码和功能。
借鉴已有测试用例：利用过去测试结果作为参考，并利用过去测试结果发现的问题，设计和编写测试用例，帮助避免重复劳动和提高测试效率。
测试用例监控：通过测试用例的监控和跟踪，可以确定测试计划的进度、被测试应用程序的状态以及任何工作阻碍或问题，以及相应的解决方案和改进方案。
采用工具和自动化：利用自动化工具，实现测试用例的自动执行，帮助提高测试执行的效率和覆盖范围，并在大型项目中提高测试用例的管理水平。
总之，保证测试用例的质量需要充分考虑测试场景和测试用例设计方案，确保测试用例是可重复的，全面准确，考虑边界条件和异常情况，并采用一系列工具和自动化策略来提高测试用例的质量和管理水平。
（2）测试用例书写标准
- 标志符（Identification）：每个测试用例应该有一个唯一的标志符，它将成为所有与测试用例相关的文档 / 表格引用和参考的基本元素，这些文档 / 表格包括设计规格说明书、测试日志表、测试报告等。
- 测试环境要求（Test Environment）：用来表征执行测试用例需要的测试环境，一般来说，在整个测试模块里面应该包含整个测试环境的特殊需求，而单个测试用例的测试环境需要表征该测试用例单独所需要的特殊环境需求。
- 输入标准（Input Criteria）：用来执行测试用例的输入需求。这些输入可能包括数据、文件，或者操作（例如鼠标的左键单击、键盘的按键处理等），必要的时候，相关的数据库、文件也必须被罗列。
- 输出标准（Output Criteria）：标识按照制定的环境和输入标准得到期望的输出结果。如果可能的话，尽量提供适当的系统规格说明来证明期望的结果。 测试用例之间的关联：用来标识该测试用例与其他的测试（或其他测试用例）之间的依赖关系。在测试实际过程中，很多的测试用例并不是单独存在的，他们之间可能有某种依赖关系，例如用例 A 需要基于 B 的测试结果正确的基础上才能进行，此时需要在 A 的测试用例中表明对 B 的依赖性，从而保证测试用例的严谨性。
- 测试项（Test Items）：测试用例应该准确地描述所需要测试的项及其特征，测试项应该比测试设计说明中列出的特性描述更加具体，例如，我们做 Windows 计算器应用程序的窗口测试，测试对象是整个应用程序的用户界面，其测试项将包括该应用程序的界面特性要求，例如窗口缩放测试、界面布局、菜单等。
（3）测试用例评审要点
① 优秀测试用例的特点
明确的测试目标：测试用例需要明确测试的目标和验证点，以便于能够有效地检测系统缺陷，并且满足项目的需求和质量要求。
- 测试范围的覆盖率高：依据特定的测试目标的要求，覆盖所有的测试范围或内容。测试用例需要全面地覆盖软件系统的功能点、业务场景、异常情况等，以确保软件的稳定性、可靠性和可维护性。
- 易用性：设计思路容易被理解，测试用例的组织结构合理，测试用例的执行比较顺畅，操作连贯性好。
- 易读性：精确和清晰，前提条件、步骤和期望结果等描述清楚、准确。测试用例需要准确、清晰地描述测试步骤、测试数据、预期结果等，以便于测试人员能够轻松地理解和执行测试用例，并且能够尽快地定位和解决问题。
- 易维护性：测试用例需要容易维护和管理，尽量不依赖复杂的测试环境、测试数据和工具，以便于测试人员在软件迭代和测试升级过程中快速调整和更新测试用例。应该以很少的时间来完成测试用例的维护工作，包括添加、修改和删除测试用例。易用性和易读性，有助于易维护性。
可重复性：测试用例需要具备可重复性，即能够重复地执行和获得相同的测试结果，以便于团队成员进行有效的测试和问题的定位和解决。
逻辑性和连贯性：测试用例需要具备良好的逻辑性和连贯性，各个测试点之间需要相互关联和串联，遵循良好的测试方法和流程，能够有效地反映软件的实际运行情况。
测试用例设计能反向思维，有效地发现缺陷：测试是为了发现缺陷，能更快地发现缺陷或更有可能发现潜在缺陷的测试用例可提高测试效率。
② 测试用例评审方法
测试组内部：测试主管审核组员测试用例
研发团队：测试组建用例评审会议，让前端、后端、产品参与用例评审
测试用例的评审，可以从测试用例的框架和结构开始，然后逐步向测试用例的局部或细节推进：
- 为了把握测试用例的框架、结构，要分析其设计思路是否符合业务逻辑，是否符合技术设计的逻辑，是否可以和系统架构、组件等建立起完全的映射关系。
- 在局部上，应有重有轻，评审时应抓住一些测试的难点和系统的关键点，从不同的角度向测试用例的设计者提问。
- 在细节上，检查是否遵守测试用例编写的规范或模板，是否漏掉每一元素，每项元素是否描述清楚。
测试用例评审是一种前期 QA 工作，通过对测试用例内容、质量和可行性等方面的审查和讨论来评估测试用例的有效性和可行性，以确保测试用例的质量和适应性。它可以通过评估测试用例的有效性和可行性来提高测试效率和测试质量。测试人员需要认真对待测试用例评审工作，并且不断地进行优化和改进。
以下是一些测试用例评审的方法：
专家评审会议：组织测试团队中的专家评审测试用例，通过团队讨论和审查来评估测试用例的有效性和可行性，并对测试用例进行优化和完善。
小组评审会议：组织测试团队中的小组进行测试用例评审，通过对测试用例的内容进行分析和讨论，来评估测试用例的质量和可行性。
自评和自审：测试团队成员对自己编写的测试用例进行自评和自审，通过检查测试用例的格式、逻辑和正确性等方面，提高测试用例的质量和可行性。
无论采用什么方法，测试用例评审需要考虑以下几个方面：
测试用例的可行性：测试用例是否能够在实际测试环境中执行并取得有效的测试结果。
测试用例的覆盖率：测试用例是否能够覆盖所有的功能点、业务场景、异常情况等。
测试用例的效率：测试用例是否能够高效、快速地执行，并且能够重复使用和维护。
测试用例的质量：测试用例是否准确、有效、清晰，并且能够达到预期的测试目标。
③ 检查表
检查表（Check List） ：
- 是用来帮助评审员找出被评审的对象中可能的缺陷的。
- 检查表是一种常用的质量保证手段，也是正式技术评审的必要工具，评审过程往往由检查表驱动。
- 一份精心设计的检查表，对于提高评审效率，改进评审质量具有很大帮助。
检查表的优点：
- 可靠性强：人们借助检查表以确认被检查对象的所有质量特征均得到满足，避免遗漏任何项目。
- 效率高：检查表归纳了所有检查要点，比起冗(rong)长的文档，使用检查表具有更高的工作效率。
制定合适的检查表方法：
- 不同类型的评审对象应该编制不同的检查表
- 根据以往积累的经验收集同类评审对象的常见缺陷，按缺陷的（子）类行进行组织，并为每一个缺陷类型指定一个标识码
- 基于以往的软件问题报告和个人经验，按照各种缺陷对软件影响的严重性和（或）发生的可能性从大到小排列缺陷类型
- 以简单问句的形式（回答 “是” 或 “否”）表达每一种缺陷，检查表不易过长
- 根据评审对象的质量要求，对检查表中的问题做必要的增、删、修改和前后次序调整
根据检查项目进行评审：
- 通过检查表来进行测试用例的评审，也是一种简单而有效的方法，例如，针对检查表中的各项问题，是否都能回答 “是” 。
- 如果答案都为 “是” ，意味着测试用例通过了评审。
三、测试用例的有效管理
（1）测试用例执行的管理
① 测试用例执行的管理作用
- 好的开始是成功的一半，在开始设计测试用例时，就要抓管理，确保在测试用例设计和使用过程中能开一个好头。
- 测试用例能被有效、灵活地执行，就需要一套管理机制和相应的工具 / 系统的协助。
② 测试用例执行的管理方法
1. 意识和态度的教育 【一切从客户需求出发】
- 促进和客户、产品设计人员、开发人员等的直接沟通和充分交流
- 加强培训和知识共享，让产品设计和开发人员做专项的介绍
- 加强产品需求和设计文档的评审，强调要通读所有内容，澄清各种问题，使大家达成共识
- 让测试人员讲解对产品特性和功能的理解
2. 责任到人
- 在测试用例设计的管理中，应将模块划分清楚，责任到人。
3. 方法和流程：要在设计方法和流程上加强管理，包括：
- 采用测试用例的模板，参考已有的范例
- 要求先设计工作流程图、数据流图
- 要求测试人员相互审查、提问
- 集体审查测试用例，邀请客户、产品设计人员、开发人员的等参加
测试用例执行的管理方法是确保测试用例能够正确执行和管理的一系列措施。测试用例的执行管理主要包括以下几个方面：
测试用例执行计划：为了确保测试用例能够有序、高效地执行，需要制定详细的测试用例执行计划，包括测试执行时间、测试执行人员、测试执行工具、测试用例执行顺序等。
测试用例执行记录：在测试用例执行过程中，需要及时记录测试用例的执行情况，包括测试用例的执行结果、执行时间、执行人员等。
测试用例执行控制：为了确保测试用例的顺序和正确性，需要对测试用例执行进行有效的控制和监督，包括测试用例执行状态的跟踪、执行时间的控制、执行人员的管理等。
测试用例执行分析：在测试用例执行完成后，需要对测试用例执行结果进行分析和总结，包括对测试用例执行过程中出现的问题进行归纳分析、对测试用例执行结果进行汇总统计等。
- 测试用例执行管理需要进行持续的监控和优化，以便于在测试过程中进行快速调整和优化。
- 为了有效管理测试用例执行，我们可以借助测试管理工具，或者自主开发一套测试用例管理系统，以便于更好地进行测试用例的管理和优化。
- 同时，在执行测试用例之前，需要对测试用例的前置条件进行明确和管理，确保测试用例能够正确执行，提高测试用例的可重复性和执行效率。
③ 测试用例执行的管理工具
目前很多软件测试框架和自动化测试工具都支持测试用例管理和执行：
例如 TAPD、禅道、飞书、Jira、TestLink 、TestRail、Selenium、Appium 等。
④ 有效的测试用例管理示例
- 可以从不同的测试模块中选择一部分测试用例，然后和所需的测试环境组合，生产测试套件。
- 可以设定一些灵活的过滤条件，如未通过的测试用例、某一类型的测试用例和曾发现缺陷的测试用例等，自动生成测试套件。
- 可以选择若干个测试套件，设定进度，构造执行测试的不同过程，完成特定的测试计划或测试任务。
- 针对每个测试计划，也可以分解成多个测试任务，然后分配任务给相应的测试人员。
- 测试人员执行测试任务，完成测试过程，并报告测试结果。
（2）测试用例的维护
- 维护测试用例的过程是一项长期的任务，而且保证其及时性。
- 和编写一个新项目的测试用例不同，维护测试用例一般不会进行大动干戈，不会改变测试用例的结构。
① 测试用例需要更新的原因
- 先前的测试用例设计不全面或者不够准确：随着测试的深入和对产品规格说明书的深入研究，对某些功能、特性、逻辑等的理解越来越清楚、深刻
- 所发现的严重的软件缺陷没有被目前的测试用例所覆盖
- 新的版本中有新功能的需求或者原有功能的增强而需要发生改动
- 编写的测试用例不规范或者语句错误
- 旧的测试用例已经不再适用，需要删除
测试用例需要经常更新的原因包括：
产品需求变更：随着项目或产品需求的变化，测试用例也需要相应调整以适应新的需求变化。
缺陷修复：在测试中发现缺陷后，测试用例可能需要相应更新，以确保已修复的缺陷不会再次出现，同时确保测试用例的有效性和准确性。
新功能添加：如果项目中添加了新的功能，则需要创建新的测试用例来保证这些功能得到正确的测试覆盖。
产品优化：如果产品存在性能、可用性或用户体验等方面的问题，则可能需要对测试用例进行调整，以确保测试覆盖的改进，并最终提高软件品质。
技术升级：随着技术的发展和变化，新的测试方法、自动化工具等出现，可能需要对测试用例进行更新和重新组织，以对技术变化做出相应调整。
总之，测试用例需要经常进行更新，以确保测试的全面性、准确性和有效性。需要及时更新测试用例，以应对新的需求、产品变更、缺陷修复、新功能添加、产品优化等。这将帮助团队及时发现问题和错误，并确保产品的高质量和稳定性。
② 软件产品的多个版本共存现象
- 软件产品的多个版本共存现象是很常见的。
- 在生产环境中，由于业务需求、时间、成本等因素，可能会导致部分用户使用较旧的版本，而另一部分用户会使用更新的版本。这种情况下，多个版本共存的现象可能会出现。
- 软件产品的多个版本共存需要进行集中管理，并实施适当的技术和管理策略，以确保版本之间的交互性和支持，并为用户提供方便。
多个版本共存现象的具体表现：
同一用户使用不同版本：某些用户会同时使用多个版本的软件，例如，旧版能够支持他们的旧操作系统或特定硬件，而新版可以具备新功能和更好的性能等。
同一用户团队使用不同版本：在大型企业和机构中，由于组织结构导致不同的团队使用不同的软件版本。
不同用户团队使用不同版本：在一些企业中，部门之间使用不同版本的软件产品。
产品发布版本的变化：在产品的不同版本进行更新和发布之后，旧版本和新版本都需要保留。
对于多个版本共存现象，需要注意：
保持版本控制：使用版本控制工具来确保版本之间的变更、更新和记录，以便在需要时进行比较和恢复。
提供完整的文档：为每个版本提供完整的文档，包括版本的差异、功能、缺陷和问题等方面，以便用户明确了解其使用的软件。
维护支持：旧版本的支持仍是重要的，需要确保不会忽略这些版本的用户。因此，需要对于旧版本实行相应的维护和技术支持。
形成统一管理：推行版本化的产品和工作流程，统一管理，确保每个版本的质量和有效性。同时，启动协作和共享，通过不断集成进行升级、修改和更新等操作，最大程度的减少各个版本之间的差异性。
③ 测试用例维护的分类处理
- 产品特性没变，只是根据漏掉的缺陷来完善测试用例：这时候，增加和修改测试用例均可，因为当前被修改的测试用例对相应的版本都有效，不会影响某个特定版本多拥有的测试用例
- 原有产品特性发生了变化，不是新功能特性，而是功能增强，这时候原有的测试用例只对先前版本（如 1.0、2.0）有效，而对当前新的版本（如 3.0）无效：这时，绝不能修改测试用例，只能增加新的测试用例版本，不能影响原有的测试用例
- 原有功能取消了，这时只要将与该功能对应的测试用例在新版本上置为空标志或 “无效”状态，但不能删除这些测试用例，因为它们对先前某个版本还是有效的
- 完全新增加的特性已经很明了，那么就得增加新的测试用例
④ “测试用例爆炸” 问题
“测试用例爆炸” 是指测试用例数量增长过快，导致测试成本和时间成本呈指数级上升。这个问题通常在软件开发的后期出现，导致测试团队难以管理和执行测试用例。
具体表现为：
测试用例数量不断增加：由于产品需求和功能不断增加，测试用例数量也在不断增加，且难以控制。
测试人员的工作量增加：测试用例数量增加，测试团队的工作量也随之增加，测试人员难以在规定的时间内完成所有的测试任务。
测试管理困难：测试用例数量增长过快，测试管理人员难以跟踪、管理和更新所有的测试用例。
“测试用例爆炸” 问题主要是因为测试用例设计不当，或者测试用例的优化和精简不够。
为了有效解决这个问题，我们可以尝试以下措施：
测试用例优化：对测试用例进行精简和优化，筛选出关键的测试点，减少不必要的测试用例。
自动化测试：使用自动化测试工具对测试用例进行自动化操作，以缩短测试时间和降低测试成本。
归档管理：对测试用例进行归档管理，定期回顾，删除过期、废弃的测试用例，以保证测试用例的质量和有效性。
人员分工协作：合理安排测试人员的工作任务，对测试人员进行专业分工，集中精力对重要功能或场景进行测试。
通过以上措施，可以有效提高测试效率，降低测试成本，并且能够在保证测试质量的前提下，控制测试用例的数量增长。
【示例】假设我们有： 5 个测试对象，每个对象有 5 个测试主题，每个主题有 5 个测试用例，每个用例可有 5 个不同的测试数据。
【产生的结果】
【问题】测试用例数量爆炸！
【解决方法】
1. 系统的生成所有可能的变量
2. 识别和过滤冗余和不重要的变量
- 100% 的测试通常是不可能的！
站长推荐
- stm32使用HAL库配置串口中断收发数据（保姆级教程）
stm32使用HAL库配置串口中断收发数据（保姆级教程） - SpringSecurity实现前后端分离认证授权
SpringSecurity实现前后端分离认证授权 - U8W/U8W-Mini使用与常见问题解决
U8W/U8W-Mini使用与常见问题解决 - 【社区图书馆】伴我前行的一本书《The C Programming Language》
【社区图书馆】伴我前行的一本书《The C Programming Language》 - 【云原生进阶之容器】第六章容器网络6.6.1--Cilium网络方案概述
【云原生进阶之容器】第六章容器网络6.6.1--Cilium网络方案概述