测试是软件开发的工程严谨性

Testing Is the Engineering Rigor of Software Development

当开发者尝试向家人、配偶及非技术人员解释它们是做什么的时,喜欢用象征性比喻。我们经常(将其)诉诸为桥梁建造或者其它“硬核”工程学科。但是,当你试着把它们说得太难时,这些隐喻是经不住考验的。事实证明,软件开发在很多方面并不像那些“硬核”工程学科。

相对于这些“硬核”工程,软件开发的世界更像是桥梁建造者的地位,当时一个共通的策略就是先架起桥梁,然后在往上铺设一些很重的东西。如果它稳固,说明很好。如果不是,那就重新回到图纸层面。经过了数千年,工程师们创建了数学和物理学,将其运用于结构化的解决方案,而非先把它造好再看看效果。然而在软件开发中我们却没有任何可利用的东西,或许永远都不会有,因为现实中的软件开发太难了。为了深度探索比较软件“工程”与其它工程,Jack Reeves在1992年在《C++期刊》上发表了“什么事软件设计?”,很经典。尽管它写于20多年前,仍然非常精确。Reeves在对比中描绘了一幅悲观的画面,但1992年那会,强大的软件测试精神是缺失的。

测试“难”在你必须先构建它们才能对它们测试,这就阻碍了那种只想看看会发生什么的投机性构建。不过在软件中构建过程廉价得令人发指。我们已经开发了一套完整的生态系统工具以便于轻松做到:单元测试、模拟对象、测试用具,以及大量的其它东西。其他工程师们肯跟热衷于建造事物并在行之有效的条件下测试它。而作为开发者,我们拥抱测试,将其作为软件验证机制的主要手段(但并非唯一)。与其等待软件的某些排序计算,我们可以用工具进行处理,确保良好的工程实践。从这个角度看,我们现在有证据去抗议那些所谓的”我们没时间搞测试“的领导。一个桥梁建造师可能永远不会听到他的老板说一句:“不用做什么建造的结构分析了——我们期限快到了。”测试确实是可复用性和质量的途径,作为软件的开发者,可以将反对这种观点(的人)视为对专业的不负责任。

测试需要时间,正如结构分析也需要时间。都是为了保证最终产品的质量。是时候让软件开发者承担起他们对产品的责任了。独立测试是不够的,但它是必要的。测试是软件开发的工程严谨性。

0%