评审检查表.docx
《评审检查表.docx》由会员分享，可在线阅读，更多相关《评审检查表.docx（20页珍藏版）》请在冰豆网上搜索。
评审检查表
评审检查表
文档修改情况记录
版本
修改状态
修改日期
修改摘要
修改人
目录
1.项目计划检查表3
2.需求规格说明书检查表4
3.概要设计说明书检查表5
4.详细设计说明书检查表6
5.编码检查表7
6.测试用例检查表10
7.产品验收和发布检查表11
1.项目计划检查表
项目计划检查表
项目编号
工作产品
检查日期
检查人员
检查结果标记
合格不合格TBD待完成NA不适用
检查情况
检查项：
项；有效检查项：
项；通过项：
项；通过率：
序号
主要检查项
检查结果
说明
标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
完整性
5
文档有独立的版本说明部分
6
文档列出了项目的验收标准
7
文档列出了项目组成员和项目相关人员、角色、职责
8
文档选择了项目生命周期模型
9
文档选定了项目里程碑
10
对项目进行了估计（规模、工作量、进度、关键计算机资源、成本）
11
进行了WBS工作分解
12
文档作了项目的风险估计及风险管理计划
13
文档分析了项目所需的知识技能及培训计划
14
编写了配置管理计划
15
编写度量计划
16
编写质量保证计划
17
使用project项目管理工具编写项目进度计划
符合性检查
18
风险管理计划的风险是否排序，对前三个是否进行了分析，缓解计划是否合理
19
培训计划中的培训内容是否是项目组需要的、可行的
20
配置管理计划中的配置库机构划分是否合理，是否对开发过程中的工作产品进行了配置项的设置
21
质量保证计划是否检查了列表，和开发计划的进度是否一致
22
项目进度计划的工作任务是否包括了生命周期的所有工作（如：
是否覆盖了所有需求的设计和开发）
23
项目进度计划的资源和时间分配是否合理，里程碑的划分和交付物是否明确
承诺性
24
计划中列出的相关人员是否都了解自己的角色和职责，并在承诺记录上签字
2.需求规格说明书检查表
需求规格说明书检查表
项目编号
工作产品
检查日期
检查人员
检查结果标记
合格不合格TBD待完成NA不适用
检查情况
检查项：
项；有效检查项：
项；通过项：
项；通过率：
序号
主要检查项
检查结果
说明
标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
5
设计陈述中的命名、术语和缩写是否上下文一致
完整性和正确性
6
文档有独立的版本说明部分
7
没有丢失任何需求或必要信息，重点在于用户任务
8
是否包括了所有的原始需求（指系统或软件需求，通常限制在开发或验证上）
9
规格说明书中是否指明了所有已知的用户或系统需求？
所有用户要完成的任务都包含了吗（只有用户代表才能决定用户需求的正确性）
10
需求表达是否清晰、易理解、无二义性
11
每个功能需求都适当地指定了输入、输出项
12
已经明确陈述出所有的条件与限制
13
数据精度、时间特性和适应性是否已经明确
14
运行需求是否明确（运行平台、接口需求、用户界面等），符合初始需求
15
对质量的要求是否明确、合理（正确性、健壮性、安全性等）
16
是否分析了潜在的需求
17
是否标识并解决了需求中的潜在问题
一致性
18
是否存在冲突或重复的需求项
19
开发计划、产品和活动与需求是否保持一致
20
是否可以根据软件需求规范中的信息制定出详细的测试集，并且每项需求是否可以测试
21
是否有《需求跟踪矩阵》
3.概要设计说明书检查表
概要设计说明书检查表
项目编号
工作产品
检查日期
检查人员
检查结果标记
合格不合格TBD待完成NA不适用
检查情况
检查项：
项；有效检查项：
项；通过项：
项；通过率：
序号
主要检查项
检查结果
说明
标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
完整性
5
文档有独立的版本说明部分
6
有文档的文字目录页
7
有总体设计部分
8
有功能设计
9
有接口设计
10
有性能设计
追溯性
11
设计是否可以追踪到需求
12
需求是否可追溯到设计
符合性
13
是否每个设计都是可测试的或以别的方式可以确定的
14
设计范围、边界是否清晰，文档中是否清晰阐明了系统的各项特性及预期的结果
15
逻辑性、算法和处理过程是否正确
16
文档是否符合客户的需要
17
设计是否考虑到未来的扩充性
18
设计的系统是否易于维护
4.详细设计说明书检查表
详细设计说明书检查表
项目编号
工作产品
检查日期
检查人员
检查结果标记
合格不合格TBD待完成NA不适用
检查情况
检查项：
项；有效检查项：
项；通过项：
项；通过率：
序号
主要检查项
检查结果
说明
标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
5
设计陈述中的命名、属于和缩写是否上下文一致
完整性
5
文档有独立的版本说明部分
6
每个设计是否都有相应的标识
7
每个设计的输入/输出是否进行了描述
8
关键的用户接口是否进行了描述
9
用户接口是否模块化，并且修改时不影响其他程序
10
是否提供了一致的错误处理机制
11
各子系统、模块之间的关系是否描述得清楚
12
系统的设计是否考虑了系统的可扩展性
13
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术，避免使用怪异的、不易理解的方式和方法
18
设计的调用宽度、调用深度、耦合度、内聚度和结构化程序是否进行了描述
追溯性
19
设计是否可以追踪到需求
20
需求是否可追溯到设计
5.编码检查表
通过结合编码检查表和代码检查单，可以比较清楚地确定代码问题的位置。
5.1.代码检查表
代码检查表
项目编号
工作产品
检查日期
检查人员
检查结果标记
合格不合格TBD待完成NA不适用
检查情况
检查项：
项；有效检查项：
项；通过项：
项；通过率：
序号
主要检查项
检查结果
说明
规范性
1
编码是否符合项目或组织的编码标准
2
头文件包含是否完整
3
参数在程序开始时是否被初始化
4
参数在程序循环时是否被初始化
5
在函数或过程调用的时候参数是否被初始化
6
函数调用的格式和参数是否正确
7
变量的声明和拼写是否一致
8
变量声明的范围是否恰当
9
是否所有的指针都被初始化为NULL
10
程序中申请的内存使用后是否释放
11
是否每个==、‖等都验证了正确性
12
是否打开的文件都及时关闭了
符合性
13
源代码单元是否已经完成
14
源代码单元是否已经经过了调试
15
源代码单元是否实现了设计的全部功能
5.2.代码检查内容
重要性
激活
级别
检查项
命名
重要
20
命名规则是否与所采用的规范保持一致
重要
20
是否遵循了最小长度最多信息原则
重要
50
has/can/is前缀的函数是否返回布尔型
注释
重要
10
注释是否清晰且必要
重要
Y
10
复杂的分支流程是否已经被注释
10
距离较远的}是否已经被注释
10
非通用变量是否全部被注释
重要
Y
50
函数是否已经有文档注释（功能、输入、返回及其他可选）
10
特殊用法是否被注释
声明、空白、缩进
20
每行是否只声明了一个变更（特别是那些可能出错的类型）
重要
40
变更是否已经在定义的同时初始化
重要
40
类属性是否都执行了初始化
20
代码段落是否被合适地以空行分隔
Y
20
是否合理地使用了空格使程序更清晰
20
代码行长度是否在要求之内
20
折行是否恰当
语句/功能分布/规模
20
包含复合语句的{}是否成对出现并符合规范
20
是否给单个的循环、条件语句也加了{}
20
If/if-else/if-elseif-else/do-while/switch-case语句的格式是否符合规范
40
单个变量是否只做单个用途
重要
20
单行是否只有单个功能（不要使用“；”进行多行合并）
重要
40
单个函数是否执行了单个功能并与其命名相符
Y
20
操作符++和—的应用是否符合规范
规模
重要
20
单个函数是否不超过规定行数
重要
缩进层数是否不超过规定
可靠性（总则/变量和语句）
重要
是否已经消除了所有警告
重要
Y
40
常数变量是否声明为final
重要
80
对象使用前是否进行了检查
重要
80
局部对象变量使用后是否被复位为NULL
重要
70
对数组的访问是否是安全的（合法的index取值为[0,MAX_SIZE-1]）
重要
20
是否确认没有同名变量局部重复定义问题
20
程序中是否只使用了简单的表达式
重要
Y
20
是否已经用（）使操作符优先级明确化
重要
Y
20
所有判断是否都使用了（变量==）的形式
80
是否消除了流程悬挂
重要
80
是否每个if-else语句都有最后一个else以确保处理了全集
重要
80
是否每个switch-case语句都有最后一个default以确保处理了全集
80
for循环是否都使用了包含下限不包含上限的形式（k=0；k重要
40
XML标记书写是否完整，字符串的拼写是否正确
40
对于流操作代码的异常捕获是否有finally操作以关闭流对象
20
退出代码段时是否对临时对象做了释放处理
重要
40
对浮点数值的相等判断是否是恰当的（严禁使用==直接判断）
可靠性（函数）
重要
Y
60
入口对象是否都被进行了判断不为空
重要
Y
60
入口数据的合法范围是否都被进行了判断（尤其是数组）
重要
Y
20
是否对有异常抛出的方法都执行了try…catch保护
重要
Y
80
是否函数的所有分支都有返回值
重要
50
int的返回值是否合理（负值为失败，非负值为成功）
20
对于反复进行的int返回值判断是否定义了函数来处理
60
关键代码是否做了捕获异常处理
重要
60
是否确保函数返回CORBA对象的任何一个属性都不能为null
重要
60
是否对方法返回值对象做了null检查，该返回值定义时是否被初始化
重要
60
是否对同步对象的遍历访问做了代码同步
重要
80
是否确认在对Map对象使用迭代遍历过程中没有做增减元素操作
重要
60
线程处理函数循环内部是否有异常捕获处理，防止线程抛出异常而退出
20
原子操作代码异常中断，使用的相关外部变量是否恢复先前状态
重要
函数对错误的处理是否恰当
可维护性
重要
实现代码中是否消除了直接常量（用于计数起点的简单常数例外）
20
是否消除了导致结构模糊的连续赋值（如a=（b=d+c））
20
是否每个return前都要有日志记录
20
是否有冗余判断语句（如：
if（b）returnture；elsereturnfalse；）
20
是否把方法中的重复代码抽象成私有函数
备注：
1）激活：
本列标注Y的为激活的项目，表明这些项目必须被明确地自查（其他问题处于“顺便被检查”的状态），在运行编码检查的时候，前期几乎所有项都要在激活状态；后期稳定后，保持8~10个（或遵从当前规范）激活的检查项。
为了醒目，可以像此表这样将当前的激活项用亮黄色表示。
2）级别：
使用IBM10级法，分别是
10
文档
注释，消息
20
语法
拼写，标点符号，打字，指令格式
30
联编打包
变更管理，库，版本控制
40
复制
说明，重名，作用域，限制
50
接口
过程调用和引用，输入/输出，用户格式
60
检查
出错信息，不合适的检查
70
数据
结构，内容
80
函数
逻辑，指针，循环，递归，计算，函数缺陷
90
系统
配置，计时
100
环境
设计，编译，测试，其他支持系统问题
其中10~40是编码错误，50~100是设计错误。
3）检查项：
所有检查项均为一般疑问句，当发现回答为“否”时，即存在一个缺陷。
6.测试用例检查表
测试用例检查表
项目编号
工作产品
检查日期
检查人员
检查结果标记
合格不合格TBD待完成NA不适用
检查情况
检查项：
项；有效检查项：
项；通过项：
项；通过率：
序号
主要检查项
检查结果
说明
完整性
1
测试用例是否覆盖了测试计划的测试需求中描述的所有测试类型和功能点
2
每个测试用例是否清楚地填写了测试特性、步骤、预期结果
3
用例设计是否包含了正面和反面的用例
4
非功能测试需求和不可测试需求是否在用例中列出并说明
5
不同业务流程用例是否覆盖
6
测试用例是否包含测试数据、测试数据声称办法或者输入的相关描述
7
每个测试用例前是否有标识
8
用例陈述中的命名、术语和缩写是否上下文一致
9
是否所有的指针都被初始化为NULL
追溯性
10
系统测试用例是否可追溯到产品需求
11
产品需求是否可追踪到系统测试用例
12
集成测试用例是否可追溯到概要设计
13
概要设计是否可追踪到集成测试用例
7.产品验收和发布检查表
测试用例检查表
项目编号
工作产品
检查日期
检查人员
检查结果标记
合格不合格TBD待完成NA不适用
检查情况
检查项：
项；有效检查项：
项；通过项：
项；通过率：
序号
主要检查项
检查结果
说明
1
产品是否已经通过集成测试
2
产品是否已经完成了用户要求的全部功能或与用户达成一致
3
产品的各个部分是否都是最新版本
4
产品的名称、版本号是否正确
5
产品的各个部分是否都经过了评审
6
是否提供了用户手册
7
用户手册是否与产品的版本一致
8
是否提供了所有产品的清单
9
是否说明了使用产品应当注意的问题
10
是否表明了产品的版权
升级会员 