测试笔记(用例篇)

Posted 一位懒得写博客的小学生

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了测试笔记(用例篇)相关的知识,希望对你有一定的参考价值。

基于需求的设计

RBT( Requirements-Based Testing) 是基于需求的测试方法,会使测试更加有效,因为 它使测试专注于质量问题产生的根源,即需求。

基于需求的测试是一种最根本的软件测试,重点关注以下两大关键问题:

  1. 验证需求是否正确、完整、无二义性,并且逻辑一致;
  2. 要从“黑盒”的角度,设计出充分并且必要的测试集,以保证设计和代码都能完全符合需求。

等价类

思想:把输入划分为若干个等价类,从每一个等价类当中选一个测试用例进行测试,如果这个测试用例测试通过,我们就说这个等价类测试通过。

  • 有效等价类:根据需求规格,有意义的数据集合。
  • 无效等价类:不符合需要所要求的数据集合。

边界值

针对输入和输出的边界进行测试用例的设计;

因果图法

当输入有很多,不同输入的组合对应不同的输出,用因果图来分析不同输入组合和不同输出之间的关系。

步骤:

  1. 分析出所有的输入、输出;
  2. 找出输入输出之间的逻辑关系;
  3. 根据输入输出之间的关系画因果图;
  4. 根据因果图画判定表;
  5. 根据判定表设计测试用例

正交排列

正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合

正交试验设计(Orthogonal experimentaldesign) 是研究多因素多水平的一种设计方法,它是根据正交性,由试验因素的全部水平组合中挑选出部分有代表性的点进行试验,通过对这部分试验结果的分析了解全面试验的情况,找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。

  • 因素(Factor):在一项试验中,凡欲考察的变量称为因素(变量);
  • 水平(位级)(Level):在试验范围内,因素被考察的值称为水平(变量的取值)
正交表的构成:
行数(Runs):正交表中的行的个数,即试验的次数,用N代表;
因素数(Factors):正交表中列的个数,用C代表;
水平数(Levels):任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或从1到“水平数”,用T代表.

正交表的表示形式: L=行数(水平数*因素数) L=N(TC);
行:(水平数 - 1) * 因素数 + 1.
列:因素数

正交表的两条性质

每一列中各数字出现的次数都一样多;

任何两列所构成的各有序数对出现的次数都一样多.

正交法设计测试用例的步骤

  1. 有哪些因素(变量);
  2. 每个因素有哪几个水平(变量的取值);
  3. 选择一个合适的正交表;
  4. 把变量的值映射到表中;
  5. 把每一行的各因素水平的组合作为一个测试用例;
  6. 加上你认为可疑且没有在表中出现的用例组合

场景设计法

把一个个孤立的功能点按照一定的策略串联起来,形成一定的场景或者业务。
分析出场景(业务)里面的功能点,根据功能点找出正常和异常的输入输出,再根据分析的结果去设计测试用例。

错误猜测法

根据测试人员的知识,经验,直觉判断那一个模块会出现问题,专门针对这个模块进行测试用例的编写。

面试题:
黑盒测试设计测试用例的方法有哪些?
等价法,边界值,因果图,正交法,场景法,错误猜测法。

测试用例的有效性

  • 测试用例对应的功能已删除,不可操作了
  • 执行一条测试用例未发现BUG,实际该处有BUG
  • 执行一条测试用例发现了BUG
  • 执行一条测试用例未发现BUG,实际该处BUG已修改

测试用例的粒度

粒度:指测试用例编写的详细程度

测试用例写得过于复杂或详细,会带来两个问题:

  1. 效率问题
  2. 维护成本问题

测试用例设计得过于详细,留给测试执行人员的思考空间就比较少,容易限制测试人员的思维

据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例

  • 产品的质量要求
  • 项目对用例的要求
  • 测试时间和资源是否充分

以上是关于测试笔记(用例篇)的主要内容,如果未能解决你的问题,请参考以下文章

软件测试学习之旅----用例篇

面试测试开发工程师:用例篇

软件测试——软件测试用例篇

测试笔记(用例篇)

测试笔记(用例篇)

软件测试用例篇