测试基本功：浅谈测试用例设计

测试用例设计对我们测试人员来说是个老生常谈的话题了，但这也是我们需要一直修炼的基本功，也是团队各角色第二次拉齐需求认知的一个重要手段，我们试想，如果没有测试用例，会是一个什么样的场景？需求评审完成后，大点的需求我们的工作就是设计测试方案，小点的需求可能就跳过了测试方案这一步，只是等待着提测，进行测试，那正式介入测试后又会是一个什么场景呢？看着需求文档进行测试，想到哪儿就测到哪儿，没有章程的进行测试，这样会导致什么结果呢？大概率情况下应该是只保证了正常流程，漏掉异常场景，漏掉回归场景。

所以正确的测试流程应该是需求评审–>测试用例设计–>测试方案设计–>根据方案规划测试数据的准备–>提测后按照用例及方案进行测试，有漏掉的场景及时进行补充。

本次我来总结一下我在日常工作中测试用例设计是如何进行的，以及线下门店业务的用例的具体表现形式。

用例设计手段

测试用例设计理论上来说我们可以从以下几点入手：

01 仔细研读需求文档

需求文档是我们设计用例的基础，把控好需求的质量也变相的把控了我们测试用例的质量。因此我们要做到以下几点：

• 分析需求的合理性
• 明确需求的范围及细节
• 挖掘隐含需求

02 结合技术文档，确定改动接口

功能上的每个数据，都需要明确数据来源，是前端还是后端控制的，技术文档是我们了解功能逻辑实现的一个文档，通过技术文档了解接口，确定功能点的数据来源是否是后端处理的，从内部了解逻辑处理，确定核心接口，进行接口用例设计，保证核心接口的正确性、异常处理、幂等处理。

03 运用测试理论

设计测试用例时，很容易跟着产品需求文档的思路设计，导致我们的测试理论没有利用上，用例的覆盖度较低，用例就会显得比较单薄。在设计用例时，要时刻谨记我们的测试理论，将理论应用于实践中，以下是常用的测试用例方法。

熟知的设计用例方法有：

• 等价类、边界值
• 因果图、流程图
• 场景法等

04 结合软件质量模型

在上面基础上，我们还需要站在软件质量的角度，借助软件质量模型来辅助设计用例，使用例更加全面。一般可以从以下几个方面考虑：

功能：是否实现了产品期望的功能，功能是否完整，是否好用；
性能：是否会对系统造成大量的资源消耗，是否会影响系统响应时间；多线程同时请求，系统的表现是否正常；
安全性：是否会泄漏用户的信息；
兼容性：是否可以兼容不同的网络环境及设备，如小程序在安卓和ios系统中显示是否正确，点击按钮是否有效，返回按钮是否正常；
易用性：用户是否容易理解和使用；提示是否友好；是否给出异常提示。

线下门店业务用例的具体表现形式

01 线下门店业务

顾名思义，线下门店拥有实体门店，具体业务主要包含回收和零售，也就是说，用户可以在门店由店员对用户服务，进行回收和零售的交易，形成一个良好的闭环。线下门店是个较新的业务线，目前为止成立了两年多的时间，业务正处于快速扩张与稳步基建的过程，快速扩张体现在我们正在扩门店，门店数量逐步增长，稳步基建体现在我们在扩张的同时，注重基础功能的稳定性，不断完善基础功能，解决以往只能由人一个个确定门店业务的痛点，释放出人力，并且接入谛听系统，接受店员的改进反馈建议，助力门店稳步前进。

02 线下门店如何设计测试用例

根据线下门店业务快速扩张的特点，门店的需求特点主要体现在需求多为新功能模块，为门店业务添砖加瓦；业务的快速扩张，需要数据支持决策，门店店员也需要更直观的看到自己的工作业绩数据，门店的需求中也会包括一些统计类的需求；线下门店业务规模的不断拓展，开城及开店、人员招聘速度加快，会存在一些系统重构类的需求，由于门店接收店员的反馈建议，所以我们还有一些已有功能的迭代需求。下面根据门店业务的需求特点简单介绍一下我是如何设计用例的。

新功能模块

对于新功能模块，可以采用接口用例+功能用例设计，主要可以从以下几点实施：

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

入参校验：必填字段校验、入参长度、特殊字符、边界值设计异常用例
出参校验：业务逻辑处理、数据库表字段数据、非正常流程的处理、用户重要信息是否脱敏处理、返回错误信息是否涉及sql信息、是否包含项目敏感信息
幂等性校验：涉及状态流转、重复请求写入、删除数据库数据
（2）功能用例多以页面功能以及流程性用例设计

页面功能：设计用例时采用前后端分离的思想，对接口用例中已经涉及的功能点，前端是否根据返回做出对应的展示；前端是否根据用户当前操作给出对应的处理
流程性用例：若需求涉及流程，可以将执行流程写在用例中，保证用例在开发自测时的可读性、可执行性

已有功能模块迭代

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

技术重构

门店的快速发展，对已有系统存在较大的考验，管理角色也区分的越来越清晰，所以启动了权限系统升级，功能需求和线上保持一致，但是不同权限拥有的菜单、操作及数据权限不一致，因此需要回归已有所有功能，是个典型的回归类需求。如何设计测试用例？

分角色
分模块
由于各个角色下的功能点差异较大，每个模块都会有定制性的操作功能，在设计用例时，列出每个模块中不同角色下的差异点，测试时根据角色测试，可以准确的校验到该角色是否拥有此菜单、操作或者数据权限。有些角色在菜单、操作及数据权限上和其他角色是一致的，为了使用例发挥出有效和高效性，简化用例的复制粘贴，以"同***"代替。

统计类需求

这类需求基本上以查询为主，页面内容呈现比较多，设计用例时我们可以重点关注以下几点：

• 数据的范围：如统计范围最大到什么时间，用例多考虑边界值；门店涉及多种角色，不同角色下的数据范围要明确
• 数据的正确性：如功能点为统计门店待入库、已入库商品的数量并展示明细，用例中不仅要独立写出存在该统计功能，还要明确数量的明细是如何统计的，并标注数量与对应明细的正确性

• 异常统计场景：如店员离职或者店员升职、或者店员换店，以门店维度统计数据的时候是否还需要统计该人员。

总结

以上是我在门店业务中测试用例设计的一些见解，最后对于门店的日常常见的需求特点及常见的功能点如何设计用例做了以下总结梳理，希望我们都可以在用例设计上设计出更完美、有效的用例~

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！