请选择行业
请选择职位
请选择省份
请选择城市

下次他们说“不用测试”,你就这样跟他说

时间: 2015-02-04 13:31   作者: 51Testing软件测试网采编   点击次数: 
 

  尽管关于测试驱动开发(TDD)的书和文章有成百上千之多,仍然有很多人从未感受过测试的强大力量。

  之所以不愿意去写测试程序不外乎有以下几个理由:

  1.太费时间。

  2.不值得。

  3.我很懒。

  4.我不知道如何做。

  5.我知道我的程序好用,我运行过一次,没出问题。

  6.我是超人,我从来不犯错误。

  除非你的答案是6.(如果是这样,我很羡慕你),否则,你应该继续读下去。

  让我们从一个简单的例子开始。就说你要写一个Email地址校验程序。

  你也许会使用正则表达式,或手工实现每个字符的对比,来完成这个任务。

  现在你想验证一下你的代码是否有效。你会怎么做?你可以手工输入不同的值来验证它是否符合你的要求,结果你就测试了像下面的这些东西:

  foo

  foo@bar

  foo@bar.baz

  ...

  如果你要改变/调整校验算法会发生什么?你需要把之前所有的过程全部重复一遍,把每个值都再输入一遍,看看校验的结果。如果让计算机自动的帮你校验这些是不是会更好些呢?

  通过把测试过程自动化,你可以在任何时候对程序进行任何遍次的测试。这不仅仅在以后会节省你大量的时间,而且会增加你的自信心,因为每次当你感觉到程序可能出错时,只要运行一下你的测试程序,看看测试结果就行了。

  现在设想一下你正在编写一个更加复杂的程序,比如XML解析器。

  你不可能编写出解析器后不去测试它,问题是,你如何测试它?通常,你会创建一个XML样板文件,把它输入解析器里,手工检查解析的结果。当你看到解析器按照要求输出了你期望的结果后,你确信你完成了任务,解析器没问题。

  问题就在于如果你发现了一个Bug。那你就需要去修改你的代码,再验证一次它是否好用。可是我们程序员都是一群懒人,我们会只测试我们遇到的这个Bug,几乎从来不会去测试解析器的其它部分。这会产生什么问题呢?你能确保没有把什么东西改坏?

  当你写了单元测试程序后,这个工作流程会变的怎样?

  首先,你已经对程序进行过测试,之前你必须对每个函数进行手工的测试,手工的检查输出结果。如果这种事情你只需要做一次,那也没什么了,但当有东西出错时,你不想一遍一遍的重复做这个事情,没有人喜欢来回重复的做相同的事情,特别是无聊的事情。

  另一种情况,你为你的解析器里的每个功能都写了自动测试程序。在这个例子中,你已经测试过你的程序,对这个过程你并不陌生。你需要做的是把手工的检查改为assertions,它们会为你自动测试程序。

  当Bug出现时,巨大的变化发生了。

  如果没有自动化测试,你必须手工的检查所有的东西来确保你在修正一个Bug时不会引入其它的错误。当有数个Bug出现时,你会变得极不耐烦,你开始不再检查其它部分的代码,只关注你的这个Bug。但假如你为程序写好了自动化测试,你唯一要做的就是点击一次按钮,让所有的测试程序运行起来,你马上就能看到测试结果,几乎不需要在其它任何事情。

  当有了测试程序后,修改Bug是怎样进行的?

  首先,你需要重现这个Bug。无论如何,在你修改前,你必须要认定这个Bug是否真实的存在。如何做到这些?你要写出一个测试用例来重现这个bug,这个必须要在你做任何的修改这个bug的工作之前完成。

  如果这个bug不能重现,问题就可能出自其它地方,如果不能用自动化测试来重现这个bug,你可能在错误的地方修改了这个bug,很可能改坏了你的程序。当你写出测试程序,你必须先运行它确保它会失败。如果测试没有失败,什么地方可能出了问题,你没能正确的重现它。

  当你修改了这个Bug,你也有了针对它的测试程序,你可以立即发现这个bug是否还会出现。

  当你这时又发现另外一个bug时该怎么做?

  相同的做法。写一个测试程序,重现这个bug。即使你没有时间来立即修正这个bug或者这不是个致命的bug,你也应该有个能够让它重现的测试程序,当日后你回来解决这个问题时,你就能知道该做什么了。

打印本页 | 加入收藏

上一篇:跳槽和薪酬谈判的注意事项    

关闭  
主要城市: 北京 上海 杭州 广州 南京 武汉 长沙
全部城市: