测试的艺术:代码检查、走查与评审

软件开发人员通常不会考虑的一种测试形式-人工测试。

大多数人都以为,因为程序是为了供机器执行而编写的,那么也该由机器来对程序进行测试。这种想法是有问题的。人工测试方法在暴露错误方面是很有成效的。实际上,大多数的软件项目都应使用到一下的人工测试方法:

1. 利用错误列表进行代码检查

2. 小组代码走查

3. 桌面检查

4. 同行评审

代码检查:

所谓代码检查是以组为单位阅读代码,它是一系列规程和错误检查技术的集合。

一个代码检查小组通常由四人组成:

  1. 协调人:以为称职的程序员
  2. 该程序的编码人员
  3. 该程序的设计人员
  4. 测试专家

用于代码检查的错误列表:

  • 数据引用错误

    • 是否有引用的变量未赋值或未初始化
    • 下标的值是否在范围之内
    • 是否存在非整数下标
    • 是否存在虚调用
    • 当使用别名时属性是否正确
    • 记录和结构的属性是否匹配
    • 是否计算位串的地址,是否传递位串参数
    • 基础的存储属性是否正确
    • 跨过程的结构定义是否匹配
    • 索引或下标操作是否有“仅差一个”的错误
    • 继承需求是否得到满足
  • 数据声明错误
    • 是否所有的变量都已声明
    • 默认的属性是否被正确理解?
    • 数组和字符串的初始化是否正确?
    • 变量是否赋予了正确的长度,类型和存储类
    • 初始化是否与存储类相一致?
    • 是否有相似的变量名?
  • 运算错误
    • 是否存在非算术变量间的运算?
    • 是否存在混合摸式的运算?
    • 是否存在不同字长变量问的运算?
    • 目标变量的大小是否小于赋值大小?
    • 中间结果是否上溢或下溢?
    • 是否存住被0除?
    • 是否存在二进制的不精确度?
    • 变量的值是否超过了有意义的范围?
    • 操作符的优先顺序是否被正确理解?
    • 整数除法是否正确?
  • 比较错误
    • 是否存在不同类型变量间的比较?
    • 是否存在混合模式的比较运算?
    • 比较运算符是否正确?
    • 布尔表达式是否正确?
    • 比较运算是是否与布尔表达式相混合?
    • 是否存在二进制小数的比较?
    • 操作符的优先顺序是否被正确理解?
    • 编译器对布尔表达武的计算方式是否被正确理解?
  • 控制流程错误
    • 是否超出了多条分支路径?
    • 是否每个循环都终止了?
    • 是否每个程序都终止了?
    • 是否存在由于入口条件不满足而跳过循环体?
    • 肯能的循环越界是否正确?
    • 是否存在“仅差一个”的迭代错误?
    • DO/END语句是否匹配?
    • 是否存在不能穷尽的判断?
    • 输出信息中是否有文字或语法错误?
  • 接口错误
    • 形参的数量是否等于实参的数量?
    • 形参的量纲是否与实参的量纲相匹配?
    • 传递给被调用模块的实参个数是否等于其形参个数?
    • 传递给被调用模块的实参属性是否与其形参属性匹配?
    • 传递给被调用模块的实参量纲是否与其形参量纲匹配?
    • 调用内部函数的实参的数量、属性,顺序是否正确?
    • 是否引用了与当前入口点无关的形参?
    • 是否改变了某个原本仅为输入值的形参?
    • 全局变量的定义在模块间是否一致?
    • 常数是否以实参形式传递过?
  • 输入/输出错误
    • 文件的属性是否正确?
    • OPEN语句是否正确?
    • I/O语句是否符合格式规范
    • 缓冲大小与记录大小是否匹配?
    • 文件在使用前是否打开?
    • 文件在使用后是否关闭?
    • 文件结束条件是否被正确处理?
    • 是否处理了I/O错误?
  • 其他检查
    • 在交叉引用列表中是否存在未引用过的变量?
    • 属性列表是否与预期的相一致?
    • 是否存在“警告”或“提示”信息?
    • 是否对输入的合法性进行了检查?
    • 是否遗漏了某个功能?

代码走查:

代码走查不同于仅阅读程序或使用错误检查列表,代码走查的参与者“使用了计算机”。被指定为测试人员的那个人会带着一些书面的测试用例来参加会议。在会议期间,每个测试用例都在人们脑中进行推演,也就是说,把测试数据沿程序的逻辑结构走一遍。程序的状态(如变量的值)记录在纸张或白板上以供监视。

这些测试用例必须结构简单,数量较少。因为人脑执行程序的速度比计算机执行程序的速度慢上若干量级。因此,这些测试用例本身并不起到关键的作用。它们的作用是提供了启动代码走查和质疑程序员逻辑思路及其设想的手段。在大多数的代码走查中,很多问题是在向程序员提问的过程中发现的,而不是由测试用例本身直接发现的。

桌面检查:

可以视为由单人进行的代码检查或代码走查。

同行评分

同行评分是一种依据程序整体质量,可维护性、可扩展性、易用性和清晰性对匿名程序进行评价的技术。

  • 程序是否易于理解
  • 高层次的设计是否可见且合理
  • 低层次的设计是否可见且合理
  • 修改此程序对评审者而言是否容易
  • 评审者是否会以编写出该程序而骄傲
时间: 2024-10-14 15:46:30

测试的艺术:代码检查、走查与评审的相关文章

静态代码检查报告

