系统测试主要是针对程序设计及编程调试后的结果进行的工作，所以，很自然地，很多人认为“测试是为了证明程序中不存在错误的过程”、“测试的目的是要证明程序正确地执行了预期的功能”等，这些定义都是错误的。系统测试是以找错为目的，而不是要证明程序无错，要精心选取那些容易发生错误的测试数据，以十分挑剔的态度，去寻找程序中可能出现的错误。实践证明，大型的软件在测试前是不可能没有错误的，因此系统测试的目的就是发现程序的错误。一个好的测试用例能够发现迄今为止未发现的错误。
6.4.1系统测试的原则
要保证物流信息系统实现成功测试，达到测试的目标，系统测试时一般应遵循以下几个方面的原则：
1.测试过程中要特别关注导致用户需求无法满足和满足不必要需求的错误
测试用例不仅应该包括有效的、合理的输入数据，还应该包括无效的、不合理的数据；不仅应该包括确定的输入数据，还应该包括预期的输出结果。测试应该充分覆盖程序逻辑，以便尽可能多地发现错误。除了检查程序是否做了它应该做的事，还要检查程序是否做了它不应该做的事。如果程序做了它不应该做的事，满足不必要的用户需求，即使程序能做它应该做的事，通常也认为程序是错误的。
2.测试用例不仅选用合理的输入数据，还要选择不合理的输入数据
当以特殊方式使用程序时，可能会突然发现程序中有许多使用合理输入数据不曾遇到的错误，所以，此时使用预期的不合理的输入数据进行测试，比用合理的输入数据碰到错误的几率要大，从而能更多地发现错误，提高程序的可靠性。
3.程序员应避免测试自己的程序
程序员可以对自己编写的程序进行调试，但是，一般情况下应避免对自己设计的程序进行除单元测试之外的其他测试，可能的话最好找独立的第三方进行客观测试。物流信息系统分析和设计人员都不是测试最佳人选，因为各开发人员对自己的程序进行测试都不可避免地带有心理障碍。此外，如果程序中包含了程序员对用户需求问题叙述或说明的误解而产生的错误，当程序员测试自己编写的程序时，一般不可能发现这些错误。
4.要妥善保管好测试用例和系统测试文档（包括测试计划和测试分析报告）
测试用例的设计耗费很大的工作量，设计好的测试用例和现有的测试文档对今后系统的维护和再测试都有重要的参考借鉴意义。系统经过修改和扩充后一般都要针对相关内容进行再测试，这时原有的测试用例便可以再次使用，文档中的说明和分析结果也可以提供分析线索，检验原有问题是否已经得到解决，检查是否因为修改而激发了老问题或带来了新问题。
5.必要时进行合理的回归测试
所谓回归测试是指在测试过程中，对于发现错误而经过修改后的软件模块，再用原来发现错误的测试用例进行测试。通过回归测试不仅可以验证程序原有错误是否已经排除、系统是否确实被修改，而且还能够发现因修改而带来的新错误。
6.发现错误多的某些模块要进行集中、深入的测试
越是发现错误多的模块越有可能存在更多的错误，出错的概率就越大，在修改错误过程中又容易引入新的错误，所以在深入测试时，要集中测试这些出错多的模块。
6.4.2 系统测试的过程
物流信息系统测试并不是在系统设计活动和编程全部完成后才开始的，它可以和物流信息系统开发过程并列进行，包括整个开发过程中各个阶段的复查、检测和评估。系统测试不仅仅是程序的测试，还包括对开发文档的测试。物流信息系统的测试一般包括五个阶段的步骤，分别为单元测试、集成测试、确认测试、系统测试和验收测试。
1.单元测试
单元测试也称为模块测试或程序测试，测试的对象是物流信息系统软件的最小单位——模块。单元测试的目的是保证每个模块作为一个单元能正确运行。单元测试的依据是系统功能模块设计说明书，单元测试应对模块内所有重要的控制路径设计测试用例，以发现模块内部的错误。单元测试大多采用白箱测试技术，系统的多个模块可以并行进行测试。单元测试过程中所发现的错误多是编码和详细设计的错误。
单元测试集中于单个模块的功能和结构检验，一般包括模块接口测试、模块内部数据结构测试、覆盖条件和独立路径测试、出错处理、边界条件测试。
单元测试通常要经过人工测试和计算机测试两种类型的测试。测试工作由程序编写者本人和审查小组进行。审查之前，小组各成员应该先研究设计说明书，力求理解设计的目的和要求。为了帮助小组成员理解物流信息系统设计说明书，一般可以先由系统设计者简明扼要地介绍设计的目的和要求。在审查会上可由程序的编写者解释怎样用程序代码实现设计的要求，小组其他成员仔细倾听讲解，并力图发现其中的错误。审查会上还可以对照程序设计常见错误清单，分析审查程序，并记录发现错误。审查小组的任务是发现错误而不是改正错误。
一般源程序经过编译后，首先要进行人工测试，然后再进行机器测试。人工测试的目的在于检查程序的静态结构，找出编译阶段不能发现的问题。实践证明，组织良好的人工测试可以发现30%～50%的编码错误和逻辑错误，从而减少机器测试的负担，提高整个测试工作的效率。机器测试是用事先设计好的测试用例，执行被测程序，对比实际结果和预期结果的差别以发现错误。机器测试只能发现错误的症状，不能进行问题定位，而人工测试一旦发现错误就能够确定错误的位置、类型和性质。人工测试和计算机测试是互相补充、相辅相成的，缺少任何一种方法都会使查找错误的效率降低。
2.集成测试
集成测试是单元测试的扩展，也称组合测试或子系统测试。所谓集成，就是指把经过单元测试的模块组装成设计要求的系统结构的过程。单个模块经过测试可能是符合要求的，但是并不能保证各个模块连接起来能正常运行，有可能一个模块会给另一个模块带来副作用，也可能模块之间的接口有问题，所以要进行集成测试。集成测试集中于模块组合的功能和软件结构检验，主要包括模块组装中可能出现的问题，如数据穿过接口可能丢失、一个模块可能破坏另一个模块的内容、子功能组装可能不等于主功能、全程数据结构问题、误差累积问题等。
集成测试一般有三种形式：
（1）自上而下的集成
自上而下的集成测试是一个递增的组装测试的过程，先由一个主控模块（主程序）开始，然后按照控制层次向下进行集成，把模块按照深度优先或广度优先的方式一一组合起来，集成到整个系统结构中，每组合一个模块就进行一次测试，检查模块接口是否存在错误。
（2）自下而上的集成
自下而上的集成就是从程序的最底层模块开始组装和测试，首先从那些在软件结构中不调用其他模块的端点模块开始，将它们组装成具有特定功能的簇开始测试，然后再处理上层模块，即沿着层次结构向上对簇进行组合测试。这种集成方式需要一个驱动程序控制测试用例的输入和输出。
（3）两种方式的结合
一种结合方式是软件结构的高层采用自上而下的方式，而底层模块采取自下而上的方式；另一种结合方式是测试沿着功能性数据和控制流路径进行，输入数据采用自下而上的方式集成测试，然后，每个数据的输出采用自上而下的方式进行测试。两种方式的结合可以节省驱动数目，减少对驱动程序的需求。
3.系统测试
系统测试是对整个系统的综合测试，包括软件、硬件以及网络等组成计算机系统的各个要素的测试。系统测试可以发现系统分析设计中的错误，一般涉及对软件系统进行整体测试和有效性测试、对该软件系统与计算机中其他软件系统进行协调性测试、软件系统和硬件系统之间连接的融洽性、对软件运行的网络综合性能进行测试等。
4.确认测试
确认测试要检查软件能否按要求进行工作，即是否满足软件需求说明书中的确认标准。所以，确认测试要按照需求说明书中规定的确定指标对系统进行功能与性能测试，具体工作包括对照说明书进行黑盒测试、软件配置检查（配置齐全，文档完整、正确等）、人机界面和其他方面的检查（如可移植性、兼容性、错误恢复能力和可维护性等）等。确认测试的主要内容有：系统输入、输出、处理等功能的测试；性能测试，包括相应时间、数据处理和传输速度、数据转换能力、运行效率以及运行环境和操作方式、界面的友好性等；还包括安全性、保密性、可维护性、可移植性、兼容性、容错能力、恢复能力等限制条件的测试。
5.验收测试
验收测试是物流信息系统交付之前的最后一项测试，一般包括功能度、安全可靠性、易用性、可扩充性、兼容性、效率、资源占有率、用户文档等八个方面的测试。验收测试主要由用户来完成，通过设计一系列测试用例或使用真实数据，按照合同中规定的测试原则对系统进行测试，以确定系统是否实现了用户所要求的功能，是否达到了合同所要求的性能，并检查测试文档与程序测试是否达到了验收标准。验收测试是一项很实际的工作，一般在系统试运行的环境中进行，验收测试的结果将直接影响用户对新系统的接受和喜好程度。
在验收测试阶段发现的问题通常和需求分析阶段的差错有关，涉及的面会比较广，因此，解决起来也比较困难。为了确定解决确认测试过程中发现的软件缺陷或错误的策略，通常需要和用户充分协商。
验收测试的另一项重要内容是进行配置复审，以保证软件配置齐全、分类有序、必要的软件维护细节没有被遗漏。为了发现那些只有最终用户才能发现的程序错误或系统问题，一般采用α测试和β测试。α测试和β测试都是针对产品的测试。α测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。在α测试时，软件在一个自然设置状态下使用，开发者坐在用户旁边，随时记下错误情况和使用中的问题，所以是在受控环境下进行的测试。β测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。与α测试不同的是，β测试时开发者通常不在测试现场，所以β测试是在开发者无法控制的环境下进行的软件现场应用。
6.4.3 系统测试的方法
系统测试最基本的可以分为静态测试和动态测试。静态测试是由测试者通过阅读、检查、分析被测的物流信息系统模型以及程序代码，发现错误和存在的问题的，这种测试不运行被测试的程序。静态测试一般被用来检查模型和文档的正确性，查找程序中存在的逻辑问题。静态测试难以查出程序中隐藏的深层问题，不能代替动态测试。动态测试是在计算机上直接运行测试实例，以发现程序错误的一种测试方法。
1.黑盒测试
黑盒测试也称功能测试或数据驱动测试，着眼于程序的外部特征，将被测试的程序看成是一个黑箱子，完全不考虑程序的内部逻辑结构和处理过程，只用测试数据来验证被测程序的功能，看其是否满足需求分析中的功能说明，是否会发生异常情况，是否适当地接收输入数据而产生正确的输出信息，并且保持外部数据库或文件的完整性。
黑箱测试是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能查出程序中的所有错误。实际上，实际情况有无穷多个，人们不仅要测试所有的合法输入，而且还要对那些不合法但是可能的输入数据进行测试。
黑箱测试主要是为了发现以下的错误：功能上，是否有不正确的功能；接口上，是否能正确接受输入，并输出正确的结果；性能上，是否能满足要求，是否有数据结构错误或外部信息访问错误，是否有初始化或终止性错误。
黑箱测试常用的测试方法有等价类划分、边界值分析、因果图法和错误推测法等。
2.白盒测试
白盒测试又称为结构测试法或逻辑驱动测试法，测试人员把被测试的程序看成是一个透明的箱子，测试人员需要了解程序的内部结构和处理过程，对程序的所有逻辑路径进行测试，在不同点检查程序状态，确定实际状态与预期状态是否一致。
白盒测试是穷举路径测试。使用该测试方法时，测试人员必须检查程序的内部结构，从检查程序的逻辑出发，得出测试数据。贯彻程序的所有路径数将是一个天文数字，但是，即使每条路径都测试了仍然可能存在错误。穷举路径测试有三个方面的不足：
①不能查出程序违反了设计规范，即程序本身是个错误的程序；②不可能查出程序中因遗漏路径而出现的错误；③可能发现不了与数据相关的错误。
最彻底的白盒测试法是覆盖程序中的每一条路径。然而，由于大型复杂程序中的逻辑路径数目太多，不可能将全部路径都覆盖。根据覆盖程度的高低（从低到高排列），常用的白盒测试法依次有语句覆盖、判断覆盖、条件覆盖、判断／条件覆盖和条件组合覆盖。
