尽管关于测试驱动开发(TDD)的书和文章有成百上千之多,仍然有很多人从未感受过测试的强大力量。 之所以不愿意去写测试程序不外乎有以下几个理由: 1. 太费时间。 2. 不值得。 3. 我很懒。 4. 我不知道如何做。 5. 我知道我的程序好用,我运行过一次,没出问题。 6. 我是超人,我从来不犯错误。 除非你的答案是6.(如果是这样,我很羡慕你),否则,你应该继续读下去。 让我们从一个简单的例子开始。就说你要写一个Email地址校验程序。你也许会使用正则表达式,或手工实现每个字符的对比,来完成这个任务。 现在你想验证一下你的代码是否有效。你会怎么做?你可以手工输入不同的值来验证它是否符合你的要求,结果你就测试了像下面的这些东西: 如果你要改变/调整校验算法会发生什么?你需要把之前所有的过程全部重复一遍,把每个值都再输入一遍,看看校验的结果。如果让计算机自动的帮你校验这些是不是会更好些呢? 通过把测试过程自动化,你可以在任何时候对程序进行任何遍次的测试。这不仅仅在以后会节省你大量的时间,而且会增加你的自信心,因为每次当你感觉到程序可能出错时,只要运行一下你的测试程序,看看测试结果就行了。 现在设想一下你正在编写一个更加复杂的程序,比如XML解析器。你不可能编写出解析器后不去测试它,问题是,你如何测试它?通常,你会创建一个XML样板文件,把它输入解析器里,手工检查解析的结果。当你看到解析器按照要求输出了你期望的结果后,你确信你完成了任务,解析器没问题。 问题就在于如果你发现了一个Bug。那你就需要去修改你的代码,再验证一次它是否好用。可是我们程序员都是一群懒人,我们会只测试我们遇到的这个Bug,几乎从来不会去测试解析器的其它部分。这会产生什么问题呢?你能确保没有把什么东西改坏? 当你写了单元测试程序后,这个工作流程会变的怎样?首先,你已经对程序进行过测试,之前你必须对每个函数进行手工的测试,手工的检查输出结果。如果这种事情你只需要做一次,那也没什么了,但当有东西出错时,你不想一遍一遍的重复做这个事情,没有人喜欢来回重复的做相同的事情,特别是无聊的事情。 另一种情况,你为你的解析器里的每个功能都写了自动测试程序。在这个例子中,你已经测试过你的程序,对这个过程你并不陌生。你需要做的是把手工的检查改为assertions,它们会为你自动测试程序。 当Bug出现时,巨大的变化发生了。如果没有自动化测试,你必须手工的检查所有的东西来确保你在修正一个Bug时不会引入其它的错误。当有数个Bug出现时,你会变得极不耐烦,你开始 不再检查其它部分的代码,只关注你的这个Bug。但假如你为程序写好了自动化测试,你唯一要做的就是点击一次按钮,让所有的测试程序运行起来,你马上就能 看到测试结果,几乎不需要在其它任何事情。 当有了测试程序后,修改Bug是怎样进行的?首先,你需要重现这个Bug。无论如何,在你修改前,你必须要认定这个Bug是否真实的存在。如何做到这些?你要写出一个测试用例来重现这个bug,这个必须要在你做任何的修改这个bug的工作之前完成。 如果这个bug不能重现,问题就可能出自其它地方,如果不能用自动化测试来重现这个bug,你可能在错误的地方修改了这个bug,很可能改坏了你的程序。当你写出测试程序,你必须先运行它确保它会失败。如果测试没有失败,什么地方可能出了问题,你没能正确的重现它。 当你修改了这个Bug,你也有了针对它的测试程序,你可以立即发现这个bug是否还会出现。 当你这时又发现另外一个bug时该怎么做?相同的做法。写一个测试程序,重现这个bug。即使你没有时间来立即修正这个bug或者这不是个致命的bug,你也应该有个能够让它重现的测试程序,当日后你回来解决这个问题时,你就能知道该做什么了。 自动化测试平台TestBird,最初是从手游测试开始起步,在手游圈积累起很高的知名度,目前也已向APP测试领域进军,同时TestBird也加入了智能硬件的测试领域。不仅如此,TestBird还建立了云手机、云测试和云分析三大测试平台,通过自助App功能测试、远程真机调试、真机兼容性测试、真人体验测试、 真人压力测试和崩溃分析等产品,为移动应用提供从研发到上线再到运营的一站式质量管理服务,帮助移动应用企业建立完善的质量管理体系,全面提高移动应用的DAU、留存率以及付费情况。 部分文字来源:测试窝
|