当前位置: 首页 > 互联网 > 正文

试着去写测试案例

工作近十年了,也就是说快写了近十年的代码了。我承认之前的九年没有为自己的代码写过任何的测试脚本,或者是任何形式的测试案例。每次穿梭于书店或是网上博客等,我对单元测试,或是诸如自动化测试都十分的不屑。“代码要紧”,“完成工作要紧”这是我当年的信条。虽然我认同自己的开发习惯还是不错,编码风格也挺赞的,但自从阅读了一本名为《测试驱动开发》的书后,才发现以测试为驱动的开发过程的确是对人们自认为的开发过程的一种颠覆。无法完全的说明哪种方式的好与坏,但编写测试案例,写单元测试确实给我带来了不同的思考,并认为这是非常有必要,也会为之努力而实践的。

编写测试案例,让我们更细致的去分析问题。计算机对代码的执行不会欺骗任何人,我们开发代码的过程中总是力争将所有的点和面都考虑到,将所有可能的情况都涉及到。所以有必要模拟各种可能的场景去测试每一个细小的环节。而这个细小的环节就是我们程序中的小小单元,对一个个小小单元的全方位测试,才能力促整个程序逻辑的完整测试。所以单元测试是整个程序测试的根基,是实际业务的问题点,逻辑点。将复杂的问题分析到点,测试到点,会有助于我们在编写代码的时候理清关系,将点组成线,从而组装成整个程序。

编写测试案例,让我们更好的去重构程序。测试案例能为整个程序的正确性奠定了一个基调,任何可能的修改都不能违背单元测试的正确通过。而同样的有了测试案例,相关开发人员,可以快速方便的通过测试案例理解程序和代码的运行过程。同样的,对完美代码的无限追求下所做的改动,也能保证所做的代码重构没有改变原有程序的正确性。也不用过分的担忧代码结构的调整会造成严重的逻辑的错误,而这些错误的改动却没有被发现。当然,这里有一个前提条件,就是我们要适时的去维护我们的测试案例,并要保证我们的测试案例本身就是经得起验证并且是正确的,否则,上面所说的一切将都是不成立的。

测试案例的编写,能帮助我们快速熟悉业务,甚至可以帮助我们提炼出程序的运行过程,制定合理的程序框架。让我们在修改代码的时候,不易更改原有的逻辑,不会去污染原有的代码。可以提高我们写代码的正确率。能更好的服务系统维护,二次开发等等。说了这么多的测试案例的好处,但只有尝试和运用,你才会有这样的体会。也许一开时你会觉得写测试案例是如何的无聊和重复。但当你看一段没有测试案例的代码时,你又会感到无奈无助,更会为在这段代码上进行的修改或二次开发而感到不安。但肯定会为有相应的测试案例而暗暗叫好,并会为一段代码补上测试案例而开心不已。测试案例就好比前人栽树,后人乘凉。

那么问题来了,测试案例怎么写?

测试案例应该全面但不重复的,我们应该尽可能覆盖所有的程序代码,但我们不必为代码写重复的测试案例。测试案例应该简单明了,让人一眼就能看明白。你不必纠结英文怎么翻译,你甚至可以简单的就用中文的类和中文的方法名称来表示这个测试案例的含义,甚至可能是测试的目标名称(但我反对在生产代码里用中文,甚至包括中文拼音)。测试案例往往是并列的,列表状的,所以你能一眼看到测试的结果和未通过的测试内容,方便查找和定位。当然,你还要有好的测试工具,测试包之类的。最后也往往是最重要的是保证你的测试案例是最新最完整的。

测试案例看起来像是开发过程中的一个负担,但这只是你没有从根本上去发现测试的魅力和益处。只有你潜心下来去做,去完善你的单元测试,久而久之,你会发现,测试真的很美。

本文固定链接: http://www.byhard.com/?p=1563 | 海纳百川

该日志由 byhard 于2016年06月21日发表在 互联网 分类下,
原创文章转载请注明: 试着去写测试案例 | 海纳百川
关键字: ,
【上一篇】
【下一篇】

试着去写测试案例:目前有4 条留言

  1. 地板
    增达信购:

    虚心学习!!

    2016-06-28 16:35
  2. 板凳
    蒂欧娜:

    我就是随便看看!

    2016-06-30 15:01
  3. 沙发
    767197725:

    如果有一天,我潇洒死去,请记得,我来过这里!

    2016-07-05 09:53
    • 希望我的博客能坚持到那么久,加油。

      2016-07-15 09:51