系统测试指南

1  测试对象和目的

1．1  测试对象

         系统测试的对象是完整的、集成的计算机系统。重点是新开发的软件配置项的集合。

1．2  测试目的

         系统测试的目的是在真实系统工作环境下检验完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。

2  测试的组织和管理

       系统测试按合同规定要求执行，或由软件的需方或由软件的开发方组织，由独立于软件开发的人员实施，软件开发人员配合。如果系统测试委托第三方实施，一般应委托国家认可的第三方测试机构。

       应加强系统测试的配置管理，已通过测试的系统状态和各项参数应详细记录，归档保存，未经测试负责人允许，任何人无权改变。

         系统测试应严格按照由小到大、由简到繁、从局部到整体的程序进行。

         软件系统测试的技术依据是用户需求(或系统需求或研制合同)。其测试工作的准入条件应满足被测软件系统的所有配置项已通测试，对需要固化运行的软件还应提供固件。

3  技术要求

 系统测试一般应符合以下技术要求：

 a)  系统的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖；

 b)  测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值；

c)  应逐项测试系统/子系统设计说明规定的系统的功能、性能等特性；

d)  应测试软件配置项之间及软件配置项与硬件之间的接口；

e)  应测试系统的输出及其格式；

f)  应测试运行条件在边界状态和异常状态下，或在人为设定的状态下，系统的功能和性能。

g)  应测试系统访问和数据安全性；

h)  应测试系统的全部存储量、输入/输出通道和处理时间的余量；

i)  应按系统或子系统设计文档的要求，对系统的功能、性能进行强度测试；

j)  应测试设计中用于提高系统安全性、可靠性的结构、算法、容错、冗余、中断处理等方案；

k)  对完整性级别高的系统。应对其进行安全性、可靠性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试；

l)  对有恢复或重置功能需求的系统，应测试其恢复或重置功能和平均恢复时间并且对每一类导致恢复或重置的情况进行测试；

m)  对不同的实际问题应外加相应的专门测试。

        对具体的系统，可根据软件测试合同(或项目计划)及系统的重要性、完整性级别等要求对上述内容进行裁剪。

4  测试内容

4．1  总则

 本标准针对系统测试的测试内容主要从：适合性、准确性、互操作性、安全保密性、成熟性、容错性、易恢复性、易理解性、易学性、易操作性、吸引性、时间特性、资源利用性、易分析性、易改变性、稳定性、易测试性、适应性、易安装性、共存性、易替换性和依从性等方面(有选择的)来考虑。

 对具体的系统，可根据测试合同(或项目计划)及系统/子系统设计文档的要求对本标准给出的内容进行裁剪。

4．2  功能性

4．2．1  适合性方面

     从适合性方面考虑，应测试系统/子系统设计文档规定的系统的每项功能。

4．2．2  准确性方面

      从准确性方面考虑，可对系统中具有准确性要求的功能和精度要求的项(如数据处理精度、时间控制精度、时间测量精度)进行测试。

4．2．3  互操作性方面

       从互操作性方面考虑，可测试系统/子系统设计文档、接口需求规格说明文档和接口设计文档规定的系统与外部设备的接口、与其他系统的接口。测试其格式和内容。包括数据交换的数据格式和内容；测试接口之间的协调性；测试软件对系统每一个真实接口的正确性测试软件系统从接口接收和发送数据的能力；测试数据的约定、协议的一致性；测试软件系统对外围设备接口特性的适应性。

4．2．4  安全保密性方面

      从安全保密性方面，可测试系统及其数据访问的可控制性。

      测试系统防止非法操作的模式，包括防止非授权的创建、删除或修改程序或信息，必要时做强化异常操作的测试。

     测试系统防止数据被讹误和被破坏的能力。

     测试系统的加密和解密功能。

4. 3  可靠性

4. 3.1  成熟性方面

     在成熟性方面，可基于系统运行剖面设计测试用例，根据实际使用的概率分布随机选择输入，运行系统，测试系统满足需求的程度并获取失效数据，其中包括对重要输入变量值的覆盖、对相关输入变量可能组合的覆盖、对设计输入空间与实际输入空间之间区域的覆盖、对各种使用功能的覆盖、对使用环境的覆盖。应在有代表性的使用环境中、以及可能影响系统运行方式的环境中运行软件，验证系统的可靠性需求是否正确实现。对一些特殊的系统，如容错软件、实时嵌入式软件等，由于在一般的使用环境下常常很难在软件中植入差错，应考虑多种测试环境。

      测试系统的平均无故障时间。

      选择可靠性增长模型。通过检测到的失效数和故障数，对系统的可靠性进行预测。

4.3.2  容错性方面

  从容错性方面考虑。可测试：

