【软件测试3】测试用例，黑盒测试用例设计方法，缺陷报告

摘星观月

已于 2023-07-07 11:01:45 修改

阅读量3.5k

点赞数 4

分类专栏：软件测试文章标签：测试用例

于 2023-04-10 21:46:28 首次发布

本文链接：https://blog.csdn.net/weixin_54068678/article/details/130070521

版权

软件测试专栏收录该内容

12 篇文章 0 订阅

订阅专栏

一、什么是测试用例

1、测试用例的定义

设计一个情况，软件程序在这种情况下必须能够正常运行，且达到程序所设计的预期结果。

如果程序不能正常运行，且这种问题会重复发生，那表示测试人员已经测试出有缺陷，这时必须将问题标示出来并通知开发人员。

2、测试用例的模板和包含的内容

测试用例应该包含以下内容：

标识符（用例编号）：一般编号规则：TestCase-项目名称-模块名称-功能名称-0001
测试项：测试用例的测试目的。一般情况下，用一句话表明目的。（表明测试模块，测试对象，测试方式、事件）
依赖用例：一般功能流程上，下游功能测试用例依赖于上游功能测试的用例。
测试步骤：用最朴实的语言，写出来软件的操作步骤，要尽量详细。
测试数据：单独整合测试数据，必须和测试步骤中的数据保持一致。
预期结果：准确（对象、内容），原则上每一个操作步骤都要有一个结果。**在重要的步骤之后设定预期结果。一般和测试目的密切相关。测试目的决定测试步骤和测试结果。**例如：在XX操作后跳转到XX页面。
测试结果：要求在测试执行完成后添加，没有执行保持为空。测试结果只有两个：通过（Pass）和失败（Failed）。
测试人：测试的执行人可以和测试用例的设计者相同也可以不同。
备注：为了测试用例正常执行而做的特殊准备。

3、设计测试用例的作用

有效性：测试用例是测试人员测试过程中重要的参考依据。

可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率。

易组织性：即使是小的项目，也可能会有几千甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用。

可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。

可管理性：测试用例也可以作为检验测试人员的进度、工作量以及跟踪/管理测试人员的工作效率的标准。

4、用例按照测试分类

功能（Function）
界面（UI）
性能（Performance）
安全（Security）
接口（Interface）

二、测试用例编写注意事项

不要设计“穷举测试用例”。
在详细测试用例与有效测试时间中找到平衡点。
好的测试用例应该多关注“反向测试问题”。
测试用例库应该不断更新和维护。
测试用例可以复用，但要注意数据有效性和环境变化。
测试用例是设计出来的，不是写出来的。
多去学习经验丰富的测试工程师所设计的测试用例。
针对不同的需求类型和测试对象，灵活采用不同的测试用例设计方法。
测试项必须是确定的，不能模棱两可。测试项一般只写一个测试目的。
一个无效等价类的测试数据，只能违反一个需求。
不能把软件的缺陷设计为测试用例。

三、黑盒测试用例设计方法

1、测试数据选择

a.等价类划分法

原理

把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例
每一类的代表性数据在测试中的作用等价于这一类中的其他值，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误。
反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。

确定等价类的原则：

在输入条件规定的取值范围或值的个数情况下，可以确立一个有效等价类和两个无效等价类。
在输入条件规定“必须”情况下，可以划分一个有效类，一个无效类。
在规定了输入数据须遵守的规则后，可以划分一个有效类，和若干个无效类。

划分等价类和列出等价类表：

表格包括有效等价类及其测试数据，无效等价类及其测试数据。

确定测试用例：

为每个等价类规定一个唯一的编号
设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例覆盖。
设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使得所有的无效等价类都被覆盖。

注意事项：

不要重复，也不要缺失。

b.边界值分析法

核心：“常在河边走，哪有不湿鞋”

如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据。
分析规格说明，找出其他可能的边界条件。
如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。

2、测试步骤设计

a.因果图法 *

适合于描述对于多种输入条件组合的测试方法
根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法。
它适合于检查程序输入条件涉及的各种组合情况。

原因和结果的关系：

原因之间的约束：

要求：原因a成立，要求b一定先成立。

结果之间的约束：

屏蔽：结果之间会出现a出现，b一定不出现。例如：收到注册成功，就一定不会收到注册失败的提示。

案例
在这里插入图片描述

因果关系：
在这里插入图片描述

约束：
在这里插入图片描述

因果图使用中的局限性： 当原因和结果很多时，关系连线很多，导致因果图可读性不强，因此因果图可用于局部的小功能。

**因果图优势 ** ：能够发现设计中存在的不足。

b.判定表法

是分析和表达多逻辑条件下执行不同操作的情况的工具。

应用场合：主要适用于多条件的内容与结果分析。

由以下几个内容组成：

条件桩：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。
动作桩：列出了问题规定可能采取的动作。这些操作的排列顺序没有约束。
条件项：列出针对它左列条件的取值。在所有可能情况下的真假值。
动作项：列出在条件项的各种取值情况下应该采取的动作。

使用的条件：所有的条件桩在表中的位置和顺序互相不影响，所有的动作桩的顺序不会因为条件顺序的变化而产生不同。

建立判定表的步骤：

第一步：识别出操作条件（原因）和对应的动作（结果）

第二步：分析条件的组合数量

