ImageVerifierCode 换一换
格式:DOC , 页数:18 ,大小:198KB ,
资源ID:149377      下载积分:20 文钱
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,省得不是一点点
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.wenke99.com/d-149377.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: QQ登录   微博登录 

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(第4代白盒测试方法介绍理论篇.doc)为本站会员(创****公)主动上传,文客久久仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知文客久久(发送邮件至hr@wenke99.com或直接QQ联系客服),我们立即给予删除!

第4代白盒测试方法介绍理论篇.doc

1、 www.cse-soft.org All right reserved by WAYNE. Page 1 of 18 第 4 代白盒测试方法介绍 理论篇 密级:内部公开 作者: wayne 版本: V1.0 第 4 代白盒测试方法 介绍 理论篇 2005-12-15 拟制: Wayne Chan 2005-12-15 审核: 2005-01-01 审核: 2005-01-01 批准: 2005-01-01 www.cse-soft.org All right reserved by WAYNE. Page 2 of 18 第 4 代白盒测试方法介绍 理论篇 密级:内部公开 作者: wayne

2、 版本: V1.0 文档修改说明: 序号 修改描述 时间 责作人 版本 1 完成初稿 2005-12-19 wayne 1.0 文档分发列表: 序号 角色 文档接收者 分发时间 说明 www.cse-soft.org All right reserved by WAYNE. Page 3 of 18 第 4 代白盒测试方法介绍 理论篇 密级:内部公开 作者: wayne 版本: V1.0 目 录 1 背景 .4 1.1 白盒测试的范围 . 4 1.2 第 1 代与第 2 代白盒测试 . 4 1.3 第 3 代白盒测试方法 . 5 1.4 第 4 代白盒测试方法的产生背景 . 5 2 什么是第

3、4 代白盒测试方法 .6 3 为什么持续集成 .7 3.1 JOEL 测试 . 7 3.2 持续集成不是 XP专有实践 . 8 3.3 为什么持续集成 . 8 4 第 4 代白盒测试方法的关键特征 .9 4.1 在线测试 . 9 4.1.1 脚本驱动与脚本桩 .9 4.1.2 在线测试逻辑更新 . 10 4.1.3 拉通测试小循环 .11 4.2 灰盒调测 . 11 4.2.1 白盒测试的粒度 .11 4.2.2 检视器 . 12 4.2.3 调试就是测试 . 13 4.2.4 编码、调试、测试集成平台 . 14 4.3 持续测试 . 15 4.3.1 测试设计先行 . 15 4.3.2 如何

4、持续保障信心 . 16 4.3.3 重构测试设计 . 17 5 结论 . 17 参考资料 . 18 www.cse-soft.org All right reserved by WAYNE. Page 4 of 18 第 4 代白盒测试方法介绍 理论篇 密级:内部公开 作者: wayne 版本: V1.0 关键词: 白盒测试 第 4 代 测试方法 4GWM 在线测试 持续测试 灰盒 脚本驱动 脚本桩 摘 要: 本文 是 第 4 代白盒测试方法 的 理论介绍, 描述 3 个关键 领 域 内 9 项 关键特征 的概念与固有特征 。 同时 介绍白盒测试发展历程 , 对比 说明 第 4 代 白盒测试

5、方法 与以往 测试 方法的异 同及 优化 要素 。 缩略语: 4GWM: The 4th Generation White-box-testing Methodology,第 4 代白盒测试方法 XP: Extreme Programming,极限编程 TDD: Test Driven Development,测试驱动开发 IID: Incremental and Iterative Development,渐增迭代开发 CSE: Common Script Engine,通用脚本引擎(一种近似于 python 的 脚本语言) PCO: Points of Control and Observ

