码迷,mamicode.com
首页 > 其他好文 > 详细

02 | 如何设计一个“好的”测试用例?

时间:2020-06-30 00:49:49      阅读:66      评论:0      收藏:0      [点我收藏+]

标签:经验   check   wiki   分析   特征   完全   边界条件   png   image   

什么才算是“好的”测试用例?

“好的”测试用例一定是一个完备的集合,它能够覆盖所有等价类以及各种边界值,而跟能否发现缺陷无关。
如果把被测试软件看作一个池塘,软件缺陷是池塘中的鱼,建立测试用例集的过程就像是在编织一张捕渔网。“好的”测试用例集就是一张能够覆盖整个池塘的大渔网,只要池塘里有鱼,这个大渔网就一定能把鱼给捞上来。如果渔网本身是完整的且合格的,那么捞不到鱼,就证明池塘中没有鱼,而渔网的好坏与池塘中是否有鱼无关。

“好的”测试用例必须具备哪些特征?

  • 整体完备性: “好的”测试用例一定是一个完备的整体,是有效测试用例组成的集合,能够完全覆盖测试需求。
  • 等价类划分的准确性: 指的是对于每个等价类都能保证只要其中一个输入测试通过,其他输入也一定测试通过。
  • 等价类集合的完备性: 需要保证所有可能的边界值和边界条件都已经正确识别。

三种最常用的测试用例设计方法

第一,等价类划分方法
价类划分方法的另一个关键点是要找出所有“无效等价类”。

第二,边界值分析方法

第三,错误推测方法
错误推测方法难以系统化,并且过度依赖个人能力。
在软件企业的具体实践中,为了降低对个人能力的依赖,通常会建立常见缺陷知识库,在测试设计的过程中,会使用缺陷知识库作为检查点列表(checklist),去帮助优化补充测试用例的设计。
对于中小企业,可能最初的方法就是建立一个简单的 wiki 页面,让测试工程师完成测试用例的最初设计后对应这个 wiki 页面先做一轮自检,如果在后续测试中发现了新的点,就会继续完善这个 wiki 页面。

如何才能设计出“好的”测试用例?

在真实的工程实践中,不同的软件项目在研发生命周期的各个阶段都会有不同的测试类型。
对于每一种不同的测试类型,设计出“好的”测试用例的关注点和方法论可能会有很大的差异, 有些可能采用黑盒方法,有些可能采用白盒方法,有些还会采用灰盒方法(比如,微服务架构中的测试),所以很难有一套放之四海而皆准的套路。
面向终端用户的 GUI 测试为例
在具体的用例设计时,首先需要搞清楚每一个业务需求所对应的多个软件功能需求点,然后分析出每个软件功能需求点对应的多个测试需求点,最后再针对每个测试需求点设计测试用例。
技术图片
1.具体到测试用例本身的设计,有两个关键点需要你注意。
从软件功能需求出发,全面地、无遗漏地识别出测试需求是至关重要的,这将直接关系到用例的测试覆盖率。 比如,如果你没有识别出用户登录功能的安全性测试需求,那么后续设计的测试用例就完全不会涉及安全性,最终造成重要测试漏洞。
2.对于识别出的每个测试需求点,需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。 这里需要注意的是,要综合运用这三种方法,并针对每个测试需求点的具体情况,进行灵活选择。

用例设计的其他经验

只有深入理解被测试软件的架构,你才能设计出“有的放矢”的测试用例集,去发现系统边界以及系统集成上的潜在缺陷。

必须深入理解被测软件的设计与实现细节,深入理解软件内部的处理逻辑。

需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性,并以此为依据来找出遗漏的测试点。

02 | 如何设计一个“好的”测试用例?

标签:经验   check   wiki   分析   特征   完全   边界条件   png   image   

原文地址:https://www.cnblogs.com/Uni-Hoang/p/13211075.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!