用例缺陷进度编写-优快云博客

本文链接：https://blog.youkuaiyun.com/u013413621/article/details/121806735

一.目的

提升用例可读性；
降低临时接入测试人员接入成本；
降低由于人员变动带来的用例维护成本；
增强和保障自动化专项高效开展。

二.用例评价与常用设计

1.用例生命周期占比

需求分析：10%
用例编写：25%
用例执行：50%
用例维护：15%

2.测试用例设计方向

功能性需求：功能性用例约占7成，功能测试用例集主要涵盖的是功能测试场景，称为显示功能需求（指软件本身需要实现的功能）。
非功能性需求：非功能性用例约占3成，非功能性需求主要涉及安全性，性能以及兼容性三大方面。

3.“好的”测试用例
“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而与能否发现缺陷无关，具备如下三个特征：

整体完备性：“好的”测试用例一定是一个完备的整体，是由小测试用例组成的集合，能够完全覆盖测试的需求。
等价类划分的准确性：指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别。

4.常用的测试用例设计方法

理论层面：等价类划分方法，边界值分析方法，错误推测方法，因果图方法，判定表驱动分析方法，正交实验设计方法，功能图分析方法，场景设计方法，形式化方法，扩展有限状态机方法等。
软件企业实际工程实践层面（最常用）：等价类划分方法(有效等价类、无效等价类)【通常从值类型、范围入手】，边界值分析方法，错误推测方法。

三.测试策略

测试策略简单来讲就是需要明确“先测试什么后测试什么”和“如何来测试”，测试策略还需要说明，采用什么样的测试类型和测试方法。

功能测试：应该根据测试需求分析的思维导图来设计测试用例。因为主线业务的功能测试经常需要执行回归测试，所以需要考虑将主流功能业务进行分离设计。
兼容性测试：对于兼容性测试来说，Web测试需要确定覆盖的浏览器类型和版本，移动设备测试需要确定覆盖的设备类型和具体iOS/Android的版本等。
（1）已有的产品，可以通过分析历史访问数据，得出30%的移动设备类型以及iOS/Android的版本列表；
（2）一个全新的产品，可以通过数据统计网站查看目前主流的移动设备、分辨率大小、iOS/Android版本等信息来确定测试范围。
（3）兼容性测试用例的选取，往往依据已经实现的自动化测试用例（前提是项目组有UI自动化方面的建设）。
性能测试：对于性能测试，需要在明确了性能需求（并发用户数、响应时间、事务吞吐量等）的前提下，结合被测系统的特点，设计性能测试场景并确定性能测试框架。

四.用例编写整理

0.用例功能拆分思路
效果：划分单条用例时做到高内聚低耦合（划分时将功能模块中划分可测的单个功能，多个有关联的单功能组合时成为一个业务场景流）

参考：

根据大功能模块拆分成小功能模块
根据拆分成的小功能拆分具体功能（如：增、删、改、查操作）
根据被拆分的子功能进行业务组合（业务场景流）

1.用例名（用来概述整条用例的目的，即“测试用例标题是一条用例的概要描述”）
效果：用例标题能体现目的和结果，即“看到用例名大概知道用例是哪个模块执行什么操作，验证什么”。

参考：(用例标题可以采用“子模块名”_“功能名”+“验证点”构成，常用的结构为“主+谓+宾”)

如果是界面验证： xx模块_xx界面内容+数据正常/展示合理
如果是边界值/等价类验证： xx模块_xx功能+正常/失败
如果是逻辑验证： xx模块_xx功能逻辑+校验正常/错误
如果是跳转验证： xx模块_xx功能跳转正常
如果是组合判断：xx模块_xx功能组合正常/失败/验证

2.用例等级（依据使用频率和重要程度评估）
效果：使用频率和重要程度两个维度划分，不形成嵌套关系

参考：

P0：系统基本功能，划分依据，该用例执行失败会导致多处重要功能无法运行，该级别的测试用例在每一轮版本测试都需要运行，可作为冒烟用例，checklist用例依据。
P1：系统的重要功能，划分依据，主要包括一些功能交互相关、各种应用场景、使用频率较高的正常功能测试用例；在测试过程中可以根据版本当前的具体情况确认是否需要进行测试，可作为checklist用例依据。
P2：系统的一般功能，划分依据:使用频率较低，如特殊字符，字符串超长，消息超时等场景，回归测试中不一定都进行验证，不需要每个版本都进行测试。

3.前置条件（描述系统状态必须满足为真的条件，才能有效触发测试用例的执行）
效果：前置条件做到让用例的执行者明确系统所处的状态（需要满足哪些条件），执行测试时不会因前置条件不满足导致失败或受阻。

