软件测试(测试用例详解)(三)

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目录即可看到生成的文件在这里插入图片描述

  1. 用记事本打开即可看到生成的测试用例(格式可能会乱,需要调整一下)在这里插入图片描述

  2. 测试用例:

  • 场景设计法

主事件流,次事件流。
案例:
ATM机取款
插卡 —> 选择语言 —> 输入密码 —> 选择业务 —> 输入取款金额 —> 等待吐钱
在这里插入图片描述

  • 错误猜测法

依赖测试人员的经验。

3. 如何模拟弱网?

  • 使用fiddler模拟弱网
  1. 打开弱网
    在这里插入图片描述

  2. 参数调整:

    第一步: 在这里插入图片描述
    第二步:
    在这里插入图片描述
    第三步:修改参数即可
    在这里插入图片描述

  • charles

4. 如何测试接口?

  • 工具:Postman
  • 方法(GET/POST)
  • 参数(传参数/不传参数/传入非法参数 )
  • 参数格式(parameter/json)

5. 练习

  1. 有一个冒泡排序,针对这个代码如何测试?
  • 方法参数(参数类型,不给参数,参数传递为空)
  • 异常处理
  • 代码规范
  • 语句覆盖
  • 条件覆盖
  • 语句条件覆盖
  • 判定覆盖
  1. Linux zip命令测试
  • 功能:

    • 打包的文件是一个不存在的文件;
    • 命令使用正确,文件存在,文件是否被压缩;
    • 能否一次性打包多个文件;
    • 打包后的内容是否有缺失;
  • 界面:打包后的zip高亮;打包后的文件后缀名.zip;

  • 易用:
    输入错误,此时有没有提示

  • 性能:

    • 打包一个1KB文件时间是多少?
    • 打包一个20G的文件;
    • 一次打包多个文件;
  1. 水杯测试用例

在这里插入图片描述

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

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

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

7. 测试的分类

  • 按照测试对象划分
  • 界面测试:

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

    • 可靠性= 正常运行时间/(正常运行时间+非正常运行时间)*100%
  • 容错性测试:

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

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

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

    • 符合标准和规范
    • 直观性
    • 一致性
    • 灵活性
    • 舒适性
    • 正确性
    • 实用性
  • 安装卸载测试

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

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

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

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

  • 内存泄漏测试

    • 人工静态法: 代码走读,人工查找未被回收的内存
    • 自动工具法: 借助相应测试内存泄漏测试工具 如:Visual Leak Detector
  • 按照是否查看代码划分
  • 黑盒测试
    • 完全不考虑程序和内部结构, 检查系统功能是否按照需求规格说明书的规定正常使用, 是否能适当的接收输入数据而输出正确的结果,满足规范的需求.
    • 测试方法: 等价类, 边界值, 因果图, 场景法, 错误猜测法.
  • 白盒测试
    • 检查软件内部的逻辑结构, 对软件中的逻辑路径进行覆盖测试, 在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致.
    • 测试方法: 语句覆盖, 判定覆盖, 条件覆盖, 判定条件覆盖, 条件组合覆盖, 路径覆盖.
  • 灰盒测试
    • 介于白盒测试和黑盒测试之间,多用于集成测试阶段, 不仅关注输入输出的正确性也关注程序内部的情况.
  • 按照开发阶段划分
  • 单元测试
    在这里插入图片描述
  • 集成测试
    在这里插入图片描述
  • 系统测试
    在这里插入图片描述
  • 验收测试
    在这里插入图片描述
  • 回归测试
    在这里插入图片描述
  • 冒烟测试
    在这里插入图片描述
  • 按照实施组织划分
  • α测试
    在这里插入图片描述
  • β测试
    在这里插入图片描述
  • 第三方测试
    介于开发方和用户方之间的组织的测试.
  • 按照是否运行代码划分
  • 静态测试
    在这里插入图片描述
  • 动态测试
    在这里插入图片描述
  • 按照是否手工划分
  • 手工测试
    在这里插入图片描述
  • 自动化测试
    在这里插入图片描述
  • 按照地域划分
  • 国际化测试
    在这里插入图片描述
  • 本地化测试
上一篇:如何选择合适的鹰眼降尘系统(已解答)


下一篇:Java和大数据如何选择?