网站测试是要跟大量的前端代码打交道，要跟各种恶心的浏览器打交道，要怎么样才能出淤泥而臭美呢？诀窍一就在于善于利用各种工具来引导工程师写出优美的代码来，本篇就讲述一个笔者最近刚新鲜出炉的一个工具 jsaudit

1. 网站前端代码扫描工具
综述
栗志果

2. 前端扫描工具能做什么？
• 代码规范检查
• 潜在错误检查
• 浏览器兼容性检查
• 安全漏洞检查

3. 一 代码规范检查
• [fatal] 关键字和保留字不能作为变量名
• [error] 所有语句结束带上分号
• [error] 3个条件及以上的条件语句用switch代替if else
• [skip] 正确的缩进，最小缩进单位为4个空格
• [skip] 方法、变量都使用驼峰命名，类使用大驼峰
(Pascal)命名
• [skip] 非特殊原因必须使用YUI，
addClass/removeClass/getRegion例外

4. 二 潜在错误检查
• Bitwise —避免在js中使用位操作符
• Eqeqeq—推荐使用=== 以及!==
• Forin — 循环中要对元素有效性做检查
• Plusplus—禁用++, --操作符等
• Regexp – 在正则表达式中禁用.操作
• Strict– 要求函数符合EcmaScript 5's strict
mode

5. 三 浏览器兼容性检查
• 在 Firefox 中注释内容中如果包含 '-' 字符在某些情况
下会使该注释解析错误
• Chrome 和 Safari 中标签紧密相邻的行内元素在折行
显示时存在错误
• IE6 IE7 IE8(Q) 会忽略 OBJECT 和 IFRAME 标签之后的
空白符
• Safari Chrome 中用 for in 可以遍历出 Date Array
String 对象中被更新的原型方法
• 各浏览器中 Date 对象的 toLocalString 方法的返回值
不一致
• IE6 IE7 IE8(Q) 不支持 JSON 对象

6. 代码扫描要不要做
• 效果和代价的问题
• 效果
– 自动化扫描显著减少人工代码审核的工作量
– 在开发阶段就能发现规避错误
• 代价
– 配置和使用代码扫描工具的代价
– 修复扫描出来问题的代价
– 整合扫描工具的代价（可选）

7. 代码扫描要怎么做
• 现在的做法
– 目前中文站采用自主开发的fdlint 做代码扫描
– 业界采用jshint比较多
– 浏览器兼容性上多采用 Compability detector
• 现在推荐的做法
在开发阶段使用jshint自动语法提示，代码提交前用fdlint
在做扫描，以及compabitlity detector兼容性检查
• 将来的做法
整合到一个工具里，在开发环境中做得自动语法提示

8. 附录
• Fdlint
– 中文站自主开发的前端静态扫描工具
– DSL的扫描规则，相比来说最容易维护和定制
– ruby 开发，同时支持html css 以及javascript
– 缺点是不太稳定（notepad上揑件试用时crash
过两次），目前还不能做到开发过程中语法提
醒，不提供规则的配置管理界面

10. • Jshint(http://www.jshint.com/)
– 用Pratt parser 高效javascript扫描工具，
– 定制方便，上手极快
– 规则可扩展
– 稳定
– 缺点是添加新的规则比较难，另外叧是针对
javascript的

13. • Compatibility
detector(https://code.google.com/p/co
mpatibility-detector/)
– 通过 动态代码检测在早期发现代码的浏览器兼
容性问题，个人评价目前最靠谱的兼容性问题
解决方案
– 目前有40多条规则，有chrome和Firefox揑件
可用

15. • Jsaudit
(https://github.com/pop2008/jsaudit)
基于jshint的前端代码静态扫描工具，能够
对潜在错误，编码准则以及兼容性问题进
行扫描。是第一个也是目前为止唯一一
个对能够对JavaScript兼容性问题进行静
态扫描的工具

16. 自动化测试之美
www.webautotest.com