代码检查、走查与评审
代码走查报告(模板)
其它(根据情况添加)
开发组长：检查人：
缺陷修改是否完全完成
所有的代码是否风格保持一致
注释
所有的注释是否是最新的
所有的注释是清楚和正确
若代码修改注释是否很方便修改
所有代码异常处理是否都有注释
每一功能目的是否都有注释
是否按注释类型格式编写注释
代码注释量是否达到了规定值
源代码质量
所有变量的命名是否依照规则
ห้องสมุดไป่ตู้循环嵌套是否优化到现方式做保护处理对用户上传分享的文档内容本身不做任何修改或编辑并不能对任何下载内容负责
代码审核问题报告
文档标识：
当前版本：
当前状态：
草稿
发布日期：
发布
修改历史
日期
版本
作者
修改内容
评审号
变更控制号
评审对象：评审日期：
问题
是
否，指出问题所在或解释理由
总体
代码编制是否遵照编码规范
2 静态测试
2. 程序阅读
• 审查组人员仔细阅读代码和相关材料 • 对照代码审查单标出明显缺陷及错误
3. 审查会
• 审查会由组长主持 • 首先由程序员逐句阐明程序的逻辑，在此过程中可由 程序员或其他小组成员提出问题，追踪错误是否存在 • 经验证明在上述阐述过程中，有很多错误由讲述程序 者而不是其他小组成员发现 • 大声地朗读程序给听众，这样简单的工作是有效的错 误检测技术 • 然后利用代码审查单来分析讨论 • 组长负责讨论沿着建设性的方向前进，而其他人则集 中注意力发现错误，但不去纠正错误
G.J.Myers的代码审查单（部分）
• 数据引用错误
– 是否引用了未赋值或者未初始化的变量？ – 所有的数组引用，其下标值是否都在各自的相 应维数定义界内？ – 所有的数组引用，每一个下标是否是整数值？ – 所有引用的指针或变量当前是否已经分配储存 了？（即是否存在“悬挂引用”的问题） – 在检索操作或用下标引用数组时，是否存在“ 差1”的错误？
代码走查会的内容
• 与代码审查不同，不是读程序和使用代码审查单 • 而是由被指定的作为测试员的小组成员提供若干测 试用例（程序的输入数据和期望的输出结果），让 参加会的成员当计算机，在会议上对每个测试用例 用头脑来执行程序，也就是用测试用例沿程序逻辑 走一遍，并由测试人员讲述程序执行过程，在纸上 或黑板上监视程序状态（变量的值） • 每次开会时间以1－2小时为宜，但不允许中断 • 如果发现问题由秘书记下来，中间不讨论任何纠错 问题，主要是发现错误
内容
• 静态测试技术
– 代码审查 – 代码走查
• 静态测试的内容
– 需求定义的静态测试 – 设计文档的静态测试 – 源代码的静态测试
代码走查
• 代码走查与代码审查相似，它也是由一组 程序和错误检查技术组成，只是程序和错 误检查技术不完全相同
静态测试方法
静态测试方法静态测试是软件测试中的一种重要方法，它是在软件编写完成后，通过检查源代码、设计文档和其他相关文档来发现软件中的错误和缺陷。
静态测试方法可以帮助开发人员在软件开发的早期阶段就发现和解决问题，从而降低软件开发成本，提高软件质量。
本文将介绍静态测试的基本概念、常用的静态测试方法以及静态测试的优缺点。
一、静态测试的基本概念。
静态测试是一种不需要执行程序的测试方法，它主要通过检查和审查软件文档来发现问题。
静态测试包括静态代码分析、代码审查、代码走查等方法。
静态测试的主要目的是发现软件中的错误和缺陷，提高软件的质量和可靠性。
与动态测试相比，静态测试更早地介入到软件开发过程中，可以在软件开发的早期阶段就发现问题，从而减少后期的修改成本。
二、常用的静态测试方法。
1. 静态代码分析。
静态代码分析是通过工具对源代码进行分析，发现代码中的潜在问题和错误。
静态代码分析可以帮助开发人员发现代码中的逻辑错误、潜在的安全问题和性能问题。
静态代码分析工具可以对代码进行语法分析、数据流分析、控制流分析等，从而发现代码中的问题。
2. 代码审查。
代码审查是一种通过人工检查源代码来发现问题的方法。
代码审查可以通过小组讨论、专家评审等方式进行。
代码审查可以帮助发现代码中的逻辑错误、风格问题、最佳实践违反等。
代码审查还可以促进团队成员之间的交流和学习，提高团队的整体水平。
3. 代码走查。
代码走查是一种由程序员自己对自己的代码进行检查的方法。
程序员可以通过代码走查来发现代码中的问题，并及时进行修复。
代码走查可以帮助程序员提高对自己代码的质量意识，减少代码中的错误和缺陷。
三、静态测试的优缺点。
1. 优点。
（1）早期发现问题，静态测试可以在软件开发的早期阶段就发现问题，从而减少后期的修改成本。
（2）提高代码质量，静态测试可以帮助发现代码中的问题，提高代码的质量和可靠性。
（3）促进团队交流，代码审查和代码走查可以促进团队成员之间的交流和学习，提高团队的整体水平。
C__代码走查CheckList
代码走查
一．代码走查的目的
1．保证代码符合编码规范
2．保证代码符合设计
3．发现bug
4．保证代码单元测试充分
5．促进开发人员之间的交流，为代码的优秀程度的提高和开发人员编码技能的提高提供契机。
二．过程
每次迭代都要对修改过和新编的代码进行走查，走查的过程如下图：
三．Checklist
说明：本checklist用于走查人员走查代码。
开发人员用于自我检查的checklist可以参照此checklist，依自身实际情况制定。
说明：本checklist应随着组织开发过程中出现的实际情况，对检查项具体内容进行增、删、改，以使得此checklist更具效率，但要注意保持检查项数目的简洁。
类名：走查的类的名字。
代码走查检查单
流程控制缺陷(CF) 1 对于每一个循环:是否选用了最佳的循环结构? 2 所有的循环是否都能结束? 3 如果一个循环有多个出口,是否每个出口都有必要并且得到正确处理? 4 switch声明是否都有default条件? 5 是否所有的case-switch-break对应关系都已更正并加上批注？ 6 是否named break叙述都跳到正确的地方？ 7 循环和分支的嵌套是否过深?是否正确? 8 是否有if嵌套可以转换程switch嵌套? 9 空控制叙述是否都正确，并加上括号及批注？ 10 所有的异常是否都得到了正确的处理 11 每一个方法在是否都结束?
C# 代码审查检查表
项目名称
责任人
走查日期
编号
问题
变量,Auribute,和常量声明缺陷(VC)
1 变量和常量的命名是否与约定保持一致?
2 是否存在容易混淆的相似的变量和属性名?
3 变量和属性是否书写正确?
4 变量和属性是否被正确的初始化?
5 非局部变量是否能用局部变量替换?
6 所有的for循环的控制变量是否都在循环顶部被声明?
7 是否有应该命名为常量的文字常量?
8 变量和属性是否可以用常量替换?
9 属性是否可以用本地变量?
10
所有的属性是否都有正确的访问限制符 (private,protected,public)?
代码走查单
是否适用 严重程度
是： 高：
否： 中：
评审工件
工件版本
是否达到可评审状态
是
否
严重程度 建议修正措施
评审人员 其它 注释
不适用： 低：
4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 结果 统 计：
其它：
注释 注释是否解释了代码的目的，或总结了代码所要完成的工作？ 注释是否是最新的？ 注释是否清晰正确？ 是否对代码含义进行了注释？ 声明全局变量时，是否给以了注释？ 是否说明了每个子程序的目的？ 注释是否与代码保持一致性，不存在没用的注释？ 其它：
程序块的分界符是否各独占一行并且位于同一列，同时与引用它们 1.6 的语句左对齐？ 1.7 其它：
2 命名 2.1 定义的程序名是否有意义？
标识符的命名是否清晰、明了，有明确含义，同时使用完整的单词 2.2 或大家基本可以理解的缩写，避免使人产生误解？ 2.3 命名中规若范使是用否特与殊所约使定用或的缩系写统，风是格否保有持注释一说致明，？并在同一项目中统 2.7 一？ 2.8 其它：
是否注意运算符的优先级，并用括号明确表达式的操作顺序，避免 3.9 使用默认优先级？ 3.1 是否只引用属于自己的存贮空间？ 3.11 是否防止引用已经释放的内存空间？
如果不是构造函数，过程/函数中分配的内存，在过程/函数退出之 3.12 前是否释放？
对于退出过程/函数后仍然需要存在的内存，是否确保该内存使用完 3.13 毕后及时释放该内存？
过程/函数中申请的（为打开文件而使用的）文件句柄，在过程/函 3.14 数退出之前是否关闭？ 3.15 是否防止内存操作越界？
系统运行之初，是否初始化有关变量及运行环境，防止未经初始化 3.16 的变量被引用？ 3.17 在产品软件（项目组）中，是否统一编译开关选项？
代码走读
代码走读(1) 代码走读都有哪些内容？代码走读根据目的的不同，可以分为四个层次：1、检查是否符合编程规范；2、寻找编译器中的设计陷阱；3、快速理解源代码，找出流程设计中的问题；4、对原有代码的重构；这四个层次可以按照从简单到复杂的顺序进行。
(2) 这四个层次都有什么区别和意义？1、检查是否符合编程规范；编程规范融合并提炼了许多人多年开发编程语言程序积累下来的成熟经验，帮助编程者形成良好的编程风格，提高源程序的可读性和可维护性，降低出错的机会，迅速跨入业已存在的且具有相当高度的技术层次，并能够为提高代码的复用性提供积极的参考。
2、找编译器中的设计陷阱；术语“陷阱”的发展历史并不明确，而且它有多种定义方法。
本文定义为编程和设计过程中常见的和可防止的问题，能顺利通过编译，没有任何警告和错误信息，而且计算机严格按照作者写明的代码执行，但是结果却不是作者期望的。
许多IT人士都知道，现在市场上有很多新的编译器，它们可以捕获大部分程序错误，但遗憾的是，仍有许多错误是编译器不能发现的。
打个比方，拼写检查程序是用来查找拼写错误的，但是，如果单词DOG被错误地写为CAT，您能指出单词CAT（实际是DOG）中的拼写错误吗？很显然，不能。
因为这个单词可顺利通过拼写检查程序。
这里描述的陷阱所包括的范围广泛，从较容易的语法问题，基本设计缺陷，到完全错误的行为。
利用正确的使用方法来说明这些常见的误解和误用，可以防止编程者出现类似的问题，并防止新一代程序员重复过去的错误。
3、快速理解源代码，找出流程设计中的问题；无论是沟通程序的操作，还是将知识存储为可执行的形式，软件的源代码都是最终的介质。
我们可以将源代码编译成可执行程序，也可以阅读代码来了解程序的功能及其工作方式，还可以修改源代码来改变程序的功能。
大多数编程课程和书籍都将重点放到如何从零开始编写程序上。
然而，在软件系统的工作投入中，40％～70％是用在系统首次编写完整之后，这些工作一定涉及到阅读、理解、以及修改最初的代码。
C++代码走查CheckList
C++代码⾛查CheckList
代码⾛查
⼀．代码⾛查的⽬的
1．保证代码符合编码规范
2．保证代码符合设计
3．发现bug
4．保证代码单元测试充分
5．促进开发⼈员之间的交流，为代码的优秀程度的提⾼和开发⼈员编码技能的提⾼提供契机。
⼆．过程
每次迭代都要对修改过和新编的代码进⾏⾛查，⾛查的过程如下图：
三．Checklist
说明：本checklist⽤于⾛查⼈员⾛查代码。
开发⼈员⽤于⾃我检查的checklist可以参照此checklist，依⾃⾝实际情况制定。
说明：本checklist应随着组织开发过程中出现的实际情况，对检查项具体内容进⾏增、删、改，以使得此checklist更具效率，但要注意保持检查项数⽬的简洁。
类名：⾛查的类的名字。
网站信息化管理平台-评审报告代码走查结构管理
修改人工作产品版本完成时间
胡晓华网站信息化管理平台源代码-结构管理COMMIT后，SVN自
动版本控制
2016/8/9
跟踪人员签字
评审修正后的工作成果
签字：
日期：
跟踪结论
修正后的工作成果合格。
修正后的工作成果仍然不合格，需重新修改。
第 1 页，共 1 页
代码走查检查表模板
其他评审意见或建议：
评审意见 (具体意见描述)
评审人
责任人
特别是那些可能出错的类型8声明空白缩进重要9声明空白缩进重要变量是否已经在定义的同时初始化
代码检查列表
序号 1 所属类别 命名 重要程度 重要 检查项 命名规则是否与所采用的规范保持一致？ 所有的源文件都应该在开头有一个版权和文件内容声明 /* *Model：模块名称 *Description：文件描述 *Author:作者姓名（一般情况下用中文） *Finished：xxxx年xx月xx日 */ 在导入包时当完全限制代码所使用的类的名字,而不用通配符 的方式 例如: import java.awt.Color; import java.awt.Button;
声明、空白、缩进 重要 声明、空白、缩进 重要 声明、空白、缩进 中等 声明、空白、缩进 中等 声明、空白、缩进 中等 逻辑 逻辑 逻辑 逻辑 逻辑 逻辑 重要 中等 重要 重要 中等 重要
19 20 21 22 23
逻辑 逻辑 逻辑 逻辑 逻辑
重要 重要 重要 重要 重要
是否对有异常抛出的方法都执行了try...catch保护？ 入口对象是否都被进行了判断不为空？ 入口数据的合法范围是否都被进行了判断？(尤其是数组) 是否对有异常抛出的方法都执行了try...catch保护？ 是否对方法返回值对象做了null检查，该返回值定义时是否 被初始化?
2
注释
重要
3Leabharlann 注释重要4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
注释 注释 注释 注释
重要 重要 中等 重要
注释是否较清晰且必要？ 复杂的分支流程是否已经被注释？ 距离较远的}是否已经被注释？ 方法是否已经有文档注释？（功能、输入、返回及其他可 选） 每行是否只声明了一个变量？（特别是那些可能出错的类 型） 变量是否已经在定义的同时初始化？ 是否合理地使用了空格使程序更清晰？ 代码行长度是否在要求之内？(建议每行不超过80个字符) 折行是否恰当？ 包含复合语句的{}是否成对出现并符合规范？ 是否给单个的循环、条件语句也加了{}？ 单行是否只有单个功能？（不要使用；进行多行合并） 单个函数是否执行了单个功能并与其命名相符？ 单个函数不超过规定行数？每个函数不能超过300行 入口对象是否都被进行了判断不为空？