《ERP项目管理与实施》课件第8章

8.1ERP系统测试基础8.2ERP系统测试过程本章小结

习题

8.1.1软件质量保证

1.软件质量的概念

软件质量与传统意义上的质量概念并无本质差别，只是针对软件的某些特性进行了调整。从一般意义而言，质量通常会被定义为“无缺陷”。进一步讲，如果企业是以顾客为中心的，那么通常是根据顾客满意来定义质量：“如果顾客不喜欢，那该产品就有缺陷。”8.1ERP系统测试基础一个软件之所以被认定为质量优秀，应具备以下特性：

●满足用户的需求。

●合理的进度、成本、功能关系。

●具备扩展性和灵活性，能够适应一定程度的需求变化。

●能够有效处理例外的情况。

其中，满足用户的需求是最重要的评判标准。

ERP系统作为一种特殊的软件系统，其质量同样具备软件质量的特点。

2.软件错误的定义

在现实中，人们遇到很多软件质量问题，这些问题，轻则给使用者带来不便，重则导致重要数据丢失、重大财产损失、甚至危及生命。这些质量问题被称为软件错误。

软件错误是指软件产品中存在的导致期望的运行结果和实际结果间出现差异的一系列问题，这些问题包括故障、失效、缺陷。软件错误又被称为“Bug”。Bug的出现并不一定是代码问题，也可能是需求或设计等方面引起的。我们也可以认为软件错误是用户不喜欢的或者不能帮助用户使用应用程序达到目标的东西。

3.软件质量保证

为了提高软件的质量，人们进行了大量的研究和实践。最初的重点是着眼于技术革新，注重对各种软件工具、各种计算机辅助软件工程环境以及软件开发“模型”的研究，但这些都未能达到预期的目标。人们逐渐认识到，如果能够同时对软件开发过程的质量加以控制，那么软件质量才可能大幅度的提高。也就是说，只有从一开始就在开发过程中实施严格的过程控制，软件产品的质量才可能有保证。因此，软件质量保证也从最初的技术、方法为重心，转移到以过程管理为重心。软件质量保证的活动主要包括：

●技术方法的应用。

●正式技术评审的实施。

●软件测试。

●标准的执行。

●修改的控制。

●度量。

●记录和记录保存。

软件质量保证是为了确保软件开发过程和结果符合预期的要求而建立的一系列规程，以及依照规程和计划采取的一系列活动及其结果评价。软件质量保证并不等同于软件测试。软件质量保证评估过程质量，主要的目的是预防缺陷，而软件测试评估产品质量，主要目的是检测错误。软件质量保证通过评审测试结果和搜集软件质量度量监控测试的有效性，对软件测试文档的审核用于确定测试活动是否符合建立的标准和规范的要求。

对于ERP实施项目的ERP系统来说，其质量保证，就是为了确保ERP实施过程和结果符合预期的要求而建立的一系列规程，以及依照规程和计划采取的一系列活动及其结果评价，实际上就是指实施过程的规范化管理及效果评价。8.1.2ERP系统测试

1.软件测试基本概念

软件测试是软件开发过程的重要组成部分，用来确认一个程序的品质或性能是否符合开发之前所提出的要求。软件测试的目的，第一是确认软件的质量，即一方面是确认软件做了我们所期望的事情，另一方面是确认软件以正确的方式来做了这个事情。第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。第三，软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此软件测试的第三个目的是保证整个软件开发过程是高质量的。测试人员在软件开发过程中的任务主要如下：

(1)寻找Bug。

(2)避免软件开发过程中的缺陷。

(3)衡量软件的品质。

(4)关注用户的需求。

总的目标是：确保软件的质量。常用的软件测试方法有：黑盒测试和白盒测试。黑盒测试顾名思义就是将被测系统看成一个黑盒，从外界取得输入，然后再输出。整个测试基于需求文档，看是否能满足需求文档中的所有要求。黑盒测试要求测试者在测试时不能使用与被测系统内部结构相关的知识或经验，它适用于对系统的功能进行测试。黑盒测试的优点如下：

(1)比较简单，不需要了解程序内部的代码及实现。

(2)与软件的内部实现无关。

(3)从用户角度出发，能很容易地知道用户会用到哪些功能、会遇到哪些问题。

(4)基于软件开发文档，所以也能知道软件实现了文档中的哪些功能。

(5)在做软件自动化测试时较为方便。黑盒测试的缺点如下：

(1)不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%。

(2)自动化测试的复用性较低。

