我们现处于哪层?最顶层;每一层我们可以做哪些事?现在公司基本两层:前端→后端,稍微复杂点项目三层,UE4→前端→后端 ,后端后续微服务之后,前端→网关→后端:服务排查问题置顶向下成本将越来越高,长期受益可以从后面几个阶段提升;文章源自玩技e族-https://www.playezu.com/185239.html
二、单元测试文章源自玩技e族-https://www.playezu.com/185239.html
2.1项目周期:文章源自玩技e族-https://www.playezu.com/185239.html
测试第一步:单元测试(开发模块完成);例如:
文章源自玩技e族-https://www.playezu.com/185239.html
2.2单元测试的好处:文章源自玩技e族-https://www.playezu.com/185239.html
文章源自玩技e族-https://www.playezu.com/185239.html1、没有什么数据是造不出来的,通通返回Mock 的对象 2、代码中的异常处理代码,也可以通过mock 接口,使之抛出异常 3、不产生任何脏数据 4、跑
case更快了,因为不用启动整个项目,相当于 Main 方法 5、项目测试越往后越顺畅,为 接口测试,功能测试打头阵
三、接口测试
3.1手工测试的痛点:文章源自玩技e族-https://www.playezu.com/185239.html
1、牛牛搭系统复杂度不断增加,手工测试的工作不断增加;
2、回归工作较大测试效率越来越低,覆盖不完全;
3、线上bug没有有效保障手段,比较被动(线上bug反填到自动化脚本)
4、bug排查效率低(前后端及各服务之间分离越来越明显)
3.2自动化优点:文章源自玩技e族-https://www.playezu.com/185239.html
1、日常测试前端字段的校验不能满足要求,服务端字段校验时,通过接口测试来做能很快满足测试场景;
2、当APP的代码不更新,而服务端代码更新时,直接通过接口自动化测试就能快
速知道是否影响APP的功能。
3、接口测试相对容易实现自动化,也容易实现持续集成,且相对UI自动化也比较稳定;
4、可以减少人工回归测试人力成本与时间,缩短测试周期,支持后端快速发版需求。
5、接口持续集成会带来效率提升,人力手工成本的减少,最终达到低成本高收益。
备注:自动化的收益 = 迭代次数 * (全手动执行成本 - 维护成本) - 首次自动化成本
3.3接口自动化怎么做?文章源自玩技e族-https://www.playezu.com/185239.html
选型思路:
1、可自动化,低成本(√)
eg:postman+newman+Jenkins持续集成
2、自动化,成本高(ToDo)
TD:①Test工程+Junit框架
②单元测试
eg:持续集成+报告+得出覆盖率
3、不可自动化(待定)
eg:业务成熟之后,UI自动化是否能解决
四、自动化持续集成搭建
4.1环境搭建大概过程:
1、linux虚拟机搭建,作为测试服务器主机(我旁边那台电脑) 2、Newman安装,用于psotman脚本执行工具
3、Git 安装,clone test工程,用于拉取服务器postman的脚本; 4、Jenkins搭建,自动构建+报告展示 5、钉钉发送报告消息
五、postman工具使用
5.1,操作流程
1、下载Postman工具的客户端
eg:单接口测试及断言脚本调试
2、newman下载安装
eg:调式导出的postman脚本,确保能跑出来脚本再提交到git
3、注册一个postman账号,通过这个地址加入项目组: https:
//app.getpostman.com/join-team?invite_code=89e29047b32f8ccd21a88992dc13e500
4、新增第一个request请求
5.2 页面功能
1>接口名称;
2>接口的请求类型:GET;
3>环境变量;
eg:建议接口测试过程中多思考,灵活运用
变量;便于日后脚本维护;
4>接口请求地址
5>URL带入的入参
6>新增查看环境变量
7>发送接口请求
8>保存接口,存到对应的脚本目录下
5.3 断言初步使用
1>header头
eg:x-access-token 登陆接口保存token
2>Body请求入参,接口文档获取;
3>Test,用于Asser断言验证结果;
eg:
第一行,Json返回结果赋值给一个变量;
大框的,断言脚本登录返回值,塞到token里面
最后一行,效验该接口的角色权限结果
5.4 批量执行/调试脚本
1>导出postman脚本 2>下载环境变量脚本;
3>cmd,运行脚本;
eg:
newman run Test.postman_collection.json -n 2 -e base_url.postman_environment.json Test.postman_collection.json --接口测试脚本文件
base_url.postman_environment.json -- 环境变量文件 -n2表示迭代2次
六、展望未来(YY)
6.1 最后YY一下IT话题
1、现阶段单元测试自动化,接口测试自动化,UI测试自动化,叫什么?满足什么?未来有什么价值?
引入DevOps,DevOps是什么?跟我们有什么关系?
eg:DevOps是一种软件开发方法,涉及软件在整个开发生命周期中的持续开发,持续测试,持续集成,持续部署和持续监控。标红对于
测试而言是什么,大家自我思考;
2、被管道化的运维工程师?
eg:想想技术最初有DBA,运维工程,开发,测试,现在呢?只有 开发+测试
被管道化之后出现两类极端?
① 小中型公司,普通的运维岗位消失了 不被公司需要,被阿里云管道化,自动打包,一键部署等;(是否有危机感)
② 高级运维工程师,能力要求越来越高了,工资也越来优厚了,可以看出最终的结果,宁缺毋滥
6.2 YY Test话题
说说测试,测试现在岗位被细化:功能测试—单元测试—接口测试自动化—UI自动化—性能测试
这几个细化岗位,近几年最可能会被管道化是谁?
1、功能测试目前大厂基本很少有了(核心模块少量业务专家),都是外包测试,可能会被UI自动化代替;
2、单元测试,开发在做部分没有养成习惯,主要是保证开发质量,为下游扫平基础障碍;
3、接口测试 是不是开发也可以做,只是愿不愿意做,极端一点,把测试工资给他试试看?谷歌一开始是没有测试的;
4、UI自动化一般最难做,受产品变更的影响,成本高收益低,最近图片识别及照片算法脱衣服,想着如果应用到UI自动化 也是不会有太
大难度;(稍远稍近了点,哈哈~)
5、不能被管道化的,我们来看看 我们应该想着怎么在单元测试
/接口测试 加重我们的价值,接口测试/单元测试 有逻辑验证在里面 近期
几年被管道化可能性较低,性能有结果分析,脚本调优,暂时也不必担心;
我们现处于哪层?最顶层;每一层我们可以做哪些事?现在公司基本两层:前端→后端,稍微复杂点项目三层,UE4→前端→后端 ,后端后续微服务之后,前端→网关→后端:服务排查问题置顶向下成本将越来越高,长期受益可以从后面几个阶段提升;
二、单元测试
2.1项目周期:
测试第一步:单元测试(开发模块完成);例如:
2.2单元测试的好处:
1、没有什么数据是造不出来的,通通返回Mock 的对象 2、代码中的异常处理代码,也可以通过mock 接口,使之抛出异常 3、不产生任何脏数据 4、跑
case更快了,因为不用启动整个项目,相当于 Main 方法 5、项目测试越往后越顺畅,为 接口测试,功能测试打头阵
三、接口测试
3.1手工测试的痛点:
1、牛牛搭系统复杂度不断增加,手工测试的工作不断增加;
2、回归工作较大测试效率越来越低,覆盖不完全;
3、线上bug没有有效保障手段,比较被动(线上bug反填到自动化脚本)
4、bug排查效率低(前后端及各服务之间分离越来越明显)
3.2自动化优点:
1、日常测试前端字段的校验不能满足要求,服务端字段校验时,通过接口测试来做能很快满足测试场景;
2、当APP的代码不更新,而服务端代码更新时,直接通过接口自动化测试就能快
速知道是否影响APP的功能。
3、接口测试相对容易实现自动化,也容易实现持续集成,且相对UI自动化也比较稳定;
4、可以减少人工回归测试人力成本与时间,缩短测试周期,支持后端快速发版需求。
5、接口持续集成会带来效率提升,人力手工成本的减少,最终达到低成本高收益。
备注:自动化的收益 = 迭代次数 * (全手动执行成本 - 维护成本) - 首次自动化成本
3.3接口自动化怎么做?
选型思路:
1、可自动化,低成本(√)
eg:postman+newman+Jenkins持续集成
2、自动化,成本高(ToDo)
TD:①Test工程+Junit框架
②单元测试
eg:持续集成+报告+得出覆盖率
3、不可自动化(待定)
eg:业务成熟之后,UI自动化是否能解决
四、自动化持续集成搭建
4.1环境搭建大概过程:
1、linux虚拟机搭建,作为测试服务器主机(我旁边那台电脑) 2、Newman安装,用于psotman脚本执行工具
3、Git 安装,clone test工程,用于拉取服务器postman的脚本; 4、Jenkins搭建,自动构建+报告展示 5、钉钉发送报告消息
五、postman工具使用
5.1,操作流程
1、下载Postman工具的客户端
eg:单接口测试及断言脚本调试
2、newman下载安装
eg:调式导出的postman脚本,确保能跑出来脚本再提交到git
3、注册一个postman账号,通过这个地址加入项目组: https:
//app.getpostman.com/join-team?invite_code=89e29047b32f8ccd21a88992dc13e500
4、新增第一个request请求
5.2 页面功能
1>接口名称;
2>接口的请求类型:GET;
3>环境变量;
eg:建议接口测试过程中多思考,灵活运用
变量;便于日后脚本维护;
4>接口请求地址
5>URL带入的入参
6>新增查看环境变量
7>发送接口请求
8>保存接口,存到对应的脚本目录下
5.3 断言初步使用
1>header头
eg:x-access-token 登陆接口保存token
2>Body请求入参,接口文档获取;
3>Test,用于Asser断言验证结果;
eg:
第一行,Json返回结果赋值给一个变量;
大框的,断言脚本登录返回值,塞到token里面
最后一行,效验该接口的角色权限结果
5.4 批量执行/调试脚本
1>导出postman脚本 2>下载环境变量脚本;
3>cmd,运行脚本;
eg:
newman run Test.postman_collection.json -n 2 -e base_url.postman_environment.json Test.postman_collection.json --接口测试脚本文件
base_url.postman_environment.json -- 环境变量文件 -n2表示迭代2次
六、展望未来(YY)
6.1 最后YY一下IT话题
1、现阶段单元测试自动化,接口测试自动化,UI测试自动化,叫什么?满足什么?未来有什么价值?
引入DevOps,DevOps是什么?跟我们有什么关系?
eg:DevOps是一种软件开发方法,涉及软件在整个开发生命周期中的持续开发,持续测试,持续集成,持续部署和持续监控。标红对于
测试而言是什么,大家自我思考;
2、被管道化的运维工程师?
eg:想想技术最初有DBA,运维工程,开发,测试,现在呢?只有 开发+测试
被管道化之后出现两类极端?
① 小中型公司,普通的运维岗位消失了 不被公司需要,被阿里云管道化,自动打包,一键部署等;(是否有危机感)
② 高级运维工程师,能力要求越来越高了,工资也越来优厚了,可以看出最终的结果,宁缺毋滥
6.2 YY Test话题
说说测试,测试现在岗位被细化:功能测试—单元测试—接口测试自动化—UI自动化—性能测试
这几个细化岗位,近几年最可能会被管道化是谁?
1、功能测试目前大厂基本很少有了(核心模块少量业务专家),都是外包测试,可能会被UI自动化代替;
2、单元测试,开发在做部分没有养成习惯,主要是保证开发质量,为下游扫平基础障碍;
3、接口测试 是不是开发也可以做,只是愿不愿意做,极端一点,把测试工资给他试试看?谷歌一开始是没有测试的;
4、UI自动化一般最难做,受产品变更的影响,成本高收益低,最近图片识别及照片算法脱衣服,想着如果应用到UI自动化 也是不会有太
大难度;(稍远稍近了点,哈哈~)
5、不能被管道化的,我们来看看 我们应该想着怎么在单元测试
/接口测试 加重我们的价值,接口测试/单元测试 有逻辑验证在里面 近期
几年被管道化可能性较低,性能有结果分析,脚本调优,暂时也不必担心;
评论