2012-1
做了一些前端单元测试的调查,可以帮助了解一下前端单元测试的现状;
根据现有的经验提出些施行构想,对执行步骤进行预估和比较;
以下是现在想到和总结的一些问题,考虑的还不是很全面。
单元测试的价值是什么?
答:1、保证前端代码的健壮性与易维护性,前端的JS问题及早发现;
2、提高前端开发工程师单元测试的意识,提高代码质量,规范代码,增加代码健壮性,提高产品质量。
3、回归的价值场景:单个应用涉及其他应用变更,能迅速反馈错误。
业界的单元测试模式是什么?
答:业界有许多单元测试框架,基本模式如同一辙,页面加载 -> 查询页面中的测试用例 -> 执行JS用例脚本 -> 捕获异常
-> 结果显示。
其测试大部分是时时的,或者是本地测试用的比较多,无法在时间的维度上进行问题跟踪、分析,不容易管理JS脚本等。
与业界前端单元测试对比,我们能做什么?
1、使前端测试代码与开发代码分离,易于维护;
2、可以与UI自动化结合,前端单元测试的自动化,让更多的前端测试脚本借助现有的自动化去跑;
3、与测试平台集成,方便的JS异常错误显示与跟踪;
淘宝前端单元测试现状?
答:淘宝UED 有一套JS单元测试系统——云谦的”CloudyRun”,基于nodeJS
+ Jasmine,
CloudyRun驱动的直接是浏览器,让浏览器打开页面,支持各种浏览器,不仅局限于IE,火狐,更能支持chrome,safari。
现在的前端测试遇到什么问题。
答:
1、现有自动化产品不完善:
- 在异常数据处理上面存在问题,没有具体的错误异常日志,如:测试的结果数据采用了发送邮件的方式,而测试的历史记录却不好跟踪,假如想查看过去一个月的测试结果,就无法办到;
- 查看执行过的用例,只能查看测试代码;
- 没有数据分析
2、推行中遇到的问题:
- UED各应用的代码沙箱闭包无法调用接口和方法,除非开发有单元测试意识,特地开放;
- 代码结构每条线各自有规范,比如开发什么样的全局变量,标准的封装方法不是很统一;
- 前端开发任务比较多,做单元测试的精力比较少;
- 开发不太喜欢写测试代码。
我们做单元测试可达成的目标是什么?
答:在测试平台上试行,针对测试平台一个系统的做前端代码的单元测试,覆盖率工具。
初步只能在现有我们的平台上面做一些验证与改进,长远的来看还是利大于弊;
短期的目标是什么?
答:1、短期的目标是在测试平台试行并改进;去业务线推广还要等稍微成熟的阶段;
2、更长远的目标是基于平台目标达成,在一条产品线试行,去业务线轮岗推行。
我们推动是不是也会遇到的同样问题,优势有哪些?
答:1、我们推动必然也会存在开发人员写代码的习惯问题;
2、但是我们有着天然的优势,前端测试数据可直接继承到测试平台,用户忠诚,开发测试每天工作都在平台上面,可以潜移默化的影响开发人员的编码习惯;
3、UI自动化可以解决我们前端脚本自动化执行的问题,技术上面,有积累更多。
我们构想有哪些不同?
答:如果我们来做前端单元测试和CloudyRun重合度预估是25%。
执行步骤:
1、编写单元测试代码;
2、接入UI自动化执行;
3、错误报告
我所设想的测试步骤:
1、编写JS测试脚本,本地环境测试(我们提供本地测试环境包);
2、部署到测试平台(可能是SVN或者上传?),指定脚本所测的URL;
3、
测试平台 调用
UI自动化 脚本在服务器端浏览器注入执行JS测试脚本;
4、浏览器捕获JS错误异常;
5、异常数据发送到测试平台;
6、测试结果数据展示分析等,大致步骤是这样;如果可以,JS用例是否可以直接在平台上面编辑?
(JS代码覆盖率统计,覆盖率工具JScoverage,打桩,代码管理等问题)。
如果执行人角色是测试,会遇到哪些问题?怎么解决?
答:1、单元测试不同于接口测试,用例的编写模式也不一样,单元测试更接近于代码的测试,测试人员不了解开发写的代码逻辑和设计,所以测试代码必须是开发来完成的,如果是测试写的代码,必定会问题百出。
2、前端单元测试虽然也需要接口,但是和后端接口测试不一样;接口测试围绕业务逻辑,不需要关注代码是怎么写的;前端代码包含交互逻辑,测试需要花更多精力。
3、根本上还是需要UED开放接口和方法,而现在UED的代码存在很多不可测试的情况。
4、测试职位上优势,可以驱动开发做单元测试。
如果执行人角色是前端开发,会遇到哪些问题?怎么解决?
答:1、开发写测试代码,是一个习惯和意识的问题,长期以来前端开发都不写测试代码,
2、没有一套完成的前端测试系统来使用,需要我们来慢慢引导开发,潜移默化的影响他们的编码意识;
3、开发会有一些学习成本,不过不会很大,学习如何编写测试脚本,需要接受我们的语法。
前端UI测试所能解决的问题:(这段转的)
如:
1) [HTML] 元素节点是否输出完整,比如.site-nav,
.login-info, .quick-menu 等元素是否存在
2) [HTML] 网站导航浮出层异步接口输出的内容是否符合预期
3) [CSS} 页头高度,颜色值等CSS属性是否符合预期,是否有被页面其他CSS 覆盖掉
4) [JS] 登录信息是否正确输出,模拟Cookie 值进行测试
5) [JS] 浮出层是否能浮出以及浮出后展现是否正常
6) [JS] 搜索功能是否正常
7) 等等….
选择不同的浏览器(IE不同版本对应不同机器)执行,可进行兼容性测试。
分享到:
相关推荐
【作品名称】:泰迪杯 : 基于 python 实现 运输车辆安全驾驶行为的分析 【适用人群】:适用于希望学习不同技术领域的小白或进阶学习者。可作为毕设项目、课程设计、大作业、工程实训或初期项目立项。 【项目介绍】: 在车辆运输过程中,不良驾驶行为主要包括疲劳驾驶、急加速、急减速、怠速预热、 超长怠速、熄火滑行、超速、急变道等。 针对以上运输车辆的不良驾驶行为,给出不同不良驾驶行为的判别标准,行车安全评价模型如下: 疲劳驾驶:连续行车时间超过4小时。 提取数据思路:若某一行acc_state列值为1并且gps_speed列数值大于0,则认为汽车开始启动,继续扫描数据表,直到寻找到一行gps_speed列的数值为0,则认为汽车已经处于停止状态,再根据location_time列由两个数据获取时间间隔,判断是否属于疲劳驾驶。 急加速、急减速:每两个经纬度间汽车的加速度达到或者超过20km/s^2。两个经纬度间汽车的加速 【资源声明】:本资源作为“参考资料”而不是“定制需求”,代码只能作为参考,不能完全复制照搬。需要有一定的基础看懂代码,自行调试代码并解决报错,能自行添加功能修改代码。
基于springboot的校园社交平台源码数据库文档.zip
scipy-1.7.1-cp37-cp37m-linux_armv7l.whl
java源码资源EJB 模拟银行ATM流程及操作源代码提取方式是百度网盘分享地址
pillow-11.0.0-cp39-cp39-linux_armv7l.whl
java面试视频资源微服务架构之Spring Cloud Eureka 场景分析与实战提取方式是百度网盘分享地址
基于springboot+vue的音乐播放系统源码数据库文档.zip
matplotlib-3.5.0-cp37-cp37m-linux_armv7l.whl
onnxruntime-1.16.2-cp311-cp311-win_amd64.whl
基于springboot复兴村医疗管理系统源码数据库文档.zip
环境说明: 开发软件:VS 2017 (版本2017以上即可,不能低于2017) 数据库:SqlServer2008r2(数据库版本无限制,都可以导入) 开发模式:mvc
onnxruntime-win-x64-gpu-1.19.2.zip
bimdata_api_client-4.0.7-py3-none-any.whl
基于springboot的实验室开放管理系统源码数据库文档.zip
Pillow-9.2.0-cp39-cp39-linux_armv7l.whl
STM32神舟III号例程源码STM32芯片按键点灯-无防抖(STM32神舟III号-寄存器版)提取方式是百度网盘分享地址
基于springboot医疗废物管理系统源码数据库文档.zip
基于springboot的车辆保险理赔平台源码数据库文档.zip