白盒测试是指在测试时能够了解被测对象的结构，可以查阅被测代码内容的测试工作。它需要知道程序内部的设计结构及具体的代码实现，并以此为基础来设计测试用例。

白盒测试的直接好处就是知道所设计的测试用例在代码级上哪些地方被忽略，它的优点是能帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。白盒测试的缺点如下：

(1)程序运行会有很多不同的路径，不可能测试所有的运行路径。

(2)测试基于代码，只能测试开发人员做得对不对，而不能知道设计得正确与否，可能会漏掉一些功能需求。

(3)系统庞大时，测试开销会非常大。

2. ERP系统测试概念

本质上来说，ERP系统也是一个软件，但对ERP实施项目来说，测试的主要目的是确保实施完成的ERP系统能够满足企业预定的各项管理需求，同时具备相应的安全性、可靠性等性能。本节所说的ERP系统测试就是指ERP实施项目的系统测试，因此，其测试的内容和方法就和普通的软件测试不同。

ERP项目的系统测试，一般是基于这样一个基础：ERP系统软件是一种相对成熟的产品，已经在其他企业成功实施过。因此，ERP项目的系统测试的测试人员一般为ERP项目的工程实施人员；测试方案一般采用黑盒测试，测试目的也和软件测试不同。在一些软件公司的ERP实施方法论中，没有明确指出ERP系统测试这一过程，而实际上，系统测试是一个不能避免的过程。实施方法论中虽然没有明确这一过程，但往往将此过程包含到其他过程中，如流程模拟、系统初始化等。

3. ERP系统测试的主要内容

ERP系统测试的主要内容有功能测试、安全测试、易用性测试、性能测试、稳定性测试、健壮性测试等。

1)功能测试

功能测试主要是确保ERP系统在上线之前能满足所有的业务需求，其关键在于测试和验证这些系统的运作情况是否符合设计要求，其测试依据是需求文档。功能测试具体可以分为数据测试、业务流程测试、报表测试等。

(1)数据测试：主要核对输入的基础数据、初始数据是否有误，同时，通过有关ERP系统的功能(例如，利用系统的盘点表与现有库存余额表核对库存余额；利用系统的明细余额表与现有账簿核对明细余额等)，来检测数据的正确性和有效性。

(2)业务流程测试：主要验证各种业务流程是否正确运作。由于工作流对强化业务规则来说是非常重要的，因此测试应该覆盖整个整合系统中的所有导航项目和直接功能。应用的业务规则和启动项必须通过全面测试，确保所有规则能被正确地执行。

(3)报表测试：主要验证各种报表是否符合企业所提出的报表需求，包括报表数据的正确性、数据项是否缺少、报表格式是否正确等。

2)安全性测试

安全性包括系统安全性和用户安全性。系统安全性是指测试软件系统防止非法入侵的能力。用户安全性是指系统中的用户可以完成系统指定的功能，且不能执行系统没有指定的功能。用户安全性主要是通过权限控制系统来完成的，ERP权限控制系统决定了用户可以使用哪些信息，用户在这些信息中可以看到哪些数据。从用户界面的角度出发测试安全性可以确保严格执行验证规则。

3)易用性测试

易用性测试指软件系统的使用方便程度。其具体测试内容见表8-1。表8-1易 用 性 测 试

4)性能测试

性能测试验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的作用。主要的性能指标有服务器的各项指标(CPU、内存占用率等)、后台数据库的各项指标、网络流量、响应时间等。通常，把正常情况下的性能指标测试、在正常的基础上加大多少百分比压力的性能指标测试(即压力测试)和不断加压直到系统崩溃的指标测试(即负载测试)统称为性能测试。其他有关性能测试的说明如下：

(1)性能测试是在功能测试完成之后进行的。

(2)性能测试计划、方案一般与测试用例统一放在一个文档里。

(3)测试环境应尽量与用户环境保持一致。

(4)性能测试一般使用测试工具和测试人员编制测试脚本来完成，性能测试的环境应单独运行，尽量避免与其他软件同时使用。

(5)性能测试的重点在于前期数据的设计与后期数据的分析。

(6)性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，性能测试的重复使用率一般比较高。

5)稳定性测试

稳定性测试测试软件是否能长时间运行，且在长运行时间下是否出现异常。

6)健壮性测试

健壮性测试测试软件系统在异常情况下能否正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。

4.测试用例

