1979年，Glenford Myers在《The Art of Software Testing》一书中提出“测试的目的是证伪”这一概念，推翻了过去“为表明软件正确而进行测试”的错误认识，为软件测试的发展指出了方向，软件测试的理论、方法在之后得到了长足的发展。
测试不是挑毛病

　  然而，对测试领域先行者Glenford Myers先生“测试的目的是证伪”这一概念理解也不能过于片面。在很多软件工程学、软件测试方面的书籍中都提到一个概念:“测试的目的是寻找错误，并且是尽最大可能找出最多的错误”。这很容易让人们认为测试人员就是“挑毛病”的，而由此带来诸多问题。

　  我们可以假想在一个软件开发公司内，软件测试人员专注于“挑毛病”，开发人员和公司管理层每天会得到这样“简洁”的测试报告:“在今天的测试过程中，系统出现10次宕机现象”。

　  从“挑毛病”的角度看，测试人员已经很好的完成了自己的工作，但其工作成果对开发人员和公司管理层几乎没有任何帮助。开发人员面对这样的测试报告是无法对软件进行任何修改的;而公司管理层也会疑惑软件质量到底如何，系统能否如期发布。

　  长此以往，必然会造成开发人员和测试人员之间无法调和的矛盾;而公司管理层也会认为，测试团队只是“带来坏消息的人”，对公司产品没有提供任何帮助，不如取消为好。

　  这样的例子看似比较极端，业内普遍认为类似的问题仅出现在一个初创测试团队的公司内，但实际的情况远没有这样乐观，这类现象甚至还蔓延到近年来蓬勃兴起的部分第三方测试机构之中。

　  一个软件开发公司的管理者，拿到一份刚由某第三方测试机构完成的测试报告，报告结论是该公司开发的软件无法完成预定的需求，在500个用户并发交易的情况下会发生大量交易失败。应该说这样的报告确实挑出了软件的“毛病”，但报告中并未提及造成交易失败的原因，是硬件资源不足、支撑软件参数设置错误还是应用开发问题。这样的报告会使得委托测试单位置疑自己投资进行第三方测试的是否有实际帮助。

　  造成这些问题的原因归根结底就是对“测试的目的是证伪”这一概念的片面理解。那么，一次成功的测试是如何对问题进行阐述的呢？质量工程学中软件失效的机理给出了很好的答案。

　  软件错误是人为错误

　  质量工程学中对于软件失效是这样分析的:由于软件内部逻辑复杂，运行环境动态变化，且不同的软件差异可能很大，因而软件失效机理可能有不同的表现形式。

　  譬如有的失效过程比较简单，易于追踪分析，而有的失效过程可能非常复杂，难于甚至不可能加以详尽描述和分析，尤其是运行于高度复杂实时环境中的大型软件。

　  但总的说来，软件失效机理可描述为:软件错误，软件缺陷，软件故障，软件失效。

　  软件错误 软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见软件错误是一种人为过程，相对于软件本身，是一种外部行为。

　  软件缺陷 软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一逗点、多一语句等。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。

　  软件故障 软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无适当措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。

　  软件失效 软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。

　  因此，软件错误是一种人为错误。

　  逆流而上解决问题

　  我们了解了软件失效的机理后，就可以逆流而上，沿着软件失效，软件故障，软件缺陷，软件错误的方向对问题进行阐述和分析。

　  首先，测试人员会说明软件出现了问题，在此对软件失效现象进行了描述;

　  其次，测试人员会详细阐明是在哪个测试用例的作用下（包括输入数值、处理过程和预期输出结果），软件产生了何种异常输出，问题的类型、严重程度、修改的紧急程度如何，这样就明晰了软件故障的情况;

　  第三，测试人员会根据测试经验和实际情况，帮助开发人员进行故障定位，找到软件缺陷所在;

　  第四，测试人员在对问题情况进行统计的基础上，会指出共性问题并分析其产生的原因，发现软件错误。

　  在这样对问题进行充分分析的基础上，对问题提出修改意见，这样一份问题报告会是一份对开发人员和管理层有意义的报告。

　  我们可以按照这样的分析方法，对前面企业内部和第三方的两个测试失败的情况进行修正。
软件失效现象:发生宕机/不能承担500

[1] [2] 下一页