|
|
|
由于信息系统的构成可能比较复杂，所涉及的问题比较多，为了保证整个开发任务的按期完成，测试工作不一定只在测试阶段才进行，能提前的应尽量提前。而且可按功能分别进行。例如，硬件、网络等设备在到货后应进行初验，安装后再进行详细的测试，最后结合应用软件等对整个信息系统进行测试。本节将针对信息系统中的硬件系统、网络系统和软件系统中的测试步骤和测试内容进行介绍，重点为软件测试。
|
|
|
|
|
|
测试是开发过程中一个独立且非常重要的阶段，也是保证开发质量的重要手段之一。测试过程基本上与开发过程平行进行。在测试过程中，需要对整个测试过程进行有效的管理，以保证测试质量和测试效率。一个规范化的测试过程通常包括以下基本的测试活动。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
要使测试有计划且有条不紊地进行，需要编写测试文档。测试文档主要有测试计划和测试分析报告。测试文档的格式和要求参见本书的第10章。
|
|
|
|
|
|
在拟定测试计划时，要充分考虑整个项目的开发时间和开发进度以及一些人为因素和客观条件等，使得测试计划是可行的。测试计划的内容主要有：测试的内容、进度安排、测试所需的环境和条件（包括设备、被测项目、人员等）、测试培训安排等。
|
|
|
|
|
|
测试大纲是测试的依据。它明确详尽地规定了在测试中计对系统的每一项功能或特性所必须完成的基本测试项目和测试完成的标准。无论是自动测试还是手动测试，都必须满足测试大纲的要求。
|
|
|
|
|
|
根据测试大纲，设计和生成测试用例。在设计测试用例时，可综合利用前面介绍的测试用例设计技术，产生测试设计说明文档，其内容主要有：被测项目、输入数据、测试过程、预期输出结果，等等。
|
|
|
|
|
|
测试的实施阶段是由一系列的测试周期组成的。在每个测试周期中，测试人员和开发人员将依据预先编制好的测试大纲和准备好的测试用例，对被测软件或设备进行完整的测试。
|
|
|
|
|
|
测试完成后要形成相应的测试报告，主要对测试进行概要说明，列出测试的结论，指出缺陷和错误。另外，给出一些建议，如：可采用的修改方法，各项修改预计的工作量及修改的负责人等。
|
|
|
|
通常，测试与纠错是反复交替进行的。如果使用专业测试人员，测试与纠错可以平行进行，从而节约了总的开发时间。另外，由于专业测试人员有丰富的测试经验，采用系统化的测试方法并能全时地投入，而且独立于开发人员的思维，使得他们能够更有效地发现许多单靠开发人员很难发现的错误和问题。
|
|
|
|
|
|
由于每种测试所花费的成本不同，如果测试步骤安排得不合理，将会造成为了寻找错误原因而浪费大量的时间以及重复测试的情况。因此，合理安排测试步骤对于提高测试效率和降低测试成本有很大的作用，信息系统测试分别按硬件系统、网络系统和软件系统进行测试，最后对整个系统进行总的综合测试。
|
|
|
|
|
|
在进行信息系统开发中，通常需要根据项目的情况选购硬件设备。在设备到货后，应在各个相关厂商配合下进行初验测试，初验通过后将硬件与软件、网络等一起进行系统测试。初验测试所做的工作主要如下。
|
|
|
|
.配置检测，检测是否按合同提供了相应的配置，如系统软件、硬盘、内存、CPU等的配置情况。
|
|
|
|
.硬件设备的外观检查，所有设备及配件开箱后，外观有无明显划痕和损伤。这些包括计算机主机、工作站、磁带库、磁盘机柜和存储设备等。
|
|
|
|
.硬件测试，首先进行加电检测，观看运行状态是否正常，有无报警、屏幕有无乱码提示和死机现象，是否能进入正常提示状态。然后进行操作检测，用一些常用的命令来检测机器是否能执行命令，结果是否正常。例如，文件复制、显示文件内容、建立目录等。最后检查是否提供了相关的工具，如帮助系统、系统管理工具等。
|
|
|
|
通过以上测试，要求形成相应的硬件测试报告，在测试报告中包含测试步骤、测试过程和测试的结论等。
|
|
|
|
|
|
如果信息系统不是单机，需要在局域网或广域网运行，按合同会选购网络设备。在网络设备到货后，应在各个相关厂商配合下进行初验测试。初验通过后网络将与软件、硬件等一起进行系统测试。初验测试所做的工作主要如下。
|
|
|
|
.网络设备的外观检查，所有设备及配件开箱后，外观有无明显划痕和损伤，这些包括交换机、路由器等。
|
|
|
|
.硬件测试，进行加电检测，观看交换机、路由器等工作状态是否正常，有无错误和报警。
|
|
|
|
.网络连通测试，检测网络是否连通，可以用ping、 telnet、 ftp等命令来检查。
|
|
|
|
通过以上测试，要求形成相应的网络测试报告，在测试报告中包含测试步骤、测试过程和测试的结论等。
|
|
|
|
|
|
软件测试实际上分成4步：单元测试、组装测试、确认测试和系统测试，它们将按顺序进行。首先是单元测试（Unit Testing），对源程序中的每一个程序单元进行测试，验证每个模块是否满足系统设计说明书的要求。组装测试（Integration Testing）是将已测试过的模块组合成子系统，重点测试各模块之间的接口和联系。确认测试（Validation Testing）是对整个软件进行验收，根据系统分析说明书来考察软件是否满足要求。系统测试（System Testing）是将软件、硬件、网络等系统的各个部分连接起来，对整个系统进行总的功能、性能等方面的测试。
|
|
|
|
下面将分别对单元测试、组装测试、确认测试和系统测试的内容和要求加以说明。
|
|
|
|
|
|
单元测试也被称为被模块测试。在模块编写完成且无编译错误后就可以进行。可以选用人工测试或机器测试，当用机器测试时，一般采用白盒测试法，多个模块可以同时进行。
|
|
|
|
|
|
在单元测试中，主要从模块的5个特征进行检查：模块接口、局部数据结构、重要的执行路径、出错处理和边界条件。
|
|
|
|
①模块接口，如果所测模块的数据流不能正确地输入、输出，则根本就无法进行其他的测试。所以在单元测试中要考察模块的接口。Myers提出了接口测试要点如下。
|
|
|
|
.调用被测模块的输入参数和形式参数在个数、属性、单位上是否一致
|
|
|
|
.调用其他模块时所给的实际参数和被调模块的形式参数在个数、属性、单位上是否一致
|
|
|
|
.调用标准函数时所用的参数在属性、数目和顺序上是否正确
|
|
|
|
|
|
|
|
如果模块完成了外部的输入或输出，还应该再检查以下要点：
|
|
|
|
|
|
|
|
.在使用文件之前是否已经打开文件或使用文件完毕后是否已关闭文件
|
|
|
|
|
|
|
|
②局部数据结构，在单元测试中，局部数据结构出错是比较常见的错误，在测试时应重点考虑以下因素。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
③重要的执行路径，在单元测试中，对路径的测试是最基本的任务。由于不能进行穷举测试，需要精心设计测试用例来发现是否有计算、比较或控制流等方面的错误。
|
|
|
|
计算方面的错误主要有：算术运算的优先次序不正确或理解错误；精度不够；运算对象的类型彼此不匹配；算法不正确；表达式的符号表示不正确等。
|
|
|
|
比较和控制流是紧密结合的，一般是通过比较来决定控制流的改变。关于这方面的错误主要有：本应相等的量由于精度问题造成不相等；不同类型进行比较；逻辑运算符不正确或优先次序错误；循环终止不正确（如多循环一次或少循环一次）、死循环；不恰当地修改循环变量；当遇到分支循环时，发生出口错误等。
|
|
|
|
④出错处理，好的设计应该能预测到出错的条件并且有对出错处理的路径。虽然计算机可以显示出错信息的内容，但仍需要程序员对出错进行处理，保证其逻辑的正确性，便于用户维护。对出错的测试应该着重考虑这些常见错误：错误的描述难于理解；错误提示与实际错误不相符；出错的提示信息不足以确定错误或确定造成错误的原因；在对错误进行处理之前，系统已经对错误条件进行了干预等。
|
|
|
|
⑤边界条件，边界条件的测试是单元测试的最后工作，也是非常重要的工作。软件容易在边界出现错误，如一个n维数组，在处理数组第n个下标时常常发生错误。要仔细选择测试用例，重点考察数据流、控制流在刚好等于、大于或小于最大值或最小值的情况。
|
|
|
|
模块测试通常由程序员本人来完成。但项目负责人应该注意测试结果，将这些些测试资料妥善保存，为后续的测试工作打下良好的基础。
|
|
|
|
|
|
由于模块不是独立运行的程序，各模块之间存在联系，即存在调用与被调用的关系，在对每个模块进行测试时，需要开发两种模块：
|
|
|
|
①驱动模块（driver）,相当于一个主程序，用于接收测试用例的数据，将这些数据送到被测模块，输出测试结果。
|
|
|
|
②桩模块（stub），也被称为存根模块，桩模块用来代替被测模块中所调用的子模块，其内可进行少量的数据处理，目的是为了检验入口，输出调用和返回信息。
|
|
|
|
驱动模块和桩模块是测试用的软件，不是要交给用户的软件组成部分，但需要占用一定的开发费用。为了降低成本，对于一些不能用简单的测试软件进行充分测试的模块，可以用下节介绍的增量式测试方法，在组装测试的同时完成对模块的详细测试。
|
|
|
|
提高模块的内聚度可以简化单元测试。如果每个模块只完成一种功能，对于具体模块来讲，所需的测试方案数目就会显著减少，而且更容易发现和预测模块中的错误。
|
|
|
|
|
|
组装测试也被称为集成测试。即使所有模块都通过了测试，但在组装之后，仍可能会出现问题：通过模块的数据被丢失；一个模块的功能对其他模块造成有害的影响；各个模块被组合起来后没有达到预期功能；全局数据结构出现问题；另外单个模块的误差可以接受，但模块组合后，可能会出现误差累积，最后达到不能接受的程度，所以需要组装测试。
|
|
|
|
通常，组装测试有两种方法：一种是分别测试各个模块，再把这些模块组合起来进行整体测试，这种方法被称为非增量式集成。另一种是把下一个要测试的模块组合到已测试好的模块中，测试完后再将下一个需测试的模块组合进来进行测试，逐步把所有模块组合在一起，并完成测试。该方法被称为增量式集成。非增量式集成可以对模块进行并行测试，能充分利用人力，以加快工程进度。但这种方法容易混乱，出现的错误不容易被查找和定位。增量式测试的范围是一步步扩大的，所以错误容易被定位，而且已测试的模块可在新的条件下进行测试，程序测试得更彻底。
|
|
|
|
增量式测试技术有自顶向下的增量方式和自底向上的增量方式两种测试方法。
|
|
|
|
|
|
自顶向下的增量方式是模块按程序的控制结构，从上到下的组合方式。再增加测试模块时有先深度后宽度和先宽度后深度两种次序。如下图所示的自顶向下组合示例中，先深度后宽度的方法是把程序结构中的一条主路径上的模块相组合，测试顺序可以是M1→M2→M5→M6→M3→M7→M4。先宽度后深度的方法是把模块按层进行组合，测试顺序是M1→M2→M3→M4→M5→M6→M7。组装过程可分成以下步骤：
|
|
|
|
|
|
|
|
.用主模块作为驱动模块，与之直接相连的模块用桩模块代替。
|
|
|
|
.根据所选的测试次序，用下一个模块替换所用的桩模块；而新引入模块的直接下属模块用桩模块代替，构成新的测试对象。
|
|
|
|
.结合一个模块测试一个模块。为了避免引入新模块产生新问题，需要进行回归测试，即重复部分或全部已经进行过的测试。
|
|
|
|
.所有模块是否已经被组合到系统中，并完成测试。如果没有完成测试，则返回到第二步，重复进行；如果完成测试，则停止测试。
|
|
|
|
自顶向下的增量方式可以较早地验证控制和判断点，如果出现问题可及时进行纠正。在测试时不需要编写驱动模块，但需要桩模块。另外，如果高层模块对下层模块依赖性很大，需要返回大量信息，在用桩模块代替时，桩模块的编写就相对复杂，必然会增加开销。这时可以用下面介绍的自底向上的增量方式。
|
|
|
|
|
|
自底向上的增量方式是从最底层的功能模块开始，边组合边测试，从下向上地完成整个程序结构的测试。其步骤可以概括为：
|
|
|
|
.将最底层的模块组合成能完成某种特定功能的模块簇，为每个模块簇设计驱动程序，用驱动程序来控制并进行测试。
|
|
|
|
.按从下向上的方向，用实际模块替换相对应的驱动程序，组成新的模块簇，再为该模块簇设计驱动程序，用新的驱动程序进行控制和测试。
|
|
|
|
.所有模块是否已经被组合到系统中，并完成测试。如果没有完成测试，则返回到第二步，重复进行；如果完成测试，则停止测试。
|
|
|
|
自底向上的增量方式可以较早地发现底层关键性模块出现的错误。在测试时不需要缩写桩模块，但需要驱动模块。另外，这种方式对程序中的主要控制错误的发现相对较晚。
|
|
|
|
组装测试的方法选择取决于软件的特点和进度安排。在工程中，通常将这两种方法结合起来使用，即对位于软件结构中较上层的使用自顶向下的方法，而对于较底层的使用自底向上的方法。
|
|
|
|
|
|
经过组装测试之后，软件就被集成起来，接口方面的问题已被排除，就可以进入软件测试的最后一个环节——确认测试。确认测试的任务是进一步验证软件的有效性，也就是说，检查软件的功能和性能是否与用户的要求一样。系统分析说明书描述了用户对软件的要求，所以是软件有效性验证的标准，也是确认测试的基础。
|
|
|
|
确认测试的步骤如下图所示。首先要进行有效性测试以及软件配置审查，然后进行验收测试和安装测试，经过管理部门的认可和专家的鉴定后，软件即可交给用户使用。
|
|
|
|
|
|
|
|
|
|
有效性测试就是在模拟环境下，通过黑盒测试检验所开发的软件是否与需求规格说明书一致。为此，需要制定测试计划，规定要做的测试类型，设计测试用例，组织测试人员对已集成的软件进行测试。在设计测试用例时，除了检测软件的功能和性能之外，还需要对软件的容错性、维护性等其他方面进行检测。测试人员可由开发商的内部人员组成，但最好是没有参加该项目的有经验的软件设计人员。在所有测试用例完成之后，测试结果有两种情况：
|
|
|
|
|
|
.发现测试结果与预期的不符，这时要列出缺陷清单。在这个阶段才发现的严重错误一般很难在预定的时间内纠正，需要与用户协商，寻找妥善解决问题的办法。
|
|
|
|
|
|
确认测试的另一个环节是软件配置的审查，主要是检查软件（源程序、目标程序）和文档（包括面向开发和用户）是否齐全以及分类是否有序。确保文档、资料的正确和完善，以便维护阶段使用。
|
|
|
|
|
|
在经过软件的有效性测试和软件配置复查后，就应该开始软件系统的验收测试。验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。在验收测试之前，需要对用户进行培训，以便熟悉该系统。验收测试的测试用例由用户参与设计，主要验证软件的功能、性能、可移植性、兼容性、容错性等，测试时一般采用实际数据。
|
|
|
|
|
|
系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方。系统测试是根据系统分析说明书来设计测试用例的，常见的系统测试主要有以下内容：
|
|
|
|
（1）恢复测试（Recovery Testing）。
|
|
|
|
恢复测试将检测系统的容错能力。检测方法是采用各种方法让系统出现故障，检验系统是否能按照要求从故障中恢复过来，并在预定的时间内开始处理事务，而且不对系统造成任何损害。如果系统的恢复是自动的（由系统自动完成），则需要验证重新初始化、检查点、数据恢复等是否正确。如果恢复需要人工干预，就要对恢复的平均时间进行评估并判断它是否在允许的范围内。
|
|
|
|
（2）安全性测试（Security Testing）。
|
|
|
|
系统的安全性测试用于检测系统的安全机制、保密措施是否完善且没有漏洞。主要是为了验证系统的防范能力。测试的方法是测试人员模拟非法入侵者，采用各种方法冲破防线。例如，以系统的输入作为突破口，利用输入的容错性进行正面攻击；故意使系统出错，利用系统恢复的过程，窃取密码或其他有用的信息；想方设法截取或破译密码；利用浏览非保密数据，获取所需信息，等等。从理论上说，只要时间和资源允许，没有进入不了的系统。所以，系统安全性设计准则是使非法入侵者所花费的代价比进入系统后所得到的好处要大，此时非法入侵已无利可图。
|
|
|
|
|
|
强度测试是对系统在异常情况下的承受能力的测试，是检查系统在极限状态下运行的情况下，性能下降的幅度是否在被允许的范围内。因此，强度测试要求系统在非正常数量、频率或容量的情况下运行，例如，运行使系统处理超过设计能力的最大允许值的测试用例；设计测试用例使系统传输超过设计最大能力的数据，包括内存的写入和读出，外部设备等；对磁盘保留的数据，设计产生过度搜索的测试用例；等等。强度测试主要是为了发现，在有效的输入数据中可能引起的不稳定或不正确的数据组合。
|
|
|
|
（4）性能测试（Performance Test）。
|
|
|
|
性能测试用于检查系统是否满足系统分析说明书对性能的要求。特别是实时系统或嵌入式系统，即使软件的功能满足需求，但性能达不到要求也是不行的。性能测试覆盖了软件测试的各阶段，而不是等到系统的各部分所有都组装之后，才确定系统的真正性能。通常与强度测试结合起来进行，并同时对软件、硬件进行测试。软件方面主要从响应时间、处理速度、吞吐量、处理精度等方面来检测。
|
|
|
|
（5）可靠性测试（Reliability Testing）。
|
|
|
|
对于系统分析说明书中提出了可靠性要求时，要对系统的可靠性进行测试。通常使用以下几个指标来衡量系统的可靠性：
|
|
|
|
.平均失效间隔时间（Mean Time Between Failures MTBF）是否超过了规定的时限。
|
|
|
|
.因故障而停机时间（Mean Time To Repairs MTTR）在一年中应不超过多少时间。
|
|
|
|
（6）安装测试（Installation Testing）。
|
|
|
|
在安装软件系统时，会有多种选择。安装测试就是为了检测在安装过程中是否有误、是否易操作等。主要检测：系统的每一个部分是否齐全；硬件的配置是否合理；安装中需要产生的文件和数据库是否已产生，其内容是否正确等。
|
|
|
|
最后再强调一下，信息系统的开发过程通常为系统分析、设计、编码实现等阶段。而每个阶段都有可能出现错误，测试过程正好与开发过程相反，其开发和测试的关系如下图所示，单元测试主要是发现编码阶段的错误。组装测试主要用于发现设计阶段产生的错误，如果在确认测试中发现系统分析有错误，这就需要重新修改系统分析、设计和编码。这说明越早犯的错误要到最后才能被发现，因此要重视开发的前期工作。
|
|
|
|
|
|
|
