如何设计一个好的测试用例

1.什么是好的测试用例？

发现软件缺陷可能性大的测试用例就是好用例？那我们平时测试有多少bug是通过用例来发现的？

发现至今未被发现的软件缺陷的测试用例就是好用例？那如何评估是否还存在未被发现的缺陷呢？如果软件中根本就没有错误呢？

【理解】好的测试用例一定是一个完备的集合，能够覆盖所有等价类以及各种边界值，而跟能够发现缺陷无关

2."好的"测试用例必须的特征？

整体完备性：必须是完备的整体，能够完全覆盖测试需求

等价类划分的准确性：对于每个等价类都能保证只要其中一个输入测试通过，其他输入一定也测试通过

等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别

常用的三种测试用例设计方法：等价类划分、边界值分析、错误推测

【举例】学生成绩输入项，成绩取值范围[0,100]之间的整数，及格分数60

有效等价类1:0~59之间的任意整数；

有效等价类2:60~100之间的任意整数；

无效等价类1：小于0的负数；

无效等价类2：大于100的整数；

无效等价类3：0~100之间的浮点数；

无效等价类4：其他任意非数字字符；

边界值数据：-1,0,1,59,60,61,99,100,101

错误推测发：比类似"探索式测试方法"，难以系统化，过度依赖于个人能力和遇到的问题。常常设计缺陷库，通过check list来检查。

3.如何才能设计出好的用例？

上述三种方法合理的利用的情况下，还需要从以下几点进行考虑：

【软件功能需求】全面的，无遗漏的识别出测试需求，这直接关系到用例的测试覆盖率

【识别测试需求点】识别出每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面的设计用例

【其他经验】

• 1.深入理解被测试软件的架构，才能发现系统便捷以及系统集成上的潜在缺陷

不能全是黑盒，要对内部架构有清楚的认识，例如数据库链接方式、数据库的读写分离、消息中间kafka配置、缓存系统的层级分布、第三方系统的集成等

• 2.深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑

不要以开发代码的实现为依据设计测试用例。应该基于原始需求。所以在需求分析和设计阶段就要介入

• 3.引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，以此为一句来找出遗漏的测试点

4.其他想法

需求合理性，应该有人思考并提出质疑，是否真的符合客户的需求？以及一开始在需求评审过程就应该把控，推测出常见错误予以提醒避免开发阶段浪费时间。

需求不是找开发来确认的，而是需求提出人，或者能对需求负责的人。

需求理解，不是直接copy产品经理的需求，而是对需求的分解和补充，加上自己的经验和产品的理解，覆盖各种显性和隐性，功能和非功能的需求。

后期用例的归档整理，系统科学的整理，有利于后期的阶段性回归测试，减少在编写用例上浪费不必要的时间

原文地址：https://www.cnblogs.com/shunlilearningshare/p/11393724.html