单元测试概述(可作为单元测试计划说明书的一个章节)

测试概述

1.1   测试目标

本次单元测试的目标为通过检查软件内部的逻辑结构,对软件中的逻辑路径进行覆盖测试;在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致。

1.2   测试方法

本次单元测试采用白盒测试的测试用例设计方法,采用白盒测试方法中的基本路经测试法,此方法是是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例的方法。其设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。其步骤主要分三步:

(1)画出控制流图

(2)计算圈复杂度

(3)导出测试用例

1.2.1    画出控制流图

流程图用来描述程序控制结构。可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)。在流图中,每一个圆,称为流图的结点,代表一个或多个语句。一个处理方框序列和一个菱形决测框可被映射为一个结点,流图中的箭头,称为边或连接,代表控制流,类似于流程图中的箭头。一条边必须终止于一个结点,即使该结点并不代表任何语句(例如:if-else-then结构)。由边和结点限定的范围称为区域。计算区域时应包括图外部的范围。

1.2.2    计算圈复杂度

圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量,将该度量用于计算程序的基本的独立路径数目,为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。

有以下三种方法计算圈复杂度:

流图中区域的数量对应于环型的复杂性;

给定流图G的圈复杂度V(G),定义V(G)=E-N+2E是流图中边的数量,N是图中结点的数量;

给定流图G的圈复杂度V(G),定义为V(G)=P+1P是流图G中判定结点的数量。

1.2.3    导出测试用例 

根据上面的计算方法,可得出四个独立的路径。一条独立路径是指,和其他的独立路径相比,至少引入一个新处理语句或一个新判断的程序通路。V(G)值正好等于该程序的独立路径的条数。

1.3   进入准则

       (1) 编码阶段已经审核完成;

       (2) 项目经理已经批准了单元测试计划;

       (3) 测试组已经设计好测试案例,经过测试组组长的检查,并通过项目经理批准,本项目的单元测试人员为开发人员;

       (4) 测试数据已经准备好并经过检查

       (5) 测试资源已经到位(软件、硬件、人力)

1.4   结束准则

(1)测试遇到的所有问题已经记录下来

(2)所有测试用例都已运行

(3)95%的测试用例已经成功通过

(4)所有测试用例至少运行了三次,所有错误已经修改

(5)测试结果已经记录,测试分析报告已经提交项目经理检查

 

1.5   考虑事项

(1)按类进行划分,每个类的每个重要函数作为一个单元,每个单元采用基本路径覆盖法来设计测试用例。

(2)测试错误处理是否正确。
单元测试计划 版本:V1.3 文 档 编 号 保 密 等 级 作 者 最后修改日期 审 核 人 最后审批日期 批 准 人 最后批准日期 修订记录 日期 版本 修订说明 修订人 目 录 1 导言 2 1.1 目的 2 1.2 背景 2 1.3 范围 2 2 进入条件 2 3 退出条件 2 4 代码级别标准 2 5 代码分级清单 3 6 单元测试风险 3 7 单元测试策略 3 7.1 策略描述 3 7.2 类型 3 7.2.1 代码走查 3 7.2.2 功能测试 4 7.2.3 边界测试 4 7.2.4 覆盖率测试 4 7.2.5 内存使用测试 4 7.2.6 测试方式 4 7.3 测试用例估算 4 8 工具 5 9 进度及分工 5 10 交付物 5 导言 目的 【描述该代码走查及单元测试计划的目的。】 背景 【描述代码走查及单元测试计划的背景,活动目的。如无特殊背景信息,可裁剪。】 范围 【说明该代码走查及单元测试计划在整个项目周期的适用范围】 进入条件 【描述项活动的测试依据和满足该阶段测试进入的条件和约束。】 退出条件 【描述满足该阶段测试退出的条件,编写时特别要根据 《项目量化管理计划》列举一些量化的退出指标,例如 致命和严重级别的缺陷清除率达到 100%】 代码级别标准 【请参考组织级文档《代码分类级别指南》,中规定进行分类,质量经理可根据项目情况,对级别和通过标准做适当调整,将最后确定的通过标准记录在以下表格中】 级别 检查项 通过标准 A 代码编写格式检查 B 代码编写质量检查 C1 代码走查 C2 C3 D1 测试用例代码覆盖率检查 D2 D3 D4 E 内存泄漏检查 代码分级清单 【由架构师根据代码级别标准,划分】 模块 代码 A B C D E C1 C2 C3 D1 D2 D3 D4 √ √ √ √ √             单元测试风险 【此处描述测试任务可能遇到的风险,以及规避的方法】 # 风险描述 可能性 风险影响 责任人 规避方法 【高、中、低】 【高、中、低】 单元测试策略 策略描述 【此处描述根据项目的具体特征所确定的代码走查及单元测试的策略(如:代码走查在本项目重点关注的地方、测试可行性分析,测试方法确定,测试类型选择)】 类型 【此处描述单元测试选择的测试类型,一般建议有如下几种:】 代码走查 目标: 技术: 完成标准: 需考虑的特殊事项: 功能测试 测试目标: 技术: 完成标准: 需考虑的特殊事项: 边界测试 测试目标: 技术: 完成标准: 需考虑的特殊事项: 覆盖率测试 测试目标: 技术: 完成标准: 需考虑的特殊事项: 内存使用测试 测试目标: 技术: 完成标准: 需考虑的特殊事项: 测试方式 【说明手工测试的部分和自动测试的部分】 测试用例估算 【说明对需要开发的测试用例数目的估算】 模块 类数目 测试类型 测试用例数 工具 【本次测试将使用的工具】 用途 工具 厂商/自产 版本 测试管理 测试执行 缺陷报告 进度及分工  【根据测试的模块,分解任务,计划工作量、时间、人员;制订该计划的同时请参考中层计划等相关计划和估算文档;对于代码走查的人员安排一般要求架构师、高级工程师对工程师、助理工程师的代码进行走查,同时高级工程师、工程师 之间进行代码互查】 模块 任务 工作量 开始日期 人员 代码走查 用例设计 用例开发 用例执行 工作量合计 代码走查 用例设计 用例开发 用例执行 交付物 【描述单元测试需要交付的工作产品】 交付物名称 责任人 参与者 交付日期 测试计划 代码走查报告 测试用例 测试报告
评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值