6、ation, 观察控制点 TDF: Test Design First,测试设计先行 MCDC: Modified Condition/Decision Coverage 1 背景 1.1 白盒测试的范围 白盒测试是 软件 测试体系 中 一个分支, 测试 关注 对象是 一行行可见 代 码, 如果 代 码不可见就 不是白盒,是 黑盒测试了 。 白盒 测试也通常被认为是单元测试与集成测试的统称,但这个概念是相对的, 与当前项目遵循的 研发 流程 有 关 ,某些流程 把白盒测试划分为单元测试与集 成测试,而另一些流程, 把白盒测试划分为模块单元测试、模块系统测试、多模块集成测试 , 还有一些 流程

7、把 单元测试与集成测试混为一体,统称为持续集成测试 。 随着测试技术的发展,白盒 测试 的概念也在 发生 变化,比如,本 文提倡一种 介于白盒与黑盒之间的 灰盒 操作 模式 , 针对 被测对象同样是可见源码 , 这时, 白盒测试不 只 是白盒了 。尽管如果此, 我们仍遵循大家习惯的思维 方 式 把本文倡导的测试方法仍冠名为:第 4代白盒测试方法 ( 4GWM, The 4th Generation White-box-testing Methodology) 。 本文 讨论白盒测试方法,范围限定在 功能测试之前,针对源码行的 所有 测试,即,被测对象是 看得到的功能 源码,每个测试者必须 先

8、获 得 源码才能 实施 测试。 1.2 第 1 代与第 2 代 白盒测试 说到第 4 代 白盒测试 方法,就不能不回顾前 几 代方法。 在测试发展初期,测试工具很不成熟,人们通常以单步调试代替测试, 或采用 assert 断言 、 print 语句等 简单 方式 的 组织 测试体系, 即我们所谓的 第 1 代白盒测试,这一 时期的 测试是半手工的,没 实现 自动化,测试效果 也 严重依 赖测试者(或者调试者)的个人能力, 缺少 统一 规范的评判标准。 当然 , 调试 算 不算测试 在 业界尚 存 争议, 单论 调试的目的 (为了定位问题) 与操作方式 (过程不可重复) ,不应把调试看 作 测试

9、, 但调试 确能发现软件 BUG,显然 这 也 是一种测试手段。本文 暂不评判 调试 用 作测试手段是否合理 , 但有必要 先 确 定 调试是 测试的 某种形式,把它 看作特定历史阶段或特定 场景 下的产物 。 特定历史阶段大家比较容易理解, 调试伴随编程 语言是天生的,测试工具 却是 后天 形成,开发 人员 总喜欢认调试器 当 亲妈,测试工具则是爱管不管的 后妈 。 特定场 景 是什么? 比如,某种生僻的 RTOS 平台 根本找不到 对 应测www.cse-soft.org All right reserved by WAYNE. Page 5 of 18 第 4 代白盒测试方法介绍 理论篇

10、 密级:内部公开 作者: wayne 版本: V1.0 试工具 , 怎么办 ? 拿 调试做测试是无奈之中的必然。 这里, 我们 不 否 认 调试 也是一种测试 ,在此基础上 再 优化 其 操作过程,使调试能更好的服务于测试 ( 下 文 介绍 “灰盒调测”还有进一步论述) 。 第 1 代白盒测试方法 存在严重缺陷, 主要 有 : 测试过程 难以 重用 , 成功经验无法拷贝, 测试 结 果也 难以 评估 并 用 于 改进,这 些 对 于 团队运作是非常致命的。 到第 2 代白盒测试 , 上述 主要 缺陷 得到 克服 , 将测试操作 改用 一种形式化语言(通常称为测试脚本)来表述, 脚本可以组 合

11、成用例,用例 可组合 成测试集,用例与测试集 再 统一到测试工程 中管理 ,把 测试脚本 保存到文件, 重用 问题 解决了 。 另外, 代码覆盖率功能 使测试结果 可 以评估, 能 直观的看到哪些 代码或分支 未 被 覆盖 , 然后 有针对性的增加测试设计 。目前市 面上有大量商用工具,如 RTRT、 CodeTest、 Visual Tester、 C+ Tester 等都属于这第 2 代白盒测试工具。 1.3 第 3 代白盒测试方法 按理说,第 2 代 白盒测试 工具已经很完善了, 那 第 3 代又是什么? 软件测试是一门复杂科学,支持 自动测试与覆盖率评估 后 不见得就能成功 实施 白盒

