第13章 系统测试
第13章 系统测试 1 13.1 介绍 1 13.2 系统测试规程 2 13.2.1 目的 2 13.2.2 角色与职责 2 13.2.3 启动准则 2 13.2.4 输入 2 13.2.5 主要步骤 3 [Step1] 制定系统测试计划 3 [Step2] 设计系统测试用例 3 [Step3] 执行系统测试 3 [Step4] 缺陷管理与改错 3 13.2.6 输出 3 13.2.7 结束准则 4 13.2.8 度量 4 13.3 实施建议 4 第13章 系统测试 系统测试（System Test, ST）的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵 循系统设计。 系统测试过程域是SPP模型的重要组成部分。本规范阐述了系统测试的规程，该规程 的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和 “度量”均已定义。 本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研 发实力等）适当地修改本规范，然后推广使用。 13.1 介绍 系统测试流程如图14- 1所示。由于系统测试的目的是验证最终软件系统满足产品需求并且遵循系统设计，所以 当产品需求和系统设计文档完成之后，系统测试小组就可以提前开始制定测试计划和设 计测试用例，而不必等到“实现与测试”阶段结束。这样可以提高系统测试的效率。 系统测试过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，开发人员应当及 时消除缺陷（改错）。 图13-1 系统测试流程图 项目经理设法组建富有成效的系统测试小组。系统测试小组的成员主要来源于： ← 机构独立的测试小组（如果存在的话）。 ← 邀请其它项目的开发人员参与系统测试。 ← 本项目的部分开发人员。 ← 机构的质量保证人员。 系统测试小组应当根据项目的特征确定测试内容。一般地，系统测试的主要内容包括 ： ← 功能测试。即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规 格说明书》。由于正确性是软件最重要的质量因素，所以功能测试必不可少。 ← 健壮性测试。即测试软件系统在异常情况下能否正常运行的能力。健壮性有两层 含义：一是容错能力，二是恢复能力。 ← 性能测试。即测试软件系统处理事务的速度，一是为了检验性能是否符合需求， 二是为了得到某些性能数据供人们参考（例如用于宣传）。 ← 用户界面测试。重点是测试软件系统的易用性和视觉效果等。 ← 安全性（security）测试。是指测试软件系统防止非法入侵的能力。“安全”是相 对而言的，一般地，如果黑客为非法入侵花费的代价（考虑时间、费用、危险等 因素）高于得到的好处，那么这样的系统可以认为是安全的。 ← 安装与反安装测试。 系统测试过程域产生的主要文档有： ← 《系统测试计划》，模板见 [SPP-TEMP-ST-PLAN]。 ← 《系统测试用例》，模板见 [SPP-TEMP-TEST-CASE]。 ← 《系统测试报告》，模板见 [SPP-TEMP-TEST-REPORT]。 ← 《缺陷管理报告》，由缺陷管理工具自动生成。 13.2 系统测试规程 13.2.1 目的 o 对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。 13.2.2 角色与职责 o 项目经理组建系统测试小组，并指定一名成员任测试组长。 o 系统测试小组各成员共同制定测试计划、设计测试用例、执行测试，并撰写相应的文档 。测试组长管理上述事务。 o 开发人员及时消除测试人员发现的缺陷。 13.2.3 启动准则 o 产品需求和系统设计文档完成之后。 13.2.4 输入 o 产品需求和系统设计文档 13.2.5 主要步骤 [Step1] 制定系统测试计划 o 系统测试小组各成员共同协商测试计划。测试组长按照指定的模板起草《系统测试计划 》。该计划主要包括： ← 测试范围（内容） ← 测试方法 ← 测试环境与辅助工具 ← 测试完成准则 ← 人员与任务表 o 项目经理审批《系统测试计划》。该计划被批准后，转向[Step2]。 [Step2] 设计系统测试用例 o 系统测试小组各成员依据《系统测试计划》和指定的模板，设计（撰写）《系统测试用例 》。 o 测试组长邀请开发人员和同行专家，对《系统测试用例》进行技术评审。该测试用例通过 技术评审后，转向[Step3]。 [Step3] 执行系统测试 o 系统测试小组各成员依据《系统测试计划》和《系统测试用例》执行系统测试。 o 将测试结果记录在《系统测试报告》中，用“缺陷管理工具”来管理所发现的缺陷，并及时 通报给开发人员。 [Step4] 缺陷管理与改错 o 从[Step1]至[Step3]，任何人发现软件系统中的缺陷时都必须使用指定的“缺陷管理工 具”。该工具将记录所有缺陷的状态信息，并可以自动产生《缺陷管理报告》。 o 开发人员及时消除已经发现的缺陷。 o 开发人员消除缺陷之后应当马上进行回归测试，以确保不会引入新的缺陷。 13.2.6 输出 o 消除了缺陷的最终软件系统 o 系统测试用例 o 系统测试报告 o 缺陷管理报告 13.2.7 结束准则 o 对于非严格系统可以采用“基于测试用例”的准则： ← 功能性测试用例通过率达到100％； ← 非功能性测试用例通过率达到80％时。 o 对于严格系统，应当补充“基于缺陷密度”的规则： ← 相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m。例如n大于10，m小于等于 1。 o 本规程所有文档已经完成。 13.2.8 度量 o 测试人员和开发人员统计测试和改错的工作量，文档的规模，以及缺陷的个数与类型， 并将此度量数据汇报给项目经理。 13.3 实施建议 o 对系统测试人员进行必要的培训，提高他们的测试效率。 o 项目经理和测试小组根据项目的资源、时间等限制因素，设法合理地减少测试的工作量 ，例如减少“冗余或无效”的测试。 o 系统测试小组根据产品的特征，可以适当地修改本规范的各种文档模板。 o 对系统测试过程中产生的所有代码和有价值的文档进行配置管理。 o 为了调动测试者的积极性，建议企业或项目设立奖励机制，例如：根据缺陷的危害程度 把奖金分等级，每个新缺陷对应一份奖金，把奖金发给第一个发现该缺陷的人。 ----------------------- 迭代 审批 执行系统测试 制定测试计划 缺陷管理与改错 设计测试用例 审批
第13章 系统测试