软件测试 -- 功能测试--测试用例设计(方法)

(测试用例写完，一般会进行用例评审，目的是对测试用例进行审查和评估，以确保测试用例的质量和完整性，从而提高测试的有效性和效率。用例评审通常由测试小组中的多个成员参与，包括测试人员、开发人员、业务分析师和项目经理等。

所以说这块，我没法写啊，还是去找些相关用例评审的视频，具体了解下，他们评审是怎么做的。)

测试用例设计：可以理解根据软件测试用例方法来进行测试用例。

在编写测试用例时需要遵循一定的方法论，以确保测试的全面性和有效性。

测试用例常用方法：

1. 等价类划分法：将输入数据分成几个等价类，每个等价类的数据都应该产生相同的输出结果。

2. 边界值分析法：测试边界值和接近边界的值，以发现边界条件是否会产生错误。

3. 因果图法：用于描述系统的功能和行为，以确定可以生成的测试用例。

4. 决策表(判定表)方法：将各种输入条件与其对应的行为和输出结果组合成一个表格，生成测试用例。

5. 状态转换法：通过定义状态和状态之间的转换，生成测试用例。

6. 错误推测法：通过推测和假设错误条件和错误数据，生成测试用例。

7. 随机测试法：通过随机输入数据来测试系统，以模拟真实环境。

8. 用户场景测试法：测试用户在实际使用软件时的操作流程和场景，以确定测试用例。

测重点

- 等价类（五星）
- 边界值（五星）
- 判定表（五星）
- 场景法（流程图）（五星）
- 错误推测法（二星）
- 其他的了解概念

等价类划分法

概念：通过科学的方法找到具有共同特性的测试输入的子集，能够从穷举测试中解
放（大大减少了测试用例的数量，从而提升测试效率。）

- 分类
  - 有效等价类：满足需求

- 设计测试用例的步骤
  - 需求分析
  - 划分等价类
    - 有效
    - 无效
      - 规则（需求本身）
      - 长度
      - 类型
      - 是否为空（必填项）
      - 是否重复
  - 设计用例
- 典型应用场景
  - 输入框

等价类划分法设计测试用例的步骤

1. 需求分析

        明确需求 （找到所有的输入项）

2. 划分等价类

        针对每个输入项分别确定有效和无效等价类 

3. 编写测试用例

       一条用例尽可能多的覆盖有效等价类；

       无效等价类中每个取值都要使用一条用例来覆盖；

写出下面问题的有效等价类、无效等价类。1、程序要求输入一个数X，并且X的取值范围为集合{1,3,7,15}。

 有效等价类：1,3,7,15无效等价类：2,4

2、用户名（昵称）长度为 3-19，以字母开头，字母或数字结尾

有效等价类：
  - 用户名长度为3-19，以字母开头数字结尾
  - 用户名长度为3-19，以字母开头字母结尾
无效等价类：
  - 用户名长度小于3，
  - 用户名长度大于19，
  - 以数字开头
  - 以字母开头，以空格结尾
  - 特殊字符、汉字、为空

例1：如：城市电话号码，来设计测试用例

城市电话号码：某城市的电话号码是由3部分组成，分别是：
地区码：空白或是3位数字
前缀：非‘0’且非‘1’开头的三位数字
后缀：4位数字

例2：新浪邮箱登录

例3：TPShop商城注册功能测试用例设计

测试用例的编写一般是根据需求说明书中的需求来进行的。

我也没有，哈哈哈，一般来说都是产品经理来写的

项目经理与产品经理跟测试人员之间的关系

在软件项目中，项目经理、产品经理和测试人员通常需要密切合作，以确保项目的成功
。他们之间的关系可以简要描述如下：

项目经理与产品经理：项目经理需要与产品经理进行沟通和协调，以确保项目的目标和
需求能够得到充分的理解和实现。项目经理需要了解产品经理所编写的需求规格说明书
或需求文档，以便将其纳入项目计划和进度管理中，并在项目执行过程中与产品经理保
持沟通，及时解决问题和风险。

产品经理与测试人员：产品经理需要与测试人员进行沟通和协调，以确保测试用例能够
充分覆盖需求，并验证软件是否满足用户和客户的期望。产品经理需要向测试人员提供
需求规格说明书或需求文档，以便测试人员编写相应的测试用例。在测试过程中，产品
经理需要与测试人员保持沟通，以及时解决测试过程中的问题和风险。

