测试用例设计要素有哪些

测试用例设计要素有以下几点：1、基于需求；2、场景化；3、描述精准；4、可判定；5、原子化；6、可回归；7、独立；8、正交。其中，基于需求要求测试用例是为了验证需求而设计的，则应避免过度设计，从需求出发，设计能有效验证需求的测试用例。

一、测试用例有哪些设计原则？

测试用例设计需要遵循以下原则：基于需求、场景化、描述精准、可判定、原子化、可回归、独立、正交。下面就这些原则来逐一解释。

1.基于需求

测试用例是为了验证需求而设计的，应避免过度设计。

• 从需求出发，设计能有效验证需求的测试用例
• 明确不在需求范围内的功能，不设计测试用例
• 在需求范围内的功能，不过度设计
• 一些没有明确提出、但属于共识或隐含的需求，应设计测试用例

例1：集成系统之间用于同步数据的更新接口，需求规定接口只允许单独调用，如果设计了并发量的测试，就属于过度设计。就算并发量测试出了问题，也不能作为软件缺陷，因为并发调用不在需求范围内。

例2：单次调用这个接口，等了半天没响应。这种情况，就算没有明确提出关于超时设置的需求，也可以设计用例并提交缺陷，因为接口的响应表现已经远超出了正常响应的时长范围。可作为隐含的需求进行用例设计，如果在需求分析和细化时可以包含这类情况，就更好了。

2.场景化

测试用例设计尽可能贴近真实用户或端到端的使用场景。

• 应全覆盖真实用户的使用场景
• 围绕场景进行更多的探索
• 以名列前茅人称的主观视角描述用例，帮助建立同理心
• 按照用户使用的自然顺序设计用例

例1：某车载导航经常出现地图失效、误导、卡顿等问题，直接影响到了车主日常使用。一过隧道地图就失灵了，车机不能连WiFi，信号差导航就没法用……在软件测试阶段这些问题都没暴露，而嵌入式软件的功能验证不能不考虑真实的使用场景，能在需求分析时就考虑到当然很好，如果前期缺失这些关键信息，在测试设计时进行使用场景的思考就显得尤为重要了。

例2：一些不包含终端用户使用场景的软件，比如后台功能、接口或算法等，还需要遵循场景化这一规则吗？当然也是需要的，场景化的原则并不局限于终端用户，也可以面向系统或服务的消费者，不管用户是人还是机器、系统还是接口，都可以面向受众场景来进行用例设计。

3.描述精准

描述测试用例的语言要尽量精准，避免歧义，保证不同的人对用例都有一致的理解。

• 语言准确，没有歧义，尽量具体不空泛
• 描述精练，保留必要信息，去掉无关信息
• 避免大段描述，对大量信息进行分层和结构化设计
• 描述角度关注给用户带来的价值，而非详细的操作步骤

例：一个不满足描述精准的用例设计

请结合以下问题来理解该原则：

• 该用例的测试价值是超过限定次数的边界验证，从设计来看也在验证5次以内
• 第1-5次有必要放在这里验证吗？是不是可以放在前提条件里？
• 在这验证1-5次，和另写一个用例来验证5次以内，两种设计哪个更好？为什么？
• 现在次数限制是5，如果是200次呢？
• 哪里违反了描述精准原则？

4.原子化

每个测试用例应有单独的测试点，确保一个用例只测一点。

• 每个测试用例，只针对一个验证点进行设计
• 如发现验证点多于一个，可拆分
• 用例的颗粒度要适宜

例1：界面比较复杂，元素很多，为了满足原子化，是不是每个点都得写一个测试用例？当然不必，可以思考测试点是什么，并不是UI元素里的每一个点，而是UI的实现满足UI设计，从这个角度看，整体算是一个测试点。在描述时也不用啰嗦很多，直接贴个图就很直观。

例2：如果要测试的是一个流程，有很多步骤，还满足原子化吗？思考方法同例1，需要验证的点并不是流程中的某个步骤，提供用户价值的是整个流程，以验证流程的角度来思考，这个测试点的设计仍然是满足原子化的。

5.可判定

应给出可判定的期望执行结果，在没有缺陷的情况下，多次执行应保持结果一致性。

• 判定准则应明确可判，避免模糊或笼统的描述
• 除非业务规则变化，否则判定准则应不变
• 同一条件下，多次执行结果判定应一致

这个原则比较简单，只要用例有单一的判定规则，可以按照预期结果和实际结果来判断用例是否通过，就满足了可判定原则。

6.可回归

测试用例的存在就是为了验证和回归，因此可回归是用例的必要条件。

• 同一条件下，不同人回归的结果应一致
• 在不同时间内，回归结果应一致
• 使用满足条件的任何数据，回归结果应一致

例：假设要测试的是抽奖算法，每次不一定抽中，或者要验证拍卖逻辑，不一定次次成交，这种情况下还算可回归吗？同样的方法，仍然思考测试点，这类情况要验证的测试点不是单次执行的结果，而是多次执行的概率，或是拍卖算法的逻辑，虽然每次执行的结果不一样，只要统计上满足算法和概率要求，就是可回归的设计。

