1. 测试用例的概念

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合。

1. 测试环境
2. 操作步骤
3. 测试数据
4. 预取结果

测试用例的评价标准：

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

2. 测试用例的设计方法(黑盒测试用例)

• 基于需求进行测试用例的设计

流程:
需求文档 —> 梳理需求（掌握需求）—> 针对文档设计测试用例,只是针对需求进行了大概的测试。

方法:

• 功能相关：
  针对具体的需求，可以根据业务分类，用户角色（餐厅的会员系统）或者用户操作区域等将系统的功能分解成若干个功能模块，然后按照功能模块分别进行测试需求分析。

  • 系统各个功能界面的验证(借助UI设计稿)
  • 业务流程相关(借助需求规格说明书)
  • 用户操作的易用性，用户体验(往往结合功能测试同时验证 )
  • 功能的一致性，交互性（多功能互操作）的测试
  • 系统的不同输入，结果输出的业务数据测试。
  • 功能的错误操作，异常操作的测试（属于负面测试）
  • 功能实现用到的算法验证，有时需要用运代码评审

• 非功能相关：
  从测试需求分析来 看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高， 就越有可能给易用性，性能带来更大的挑战。

  • 性能
  • 安全性
  • 可靠性
  • 兼容性
  • 易维护性
  • 可移植性

案例：
163邮箱注册(基于需求设计测试用例)

• 等价类法

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

• 有效等价类: 满足用户需求输入集合。
• 无效等价类: 不满足用户需求的输入集合。

步骤：

1. 充分理解需求
2. 划分有效等价类，划分无效等价类
3. 从有效等价类中抽取其中一个数据进行设计测试用例；从无效等价类中抽取其中一个进行测试用例设计。

案例：

• 边界值法

userName(string user_name) {
	user_name_length = user_name.length
   if(user_name_length >= 7 && user_name_length < 15) {
   	if(user_name_length > 6 && user_name_length <15) {
   		// 注册成功
   	}else {
   		// 注册失败
   	}
   }
}

步骤：

1. 充分理解需求

2. 找边界点

3. 针对边界点设计测试用例

   • 边界点 :
     • 上点：边界上的点
     • 内点：边界内的点
     • 离点：边界值附近的一个点(闭区间外离上点最近的点，开区间区间内距离上点最近的点)。
       

• 因果图法

• 判定表
  判定表是一种表达逻辑关系的工具。
  判定关系：

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

• 如何使用因果图设计测试用例?

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

案例：
假设业务单据的处理成功规则为“淘宝618活动，订单已提交，订单合计金额大于300或有红包，则进优惠”
输入：订单已提交，订单金额大于300，有红包
输出： 优惠、不优惠

1. 订单已提交，金额大于300，有红包，优惠
2. 订单已提交，金额大于300，没有红包，优惠
3. 订单已提交，金额小于300，有红包，优惠
4. . . . . . .

• 正交表法

• 什么是正交表?
  • 名词:
    因素：变量
    水平：变量取值
• 如何通过正交表设计测试用例?
  1. 充分理解需求
  2. 确定因素水平
  3. 画正交表
  4. 补充正交表
  5. 将正交表转换成测试用例

案例：
注册邮箱: 姓名、邮箱、密码、确认密码、验证码必须全部输入才能进行注册。
使用 allpirs 画正交表：

1. 将因素和水平填到excel中
   

2. 将excel复制并保存到一个文本文件，这里命名为：正交表test.txt 。

3. 将文本文件移动到allpairs目录下。

4. 打开命令行窗口，进入到allpairs目录下

5. 输入命令，点击回车

allpairs.exe [源文件名] > [目标文件名]

6. 进入allpairs目录即可看到生成的文件

7. 用记事本打开即可看到生成的测试用例（格式可能会乱，需要调整一下）

8. 测试用例：
   

• 场景设计法

主事件流，次事件流。
案例：
ATM机取款
插卡 —> 选择语言 —> 输入密码 —> 选择业务 —> 输入取款金额 —> 等待吐钱

• 错误猜测法

依赖测试人员的经验。

3. 如何模拟弱网？

• 使用fiddler模拟弱网

1. 打开弱网
   

2. 参数调整：

   第一步：
   第二步：
   
   第三步：修改参数即可
   

• charles

4. 如何测试接口？

• 工具：Postman
• 方法（GET/POST）
• 参数（传参数/不传参数/传入非法参数 ）
• 参数格式（parameter/json）

5. 练习

1. 有一个冒泡排序，针对这个代码如何测试？

• 方法参数（参数类型，不给参数，参数传递为空）
• 异常处理
• 代码规范
• 语句覆盖
• 条件覆盖
• 语句条件覆盖
• 判定覆盖
  …

2. Linux zip命令测试

• 功能：

  • 打包的文件是一个不存在的文件；
  • 命令使用正确，文件存在，文件是否被压缩；
  • 能否一次性打包多个文件；
  • 打包后的内容是否有缺失；
    …

• 界面：打包后的zip高亮；打包后的文件后缀名.zip;
  …

