中文04中文测试员5

1、No.52 0 0 5 . 0 2THE SOFTEWARE TESTING ENGINEERING MAGAZINE 普及&共享&交流&提高2005 年 02 月第五期测试员电子期刊?本期导读2第页欢迎访问我们的网站 - ?主办方： 测试时代投稿： 主编： http审阅： Seanhe协作： Aken ? 软件测试的新模型 . 通常情况下，一个软件模型说明的内容主要包括，在测试过程中你应该考虑到哪些问题，如何对测试进行计划，测试要达到什么目标详见 P3. ? 嵌入式软件测试策略 .在嵌入式领域目标系统的应用系统日趋复杂，而由

2、于竞争要求产品快速上市，开发技术日新月异，同时硬件发展的日益稳定，而软件故障却日益突出详见 P15.? Rational Clear Quest 技 巧集.收集和整理了 Rational ClearQuest 常见的问题详见 P20.? Junit 之走马观花篇. 我们细致地研究 JUint 框架并思索如何来构造它。我们发现了许多不同层次上的教训。在本文中， 我们将尝详见 P26. ? 利用 Jmeter 测试 WebSphere 性能.本文描述如何部署 Apache 开放源代码工具 JMeter ， 以基于 IBM WebSphere Application Server 和 WebSphe

3、re Branch Transformation Toolkit（ BTT）来测试中间件解决方案的响应性详见 P43.? 软件测试要不要追究 Bug 发生的原因.软件测试到底要不要追究 BUG 发生的原因呢？这个问题的争议很多，有人认为寻找 BUG 的原因是开发的事情，软件测试只要能发现 Bug详见 P52.? 使用 IBM Rational 的测试理念成功打造测试团队.测试在所有的软件开发过程中都是最重要的部分。在软件开发过程中，一方面要求我们通过测试活动验证所开发的软件详见 P54.第 3 页2005 年 02 月第五期测试员电子期刊一、 软件测试的新模型 作者：Brian Marick

4、翻译：Blueski通常情况下，一个软件模型说明的内容主要包括，在测试过程中你应该考虑到哪些问题，如何对测试进行计划，测试要达到什么目标，什么时候开始，在测试中你要用到哪些信息资源。一个好的模型可以引导你对问题进行思考，而不好的模型则只能使你误入歧途。 这里我要宣称的是，目前的大多数软件测试模型都是不好的模型。这是因为这些测试模型仅仅是软件开发模型的一些装饰和补充而已。 人们一直在苦苦寻找软件开发的模型，在创建了新的模型后，就把测试作为一个阶段放在模型的后面部分。因此测试总被作为一种事后行为，测试总是被开发所驱动。总的来说， 我们是在检测他们的完成品。但是， 作为事后处理的测试， 其驱动方式是

5、不正确的。实际上它显而易见地和开发过程中各种行为之间有关，测试没有起到应有的平衡作用。这样的测试只是检测了开发人员做了什么，而并没有检测到他们是否按照规则做了什么， 这样的做法割裂了本该紧密联系的行为， 剩下的只有那些匆忙而草率的想法所带来的伤害。 而这样做的结果就是效果很差的、效率很低的测试。效果很差的测试将导致很多bug 没有被发现，而效率很低的测试所浪费的是成本。 在本文中，我要做 2 件事，其一，我要一个不好的模型，即 V 模型。我希望通过论述来表明，“单元测试” 和“ 集成测试” 这 2 个词汇可以从我们的词汇表中取消了。其二， 我将描述一个更好的模型。不过首先我认为，要真正拥有一个

6、充分合理的模型还为时尚早。我仅仅是描述了一些新模型应该符合的重要的要求。这些要求将在本文末尾处列举。 1. V 模型有什么问题呢？ 在本文中我要把 V 模型作为不好的模型的典型来进行分析。我选择 V 模型作为分析的典型是因为 V 模型是最广为人知的测试模型。 最典型的 V 模型版本一般会在其开始部分对软件开发过程进行描述，如下图所示： 欢迎访问我们的网站 - ? 第 4 页2005 年 02 月第五期测试员电子期刊图 1-V 模型的各级开发阶段 这是古老的瀑布模型。作为开发模型，它有很多问题，不过这里不作讨论。尽管它的各种状态是我们接着要讨论的大家最熟悉的 V