12、测试 ,尤其重要的是,第 2 代白盒测试解决了重复测试问题,但没解决持续测试 问题 。 简单来说,重复测试 使 测试操作 能 以 规范格式 记录 , 当被测对象 没 变化(或变化 很少 )时 , 测试用例是可重 用的, 但 如果 源码大幅调整 (甚至重构) , 或 者 按 迭代 模 式不停追加 新 功能时, 如何 维持 用例 同步增长,并 与 源 码 一起 同步更新 , 已 经 不是简单的 增 强用例 复 用 能力 就 能 解决的 。 因为代 码更新与用例更新交织进行,测试用例与被测源码一样对等的成为日常工作对象, 必然 促使原有 工作模式与 测试 方法 产生变革 , 概括 而言 , 白盒测试

13、过程要从一次测试 模式 过渡到持续测试模式。 第 3 代白盒测试 工具以 xUnit 为代表,包括 JUnit、 DUnit、 CppUnit 等, 当然,我们列举xUnit 工具,并不说这些第 3 代工具就比第 2 代工具要好 。 事实上, 目前 xUnit 工 具 在 功能 上 普遍赶不上第 2 代商用工具,许多 xUnit 工具甚至连基本的 覆盖率 都 支持不了, 况且,xUnit 使用被测代码的编程语言 写用例, 普遍 效率低下。 这里, 我们区别第 2 代 方法 与第3 代 方法 , 主 要 是测试理念上差别, 而 不以 工具 差别为基准 , 因为 工具配套跟进 还 与诸多现实 因素

14、相关, 是另一层面话题 。 1.4 第 4 代白盒测试方法 的 产生 背景 xUnit 是 XP 实践的重要支撑工具 , XP 作为一种软件 开发 方法论, 总体 虽然敏捷,但很脆弱 ,它对程序员非常友好,但对组织不是 。 以 xUnit 为代表的 XP 测试实践 同样 表现 出 这一 特质, 据已有 案例 分析, XP 持续集成 在 java 项目中成功的很多, C+有一些, C 语言项目就很少 了 , 为什么编程语言对持续集成 的 影响如此 深远 ? 第 4 代白盒测试 尝试 解决软件测试 的 深层次 矛盾:测试的投入产出比问题。 大家知道,研发资源总是有限的,你可以把测试人员与开发人员的

15、比例配到 1:1,也可以配到 2:1,甚至5:1,但你做不到 10:1、 100:1,如果你有钱 ,也有人 , 完全 可以 按 100:1 或更高比例 配置,这时 所有测试瓶颈都没了 , 你可以让测试人员 边喝咖啡边干活 ,因为每 新 写 1 行 代 码总有人编出 100 行 脚本 测 试 它,还怕产品不稳定吗? 不过 , 疯子才 会 这么 做,比尔盖 兹 有 的是钱 , 一年捐款十多亿 美金 ,但不见得微 软 旗下 产品 就 经常让测试人员比开发人员多 出 一 倍。我的意思是, 测试资源 必然 是受限的, 这个前提下我们才讨论 第 1 代、第 2 代 白盒 测试向第 3 代、第 4 代演化的

16、必要性。 基于同 样 原理的 xUnit 工具 ,针对 不同 开发 语言 效果 截然不同 , 这 说明 什么? 说明 这种 实践的 瓶 颈 仍在 投入产出比上 , 也就是 上面所说 的 1:1 效果,www.cse-soft.org All right reserved by WAYNE. Page 6 of 18 第 4 代白盒测试方法介绍 理论篇 密级:内部公开 作者: wayne 版本: V1.0 还是 2:1,抑或是 5:1 效果。 高效平台下的高效工具可以 大幅 提高测试效率, 测试投入与开发投入 之比 小于 1:1 就能保证 测试质量 , 项目 就 成功 了 ,而低效平台下的低效工