第三步：简化和优化结果。排除一些不可能存在的情况

适合使用判定表设计测试用例的条件：

规格说明以判定表的形式给出，或很容易转换成判定表
条件的排列顺序不影响执行哪些操作
规则的排列顺序不影响执行哪些操作
当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
如果某一规则要执行多个操作，这些操作的执行顺序无关紧要

案例：

在这里插入图片描述

c.场景法

原理： 测试时，生动地描绘出事件触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。

基本流： 软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。

备选流： 除了基本流之外的各支流，包含多种不同的情况。

注意：

场景中必须有基本流

测试用例的步骤：

根据说明，描述出程序的基本流及各项备选流
根据基本流和各项备选流生成不同的场景
对每一个场景生成相应的测试用例
对生成的所有测试用例重新复审，去掉多余的测试用例
测试用例确定后，对每一个测试用例确定测试数据值

案例：
在这里插入图片描述

d.正交试验法

概念：使用正交表，从大量实验中，挑选一部分具有代表性的点，进行试验，分析数据。

核心思想：

影响实验结果的称为实验因素
每一个因素的不同取值（状况）称为水平
正交表：每列中，同一个数字（水平），出现的次数相等，任意两列组成的数字对（水平对）出现的次数也是相同的。

实施步骤：

分析所有对结果有影响的因素。从多个角度和方式进行分析（不要放过文本框、按钮等需求中提及或者没有提及的内容）
分析每个因素的水平数量。充分利用等价类、边界值（需求中说明和未说明的都要分析）
选择正交表。只有特定的因素数和水平数的组合才有对应的正交表。在现实中用到的时候，找最贴近的正交表（正交表的因素数和水平数一般要大于实际的因素数和水平数）

正交表的数字关系。n代表实验次数，m代表水平数，k代表因素的数量，这三个数字之间没有任何数学关系。

案例：

使用正交设计助手选择最贴近的正交表生成。

e.功能图法

功能图法又叫做状态迁徙图

来源：在遇到有事务流或由于某种条件成立导致状态改变的软件时，如何进行测试用例的设计就比较麻烦。

状态迁徙图法的目标

设计足够多的测试用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖

步骤：

列出所有可能的输入事件，以IP（input） N的方式
定义空闲状态（初始状态）。一般以软件刚启动时打开的界面状态为空闲状态。
为空闲状态加操作（只加一次）
为上一步产生的新状态加操作（只加一次，并且已经加过的操作不进行重复添加）
循环给所有的新增状态加操作，直到没有新状态产生为止。
组合任意的状态，以列表的形式展现，设计和编写测试用例。

案例：QQ登录界面为例

f.其他用例设计方法

1、测试大纲法

一般用于快速的测试和过程记录。

2、探索性测试

基于经验和直觉，是计划内测试用例设计的补充。

探索性测试执行前也需要设计测试用例。

3、猴子测试

一种没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。

缺点：

测试往往不太真实
不能达到一定的覆盖率
许多测试都是冗余的
需要使用同样的随机数才能重建测试

4、错误推演法

列举出程序中所有可能有的错误和容易发生错误的情况和环境,根据他们选择测试用例。比如适当的断网和弱网测试。
适用场景：容错分析

3、用例设计方法综合选择

首先进行等价类划分
在任何情况下都必须使用边界值分析方法
如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法
对于参数配置类软件，要用正交试验法选择较少的组合方式达到最佳效果
状态迁徙图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据
对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程
可以用错误推测法追加一些测试用例
对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例

案例：以某APP为例

启动页需求：读取版本信息，读取用户信息。

登录界面需求：手机号只支持大陆手机号，验证码为6位数字

在这里插入图片描述

4、注意事项：

测试用例的设计方法：没有哪一种是单独使用的。

所有的软件，都是因为某种操作结果才会导致一定的结果。---------考虑使用因果图
所有的软件都有文本框。---------考虑必须一定使用等价类、边界值。

四、缺陷和缺陷报告

一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不是缺陷。

1、缺陷的属性

缺陷类型： 根据缺陷的自然属性划分（功能、用户界面、文档、软件包、性能、系统/模块接口）

注意： 需求分析、设计阶段文档类型缺陷多，集成测试阶段接口类缺陷多，系统测试阶段功能、界面缺陷多，验收测试阶段更关注性能缺陷，实施过程软件包缺陷多。
缺陷严重程度 ：致命（某主要功能完全丧失）、严重（某主要功能部分丧失）、一般（次要功能没有完全实现，但不影响使用）、较小（操作不便，不影响功能的使用）
缺陷优先级： 必须被修复的紧急程度（立即解决P1、高优先级P2、正常排队P3、低优先级P4）

注意： 优先级的衡量，一般可以根据测试的软件系统的全业务流程划分，软件的基本功能的缺陷优先级高。软件的备选流、基本功能的反向测试优先级较低，甚至可改可不改。
缺陷状态： 缺陷通过一个跟踪修复过程的进展情况。（激活或打开，已修正或修复，关闭或非激活，重新打开，推迟，保留，不能重视，需要更多信息，重复，不是缺陷，需要修改软件规格说明书）
缺陷起源
缺陷来源（需求说明书，设计文档，系统集成接口，数据流，程序代码）
缺陷根源（测试策略，过程、工具和方法，团队/人，缺乏组织和通讯，硬件，软件，工作环境）