软件工程：实践者的研究方法第16章软件测试技术

第16章 软件测试技术

　　软件测试的重要性及其对软件质量的好坏的预意是非常重要的。下面这段话引自Deutsch［DEU79］：性及其对软件质量的好坏的预意是非常重要的。下面这段话引自Deutsch[DEU79]：

　　软件系统的开发包括一系列生产活动，其中由人带来的错误因素非常多。错误可能出现在程序的最初…，其时目标可能是错误的或描述不完整，也可能在后期的设计和开发阶段…，因为人们不能完好无缺地工作和交流，软件开发过程中必须伴有质量保证活动。

　　软件测试是软件质量保证的关键元素，代表了规约、设计和编码的最终检查。

　　软件作为系统元素的可见性不断增加软件故障带来的代价太高使得人们注重于规划良好的彻底测试，软件开发组织将30％—40%的项目精力花在测试上并不为怪。另一方面，人命悠关的软件(如飞行控制和核反应堆)测试所花的时间往往是其他软件工程活动时间之和的三到五倍。

　　本章讨论软件测试基础和设计软件测试用例的技术。软件测试基础定义了软件测试的目标，测试用例的设计讨论符合整体目标的测试用例创建技术。第17章讨论测试策略和软件调试。

16.1软件测试基础

　　测试为软件工程师带来了很有趣的意外。在软件过程的早期，软件工程师试图由抽象概念到具体实现来建立软件，现在来了测试，工程师创建测试用例试图“摧毁”已经建立的软件。事实上，在软件工程过程中，测试可以看成(至少心理上)摧毁性的而不是建设性的。

　　软件开发者就其本性而言是建设者，测试要求开发者放弃刚开发的软件是正确的观念，并克服发现错误时的心理矛盾。Beizers［BEI90］如下描述了这种情况：

　　如果我们真正擅长编程，就应当不会有错误，但这只是一个神话。如果我们真的很认真，如果每个人都使用结构化方法，自顶向下设计而且使用决策表，如果程序是用SQUISH写的，如果我们有合适的银弹，就不会有错误了，这样，神话就不存在。因为我们并不擅长所做的事，所以有错误，如果不擅长，就应当感到内疚。因此，测试和测试用例设计是对失误的承认，它注入了一针内疚剂。测试的枯燥是对我们错误的处罚，为什么处罚？为了人？为什么内疚？为了没能达到人类的完美境界？为了没有区别另一个程序员所想的和所说的？为了没有心灵感应？为了没有解决人类四千年来尚未解决的相互通信问题？

　　测试真的应当注入内疚感？测试真的是摧毁性的？这些问题的回答是“不！”，然而，测试的目标可能和我们所期待的不同。

16.1.1测试目标

　　Glen Myers［MYE79］在他的软件测试著作中陈述了一系列关于测试目标的规则：欢馐?

　　1.测试是一个为了寻找错误而运行程序的过程。

　　2.一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例。

　　3.一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。

　　上述目标蕴含了一个观点上的戏剧性变化，他们转向通常的观点，即一个成功的测试是指没有找到错误的测试。我们的目标是设计这样的测试，它们能够系统地揭示不同类型的错误，并且耗费最少时间与最小工作量。

　　如果成功构造了测试(根据上述目标)，则能够在软件中揭示错误。测试的第二个好处在于它证实了软件依据规约所具有的功能及其性能需求，此外，构造测试时的数据收集提供了软件可靠性以及软件整体质量的一些信息。但是，有一件事测试无法完成：

　　测试无法说明错误不存在，它只能表示软件错误已经出现。

　　在构造测试时必须牢记这一点。

16.1.2测试原则

　　在设计有效的测试用例之前，软件工程师必须理解软件测试的基本原则。Davie［DAV95］提出了一组①测试原则：

　　·所有的测试都应追溯到用户需求。正如我们所知，软件测试的目标在于揭示错误。而最严重的错误(从用户角度来看)是那些导致程序无法满足需求的错误。

　　·应该在测试工作真正开始的前较长时间内就进行测试计划。测试计划(第17章)可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始，因此，所有测试可以在任何代码被产生前进行计划和设计。

　　· Pareto原则应用于软件测试。简单而言， Pareto原则暗示着测试发现的错误中的80％很可能起源于程序模块中的20％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。

　　·测试应从“小规模”开始，逐步转向“大规模”。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误(第17章)。

　　·穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大(进一步讨论参见第16.2节)，因此，在测试中不可能运行路径的每一种组合，然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。

　　·为了达到效果，应该由独立的第三方来构造测试。“效果”指最可能发现错误的测试(测试的主要目标)。由于本章中已经介绍过、并将在第17章进一步讨论的那些原因，创建系统的软件工程师并不是构造软件测试的人选。