【软件测试】3、代码检查与Code Review

对于一家技术研发流程完善的技术公司来说,代码审查都是必不可少的一部分。虽然大部分代码审查工作都是研发团队的工程师完成,广义上讲,代码审查也是软件测试的一部分。这与大部分人对软件测试的观念有所不同,他们可能认为软件测试的唯一方法是用计算机执行代码。实际上,使用计算机执行的软件测试只是传统的测试方法,而软件测试的新观念认为在进行传统测试之前,代码人工审查也是非常必要的。

1、代码检查

代码检查通常以一个小组为单位,主要的目的在于发现代码中出现的错误以及不良风格,主要有:

(1)数据引用错误:

①使用了未初始化和未赋值的变量;②数组下标越界;③数组下标非正整数;④“虚调用”,即引用了非法内存;⑤按照错误的数据类型引用内存数据;⑥数据类型与引用它的结构不匹配;⑦内存寻址错误;⑧基础存储结构错误;⑨跨过程的结构定义错误;⑩数组或字符串存在下标边界引用错误(特别是第一个和最后一个);⑪类的继承需求没有满足。

(2)数据声明

①使用了未声明的变量;②变量声明的属性错误;③变量在声明时初始化错误;④变量的长度和数据类型错误;⑤变量的初始化与存储空间类型不一致;⑥变量名称过于相似。

(3)运算错误

①运算的变量之间数据类型不一致;②存在相同数据类型、不同字长的变量之间的运算;③被赋值的变量数据类型小于右侧表达式的返回结果的数据类型;④存在混合模式的运算;⑤表达式运算结果存在溢出;⑥存在用0除;⑦计算进制错误;⑧变量的值超出实际意义;⑨操作符优先级判断错误;⑩整数运算逻辑错误。

(4)比较错误

①存在不同数据类型的比较;②混合模式比较中类型转换规则错误;③比较运算逻辑不正确,尤其注意“等于”的情况;④bool表达式所叙述的内容是否正确;⑥浮点变量比较错误;⑦逻辑运算优先级错误;⑧使用了编译器不接受的写法。

(5)流程控制错误

①含有潜在的非法分支;②存在死循环的可能;③存在从来没有执行的循环体;④循环越界;⑤循环次数多一次或者少一次,常常因为≥和>、≤和<的区别造成;⑥do和while不匹配;⑦代码块“{”和“}”不匹配;⑧未设置默认的判断分支。

(6)接口错误

①形参与实参数量不匹配;②形参与实参的数据类型不匹配;③形参和实参的量纲不匹配;④原本输入参数的值被改变;

(7)输入输出错误

①文件声明属性错误;②文件打开属性错误;③打开文件的内存空间不足;④使用了未打开的文件;⑤文件使用过后未关闭;⑥未处理判断文件结束的条件;⑦未处理文件打开失败的情况。

(8)其他检查

①程序出现警告;②程序未检查输入的合法性;③程序遗漏了某些功能。

2、代码走查

代码走查主要考察代码的运行流程。测试者使用书面的测试用例进行推演,即使用测试数据沿程序的逻辑结构运行一遍并记录程序的状态。

时间: 2024-09-23 08:10:18

【软件测试】3、代码检查与Code Review的相关文章

Code Review 理论与实战

一. Code Review 简介 1 Code Review 的目的 凡事知其然还要知其所以然 , 我们首先需要知道什么是 Code Review 和我们使用它的目的是什么. Code Review 是一种用来确认方案设计和代码实现的质量保证机制,通过这个机制我们可以对代码,测试过程和注释进行检查. Code Review 主要用来在软件工程过程中改进代码质量,通过 Code Review 可以达到如下目的: 在项目早期就能够发现代码中的BUG 帮助初级开发人员学习高级开发人员的经验,达到知识

[读后感]从Code Review 谈如何做技术

还有9个电,争取把这篇发出去,里面有太同共鸣,只不过之前没能写出来, 一是文笔有限,总结不够明确,本文至少总结出了我想总结的6个观点,看来总结能力还是要提高: 二是不确认这是对的,所以不敢贸然写出来,看来奔四的程序员都有这些共同的想法,并非我一人,还有许多人... 着实说,代码审查,以前想过,但没做过: 代码审查确实很不错,不懂开发的测试人员其实从某种角度是用于粗暴地替代代码审查, 结果可知,花在修复 Bug 上的时间要比编码时间多 N 倍, 我想我们以敏捷方式来对付它,逐层皮儿地扒着做,做完一

