我过去曾经在一家只有几个人创业公司工作,当时我做的是 Android 开发,当时我开发出来的 App 有非常多的 Bug ,怎么点怎么闪退,修好了旧的 Bug 又多出来一个新的 Bug

在这家公司工作的压力很大,没做多久就走了。离开这家公司后我就一直在想,为什么自己做的软件有这么多 Bug ,然后我看了很多软件开发相关的书。而这些书里面,讲怎么避免 Bug 的主题主要有单元测试测试驱动开发,所以我看了很多相关的书。

测试驱动开发主要有两个好处,一是自动验证写出来的代码是否满足需求,二是持续为业务需求和软件设计的变化保驾护航

一般的软件开发流程是设计—开发—测试,而测试驱动开发的流程则是编写测试代码—开发—持续优化设计

如果你想定制一款软件,那就要找一家懂得测试驱动开发的软件开发团队,否则除非你找到非常顶尖的,思维非常缜密的软件开发人才或团队,否则的话等待你的就是无尽的 Bug 。所谓的 Bug ,指的是软件缺陷,比如你在 App 上点了一个按钮后,App 就退出了,又或者是应该显示 3 的地方,显示成了 30 。

Bug 多有什么影响呢?假如你让一个团队帮你开发一款软件,他们说要三个月,开发完之后,Bug 太多,修了 6 个月,最后才拿出了一个相对稳定一些的版本。假如说这 6 个月他们还要你出钱,那就相当于是你的成本是原来的三倍。就算他们不要钱,时间也是非常宝贵的资源啊,钱没了还能赚,时间没了可就回不来了。

如果一个软件开发团队懂得测试驱动开发,那开发出来的软件质量的下限不会太低。所谓的测试驱动开发,就是在写生产代码前,先写测试代码,然后再不断地重构代码,能不断优化代码。就像是上学时候的考试,对于新知识,我们怎么知道自己学会没有?唯一的证明办法就是考试,在需要的时候能用新知识解决各种各样的问题,这才算是掌握了新知识。

对于程序员写代码也是一样的,在写生产代码前,先写测试代码,这样在写完代码后,就知道写出来的代码到底有没有解决问题,满不满足业务需求。

单元测试除了能验证写出来的代码是否满足需求,而且还能在代码修改后保护原有功能不受破坏,就像手机壳保护手机一样,不怕摔。修改代码的常见原有两个,一是因为需求方一拿到产品后,几乎立马就能想到更好的软件交互方式,又或者是更好的功能设计。二是软件开发团队随着时间的推移,也会找到一种能更好地满足业务需求的软件设计。这两种情况是经常会出现的,所以就需要单元测试持续为这种变化保驾护航。

假如没有单元测试,那么软件开发团队可能会在发现代码有问题的时候,不敢去修改代码,因为怕修改代码后出现 Bug 后被客户责怪,但是有问题的不改的话,相当于是鸵鸟心态,软件中有可能出问题的地方几乎一定会出问题,只是快慢不同。

单元测试的还有一个特点,就是能自动执行,与自动执行测试相对的是手工测试,所谓的手工测试,如果测试的是 App
的话,那其实就是用手点点点,大概看下有没有什么问题,有没有闪退什么的。在用手点一点,用眼睛看看这种简单的事情上,人是肯定比不过电脑的。

虽然手工背后也有一套测试理论,但是手工测试人员的门槛非常低,差的可能根本连什么是软件都搞不清楚。而大多数的软件公司由于招不起技术好的测试工程师,又或者是不重视交付的软件质量,所以招的一般也是比较差的手工测试人员,导致软件测试效率低,交付的软件质量非常低,到了用户手上后还是有非常多的 Bug 。

而单元测试就不一样了,单元测试可以在每次软件更新后都把整个软件自动测试一遍,效率非常高,测试的过程不需要人工参与,工程师要做的是在写代码前建立测试,建立好了之后就能一键测试,可以说是一劳永逸。在执行效率上,手工测试和单元测试比起来,就像是马车和汽车相比,一百头马都比不上一辆汽车。

综上所述,如果你想定制一款软件,尽量找懂得测试驱动开发的软件团队。

余下全文(1/3)

本文最初发表在wkee.net,文章内容属作者个人观点,不代表本站立场。

分享这篇文章:

请关注我们:

《为什么大多数定制软件的 Bug 很多?》有1个想法

  1. admin  这篇文章, 并对这篇文章的反应是俺的神呀赞一个

发表评论

邮箱地址不会被公开。 必填项已用*标注