【测试】-测试用例

通过学习我们了解到测试的基本概念，本篇我们进行测试用例的学习

---

测试用例的基础概念

什么是测试用例

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

测试用例的好处

测试执行者的依据：使得工作可重复，自动化测试的基础；
评估需求覆盖率：用例的复用，积累测试的方法思路以供后续借鉴；
使用中带来困扰：测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
解决如下问题：不知道是否较全面的测试了所有功能，测试的覆盖率无法衡量。对新版本的重复测试很难实施，存在大量冗余测试影响测试效率
测试用例的好处

1. 提高测试效率，节约测试时间
2. 测试用例是自动化测试的前提
   好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试

测试用例的基本要素

测试环境，操作步骤，测试数据，预期结果
在测试用例要素中，实际结果是不被包含进来的

测试用例的设计方法

是基于黑盒测试的设计方法
基于需求的设计方法
等价类
边界值
因果图
正交排列
场景设计法
错误猜测法

基于需求的设计方法

基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计；
在分析测试需求时，一般分为功能测试需求和非功能测试需求。

功能测试需求分析

在功能测试需求分析中，我们首先要进行以下操作：
需求文档->梳理需求（掌握需求）->针对文档设计测试用例（基于需求设计测试用例）
对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来，功能测试需求包括以下，通常包括以下几个方面。
（1）系统各个功能界面的验证
（2）借助业务把功能串起来进行测试
（3）功能的一致性，交互性（多功能互操作）的测试
（4）系统的不同输入，结果输出的业务数据测试。
（5）功能的错误操作，异常操作的测试（属于负面测试）
（6）功能实现用到的算法验证，有时需要用运代码评审
（7）用户操作的易用性，用户体验，往往结合功能测试同时验证
需求文档->梳理需求（掌握需求）->针对文档设计测试用例（基于需求设计测试用例）
也可以进行以下概括：
功能：业务流程（依据软件规格说明书，prd，需求规模说明书【如果是物体：描述这个物体功能主要用来干什么】），
界面（软件布局，图片大小，文字字体、大小UI设计稿），易用性（测试人员的测试经验）
非功能相关：兼容（设备，操作系统），性能（接口响应时间，接口承载量），安全（xss漏洞，sql注入，权限处理），网络（2G，3G，4G，5G，wife，弱网）
依据软件规格说明书（prd）进行设计

非功能需求测试分析

在非功能需求测试分析中，我们首先要进行以下操作：
充分理解需求->将需求拆分->划分功能需求/非功能需求->测试用例设计
非功能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战。
这里要说明的是对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能特性的要求是不一样的，这个需要根据具体的项目、具体需求和不同产品应用的特点进行分析。
（1）纯客户端软件，比如字处理软件（Word，PPT)，媒体（音频/视频）播放软件（电脑自带的）等。这类软件对系统的功能测试要求是最低的，但是对兼容性和稳定性，可移植性有一定的要求。
（2）企业内部的客户端/服务端（C/S)应用系统。比如电子邮件，即时通信系统（飞Q，企业QQ）等，在系统功能测试需求上比纯客户端复杂，要求功能正确，稳定性能好。但是整体上看，对性能，安全性，兼容性要求不高。
（3）外部大型复杂网络应用系统，比如电子商务，网上银行，视频网站（腾讯，优酷）等，除了有复杂的系统的功能测试需求外，在系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。

测试用例具体的设计方法

等价类

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，**解决了不能穷举测试的问题。

思想：将输入集合划分为不同的类别，测试的时候，只需要从这些类别中抽取其中一个测试用例，此时如果通过，就代表这一类测试用例通过

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

等价类思想设计测试用例步骤

1. 充分理解需求
2. 需求划分（划分有效等价类和无效等价类）
3. 从有效等价类中抽取其中一个数据进行设计测试用例；从无效等价类中抽取一个数据进行设计测试用例（根据需求规格说明书设计测试用例，会用到测试用例的万能公式）

边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

边界点

上点：边界上的点
内点：边界内的点
离点：边界值附近的一个点（闭区间：区间外距离上点最近的点）开区间（区间内距离上点最近的点）

边界值设计测试用例步骤

1. 充分理解需求
2. 找边界点
3. 针对边界点设计测试用例

判定表（因果图）

判定表是一种表达逻辑判断的工具，因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

判定表基本知识

关系：
与：所有的条件必须全部满足，如果一个条件不满足，此时结果假
或：满足其中一个条件，结果就为真，如果条件全部为假，那就为假
非：如果条件为假，那么结果才为真
恒等：如果条件为真，那么结果必定为真。

判定表（因果图）设计测试用例步骤

1. 充分理解需求
2. 分析所有可能的输入和可能的输出。
3. 找出输入与输出之间的对应关系。
4. 画出因果图。///（设计判定表）
5. 把因果图转换成判定表。///（设计判定表）
6. 把判定表对应到每一个测试用例。

正交表

正交表的概念

最简单的正交表是L4(23)，含意如下：“L”代表正交表；L 下角的数字“4”表示有 4 横行，简称行，即要做四次试验；括号内的指数“3”表示有3 纵列，简称列，即最多允许安排的因素是3 个；括号内的数“2”表示表的主要部分只有2 种数字，即因素有两种水平1与2。
正交表的表示形式： L=行数(水平数*因素数) L=N(TC)
因素：输入变量
水平：每一个输入变量的取值

正交表的两条性质：
每一列中各数字出现的次数都一样多。
任何两列中的各有序数对出现的次数都一样多。

因果法设计用例太多怎么办？
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。

正交表设计测试用例步骤

1. 充分理解需求
2. 确定因素，确定水平
3. 画正交表
4. 补充正交表
5. 将正交表转换成测试用例（allpairs）

allpairs使用

1. 将因素和水平放在excal表中
2. 将excal表格内容直接复制到txt文本中
3. 把文本保存在allpairs的路径下
4. CMD进入到allpairs安装路径
5. 在cmd界面输入：all pairs.exe 文档名称 > 新的文档名称_result.txt生成一个新的文档~可以填写，也可以不填写（需要进行补充）
6. 生成正交表
7. 打开文档查看

场景设计法

什么是场景

场景：指的是特定的测试环境或上下文，包括测试的条件、假设、输入和预期输出。每个测试场景都代表了一个具体的测试情境，可以用于验证系统、应用程序或功能的正确性、稳定性和性能。
场景设计法是对整个软件的使用流程进行测试用例设计
场景设计分为：主时间流和次事件流
主事件流（Main Flow）是指用户按照正常的步骤和预期的操作路径与系统进行交互的流程。
次事件流通常用于测试边界条件、异常情况、错误处理、用户交互冲突等情况，以确保系统在不同的操作路径和情景下都能正常运行并提供正确的响应。

通过场景设计测试用例

1. 充分理解需求
2. 确定主事件流
3. 确定次事件流
4. 每一个事件流就是一个测试用例

错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比
很高，被广泛应运于测试。
这个方法的缺点是难以系统化，并且过度依赖个人能力。
主要依 据测试人员的经验
以注册为例
1、校验中特殊字符空格的处理?
2、密码校验中的大小写？
3、姓名中的特殊字符？
4、密码发送是否明文