软件代码与测试缺陷的管理.ppt

《软件代码与测试缺陷的管理.ppt》由会员分享，可在线阅读，更多相关《软件代码与测试缺陷的管理.ppt（71页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件代码与测试缺陷的管理软件代码与测试缺陷的管理 计算机软件培训讲座讲座内容讲座内容一、软件代码的管理一、软件代码的管理二、代码的审查规范二、代码的审查规范三、软件项目的测试三、软件项目的测试四、软件的缺陷管理四、软件的缺陷管理一、源代码的管理一、源代码的管理1.1 软件源代码管理工具软件源代码管理工具n目前主要的源代码管理是：目前主要的源代码管理是：CVS、VSSnCVS（Cuncurrent Versions System）是是基基于于 TCP/IP 协协议议的的版版本本控控制制工工具具，也也是是 Open source 界界最最重重要要的的开开发发工工具具之之一一。CVS 保保存存了了对

2、对项项目目源源码码每每一一次改动的记录和注释。次改动的记录和注释。n在在任任何何时时候候，你你都都可可以以找找到到仓仓库库中中任任何何文文件件的的任任何何版版本本。它它容容许许几几个个人人同同时时工工作作在在同同一一个个文文件件，在在他他们们提提交交文文件件时时来来合合并并他他们们所所做做的的修修改改。在在修修改改冲冲突突时时会会发发出出警警告告来来通通知知用用户户，确确定定将将此此文文件件的的更更新新版版本本放放入入仓仓库库内内，发发生生的的冲冲突由某人解决。突由某人解决。nVSS（Visual SourceSafe）是是微微软软的的源源代代码码管管理理工工具具，与与CVS功功能能基基本本相

3、相似，用法上略有不同。在此以似，用法上略有不同。在此以CVS为例介绍。为例介绍。1.2 基于基于CVS的并行开发流程的并行开发流程n你你把把你你的的所所有有代代码码导导入入（import）CVS，然然后后其其他他人人可可以以检检出出（check out）源码树的一个工作拷贝。）源码树的一个工作拷贝。n每每个个人人都都工工作作在在自自己己的的本本地地计计算算机机中中，当当有有一一个个新新的的功功能能出出现现时时，他他们们必必须须更更新新（update）他他们们的的本本地地拷拷贝贝来来保保持持和和当当前前版版本本同同步步。他他们们会会提提交交（commit）他们改变的文件到仓库中来生成新的版本。）

4、他们改变的文件到仓库中来生成新的版本。n在在提提交交时时出出现现的的问问题题CVS都都会会产产生生警警告告，然然后后你你必必须须仔仔细细检检查查出出问问题题的的文文件件来来手手工工解解决决冲冲突突。在在文文件件中中，改改动动的的部部分分会会在在前前面面以以 符符号号显显示示，并并且且列列出出两两个个版版本本的的不不同同之之处处。仅仅删删除除旧旧版版(或或修修改改使使它它能能够够工工作作)，再再次次提提交文件，一旦交文件，一旦CVS没有警告返回上一步，继续工作。没有警告返回上一步，继续工作。1.3 CVS操作操作内内 容容说说 明明CVS基本概念基本概念实用实用CVS时的常用概念时的常用概念CV

5、S记录文件记录文件记录用户对记录用户对CVS的所有操作的所有操作配置配置介绍如何配置介绍如何配置CVS客户端客户端登录登录登录到系统中的登录到系统中的CVS服务器服务器文件上传文件上传上传上传CVS服务器上没有的服务器上没有的module到服务器上到服务器上文件下载文件下载将服务器上的文件下载到本地将服务器上的文件下载到本地编辑文件编辑文件编辑本地文件编辑本地文件提交修改文件到服务端提交修改文件到服务端编辑本地文件编辑本地文件比较文件比较文件比较文件的异同比较文件的异同更新本地文件更新本地文件将服务端文件更新到本地将服务端文件更新到本地合并文件合并文件合并不同分支（版本）的文件合并不同分支（版

6、本）的文件添加文件添加文件上传上传CVS服务器上没有的文件到服务器上服务器上没有的文件到服务器上删除文件删除文件删除删除CVS服务器上的文件服务器上的文件创建标签创建标签为文件创建标签为文件创建标签分支分支实现软件产品分支的操作实现软件产品分支的操作查看版本历史查看版本历史查看查看CVS服务器上文件的历史纪录或者当前状态服务器上文件的历史纪录或者当前状态1.4 CVS的基本概念的基本概念nrepository仓库：仓库：用用于于存存放放版版本本控控制制下下的的所所有有目目录录和和所所有有各各种种版版本本的的文文件件；CVS会会完完成成对对repository的查询和更新。的查询和更新。数数据据