从 Code Review 谈如何做技术

编者注:本文来自酷壳-CoolShell.cn 的陈皓 这两天,在微博上表达了一下Code Review的重要性.因为翻看了阿里内部的Review Board上的记录,从上面发现Code Review做得好的是一些比较偏技术的团队,而偏业务的技术团队基本上没有看到Code Review的记录.当然,这并不能说没有记录他们就没有做Code Review,于是,我就问了一下以前在业务团队做过的同事有没有Code Review,他告诉我不但没有Code Review,而且他认为Code Review没

敏捷软件开发实践-Code Review Process

介绍: 在敏捷软件开发中,从代码的产生速度上来看,要比传统Waterfall产生速度高很多.因为我们把时间安排的更加紧凑了.那么这么多的代码,如何能保证这些代码质量呢?很多人可能直接想到静态代码检测工具.没错,那些是可以定义一个代码检查规则来确保代码的质量,但是那个仅仅是从语言角度,那么逻辑是否已经最优化了?可重用性是否已经优化到极致了?这些是静态代码工具不能完成的,所以我们需要Code Review 实现方式: 对于已经在项目组很久的人来说: 虽然传统的code review就是把代码从仓库c

Code Review for Vue 2.0 Preview

是的!Vue 2.0 发布了! Vue 2.0 preview 仓库在此 首先,当我第一次看到 Vue 2.0 的真面目的时候,我的内心是非常激动的 Demo 来个简单的 demo,首先把 dist/vue.js 导入到一个空白的网页里,然后写: 当然,在大家阅读下面所有的内容之前,先想象一下,这是一个运行时 min+gzip 后只有 12kb 大小的库 <script src="./dist/vue.js"></script> <div id="

工程中Java Code Review发现的问题汇总

工程中Java Code Review发现的问题汇总 概述 最近对团队内近期开发的一些Java web工程进行了Code Review,这些Code主要是需要在多个工程中复用的基础组件,Java代码为主.审核中发现了一些编码问题(暂时不考虑设计模式.架构层面的),这里进行一下汇总总结. 问题列表 注释 普通的程序员最痛恨接手或使用没有文档的代码,而程序员一般又不喜欢些文档,代码注释是文档的一种,在Code Review中发现工具扫描时注释率很高,但是真正进去去看,注释率极低. 接口一定要有详细的

聊Code review(上)

篇前的话:本文主要关注互联网应用程序如何做Code review(代码审查)方面.上篇主要描述什么是code review, 为什么要去做,主要包含哪些内容:下篇,主要讲如何组织人员做代码review,对程序员,以及团队有什么影响,重点在下篇. 从事过几年程序开发的猿猿们(注1),听过.或抱怨过: "某某系统的代码太烂"或"某某人的代码太烂".本文着重说应用软件的code review,将从这些问题去探讨:为什么要做代码review?如何去做代码review,应该注

7 个 code review 的技巧(转)

Code review,中文译为「代码审查」,是指对代码进行系统性的审查,通常是和其他开发者来共同进行.这里作者就讲了在 Asana 中他们是怎么来做代码审查的. 1.先确定 code review 的目标优先级 在 code review 之前先和你的团队成员明确 code review 中事项的优先级. 作者认为 code review 中应该做的事: 熟悉同事在编程时的思考方式,这样其余同事以后如果有需要就可以更轻松.快速的修改代码. 向同事介绍修改了哪些文件,增加了什么样的功能,这样在问

有人实践过 Phabricator 以及 Arcanist 作为 code review 的工具么?(转)

作者:覃超链接:http://www.zhihu.com/question/19977889/answer/13539702来源:知乎 平时就经常实践. 整个公司的code review就是使用这个. 具体说来, 由于我的project稍微有点特殊,所以我这一年在facebook工作的时候一直在用两套Code Review工具: Facebook的Phabricator 和 Google的Gerrit (他们都是开源). 我觉得两个工具都很快,很稳定,然后都有效地提供了code review必备