前端测试的思考
?
?
淘宝前端单元测试现状？
答：淘宝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不同版本对应不同机器）执行，可进行兼容性测试。
