当前位置：文档之家 › 代码走读检查表模板

代码走读检查表模板

  • 格式：xls
  • 大小：27.00 KB
  • 文档页数：234

下载文档原格式

  / 234

合集下载

代码走查检查表

代码走查检查表
4
整个代码体系结构组合合理,分层清晰，代码之间功能划分明确
5
所有的接口模块化，尽量减少接口之间的耦合度，修改时尽量不影响其他代码模块
6
代码体系构架对空间和速度都已经进行考虑
7
数据库操作、IO操作等是否正确关闭资源。并且必须在try -catch-finally 的finally中关闭。
8
一个业务如果进行多次数据库更新、添加、删除是否正确添加事务。
代码走查检查表
评审日期：年 月 日
评审对象
作者
评审人
评审工作量
序号
检查项
评审意见
走查前准备
1
得到一份解释代码的最新的设计文档，作为代码走查的参考
2
代码都已提交 ，版本统一
程序结构组织
1
所有代码的结构清晰，具有良好的结构外观和整齐
2
所有的模块（函数和外部接口）定义清晰，模块分解清楚
3
所有的功能需求都明显的覆盖
1
类、方法、判断条件、循环、主要变量是否添加注释。
2
类名、方法名、变量名的命名是否规范。
3
有返回值的方法是否正确返回。Return语句应定义在方法结尾处。
4
源代码能够自我解释，每个人看到代码就能很快理解
5
解释不过于简单，解释说明代码功能，准确描述代码意义6所有的假Fra bibliotek和限制进行注解
7
长的控制体结束，进行注解
新增
all
孟洋涛、郑海焘
郑博
1.1
2012-5-28
根据各项目组评审出问题进行修改
all
孟洋涛
郑博
14
递归局限于一个函数
15
对接口的调用必须要有判断传入的参数不能为空和传入的参数正确。

程序规范执行情况检查表

程序规范执行情况检查表

程序规范执行情况检查表
以上是关于程序规范执行情况的检查表。

请根据具体情况填写
相应的执行情况。

注意：程序规范的执行情况检查是保证代码质量和可维护性的
重要步骤。

确保程序符合规范要求可以提高代码的可读性和重用性，减少错误和维护成本。

对于不符合规范要求的地方，需要及时进行
修正和改进。

请根据实际情况填写每个项目的执行情况，可以使用以下分类进行描述：
- 符合要求：表示该项目已经按照规范要求执行。

- 部分符合要求：表示该项目在某些地方符合要求，但还有一些需要改进的地方。

- 不符合要求：表示该项目未能按照规范要求执行。

需要修正和改进。

例如：。

代码走查检查单

代码走查检查单
3
编码时间 模块名称 测试完成日期
代码走查
；
能。 化为局部变量。 系。 英文单词和拼音混写。
用同样的名称。
为单位，Tab键为4个空格。
文件编码 制表时间
□ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合
■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合
4
。 定义过的常量。
□ 不符合 □ 不符合 □ 不符合 □ 不符合
□ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合
■ 符合 ■ 符合 ■ 符合 ■ 符合
开至少两个Tab键。
的1/5~1/3。
段空一行； 要描述。
□ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合
□ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合

代码走读检查列表

代码走读检查列表