7、如如何何存存放放在在repository中中：随随着着CVS版版本本的的不不同同，存存放放结结构构会会发发生生变化，一般情况下用户无需了解数据到底是如何存放的。变化，一般情况下用户无需了解数据到底是如何存放的。nModul：一个目录层。一个软件工程通常作为单个的模块存放在库中。：一个目录层。一个软件工程通常作为单个的模块存放在库中。ncheckout：描述将某个模块从库中首次导出。描述将某个模块从库中首次导出。nCommit：将你对文件的修改提交到库中。（相当于将你对文件的修改提交到库中。（相当于VSS中的中的checkin）nTimestamp:CVS自动给文件添加的日期标志，自动给文件添加

8、的日期标志，格式形如：格式形如：Fir Dec 20 06:18:48nrevision：文文件件的的版版本本。形形如如1.1，1.2.1，一一般般1.1是是该该文文件件的的第第一一个个revision，后面的一个将自动增加最右面的一个整数。，后面的一个将自动增加最右面的一个整数。1.4 CVS的基本概念的基本概念nbranch：分分支支是是出出于于软软件件版版本本的的稳稳定定性性和和开开发发的的延延续续性性考考虑虑的的，当当我我们们在在原原来来的的版版本本基基础础上上需需要要创创建建另另外外一一个个版版本本（项项目目）时时，可可创创建建一一个个分分支支，分分支支跟跟主主版版本本可可独独立立开

9、开发发，又又可可以以相相互互合合并并。一一般般是是有有个个发发布布版版v1.0，在在开开发发v1.2的的基基础础上上，同同时时又又在在修修改改v1.0，这这时时就就可可以以创创建建分分支支，不不同同分分支支也也可可以互相合并。以互相合并。ntag：tag顾顾名名思思义义就就是是做做个个标标签签，如如张张三三的的文文件件，他他就就可可以以做做个个标标签签为为张张三三以以表表明明是是他他的的文文件件。Tag只只是是在在文文件件上上做做了了一一个个标标签签，并并没没有有创创建建不不同同的的文文件件。通通常常不不需需要要对对某某一一个个孤孤立立的的文文件件作作tag，而而是是对对所所有有文文件件同同时

10、时作作一一个个tag，以以后后用用户户可可以以仅仅向向特特定定tag的的文文件件提提交交或或者者checkout。另另外外一一个个作作用用是是在在发发布布软软件件的的时时候候表表示示哪哪些些文文件件及及其其哪哪个个版版本本是是可可用用的的；各各文文件件不不同同revision可可以以包包括括在在一一个个tag中中。如如果果命命名名一一个个已已存存在在的的tag,，默默认认将将不不会会覆盖原来的。覆盖原来的。nconflict：完完全全是是纯纯文文本本的的冲冲突突，不不包包含含逻逻辑辑上上的的矛矛盾盾。冲冲突突的的产产生生是是在在多多人人对对同同一一文文件件的的修修改改的的时时候候，不不同同的的

11、人人对对此此文文件件的的同同一一地地方方做做了了修修改改，这这个个时时候候CVS以以文文本本的的形形式式给给出出了了冲冲突突的的地地方方，至至于于如如何何处处理理，CVS给给出出引引导，最终靠用户决定如何解决。导，最终靠用户决定如何解决。1.5 CVS中的指示符含义中的指示符含义nU file 形如形如“U file”的行表示文件已被更新为源代码树仓库中最新版本。这一操作的行表示文件已被更新为源代码树仓库中最新版本。这一操作适用于本地工作目录中不存在但源代码树仓库中却存在的文件；或是本地适用于本地工作目录中不存在但源代码树仓库中却存在的文件；或是本地工作目录中没有修改但却不是源代码树仓库中最新

12、版本的文件。工作目录中没有修改但却不是源代码树仓库中最新版本的文件。nP file 与与“U file”类类似似，但但cvs服服务务器器只只是是提提供供一一个个补补丁丁而而不不是是整整个个文文件件。两两种种操操作的结果是相同的。作的结果是相同的。nA file “A file”表示文件已经被添加到个人的工作拷贝中，但是还未提交到源代码表示文件已经被添加到个人的工作拷贝中，但是还未提交到源代码树仓库中。如果从本地工作目录中删除，将丢失文件。这个指示符提醒你树仓库中。如果从本地工作目录中删除，将丢失文件。这个指示符提醒你对添加的文件进行提交。对添加的文件进行提交。nR file “R file”表

