用TestDirector生成的测试用例

　　　　　　　　　　　　　　　　嵌入式测试
第一部分：简介
嵌入式系统是将先进的计算机技术、半导体技术和电子技术和各个行业的具体应用相结合后的产物，这一点就决定了它必然是一个技术密集、资金密集、高度分散、不断创新的知识集成系统。今天嵌入式系统带来的工业年产值已超过了1万亿美元，1997年来自美国嵌入式系统大会(Embedded System Conference)的报告指出，未来5年仅基于嵌入式计算机系统的全数字电视产品，就将在美国产生一个每年1500亿美元的新市场。美国汽车大王福特公司的高级经理也曾宣称，“福特出售的‘计算能力'已超过
了IBM”，由此可以想见嵌入式计算机工业的规模和广度。1998年11月在美国加州圣*何塞举行的嵌入式系统大会上，基于RTOS的Embedded Internet成为一个技术新热点。
美国著名未来学家尼葛洛庞帝99年1月访华时预言，4～5年后嵌入式智能(电脑)工具将是PC和因特网之后最伟大的发明。我国著名嵌入式系统专家沈绪榜院士98年11月在武汉全国第11次微机学术交流会上发表的《计算机的发展与技术》一文中，对未来10年以嵌入式芯片为基础的计算机工业进行了科学的阐述和展望。
3 嵌入式系统工业的特点和要求 (Embedded System Industry, ESI)
3.1 嵌入式系统工业是不可垄断的高度分散的工业
从某种意义上来说，通用计算机行业的技术是垄断的。占整个计算机行业90%的PC产业，80%采用Intel的8x86体系结构，芯片基本上出自Intel，AMD，Cyrix等几家公司。在几乎每台计算机必备的操作系统和文字处理器方面，Microsoft的Windows及Word占80-90%，凭借操作系统还可以搭配其它应用程序。因此当代的通用计算机工业的基础被认为是由Wintel(Microsoft和Intel 90年代初建立的联盟)垄断的工业。
嵌入式系统则不同，它是一个分散的工业，充满了竞争、机遇与创新，没有哪一个系列的处理器和操作系统能够垄断全部市场。即便在体系结构上存在着主流，但各不相同的应用领域决定了不可能有少数公司、少数产品垄断全部市场。因此嵌入式系统领域的产品和技术，必然是高度分散的，留给各个行业的中小规模高技术公司的创新余地很大。另外，社会上的各个应用领域是在不断向前发展的，要求其中的嵌入式处理器核心也同步发展，这也构成了推动嵌入式工业发展的强大动力。嵌入式系统工业的基础是以应用为中心的“芯片”设计和面向应用的软件产品开发。
3.2 嵌入式系统具有的产品特征
嵌入式系统是面向用户、面向产品、面向应用的，如果独立于应用自行发展，则会失去市场。嵌入式处理器的功耗、体积、成本、可靠性、速度、处理能力、电磁兼容性等方面均受到应用要求的制约，这些也是各个半导体厂商之间竞争的热点。和通用计算机不同，嵌入式系统的硬件和软件都必须高效率地设计，量体裁衣、去除冗余，力争在同样的硅片面积上实现更高的性能，这样才能在具体应用对处理器的选择面前更具有竞争力。嵌入式处理器要针对用户的具体需求，对芯片配置进行裁剪和添加才能达到理想的性能；但同时还受用户订货量的制约。因此不同的处理器面向的用户是不一样的，可能是一般用户，行业用户或单一用户
.嵌入式系统和具体应用有机地结合在一起，它的升级换代也是和具体产品同步进行，因此嵌入式系统产品一旦进入市场，具有较长的生命周期。嵌入式系统中的软件，一般都固化在只读存储器中，而不是以磁盘为载体，可以随意更换，所以嵌入式系统的应用软件生命周期也和嵌入式产品一样长。另外，各个行业的应用系统和产品，和通用计算机软件不同，很少发生突然性的跳跃，嵌入式系统中的软件也因此更强调可继承性和技术衔接性，发展比较稳定。嵌入式处理器的发展也体现出稳定性，一个体系一般要存在8-10年的时间。一个体系结构及其相关的片上外设、开发工具、库函数、嵌入式应用产品是一套复杂的知识系统，用户和半导体厂商都不会轻易地放弃一种处理器。
3.3 嵌入式系统软件的特征
嵌入式处理器的应用软件是实现嵌入式系统功能的关键，对嵌入式处理器系统软件和应用软件的要求也和通用计算机有所不同。
(1) 软件要求固态化存储
为了提高执行速度和系统可靠性，嵌入式系统中的软件一般都固化在存储器芯片或单片机本身中，而不是存贮于磁盘等载体中。
(2) 软件代码高质量、高可靠性
尽管半导体技术的发展使处理器速度不断提高、片上存储器容量不断增加，但在大多数应用中，存储空间仍然是宝贵的，还存在实时性的要求。为此要求程序编写和编译工具的质量要高，以减少程序二进制代码长度、提高执行速度。
(3) 系统软件(OS)的高实时性是基本要求
在多任务嵌入式系统中，对重要性各不相同的任务进行统筹兼顾的合理调度是保证每个任务及时执行的关键，单纯通过提高处理器速度是无法完成和没有效率的，这种任务调度只能由优化编写的系统软件来完成，因此系统软件的高实时性是基本要求。
(4) 多任务操作系统是知识集成的平台和走向工业标准化道路的基础
3.4 嵌入式系统开发需要开发工具和环境
通用计算机具有完善的人机接口界面，在上面增加一些开发应用程序和环境即可进行对自身的开发。而嵌入式系统本身不具备自举开发能力，即使设计完成以后用户通常也是不能对其中的程序功能进行修改的，必须有一套开发工具和环境才能进行开发，这些工具和环境一般是基于通用计算机上的软硬件设备以及各种逻辑分析仪、混合信号示波器等。
3.5 嵌入式系统软件需要RTOS开发平台
通用计算机具有完善的操作系统和应用程序接口(API)，是计算机基本组成不可分离的一部分，应用程序的开发以及完成后的软件都在OS平台上面运行，但一般不是实时的。嵌入式系统则不同，应用程序可以没有操作系统直接在芯片上运行；但是为了合理地调度多任务、利用系统资源、系统函数以及和专家库函数接口，用户必须自行选配RTOS开发平台，这样才能保证程序执行的实时性、可靠性，并减少开发时间，保障软件质量。
3.6 嵌入式系统开发人员以应用专家为主
通用计算机的开发人员一般是计算机科学或计算机工程方面的专业人士，而嵌入式系统则是要和各个不同行业的应用相结合的，要求更多的计算机以外的专业知识，其开发人员往往是各个应用领域的专家。因此开发工具的易学、易用、可靠、高效是基本要求。
结 语
中国的单片机应用和嵌入式系统开发走过了15年的历程，有超过10万名从事单片机开发应用的工程师，但95%以上是3~5个人的小组以孤军奋战的封闭方式开发几乎不可重用的软件。今天面对的是嵌入式系统工业化的潮流，如果我们不能认清嵌入式软件必须以工业化的方式生产开发，不理解在短时间内装配集成“数百人年”嵌入式产品软件库固化于芯片之中的方法，那么我们将失去更多“上游”产品的市场机遇；反之在我国大力推动和建设“嵌入式软件工厂”，使我国的嵌入式软件库(零件)产品化并溶入国际市场，对加速知识创新和建立面向21世纪的知识经济.-
嵌入式计算机系统的展望 ----中国计算机学会微机专业委员会主任 中国科学院院士沈绪榜
　　 从使用角度来说，计算机可分为两类：一类是独立使用的计算机系统，如个人计算机、工作站等；一类是嵌入式计算机系统，它是作为其他系统的组成部分使用的。不管是哪一种计算机系统，要能够迅速地向前发展，都必须满足五个简单而又基本的条件：一是经济性，计算机要很便宜，让更多的人能买得起；二是小型化，人们携带起来方便；三是可靠性，能够在一般环境条件下或者是苛刻的环境条件下运行；四是高速度，能够迅速地完成数据计算或数据传输；五是智能性，使人们用起来更习惯，对人们更有使用价值。不过，对不少应用来说，嵌入式计算机系统对这些基本条件的要求往往是更苛刻的。这可以从一些嵌入式系统的成功与失败的例子清楚地看出来。所以，这里就从这五个基本条件出发，展望一下嵌入式系统发展的未来。
　　 就经济性来说，个人计算机的普及要算是一个典型的成功例子。可惜的是，Xerox的管理人员于70年代初实施其无纸办公室的计划时，虽然首先开发了个人计算机，但他们认为这种计算机对一般人来说可能是太贵了，因而没有制造与发展个人计算机。自动付款机系统要算是一个典型的失败例子。它要求超市中的每件商品都有一个存贮商品价钱的芯片。当商品小推车经过记账出口时，一个无线电信号使芯片传出它的价钱信息以自动记账。当信用卡"扫过"时，就给出清单，这样记账时就不用排队了。这个系统未得到使用，就是因为芯片的价钱还是太贵了。芯片技术能降低电子产品成本的速度，就连当代电子学革命之父，2000年诺贝尔物理奖获得者杰克·基尔比也没有想到，他在1959年发明的芯片技术，会将电子产品的成本降低到了百万分之一的地步。芯片技术的这种神奇的作用，恐怕就是摩尔预言神奇般灵验的主要原因之一吧！难怪尽管发展芯片技术的耗资是惊人的巨大，发达国家还是力争在芯片技术的竞争中要永远保持领先的地位，以便能主宰世界信息技术的发展。就小型化来说，需要人们携带的电子产品，如心脏启博器，小型化要求就非常明显了。电子产品的小型化程度也是受芯片技术的发展水平限制的。尽管到2015年微米技术将达到它的物理极限，但仍然有许多应用还有待芯片技术的进一步微型化，使其功能密度的进一步提高。为此，MEMS技术、系统芯片技术得到了发展。不仅如此，人们还在致力于纳米技术与生物技术研究，以期能使芯片技术有可能达到更高的微型化程度。例如，日本人的研究目标是"制造出能进入管道内进行检修的微型机械，能进入血管内进行手术的微型机器人，生产微型机器人，生产微型机械部件的超小型化工厂，确保日本在未来微机械加工领域的领导地位，在基础研究方面实现纳米技术的Ogata计划"。由于嵌入式系统是针对特定应用对象设计的，利用这一情况，嵌入式微处理器的设计一般都具有结构多样性与应用灵活性的两大特点。为了微型化，低功耗也是一个重要的性能指标。就可靠性来说，对于常规条件下使用的家电产品等，现在的芯片技术已使产品的可靠性达到了非常令人满意的程度。但对太空、人体等特殊环境下使用的产品的长寿命要求，仍然不是一项容易实现的指标，还有待于芯片技术的进一步发展与完善。就高速度来说， 应用对它的要求似乎没有止境，许多人工智能应用就是受到了计算速度的限制。对互联网来说，很多应用还是受到传输速度的限制，加密解密就是一个很重要的例子。也许人们常常提到的量子计算技术才能解决这个高性能要求的问题。就智能性来说，现代的芯片计算机可以进行逻辑、符号和语言处理等这些被认为是大脑左半球的功能，而且达到了人类自己都感到惊奇的程度。但如何实现与有生命的组织一样灵活而精细的信息处理能力，如发现缺陷、识别和改正错误之类的生物功能等问题，目前尚未找到有效的途径。更不用说，各种生命形式中的自律性、自组织、自更新和自发展等最典型的生物功能如何在当前的芯片计算机中实现了。硅基芯片是人类智慧的结晶，它正在不断地实现各种人类自身功能的延伸。模糊推理芯片确实使智能家电得到了大力发展，神经网络芯片则在模拟人类的学习功能上迈进了一大步。芯片是智能化的支柱，人们不仅利用它研制智能的机器，改造客观的世界，而且也在利用它研制嵌入到人体内的产品，修补人体的缺陷，增进自身的健康。
　 综上所述，嵌入式系统的发展主要体现在芯片技术的进步上，以及在芯片技术限制下的算法与软件的进步上。今天正在开发的嵌入式系统，到底哪些明天定会取得应用上的成功，这是很难预料的。因为这不仅要取决于技术的因素，还要取决于社会的因素。 虽然预测未来是困难的，但不管怎样，展望未来，明天的嵌入式系统将会比今天的更便宜、更小巧、更可靠、更高效而且更智能化，因为这毕竟是它赖以发展并为人类所最能接受的简单而基本的条件。所以从技术上来看，沿着这五个简单而基本的条件努力，恐怕是势在必行不可忽视的。 嵌入式系统的产品可是最大的最多的，在日常电器中，我们的数字式产品，比如电饭锅，微波炉，数字式录音机，播放机，但是为什么嵌入式系统测试如此冷落？是我们的产品已经达到炉火纯青？不再需要测试？其实不是，这里只能说明一点：我们的工作只能在高端，对下面一无所知，都是人家已经作好了，我们 只是装配，中国将成为世界加工厂，这点不假，但是我们不能总是为人家加工、装配.========================================================================================================

