《[精品]软件代码与测试缺陷的管理》由会员分享，可在线阅读，更多相关《[精品]软件代码与测试缺陷的管理（72页珍藏版）》请在金锄头文库上搜索。
1、软件代码与测试缺陷的管理,陈 志 成 北京东方瑞威科技发展有限公司 2007.03.24,计算机软件培训讲座,讲座内容,一、软件代码的管理 二、代码的审查规范 三、软件项目的测试 四、软件的缺陷管理,一、源代码的管理,1.1 软件源代码管理工具,目前主要的源代码管理是： CVS、VSS CVS（Cuncurrent Versions System）是基于 TCP/IP 协议的版本控制工具，也是 Open source 界最重要的开发工具之一。CVS 保存了对项目源码每一次改动的记录和注释。 在任何时候，你都可以找到仓库中任何文件的任何版本。它容许几个人同时工作在同一个文件，在他们提交文件时来合
2、并他们所做的修改。在修改冲突时会发出警告来通知用户，确定将此文件的更新版本放入仓库内，发生的冲突由某人解决。 VSS（Visual SourceSafe）是微软的源代码管理工具，与CVS功能基本相似，用法上略有不同。在此以CVS为例介绍。,1.2 基于CVS的并行开发流程,你把你的所有代码导入（import）CVS，然后其他人可以检出（check out）源码树的一个工作拷贝。 每个人都工作在自己的本地计算机中，当有一个新的功能出现时，他们必须更新（update）他们的本地拷贝来保持和当前版本同步。他们会提交（commit）他们改变的文件到仓库中来生成新的版本。 在提交时出现的问题CVS都会产
3、生警告，然后你必须仔细检查出问题的文件来手工解决冲突。在文件中，改动的部分会在前面以 符号显示，并且列出两个版本的不同之处。仅删除旧版(或修改使它能够工作)，再次提交文件，一旦CVS没有警告返回上一步，继续工作。,1.3 CVS操作,1.4 CVS的基本概念,repository仓库： 用于存放版本控制下的所有目录和所有各种版本的文件；CVS会完成对repository的查询和更新。 数据如何存放在repository中：随着CVS版本的不同，存放结构会发生变化，一般情况下用户无需了解数据到底是如何存放的。 Modul：一个目录层。一个软件工程通常作为单个的模块存放在库中。 checkout：
4、描述将某个模块从库中首次导出。 Commit：将你对文件的修改提交到库中。（相当于VSS中的checkin） Timestamp: CVS自动给文件添加的日期标志， 格式形如：Fir Dec 20 06:18:48 revision：文件的版本。形如1.1，1.2.1，一般1.1是该文件的第一个revision，后面的一个将自动增加最右面的一个整数。,1.4 CVS的基本概念,branch：分支是出于软件版本的稳定性和开发的延续性考虑的，当我们在原来的版本基础上需要创建另外一个版本（项目）时，可创建一个分支，分支跟主版本可独立开发，又可以相互合并。一般是有个发布版v1.0，在开发v1.2的基础
5、上，同时又在修改v1.0，这时就可以创建分支，不同分支也可以互相合并。 tag：tag顾名思义就是做个标签，如张三的文件，他就可以做个标签为“张三“以表明是他的文件。Tag只是在文件上做了一个标签，并没有创建不同的文件。通常不需要对某一个孤立的文件作tag，而是对所有文件同时作一个tag，以后用户可以仅向特定tag的文件提交或者checkout。另外一个作用是在发布软件的时候表示哪些文件及其哪个版本是可用的；各文件不同revision可以包括在一个tag中。如果命名一个已存在的tag, ，默认将不会覆盖原来的。 conflict：完全是纯文本的冲突，不包含逻辑上的矛盾。冲突的产生是在多人对同一
6、文件的修改的时候，不同的人对此文件的同一地方做了修改，这个时候CVS以文本的形式给出了冲突的地方，至于如何处理，CVS给出引导，最终靠用户决定如何解决。,1.5 CVS中的指示符含义,U file 形如“U file”的行表示文件已被更新为源代码树仓库中最新版本。这一操作适用于本地工作目录中不存在但源代码树仓库中却存在的文件；或是本地工作目录中没有修改但却不是源代码树仓库中最新版本的文件。 P file 与“U file”类似，但cvs服务器只是提供一个补丁而不是整个文件。两种操作的结果是相同的。 A file “A file”表示文件已经被添加到个人的工作拷贝中，但是还未提交到源代码树仓库中
7、。如果从本地工作目录中删除，将丢失文件。这个指示符提醒你对添加的文件进行提交。 R file “R file”表示文件已经从个人的工作拷贝中删除，但是还未提交删除操作，所以该文件还没有从源代码树仓库中删除。这个指示符提醒你对删除的文件进行提交。,1.5 CVS中的指示符含义,M file “M file”表示文件已经在工作目录中被修改。 M能够表示你所修改文件的两种情况：一是源代码树仓库中的文件没有被修改，还保持在你最后一次更新时的状态；或是源代码树仓库中的文件已经被修改，但是可以与你本地工作目录上的文件无冲突地成功合并。 C file “C file”表示合并本地修改和源代码树修改时有冲突发
8、生。file（本地工作目录上的备份）现在是试图合并两个版本的结果；未修改的文件备份被标记为.#file.revison，也保存在本地的工作目录上，这个版本是你所修改文件的初始版本。（在有些系统中，以.#开头的文件如果有一段时间没有被访问的话会被自动清除。所以假如你想保存初始文件的备份，最好的办法就是重命名）。 ? file “? file”表示file仅存在于本地工作目录中，不与源代码树仓库中的任何文件相对应，不受cvs的控制。,1.6 CVS中的配置,1.7 CVS中的上传(Import),1.8 CVS中的下载(CheckOut),1.9 CVS中的提交(CheckIn),1.10 CVS
9、中的文件比较,二、代码的审查规范,2.1 代码审查规范：岗位与职责,代码提交人 (1) 完成阶段性的编码工作。 (2) 预提交代码必须是在当前最新的环境下完成。 (3) 预提交代码必须符合公司编码规范。 (4) 预提交代码必须确保编译通过。 (5) 必须在自己的个人建造版本上进行测试，保证测试用例全部通过。 (6) 保证CheckIn操作的正确性，不能遗漏文件或其他错误操作。,2.1 代码审查规范：岗位与职责,代码审查人(review ) (1) 负责对代码做Code Review。 (2) 保证预提交代码的质量和功能正确性。 (3) 指导监督新员工前三次CheckIn操作，保证新员工Chec
10、kIn操作的正确性,CheckIn mail发送的正确性。 (4) 需要提前确定项目模块的负责人，code review必须有模块负责人参加。,2.2 代码审查规范：CheckIn,CheckIn的含义 对数据库中现有的程序代码进行修改（包括修改，添加，删除等操作），要把自己的修改提交到数据库的操作，我们称之为CheckIn。 CheckIn操作的步骤 (1) 若在本地目录新增（删除）文件，第一时间在Wincvs(或SourceSafe，暂以Wincvs说明)上Add selected（Remove selected）。 (2) 编写代码，修改其他文件。 (3) Update和merge新的代
11、码。 (4) 运行编译检查, 并确保全部编译通过。 (5) 进行测试，保证测试用例全部通过。 (6) 代码审查（Code Review）：必须找相应的code review负责人做代码审查工作，code reviewer可借助代码风格整理工具检查代码风格。 (7) ChecekIn代码，commit提交。 (8) 填写发送CheckIn mail，通知所有开发人员本次CheckIn的内容、意义。 (9) 新员工的前三次CheckIn都要在review人员的监督下操作，避免出现不必要的错误。,2.2 代码审查规范,CheckIn mail发送 在CVS执行CheckIn操作之后，要登录“软件工程
12、管理系统”，进入相应的页面填写CheckIn mail。具体步骤如下： (1) 进入软件工程管理系统后系统会自动提示有代码Checkin，确认要填写(有时可以多次Checkin后再统一发Email，这时可以暂时不用填写)。 (2) 选择CheckIn代码或文档所属的项目和任务。 (3) 选择或填写Checkin的类型，添加代码、或修复BUG等。 (4) 进入CheckIn mail的页面，按照其规定格式填写即可。 (5) 填写完毕后，点击“提交CheckIn记录”，系统会自动将此CheckIn记录的内容email给相关人员。,2.2 代码审查规范,CheckIn 的重要性 (1) 将自己修改的
13、代码保存到服务器的数据库上，这样可以保证数据不会丢失。 (2) 更新了数据库，可以使其他人获取自己修改后的程序代码，保证了工作上的协调一致。 (3) 软件项目的所有源代码、测试代码、说明文档等，就是由这一次次的CheckIn构建起来的。每一个CheckIn，都清楚的显示着大家的工作情况，工作内容和结果。,2.2 代码审查规范,CheckIn 的注意事项 (1) 任何人在修改代码后，都要经过Code Review，才能够CheckIn代码，这样可以保证代码的质量。千万不要存在侥幸心理，认为自己的改动无关紧要，没有经过别人Code Review，就CheckIn。要知道，每一个细小的错误，都有可能
14、造成不可预期的严重后果。一次错误的修改，可能会把源代码树放倒，将影响到所有人的正常工作。 (2) 修改后的代码，要尽快CheckIn，不可拖得时间太长。当自己checkin之前，别人又有CheckIn时，需要重新获取服务器上的代码（UpDate），如果有冲突需进行merge，然后重新做checkin前的检查，避免产生错误。 (3) 不允许在源代码冻结时或者系统夜间做自动测试或自动备份时CheckIn。 (4) 每次CheckIn之后必须及时填写CheckIn mail。要让别人知道自己都做了什么事情，这也是考核评定的重要组成部分。 (5) CheckIn记录不允许是修复Bug的工作，必须先有B
15、ug号，才有BugFix (BUG修复) 记录。发现的Bug必须录入到Bug系统。,2.3 代码审查准则,Code Review的目的 凡事知其然还要知其所以然，我们首先需要知道什么是Code Review和我们使用它的目的是什么。 Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码，测试过程和注释进行检查。Code Review主要用来在软件工程中改进代码质量，通过Code Review可以达到如下目的： 在项目早期就能够发现代码中的BUG。 帮助初级开发人员学习高级开发人员的经验，达到知识共享。 避免开发人员犯一些很常见，很普通的错误。 保证项
16、目组人员的良好沟通。 项目或产品的代码更容易维护。,2.3 代码审查准则,Code Review的前提 (1) Code Review人员要理解Code Review的概念。 (2) 代码是否已经正确的build。 (3) 代码执行时功能是否正确。 (4) Review人员是否理解了代码。 (5) 开发人员是否对代码做了单元测试。,2.4 代码审查内容,(1) 完整性检查（Completeness） 代码是否完全实现了设计文档中提出的功能需 代码是否已按照设计文档进行了集成和Debug 代码是否已创建了需要的数据库，包括正确的初始化数据 代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型 (2) 一致性检查（Consistency） 代码的逻辑是否符合设计文档 代码中使用的格式、符号、结构等风格是否保持一致,2.4 代码审查内容,(3) 正确性检查（Correctness） 代码是否符合制定的标准 所有的变量都被正确定义和使用 所有的注释都是准确的 所有的程序调用都使用了正确的参数个数 (4) 可修改性检查（Modifiability） 代码涉及到的常量是否易于修改（如使用配
