新闻动态

破坏的意义软件实现是从建设者的角度来认识软件而软件

2019-03-10 22:22:30 作者:小麦

软件实现是从建设者的角度来认识软件,而软件测试是从破坏者的角度来认识软件。视角的不同,决定了软件开发的基本特征攻击性。

在大自然中,善于发现被攻击对象的弱点,是攻击者赖以生存的基本技能;而在软件开发,发现各种类型软件固有的软肋,也是软件测试人员应该具备的基本技能。当然,软件测试是一种模拟攻击和善意破坏,目的是帮助软件提升抵抗力和生存能力。

在非洲的草原上,一只母狮在捕猎。它在一尺高的草丛中匍訇前进,悄然接近一群正在食草的瞪羚。它观察良久,猛然扑向一只受伤的瞪羚。经过短暂的追逐,它收获了一顿丰盛的午餐。

对于软件来说,最大的软肋在于逻辑思维的不可遍历性。

在前一节中我们谈到,一个简单的程序可以产生海量的逻辑路径。面对海量的逻辑路径,要想对整个软件系统进行穷举测试基本上是不可能的。

我们不妨来举一个企业应用中的例子。

有一个保单批改的流程。这个流程要完成大量的工作,例如,保单信息的修改、计算保费、自动核保条件的判断、重新计算折扣、财务记录的生成等。

在这个保单模型实现的技术层面,采用了所谓动态对象模型的技术。这个动态模型会导致保单工作在不同的逻辑路径上。那么我们可以假设,当测试人员需要编写1000个测试用例来测试保单批改流程时,由于动态对象模型的存在,我们必须兼顾常规保单和使用了动态模型的保单。

很显然,在这种情况下,测试用例的数量立即翻了一倍。

实际上,软件开发实现中,影响逻辑路径的因素是非常多的。

我们说,软件测试的目标不是穷举,而是对逻辑路径进行一些规律上的分析—就像是母狮在观察羚羊,并尽可能多地验证实现与设计要求之间的吻合程度—也就是所谓的质量。那么,规律分析的目标又是什么呢?很简单,是为攻击做准备。

很多软件测试人员在面对一个复杂系统的时候,经常会感到手足无措。应该从哪里下手?做到怎样才算完成质量验证?在这里,我有些原则性的想法可以与读者共享。

在开始有关测试原则的话题讨论之前,我想先指出一个软件开发中的误区。

很多人认为,软件生产部门不需要保证软件的正确集成。集成的正确与否依赖于集成测试,这就像组装了一架飞机而没有责任保证它可以飞上蓝天一样。

因此,软件开发实践中,我们经常可以看到这样的现象在集成测试阶段,一些基本的业务流程在一般性的场景下都无法正常工作。我认为,这正是由于软件开发人员思想上的误区造成的。

我赞同敏捷方法提倡的测试驱动。这种敏捷测试方法,我称之为可行性测试”,就像对汽车进行动力学测试一样,它是软件生产的个组成部分,是由软件的设计者和实现者共同完成的。“可行性测试可以保证软件在某些情况下是可以工作的,但是不保证软件在更多的情况下可以工作。

本节中将要讨论的软件测试,不包括“可行性测试”。“可行性测试”应当在软件生产的过程中完成。因此,当软件测试人员开始工作时,我们的假定前提是,软件已经可以在一定的条件下正常工作了(在实践中,很多软件此时在任何条件下都不能正常工作)

可行性测试”已经验证了软件可以在一定的条件下生存,而软件测试人员的工作,是尝试去扩大那些软件生存条件的范围,从而检验软件的生存能力。显然,尝试的方式就是进行破坏性地攻击。

,接下来我们将讨论软件测试的一些原则。