a) 系统对中断发生的反应；

b) 系统在边界条件下的反应；

c) 系统的功能、性能的降级情况

d) 系统的各种误操作模式：

e)  系统的各种故障模式(如数据超范围、死锁)；

f)  测试在多机系统出现故障需要切换时系统的功能和性能的连续平稳性。

注：可用故障树分析技术检测误操作模式和故障模式。

4．3．3  易恢复性方面

  从易恢复性方面考虑，可测试：

  a)  具有自动修复功能的系统的自动修复的时间；

  b)  系统在特定的时间范围内的平均宕机时间；

c) 系统在特定的时间范围内的平均恢复时间；

d) 系统的可重启动并继续提供服务的能力；

e)  系统的还原功能的还原能力。

4. 4  易用性

4. 4.1  易理解性方面

从易理解性方面考虑，可测试：

a)  系统的各项功能，确认它们是否容易被识别和被理解；

b)  要求具有演示能力的功能，确认演示是否容易被访问、演示是否充分和有效；

c)  界面的输入和输出。确认输入和输出的格式和含义是否容易被理解。

4．4．2  易学性方面

 从易学性方面考虑，可测试系统的在线帮助，确认在线帮助是否容易定位，是否有效；还可对照用户手册或操作手册执行系统，测试用户文档的有效性。

4．4．3  易操作性方面

 从易操作性方面考虑。可测试：

 a)  输入数据，确认系统是否对输入数据进行有效性检查；

 b)  要求具有中断执行的功能。确认它们能否在动作完成之前被取消：

c)  要求具有还原能力(数据库的事务回滚能力)的功能，确认它们能否在动作完成之后被撤消；

d)  包含参数设置的功能，确认参数是否易于选择、是否有缺省值；

e)  要求具有解释的消息，确认它们是否明确；

f)  要求具有界面提示能力的界面元素，确认它们是否有效；

g)  要求具有容错能力的功能和操作，确认系统能否提示出错的风险、能否容易纠正错误的输入、能否从差错中恢复：

h)  要求具有定制能力的功能和操作，确认定制能力的有效性；

i)  要求具有运行状态监控能力的功能，确认它们的有效性。

注：以正确操作、误操作模式、非常规操作模式和快速操作为框架设计测试用例，误操作模式有错误的数据类型作参数、错误的输人数据序列、错误的操作序列等。如有用户手册或操作手册。可对照手册逐条进行测试。

4．4．4  吸引性方面

       从吸引性方面考虑，可测试系统的人机交互界面能否定制。

4．5  效率

4．5．1  时间特性方面

      从时间特性方面考虑，可测试系统的响应时间、平均响应时间、响应极限时间，系统的吞吐量、平均吞吐量、极限吞吐量，系统的周转时间、平均周转时间、周转时间极限。

    注1：响应时间指系统为完成一项规定任务所需的时间：平均响应时间指系统执行若干并行任务所需的平均时间；响应极限时间指在最大负载条件下．系统完成某项任务需要时间的极限；吞吐量指在给定的时间周期内系统能成功完成的任务数量：平均吞吐量指在一个单位时间内系统能处理并发任务的平均数：极限吞吐量指在最大负载条件下。在给定的时间周期内。系统能处理的最多并发任务数；周转时间指从发出一条指令开始到一组相关的任务完成的时间；平均周转时间指在一个特定的负载条件下．对一些并发任务。从发出请求到任务完成所需要的平均时间；周转时间极限指在最大负载条件下，系统完成一项任务所需要时间的极限。在测试时。应标识和定义适合于软件应用的任务。并对多项任务进行测试．而不是仅测一项任务。

     注2：软件应用任务的例子。如在通信应用中的切换、数据包发送。在控制应用中的事件控制，在公共用户应用中由用户调用的功能产生的一个数据的输出等。

4．5．2  资源利用性方面

    从资源利用性方面考虑。可测试系统的输入，输出设备、内存和传输资源的利用情况：

    a)  执行大量的并发任务，测试输入/输出设备的利用时间；

    b)  在使输入/输出负载达到最大的系统条件下．运行系统，测试输入/输出负载极限；

    c)  并发执行大量的任务，测试用户等待输入/输出设备操作完成需要的时间；

    注：建议调查几次测试与运行实例中的最大时间与时间分布。

    d)  在规定的负载下和在规定的时间范围内运行系统，测试内存的利用情况；

    e)  在最大负载下运行系统，测试内存的利用情况；

    f)  并发执行规定的数个任务．测试系统的传输能力；

    g)  在系统负载最大的条件下和在规定的时间周期内，测试传输资源的利用情况；

    h)  在系统传输负载最大的条件下．测试不同介质同步完成其任务的时间周期。

