测试软件笔记

Posted 2021-10-25 小鹿可可乐

测试

• 1.Postman接口测试
• • 1.1概念及原因
  • 1.2接口测试步骤
  • 1.3 编写测试用例
  • 1.4 post数据类型
  • 1.5 BUG前端还是后端
  • 1.6 Fiddler抓包
  • 1.7 Postman变量类型
• 2. Jmeter性能测试
• • 2.1 接口测试
  • 2.2 多个接口组合
  • 2.3 压力测试
  • • 2.3.1压测前要明确压测功能和压测指标，一般需要确定的几个问题：
    • 2.3.2 压测设置
    • 2.3.3 压测结果查看
    • 2.3.4 压测结果分析

1.Postman接口测试

1.1概念及原因

接口测试是测试系统组件间一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。
接口测试可以较早介入。

1.2接口测试步骤

• 测试接口文档（需求文档）
• 根据接口文档编写测试用例（用例编写完全可以按照以往规则来编写，例如等价类划分，边界值等设计方法）
• 执行测试，查看不同的参数请求，接口的返回的数据是否达到预期。
• 得到测试报告

1.3 编写测试用例

• 覆盖所有参数
• 覆盖所有必填参数
• 某一必填参数为空
• 必填参数基础上少填一个参数
• 多传一个参数
• 必填参数数据类型错误，数据值错误
• 任意组合可选参数
• 与业务逻辑相关的，用户身份认证为空或者错误
• 字段唯一性校验，如插入字段不能重复，发送两次请求，查看第二次结果

1.4 post数据类型

None不需要参数
from-data 可以传文件.txt 或 Text 文本信息键值对
X—www表单个数 键值对
Raw -> 文本 html json …
Binary 上传文件，以多媒体文件为主

1.5 BUG前端还是后端

先看请求报文，对着接口文档，看请求报文有没问题，有问题就是前端发的数据不对
请求报文没问题，那就看返回报文，返回的数据不对，那就是后端开发的问题咯

1.6 Fiddler抓包

通过Fiddler改写HTTP代理，让数据从它那通过，来监控并且截取到数据
在打开Fiddler的一瞬间，他就已经设置好浏览器的代理。
当你关闭时，它又帮你吧代理还原了。所以一般不要手动设置。

1.7 Postman变量类型

Postman提供了4种变量类型
环境变量（Environment Variable）:

• 环境变量值在同一个变量值随着环境的不同而变化。比如测试环境和生产环境只是host不同，那就可以吧host设置成一个变量，当切换成测试环境用的就是测试环境的host,切换到生产环境就是生产环境的host。

本地变量（Local Variable）：

• 主要是针对单个url请求设置的变量，作用域只是局限在请求范围之内

全局变量（Global Variable）：

• 当环境变量和全局变量名称一样时，切换到某个环境时，环境变量会覆盖全局变量 全局变量在所有的环境里，变量值都一样，全局变量的作用域是所有请求

数据变量（Data Variable）：
需要添加断言

• 参数化 批量测试 数据变量是通过导入外部数据文件（txt 文件 json文件或CSV文件），来获取变量数据
• 批量执行入口：
  1、选择请求接口内容
  2、选择测试环境
  3、填写请求次数（和参数内容对应）
  4、上传参数化数据内容
  5、查看数据内容是否正确
  6、点击执行结果

2. Jmeter性能测试

2.1 接口测试

• 添加线程组
• 线程组中添加http请求，并填写域名，接口，请求参数
• http请求中添加断言
• 查看请求结果 1）查看结果树：打开查看结果树，绿色代表测试通过，红色代表测试失败。在此我们可以看到详细的请求头，响应时间，请求参数和返回结果，方便进行接口调试
  2）断言结果：断言结果是查看返回的数据是否符合给定的断言
  3）查看聚合报告
  Label: 每个JMeter的请求都有一个Name属性，这里显示的就是Name属性的值。
  #Samples:表示本次测试中一共发出多少个请求
  Average:平均响应时间
  Median:也就是50%用户的响应时间
  90%Line: 90%用户的响应时间
  Min：最小响应时间
  Max：最大响应时间
  Error%：本次测试中出现错误的请求的数量/请求的总数
  Throughput：吞吐量——默认情况下表示每秒完成的请求数
  KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec

2.2 多个接口组合

• 正则表达式
• Json Path Extractor

2.3 压力测试

2.3.1压测前要明确压测功能和压测指标，一般需要确定的几个问题：

1.固定接口参数进行压测还是进行接口参数随机化压测？
2.要求支持多少并发数？
3.TPS（每秒钟处理事务数）目标多少？响应时间要达到多少？
4.压服务器名称还是压服务器IP，一般都是压测指定的服务器

2.3.2 压测设置

1.线程数：并发数量，能跑多少量。具体说是一次存在多少用户同时访问
2.Rame-Up Period(in seconds):表示JMeter每隔多少秒发动并发。理解成准备时长：设置虚拟用户数需要多长时间全部启动。如果线程数是20，准备时长为10，那么需要10秒钟启动20个数量，也就是每秒钟启动2个线程。
3.循环次数：这个设置不会改变并发数，可以延长并发时间。总请求数=线程数*循环次数
调度器：设置压测的启动时间、结束时间、持续时间和启动延迟时间。

2.3.3 压测结果查看

1.Samples:表示一共发出的请求数
2.Average：平均响应时间，默认情况下是单个Request的平均响应时间（ms）
3.Error%:测试出现的错误请求数量百分比。若出现错误就要看服务端的日志，配合开发查找定位原因
4.Throughput:简称tps,吞吐量，默认情况下表示每秒处理的请求数，也就是指服务器处理能力，tps越高说明服务器处理能力越好。

2.3.4 压测结果分析

• 与开发确认
• 吞吐量
• 结束登录web服务器查看CPU等性能
• 最大tps
• 最大并发数
  今天也要好好学习呀~