代码走读检查列表Pre-review checklist 准备工作considerations 通常的考虑2.1Practical1.Have you been provided with a design document to understand the code ? Is the design documentup-to-date (latest version) ? 你是否得到一份解释代码的设计文档？设计文档是否最新的？2.Does the design document explain 设计文档是否做了如下解释：- program architecture ? 程序结构？- module breakup and functionality ? 模块是否已经完成和函数化？- task breakup ? 任务完成了吗？- each routine in pseudo-code form ? 每个函数都有伪代码？3.Has the code been compiled with strict warning and error checking enabled (-Wall and -Werroroptions); have all compilation warnings and errors been removed ? 代码是否已经被使用严格的告警和错误检查编译过？所有的编译告警和错误都已经修改？4.Has the code been compiled with a C++ compiler in addition to a C compiler ? 代码是否使用带C++特性的C编译器编译？2.2Program (product) architecture 程序结构1.Is the overall organization of the code clear, including a good architectural overview andjustification ? 所有代码的结构是否清晰，具有良好的结构外观和整齐？2.Are modules well defined, including their functionality and interfaces to other modules ? Is thetask/process breakup of the modules clear ? 所有的模块都定义得很好，包括函数和外部接口？任务/进程把模块分解清楚？3.Are all the functional requirements covered sensibly, by neither too few nor too many modules ?所有的功能需求都明显的覆盖，过多还是过少？4.Is the top-level design independent of the OS/environment which will be used ? 高层设计是否独立于OS/环境？5.Is the architecture designed to accommodate likely changes ? 结构设计是否能够满足变化？6.Does the architecture describe how reused code will be made to conform to other architecturalobjectives 体系结构是否描述了如何把代码重用到其他体系结构中?7.Does the whole architecture hang together conceptually ? 整个体系结构组合在一起，是否合理？8.Are all major data structures described and justified ? 所有主要的数据机构是否描述清楚和合理的9.Are data structures belonging to every module localised suitably so that they areaccessed/modified by well-defined access routines ? 模块中所有的数据结构是否都定义为局部的，并且通过定义好的函数进行访问？10.Is there a well-defined strategy to interface with external entities ? 是否为外部定义了良好的函数接口？11.Are all interfaces modularized so that changes will not affect the rest of the code ? 所有的接口是否模块化，因此他们的修改不影响其他代码？12.Are memory usage estimates and a strategy for memory management described and justified ? 内存使用方法和内存管理策略是否描述清楚和正确？13.Does the architecture set space and speed budgets for each module ? 体系构架是否对空间和速度都已经进行考虑？14.Is a strategy for handling data (strings) described and are storage estimates provided ? 是否提供了处理数据的策略？15.Is a coherent error handling strategy provided ? 是否具有同一的错误处理策略？16.Are error messages managed as a set to present a clean interface ? 是否把错误信息管理，作为一套清晰的函数接口提供？17.Are the motivations for the major decisions provided ?18.Are you (if you had to program/implement the system) comfortable with the architecture ? 你觉得这个体系结构舒服吗？3.Code Review Checklist for Standards 代码检查3.1 Directory organization 目录组织1.Are all file names less than or equal to 8.3 characters in length ? 所有的文件名是否小于或者等于8.3个字符？2.Are portable files identified as separate from core protocol files ? 可移植的文件是否和核心的协议文件分开？3.Is the file/module grouping clear ? 文件和模块是否分组清晰？organization 文件组织3.2File1.Does each file have a file header conforming to the standard convention ? 每个文件是否都有文件头和标准的习惯一致？（描述文件的用途，作者，对外提供的函数）2.Is each file organized in order - file header, type definitions, macros, prototypes, functions ? 每个文件都组织的有序－文件头，类型定义，宏，原型，函数？3.Are all lines within 80 characters in length ? 所有的代码行是否在80字符以内？4.Is each file less than or equal to 2000 lines in length ? 每个文件都小于2000行？5.Does each file hold code for one and only one module ? 每个文件是否只包含一个模块的代码？3.3Procedure organization / layout 函数组织1.Does each procedure have a header conforming to the standard convention ? 每个函数是否都有一个标准的函数头声明？2.Is the procedure organized - header, procedure name & parameters, procedure body ? 函数组织：头，函数名，参数，函数体3.Is the procedure defined in both ANSI format & otherwise using a __STDC__ compilation switch ?函数定义是否符合ANSI或者用标准C的编译开关？4.Does each procedure fit into a maximum of 2 printed pages (excluding the header) ? 每个函数都能够在最多2页纸可以打印。

模板_测试检查表checklist

模板_测试检查表checklist