<2>嵌入式软件测试策略

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

　　 由于嵌入式系统的自身特点，如实时性 (Real-timing) ，内存不丰富， I / O 通道少，开发工具昂贵，并且与硬件紧密相关 CPU 种类繁多，等等。嵌入式软件的开发和测试也就与一般商用软件的开发和测试策略有了很大的不同，可以说嵌入式软件是最难测试的一种软件。

　　 嵌入式软件测试使用有效的测试策略是唯一的出路，它可以使开发的效率最大化，避免目标系统的瓶颈，使用在线仿真器节省昂贵的目标资源。自从出现高级语言，开发环境与最终运行环境通常都是存在差异的，嵌入式系统更是如此。开发环境被认为是主机平台，软件运行环境为目标平台。相应的测试为 host-target 测试或 cross-testing 。

　　 讨论嵌入式软件测试首先就会遇到一个问题：为什么不把所有测试都放在目标上进行呢？因为若所有测试都放在目标平台上有很多不利的因素：

1 ）测试软件，可能会造成与开发者争夺时间的瓶颈，避免它只有提供更多的目标环境。

2 ）目标环境可能还不可行。

3 ）比起主机平台环境，目标环境通常是不精密的和不方便的。

4 ）提供给开发者的目标环境和联合开发环境通常是很昂贵的。

5 ）开发和测试工作可能会妨碍目标环境已存在持续的应用

从经济上和开发效率上考虑，软件开发周期中尽可能大的比例在主机系统环境中进行，    其中包括测试。

     确定 host-target 测试环境后，开发测试人员又会遇到以下的问题：

1 ）多少开发人员会卷入测试工作（单元测试，软件集成，系统测试） ?

2 ）多少软件应该测试，测试会花费多长时间？

3 ）在主机环境和目标环境有哪些软件工具，价格怎样，适合怎样 ?

4 ）多少目标环境可以提供给开发者，什么时候 ?