7、模型的基础。我的意见同时也针对其它的装饰在一些更好的开发模型之上的测试模型， 例如螺旋模型Boehm88。 在 V 模型中，测试过程被加在开发过程的后半部分，如下图所示： 图 2-V 模型示意图 单元测试所检测的是，代码的开发是否符合详细设计的要求。集成测试所检测的是， 此前测试过的各组成部分是否能完好地结合到一起。系统测试所检测的是， 已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。 对于测试设计，显而易见的是，V 模型的用户往往会把执行测试与测试设计分开对待。在开发文档准备就绪后， 就可以开始进行相关的测试设计。如下图所示， 相应的测试设计覆盖在

8、了相关的开发过程之上： 欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊图 3-将测试设计覆盖了开发过程后的 V 模型 V 模型有着很吸引人的对称外形，并且把很多人都带入了歧途。本文将集中讨论它在单元测试和集成测试中引起的问题。 为了说明的方便，这里专门制作了以下图片，图中包括一个单独的单元，以及一个单元组， 我称之为子系统（ subsystem）。 图 4-一个假想的子系统 对于一个单元应该多大才最为合适的问题，已经有过很多的讨论，究竟一个单元仅仅是一个函数，一个类， 还是相关的类的集合？这些讨论并不影响我在这里所要阐述的观点。我们权且认为

9、一个单元就是一个具有最小程度的代码块，开发人员可以对进行独立地讨论。 V 模型认为人们首先应该对每一个单元进行测试。当子系统中所有的单元都已经测试完毕， 它们将被集中到一起进行测试， 以验证它们是否可以构成一个可运行的整体。 那么，如何针对单元进行测试呢？我们会查看在详细设计中对接口的定义，或者查看源代码， 或者同时对两者进行查看， 找出符合某些测试设计中的有关准则的输入数据来进行输入， 然后检查结果， 看其是否正确。由于各单元一般来说不能独立地运行，所以我们不得不另外设计桩模块（ Stub）和驱动模块（ Driver），如下图所示。 5第页欢迎访问我们的网站

10、- ?2005 年 02 月第五期测试员电子期刊图 5：单元及其外部的驱动模块和桩模块 图中的箭头代表了测试的执行轨迹。这就是大多数人所说的“单元测试” 。我认为这样的方法有时候是一种不好的方法。 同样的输入也可以有同一子系统中的其它单元来提供，这样，其它的单元既扮演了桩模块， 又扮演了驱动模块。如下图所示： 图 6-子系统内部各单元间的测试执行轨迹 到底选择哪一种方法，这需要一种折衷和权衡。设计桩模块和驱动模块要付出多少代价？这些模块如何进行维护？ 子系统是否会由此而掩盖了一些故障？ 在整个子系统范围内进行排错的困难程度有多大？ 如果我们的测试直到集成测试时才真正开始， 那么一些 bug 可

11、能较晚才被发现。由此造成的代价同设计桩模块和驱动模块的代价如何比较？ 等等。 V 模型没有去考虑这些问题，当单元开发完成后就执行单元测试，而当自系统被集中在一起后就执行集成测试， 仅此而已。令我奇怪和沮丧的是， 人们从不去做一些权衡， 他们已经受制于他们的模型。 因此，一个有用的模型应该允许测试人员考虑节省并推迟测试的可能性。 一个测试，如果要发现一个特定的单元中的 bug，最好是在该单元保持独立的情况下执行， 并且在其外部辅以特定的桩模块和驱动模块。而另一种方法则是让它作为子系统的一部分来进行测试，该测试的设计主要是为了发现集成的问题。由于一个子系统本身也需要桩模块和驱动模块来模拟该子系统和

12、其它子系统的联系，因此， 单元测试和集成测试可能被推迟到至少整个系统已经部分集成的时候。在这种情况下，测试者可能通过产品的外部接口同时进行单元测试、集成测试和系统测试，同样的， 其主要目的还是为了减少总体生命周期的成本，对测试成本和延期进行测试及由此造成延期发现 bug 的代价成本进行权衡。据此而言， “单元测试”、“ 集成测试” 和“ 系统测试” 的区别已经大大削弱了。其结果可参考下图： 6第页欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊 图 7-新的方法：在部分阶段延迟进行单元测试和集成测试 在上图右边的方块中， 最好要改成为“执行某

13、些适当的测试并得到相应的结果”。 图中的左边会怎样？ 考虑一下系统测试设计，它的主要根据和信息来源是是规格说明。假设你知道有 2 个单元处在一个特定的子系统中， 它们在运行时相互联系， 并且要执行规格说明中的一个特定的声明。为什么不在该子系统被集成时立即对此规格说明中的声明进行测试， 就象是在设计完成后立即开始测试的设计一样呢？ 如果该声明的执行和子系统外的子系统没有任何关系， 为什么还要等到整个系统完成以后再测试呢？ 难道越早发现 bug 成本越低不对吗？ 在上一张图片中， 我们用了向上指的箭头（ 更有效， 但在时间上有延迟）。这里还可以把箭头往下指（ 在时间上提前）： 图 8-新的方法：在