17、具, 必然 要投入 更多测试 资源 (比方5:1)才能保证效果, 拐点就在这儿, 哪个公司禁得起 5:1 的测试投入 ?! 从 这个意上说,推出第 4 代白盒测试方法意义重大,我们要 尝试解决 决定项目成败的拐点问题。 事先申明一下,下 文 涉及 持续集成与 测试先行 (或称测试驱动开发, TDD)实践,虽然这两者 都 是 XP 的重要组成部分, 但我们 无意宣扬 XP, 事实上,真正能适应 XP 的项目范围并不宽, 跳过需求与预设计直接启动项目的做法,足以让客户敬而生畏, 把文档 丢 给狮子,那是无政府主义 散 兵 游 勇行径 。 不过 , XP 确有 许多闪闪发光的实践, 持续集成只要运用

18、恰当 还 是不错的 模式 , 测试先行 的 理念 也 不赖, 只要不 过度实施就好。 2 什么是 第 4 代白盒测试方法 第 4 代白盒测试方法 ( 4GWM) 针对前几代测试方法不足提出, 许多理念仍继承第 2 代与第 3 代测试方法。 下表简要的列出第 1 代到第 4 代白盒方法的主要差别: 是否 评估测试 效果 是否自动测试 是否持续测试 是否调测一体 第 1 代白盒测试 方法 否 否 否 否 第 2 代白盒测试 方法 是 是 否 否 第 3 代白盒测试 方法 是 是 是 否 第 4 代白盒测试 方法 是 是 是 是 上表中,“ 是 否评估 测试 效果” 指是否有覆盖率 或 其它评估测试

19、效 果 的指标,“是否自动 测试” 指是否 形式化描述测试操作并将它用于再次测试, “是否持续测试” 指是否 以按 持续集成 的 模式 开展 测试, “是否调测一体” 指 是否将 测试设计 高效的融入 产品 编 码 与调试 的日常实践之中 。 第 2 代白盒测试与第 3 代的分水岭在于“是否持续集成”,或许您会说, 我的项目也是经常出版本,反复追加测试用例的呀,请注意, 这是两个概念, Joel 测试 改进代码的 12个步骤中有一条:“ 编写新代码之前 先 修复故障吗? ” , 先 修复故障是质量优先的项目,否则进度优先 ,这是 两种 完全不同的行事风格, 前者时时测试, 始终每写一两个函数就

20、补全相关测试用例, 测试 实践是融入开发全过程的,而后者 依 时间表 行事, 测试 仅 是 特定 阶段里 的任务。 对了,测试方法怎么跟 软件开发方法扯上了 ? 因为测试不是孤立的, 测试是否有效强烈依赖于软件 工程 方法, 就 像 早期 的 开发语言,只有 assert 语句与 测试相关,发展到现有的 C#,单元测试框架也是该语言的固有组件了。 测试脚本也是一种产品代码, 测试方法实际与软件开发方法密不可分的,这在第 3 代与第 4 代白盒测试中体现得很充分。 第 4 代白盒 测试 方法 相对第 3 代方法,增 加 了 将测试过程(包括测试设计、执行与改进)高效的 融入开发全过程, 这里,“

21、高效的”是关键词, 那 如 何才算高效 呢 ? 我们 先简单了解 4GWM 在 3 个关键领域 的 9 项 关键特征 ,如下: A. 第一关键域:在线测试 1、 在线测试驱动 2、 在线脚本桩 www.cse-soft.org All right reserved by WAYNE. Page 7 of 18 第 4 代白盒测试方法介绍 理论篇 密级:内部公开 作者: wayne 版本: V1.0 3、 在线测试用例设计、运行,及评估改进 B. 第二关键域: 灰盒调测 4、 基于调用接口 5、 调试即测试 6、 集 编码、调试、测试 于 一体 C. 第 三 关键域: 持续测试 7、 测试设计先