对于前面所说的各项测试内容，最终是通过设计测试用例进行的。测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。测试用例目前没有经典的定义，比较通常的说法是：对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。测试用例的内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。测试用例是根据需求来设计的，而不同类别的软件，其需求不同，因此测试用例也是不同的。一般，测试用例可以根据它们所关联的测试类型或测试需求来分类，而且将随类型和需求进行相应的改变。最佳方案是为每个测试需求至少编制两个测试用例：一个测试用例用于证明该需求已经满足，通常称做正面测试用例；另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称做负面测试用例。测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例应该参照用例规约(或设计规格说明书)，根据关联的功能、操作按路径分析法设计测试用例，而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。

设计备选事件和异常事件的用例则要复杂和困难得多。

一般软件测试常用的基本方法有等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。对于ERP系统来说，可以采用等价类划分法、逻辑覆盖法等进行测试用例的设计。8.1.3测试工作流程

测试工作的流程如下：

(1)制定测试计划。

(2)设计测试案例。

(3)执行系统测试。

(4)进行缺陷管理和改错。

(5)编写《验收测试报告》。8.1.4测试文档

主要的测试文档有测试计划、测试案例、测试报告等。

1.测试计划

测试计划是测试人员管理测试项目，在软件中寻找Bug的一种有效的工具。测试计划主要有两个作用，一是评判测试覆盖率以及效率，使测试工作有条理地逐步展开；二是有利于与项目经理、开发人员进行沟通。总之，有了测试计划，可以更好地完成测试工作，确保用户的满意度。测试人员在编写测试计划之前，应获得以下文档：

(1)程序经理编写的产品功能说明书或产品开发计划。

(2)程序经理或开发人员提供的开发进度表。

根据产品的特性及开发进度安排，测试人员制定具体的测试计划。测试计划通常包括以下内容：

(1)测试目标和发布条件。

①给出清晰的测试目标描述。

②定义产品的发布条件，即在达到何种测试目标的前提下才可以发布产品的某个特定版本。

(2)给出待测产品范围。其内容包括：

①软件主要特性/功能说明，即待测软件主要特性的列表。

②特性/功能测试一览，应涵盖所有特性、对话框、菜单和错误信息等待测内容，并列举每个测试范围内要重点考虑的关键功能。

(3)给出测试方法描述。其内容包括：

①定义测试软件产品时使用的方法。

②描述每一种特定的测试方法可以覆盖哪些测试范围。

(4)确定测试人员。其内容包括：

①定义参与测试的人员，并给出所有测试人员的相关信息。

②描述每位测试人员的职责范围。

(5)给出测试进度表。具体包括：

①定义测试里程碑。

②定义当前里程碑的详细测试进度。

(6)确定配置范围和测试工具。其内容包括：

①给出测试时使用的所有计算机平台列表。

②描述测试覆盖了哪些硬件设备。

③测试时使用的主要测试工具。此外，还应列出测试中可能会面临的风险及测试的依赖性，即测试是否依赖于某个产品或某个团队。比如此项测试依赖于需要二次开发的特定模块A，而这个特定模块A要在次年2月份才能做好，那么此项测试就可能只有在次年2月份才能开始，这样就存在着依赖关系。如果该团队的开发计划推后，则此项测试也会被推迟。

2.测试案例

ERP实施项目的测试用例一般以该ERP软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。编写测试用例文档应有文档模板，须符合内部的规范要求。

测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试目的、测试要求、测试步骤、预期结果(含判断标准)等。

测试用例可以采用表8-2所示方式，每个用例填写一张表格。表8-2测试用例

3.测试报告

测试报告有两种，一种是测试用例进行测试后针对每个测试用例所提交的用例测试结果报告；另一种是所有测试完成之后所提交的整体测试结果报告。

1)用例测试报告

用例测试报告一般是在测试用例的基础上扩充部分内容而得到的，如表8-3所示，其中增加了测试结果、备注、测试人和测试时间信息。表8-3用例测试报告

2)整体测试结果报告

整体测试结果报告通常也叫验收测试报告，一般是根据测试计划、测试结果来编写的，其主要内容包括测试背景、测试依据、测试环境、测试方法、测试时间和测试人员、测试情况与记录、测试结果、反馈建议等。

测试背景：简要说明本次测试的主体以及需要达到的目标。

测试依据：列出本次测试的主要依据，一般为需求说明书等相关文档。

测试环境：说明本次测试的软件、硬件环境，对于软件，要说明软件的版本号。测试方法：说明本次测试所采用的测试方法，一般和测试计划中的测试方法相同。

测试时间和人员：说明本次测试的起止时间以及测试负责人和测试参与人员。对于测试人员，要说明其职务。

