【测试】7.测试的艺术

概述

• 软件测试更适宜被视为试图发现程序中错误（假设其存在）的破坏性的过程。一个成功的测试用例，通过诱发程序发生错误，可以在这个方向上促进软件质量的改进。当然，最终我们还是要通过软件测试来建立某种程序的信心：软件做了其应该做的，未做其不应该做的。但是通过对错误的不断研究是实现这个目的的有效途径。

软件测试的重要原则
          1.测试用例中一个必需部分是对预期输出或结果进行定义
          2.程序员应该避免测试自己编写的程序
          3.编写软件的组织不应该测试自己编写的软件
          4.应当彻底检查每个测试的执行结果
          5.测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况
          6.检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
          7.应避免测试用例用后即弃，除非软件本身就是一个一次性的软件
          8.计划测试工作时不应默许假定不会发生错误
          9.程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
          10.软件测试是一项极富创造性、极具智力挑战性的工作

原则1：测试用例中一个必需部分是对预期输出或结果的定义。

   这条显而易见的原则在软件测试中是最常犯的错误之一。同样，这个问题也是
基于人们的心理的。如果某个测试用例的预期结果事先没有得到定义，由于“所见
即所想”现象的存在，某个似是而非、实际上是错误的结果可能会被解释成正确的
结论。换句话说，尽管“软件测试是破坏性”的定义是合理的，但人们在潜意识中
仍然渴望看到正确的结果。克服这种倾向的一种方法，就是通过事先精确定义程序
的预期输出，鼓励人们对所有的输出进行仔细检查。因此，一个测试用例必须包括
两个部分：
        1. 对程序的输入数据的描述。
        2. 对程序在上述输入数据下的正确输出结果的精确描述。
        所谓“问题”，可以归纳为一个或一组我们不能给出可信服的解释、看上去不
太正常或不符合我们期望或预想的事实。应当明确的是，在确定事物存在“问题”之前，
人们必须已经形成了特定的认识。没有期望，也就没有所谓的意外。

原则2：程序员应当避免测试总结编写的程序

    如果我们对软件项目关注的重点发生变化，就会产生另外一个问题。当程序
员“建设性”地设计和编写完程序之后，很难让他突然改变视角以一种“破坏性”
的眼光来审查程序。
    正如许多房屋业主都知道的那样，撕下屋里的墙纸（这是个破坏性的过程）
并不容易，如果这些墙纸又恰恰是业主第一个亲手贴的，尤其令其沮丧不已。同
样，大多数程序员都不能有效地测试自己编写的程序，因为他们无法改变思维方
式来尽力暴露自己程序中的错误。另外，程序员可能会下意识地避免找出错误来，
担心受到同事、上司、客户或正在开发的程序或系统的主管的惩罚。
    仅次于上面的心理学问题，还有一个重要的问题：由于程序员错误地理解了
疑难定义或规范，导致程序中存在错误。如果情况是这样，程序员可能会带着同
样的误解来测试自己的程序。
    这并不意味着程序员测试自己的程序是不可能的。当然，我们的言下之意是，
让其他人来测试程序会更加有效，也会更容易测试成功。
    请注意，我们的论据并不适合于“调试”（纠正已知的错误）。“调试”由程序
的编写人员来完成会有效得多。

原则3：编写软件的组织不应当测试总结编写的软件

   同样，我们并不是说编程组织发现程序中的问题是不可能的，事实上很多组
织已经在某种程度上成功地做到了这一点。当然，我们的言下之意是，更经济的
方法是由客观、独立的第三方来进行测试。

原则4：应当彻底检查每个测试的执行结果

    这个原则可能是最显而易见的原则，但也同样常常被忽视。我们见过大量的
例子，即便错误的症状在输出清单中可以清楚地看到，但还是没有找出那些错误
来。换言之，在后续测试中发现的错误，往往是前面的测试遗漏掉的。

原则5：测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况。

    例如，很少有人会向程序输入1，2，5以证明程序不会错误地将其解释为一个
不规则三角形，而不是一个无效三角形。此外，在软件产品中突然暴露出来的许多
问题是当程序以某些新的或未预料到的方式运行时发现的。因此，针对未预料到的
和无效输入情况的测试用例，似乎比针对有效输入情况的那些用例更能发现问题。

原则6：检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。

    这条原则是上条原则的必然结果。必须检查程序是否有我们不希望的负作用。
比如，某个工资管理程序即便可以生成正确的工资单，但是如果也为非雇员生成
工资单或者它覆盖掉了人员文件的第一条记录，这样的程序仍然是不正确的程序。

原则7：应避免测试用例用后即弃，除非软件本身就是一个一次性的软件

    这个问题在采用交互式系统来测试软件时最常见。人们通常会坐在终端前，匆
忙地编写测试用例，然后将这些用例交由程序执行。这样做的问题在于，饱含我们
宝贵投入的测试用例，在测试结束后就消失了。一旦软件需要重新测试（例如，当
改正了某个错误或作了某种改进后），又必须重新设计这些测试用例。情况往往是
这样的，由于重新设计测试用例需要投入大量的工作，人们总是避免这样做。因此，
对该程序的重新测试极少会同上次一样严格。这就意味着，如果对程序的更改导致
了程序某个先前可以执行的部分发生了故障，这个故障往往是不会被发现的。保留
测试用例，当程序其他部件发生更动后重新执行，这就是我们所谓的“回归测试”。

原则8：计划测试工作时不应默许假定不会发现错误。

    项目经理经常容易犯这个错误，这也是使用了不正确的测试定义的一个迹象—
也就是说，假定“测试是一个证明程序正确运行的过程”。我们再一次重申，所谓
测试，就是为发现错误而执行程序的过程。

原则9：程序某部分存在存在更多错误的可能性，与该部分已发现错误的数量成正比

    该原则的另一个说法是，错误总是倾向于聚集存在，而在一个具体的程序中，某
些部分要比其他部分更容易存在错误，尽管没有人能够对这种现象给出很好的解释。
这种现象之所以有用，是因为它给予了我们对软件测试过程的深入理解或反馈信息。
如果一个程序的某个部分远比其他部分更容易产生错误，那么这种现象告诉我们，为
了使测试获得更大的成效，最好对这些容易存在错误的部分进行额外的测试。

原则10：软件测试是一项极富创造性、极具智力挑战性的工作

    测试一个大型软件所需要的创造性很可能超过了开发该软件所需要的创造性。
我们已经看到，要充分地测试一个软件以确保所有错误都不存在是不可能的。本
书后续章节讨论的技术使我们能够为某个软件设计出合理的测试用例集，然而这
些技术仍然需要大量的创造性。

小结

1. 软件测试是为发现错误而执行程序的过程
2. 尽量避免编码人员测试总结的程序
3. 好的测试用例能够对未发现的错误高度敏感、
4. 成功的测试用例需要仔细定义输入输出的期望值
5. 成功的测试用例需要仔细研究分析测试结果

笔记总结之《软件测试的艺术》