基于Code Collaborator和Review board的代码审工具试用对比说明
Code Collaborator和Review Board试用说明
代码评审(Code Review)是敏捷开发很重要的一环，是保证软件质量的最佳实践之一。要做好代码评审, 就需要有一套简单，高效，功能完善且界面友好的工具，来支持代码审查审查流程。
目前部门还没有采用Pair Programming那种时时刻刻都在review代码的工作方式，代码Review多采用走查方式，即代码写完后召开一个Code Review的Meeting，集中时间和经验丰富的人力对重点代码进行筛查，这种方式的代码Review有利，但也有弊。其弊端在于低效和覆盖面小。做一次走查需要N多人参与若干个小时，而在这段时间里不是每个参与者都能极其高效的参与到走查中的，实践证明只有少数几个人能真正在一次代码审查会议上起到关键的作用。另外走查一次能覆盖的代码范围又较小，一些看似不重要却很可能带来BUG的代码在走查会上很容易被遗漏。Code Collaborator 和Code Review等工具是对代码审查是一种很好的补充。Code Collaborator是一款收费工具，目前我部门ANM2000专项正在使用，效果较好。当前比较流行的开源Code Review工具有Review Board、CodeStriker 等。
依据我《代码审查流程》，综合分析，备选的两款工具分别是：Code Collaborator（代码合作者）和Review board（评审委员会）。在完成两款工具的使用对比后，根据试用的实际情况对两款工具进行比较见下表：
?【基于Code Collaborator和Review board的代码审工具试用对比表】
两款工具的安装与试用说明见：
?附件一：《基于ReivewBoard的代码审查平台搭建简要说明》
?附件二：《基于Code Collaborator的代码审查平台搭建简要说明》
【基于Code Collaborator和Review board的代码审工具试用对比表】
附件一：《基于ReivewBoard的代码审查平台搭建简要说明》
1. Review Board简介
Review Board（简称RB）起源于VMware的一些开发者，是基于Django的网络应用，界面友好，功能也非常强大，包含一套完整的Review流程，支持现在几种流行的SCM工具和数据库。令人高兴的是它提供了在diffs里进行语法彩色编码，使得代码阅读变得简便。此外，它还实现了基于Lucene的搜索来帮助管理较大的diffs组。
2. 服务器安装
RB可以安装在多种平台。本文是在WinXP SP3上安装，其他平台请参考其他文档。
需要先安装Python 2.5和Apache Http Server 2.2，安装完成后，必须要先保证“C:\Python25;C:\Python25\Scripts”在你的环境变量里。其他软件（针对Python2.5）我已打包，见附件安装包。
1）安装和Python相关的一些工具
在软件包中，安装mod_python，PIL，setuptools。这几个都是双击之后，一路NEXT 即可。
2）安装memcached for windows（在软件包中）
先使用命令行memcached.exe -d install安装服务，再去WinXP服务管理界面启动该服务。然后用命令行easy_install python-memcached安装python-memcached. (NOTE: 最近发现easy_install也被墙了，所以用easy_install时可能有点问题。如果是那样，请找个代理，然后设置HTTP_PROXY环境变量翻墙）。
3）安装数据库
RB支持三种数据库服务器：MySQL、PostgreSQL 、SQLite 。
4）安装GNU patch（在软件包中）
它的安装也是一路NEXT。安装完成之后，把它EXE所在的路径放到PATH里。
5）安装SVN
安装SVN，建立SVN仓库，创建用户名和密码。
6）安装RB
RB团队已经把它放到easy_install的源里了，所以可以用 easy_install ReviewBoard 安装，该装的都完成了，下一站就是建站。
3. 建站
在命令行中打一句命令：rb-site install "站名"
之后，它会问你一会问题，比如用什么数据库，什么Http Server, 请按之前的安装回答。还会让你输入管理员密码之类的。
命令完成之后，会在当前工作路径下成一个的站名一样的目录。请到里面找到conf\apache-modpython.txt，这里面是一段apache server配置的片断,请把这片断复制到真正的httpd.conf里。
4. RB中添加Repository
在建站完成后，你应该可以访问到RBweb页面。
添加Repository, 需要用admin用户。然后是Perforce的配置。
首先有你在建站时用的admin用户登录，然后就会进入到Admin的页面（最上面有一个Admin 的链接）。
点击Repositories进入到SCM的配置页面。然后“Add Repository", 输入Perforce的相关参数。
保存之后，Perforce就配置完成了。
RB的Admin页面做得还算友好，其他方面的配置，比如Email，站点信息之类的，需要
进一步使用验证。也可以到官网去看Manual，学习如何使用ReviewBoard。
5. 如何发布一个Review Request
简单说ReviewBoard支持两种Review Code的模式，一种是在code没有commit之前提交diff/patch文件进行review，叫做pre-commit review，另外一种则是在code commit 之后，由工具自动根据提交的版本号生成diff/patch文件，并形成一条新的Review Request，这种模式也叫post-commit review。
先说pre-commit review模式。生成pre-commit review request有两种方法，第一种就是通过页面手工提交patch/diff文件的方法：首先通过界面设置好你的svn repository，比如：svn://10.78.13.228:3344；然后在你的DashBoard中“New Review Request"，有三个字段需要填写：
Repository:/* 选择你刚才配置的repository的id */
Base Diff Path: /* 如果你checkout出来的proj的svn url是svn://10.78.13.228:3344/trunk/testproj，那么这个字段填的就是/trunk/testproj */ Diff: /* 你生成的diff文件的路径，在Windows上可以用TortoiseSVN的creatpatch工具直接生成某个源文件的diff格式文件 */
填好后，提交，这时你就会看到一个处于draft状态的Request，继续编辑它，指定Reviewer，然后Publish这个Request，这样你指定的Reviewer就能看到这个Request了。这块如果你设置了Email通知，Publish过程会有一定延迟，特别是如果你的Email设置出错了，那Publish将一直处于ing状态，你刷新一下页面后，实际上你的Request已经publish 结束了。
另外一种提交pre-commit review request的方法是通过一个名为“Post-Review”的python脚本实现的。这个脚本在RBTools工具包中，较为好用，只要用这个post-review 加上checklist-id就OK了。
配置这个工具（有些是专门针对Perforce的配置）：
1) 保证SVN连接的情况下，用“easy_install -U RBTools”安装post-review工具
2) 修改post-review的相关脚本（下载https://www.360docs.net/doc/0512088861.html,/source/2856000。）修改分三步，第一，到C:/Python25/Scripts，删掉post-review.py, post-review.bat, post-review.exe; 第二，拷贝压缩包里的文件到C:/Python25/Scripts）; 第三，打开
post-review.py, 然后修改REVIEWBOARD_URL 那一行，用真实的URL替换。
3) 安装GNUDiff，这是用来生成diff文件的时候用的。要把diff加到PATH里，一般是这个路径"C:/Program files/GnuWin32/bin"。
关于post-review的更多用法，可阅读官方的Manual。ReviewBoard功能还算强大，Review时你可以针对每行代码写Comments，这种Review Code的方式给你足够时间去思考，只要你认真对待，就不会出现盲区、死角，所以新提交的代码就都能被Review到。
6. post review
1) 在你建的RB上，注册一个新账号;
2) 打开cmd, 用命令"post-review PendingChangelistId -o "
3) 第一次用这个命令，它会让你输入username和passwd，以后就不会了。
4) 上传DIFF之后，它会用默认的浏览器打开网页, 显示你刚上传的Request, 这时它处于draft状态。
5) 加上一些必要的信息, 比如谁来review之类的，然后就Pulish吧！
7.总结
RB的基础配置就这么多，它的英文网站上还有更丰富的内容，包括其他代码服务器的配置，RB升级，搬移等等。Review Board 的使用理念主要基于“Review Request”。开发人员提交一个补丁，同时生成一个 Review Request ；其他人针对这个补丁提供 Review 意见（可以对特定代码行发表 Review 意见，并且可以对 Review 意见进行回复讨论）。也可以利用 Review Board 提供的 RBTools 包中的 post-review 指令从代码库中指定几个版本自动生成一个 Review Request 。
总体来说，利用 Review Board 组织基于互联网的远距离协同开发还是不错的，可以有一个方便的界面对代码开展讨论。但是ReivewBoard（开源工具）的安装的确有些让人头痛，一堆互相依赖的软件包，版本稍有差异就很可能导致安装运行失败。而且失败的原因还很难得知。再则对中文的支持也比较差，按照默认的步骤安装和配置后，输入和保存英文均没有问题。但是一旦输入中文，保存后页面显示的都是乱码，甚至某些时候在保存中文数据时ReivewBoard还提示错误。为了使用好此工具，项目组要形成一套与之协作代码审查工作流程，并通过一定时间（参照网上其他项目组的经验，大概3到6个月）的持续改进来固化和部署。
附件二：《基于Code Collaborator的代码审查平台搭建简要说明》
1. 安装CodeCollaborator V6.0
安装程序在：http://10.78.11.19/
第一步首先安装并配置IIS；
第二步安装安装配置MySQL；
第三步接着安装Windows服务器安装程序；
a,欢迎页，欢迎您到这个屏幕的安装过程，点击下一步继续；
b,License许可协议, 阅读许可协议，选择我接受协议，然后再点击下一步；
c,选择目录地址进行服务器安装，确保该目录至少5 GB空间可用；
d,开始菜单创建快捷方式；
e,配置Web服务器,进入一个开放的端口号，不与任何现有的服务冲突。端口8080是标准的端口，我们将默认。单击下一步，安装程序尝试连接到这个端口。如果该端口正在使用中，会出现一个警告信息，你必须指定一个不同的端口或免费注册所需的端口；
g,配置数据库类型MySQL，填写详细配置使用数据库的用户名和密码，用户名和密码；
h,选择下列认证类型之一：
内部：在维护自己的数据库用户名和密码。
LDAP的：您可以使用LDAP身份验证，这将不要求你维护用户名和密码。如果选择此选项，则下一屏幕允许您配置LDAP集成。由于这种配置是有点麻烦。
第四步登录到Web浏览器客户端，
当您在安装完成后，Web浏览器会自动打开，将用来管理服务器的一部分。
a,数据库初始化。当第一次打开配置服务器的网络浏览器，“需要数据库初始化”显示出来，点击初始化数据库继续。
b,内部验证。如果您选择在安装过程中内部认证前，指定“管理员”作为用户名，密码字段留空白。点击登录。
第五步，首次运行初始化，一旦你作为管理员登录，下图会要求您提供必要的信息设置服务器。
最初的几个用户，下图将帮助您开始填写用户列表。你应该提供这部分至少有两个用户名。
通常情况下，管理员登录仅用于管理目的，因此建议您输入的个人用户名是以进行自己的代码审查的目的。
第六步，首页。
在第一次运行的初始化将进入主页。
一个绿色的提示框，提醒您可以配置您的服务器，或建立一个新的审查等，在主菜单链接处，默认情况下，不允许管理员创建评语。
下图是管理站
一旦你点击Admin链接，浏览器会指示您到管理部分。在管理部分是在这里您可以根据自己的喜好配置设置。
屏幕的左侧黄色框是管理菜单，其中包含了有用的链接数，通过不同的配置指导子类别。第七步，许可
ID：找到8个字符节点的“许可证“编号。ID是独一无二的，每次安装，由ID授权码激活您的许可证。
第八步服务器设置开通用户权限，并发布给用户；
用户客户端安装过Windows客户端安装程序后，登陆设置服务器地址、用户名和密码后，见下图。然后设置与SVN连接后即完成安装并可以使用CodeCollaborator进行代码审查的流程。
所需的各安装程序名称见下图：
2. Code Collaborator 使用见Owner's Manual：
https://www.360docs.net/doc/0512088861.html,/docs/manual/6.0/
3. 登录到客户端Web浏览器。输入您的登录名和密码。（用户名和密码，通常是由管理
员提供的，但如果你的管理员允许用户创建登录，您可以创建自己的登录名和密码）一旦你登录，您可以检查您的行动项目，看看是否有任何指定评论。您还可以通过点击编辑在屏幕上的菜单栏右设置。
4. 创建作为一个代码审查请求：有几种选择创建一个审查。
a,在菜单栏上单击新”New Review”
b,在屏幕上创建一个审查，填写基本信息和选择审查参加者在屏幕上创建一个审查
c,单击Apply。这一步是必要的；
d,在客户端允Web浏览器支持下，创建一个审查和修改列表。
d,单击Apply and Begin Review,开始审查，并发出通知给参与审查人员。
5. 添加审查意见和标注缺陷
有人邀请你去审查，您收到一封电子邮件通知，并根据任务清单进行审查。点击将其打开。
单击一个文件，外部的diff查看器会将将其打开，并且您将可以在这里直接添加评论和标注缺陷。
评论：点击就行了（文本文件）或地区（在支持文档）你想评论，然后键入您的评论。评论是嵌入个被绑缚到一个特定的代码行的谈话，未读的评论是黄色标记。
提示：您可以单击接受或清除标记已读未读评论。标记已读只是表明你已经看到了评论。当您查看文件多次，如果你不想重新读取相同的意见，这是有益的。一旦这个按钮被使用，会出现一个绿色的对勾通知。
缺陷：当你发现一个缺陷，点击这一行（文本文件）或区域中单击（在支持文档）缺陷。确保新增缺陷标签被选中，并撰写你对缺陷的描述。一旦一个缺陷被创建，您可以标记为已解决的缺陷，编辑或删除的缺陷，或者用它在评论框底部的链接一个外部的缺陷。如果输入缺陷，作者应该修复的缺陷和上传修复和评论修改后的代码，直到代码是可以接受的。请注意，直到所有的缺陷得到解决：要么标记为已解决的，删除，或追踪外部，否者审查活动将不会关闭。
6. 完成审查
代码审查规范
1. Code Revie进行检查试过现的质量保机制，通这个机制我可以代码、注一种Code Revie来确认方案计和代码的要用在软件工程程中改进码质量，Code Revie以达到如下Code Review代码审查规范1. Code Review目的 Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码、测试过程和注释进行检查。 Code Review主要用来在软件工程过程中改进代码质量，通过Code Review可以达到如下目的： 在项目早期就能够发现代码中的BUG。?帮助初级开发人员学习高级开发人员的经验，达到知识共享。?避免开发人员犯一些很常见，很普通的错误。?保证项目组人员的良好沟通。?项目或产品的代码更容易维护。? 2. Code Review的前提条件 代码提交审核前，开发者必须确保代码符合如下条件，审核者需要确保所有前提条件都已满足方可开始审查，同时也是审查的主要检查点。 所有代码注释清晰，语法正确，编译通过。?日志代码完整，业务日志、系统日志分开，中文描述，脱敏处理，状态变更，?全部清晰明确。 测试代码覆盖全部分支和流程，暂时统一使用工具Emma（各编译器可下载对?应插件）进行Coverage Check。 项目引用关系明确，依赖关系清晰，配置文件描述。? 的审查范围3. Code Review 代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正确设计以符合设计要求（性能、功能）与设计文档相同等等。）完整性检查（Completeness3.1、 代码是否完全实现了设计文档中所涉及的所有流程和功能点?代码是否已包含所有所需的业务日志、系统日志、异常日志，日志内容是否完?整，日志文件配置是否正确。 代码是否使用缓存等，配置信息是否正确可配置。?代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型等?一致性检查（Consistency）3.2、 代码的逻辑是否符合设计文档?代码中使用的格式、符号、结构等风格是否保持一致?）Correctness3.3、正确性检查（代码是否符合制定的标准?所有的变量都被正确定义和使用?所有的注释都是准确的?所有的程序调用都使用了正确的参数个数? Modifiability）、3.4 可修改性检查（如使用配置、定义为类常量、使用专门的常量代码涉及到的常量是否易于修改(?)类等 代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行?访问的 代码是否只有一个出口和一个入口（严重的异常处理除外）?）可预测性检查（Predictability3.5、代码所用的开发语言是否具有定义良好的语法和语义?是否代码避免了依赖于开发语言缺省提供的功能?代码是否无意中陷入了死循环?代码是否避免了无穷递归?．
OA-项目阶段评审表-4-编码评审报告
OA系统 1.0 详细设计评审报告 文件控制文档编号分册名称总页数?受控?不受控 O A-1703 版本号 1.0 O A项目开发-详细设计评审报告第1册/共1册6页正文 审批 4页附录无 编制江华谭璨生效日期2014/4/10 湖南楚晟科技有限公司
修改变更记录： 更改条款及内容更改人 江华审批人 谭璨 更改日期 1.0 2014/4/10
声明： 在软件开发过程中的适当阶段对软件阶段产品进行评审，是确保软件产品最终质量的重要方法。阶段评审可以对某个开发阶段的阶段产品进行评审，也可以对某几个开发阶段的阶段产品进行综合评审。在每次阶段评审中，必须履行正式手续，填写必要的评审表格，以利于项目管理工作，利于产品验收时的质量检查工作。 项目阶段评审表由三张子表组成，表 1是对评审中指标问题记录 RPL(review problem log)；表2是评审总结报告RSR(review summary report)；表3是评审小组成员登记与签字表。
表 1评审问题记录（RPL ） 3 登记号 2014/4/10 RPL 评审问题记录 评审日期 评审性质评审√复审□ 1 项目名 编号 O A 系统项目 问题摘要 项目编号 问题类型 是否解决 是 是 是 是 是 是 是 是 1 2 3 4 5 6 7 8 9 是否所设计的架构，包括数据流、控制流和接口，被清楚地表达了清晰性 清晰性 是否所有的假设、约束、策略及依赖都被记录在本文档了 数据元素、流程和对象的命名和使用在整套系统和外部接口之间是一致性 一致性 是否依照实际操作环境（硬件、软件和支持软件）进行详细设计 可行性 是否出现了错误的、缺少的或不完整的详细设计逻辑 编码规范 代码设计是否符合规范、是否符合概要设计要求 数据使用 是否已描述最低级别数据元素，是否已详细说明取值范围 算法设计 对所有算法设计、说明是否具体、明确 程序接口实现是 程序接口设计是否明确、具体 操作界面的设计是否采用了人性化的设置（例如：词汇、使用信息程序接口实现是 和进入系统的提示是否人性化） 10 程序输入输出是 11 12 13 14 程序所有输入输出是否描述具体清晰 是否已经对继承设计、代码或先前选择工具的使用进行了详细说明可维护性 是 重要模块说明是 是否对主要逻辑模块进行了特殊的说明和解释 该设计能够提供错误检测和恢复吗？ 可靠性 是 是 是否能够对该系统进行测试、演示、分析或检查来说明它是满足需易测性 求的 15 易测性 是 是 16 17 该系统是否能用增量型的方式来集成和测试 可追溯性 是否各部分的设计都能追溯到需求说明书的需求
代码评审表
产品代码评审表 注：表头检查项目中黑体的项目表示必审项。
使用说明： 1.此表用于检查产品/项目代码的状况，从而从代码上对产品质量进行提高。 2.由产品经理或设计人员确定代码的检查范围，以核心业务处理的代码检查为主； 3.按照确定的检查范围列出需要检查的类清单，并通过检查代码得出评审结论，对于各种类的检查侧重点可以不同； 4.代码检查采用程序员自己检查和至少一个其他程序员进行复查的方式进行； 5.在代码实现的功能基本正确以后才能进行该部分代码的确认，对评审发现问题的代码要复查； 6.类型有以下几种状态：界面（UI）、业务处理（BO）、数据处理（DM）、数据对象（VO）； 7.按照检查项目逐项确认，对正确的项填写“Y”，有问题的项填写“N”，不需确认的项填写“－”，未确认的项不填； 8.评审结果可以分几种：A--好、B--合格、C--有问题、D--有严重问题。对于有问题和有严重问题的需要注明问题的内容（可以附加问题说明），对 于这种情况需要再重新进行代码修改并重新进行确认； 9.在代码提交时要求同时提交本确认表，提交时要保证所有检查的类的评审结果为A或B； 10.确认的项目除列出的项目外，产品组可以补充项目。项目说明： ●易读性：代码结构清晰； ●注释清晰：对功能的注释及代码的作者； ●命名规范：变量、类、方法、属性的命名符合公司开发规范； ●逻辑正确性：业务逻辑处理的正确性； ●事务一致性：TRANSACTION是否一致； ●Sql语句清晰：SQL语句结构是否清晰； ●计算精度：如计算精度有问题时是否使用了UFDouble； ●用标准控件：对于可以使用标准控件的是否使用标准控件； ●调用中间件：不存在反复调用中间件的情况； ●BS与UI交叉：没有BS类与UI类的交叉调用情况； 通过检查以上项目，根据情况得出评审的结论，必审项目要求必须检查；
代码审查规范方案
代码审查规范 1. Code Review目的 Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码、测试过程和注释进行检查。 Code Review主要用来在软件工程过程中改进代码质量，通过Code Review可以达到如下目的： ?在项目早期就能够发现代码中的BUG。 ?帮助初级开发人员学习高级开发人员的经验，达到知识共享。 ?避免开发人员犯一些很常见，很普通的错误。 ?保证项目组人员的良好沟通。 ?项目或产品的代码更容易维护。 2. Code Review的前提条件 代码提交审核前，开发者必须确保代码符合如下条件，审核者需要确保所有前提条件都已满足方可开始审查，同时也是审查的主要检查点。 ?所有代码注释清晰，语法正确，编译通过。 ?日志代码完整，业务日志、系统日志分开，中文描述，脱敏处理，状态变更，全部清晰明确。 ?测试代码覆盖全部分支和流程，暂时统一使用工具Emma（各编译器可下载对应插件）进行Coverage Check。
?项目引用关系明确，依赖关系清晰，配置文件描述。 3. Code Review的审查范围 代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正确设计以符合设计要求（性能、功能）与设计文档相同等等。 3.1、完整性检查（Completeness） ?代码是否完全实现了设计文档中所涉及的所有流程和功能点 ?代码是否已包含所有所需的业务日志、系统日志、异常日志，日志内容是否完整，日志文件配置是否正确。 ?代码是否使用缓存等，配置信息是否正确可配置。 ?代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型等 3.2、一致性检查（Consistency） ?代码的逻辑是否符合设计文档 ?代码中使用的格式、符号、结构等风格是否保持一致 3.3、正确性检查（Correctness） ?代码是否符合制定的标准 ?所有的变量都被正确定义和使用 ?所有的注释都是准确的 ?所有的程序调用都使用了正确的参数个数
代码走查检查表
代码走查检查表 评审日期：年月日评审对象作者 评审人评审工作量 序号检查项评审意见 走查前准备 1 得到一份解释代码的最新的设计文档，作为代码走 查的参考 2 代码都已提交，版本统一 程序结构组织 1 所有代码的结构清晰，具有良好的结构外观和整齐 2 所有的模块（函数和外部接口）定义清晰，模块分解 清楚 3 所有的功能需求都明显的覆盖 4 整个代码体系结构组合合理 ,分层清晰，代码之间功 能划分明确 5 所有的接口模块化，尽量减少接口之间的耦合度，修 改时尽量不影响其他代码模块 6 代码体系构架对空间和速度都已经进行考虑 7 数据库操作、IO操作等是否正确关闭资源。并且必 须在try -catch-finally 的finally中关闭。 8 一个业务如果进行多次数据库更新、添加、删除是否 正确添加事务。 9 进行逻辑与、逻辑或判断时是否使用短路与、短路或。 10 多处使用相同代码时，应定义唯一方法或变量以供使 用。 11 对象是否使用工厂获取。 12 导入类时，如果仅使用包中的几个类，应导入具体类， 而不是导入整个包。 13 数组声明的时候使用 int[] index ，而不要使用 int index[]。 14 代码实现的逻辑是否与详细设计描述的逻辑一致 15 检查类中是否有无效的代码或者是无用的代码。 16 不要使用System.out.print()以及System.err输 出，需要进行日志处理 17 所有的文件名符合文件命名规范，见名知意 18 文件和模块分组清晰 19 较长的语句、表达式或参数（>80字符）要分成多行 书写，长表达式要在低优先级操作符处划分新行，操 作符放在新行之首，划分出的新行要进行适当的缩 进，使排版整齐，语句可读 20 每个程序文件都小于2000行
代码检查、走查与评审
代码检查、走查与评审 (总分：96.00，做题时间：90分钟) 一、{{B}}选择题{{/B}}(总题数：32，分数：96.00) 1.下列选项中不属于静态错误分析的是______。 （分数：3.00） A.类型和单位分析 B.功能分析√ C.引用分析 D.表达式分析 解析：[解析] 静态错误分析主要用于确定在源程序中是否有某类错误或“危险”结构，它通常包括4种：类型和单位分析、引用分析、表达式分析、接口分析。 2.在软件生存周期中要有管理评审，原因在于______。 （分数：3.00） A.需要回顾已经过的开发状况 B.需要分析总结出软件存在的问题 C.需要分析总结出改进的措施 D.以上全部√ 解析：[解析] 管理评审是对项目管理体系的适应性和管理活动的有效性进行评价。在软件生存周期中需要管理，目的是为了能够更好地开发和更快地进展。为此，需要回顾已经过的开发状况，分析总结出软件存在的问题以及改进的措施，这些便是要进行管理评审的原因。 3.在代码检查中，负责提供关于检查项目的资料并回答检查人员问题的角色是______。 （分数：3.00） A.协调人 B.开发人员√ C.检查人员 D.讲解员 解析：[解析] 代码检查小组通常规模很小，是由设计、开发、质量等不同部门中工作性质相关的人员中与产品关系密切的那些人组成，一般人数为4～7人不等。小组人员的角色分配通常有：协调人员、开发人员、检查人员、讲解员、记录员。其中开发人员是检查项目的生产者，主要负责提供检查项目资料和回答检查人员问题；协调人员主持、引导代码检查的执行过程，全面负责代码检查的效果；讲解员负责在检查会议中讲解检查项目，引导小组对产品进行彻底检查；记录员负责会议期间在检查表上记录发现的每一个错误，同时也承担作为一般检查人员的任务。 4.在软件企业中，应用最广泛的评审方法是______。 （分数：3.00） A.走查√ B.结对评审 C.正式评审 D.小组评审 解析：[解析] 同行评审的方法很多，基于正式化程度可以分为临时评审、桌上检查、结对评审、走查、小组评审、正式评审6种，其中走查是一种非正式的评审，但在软件企业中被广泛使用。走查的方法有两种：一种是使用一些样品数据作为测试用例，一步步地执行模块，几位参与评审的一起检查以确保正确的逻辑和行为；另一种走查是按照脚本执行，通过脚本描述一个具体的任务或场景，用以说明系统如何在交互中完成预定的功能。 5.小组成员开会，集体扮演计算机角色，把测试数据沿程序的逻辑结构走一遍是______。 （分数：3.00） A.数据分析 B.执行测试用例
代码评审清单
代码评审清单（Code Checklist ） 产品,项目组名称；_宅急送_________ 产品项号名称，公共_______________ 版本号：被检杳人簽字：—检杳內容: _ _ 检查人螯宇，_____________________ 检查日期’______________________ 说明：
是杏尽童避免了嵌会的立?弔 篦杂芳雄是否併行了必茅而充分的汗释 拎K是否代码拥亍路径是否清晰 S罰Chi航是否有決4分支 控制逻短复杂度是否合浬是否诜行了必更1门充分的注释 同个循坏怎是吞仅执行了羊而明确的巧毙 占械比校需要挣常数玫在比较表达式的前面 否代彳礎丧奸格ig化并能疝苴逻辑结枸 尽量孑哎在循开丙岀观近程谐月奇个吐务可作远程谓用次数是否小于以 冈1中因数是吞仕抱定范围内 Joinb on矽页产恪匹0己 问題淸单. 冋幅沐阚窟改n期修改n期楡杳 SQL r 是 冈1语句』碍 弓用乎符画单引号 T^MO select *开预的语句，必姦指出旦饶宇SF 严禁使用ins?t m2 Uiblc: values "t ? , ? , "?) ＞必须指1岀具依更0jt值広字段 避兌隐含的炎型转换(不同数据类型字段明加) 子宣询前后必须加上桔号 邀免在我here使用，1* / 1=2’这*怯廿戎作为部分条件 禁上使用椰图 禁上使用XX in 0 or XX血CKm中的元素个数不应超过500) 禁止使用or超辽500个 其止使用not in?建议使冃not exist 婪止在一条河语句中恃月3层以丄的嵌套 如具勺多表连莪盯「应该有主从之分，尽重从一个表取数 Where子句过滤条杵，索引列或过遞记录最多氏条林应験在前面 字符邑连接必须使用“ r Caw when吾匀中巳能出珂二、k、u以及is mill运算袴 左连接写送必須带”cxuei'关佬宰 伝稈诅用蓟摇伎端启否有不必萼的冗輛摇
设计评审控制程序
XXX项目 设计评审控制程序
修订历史记录
目录 1 目的 (4) 2 适用范围 (4) 3 职责 (4) 3.1 项目经理 (4) 3.2 部门经理 (4) 3.3 评审组长 (4) 3.4 副总 (4) 4 工作程序 (4) 4.1 设计评审时机 (4) 4.2 设计评审的形式 (5) 4.3 设计评审的准备 (5) 4.4 设计评审的实施 (5) 4.5 对发现问题的处理和跟踪措施 (5) 4.6 质量记录的控制 (6) 5质量记录 (6)
1 目的 通过设计评审发现设计开发活动中存在的问题，及时采取措施解决，同时对解决措施的执行情况进行跟踪验证以确保其有效性。 2 适用范围 本程序适用于项目设计开发各阶段所进行活动的评审工作。 3 职责 3.1 项目经理 项目经理或相关人员提出评审申请。 3.2 部门经理 批准申请，并组织实施，审核《评审报告》。 3.3 评审组长 负责编写《评审报告》 3.4 副总 负责审批《评审报告》 4 工作程序 4.1 设计评审时机 计划阶段：在计划阶段完成后，需要对《项目开发计划》、《质量保证计划》、《配置管理计划》进行评审。评审会应包括：项目经理、项目组的技术骨干，如果项目为重大项目，还应包括主管副总、技术总监、有关专家和用户代表。
需求分析阶段：在需求分析阶段完成规格之后，需要对《需求规格说明书》进行评审。评审会应包括：项目经理、需求分析人员、项目组的技术骨干，如果项目为重大项目，还应包括技术总监、有关专家和用户代表。 设计阶段：在详细设计完成之后需要对《详细设计说明书》进行评审。评审会应包括：项目经理、项目组的技术骨干，如果项目为重大项目，还应包括技术总监和有关专家。 编码阶段：在编码阶段结束时，需要对程序代码进行评审。评审会应包括：项目经理、项目组的技术骨干。 测试阶段：在系统测试阶段开始之前，系统测试部应完成对《测试计划》的评审。评审会应包括：测试部与本项目有关人员、项目经理、项目组的技术骨干，如果项目为重大项目，还应包括技术总监。 如果发现的问题涉及顾客需求变更、体系结构调整，或者是跨基线的变更，要先申请评审。 4.2 设计评审的形式 设计评审采取评审会的形式。 4.3 设计评审的准备 评审申请人应填写《评审申请表》，提出设计评审申请，同时附上相应的《检查表》，报部门经理审批。 《评审申请表》的内容包括： ●项目名称； ●评审时间、地点； ●评审组长、成员。 ●评审的方式方法； ●评审内容。 评审组长或其指定人员负责准备相关资料。 评审组长应提前1—3个工作日通知参加评审的人员，并向其发放评审相关资料，参加评审人员应根据评审安排和相关资料，做好评审准备。 4.4 设计评审的实施 评审由评审组长主持。 评审小组通过交谈、查阅文件、检查现场，对《评审申请表》中的各项评审内容进行评审。 评审组长汇总评审意见，编写《评审报告》，报部门经理审核，由直属副总审批。 4.5 对发现问题的处理和跟踪措施 评审结束后，部门经理根据《评审报告》中提出的问题，责成有关人员按规定期限对所发现的问题加以解决。 对于重大部题根据《评审报告》的要求进行复审。