今天在下面刊载一篇小王同学写的静态代码检查报告,图文并茂,条理清晰. 1. 工具说明 FindBugs 是一个静态分析工具,它检查类或者 JAR 文件,将字节码与一组缺陷模式进行对比以发现可能的问题.有了静态分析工具,就可以在不实际运行程序的情况对软件进行分析.不是通过分析类文件的形式或结构来确定程序的意图,而是通常使用 Visitor 模式.Findbugs可以在多个环境中运行,同时也可以编写自己的检测器,功能比较完善.我们平时可以收集自己的或者是别人的开发经验,把它做成检测器来完善Findb

Android 代码检查工具SonarQube

http://blog.csdn.net/rain_butterfly/article/details/42170601 代码检查工具能帮我们检查一些隐藏的bug,代码检查工具中sonar是比较好的一个.官网 Sonar 概述 Sonar 是一个用于代码质量管理的开放平台.通过插件机制,Sonar 可以集成不同的测试工具,代码分析工具,以及持续集成工具.与持续集成工具(例如 Hudson/Jenkins 等)不同,Sonar 并不是简单地把不同的代码检查工具结果(例如 FindBugs,PMD

java 命名代码检查-注解处理器

命名代码检查 根据 <Java 语言规范( 第 3 版 ) > 中第6.8节的要求, Java 程序命名应当符合下列格式的书写规范: 类 ( 或接口 ) : 符合驼式命名法, 首字母大写. 方法 : 符合驼式命名法,首字母小写 字段 : 类或实例变量 : 符合驼式命名法 , 首字母小写 常量 : 要求全部有大写字母或下划线构成, 并且第一个字符不能是下划线. 要通过注解处理器的API 实现一个编译器插件 , 首先需要了解这组 API 的基本知识.我们实现注解处理器的代码需要继承抽象类 java

华为软件开发云测评报告二:代码检查

相关文章:<华为软件开发云测评报告一:项目管理> 体验环境 体验方式:PC端 系统:Windows 64位 浏览器类型:Chrome浏览器 浏览器版本:58.0.3029.110 体验时间:2017.06.25 分析目的 了解华为软件开发云的代码检查服务功能,分析其优缺点: 从人工代码检视到自动化代码检查,华为软件开发云如何保证代码质量: 代码检查未来的发展趋势: 产品简介 产品名称:华为软件开发云 定位:软件开发云(DevCloud)是集华为研发实践.前沿研发理念.先进研发工具为一体的研发云

【tool】利用测试概念进行代码设计时的七条基本原则

跟其它编码原则一样,这些原则也不是不容置疑或不可改变的教条.有时候打破这些规则也是必要的.因此,理解每条原则背后的动机和判断何时这些动机不适用(或应让位给更关心的问题)的能力是很重要的. 原则 1. 到 GUI 视图的外面去 尽可能把代码移到 GUI 视图的外面.然后各种 GUI 动作就能成了模型上的简单方法调用.为什么您需要这样做呢? 对 GUI 测试者来说,通过方法调用测试功能比间接地测试功能容易的多. 另一个好处是它使修改程序功能而不影响视图变的更容易. 当然,视图中也可能存在错误.在理想

SonarQube4.4+Jenkins进行代码检查实例之一

在最新的<关于代码审查的几点建议>中再次提到了代码分析: 6.尽量使用静态代码分析工具以提高审查效率. 笔者之前也谈到过多次代码分析.代码检查,见: 关于代码评审的微博讨论汇集 #敏捷有效实践# 每日代码自动检查 英文是daily code inspection.对代码质量关注时,安排人工检查code review是需要的,但100% code review需要很多工作量,不是所有的组织值得这样做,而工具自动检查是只需少量人工建设配置,99%的组织值得采用.此实践花费不多,收效不小. #CMM

使用vue-cli脚手架搭建项目,保存编译时出现的代码检查错误(ESLint)

一.问题 出现这么写错误是什么原因呢?相信很多小白都会像我一样,第一次接触时有点二丈和尚摸不着头脑.其实是在你用vue-cli脚手架构建项目时用了ESLint代码检查工具,如下图 那么什么是ESLint呢? 二.ESLint介绍(中文官网) 官网是这用介绍的, ESLint 是一个开源的 JavaScript 代码检查工具,由 Nicholas C. Zakas 于2013年6月创建.代码检查是一种静态的分析,常用于寻找有问题的模式或者代码,并且不依赖于具体的编码风格.对大多数编程语言来说都会有

git 服务器搭建及提交代码检查

本地 git 服务,通常都会选择 gitlab.本人最先也是选择 gitlab,在 centos7 上按照官网的步骤进行安装,下载的速度难以忍受,无奈放弃.最终选择在 docker 中安装 gogs 镜像来自建 git 服务. 一.安装 gogs 1.拉取镜像 docker pull gogs/gogs 2.创建数据目录 mkdir -p /var/gogs 3.创建窗口并运行 docker run -d --name=git-gogs -p 10022:22 -p 13000:3000 -v

静态代码检查工具 cppcheck 的使用(可分别集成到VS和QT Creator里)

CppCheck是一个C/C++代码缺陷静态检查工具.不同于C/C++编译器及其它分析工具,CppCheck只检查编译器检查不出来的bug,不检查语法错误.所谓静态代码检查就是使用一个工具检查我们写的代码是否安全和健壮,是否有隐藏的问题. 比如无意间写了这样的代码: [cpp] view plain copy int n = 10; char* buffer = new char[n]; buffer[n] = 0; 这完全是符合语法规范的,但是静态代码检查工具会提示此处会溢出.也就是说,它是一