5 ）主机和目标机之间的连接怎样？

6 ）被测软件下载到目标机有多快 ?

7 ）使用主机与目标环境之间有什么限制（如软件安全标准） ?

任何人或组织进行嵌入式软件的测试都应深入考虑以上问题，结合自身实际情况，选定合理测试策略和方案。

     对于嵌入式软件测试或叫交叉测试（ cross-test ），在测试的各个阶段有着通用的策略：

1 ．单元测试：

所有单元级测试都可以在主机环境上进行，除非少数情况，特别具体指定了单元测试直接在目标环境进行。最大化在主机环境进行软件测试的比例，通过尽可能小的目标单元访问所有目标指定的界面。

在主机平台上运行测试速度比在目标平台上快的多，当在主机平台完成测试，可以在目标环境上重复作一简单的确认测试，确认测试结果在主机和目标机上没有被他们的不同影响。在目标环境上进行确认测试将确定一些未知的，未预料到的，未说明的主机与目标机的不同。例如，目标编译器可能有 bug ，但在主机编译器上没有。

2 ．集成测试：

  软件集成也可在主机环境上完成，在主机平台上模拟目标环境运行，当然在目标环境上重复测试也是必须的，在此级别上的确认测试将确定一些环境上的问题，比如内存定位和分配上的一些错误。

在主机环境上的集成测试的使用，依赖于目标系统的具体功能有多少。有些嵌入式系统与目标环境耦合的非常紧密，若在主机环境做集成是不切实际的。一个大型软件的开发可以分几个级别的集成。低级别的软件集成在主机平台上完成有很大优势，越往后的集成越依赖于目标环境。

3 ．系统测试和确认测试

所有的系统测试和确认测试必须在目标环境下执行。当然在主机上开发和执行系统测试，然后移植到目标环境重复执行是很方便的。对目标系统的依赖性会妨碍将主机环境上的系统测试移植到目标系统上，况且只有少数开发者会卷入系统测试，所以有时放弃在主机环境上执行系统测试可能更方便。

确认测试最终的实施舞台必须在目标环境中，系统的确认必须在真实系统之下测试，而不能在主机环境下模拟。这关系到嵌入式软件的最终使用。

包括恢复测试、安全测试、强度测试、性能测试，已超出了软件测试的范畴，本文暂不讨论。

使用有效的 cross-test 测试策略可极大的提高嵌入式软件开发测试的水平和效率，当然正确的测试工具使用也是必不可少的：

    总结一下，应用以上测试工具进行 .Cross-test 时的策略：

A)        使用测试工具的插装功能（主机环境）执行静态测试分析，并且为动态覆盖测试准备好一插装好的软件代码。

B)        使用源码在主机环境执行功能测试，修正软件的错误和测试脚本中的错误。

C)         使用插装后的软件代码执行覆盖率测试，添加测试用例或修正软件的错误，保证达到所要求的覆盖率目标。

D)        在目标环境下重复（ B ），确认软件在目标环境中执行测试的正确性。

E)        若测试需要达到极端的完整性，最好在目标系统上重复（ C ），确定软件的覆盖率没有改变。

     通常在主机环境执行多数的测试，只是在最终确定测试结果和最后的系统测试才移植到目标环境，这样可以避免发生访问目标系统资源上的瓶颈，也可以减少在昂贵资源如在线仿真器上的费用。另外，若目标系统的硬件由于某种原因而不能使用时，最后的确认测试可以推迟直到目标硬件可用，这为嵌入式软件的开发测试提供了弹性。设计软件的可移植性是成功进行 cross-test 的先决条件，它通常可以提高软件的质量，并且度软件的维护大有益处。以上所提到的测试工具，都可以通过各自的方式提供测试在主机与目标之间的移植，从而使嵌入式软件的测试得以方便的执行。

使用有效的 cross-test 测试策略可极大的提高嵌入式软件开发测试的水平和效率，提高嵌入式软件的质量。

==========================+++++++++++++++++++++++++++++++++++============================================

<3>嵌入式的测试方案(codetest)

可到www.superst.com上下载CodeTest嵌入式测试方式>
美国AMC公司采用了专利——插桩技术开发出专为嵌入式开发者设计的高性能测试工具CodeTEST，它可以用于本机测试（native）或在线测试( in-circuit).
CodeTEST系列包括三种嵌入式软件测试和分析工具：CodeTEST Native，CodeTEST Software-In-Circuit和CodeTEST Hardtware –In -Circuit。其中每一种工具代表了嵌入式系统开发的每一个周期的不同开发阶段。我们以标号1、2、3来表示：

在开发阶段1，由于是开发的早期，没有目标硬件，所应采用的工是桌面工具。
在开发阶段2，由于此时已开始，系统的集成工作，硬件开发板已出现。
在开发阶段3，此时项目已处于系统测试或确认阶段，任何疏忽、质量问题和性能缺现都会影响产品的发布、销售和盈利。
CodeTEST系列可以满足你选择适合自己测试类型：纯软件，驻留IDE硬件探头或同时选择以上所有三个测试的类型。
CodeTEST的突出特点：
性能分析可以实现代码的精确的可视化，从而大大提高提高工作效率，简化软件确认和查找故障的过程，
内存分析可以监视内存的使用，提前查处内存的泄漏，从而节约你宝贵的时间和成本。
代码追踪可以进行三个不同层次的软件运行追踪，甚至是追踪处理器内部的Cache，这样可以更容易的查找问题所在。
高级覆盖工具可以通过确认高隐患的代码段，显示哪些函数、代码块、语句、决策条件和条件以执行过或未执行过，来提高产品的质量。高级覆盖工具完全符合高要求的软件测试标准（如：R CTA/DO-178B，A级标准），可以实现语句覆盖、决策覆盖和可变条件的决策覆盖。

CodeTEST在各开发阶段的应用
CodeTEST Native
在早期的开发阶段，采用CodeTEST Native的插桩器可以实现较快的软件测试和分析。虽然此阶段的测试和分析不是实时测试，但这是没有目标硬件连接时的最好的分析和查找问题的最好方法。采用C odeTEST，可以提高软件测试的代码覆盖率、查找和分析内存的泄漏和深度追踪来确保软件的正常运行。

CodeTEST Software-In-Circuit
当有硬件连接到测试系统时，我们就可以采用“target hardware”工具了。一般说来，在这一阶段，逻辑分析仪、仿真器和纯软件工具是用来确定系统是否正常工作，但是采用这些工具测试软件往往增加了工程师工作的难度和压力。而采用C odeTEST Software-In –Circuit，通过目标代理（tragrt agent）来测试和分析目标硬件就不需要硬件工具。
CodeTEST Software-In–Circuit插桩器还可以很方便的让你从CodeTEST Native的desktop-stimulated测试跳转到目标硬件的实时测试。跳转后，插桩器、脚本的文件格式和数据不受Native环境影响。而且，就学习N ative和CodeTEST Software-In –Circuit的测试方法而言是差不多的。对于大多数在这两种开发阶段使用过其他的工具的开发者，CodeTEST可以大大节约开发的时间。
虽然CodeTEST Software-In –Circuit工具链不提供外部硬件测试系统的细节情况，但它为硬件的探测的难题提供了解决方案，提供了强大的代码覆盖实时工具、内存分析和软件追踪，而且在真实硬件环境中运行，价格低廉。
CodeTEST Hardtware-In-Circuit
当你进入此阶段时，你需要一组能提供监视软件测试深度和精确度的的工具链。带有的Bugs和错误的程序必须修改、升级或更新。
CodeTEST Hardtware-In-Circuit工具链采用外部硬件辅助和相应的通讯系统来实现最大程度的软件实时测试。
与逻辑分析仪和仿真器不同，CodeTEST Hardtware-In-Circuit具有处理目前复杂嵌入式系统的实时测试的能力。CodeTEST外置探测的硬件系统主要包括控制和数据处理器、大容量内存和可编程的升级定时器，因此大型测试的时间精度可在+ /-50ns内。
CodeTEST Hardtware-In-Circuit除了提供测试代码覆盖率、内存分析和追踪分析，它的精确的实时测试能力还可以帮你查出软件性能和质量上的问题所在。

