谈谈测试用例的设计

谈一谈软件测试的基本功-测试用例的设计

软件测试中测试用例的设计是一个非常基础的工作，也是最重要的工作。

测试用例是通过执行一系列步骤来验证软件功能是否符合预期的规范文件，因此，测试用例质量的高低直接影响测试效果，也是评判测试工程师能力的关键指标之一。

测试用例设计流程

  1. 理解需求和业务场景 测试用例设计的第一步是理解需求和业务场景。只有深入理解需求和业务场景，才能设计出合理有效的测试用例。在设计测试用例之前，需要对需求进行全面的分析和理解，确定系统的功能、性能、安全等方面的需求。

  2. 设计测试用例 在设计测试用例时，需要根据需求和业务场景来确定测试用例的目的，以及测试用例的输入、输出和预期结果。测试用例应该从多个角度来设计，包括功能性测试、性能测试、安全测试等方面。对于每个测试用例，需要提供详细的测试步骤和预期结果。

  3. 编写测试用例 在编写测试用例时，需要注意测试用例的可重复性和可复用性。测试用例需要尽可能地覆盖所有的业务场景和异常情况，并且需要保证测试用例的输入数据和测试环境是一致的。测试用例需要注重细节，包括测试数据的准备、测试环境的搭建、测试步骤的描述、预期结果的定义等方面。

  4. 执行测试用例 在执行测试用例时，需要按照测试用例的步骤进行操作，并记录测试结果、测试时间和测试人员等信息。在测试的过程中，需要注意测试用例的执行顺序和执行状态，并及时记录和反馈测试结果。对于发现的问题和缺陷，需要及时进行记录和跟踪。

  5. 优化测试用例 在测试用例的设计和执行过程中，需要不断优化测试用例，提高测试用例的效率和质量。可以根据测试结果和测试覆盖率等指标，评估测试用例的效果和质量，并进行优化和改进。 测试用例设计是软件测试中的重要环节，需要注重细节、提高效率和质量，这样才能保证测试的效果和测试的质量。

功能测试用例设计（购物车）

  1. 确定测试目的和覆盖范围 测试目的是验证购物车的功能是否符合需求，覆盖范围包括购物车的基本功能，如添加商品、删除商品、修改商品数量等。

  2. 设计测试用例 测试用例需要从多个维度来设计，包括功能测试、性能测试、安全测试等方面。以下是一些示例测试用例：

功能测试用例

测试目的：验证购物车的基本功能是否正常工作。 测试步骤：

购物车基本操作功能（增删改查）

添加商品

1.是否能够添加商品

2.添加单个商品数量是否有上下限

3.添加商品种类是否有上下限

4.添加同类型商品的不同规格商品显示是否分条显示

5.加入购物车商品排序是否合理

删除商品

1.能否删除单类商品

2.是否有快速删除多种商品方式（全选，删除）

3.删除商品是否有确认提示

跳转商品详情

1.跳转商品图片显示是否正常

2.跳转商品链接显示内容是否完整，是否过长

3.点击图片或者链接是否能够跳转商品详情

编辑商品、商品跳转

1.是否有通过+ -编辑商品数量方式

2.是否有通过输入直接编辑商品数量方式

3.编辑商品数量是否有上下限

4.编辑商品数量是否考虑库存情况

5.商品链接能否自动跳转

检查商品数量，金额，优惠明细

1.商品加入购物车内是否和原价格一致

2.商品数量显示是否正确

3.选择商品总数是否正确

4.选中商品价格总额是否正确

进入商品购物或结算

1.购物车是否有进入购物链接

2.购物车是否有进入结算链接

购物车交互功能

购物车与用户模块关联

1.未登录用户是否可以添加商品到购物车

2.未登录用户添加商品到购物车，登录后是否将商品合并到用户购物车

3.若不允许未登录用户添加商品到购物车，点击加购物车后是否有登录提示

4.用户有会员折扣时，购物车内商品价格是否对应

购物车与商品订单模块关联

1.加入购物车商品有价格调整，购物车内商品价格是否跟随变化

2.加入购物车商品，库存变化时购物车是否有对应调整

3.购物车商品确认订单后是否会从购物车清除

4.订单价格是否与购物车内一致

购物车与优惠活动模块关联

1.商家发放用户优惠券购物车对应变化

