关于怎么写好测试用例_测试用例怎么写好-CSDN博客

文章目录

1. 如何更好的理解需求
2. 测试设计技术
- 2.1 常见测试设计技术
- 2.2 测试点分析
3. 编写测试用例

关于怎么写好测试用例，本文重点整理测试用例的方法和一些常见的测试用例、测试点。

首先要理解需求，其次才是你的测试设计技术。

1. 如何更好的理解需求

首先，了解需求，查看你能拿到的所有关于需求的资料，包括并不限于：需求文档，规格说明书，原型设计，UI 或 UX 等。每个功能模块的业务流程、细节都会体现在软件需求说明书里。

了解需求的主要目的是提取我们的测试点，根据测试点来编写测试用例。

其次，及时沟通。要与产品设计者和开发人员及时沟通，需求文档中模糊的地方应该和产品确认。部分限制条件需要和开发人员确认，如果开发过程中有需求变更，也应该及时同步到测试侧。

最后就是及时提出问题，使用流程图来帮助理解复杂的需求。

2. 测试设计技术

2.1 常见测试设计技术

等价类划分
黑盒测试方法，把输入域（输入的测试值）划分为不同的子集合。分为：有效等价类和无效等价类。【按数据范围和数据类型，划分有效和无效】
例如，如果一个输入框要求输入1到100的数字，你可以分为三个等价类：小于1、1到100、大于100。

测试用例设计	测试输入
输入正确 1～100 的数字	50
输入小于 1 的数字	0,-1
输入大于 100 的数字	101
输入包含小数点的数字	1.1,0.9,
输入包含特殊字符的数字	abc&…%

边界值分析
在等价类划分的基础上，专注于测试边界值，即等价类的边界值和邻近边界值。通常情况下，边界值是最有可能引发错误的地方。
边界值分析法是对等价类划分法的一个补充，边界值一般都是从等价类的边缘值去寻找。
一般包含：正好等于、刚刚大于、刚刚小于边界的值作为测试数据

所以上面的测试用例中可以补充 1,100,0.99

场景法
通过场景描述的业务流程（或业务逻辑），设计用例来遍历场景，验证系统功能的正确性。
一般来说，先画流程图，然后列出所有情况。

补充说明：场景法的重点是测试流程，因此每一个流程用一个用例验证即可，流程测试没有问题并不能说明系统功能没有问题了，还需要对单步的功能进行测试，只有单个功能点和流程测试，才算是充分的测试。（单步的功能：使用边界值法等对单个的输入进行测试。）

登录功能基础逻辑

错误推测法
通过假设系统中可能存在的错误或缺陷，从而设计出相关的测试用例来验证这些假设。这种方法通常用于发现系统中的潜在问题，尤其是在测试团队对系统的内部结构和实现细节缺乏详尽了解的情况下。
基于经验和直觉推测程序汇总所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

举例：上面 1～100 的输入框中，输入包含特殊字符的数字，或输入文字等等。

2.2 测试点分析

举例：登录注册测试点分析

1.通过分析需求描述中的输入【登录时输入的帐号密码】、输出【页面返回的提示】、处理、限制【密码需8位数以上】、约束等，给出对应的验证内容；（功能测试）

2.通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在功能交互的功能项，给出对应的验证内容；（功能交互测试）

3.考虑到需求的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，注册帐号的唯一性验证（界面、易用性、兼容性、安全性、性能压力）

测试点分析思路步骤：

正常功能：是否可以正常提交（冒烟测试）
单个功能项验证（正常+异常）：重点输入项。
按顺序从上至下，对每一个输入项进行验证。
1）数据长度、数据类型验证、必填项验证、重复
2）业务约束验证
功能交互验证：模块之间传递的信息和数据，对存在功能交互的功能项
隐形需求：充分熟悉产品业务，挖掘隐性需求
需求跟踪矩阵（不常用）
需求的变更：早发现、早讨论、早决定、早调整

3. 编写测试用例

3.1 测试用例包含什么内容