13、表示示文文件件已已经经从从个个人人的的工工作作拷拷贝贝中中删删除除，但但是是还还未未提提交交删删除除操操作作，所所以以该该文文件件还还没没有有从从源源代代码码树树仓仓库库中中删删除除。这这个个指指示示符符提提醒醒你你对对删删除除的的文文件进行提交。件进行提交。1.5 CVS中的指示符含义中的指示符含义nM file “M file”表示文件已经在工作目录中被修改。表示文件已经在工作目录中被修改。M能能够够表表示示你你所所修修改改文文件件的的两两种种情情况况：一一是是源源代代码码树树仓仓库库中中的的文文件件没没有有被被修修改改，还还保保持持在在你你最最后后一一次次更更新新时时的的状状态态；或或是

14、是源源代代码码树树仓仓库库中中的的文文件件已经被修改，但是可以与你本地工作目录上的文件无冲突地成功合并。已经被修改，但是可以与你本地工作目录上的文件无冲突地成功合并。nC file “C file”表表示示合合并并本本地地修修改改和和源源代代码码树树修修改改时时有有冲冲突突发发生生。file（本本地地工工作作目目录录上上的的备备份份）现现在在是是试试图图合合并并两两个个版版本本的的结结果果；未未修修改改的的文文件件备备份份被被标标记记为为.#file.revison，也也保保存存在在本本地地的的工工作作目目录录上上，这这个个版版本本是是你你所所修修改改文文件件的的初初始始版版本本。（在在有有些

15、些系系统统中中，以以.#开开头头的的文文件件如如果果有有一一段段时时间间没没有有被被访访问问的的话话会会被被自自动动清清除除。所所以以假假如如你你想想保保存存初初始始文文件件的的备备份份，最最好好的的办办法就是重命名）。法就是重命名）。n?file “?file”表表示示file仅仅存存在在于于本本地地工工作作目目录录中中，不不与与源源代代码码树树仓仓库库中中的的任任何文件相对应，不受何文件相对应，不受cvs的控制。的控制。1.6 CVS中的配置中的配置1.7 CVS中的上传中的上传(Import)1.8 CVS中的下载中的下载(CheckOut)1.9 CVS中的提交中的提交(CheckIn

16、)1.10 CVS中的文件比较中的文件比较二、代码的审查规范二、代码的审查规范2.1 代码审查规范：代码审查规范：岗位与职责岗位与职责 n 代码提交人代码提交人(1)完成阶段性的编码工作。完成阶段性的编码工作。(2)预提交代码必须是在当前最新的环境下完成。预提交代码必须是在当前最新的环境下完成。(3)预提交代码必须符合公司编码规范。预提交代码必须符合公司编码规范。(4)预提交代码必须确保编译通过。预提交代码必须确保编译通过。(5)必须在自己的个人建造版本上进行测试，保证测试用例全部通过。必须在自己的个人建造版本上进行测试，保证测试用例全部通过。(6)保证保证CheckIn操作的正确性，不能遗漏

17、文件或其他错误操作。操作的正确性，不能遗漏文件或其他错误操作。2.1 代码审查规范：代码审查规范：岗位与职责岗位与职责 n 代码审查人代码审查人(review)(1)负责对代码做负责对代码做Code Review。(2)保证预提交代码的质量和功能正确性。保证预提交代码的质量和功能正确性。(3)指导监督新员工前三次指导监督新员工前三次CheckIn操作，保证新员工操作，保证新员工CheckIn操作的操作的正确性正确性,CheckIn mail发送的正确性。发送的正确性。(4)需要提前确定项目模块的负责人，需要提前确定项目模块的负责人，code review必须有模块负责人必须有模块负责人参加。参

18、加。2.2 代码审查规范：代码审查规范：CheckIn nCheckIn的含义的含义 对对数数据据库库中中现现有有的的程程序序代代码码进进行行修修改改（包包括括修修改改，添添加加，删删除除等等操操作作），要把自己的修改提交到数据库的操作，我们称之为要把自己的修改提交到数据库的操作，我们称之为CheckIn。nCheckIn操作的步骤操作的步骤(1)若若在在本本地地目目录录新新增增（删删除除）文文件件，第第一一时时间间在在Wincvs(或或SourceSafe，暂暂以以Wincvs说明说明)上上Add selected（Remove selected）。）。(2)编写代码，修改其他文件。编写代码

