英文原文：
Is testing a waste of time?
让我们具体地阐明
作为开发职员，我们都晓得我们应当测试我们的代码。我们应当写单位测试，但这也凡是是我们发明没工夫时跳过的第一步。
作为团队的指导者或许治理者我们都晓得测试是需要的，可是当停止日期邻近的时分，我们偏向于减少测试，而把更多的重点放到编码上。
如许看测试范畴仿佛很严重。我们都晓得测试对我们是有益的，可是一旦项目面对压力时我们就不再测试了。
http://dilbert.com/strip/2010-08-21
我们为何测试?
Edsger W Dijkstra 说过:测试可以用来找到显式的缺点（bug），可是没法显示埋伏的软件缺点（bug）。
这意味着测试不克不及百分百包管你的软件没出缺陷（bug），可是它的确很有协助。我们也能够换种说法，假如我们不实行测试我们简直可以百分百包管我们的软件会出缺陷（bug），除非我们是在编写像“hello world！”那样容易的顺序。可是即便这么容易的顺序你也会测试，由于一旦你输出完你的代码你就会很猎奇它的输出是否是真的是“hello world！”。
而这就是第一类方式的测试，也是我们不断在做的: 手工测试. 我们编写顺序，然后启动它去查验运转后果。 关于一个容易的“hello world”这多是足够的，可是关于庞杂度更高的顺序这可能会招致工夫的糜费，这是对一个已知的行动后果集的手工反复。这莫非不是我们创造盘算机的初志吗?
关于“hello world”这不是大问题，可是当你创立一个web使用时，测试场景是在翻页十次，点击某些按钮，在大量表单中输出（准确的）数据以后再测试某些特定前提，你就看到主动化会节俭大量的工夫。假如你能经过测试运转器（test runner）间接履行你想要测试的函数，而不是必需破费半分钟手工履行到阿谁函数，你会节俭非常多工夫！
但这也意味着我们需求多一点点编程，而更多的编程意味着更多的工夫和精神。所以它会破费更多的工夫而你的项目可能因而竣工的晚些。
或许未必
让我们创立一个把持台使用顺序来盘算最至公约数(GCD)的两个整数。有非常多办法可以处理这个问题，但为容易起见，我们将
1.输出两个整数
2.不论其算法怎样，盘算一下 GCD
3.显示输出
让我们阅读一下正常的开发周期。我们凡是写一个 main() 函数，失掉了两个整数，和挪用一个函数来盘算一下 GCD，然后显示后果。
测试。在你的把持台中输出 2 个整数会花一些工夫，这将变得相当无聊，假如你需求屡次反复你的代码。这也很轻易在把持台使用顺序中输出犯错，招致顺序解体。这意味着你必需从头启动顺序，输出两位数，然后再次验证后果。请你要记着，我们会商的是一个把持台使用顺序，只需求两个输出值，不需求点击(在 web 使用顺序中)，我们曾经看到，这将需求破费一些工夫。
然后，我们极可能会想要测试一些更多意味侧重出发序的值，进入两位数（准确地），然后测试。。。所以我们即便看到也不会立刻如许做，由于它要破费太多的工夫。Edge 案例将会被遗忘，过错只会在生产中被发明！
另外，当我们改动一些我们需求再次运转一切的测试(手动)，运用一个被遗忘的，或许运用快捷键的高风险的测试。
在那儿，不会有跟踪我们的测试任务。不写入日记文件，在全部测试时期，除非你增加这个你做的工作列表任务(手动)。
消极反应轮回
凡是，当项目（由于某种缘由）延期了，则轻易堕入一种消极反应轮回。有时我们会先决议跳过编写测试代码，而这则会形成状况以下图所示：
项目延期，形成我们不能不去编写更多的代码。所以与其“糜费工夫”去不断地测试代码，不如不断地去开发项目。而如许做的后果就是代码质量进一步降落，并终极（或早或晚）招致返工。返工又凡是会在最有限的工夫里变得非常紧迫（有点人叫这类景象为“墨菲是个乐天派！”）。实在返工甚么也改动不了，项目如今只会进一步被延迟。很奇异吧，我们编写越多的代码，我们的项目竣工越晚。一种经常使用应对办法是让更多的开发职员被介入到项目标研发中，但是如许的用处也执偾加重消极反应轮回罢了。
若项目缺少测试，在验收和生产情况时，凡是用户则会发明很多 bug，这将会疾速地下降用户对项目标信赖度，从而发生消极反应。这类反应通报给（任务过分的）开发职员，就形成开发职员“疲惫”景象。结果就是开发职员任务努力性降落，开发职员离任，......，项目又进一步延迟了。
打破消极轮回
我想你曾经想到有一个方法可以处理这类景象。让我们来绘制一幅分歧的场景：
我们可以从一个幻想方案“项目定时竣工”Start。我们开发代码，然后立刻测试它。测试最好是主动化（编码完成）的，如许我们可以轻松有效的去履行它们。我们把开发和测试严密的联合在一同，每一个开发测试轮回可以很疾速的履行。当一个开发测试轮回完毕时我们有决心包管代码质量是很高的，由于它曾经经过了测试。并且用户由于发明缺点（bug）的数量变少而对我们持续高度信赖。即便他们发明了一个缺点（这仍然是有可能的），我们也能够扩大我们的测试聚集，去防止相干缺点的重现。
如斯下去，返工将不再是必需的，项目得有持续。
假如我们的项目曾经延期了，就需求我们花些工夫来采取这类办法论。对新功用的解冻或许是必需的。中止开发新的代码，取而代之去为最严重的（恼人的－明晰的－高价格的）缺点编写测试。
项目延期的状况下再去为你完好的代码库编写测试是不成行的，只针对此中的一些部分就能够，不要去糜费你的工夫。可是要记着其它部分也仍是需求编写测试的。我在这类状况下会去找出最严重的问题（划分优先级），然后为它们编写测试。以后“疾速”修正代码就会变的更轻易，而且可以包管在修正其他部分是它不会犯错。主动化测试可以很频仍的履行，从而下降了缺点（bug）重现的风险。好了，如今可以Start去有效的强壮我们项目了
上面这些凡是会请求实行代码重构，从而使它可测试化。我会在另外一篇文章里引见它。
总结
大部分的项目中，会思索测试和编码之间的均衡。不外我盼望大师都能明白，测试实际上是项目标减速器，而不是在糜费工夫。
下一篇文章我将带你进入测试驱动开发的范畴，你会发明本人能变得更有效力！
测试高兴！
本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。
2KB翻译任务按照
CC 协定，假如我们的任务有进犯到您的权益，请实时联络我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
