Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

测试驱动的前端开发初探

1,315 views

Published on

前端自动化UI测试实践,TDD简介

Published in: Technology
  • Be the first to comment

测试驱动的前端开发初探

  1. 1. 测试驱动的前端开发 & 前端自动化测试实践
  2. 2. About me... ● Flash Actionscript Developer ● 写一点点 JS ● Ruby 粉丝 ● 最爱 web applications ● 研究 / 开发各种工具 ● 目前在架构组,负责前端开 发的工具支持
  3. 3. 曾经 ... ● 前端是一片未开垦的 自由大陆 ● 我们是第一代前端开 发工程师
  4. 4. 我们无所畏惧● 并引以为豪● 就像他们
  5. 5. Orville Wright & Wilbur Wright 1903
  6. 6. 时间推移 ● 客户端的功能越来越 强 ● Web 体验越来越好
  7. 7. 同时,我们还关注 ...● 减少带宽流量 ● 提升 Web 性 ● 如何在各种设备上 有一致的良好体验● 减轻服务器压力 能,进而提升 减少跨设备的迁移 懒加载,仅加载当 客户转化率 ●● 前最需要的数据 成本 MONEY
  8. 8. Now happening
  9. 9. 我们在这里 ● ?
  10. 10. 挑战 ● 开发的复杂度增加 ● 设备兼容难度增加 ● 质量要求更高了 ● 效率要求更高了
  11. 11. 我们准备好了吗?
  12. 12. Part II.前端开发之痛
  13. 13. 同一个功能要在多种浏 改了 A 页面功能却造成了● 览器中测试 ● 文档总是没法 ● B 页面的故障● 同样的流程要手工进行 及时随代码更 ● 开发充满危机感,不敢放 心重构 很多次 新 ● 维护成为沉重的负担● 浏览器版本更新,不断 有新的浏览器加入 ● 被咬了才知道
  14. 14. 测试的烦恼 ● 同一个功能要在多种 浏览器中测试 ● 同样的流程要手工进 行很多次 ● 浏览器版本更新,不 断有新的浏览器加入
  15. 15. 解决方案思考● 增加测试资源投入 ● 自动化 UI 测试 ● 简单有效 ● 成本更低 ● 不能面面俱到 ● 便于维护 ● 测试有难度 ● 工具不成熟
  16. 16. 从手工测试到自动化测试
  17. 17. Level 1● 操作,肉眼检查结果是否正确
  18. 18. Level 2● 操作,用 alert/console.log/$.log 检查输出结果
  19. 19. Level 3● 将操作编写为脚本, 模拟手工操作或模拟 操作的结果● Console.log● 手工打开浏览器
  20. 20. Level 4● 操作脚本 + 测试框架● 手工打开浏览器
  21. 21. Level 5● 用脚本模拟操作● 脚本自动打开浏览器● 脚本自动处理测试结 果
  22. 22. Zombie.js 实践
  23. 23. Zombie.js● Headless: 快速、无需真实浏览器● 基于 node.js● 模拟浏览器● 命令行方式运行
  24. 24. 安装● 安装 node.js● 安装 zombie.js ● npm install zombie
  25. 25. example
  26. 26. 遇到的问题● 适合 zombie.js 的测试框架 ● Jasmine / vows ?● 与真实浏览器有差异 ● Global scope ● Document.write● Ajax 数据模拟 ● Nock● 中文问题 ● Iconv
  27. 27. 难点● 大部分代码难以用 on page js 测试 ● 动画 ● 用户操作,如选择文件 ● 布局兼容性● 对策 ● 使用 MVC ,测试 Model 和 Control ● 用 js 测试“状态相关”的功能(单元测试) ● 用 ruby/selenium 测试“操作相关”的功能
  28. 28. 难点● Ajax 操作、 setTimeout 等异步功能● 对策 ● 主流的测试框架都已支持异步测试
  29. 29. 难点● 不同类型用户的构造 ● 诚信通用户 ● 炫旺铺用户 ● 手机认证用户 ● 支付宝实名认证用户 ● ……● 对策 ● 数据银行 ● 尝试用程序在 HTML 结构上反映用户类型
  30. 30. JSTestDriver
  31. 31. example
  32. 32. JSTestDriver● 建立一个服务器● 支持任意种类、数量的浏览器● 命令行运行● 并行测试,效率高● 可以很方便与持续集成 (CI) 系统集成● 有 IDE 插件● 提供代码覆盖率数据● 专注于 js 的测试,对 HTML 支持不好● 适合单元测试,不适合功能测试
  33. 33. 隐藏的危险 ● 文档总是没法及时随 代码更新 ● 被咬了才知道
  34. 34. 测试是很好,可是……● “ 写测试太花时间,项目时间太紧”● “ 功能很难测试”
  35. 35. 这是因为 没有测试驱动开发
  36. 36. TDD 的流程● 编写测试 ● 让测试编译通过,但 是测试失败● 重构代码 ● 让测试通过
  37. 37. 先写测试带来的好处● 迫使我们先思考 ● 哪些模块可以被测试 ● 怎么样分模块可以更容易维护功能和测试 – SRP ● 单一模块怎样设计可以方便测试 – 暴露 ajax 回调方法 – 完全分隔 MVC● 不断前进,成就感● 有测试保证质量,写的过程中可以随时重构
  38. 38. TDD 陷阱● “ 错误的文档还不如没有文档”● 不干净的测试脚本反而会增加维护成本
  39. 39. 如何写出好的测试
  40. 40. mocking & stubbing
  41. 41. 可读性● BDD 风格● 一个 test 方法只测试一个内容● 不断重构,优化
  42. 42. 测试脚本也是程序● 发现程序的 bug ,就 加入到测试脚本中
  43. 43. 维护的烦恼 ● 改了 A 页面功能却造 成了 B 页面的故障 ● 开发充满危机感,不 敢删代码、删文件… …放心重构 ● 维护成为沉重的负担
  44. 44. 持续集成
  45. 45. End● 不是为了分享,而是为了寻找支持● 前端 TDD 需要大家的努力● 前端质量 & 效率提升需要大家贡献● 希望有更多的人参与 TDD 实践,总结出更好的 经验● 不管其他人怎么评价 TDD ,去尝试一下
  46. 46. Thank you all!
  47. 47. Any questions?

×