19、，修改其他文件。(3)Update和和merge新的代码。新的代码。(4)运行编译检查运行编译检查,并确保全部编译通过。并确保全部编译通过。(5)进行测试，保证测试用例全部通过。进行测试，保证测试用例全部通过。(6)代代码码审审查查（Code Review）：必必须须找找相相应应的的code review负负责责人人做做代代码码审审查查工作，工作，code reviewer可借助代码风格整理工具检查代码风格。可借助代码风格整理工具检查代码风格。(7)ChecekIn代码，代码，commit提交。提交。(8)填写发送填写发送CheckIn mail，通知所有开发人员本次，通知所有开发人员本次Ch

20、eckIn的内容、意义。的内容、意义。(9)新新员员工工的的前前三三次次CheckIn都都要要在在review人人员员的的监监督督下下操操作作，避避免免出出现现不不必必要要的错误。的错误。2.2 代码审查规范代码审查规范nCheckIn mail发送发送 在在CVS执执行行CheckIn操操作作之之后后，要要登登录录“软软件件工工程程管管理理系系统统”，进进入入相应的页面填写相应的页面填写CheckIn mail。具体步骤如下：。具体步骤如下：(1)进进入入软软件件工工程程管管理理系系统统后后系系统统会会自自动动提提示示有有代代码码Checkin，确确认认要要填填写写(有时可以多次有时可以多次

21、Checkin后再统一发后再统一发Email，这时可以暂时不用填写，这时可以暂时不用填写)。(2)选择选择CheckIn代码或文档所属的项目和任务。代码或文档所属的项目和任务。(3)选择或填写选择或填写Checkin的类型，添加代码、或修复的类型，添加代码、或修复BUG等。等。(4)进入进入CheckIn mail的页面，按照其规定格式填写即可。的页面，按照其规定格式填写即可。(5)填填写写完完毕毕后后，点点击击“提提交交CheckIn记记录录”，系系统统会会自自动动将将此此CheckIn记记录的内容录的内容email给相关人员。给相关人员。2.2 代码审查规范代码审查规范nCheckIn 的

22、重要性的重要性(1)将将自自己己修修改改的的代代码码保保存存到到服服务务器器的的数数据据库库上上，这这样样可可以以保保证证数数据据不不会会丢丢失。失。(2)更更新新了了数数据据库库，可可以以使使其其他他人人获获取取自自己己修修改改后后的的程程序序代代码码，保保证证了了工工作作上的协调一致。上的协调一致。(3)软软件件项项目目的的所所有有源源代代码码、测测试试代代码码、说说明明文文档档等等，就就是是由由这这一一次次次次的的CheckIn构构建建起起来来的的。每每一一个个CheckIn，都都清清楚楚的的显显示示着着大大家家的的工工作作情情况，工作内容和结果。况，工作内容和结果。2.2 代码审查规范

23、代码审查规范nCheckIn 的注意事项的注意事项(1)任任何何人人在在修修改改代代码码后后，都都要要经经过过Code Review，才才能能够够CheckIn代代码码，这这样样可可以以保保证证代代码码的的质质量量。千千万万不不要要存存在在侥侥幸幸心心理理，认认为为自自己己的的改改动动无无关关紧紧要要，没没有有经经过过别别人人Code Review，就就CheckIn。要要知知道道，每每一一个个细细小小的的错错误误，都都有有可可能能造造成成不不可可预预期期的的严严重重后后果果。一一次次错错误误的的修修改改，可可能能会会把把源源代代码树放倒，将影响到所有人的正常工作。码树放倒，将影响到所有人的正

24、常工作。(2)修修改改后后的的代代码码，要要尽尽快快CheckIn，不不可可拖拖得得时时间间太太长长。当当自自己己checkin之之前前，别别人人又又有有CheckIn时时，需需要要重重新新获获取取服服务务器器上上的的代代码码（UpDate），如如果果有有冲突需进行冲突需进行merge，然后重新做，然后重新做checkin前的检查，避免产生错误。前的检查，避免产生错误。(3)不允许在源代码冻结时或者系统夜间做自动测试或自动备份时不允许在源代码冻结时或者系统夜间做自动测试或自动备份时CheckIn。(4)每每次次CheckIn之之后后必必须须及及时时填填写写CheckIn mail。要要让让别别

25、人人知知道道自自己己都都做做了了什么事情，这也是考核评定的重要组成部分。什么事情，这也是考核评定的重要组成部分。(5)CheckIn记记录录不不允允许许是是修修复复Bug的的工工作作，必必须须先先有有Bug号号，才才有有BugFix(BUG修复修复)记录。发现的记录。发现的Bug必须录入到必须录入到Bug系统。系统。2.3 代码审查准则代码审查准则Code Review的目的的目的n凡事知其然还要知其所以然，我们首先需要知道什么是凡事知其然还要知其所以然，我们首先需要知道什么是Code Review和我和我们使用它的目的是什么。们使用它的目的是什么。nCode Review是一种用来确认方案设

