软件企业信息工程事业部测试管理规程.doc

信息工程事业部测试管理规程 信息工程事业部测试管理规程信息工程事业部测试管理规程 文档名称文档名称：信息工程事业部测试管理规程 建立日期建立日期： 创创 建建 人人： 编辑软件编辑软件： 文档修订记录 版本编号或者 更改记录编号 *变化 状态 简要说明（变更 内容和变更范围）日期变更人批准日期批准人 V1.0A 新建 *变化状态：A增加，M修改，D删除 信息工程事业部测试管理规程 目录目录 1 1 1 简介简介简介 4 1.11.11.1目的目的目的 4 1.21.21.2适用范围适用范围适用范围 4 1.31.31.3参考文件参考文件参考文件 4 1.41.41.4什么是软件测试什么是软件测试什么是软件测试 4 1.5软件测试的目的 5 1.6测试工作目标 5 1.71.71.7术语 5 1.81.81.8角色说明角色说明角色说明 5 1.91.91.9人员安排人员安排人员安排 6 2 2 2 测试管理流程测试管理流程测试管理流程 7 2.12.12.1以开发人员为主的测试流程以开发人员为主的测试流程以开发人员为主的测试流程 7 2.1.12.1.12.1.1需求阶段需求阶段需求阶段 7 2.1.22.1.22.1.2设计、编码阶段设计、编码阶段设计、编码阶段 8 2.1.32.1.32.1.3测试阶段测试阶段测试阶段 8 2.22.22.2以测试人员为主的测试流程以测试人员为主的测试流程以测试人员为主的测试流程 9 2.2.12.2.12.2.1 测试接收标准测试接收标准测试接收标准 .11 2.2.22.2.22.2.2 测试过程测试过程测试过程 .13 2.2.32.2.32.2.3 测试方法测试方法测试方法 .14 2.2.3.12.2.3.12.2.3.1 等价类划分等价类划分等价类划分 .14 2.2.3.22.2.3.22.2.3.2 因果图因果图因果图 .16 2.2.3.32.2.3.32.2.3.3 边界值分析边界值分析边界值分析 .16 2.2.3.42.2.3.42.2.3.4 猜错法猜错法猜错法 .17 2.2.3.52.2.3.52.2.3.5 随机数法随机数法随机数法 .17 2.2.42.2.42.2.4 测试测试测试用例用例用例 .17 2.2.4.12.2.4.12.2.4.1 测试用例设计原则测试用例设计原则测试用例设计原则 .17 2.2.4.22.2.4.22.2.4.2 测试用例要素测试用例要素测试用例要素 .18 2.2.52.2.52.2.5 测试测试测试工具工具工具 .19 2.2.5.12.2.5.12.2.5.1 测试工具分类测试工具分类测试工具分类 .19 2.2.5.22.2.5.22.2.5.2 测试工具选择测试工具选择测试工具选择 .20 2.32.32.3缺陷管理缺陷管理缺陷管理 .21 2.3.12.3.12.3.1软软软件件件测试测试测试缺陷管理流程缺陷管理流程缺陷管理流程细则细则细则 .21 2.3.22.3.22.3.2缺陷状缺陷状缺陷状态态态列表及描述列表及描述列表及描述 .22 2.3.32.3.32.3.3缺陷状缺陷状缺陷状态态态切切切换换换流程流程流程 .22 2.42.42.4软件测试注意事项软件测试注意事项软件测试注意事项 .22 3 3 3 缺陷分类缺陷分类缺陷分类 .23 3.13.13.1按严重程度分类按严重程度分类按严重程度分类 .23 3.23.23.2按缺陷类型分类按缺陷类型分类按缺陷类型分类 .24 4 4 4 附录附录附录 .25 附录一 单元测试报告 25 附录二 集成测试报告 26 附录三 测试大纲 27 附录四 测试大纲附录 28 附录五 测试计划 29 信息工程事业部测试管理规程 附录六 程序错误报告 31 附录七 测试分析报告 32 信息工程事业部测试管理规程 1 1 1 简介简介简介 1.11.11.1 目的目的目的目的 目前信息工程研究所软件测试人员较少，经验缺乏、水平较低、过程控制较差。本规划主要 针对我们目前的测试工作状况把工作思路理清，在流程顺畅的基础上做到在理论上的逐步提升。为 了保证测试流程的规范性，确保各软件产品均按照需求文档进行开发，且与用户要求的一致，控制 并提高软件产品质量，规范并严格控制产品测试流程，特制定本规划。 1.21.21.2 适用范围适用范围适用范围适用范围 本规程适用于信息工程事业部各项目和工作产品。 1.31.31.3 参考文件参考文件参考文件参考文件 信息工程研究所测试管理规程 GBT 15532-2008 计算机软件测试规范 1.41.41.4 什么是软件测试什么是软件测试什么是软件测试什么是软件测试 无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。在开发软件系统的过程中， 面对着错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间 的通信和配合也不可能完美无缺，因此，在软件生命周期的每个阶段都不可避免地会产生差错。如 果在软件投入生产性运行之前，没有发现并纠正软件中的大部分差错，则这些差错迟早会在生产过 程中暴露出来，那时不仅改正这些错误的代价更高，而且往往会造成很恶劣的后果。测试的目的就 是在软件投入生产性运行之前，尽可能多地发现软件中的错误。目前软件测试仍然是保证软件质量 的关键步骤，它是对软件规格说明、设计和编码的最后复审。软件测试在软件生命周期中横跨两个 阶段。通常在编写出每个模块之后就对它做必要的测试(称为单元测试)，模块的编写者和测试者是 同一个人，编码和单元测试属于软件生命周期的同一个阶段。在这个阶段结束之后，对软件系统还 应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这 项工作。 大量统计资料表明，软件测试的工作量往往占软件开发总工作量的 40以上，在极端情况， 测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的三倍 信息工程事业部测试管理规程 到五倍。因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成了， 实际上，大约还有同样多的开发工作量需要完成。仅就测试而言，它的目标是发现软件中的错误， 但是，发现错误并不是我们的最终目的。软件工程的根本目标是开发出高质量的完全符合用户需要 的软件。 1.5 软件测试的目的软件测试的目的 测试的正确定义是“为了发现程序中的错误而执行程序的过程” 。这和某些人通常想象的“测 试是为了表明程序是正确的” ， “成功的测试是没有发现错误的测试”等等是完全相反的。正确认识 测试的目标是十分重要的。 由于测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰 当的。因此，在综合测试阶段通常由其他人员组成测试小组来完成测试工作。此外，应该认识到测 试决不能证明程序是正确的。即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在 程序中。测试只能查找出程序中的错误，不能证明程序中没有错误。 1.6 测试工作目标测试工作目标 年逐步建立测试环境，搭建缺陷跟踪管理系统，完善测试流程、测试组织结构。 2013 年利用测试管理系统将测试过程从测试需求、测试设计、到测试执行完整的管理起来。 2014 年完善自动化测试工具、性能测试工具，逐步深入测试。 1.71.71.7术语术语 1.81.81.8 角色说明角色说明角色说明角色说明 岗位职责说明 测试组组长a) 负责信息工程研究所测试工作的管理，对部门最终产品质量负责 b) 负责与产品业务相关部门和研发项目组的多方沟通，保证项目的顺 利进行 c) 协调测试资源，并对各种资源进行计划、分工和管理 d) 制定各个项目的测试计划 e) 参加项目各阶段的评审和验收 f) 测试组团队成员管理、保证团队高效、协作的工作 信息工程事业部测试管理规程 测试负责人a) 对各产品组具体项目的测试工作进行分析、制定测试计划 b) 负责项目中具体业务的分析、整理，辅助测试工程师进行测试需求 分析 c) 提供测试工程师业务培训和指导、答疑等 e) 整理需求中和系统不明确的地方，统一与业务或研发人员进行沟通 测试工程师a) 服从项目管理和组长管理，能够保质保量按时完成测试任务 b) 了解软件需求，根据功能列表清单进行测试并记录、跟踪缺陷处理 流程 ，对测试的功能点进行记录 c) 有义务对项目工作提出建设性建议 d) 与开发组进行有效沟通 1.91.91.9 人员安排人员安排人员安排人员安排 人员由项目组统一安排，协调一个固定的开发人员进行测试环境搭建以及版本更新等工作。 信息工程事业部测试管理规程 2 2 2 测试管理流程测试管理流程测试管理流程 为了能够清晰的描述测试的工作流程，在此将测试工作从开发人员为主的测试和测试人员为主 的测试两个方面来进行说明，并对各流程进行说明。 2.12.12.1 以开发人员为主的测试流程以开发人员为主的测试流程以开发人员为主的测试流程以开发人员为主的测试流程 以开发人员为主的测试流程 测试交付物负责人测试活动 指定测试负责人 搭建测试环境 构建测试版本 单元测试、 系统测试等 提交测试问题 审批 编写测试报告 项目总结 通过 未通过 测试日志 测试报告 缺陷管理系统 或 缺陷记录文档 项目经理 项目经理 开发人员 开发人员 开发人员 项目管理人员 项目管理人员 项目管理人员 版本控制系统 图表 1 以开发人员为主的测试流程 2.1.12.1.12.1.12.1.1 需求阶段需求阶段需求阶段需求阶段 开发人员要全面了解项目需求收集结果包括项目需求规格说明、功能结构及模块划分等， 还有了解项目需求变更。项目管理人根据软件需求及项目计划制定并确认XXX 系统测试计划 。 信息工程事业部测试管理规程 2.1.22.1.22.1.22.1.2 设计、编码阶段设计、编码阶段设计、编码阶段设计、编码阶段 项目开发组在概要设计时要明确功能点，开发人员根据概要设计编写系统测试功能列表清单 。项目负责人安排和协调测试设备、环境等准备工作。开发人员对完成的功能模块进行自测，将关 键的、有价值的问题记录在测试问题记录 。 自测完成后由项目负责人协调人员进行互测，互测之前通知配置管理人员要将该单元可执行文 件放置到基线域内进行版本的控制，然后由基线域拿到测试域。测试人员由测试域得待测程序进行 测试，并将问题记录到单元测试问题记录内，开发人员对所有的缺陷进行分析修改。确认无误 后开发人员填写XXX 测试申请单 ，该申请单内主要填写测试要点，给系统测试人员进行提示， 以免测试人员遗漏。 将XXX 测试申请单及可执行文件提交给项目负责人，确认后通知配置管理人员将该单元 可执行文件放置到基线域内进行版本的控制，然后由基线域拿到测试域。将XXX 测试申请单 直接放置到基线域测试申请单文件夹内。系统测试人员由测试域得待测程序进行测试 2.1.32.1.32.1.32.1.3 测试阶段测试阶段测试阶段测试阶段 系统测试人员由测试域得待测程序进行测试，测试组按测试计划 、 系统测试功能列表清单 的要求对待测软件进行系统测试。在测试的过程中如果出现经三次修改还未通过的问题直接退回开 发组。每个功能点的详情在系统测试功能列表清单都有记录。 开发人员对测试人员提交的缺陷进行分析确认，对有争议的问题可项目负责人确认和仲裁；开 发人员针对测试的缺陷逐项进行修改确保每个被发现的缺陷的解决方式必须在开发组中达到一致， 修改完成后再将待程序件由配置人员放置到测试域由测试组进行回归测试。回归测试程序不再放置 到基线域，直到该模块最终版本才放置到基线域进行版本控制。 测试全部结束后，测试人员对测试结果进行汇总；测试负责人和项目负责人对测试进行分析和 评估，编写测试分析报告经过评审后提交到配置库测试域，至此测试工作结束。 信息工程事业部测试管理规程 2.22.22.2 以测试人员为主的测试流程以测试人员为主的测试流程以测试人员为主的测试流程以测试人员为主的测试流程 图表 以测试人员为主的测试流程 负责人测试交付物测试活动 通过 未通过 项目经理 项目管理人员 缺陷管理系统 或 缺陷记录文档 开发人员 建立项目测试组 项目管理人员 项目总结 版本控制系统 测试人员 提交测试问题 构建测试版本 编写测试报告 搭建测试环境 审批 开发人员 测试报告 项目管理人员 了解项目需求 制定测试计划 编写测试用例 系统测试 测试计划 测试用例 测试人员 测试人员 测试人员 测试人员 测试日志 2 以测试人员为主的测试流程 软件测试需要相关的文档作为测试设计及测试过程中判断是否符合要求的依据和标准，包括 信息工程事业部测试管理规程 项目开发计划 、 需求规格说明书 、 概要设计说明书 、 详细设计说明书 、 系统集成计划 、 软件配置计划等文档资料。 软件测试组在测试过程中形成的文档包括软件测试计划 、 软件测试用例 、 测试缺陷记录 、 测试分析报告 。 a.了解项目 软件测试组在项目启动后掌握软件项目的背景，参与软件系统的需求评审，进一步了解软件特 定的功能性和非功能性需求，从而可以分析软件系统的质量需求，确定项目的测试需求和基本任务。 b.测试计划 测试经理收集和组织测试计划信息，并创建软件测试计划 。在测试计划中根据需求规格 说明书 、质量计划等收集和整理测试需求信息，确定质量需求和测试目标；制定测试策略；建立 测试通过准则；确定资源和进度；最后组织测试计划的评审。 c.测试设计 测试工程师为每一个测试需求确定测试用例集，并且确定执行测试用例的测试过程。 （1）设计测试用例 为每一个测试需求，确定其需要的测试用例。 为每一个测试用例，确定其输入及预期结果。 确定测试用例的测试环境配置、需要的驱动程序或桩程序。 编写软件测试用例文档。 对测试用例进行同行评审。 （2）设计测试过程 根据界面原型为每一个测试用例定义详细的测试步骤。 为每一测试步骤定义详细的测试结果验证方法。 为测试用例准备输入数据。 编写测试过程文档。 对测试过程进行同行评审。 在实施测试时对测试过程进行更改。 d.执行系统测试 测试工程师执行系统测试，确认软件系统工作版本是否满足功能性需求和非功能性需求等。 （1）开发组在 VSS 上单独建立测试版本并通知测试经理组织测试。 （2）测试组从 VSS 上获取需要测试的相应软件系统版本，配置测试环境。 信息工程事业部测试管理规程 （3）执行系统测试按照测试过程手工执行系统测试或运行测试脚本自动执行系统测试； （4）详细记录系统测试结果（测试缺陷记录 ） ，并对测试结果进行分析，提交测试结果和 分析报告给相关开发人员和测试经理。 （5）回归测试对修改后的软件系统版本执行回归测试。 e.评估测试 测试组对每一次测试结果进行分析评估，在每一个测试阶段提交测试分析报告 。 2.2.12.2.12.2.1 测试接收标准测试接收标准测试接收标准测试接收标准 注：接收标准为程序员经过单元测试或开发人员自测后，提交测试时应达到可测试的最低标准，如 不满足最低测试标准，则需返回开发，待问题解决后重新提交测试。 信息工程事业部测试管理规程 1. 以下接收资料完整，如资料不完整，则不予接收以下接收资料完整，如资料不完整，则不予接收 (1) 经过审核程序源代码。 (2) 运行单元测试的相关的模块（测试桩模块或其他模块）结果。 (3) 必要的数据库文件。 (4) 经过审核过的概要和详细的设计文档、帮助文件、其他必要的文件。 (5) 若执行白盒测试，则需要提交白盒测试的测试用例和白盒单元测试报告。 2. 程序界面程序界面 (1) 界面风格 a、 界面风格一致（包括控件的大小、快捷键的命令名称） ，美观大方。 b、 无错字别字，最好能望文知意。 (2) 菜单项问题 a、 可用模块各菜单项功能均已实现。 b、 可用模块各菜单项快捷键可以使用。 3. 功能实现功能实现 (1) 说明书规定的功能或程序员提交的功能说明书的功能均已实现。 (2) 基本流程可以走通。 (3) 提交模块界面上的功能均实现，符合设计文挡规定的功能。 (4) 正确实现左右键功能 a、 左键拖动功能已实现（如果有） 。 b、 右键功能与菜单项功能对应（均已实现） 。 c、 右键的快捷键应与菜单项一致。 (5) 提示问题 a、 提示、警告、或错误说明应该清楚、明了、恰当。 b、 非法的输入或操作应有足够的提示说明。 c、 由于误操作得到的反馈信息，应该能够指导用户的下一步操作。 (6) 数据库的增删改问题 a、 增删改功能可以实现。 b、 增删改时响应时间不能超过 5 秒。 (7) 数据的查询 信息工程事业部测试管理规程 a、 能够及时查询所需要的数据。 (8) 能被主模块调起或调起子模块。 4. 系统情况及其他系统情况及其他 (1) 程序可以运行。 2.2.22.2.22.2.2 测试过程测试过程测试过程测试过程 需求阶段：需求阶段： 测试人员了解项目需求收集结果包括项目需求规格说明、功能结构及模块划分等。 测试人员了解项目需求变更。 测试人员会同项目主管根据软件需求制定并确认测试计划 （附录五） 。 设计编码阶段：设计编码阶段： 测试人员制定测试大纲 （附录三、附录四） 。 项目开发组对完成的功能模块进行单元测试，测试人员参与单元测试过程；单元测试完成，产 生单元测试报告。 所有单元测试及相应的修改完成后，项目开发组组织进行集成测试，测试人员参与集成测试过 程；集成测试完成后，产生集成测试报告。 测试阶段：测试阶段： 项目开发组完成集成测试后，提交测试所要求的待测软件及各种文档、手册、前期测试报告 （需求分析 、 软件设计规范和上一级测试报告附录一、附录二） 。 测试组安排和协调测试设备、环境等准备工作。 测试组按测试计划、测试大纲的要求对待测软件进行有效性测试、集成测试。 填写错误报告 （附录六） 。 对修改后的情况进行复合。 测试结束后，测试人员对测试结果进行汇总；测试主管审核测试结果，得出测试结论；测试组 进行测试分析和评估，编写测试分析报告 （附录七） 。 提交测试分析报告 。 将所有文件存档。 对测试未通过的待测软件，测试人员汇总并向项目开发组提交测试错误报告。 项目开发组对测试错误报告进行确认，对有争议的问题可由上一级技术负责人确认和仲裁；项 目开发组针对测试错误报告进行逐项修改，修改完成后再将待测软件及错误修改情况提交及测 信息工程事业部测试管理规程 试组进行回归测试。 待测软件测试通过后，项目测评结束。 制作用户操作手册 （帮助文件） 。 用户测试阶段：用户测试阶段： 项目开发组与用户方商定测试计划、测试内容、测试环境等。 项目测试组向用户方提供项目内部测试汇总报告。 由项目开发组或测试组配合用户进行用户方测试。 由用户方编制用户方软件测试报告（程序错误报告和测试分析报告） ，若用户方不愿或无法编 制测试报告，则经与用户方协商由我方测试人员编制用户方测试报告，经用户方签字后即可生效。 项目经理与用户方对用户方测试进行确认。 2.2.32.2.32.2.3 测试方法测试方法测试方法测试方法 黑盒测试(blackbox testing)又称功能测试、数据驱动测试或基于规范的测试。用这种方法 进行测试时，被测程序被当作看不见内部的黑盒。在完全不考虑程序内部结构和内部特性的情况下， 测试者仅依据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性。因此黑盒测试是从 用户观点出发的测试，黑盒测试直观的想法就是既然程序被规定做某些事，那我们就看看它是不是 在任何情况下都做的对。完整的“任何情况”是无法验证的，为此黑盒测试也有一套产生测试用例 的方法，以产生有限的测试用例而覆盖足够多的“任何情况” 。由于黑盒测试不需要了解程序内部 结构，所以许多高层的测试如确认测试、系统测试、验收测试都采用黑盒测试。 黑盒测试首先是程序通常的功能性测试。要求：每个软件特性必须被一个测试用例或一个被认 可的异常所覆盖。用数据类型和数据值的最小集测试。用一系列真实的数据类型和数据值运行，测 试超负荷、饱和及其他“最坏情况”的结果；用假想的数据类型和数据值运行，测试排斥不规则输 入的能力；对影响性能的关键模块，如基本算法、应测试单元性能(包括精度、时间、容量等)。不 仅要考核“程序应该做什么?”还要考察“程序是否做了不该做的” ，同时还要考察程序在其他一些 情况下是否正常。这些情况包括数据类型和数据值的异常等等。 下述几种方法：(a)等价类划分，(b)因果图方法，(c)边值分析法，(d)猜错法，(e)随机数法， 就是从更广泛的角度来进行黑盒测试。每一个方法都力图能涵盖更多的“任何情况” ，但又各有长 处，综合使用这些方法，会得到一个较好的测试用例集。 信息工程事业部测试管理规程 2.2.3.12.2.3.12.2.3.1等价类划分等价类划分等价类划分等价类划分 等价类划分是一种典型的黑盒测试方法。等价类是指某个输入域的集合。它表示对揭露程序中 的错误来说，集合中的每个输入条件是等效的。因此我们只要在一个集合中选取一个测试数据即可。 等价类划分的办法是把程序的输入域划分成若干等价类，然后从每个部分中选取少数代表性数据当 作测试用例。这样就可使用少数测试用例检验程序在一大类情况下的反映。 在考虑等价类时，应该注意区别以下两种不同的情况： 有效等价类：有效等价类指的是对程序的规范是有意义的、合理的输入数据所构成的集 合。在具体问题中，有效等价类可以是一个，也可以是多个。 无效等价类：无效等价类指对程序的规范是不合理的或无意义的输入数据所构成的集合。 对于具体的问题，无效等价类至少应有一个，也可能有多个。 确定等价类有以下几条原则： 如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类。 例如，程序的规范中提到的输入条包括“项数可以从 1 到 999” ，则可取有效等价类 为“l 考项数999” ，无效等价类为“项数l， ，及“项数999” 。 输入条件规定了输入值的集合，或是规定了“必须如何”的条件，则可确定一个有效等 价类和一个无效等价类。 如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类； 如果规定了输入数据的一组值，而且程序对每个输入值分别进行处理，此时可为每一个 输入值确立一个有效等价类，此外，针对这组值确立一个无效等价类，它是所有不允许输入值 的集合； 如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干 个无效等价类（从不同的角度违反规则） 。如某程序涉及标识符，其输入条件规定“标识符应 以字母开头”则“以字母开头者”作为有效等价类， “以非字母开头”作为无效等价类。 如果我们确知，已划分的等价类中各元素在程序中的处理方式是不同的，则应将此等价 类进一步划分成更小等价类。 输入条件有效等价类无效等价类 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 根据已列出的等价类表，按以下步骤确定测试用例： 为每个等价类规定一个唯一的编号； 信息工程事业部测试管理规程 设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使 得所有有效等价类均被测试用例所覆盖； 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步，使所有无效等价类 均被覆盖。这里强调每次只覆盖一个无效等价类。这是因为一个测试用例中如果含有多个缺陷， 有可能在测试中只发现其中的一个，另一些被忽视。 等价类划分法能够全面、系统地考虑黑盒测试的测试用例设计问题，但是没有注意选用一些 “高效的” 、 “有针对性的”测试用例。后面介绍的边值分析法可以弥补这一缺点。 2.2.3.22.2.3.22.2.3.2因果图因果图因果图因果图 等价类划分法并没有考虑到输入情况的各种组合。这样虽然各个输入条件单独可能出错的情况 已经看到了，但多个输入情况组合起来可能出错的情况却被忽略。采用因果图方法能帮助我们按一 定步骤选择一组高效的测试用例，同时，还能为我们指出程序规范的描述中存在什么问题。 利用因果图导出测试用例需要经过以下几个步骤： 分析程序规范的描述中哪些是原因，哪些是结果。原因常常是输入条件或是输入条件的等价 类。结果是输出条件。 分析程序规范的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图” 。 由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情 况，在因果图上使用持殊的符号标明约束条件。 把因果图转换成判定表。 把判定表的每一列写成一个测试用例。 2.2.3.32.2.3.32.2.3.3边界值分析边界值分析边界值分析边界值分析 边界值分析法是列出单元功能、输入、状态及控制的合法边界值和非法边界值，设计测试用例， 包含全部边界值的方法。典型地包括 IF 语句中的判别值，定义域、值域边界，空或畸形输入，末 受控状态等。边值分析法不是一类找一个例子的方法，而是以边界情况的处理作为主要目标专门设 计测试用例的方法。另外，边值分析不仅考查输入的边值，也要考虑输出的边值。这是从人们的经 验得出的一种有效方法。人们发现许多软件错误只是在下标、数据结构和标量值的边界值及其上、 下出现，运行这个区域的测试用例发现错误的概率很高。 用边界值分析法设计测试用例时，有以下几条原则： 如果输入条件规定了取值范围，或是规定了值的个数，则应以该范围的边界内及刚刚超 出范围的边界外的值，或是分别对最大、最小及稍小于最小、稍大于最大个数作为测试用例。 信息工程事业部测试管理规程 如有规范“某文件可包含 l 至 255”个记录“，则测试用例可选 1 和 255 及 0 和 256 等。 如果输入条件规定了值的个数，则用最大个数、最小个数、比最大多 1、比最小小 1 的 数作为测试输入数据； 根据规格说明的每个输出条件，使用前面的原则； 如果程序规范中提到的输入或输出域是个有序的集合(如顺序文件、表格等)就应注意选 取有序集的第一个和最后一个元素作为测试用例。 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为 测试用例； 分析规格说明，找出其他可能的边界条件。 一个典型的边界值分析例子是三角形分类程序。选取 a，b，c 构成三角形三边， “任意两边之 和大于第三边”为边界条件。边值分析相等价类划分侧重不同，对等价类划分是一个补充。如上述 三角形问题，选取 a3，b4，c5，a2，b4，c7 则覆盖有效和无效等价类。如果能在等 价类划分中注入边值分析的思想。在每个等价类中不只选取一个覆盖用例，而是进而选取该等价类 的边界值等价类划分法将更有效，最后可以用边值分析法再补充一些测试用例。 2.2.3.42.2.3.42.2.3.4猜错法猜错法猜错法猜错法 猜错法在很大程度上是凭经验进行的，是凭人们对过去所作的测试工作结果的分析，对所揭示 的缺陷的规律性作直觉的推测来发现缺陷的。 一个采用两分法的检索程序，典型地可以列出下面几种测试情况： 被检索的表只有一项或为空表； 表的项数恰好是 2 的幂次； 表的项数比 2 的幂次多 1 等。 猜错法充分发挥人的经验，在一个测试小组中集思广益，方便实用，特别在软件测试基础较差 的情况下，很好地组织测试小组 (也可以有外来人员)进行错误猜测，是有效的测试方法。 2.2.3.52.2.3.52.2.3.5随机数法随机数法随机数法随机数法 即测试用例的参数是随机数。它可以自动生成，因此自动化程度高。使用大量随机测试用例测 试通过的程序会提高用户对程序的信心。但其关键在于随机数的规律是否符合使用实际。 信息工程事业部测试管理规程 2.2.42.2.42.2.4 测试测试测试测试用例用例用例用例 2.2.4.12.2.4.12.2.4.1测试用例设计原则测试用例设计原则测试用例设计原则测试用例设计原则 设计测试用例时，应遵循以下原则： a) 基于测试需求的原则。应按照测试类别的不同要求，设计测试用例。如，单元测试依据详 细设计说明；集成测试依据概要设计说明；配置项测试依据软件需求规格说明；系统测试依据用户 需求（系统/子系统设计说明、软件开发计划等） 。 b) 基于测试方法的原则。应明确所采用的测试用例设计方法。为达到不同的测试充分性要求， 应采用相应的测试方法，如等价类划分、边界值分析、猜错法、因果图等方法。 c) 兼顾测试充分性和效率的原则。测试用例集应兼顾测试的充分性和测试的效率；每个测试 用例的内容也应完整，具有可操作性。 d)测试执行的可再现性原则。应保证测试用例执行的可再现性。 2.2.4.22.2.4.22.2.4.2测试用例要素测试用例要素测试用例要素测试用例要素 每个测试用例应包括以下要素： a) 名称和标识。每个测试用例应有唯一的名称和标识符。 b) 测试追踪。说明测试所依据的内容来源，如系统测试依据的是用户需求；配置项测试依据 的是软件需求，集成测试和单元测试依据的是软件设计。 c) 用例说明。简要描述测试的对象、目的和所采用的测试方法。 d) 测试的初始化要求。应考虑下述初始化要求： 1） 硬件配置。被测系统的硬件配置情况，包括硬件条件或电气状态。 2） 软件配置。被测系统的软件配置情况，包括测试的初始条件。 3） 测试配置。测试系统的配置情况，如用于测试的模拟系统和测试工具等的配置情况。 4） 参数设置。测试开始前的设置，如标志、第一断点、指针、控制参数和初始化数据等 的设置。 5） 其他对于测试用例的特殊说明。 e) 测试的输入。在测试用例执行中发送给被测对象的所有测试命令、数据和信号等。对于每 个测试用例应提供如下内容： 1） 每个测试输入的具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无 效值、边界值等） ； 2） 测试输入的来源（例如：测试程序产生、磁盘文件、通过网络接收、人工键盘输入等） ，以及选择输入所使用的方法（例如：等价类划分、边界值分析、差错推测、因果图、功能图方法 信息工程事业部测试管理规程 等） ； 3） 测试输入是真实的还是模拟的； 4） 测试输入的时间顺序或事件顺序。 f) 期望的测试结果。说明测试用例执行中由被测试软件所产生期望的测试结果，即经过验证， 认为正确的结果。必要时，应提供中间的期望结果。期望测试结果应该有具体内容，如确定的数值、 状态或信号等，不应是不确切的概念或笼统的描述。 g) 评价测试结果的准则。判断测试用例执行中产生的中间和最后结果是否正确的准则。对于 每个测试结果，应根据不同情况提供如下信息： 1） 实际测试结果所需的精度； 2） 实际测试结果与期望结果之间的差异允许的上限、下限； 3） 时间的最大和最小间隔，或事件数目的最大和最小值； 4） 实际测试结果不确定时，再测试的条件； 5） 与产生测试结果有关的出错处理； 6） 上面没有提及的其他准则。 h) 操作过程。实施测试用例的执行步骤。把测试的操作过程定义为一系列按照执行顺序排列 的相对独立的步骤。对于每个操作应提供： 1） 每一步所需的测试操作动作、测试程序的输入、设备操作等； 2） 每一步期望的测试结果； 3） 每一步的评价准则； 4） 程序终止伴随的动作或差错指示； 5） 获取和分析实际测试结果的过程。 i) 前提和约束。在测试用例说明中施加的所有前提条件和约束条件，如果有特别限制、参数偏 差或异常处理，应该标识出来，并要说明它们对测试用例的影响。 j) 测试终止条件。说明测试正常终止和异常终止的条件。 2.2.52.2.52.2.5 测试测试测试测试工具工具工具工具 2.2.5.12.2.5.12.2.5.1测试工具分类测试工具分类测试工具分类测试工具分类 软件测试工具可分为静态测试工具、动态测试工具和其他支持测试活动的工具，每类测试工具 在功能和其他特征方面具有相似之处，支持一个或多个测试活动。应根据测试要求选择合适的工具。 工具类型工具类型功能和特征说明功能和特征说明举例举例备注备注 信息工程事业部测试管理规程 静态测试静态测试 工具工具 对软件需求、结构设计、详细 设计和代码进行评审、走查和 审查的工具 复杂度分析、数据流分析、控制 流分析、接口分析、句法和语义 分析等工具 针对软件需求、结构设计、 详细设计的静态分析工具 很少 动态测试动态测试 工具工具 支持执行测试用例和评价测试 结果的工具，包括支持选择测 试用例、设置环境、运行所选 择测试、记录执行活动、故障 分析和测试工作有效性评价等 覆盖分析、捕获和回放、存储器 测试、变异测试、仿真器及性能 分析、测试用例管理等工具 测试捕获和回放及数据生 成器可以用于测试设计 支持测试支持测试 过程活动过程活动 的其他工的其他工 具具 支持测试计划、测试设计和整 个测试过程的工具 测试计划生成、测试进度和人员 安排评估、基于需求的测试设计、 测试数据生成、问题管理和测试 配置管理等工具 复杂度分析可用于测试计 划的制定，捕获和回放、 覆盖分析可用于测试设计 与实现 2.2.5.22.2.5.22.2.5.2测试工具选择测试工具选择测试工具选择测试工具选择 软件测试应尽量采用测试工具，避免或减少人工工作。为让工具在测试工作中发挥应有的作用， 应确定工具的详细需求，并制定统一的工具评价、采购（开发） 、培训、实施和维护计划。 选择软件测试工具应考虑如下因素： a) 软件测试工具的需求及确认： 1） 应明确对测试工具的功能、性能、安全性等需求，并据此进行验证或确认。 2） 可通过在实际运行环境下的演示来确认工具是否满足需求，演示应依据工具的功 能和技术特征、用户使用信息（安装和使用手册等）以及工具的操作环境描述等进行。 b) 成本和收益分析： 1）估计工具的总成本，除了最基本的产品价格，总成本还包括附加成本，如工具的挑选、 安装、运行、培训、维护和支持等成本，以及为使用工具而改变测试过程或流程的成本等。 2）分析工具的总体收益，如工具的首次使用范围和长期使用前景、工具应用效果、与其 他工具协同工作所提高的生产力程度等。 c) 测试工具的整体质量因素： 1）易用性； 2）互操作性； 3）稳定性； 信息工程事业部测试管理规程 4）经济实用性； 5）维护性。 2.32.32.3 缺陷管理缺陷管理缺陷管理缺陷管理 项项目目经经理理、开开发发小小组组测测试试小小组组测测试试小小组组 新建BUG待解决 重打开 已关闭 延后 取消 待回归是否通过 是否取消 结束 否 是 否 是 必要时 当已关闭的BUG 再次出现时测试人 员可将其重新打开 给相关人员处理 图表 2 软件测试缺陷管理流程 2.3.12.3.12.3.1软软软软件件件件测试测试测试测试缺陷管理流程缺陷管理流程缺陷管理流程缺陷管理流程细则细则细则细则 1. 测试小组新建 BUG，提交给项目经理和开发小组，状态为“待解决”。 2. 项目经理和开发小组根据 BUG 的详细情况，确定处理方案，处理完毕后将状态置为“待回 归” ，没有必要处理的置为“取消” ，必要时可置为“延后”稍后进行处理。 处理完毕的提 交到测试小组进行回归测试。 3. 测试小组回归测试时，应按处理方案进行测试，严格控制测试的质量。在回归测试时，进 行以下操作： 如果回归通过，将缺陷状态设为“已关闭” ，结束事务； 如果回归没通过，将缺陷状态设为“重打开” ，并提交给原处理该事务的项目经理或开发人 员重新处理。 4. 项目经理或开发人员接到“重打开”的缺陷后，需及时查明原因，重新处理该缺陷。 5. 测试小组接到项目经理提交的“取消”的事务时，应根据该事务的严重性及对相关系统的影响， 判断该事务是否可以取消，进行以下操作： 信息工程事业部测试管理规程 如果确定可以取消时，将状态设为“已关闭” ，结束缺陷。 如果确定不可以取消时，将状态设为“待解决” ，提交给开发人员重新进行处理。 6. 测试人员接到项目经理或开发人员提交的“延后”的事务时，须在必要时提交给项目经理或开 发人员重新进行处理。 7. 如果已关闭的 BUG，再次出现时，可将状态设为“重打开”，再次提交给相关人员处理。 2.3.22.3.22.3.2缺陷状缺陷状缺陷状缺陷状态态态态列表及描述列表及描述列表及描述列表及描述 测试 BUG 的状态列表及描述如下： 序号状态名描述 待解决测试小组提交给项目经理及开发人员的需处理缺陷 待回归开发人员处理完毕的事务提交测试人员进行回归 重打开测试小组将回归没通过的 BUG 重新打开给开发人员处理 取消开发人员将不用处理的缺陷取消 延后开发人员将暂时不用处理的缺陷延后 已关闭缺陷处理被确认 2.3.32.3.32.3.3缺陷状缺陷状缺陷状缺陷状态态态态切切切切换换换换流程流程流程流程 源状态目标状态有权工作组 待解决待回归项目负责人、开发小组 待回归已关闭测试小组 待解决取消项目负责人 待解决延后项目负责人 待回归重打开测试小组 重打开待回归项目负责人、开发小组 取消待解决测试小组 取消已关闭测试小组 延后待解决测试小组 已关闭重打开测试小组 2.42.42.4 软件测试注意事项软件测试注意事项软件测试注意事项软件测试注意事项 1、如果修改过程中涉及到需求、设计文档的变更则相关负责人应及时修改需求规格说明书 或系统设计文档，确保产品本身和需求及设计文档保持一致。 信息工程事业部测试管理规程 2、根据界面原形设计仔细检查软件的界面是否合乎要求（每一个子界面也应如此）。 其中，应注意提示信息和软件开发商信息是否正确。小的图标是否合乎要求。检查菜单当中的各项 功能和功能按钮是否能正确使用。 3、根据需求规格说明书和概要设计编写测试功能列表清单。对功能界面要求注 意与功能相关的信息显示及显示位置是否正确，数据输入界面应注意文字格式及数字和文字的区别， 是否能够正确保存信息。数据查询（显示）界面应注意显示信息是否正确和完整，是否能正确查询。 对打印功能要求注意打印出的报表是否正确（包括报表各项信息、数据信息和报表格式字体等）。 4、再一项测试主要是对软件的错误处理功能进行测试。就是进行错误的操作或输入错误的数 据，检查软件对这些情况是否能做出判断并予以提示。特殊情况下要制造极端状态和意外状态，比 如网络异常中断、电源断电等情况。一定要注意测试中的错误集中发生现象，这和程序员的编程水 平和习惯有很大的关系。 5、对测试错误结果一定要有一个确认的过程。一般有 A 测试出来的错误，一定要有一个 B 来 确认，避免浪费开发人员的时间，严重的错误可以召开评审会进行讨论和分析。由于程序错误太多 造成测试人员测试进行缓慢，效率较低的程序要退回开发组重新处理。开发组应该把自己测试不出 缺陷的程序提交到测试组，而不要把太多的测试寄希望于测试组，这就要求开发组和测试组都要负 责任。 6、制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个 高水平的测试。 7、回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不 少见。 8、妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。 3 3 3 缺陷分类缺陷分类缺陷分类 3.13.13.1 按严重程度分类按严重程度分类按严重程度分类按严重程度分类 本规范定义以下五类测试错误类型。 A A 类类严重错误严重错误 包括以下各种错误： 由于程序所引起的死机,非法退出 死循环 数据库发生死锁 信息工程事业部测试管理规程 因错误操作导致的程序中断 功能错误 与数据库连接错误 数据通讯错误 B B 类类较严重错误较严重错误，包括以下各种错误： 程序错误 程序接口错误 数据库的表、业务规则、缺省值未加完整性等约束条件 C C 类类一般错误一般错误 包括以下各种错误： 操作界面错误（包括数据窗口内列名定义、含义是否一致） 打印内容、格式错误 简单的输入限制未放在前台进行控制 删除操作未给出提示 数据库表中有过多的空字段 D D 类类较小错误较小错误 包括以下各种错误： 界面不规范 辅助说明描述不清楚 输入输出不规范 长操作未给用户提示 提示窗口文字未采用行业术语 可输入区域和只读区域没有明显的区分标志 E E 类类测试建议测试建议 3.23.23.2 按缺陷类型分类按缺陷类型分类按缺陷类型分类按缺陷类型分类 主要有：功能实现、数据正确性、界面显示、接口、性能、多语言。 信息工程事业部测试管理规程 4 4 4 附录附录附录 附录一附录一 单元测试报告单元测试报告 1 测试过程与结果 1.1 （某程序模块/文档名称）测试 测试对象：（某程序模块/文档） 测试方面：（设计规范/应用功能及流程/程序代码） 责任人： 测试人及测试时间： 问题及影响、处理结果： 1.2 （某程序模块/文档名称）测试 测试对象：（某程序模块/文档） 测试方面：（设计规范/应用功能及流程/程序代码） 责任人： 测试人及测试时间： 问题及影响、处理结果： 2 测试结论 对单元测试的结果评