完全的解决方案

CodeTEST家族提供了六大独立的软件模块：CodeTEST性能分析，
CodeTEST 内存分析，CodeTEST代码跟踪，CodeTEST语句覆盖，CodeTEST决策覆盖，CodeTEST可变条件决策覆盖。这些模块你可以自由的选择，来满足你对可视化的要求。
CodeTEST性能
（CodeTEST可以确定调试代码时那一段代码花费较多时间，这样就可以更容易地监控所有程序的执行。）
由于CodeTEST可同时实时监视32，000个函数和1000各任务，因此它可以监控大型程序中每一个子程序的执行。而现有的调试工具通常采用采样技术，因此只能对部分代码和程序进行分析。在每次监视过程中，C odeTEST可以监视所有的应用程序，探测程序执行的瓶颈所在。它不仅可以显示出程序和函数执行最坏情况和最好情况所花的时间，而且还可以显示任务、函数及函数相互调用关系的所有结果。通过性能分析的排序列表，你可以很容易的确定你哪一部分程序需要修改。
CodeTEST内存分析
（CodeTEST内存分析可以动态追踪内存分配，报告内存出错和相应的原始数据。）
CodeTEST内存分析解决了难以追踪动态内存分配问题。它不仅可以报告为程序中每条语句分配多少字节的内存（当程序运行时），而且它还可以鉴别2 0多种内存分配错误。例如，CodeTEST内存分析可以捕捉像“释放空指针（freeing a null pointer）”一样常见的程序错误，报告发生错误的函数和代码行。而相比而言，现有的调试工具需要进行上百次的代码追踪和监视，花数周的的时间才能探测一个程序问题的所在。
CodeTEST代码跟踪

（多追踪窗口观察可以简化程序设计流程，实现程序设计的规范化。）
CodeTEST代码追踪把深度追踪和面向Software的简化运用特点结合起来。该工具可以从三个不同的抽象层次显示程序执行过程：1）高级，显示R TOS事件和函数执行的入口和出口。2）控制流程级，显示在每个函数执行到哪一语句。3）原码级，显示每条执行过的C或C++语句。
CodeTEST具有专为软件工程师设计的触发（trigger）和存贮（storage）功能。你完全可以避开采用其它调试工具复杂的设置，只需根据确定一个任务中R TOS任务和函数等级来选择所需要追踪的软件内容。CodeTEST具有强大的触发功能，包括内存分配错误触发。由于CodeTEST可以记录每一条代码行执行的时间（t imestamp），因此你可以很容易的确定函数中每个循环执行的时间。
如果你想标识出追踪过程中你感兴趣的事件，你还可以在你的代码中插入用户定义的标记（tags）。这些标记和时间记录（timestamp）会在追踪过程中显示出来，而且你可以观察追踪过程中指定变量的值。
CodeTEST-ACT（先进的代码覆盖工具）
（CodeTEST覆盖可以显示程序中覆盖过的函数以及代码的总覆盖率。）
代码覆盖是一种可以确定在一个特定的测试过程中，哪一部分程序执行过，而哪一部分程序未被执行过的技术。
CodeTEST-ACT提供了一种交互式界面，该界面可以在程序运行时显示出程序、函数和源代码的语句覆盖（SC）情况。此外，CodeTEST-ACT 独特之处是它在测试过程中提供了一张可以显示覆盖程度的覆盖率趋势图，该图可以让你确定花多少时间就可以是完成一个特定等级的代码覆盖。这样，一旦覆盖率的峰值一到你就可以终止测试，从而避开了测试中多余的和低效的部分，大大的缩短了测试的时间。
CodeTEST-ACT除了可以显示代码段执行的语句覆盖外，还提供了决策覆盖（DC）和条件决策覆盖（MCDC）的功能。
CodeTEST-ACT可以为不同等级的测试提供清晰的分析报告：CodeTEST SC提供语句覆盖分析和SC报告；CodeTEST DC不仅提供语覆盖分析和SC报告，而且还提供RTCA/DO-178 Level B测试标准所需的决策覆盖分析和DC报告；CodeTEST MCDC不仅包括SCHEDC报告，还提供了进行Level A测试所需的MCDC分析和报告。
查桩器的性能分析

你可以根据程序执行的流程和操作（包括RTOS、函数和程序跳转分支及源程序的组织结构）来决定你对可见性需要程度。而这些需要可以通过对原程序插桩来实现, 而且插桩时插入原程序的语句与编写原代码语言很相近。
以往的解决方案是基于微处理器、总线信息和片内Cache，在总线上提前抓取信号。而CodeTEST可视化解决方案是基于软件插桩器实现的。采用插桩器，你用不着猜测关键的代码在哪，一切一目了然。
CodeTEST自动插桩技术可以无需修改源代码而直接把插桩器插入应用软件中。你可以决定那些代码要插桩，要进行哪些测试。当插桩器在处理器中运行时，它会产生特定的实时可视标签（tags）。打完桩后关闭插桩器，这样就生成插桩版本（on-target）的新程序，而且你完全没必要删除这些可视标签。自动插桩器可以让你很容易地给大量代码插桩，而且它的可增加标签的特点可以在你需要修改b ugs或编辑文件时很快的重新插桩。在插桩的标签信息送回主机后，你就可以在程序运行时看到代码执行的精确流程。CodeTEST的解决方案不占用目标板上的处理器，可以独立于目标板的Cache运行，并且不受内存的影响。目前，在所有的测试工具中，只用CodeTEST插桩技术支持各开发阶段的软件测试和分析。

