检查问题报告

开篇：写作不仅是一种记录，更是一种创造，它让我们能够捕捉那些稍纵即逝的灵感，将它们永久地定格在纸上。下面是小编精心整理的12篇检查问题报告，希望这些内容能成为您创作过程中的良师益友，陪伴您不断探索和进步。

第1篇

关键词：软件代码审查；代码审查过程；代码审查问题

中图分类号：TP311.52文献标识码：A文章编号：1007-9599 (2012) 03-0000-02

Discussion on the Code Review of Software Static Testing

Yuan Zhengjiang

(Jiangnan Institute of Electrical and Mechanical Design,Guiyang550009,China)

Abstract:This paper describes the software code to examine the role,content,code review process,and lists some common problems of code review.

Keywords:Software code review;Code review process;Code review problem

一、引言

软件测试常用方法可分为动态测试和静态测试，只有动态测试和静态测试有效结合，才能更好的完成软件测试工作。代码审查是软件静态测试中常用的软件测试方法之一，代码审查时，只要测试人员方法得当、足够细心，往往能够产生意想不到的效果。

二、代码审查的作用

代码审查是在不执行软件的条件下有条理的仔细审查软件代码，从而找出软件缺陷的过程。

代码审查可以找出动态测试难以发现或隔离的软件缺陷。在开发过程初期让测试人员集中精力进行软件代码审查非常有价值：可以提高代码质量；在项目的早期发现缺陷，将损失降至最低；促进团队沟通、促进知识共享、共同提高。

代码审查还可以为动态测试时设计和执行测试用例提供思路。通过代码审查，可以确定有问题或者容易产生软件缺陷的特性范围。

三、代码审查的过程

代码审查过程可分为：代码审查策划阶段、代码审查实施阶段以及代码审查总结阶段。

（一）代码审查策划阶段

1.项目负责人分配代码审查任务；

2.确定代码审查策略：依据软件开发文档，确定软件关键模块，作为代码审点；将复杂度高的模块也作为代码审查的重点；

3.项目负责人确定代码审查单，审查内容一般可包括：

（1）可追溯性：

――代码是否遵循详细设计？

――代码是否与需求一致？

（2）逻辑：

――表示优先级的括号用法是否正确？

――代码是否依赖赋值顺序？

――“if…else”和“switch”使用是否正确清晰？

――循环能否结束？

――复合语句是否正确地被花括号括起来？

――case语句是否所有可能出现的情况均已考虑？

――“goto”是否使用？

（3）数据：

――变量在使用前是否已初始化？

――变量的声明是否按组划分为外部的和内部的？

――除最明显的声明外，是否所有声明都有注释？

――每个命名是否仅用于一个用途？

――常量名是否都大写？

――常量是否都是通过“#define”定义的？

――用于多个文件中的常量是否在一个头文件中定义？

――头文件中是否存在可执行的代码？

――定义为指针的变量是否作为指针使用（而不是作为整数）？

――指针是否初始化？

――释放内存后是否将指针立即设置为NULL（或0）？

――传递指针到另一个函数的代码是否首先检查了指针的有效性？

――通过指针写入动态分配内存的代码是否首先检查了指针的有效性？

――宏的命名是否都大写？

――数组是否越界？

（4）接口：

――在所有的函数及过程调用中，参数的个数都正确吗？

――形参与实参类型匹配吗？

――参数顺序正确吗？

――如果访问共享内存，是否具有相同的共享内存结构模式？

（5）文档：

――软件文档是否与代码一致？

（6）注释：

――注释与代码是否一致？

――用于理解代码的注释是否提供了必要的信息？

――是否对数组和变量的作用进行了描述？

（7）异常处理：

――是否所有可能的错误都已加以考虑？

（8）内存：

――在向动态分配的内存写入之前是否检查了内存申请是否成功？

――若采用动态分配内存，内存空间分配是否正确？

――当内存空间不再需要时，是否被明确的释放？

（9）其它：

――是否检查了函数调用返回值？

――所有的输入变量都用到了吗？

――所有的输出变量在输出前都已赋值了吗？

4.确定代码审查进度安排，项目负责人负责安排代码审查的进度。

（二）代码审查实施阶段

1.代码讲解：软件开发人员详细向测试人员讲解如何以及为何这样实现，测试人员提出问题和建议。通过代码讲解，测试人员对被审查的软件有了一个全面的认识，为后续代码审查打下良好的基础。

