个人程序没问题，测试只是一件浪费时间的事

让咱们详细地说明

做为开发人员，咱们都知道咱们应该测试咱们的代码。咱们应该写单元测试，但这也一般是咱们发现没时间时跳过的第一步。
做为团队的领导者或者管理者咱们都知道测试是必要的，可是当截止日期临近的时候，咱们倾向于减小测试，而把更多的重点放到编码上。
这样看测试领域彷佛很紧张。咱们都知道测试对咱们是有利的，可是一旦项目面临压力时咱们就再也不测试了。

咱们为何测试?

Edsger W Dijkstra 说过:测试能够用来找到显式的缺陷（bug），可是没法显示潜伏的软件缺陷（bug）。
这意味着测试不能百分百保证你的软件没有缺陷（bug），可是它确实颇有帮助。咱们也能够换种说法，若是咱们不进行测试咱们几乎能够百分百保证咱们的软件会有缺陷（bug），除非咱们是在编写像“hello world！”那样简单的程序。可是即便这么简单的程序你也会测试，由于一旦你输入完你的代码你就会很好奇它的输出是否是真的是“hello world！”。
而这就是第一类形式的测试，也是咱们一直在作的: 手工测试. 咱们编写程序，而后启动它去检验运行结果。 对于一个简单的“hello world”这多是足够的，可是对于复杂度更高的程序这可能会致使时间的浪费，这是对一个已知的行为结果集的手工重复。这难道不是咱们发明计算机的初衷吗?
对于“hello world”这不是大问题，可是当你建立一个web应用时，测试场景是在翻页十次，点击某些按钮，在大量表单中输入（正确的）数据以后再测试某些特定条件，你就看到自动化会节省大量的时间。若是你能经过测试运行器（test runner）直接执行你想要测试的函数，而不是必须花费半分钟手工执行到那个函数，你会节省不少时间！
但这也意味着咱们须要多一点点编程，而更多的编程意味着更多的时间和精力。因此它会花费更多的时间而你的项目可能所以完工的晚些。

也许未必

让咱们建立一个控制台应用程序来计算最大公约数(GCD)的两个整数。有不少方法能够解决这个问题，但为简单起见，咱们将

• 输入两个整数

• 无论其算法怎么样，计算一下 GCD

• 显示输出

• 让咱们浏览一下正常的开发周期。咱们一般写一个 main() 函数，获得了两个整数，以及调用一个函数来计算一 下GCD，而后显示结果。

测试。在你的控制台中输入 2 个整数会花一些时间，这将变得至关无聊，若是你须要屡次重复你的代码。这也很容易在控制台应用程序中输入出错，致使程序崩溃。这意味着你必须从新启动程序，输入两位数，而后再次验证结果。请你要记住，咱们讨论的是一个控制台应用程序，只须要两个输入值，不须要点击(在 web 应用程序中)，咱们已经看到，这将须要花费一些时间。
而后，咱们极可能会想要测试一些更多意味着重启程序的值，进入两位数（正确地），而后测试。。。因此咱们即便看到也不会当即这样作，由于它要花费太多的时间。Edge 案例将会被遗忘，错误只会在生产中被发现！
此外，当咱们改变一些咱们须要再次运行全部的测试(手动)，使用一个被遗忘的，或者使用快捷键的高风险的测试。
在那儿，不会有跟踪咱们的测试工做。不写入日志文件，在整个测试期间，除非你增长这个你作的事情列表工做(手动)。

消极反馈循环

一般，当项目（由于某种缘由）延期了，则容易陷入一种消极反馈循环。有时咱们会先决定跳过编写测试代码，而这则会形成状况以下图所示：

项目延期，形成咱们不得不去编写更多的代码。因此与其“浪费时间”去不停地测试代码，不如不停地去开发项目。而这样作的结果就是代码质量进一步降低，并最终（或早或晚）致使返工。返工又一般会在最有限的时间里变得十分紧急（有些人叫这种现象为“墨菲是个乐天派！”）。其实返工什么也改变不了，项目如今只会进一步被延迟。很奇怪吧，咱们编写越多的代码，咱们的项目完工越晚。一种经常使用应对措施是让更多的开发人员被参与到项目的研发中，然而这样的做用也只是加重消极反馈循环而已。
若项目缺少测试，在验收和生产环境时，一般用户则会发现许多 bug，这将会快速地下降用户对项目的信任度，从而产生消极反馈。这种反馈传递给（工做过分的）开发人员，就形成开发人员“疲劳”现象。后果就是开发人员工做积极性降低，开发人员离职，……，项目又进一步延迟了。

打破消极循环

我想你已经想到有一个办法能够解决这种现象。让咱们来绘制一幅不一样的场景：

咱们能够从一个理想计划“项目按时完工”开始。咱们开发代码，而后当即测试它。测试最好是自动化（编码实现）的，这样咱们能够轻松有效的去执行它们。咱们把开发和测试紧密的结合在一块儿，每一个开发测试循环能够很快速的执行。当一个开发测试循环结束时咱们有信心保证代码质量是很高的，由于它已经经过了测试。并且用户由于发现缺陷（bug）的数目变少而对咱们继续高度信任。即便他们发现了一个缺陷（这依然是有可能的），咱们也能够扩充咱们的测试集合，去避免相关缺陷的重现。
如此下去，返工将再也不是必须的，项目得有继续。
若是咱们的项目已经延期了，就须要咱们花些时间来采用这种方法论。对新功能的冻结也许是必须的。中止开发新的代码，取而代之去为最严重的（恼人的－清晰的－高代价的）缺陷编写测试。
项目延期的状况下再去为你完整的代码库编写测试是不可行的，只针对其中的一些部分就能够，不要去浪费你的时间。可是要记住其它部分也仍是须要编写测试的。我在这种状况下会去找出最严重的问题（划分优先级），而后为它们编写测试。以后“快速”修改代码就会变的更容易，而且能够保证在修改其余部分是它不会出错。自动化测试能够很频繁的执行，从而下降了缺陷（bug）重现的风险。好了，如今能够开始去有效的强健咱们项目了
上面这些一般会要求进行代码重构，从而使它可测试化。我会在另外一篇文章里介绍它。

总结

大部分的项目中，会考虑测试和编码之间的平衡。不过我但愿你们都能清楚，测试实际上是项目的加速器，而不是在浪费时间。

关于TestBird：TestBird可以提供真机兼容性测试、真人体验测试、真人压力测试。与腾讯、网易等5500多家游戏厂商创建合做关系，测试手游超过16000款，占据手游行业70%以上份额。

TestBird真机测试平台（测试帐号免费注册）

• 已经拥有2000多款全球热门机型，覆盖市面上95%以上人群；

• 真人体验测试：已经吸引40000多名高品质玩家，供开发者进行游戏玩法体验调研；

• 真人服务器压力测试：基于TestBird已有的40000多名真实玩家，为开发者提供多人在线服务器压力测试；

• 云手机：基于云端2000+真实手机，可供开发者远程使用。方便调试BUG、应用演示、游戏在线试玩等。

测试愉快！

英文原文：codeproject.com