26、计和代码实现的质量保证机制，通过是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码，测试过程和注释进行检查。这个机制我们可以对代码，测试过程和注释进行检查。Code Review主要主要用来在软件工程中改进代码质量，通过用来在软件工程中改进代码质量，通过Code Review可以达到如下目的：可以达到如下目的：在项目早期就能够发现代码中的在项目早期就能够发现代码中的BUG。帮助初级开发人员学习高级开发人员的经验，达到知识共享。帮助初级开发人员学习高级开发人员的经验，达到知识共享。避免开发人员犯一些很常见，很普通的错误。避免开发人员犯一些很常见，很普通的错误。保证项目组人

27、员的良好沟通。保证项目组人员的良好沟通。项目或产品的代码更容易维护。项目或产品的代码更容易维护。2.3 代码审查准则代码审查准则Code Review的前提的前提n(1)Code Review人员要理解人员要理解Code Review的概念。的概念。n(2)代码是否已经正确的代码是否已经正确的build。n(3)代码执行时功能是否正确。代码执行时功能是否正确。n(4)Review人员是否理解了代码。人员是否理解了代码。n(5)开发人员是否对代码做了单元测试。开发人员是否对代码做了单元测试。2.4 代码审查内容代码审查内容(1)完整性检查（完整性检查（Completeness）代码是否完全实现了

28、设计文档中提出的功能需代码是否完全实现了设计文档中提出的功能需代码是否已按照设计文档进行了集成和代码是否已按照设计文档进行了集成和Debug代码是否已创建了需要的数据库，包括正确的初始化数据代码是否已创建了需要的数据库，包括正确的初始化数据代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型(2)一致性检查（一致性检查（Consistency）代码的逻辑是否符合设计文档代码的逻辑是否符合设计文档代码中使用的格式、符号、结构等风格是否保持一致代码中使用的格式、符号、结构等风格是否保持一致2.4 代码审查内容代码审查内容(3)正确

29、性检查（正确性检查（Correctness）代码是否符合制定的标准代码是否符合制定的标准所有的变量都被正确定义和使用所有的变量都被正确定义和使用所有的注释都是准确的所有的注释都是准确的所有的程序调用都使用了正确的参数个数所有的程序调用都使用了正确的参数个数(4)可修改性检查（可修改性检查（Modifiability）代码涉及到的常量是否易于修改（如使用配置、定义为类常量、使用专代码涉及到的常量是否易于修改（如使用配置、定义为类常量、使用专门的常量类等）门的常量类等）代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行

30、访问的量进行访问的代码是否只有一个出口和一个入口（严重的异常处理除外）代码是否只有一个出口和一个入口（严重的异常处理除外）2.4 代码审查内容代码审查内容(5)可预测性检查（可预测性检查（Predictability）代码所用的开发语言是否具有定义良好的语法和语义代码所用的开发语言是否具有定义良好的语法和语义是否代码避免了依赖于开发语言缺省提供的功能是否代码避免了依赖于开发语言缺省提供的功能代码是否无意中陷入了死循环代码是否无意中陷入了死循环代码是否是否避免了无穷递归代码是否是否避免了无穷递归(6)健壮性检查（健壮性检查（Robustness）代代码码是是否否采采取取措措施施避避免免运运行行时

31、时错错误误（如如数数组组边边界界溢溢出出、被被零零除除、值值越越界、堆栈溢出等）界、堆栈溢出等）(7)结构性检查（结构性检查（Structuredness）程序的每个功能是否都作为一个可辩识的代码块存在程序的每个功能是否都作为一个可辩识的代码块存在循环是否只有一个入口循环是否只有一个入口2.4 代码审查内容代码审查内容(8)可追溯性检查（可追溯性检查（Traceability）代码是否对每个程序进行了唯一标识代码是否对每个程序进行了唯一标识是否有一个交叉引用的框架可以用来在代码和开发文档之间相互对应是否有一个交叉引用的框架可以用来在代码和开发文档之间相互对应代码是否包括一个修订历史记录，记录中

32、对代码的修改和原因都有记录代码是否包括一个修订历史记录，记录中对代码的修改和原因都有记录是否所有的安全功能都有标识是否所有的安全功能都有标识(9)可理解性检查（可理解性检查（Understandability）注释是否足够清晰的描述每个子程序注释是否足够清晰的描述每个子程序是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度是否在定义命名规则时采用了便于记忆，反映类型等方法是否在定义命名规则时采用了便于记忆，反映