22、行 8、 持续保障信心 9、 重构测试设计 3 为什么持续集成 为什么要持续集成?这个问题太重要了, 我们 专门拎出来 讲 ,请大家 先 不 急 于 跳 过本章去看 4GWM 的 9 个关键 特征 怎么定义的。 3.1 JOEL 测试 Joel 是个怪人,当然他不认识我,我 拜 读 他的 Blog 才 知道 他 的 。 这家伙 总有许多稀奇古怪的思想在小脑 瓜 里蹦达, 他是“ 经常放猫出来 闲逛 ”的 人 。 科学研究表明,人的大脑只占体 重 2%,却消耗 20%的 能量,当大脑思考问题时,释放出的能量 等 同 于夜间放一只猫出来活动。 他 的“ Joel 说软件”专栏( )很火, 有一些

23、不乏真知灼见。 比如, Joel 测试 改进 代码的 12 个步骤 : 1、 有 版本 控制机制吗? 2、 能一步完成编 译链接 吗? 3、 每天都做编 译 吗? 4、 使用缺陷跟踪库 吗? 5、 编写新代码之前 先 修复 缺陷 吗? 6、 有最新的进度表吗? 7、 有规格说明书吗? 8、 程序员拥有安静的工作环境 吗? 9、 你用到了你资金能力内可买到的最好工具吗? 10、 有测试人员吗? 11、 要求 新聘人员在面试时编 写代 码 吗 ? 12、 进行走廊可用性测试吗? 每个 问题可以回答“是”或者“否”,答“是”则加 1 分,得 12 分是完美, 11 分勉强接受, 10 分以下问题就大

24、了 ,大家有兴趣看看你所在的组织能打多少分。 有测试人员吗? 干嘛这么问,没测试人员还叫软件公司吗? 这个问题并不可笑, 还真有 不少 公司 从 未 配 置 过 专职 测试人员。 某白炽灯 生产 商 在使用说明中特 意 声 称 ,灯泡不能往嘴里塞,否则 会 出严重医学事故,说明书中还郑重其事 的介绍灯泡不慎入 口 后 , 如何求医,如何抹润滑 剂, 如何左转 90 度右转 90 度 慢 慢 取出来。 有 人觉得滑稽, 谁 白痴 有事没事拿灯泡往嘴里 送 ? 即使 放 嘴里 了 也不用这么麻烦吧? 非得试试, 结果 如何? 怎么也拿不出来了 , 只得嘴里 叼个 灯泡 打的上医院, 最后, 医生按

25、 照 说明书 费 老 劲 才 将 那玩意卸下。 所以,不要轻易否定 前人 经验, 早有人试过了。 看看 上面 12 个步骤, 前 5 步活脱脱 在讲 如何 实施 持续集成, 若 进一步了解 其内容,大家www.cse-soft.org All right reserved by WAYNE. Page 8 of 18 第 4 代白盒测试方法介绍 理论篇 密级:内部公开 作者: wayne 版本: V1.0 不妨浏览 Joel 的 Blog 原文。 3.2 持续集成不是 XP 专 有实践 持续集成属于 IID(持续迭代开发) 方法学, 在 测试 上 , 就现实而论 是 以 xUnit 实践 为代

26、表 , 持续集成 概念 被 XP 刻上 深深 烙 印,但它确非 XP 专有实践。 早在 20世纪 60年代 IBM的 Federal Systems Division就开始应用 IID开发模式了, 源于 IBM的 集成产品开发流程( IPD) 相对 CMM, 有个 显 著 特征, 它 支持 渐增迭代开发, 虽然 迭代频度比不上微软每日 构造 , 但其理念仍是持续 的迭代开发。有意思的是, IPD 流程在华为公司本土化后, 发展出 “ 版本火车 ” 理论, 有点 类似于 Scrum 实践了, 版本火 车 不仅让产品 (通常是大产品) 版本发布 更加规范有序 ( 因为火车总是定点出发的 ) ,也