关注点：

根据业务数据流，抽离出处理当前业务需要具备的系统状态–》“很容易被自己忽略，因为需求是你看过（你自然清楚），但有可能后面执行的人不清楚”。
可以将一些与测试用例步骤现相关的错误处理细节，以前置条件的形式叙述，方便之后编写与前置条件不满足时的测试用例。
前置控制变量（控制其他条件正确，方便关注所要验证内容）
需要提供必要测试数据

4.操作步骤（描述操作/输入内容数据的过程）

评估维度：

步骤描述不冗余；
组织的用例步骤有【“操作过程”+“对应验证项”】或【“操作数据项”+“对应验证项”】；
操作能衔接前置条件（不冲突），冲突时应在步骤中写明条件，做分隔处理
步骤之间的关联紧凑，标点示意清晰
例如：（1）并列步骤是否使用分号进行分隔，上一步骤使用分号（2）不需要承接上一步骤的，上一步骤是否有使用句号分隔，需要承接上一步骤的，上一步骤结尾使用逗号分隔
用例步骤验证业务内容完整；

注意点:

操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；
操作和预期结果是必须对应，但操作中不要包含结果或条件；
步骤描述中会产生两种不同预期结果的，不建议存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）；
步骤描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等；
步骤中不允许出现二义性语句（可通过增加限定词，消除二义性）；

5.预期结果（执行完成操作后，程序预期表现的结果）
效果：预期结果验证点对应操作步骤验证点完整

评估维度：

对应序号的预期结果需要与对应步骤序号进行对应；
每个用例必需至少要有一条预期结果，结果不能为空；
结果中只能包含结果，不能有步骤；
一个结果有多个预期检查点时，确保步骤检查点对应完整；

五.撰写缺陷报告（单）

缺陷报告是测试工程师与开发工程师沟通的重要桥梁，也是测试工程师日常工作的重要“输出”。开发工程师可以根据缺陷报告快速理解软件缺陷，并精准定位问题，开发经理可以准确预估缺陷修复的优先级和严重程度，产品经理可以了解缺陷对用户或业务的影响程度。

缺陷标题：对“什么问题”的描述不仅要做到清晰简洁，还要具体，不能采用过于笼统的描述。描述问题的同时还必须清楚地表述与问题相关的上下文，也就是问题出现的场景。
缺陷概述：更多概括性的缺陷本质与现象的描述，是缺陷标题的细化，可以在这部分列出同一类型的缺陷可能出现的所有场景，还可以描述同样的问题是否会在之前的版本中重现。在这里，应该尽量避免以缺陷重现步骤的形式来描述，而应该使用概括性的语句。
缺陷影响：缺陷引起的问题对用户或者对业务的影响范围以及严重程度。缺陷影响决定了缺陷的优先级和严重程度。
环境配置：环境配置用于详细描述测试环境的配置细节，为缺陷的重现提供必要的环境信息。
前置条件：前置条件是指测试步骤开始前系统应该处在的状态，其目的是减少缺陷重现步骤的描述。
缺陷重现步骤：用简洁的语言向开发工程师展示缺陷重现的具体步骤。需确保缺陷的可重现性，并找到最短的重现路径，从而过滤掉那些非必要的步骤，避免差生不必要的干扰。
期望结果和实际结果：期望结果和实际结果通常与缺陷重现步骤绑定在一起，在描述重现步骤的过程中，需要明确说明期望结果和实际结果。
（1）期望结果：需要说明应该发生什么，而不是什么不应该发生；
（2）实际结果：应该说明发生了什么，而不是什么没有发生。
优先级和严重程度：
（1）缺陷越严重，优先级就越高；缺陷影响的范围越大，优先级也会越高；
（2）有些缺陷虽然从用户影响的角度来说不算严重，但是会妨碍测试或者自动化测试的执行，这类缺陷的严重程度低，但是优先级高；
（3）有些缺陷虽然严重程度比较高，但是考虑到修复成本以及技术难度，同时存在变通方案的，也会出现优先级低的情况。
变通方案：是提供一种临时绕开当前缺陷而不影响产品功能的解决问题方式，通常由测试工程师或者开发工程师提出，或者一起提出。
根原因分析 ：如果在发现缺陷的同时，定位出问题的根本原因，清楚地描述缺陷产生的原因并反馈给开发工程师，那么开发工程师修复缺陷的效率就会大幅提升。
附件：通常为缺陷的存在提供必要的证据支持，常见的附件有界面截图、测试用例日志、服务器端日志、GUI测试的执行视频等。