系统测试的目的是确认系统的各项功能和性能是否满足研制技术要求。通过实施预定的测试计划和测试执行活动确认软件的功能需求、性能需求和文档需求。
本软件的测试活动遵循GJB5000A二级标准，具体要求如下：
1）按照实际情况搭建测试环境；
2）需要进行软件配置项测试和验收测试。
a）由独立的软件测试组实施软件配置项测试，测试时，功能、性能、外部接口覆盖应达到100%；
b）验收测试组由研发单位相关技术领域专家、第三方评测机构相关测试人员及用户代表组成。
为保证测试的顺利进行，同时也为以后系统的维护和升级，在测试过程中必须生成相应的文档，包括测试计划、测试说明、测试细则、测试报告、测试问题记录等测试文档。测试完成需要提交最终的测试结果报告，包括软件配置及版本、硬件配置、测试用例、测试记录和测试总结报告等文档。
在进行系统开发过程中，成立系统测试组织，负责对系统的整个开发过程进行跟踪测试，并形成测试报告，反馈给开发团队。各个分系统的软件单元测试由系统开发人员完成，不进行统一的测试。其他的测试均以测试小组为主进行。
1.1.1.1 测试流程及细则
1.1.1.1.1 系统测试流程
图 4.10 1系统测试流程图
1.1.1.1.2 流程细则
1)需求阶段
(1)在测试工作开始前，测试人员了解项目需求收集结果，包括项目需求规格说明、功能结构及模块划分等。
(2)测试人员了解项目需求变更。
(3)测试人员会同项目主管根据软件需求制定并确认《测试计划》，围绕测试的目标，制定相应的测试策略及计划，测试计划内容中要体现包括被评估被测系统之间的关系，系统间的架构关联、用户的性能需求、用户的行为模式。测试计划的步骤分为确定测试需求、进行风险评估、确定资源、确定测试日程表、生成测试计划。
2)设计编码阶段
(1)测试人员确定并描述测试用例、检查评估测试覆盖、创建和确认测试程序、创建和维护测试外部数据集，形成《测试大纲》。
(2)项目开发组对完成的功能模块进行单元测试，测试人员参与单元测试过程；单元测试完成，产生单元测试报告。
(3)所有单元测试及相应的修改完成后，项目开发组组织进行集成测试，测试人员参与集成测试过程；集成测试完成后，产生集成测试报告。
3)测试阶段
(1)项目开发组完成集成测试后，提交测试所要求的待测软件及各种文档、手册、前期测试报告(《需求分析》、《软件设计规范》和《测试报告》)。
(2)测试组安排和协调测试设备、环境等准备工作。
(3)测试组按测试计划、测试大纲的要求对待测软件进行有效性测试、集成测试。
(4)测试过程中，可能会出现意外中断测试进程的错误，因此测试组会针对这种情况，确定问题的实际原因，填写《错误报告》。
(5)对修改后的情况进行复合，重置测试环境，然后重新执行测试。
(6)测试结束后，测试人员对测试结果进行汇总；测试主管审核测试结果，得出测试结论；测试组进行测试分析和评估，编写《测试分析报告》。
(7)提交《测试分析报告》。
(8)将所有文件存档。
(9)对测试未通过的待测软件，测试人员汇总并向项目开发组提交测试错误报告。
(10)项目开发组对测试错误报告进行确认，对有争议的问题可由上一级技术负责人确认和仲裁；项目开发组针对测试错误报告进行逐项修改，修改完成后再将待测软件及错误修改情况提交及测试组进行回归测试。
(11)待测软件测试通过后，项目测评结束。
(12)制作《用户操作手册》(帮助文件)。
4)用户测试阶段
(1)项目开发组与用户方商定测试计划、测试内容、测试环境等。
(2)项目测试组向用户方提供项目内部测试汇总报告。
(3)由项目开发组或测试组配合用户进行用户方测试。
(4)由用户方编制用户方软件测试报告(程序错误报告和测试分析报告)，若用户方不愿或无法编制测试报告，则经与用户方协商由我方测试人员编制用户方测试报告，经用户方签字后即可生效。
(5)项目经理与用户方对用户方测试进行确认。
1.1.1.1.3 流程注意事项
根据《软件开发规范》仔细检查软件的界面是否合乎要求，应注意提示信息和软件开发商信息是否正确，小的图标是否合乎要求；检查菜单当中的各项功能和功能按钮是否能正确使用。
根据《软件开发规范》和《用户需求》及《软件详细设计》设计测试用例。(以边界值法、等价类划分法为主)。对功能界面要求注意与功能相关的信息显示及显示位置是否正确。数据输入界面应注意文字格式及数字和文字的区别。是否能够正确保存信息。数据查询(显示)界面应注意显示信息是否正确和完整。是否能正确查询。对打印功能要求注意打印出的报表是否正确。(包括报表各项信息、数据信息和报表字体等)。
这一项测试主要是对软件的错误处理功能进行测试，即进行错误的操作或输入错误的数据，检查软件对这些情况是否能做出判断并予以提示。
特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。
妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
1.1.1.2 测试环境搭建
搭建测试环境是软件测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、计算机、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。测试环境尽量模拟用户的真实使用环境。这里所涉及到的测试环境指得是能满足各应用系统各自的集成测试以及各应用软件集成后的系统测试需求的应用系统软件的测试环境。
1.1.1.2.1 确定测试环境的组成
1)部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；
2)用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；
3)用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；
4)是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份；
5)测试中所需要使用的网络环境。由于测试结果与局域网内的网络速度有关，那么应该保证计算机的网卡、网线以及用到的集线器、交换机都不会成为瓶颈。
1.1.1.2.2 确定测试工具
1)单元测试工具
单元测试是最小粒度的测试，以测试某个功能或代码块。因为测试过程中需要知道内部程序设计和编码的细节，所以一般由程序员来做。本系统的开发采取C++技术路线，因此应针对不同的开发语言与开发工具采用不同的测试工具。如Java开发人员采用JUnit作为单元测试工具。JUnit是一个开发源代码的Java测试框架，用于编写和运行可重复的测试，它和Eclipse平台有着良好的嵌入结合。它的优点主要有：
(1)可以使测试代码与产品代码分开；
(2)针对某一个类的测试代码通过较少的改动便可以应用于另一个类的测试。
(3)易于集成到测试人员的构建过程中，JUnit和Ant的结合可以实施增量开发。
2)自动化测试工具
本系统的测试过程包含大量的集成测试、回归测试，由于这些测试的工作量很大，重复性强，因此常常需要自动化测试工具的支持。本系统测试中选取的自动化测试工具是WinRunner。WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。用WinRuuner创建一个测试，只需点击鼠标和键盘，完成一个标准的业务操作流程，WinRunner自动记录你的操作并生成所需的脚本代码。这样，即使计算机技术知识有限的业务用户轻松创建完整的测试。你还可以直接修改测试脚本以满足各种复杂测试的需求。同时WinRunner还提供这多种测试创建方式，以满足测试团队中业务用户和专业技术人员的不同需求。
3)压力测试工具
本系统管理着大量的基础数据，对系统的负载要求很高，因此测试中需要进行压力测试。压力测试工具选用LoadRunner。LoadRunner种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner的测试对象是整个企业的系统，它通过模拟千万用户实施并发操作行为和实行实时性能监测，来帮助用户更快的查找和发现问题。此外，LoadRunner能支持广范的协议和技术，为系统的特殊环境提供特殊的解决方案。一旦测试完毕后，LoadRunner收集汇总所有的测试数据，并为用户提供高级的分析和报告工具，以便迅速查找到性能问题并追溯原由。使用LoadRunner的Web交易细节监测器，可以了解到将所有的图象、框架和文本下载到每一网页上所需的时间。此外，LoadRunner能支持广范的协议和技术，为系统的特殊环境提供特殊的解决方案。
1.1.1.2.3 管理测试环境
1)设置专门的测试环境管理员角色
每个测试项目或测试小组都应当配备一名专门的测试环境管理员，其职责包括：测试环境的搭建。包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册的编写；记录组成测试环境的各台机器的硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况；测试环境各项变更的执行及记录；测试环境的备份及恢复；操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理。
2)记录好测试环境管理所需的各种文档
测试环境的各台机器的硬件环境文档，测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因以及所形成的备份文件的文件名和获取方式；用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测应用时所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录。
3)测试环境访问权限的管理
为每个访问测试环境的测试人员和开发人员设置单独的用户名和密码。访问操作系统、数据库、WEB服务器以及被测应用等所需的各种用户名、密码、权限，由测试环境管理员统一管理；测试环境管理员拥有全部的权限，开发人员只有对被测应用的访问权限和查看系统日志(只读)，测试组成员不授予删除权限，用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中。
4)测试环境的备份和恢复
测试环境必须是可恢复的，否则将导致原有的测试用例无法执行，或者发现的缺陷无法重现，最终使测试人员已经完成的工作失去价值。因此，应当在软件测试环境发生重大变动时进行完整的备份，例如使用Ghost对硬盘或某个分区进行镜像备份。
1.1.1.3 测试工作组织
为保证项目的质量，将成立专门的系统测试小组，在项目经理的统一领导之下，完成本次项目的测试工作。
项目测试小组组织结构如下图所示：
图 4.10 2测试小组组织结构图
各角色的职责和分工如下表所示：
表 4.10 1角色职责与分工
1.1.1.4 测试用例制订
测试用例是测试的前提与基础，测试用例的设计不仅仅限于尽量找出系统中存在的问题，而在很大程度上也起着验证功能的实现与预先设计是否一致的作用，达到验证系统功能正确性的目的，同时还能够评估测试的覆盖范围是否能够满足全部的功能要求，为整个系统全面、科学的质量评估提供基础。
在测试用例设计上，测试人员对每一个要测试的功能模块进行用例设计时，要考虑以下几个方面：
1)正常功能用例设计(在正常业务功能情况下的合理输入，验证模块功能的正确性)
2)功能的容错性设计(在非正常情况使用下，验证功能模块的容错性，如不合理的输入、错误数据类型、定义域之外的值)
3)边界值测试设计(对每一个功能模块进行边界条件的测试：上限、下限、临界值)
4)压力测试设计(对常用功能进行压力测试用例设计)
5)用户界面测试设计(对用户界面的用例设计，如按TAB键的顺序，菜单的布局等)
6)易用性测试设计指导(界面友好性、提示是否清晰等)
1.1.1.5 测试内容
与开发过程类似，测试过程也必须分步骤进行，每个步骤在逻辑上是前一个步骤的继续。根据系统研制技术要求，对项目系统进行测试。本项目的应用软件系统由若干个分系统组成，每个分系统又由许多模块组成，按《测试计划》对验收对象进行逐项测试，并详细记录每一项测试结果，并将这些结果分别与预期的结果比照分析，然后编写《测试报告》。应用系统软件测试内容如下：
1.1.1.5.1 模块测试
每个应用程序模块完成后，进行模块测试。模块测试的目的在于通过大量、反复的测试，尽可能地捕获程序编写时的编码及应用处理上的错误，并加以改正，使程序编写时的错误在这一测试环节得到控制。
1.1.1.5.2 分系统测试
分系统的测试首先对各功能模块、各个分系统进行全面的性能测试，压力测试的目的是希望能够通过测试，得知在极短时间内对系统进行大量并发访问，是否会对系统造成瞬间无法承受的压力冲击，致使其运行异常甚至崩溃。压力测试可以使我们获知系统的耐压程度，在必要时采取适当的紧急防护措施，如控制、分散等措施，减低缓解系统瞬间压力，防止尖峰时刻的出现，使系统得以稳定地运行。然后，对系统中使用频率高的功能进行压力测试，以及对容易产生并发的操作进行严格并发测试。
这时需要考虑的问题是：
在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
一个模块的功能是否会对另一个模块的功能产生不利的影响；
各个模块功能组合起来，能否达到整个分系统预期要求的功能；
全局数据结构是否有问题；
单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
因此在单元测试的同时可进行组装测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。
1.1.1.5.3 分系统测试
应用分系统测试是把经过测试的分系统装配成一个完整的分系统来测试，主要检测组装在一起的多个分系统运转是否符合分系统设计要求。在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。在这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。
1.1.1.5.4 性能测试
系统的性能是一个很重要的参数，包括系统的效率、响应时间及处理能力。在测试中，为每个应用设置响应时间、处理速度量度，评估系统的最高处理能力，在发现系统的性能不满足要求进，需进行相应措施对系统的性能进行调整。
1.1.1.5.5 功能性测试
功能性测试是对项目实现的功能进行测试，一般采用的是独立测试方法。
独立测试是将本项目开发实现的功能一一进行独立测试。在测试过程中，将针对每一个功能制定相应的测试个案，进行严格的功能测试。如测试结果与实现要求不符，将由开发人员进行改进及完善，最终达到功能要求。
测试中发生问题时，编程人员会改动程序以便解决问题。系统将在修改后进行重新测试。此时其进行的测试不仅针对改动部分，还应对原已通过独立测试的部分进行重新测试。
1.1.1.5.6 稳定性测试
系统稳定性的测试涵盖系统运行的多个方面，主要包括：
1.对软件多次测试，长时间运行，是否正常运行；
2.长时间对软件开启关闭软件和系统是否正常；
3.软件长时间执行某个业务后切换到别的不同的业务操作是否受影响；
4.软件长时间开启但是不执行任何操作，然后检查能否正常执行业务操作；
5.软件长时间对日常的用户数进行操作运行，观察系统内存占用率是否越来越大，可用内存是否减少，内存是否溢出，饱和运算内存是否占用过大、是否溢出；
6.软件长时间开启正常运行，观察系统CPU是否使用率是否越来越高,在饱和运算时,观察系统cpu使用率，饱和运算结束时，CPU使用率能否回到正常值；
7.在系统运行过程中，对系统饱和施压，观察系统的各种性能指标，以及服务器的指标、观察服务器电源电压是否降低、机箱、内存、硬盘、CPU等硬件指标来观察系统的稳定性；
8.模拟平常的压力，模拟实际中日常的用户数进行操作。要存、取、建、查数据，验证数据库是否正常读写；
9.模拟饱和压力测试，模拟实际中日常最大用户数进行操作。要存、取、建、查数据，验证数据库是否正常读写，系统运行是否受影响；
10.多个关联软件，存在接口访问数据交流，关闭其中的一个软件，检查软件是否稳定运行；
11.多对不同功能模块软件同时操作是否能够正常响应，数据库运行是否正常等等。
1.1.1.5.7 容量测试
系统在试运行之前，我们建议进行容量测试，以找出系统运行后可处理的最大处理容量，确保能够平滑地过渡或避开业务处理高峰期。与此同时，通过对业务处理高峰期时系统硬件资源情况的占有量的获取，能够有效地调配系统资源。
通过容量测试，得知系统承载量，并结合业务发展增长量，可以推算出需要更换相关硬件的时间，以便用户可以提前做好应对准备。
1.1.1.5.8 配置测试
软件配置测试是用于测试和验证软件，在不同的软件和硬件配置中进行运行。配置测试就是测试软件是否和系统的其他与之交互的元素之间兼容，如操作系统、硬件等，验证被测软件在不同的软件和硬件配置中的运行情况，能否稳定无障碍运行、满足业务需求。
1.1.1.5.9 集成测试
集成测试也叫做组装测试或联合测试，就是对各分系统组合起来的程序进行测试，主要检测应用系统运转是否通顺，分系统之间的协同工作是否正确，业务功能是否达到预期要求。
1.1.1.5.10 界面测试
应用软件界面要符合现行标准和用户习惯，确保整个软件风格一致。界面测试要从友好性、易操作性、美观性、布局合理、分类科学、标题描述准确等方面入手。测试用例的设计要重点掌握以下几点：
背景和前景的颜色是否协调，颜色反差是否用得恰当；
软件的图标、按钮、对话框等外观风格是否一致，美观效果所要求的屏幕分辨率；
Ø 窗口元素的布局是否合理和一致；
Ø 各种字段标题的信息描述是否准确；
Ø 快捷键、按钮、鼠标等操作在软件中是否一致；
Ø 窗口及报表的现实比例和格式是否能适应用户的预期要求；
Ø 误操作引起的错误提示是否友好；
Ø 活动窗口和被选中的记录是否高亮显示；
Ø 是否有帮助信息，菜单导航是否正常执行；
Ø 检查一些特殊域和特殊控件是否运行。
1.1.1.5.11 出所测试
系统出所测试是按照系统需求规格说明书的要求，制定系统出所测试大纲，并完成系统出所测试大纲的评审，按照系统出所测试大纲的要求，完成系统出所测试，并提交系统出所测试报告，并完成系统出所测试问题的归零。
1.1.1.5.12 验收测试
验收测试组由研发单位相关技术领域专家、第三方评测机构相关测试人员及用户代表组成。验收测试把系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是在用户积极参与下进行的，而且可能主要使用实际数据(系统将来要处理的信息)进行测试。验收测试的目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书中的错误。
1.1.1.5.13 灾难恢复测试
灾难恢复测试是指在模拟灾难事故发生的情况下，对系统的恢复情况进行测试及彩排。要尽可能地找出可能发生的灾难性事故，并一一进行模拟，查看系统的恢复情况。灾难恢复测试能够反映出系统备份的准确性及完整性，以及自动恢复功能的强弱，出具不同灾难恢复所需的时间数据，以此可以估算出在灾难发生时对用户所造成的影响及忍受程度。
1.1.1.6 测试方法
1.1.1.6.1 静态测试和动态测试
静态测试的基本特征是在对软件进行分析、检查和测试时不实际运行被测程序。按照进行静态测试的正式程度及其在软件生产质量管理和质量控制中的作用，可分为工程测试、正式测试、审核测试和检查性测试。静态测试可用于对各种软件文档的测试，常用于软件开发过程的早期阶段，主要有结构化走通(walk-through)和Fagan检查等方法。
动态测试的基本特征是通过运行软件来检验软件的动态行为和运行结果的正确性，包括被测程序、测试数据和软件需求规约三个基本要素。根据动态测试在软件开发过程中所处的阶段及其作用，可分为单元测试、系统测试、集成测试、验收测试和回归测试，贯穿于整个软件开发过程的各个阶段。
1.1.1.6.2 黑盒测试方法
黑盒测试(black—boxtesting)又称功能测试、数据驱动测试或基于规范的测试。用这种方法进行测试时，被测程序被当作看不见内部的黑盒。在完全不考虑程序内部结构和内部特性的情况下，测试者仅依据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性。因此黑盒测试是从用户观点出发的测试，黑盒测试直观的想法就是既然程序被规定做某些事，那我们就看看它是不是在任何情况下都做的对。完整的“任何情况”是无法验证的，为此黑盒测试也有一套产生测试用例的方法，以产生有限的测试用例而覆盖足够多的“任何情况”。由于黑盒测试不需要了解程序内部结构，所以许多高层的测试如确认测试、系统测试、验收测试都采用黑盒测试。
黑盒测试主要是为了发现以下几类错误：
是否有不正确或遗漏了的功能；
在接口上，输入能否正确的接受，能否输出正确的结果；
是否有数据结构错误或外部信息(例如数据文件)访问错误；
性能上是否能够满足要求；
是否有初始化或终止性错误。
黑盒测试首先是程序通常的功能性测试，要求：
每个软件特性必须被一个测试用例或一个被认可的异常所覆盖。
用数据类型和数据值的最小集测试。
用一系列真实的数据类型和数据值运行，测试超负荷、饱和及其他“最坏情况”的结果；
用假想的数据类型和数据值运行，测试排斥不规则输入的能力；
对影响性能的关键模块，如基本算法、应测试单元性能(包括精度、时间、容量等)。
不仅要考核“程序应该做什么?”还要考察“程序是否做了不该做的”同时还要考察程序在其他一些情况下是否正常。这些情况包括数据类型和数据值的异常等等。下述几种方法：(a)等价类划分，(b)因果图方法，(c)边值分析法，(d)猜错法，(e)随机数法，就是从更广泛的角度来进行黑盒测试。每一个方法都力图能涵盖更多的“任何情况”，但又各有长处，综合使用这些方法，会得到一个较好的测试用例集。
1)等价类划分
等价类划分是一种典型的黑盒测试方法。等价类是指某个输入域的集合。它表示对揭露程序中的错误来说，集合中的每个输入条件是等效的。因此我们只要在一个集合中选取一个测试数据即可。等价类划分的办法是把程序的输入域划分成若干等价类，然后从每个部分中选取少数代表性数据当作测试用例。这样就可使用少数测试用例检验程序在一大类情况下的反映。
在考虑等价类时，应该注意区别以下两种不同的情况：
有效等价类：有效等价类指的是对程序的规范是有意义的、合理的输入数据所构成的集合。在具体问题中，有效等价类可以是一个，也可以是多个。
无效等价类：无效等价类指对程序的规范是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。
确定等价类有以下几条原则：
如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类。例如，程序的规范中提到的输入条包括“……项数可以从1到999……”，则可取有效等价类为“项数＜999”，无效等价类为“项数＜l，，及“项数＞999”。
输入条件规定了输入值的集合，或是规定了“必须如何”的条件，则可确定一个有效等价类和一个无效等价类。如某程序涉及标识符，其输入条件规定“标识符应以字母开头……”则“以字母开头者”作为有效等价类，“以非字母开头”作为无效等价类。
如果我们确知，已划分的等价类中各元素在程序中的处理方式是不同的，则应将此等价类进一步划分成更小等价类。
根据已列出的等价类表，按以下步骤确定测试用例：
为每个等价类规定一个唯一的编号；
设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖；
设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步，使所有无效等价类均被覆盖。这里强调每次只覆盖一个无效等价类。这是因为一个测试用例中如果含有多个缺陷，有可能在测试中只发现其中的一个，另一些被忽视。等价类划分法能够全面、系统地考虑黑盒测试的测试用例设计问题，但是没有注意选用一些“高效的”、“有针对性的”测试用例。后面介绍的边值分析法可以弥补这一缺点。
2)因果图
等价类划分法并没有考虑到输入情况的各种组合。这样虽然各个输入条件单独可能出错的情况已经看到了，但多个输入情况组合起来可能出错的情况却被忽略。采用因果图方法能帮助我们按一定步骤选择一组高效的测试用例，同时，还能为我们指出程序规范的描述中存在什么问题。
利用因果图导出测试用例需要经过以下几个步骤：
分析程序规范的描述中哪些是原因，哪些是结果。原因常常是输入条件或是输入条件的等价类。结果是输出条件。
分析程序规范的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。
由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用持殊的符号标明约束条件。把因果图转换成判定表。把判定表的每一列写成一个测试用例。
3)边值分析法
边值分析法是列出单元功能、输入、状态及控制的合法边界值和非法边界值，设计测试用例，包含全部边界值的方法。典型地包括IF语句中的判别值，定义域、值域边界，空或畸形输入，末受控状态等。边值分析法不是一类找一个例子的方法，而是以边界情况的处理作为主要目标专门设计测试用例的方法。另外，边值分析不仅考查输入的边值，也要考虑输出的边值。这是从人们的经验得出的一种有效方法。人们发现许多软件错误只是在下标、数据结构和标量值的边界值及其上、下出现，运行这个区域的测试用例发现错误的概率很高。
用边值分析法设计测试用例时，有以下几条原则：
如果输入条件规定了取值范围，或是规定了值的个数，则应以该范围的边界内及刚刚超出范围的边界外的值，或是分别对最大、最小及稍小于最小、稍大于最大个数作为测试用例。如有规范“某文件可包含l至255”个记录……“，则测试用例可选1和255及0和256等。
针对规范的每个输出条件使用原则〔a〕等价类划分。
如果程序规范中提到的输入或输出域是个有序的集合(如顺序文件、表格等)就应注意选取有序集的第一个和最后一个元素作为测试用例。
分析规范，尽可能找出可能的边界条件。一个典型的边值分析例子是三角形分类程序。选取a，b，c构成三角形三边，“任意两边之和大于第三边”为边界条件。边值分析相等价类划分侧重不同，对等价类划分是一个补充。如上述三角形问题，选取a＝3，b＝4，c＝5，a＝2，b＝4，c＝7则覆盖有效和无效等价类。如果能在等价类划分中注入边值分析的思想。在每个等价类中不只选取一个覆盖用例，而是进而选取该等价类的边界值等价类划分法将更有效，最后可以用边值分析法再补充一些测试用例。
4)猜错法
猜错法在很大程度上是凭经验进行的，是凭人们对过去所作的测试工作结果的分析，对所揭示的缺陷的规律性作直觉的推测来发现缺陷的。
猜错法充分发挥人的经验，在一个测试小组中集思广益，方便实用，特别在软件测试基础较差的情况下，很好地组织测试小组(也可以有外来人员)进行错误猜测，是有效的测试方法。
5)随机数法
即测试用例的参数是随机数。它可以自动生成，因此自动化程度高。使用大量随机测试用例测试通过的程序会提高用户对程序的信心。但其关键在于随机数的规律是否符合使用实际。
1.1.1.6.3 白盒测试方法
白盒法测试，是以程序的内部逻辑为基础，有选择地执行程序中最有代表性的通路。因此，白盒法也叫逻辑覆盖法。最彻底的逻辑覆盖法，是覆盖程序巾的诲一条通路。但当程序中含有大量循环时，要执行每一条通路是可能的。因此，我们只能寄希望于程序的覆盖度尽可能高一些。目前常用的一些覆盖标准有：语句覆盖、判定覆盖、条件澄盖、判定条件覆盖、条件组合覆盖、路径覆盖等。
白盒法考虑的是测试用例对程序内部逻辑的覆盖程度，所以又称为逻辑覆盖法。最彻底的白盒法是覆盖程序中的每一条路径，但这不可能，我们希望覆盖的路径尽可能多一些。为了衡量测试的覆盖程度，需要建立一些标准，目前常用的一些覆盖标准是：
Ø 语句覆盖；
Ø 判定覆盖；
Ø 条件覆盖；
Ø 判定/条件覆盖；
Ø 条件组合覆盖。
Ø 语句覆盖
程序的某次运行一般并不能执行到其中的每一个语句，因此，如果某语句含有一个错误，而它在测试中没执行，这个错误就不可能被发现。为了提高发现错误的可能性，应该在测试时至少要执行程序中的每一个语句。
所谓“语句覆盖”测试标准，它的含义是：选择足够的测试用例，使得程序中每个语句至少都能执行一次。
2)判定覆盖
比“语句覆盖”稍强的覆盖标准是“判定覆盖”(或称分支覆盖)。这个标准是：执行足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值，即使得程序中的每一个分文至少都通过一次。
“判定覆盖”比“语句覆盖”严格，因为如果每个分支都执行过了，自然每个语句也就执行了。
3)条件覆盖
它的含义是：执行足够的测试用例，使得判定中每个条件获得各种可能的结果。
亦是如此，它们能满足“条件覆盖”但不满足“判定覆盖”。
4)判定/条件覆盖
针对上面的问题引出了另一种覆盖标准，这就是“判定/条件覆盖”，它的含义是：执行足够的测试用例，同时满足判定覆盖和条件覆盖的要求。显然，它比“判定覆盖”和“条件覆盖”都强。
值得指出，看起来“判定/条件覆盖”似乎是比较合理的，应成为我们的目标，但是事实并非如此，因为大多数计算机不能用一条指令对多个条件作出判定，而必须将源程序中对多个条件的判定分解成几个简单判定。这个讨论说明了，尽管“判定/条件覆盖”看起来能使各种条件取到所有可能的值，但实际上并不一定能检查到这样的程度。针对这种情况，有下面的条件组合覆盖标准。
5)条件组合覆盖
“条件组合覆盖”的含义是：执行足够的测试用例，使得每个判定中条件的各种可能组合都至少执行一次。这是一个最强的逻辑覆盖标准。
1.1.1.7 应用系统软件集成的接口测试
明确系统各部分的关系，定义各类接口是确定系统集成范围和有效完成集成工作的保证。因此，在各个系统软件通过单项测试验收之后，系统集成测试主要是针对于各种接口的测试。
系统主要通过数据流程和服务流程在各个节点边界和应用系统对外边界的交互情况作为接口定义的基础。
模块之间的接口有以下几种类型：
通信协议：两个模块之间通信采用的标准协议或者自定义网络协议。协议中包含数据部分和控制部分。有些实现将数据与控制分离，如FTP；而大部分实现将数据与控制通过一条链路来传递，通过不同的消息包进行分离。
调用关系：模块A调用模块B，实际上是由模块A向模块B发出了一条控制指令，往往体现为参数与返回值，可以认为它们是控制的副本。
文件、数据库、队列、第三方中间件等：表现主要是数据的传递，其中的控制体现不明显。
共享资源：如两个模块共享一段“存储区域”，其中涉及的关键资源主要是“锁”，这两个模块在运行时往往分布在不同的进程或者线程中，表现为对数据或资源的竞争和共享。
同步：一个模块的运行需要另外一个模块的触发，双方往往存在“信号”等通知机制，也可以理解为一种特殊的控制方式。
针对上面的五种接口方式，我们可以将被测系统归类(以上的分类)，找出其中的数据接口与控制接口：
Ø 将数据接口与控制户口分解，分析需要的数据和需要的控制指令，然后，找出数据与指令中的变数所在；如数据(协议包)中的字段的取值，指令的参数变化等；接下来，将变数划分等价类，找出每类的代表，即是我们的测试数据。目的是让每类数据流与控制流均通过接口一次，从而实现测试的完全性；最后，就是考虑如何生成这些测试数据，需要对应到集成后“大模块”的输入与输出。
Ø 需要考虑的是业务。模块之间的联系(接口)往往是为了体现业务上的关联。关联本身也是有很多属性的，如关联点(每个模块)都存在一个角色，关联有多重性(multiplicity)--即模块A在运行时可能对应多个模块B的实例。
因此，接口测试的目的是：模块的集成能否准确体现业务上的关联，各个模块是否具备其角色的全部属性和接口，模块之间的关联关系如何打破，关联的多重性是否有效。还要考虑接口的性能，尤其对于系统关键接口。接口的性能测试越早进行越好。如果等到系统测试时做，可能接口外面封装了太多的代码，影响性能问题的精确定位。
结束测试阶段的工作包括：编写测试报告、测试资料整理。
完成测试计划中罗列的所有工作，达到预期的测试目标后，进行测试报告的编写。
对于测试过程中产生的测试资源--测试计划、测试用例设计、测试代码，这些是以后测试复用的基础。如果这些资源本身不能说明自己，则需要整理一份单独的说明文档，供以后参考使用。