2.静态分析：一般采用静态分析工具进行，主要分析软件的代码规模、模块数、模块调用关系、扇入、扇出、圈复杂度、注释率等软件质量度量元。静态分析在代码审查时应优先进行，有利于软件测试人员在后续代码审查时对软件建立宏观上认识，在审查中容易做到有的放矢，更易于发现软件代码中的缺陷。

3.规则检查：采用静态分析工具对源程序进行编码规则检查，对于工具报出的问题再由人工进行进一步的分析以确认软件问题，是一种比较有效的方法。

4.正式代码审查：代码审查可分两步进行：独立审查和会议审查。根据情况，这两步可以反复进行多次。

（1）独立审查：测试人员根据项目负责人的工作分配，独自对自己负责的软件模块进行代码审查。测试人员根据代码审查单，对相关代码进行阅读、理解和分析后，记录发现的错误和疑问。

（2）会议审查：项目负责人主持召开会议，测试人员和开发人员参加；测试人员就独立审查发现的问题和疑问与开发人员沟通，并讨论形成一致意见；对发现的问题汇总，填写软件问题报告单，提交开发人员处理。

5.更改确认：开发人员对问题进行处理，代码审查人员对软件的处理情况进行确认，验证更改的正确性，并防止出现新的问题。

（三）代码审查总结阶段

代码审查工作结束后，项目负责人总结代码审查结果；编写测试报告，对软件代码质量进行评估，给出合理建议。

把代码审查提出的所有问题、亮点及最终结论详细的记录下来，供其他软件项目代码审查借鉴。必要时，可建立常见软件代码缺陷数据库，为软件代码审查人员培训和执行代码审查提供数据支持，也可以为软件编码规则制定规范提供实践依据。

四、代码审查中的常见问题

如果软件测试人员熟悉常见的软件代码审查问题，对代码审查效率是很有帮助的。笔者根据自己的应验，列举部分常见软件代码审查问题如下（仅供参考）：

（1）浮点数相等比较：可能造成程序未按设计的路径执行；

（2）因设计原因导致某些代码不能执行：如逻辑表达式永远为真（或假）造成某分支不能执行、代码前面有return语句、某模块从未被调用等；

（3）switch语句没有break语句（有意如此设计时除外）；

（4）数组越界使用：数组越界容易发生在数组下标是计算得到的情况下，而且审查时很难发现这种代码缺陷，应加以重视；

（5）变量未初始化就使用或者是条件赋值就使用；

（6）程序中存在未使用的多余变量；

（7）复合逻辑表达式没有使用括号造成运算顺序错误；

（8）有返回值的函数中return没有带返回值；

（9）逻辑判别的表达式不是逻辑表达式；

（10）动态分配的内存没有及时释放：忘记写内存释放代码或由于其它逻辑缺陷导致内存释放代码未得到执行；

（11）没有对缓冲区溢出进行必要的防护；

（12）访问空指针，即指针未初始化就使用；

（13）指针指向的内存释放后，未将指针置为NULL：其它函数访问该指针时，判断指针不为空，当作有效指针使用，会造成内存访问错误；

（14）注释说明与程序代码实现不一致，甚至相反；

（15）循环存在不能跳出的可能，程序中没有相应的保护机制。

五、结束语

第2篇

[关键词]项目管理软件需求开发进度成本质量管理模型

一、引言

软件需求开发是软件工程的一个重要环节，在软件生命周期中的需求、设计、编码、测试和维护等各个阶段中，需求开发处于软件工程的开始部分，它提供构建软件项目的根基，决定软件开发成果满足客户需求的匹配程度。软件需求开发环节的失误会随着开发进度的扩大而蔓延，资料表明，软件项目中由于需求开发管理混乱而造成的返工开销几乎占了总开发的50％。本文应用项目管理理论分析软件需求开发阶段的系统构成，并设计管理模型来提高软件需求开发的管理效率。

二、软件需求开发管理过程

由于计算机技术的迅速发展，使得软件需求具有模糊性、不确定性、变化性、主观性等特点，并带来软件需求开发管理的复杂性。软件需求开发是一定的组织利用有限的资源在规定的时间内完成，可以作为项目来进行管理，其管理过程由需求获取、需求分析、编写软件需求规格和需求验证四个阶段构成。

