测试用例编写方法

2023-07-07 11:13:25   3  举报





AI智能生成

测试用例编写方法是一种系统化、规范化的过程，用于验证软件或系统是否满足预定的需求和功能。首先，需要明确测试目标和范围，然后分析需求文档，提取关键功能点。接着，根据功能点编写详细的测试步骤，包括预期结果和实际结果。在编写过程中，要注意覆盖正常情况、异常情况以及边界条件。最后，对测试用例进行评审和优化，确保其完整性和有效性。通过这种方法，可以有效地提高测试的质量和效率，降低软件缺陷的风险。

测试用例

测试

作者其他创作

大纲/内容

1 测试用例设计

1.1 确定测试范围

• 必须有完整的功能列表

• 需求已经组织评审和澄清

• 必须有完整的需求文档

1.2 用例设计原则

• 遵循“边界值”全覆盖原则

http://note.youdao.com/noteshare?id=c77cb3cbbc603cff1063ab087e0ac4e4&sub=1C5241CAE82A4899A069D520C927AC31

• 遵循”等价类划分场景全覆盖原则”

文档：等价类分析法典型案例.note 链接：http://note.youdao.com/noteshare?id=45aef80cc624d4924b5d2a10622a2c35&sub=0563DE824DB84C7BAF851EB7C0D0FEE4

• 遵循”测试用例路径唯一“原则

当出现多个路径时，需要新建用例去覆盖。一条用例仅覆盖一个测试点。降低漏测风险

• 遵循“单条用例覆盖最小化”原则

假如要测试一个功能 A，它有三个子功能点 A1，A2 和 A3，下面两种方法来设计测试用例：方法1 ：用一个测试用例覆盖三个子功能 -Test_A1_A2_A3，方法2 ：用三个单独的用例分别来覆盖三个子功能 - Test_A1，Test_A2，Test_A3 方法2，则遵循了“单条用例覆盖最小化”原则好处，当用例执行失败时，降低复现/定位复杂度。

• 遵循“测试用例与测试用例之间最低耦合度”原则

严谨使用上一条测试用例的结果，做为下一条测试用例的输入。 2、每一条测试用例，应该都是完整独立的。这样做的好处便于测试用例拉取、复用、可维护。减少后续投入成本。

1.3 用例设计维度

1.3.1 功能

• 正向（正常）场景

• 逆向（异常）场景

1.3.2 非功能

1.3.3 性能

1、性能测试，首先需要有具体的、明确的性能指标需求。

2、性能关注指标： CPU 、Memory、IO、网络传输速率等。

• 单品（模块）性能

比如SDK、算法、单独性能要求

• 整体性能

系统集成后的性能要求

• 网络传输性能

1.3.4 可靠（稳定）性

• 时间维度

• 负载稳定性

1.3.5 健壮性

• 看门狗

• 异常掉电

• 反复重启

1.3.6 易用性

• 安装易用性

• 运维易用性

• 功能操作易用性

1.3.7 客户体验

比如视频播放效果、操作是否顺手、开机时间等等

1.3.8 安全性

• 数据存储安全

• 网络传输安全

2 测试用例编写格式规范

2.2 用例标题

概述测试用例的主要内容，明确用例测试意图

• 语言简洁，阐明本条用例是干什么

• 一句完整的话

• 遵循“条件/动作"规则，常用的结构“主、谓、宾”

2.1 测试用例编写前提

• 测试范围已经确定

• 测试点已经梳理完成

• 用例转换路径：业务需求-功能需求-测试需求-测试点-测试用例

2.3 用例级别分布

• Lve 1 ：基本(～10%)

系统基本功能用例，可用于版本提交时的冒烟测试，可作为版本是否转测试通过和业务验收的依据。划分依据：该用例执行的失败会导致多处重要功能无法运行的。例如：开关机、升级等。

• Lve 2：重要（～20%）

系统中的重要功能用例。划分依据：主要包括一些功能交互相关、各种应用场景、客户使用频率较高的正常功能测试用例。例如：设备上报、录像回放效果、预览等功能。

• Lve 3：一般（～60%）

系统的一般功能划分依据：一般功能用例，包括异常路径的测试用例；使用频率低于2级用例。例如：表单输入边界值、特殊字符的校验等。

• Lve 4：生僻（～10%）

该级别用例一般比较少。主要是一些使用频率非常少的功能等。如果用例执行不通过，不会对系统和业务造成太大的伤害的测试用例 2.划分依据：该用例对应较生僻的预置条件和数据设置。例如：日志记录错误等。

2.4 预置条件

• 执行测试用例关键必备条件

• 让用例的执行者更加明确系统当前状态

• 预置条件不能阻塞测试用例的执行

2.5 操作步骤

• 用例描述中不允许出现二义性语句

• 用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等