2.商品满减活动，购物车价格对应变化

购物车和支付功能的交互

1.进行结算支付，选择微信付款，此时需要考虑金额＞零钱，金额＜零钱，金额=零钱三种情况

2.进行结算支付，选择已添加的银行卡付款，此时同样需要考虑金额＞银行卡余额，金额＜银行卡余额，金额=银行卡余额三种情况

3.进行结算支付，选择使用新卡付款，按照流程添加新卡，此时同样需要考虑金额＞新卡余额，金额＜新卡余额，金额=新卡余额三种情况

3.进行结算支付，选择好友代付，测试好友能否收到代付请求，好友能否代付，代付能否成功

4.使用指纹确认付款（正确的/不正确的指纹）

5.使用密码确认付款（正确的/不正确的密码 ）

6.支付成功，对应的途径会减少相应的金额，也会生成相应的订单

一些补充

1.删除商品是否有提示；

2.是否支持快捷键功能；

3.是否有回到顶部的功能；

4.商品过多时结算按钮是否可以浮动显示；

4.购物车有多个商品时，能不能只对单个商品结算；

性能测试

  1. 进入购物车页面消耗时长

  2. 添加商品到购物车时长

  3. 进入购物车结算时长

  4. 对购物车页面内容变更，页面内容更新速度。（增加某个购买数量，页面对应显示更新速度）

  5. 耗电量

  6. 消耗流量的多少

  7. 所占内存等

界面/UI测试

  1. 界面的设计风格是否统一

  2. 界面中文字是否简洁，没有错别字

安全性测试

  1. 支付过程中是否有个人信息/密码丢失的风险

  2. 是否有金额被盗刷的风险

兼容性测试

  1. 苹果手机和安卓手机

  2. 苹果手机的不同版本

  3. 安卓手机不同的机型

  4. 网页版测试，五大浏览器

  5. 不同分辨率

易用性测试

是否易操作，易学习，易理解

网络测试

  1. 网络兼容性：2g/3g/4g，WiFi，热点，移动/联通/电信

  2. 无网测试

  3. 弱网：延时&丢包

中断测试

前后台切换，网络异常，低电量，断电，来电，短信等

接口测试用例的设计（购物车）

根据技术文档确定新功能的核心接口，设计对应的接口用例，接口用例要设计的尽可能的完整，颗粒度要更加精细

  • 入参校验：必填字段校验、入参长度、特殊字符、边界值设计异常用例

  • 出参校验：业务逻辑处理、数据库表字段数据、非正常流程的处理、用户重要信息是否脱敏处理、返回错误信息是否涉及sql信息、是否包含项目敏感信息

  • 幂等性校验：涉及状态流转、重复请求写入、删除数据库数据

以购物车为例，设计接口测试用例需要考虑以下几个方面：

接口测试目标

首先需要明确接口测试的主要目标，比如测试购物车添加商品、删除商品、修改商品数量、结算等接口是否能够正常工作。

测试数据准备

接口测试需要准备一些有效的测试数据，这些数据需要包括必要的参数、数据类型以及数据范围等信息。

接口执行顺序

接口之间有一定的调用顺序，需要注意接口之间的依赖关系，例如不能在添加商品前调用删除商品接口等。

接口输入输出参数

需要仔细查看每个接口的输入和输出参数，了解其含义和数据类型，确保所有参数都正确传递和返回。

基于以上方面，下面是购物车接口测试用例的设计示例：

购物车添加商品接口测试用例

  • 验证添加指定商品到购物车成功。

    • 测试数据：商品ID、用户ID、商品数量

  • 验证添加同一个商品到购物车多次失败。

    • 测试数据：商品ID、用户ID、商品数量

  • 验证添加不存在的商品到购物车失败。

    • 测试数据：错误商品ID、用户ID、商品数量

  • 验证添加商品数量超过库存数到购物车失败。

    • 测试数据：商品ID、用户ID、商品数量

购物车删除商品接口测试用例

  • 验证删除购物项成功。

    • 测试数据：购物项ID、用户ID

  • 验证删除不存在的购物项失败。

    • 测试数据：错误购物项ID、用户ID

购物车修改商品数量接口测试用例

  • 验证修改购物项数量成功。

    • 测试数据：购物项ID、用户ID、修改后的数量

  • 验证修改购物项数量为负数或非数字失败。

    • 测试数据：购物项ID、用户ID、非法数量