项目经理与测试人员：项目经理需要与测试人员进行沟通和协调，以确保测试计划能够
充分覆盖项目的目标和需求，并在测试执行过程中保证质量和进度。测试人员需要向目
经理提供测试计划、测试进度和测试报告，以便项目经理进行项目管理和控制。在测试
过程中，项目经理需要与测试人员保持沟通，及时解决测试过程中的问题和风险。

总之，项目经理、产品经理和测试人员需要相互合作，保持良好的沟通和协调，以确保
软件项目能够按时、按质量完成，满足用户和客户的期望和需求。

说白了，还是有工作经验的好，有工作经验还用了解这些？搞吧，趁年轻，学一点是一点

tpshop注册功能需求说明：
手机号：第一位为1，第二位非2，的11位自然数
注意：对于邮箱注册，仅验证邮箱格式是否正确
xxxx-长度为4-16，类型为数字，字母，下划线组合（可以是纯字母或者数字，不能以下划线开头）

验证码：字母或者数字，与图片一致，点击刷新按钮可以更新验证码
设置密码：要求同输入框提示，6-16位大小写英文字母，数字或符号的组合 (可以是纯字母，数字，符号）
确认密码：同设置密码
推荐人手机：（非必填，之前注册成功的用户）
我已阅读并同意：勾选之后才可以点击同意协议并注册

划分等价类、边界值(以密码举例)

边界值一会介绍

测试用例

ID：建用例编号
用例优先级
P0：一般为保证软件中最主要、重要的功能，最基本的流程能正常运行而设计
P1：次要功能、小功能
P2：UI、边界、错误的设置
P3：错误信息、较复杂的场景、不常用的场景
测试结果：pass、fail、block（由于有bug不能继续执行时填写）、NA（由于环境、资源缺失不能执行时填写）
测试版本号：当前测试任务所用的软件版本号
备注：
1. fail的用例问题描述和对应的bugID可填入此项中
2. block和NA的用例需要在此项填写原因
3. 对用例有疑问，或此用例需要更新也可以填写在此项中

适用场景：

针对需要数据量大，有测试数据输入的地方 

典型代表：页面级的输入框类测试

边界值

上点：边界上的点（正好等于）
离点：距离上点最近的点（刚好大于、刚好下于）
内点：范围内的点（区间范围内的数据）

        

- 作用：对等价类的补充，统计表明程序最容易出错的地方就是在边界附近。
- 概念：基于边界值【有效等价类和无效等价类的分界点】设计测试用例的一种【黑盒】方法

- 设计测试用例步骤
  - 需求分析
  - 划分等价类
  - 确定边界
    - 上点
    - 内点
    - 离点
  - 设计测试用例
- 典型应用场景
  - 存在边界 > >= < <= 大于 小于等于

- - 上点：必选（不考虑区间开闭）  - 内点：必选（建议选择中间范围）  - 离点：开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）

适用场景：

在等价类的基础上针对有边界范围的测试数据输入的地方 

常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语 

典型代表：有边界范围的输入框类测试

判定表

- 概念：存在多个输入条件、多个输出结果，输入和输入之间有组合关系，输入和输出
- 之间有依赖或制约关系。

- 判定表组成：
  - 条件桩：所有输入条件，如欠费状态、关机状态
  - 动作桩：所有的可能的输出结果，如允许主被叫、不允许主被叫
  - 条件项：单个条件的取值范围，一般都是有效等价类和无效等价类(关机、不关机)
    - 表示方式
      - 字符：
        - 真/有效等价类/Y
        - 假/无效等价类/N
      - 数字:
        - 真/有效等价类/1
        - 假/无效等价类/0
  - 动作项：基于每一种条件的组合，得到确认的结果，如打不通等

设计测试用例的步骤

1. 明确条件桩（找到所有的输入条件）2. 明确动作桩（找到所有的输出结果）3. 对条件桩进行全组合4. 明确每个组合对应的动作桩（基于每一种条件的组合情况，确定本组合下的输出结果。）5. 设计测试用例，每行数据对应一条测试用例

真假表示说明：

表示形式	真	假
数字	1	0
符号	Y	N

如：用户呼叫

例2：

订单检查，如果金额大于500元，又未过期，则发出批准单和提货单；        如果金额大于500元，但过期了，则不发批准单与提货单；        如果金额小于500元，则不论是否过期都发出批准单和提货单；        在过期的情况下，不论金额大小还需要发出通知单。

例3：文件修改

如果想对文件进行修改，   输入的第一列字符必须是A/B，第二列字符必须是一个数字，   如果第一列字符不正确，则给出信息L；   如果第二列字符不正确，则给出信息M。

2个条件组合数：4

3个条件组合数：8

3个条件组合数：16

n个条件组合数：2的n次方

适用场景：

有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制 约）关系

以下测试用例的几种方法，不是重点，了解即可

因果图、正交法、场景法、错误推测法

因果图

- 概念：用图解的方法表示输入的各组合关系，写出判定表，进而设计测试用例的一种【黑盒测试】方法。
- 适用范围：适用于分析程序输入条件的各种组合情况，以及输入和输出之间的依赖关系。
- 核心
  - 因：条件
  - 果：结果
- 基本符号（掌握）
  - 恒等（-）：条件成立，结果成立。
  - 非（~）NOT：条件成立，结果不成立；条件不成立，结果成立。
  - 或（V）OR：只要有一个条件成立，结果就成立；所有条件都不成立时，结果才不成立。
  - 与/且（^）AND：多个条件必须同时成立，结果成立；只要有一个不成立，结果就不成立。

设计测试用例的步骤

- 需求分析
- 画出因果图
- **将因果图转换为判定表**
- 生成测试用例

例1：

如果想对文件进行修改，   输入的第一列字符必须是A/B，第二列字符必须是一个数字，   如果第一列字符不正确，则给出信息L；   如果第二列字符不正确，则给出信息M。

正交法

用最小的测试用例获得最大的测试覆盖率。

L4（23）：3因素2水平

**说明**- k代表因素（输入参数）- m叫水平（输入参数的取值）- n代表测试用例数- 读法：k因素m水平

基于正交表设计测试用例- 需求分析- 确定因素与水平（因素：控件名称；水平：每个控件对应的取值）- 确定要采用的正交表- 将正交表中的字母用文字代替- 设计测试用例（一行就是一条测试用例）

例：字符属性设置程序

窗体中有多个控件（字体、字符样式、颜色、字号），每个控件有多个取值字体：仿宋、楷体、华文彩云字符样式：粗体、斜体、下划线颜色：红色、绿色、蓝色字号：20号、30号、40号

allpairs工具，设计测试用例步骤

步骤- 需求分析- 确定因素与水平（因素：控件名称；水平：每个控件对应的取值）- 将确定的因素与水平复制到txt文件中- 打开DOS窗口，进入allpairs目录，运行命令：allpairs.exe test.txt > result.txt- 根据生成的新文件编写测试用例（一行就是一条测试用例）

工具allpairs放到百度网盘里了

场景法(流程图法)

介绍：场景法，也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。

意义：

用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用 

测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

- 概念：场景法就是模拟用户操作软件时的场景，主要用于测试多个功能之间的组合使用情况。
- 使用测试阶段
  - 集成测试
  - 系统测试
  - 验收测试
- 设计测试用例的步骤
  - 需求分析
  - 绘制流程图
  - 设计测试用例（一条流程路径就是一条测试用例）

- 流程图常用符号

开始或结束：椭圆

方向或路径：箭头

处理或操作：长方形

判断：菱形

输入或输出：平行四边形

- 绘制流程图
  - 第1步：确认场景中关键业务步骤
  - 第2步：确定业务之间的先后顺序
  - 第3步：用箭头连接即可


- 绘制工具
  - Microsoft Visio
  - 软件介绍
  - Visio的安装
    - 以管理员身份运行Visio2003_SP3.exe
    - 默认安装即可，中间不需要修改或填写任何内容
  - Visio的基本使用：
    - 新建
  - 画图
    - 选中---del---删除操作
    - ctrl 鼠标左键 拖拽 画纸边缘 -- 扩大画纸
      - ctrl 滚轮 -- 放大缩小
      - 组合与取消组合

 visio绘制流程图软件，已放到百度网盘

适用场景：对于多个功能之间的组合逻辑测试

错误推测法

概念：利用经验或智慧发现程序中可能犯错的地方。

适用场景：

所有正常测试结束后，通过错误推断法再测试之前问题较多的模块 

时间紧，任务量大，根据之前项目类似经验找出易出错的模块重点测试

总结：

- 具有输入功能，但输入之间没有组合关系==》【等价类】- 输入有边界 如长度、类型==》【边界值】- 多输入、多输出、输入与输入之间存在组合关系、输入与输出之间存在依赖或制约- 关系==》【判定表、因果图】- 用最少的测试用例获得最大测试覆盖率时 ==》【正交法】- 多个功能的组合测试 ==> 【场景法、流程图】- 最后推荐使用【错误推测法】来进一步补充测试用例

最后：下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。