执行步骤：

　　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不同版本对应不同机器）执行，可进行兼容性测试。