测试用例是业务测试过程中测试者的生命线。
在大需求面前无从下手测试时，测试用例是测试者对全盘概念的梳理和深度探索；
在测试过程中碰到任何问题阻断测试场景或思路时，测试用例是测试者的执行指令和方向盘。
当需求文档及对应的需求技术方案产出时，测试者需要根据提供的文档对需求进行解构，解构出需求的原子内容后，再进行测试用例的设计，而测试用例即需要考虑测试验证的全面性又需要考虑测试的深度。那么，这就需要测试人员进行全方位考虑来构建测试思路和使用什么样的测试策略和方法来尽可能保证测试覆盖的全面性。

试问，当面对一个大型需求（此处是指需要花费至少 2 个迭代才能完成的需求），测试人员需要有什么样的测试用例设计思路才能达到高时效、高人效、全面的做到测试覆盖呢？

测试用例设计核心

重要程度

测试用例的设计首要考虑的是主流程场景（一定要搞清楚需求的背景及需求是为了解决什么问题而产生的），主流程包括：
1. 测试用例的设计围绕产品需求文档的描述进行设计
2. 测试用例的设计场景是否符合实际用户的使用场景
在主流程中，把握测试用例的优先级，能够尽早在测试过程中发现严重问题，尽早暴露问题

等价性

测试用例的设计需要根据开发的实现逻辑去设计，黑盒测试可能存在设计的多个测试用例间存在无效测试用例的情况，比如有些交互场景中，存在表单中有多个填入项，如果测试者设计时，将每个输入项都作为一个测试场景去设计，而不了解实现的话，那测试用例将呈指数增长，必定会存在很多无效测试用例。当然，此处的比喻比较极端，但测试者需要有这样的意识，去把开发侧实现的逻辑分支梳理清楚，防止产生垃圾测试用例的情况。

边界性

测试用例的设计涉及到功能模块间的交互，既然涉及到交互那必然存在边界。测试者需要明确该需求的上下游，该需求有几个入口和几个出口。

基于以上几点，作为设计测试用例的核心思想贯穿整个测试用例编写过程，再配合测试方法，你的脑海中将呈现一个需求完整的骨架，那么测试者对质量的把握度会大大提升。

测试点

主流程

主流程，即需求中说明的所有功能点场景，这里是测试的重点，也是冒烟测试去检查提测质量的重要手段。

分支流程

主干逻辑以外的分支逻辑场景。

异常流程

数据异常：如关键数据缺失、数据重复推送
调用链异常：如业务调用链路异常，系统的处理
常见异常有：

1. 依赖服务不可用，是否有降级处理，是否有监控告警？
2. 依赖数据缺失，是否 catch 异常，确保程序不 crash，并产生 error 日志？
3. 服务重启，是否容错？
4. 基础组件服务异常，如 redis、kakfa、mysql 等异常，是否丢数据，基础服务恢复以后，能否恢复服务？

UI 测试点

1. 风格、样式、布局
2. 校验：必填、选填等
3. 显示是否有遮盖和不合理的省略情况
4. 提示语是否友好
5. 等等（此处可对不同项目的 UI 关注点进行补充）

向前兼容

针对对已有的需求进行改造时，需要考虑接口或者 GUI 上的向前兼容。

关联功能

需要评估该需求是否会影响到已有功能，比如：代码中对公共模块的改动。

历史数据影响

需求改造是否需要对历史存在的数据进行处理？如：已有表结构更改等。

性能影响

这里指的性能影响比较简单，如：接口响应速度（大数据量的查询、高并发访问等）、GUI 的渲染速度（大数据量时的渲染）作为基本的性能达标指标；
对于系统最大的业务处理能力、处理速度等性能表现，需要另起一个大话题来说了。

终端兼容性

若产品支持：PC、小程序、APP 端等多个终端，需要在多终端验证功能可用性。

安全性

业务数据安全：如，重要数据非明文；
业务场景安全：如，绕过登录验证、交易中的数据篡改、接口的恶意调用等

以上设计测试用例的思路和方法是个人工作经验中的沉淀和总结，属于个人浅薄之见，但应该对测试新人有一定的参考作用，同时也希望业内精英能够发现不足和缺陷，提出改进意见。