亲测快捷高效的编写测试用例方法

前言

测试用例是任何测试周期的第一步，对任何项目都非常重要。如果在此步骤中出现任何问题，则在整个软件测试过程中都会扩大影响。如果测试人员在创建测试用例模板时使用正确的过程和准则，则可以避免这种情况。在本篇文章中将分享一些简单而有效的技巧，可用于编写有效的测试用例。这些技巧将在优化资源使用的同时节省您的时间和精力。

一、什么是测试用例？

测试用例就是由前提条件、输入、执行条件、预期结果等组成，以完成对某个特定需求或者目标测试的数据，体现测试方案、方法、技术和策略的文档。（简单来说就是给定条件、执行流程、预期结果的一个文档，供后续测试人员进行测试。）测试用例的设计需要尽可能覆盖软件的所有状态，尽量考虑周期。

二、设计用例是否有必要？

如果不记下来，很可能到执行的时候测试点就遗漏了，另外也不便于用例评审，用例总结，对后期测试工作没大的改进作用。所以测试用例一定要写，颗粒度视情况而定。针对测试人员少，上线时间紧的项目，可只做思维导图列出测试点。

三、设计用例的益处？

设计用例的过程可以更深刻的理解需求，熟悉各功能点，保证尽可能全的覆盖到各测试点。也便于用例评审。

四、一定要写测试用例吗？

对于大中型任务，还是要写详细的测试用例；对于紧急小型任务，可以写测试点；对于新人负责的模块，一定要写测试用例。

五、测试用例怎么写？

（1）根据需求文档，拆分测试点；（2）根据测试用例设计方法 + 经验 + 拆分后的测试点 + 通用用例约束。来设计最终的详细测试用例；（3）写用例的思路：产品需求-测试需求-测试点-测试用例；（4）还要考虑兼容性问题、浏览器兼容、操作系统兼容性，如果是app测试还要考虑中断测试、弱网测试等；设计用例时也要注意涉及到的数据库中的字段值是否正确；需要注意关联模块的用例设计；注意新增接口、新增字段的用例的设计；（5）除了用xmind整理测试点，也可以这样：根据需求文档找到角色和功能模块的匹配关系，输出usecase图---输出流程图---依据业务规则、usecase、流程图输出测试用例。

六、用例必备4个方面？

预置条件、执行步骤、预期结果、测试结果；用例要点：需包括与其他模块耦合关系、用例的级别（level0、level1），考虑哪些需求必须完成，哪些需求可以后续完成。

七、用例设计理念？

首先要保证产品的质量，测试用例的数量并不能决定质量的好坏，要做到覆盖全面，提倡高质量的自动化测试

八、没有需求文档，如何测试，如何设计测试用例？

A.查找其他相关文档，来帮助理解所要测试的产品需要完成的目标；B.尽量多参加项目组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理解；C.咨询相关人员-项目负责人、市场人员；D.召集相关人员，对你整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计你的case了；E.如果是一款已经上线的产品，可以多使用产品，有不懂的问产品经理；F.也可以去看历史bug，可以了解到一些需要关注的东西。

九、测试用例有哪些设计方法？

1. 编写测试方法都有哪些等价类划分法边界值分析法错误推测法因果图法场景设计法 2. 介绍一下每种测试方法（定义）并举例说明

等价类划分法定义：输入有效的等价类和无效的等价类的数据进行测试，有效等价类：是指合理的、有意义的数据。如：测试手机号码输入框正常格式输入无效等价类：与有效等价类的定义相反。指不合理的或无意义的数据。对于具体问题，无效等价类至少应有一个，也可以有多个。如：测试手机号码输入框输入错误格式（2.5.6开头等）边界值分析法边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类边界。如：测试手机号码输入框输入10.11.12位手机号其中11位是正确的10.12位为边界值错误推测法基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。如：测试返回按钮，根据经验设计用例，测试其功能是否可用，与物理返回键点击后结果是否一致，返回的界面是否是需求要求的上个网页等等一切可能出现的错误因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。如：测试自助售卖机场景设计法场景1. 成功提款 | 基本流| ---|---|--- 场景2. ATM内没现金 | 基本流 | 备选流2 场景3. ATM内现金不足 | 基本流 | 备选流3 场景4. PIN密码有误（还有输入机会） | 基本流 | 备选流4 场景5. PIN密码有误（不再有输出机会） | 基本流 | 备选流4 场景6. 账户不存在/账户类型有误 | 基本流 | 备选流5 场景7. 账户余额不足 | 基本流 | 备选流6

十、如何以更好的方式编写测试用例

让我们看一下编写更好的测试用例模板的技巧。

详细的领域知识

信息技术领域的知识意味着对特定项目的业务和运营动态，所涉及的风险和机会的深入了解。必须遵循域中的相关问题的最佳做法，而不一定是测试领域的最佳时间。