14、不同阶段上提前进行测试设计 7第页欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊在这种情况下，左边的方块中最好被标记为：“在当前信息条件和情况下可以做的任何测试设计”。这样， 当测试设计得自于系统中某一个组件的描述时，模型必须允许这样的测试在组件被装配之前被执行。我必须承认我的图片非常难看， 这些箭头指得到处都是，对此我有 2 点说明： 1. 我们所讨论的事情不是创造美，而是想要发现尽可能多的严重错误，同时尽可能地降低成本。 2. 难看的部分原因也是因为必须按照某些次序来执行的结果，亦即开发人员先提供系统描述文档， 然后测试和这些文档进行关

15、联。这些文档就象是坚实的老橡树，而测试设计则象是细细的枝条缠绕在树上。如果我们采用不同的原理来进行组织， 图片可能就会变得好看些。但复杂性仍不可避免， 因为我们要讨论的问题本身就很复杂。 V 模型失败的原因是它把系统开发过程划分为具有固定边界的不同阶段，这使得人们很难跨过这些边界来采集测试所需要的信息。有些测试应该执行得更早些， 有些测试则需要延后进行。而且， 它也阻碍了你从系统描述的不同阶段中取得信息进行综合。例如， 某些组织有时执行这样的做法， 即对完成的工作进行签署。这样的规定也扩展到系统测试的设计。签署表示已经过评估，该测试设计工作已经完成， 除非对应的设计文档改变， 否则就不会被修订

16、。如果同这些测试相关的信息后来被重新挖掘和认识， 例如， 架构设计表明有些测试是多余的， 或者，详细设计表明有一个内部的边界可以和已存在的系统测试组合在一起进行测试的话， 那么实际上还需要继续调整原来的系统测试设计。 因此，模型必须允许利用不同来源的综合信息进行个别的测试设计。另外，模型还应该允许在新的信息来源出现后重新进行测试的设计。 2.一个不同的模型 让我们来看本文的第二项内容，一个不同的模型。 很多时候人们把代码移交给其他人，并且说：“希望你能接受和喜欢它。” 这不仅发生在将整个项目放在一张光盘中交给客户的时候， 也发生在项目内部。 例如，一个小组对另一个小组说：“ 我们已经完成了为

17、COMM 库加入了对 XML 的支持。源代码现在已经放在 master 库中， 可执行库则已经加入到集成与创建的环境中。XARG 小组的工作已经没有什么阻碍了， 随时去取吧。” 某个程序员检查了 bug 的修改并且发出邮件：“我已经修改了 Bug 列表中的那个Bug， 很抱歉！” 至此， 早先受该问题影响的其它代码就可以继续处理了。 在这些情况下，人们要把代码移交给其它人，其中有可能会存在一些影响。测试人员需要干预这个过程。在移交之前，测试人员应执行这些代码，发现其中的 bug8第页欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊（ 影响），

18、 并且提出问题：“ 你确实要提交这些吗？” 由此， 移交的内容可能会被延期， 直到 bug 被修复好。 尽管你还要做其它的各种测试，这项测试仍然是很基本的测试工作。如果你没有做这样的测试， 就不能算是合格的测试人员。 我们的测试模型必须包含这一重要的现实需要：针对代码移交的测试。由此，测试模型应提示进行针对每一次代码移交的测试。 就让我以支持 XML 的 COMM 库作为例子。这里存在着一个小组把代码移交给 XARG小组以进行项目的余下部分。那么谁会遭受影响？ 要将这些支持 XML 的代码直接进行使用的 XARG 小组可能会立即受到影响； 这可能会在稍后影响到市场人员，他们要在一个行业展示会议

19、上为“合作伙伴发行”版本提品演示和宣传，而 XML 支持是影响他们销售的重要部分； 还有， 它可能损害采纳我们的产品的合作伙伴。 现在我们可以提出一些有趣的关于测试计划的问题了。最简单的可以做的事情是，在移交的时候立即执行 XML 支持的完整测试。（“ 完整” 的含义是， 为此设计尽可能多的测试）但也许一些 XML 特性并不是 XARG 小组所需要的，因此可以把它们放在合作伙伴版本封版（ 下图中的“ Partner Release”）的测试中去。这意味着可以把一些 XML 相关测试放到稍后的移交过程中去。或者基于其它理由， 例如在近阶段有其它的测试任务要执行。而 XARG 小组则要因 XML

