您的位置: 首页  >  文章  >  3.软件测试用例

3.软件测试用例

分类: 文章 • 2025-05-27 18:04:53

软件测试用例

测试用例的的基本要素

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
评价测试用例的标准：对比好坏代码的评价标准

  • 用例表达清楚，无二义性。
  • 用例可操作性强。
  • 用例的输入与输出明确。一条用例只有一个预期结果。
  • 用例的可维护性好。
  • 用例对需求的覆盖率高。
  • 暴露程序Bug的能力强力。

例：
3.软件测试用例

测试用例的设计方法

基于需求的设计方法

RBT( Requirements-Based Testing)是基于需求的测试方法，会使测试更加有效，因为 它使测试专注于质量问题产生的根源，即需求。
基于需求的测试是一种最根本的软件测试，重点关注以下两大关键问题。 （1）验证需求是否正确、完整、无二义性，并且逻辑一致。 （2）要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需
求。

  • 等价类

    依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过。

    1. **有效等价类：**对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
    2. 无效等价类：根据需求说明书，不满足需求的集合。

    **特点：**解决了输入很多无法穷举的问题

  • 边界值

    针对边界值和边界值附近的值进行测试用例设计

    一般边界值和等价类方法用在一起设计及测试用例

  • 因果图

    本质：因果图是一种简化了的逻辑图；

    适用于：有多个输入、输出和不同输入的组合之间有关系。

    因果图需要掌握的基本知识
    • **恒等：**如果原因为真，那么结果必定为真

3.软件测试用例

  • **与：**只有2个原因都为真，那么结果为真

3.软件测试用例

  • **或：**2个原因中有一个为真时，结果就为真
    3.软件测试用例

  • **非：**只有原因为假，结果才为真

3.软件测试用例

因果图法设计测试用例的步骤如下：
  1. 分析所有可能的输入和可能的输出。
  2. 找出输入与输出之间的对应关系。
  3. 画出因果图。
  4. 把因果图转换成判定表。
  5. 把判定表对应到每一个测试用例。

  • 正交排列

    • 研究多因素多水平的一种设计方法。取出多个水平的最优组合，通过研究这些组合最后的实验结果来分析自己的实验结果。

    • 正交表的构成：

      • 因素（Factor）：输入

      • 水平（位级）（Level）：因素的取值

      • 水平数：每个因素取值的个数

      • 列数：因素数（C）

      • 行数(Runs)：试验的次数（N），（水平数-1）*因素数+1

    • 正交法设计测试用例的步骤：
      1、有哪些因素（变量）
      2、每个因素有哪几个水平（变量的取值）
      3、选择一个合适的正交表
      4、把变量的值映射到表中
      5、把每一行的各因素水平的组合作为一个测试用例
      6、加上你认为可疑且没有在表中出现的用例组合

    • 正交表的性质

      • 每一列中不同的数据出现的次数一样多
      • 任何两列各有序对数出现的次数一样多

    • 问题：

      • 如果水平数不相等是否可以使用正交表?
        • 答：可以，需要直接查正交表，按最大水平数
      • 如果行数为奇数是否可以使用正交表（无法保证每列不同数据出现的次数一样多）?
        • 可以，查表：PICT

  • 场景设计法

    • 基本事件流：正常情况的事件发展顺序
    • 备选事件流：异常情况下的事件发展顺序

  • 错误猜测法

    根据经验和直觉去判断系统的哪个模块有一个问题，针对有问题的模块进行测试用例的设计。设计用例的补充方法。

测试用例的粒度和评价

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

测试用例的粒度和评价

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

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法， 具体到界面元素的操作步骤，指定测试的方法和工具等。

  • 测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。
  • 过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
  • 粒度的把握可参考：
    • 产品的质量要求
    • 项目对用例的要求
    • 测试时间和资源是否充分

用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

  • 粒度的把握可参考：
    • 产品的质量要求
    • 项目对用例的要求
    • 测试时间和资源是否充分

相关推荐