6 代码检查、走查与评审
代码走查
代码走查(code walkthrough)和代码审查(code inspection)是两种不同的代码评审方法,代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的。
最近对项目组进行代码评审，发觉需要对代码评审中找到的问题进行一下分类，大概可以分成以下几类问题：1. Comment注释没写，或者格式不对，或者毫无意义2. Coding Standard没遵守代码规范3. Existing Wheel重复现成的代码，或者是开源项目，或者公司已有代码4. Better practiceJava或者开源项目，有更好的写法5. Performance bottle and Improvement性能瓶颈和提高6. Code Logic Error代码逻辑错误7. Business Logic Error业务逻辑错误代码审查列出问题的类型，并有解决情况报告11月23日代码走查——项目走向成功的锦囊之一说起代码走查，相信每个人都不陌生，但为什么要执行代码走查，什么时候来执行代码走查，如何有效执行代码走查，很多人的看法和见解都不一样。
一般的看法，认为代码走查是一种非正式的代码评审技术，它通常在编码完成之后由代码的作者向一组同事来讲解他自己编写的代码，由同事来给出意见。
这种做法在很多做软件开发组织中经常采用。
但从实际执行效果来看，成效并不都那么明显，反而很多组织的这种做法有浪费时间之嫌。
主要是因为代码走查活动时间有限，而参加代码走查的人之前没有较多的时间来提前了解被走查的代码，故而在实际执行时能被走查的代码所占的比例并不高，同时也发现不了多少本质问题。
随着软件外包业的发展，它有别于软件产品开发，客户对于产品的要求不再局限于系统是否能够正确运行。
而是在设计、代码的品质上也有了更多的要求。
有的客户甚至会在我们每次交付后先来检查我们的代码品质，只要是代码不符合要求就会被拒绝。
但在项目的实际执行中，面对客户的这些要求，我们又常常遇到诸如编写的代码不符合规范；编码效率低；代码的可重用性低；代码错误多等现象，从而影响到项目的时程和交付的品质，影响到客户对我们的满意度和对我们专业程度的质疑。
软件测试类型及其在软件开发过程中的地位代码检查走查与评审_真题-无答案
软件测试类型及其在软件开发过程中的地位、代码检查、走查与评审(总分99,考试时间90分钟)选择题1. 把经过评审通过的各项需求转换为一个相应的体系结构，包括数据的体系结构、系统和软件的体系结构，这是软件生命周期哪一阶段做的事情______。
A.系统和需求定义 B.编程和单元测试 C.软件设计 D.运行和维护2. 之所以要对已交付使用的软件进行维护，原因是______。
Ⅰ．为了增强软件的功能，满足功能上的变更Ⅱ．运行中发现了软件中的错误需要更正Ⅲ．为了适应软件工作环境变化而引起的相应改变A.Ⅰ B.Ⅰ和Ⅲ C.Ⅱ和Ⅲ D.Ⅰ和Ⅱ和Ⅲ3. 以下不属于软件需求分析阶段测试的内容是______。
A.通过场景走查和与用户沟通，看需求是否是用户“真”的需求 B.通过对开发进度、开发费用、产品性能、可靠性和内存使用等各方面需求的分析，看综合起来是否合理，是否有对需求的一个优先级安排 C.通过领域分析和与用户沟通，看需求是否是完备的 D.通过检查需求与实现环境的不相容之处，看需求是否可兼容4. 下列可以做为软件测试对象的是______。
A.需求规格说明 B.软件设计规格说明 C.源程序 D.以上全部5. MM-路径集成是一种基于消息的路径集成方法，其中MM-路径是指______。
A.对应调用图的每一个边建立并执行的一个集成测试会话序列 B.针对模块的每一个程序剖面执行的语句序列 C.按照广度优先策略逐层集成与测试的序列 D.穿插出现在各模块中执行的方法和消息的序列6. 测试过程需要输入软件配置、测试配置和测试工具。
其中不属于测试配置的是______。
A.测试计划B.测试用例C.测试报告D.测试程序7. 面向对象的软件设计要首先考虑问题中的数据实体，通过实体提供的服务和实体之间的消息的传递来实现某种计算，这种体系结构的好处体系在______。
A.稳定性 B.一致性 C.可靠性 D.效率8. 规划阶段实际上指的是______。
代码评审的流程
代码评审是一种常用的质量保证方法，通过对代码进行系统性和结构化的检查，以发现潜在的问题、提出改进意见，并确保代码符合预定的标准和最佳实践。
以下是一个典型的代码评审流程：1.确定评审范围：明确要进行评审的代码模块或文件范围。
可以根据项目需求、功能模块或特定任务等进行确定。
2.选择评审人员：选定适当的评审人员，包括开发人员、技术专家、项目经理等，具有相关技术知识和经验，能够提供有价值的反馈和建议。
3.分配评审任务：将评审任务分配给各评审人员，确保每个人员都有清晰的责任和任务。
4.进行评审：评审人员独立地审查代码，检查其可读性、可维护性、性能、安全性等方面。
使用工具辅助代码静态分析也是一个有效的方式。
5.记录问题与建议：评审人员记录发现的问题、改进建议和注释，并将其与相应的代码行关联起来。
这可以通过评审工具、文档或在线协作平台来完成。
6.开展评审会议：评审人员进行评审结果的汇总和讨论，分享他们的观点、问题和建议。
这可以是一个面对面的会议或线上会议。
7.提交评审反馈：评审人员将评审结果整理成报告或通过评审工具提交给相应的开发人员。
确保问题和建议清晰明确，并提供必要的解释和示例代码。
8.开发人员响应与修复：开发人员接收评审反馈后，进行问题的分析和修复。
他们可以与评审人员进行进一步的沟通，以便更好地理解问题和建议。
9.进行再评审：在开发人员完成修复后，再次进行评审，以验证问题是否得到解决并确认改进是否有效。
10.关闭评审：最终评审结果被记录下来，并评估整个评审过程的效果和质量。
同时，为将来的迭代和项目经验积累提供反馈和改进意见。
以上流程仅为一般参考，实际的代码评审流程可能因组织和项目的需求而有所不同。
关键是确保评审过程系统性、持续性，并在项目中充分发挥其价值和作用。
检查代码的方法
检查代码的方法全文共四篇示例，供读者参考第一篇示例：在软件开发过程中，代码检查是非常重要的环节。
它可以帮助开发人员发现潜在的bug和错误，并且提升代码质量。
本文将介绍一些常用的检查代码的方法，帮助开发人员更好地进行代码检查。
一、代码审查代码审查是最常用的一种检查代码的方法。
一般情况下，代码审查包括两种形式：静态代码审查和动态代码审查。
静态代码审查是通过检查源代码或编译后的代码进行审查。
它可以发现一些潜在的bug和编码风格问题。
常用的静态代码审查工具包括Lint、PMD、Checkstyle等。
动态代码审查是通过运行程序来检查代码的质量。
可以使用断点调试工具来检查代码的执行过程，查看变量的值是否正确、程序的执行路径是否正确等。
二、单元测试单元测试是一种非常有效的代码检查方法。
通过编写单元测试用例，可以测试代码的各个功能模块是否正常工作。
如果单元测试用例都通过了，那么说明代码的质量较高。
在编写单元测试用例时，需要考虑尽可能多的测试场景，包括正常情况和异常情况下的处理逻辑。
可以使用Mock框架来模拟一些外部依赖，从而使测试更加容易。
代码走查是一种通过团队协作来检查代码的方法。
一般在代码走查会有一个专门的评审小组，由团队成员轮流担任Leader，负责主持代码走查的过程。
在代码走查中，团队成员可以提出自己的看法和建议，帮助发现代码中的问题。
这种方法可以增强团队之间的沟通和合作，提升整个团队的代码质量。
四、代码规范检查代码规范检查是一种通过检查代码是否符合编码规范来评估代码质量的方法。
编码规范是一种统一的编码风格，可以帮助开发人员编写易读、易维护的代码。
在进行代码规范检查时，可以使用代码检查工具来自动检查代码中的规范问题，如缩进、命名规范、文档注释等。
这种方法可以节省开发人员的时间，同时提高代码的一致性和可读性。
五、自动化测试自动化测试是一种自动化进行测试的方法。
通过编写自动化测试脚本，可以帮助开发人员快速地测试代码的各个功能，提高测试效率和代码质量。
软件测试(代码走查、检查与审查)
5、传递给被调用模块的实参量纲是否与其形参量纲匹配？
6、调用内部函数的实参的数量、属性、顺序是否正确？
7、是否引用了与当前入口点无关的形参？
8、是否改变了某个原来仅为输入值的形参？
9、全局变量的定义在模块间是否一致？
10、常数是否以实参形式传递过？
1）程序是够易于理解？
2）高层次的设计是够可见且合理？
3）低层次的设计是否可见且合理？
4）修改此程序对评审者而言是否容易？
5）评审者是否会以编写出该程序而骄傲？
还要要求评审人给出总的评价和建议的改进意见。
评审结束后，参与者会收到自己的那两个程序的匿名评价爱表，此外还会收到一个带统计的总结，说明在所有的程序中其程序的整体和具体得分情况，以及他对其他程序的评价爱与其他评审人同意程序打分的比较分析情况。
2、桌面检查胜过没有极限嘻哈，但其效果远远逊色于代码检查和代码走查。
同行评审
（peerrating）
1、同行评审的概念
同行评分是一种依据程序整体质量，可维护性、可扩展性、易用性和清晰性对匿名的程序进行技术评价的技术。改技术的目的是为程序员提供自我评价的手段。
2、实施过程：
选出一名程序员来担任这个评分过程的管理员，管理员又会挑选出大约2~20名参与者，保持匿名，这些参与者否应具有相似的背景要求每名参与者都挑选出两个由自己编写的程序以供评审。其中的一个程序应是参与者自认为能代表其自身能力的最好的作品，而了另一个则是参与者自认为质量较差的作品。
3、代码走查的意义：
提出的建议应针对程序本身，而不是针对程序员。换句话说，软件中存在的错误不应该被视为编写程序人员自身的弱点。相反，这些错误应被看作是伴随着软件的艰难性所固有的。
代码评审方法论
代码评审方法论代码评审是软件开发中非常重要的环节，它可以帮助开发团队提高代码质量、减少潜在的问题和错误。
本文将介绍一些常用的代码评审方法论，以帮助开发团队更好地进行代码评审。
一、代码评审的重要性代码评审是软件开发过程中的一项关键活动，它可以帮助团队发现潜在的问题和错误，提高代码质量和可维护性。
通过代码评审，团队可以共同学习和分享最佳实践，提升整个团队的技术水平。
二、代码评审的常用方法1. 静态代码分析静态代码分析是一种自动化的代码审查方法，它通过分析代码的语法和结构，检测潜在的问题和错误。
常见的静态代码分析工具包括Lint、FindBugs、Checkstyle等。
在代码评审过程中，可以使用这些工具来辅助发现代码中的问题，如未使用的变量、空指针引用、代码重复等。
2. 代码走读代码走读是一种通过阅读代码来评审的方法，评审人员需要仔细阅读代码，并检查代码的可读性、可维护性和可扩展性。
在代码走读过程中，可以关注以下几个方面：- 命名规范：检查变量、函数和类的命名是否符合规范，是否能够清晰地表达其含义。
- 代码结构：检查代码的组织结构是否合理，是否符合设计原则，是否易于理解和修改。
- 注释和文档：检查代码中的注释和文档是否准确、清晰，是否能够帮助其他人理解和使用代码。
3. 功能测试功能测试是一种通过运行代码来评审的方法，评审人员需要按照预定义的测试用例来运行代码，并验证其功能的正确性和完整性。
在功能测试过程中，可以关注以下几个方面：- 边界条件：检查代码在各种边界条件下的行为，如输入的最大值、最小值、空值等。
- 异常处理：检查代码对异常情况的处理是否正确，是否能够保证系统的稳定性和可靠性。
- 性能和效率：检查代码的性能和效率是否满足需求，是否存在性能瓶颈和潜在的优化点。
4. 安全性评估安全性评估是一种通过检查代码中的安全漏洞和弱点来评审的方法，评审人员需要了解常见的安全问题和攻击方式，并检查代码中是否存在潜在的安全隐患。
代码走查报告
代码走查报告经过对代码的仔细检查和评估，本次代码走查报告旨在提供一个全面的分析和评价，以便进一步改进代码质量和性能。
报告将按照以下几个方面展开，包括代码结构、代码规范、代码性能和代码安全。
1. 代码结构代码结构是一个良好软件设计的基础。
通过代码走查，我们着重关注以下几个方面的问题：1.1. 模块划分：代码是否按照模块划分，模块之间的职责是否清晰明确，模块间的依赖关系是否合理。
1.2. 类与函数：是否遵循单一职责原则，类和函数的命名是否能够准确反映其职责，是否存在冗余代码或重复逻辑。
1.3. 注释与文档：代码中是否有足够的注释，注释内容是否准确完整，是否存在过时的注释。
2. 代码规范代码规范是保证代码可读性和可维护性的基础。
在代码走查中，我们关注以下几个方面的问题：2.1. 命名规范：代码中的变量、函数、类等命名是否符合规范，是否能够准确描述其含义。
2.2. 缩进与格式：代码是否统一使用相同的缩进风格，是否合理使用空格和换行符，增加代码的可读性。
2.3. 异常处理：是否对可能出现的异常情况进行捕获与处理，是否使用合适的异常提示信息。
3. 代码性能代码性能是保证系统高效运行的关键。
在代码走查中，我们关注以下几个方面的问题：3.1. 算法与数据结构：代码中是否使用了适当的算法和数据结构，以提高程序的运行效率。
3.2. 循环与递归：遍历和循环的逻辑是否合理，是否存在无限递归或者死循环的情况。
3.3. 资源管理：代码中是否合理使用内存和其他资源，是否存在资源泄露或者过度消耗问题。
4. 代码安全代码安全是保护系统和用户信息的重要方面。
在代码走查中，我们关注以下几个方面的问题：4.1. 输入验证：代码中是否对输入数据进行合法性验证，以防止恶意输入和攻击。
4.2. 数据隐私：对于涉及用户隐私的数据，是否进行适当的加密和保护。
4.3. 错误处理：是否对可能出现的错误情况进行合理的处理和记录。
结论：通过对代码的走查和评估，我们发现了一些需要改进的地方，包括代码结构、代码规范、代码性能和代码安全等方面的问题。
代码走查规范
维远泰克代码走查规范文件编号：起草部门：测试组审核人：签发人：批准日期：版本标识：目录1引言...................................................................................................................................... 错误!未定义书签。
1.1目的 .................................................................................................................................... 错误!未定义书签。
1.2说明 .................................................................................................................................... 错误!未定义书签。
2代码走查 (4)2.1检查点 (4)2.2走查流程 (4)2.2.1走查流程图 ......................................................................................................... 错误!未定义书签。
2.2.2流程概述............................................................................................................. 错误!未定义书签。
2.2.3具体流程............................................................................................................. 错误!未定义书签。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
代码检查
负责静态测试的人员不是固定的。在某些小 组中，程序员就是组织和审查的人员，软件 测试员被要求作为独立的观察者。还有一些 小组，软件测试员是该任务的执行人，要求 编写代码的程序员和其他同时帮助审查。采 用何种方式取决于开发小组的自身状况。
代码检查
静态白盒测试一般面临的情况是不能善始善 终，因为小组会认为太好使，费用太高，没 有产出。 原因是人们认为程序员的任务就是编写代码， 而任何破坏代码编写效率的事情都会减缓开 发过程。
代码检查、走查与评审
静态的白盒测试
静态测试和动态测试
静态测试（人工测试）
不运行程序进行测试，即检查和审阅
静态黑盒测试——检查产品说明书 静态白盒测试——检查代码，在不执行的条件下有 条理地仔细审查软件设计、体系结构和代码，从而 找出软件缺陷的过程，有时称为结构分析。
动态测试（基于计算机的测试）
运行和使用软件以发现错误，即通常意义上的测试
代码检查的错误列表（cont）
int x = 1; int y = 2; float z = 0; z = x/y; System.out.println ("z = " z); OUTPUT: z=0
代码检算？（如日期与数字） 是否有混合模式或不同长度数据的比较运算？ 比较运算符是否正确？（如至多、至少，不小于） 布尔表达式（与、或、非）是否正确？ 比较运算符是否与布尔表达式相混合？（如2<i<10对 吗？） 是否存在浮点数的比较？ 优先顺序是否正确？(例如if((a==2) && (b==2) || (c==3)) 布尔表达式的计算方式（例如 if((x==0 && (y/x)>z)）
代码检查的错误列表（cont）
for (i==x ; i<=z; i++) { ... } while (NOTFOUND) { ... }
代码检查的错误列表（cont）
6.接口错误
形参和实参的数量是否相等？ 形参的属性是否与实参的属性相匹配？ 形参的属性是否与实参的顺序相匹配？ 形参的单位是否和实参匹配？（属逻辑错误） 是否改变了某个仅作为输入值的形参？（C++中的 const关键字） 全局变量的定义是否一致？
代码检查
四个基本要素
确定问题. 遵守规则. 准备. . 编写报告.
代码检查
实施过程
协调人在代码检查前几天分发程序清单和设计规范 编码人员讲述程序的逻辑结构，其他人员提问题并判断 是否存在错误(对照历来常见的编码错误列表) 注意力集中在发现错误而非纠正错误上（非调试） 会议结束后，程序员会得到一份已发现错误的清单
桌面检查的缺点
桌面检查的效率低 是一个完全没有约束的过程 违反了测试原则：人们一般不能有效测试自己编写的程 序，因此桌面检查最好由其他人而非该程序的编写人员 来完成 桌面检查的效果逊色于代码走查或代码检查 缺少了代码检查和走查小组中存在的互相促进的效应
小结
人工测试的必要性和有效性 人工测试方法
利用错误列表进行代码检查 小组代码走查 桌面检查
规程稍微不同 走查会议期间，每个测试用例都在人们脑中推演，即把测 试的数据沿着程序的逻辑结构走一遍，记录程序的状态供 监视，很多错误是在向程序员提问的过程中发现的。
其他与代码检查相同的地方
参与者所持的态度同样非常关键 代码走查也会带来同样的附带作用
桌面检查
桌面检查
是人工查找错误的一种古老的方法 桌面检查可视为由单人进行的代码检查或代码走查 由一个人阅读程序，对照错误列表检查程序，对程序推 演的过程。
人工测试
人工测试方法的正规性、精确性不如基于计算机测试，但 并不妨碍测试取得成功，相反可以提高测试的功效和可靠 性 错误发现得越早，改正错误成本越低，正确改正错 误可能性越大 程序员在开始基于计算机的测试时要经历一个心理 上的转变，改正早期发现的错误比改正后期计算机 执行发现的错误时失误更少 更容易定位以及发现由该错误引发的其他缺陷（如 连锁错误或类似错误）降低调试成本 通常会有效地查找出30％－70％的逻辑设计和 编码错误
代码检查的其他作用
程序员会得到编程风格、算法选择及编程技术等方面的 反馈信息其他参与者也可以同样受益
代码检查
人员组成（4人） 一人负责协调：分发材料、安排进程、确保错误随后得到改正 被测试程序的编码人员 程序的设计人员和一名测试专家 实施过程 协调人在代码检查前几天分发程序清单和设计规范 编码人员讲述程序的逻辑结构，其他人员提问题并判断是否存 在错误 对照历来常见的编码错误列表分析程序 注意力集中在发现错误而非纠正错误上（非调试） 会议结束后，程序员会得到一份已发现错误的清单
代码检查的错误列表（cont）
8.其他检查
是否存在未引用过的变量？ 每个变量的属性和赋予的默认值是否一致？ 编译通过的程序是否存在“警告”或“提示”信息？ 程序或模块是否对输入的合法性进行了检查？（如第一 章中三角形例） 程序是否遗漏了某个功能？
代码走查
代码走查和代码检查类似，都是以小组为单位进行代码阅读， 是一系列规程和错误检查技术的集合。二者的过程大致相同， 不同之处在于
代码检查的错误列表
1.数据引用错误
变量使用前是否赋值或初始化？
容易引起变量使用错误，特别是对于指针或引用变量。 在java中要求变量在使用前必须初始化。
数组下标的范围和类型
是否存在下标越界错误，下表类型是否为整型。
通过指针引用的内存单元是否存在（虚调用）？
如在函数返回局部变量的指针或引用时会产生虚调用错误。
代码检查的错误列表（cont）
7.输入输出错误
文件属性是否正确？ 打开文件的语句是否正确？ 缓冲区、内存大小是否足够来保留程序将读取的文件？ 文件在使用前是否打开？ 文件在使用后是否关闭了？ 文件结束条件是否本正确处理？ 是否处理了IO错误？ 打印或输出的文本信息中是否存在拼写或语法错误？即 输出结果正确性。
代码检查的错误列表（cont）
5.控制流程错误
是否所有循环都能终止？（循环结束条件是否能满足以 及递归的终止条件是否能满足。） 是否存在由于入口条件不满足而跳过循环体？（dowhile循环） 是否存在仅差一个的循环错误？（如for(int i=0;i<=10;i++){}） 程序结构中括号是否匹配、if,else是否匹配、do,while 是否匹配、try,catch是否匹配等。
代码检查的错误列表（cont）
3.运算错误 是否存在非算术变量之间的运算？ 是否存在混合模式的运算？（ int与float类型） 是否存在不同字长变量之间的运算？（int与long类型） 目标变量大小是否小于所赋值的大小？（精度损失或越 界错误） 中间结果是否上溢或下溢？ 是否存在除0错误？ 操作符的优先顺序是否正确？ 整数除法是否正确？（精度问题，如2*（i/2）==i）
被引用的变量或内存的属性是否与编译器预期的一致？
如A类型的指针或引用是否指向的是非A类型对象。
代码检查的错误列表（cont）
2.数据声明错误 是否所有变量都已声明？
绝大多数编程语言要求变量先定义后使用，可保证变量使用的 安全性。
默认的属性（默认值）是否正确？ 变量的初始化是否正确？变量的初始化是否与 其存储空间的类型一致？ 是否每个变量都有正确的长度、类型和存储类 别？ 是否存在相似名称的变量？