20、中的 bug 修复而延迟一小段时间。 我们的测试计划所表示的进度可以通过在开发的时间线上进行注解的方式来表现，如下图所示： 图 9： 添加在开发计划之上的测试计划 我们应严格地围绕在 XML 支持的功能交接的时段里进行测试。测试设计和测试支持工作要早于测试执行。而另外的 XML 测试则要延迟到基于整个项目范围的“ 代码第页9欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊完成”（ 图中的“ Code Complete” 里程碑），或者要等到全部的子系统被集中在一起，而且整个产品为了行业会议而在经过稳定化处理后创建了版本（ 图中的“ Partn

21、er Release” 里程碑）。 显然， 有两项内容没有包含在代码完成里程碑中： 还有大量其它的测试工作（ 包括设计、工具选用）。这些工作可能因为 COMM 以外的子系统的交接而延期。而且， 还有用于完成里程碑中所规定的某些风险的测试， 例如， 可能还有一组用于运行市场人员的演示 Demo 脚本的测试， 包括她可能在无意中引起的偏离。其目的是要避免这样的情况， 即当她站在1000 人的观众面前时， 她还仅仅是第一次以某种特定的顺序来输入数据。 一些首次交接时进行的 XML 测试需要在代码完成里程碑上再次执行。 我的观点是，测试计划是由很多困难的决定所组成，这些决定包括人员组织安排、机器资源配

22、置、测试设计的时间定位、测试支持代码的数量、哪些测试要做自动化， 等等。这些决定应根据单独的交接中的内容信息来作出。如果仅有一次交接， 那么你可以更顺利一些。测试计划还应继续考虑以下问题： 1. 风险分析， 谁会因此受到损害， 以什么方式？ 2. 选定一种测试途径来定位特定的风险。 3. 对测试设计和执行的周期和成本进行估计。 4. 在项目进度上的特定位置， 将计划纳入执行的行动： A. 开始对测试进行设计 B. 同时设计和创建一些支持测试的代码 C. 在全部测试完成以前就执行部分的测试， 因为可能存在不只一次的交接，在每一次交接的测试规划中， 可能存在一些潜在的复杂的相互影响。工作安排不得不

23、进行一些调整以达到相互间的平衡。测试支持代码和工具需要在各项任务中得到共享。你还必须考虑到在什么程度上让那些为早先的交接所设计的测试在以后重新执行， 等等。 这看起来很复杂。看上去似乎有太多的内容需要跟踪，而且太多的内容可能被忽略。也许你认为我是在要求你要对每一次交接来执行 IEEE 829 IEEE98中关于测试计划的要求， 然后把它们合并为一份贯穿整个项目的针对交接进行测试的测试计划。 是， 也不是。思考问题总是要占用时间的。太多的计划可能会减少结果的产出。在有些时候，你需要做的是停止计划并开始行动。例如，你无法思考并描述每一个bug 修复， 尽管 bug 修复也是一种交接。 但是 bug

24、 修复是实际工作中现实存在的问题。总体项目计划中应该包含 bug 修复。10第页欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊需要强调的是，你应该有一个默认的 bug 修改处理的标准过程，该过程应包括运行于每一个提交的 bug 修复的验证过程。你还需要努力地去思考问题。很多时候， 各项验证是被放在一起同时进行并完成的。 比较现实地来说，一个模型应该允许一些机械式行为， 例如， “ 不管是哪一个 X 类型的交接，都要执行下列操作” 。同时我们鼓励对特定的交接执行刚刚够的检查， 对于风险越小的交接， 就越可以采用机械式的测试行为。 一个明确考虑

25、到基本的测试现实的模型肯定会比忽略这些现实或者把你的工作复杂性完全抽象化的模型做得更好。文档则是另一个例子。 我还没有提到需求及规格说明书，或者设计文档。某个交接中产生的一系列变化会引起很多争议。这些文档所扮演的角色是什么呢？它们常常是这么被使用的： 图 10：测试中对开发文档的利用 文档可以指导你在一个交接变化时如何做出反应。如果你有一份很好的需求文档， 它可能是产品所解决的问题的描述， 尽管也许不是很直接。它可以帮助你对风险进行分析。一份好的规格说明应对系统的行为进行描述。这将帮助你把测试方法转化为具体的测试。一份好的架构设计则可以帮助你理解变化可能引起的几种不同的情况： 系统的其它部分会