纯软件的测试工具
纯软件的测试工具采用的是软件打点技术，在被测代码中插入一些函数，用这些函数来完成数据的生成，并上送数据到目标系统的共享内存中。同时在目标系统中运行一个预处理任务，完成这些数据的预处理，将处理后的数据通过目标机的网口或串口上送到主机平台。这一切都需借助于用户的目标处理器完成。 通过以上过程，测试者得以知道程序当前的运行状态。 从上述分析可知，纯软件的测试工具的测试原理有两个必然存在的特点——插桩函数和预处理任务。
由于插入插桩函数和预处理任务的存在，使系统的代码增大，更严重的是这些代码会对系统的运行效率有很大的影响（超过50%）。函数本身要有它的实现过程，它要完成数据的生成和暂存，而且这些函数在它的实现过程中还可能被其他优先级更高的中断程序所中断，预处理任务需要占用目标系统CPU处理时间、共享内存和通信通道完成数据的处理、数据的上送。由于这些弊端的存在，当采用纯软件测试工具对目标系统进行测试时，用户目标系统是在一种不真实的环境下运行的，我们所捕获的数据也是不够精确。
所以采用纯软件的测试工具缺乏性能分析，它不能对用户目标系统中的函数和任务运行的时间指标进行精确的分析。
当做覆盖率分析的时候，因为要大量打点，而打点多于200时就会影响系统的运行，所以只能做单元覆盖率分析且单元的程序量不能太大。
它不能对内存的动态分配进行动态的观察。
纯硬件的测试工具
纯硬件工具通常用于系统的硬件设计与测试工作。当它用于软件的分析测试时，却无法满足用户的基本要求。
以逻辑分析仪为例，逻辑分析仪是通过监控系统在运行时总线上的指令周期，并以一定的频率捕获这些信号，通过对捕获的信号进行分析来判断程序当前运行的状况。由于它使用的是采样的方式，难免会遗失一些重要的信号；同时，分析的范围也及其有限。以性能分析为例，当使用某种逻辑分析仪进行性能分析时，我们只能以抽样的方式，同时对８０个函数做性能分析，得到一个不精确的结果；而若使用CodeTEST，我们可以同时对128０００个函数做性能分析，得到一个精确的结果。
当对程序做覆盖率分析时，因为硬件工具是从系统总线捕获数据的，如当CACHE打开我们会采用指令预取技术，从外存中读一段代码到一级CACHE中，这时逻辑分析仪在总线上监视到这些代码被读取的信号，就会报告这些代码已经被执行了,但实际上被送到CACHE中的代码可能根本没有被命中。为了避免这种误差必须把CACHE关闭掉，而CACHE关掉就不是系统真实的运行环境了，有时甚至会由于CACHE关闭而导致系统无法正常运行。
而仿真器通常采用内存标记技术，它所关心的也是处理器从外存的代码段读取数据的情况。所以也无法在CACHE打开的方式下工作。而它的性能分析也是以仿真器的时间系统以抽样的方式进行的，也无法时实对系统进行真实的分析。所以我们所得出的结果也是不精确的。
纯硬件工具根本不能对内存分配进行分析和检查的能力。
CodeTEST对软件分析测试功能的实现原理
AMC公司吸取了纯软件测试工具和纯硬件测试工具的优点，并对它们进行改善和提升后推出了CodeTEST。
由上图我们可以看出，程序员编写的源代码首先会通过CodeTEST的编译驱动器调用原编译器对进行预编译，然后CodeTEST的插桩器（源代码分析程序）对预编译好的源代码进行自动的插桩，即在需要插桩的关键位置写入一条赋值语句（如：amc_ctrt=0x74100009）,并把插入的标记送入一个数据库文件中生成一个符号数据库暂存起来，以备为以后分析时调用。然后，CodeTEST的编译驱动器又会调用原编译器对插桩后的代码进行编译生成可执行目标代码送到目标板上运行。当程序在目标系统运行到插桩点的位置时，目标板的控制总线和地址总线上会出现相应的控制信号和地址信号。当CodeTEST的辅助硬件（信号捕获探头）从控制总线和地址总线上监视到符合以上条件的信号时，CodeTEST会主动地从数据总线上把数据捕获回来送到CodeTEST的内存中暂存并对这些数据进行预处理，然后将预处理后的数据通过局域网送到工作平台上。通过与前面生成的符号数据库中的数据进行比较，我们就此得知当前程序的运行状态，借此完成对嵌入式软件的性能分析，高级覆盖率分析，内存分析和大容量的代码跟踪。
由此可知，CodeTEST是一个硬件辅助软件的测试与分析工具，它一方面吸取软件打点技术，并对这种技术进行了改善，纯软件工具插入的是一个函数，而CodeTEST插入的是一条赋值语句， 它在汇编级也是一条语句，所以它执行的时间非常短，同时避免了被其它的中断所中断，所以它对目标系统的影响非常小（1%-15%）。另一方面，CodeTEST从纯硬件的测试工具那里吸取了从总线捕获数据的技术并且对它进行了改善，CodeTEST不再是采样的方式，它是通过监视系统总线，当程序运行到插入的特殊的点的时候才会主动的到数据总线上把数据捕获回来，借此，在同样的处理能力下，CodeTEST可以做到精确的数据观察。
CodeTEST强大的测试分析功能。
由于CodeTEST对软件打点技术和从总线捕获数据进行了改善和提升，正是这种原理上的优势，所以CodeTEST具有强大的性能分析、内存分析、高级覆盖率分析和代码跟踪功能。
1． 强大的性能分析：CodeTEST能同时对128000个函数和1000个任务进行性能分析，可以精确的得出每个函数或任务执行的最大时间、最小时间和平均时间，精确度达到50ns；能够精确的显示各函数或任务之间的调用情况，帮助你发现系统瓶颈、优化系统和提升你的系统性能。
2． 强大的覆盖率分析。 CodeTEST可以在系统真实的环境下，可以从单元级、集成级、系统级以及产品终端现场阶段进行嵌入式软件的分析与测试。帮助测试工程师掌握当前的测试覆盖率数据，指导测试用例的编写。
3． 强大的内存分析。CodeTEST可以动态追踪内存分配，报告内存出错和相应的原始数据。他不仅可以在程序运行时报告为每条语句分配多少字节的内存，而且他可以鉴别20多种内存分配的错误。例如：CodeTEST可以捕捉“释放空指针（freeing a null pointer）”一样常见的程序错误，报告发生错误的函数和代码行帮，助你尽早发现动态内纯泄漏，而无需到系统崩溃时。
4． 强大的代码跟踪分析。CodeTEST提供400K的追踪缓冲空间，能追踪150万行的源代码。我们可以设置触发器来追踪自己感兴趣的事件，可以显示运行过程中程序运行的实际情况，帮助你查找程序的BUG所在。

<4>嵌入式测试实例：手机测试