33、类型等方法每个变量都定义了合法的取值范围每个变量都定义了合法的取值范围代码中的算法是否符合开发文档中描述的数学模型代码中的算法是否符合开发文档中描述的数学模型(10)可验证性检查（可验证性检查（Verifiability）代码中的实现技术是否便于测试代码中的实现技术是否便于测试2.5 代码审查代码审查:Code Review经验检查项经验检查项(1)面向对象设计方面检查项面向对象设计方面检查项类设计和抽象是否合适类设计和抽象是否合适是否符合面向接口编程的思想是否符合面向接口编程的思想是否采用合适的设计范式是否采用合适的设计范式这几点的范围都很大，在此不展开讨论，有专门的书籍介绍这方面问题，这几

34、点的范围都很大，在此不展开讨论，有专门的书籍介绍这方面问题，而在而在Code Review中主要靠经验来判断。中主要靠经验来判断。(2)性能方面检查项性能方面检查项 n性能检查在大多数代码中都是需要严重关注的方面，也是最容易出现问性能检查在大多数代码中都是需要严重关注的方面，也是最容易出现问题的方面，常常有程序员写出了功能和语法没有丝毫问题的代码后，正题的方面，常常有程序员写出了功能和语法没有丝毫问题的代码后，正式运行时却在性能上表现不佳，从而不得不做大量的返工，甚至是推倒式运行时却在性能上表现不佳，从而不得不做大量的返工，甚至是推倒重来。重来。性能检查的具体细节如下：2.5 代码审查代码审查

35、:Code Review经验检查项经验检查项 n性能方面检查的具体细节项目性能方面检查的具体细节项目 n在在海海量量数数据据出出现现时时、队队列列、表表、文文件件、在在传传输输、upload等等方方面面是是否否会会出出现现问题，有无控制，如分配的内存块大小，队列长度等控制参数问题，有无控制，如分配的内存块大小，队列长度等控制参数对对hashtable，vector等等集集合合类类数数据据结结构构的的选选择择和和设设置置是是否否合合适适，如如正正确确设置设置capacity，load factor等参数，数据结构的是否是同步的等参数，数据结构的是否是同步的有无滥用有无滥用String对象的现象对

36、象的现象是否采用通用的线程池、对象池模块等是否采用通用的线程池、对象池模块等cache技术以提高性能技术以提高性能类的接口是否定义良好，如参数类型等，避免内部转换类的接口是否定义良好，如参数类型等，避免内部转换是否采用内存或硬盘缓冲机制以提高效率是否采用内存或硬盘缓冲机制以提高效率并发访问时的应对策略并发访问时的应对策略I/O方方面面是是否否使使用用了了合合适适的的类类或或采采用用良良好好的的方方法法以以提提高高性性能能（如如减减少少序序列列化化，使用使用buffer类封装流等）类封装流等）同步方法的使用是否得当，是否过度使用同步方法的使用是否得当，是否过度使用递归方法中的叠代次数是否合适，应

37、该保证在合理的栈空间范围内递归方法中的叠代次数是否合适，应该保证在合理的栈空间范围内如果调用了阻塞方法，是否考虑了保证性能的措施如果调用了阻塞方法，是否考虑了保证性能的措施避免过度优化，对性能要求高的代码是否使用相关工具等避免过度优化，对性能要求高的代码是否使用相关工具等2.5 代码审查代码审查:Code Review经验检查项经验检查项(3)资源泄漏处理方面检查项资源泄漏处理方面检查项 对对于于C#.Net和和JAVA程程序序来来讲讲，由由于于存存在在垃垃圾圾收收集集机机制制，所所以以内内存存泄泄漏漏不不是是太太明明显显，但但使使用用不不当当，仍仍然然存存在在内内存存泄泄漏漏的的问问题题。而

38、而对对于于其其它它的的语语言言，如如C+等等在在这这方方面面就就要要严严重重关关注注了了。当当然然数数据据库库连连接接资资源源不不释释放放的的问题也是广大程序员最常见的。问题也是广大程序员最常见的。分配的内存是否释放，尤其在错误处理路径上（对非分配的内存是否释放，尤其在错误处理路径上（对非C#与与JAVA类）类）错误发生时是否所有的对象被释放，如数据库连接、错误发生时是否所有的对象被释放，如数据库连接、Socket、文件等、文件等是否同一个对象被释放多次（对非是否同一个对象被释放多次（对非C#与与JAVA类）类）代码是否保存准确的对象代码是否保存准确的对象reference计数（对非计数（对非

