CMMI代码检查报告
CMMI-3CM-SP11-配置项状态报告模板
项目名称 配置项名称 系统需求说明书 系统概要设计说明书 系统详细设计说明书 需求跟踪矩阵 数据库设计 .net公共模块 程序源代码（需细 分） UI设计说明书 测试计划 测试报告 软件维护说明书 可执行代码 项目计划
河南济源信贷管理系统
配置项标识
当前版本 配置项状态
JYXD_XTXQSMS
已基线 20060413
20060413
黎平 所属基线 功能基线 设计基线 设计基线 设计基线 设计基线 产品基线 产品基线 产品基线 产品基线 产品基线 产品基线 产品基线 产品基线
1）计划类是受控配置项； 2）报告类是存档； 3）表中只保存最后一个版本的信息，详细信息看变更记录 4）出库时间为最后一次出库时间，如果是存档类的内容没有出库可言。 5）不同的基线应当存放在不同的路径下 6）平时开发的代码或文档，没有必要进基线库或受控库。所以应当不会出现33次修改，请看《配置管理计划》 7）项目经理不能直接负责配置管理工作
20060703
JYXD_SJCSJ
1
已基线 20050614
20050614
JYXD_CODE_NET_COMMON
1.4
已基线 20060301
20060301
JYXD_CODE_SOURCE
1.33 已基线 20060412
20060412
JYXD_UI
1
已基线 20050622
20050622
20060610 变更次数
0 3 2 0 0 4 3 1 3 3 2 3 2
JYXD_TESTPLAN
1.3
已基线 20050630
20050630
JYXD_TESTREPORT
CMMI-差距分析报告
过程和方法
Y Y Y Y Y Y Y Y Y Y Y
实施 Y Y Y Y Y Y Y Y Y Y Y
一、评估范围
级别
Maturity Level 4
过程域名称 Organization Process Performance Quantitative Project Management
过程和方法 Y Y
确认计划和软件开发计划进行整合。
加强对上线三月缺陷检出密度的分析。
一、组织过程焦点（OPF）
Strength
None
Opportunity
加强收集项目中的最佳实践。
加强收集过程改进需求。
通过分析项目过程数据识别过程改进机会。
建议加强CMMI流程的培训和推广。
一、组织过程定义（OPD）
Strength
None
Opportunity
简化QA使用的过程和产品检查单
一、配置管理（CM）
Strength
None
Opportunity
配置管理过程尽量使用现有的VSS工具。
配置状态报告等建议从使用的工具中导出。
一、CMMI L3
需求开发
技术解决方案
产品集成
Y
Supplier agreement management
N
实施 Y Y Y Y Y
Y N
一、评估范围
级别
Maturity Level 3
过程域名称 Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Foucs Organizational Process Definition Organizational Training Integrated Project Management Risk Management Decision Analysis and Resolution
CMMI QA检查单
验收检查单
1) 转产资料是否完整、正确 2）转产资料是否已顺利交接给供应链 3）是否有转产资料清单 4）转产评审记录检查
1）工程施工启动会议 2）工程施工计划 3）工程文件 4）勘测计划 5）工程勘测报告 7）施工方案 8）验货签收单 9）工程进度计划 10）工程问题记录表 11）工程初验报告 12）工程总结报告
配置管理检查单
2）质量检查结果是否有做记录 3）质量问题是否被处理并做记录，
质量保证检查单
41） ）是 是否 否编 做制 度质 量量 计报 划告
2）度量数据收集记录
3）是否做度量分析，度量分析的问题是否做处 理
度量分析检查单
1）是否按决策时机启动决策分析过程
2）是否召开决策分析会议
3) 编制决策分析报告
1）风险识别是否合理 2）是否进行风险评估 3）是否进行风险缓解 4）是否进行风险监控
项目监督与控制检查单 变更管理检查单 风险管理检查单
关键管控点
1）项目需求规格书是否进行评审 2）需求规格书是否能够涵盖客户所需的所有要 求 3）需求规格书功能参数是否符合相关规范及要 求（参考用户要求、国军标等） 4）是否建立需求跟踪矩阵 1）项目总体方案及各分方案是否进行评审 2）总体方案编制是否按需求规格书中的要求 3）各分方案设计是否明确， 能够顺利执行 4）方案评审后需发布
1）变更申请 2）变更评估 3）变更通知 4）变更实施 5）变更验证 6）变更发布
1）项目风险跟踪表 2）项目风险管理报告
研发过程检查（依项目策划
调整）
项目研制阶段
建议检查频度
内容
需求
每节点、里程碑检查，至少一次
1）项目需求规格说明书 2）需求评审
方案设计
CMMI实施经验总结-检查单设计
CMMI实施经验总结-检查单设计CMMI实施经验总结-检查单设计睿泰科技王高球本文来源于多年从事CMMI研发管理咨询的经验总结，相信很多实施过CMMI的企业都会被各种各样的“检查单”所淹没，甚至到最后所以人员看到检查单就烦，从而变成了一种负担。
众所周知，高质量的产品是企业赖以生存的根本，而如何保证企业能生产出高质量的产品呢？这一直是质量管理知识领域的一个重大研究课题，就目前来讲，保证产品质量主要有以下几种手段：一、 QA检查：保证公司通过长时间一点一滴积累形成的企业财富（例如公司管理及工程技术相关过程和标准）能很好的在以后项目中得到充分应用。
二、评审（技术或者管理）：所谓“当局者迷，旁观者清”，这也是很多企业为什么会投入资源执行这项活动的根本目的。
三、测试：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并评估其满足设计、需求、乃至客户诉求的程度。
相信大家对上面三种质量手段概念都已经是再熟悉不过了，在这里我也不过多详细阐述了。
但就我多年的咨询经验来讲，上述几种质量手段，除了测试在各个公司还算是得到应有的重视并充分实施外（因此测试在本文中也就不阐述了），其他两种手段要么是没有做，要么是浮于形式。
其实并不是企业不想好好去应用好“QA检查”和“评审”这两项质量手段，而是不知道怎么去利用好这两种质量手段去提升公司产品质量。
通过这些年的经验积累，以及跟同行的交流，大家基本上都赞同要让“QA检查”和“评审”这两种质量手段产生明显的效果，核心在于这两种质量手段都会用到的“检查单”，下面将给大家介绍怎样才能设计并使用好“检查单”这种工具。
检查单（Checklists）是软件质量管理活动中最常用的工具之一，通过检查单的作用是提醒检查人员检查哪些内容，避免遗漏。
在设计、使用检查单时，需要重点关注以下六点：（1）2种类型的检查单要分开设计检查单可以分为针对形式的检查单与对针对内容的检查单针对形式的检查单是一种有法可依的检查单，他们需要依据公司的过程、规程、模板、指南等而定义，是由QA人员来使用，主要是用来检查活动、工作产品与规范的符合性问题。
CMMI-差距分析报告课件 (一)
CMMI-差距分析报告课件 (一)CMMI（Capability Maturity Model Integration，能力成熟度模型集成）是一种软件过程改进的标准模型，旨在帮助组织改进其软件开发过程的能力，并以此为基础实现业务目标。
而CMMI-差距分析报告课件则是一份基于CMMI模型的分析报告，旨在帮助组织发现其当前软件开发过程存在的问题，并提出具体的改进建议。
本文将重点介绍CMMI-差距分析报告课件的主要内容，包括它的结构、分析方法和实际意义。
一、结构CMMI-差距分析报告课件通常由四个部分构成：1. 引言：简要介绍CMMI模型以及该报告的目的和主要内容。
2. 现状分析：对组织目前的软件开发过程进行全面的梳理和分析，包括过程文档、流程控制、资源配置等方面。
3. 诊断分析：建立起组织目前的软件开发过程与CMMI模型的对应关系，并根据实际情况对其进行评估，从而具体分析出组织在软件开发过程中存在的差距。
4. 改进建议：根据诊断分析的结果，给出具体的改进建议，包括过程改进计划、培训计划等方面，并明确改进的优先级和重点。
二、分析方法CMMI-差距分析报告课件主要采用两种分析方法：1. 基于问卷和面谈的调研分析方法。
通过向组织的内部和外部人员发放问卷、进行面谈，收集有关组织软件开发过程的数据和意见，从而对其进行综合分析。
2. 基于模型的分析方法。
将组织的软件开发过程和CMMI模型进行对应，查找差距，从而全面分析组织软件开发过程中存在的问题，提出改进建议。
三、实际意义CMMI-差距分析报告课件对组织来说具有重要的实际意义：1. 帮助组织发现软件开发过程中存在的问题。
通过全面的分析，揭示出组织软件开发过程中存在的差距，并在此基础上提出具体问题和改进的建议。
2. 提升软件开发的能力和效率。
通过对软件开发过程的诊断和改进，组织能够提升自身的软件开发能力和效率，从而为业务发展提供更加有力的支持。
3. 为可持续发展提供依据。
【软件工程】【CMMI】试运行报告
试运行报告文档修订记录*变化状态：C——创建，A——增加，M——修改，D——删除，AU——审核目录1 项目进度 (4)2 项目质量 (4)3 项目成本 (4)4 项目风险 (4)5 项目资源 (4)6 项目范围 (4)7 项目沟通 (4)8 项目文档 (5)9 项目评价 (5)10 遗留问题 (5)11 经验教训及建议 (5)1项目进度按照项目整体计划或项目滚动计划编写的计划工期与实际工期之间差距和原因分析。
其间有哪些变化？对工作量的估计如何？2项目质量项目的最终交付物与客户实际需求的符合度。
合同项目注意完成合同的要求与客户提出的需求，自研项目注意是指内部的要求，比如《项目建议书》等等。
项目质量管理不但包括对项目本身的质量管理，也包括对项目生产的产品进行的质量管理。
具体可以是质量计划、质量保证入手。
同时，对项目管理流程上的问题提出改进意见。
3项目成本就计划成本、实际成本对比成本构成明细的差距和原因分析及建议，也包括项目合同款执行情况的分析总结。
这里主要计算的成本是人工费。
4项目风险这里暂时主要指项目中发生的变更和项目中发生问题的分析统计的总结。
5项目资源项目资源不但包括人力资源情况，而且还包括设备、材料等其它资源的合理使用、开发情况。
特别是项目成员的绩效统计分析和评价，其中，必须是对每个项目成员的详细评价及评分。
人力资源包括项目组人员在项目组工作的起止时间；6项目范围项目范围包括产品范围和项目范围。
其中，产品范围定义了产品或服务所包含的特性和功能；项目范围定义了为交付具有规定特性和功能的产品或服务所必须完成的工作。
合同中所规定的产品范围和项目范围以及用户确认的计划等都属于项目中要控制的范畴，另外还包括实际执行情况的差距和原因分析。
7项目沟通沟通是人员、技术、信息之间的关键纽带，是项目成功所必须的。
项目过程中的内部、外部沟通交流是否充分，以及因为沟通而对项目产生的影响等方面进行总结。
8项目文档项目文档，包括硬拷贝文档和电子文档，都应该收集、整理、编制、控制和移交，以便统一归档保存和进一步开发利用。
CMMI-项目总结报告模板
【项目名称】项目总结报告广东×××技术股份有限公司修订历史记录【模板使用必读：模板内容和页眉中【】包含内容为指导性的待替换文字，请在使用中替换为具体内容，或删除。
文件提交时不得再含有这些内容。
】目录1引言 (4)1.1编写目的 (4)1.2背景 (4)1.3范围 (4)1.4参考资料 (4)2项目工作成果 (5)2.1交付给用户的产品 (5)2.2交付给研发中心的产品 (5)2.2.1代码部分 (5)2.2.2文档部分 (6)2.3需求完成情况与功能及性能符合性统计 (6)2.3.1需求完成情况统计 (6)2.3.2功能符合性分析 (6)2.3.3性能符合性分析 (7)3项目工作分析 (7)3.1项目计划与进度实施分析 (7)3.1.1开发进度 (7)3.1.2项目计划变更统计 (8)3.1.3项目计划评价 (8)3.2成本分析 (8)3.2.1人力成本 (8)3.2.2项目费用 (8)3.3项目质量分析 (9)3.3.1不符合项记录统计 (9)3.3.2缺陷数据统计分析 (9)3.4风险管理实施情况分析 (10)3.5项目团队评价 (11)3.5.1团队建立 (11)3.5.2团队建设措施 (11)3.5.3团队中存在的问题 (11)3.5.4对项目成员的评价 (11)4对技术方法的评价 (11)5专利版权及知识共享情况 (12)5.1专利与版权情况 (12)5.2知识共享情况 (12)6项目主要资产及处理意见 (12)7项目自我总体评价 (12)8经验与教训总结 (12)1引言1.1编写目的【目的：<<XXX项目>>的（研发或合同）项目已经完成，特编写此项目总结作为系统结项的依据。
同时指出预期的读者：如，中心领导、本项目组成员、PMO、结项评审小组。
】1.2背景【对项目基本信息作简要介绍。
】项目计划开始时间：项目计划结束时间：项目实际开始时间：项目实际结束时间：1.3范围【如，本文档主要包括项目背景、项目范围、实际开发成果、开发工作评价、项目组内部工作总结以及项目经验与教训总结。
CMMI-差距分析报告课件 (二)
CMMI-差距分析报告课件 (二)1. CMMI简介- CMMI是一种软件过程改进模型，旨在帮助组织提高其软件开发和维护的过程，从而实现更高的质量、效率和效益。
- CMMI包括5个级别，每个级别都涵盖了一组特定的过程能力，从初始级别到优化级别逐渐提高。
2. 差距分析的意义- 差距分析是评估组织当前过程能力与目标能力之间差异的一种方法。
- 通过差距分析，组织可以更好地理解其当前状态，并确定需要采取哪些措施来改进其过程能力。
3. 差距分析报告的内容- 差距分析报告应包括组织的现状分析、目标能力分析和差距分析。
- 现状分析应包括组织的过程能力、资源和人员分析等。
- 目标能力分析应包括组织希望达到的过程能力和目标状态。
- 差距分析应对组织现状和目标能力进行比较，确定差距所在的领域和程度，并提出改进建议。
4. 差距分析报告的编写步骤- 确定差距分析的目的和范围。
- 收集和整理组织的现状信息和目标能力信息。
- 对现状和目标能力进行比较，确定差距所在的领域和程度。
- 提出改进建议，并制定改进计划。
- 撰写报告，并进行审阅和修改。
5. 差距分析报告的应用- 差距分析报告可作为改进计划的基础，帮助组织制定改进策略和实施计划。
- 差距分析报告还可用于组织内部的沟通和交流，帮助各部门和人员更好地理解组织的现状和目标，共同推进改进工作。
- 差距分析报告也可用于组织对外宣传，展示组织的过程能力和改进成果，提升组织的形象和信誉度。
6. 差距分析的挑战和注意事项- 差距分析需要收集大量的信息和数据，需要投入大量的时间和精力。
- 差距分析需要对组织的过程能力和业务进行深入的了解和分析，需要具备相关的知识和技能。
- 差距分析需要充分考虑组织的实际情况和资源限制，制定合理的改进计划和实施方案。
CMMI-门禁系统代码评审报告
评审组意见： 1.增加适当的代码调试2.代码分组不够明显
建议性意见：
必须性意见：
1.减少远程数据调用次数，多采用本地缓存策略 2.增加更多容错处理
评审总工时：
40
问题数量 12
评审结论：(“有条件通过”时请说明“条件”是什么；“不通过”时需说明理由)
□ 通过 ■有条件通过 □ 不通过 说明：所有问题修正后，评审通过
项目名称
IACS_广州市×××电子门禁系统
评审性质
评审类型
技术类 管理类
评审时间
代码评审总数（千行）
□需求 □设计 ■编码 □测试用例 □其它 □立项 □项目计划 □里程碑 □结项 □其它
代码总数
■初审 □复审
评审材料清单：《IACS_广州市×××电子门禁系统代码》《IACS_广州市×××电子门禁系统_系统测试计划_v1.0.docx》
评审成员
签字
评审成员
评审组成员签字
签字
评审成员
评审成员
签字
评审成员
签字评审成员ຫໍສະໝຸດ 评审成员签字评审成员
签字
评审成员
问题按时关闭率
100%
签字 签字 签字
评审成员 评审成员 评审成员
签字 签字 签字
审批人意见： 评审通过。按照评审意见进行下一步工作
签名
时间
QR20-01 代码检查表 CMMI项目管理
开闭原则，软件应该对扩展开放，对修改关闭。也就是 说，应该在不修改以前源代码的基础上，改变程序的行 为以适应新的需求。
里氏代换原则：假设有两个类，一个是基类Base，一个 是派生类Derived，如果一个方法可以接受基类对象b的 话：method1(Base b)，同样，这个方法也应该接受派生 类Derived的对象d，而不影响方法的行为。里氏代换原 则是继承复用的基石。
强制 推荐
强制
强制 强制 强制 推荐 强制 强制 强制 强制 强制 强制 强制 强制 强制
推荐
强制
记录编号： 第3页 共6页
54 55 56 57 58 59 60
61 62 63 64 65
66
67 68
69
版本号：2 修订号：0
注释尽量简洁，尺度没有准确的定义，大部分人能明白 即可，可以将自己的代码给同事看看。 接口中的方法一定要编写注释。 应使用正式的.net风格的xml tag进行注释。 代码的版权信息，每个源文件都应包含版权信息。 类注释，描述类的主要职责。 对于public方法和长方法应进行注释，描述方法是做什 么的，如何调用，最好给出调用代码示例。 复杂的算法、长方法的实现要编写内部实现注释，从为 什么要这么做角度去描述。 对已经正式发布版本中的代码进行修改和维护时，应该 在修改处进行内部注释并注明修改人、修改时间、修改 意图以及应注意问题等。 使用行末注释对深层嵌套代码进行注释。 所有变量都应该进行初始化。 变量在使用前应进行合法性检查。 静态变量和方法的使用应保证线程安全。 所有异常应该被正确的处理，不应简单的吞掉异常或打 印。应该将异常记入日志或者包装后向上层抛出。对于 表现层页面，不应该出现程序异常，应该在捕获到异常 后进行友好的提示。 对于静态方法，应该使用类名去使用，不应该用实例去 引用，主要是为了体现更多的语义。 对一些基本数据类型和不太可能通过继承进行扩展的 类，应声明为readonly，提高效率。
CMMI-代码审查报告模板
【审核人员填写此表格。如果使用缺陷跟踪软件，则无需填写此表。或者如果使用缺陷管理过程，则使用缺陷跟踪过程表格。】
程序名称
包括哪些模块。如不是完整模块，则说明是哪个模块中的哪些接口。
功能描述
开发者
起止日期
审查者
审查日期
缺陷名称
何人何时如何解决
审核人意见、签字
程序名称
包括哪些模块。如不是完整模块，则说明是哪个模块中的哪些接口。
功能描述
开发者
起止日期
审查者
审查日期
缺陷名称
何人何时如何解决
审核人意见、签字
……
【项目名称】
代码审查报告
文件编号
【项目编号】/ HW-SP-IMPT-T07
文件状态
[]草稿 [ ] 正式发布 [ ]正在修改
当前版本
拟 制
日期
审 核
日期
批 准
日期
广东×××技术股份有限公司
修订历史记录
A-增加M-修订D-删除*M*D）
修改人
摘要
备注
【模板使用必读：模板内容和页眉中【】包含内容为指导性的待替换文字，请在使用中替换为具体内容，或删除。文件提交时不得再含有这些内容。】
CMMI-33.里程碑评审报告模板
实际完成
4.1.1.1 4.1.1.2 4.1.2.1 4.1.2.2
4.2
投入工作量 工种 编码
计划投入 10
实际投入 12
2007/5/26
偏差说明 0 0 0 0 0
相对偏差 20.00%
人员投入 工种 编码
计划人员投入 2
实际人员投入 2
偏差说明 0.00%
本里程碑设备投入 序号 1 2
评审意见： 下一阶段可能风险：
评审结论：
■ 通过。
□ 不通过。理由：
（如需重新评审，在下面打勾）
□ 重新评审日期：
□ 有条件通过。理由：
条件：
问题解决人：
日期：
追踪人：
日期：
项目经理
周密
PPQA人员
张婷
建立日期:2007-05-24
里程碑评审报告
项目名称 项目负责人 本里程碑名称 本里程碑主要产品 评审出席人员
江西省高级人才库系统 周密
编码实现
项目编号 评审日期 评审主持人
刑毅、周密、吴 4 5
计划完成
4.1.1.1 4.1.1.2 4.1.2.1 4.1.2.2
2007.02.07
2007.02.08
7
PPQA检查单
2007.02.07
2007.02.08
8
配置项状态报告
2007.02.07
2007.02.08
评审相关材料：[ 项目资源计划跟踪表 , 相关人员参与计划跟踪表 , 项目计划 , 风险分 析和监控表 , 问题一览表 , 数据管理计划和跟踪表 ,PPQA 检查单 , 配置项状态报告 ]
2
相关人员参与计划跟踪 表
3
04 终验报告(CMMI模板)
项目名称
项目编号
地点
终验人员
终验结论：
[举例如下：
根据XX（客户合称）与X公司签订的《XX合同》（合同名称），X公司已完成合同中的任务，工程质量符合合同要求。
经过双方确认，同意对该项目进行终验，向X公司颁发该项目的终验报告证书，该终验报告证书一式二份，终验单位各持一份。
X公司将继续严格执行合同规定，对于遗留问题将按照进度要求做好后续的开发维护和支持工作。]
用户代表签字（盖章）
年 月 日
项目经理签字：
年 月 日
部门经理签字：
年 月 日
CMMI实验报告
CMM2标准CMM 2（可重复级）就是建立了基本的项目级管理过程，可对项目的成本、进度进行跟踪和控制，生产的过程、标准、工作产品以及服务都是被严格定义和文档化的。
基于以往管理类似的项目的经验，计划和管理新项目，并可依据一定的标准重复利用类似的软件产品。
CMM 2的核心就是重复利用。
CMM2由6个关键过程域(KPA)组成：需求管理(RM)、软件项目计划(SPP)、软件项目跟踪与监控(SPTO)、软件子合同管理(SSM)（本文略）、软件质量保证(SQA)、软件配置管理(SCM)。
需求管理(Requirement Management)需求管理的目的是为了在客户和处理客户需求的软件项目之间建立共识。
这是软件项目规划(SPP)和管理(SPTO)的基础，需求变更依赖于配置管理(SCM)的变更控制流程。
在项目实施过程中，最突出的现象就是项目组成员没有完全理解需求，软件需求不稳定，客户经常变更需求，无法有效控制需求变更，需求变更往往造成项目延期和费用超支。
CMM2要求的需求管理的基本流程可如<图一>所示。
该流程描述了软件工程组开始获取原始需求，汇总为系统需求，分配系统需求，复审软件需求，软件需求必须文档化形成需求文档，此文档必须经过相关组和个人的评审，通过评审之后才纳入配置管理，为需求文档建立基线。
软件项目计划、活动及软件工作产品，应和软件需求的变化保持一致。
根据流程，可以结合实际开发情况确定项目的需求管理步骤：a. 获取需求和确认需求以Use case（用例）为单位，以Rational Requisite Pro作为需求管理工具，使用Rational Rose进行维护Use case和Use case Model。
获取需求工件是：用例模型(Use case Model)、非功能性的“补充规约”、用例规约(Use case Specification)、词汇表(Glossary)b. 通过访谈，从客户处获取原始需求，形成需求文档。
CMMI-3里程碑评审报告071002-V1.0
相对偏差
实际里程碑进度 本里程碑相对偏差 本里程碑绝对偏差
里程碑评审其他事项 序号 1 2 3 4 项目进度表 , 风险分析和监控表 , 问题一览表 , 项目数据管理计划和 跟踪表 ,PPQA 检查单 , 配置项状态报告 ]
评审意见：
下一阶段可能风险：
评审结论：
■ 通过。
□ 不通过。理由：
（如需重新评审，在下面打勾）
□ 重新评审日期：
□ 有条件通过。理由：
条件：
问题解决人：
日期：
追踪人：
日期：
项目经理
PPQA人员
建立日期:
项目名称 项目负责人 本里程碑名称 本里程碑主要产品 评审出席人员
工作包完成情况 计划完成（个）
里程碑评审报告
项目编号 评审日期 评审主持人
实际完成（个）
相对偏差
投入工作量 工种 编码
计划投入
实际投入
备注 相对偏差
本里程碑设备投入 序号 1 2
里程碑时间进度 计划里程碑进度
计划投入
实际投入
CMMI-3系统测试报告
某某区电子政务系统测试分析报告版本 <0.1>修订历史记录目录1.简介 (4)1.1目的 (4)1.2范围 (4)1.3定义、首字母缩写词和缩略语 (4)1.4参考资料 (4)1.5概述 (4)2.测试结果摘要 (5)2.1测试总结 (5)2.2测试简介 (5)2.3测试机构和人员 (5)2.4测试环境 (5)3.基于需求的测试覆盖 (6)3.1测试结果汇总表 (6)3.2源程序代码行及千行代码错误率统计 (6)3.3系统缺陷提出情况 (7)3.4缺陷修改情况 (7)4.评价 (7)测试分析报告1.简介某某区电子政务系统测试分析报告是以真实有效的测试数据为依据，并结合需求规格说明书和概要设计说明书，得出的相关项目现阶段开发成果分析报告。
1.1目的本文档是依照某某区电子政务系统的测试计划及测试用例进行测试后，汇总得出的报告，并对测试结果进行分析。
因此，它既可以成为纠正软件缺陷的依据，也可以为软件验收和交付打下基础。
1.2范围本文档适用于某某区电子政务系统分析阶段及试运行前阶段。
本文档只是针对试运行前阶段的本项目的测试分析报告，不包括项目实施中，以及项目试运行后系统作的一些修改的回归测试。
本文档的预期读者包括：✧高级管理者――根据此文档了解相关项目的进展及其它情况。
✧质量保证人员――依据此文档提供的数据，对该项目的质量作出评估。
✧项目经理及开发人员－－对项目的当前状况进行分析并提出相应改进措施。
✧软件测试人员――对相关项目的前阶段测试工作做出总结。
1.3定义、首字母缩写词和缩略语PW-HSEGOV ——某某区电子政务系统1.4参考资料1.5概述本文档包括“测试结果摘要”、“基于需求的测试覆盖”及“评价”3个方面的内容，其中：➢测试结果摘要：主要对本次测试的最后结果进行总结，包括测试的通过情况、测试机构和人员的介绍以及测试环境的相关情况。
➢基于需求的测试覆盖：主要是参考需求说明书，对测试结果进行汇总，并列举出了缺陷的分布情况等信息。
CMMI-3集成测试报告-例子
某某区电子政务系统集成测试分析报告第一章简述1.1 测试内容某某区电子政务系统分外部门户网站、办公业务门户和办公OA系统三大组成部分。
对该三大组成部分分别作如下测试。
极限测试：由每个模块使用大致对应数目的虚拟用户逐渐按比例加压，记录能正常工作的情况下的最大用户。
响应时间测试：测试实时页面和含有控件的页面响应时间。
实时页面的响应时间不超过3秒，有控件加载的页面的响应时间不超过7秒。
运行环境测试：测试该系统在需求规格说明书所明确的软硬件环境下能否正常运行。
1.2 测试环境●服务器一台：曙光天阔S240-Xp4Cpu 2.0g hz X 4内存 2.0g硬盘80g操作系统：应用服务器：数据库服务器：JA V A环境JRE1.5_04或以上版本●客户端4-5台：兼容机Cpu 1.8g hz内存512M硬盘40g操作系统WINDOWS2000网页浏览器 IE6.0或以上版本●测试模拟和测试监控测序loadrunner 8.01.3 测试进度安排测试环境的搭建●测试环境的搭建：半天，选择一台服务器，4-5台客户端，如果操作系统不一致的必须从新安装，服务器上安装某某区电子政务系统，所有客户端安装LoadRunner8,安装类型选择Standalone Installation，安装方式选择Custom Installation。
以服务器系统能访问，客户端LoadRunner能运行为标准判断该阶段是否完成。
●外部门户网站模块的测试：2天，进行脚本录制，及修改测试脚本。
提取部分打开实时页面和含有控件页面的步骤包含入事务，实时页面事务标注为index_rlt_ 序号,含有控件页面事务标注为index_ctrl_序号, 所有脚本一起进行极限测试。
●内网站模块的测试：2天，进行脚本录制，及修改测试脚本。
提取部分打开实时页面和含有控件页面的步骤包含入事务，实时页面事务标注为index_rlt_ 序号,含有控件页面事务标注为index_ctrl_序号。