测试情况与记录：用表格的形式列出所有的测试项目，以及各测试项目的测试结果。这里的测试结果一般为“通过”或“不通过”。

测试结果：总体说明本次测试的结果。

反馈建议：列出在测试过程中发现的问题以及需要改进的地方。8.2.1制定测试计划

测试计划一般是在充分理解需求以后，在需求文档的基础上根据测试计划的文档项目由经理依次写入各项内容制定而成。现针对测试计划文档的各部分说明如下。8.2ERP系统测试过程

1.测试目标和发布条件

针对本项目，测试目标为：保证初始化后的ERP系统数据录入正确，各业务流程符合业务需求，ERP系统能正常运行，保证超市进销存管理的需要。

发布条件为：只有通过所有测试项目的测试，才可以上线试运行。

2.待测产品范围

待测产品范围主要说明软件的主要特性、功能，即列出所要测试的项目。针对本项目，列出的测试项目如表8-4所示。对于其中一些测试项目，在表8-4中列举得还不够详细，则可以用另外的附加表格进行细化说明。例如，软件功能模块的基础数据管理，还可以细分为物料管理、单位管理、员工管理等；其他模块如采购模块、销售模块、仓存模块、基础数据等，也都可以进一步细化。表8-4测试项目列表

3.测试方法描述

测试方法描述主要定义测试软件产品时使用的测试方法，并描述每一种特定的测试方法可以覆盖哪些测试范围。针对本项目，ERP系统是相对成熟的产品，不是一个软件开发项目，因此，采用的测试方法应为黑盒测试。

4.测试环境

测试环境主要列出测试的软硬件环境、外部接口以及所使用的测试工具。针对本项目，列出测试环境如下：

计算机：服务器一台，工作机三台。

操作系统：Windows2000Server。

数据库：SQL2000。

进销存软件：金蝶K/3V10.4。

5.测试人员

测试人员主要定义参与测试的人员，给出所有测试人员的相关信息，并描述每位测试人员的职责范围。针对本项目，列出测试人员，如表8-5所示。表8-5测试人员列表

6.测试进度表

测试进度表主要用来定义测试里程碑以及当前里程碑的详细测试进度。针对本项目，列出测试进度表，如表8-6所示。表8-6测试进度安排8.2.2选择测试案例

在制定测试计划之后，开始选择测试案例。一般，一些成熟的ERP软件商会提供一套完整的测试案例，当然，也可以根据实际情况来编写具体的测试案例。

对于ERP实施项目，由于软件产品本身是一个成熟的产品，因此，测试重点并不在于软件产品功能本身，而应将重点放在数据、流程等的正确性上。所以，在编写测试案例时，也应该将重点放在这里。实际上，在很多实际的ERP实施过程中，对于软件的功能、性能、稳定性、健壮性、易用性等并没有专门设计测试案例，只是进行简单的一般性测试。针对本项目，系统功能中的数据、业务流程、统计报表等，需要编写测试案例。每一个测试子项目需编写一个测试案例，对于还不够详细的测试子项目，要进一步细化后再编写测试案例。编写测试案例时，可以采用前面提到过的测试案例文档格式，如表8-7所示。表8-7测试案例之日销售汇总报表8.2.3实施测试

在测试案例完成之后，各测试人员需按照测试计划的时间和任务要求，根据设计的测试案例实施测试，然后根据测试现象或测试的结果，与测试案例中的预期结果进行比对，并填写测试报告。

测试时需要注意的是，测试案例中有些地方的说明并不够明确，比如前面测试日销售汇总报表的测试案例，测试步骤的第1步“输入10笔销售单”并没有明确规定销售单的内容，因此，需要测试人员自己决定；同时，在进行预期结果第3步的比对时，10笔销售单的统计数据应在系统外计算，并将系统外计算的统计数据和统计报表上的统计数据进行

比对。

每项测试完成后，都要填写测试报告，如表8-8所示。表8-8测试报告之日销售汇总报表8.2.4测试问题反馈与处理

测试人员在测试过程中发现问题后须及时进行汇总反馈，分析其中的原因并提出建议解决方法，然后提交给专项负责人员处理，并规定解决时间；对于一些暂时无法解决的问题，要注明原因。

对于一些小型的ERP实施项目，一般情况下，测试人员和实施人员为同一人。此时，测试人员会直接去修改解决测试时发现的问题。在这种情况下，测试人员一般要记录测试中发现的问题以及解决的方法和时间，以备以后发现同类问题时参考。全部测试完成并且测试结果无误后，即可编写《验收测试报告》。内容具体如下：

《验收测试报告