购物车结算接口测试用例

  • 验证结算购物车成功。

    • 测试数据：用户ID、结算商品ID、商品数量、收货地址等信息

  • 验证结算购物车时购物车为空失败。

    • 测试数据：用户ID、空购物车

  • 验证结算购物车时包含已下架商品失败。

    • 测试数据：用户ID、已下架商品ID、商品数量

  • 验证结算购物车时库存不足失败。

    • 测试数据：用户ID、商品ID、库存不足数量

通过以上购物车接口测试用例的设计和执行，可以有效确保购物车接口的质量，提高购物车功能的稳定性和可靠性。

针对已有功能模块迭代

在已有功能上进行优化的需求，我们在设计用例时首先根据技术文档确定接口是否是新增，若是新增则可以对核心接口设计接口用例，非核心接口则可以设计功能用例；若不是新增，是在原有接口做的改动，我们则要进一步明确接口的影响范围，在用例中作为回归用例体现出来。

  1. 需求分析和评审 在迭代开始前，需要对迭代的需求进行分析和评审，明确需求变更的目的和影响范围，以便确定测试用例的修改和添加方向。

  2. 历史缺陷重测 在已有功能迭代时，需要重新测试之前已经存在的缺陷，以确保之前的问题已经被修复，不会再次出现。这个过程称为历史缺陷重测。

  3. 冒烟测试 在迭代完成后，需要进行冒烟测试，确保已有功能模块的主要功能没有受到影响。

  4. 回归测试 在已有功能迭代时，需要进行回归测试，确保迭代对已有功能模块的影响没有引入新的问题。回归测试应该包括之前的测试用例以及新的测试用例。

  5. 边界测试和异常测试 在迭代过程中，需要重新评估边界和异常条件，并针对新的需求进行测试用例的设计和添加。

  6. 性能测试 在某些情况下，迭代可能会对系统的性能产生影响。因此，需要进行性能测试，以确保系统在预期负载下仍然可以正常工作。 在测试用例设计过程中，需要考虑到迭代对已有功能模块的影响，并根据实际情况进行相应的测试用例设计和修改。同时，要保证测试用例的全面性和可靠性，提高测试效率和测试质量。

冒烟测试用例设计步骤

冒烟测试是软件测试中的一项重要测试，它主要用于验证一个软件的主要功能是否能够正常运行。

冒烟测试（Smoke testing）是一种快速而基础的测试，用于检查一个软件系统的主要功能是否正常工作。通常在软件开发的早期阶段进行，以便及早发现和解决主要问题，确保系统可以进一步进行详细测试。以下是设计冒烟测试用例的一些建议：

  • 确定关键功能：首先，确定软件系统的关键功能，这些功能对系统的整体性能和稳定性至关重要。这些功能的测试应该是您冒烟测试的重点。

  • 识别主要路径：识别关键功能的主要路径或步骤。这些路径是使用软件系统时的主要流程。您的测试用例应该覆盖这些路径的核心步骤。

  • 设计基本的测试用例：设计基本的测试用例来验证关键功能是否正常工作。这些测试用例应该是简单的，易于执行和验证结果。

  • 考虑异常情况：考虑关键功能的异常情况。例如，输入无效数据，使用不正确的参数等。您的测试用例应该涵盖这些情况，并验证系统是否能够正确处理它们。

  • 考虑典型用户：考虑典型用户的使用情况和使用习惯。根据这些情况设计测试用例，以确保系统在真实情况下的表现良好。

  • 自动化测试用例：考虑自动化测试用例，以便在将来快速、可靠地执行冒烟测试。自动化测试用例应该是简单的、易于维护的，并涵盖关键功能的主要路径。

总之，设计冒烟测试用例需要根据关键功能、典型用户和异常情况来确定主要路径，设计基本测试用例，并自动化测试用例以便在将来更快地执行测试。

需要注意的是，冒烟测试用例需要定期维护，确认原先的用例在新的项目或版本中有效，一些不需要的用例可以精简删除。冒烟测试用例编写结束后，需要经过产品经理、项目经理和开发人员评审后，才能在之后的项目中使用。

posted @ 2023-03-30 15:18  测试玩家勇哥  阅读(75)  评论(0)  编辑  收藏  举报