测试以前应当根据测试的要求选择测试用例( Test case),用来检验程序员编制的程序, 因此不但需要测试的输入数据,而且需要针对这些输入数据的预期输出结果 ③程序员应避免检查自己的程序。 程序员应尽可能避免测试自己编写的程序,程序开发小组也应尽可能避免测试本小组开 发的程序。如果条件允许,最好建立独立的软件测试小组或测试机构。这点不能与程序的调 试( debuging)相混淆。调试由程序员自己来做可能更有效。 ④在设计测试用例时,应当包括合理的输入条件和不合理的输入条件。 合理的输入条件是指能验证程序正确的输入条件,不合理的输入条件是指异常的,临界 的,可能引起问题异变的输入条件。软件系统处理非法命令的能力必须在测试时受到检验。 用不合理的输入条件测试程序时,往往比用合理的输入条件进行测试能发现更多的错误 ⑤充分注意测试中的群集现象 在被测程序段中,若发现错误数目多,则残存错误数目也比较多。这种错误群集性现象 已为许多程序的测试实践所证实。根据这个规律,应当对错误群集的程序段进行重点测试, 以提高测试投资的效益 ⑥严格执行测试计划,排除测试的随意性 测试之前应仔细考虑测试的项目,对每一项测试做出周密的计划,包括被测程序的功能 输入和输出、测试内容、进度安排、资源要求、测试用例的选择、测试的控制方式和过程等 还要包括系统的组装方式、跟踪规程、调试规程,回归测试的规定,以及评价标准等。对于 测试计划,要明确规定,不要随意解释 ⑦应当对每一个测试结果做全面检查。 有些错误的征兆在输出实测结果时已经明显地出现了,但是如果不仔细地全面地检査测 试结果,就会使这些错误被遗漏掉。所以必须对预期的输出结果明确定义,对实测的结果仔 细分析检査,抓住征侯,暴露错误。 ⑧妥善保存测试计划,测试用例,出错统计和最终分析报告,为维护提供方便。 (3)确认和验证的关系 确认(Ⅷ alidation)是一系列的活动和过程,其目的是想证实在一个给定的外部环境中软 件的逻辑正确性。它包括需求規格说明的确认和程序的确认,而程序的确认又分为静态确认 与动态确认。静态确认一般不在计算机上实际执行程序,而是通过人工分析或者程序正确性 证明来确认程序的正确性:动态确认主要通过动态分析和程序测试来检査程序的执行状态, 以确认程序是否有问题。 验证( Verification),则试图证明在软件生存期各个阶段,以及阶段间的逻辑协调性、完 备性和正确性 确认与验证工作都属于软件测试。在对需求理解与表达的正确性、设计与表达的正确性、 实现的正确性以及运行的正确性的验证中,任何一个环节上发生了问题都可能在软件测试中 表现出来。 (4)测试信息流 测试信息流如图5.1所示。测试过程需要三类输入: 软件配置:包括软件需求规格说明、软件设计规格说明、源代码等 测试配置:包括测试计划、测试用例、测试驱动程序等; 测试工具:测试工具为测试的实施提供某种服务。例如,测试数据自动生成程序、 静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的工作台等。 测试之后,用实测结果与预期结果进行比较。如果发现出错的数据,就要进行调试。对 已经发现的错误进行错误定位和确定出错性质,并改正这些错误,同时修改相关的文档。修 正后的文档一般都要经过再次测试,直到通过测试为止2 测试以前应当根据测试的要求选择测试用例（Test case），用来检验程序员编制的程序， 因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。 ③ 程序员应避免检查自己的程序。 程序员应尽可能避免测试自己编写的程序，程序开发小组也应尽可能避免测试本小组开 发的程序。如果条件允许，最好建立独立的软件测试小组或测试机构。这点不能与程序的调 试（debuging）相混淆。调试由程序员自己来做可能更有效。 ④ 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。 合理的输入条件是指能验证程序正确的输入条件，不合理的输入条件是指异常的，临界 的，可能引起问题异变的输入条件。软件系统处理非法命令的能力必须在测试时受到检验。 用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能发现更多的错误。 ⑤ 充分注意测试中的群集现象。 在被测程序段中，若发现错误数目多，则残存错误数目也比较多。这种错误群集性现象， 已为许多程序的测试实践所证实。根据这个规律，应当对错误群集的程序段进行重点测试， 以提高测试投资的效益。 ⑥ 严格执行测试计划，排除测试的随意性。 测试之前应仔细考虑测试的项目，对每一项测试做出周密的计划，包括被测程序的功能、 输入和输出、测试内容、进度安排、资源要求、测试用例的选择、测试的控制方式和过程等， 还要包括系统的组装方式、跟踪规程、调试规程，回归测试的规定，以及评价标准等。对于 测试计划，要明确规定，不要随意解释。 ⑦ 应当对每一个测试结果做全面检查。 有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细地全面地检查测 试结果，就会使这些错误被遗漏掉。所以必须对预期的输出结果明确定义，对实测的结果仔 细分析检查，抓住征侯，暴露错误。 ⑧ 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。 (3) 确认和验证的关系 确认（Validation）是一系列的活动和过程，其目的是想证实在一个给定的外部环境中软 件的逻辑正确性。它包括需求规格说明的确认和程序的确认，而程序的确认又分为静态确认 与动态确认。静态确认一般不在计算机上实际执行程序，而是通过人工分析或者程序正确性 证明来确认程序的正确性； 动态确认主要通过动态分析和程序测试来检查程序的执行状态， 以确认程序是否有问题。 验证（Verification），则试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完 备性和正确性。 确认与验证工作都属于软件测试。在对需求理解与表达的正确性、设计与表达的正确性、 实现的正确性以及运行的正确性的验证中，任何一个环节上发生了问题都可能在软件测试中 表现出来。 (4) 测试信息流 测试信息流如图 5.1 所示。测试过程需要三类输入： ▪ 软件配置：包括软件需求规格说明、软件设计规格说明、源代码等； ▪ 测试配置：包括测试计划、测试用例、测试驱动程序等； ▪ 测试工具：测试工具为测试的实施提供某种服务。例如，测试数据自动生成程序、 静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的工作台等。 测试之后，用实测结果与预期结果进行比较。如果发现出错的数据，就要进行调试。对 已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修 正后的文档一般都要经过再次测试，直到通过测试为止