将较长的测试用例分解为许多较小的用例

如果步骤太多，最好将测试用例分成一组较小的用例。如果测试脚本中的某个地方发生错误，对于开发人员来说，回溯并重复测试步骤将更加容易。如果是某一长用例测试未通过或者发生错误，则开发人员很可能会花更长的时间发现和改正这个BUG，甚至错过该BUG

前提条件

在开始测试用例之前，建议确认适用于测试的所有假设以及在执行之前必须满足的前提条件。可能存在数据依赖关系，也可能依赖于测试环境或任何其他测试用例。特别是数据相关性的测试用例，一定要确保测试用例执行之前测试数据是没问题的。

测试数据输入

在编写新的测试用例时，测试人员可以在测试用例描述内共享适用于测试用例的测试数据，也可以在特定的测试用例步骤中添加测试数据。由于无需在其他地方查找测试数据，因此可以节省时间。如果要验证值，则测试人员可以指定值范围或描述要在特定字段中测试的值。从每个类中选择一些值，这些值可以很好地覆盖您的测试。最好不要提及实际的测试数据值，而要提及运行测试所需的数据类型。在多个团队使用测试数据且其不断变化的项目中，仅提及数据类型将是明智的选择。

组织工作

使用测试管理工具而不是电子表格来管理您的测试用例。有许多测试管理工具可用于在一个地方组织测试用例，这将提高团队的生产力。

停止假设

最好参考规范文档。关于功能或功能的假设可能导致客户端与开发人员之间的分歧。客户需求与正在开发的应用程序之间的差距将影响业务。

测试用例命名约定

为了编写易于理解的测试，我们必须停止在各自为阵的情形下进行编码，并注意命名约定。在为我们的应用程序编写自动化测试时，需要命名测试类，测试类的字段，测试方法和局部变量。哪个团队成员编写测试无关紧要，其他人甚至无需查看测试代码即可知道在什么情况下测试了哪些功能。

满足客户要求

如果测试人员错过了一个错误或编写了与真实场景无关的测试用例，那么这只是浪费资源和时间。目的是满足客户的期望，只有测试人员从用户角度出发才能实现。

涵盖所有验证点

编写定义良好的测试用例验证步骤非常重要，该步骤应涵盖被测功能的所有验证点。为了确保测试用例涵盖了所有验证点，请确保您的测试用例步骤与为项目指定的工件相匹配。

避免重复

在需要时进行自动化测试，因为这将减少手动工作并节省大量时间。测试脚本的编写方式应使其以后可用于其他项目。

使其可重用

创建测试用例模板，将来可以被其他团队重用。此外，在为模块编写新的测试用例之前，请确定是否已经为其他项目编写了类似的测试用例。这样做可以避免测试管理工具中的任何冗余。如果需要特定的测试用例执行其他测试用例，则在先决条件或特定的设计步骤中调用现有的测试用例。

组相似测试用例分组

测试运行是测试人员应按特定顺序执行的测试用例的集合。测试用例通常在测试运行中分组。最好将前提条件放在测试运行的开始，而不是将其插入每个测试用例中。实际上，只有少数测试用例需要前提条件，因此该字段通常为空。测试管理工具将帮助您自定义表单并创建测试用例模板，从而节省编写测试用例时的时间和精力。要记住的另一件事是，通过将重复的前提条件移至测试运行中来避免多次编写相同的指令。

容易理解

应该在需要的地方用注释明确定义测试用例，以便将来任何其他软件测试人员都可以使用它。无论您从事什么项目，在设计测试用例时，都应始终考虑到测试用例不会总是由设计它们的人执行。因此，测试应该易于理解且要点明确。如果编写所有这些测试用例的人由于某种原因离职并且您有一个全新的测试团队可以工作，那么在设计阶段花费的全部精力可能会花光。

测试用例描述

在描述中，测试人员需要提及有关将要测试的内容，需要验证的内容，测试环境和测试数据的所有详细信息。下面提到的信息应该在写得很好的测试用例描述中：*进行测试*测试工具*测试环境详细信息*行为得到验证*任何依赖项，例如前提条件和假设*要使用的测试数据

维护和更新

所有测试用例都应使用新要求进行更新，以便将来有需要时更容易执行它们。即使其他测试人员想要使用该测试用例，他/她也不必遍历脚本的详细信息

十一、高效的测试报告

一份清晰而全面的报告可以帮助我们得出与产品开发有关的有意义的结论。那么，我们如何才能有效地报告我们的测试？编写有效的测试用例和详细的测试报告是快速执行任务的另一种方法。这一句话中使用了详细和快速两个词，听起来可能是矛盾的，但是详细的报告需要一次性的努力。使用合适的工具和保持良好的使用习惯，你可以快速访问查看必要的日志内容、用户数据以及错误信息。每种工具的报告格式都不同；但是，无论采用哪种格式，某些指标都是必不可少的：