测试用例设计心得分享

有没有测试小伙伴和我一样，在面对包含多步骤、多分支、多依赖的复杂业务时，用例设计总是下不了手，

不知道怎么写、从哪里开始写，怎么写最清晰？因此我结合测过的几个复杂版本的用例设计过程，总结了一套自己的用例设计方法论，可以简单参考一下。

用例设计前置步骤

1、可以通过画业务流程图的方式来熟悉整体业务流向，从大的方向去拉通测试场景，不至于陷入细节而无法顾忌全貌，一定要自己动手梳理理解后的流程

2、拆分子流程（使用场景），了解业务的流转规则、约束条件、数据流向等

3、涉及现状的逻辑，除了让产品提供现状逻辑图或原型外，建议自己也要手动去系统实操一遍

在进行用例设计前要了解开发的设计逻辑，这直接决定了测试的深度、效率和有效性。可以让开发提供关键业务设计流程图、数据库设计逻辑、接口设计逻辑等，或者直接找他们面对面沟通。我平时负责版本测试时，如果涉及到一些逻辑比较复杂的需求，我都会要求开发给我输出关键业务设计流程图。

那了解开发设计对我们测试有什么帮助呢？

1、能够知道开发本次调整会影响到的逻辑和范围，针对调整逻辑去分析测试范围和测试重点，以免漏测或者无效测试等情况；比如，有些功能可能会采用缓存机制，那用例需要加上数据库与缓存的数据是否一致性等方面的设计

2、通过开发提供的设计，测试可以提前验证设计合理性，对比业务需求与实现逻辑，验证功能实现是否一致，避免将问题带到测试阶段，修复成本变高。

3、在测试过程中如果发现bug，也能够更快的定位到原因，用开发语言沟通缺陷；比如：哪个接口缺了字段、哪个缓存key没有更新等。

进行前面两个前置步骤之后，对业务的理解应该更深入了，这时再来设计用例，思路就会清晰很多，接下来讲讲怎么把前面理解的内容转换成用例；

1、路径覆盖

识别所有可能的业务流路径（主流程、备选流程、异常流程）

2、提取各个流程的测试要素

这个流程涉及到的触发入口、权限要求、约束条件（如等价类、边界值等）、特殊操作等

3、对测试要素进行归类

哪些是前置条件、哪些是配置、哪些是验证点

4、对各个测试要素排列组合与正交分析，得到测试场景（这是应对多因素影响系统的强大技巧），执行这些组合测试，能有效发现因不同因素间交互作用而产生的缺陷

5、编写测试用例，检查去除重复多余用例