手机测试包含: 基于功能、性能、用户面的测试（贝它测试）、Benchmark测试；作为专用的消费电子产品测试还包括可靠性测试（对于硬件则是RQT；对于软件则是field trial）；标准符合性测试（TA/FTA）；互操作性测试（IOT）；安全性测试（安规测试）；强度测试等.
手机测试是一个很大的题目，涉及到硬件测试和软件测试，还有结构的测试，比如抗压，抗摔，抗疲劳，抗低温高温等，结构上的设计不合理，会造成应力集中，使得本身外壳变形，对于翻盖手机，盖子失效，还有其他严重问题。硬件测试一般都有严格的物理电气指标，也有专门的仪器，这里的仪器，不在多说，一般如果是专业的测试人员，不会对词陌生吧。
因为我们人员编制问题，所以我对于各项测试，都或多或少了解一点，甚至从事过。。
但是手机测试，一般是指软件测试，这个一方面也说明了软件在手机上的重要行。一方面也说明手机测试的难度。因为期他得测试都有明确的指标，严格的操作规程，还有各种仪器。下面说的手机测试一般都是手机软件测试，以后不在重复说明。
因为工作原因，没有及时回复大家要求，这里先回答一点，希望大家一起参与，毕竟我一个人精力有限，知道也少。
这里就作为前言部分吧在说明手机测试之前，我觉得应该了解一下什么是嵌入市操作系统，这是个时髦的名词，虽然我们已经被嵌入市操作系统的产品所包围，但是却不一定能说清楚，什么是嵌如实操作系统，而学校的课堂上，讲的也不多，所以很多人对此感到云山舞罩。
简单的说，一个嵌入市操作系统就是为完成某中特定功能而专门开发的操作系统。这个操作系统的功能很明确，不象大型操作系统，范围广泛，大千世界，尽在其中，而嵌如操作系统只为完成某一项或者几项功能。
再说一下手机的特殊性，也就是要求对响应时间达到一定限制范围。也就是所谓的实时操作系统，如果一个电话不能在90秒内接听，那么对方会挂掉而你的操作系统还没反映过来，那么这个操作系统无疑是失败的，这是对嵌如操作系统实时性的要求。
作为一个测试人员，你必须了解这些，可能对一些软件开发人员，他不必很在意这些方面，因为他只要了解自己模块的入口说明和 出口说明就可以。但是测试人员不行。高级测试人员应该了解嵌入操作系统的特点，这个系统不象WINDOWS，有图形界面可以输入输出，也不象D OS用命令行模式，所有这些，都需要自己编写一个编辑器，编写一个交互界面，编写一个输入输出界面，在WINDOWS中，利用一些API和一些M FC，不用考虑硬件的问题，因为系统已经完成，而WINDOWS是讲究和硬件分离的，因为这样可以保护系统不受侵入。而在嵌入市系统里面。这一些都要求和硬件息戏相关。
手机测试中，软件出现的故障不一顶是由于软件的错误，也可能是由于没有考虑到硬件和软件没有完美的结合。因此我们在了解操作系统同时，也要了解一下其他的手机硬件性能，比如CPU ，比如存储器。 CPU的处理运算能力是以MIPS来衡量的，当然越快越好，但是也是和成本相关的，我不知道现在MOTOROLA T39的CPU，但是，因为是PDA，又是手写屏幕，所以菜单特别的慢。关于存储器需要专门做出说明，因为这里 的存储器很特别，不象PC，手机没有硬盘！
作为一个新来的，可能对嵌入时操作系统游乐 一个大致了解了，那么对他的程序又是如何的呢，难道是和以前的程序不一样？
其实，嵌入时系统的编程语言一般有C，而且也是最多的，也有其他语言。比如C++在最开始时候是用 汇编的，但是汇编难懂，而且也不容易移植，渐渐的被C代替，不过即使如此，在启动程序时候，要启动板子，也就是电路板时候，还是需要用一些汇编语言完成。
作为一个嵌入市系统的程序，和在PC上运行着的程序没有任何不同，唯一不同可能是在PC上运行的程序，你可以看到结果——如果你用输出语句的话，而在这里，你是看布道结果的。除非你加上L CD硬件，然后编写了LCD驱动程序，然后再编写显示 程序。编写嵌入市程序，一切都要自己解决。
我们的手机如果不是认为把电源切断的话，或者在电源消耗到一定程度的话，是会一直在使用的，所以，手机程序是一直在运转的，就是说一直在循环，这个，对于了解嵌入市程序，应该是个好材料——嵌入市程序就是一个无限循环的程序，除非关掉电源和电源因素，这里也有一个测试点：硬件中断是最高级的，它会终止你的程序，即使你现在的程序级别很高，比如通话，如果没电了，一切会o ver. 手机程序就是在一个无限循环的程序，什么时候跳出这个无限循环？你关机吧，如果感到不高兴，把电池卸下来，因为有可能进入死循环，而关机键失效了，——只好通过取下电池了。

这里要专门说明一下存储器，因为很多手机毛病都和存储有关，而且很多问题都和存储相关，计算机的存储是关键，而手机更始关键，因为计算机有硬盘作为存储，而手机所有的都在存储器里存储器分为几类，RAM 随即存储器，ROM随即只读存储器还有现在出现一些的闪存，以及电子可编程存储和非易失存储起。一个一个到来RAM 随机存储器，其中又有SRAM（静态RAM）DRAM（动态RAM），SRAM，只要只要电源开着，就会保存，我们打电话，有些最后拨打的号码，暂时是存在SRAM中的，不会立刻写入通话记录。只有正常关机，才会写入，如果取电池的话，是不会写入手机的通话记录的，如果在通话记录中出现了已经拨打电话，但是没有记录的情况，那么有可能和这个存储器有关，可能是你的软件上错误，也可能是硬件。DRAM在手机上用的不多，因为保留数据时间很短，

从价格上看，SRAM是非常昂贵的，而DRAM相比很便宜。
ROM也有几种，PROM可编程ROM 和EPROM可擦除可编程ROM两者区别是，PROM是一次性的，也就是软件灌入后，这个就完蛋了，这种是早期的产品，现在已经不可能使用了，而E PROM则是通用的存储器，这些存储器不符和手机软件产品，一般使用ROM少
其他FLASH
这是近来手机采用最多的存储器，这种存储起结合了ROM和RAM的长处，但是不属于RAM也不属于ROM
手机大量采用的NVRAM 非易失存储器 和SRAM属性差不多，EEPROM 电子可擦出可编程存储器 ，闪存，ROM的后代。手机软件一般放在EEPROM中，EPROM是通过紫外光的照射，擦出原先的程序，而EEPROM是通过电子擦出，当然价格也是很高的，而且写入时间很长，写入很慢，所以前面提到的电话号码，一般先放在S RAM中，不是马上写入EEPROM，因为当时有很重要工作要做——通话，如果写入，漫长的等待是让用户忍无可忍的。
NVRAM 是一个很特别的存储器，它和SRAM相类似，但是价格却高很多，由于一些数据实在重要，断电后必须保持这些数据，所以只能存放在这里，一般和个人信息有关的数据会放在这里，比如和S IM卡相关数据。容量大小也只有几百字节。
闪寸存储器是所有手机的首选，综合了前面的所有优点，不会断电丢失数据（NVRAM）快速读取，电气可擦出可编程（EEPROM）所以现在手机大量采用，
说了这么多存储器，可能比较糊涂了，这么多存储器，究竟采用哪中呢，在手机发展中，各种存储器都用过，至于现在，各种手机采用的存储器是不同的，这个和成本相关，各种存储器价格不一样，本着性价比最优组合，由设计者决定，有些是可选的，有些是必须的，是手机方案决定的，我们了解只是各种存储性能，特点，在测试中判断错误原因。

手机协议站软件的白合测试
手机软件测试单丛测试的内容来看，包括上面的MMI和底下的PROTOCOL由于MMI的灵活性，和各个厂家的个性化，以及手机本身的用户不同，MMI的侧重点也就不同，在基本通话、短消息、数据功能完成的基础上可以五花八门，所以测试的重点不同。测试方法各不相同。但是协议就不同了，协议是统一的，虽然你实现方法可以不同，但是完成的功能必须相同，和MMI不同，虽然都是聊天，但是有些用短消息聊天，有些用PUSH聊天，而协议软件有一个遵守的规范——ETSI指定的协议规范，有统一的命令规范和统一的标准。消息（术语，不是软件编程里的消息，是通信术语）是固定的嘛。针对协议的测试，因为有标准可循，有规范可仪，所以软件测试就很多工具，公司也多，自动化测试要自动话，否则，按照人的测试能力，谁也无法保证其绝对可靠性，也没有这么大的人力去仔细做测试。一般对于白合测试是比较严格的，而且也是耗费人力的，所以常采用自动化测试工具。这样节省人力、缩短测试时间。至于谁家的工具比较好，涉及各取所需吧，也涉及到成本问题。你如果想购买某产品，会给你一个DEMO版本，给你一个月的评价时期，这个评估版本让你熟悉其产品的优劣也让你熟悉其操作。
测试工具一般都有二次开发功能，也就是可以自己编写脚本，针对不同的软件平台做一些改动，这样可以根据自己的需要编写测试CASE测试用列当然即使是全部用自动化测试，你心理还是没底，你还是要仔细去看代码。分析流程，读懂其含义，一个很小的问题，出错保护没有作好，一般这个问题最多，出错保护机制没有作好，会造成崩溃这样严重的问题。
这是针对协议代码的白合测试如果你是对购买来的协议进行测试，一般有仪器，模拟一个网络基站，进行测试，不过这样的仪器非常昂贵，而且测试人员要对ETSI协议比较熟悉。我没有直接参加针对协议的白合测试，不过对评估般的测试软件曾经PRACTISE，可测试覆盖率，我很奇怪的是，一般打点（跟踪）也是需要消耗CPU时间的这样程序效率就降低了，而我要测试程序的效率等项目就要考虑CPU，而且程序的工作运转必须和CPU息息相关，而现在CPU 在保证程序RUN同时，还要进行打点，是否测试出的指数和实际不符和呢，是否没有达到真实的水平呢而它这个产品（水牛）介绍说，一般不占用CPU时间，我想了很长时间没有想通后想咨询，告之这是他们的专利，无可奉告。由于这种测试工具是针对平台所以如果你平台不支持的，也就没有办法使用了。还有集成测试等等，在软件的介绍中有详细说明，不再详细说明。对协议进行白合测试，我想对你的要求就是：熟悉相关的协议，否则白扯；熟悉开发的语言，否则免谈。总之，我估计你们公司如果进行白合测试的话，我想测试工具是不可少的，
希望你顺利完成测试任务。早日听到好消息。

