附件九 设计评审报告
文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改 版 本 历 史 版本/状态 1. 基本信息
作者 参与者 起止日期 备注 文件标识： ProjectName- 当前版本： X.Y 作 者： 完成日期： Year-Month-Day 提示：由评审主持人或评审员填写此表格。 待评审的工作成果 工作成果名称，标识符，版本，作者，时间… 技术评审方式 评审时间 评审地点 参加技术评审的人员 类别 主持人 评审 小组 成员 记录员 名字 第36页，共52页
（正式评审）或者(走查) 工作单位 职称、职务： 2. 缺陷识别和跟踪
评审问题跟踪表 编问题问题严重性 提交者 提交日期 问题处理负责人 解决措施/原因说明 问题解决状态 实际关闭日期 问题关闭验证人 1 2 3 3. 评审结论与意见
备注 号 描述 类型 提示：由主持人或评审员填写此表格。
[ ] 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。 评审结论 [√] 工作成果基本合格，需要作少量的修改，之后通过审核即可。 [ ] 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。 意见 负责人 签字 签字： 日期： 第37页，共52页
附件十 系统/用户测试计划
文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改 版 本 历 史 版本/状态 1. 测试范围与主要内容
提示：系统测试小组应当根据项目的特征确定测试范围与内容。一般地，系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性（security）测试、安装与反安装测试等。
2. 测试方法
提示：例如黑盒测试和白盒测试。 3. 测试环境与测试辅助工具 环境
设备 服务器 客户端 网络 工具 配置 软件 硬件 软件 硬件 名称/类型 备注 作者 参与者 起止日期 备注 文件标识： 当前版本： 作 者： 完成日期： 类型 测试管理 缺陷跟踪 用于功能性测试的工具 用于性能测试的工具 工具 开发商 版本 第38页，共52页
测试覆盖监测器或评测器 4. 测试进度计划 任务 制定测试计划 设计测试 实施测试 执行测试 对测试进行评估 5. 测试完成准则 提示：
人员 任务 开始日期 结束日期 对于非严格系统可以采用“基于测试用例”的准则： （1）功能性测试用例通过率达到100％； （2）非功能性测试用例通过率达到95％时。 对于严格系统，应当补充“基于BUG密度”的规则：
相邻n个CPU小时内“测试期BUG密度”全部低于某个值m。例如n大于10，m小于等于1。
最后一次回归测试二类缺陷数量为零，用例外非常规缺陷数量小于等于2 个/万行程序；
测试用例功能点覆盖率100%； 6. BUG管理与改错计划
提示：根据所采用的BUG管理工具确定：（1）BUG管理流程，（2）BUG修改流程。
定义BUG修改约定，例如：不同级别的BUG必须在几日内处理完成。 7. 附录. 本计划审批意见 项目经理审批意见： 签字 日期
第39页，共52页
附件十一 系统/用户测试报告
1. 基本信息 测试依据 测试范围 测试验收标准 测试环境描述 测试驱动程序描述 测试人员 测试时间 须注明每次回归测试的时间 测试工具 2. 实况记录 模块 测试用例编号 期望结果 测试结果 缺陷密度 是否执行了回归测试 例如：参照标准、客户需求、需求规格说明书、测试用例等 提示：可以把测试驱动程序当作附件 3. 测试总评价 根据对测试结果提出一个关于软件能力的全面分析，需标明遗留的主要缺陷、局限性和软件的约束限制等，并提出软件测试过程中程序中的不足。
根据测试标准及测试结果，综合评价软件的开发是否已达到预定目标。 4. 缺陷修改记录
提示：如果采用了缺陷管理工具，能自动产生缺陷报表的话，则无需本表。 缺陷名称 缺陷类型 … 测试人员签字/日期：
严重程度 模块 原因 驻留时间 解决方案 第40页，共52页
软件开发的具体流程与管理制度详解
