首页 > 软件测试/ 正文
大话js代码静态检查
2012-09-18 15:20:14 ℃1、背景
首先必须承认,静态代码检查不能解决所有问题!比如说,QA不能指望着靠静态代码检查来发现rd的代码逻辑的bug。而对于javascript,可能就是代码某处少了个分号,或者是某些编码的bad –practice。这些问题可能很小很小,但是对用户体验足以造成巨大影响。因此,如果这种检查真的能发现问题,那么还是很有必要的。
之后的一个问题是成本:为了发现一个潜在的问题,我们要付出多少精力?静态检查给我们的印象是:飞速的扫描一遍代码然后返回一大堆信息——就像一个可能蕴藏金子的沙堆,我们必须有耐心才能在这个沙堆中找到有价值的信息。显然这一过程的成本由以下两部分组成:代码扫描+判别有效性。第一个过程往往十分迅速,秒级而已。而第二个过程往往需要人工的介入,这是成本消耗的关键点。试想,如果静态检查返回过多无用信息,导致人工检查耗时过长,则这种检查的收益就得不偿失了。
综上所述,静态代码检查面临的挑战是:准确性和低成本。
2、初识静态检查规则与工具
静态检查工具jslint&jshint
为了应对QA前端js知识储备不足的短板,我们除了加强自身的学习之外,一个有效的方法就是“站在巨人的肩膀上”。
1)jslint
前端领域的大牛Douglas Crockford编写了JsLint,将他认为的那些重要的js编程实践作为静态检查项,他提出的某些编程实践也确实被人们所接受,因为这确实是容易引起问题的关键点(例如,在应该使用===的地方不要使用==等)。不过JsLint也存在一些问题,如它的某些检查过于严苛;遇到for-in语句后会停止检测;且非开源。。这些问题都使得人们对JSLint“敬而远之”。
2)jshint
为解决jslint现存的问题,有了JSHint这个项目,此开源项目作为JSLint的一个分支,允许用户自定义检查项,使用起来更加轻量级。有了JSHint,程序员就可以根据自己的编程习惯来定制个性化的检查策略。文献[1] 讲述了JSHint与JSLint的区别。
JsHint本质上是一个js库(jshint.js)。笔者也曾膜拜此文件的代码,发现它实际上是一个js的词法分析器,里面定义了各种规则,然后对输入的代码字符串做切词和匹配,每发现一个“错误”(或是坏的编程实践)就放到结果数组中保存起来。因此,如果你会写js代码的话,完全可以在js文件中引用jshint.js。例如,你可以使用JSHINT函数来进行代码检查,如下所示:
var result = JSHINT(source, options);
其中JSHINT是一个全局函数,第一个参数source : 必选项。表示需要检查的代码,js或者json,可以传一个字符串或者一个数组。如果传字符串,需要用’\r’或者’\n’来分隔一行一行的代码;如果传数组,则每一个数组元素表示一行的代码。第二个参数option : 可选项。表示代码检查的配置项,具体的配置项含义参见文献[2],使用key/value字典表示,key就是要检查的配置项名称,value是bool类型。返回值:如果代码没有问题,JSHINT会返回一个true;否则返回false。当返回值是false的时候可以使用JSHINT.errors获取出错的原因,JSHINT.data包含了本次检查更详细的信息。另外,使用JSHINT.report可以生成错误信息的html报告。
认识检查规则
prop | description |
bitwise | 如果是true,则禁止使用位运算符 |
curly | 如果是true,则要求在if/while的模块时使用TAB结构 |
debug | 如果是true,则允许使用debugger的语句 |
eqeqeq | 如果是true,则要求在所有的比较时使用===和!== |
evil | 如果是true,则允许使用eval方法 |
forin | 如果是true,则不允许for in在没有hasOwnProperty时使用 |
maxerr | 默认是50。 表示多少错误时,jsLint停止分析代码 |
newcap | 如果是true,则构造函数必须大写 |
nopram | 如果是true,则不允许使用arguments.caller和arguments.callee |
nomen | 如果是true,则不允许在名称首部和尾部加下划线 |
onevar | 如果是true,则在一个函数中只能出现一次var |
passfail | 如果是true,则在遇到第一个错误的时候就终止 |
plusplus | 如果是true,则不允许使用++或者- -的操作 |
regexp | 如果是true,则正则中不允许使用.或者[^…] |
undef | 如果是ture,则所有的局部变量必须先声明之后才能使用 |
sub | 如果是true,则允许使用各种写法获取属性(一般使用.来获取一个对象的属性值) |
strict | 如果是true,则需要使用strict的用法, 详见http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/ |
white | 如果是true,则需要严格使用空格用法。 |
不足
牛人的东西很好,但实际使用起来发现有如下的问题:
(1)静态代码检查规则配置需要修改Jshint的Js源代码,修改代价较高,且容易出错;
(2)检查结果误报较多,且可读性差,找到真正是问题的结果需要排查几K的报错信息,效率较低。
- 上一篇:我的软件测试之旅:(5)难点——功能改进的测试
- 下一篇:基于代码的场景测试
更多郑州计算机学校什么课程好呢,郑州市计算机短期培训班,郑州北大青鸟什么专业好呢,郑州电脑编程培训多少钱,未来软件开发就业如何,郑州北大青鸟速成班相关文章
- Java如何实现网页程序自动登录
- 初步介绍自动化测试
- 如何测试一个印有广告的水杯?
- 关于接口测试
- 6年软件测试总结
- 一个简单的自动化测试架构的实现(C#)
- 软件测试的作用功不可没
- 自动化测试阶段和软件设计思考
- 敏捷测试现实与幻想
- 软件测试不是寻找Bug的游戏
- 在软件测试工作中体会成长
- 自动化软件测试推广经验分析总结
- 质量管理:IT项目计划中质量目标的确定
- 建立质量保证方法论的核心手段——要素有形化和无缝整合
- CMM的动机
- 实用SOA测试指南:测试流程起始步骤
- CMM流程之总结
- 软件项目质量管理实战总结(下)
- 软件测试中的风险因素识别
- 软件测试行业可以做多长时间呀?
- 软件开发各阶段的质量控制
- 软件测试过程中有哪些风险?
- 小议软件项目的管理
- 配Ivy Bridge 戴尔两款台式机5月上市
- 什么是网络传真
- 有关分区的那些事儿
- 手机储存卡真假识别宝典
- 输入法状态,也能玩“智能”
- 河南软件测试学校哪家比较靠谱
- 搜索
-
- 热门标签