测试是一件浪费时间的事吗?

让我们详细地说明

作为开发人员,我们都知道我们应该测试我们的代码。我们应该写单元测试,但这也通常是我们发现没时间时跳过的第一步。

作为团队的领导者或者管理者我们都知道测试是必要的,但是当截止日期临近的时候,我们倾向于减少测试,而把更多的重点放到编码上。

这样看测试领域似乎很紧张。我们都知道测试对我们是有利的,但是一旦项目面临压力时我们就不再测试了。

我们为什么测试?

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,这将会快速地降低用户对项目的信任度,从而产生消极反馈。这种反馈传递给(工作过度的)开发人员,就造成开发人员“疲劳”现象。后果就是开发人员工作积极性下降,开发人员离职,……,项目又进一步延迟了。

我们可以从一个理想计划“项目按时完工”开始。我们开发代码,然后立即测试它。测试最好是自动化(编码实现)的,这样我们可以轻松有效的去执行它们。我们把开发和测试紧密的结合在一起,每个开发测试循环可以很快速的执行。当一个开发测试循环结束时我们有信心保证代码质量是很高的,因为它已经通过了测试。而且用户因为发现缺陷(bug)的数目变少而对我们继续高度信任。即使他们发现了一个缺陷(这依然是有可能的),我们也可以扩充我们的测试集合,去避免相关缺陷的重现。

如此下去,返工将不再是必须的,项目得有继续。

如果我们的项目已经延期了,就需要我们花些时间来采用这种方法论。对新功能的冻结也许是必须的。停止开发新的代码,取而代之去为最严重的(恼人的-清晰的-高代价的)缺陷编写测试。

项目延期的情况下再去为你完整的代码库编写测试是不可行的,只针对其中的一些部分就可以,不要去浪费你的时间。但是要记住其它部分也还是需要编写测试的。我在这种情况下会去找出最严重的问题(划分优先级),然后为它们编写测试。之后“快速”修改代码就会变的更容易,并且可以保证在修改其他部分是它不会出错。自动化测试可以很频繁的执行,从而降低了缺陷(bug)重现的风险。好了,现在可以开始去有效的强健我们项目了

上面这些通常会要求进行代码重构,从而使它可测试化。我会在另一篇文章里介绍它。

总结

大部分的项目中,会考虑测试和编码之间的平衡。不过我希望大家都能清楚,测试其实是项目的加速器,而不是在浪费时间。

下一篇文章我将带你进入测试驱动开发的领域,你会发现自己能变得更有效率!

测试愉快!

为程序员提供最优质的博文、最精彩的讨论、最实用的开发资源;提供最新最全的编程学习资料:PHP、Objective-C、Java、Swift、C/C++函数库、.NET Framework类库、J2SE API等等。并不定期奉送各种福利。

本文分享自微信公众号 - java一日一条(mjx_java)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-01-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏灯塔大数据

荐读|爬虫还在用Python?我与Node.js不得不说的故事

深夜闲来无事,默默的打开github,在搜索框中填入了”Stars:>1”,本想着依旧可以在第一页看到Spark的身影,结果第一个映入眼帘的是这个: ? 快速...

1.8K60
来自专栏数据派THU

21个令程序员泪流满面的瞬间

20140
来自专栏移动端开发

苹果审核2.1大礼包,这几个方面入手。

1.6K20
来自专栏13blog.site

Spring+SpringMVC+MyBatis+easyUI整合优化篇(八)代码优化整理小记及个人吐槽

前言 这两天也一直在纠结这一篇文章该写什么东西,前面临时加的两篇文章就有些打乱了整体节奏,这一篇又想去写一下代码层面优化的事情,可是也不太能抓住重要的点,不太确...

26660
来自专栏企鹅号快讯

这篇SEO干货讲的不错!不来看看?

作为一个网络推广从业者,SEO一直是我笔者勤学苦练的绝技,可是,找了很多资料,就没有一个干货是讲真话的,但是,功夫不负有心人,总算让我找到了,好了,送给需要了解...

27750
来自专栏java一日一条

为什么要测试,测试是如何令人更快乐的?

我曾经是一个不测试主义者,因为我看不到测试的价值。然后,我试了一段时间,变得对它深信不疑。我收集了一些经验,当然还远远不够。这篇文章总结了一些我知道的以及我认为...

9010
来自专栏Crossin的编程教室

3分钟破译朋友圈测试小游戏

最近,朋友圈时不时会流行起某个测试类小游戏,比如你的性格图谱啦,你是三体中的哪个角色啦,你有什么超能力啦……昨天晚上在某个群里,又被一个测测你是什么书的小游戏刷...

49970
来自专栏包子铺里聊IT

10分钟拥有自己的Wikipedia

谁是花和尚? 花和尚是一个定居西雅图的程序员,拥有多年系统设计和开发经验。喜欢研究和总结System Design, 并传授给大家。花和尚在MITBBS一篇 "...

68360
来自专栏FreeBuf

物联网安全研究之二:IoT系统攻击面定义分析

在前文中,我们了解了IoT技术的基本架构,本文我将来说说IoT安全,在此过程中,我们会尝试定义一种新方法来理解IoT安全,同时也会创建一个结构化流程来方便认知I...

45390
来自专栏CSDN技术头条

荔枝FM架构师刘耀华:异地多活IDC机房架构

声明:本文首发于CSDN,禁止未经许可的任何形式转载,可咨询文末的责编。 多机房架构存在的原因 ? 单机房一旦死机,断电、维护根本无法挽回整个数据,想离线读取等...

53760

扫码关注云+社区

领取腾讯云代金券