• 易用：
  输入错误，此时有没有提示
  …

• 性能：

  • 打包一个1KB文件时间是多少？
  • 打包一个20G的文件；
  • 一次打包多个文件；
    …

3. 水杯测试用例

6. 测试用例设计万能公式

功能，界面，性能，易用，兼容，安全，网络，中断…

• 功能：
  • 物体: 最基本的功能
  • 软件：软件的实现功能
• 界面：
  • 物体：外表，材质，大小，容量…
  • 软件：界面，字体大小，字体颜色，页面布局…
• 易用：（主要依赖测试人员经验）操作简单，使用流畅，人性化…
• 兼容：
  • 物体：除了本职功能还有没有其他功能
  • 软件：操作系统，设备，浏览器版本…
• 性能：
  • 物体：使用寿命…
  • 软件：响应时间,CPU占用率 ,吞吐量，并发数…
• 安全：
  • 物体：材质是否有毒， 物体会不会对人体健康产生危害…
  • 软件：SQL注入，xss漏洞，输入有毒脚本…
• 网络:
  • 2G~5G
  • 弱网
  • WiFi
  • …

7. 测试的分类

• 按照测试对象划分

• 界面测试:

  • 用户直观看到的都是界面：web站，app，小程序，公众号，测试界面的时候，参考软规格说明书，UI设计稿

• 可靠性测试

  • 可靠性= 正常运行时间/(正常运行时间+非正常运行时间)*100%

• 容错性测试:

  • 输入异常容错, 异常操作如: 数据级测试, 校验测试, 界面容错测试
  • 灾难恢复性测试: 强制让软件发生故障, 然后验证系统已保存的用户数据是否丢失,系统和数据是否能尽快恢复.

• 文档测试

  • 包括: 测试文件, 开发文件, 产品文件
  • 关注文档的术语,正确性,完整性,一致性,易用性.

• 兼容性测试

  • 系统版本兼容
  • 用户已有数据兼容
  • 操作系统的兼容
  • 应用平台兼容
  • 浏览器的兼容
  • 与第三方系统及第三方数据的兼容性

• 易用性测试

  • 符合标准和规范
  • 直观性
  • 一致性
  • 灵活性
  • 舒适性
  • 正确性
  • 实用性

• 安装卸载测试

  • 软件不同的安装卸载方式: 应用市场, 浏览器, 下载apk包, 技术脚本或命令等
  • 安装兼容性: 应用是否可以在不同的环境系统及版本下安装
  • 安装或卸载过程中是否可以手动暂停或取消
  • 安装空间不足是系统是否有提示
  • 是否可以正常卸载,及各种卸载方式
  • 卸载和安装过程中出现环境问题软件是否可以正常并且合理的应对,如: 死机, 断电, 断网等.

• 安全性测试

  • 输入域, 输入恶性或带有病毒的脚本或长字符串.
  • 代码中的安全问题,如SQL/XML脚本注入
  • 不安全的数据存储或传递
  • 数据文件,邮件文件,系统配置文件等里面有危害系统的信息或数据.
  • 有问题的访问控制及权限分配等.
  • 假冒ID: 身份欺骗
  • 篡改, 对数据的恶意修改,破坏数据的完整性

• 性能测试

  • 资源泄露
  • 资源瓶颈
  • 线程死锁,线程阻塞
  • 查询速度慢或效率低
  • 受外部系统影响越来越大

  衡量指标: 用户响应时间, 事务平均响应时间(TPS), 吞吐率, 每秒点击次数, 内存和CPU使用率等.

• 内存泄漏测试

  • 人工静态法: 代码走读,人工查找未被回收的内存
  • 自动工具法: 借助相应测试内存泄漏测试工具 如:Visual Leak Detector

• 按照是否查看代码划分

• 黑盒测试
  • 完全不考虑程序和内部结构, 检查系统功能是否按照需求规格说明书的规定正常使用, 是否能适当的接收输入数据而输出正确的结果,满足规范的需求.
  • 测试方法: 等价类, 边界值, 因果图, 场景法, 错误猜测法.
• 白盒测试
  • 检查软件内部的逻辑结构, 对软件中的逻辑路径进行覆盖测试, 在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致.
  • 测试方法: 语句覆盖, 判定覆盖, 条件覆盖, 判定条件覆盖, 条件组合覆盖, 路径覆盖.
• 灰盒测试
  • 介于白盒测试和黑盒测试之间,多用于集成测试阶段, 不仅关注输入输出的正确性也关注程序内部的情况.

• 按照开发阶段划分

• 单元测试
  
• 集成测试
  
• 系统测试
  
• 验收测试
  
• 回归测试
  
• 冒烟测试
  

• 按照实施组织划分

• α测试
  
• β测试
  
• 第三方测试
  介于开发方和用户方之间的组织的测试.

• 按照是否运行代码划分

• 静态测试
  

• 动态测试
  

• 按照是否手工划分

• 手工测试
  
• 自动化测试
  

• 按照地域划分

• 国际化测试
  
• 本地化测试