用例编号：功能模块划分_序号
测试标题：简洁明了地描述测试的目标或场景，输入内容+结果，同一功能模块标题不能重复（来自测试点）
前置条件：述执行测试用例所需的前提条件，例如预置条件、环境要求等
测试优先级：P0/P1/P2
测试步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作
预期结果：描述测试执行后预期得到的结果或系统行为。
实际结果：执行测试后实际得到的结果或系统行为。通常在执行测试后填写。
测试结果：对比实际结果和预期结果，确定测试是否通过，并记录任何失败或异常情况。
测试状态：标识测试执行的状态，例如通过、失败、阻塞等
测试者：执行测试用例的人员的姓名或标识符
备注

3.2 测试用例的优先级别划分

测试用例一般分为：P0、P1、P2 三种，也可继续划分。

P0：高优先级，包括对系统核心功能、高风险功能和紧急修复问题的验证。这些测试用例对于保证系统的基本功能和稳定性至关重要，如果这些测试用例未通过，可能会严重影响系统的可用性和用户体验。
另外：阻塞优先级也普遍归为 P0，这是一个特殊的优先级，通常用于标识系统中的严重问题或缺陷，它们可能会阻止系统的正常使用或导致系统崩溃。这类问题通常需要立即解决，并且可能需要紧急修复。

P1：中优先级，包括对普通功能和一般风险的验证。这些测试用例涉及到系统的一般功能和常规业务流程，对于保证系统的完整性和正确性有一定的贡献。

P2：低优先级，包括对边缘功能、低风险问题和次要改进的验证。这些测试用例通常涉及系统的次要功能或辅助功能，对于系统的基本功能和稳定性影响较小。

划分方法：

业务价值：测试用例对业务目标的贡献程度是确定优先级的重要因素之一。如果测试用例涉及到系统的核心功能或关键业务流程，那么它的优先级可能会较高。
风险程度：测试用例涉及到的潜在风险和影响范围是确定优先级的另一个重要因素。如果测试用例验证了系统中的一个可能导致严重后果的缺陷，那么它的优先级可能会较高。
紧急程度：测试用例对项目进度或上线计划的影响程度也是确定优先级的考量因素之一。如果测试用例涉及到修复一个已知的严重问题，那么它的优先级可能会较高。
复杂度和成本：测试用例的设计和执行成本以及涉及的复杂度也是确定优先级的考量因素之一。如果一个测试用例的设计和执行需要较多的资源和时间，那么它的优先级可能会较高。
利益相关者需求：根据项目的利益相关者对系统的关注点和重点，确定测试用例的优先级。不同的利益相关者可能对系统的不同方面有不同的关注程度。

GPT 的举例说明：

高优先级（High Priority）：
- 测试用例1：用户添加商品到购物车，确保购物车中商品数量正确且能够成功添加。
- 测试用例2：用户提交订单后，确保订单能够成功创建并跳转到支付页面。
- 测试用例3：用户在结算页面输入无效的支付信息，确保系统能够给出合适的错误提示并阻止用户继续操作。
中优先级（Medium Priority）：
- 测试用例4：用户在商品详情页面查看商品评价，确保评价信息显示正确。
- 测试用例5：用户在搜索框中输入关键词搜索商品，确保搜索结果准确显示。
- 测试用例6：用户在登录后查看个人订单列表，确保订单信息完整显示。
低优先级（Low Priority）：
- 测试用例7：用户在个人信息页面修改用户头像，确保头像修改成功并显示正确。
- 测试用例8：用户在购物车页面调整商品数量，确保商品数量变化后价格更新正确。
- 测试用例9：用户在用户注册页面输入格式不正确的电子邮箱地址，确保系统给出合适的错误提示。
阻塞优先级（Blocker Priority）：
- 测试用例10：用户在结算页面提交订单时，系统崩溃或出现严重错误，阻止订单创建和支付。
- 测试用例11：用户登录页面无法正常加载或显示，导致无法登录系统。
- 测试用例12：用户在购物过程中，网站频繁出现404错误页面或其他异常，阻止用户正常购物流程的进行。