4．6  维护性

4．6．1  易分析性方面

    从易分析性方面考虑，可设计各种情况的测试用例运行系统，并监测系统运行状态数据，检查这些数据是否容易获得、内容是否充分。如果软件具有诊断功能。应测试该功能。

4．6．2  易改变性方面

    从易改变性方面考虑，可测试能否通过参数来改变系统。

4．6．3  稳定性方面

本标准暂不推荐软件稳定性方面的测试内容。

4．6．4  易测试性方面

从易测试性方面考虑，可测试软件内置的测试功能确认它们是否完整和有效。

4．7  可移植性

4．7．1  适应性方面

 从适应性方面考虑，可测试：

 a)  软件对诸如数据文件、数据块或数据库等数据结构的适应能力；

 b)  软件对硬件设备和网络设施等硬件环境的适应能力；

 c)  软件对系统软件或并行的应用软件等软件环境的适应能力；

 d)  软件是否易于移植。

4．7．2  易安装性方面

 从易安装性方面考虑，可测试软件安装的工作量、安装的可定制性、安装设计的完备性、安装操作的简易性、是否容易重新安装。

 注1：安装设计的完备性可分为三级：

 a)  最好：设计了安装程序，并编写了安装指南文档；

b)  好：仅编写了安装指南文档；    ·

c)  差：无安装程序和安装指南文档。

注2：安装操作的简易性可分为四级：

a)  非常容易：·只需启动安装功能并观察安装过程

b)  容易：只需回答安装功能中提出的问题；

c)  不容易：需要从表或填充框中看参数；

d)  复杂：需要从文件中寻找参数，改变或写它们。

4．7．3  共存性

从共存性方面考虑，可测试软件与其他软件共同运行的情况。

4．7．4  易替换性

       当替换整个不同的软件系统和用同一软件系列的高版本替换低版本时在易替换性方面，可考虑测试：

 a)  软件能否继续使用被其替代的软件使用过的数据：

 b)  软件是否具有被其替代的软件中的类似功能。

4．8  依从性

    当软件在功能性、可靠性、易用性、效率、维护性和可移植性方面遵循了相关的标准、约定、风格指南或法规时，应酌情进行测试。

5  测试环境

     测试环境应包括测试的运行环境和测试工具环境。

      测试的运行环境一般应符合软件测试合同(或项目计划)的要求，通常是软件及其所属系统的正式工作环境。

       测试工具一般要求是经过认可的工具。

6  测试方法

      系统测试一般应采用黑盒测试方法。

7  测试过程

7．1  测试策划

 测试分析人员应根据测试合同(或项目计划)、被测软件的开发合同或系统/子系统设计文档分析被测系统，并确定以下内容：

 a)  确定测试充分性要求。确定测试应覆盖的范围及每一范围所要求的覆盖程度。

 b)  确定测试终止的要求。指定测试过程正常终止的条件(如测试充分性是否达到要求)。并确定导致测试过程异常终止的可能情况(如接口错误)。

c)  确定用于测试的资源要求，包括软件(如操作系统、编译软件、静态分析软件、测试数据产生软件、测试结果获取和处理软件、测试驱动软件等)、硬件(如计算机、设备接口等)、人员数量、人员技能等。

d)  确定需要测试的软件特性。根据软件开发合同或系统，子系统设计文档的描述确定系统的功能、性能、状态、接口、数据结构、设计约束等内容和要求．对其标识。若需要．将其分类。并从中确定需测试的软件特性。

e)  确定测试需要的技术和方法，如测试数据生成和验证技术、测试数据输入技术、测试结果获取技术、是否使用标准测试集等。

f)  根据测试合同(或项目计划)的要求和被测软件的特点确定测试准出条件。

g)  确定由资源和被测系统决定的系统测试活动的进度。

h)  对测试工作进行风险分析与评估，并制订应对措施。

 根据上述分析研究结果，编写系统测试计划。

      应对系统测试计划进行评审。评审测试的范围和内容、资源、进度、各方责任等是否明确，测试方法是否合理、有效和可行，风险的分析、评估与对策是否准确可行，测试文档是否符合规范。测试活动是否独立。当测试活动由被测软件的供方实施时，系统测试计划的评审应纳入软件开发过程的阶段评审；当测试活动由独立的测试机构实施时，系统测试计划应通过软件的需方、供方和有关专家参加的评审。在系统测试计划通过评审后，进入下一步工作；否则，需要重新进行系统测试的策划。