27、推动 研发以更 快 频 度 推 陈出新 。 但目前持 续 集 成仍在有限范围 能 成功应用 , 微软无疑是 个 样板, 毕竟 纯软件 产品 容易实施每日构造, 还有不少 实践 XP 的 项目 , 持续集成 也运用得很成功 。 所以,就整体而言,持续集成能否成功,已经不是方法论问题,更多是 IT 工具 如何 支撑 的 问题。 3.3 为什 么 持续集成 我们看 一 个实际案 例,某通信产品在 V1 版本编码完成时,进行过规范的单元测试活动,之后 V2、 V3 要 不断 增 加功能 、 修 改功能 , 就 放弃 单元测试 了 , 当 V3 最后 市场交付时 统计发现 ,相对 V1 版本 , 代码

28、修改 量已 达到 40%。 QA从 其中 两个模块 随机抽取 100 个问题单 做 缺陷分析, 结果发现 : 第一个模块 有 50%的问题是在 V1 版本单元测试结束后引入的, 而另一模块也有 30%问题是 单元测试后引入的。 也就是说,在 第一次 完整 单元测试 之 后 , 代码 修改了 40%,也 因此 产生了 40%的 问题, 由于增量 白盒测试难以实施, 这些问题 都 被遗留到 后期 功能 测试 中 才 发现 。 单元测试没能持续开展, 带来后果是:发现问题不彻底,付出代价也更高。 上述模式 在业界 还 普遍存在, 我们 称为 一次测试, 与持续测试 不同 ,一次测试 的 测试设计只

29、做一次, 用例 仍 可 重复 拿来跑 , 因为测试 脚本 与源码 不 同步, 用例 维护是 间歇 进行的,或者干脆 不维护。 注意, 一次测试与持续测试的差别不 在于用例是否 可 重用, 而 在于 测试设计的持续性。 许多企业 做不到持续测试 ,其 主要 原因不是不想做, 第一次 测试 都认真做了, 追加 代码 或修 改代码当然 也 要做测试, 做不了 是因为操作上存在困难。 持续测试是需要一开始就规划,测试工具要 配套 跟 进 才能 顺利 实施 的 ,对于 老产品,代码 修修补补 ,无论 一次测试还是持续测试 都很难 做得好 。 引入持续测试,不仅 以更低代价发现更多问题 ,更重的是, 它体

30、现 了 一个组织在 测试 理 念上 有质的 飞跃 。 一次测试是一种被动测试, 开发人员 受 制 于组织纪律 ( 或主管、 QA 等压力 ) 才去做,而 持续测试 是 主动 测试 , 大家在测试 中 尝到甜 头,从原先不自觉 状态 ,过渡到自发、自觉 的 时时做 测试。 这两种情形无疑有天壤之别, 前面提到 的 Joel 测试 12 步 骤 ,实际上是微软实践, 与 持续 集成相关的有 5 条,足见 它的重要性, 是 否 引入 持续 集成 ,以及实施 的 效果如何, 实际 反映 了 一流公司与二流公司的差距。 www.cse-soft.org All right reserved by WAY

31、NE. Page 9 of 18 第 4 代白盒测试方法介绍 理论篇 密级:内部公开 作者: wayne 版本: V1.0 4 第 4 代白盒测试方法 的 关键特征 白盒测试是一 项 实践性很强的技术, 我们讲第 4 代白盒测试方法,离不开相关 测试实践,尤其是测试工具支撑 。 本文的上篇先从理论上介绍什么是 4GWM,下篇 则结合 具体测试工具介绍 4GWM 的典型实践。 4.1 在线测试 4GWM 第一 个 关键域是在线测试,包 括 3 个关键特征: 在线测试驱动 在线脚本桩 在线测试用例设计、运行,及评估改进 一次 白盒测试 中 (即一个用例 中 ) 我们关注被测单元 功能 是否 实现