7.独立

测试用例彼此之间应尽量保持独立，用例B的执行不应该依赖于用例A的执行结果。可以结合上面的抽奖用例和以下问题来思考独立原则。

1. 当多个用例彼此之间存在数据或流程上的依赖时，是放在一起验证较好，还是分开验证较好？
2. 如果测试人员按照特定顺序执行用例比较节省时间，如订单的创建、提交、审核、取消，这几个过程还是彼此独立的吗？
3. 在用例里怎样描述能凸显独立性？
4. 为什么用例之间较好彼此独立？

8.正交

测试用例的设计应尽量全面，无重复，确保测试设计有效且低成本。

• 多个用例之间应彼此正交
• 不重复验证同一个测试点

对于不重复验证同一个测试点，想更多澄清一下，我们在设计用例的时候应避免重复设计，但在测试执行时，适当的重复验证是合理的，能够预防一些遗漏的缺陷。

以上就是测试用例的设计原则了，这些原则能帮助我们更真实、有效且经济地设计出设计出更好的测试用例。

二、测试用例的设计原则适用场景

测试用例的设计原则可适用于以下场景：

1. 测试用例设计：任何进行测试设计的场景，如单元测试、用户测试、接口测试等
2. 测试用例评审：进行测试设计评审的场景，可参考设计原则给出改进建议
3. 回归范围确定：好的用例设计能够更方便地确定回归范围，当确定范围困难时，有可能是用例设计本身不合理，难以快速界定测试的范围和要验证的价值
4. 测试有效性评估：当需要评估测试是否有效时，可参考设计原则进行评估，好的测试设计可以更有效地验证功能和揭示缺陷

最后再澄清一下，测试用例设计原则同样适用于敏捷测试的情况。可能在敏捷场景下，测试人员不会写出详尽的测试用例文档，但由于敏捷的快速迭代和反馈，在测试设计上更要追求高效和经济，因此会比时间和资源相对充裕的场景更需要优化测试设计。

不论在何种场景，都需要更好的测试设计，这也是优异的软件从业者必备的核心技能。

三、测试用例管理工具

无论是需求管理、设计测试用例、编写测试执行报告、通知其他团队成员测试进展等，使用测试管理工具都是非常有必要的。为了管理测试过程遇到的所有issue，一些测试管理工具可以让你的测试管理工作变得非常方便和高效。下面推荐一些优异的免费/付费测试管理软件。

1、PingCode

PingCode 是国内的一站式软件研发项目管理工具，在2021年曾被36氪评为国内研发项目管理工具较好1。被广泛用于需求管理、敏捷/瀑布/看板项目管理、测试管理、缺陷管理、文档管理等工作领域。

PingCode 具有专门的测试管理模块，支持测试用例创建、用例库管理、用例评审、测试计划、自动生成测试报告，测试用例还能关联版本、需求、缺陷等。

最让我喜欢的是，PingCode 支持用例自定义，这对于对扩展有情结的人来说非常重要，因为业务是多变的，多给自己留点空间，同时用例导入这块支持脑图的导入、支持代码工具git、CI/CD工具jinkens等也是非常吸引我的。

PingCode 支持25人以下免费，支持私有部署，SAAS等购买方式，价格仅为Jira的30%-40%；（PingCode 官网）

2、Testpad

Testpad是一个轻量级的测试计划管理工具，是DIY电子表格的完美升级版，目的是给你足够的过程，无需在繁琐的测试用例管理工作中耗费过多时间。

特点：

1. 简单到任何人都可以使用-不需要培训
2. 测试报告一目了然：测试了什么，还有多少要做，”我们准备发布了吗？”
3. 基于分层检查表的测试计划
4. 创建灵活的测试，你可以在测试过程中随时改进。
5. 满足你想要的任何测试方式。TCM，BDD，或任何形式的探索性测试。

（官网：https://testpad.com/）

3、TestRail

TestRail提供全面的测试用例管理，帮助你组织测试工作，实时了解测试活动。强大的报告和指标使QA团队能够提高生产力并提供快速反馈。

特点：

1. 轻松地跟踪单个测试用例的状态。
2. 用信息丰富的仪表板和活动报告来衡量进度
3. 比较多个测试运行、配置和里程碑的结果
4. 追踪团队的工作量以调整任务和资源
5. 高度可定制，有基于云或内部安装的选项
6. 与缺陷跟踪和协作解决方案集成，如Atlassian Jira、FogBugz、Bugzilla、Axosoft、GitHub和TFS；以及与名列前茅的测试自动化工具，包括Ranorex Studio。

（官网：https://www.gurock.com/testrail/）

以上就是关于测试用例管理设计原则，管理工具的盘点，希望对大家有所帮助。

部分内容来源：圆小豆的美梦工场，作者于晓南