如何编写好的测试用例？

Test Case（测试用例）是为特定目标准备的一组测试输入，执行条件和预期结果，以便测试程序路径或验证其是否满足特定需求，是软件测试人员的基本需求能力.

良好用例的标准

/是否可以找到错误

设计测试用例的目的是发现错误. 如果找不到错误，如何将其称为良好的测试用例？

/它足够有效吗？

一个好的测试用例应该测试多个测试点，从而减少所需的用例总数. 但是您不能包含太多不想关闭的测试点，否则就无法测试该用例测试用例怎么 写，这将给调试开发带来困难.

/是否足够经济

此测试用例是否易于执行，以及分析和调试成本是否过高值得考虑. 毕竟，我们还必须从组织的角度来看待测试问题. 公司为了赚钱而做这些事情. ，不用于测试.

/是否有足够的可伸缩性

重点是检查测试用例是否维护昂贵.

测试用例的好处

/阐明想法并避免遗漏

这是我们认为最重要的一点. 如果要测试的项目很大且很复杂，我们可以通过根据每个功能编写用例来细分项目功能并组织我们的测试系统思想，以避免遗漏需求. 测试功能点.

/跟踪测试进度

通过编写测试用例和执行测试用例，我们可以清楚地知道我们的测试进度.

/历史参考

在我们所做的项目中，可能有许多相同或相似的功能. 我们已经为此类功能设计了测试用例，以便将来在遇到类似功能时可以将它们用作参考.

/重复性

即使测试已完成，我们也不是一个人来测试系统，而且需要多个人重复测试，所以我们需要测试用例来规范和指导我们的测试行为.

测试用例方法

/等价类划分

在输入域的一个子集中，在此子集中，每个输入数据等同于揭示程序中的错误.

如果有一个输入框需要输入1-10000个数字，则我们无法使用每个数字进行尝试. 我们输入5和6来验证并暴露输入框的错误可以视为等效.

这时我们可以随机提取一些数据进行验证. 例如: 10、99、7777 ...

等效类别: 有效等效类别和无效等效类别

输入框的数字必须为1-10000

有效等效类: 您可以输入1到10000之间的数字进行验证，例如: 2、5、99、8495 ...

无效的等效类: 您可以输入1-10000以外的任何字符进行验证，例如: 20000，字母，下划线，特殊符号，空格，回车符.....

/边界值

边界值是对等价类的补充. 测试工作经验告诉我们，大量错误是由于输入和输出边界价格引起的.

我们也以上述示例为例. 一个输入框要求输入一个介于1到10000之间的数字.

我们要测试它是否超出此范围测试用例怎么 写，例如: 0，-1，-2、1000、10001 ....等，以确定它是否超出我们的范围.

/因果关系图

因果图方法的最终结果是决策表，它适合于检查程序输入条件的各种组合. 例如: 原因: A = 0，B = 0，因此，我可以判断: A = B.

确切地说，他是因果关系. 它会无形地指导我们的测试.

当然，为了避免遗漏，我们可以在系统中绘制因果关系. 但是，如果系统庞大而复杂，则该个人还活着.

/错误的猜测方法

根据经验和直觉推测系统可能出现的错误，从而有针对性地设计测试用例方法.

/其他

有许多设计测试用例的方法. 我们通常使用上述方法. 其他方法包括: 状态转换图，过程分析方法，正交验证方法等.

测试用例的格式和元素

测试用例应包括: 编号，标题，测试方案，测试步骤和预期结果.

当然，您还可以添加其他一些选项，例如: 优先级，测试阶段...

示例:

以上格式摘自“ Microsoft软件测试之路”，仅供参考. 通用项目管理系统的用例管理具有固定的格式，搜索，修改等功能，使用非常方便.

例如: Zen Tao项目管理，QC，Bugfree等中有用案例的管理.

开始设计测试用例的最佳时间

根据客户需求整理出项目需求分析文档后，我们可以根据需求文档编写测试用例. 但是，通常我们的（大多数国内小公司）项目需求文档非常“简单”，因此很难根据需求文档设计测试用例.

我们只需要等到项目开发人员开发项目并为我们提供系统文档，部署环境和结构（如果系统涉及）即可. 我们消除这些文档来设计测试用例.

在什么情况下不适合编写测试用例

/低成本性能

如果一个功能被快速测试，而我只需要测试一次，但是我们在设计测试用例时会遇到麻烦，并且需要很长时间.

目前，无需编写测试用例.

/需求变化很大且很频繁

需求的功能更改非常频繁，并且更改非常大. 之前编写的测试用例根本无法使用，必须重写. 目前，建议您不要自己做.

建议选择第三方测试机构来提供帮助，例如Testin之类的众包测试服务.

结合探索性测试思维

完全执行测试用例是一件很无聊的事情. 个人在执行测试用例时会做一些事情. 其他非常规操作取决于系统是否将具有相应的处理和提示.

在此非常规操作下发现了我的一些错误.

当然，真正的探索性测试需要对产品有深入的了解，并具有一定的软件开发技术的深度和广度.

来自: 简介

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-191444-1.html