39、C#与与JAVA类）类）2.5 代码审查代码审查:Code Review经验检查项经验检查项(4)线程安全方面检查项线程安全方面检查项 线线程程安安全全问问题题实实际际涉涉及及两两个个方方面面，一一个个是是性性能能，另另一一个个是是资资源源的的一一致致性性，我们需要在这两方面做个权衡，现在就是到了权衡利弊的时候了。我们需要在这两方面做个权衡，现在就是到了权衡利弊的时候了。代码中所有的全局变量是否是线程安全的代码中所有的全局变量是否是线程安全的需要被多个线程访问的对象是否线程安全，检查有无通过同步方法保护需要被多个线程访问的对象是否线程安全，检查有无通过同步方法保护同同步步对对象象上上的的锁锁是

40、是否否按按相相同同的的顺顺序序获获得得和和释释放放以以避避免免死死锁锁，注注意意错错误误处处理代码理代码是是否否存存在在可可能能的的死死锁锁或或是是竞竞争争，当当用用到到多多个个锁锁时时，避避免免出出现现类类似似情情况况：线程线程A获得锁获得锁1，然后锁，然后锁2，线程，线程B获得锁获得锁2，然后锁，然后锁1在保证线程安全的同时，要注意避免过度使用同步，导致性能降低在保证线程安全的同时，要注意避免过度使用同步，导致性能降低2.5 代码审查代码审查:Code Review经验检查项经验检查项(5)程序流程方面检查项程序流程方面检查项 循环结束条件是否准确循环结束条件是否准确是否避免了死循环的产生

41、是否避免了死循环的产生对循环的处理是否合适，如循环变量，局部对象，循环次数等能够考虑对循环的处理是否合适，如循环变量，局部对象，循环次数等能够考虑到性能方面的影响到性能方面的影响(6)数据库处理方面数据库处理方面 数据库设计或数据库设计或SQL语句是否便于移植（注意和性能方面会存在冲突）语句是否便于移植（注意和性能方面会存在冲突）数据库资源是否正常关闭和释放数据库资源是否正常关闭和释放 数据库访问模块是否正确封装，便于管理和提高性能数据库访问模块是否正确封装，便于管理和提高性能 是否采用合适的事务隔离级别是否采用合适的事务隔离级别 是否采用存储过程以提高性能是否采用存储过程以提高性能 是否采用

42、是否采用PreparedStatement以提高性能以提高性能2.5 代码审查代码审查:Code Review经验检查项经验检查项(7)通讯方面检查项通讯方面检查项 socket通讯是否存在长期阻塞问题通讯是否存在长期阻塞问题发送接收的数据流是否采用缓冲机制发送接收的数据流是否采用缓冲机制socket超时处理，异常处理超时处理，异常处理数据传输的流量控制问题数据传输的流量控制问题(8)对象处理方面检查项对象处理方面检查项 对象生命周期的处理，是否对象的对象生命周期的处理，是否对象的reference已经失效，能够设置为已经失效，能够设置为null，并被回收，并被回收在对象的传值和传参方面有无问

43、题，对象的在对象的传值和传参方面有无问题，对象的clone方法使用是否过度方法使用是否过度是否大量经常的创建临时对象是否大量经常的创建临时对象是否尽量使用局部对象（堆栈对象）是否尽量使用局部对象（堆栈对象）在只需要对象在只需要对象reference的地方是否创建了新的对象实例的地方是否创建了新的对象实例2.5 代码审查代码审查:Code Review经验检查项经验检查项(9)异常处理方面检查项异常处理方面检查项 每次当方法返回时是否正确处理了异常，如最简单的处理，记录日志到日志每次当方法返回时是否正确处理了异常，如最简单的处理，记录日志到日志文件中文件中是否对数据的值和范围是否合法进行校验，包

44、括采用断言（是否对数据的值和范围是否合法进行校验，包括采用断言（assertion）在出错路径上是否所有的资源和内存都已经释放在出错路径上是否所有的资源和内存都已经释放所有抛出的异常都得到正确的处理，特别是对子方法抛出的异常，在整个调所有抛出的异常都得到正确的处理，特别是对子方法抛出的异常，在整个调用栈中必须能够被捕捉并处理用栈中必须能够被捕捉并处理当调用导致错误发生时，方法的调用者应该得到一个通知当调用导致错误发生时，方法的调用者应该得到一个通知不要忘了对错误处理部分的代码进行测试，很多代码在正常情况下执行良好，不要忘了对错误处理部分的代码进行测试，很多代码在正常情况下执行良好，而一旦出错，