26、受到怎样的影响？ 什么测试需要再次进行？ 我并不是经常能看到好的文档。需求文档常常象是市场销售用的系统特性列表。规格说明书有时就象是在代码完成后提交的用户手册文件。而设计文档经常不存在。 好了，通过针对交接所引起的变化的集中讨论，我已把测试过程和软件开发过程相对地分离开了。如果文档中关于“ XML 支持功能加入到 COMM” 的描述很薄弱的话， 我会尽自己所知来进行尽可能好的测试设计。然后， 假如在项目后期， XML 相关的 用户文档出来了， 我就可以对后来再次提交的交接增加相关的测试。假如市场需求改变了， 她们经常会这么做， 我还会在此后增加或者去除一些测试。所有这一切看起来是这样的： 11

27、第页欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊 图 11-在文档不完整的条件下进行测试，并在后期补充测试 这样，虽然项目文档总是不到位，而且经常延迟提交，测试的效果也因此常常被降低， 我们还是要避免测试受到项目文档的制约。 头脑灵活的测试人员并不过于相信文档。毕竟，总是人在犯错误。那么，难道不是人在写这些文档吗？ 由于“ 正式的” 文档是很薄弱的，测试模型必须明确地鼓励在测试过程中使用项目文档之外的各种不同信息来源。 测试人员必须和程序员、用户、市场人员、技术作者以及任何的可能为实现更好测试提供线索的人进行交流。测试人员还应该努力把自己

28、沉浸在某些技术所构建的氛围中。例如， 我希望测试人员在做 XML 测试工作时常去访问 W3 组织的 XML 地址（ /XML/）以及其它 XML 站点、邮件列表，甚至包括比较特别的 如 Dave Winer 的 DaveNet/脚本新闻（ /）。这些资源并不是所谓的“ 辅助通道” ，而是可以被列入计划和进度日程的资源。 另外，所执行的测试本身也是一种有用的信息的资源。好的测试人员会仔细阅读bug 报告， 因为这些报告讲授了系统所存在的薄弱之处。特别地， 这些报告还暗示了一些正式的架构设计所没有提供的架构上的策略。执行

29、测试的行为应该产生一些新的测试想法。如果模型没有考虑到这些， 那么它就是一个落后的模型。 因此，测试模型应该包含反馈的循环，让测试设计可以考虑到，在运行测试时还可以继续发现到更多的测试内容。 在我们的工作中，真正的复杂性来自于所有计划的执行都处于一个不确定的、容易忽略的环境里。代码并不是唯一在不断变化的东西。而计划日程也在改变。新的功能扩充会带来新的里程碑。某些功能会从当前版本中去除。在开发过程中， 所有人-市场人员、开发人员和测试人员， 都会逐渐对诸如“ 产品究竟提供什么” 这样12第页欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊的问题

30、有越来越清晰的了解。在这些情形下， 我们怎么能说测试计划的第一个版本会是完全正确的呢？ 因此，模型应该要求测试计划人制定明确的规定，对已交接的交接内容，新的交接， 以及交接内容的变更进行负责。 3. 总结 V 模型有以下的缺陷， 其它模型实际上也与此相似： 1. 忽略了这样的事实情况， 即软件开发是由一系列的交接所组成， 每一次交接内容都改变了前一次交接的行为。 2. 依赖于开发文档的存在， 及文档的精确性、完整性， 并且没有对时间进行限制。 3. 认定一种测试的设计是依据某一个单独的文档，而不包括根据其前后阶段的文档的修改而作相应修改。 4. 认定这些依赖于某个单独文档的测试一定要在一起执行

31、。 我大致描述了一个替代模型， 但还不够精细。它考虑到了代码的交接和里程碑。对测试成本控制作了以下明确描述： 测试设计的目标是定义好可能发现 bug 的测试输入，而测试执行的目标是以各种方式加入这些数据， 并检验结果，由此来降低整个生命周期的成本。 我们的模型假设软件产品总是不完美的，开发过程中有很多变更，而且对产品的测试也是一个不断学习的过程。 过去， 我很少考虑到模型。表面上我一直还在用 V 模型。虽然我按此制订计划， 但我总是还要花费很多额外的精力和时间来考虑模型中没有提到的方面。换言之， 模型造成了一些阻碍， 因此我有必要对此进行研究。 对一个新的模型来说，对模型所提出的要求必须非常明

