为什么大多数定制软件的 Bug 很多？

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

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

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

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

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

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

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

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

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

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

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

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

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

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