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