45、整个系统就崩溃了而一旦出错，整个系统就崩溃了2.5 代码审查代码审查:Code Review经验检查项经验检查项(10)方法（函数）方面检查项方法（函数）方面检查项 方法的参数是否都做了校验方法的参数是否都做了校验数组类结构是否做了边界校验数组类结构是否做了边界校验变量在使用前是否做了初始化变量在使用前是否做了初始化返回堆对象的返回堆对象的reference，不要返回栈对象的，不要返回栈对象的reference方法方法API是否被良好定义，即是否尽量面向接口编程，便于维护和重构是否被良好定义，即是否尽量面向接口编程，便于维护和重构(11)安全方面检查项安全方面检查项对命令行执行的代码，需要详细

46、检查命令行参数对命令行执行的代码，需要详细检查命令行参数WEB类程序检查是否对访问参数进行合法性验证类程序检查是否对访问参数进行合法性验证重要信息的保存是否选用合适的加密算法重要信息的保存是否选用合适的加密算法通讯时考虑是否选用安全的通讯方式通讯时考虑是否选用安全的通讯方式(12)其他其他 日志是否正常输出和控制日志是否正常输出和控制配置信息如何获得，是否有硬编码配置信息如何获得，是否有硬编码 三、软件项目的测试三、软件项目的测试软件测试所包含的内容软件测试所包含的内容n软件质量与测试软件质量与测试n软件测试的概念软件测试的概念n软件测试原则与策略软件测试原则与策略n软件测试完成的标准软件测试

47、完成的标准n软件测试步骤软件测试步骤n软件测试工作流程软件测试工作流程n软件测试的自动化软件测试的自动化 3.1 3.1 软件质量与测试软件质量与测试软件质量模型软件质量模型产品产品修改修改产品产品升级升级产品运行产品运行正确性、可靠性、高效性、易用性、完整性正确性、可靠性、高效性、易用性、完整性可维护性可维护性灵活性灵活性可测试性可测试性可移植性可移植性可重用性可重用性互操作性互操作性软件质量模型软件质量模型是否测试直接影响软件质量是否测试直接影响软件质量APCD检查执行经验教训遗留问题问题原因主要原因 计划ISO质量管理的PDCA循环图 测试过程影响质量测试过程影响质量个人对个人对PDCA

48、PDCA的新解的新解nP(Process)：从从过过程程做做起起。从从生生产产管管理理的的各各个个流流程程做做起起，把把控控好好市市场场信信息息、工工程程实实施施、质质量量检检查查、数数据据安安全全、技技术术方方向向等等各各个个环环节节。另另外外，P还还可可以以代代表表生生产、产品产、产品(Production)的意思。的意思。nD(Document)：从从文文档档做做起起。质质量量管管理理体体系系的的重重要要内内容容是是文文书书与与记记录录的的规规范范化化，人人员员管管理理、文文件件传传达达、项项目目规规范范、计计划划检检查查等等等等，都都要要求求采采用用标标准准的的文文档档格格式式进进行行

49、管管理理。需需要要特特别别指指出出的的一一点点是是：这这个个的的文文档档不不仅仅仅仅是是纸纸质质文文档档，也也包包括括电电子文档，纸质和电脑仅是保存介质的不同，但是都要求规范化的管理。子文档，纸质和电脑仅是保存介质的不同，但是都要求规范化的管理。nC(Cell)：从从细细节节做做起起。Cell本本义义是是细细胞胞，这这里里引引申申为为细细节节、细细小小、微微小小的的含含义义。统统计计数数据据表表明明每每个个重重大大质质量量事事故故的的发发生生约约有有29件件小小的的事事件件发发生生，每每见见小小事事件件的的发展约有发展约有10此微小的征兆出现，因此要注意从微小做起来保证产品质量。此微小的征兆出

50、现，因此要注意从微小做起来保证产品质量。nA(All)：从从全全员员做做起起。产产品品的的质质量量是是公公司司的的生生命命线线，但但是是要要保保证证产产品品的的质质量量就就需需要要提提高高公公司司的的整整体体质质量量。公公司司的的整整体体质质量量不不仅仅仅仅指指产产品品的的质质量量，还还包包含含经经营营者者、经经营营方方法法、工工作作方方法法、人人才才员员工工、管管理理服服务务等等多多个个方方面面的的质质量量。无无论论干干部部领导还是普通工人，都要时刻有质量管理的意识。领导还是普通工人，都要时刻有质量管理的意识。软件人员要注重软件的测试，以提高软件的可靠性、可用性等。软件人员要注重软件的测试，