fault－－故障
在软件中一个错误的表现。

feasible path－－可达路径
可以通过一组输入值和条件执行到的一条路径。

feature testing－－特性测试
参考功能测试（Functional Testing）

FMEA－－失效模型效果分析（Failure Modes and Effects Analysis）
可靠性分析中的一种方法，用于在基本组件级别上确认对系统性能有重大影响的失效

FMECA－－失效模型效果关键性分析(Failure Modes and Effects Criticality Analysis)
FMEA的一个扩展，它分析了失效结果的严重性。

FTA－－故障树分析(Fault Tree Analysis)
引起一个不需要事件产生的条件和因素的确认和分析，通常是严重影响系统性能、经济性、安全性或其它需要特性。
functional decomposition－－功能分解
参考模块分解（modular decomposition）

Functional Specification －－功能规格说明书
一个详细描述产品特性的文档。

Functional Testing－－功能测试
测试一个产品的特性和可操作行为以确定它们满足规格。

glass box testing－－玻璃盒测试
参考白盒测试（White Box Testing）

IEEE－－美国电子与电器工程师学会（Institute of Electrical and Electronic Engineers）

incremental testing－－渐增测试
集成测试的一种，组件逐渐被增加到系统中直到整个系统被集成。
infeasible path－－不可达路径
不能够通过任何可能的输入值集合执行到的路径。

input domain－－输入域
所有可能输入的集合。

inspection－－检视
对文档进行的一种评审形式。

installability testing－－可安装性测试
确定系统的安装程序是否正确的测试。

instrumentation－－插装
在程序中插入额外的代码以获得程序在执行时行为的信息。

instrumenter－－插装器
执行插装的工具

Integration Testing－－集成测试
测试一个应用组合后的部分以确保它们的功能在组合之后正确。该测试一般在单元测试之后进行。

interface－－接口
两个功能单元的共享边界。

interface analysis－－接口分析
分析软件与硬件、用户和其它软件之间接口的需求规格。

interface testing－－接口测试
测试系统组件间接口的一种测试。

invalid inputs－－无效输入
在程序功能输入域之外的测试数据。

isolation testing－－孤立测试
组件测试（单元测试）策略中的一种，把被测组件从其上下文组件之中孤立出来，通过设计驱动和桩进行测试的一种方法。

job control language－－工作控制语言
用于确定工作顺序，描述它们对操作系统要求并控制它们执行的语言。

LCSAJ－－线性代码顺序和跳转（Linear Code Sequence And Jump）
包含三个部分：可执行语句线性顺序的起始，线性顺序的结束，在线性顺序结束处控制流跳转的目标语句。

LCSAJ coverage－－LCSAJ覆盖
在组件中被测试执行到的LCSAJ的百分比。

LCSAJ testing－－LCSAJ测试
根据LCSAJ设计测试用例的一种技术。

Load Testing－－负载测试
通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。

logic analysis－－逻辑分析
（1）评价软件设计的关键安全方程式、算法和控制逻辑的方法。（2）评价程序操作的顺序并且检测可能导致灾难的错误。

logic-coverage testing－－逻辑覆盖测试
参考结构化测试用例设计（structural test case design）

maintainability－－可维护性
一个软件系统或组件可以被修改的容易程度，这个修改一般是因为缺陷纠正、性能改进或特性增加引起的。

maintainability testing－－可维护性测试
测试系统是否满足可维护性目标。

modified condition/decision coverage－－修改条件/判定覆盖
在组件中被测试执行到的修改条件/判定的百分比。

modified condition/decision testing －－修改条件/判定测试
根据MC/DC设计测试用例的一种技术。

Monkey Testing－－跳跃式测试
随机性，跳跃式的测试一个系统，以确定一个系统是否会崩溃。

MTBF－－平均失效间隔实际（mean time between failures）
两次失效之间的平均操作时间。

MTTF－－平均失效时间 （mean time to failure）
第一次失效之前的平均时间

MTTR－－平均修复时间（mean time to repair）
两次修复之间的平均时间

multiple condition coverage－－多条件覆盖
参考分支条件组合覆盖（branch condition combination coverage）

mutation analysis－－变体分析
一种确定测试用例套完整性的方法，该方法通过判断测试用例套能够区别程序与其变体之间的程度。

Negative Testing－－逆向测试/反向测试/负面测试
测试瞄准于使系统不能工作。

non-functional requirements testing－－非功能性需求测试
与功能不相关的需求测试，如：性能测试、可用性测试等。

N-switch coverage－－N切换覆盖
在组件中被测试执行到的N转换顺序的百分比。

N-switch testing－－N切换测试
根据N转换顺序设计测试用例的一种技术，经常用于状态转换测试中。

N-transitions－－N转换
N＋1转换顺序

operational testing－－可操作性测试
在系统或组件操作的环境中评价它们的表现。

output domain－－输出域
所有可能输出的集合。

partition testing－－分类测试
参考等价划分测试（equivalence partition testing）

path－－路径
一个组件从入口到出口的一条可执行语句顺序。

path coverage－－路径覆盖
在组件中被测试执行到的路径的百分比。

path sensitizing－－路径敏感性
选择一组输入值强制组件走一个给定的路径。

path testing－－路径测试
根据路径设计测试用例的一种技术，经常用于状态转换测试中。

performance testing－－性能测试
评价一个产品或组件与性能需求是否符合的测试。

portability testing－－可移植性
测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。

Positive Testing－－正向测试
测试瞄准于显示系统能够正常工作。

precondition－－预置条件
环境或状态条件，组件执行之前必须被填充一个特定的输入值。

predicate－－谓词
一个逻辑表达式，结果为‘真’或‘假’。

predicate data use－－谓词数据使用
在谓词中的一个数据使用。

program instrumenter－－程序插装
参考插装（instrumenter）

progressive testing－－递进测试
在先前特性回归测试之后对新特性进行测试的一种策略。

pseudo-random－－伪随机
看似随机的，实际上是根据预先安排的顺序进行的。

QA－－质量保证（quality assurance）
（1）已计划的系统性活动，用于保证一个组件、模块或系统遵从已确立的需求。（2）采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

QC－－质量控制（quality control）
用于获得质量需求的操作技术和过程，如测试活动。

Race Condition－－竞争状态
并行问题的根源。对一个共享资源的多个访问，至少包含了一个写操作，但是没有一个机制来协调同时发生的访问。

