1.3 软件测试的目的和原则

1.3.1 软件测试的目的

不同的机构会有不同的测试目的，相同的机构也可能有不同的测试目的，可能是测试不同区域或是对同一区域的不同层次进行测试。

软件测试的目的决定了如何组织测试。如果测试的目的是为了尽可能多地找出错误，那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。如果测试的目的是为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。

测试可视为包括分析、设计和编码3个阶段的“最终复审”，在软件质量保证中具有重要地位。为了确保软件的质量，较理想的做法应该是按照软件的开发过程，对软件工程各阶段形成的结果分别进行严格的审查。

软件测试的目的可认为是：

● 帮助开发人员、测试工程师发现问题、分析问题。

● 减少软件的缺陷数目或者降低软件的缺陷密度。

● 提高软件的可靠性。

● 评估软件的性能指标。

● 增加用户对软件的信心。

● 测试的最终目的是为了避免错误的发生，确保应用程序能够正常高效地运行。

对于软件测试目的，Grenford J. Myers提出以下观点：

1）软件测试是为了发现错误而执行程序的过程。

2）测试是为了证明程序有错，而不是证明程序无错。

3）一个好的测试用例在于它能发现至今未发现的错误。

4）一个成功的测试在于它发现了至今未发现的错误。

这些观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这些观点可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误的测试就是没有价值的。然而事实并非如此。

首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，通过分析也能帮助我们设计出有针对性的检测方法，改善测试的有效性。

其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。例如，Bev Littlewood发现一个经过测试而正常运行了n小时的系统有可能继续正常运行n小时。

1.3.2 软件测试的原则

根据上述测试目的，软件测试应遵循以下原则：

1）应当把尽早地和不断地进行软件测试作为软件开发者的座右铭。

由于原始问题的复杂性、软件的复杂性和抽象性、软件开发各个阶段工作的多样性，以及开发过程中各种层次的人员之间工作的配合关系等因素，使得开发的每个环节都可能产生错误。所以不应把软件测试仅仅看作软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段。坚持在软件开发的各个阶段进行技术评审，这样才能在开发过程中尽早发现和预防错误，杜绝某些隐患，提高软件质量。

2）测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。

在进行测试之前应当根据测试的要求选择测试用例（Test Case）。测试用例主要用来检验程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。如果对测试输入数据没有给出预期的程序输出结果，那么就缺少了检验实测结果的基准，就有可能把一个似是而非的错误结果当成正确结果。

3）程序员应避免检查自己的程序。

测试工作需要严谨的作风、客观的态度和冷静的情绪。人们常常由于各种原因而产生一种不愿否定自己的工作的心理，这种心理就成为测试自己编写的程序的障碍。另外，程序员对软件规格说明理解错误而引入的错误自己就更难发现。如果由别人来测试程序员编写的程序，可能会更客观、更有效，并更容易取得成功。要注意的是，这点不能与程序的调试相混淆，调试由程序员自己来做可能更有效。

4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

合理的输入条件是指能验证程序正确性的输入条件，而不合理的输入条件是指异常的、临界的、可能引起问题异变的输入条件。在测试程序时，人们常常倾向于过多地考虑合法的和期望的输入条件，以检查程序是否做了它应该做的事情，而忽视了不合法的和预想不到的输入条件。事实上，软件在投入运行以后，用户的使用往往不遵循事先的约定，使用了一些意外的输入，如用户在键盘上按错了键或输入了非法的命令。如果软件对这种情况不能做出适当的反应，给出相应的信息，那么就容易产生故障，轻则给出错误的结果，重则导致软件失效。因此，软件系统处理非法命令的能力也必须在测试时受到检验。用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试更能发现错误。

5）充分注意测试中的群集现象。

测试时不要以为找到了几个错误问题就不需要继续测试了，经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。

在所测程序段中，若发现错误数目较多，则残存错误数目也比较多。这种错误群集现象已被许多程序的测试实践所证实。例如，美国IBM公司的OS/370操作系统中，47%的错误仅与该系统的4%的程序模块有关。这种现象对测试很有用。如果发现某一程序模块似乎比其他程序模块有更多的错误倾向，则应当花费较多的时间和代价测试这个程序模块。

6）严格执行测试计划，排除测试的随意性。

测试计划应包括：所测软件的功能、输入和输出、测试内容、各项测试的进度安排、资源要求、测试资料、测试工具、测试用例的选择、测试的控制方式和过程、系统组装方式、跟踪规程、调试规程、回归测试的规定以及评价标准等。对于测试计划，要明确规定，不要随意更改。

7）应当对每一个测试结果做全面检查。

这是一条最明显的原则，但常常被忽视。有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细全面地检查测试结果，就会使这些错误被遗漏掉。所以必须对预期的输出结果明确定义，对实测的结果仔细分析检查，抓住征候，暴露错误。

8）妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。

9）应尽可能早地开始测试。在软件生存期中，错误发现得越晚，修复错误的费用就越高。如表1-1所示。

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

11）测试用例应由测试输入数据、测试执行步骤和与之对应的预期输出结果三部分组成。

12）按照组件和功能特征的优先级从高到低的顺序进行测试。

13）重点放在处理多语言字符串的直接或间接输入/输出（I/O）上。

14）对测试出的错误结果一定要有一个确认的过程。

15）注意回归测试的关联性，修改一个错误而引起更多错误出现的现象并不少见。