《软件测试设计》第1章——静态测试

手段:评审(人工检查)、静态分析(自动化检查) 基本思想:预防缺陷 1 1 评审 是静态测试技术的重要组成成分,多用于软件开发周期早期。 方式:深入阅读和理解

手段:评审(人工检查)、静态分析(自动化检查)

基本思想:预防缺陷

1.1 评审

是静态测试技术的重要组成成分,多用于软件开发周期早期。

方式:深入阅读和理解被检查文档

评审阶段:① 计划阶段 ② 预备会阶段 ③ 个人准备阶段 ④ 评审会议阶段 ⑤ 返工阶段 ⑥ 跟踪结果阶段

评审的优点:① 提高质量:覆盖率较高,但增加项目的成本和时间。 ② 提高有效性:可降低测试和开发的成本。 ③ 可预测性:动态测试最难预测和管理。 ④ 培训目的 ⑤ 缺陷预防

1.1.1 评审遵循的原则

① 尽早开展评审活动

② 控制评审会议的时间

③ 评审的是软件产品而不是作者

④ 每个评审员都有机会表达各自的观点

⑤ 发现缺陷,而不是修复缺陷

⑥ 评审中发现的缺陷和问题,应划为不同的严重程度级别(严重缺陷、重要缺陷、一般缺陷、好的)

⑦ 评审团队最后应对评审对象给出如下评审意见

1.1.2 选择合适的评审类型

(1) 审查

是系统的同行检查方法,比较全面

(2) 技术评审

同行间的小组讨论工作。

为了对测试对象所采用的技术实现方法达成共识

技术评审可为管理人员提供证据确认项目的技术状态。

(3) 走查

通过作者逐步陈述文档内容,收集测试对象的相关信息,并对其中内容达成共识。

(4) 非正式评审

工作量小

(5) 管理评审和审计

① 管理评审

指管理层及其代表执行的对软件采购、供应、开发、运作或维护过程的系统化评估

目的:监控进程和评估状态,为下一步行动作出决策

② 审计

目的:是对进程的一致性、规范性和标准提供独立的评估

(6) 特殊工作产品的评审

合同评审,需求评审,设计评审,验收/资质评审,运行预备评审

1.1.3 案例分析:如何开展评审活动

为成功将评审引入到项目和组织中,需采取以下措施:

① 获得管理层支持

② 管理人员培训

③ 正规的评审过程

④ 开展评审技术和规程的培训

⑤ 获得评审员和评审对象的支撑

⑥ 评审最重要的文档

1.1.4 影响评审成功的因素

① 技术因素

② 组织因素

③ 人员问题

 1.2 静态分析

通过工具支持来完成。没有运行测试对象。与评审紧密联系。

静态分析常发现的缺陷类型如下:

① 违背语法规则

② 违背编程规范和标准

③ 控制流异常

④ 数据流异常

静态分析的优点:

① 测试执行前尽早发现测试对象中缺陷和问题

② 通过度量计算,早期就可对可能存在问题的代码和设计保持响应的警惕

③ 发现在动态测试过程中不易发现的缺陷异常

④ 发现软件模块间相互关联的不一致性

⑤ 可改进代码和设计,增强可维护性

静态分析的目的:

① 发现测试对象中的缺陷或可能存在缺陷的地方

② 得到测试对象的度量数据,从而对测试对象的质量进行评估

1.2.1 基本代码分析

(1) 控制流分析

控制流:指组件或系统中的一系列顺序发生的事件或路程

控制流测试属于白盒测试(基本结构的测试基础)

控制流分析可发现以下缺陷:

① 选择控制中switch语句,若选项超过设定值,代码如何处理?

② 测试对象代码中所有循环是否都能终止?

③ 循环入口条件是够满足?

④ 多一次/少一次循环的错误

⑤ 是否存在不能穷尽的判断?

(2) 数据流分析

对象的状态:创建(Creation/Defined)、使用(Usage/Uesd)、销毁(Destruction/Killed)

~:变量不存在或没有定义

d:变量声明或定义,并且变量已经赋值

u:读取或使用

k:声明或定义了变量,但还没有为其赋值,或已经释放变量

下分析正确错误:

~d:正确

~u:错误

~k:错误

dd:赋值后,再赋值,可疑,可能是编程错误

du:赋值后,再使用,正确

dk:变量定义后在销毁,可疑,可能是编程错误

ud:使用后,再定义,可以接受

uu:使用后,再使用,正确

uk:使用后,再销毁,正确

kd:销毁后,再定义,可以接受

ku:销毁后,再使用,严重错误

kk:销毁后,再销毁,可疑,可能是编程错误

(3) 编码标准的一致性

编码标准:开发人员编写代码的指导性规范

优点:

① 减少代码中的缺陷

② 良好编码架构有利于采用基于结构的技术来创建测试用例,从而易于组件测试

③ 易于维护

④ 对新人友好

(4) 生成代码度量

代码度量:① 圈复杂度(Cydomatic Complexity) ② 规模(Size) ③ 注释率(Comment Frequency) ④ 嵌套的层数(Number of Nested Levels) ⑤ 函数调用数(Number of Function Calls)

1.2.2 基于架构的分析

架构:

①产品或系统中的组件相互调用关系

②产品图形化用户接口的菜单结构

③网络产品或者其他功能结构

举例:

(1) 网站

使用静态分析工具也能评价网站的架构,目的是检查网站的树状结构是否平衡

网站结构图中信息的作用:

① 验证网站功能是否实现

② 估算测试工作量

③ 评估网站可用性

④ 评估网站可维护性

(2) 调用图

调用图:控制流的一种表示形式

从测试角度看,构建程序调用图的目的是:

① 设计相应测试用例来调用特定的模块或函数

② 在代码中设置相关的断点或位置,确定模块的调用处

③ 为选择集成测试的集成策略提供建议

④ 评估所以代码的架构及其架构的易用性和可维护性

标签: 软件开发 文档