7．2  测试设计

     测试设计工作由测试设计人员和测试程序员完成，一般根据系统测试计划完成以下工作：

 a)  设计测试用例。将需测试的软件特性分解，针对分解后的每种情况设计测试用例。

 b)  获取测试数据．包括获取现有的测试数据和生成新的数据．并按照要求验证所有数据。

 c)  确定测试顺序，可从资源约束、风险以及测试用例失效造成的影响或后果几个方面考虑。

 d)  获取测试资源，对于支持测试的软件，有的需要从现有的工具中选定，有的需要开发。

  e)  编写测试程序．包括开发测试支持工具。

  f)  建立和校准测试环境。

  g)  编写系统测试说明。

         应对系统测试说明进行评审。评审测试用例是否正确、可行和充分。测试环境是否正确、合理。测试文档是否符合规范。当测试活动由被测软件的供方实施时，评审应由软件的供方组织，软件的需方和有关专家参加；当测试活动由独立的测试机构实施时，评审应由测试机构组织，软件的需方、供方和有关专家参加。在系统测试说明通过评审后，进入下一步工作；否则，需要重新进行系统测试的设计和实现。

7．3  测试执行

      执行测试的工作由测试员和测试分析员完成。

      测试员的主要工作是执行系统测试计划和系统测试说明中规定的测试项目和内容。在执行过程中。测试员应认真观察并如实地记录测试过程、测试结果和发现的差错，认真填写测试记录。

 测试分析员的工作主要有如下两方面：

 a)  根据每个测试用例的期望测试结果、实际测试结果和评价准则判定该测试用例是否通过。如果不通过。测试分析员应认真分析情况。并根据以下情况采取相应措施：

     1)  系统测试说明和测试数据的差错。采取的措施是：改正差错，将改正差错信息详细记录。然后重新运行该测试。

2) 执行测试步骤时的差错。采取的措施是：重新运行未正确执行的测试步骤。

3) 测试环境(包括软件环境和硬件环境)中的差错。采取的措施是：修正测试环境，将环境修正情况详细记录，重新运行该测试：若不能修正环境，记录理由，再核对终止情况。

4) 系统实现的差错。采取的措施是：填写软件问题报告单，可提出软件修改建议，然后继续进行测试；或者把差错与异常终止情况进行比较，核对终止情况。软件变更完毕后，应根据情况对其进行回归测试。

5) 系统设计的差错。采取的措施是：填写软件问题报告单，可提出软件修改建议，然后继续进行测试；或者把差错与异常终止情况进行比较，核对终止情况。软件变更完毕后，应根据情况对其进行回归测试或重新组织测试，回归测试中需要相应地修改测试设计和数据。

6) 当所有的测试用例都执行完毕，测试分析员要根据测试的充分性要求和失效记录，确定测试工作是否充分，是否需要增加新的测试。当测试过程正常终止时，如果发现测试工作不足，应对软件系统进行补充测试(具体要求见7．2和7．3)，直到测试达到预期要求，并将附加的内容记录在系统测试报告中；如果不需要补充测试．则将正常终止情况记录在系统测试报告中。当测试过程异常终止时。应记录导致终止的条件、未完成的测试和末被修正的差错。

7．4  测试总结

       测试分析员应根据软件开发合同或系统/子系统设计文档、系统测试计划、系统测试说明、测试记录和软件问题报告单等，分析和评价测试工作，一般包括下面几项工作：

a)  总结系统测试计划和系统测试说明的变化情况及其原因，并记录在系统测试报告中；

 b)  对测试异常终止情况，确定未能被测试活动充分覆盖的范围。并将理由记录在系统测试报告中；

c)  确定未能解决的软件测试事件以及不能解决的理由，并将理由记录在系统测试报告中；

 d)  总结测试所反映的软件系统与软件开发合同或系统/子系统设计文档之间的差异，记录在系统测试报告中；

e)  将测试结果连同所发现的差错情况同软件开发合同或系统/子系统设计文档对照，评价软件系统的设计与实现，提出软件改进建议，记录在测试报告中：

f)  编写系统测试报告，该报告应包括：测试结果分析、对软件系统的评价和建议；

g)  根据测试记录和软件问题报告单编写测试问题报告。

 应对系统测试的执行活动、系统测试报告、测试记录、测试问题报告进行评审。评审测试执行活动的有效性、测试结果的正确性和合理性。评审是否达到了测试目的、测试文档是否符合要求。当测试活动由被测软件的供方实施时，评审应由软件的供方组织，软件的需方和有关专家参加；当测试活动由独立的测试机构实施时。评审应由测试机构组织．软件的需方、供方和有关专家参加。

8  文档

 系统测试完成后形成的文档一般应有：

1. 系统测试计划；
2. 系统测试说明；
3. 系统测试报告；
4. 系统测试记录和／或测试日志；
5. 系统测试问题报告。

可根据需要对上述文档及文档的内容进行裁剪。