32、确，这就象业务需求对产品开发非常重要一样。我希望自己对本文中所提倡的模型的要求的描述能够和 V 模型中的描述一样精确， 并具有同样的指导意义。 理想的测试模型应该包括下列要求： 1. 使测试对项目中的每一次代码交接有所反应。 2. 要求测试计划人制定明确的规定，对已交接的交接内容，新的交接，以及交接内容的变更进行负责。 13第页欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊3. 在测试设计中，除了使用项目文档外，还应明确鼓励使用其它各种信息，这些信息有不同来源。 4. 事实上项目文档总是不到位，而且经常延迟提交，测试的效果也因此常常被降低。

33、但我们还是要尽量避免测试受到项目文档的制约。 5. 允许根据多种来源提供的综合信息来设计一些独立的测试。 6. 让测试被重新设计， 以新的信息形式进行表现。 7. 包含反馈的循环，让测试设计可以考虑到，在运行测试时还可以继续发现到更多的测试内容。 8. 让测试人员认识到， 避免测试的延迟可以节省成本。 9. 在组件被组装到程序中去之前对组件的执行进行测试。 感谢 是 James Bach 最早让我认识到，在测试计划中应考虑到交接。Noel Nyman 和 Johanna Rothman 在一份草案中提供了一些有帮助的评论。Kamesh Pemmaraju 和 Carol Stollmeyer

34、使我终于没有放弃对原理的辩解和阐述， 不仅是在细节方面， 也在实际生活中， 以及每一个实际项目中。他们给了我很大的促进， 使我去地思考问题。 参考Boehm88Barry W. Boehm, “A Spiral Model of Software Development and Enhancement,” IEEE Computer, 1988 年 5 月IEEE98IEEE Standard for Software Test Documentation, IEEE 标准 829-1998, 电子和电气工程师学会, 1998Marick98Brian Marick, “When Should

35、 a Test be Automated?” 国际质量（/pub/papers/automate.pdf）,1998 年 5 月14第页欢迎访问我们的网站 - ? 北京慧灵科技有限公司依托测试时代资源，推出面向实践的软件测试专业课程，由国内著名软件企业的一线技术专家主讲，为您的企业解 决实践中的关键问题。如果您培训的目的不是拿一个证书，而是想学习 软件测试的最佳实践，那我们会是您一个不错的选择。 详情请登陆公司网站： 2005 年 02 月第五期测试员电子期刊二、嵌入式软件测试策略作者： a

36、dmin在嵌入式领域目标系统的应用系统日趋复杂，而由于竞争要求产品快速上市，开发技术日新月异，同时硬件发展的日益稳定，而软件故障却日益突出，软件的重要性逐渐引起人们的重视，越来越多的人认识到嵌入式系统的测试势在必行。提到嵌入式软件测试，首先要简单介绍一些软件工程的一些观点，现在，被普遍接受的软件的定义是：软件(software)是计算机系统中与硬件(hardware)相互依存的另一部分，它包括程序(program)、相关数据(data)及其说明文档(document)。其中程序是按照事先设计的功能和性能要求执行的指令序列；数据是是程序能正常操纵信息的数据结构；文档是与程序开发维护和使用有关的各

37、种图文资料。 对于一般商用软件的测试，嵌入式软件测试有其自身的特点和测试困难。 由于嵌入式系统的自身特点，如实时性(Real-timing)，内存不丰富，I / O 通道少，开发工具昂贵，并且与硬件紧密相关 CPU 种类繁多，等等。嵌入式软件的开发和测试也就与一般商用软件的开发和测试策略有了很大的不同，可以说嵌入式软件是最难测试的一种软件。 嵌入式软件测试使用有效的测试策略是唯一的出路，它可以使开发的效率最大化，避免目标系统的瓶颈，使用在线仿真器节省昂贵的目标资源。自从出现高级语言，开发环境与最终运行环境通常都是存在差异的，嵌入式系统更是如此。开发环境被认为是主机平台，软件运行环境为目标平台。

38、相应的测试为 host-target 测试或 cross-testing。 讨论嵌入式软件测试首先就会遇到一个问题：为什么不把所有测试都放在目标上进行呢？因为若所有测试都放在目标平台上有很多不利的因素： 1）测试软件，可能会造成与开发者争夺时间的瓶颈，避免它只有提供更多的目标环境。 2）目标环境可能还不可行。 3）比起主机平台环境，目标环境通常是不精密的和不方便的。 4）提供给开发者的目标环境和联合开发环境通常是很昂贵的。 5）开发和测试工作可能会妨碍目标环境已存在持续的应用 从经济上和开发效率上考虑，软件开发周期中尽可能大的比例在主机系统环境中进行， 其中包括测试。 15第页www.ltes