测试检查表checklist输入、编辑功能的验证检查点：1. 必输项是否有红星标记，如果不输入提示是否跟相应的Label对应，提示的顺序是否跟Form输入域的排列次序一致；2. 输入的特殊字符是否能正确处理：`~!@#$%^&*()_+-={}[]|\:;”’ <>,./?;3. Form下拉菜单的值是否正确，下拉菜单的值通过维护后是否正确显示并可用；下拉菜单比如是机构编码，要到机构编码的维护界面查询一下是否Form列出的与其一致；4. 涉及到下拉菜单的编辑修改Form，要检查在编辑和修改From中，下拉菜单是否能正确显示当前值；5. Form提交后，要逐项检查输入的内容跟通过查询的结果一致；6. 有多层下拉菜单选择的情况要校验两层菜单的选择是否正确；7. 备注字段的超长检查；8. 提交保存后能否转到合适的页面；9. 编辑Form显示的数据是否跟该记录的实际数据一致；10. 编辑权限的检查，比如：user1的数据user2不能编辑等；11. 可编辑数据项的检查，比如：数据在正式提交之前所有的属性都可以编辑，在提交之后，编号、状态等不能编辑，要根据业务来检查是否符合需求；12. 对于保存有事务Transaction提交，比如一次提交对多表插入操作，要检查事务Transaction的处理，保证数据的完整和一致；13. 其他的合法性校验。

查询功能检查点：1. 查询输入Form是否正常工作，不输入数据是否查询到全部记录；2. 当查询的数据非常多的时候，性能有无问题；3. 查询的下拉菜单列出的数据是否正确；4. 查询结果是否正确；对于复杂的查询要通过SQL来检查结果；5. 如输入%*?等通配符是否会导致查询错误；6. 查询结果列表分页是否正确，在点击下一页上一页时，查询条件是否能带过去，不能点击翻页时又重新查询；7. 对于数据量比较大的表查询时，不容许无条件查询，避免性能问题的出现；8. 对于查询输入项的值是固定的要用下拉菜单，比如状态、类型等；9. 分页的统计数字是否正确，共X页，第N页，共X条记录等；10. 对于查询有统计的栏目，比如：总计、合计等要计算数据是否正确；11. 查询结果有超链接的情况要检查超链接是否正确；12. 查询权限的检查，比如：user1不能查询到user2的数据等；删除功能检查点：1. 必须有“确认删除”的提示；2. 根据需求检查是软删除还是硬删除，来检查数据库中是否还存在该条记录；3. 是否有相关的数据删除，如果有要确认该相关的数据也已经删除，并且在同一事务中完成；4. 是否有删除约束，如果有删除约束，要检查该记录是否被约束，如果被约束该记录不能被删除；5. 如果是软删除，用查询、统计界面检查该条记录能否被查询出来，数据是否被统计进去；6. 检查因为业务约束不能删除的数据能否被保护不能手工删除，比如：流程中已经审批的文件不能被删除；7. 跟删除相关的权限问题，比如：需求要求只有管理员和该记录的创建人能够删除该记录，那就以不同的用户和角色登录进去，执行删除操作，检查是否与需求匹配；上传附件检查点：1. 检查是否能正确上传附件文件；2. 检查上传的文件是否能正确下载并打开；3. 至少检查下列大小的文件能正确上传，0k,100k,1M,2M,4M,10M,20M等；4. 如果没有指定类型的限制，至少上传以下几种类型的文件能否正确上传并正确打开，类型有：.doc,.xls,.txt,.ppt,.htm,.gif,.jpg,.bmp,.tif,.avi等；5. 如果有文件类型的限制还要检查能上传的文件的类型；6. 上传同名的文件，在打开的时候是否出错；7. 有中文文件名的文件能否正确上传；影响操作性能的检查点：（不能代替系统的性能测试和压力测试，主要看系统在正常操作情况下的响应和处理能力）1. 对数据记录条数比较多的表的查询操作，避免全表查询，比如对银行用户账号的查询就不能缺省全部查出，必须让用户输入查询条件；2. 菜单树，测试大量数据时菜单树的响应情况；3. 有日志的查询或者统计，要注意查询的效率；4. 大报表的处理或者批处理的操作，要关注效率，比如：银行对帐、财务年终结算、财务年报表、系统初始化等；5. 大报表的排序sort、组函数的使用等；6. 大数据量的处理，如导入、导出、系统备份、文件传输等。

学生寄宿和走读情况调查表

学生寄宿和走读情况调查表

寄宿和走读情况调查表
学校名称：填表时间：
学校类型中心校本部（）村完小（）教学点（）在校生数(人)
寄宿生情况
寄宿需求人
数
(人) 已寄宿人数
(人)
是否满足寄宿需
求(是/否)
乘坐周末
班车人数
(人)
寄宿年
级
4-6年级( )
3-6年级( )
1-6年级( )
寄宿条
件
一人一床( )
二人一床( )
大通铺( )
寄午生情况
学校是否提供寄午(是/否) 未提供
寄午原
因
没有寄午需求( )
无法提供寄午条件( )
需要寄午学生总
数
(人)
已寄午人数
(人)
走读生家校往返情况
走读生总数(人) 步行走读
人数
(人)
其中
步行单程
20分钟以内
(人)
步行单程
20-40分
钟
(人)
步行单程
40-60分钟
(人)
步行单程
60-90分钟
(人)
步行单程90
分钟以上
(人)
其他走读
方式人数
(人)
其中
家长接送
(人)
包车接送
(人)
骑车往返
(人)
自行搭车
(人)
备注栏
1。

java代码检查表(很好的公司在用)

java代码检查表(很好的公司在用)
2.2嵌套内部类是否超过2层？
2.3所有方法是抽象的且所有成员变量是静态常量的抽象类是否声明成了接口？
2.4当类所有的方法和属性都是静态的时，是否定义了缺省的私有构造方法？
2.5没有使用任何实例类成员（包括方法和成员变量）的方法是否被声明为静态的？
2.6异常发生时是否均恰当的记录了错误日志？是否存在使用System.out.println而不是日志模块记录日志的情况发生？
4.8循环条件中或重复出现的如.length() .size() .getClass().getName()等取值方法的返回值是否使用了临时变量代替？
4.9频繁拼装字符串时，是否使用了StringBuffer，并事先分配恰当空间？
5.
目录结构
5.1Jsp,Action，service ，dao ,逻辑分层是否明确
4.6.1嵌套的条件判断、循环是否可替换为较简单的结构？
4.6.2是否存在可以合并的循环或条件判断？
4.6.3循环体内是否存在可以提到循环体外的代码？如实例化对象或声明变量等
4.7switch中case的常量是否可以安排为连续的值？这样做可以使得代码被编译为tableswitch类型的跳转表提高性能。连续的 else if结构是否按情况出现的频率进行了排序？
2.10.5是否存在不必要的import句？
3.
缺陷检查
3.1程序逻辑是否符合详细设计？
3.2输入参数、调用其他函数的返回值是否有必要校验合法性、完整性、依赖关系？如有必要，是否做了恰当的校验？如无必要，是否有多余的代码？
3.3是否避免了在抽象类构造方法中调用抽象方法？
3.4是否避免了直接抛出Exception类异常，而没有抛出恰当的由Exception派生的异常类？

代码走查检查表模板

代码走查检查表模板

其他评审意见或建议：
评审意见 (具体意见描述)
评审人
责任人
特别是那些可能出错的类型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行 入口对象是否都被进行了判断不为空？

学生走读(在家住宿)申请表模板

学生走读(在家住宿)申请表模板
学生走读(在家住宿)申请表模板
姓名
性别
码
本人 承诺
家庭住址 现因
自负。申请日期，自
姓名
联系方式
，申请走读（在家住宿），走读安全责任 年 月 日至 年 月 日。
与学生关系
签 名： 年月日
工作单位
身份证号码
联系方式
学生
家庭住址
家长
承诺
，申请走读（在家住宿），走读安全责任由学生本人和学生家长承
担。申请日期，自 年 月 日至 年 月 日。
签 名： 年月日
居委会 意见
盖 章： 年月日
辅导员 意见
院系 意见
盖 章： 年月日
注：本申请表须附相关证明材料
学生处 意见
签 字： 年月 日
盖 章： 年月日

JAVA代码审查检查表

JAVA代码审查检查表
是[ ]否[ ]免[ ]
11
3.2变量是否已经在定义的同时初始化
是[ ]否[ ]免[ ]
12
3.3类属性是否都执行了初始化
是[ ]否[ ]免[ ]
13
3.4代码段落是否被合适地以空行分隔
是[ ]否[ ]免[ ]
14
3.5是否合理地使用了空格使程序更清晰
是[ ]否[ ]免[ ]
15
3.6代码行长度是否在要求之内
是[ ]否[ ]免[ ]
16
3.7折行是否恰当
是[ ]否[ ]免[ ]
17
4.1包含复合语句的{}是否成对出现并符合规范
是[ ]否[ ]免[ ]
18
4.2是否给单个的循环、条件语句也加了{}
是[ ]否[ ]免[ ]
19
4.3if/if-else/if-else if-else/do-while/switch-case语句的格式是否符合规范
5
2.2复杂的分支流程是否已经被注释
是[ ]否[ ]免[ ]
6
2.3距离较远的}是否已经被注释
是[ ]否[ ]免[ ]
7
2.4非通用变量是否全部被注释
是[ ]否[ ]免[ ]
8
2.5函数是否已经有文档注释
是[ ]否[ ]免[ ]
9
2.6特殊用法是否被注释
是[ ]否[ ]免[ ]
10
3.1每行是否只声明了一个变量（特别是那些可能出错的类型）
是[ ]否[ ]免[ ]
20
4.4单个变量是否只做单个用途
是[ ]否[ ]免[ ]
21
4.5单行是否只有单个功能（不要使用；进行多行合并）
是[ ]否[ ]免[ ]
22

代码走读检查个人评价表-V0.2

代码走读检查个人评价表-V0.2

是[ ] 否[ ] 免[ ]
7. 循环索引是否具有有意义的命名？
是[ ] 否[ ] 免[ ]
8. 循环是否设计得很好－它是否只执行一种功能？ 是[ ] 否[ ] 免[ ]
9. 循环终止的条件是否是清晰的、明显的？
是[ ] 否[ ] 免[ ]
10. for循环体内的代码是否避免了修改循环索引的操 作？
（七）比较、计算和表达式
1. 代码是否与比较/计算变量的大小/类型无关？
是[ ] 否[ ] 免[ ]
2. 代码是否与表达式中操作符的优先级无关？
是[ ] 否[ ] 免[ ]
3. 当一个表达式被经常使用时，我们是否使用一个宏来 增加它的可读性？
是[
]
否[
]
免[
]
4. 是否所有的表达式使用了正确的操作符？（如“=” 与“==”）
是[ ] 否[ ] 免[ ] 是[ ] 否[ ] 免[ ] 是[ ] 否[ ] 免[ ]
（一）变量的声明
1. 每个变量是否分配了正确的长度、类型和存储空间？ 是[ ] 否[ ] 免[ ]
2. 是否避免了使用静态变量？
是[ ] 否[ ] 免[ ]
3. 所有的声明是否与编译器或者机器的具体处理长度无 关？
是[ ] 否[ ] 免[ ]
7. 是否在程序中设置了调试辅助信息？并使得它们很容 易被激活？
是[
]
否[
]
免[
]
8. 代码是否检查了所有它要调用的函数的返回值？被调 用的这些子函数的形参和实参是否匹配？
是[
]
否[
]
免[
]
9. 涉及相同变量的代码都放在一起了吗？
是[ ] 否[ ] 免[ ]
（四）递归 1. 递归是否是实现函数的最好方式，一定需要吗？ 2. 递归是否定义了明确的停止条件？ 3. 递归是否限制在一个函数内？ 4. 堆栈大小是否支持递归调用的深度？

代码走读 实施流程

代码走读 实施流程

代码走读实施流程
代码走读是一种对代码进行审查和评估的方法，旨在提高代码质量、减少错误和提高开发效率。

以下是代码走读的实施流程：
1. 确定走读目标：首先需要明确代码走读的目标，例如检查代码规范、代码质量、安全漏洞等。

这有助于制定具体的走读计划和检查表。

2. 选取走读人员：选择具有相关背景和经验的开发人员作为走读人员，他们应具备一定的技术能力和分析能力，能够发现问题并提供有价值的建议。

3. 制定走读计划：根据走读目标和范围，制定详细的走读计划，包括需要检查的代码范围、时间安排、检查方法和工具等。

4. 准备工具和环境：根据需要，准备相应的工具和环境，例如代码编辑器、版本控制系统、代码质量检查工具等。

5. 进行走读：按照计划进行代码走读，重点关注代码规范性、可读性、可维护性、性能和安全性等方面。

记录发现的问题和建议，并与相关人员进行沟通和确认。

6. 分析问题并提出建议：对发现的问题进行深入分析，找出根本原因，并提出相应的改进建议。

这些建议可以包括优化代码结构、改进算法、提高可读性等。

7. 汇总报告：将走读结果汇总成报告，包括发现的问题、建议和改进措施等。

报告应该清晰、简洁，便于相关人员理解和执行。

8. 跟踪和验证：对提出的改进措施进行跟踪和验证，确保问题得到解决并取得良好的效果。

同时，不断总结经验教训，为今后的代码走读提供参考。

需要注意的是，代码走读是一个持续的过程，需要定期进行以确保代码质量不断提高。

同时，走读人员应该保持客观、公正的态度，遵循良好的沟通技巧和方法，以确保走读效果的最大化。

软件测试-软件代码走查清单模板

软件测试-软件代码走查清单模板
是［］否［］免［］
72
变量值问题如：变量的初始化或缺省值必须正确；变量不能发生上溢或下溢；变量的精度要保证足够；
是［］否［］免［］
73
逻辑判断问题如：要确保不会在程序中出现由于精度原因而导致的比较无效吗；确保表达式中的运算优先级正确；确保逻辑判断结果正确；
是［］否［］免［］
序号
总则条款
执行情况
说明
74
是［］否［］免［］
三、命名规则
20
对于全局变量的命名，必须以“g_”开头，局部变量不得以“g”开头；
是［］否［］免［］
21
变量的命名尽量有意义，如果没按意义进行命名，则必须在声明变量时加上备注解释其意义；
是［］否［］免［］
四、表达式与基本语句
22
代码行中的运算符超过两个，必须用括号清楚地确定表达式的操作顺序；
是［］否［］免［］
38
函数名字与返回值类型在语义上最好不要存在冲突；
是［］否［］免［］
39
不要函数的将正常值和错误标志混在一起返回，正常值应当用输出参数获得，而错误标志用“return”语句返回；
是［］否［］免［］
40
在函数体的“入口处”，最好用“assert”对参数的有效性进行检查；
是［］否［］免［］
是［］否［］免［］
3
所有的函数和全局变量在头文件中进行声明；
是［］否［］免［］
4
头文件和定义文件目录结构合理；
是［］否［］免［］
5
每个程序文件的头部必须包含完整的版权和版本声明；
是［］否［］免［］
6
重要头文件要使用ifndef/define/endif预处理块；
是［］否［］免［］
二、程序版式

第14章代码复查检查表

第14章代码复查检查表
10．开发完每个背后程序后，用同样的方法简要检查一下缺陷数据和检查表，并标识出有用的更改和增加部分。
11．建议想一想哪些步骤可以在以后预防这些缺陷。
五、改进检查表
应该养成定期复查缺陷数据和重新审核检查表的习惯。当步骤是有效时，保留它们。当某些步骤不理想时，找出怎样才能使这些步骤更有效并更新检查表。这样检查表就变成了个人经验的总结。它还可以帮助你坚持按照自己设计的步骤来查找和修复缺陷。
/* CData()*/
/* Empty()*/
/*****************************************************************/
重用指导
示例
描述如何使用该程序的.提供说明格式\参数值和类型以及参数范围;
提供对非法值、溢出条件或及其它潜在的有可能引起非正常操作的条件等方面的警告
教案（续页）第68页
六、编码标准
检查表现很有效的一个原因是她提供了一个进行代码复查的标准。虽然最主要的代码复查标准是程序设计语言的语法规格说明，但这些说明并没指明编码的格式和风格。
标准是官方接受的用于对照的基础。因此，编码标准定义为被广泛接受的、能够作为工作样板的编码实践集。这个标准用于指导编写源程序代码。这样的标准一般定义了源程序的书写格式、什么语句分别写在单独的一行或语句怎样缩排。编码标准中一般要定义注释的书写规范，包括必须的说明性注释。编码标准还有助于预防缺陷。
If(record_count>/
If(record_count>limit)/*检查record_count是否超过限制*/
程序主体前应有一段注释来描述由以下部分所做的处理
/*****************************************************************/

自动化编程规范检查清单

自动化编程规范检查清单
自动化编程规范检查表 日期 检查人 被检查人 被检查项目 函数部分 1 函数说明 2 变量命名要有意义 3 脚本注释 4 参数设置是否合理 5 长时间等待避免使用wait()方法，用.Exist() .WaitProperty()等来处理 检查结果
6 保存数据时 7 函数逻辑是否存在纰漏 8 模板部分 如果模板要用“host==”来引用QTP语句，此语句 1 中不要存在变量，如果必须使用变量，要将此语句写 成函数，通过参数来传递 2 关键步骤要加截图 数据表部分 1 避免将数据写死，要通过变量传值或写成全局变量 2 各泳道之间的数据应尽量保持独立，如果必须引用其 他泳道的数据通过“$测试点ID=变量名$” 函数中对失败情况是否添加了判断，及错误提示信息 是否准确
ቤተ መጻሕፍቲ ባይዱ 是否已修改
修复日期
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

声明、空白、缩进 重要 声明、空白、缩进 重要 声明、空白、缩进 中等 声明、空白、缩进 中等 声明、空白、缩进 中等 逻辑 逻辑 逻辑 逻辑 逻辑 逻辑 重要 中等 重要 重要 中等 重要
19 20 21 22 23
逻辑 逻辑 逻辑 逻辑 逻辑
重要 重要 重要 重要 重要
是否对有异常抛出的方法都执行了try...catch保护？ 入口对象是否都被进行了判断不为空？ 入口数据的合法范围是否都被进行了判断？(尤其是数组) 是否对有异常抛出的方法都执行了try...catch保护？ 是否对方法返回值对象做了null检查，该返回值定义时是否 被初始化?
2
注释
重要
3
注释
重要
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
注释 注释 注释 注释
重要 重要 中等 重要
注释是否较清晰且必要？ 复杂的分支流程是否已经被注释？ 距离较远的}是否已经被注释？ 方法是否已经有文档注释？（功能、输入、返回及其他可 选） 每行是否只声明了一个变量？（特别是那些可能出错的类 型） 变量是否已经在定义的同时初始化？ 是否合理地使用了空格使程序更清晰？ 代码行长度是否在要求之内？(建议每行不超过80个字符) 折行是否恰当？ 包含复合语句的{}是否成对出现并符合规范？ 是否给单个的循环、条件语句也加了{}？ 单行是否只有单个功能？（不要使用；进行多行合并） 单个函数是否执行了单个功能并与其命名相符？ 单个函数不超过规定行数？每个函数不能超过300行 入口对象是否都被进行了判断不为空？
其他评审意见或建议：
评审意见 (具体意见描述)
ቤተ መጻሕፍቲ ባይዱ
评审人
责任人
代码检查列表
序号 1 所属类别 命名 重要程度 重要 检查项 命名规则是否与所采用的规范保持一致？ 所有的源文件都应该在开头有一个版权和文件内容声明 /* *Model：模块名称 *Description：文件描述 *Author:作者姓名（一般情况下用中文） *Finished：xxxx年xx月xx日 */ 在导入包时当完全限制代码所使用的类的名字,而不用通配符 的方式 例如: import java.awt.Color; import java.awt.Button;