recovery testing－－恢复性测试
验证系统从失效中恢复能力的测试。

regression analysis and testing－－回归分析和测试
一个软件验证和确认任务以确定在修改后需要重复测试和分析的范围。

Regression Testing－－回归测试
在发生修改之后重新测试先前的测试以保证修改的正确性。

release－－发布
一个批准版本的正式通知和分发。

reliability－－可靠性
一个系统或组件在规定的条件下在指定的时间内执行其需要功能的能力。

reliability assessment－－可靠性评价
确定一个已有系统或组件的可靠性级别的过程。

requirements-based testing－－基于需求的测试
根据软件组件的需求导出测试用例的一种设计方法。

review－－评审
在产品开发过程中，把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

risk－－风险
不期望效果的可能性和严重性的一个度量。

risk assessment－－风险评估
对风险和风险影响的一个完整的评价。

safety－－（生命）安全性
不会引起人员伤亡、产生疾病、毁坏或损失设备和财产、或者破坏环境。

safety critical－－严格的安全性
一个条件、事件、操作、过程或项，它的认识、控制或执行对生命安全性的系统来说是非常关键的。

Sanity Testing－－理智测试
软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考冒烟测试

SDP－－软件开发计划（software development plan）
用于一个软件产品开发的项目计划。

security testing－－安全性测试
验证系统是否符合安全性目标的一种测试。

security.－－（信息）安全性
参考计算机系统安全性（computer system security）

serviceability testing－－可服务性测试
参考可维护性测试（maintainability testing）

simple subpath－－简单子路径
控制流的一个子路径，其中没有不必要的部分被执行。

simulation－－模拟
使用另一个系统来表示一个物理的或抽象的系统的选定行为特性。

simulation－－模拟
使用一个可执行模型来表示一个对象的行为。

simulator－－模拟器
软件验证期间的一个设备、软件程序、或系统，当它给定一个控制的输入时，表现的与一个给定的系统类似。

SLA－－服务级别协议（service level agreement）
服务提供商与客户之间的一个协议，用于规定服务提供商应当提供什么服务。

Smoke Testing－－冒烟测试
对软件主要功能进行快餐式测试。最早来自于硬件测试实践，以确定新的硬件在第一次使用的时候不会着火。

Acceptance Testing－－可接受性测试
一般由用户/客户进行的确认是否可以接受一个产品的验证性测试。

测试的基本原则<->

在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。这里有一组测试原则：
1 、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。
2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。
3 、 Pareto 原则应用于软件测试。简单地讲， Pareto 原则暗示着测试发现的错误中的 80 ％很可能起源于程序模块中的 20 ％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。
4 、测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ” 。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。
5 、穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
6 、为了达到最佳效果，应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。
7、 不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现.

测试的基本原则<二>

1．应当把“尽早和不断的测试”作为开发者的座右铭
2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。
3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。
8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

GUI 测试

图形用户界面（ GUI ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时， GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。下列问题可以作为常见 GUI 测试的指南：

窗口：
· 窗口是否基于相关的输入和菜单命令适当地打开？
· 窗口能否改变大小、移动和滚动？
· 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
· 当被覆盖并重新调用后，窗口能否正确地再生？
· 需要时能否使用所有窗口相关的功能？
· 所有窗口相关的功能是可操作的吗？
· 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示？
· 显示多个窗口时，窗口的名称是否被适当地表示？
· 活动窗口是否被适当地加亮？
· 如果使用多任务，是否所有的窗口被实时更新？
· 多次或不正确按鼠标是否会导致无法预料的副作用？
· 窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
· 窗口是否正确地被关闭？

下拉式菜单和鼠标操作：
· 菜单条是否显示在合适的语境中？
· 应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
· 下拉式操作能正确工作吗？
· 菜单、调色板和工具条是否工作正确？
· 是否适当地列出了所有的菜单功能和下拉式子功能？
· 是否可以通过鼠标访问所有的菜单功能？
· 文本字体、大小和格式是否正确？
· 是否能够用其他的文本命令激活每个菜单功能？
· 菜单功能是否随当前的窗口操作加亮或变灰？
· 菜单功能是否正确执行？
· 菜单功能的名字是否具有自解释性？
· 菜单项是否有帮助，是否语境相关？
· 在整个交互式语境中，是否可以识别鼠标操作？
· 如果要求多次点击鼠标，是否能够在语境中正确识别？
· 光标、处理指示器和识别指针是否随操作恰当地改变？

数据项：
· 字母数字数据项是否能够正确回显，并输入到系统中？
· 图形模式的数据项（如滚动条）是否正常工作？
· 是否能够识别非法数据？
· 数据输入消息是否可理解？

什么是冒烟测试

注意
在冒烟测试中，使用不匹配的二进制文件进行测试是一个常见错误。为了避免此错误，当两个或多个更新后的二进制文件之间存在依赖项时，请在测试版本中包括所有更新后的二进制文件。否则，测试的结果可能无效。
创建每日构建 (Daily Build)
每日构建要求团队成员协同工作，并鼓励开发人员彼此保持同步。如果新版本的迭代被延迟，则该延迟很容易导致具有多个依赖项的产品不同步。遵循每日构建和冒烟测试的过程，任何更改过的或新的二进制文件都可确保实现高质量。
有关设置重复版本的更多信息，请参见 在 Team Foundation Build 中运行生成。有关验证产品版本的更多信息，请参见如何：配置和运行生成验证测试 (BVT)。

　　　　　　　　　　　　　　　　　　　　　　编号：

测试用例规程

目的：

测试用例文档化、规范化，实现软件测试的配置管理

一、适用范围：

同方融达系统测试

二、规范：

1 XX测试项目

1．1 XX测试子项目

注：

测试项目：

   指明并简单描述本测试用例集是用来测试哪些软件项目，软件子项目或软件特性的。

 对于测试项目，测试子项目的划分和分类的确定，是由测试方案文档的“测试用例设计”来完成的。

测试子项目：

   参考上述关于“测试项目”的说明。

用例编号：

   对该测试用例分配的唯一的编号标识。

用例级别：

   表明该用例的重要程度。用例的重要性并不对应用例可能造成的后果，而是对应用例的基本程度。测试用例分为四级：

   级别1：基本。该类用例涉及系统基本功能，用于版本提交时作为“版本通过准则”。如存在不通过的项目时可考虑重新提交版本，例如通话不计费等。1级用例的数量应受到限制。

   级别2：重要。该类用例涉及单个版本特性

   级别3：详细。该类用例仅影响某单项功能的某一细节方面。例如某业务的登记和使用正常，但和另一个新业务发生不应有的冲突。有关性能、极限等方面的测试可归入3级用例。有关用户界面的基本规范等方面的测试可归入3级用例

   级别4：生僻。该类用例对应较生僻的预置条件和数据设置。有关用户界面的优化等方面的测试可归入4级用例

输入：

  具体的输入值，包括各输入值的先后关系等。

预期输出：

  预期输出值，如需要，也要列出描述预期输出数值的容许范围的公差。

实测结果：

  测试时填写，是否通过，若未通过，需列出实际测试时的测试输出值

  本次测试结果：

OK：测试结果全部正确

POK：测试结果大部分正确

NG：测试结果有较大的错误

NT：本次无法测试（特殊原因）

预置条件：

  执行本用例前，被测试对象所需具备的预置数据，所处状态或入口条件等要求

特殊环境要求：

  硬件环境

  软件环境

  其他

特殊测试步骤要求：

  执行本用例时要注意的步骤要求

相关测试用例：

相关测试规程：