39、欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊 确定 host-target 测试环境后，开发测试人员又会遇到以下的问题： 1）多少开发人员会卷入测试工作（单元测试，软件集成，系统测试）? 2）多少软件应该测试，测试会花费多长时间？ 3）在主机环境和目标环境有哪些软件工具，价格怎样，适合怎样? 4）多少目标环境可以提供给开发者，什么时候? 5）主机和目标机之间的连接怎样？ 6）被测软件下载到目标机有多快? 7）使用主机与目标环境之间有什么限制（如软件安全标准）? 任何人或组织进行嵌入式软件的测试都应深入考虑以上问题，结合自身实际情况，选定合理测试策略和方案

40、。 对于嵌入式软件测试或叫交叉测试（cross-test），在测试的各个阶段有着通用的策略： 1单元测试： 所有单元级测试都可以在主机环境上进行，除非少数情况，特别具体指定了单元测试直接在目标环境进行。最大化在主机环境进行软件测试的比例，通过尽可能小的目标单元访问所有目标指定的界面。 在主机平台上运行测试速度比在目标平台上快的多，当在主机平成测试，可以在目标环境上重复作一简单的确认测试，确认测试结果在主机和目标机上没有被他们的不同影响。在目标环境上进行确认测试将确定一些未知的，未预料到的，未说明的主机与目标机的不同。例如，目标编译器可能有 bug，但在主机编译器上没有。 2集成测试： 软件集成

41、也可在主机环境上完成，在主机平台上模拟目标环境运行，当然在目标环境上重复测试也是必须的，在此级别上的确认测试将确定一些环境上的问题，比如内存定位和分配上的一些错误。 在主机环境上的集成测试的使用，依赖于目标系统的具体功能有多少。有些嵌入式系统与目标环境耦合的非常紧密，若在主机环境做集成是不切实际的。一个大型软件的开发可以分几个级别的集成。别的软件集成在主机平台上完成有很大优势，越往后的集成越依赖于目标环境。 16第页欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊3系统测试和确认测试 所有的系统测试和确认测试必须在目标环境下执行。当然在主机上

42、开发和执行系统测试，然后移植到目标环境重复执行是很方便的。对目标系统的依赖性会妨碍将主机环境上的系统测试移植到目标系统上，况且只有少数开发者会卷入系统测试，所以有时放弃在主机环境上执行系统测试可能更方便。 确认测试最终的实施舞台必须在目标环境中，系统的确认必须在真实系统之下测试，而不能在主机环境下模拟。这关系到嵌入式软件的最终使用。 包括恢复测试、安全测试、强度测试、性能测试，已超出了软件测试的范畴，本文暂不讨论。 使用有效的 cross-test 测试策略可极大的提高嵌入式软件开发测试的水平和效率，当然正确的测试工具使用也是必不可少的： 总结一下，应用以上测试工具进行.Cross-test

43、时的策略： A) 使用测试工具的插装功能（主机环境）执行静态测试分析，并且为动态覆盖测试准备好一插装好的软件代码。 B) 使用源码在主机环境执行功能测试，修正软件的错误和测试脚本中的错误。 C) 使用插装后的软件代码执行覆盖率测试，添加测试用例或修正软件的错误，保证达到所要求的覆盖率目标。 D) 在目标环境下重复（B），确认软件在目标环境中执行测试的正确性。 E) 若测试需要达到的完整性，最好在目标系统上重复（C），确定软件的覆盖率没有改变。 通常在主机环境执行多数的测试，只是在最终确定测试结果和最后的系统测试才移植到目标环境，这样可以避免发生访问目标系统资源上的瓶颈，也可以减少在昂贵资源如在

44、线仿真器上的费用。另外，若目标系统的硬件由于某种原因而不能使用时，最后的确认测试可以推迟直到目标硬件可用，这为嵌入式软件的开发测试提供了弹性。设计软件的可移植性是成功进行 cross-test 的先决条件，它通常可以提高软件的质量，并且度软件的维护大有益处。以上所提到的测试工具，都可以通过各自的方式提供测试在主机与目标之间的移植，从而使嵌入式软件的测试得以方便的执行。 使用有效的 cross-test 测试策略可极大的提高嵌入式软件开发测试的水平和效率，提高嵌入式软件的质量。 17第页欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊附录： 1