1.需求获取

需求获取是在问题和最终解决方案之间架设桥梁，其主要任务是和用户方的领导层、业务层人员进行沟通，获取用户的具体需求，并了解用户的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等具体情况，同用户建立起良好的沟通渠道和方式。软件需求获取的方法有：与用户交谈，向用户提问题；参观用户的工作流程，观察用户的操作；用户工作的情景分析；现有系统的问题报告和改进要求，事件和响应；市场调查和向用户群体发调查问卷；与同行、专家交谈，听取他们的意见；分析已经存在的同类软件产品，提取需求；从现有产品或竞争产品的文档中提取需求；从行业标准、规则中提取需求；从Internet上搜查相关资料等。

2.需求分析

需求分析主要通过建立业务模型的方式来描述用户的功能需求，为客户、用户、开发方等不同参与者提供一个交流的渠道。业务模型可以映射出软件产品的核心需求，即功能需求。功能需求应描述软件提供的功能和服务、对输入的响应，并描述特定条件下的系统构成等。软件产品本身可能还存在与业务无直接关系的非功能需求，具体与系统的总体特性有关，如可靠性、响应时间、存储空间等。非功能需求定义系统提供服务或功能的约束，包括时间约束、空间约束、开发过程约束及应遵循的标准等。通常这两类需求构成软件需求的总集。

3.编制软件需求规格

软件需求规格的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础，需求分析完成的标志就是提交一份完整的软件需求规格说明书。软件需求规格说明书以一种开发人员可用的技术形式阐述软件必须提供的功能和具备的性能，以及必须考虑的限制条件。软件项目客户通过软件需求规格了解软件项目能够提供的软件产品，检查软件需求是否满足需要；项目管理人员根据软件需求规格制定项目的开发计划和管理过程；软件开发人员通过软件需求规格理解要开发的产品及具体要开发的内容；软件测试人员通过软件需求规格验证软件。

4.需求评审

编写的软件需求规格说明书还应当进行需求评审，确保需求确定的科学性。可采用下列指标进行评审：(1)正确性:每条需求都正确代表构建软件系统所要完成的事情。(2)无歧义:每条需求只有一种解释。(3)完备性:需求不能发生遗漏，应全面考虑相关问题。(4)一致性:用户需求必须和业务需求一致，功能需求必须和用户需求一致。(5)重要性和稳定性分级:现有资源不足以实现所有需求时，可以根据级别的高低决定实现的先后，舍弃一些级别低的需求以保证项目的按期交付。(6)可验证性:需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。(7)可修改性:每一条需求都易于完整一致的进行变更，且不改变需求集的结构和风格。(8)可跟踪性:每条需求都是可溯源的，且存在一种机制使得在以后的工作中引用需求是可行的。(9)可理解性:用户和开发人员都完全理解需求集的整体行为、所提供的功能及其中的每条需求的含义。

三、软件需求开发管理模型

1.软件需求开发管理模型构建原则

软件需求开发是一项复杂的系统工程，管理模型的构建应遵循下列原则:(1)程序性原则：软件需求开发管理应遵循固定的业务流程，可将其划分为需求获取、需求分析、编写软件需求规格和需求验证四个阶段，前一阶段的工作完成后才能进入下一阶段。(2)系统性原则：软件需求开发要在限定的时间、成本条件约束下达到一定的质量，实现软件系统的最优，要求管理遵循系统管理原则，实现目标最优。(3)简化性原则：化繁为简，将模糊的、潜在的复杂问题明确化，以图表的形式表示出，并以简化的解决方案解决问题，便于项目管理。(4)平衡性原则：管理软件需求开发的具体事务要有一定的侧重。对于需求开发过程事项，应根据影响大小分清主次，关键的事项或者事项里的某个多发问题点，着重管理，达到在管理上的主次平衡。(5)高效性原则:模型的设计必须以促进需求开发目标的实现为前提，提供给相关人员一个展示需求开发管理和有效解决方案的平台。（6）时时控制性原则:及时控制需求开发过程中影响进度、成本、质量等问题，及时发现解决冲突事件，做到事前、事中、事后控制，保证项目按时保质保量完成。(7)动态性原则:开发中应关注信息技术的发展，将先进的技术应用到软件需求开发中，并学习借鉴相关软件需求开发的成果。

2．软件需求开发管理模型

