不同的目的对应不同的测试,测试包含了太多的内容,测试的方式也取决于你进行测试的目的。下面有几种测试方式,你可能会在你的应用中使用:
可用性测试
性能测试
稳定性性和回归测试
在本文中,会专注于稳定性和回归测试。换句话说,这类测试可以确保你的代码执行正确,并且不包含bug。在大部分情况下,绝对没有bug是不可能的。我们可以做的是采取一些有效措施来减少bug的数量,并且阻止老Bug的复现。
软件测试
通常你都是如何寻找bug的?
程序员通常都需要应付程序的验收和bug的修复。在过去,这样的任务差不多都是通过调用alert然后刷新浏览器来检查变量的值,或者观察脚本的执行是否和期望的一致。
现在,大部分浏览器内置一个强大的控制台工具。对于那些没有内置控制台的浏览器,你也可以使用含有类似功能的Firebug Lite。调试过程基本类似:在代码中调用console.log,刷新浏览器来观察结果是否和期望的一致。
断点调试
通过使用Firebug和一些类似的工具都可以轻易地实现对脚本的断点调试。但是大部分人还是认为console.log已经足够好用,特别是 和alert进行对比之后。确实,console不会阻塞UI,并且会让你觉得不需要太接近浏览器层面,但是它也只能做到如此。console.log调 试和alert调试法基本类似,有优雅之处,一样也有不优雅之处。
使用断点调试的时候,你可以设置一些断点,然后查看所有相关变量,而不需要把变量一个一个记录下来。
console.log带来的问题
console.log式调试有一些问题。首先,console.log本身可能会带来一些问题。如果你曾经忘记在 重要的demo或者部署中移除调试代码,你肯定知道我说的是什么。如果浏览器不支持console对象,代码就会报错,包括在没有打开firebug的 Firefox中。“但是JavaScript是灵活的”,你可能会这么说。“你可以自己定义一个没有操作的console对象,然后这些问题就解决 了”。确实,你可以这么做,但这就像是你通过刷一层油漆的方式来解决车子生锈的问题。
如果使用console.log的方式不可接受,那么我们马上就会意识到下一个问题:一旦一个调试策略已经定论, 你可以去掉所有的log语句。如果新的问题在同一处代码中出现,你还是回到了原来的方式,将原来美好的log语句重新引入。断点调试肯定是一个临时方案。 特设调试都是耗时,易于出错并且不可重复的解决方案。
举报/反馈