45、). HOST-TARGET 的连接方法简介： 图 1- 直接连接 图 2 - 通过仿真器连接 18第页欢迎访问我们的网站 - ? 2005 年 02 月第五期测试员电子期刊 图 3 - 使用介质进行间接连接 图 4 - 使用 PROM 等传递被测软件 图 5 - 测试的交互界面19第页欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊图 6 - 无交互界面的连接-三、Rational ClearQuest 技巧集 作者： pyp & http 前提： Rational ClearQuest 的版本为 2002.

46、05.00 问题一： 给某些字段设置使用权限， 只有相关人员才能看到某些字段而进行填写，对于一般人员使它变为不见， 我该如何设置呢？ 解答提示：一个比较简单的方法可以让别人看不到你设置的字段：设置一个新的组，把想看新字段的人加到这个组中，在 Designer 中，设置 Forms 的时候，加一个 Tab页， 把只想让一部分人看到的字段都加到这个页中， 鼠标右击这个字段，在属性页中， 有“ User Group Access” 这个选择， 选择你想要看的组加到列表中就可以了。在使用的过程中， 只有相关的组成员才能看到这个 tab 页， 也就间接的等于别人看不到这些字段了。 问题二：在 Web 端

47、访问的时候，只能看到提示“ Restricted Query Not Defined” 。 解答提示：一般是因为没有注册的缘故，使用 CQ 的过程中，必须对 Web 服务器进行License 注册。 问题三： 如何让一些 Database 不显示在客户端和 Web 端的使用列表中。 20第页欢迎访问我们的网站 - ?2005 年 02 月第五期测试员电子期刊解答提示： 在使用 CQ 的过程中， 必须选择 Database 才可以进入客户端或 Web 端。而 Database 的内容， 与选择的 Schema Repository(s)有关，下面就是如何让部分Da

48、tabase 不显示在列表中。 在 Designer 中， 选择菜单中的 Database-Update User Database Properties，选择不需要显示的 Logical Database Name， 点击“ Properties” 按钮，进入配置页面。在配置页面中， 把“ Production Database”选择为“ Test Database” ， 点击“ Update” ， 则此 Database 将不会显示在列表中。如果将来想要恢复， 只要把“ Test Database” 再选择成“ Production Database”即可。 问题四： 在 project

49、的 Forms 下， 我为项目经理设计了一个下拉列表框， 请问： 如何将 users 下面的 field:login_name、fullname 下面的记录值自动在这个下拉列表框里显示。格式就是： login_name(fullname)。 解答提示： 这个我并不清楚你要做什么， 是在下拉框中显示所有用户的登陆名和全称， 还是显示一个组的， 或者是显示当前登陆用户的？ 如 果 显示 当前 用 户的 ，则 比 较 的简 单。 直接login_name=session.GetUserLoginName,full_name=login_name.fullname,把login_name 和 full

50、_name 拼成一个字符串显示出来就可以了。 如 果是 在 组 中的，你 可以查看安装 目 录 ClearQuestapihelpindex.htm中Session Object，User Object，Group Object，Groups Object 几章。我的想法是：在 field 的 Choice List 中， 使用程序进行列表内容的控制， 建立一个 session，使用 session.GetUserGroups 取到用户组， 再 for each user in 用户组，在里面choices.additem(user)，但是我试验了一个上午，不知道什么原因，一直都没有成功过，你

51、不妨再仔细的看看 Rational ClearQuest API Reference 里面的东西吧。如果能解决， 最好告诉我解决的办法， 我也学习学习。 问题五： 对于特定的字段， 强制要求用户每次 Action 的时候， 都必须填写。 解答提示： 在字段的 Permission 中，用下面的代码控制： SetFieldvalue Field1, 把字段的值设置为空 Field_Permission=AD_MANDATORY 让字段必填 在 Behaviors 中把需要必填的字段状态设置成 Hook 就可以了。 21第页欢迎访问我们的网站 - ?2005 年 0

52、2 月第五期测试员电子期刊 问题六：在 Clearquest Designer 里设置 Field 时那些 Type 都代表什么意思？ 比如， Type 里的 REFERENCE,REFERENCE_LIST 都是什么类型， 设置成这个类型后， 会出现什么结果？ 您能给我详细说一下吗？ 解答提示：在 ClearQuest Designer Help 中的 Selecting a field data type 中有相应的说明。 ClearQuest supports the following field data types: Data Description/Comments ATTACH

53、MENT_LIST: Allows records to store files related to the record. DATE_TIME: SQL date and time. INT: SQL integer. MULTILINE_STRING: A variable-length string of unlimited size. REFERENCE: A reference to a unique key in a record type.For REFERENCE type fields, you must select a state-based or stateless record type to refer to. You can also enter