• 用例描述中不允许存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）

• 操作和结果是一一对应的，但操作中不要包含结果的检查

• 操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚

• 操作路径唯一，不唯一则多条用例覆盖（降低耦合）

• 需要明确“测试关键输入”数据

2.6 预期结果

• 预期结果一定是客观的、可判定的

• 每一步操作都有对应的预期结果

1、即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果 2、期望结果禁止使用正确，正常，错误之类的含糊主观的字眼

• 预期结果一定是确定的

• 预期结果一定是符合需求的

1、即对同样的测试用例，系统的执行结果应当是相同的、确定的

• 结果对应不同输入数据有差别时需分别对应描述清晰

• 结果涉及消息：需明确关键查看内容

• 结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化

• 结果涉及页面，需明确页面提示结果、数据变化

• 结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等

• 一个结果有多个检查点时，确保检查点完整

• 结果中只能包含结果，不能有步骤

• 原则上每个用例必需要有预期结果，结果不能为空

3 测试用例编写方法

3.1 黑盒测试用例

• 场景图法

• 正交试验设计法

• 判定表驱动法

• 错误推测法

• 边界值分析法

• 等价类划分法

3.2 白盒测试用例

• 符号测试

• 域测试

• 基本路径覆盖测试法

• 逻辑覆盖法

• 静态质量度量法

• 静态结构分析法

• 代码检查法

4 测试用例编写原则

4.1 全面性

• 大量数据并发测试的准备

• 应考虑存在跨年、跨月的数据

• 应尽可能覆盖程序的各种路径

4.2 正确性

• 预期结果应与测试数据发生的业务吻合

• 输入界面后的数据应与测试文档所记录的数据一致

4.3 符合正常业务惯例

• 兼顾各种业务变化的可能

• 测试数据应符合用户实际工作业务流程

4.4 系统性

• 对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系

• 对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系

4.5 连贯性

• 对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯。

• 对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；
如果是依靠页面链接，页面链接是否正确。

4.6 仿真性

• 人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例

• 从项目需求分析文档/概要设计/详细设计/原型图中，了解出项目的需求

4.7 可操作性

• 测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果

5 用例设计步骤

5.1 测试需求分析

通过测试人员自己的分析、理解，整理成为测试需求，使测试人员能清楚被测项目包含的功能点。

5.2 业务流程分析

• 项目的流程：主线流程、分支流程、数据流转，流转过程中关键点的判断条件以及完成操作的一些非必要条件

• 对被测项目的业务流程要全部梳理出来（可画出项目的流程图，也可用头脑风暴）

• 分析了解被测试项目所属的行业及其业务知识

5.3 测试用例设计

• 在设计用例时要尽量考虑录入正常、边界、异常值等系统的处理情况

• 主要包括功能测试、界面测试、兼容性测试、易用性测试、异常测试、性能测试、压力测试等

5.4 测试用例评审

由测试用例设计者发起，参加的人员需包括测试负责人、项目经理、开发人员、产品及其他相关的测试人员

5.5 测试用例完善

• 在软件交付使用后客户反馈的软件缺陷（BUG），而缺陷（BUG）又是因测试用例存在漏洞造成，也需要对测试用例进行完善

• 在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善

• 测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新

6 测试分析与设计

6.1 分析与设计过程

• 建模 - 输出业务/系统流程（分析：业务流程 - 系统流程）

• 扩展 - 多类型测试（性能、安全、异常等等）：基于业务经验

• 细分 - 测试用例/数据（设计：测试用例）

• 设计 - 测试场景

6.2 测试场景分析实施

• 第一步：根据业务的目标（价值）、类别、技术等输入，确定业务场景分析的范围

• 第二步：业务流程梳理（业务场景）

事件流程

i. 基本流程

ii. 备选流程

1. 场景拆分

2. 场景正向逆向分析

a. 正常数据、异常数据

b. 破坏性数据

c. 并发性数据

• 第三步：场景串联

• 梳理场景、流程

￮在有限的条件下，尽可能梳理多的场景流程，涵盖

• 回归场景、流程

• 整合场景、流程

￮结合实际的需求场景、客户场景

6.3 非功能性设计扩展

• 异：用非正常输入值进行用例测试。验证结果的正确性

• 复：重复的参数对同一用例进行执行测试。验证幂等结果是否符合预期

• 并：针对测试用例进行大数据量同时执行，验证并发下的测试结果

• 多：针对测试用例进行大数据量覆盖测试

 收藏

立即使用

IoT物联网平台知识汇总

 收藏

立即使用

周报模板

 收藏

立即使用

【职造便利店】测试职业发展路径

 收藏

立即使用

2023年最新版软件测试知识图谱

喵小咪

职业：本科

去主页





0 条评论

下一页

为你推荐

查看更多