基于以上分析，本文构建了软件需求开发管理模型，见下图：

该模型遵循了软件需求开发的管理流程。启动阶段，软件开发进行了可行性研究，软件项目已立项，项目正式启动。软件需求开发管理阶段是模型的主要部分，按照项目流程，依次划分为需求获取、需求分析、编写软件需求规格和需求验证四个阶段。总结阶段，对软件需求开发管理进行总结，并进入到软件程序设计阶段。模型的核心部分是应用项目管理的进度管理、成本管理、质量管理，对软件需求开发进行动态管理。进度管理就是制定出经济合理的进度计划，然后在计划执行过程中，检查实际进度与计划进度之间的差异，并及时找出出现差异的原因，采取有效的补救措施，以确保项目按时按质完成。进度管理应加强沟通，掌握可能延误进度的环节，并严格控制进度变更。成本管理就是对项目所需的成本情况进行详细地分析和估算，编制资源需求计划，并编制项目所需的成本估算和预算，在执行过程中，采取相应的措施对项目成本进行控制。成本管理应严格控制加班、浪费等额外支出。质量管理是为了保证项目的可交付成果能够满足客户的需求，围绕项目质量而进行的计划、协调和控制等活动，其具体内容涉及质量规划、实施质量保证和质量控制。通过进度管理、成本管理和质量管理，使软件需求开发成为进度快、成本低和质量合格的有机统一体。

该模型规范了软件需求开发的业务流程，并在整个软件需求开发的不同环节之间建立联系，明确需求开发过程与自身各任务项之间以及项目其余环节所存在的各种联系。模型各环节间的相关性、可追溯性保证了软件项目需求开发过程，可以遵循统一的管理模式。该模型具备可配置性。每个软件项目，都具有个性化管理需求，在进度管理、成本管理、质量管理等方面有不同的要求，可以针对具体的开发团队，项目要求，管理侧重点，扩增相应的管理模块，将此模型推广到任何一个软件需求开发项目。

3.模型应用

由于软件需求开发具有复杂性，其主要表现为需求描述问题，明确表达需求较难确定，并且难以统一；需求完备问题，需求没有遗漏，难以准确划定系统范围；需求的变更问题，需求变化是永恒，需求不可能是完备。模型应用需做好以下工作：（1）文档化管理。需求必须有文档来记录，该文档必须是正确的，是经过验证的，是在受控的状态下变更的。开发或管理人员常常会在含糊的情况下把认为是相对简单的需求忽视而省略文档记录，其实未必简单，只有想清楚、写清楚、说清楚才说明已经真正把需求整理清楚了，同时方便日后维护工作的展开。需求含糊的情况下要进行会议形式处理，并邀请相关人员参加进行需求澄清及确定，需求在进行多方确定后进行归档。同时软件需求的复用率也是相当高的，可以避免升级时重新将需求再次获取，只需要在原来的基础上作为文挡需求复用升级处理。（2）审核评估需求变更，减少变更的影响。在管理软件开发过程中，需求渐变是必然的，无论需求变化的程度如何，只要需求变更就必须进行评估。在需求变更之前必须由项目管理人员审核，再传给开发人员进行评估等工作。管理人员必需依据对整套系统的了解程度分析需求变更过程中可能受影响的系统及受关联的功能模块，并制定积极应对措施。(3)整体管理。应识别、确定、结合、统一与协调软件需求开发管理过程中所需要进行的各种过程和活动，保证进度、成本、质量等各要素的相互协调。

四、结语

软件需求开发在软件项目管理中具有重要地位。本文应用项目管理理论，设计了软件需求开发管理模型。该模型遵循项目管理流程，将软件需求开发划分启动、需求开发过程、总结三个阶段，并将软件需求开发过程划分为需求获取、需求分析、编写软件需求规格和需求验证四个阶段，模型应用项目管理的进度管理、成本管理、质量管理，对软件需求开发进行动态管理，实现软件需求开发项目目标最优。该模型能够提高软件需求开发管理效率，确保软件开发能够按进度，低成本，高质量地完成。

参考文献：

[1]景慎艳:软件项目需求管理的探索与实践[J].电脑知识与技术，2008（27）

[2]左怀远:软件项目中的风险管理研究[J].世界科技研究与发展，2008（3）

[3]孙琦龙:加强软件项目管理的实践模式[J].科技信息，2008（7）