基于工作流技术的软件测试流程定义与监控_图文(精)（共5篇）

第一篇：基于工作流技术的软件测试流程定义与监控_图文(精)

收稿日期 :2005-12-09;修返日期 :2006-01-18(基于工作流技术的软件测试流程定义与监控 * 郑小军 , 刘 超 , 晏海华

(北京航空航天大学 软件工程研究所 , 北京 100083 摘 要 :阐述了软件测试流程的相关概念 , 论述了基于工作流技术实现软件测试流程定义与监控的概念模型 , 详细探讨了软件测试流程定义与实例化和软件测试流程的执行与监控所涉及的主要内容及其具体实现方案。关键词 :工作流;测试流程;测试阶段;测试流程控制项

中图法分类号 :TP311 51 文献标识码 :A 文章编号 : 1001-3695(2007 02-0043-03 M echan is m o f D efi n i n g and M on itori ng Soft w are Testi ng Flo w Based onW orkfl o w Z HENG X iao-j un , L I U Chao , YAN H a-i hua(Soft wa re Eng i neering Instit u te , B e i hang Un iversit y, B eiji ng 100083, C hina Abstract :Th i s paper expati ates the concepts related to soft ware testi ng flo w, d i ssertate t he connecti onalm odel of m i ple m en-ti ng the defi n iti on and mon itoring of soft w are testi ng fl ow based on theworkfl ow technol ogy.It also discusses i n detail about the

m ain content and specific realizati on sche m e i nvolved i n t he defi n iti on , i nstanti ati on , executi on and m on itoring of soft ware tes-ti ng fl ow.Key words :W ork flo w;Soft w are Testi ng F l ow;Test Phase;Soft w areTesti ng Flo w Control Ite m 1 引言

研究新的开发方 法、技术和工具以提高软件项目的生产效 率和质量一直是软件 工程研究的热点。三十多年来 , 尽管新的 开发方法和技术在软 件开发过程中的应用起到了一定的作用 , 但软件产业随着软件 规模和结构 复杂度 的提高 依然没 能摆脱 项目延期及超出预算 的困扰。

一个成功的软件 项目意味着 能够在 没有超 出预算 的情况 下 , 按时交付质 量合 格的 软件 产 品。I EEE 资 料表 明 , 仅 1995年一年内 , 大型软件系统的失败率(取消率 达到了 20%;而在 剩下的 80%中 , 大约有 2/3的项目延期 , 并且有 些项目 的经费 开支超过了预算的一倍;而且也有 2/3的项目因为第一年开发 中所存在的可靠性和 质量方面的问题而频频出现故障

[1]。

许多企业项目屡 遭失败的主要原因是 :①缺乏有效的软件 过程管理体系 , 过多地依赖 软件设 计与开 发者的个 人素质;② 大多没有建立起完善 的质量保障体系 , 忽视软件测试的重要作 用。

软件测试是软件 质量保证的关键步骤 , 软件开发生命周期 中受到最多关 注 的 就是 测 试 [2]。测 试 的 目标 是 以 最 少的 人

力、物力和时间投入 , 尽 可能多地 找出软 件中潜 在的各 种错误 和缺陷

[2]。建立良好的测试过程 管理体 系不仅 能够发 现错误

和缺陷 , 保证产品质量 , 还能够 通过对测试过程进行度量 , 辅助 组织进行过程改进 , 提高测试生产率 , 降低测试成本。

因而 , 研究有效的软件测试过程管理方法就成为近年来的

一个热点。经过软件专家 们的不懈努力 , 软件测试过程管理的 理论已相对成熟 , 测试的技术、方法和工具得到了相当的发展 , 但是对软件测试 流程的定义 及监控 却缺乏 相应的研 究。为了 使测试管理方法 能够适合不同类型软件的测试 , 适合不同软件 测试部门的测试 流程 , 开发具有软件测试流程管理功能的软件 过程管理工具就 成了一种需 要。由于工 作流技 术已经 成为目 前比较流行的过 程实现技术 , 本文的研究就以工作流技术为依 据 , 探讨如何对软件测试流程进行定义与监控。工作流技术

近几年来工 作流管理技术 逐步被应 用于过 程自动 化以及 应用系统集成中。W M f C 将工作流 定义为一种 过程 , 在该过程 中 , 文档、信息或任务等 按照一 定的过程 规则在 过程参 与者之 间传递 [3]。过程是为了实现某 个目标而 将一系 列相互 关联的 活动协调起 来的 一个 集合 [3]。工 作流 管理 系统 是用 来定 义、创建和管理工 作流的 软件 系统 [3]。W M f C 定 义的 工作流 管理 系统参考模型 [4]如图 1所示。此工作流 参考模 型定义 了工作 流管理系统的基 本结构 , 它包含工作流管理系统的主要组件以 及这些组件之间 的接口。

(1 工作流 执行服务组件(Work flow Enact m ent Serv ices 提 供了一个运行环 境 , 在该环 境中 , 利用一 个或多 个工作 流引擎 进行过程的实例 化、解释以 及激活 , 并且 支持与 外部必 要的资 源的交互。它由一个或多 个创建、管理和执行工作流实例的工 作流引擎组成。

(2 工 作流 引擎(Workfl ow Eng i ne 是一 个为 工 作流 实例 提供运行执行环 境的软件服务。

((e fi 43 第 2期 郑小军等 :基于工作流技术的软件测试流程定义与监控 并记录业务过程。它输 出一个能 被工作 流引擎 解释的 过程定 义。(4 工作流管理和 监控 组件(A d m i nistrati on &M onitor i ng 主要负责对工作流实 例的运 行进行 监控。管理 员可以 通过工 作流管理工具获得目 前各个活动的运行情况报告 , 并干预实例 的行进。

(5 工作流客 户端 应用组 件(W ork flow C li ent A pp licati on 是与活动相关的人员 进行交 互的软 件实体。通 常包括 工作列 表(W o rk list 以及工作列表管理器(Wo rkli st H andler 两个主要 组成部分。

(6 外部应用调 用组件(Invoked A pp licati ons 是指 工作流 执行服务在过程运行 中调用处理应用数据的外部应用程序。

(7 其他 工作流 执行 服务 组件(O t her W o rkfl ow Enact m ent Serv ices 是不

同的工作流管理系统之间的互操作。3 测试流程相关概念

在具体讨论软件 测试流程定义及其监控之前 , 我们先明确 文中所述的几个与软 件测试 流程相 关的概念。首先我 们先讨 论一下软件过程的定 义。软件过 程是软 件工程 界讨论 和研究 的热点之一 , 依据 C MM(能 力成 熟度 模型 的观 点 , 软件 过程 是指软件开发人员开 发和维护软件及相关产品的一套行为、方 法、实践及变换过 程

[1];从工 作流 的角 度理 解 , 软件 过程 是软

件生存周期中为达到 某个目标而 必须实 施的所 有软件 工程活 动的集合 [6]。依据 软件 过程 定义 , 我 们给 出软 件测 试过 程及 相关概念的定义如下 :

定义 1 软 件测试过 程是在 软件测 试中为 达到某 个目标 而必须实施的所有活 动的集合。

定义 2 测试阶段是软件测试 过程中的子 过程 , 是根据某 种要求对测试过程进 行的一种划分。

定义 3 测 试流程是 由测试 阶段以 及这些 测试阶 段之间 的转移关系、各测试阶段的相关数据以及测试流程控制项等构 成。

定义 4 测试流程控制项是依 据测试过程 管理的需要 , 从 各个测试阶段中提取 出来的阶段完成所必须满足的前置条件。

定义 5 测 试流程模 板指的 是用户 可以在 不同的 项目中 进行重用的测试流程。

定义 6 测 试流程实 例是指 测试流 程模板 与某个 具体测 试项目相结合 , 设定了测试 流程模 板中的 相关属性 , 用 来对具 体测试项目的流程进 行控制。

软件测试过程一 般包括四个阶段 , 即测试策划、测试设计、之间的关系、测试流程控制项和测 试阶段 基数(测试流 程所包 含的测试阶段 个数。测试 阶段 之间 的关 系主 要有 串行 和并 行两种关系。

测试阶段主 要包含计划起 止时间、实际 起止时 间、运 行状 态、启用状态等属性 , 其中运行状态 有未开始、活动、暂停、完成 四种状态 , 只有测试阶段处于活动状态时测试阶段中的功能才 能被使用 , 处于其他三种状态时都不能被使用。启用状态包含 启用和禁用两种 状态。测 试阶段处于禁用状态时 , 不受测试流 程所定义的约束 所控制 , 测 试阶段 中的功 能可以 被任意 使用;测试阶段处于启 用状态时 , 测试阶段将受到测试流程所定义的 约束的控制。

测试流程控 制项主要有启用状态和完成状态两个属性 :① 启用状态包含启 用和禁用两 种状态。测 试流程 控制项 处于启 用状态时 , 它在测试流程中 起作用;测试 流程控 制项处 于禁用 状态时 , 它在测试流程中不起作用。②完成状态包含未完成和 完成两个状态 , 分别表示测试流程控制项中定义的条件是否满 足。

测试阶段与 测试流程控制项之间的关系是 , 一个测试阶段 中可能包括几个 测试流程控制项 , 一个测试流程控制项只可能 属于一个测试 阶段。一 个测 试阶 段如 果受 流程 控制(即 测试 阶段的启 用状 态处 于 启用 时 , 那么 该 测试 阶 段 完成 的 条件 是 :当测试阶段的计划终止 时间到 达时 , 属于测 试阶段 的启用 状态为启用的测 试流程控制项的完成状态均必须为完成。

测试流程模 板就是没有对 测试流程 的相关 信息进 行设定 的 , 可以被多个项目所使用的测试流程。测试流程实例就是对 测试流程模板中 的相关信息进 行设定并 用于对 具体项 目进行 控制的测试流程。测试 流程模 板与测试 流程实 例之间 的关系 就好像面向对象 技术中类(C lass 和对象(O b j ect 的关系。

本文首先设 计一种流程定义工具 , 对测试流程模板进行图 形化的定义 , 针对具体测试项目对测试流程模板进行实例化生 成测试流程实例 , 然后通过对测试流程实例的执行和监控对测 试项目进行控制。测试流程定义与监控 1 测试 流程定义与监控系统框架

根据软件测试过程的 特点 , 本文对图 1的工作流管理系统 参考模型进行了 简化 , 将测试流程定义与监控系统的结构分为 五个模块。其 UM L 用例包图表示如图 2所示。

其中 , 测试流程定义组 件、软 件测试 流程执 行和监控 组件 以及管理组件 将在 下面说 明。测 试应 用组 件(测试 过程 管理 工具的核心内容 主要用 于管 理各测 试阶 段内 部的 数据 流转 和操作;数据外部组件主要用于对测试流程实例执行中的某些 实际数据进行相 应的描述以及外部处理 , 这两部分内容并非本 文论述的重点 , 不再赘述。

计算机应用研究 2007年 4 2 测试流程 的定义与实例化

从实现的角度讲 , 测试流程是用于定义测试过程中的测试 阶段及其关系 , 其中包括指 明测试 阶段的 开始和 结束的条 件、测试阶段本身 的信 息以 及测 试阶 段中 的测 试流 程控 制项 等。对测试流程的定义 , 可以采用基于文本和基于图形可视化两种 方式。为了方便用户的使用以 及测试流程定义的直观性 , 本系 统采用可视化图形定 义方式定义测试流程。2 1 测试流程的定义

测试流程是由测 试阶段以及 这些测 试阶段 之间的 转移关 系、各测试阶段产生的相关数据以及测试流程控制项等四种关 键元素构成 , 同时这四种元 素之间 有各种 关系 , 各个元 素本身 又有其自身特点。

测试流程的定义 是指利用现有的测试流程 , 通过裁减或者 新建一个测试流程作 为控制具体测试项目的可以重用的资源 , 这些资源被称为测试 流程模 板。这些操 作均采 用可视 化图形 操作方式 , 在测试流程模板 的可视 化绘制 和显示中 , 本

文采用 了 UM L 活动图建模 符号 的子 集 , 包括 起始 图 元、测试 阶 段图 元、并发同步图元、连接图元和结束图元 五种图元。起始图元、结束图元、并发同步图元、连 接图元 基本与 UM L 保 持一致 , 测 试阶段图元采用 UM L 中的活动图元表示。图 3为利用测试流 程定义工具绘制的串 并行四阶段测试流程。其中 , 并行的意义 表示除了测试阶段的 起止时间可以重叠之外 , 其他的前置条件 均相同;串行的意义是指后面测试阶段的开始受制于前面测试 阶段是否完成。

用户通过图形化 方式绘制测 试流程 中的测 试阶段 和它们 之间的串并行关系。绘 制的测试 流程控 制模板 保存时 必须对 以下规则进行合法性 检查 :(1 图元规则。必须有且 仅有一个起 始图元 和结束图 元;流程图中测试阶段图 元的数目必须小于等于流程模板基数;流 程起始图元的入度必 须是 0, 除流程起始 图元外的所 有图元的 入度必须大于等于 1;流程 结束图元的出度必须是 0, 除流程结 束图元外的所有图元 的出度必须大于等于 1;起始图 元与结束 图元不能相连;除了并发同 步图元 外 , 所 有图元 之间的 连线不 能超过一条。

(2 测试阶 段规 则。测试 阶段的 名称 必须 在预 先定 义的 测试阶段名称集合中 , 测试阶段之间的顺序必须满足一定的约 束。例如 , 如果预先定义了四个测试阶段 , 即测试 策划、测试设 计、测试执行和测试总结 , 那么就 不能定 义一个 名称为 测试准 备的测试阶段 , 测试设计要 么与测 试策划 并行 , 要么在 测试策 划之后出现 , 不能将测试策划放在测试设计之后。

用户在完成了测 试阶段以及 相互之 间的转 移关系 的定义 后 , 可以对属于各 测试 阶段 的流 程控 制项 的启 用状 态进 行设 定。在四阶段测试流程中 , 测试流程控制项的启用状态为启用 的意义以及所属的测 试阶段如表 1所示。2 2 测试流程的实例化

软件测试流程的 实例化是指 对选择 的测试 流程模 板所进 行的一系列操作。这些操作包 括 :首先要针对具体的测试项目 根据需要选择一个测 试流程模板 , 然

后设定测试流程控制所必 需的信息 , 在通过了合法 性检查 之后 , 最后启 用流程。实例化

表 1 测试流程控制项启用意义及所属测试阶段表 测试流程 控制项名称

启 用 意 义 所属测试 阶段 控制项 目组人 员 定义

测试项目负责人至少需 要为该项目 指定一 个 测试员、一个开发人员、一 个测试分 析员以 及 测试设计员和质量保证员 测试策 划 控制测 试需求 定 义

测试项目负责人必须定 义该测试项 目的测 试 需求

测试策 划 控制测 试计划 提 交审批

测试计划文档必须提交审批 测试策 划 等待测 试计划 审

批通过

测试计划文档必须审批通过 测试策 划 控制测 试需求 细 分和人员分配

必须进行初始的测试需求细分和人员分配 测试设 计 控制测试项覆 盖 系统判断每个测试项至 少有一个测 试用例 覆 盖 测试设 计 控制测 试用例 提 交审批

每个测试用 例必须 提交 测试 用例 审批 , 否 则 无法从草稿状态成为 定稿状态。测 试用例 的 状态必须全为定稿状态 测试设 计 控制测 试说明 提 交审批

测试说明文档必须提交审批 测试设 计 等待测 试说明 审 批通过

测试说明文档必须审批通过 测试设 计 控制测 试就绪 审 批

测试就绪文档必须审批通过 测试执 行 控制软 件问题 归 零

没有软件问题处于打开、新建、待验状态 测试执 行 控制测 试用例 执 行结果

每个测 试用 例的 执 行结 果 必须 均 不是 未 执 行 , 阻碍测试或部分测试 测试执 行 控制测 试用例 执 行

每个测试用例必须拥有至少一个执行结果 测试执 行 控制测 试任务 执 行

所有的测试任务必须是完成状态 测试执 行 控制测 试总结 报 告提交审批

测试总结报告文档必须提交审批 测试总 结 等待测 试总结 报 告审批通过

测试总结报告文档必须审批通过 测试总 结 测试流程模 板实例化中需 要对测试 流程相 关的所 有数据 进行设定 , 包括测试阶 段、测 试流程 控制项 信息的设 定。测试 阶段中主要对测 试阶段的计 划起止时 间、运行状 态进行 设定;测试流程控制项 主要对测试流程控制项的启用状态进行设定。测试流程模 板实例化完成后 , 数据合法性检查必须通过后 才能启用流程 , 对实际测试项目进行控制。这里所说的合法性 检查就是对以下 规则进行检查 :

必须对测试 阶段的计划起止时间进行设定;各个测试阶段 的起止时间不能 超出测试项目的时间范围;测试阶段的计划结 束时间不能早于 计划开始时间;一个测试阶段如果有前序测试 阶段 , 那么它的计划开始时间必须晚于前序测试阶段的计划结 束时间。3 测试 流程执行和监控

测试流程的 执行和监控 是工作流 引擎的 一个简 化。测试 流程的执行主要 是指依据测试 阶段的计 划起止 时间以 及测试 阶段之间的约束 关系对测试阶 段实行自 动启动 和自动 完成功 能;依据测试流程控制项的启用意义对测试过程产生的数据和 文档进行统计 , 并设定测试流程控制项的完成状态。测试流程 对应用程序的控 制主要是依据 测试阶段 以及测 试流程 控制项 的各种状态为测 试应用程序提供访问接口 , 进而对应用程序进 行控制。

(页 45 第 2期 郑小军等 :基于工作流技术的软件测试流程定义与监控

式函数及径向基函数 相互比较 , 最终确定采用最常用的径向基 函数;, C 等参数 采用 交叉 验证 方法(C ross V ali dati on , CV 确 定为 =1, C =103;使用 SVM C l assifi er MATLAB T oolbox 工具 包进行实验分析 , 数据为 20个 测试样 本点。预测 结果显 示如 图 2

所示。

如图 2和图 3所示 , 两幅图中的 * 和 o 分别 表示测试 样本集中信用好的企业和信用 差的企业。图 2表示 20个测试 点的真实值 , 图 3表示 20个 测试 点的 预 测值。可以 看出 , 20个测试点中绝大部分 点被正确划分 , 只有极少点划分错误。2 3 结果分析

表 1列出 了 S VM 与 PP 模 型 的 结 果 , 同 时 与 神 经 网 络(NN 所建模型的结果进行了比 较。神经网 络使用 的是 BP 算 法 , 由于神经 网络方法并 不是一种 稳定的方法 , 故表 1中神经 网络的结果是 15次的平均结果。表 1中第 一类错误是指将信 用好的企业评判为信 用差的企业 , 第二类错误是指将信用差的 企业评判为信用好的 企业。可 以看出 , S VM 与 PP 在 测试样本 集 中 的 预 测 准 确 率 达 到 了 90%, 明 显 好 于 NN 模 型 的 83 17%;我们还发现 , S VM 与 PP 的第一 类错误 率和第 二类错 误率均小于 NN 的 第 一类 错误 率 和第 二类 错 误率;从 识 别速 度 , 也就是指将原 始数 据输 入计 算机 得到 最后 结果 的时 间上 看 , S VM 与 PP

也有很大提高。3 结论

一个基本的 模式识别系统 主要是 由数据 获取、预处理、特 征提取和选择以 及分类决策 所组成。本 文主要 对其后 两部分 进行了讨论 , 提出了一种基于投影寻踪与支持向量机的模式分 类方法。该方法首先利 用投影 寻踪对传 统的指 标进行 特征提 取 , 把多维评价指标综合成 一维投 影指标 , 然后 通过支 持向量 机构造广义最优 超平面。实验表明 , 这一方法大大降低了特征 空间的维数 , 并有很好的分类正确率。

参考文献 : [1]李祚泳.投 影寻 踪 技术 及 其应 用 进展 [J].自 然杂 志 , 1997, 19(4:224-227.[2] Vapn i k.统计学习理 论的本质 [M].张学 工.北京 :清华大 学出版 社 , 2000.[3]黄晓荣 , 付强 , 梁川.投影寻踪分类模型在工程评标中的应用 [J].哈尔滨工业大学学报 , 2004, 36(1:35-38.[4]

M L Ray m er , et a l.D i m en si onalit y Reducti on U si ng Gen etic A l go-rit hm s[J].I EEE T ransacti on s on E voluti onary Co m putation , 2000, 4(2:164-171.[5] Fri edm an J H, Tu rkey J W.A P roj ecti on A l gorith m for E xp l oratory Data Anal ys i s[J].I EEE T rans.on C o m pu ter , 1974, 23(9:881-890.[6]邓乃扬 , 田英杰.数据 挖掘中 的新 方法 支持 向量 机 [M ].北

京 :科学出版社 , 2004.[7]丁欣.国外信用风险评估方法的发展现状 [J].湖南大学学报(社 会科学版 , 2002, 16(3:140-142.[8]刘闽 , 林成 德.基 于支 持向 量机 的商 业 银行 信用 风险 评估 模型 [J].厦门大学学报 , 2005, 44(1:72-75.作者简介 : 赵晓翠(1981-, 女 , 山东东阿人 , 硕士研究生 , 主 要研究方向 为运筹与 优化、支持 向量机;王 来生(1954-, 男 , 吉 林人 , 教 授 , 博导 , 主 要研究 方向为运筹与优化、数据挖掘等。

(上接第 45页 人员 对测试 流程进 行查看 和人工 干预 控制。测 试流程查看功能是指 以图形化的方式提供对测试流程的查看 , 主要包括以颜色来实 时反应测试阶段的四种状态、以对话框来 查看测试阶段的计划 起止时间和测试流程控制项的完成情况。测试流程人工干预控 制功能是指 以图形 化的方 式对测 试流程 进行人工变更 , 主要包括变 更测试 阶段计 划起止时 间、变更测 试阶段运行状态(图 4

和变更测试流程控制项启用状态。5 小结

本文首先对软件 测试流程的相关概念进行了阐述 , 然后从 概念层到实现层详细 论述了测 试流程 定义、执行 和监控机 制。本文所提出的概念和 方法已经在 北航软 件所开 发的测 试过程 ite 0, 实 项目的测试过程 以及相关文档和数据的有效管理 , 提高了软件 测试工作的效率。参考文献 : [1] [美 ]卡耐基梅隆大学软件工程研究所.能力成熟度模型(C MM :软件过程改进指南 [M].北京 :电子工业出版社 , 2001.[2]张春霞 , 苏秦.软件测试过程 分析 [J ].计算机 应用研究 , 2004, 21(5:46-48, 51.[3]W ork flo w M an age m en t Coa li ti on.T er m i nol ogy &G lossary [Z ].W F M C-TC-1011.Iss ue 3.0, 1999.[4]W ork flo w M anage m en t Coalition.The W ork fl ow Ref eren ce M od el [Z].W F M C-TC00-1003, 1995.[5]庞岩梅 , 晏 海华.基于 工作 流技 术的 软 件过 程定 义和 追踪 机制 [J].计算机工程与应用 , 2003, 39(26:69-72.[6]陶伟.以体系结构为中心的软件产品线开发 [D ].北京 :北京航空 航天大学 , 1999.作者简介 : 郑小军(1980-, 男 , 陕西渭南人 , 硕士研究生 , 主 要研究方向 为软件质 量保证;刘超(1958-, 男 , 北京人 , 教授 , 硕士 , 主要 研究方向 为软件工 程;晏海华(1964-, 男 , 湖南益阳人 , 副教授 , 硕士 , 主要研究 方向为软。

计算机应用研究 2007年

第二篇：软件测试流程

每个软件测试阶段都要经历以下步骤：测试需求分析、测试过程设计、测试实现、测试实施、测试评价、测试维护。

1.测试需求分析：整个测试过程的基础；确定测试对象以及测试工作的范围和作用。

2.测试过程设计：包括测试计划,测试策略制定，测试时间安排用，测试用例编写等

3.测试实现：环境配置好了，新的版本也收到了，人员也都培训好了等等

4.测试实施：已经按照测试计划进行展开了，比如手工测试，自动化测试等

5.测试评价：对版本测试覆盖率，测试质量，人员测试工作以及前期的一些工作制定情况进行评价

6.测试维护：对测试用例库，测试脚本，bug库等进行维护，保证延续性等

软件测试过程

软件测试过程按各测试阶段的先后顺序可分为单元测试、集成测试、确认（有效性）测试、系统测试和验收（用户）测试5个阶段，如图3所示。

(1)单元测试：测试执行的开始阶段。测试对象是每个单元。测试目的是保证每个模块或组件能正常工作。单元测试主要采用白盒测试方法，检测程序的内部结构。

(2)集成测试：也称组装测试。在单元测试基础上，对已测试过的模块进行组装，进行集成测试。测试目的是检验与接口有关的模块之间的问题。集成测试主要采用黑盒测试方法。

(3)确认测试：也称有效性测试。在完成集成测试后，验证软件的功能和性能及其他特性是否符合用户要求。测试目的是保证系统能够按照用户预定的要求工作。确认测试通常采用黑盒测试方法。

(4)系统测试：在完成确认测试后，为了检验它能否与实际环境（如软硬件平台、数据和人员等）协调工作，还需要进行系统测试。可以说，系统测试之后，软件产品基本满足开发要求。

(5)验收测试：测试过程的最后一个阶段。验收测试主要突出用户的作用，同时软件开发人员也应该参与进去。

第三篇：软件测试一般流程[模版]

一般测试流程：

1.需求分析阶段：只要就是对业务的学习，分析需求点。

2.测试计划阶段：测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。

3.测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审。

4.测试方案阶段：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要评审。

5.测试执行阶段：执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文档。

第四篇：软件测试需求分析与定义方法

软件测试需求分析与定义方法

如何确定测试工作的范围？

对于一个存在生命周期的软件产品来说，它的开发和测试往往都不是一次性的，因为随着新的需求的出现，以及对原有版本的改进，新的版本会不断的发布（即使对于一些以客户定制方式运作的项目，在开发过程中以及发布后的维护期内，也会产生众多的内部版本）。随着版本的迭代，我们的测试工作也会一直继续下去。而在每一次迭代时，可能在整个工作阶段的开始就受到一些因素的影响，比如市场需求、既定的发布时间、并发的工作导致的资源紧张等等，使我们不得不考虑对软件质量要求的适度，最终使得我们在每个阶段的测试工作的要求或者说所涉及到的内容有可能是不同的。这种变化，最终将会影响到测试需求的确定。那么到底该如何确定每次迭代是测试工作的范围呢？在笔者的实践中，通常把测试工作范围的确定，等价的认为是软件需求的确定。

不过现在有一个很实际的问题是这样：软件需求在开发过程中不断发生变化，有时候到了后期还会有新的需求添加进来，还有些需求在交付内部测试版本之后又发现原来的需求本身就存在缺陷，之后再次返工，在软件最终发布之前，怎么可能确定的下来呢。啊，这些都是让我们的开发人员和测试人员极其头痛的事情。到底应该怎样在频繁变更的需求中确定哪些部分是我们在某个阶段要测试的内容呢？或者说通过什么样的方法可以改善我们上面提到的那些问题呢？一个实际的做法就是实现软件需求的版本化控制。（用软件需求的版本化控制来解决软件需求的频繁变更）既然说到了这里，就不免要说些题外话。笔者一直都认为软件需求是开发工作和测试工作在制定计划、开展工作时所共同参照的源头和依据，而我们只有在源头上控制好，才能保证下面工作的平稳开展。如果希望某个阶段工作的进度和内容可以明确的定义下来，就必须要考虑软件需求的版本化控制。这里所提到的“软件需求的版本化控制”，是指在一个软件产品的生命周期中，当要进行一个新版本的迭代时，要尽早的确定这个版本中将要实现的需求，并同上个版本做出比较，哪些内容是新增的，哪些内容是被调整过的。在该阶段工作开始之初的工作会议上，明确的向所有需要了解软件需求的涉众传达这部分信息。而如果在该版本的开发过程中不断的出现需求变更的情况，则应该根据市场策略、已公布的发布时间、客户需求、实现的代价、难易程度以及对现有工作的影响等方面，对需求进行适度划分，严格定义当前版本中需要实现的需求，而其他部分，则作为未来版本的软件需求进行考虑。如果有的朋友认为上面的内容还是太理论化，需要一个更实际的、可操作的方法。那么只能说，对于需求的变更，以及因为需求变更而引起的设计的变更，必须要早发现，早讨论，早决定，早调整。这可能更多的要依靠一个团队中相关负责人员的主动工作来保证，而不是依靠一个明确的方法。注意，这里的一个关键是，对于软件需求，同样需要严格按照版本进行管理，或者说使用“基线”进行管理。如何整理测试需求？一旦当前阶段测试工作的范围确定下来，我们就可以开始考虑测试需求的整理——也就是明确的定义现阶段要“测什么”。测试需求的确定将为我们制定进度时间表、分配资源以及如何确定某个阶段测试工作是否完成提供一个可供衡量的标准。当然，还有更重要的一点，已被确定的测试需求是我们进行测试用例设计和考虑测试覆盖的依据。整理测试需求的第一步，就是要“测试需求”。测试需求？对，不知道您是否想到，这里的“测试需求”中的“测试”是一个动词，指的是对软件需求本身的检查。

啊？这不是已经超出了测试工作的范围了吗？测试人员不是应该只关心软件的实现同需求是否相符吗？这样对测试人员要求未免太高了。——这是笔者过去同一些朋友谈到测试人员必须对需求进行检查时听到的一些不同的声音。在这里，首先要明确一个问题，就是软件测试的工作到底做什么？

在《软件测试》（Ron Patton〔美〕，中文版由机械工业出版社出版，这本书是测试新手入门的经典教材）一书的第10页，有一个明确而简洁的定义：软件测试员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。

瞧！这里说要“尽可能早”的“找到软件缺陷”。那这“尽可能早”要早到什么时候呢？

不知道大家对《软件工程》这本书还有什么印象。至少在笔者看过的多个不同版本的软件工程方面的书中，对于软件缺陷都会有一段类似的描述：缺陷发现的越早，则修复这个缺陷的代价就越小，在需求、设计、编码、测试、发布等不同的阶段，发现缺陷后修复的代价都会比在前一个阶段修复的代价提高10倍（参见下图）。这样看来，上面问题的答案自然就变成了“秃子头上的虱子”：从需求阶段开始！从“测试需求”开始！

注意，笔者这里的观点并不是说可以取消团队中的“需求评审会议”，这里并不存在冲突。笔者所希望讲述的，是测试人员应该如何看待软件需求，而并不是把“需求评审会议”所承担的责任揽到自己身上。?在论坛上也偶尔看到有的朋友问：如何测试需求呢？每次看到这样的提问，笔者内心就禁不住的一阵激动，因为一直以来，讨论这方面问题的朋友的确少之又少。

在笔者的实际工作中，对软件需求的检查包括两个方面的内容。

一是对软件需求正确性的检查，也就是要保证需求文档中所描述的内容是真实可靠的。在进行这部分工作时，不要迷信所谓的“都是用户提出的真实的需求”，因为我们必须考虑，提出这些需求的涉众，是否真的可以正确的描述自己的需求？我们的需求人员是否真的可以正确的理解用户的需求？有没有一些被用户认为在业务处理上是理所当然、极其平常的事情，而没有作为需求提出来？有没有一些被用户认为他们过去使用的软件已经提供了相应的功能，所以认为我们也应当提供，而没有提出来的？关于这个问题，也曾经有朋友提过不同的看法，认为这样对测试人员的要求太高了——既要熟悉需求人员的工作，又要熟悉软件所涉及的行业的业务。但笔者还是固执的认为，作为测试人员，还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解——当然，这不是对一个刚刚入门的测试者的要求，但是如果想称为一个优秀的测试者，是难免要付出这部分努力的。

二是要保证软件需求的可测试性。对于“可测试性”，笔者的概念是：对于一条软件需求或者一个需要实现的特性，必须存在一个可以明确预知的结果，并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证。说的具体一点，就是要保证所有的需要实现的需求都是可以用某种方法来明确的判断是否符合需求文档中的描述。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证，或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷，应该请需求人员对需求文档进行修改或补充——我们有理由相信，如果作为测试人员对需求无法产生准确的理解，那么开发人员也同样无法对同一条需求产生准确的理解。对于一条确定的软件需求理解的二义性，是在不规范的开发过程中导致返工的一个主要原因。如果认为有必要，那应该在“需求评审会议”上确认所有涉众对需求的理解是一致的。当然，对于如何提高软件需求的质量，在网络上或者已经出版的书刊中都已经有了很多更加具体、实用的方法，如果有兴趣，大家也可以找来参考。不过，如果您是一位测试者，那么上面这部分内容对您仍然是非常有用的。相信您只要在工作中进行尝试，慢慢的体会，一定会发现这种方法给您带来的好处。?现在当前的测试工作范围已经确定，相应版本的软件需求也通过了评审，我们就可以在这个已经确定的范围内进行测试需求的整理。我们手头上可以参考的东西，通常会有软件需求规约（以下简称SRS）和用例（以下简称UC）——当然，也可能是一份包含UC的SRS。通过对SRS和UC的阅读，我们可以从文档对特性和业务流程的描述中获得对软件所涉及的业务的一个基本的认识。比如用户在处理实际业务时都要作些什么，多个业务之间的先后顺序是怎样的，用户在处理业务是对于哪些地方有特别的要求，等等。这部分规则，将成为我们的测试需求中最基本的一部分。

至于测试需求的表现形式，笔者认为大家都可以根据自己的需要进行设计，而没有必要把思路限制在到底使用表格方式还是使用文本方式，只要把握一个原则就行了：在一条测试需求中，用容易理解的自然语言，明确的描述一项需要测试的内容。对于多项测试内容，应尽可能的剥离开来，保证一条测试需求只包含一项测试内容。

另外，大家也可能注意到了，在软件开发过程的这个阶段，通常是没有用户界面（以下简称UI）可供参考的——虽然RUP中对于需求阶段的工作描述包括了UI设计的部分，但很多时候在这个阶段还是无法提供一个确定的UI的——也就是说我们这时获得的测试需求，将是完全基于业务的，而并不包括基于UI的那部分规则，是同软件的最终具体实现相独立的。

随着开发工作的继续，开发部门的架构设计文档和详细设计文档也将陆续提交，这时候，我们可以根据设计文档来对已有的测试需求进行增补。注意，这里我们对于设计文档中提到的内容要有选择的采用，只有同SRS或UC中已经定义的部分相符的内容，才可以用来调整我们的测试需求。而同软件需求不相符的部分，则需要同设计人员和需求人员一起讨论，确定下以哪一方作为基准，决定是否需要调整软件需求，然后对测试需求进行相应的增补或者调整。比如对于一些算法，需要考虑设计文档中定义的，同系统实现相关的那些计算公式，是否同软件需求中描述的算法表达的是否是同一个意思？而对于一些约束或者业务规则，设计文档中描述的是否同需求中的相应部分一致？呵呵，看完上面这部分内容，恐怕又有一部分朋友晕倒在地了，而没有晕倒的那部分朋友也要提出异议：啊？！你这不是又包含了对开发人员所作的设计工作的检查吗？！刚刚让我们检查需求，现在又让我们检查设计，真的把我们当成全才了！没办法，为了让软件交到我们手上的时候只包含尽量少的缺陷，大家只能再辛苦一下了。我们的工作不应当仅仅限制在软件交付后尽力找到存在的缺陷，而更应该努力及早发现软件缺陷出现的苗头，尽量预防缺陷的出现。虽然并不是说在所有的团队中都应该由测试人员承担“测试需求”和“测试设计”的工作，但是测试人员对这些工作起到的作用，是其他团队中的其他角色所无法替代的。开发部门完成编码实现工作，提交供内部测试的应用程序时，测试人员手头上应该已经准备好了绝大部分测试用例和测试数据，测试部门将开始执行测试。通常在我们执行测试的过程中，即使我们已经从“通过测试”和“失败测试”两个不同的角度准备了非常充分的测试用例和测试数据，但总是有些缺陷的出现是出乎我们意料的，或者说是已有的测试需求和测试用例未能覆盖的。那么，对于这部分缺陷，也应当添加到测试需求中，并设计相应的测试用例，以便于下次版本迭代时进行参考。OK，相信说到这里，各位看客也应该可以理解我的观点了：对于一个长期发展的团队或者持续开发的产品，它的所有东西都是要不断积累的、不断迭代的。无论对于软件需求还是测试需求，不仅仅是在一个版本的开发过程中，在不同的阶段进行迭代，在产品的整个生命周期中的不同版本间，也是不断迭代和积累的。

第五篇：软件测试技术与管理方法探讨论文

1自动化测试

传统的测试已经无法满足测试的需要，自动化测试应运而生，自动化测试是指在预设条件下运行，包括正常条件和异常条件，自动化主要研究的是自动化框架测试、自动化测试脚本技术、自动化用例生成。通过资料了解，C-ATFM模型。该模型基于C语言，面向对象集成环境，采用源码嵌入有效的分析软件的代码、词法、语法、策略、指令。并且随着软件工程及软件测试的发展，自动化的机器测试发展更有前景。

2下面简介软件测试的过程

2.1模块测试

模块测试主要针对软件设计中的程序模块，通过测试技术测试程序块是否正确，模块测试的主要目的是测试程序内部的错误，根据程序设计的结构检查代码和程序是否合理，是否符合设计思路和理念，是否能够正常运行。

2.2组装测试

在模块的基础上，需要将所有模块的功能全部测试完成后组装成为系统，组装测试的目的在于，连接所有模块之后，模块之间的接口、触发器是否能正常运行，并且计算显示的数据是否正确，模块之间的功能是否互相冲突，是否达到预期的目的和结果显示，是否构成正确的、预期的数据结构。不同模块之间的误差有多少，有多少可以解决，有多少不能解决。

2.3确认测试

确认测试的目的是验证软件的功能和特性是否达到预期的愿望，是否能按照预期的组织结构、系统结构、用例分析和时序分析运作，并且进行验收测试和安装测试。

2.4系统测试

系统测试是确认软件是否与硬件互相支持，是否能满足软件使用者对软件的需求和操作简便的愿望，比如说查询模块运行完后界面中查询条件应该为查询之间输入的查询条件。系统测试保证了系统的正常运行，另外很重要的就是权限测试，系统在研发之初定义的权限信息和权限功能是否实现，是否发现软件成品与软件定义不符合或者矛盾。

3软件测试技术的地位

一个成功的测试用例在于发现了至今尚未发现的缺陷。其实，软件编程的过程也会出现一些不可避免的错误，例如：对于用户需求的错误分析和编程出现的一些语法错误，如果软件与发票费用相关更是与测试密不可分。软件不断地接近成熟和完成以及投入使用阶段，软件测试工程师必须更加谨慎的检测每一部分程序，一段程序的完成，测试工作量占有总工作量40%以上，这就给我们说明：测试是软件开发成功的重要组成部分。