32、,被测单元作为整体,在特定环境下 运 行(比如某些全局变量取特定值、某些依赖线程或任务已启动等) , 具有特定的输入输出, 这 几项 都属于“测试驱动”。 另外 ,被测单元若能正确运行,还依赖它调用的子函数 是否提供 正常功能 , 这些 子函数我们称 为 “测试桩” 。 分层结构如下图 : 在 三 层实体中, 被测单元 是 测试 关注对象, 要求 尽可能 真实, 我们 设法 维持 其 原状, 测试驱动与测试 桩 可以模拟 ( 或叫仿真 ) ,允许 存在一定失真,但 要求尽可能高效 ,否则测试产出的拐点问题解决不了 。 4.1.1 脚本驱动与脚本桩 先回答一个基础问题,编写测试用例应优先采用脚本

33、语言,而不 与 被测代码使用 同一 的语言,为什么? 还是应为 软件测试 的 深层次问题 投入产出比, 如果被 测编程 语言 的抽象度 较低、封装性差,用起来就很麻烦 。 比如 拿 C 或 C+写 测试 用例, 得处处小心 内存 操作, 要正常申请释放 、 注意不 越界 ,时常关心使用 变量 是否安全、是 否已初始化 等。 也许有人说,不对, CppUnit 中拿 C+测 C+, 我用得很爽呀? 噢 ,没错, 我得先恭喜这位老兄,你是好同志呐, 安于现状 不失为 一种 好 品质 。 我们设想一下, 编写一万行 C+代码,你要写多行代码 测试它,一千行?两千行? 不对,是一万行, 按 业界 普遍

34、 规律,测试代码 行 至少 要与 被测 代码 行数 相当才见 效果, 测试代码要不要调试?当然要调, 天哪,算出来的了, 测试投入至少是开发投入的 三 、四 倍才做得下来(后期 还有 功能测试、性能测试 、兼容性测试 等 等, 还要占用大量精力) ,这 样的 项目是不是处在能否成功的拐点上? 所以, 如果 您 还在用 C、 C+等过程语 言 写用例,请尽快换到脚本语言, 如 python、 ruby、 CSE 等 , 用脚本 语言能让你编写用例 的 效率提高 3 到5 倍。 www.cse-soft.org All right reserved by WAYNE. Page 10 of 18

35、第 4 代白盒测试方法介绍 理论篇 密级:内部公开 作者: wayne 版本: V1.0 用脚本 编写用例,意味着测试驱动与测试桩仿真也用脚本 语言 。我们看一下 VcTester 工具使用的 测试 脚本 ,假定被测 对象是 C 代码 的 冒泡排序算法 : void BubbleSort(OBJ_DATA_PTR *ObjList, int iMax) int i,j,exchanged; OBJ_DATA *tmp; for (i = 0; i = i; j-) if ( ObjCompare(ObjListj+1,ObjListj) Data() Data(): return -1; end else return 1; end; vd.ObjCompare.stub(StubFunc); # 打脚本桩 vd.BubbleSort(vd.gList,6); # 发起测试 assert(vd.gList0-Data Data); # 检查 测试 结果 vd.ObjCompare.stub(nil); # 清除脚本桩 脚本驱动是指 将被测系统的全局变量与全局函数映射到脚本系统,然后 使用脚本 读写 C语言变量,调用 C 语言函数。 在 VcTest

Copyright © 2018-2021 Wenke99.com All rights reserved

工信部备案号浙ICP备20026746号-2  

公安局备案号:浙公网安备33038302330469号

本站为C2C交文档易平台,即用户上传的文档直接卖给下载用户,本站只是网络服务中间平台,所有原创文档下载所得归上传人所有,若您发现上传作品侵犯了您的权利,请立刻联系网站客服并提供证据,平台将在3个工作日内予以改正。