嵌入式软件测试有哪些类型测试

嵌入式软件测试怎么实现自动化测试

嵌入式软件测试策略在嵌入式领域目标系统的应用系统日趋复杂，而由于竞争要求产品快速上市，开发技术日新月异，同时硬件发展的日益稳定，而软件故障却日益突出，软件的重要性逐渐引起人们的重视，越来越多的人认识到嵌入式系统的测试势在必行。

提到嵌入式软件测试，首先要简单介绍一些软件工程的一些观点，现在，被普遍接受的软件的定义是：软件（software）是计算机系统中与硬件（hardware）相互依存的另一部分，它包括程序（program）、相关数据（data）及其说明文档（document）。

其中程序是按照事先设计的功能和性能要求执行的指令序列；数据是是程序能正常操纵信息的数据结构；文档是与程序开发维护和使用有关的各种图文资料。

对于一般商用软件的测试，嵌入式软件测试有其自身的特点和测试困难。

由于嵌入式系统的自身特点，如实时性（Real-timing），内存不丰富，I / O通道少，开发工具昂贵，并且与硬件紧密相关CPU种类繁多，等等。

嵌入式软件的开发和测试也就与一般商用软件的开发和测试策略有了很大的不同，可以说嵌入式软件是最难测试的一种软件。

嵌入式软件测试使用有效的测试策略是唯一的出路，它可以使开发的效率最大化，避免目标系统的瓶颈，使用在线仿真器节省昂贵的目标资源。

自从出现高级语言，开发环境与最终运行环境通常都是存在差异的，嵌入式系统更是如此。

开发环境被认为是主机平台，软件运行环境为目标平台。

相应的测试为host-target测试或cross-testing。

讨论嵌入式软件测试首先就会遇到一个问题：为什么不把所有测试都放在目标上进行呢？因为若所有测试都放在目标平台上有很多不利的因素：1）测试软件，可能会造成与开发者争夺时间的瓶颈，避免它只有提供更多的目标环境。

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

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

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

5）开发和测试工作可能会妨碍目标环境已存在持续的应用从经济上和开发效率上考虑，软件开发周期中尽可能大的比例在主机系统环境中进行，其中包括测试。

更多资讯请登录Ltesting中国软件测试培训网查询文章来源于Ltesting中国软件测试培训网

项目开发中软件测试类型的分类有哪些呢？

单元测试（Unit test）：是针对模块组件或方法的测试。

在本人的操作中，一般是开发员工作范围内的测试；在具备组件接口规范的情况下，一般需要做一个测试工具模拟调用环境，编写测试实例，通过断点情况监视模块实际工作是否正常。

一股采用这种方式开发的单一功能模块质量都是非常高的。

但是如果没有统一的模块规范，那么开发与测试的工作量接近一比一；但如果模块是按统一的标准开发的，那么同一套测试套件就可以用到各个模件上，从而节省了测试时间。

本人认为这属于开发部门工作范围内的测试，与QAQC部门没有什么大的关系，事实上，在这一层次的用例也不是QC可以做到和理解的。

白箱测试：在理解内部流程的情况下针对逻辑流程设计测试实例，目的是找出极限边缘以及内在的逻辑错误。

单元测试中白箱测试的比例很高，（原因不难理解，还有谁比作者自己更理解模块的构造流程的）。

黑箱测试：这是QC部门的主要工作。

黑箱测试主要在于编写测试实例。

不过在实际操作中，都是把最不懂技术的成员分配做测试，最高技术水平就是会用VSS，所以也就别指望编什么测试实例。

所谓的黑箱测试，常常是对着菜单按钮，这个按下去，噢，有东西出来了，对的，打个勾——其实，这时侯的实例就是一个个按下去然后看看有没有输出，而且只限于界面方面，内在的部分和边缘情况大概是不用指望的。

但据作者所知，在CMM达到四以上的国外软件公司中，黑箱测试是对软件评价的最主要方式，通过合适的测试实例，除了最常见的可用性测试外，还包括压力测试，和怪用测试（Monkey test）。

压力测试：评价一个系统极限可以承受的压力是多少，同时在超负荷后的的响应情况；同时，在极限状况下，一些平时不太出现的ug也会浮现出来。

所以，这个测试作者认为不应该单独由QC部门进行，而应该由开发部门与QC部门联合进行。

理想的系统在极限测试状况下就算响应不及，也不至于当机，并在负荷恢复正常后一段时间内可以恢复正常运转。

这时当初对Windows恶评的原因之一：像网站一旦超出100-200个concuent,Windows不但罢工还死掉了；不得不重启系统（当然，Windows任意硬重启都能死鱼翻生，大多数情况下吧，也属一种难能可贵的优点）；而linux在超出负荷后一般情况下下降曲线不至于太明显——不过这也不是绝对的，作者就发现一旦Linux在极限状态下进入内存抖动时，死相和Windows差不了多少；所以内存不至于耗干是Linux可靠性能超过Windows的重要因素。

回归测试：在修改其中一个模块后看其他模块有什么问题。

作者认为这个测试是过程化程序的观念产物，在模块化软件中相互耦合程度低，而且服从统一的调动协议，是不是修改真是自家里的事情，和他人（模块）没有半点相干。

整体测试：把不同的模块连结后，看看联合工作情况如何。

这实际上是对接口协议的测试。

作者认为是可以作为接口互动部分的设计一部分工作，没有必要摆出来作为流程之一。

同理还有系统测试，反正最后整个系统运行起来是什么情况。

看似大，但如果前面已经做到好好的，这里如果出问题那才叫怪呢！ Alpha测试：放任内部成员胡作非为的测试； Beta测试：让全世界的坏人都胡作非为的测试。

代码覆盖分析工具在嵌入式软件测试中的应用有哪些？

介绍覆盖性测试技术的基本概念以及其在嵌入式系统中的基本工作过程；通过将覆盖测试工具Bullseye-Coverage移植到嵌入式操作系统（Nuclcus）的具体实现过程，说明系统要求、系统结构，以及具体的技术实现细节和步骤。

其中，如何解决覆盖数据传输问题系统实现的关键点。

软件测试的重要性是毋庸置疑的。

如何以最少的力和资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，是软件公司探索和追求的目标。

然而大家都知道，从理论上讲测试是永无止境的，只要不断测试就一定能不断发现问题.那么究竟如何度量测试的进度，如何判断测试可以完结呢？些，可以依靠测试覆盖率的分析来实现。

嵌入式软件系统也不例外。

1、代码覆盖分析代码覆盖分析过程包含以下几个方面：通过一组覆盖测试数据发现和分析那些没有被运行到的代码；为了提高代码覆盖率而设计新的测试用例；确定代码覆盖的定量标准，这XXX数据也间接地反映测试质量；识别那些冗余的测试用例。

代码覆盖分析是一种白盒测试方法，因为覆盖分析需要访问测试代码本身，且经常需要重新编泽程序，以程序的内部结构为基础来设计测试案例。

其基本准则是测试案例要尽可能多地覆盖程序的内部逻辑结构，发现其中的错误和问题。

另外要注意的是，覆盖分析并不是为了提高程序本身的质量而是为了确保测试用例的质量。

一般来说，覆盖分析通常应用在软件测试的早期，即单元测试阶段。

在软件发布版本阶段是不需要运行软件覆盖分析的。

2、覆盖分析在嵌入式系统上的问题嵌入式软件的开发与通用软件的开发很大的不同点在于：嵌入式系统需要采用交叉开发的方式，即开发工具运行在软硬件配置丰富的宿主机上，而嵌入式应用程序则运行在软硬件资源相对缺乏的目标机上。

所以针对覆盖分析测试，嵌入式系统的困难之一就是如何获取测试产生的覆盖数据。

犬多数的覆盖分析测试工具都需要对代码捅装，而当在目标环境下运行经过代码插装的可执行程序时，就会有覆盖分析数据产牛。

这些数据是分析覆盖数据报告的重要输入条件，所以要顺利实现嵌入式系统覆盖分析的一个关键点是如何建立宿主机与目标机之间的物理/逻辑连接，解决覆盖分析数据信息的传输问题。

3、BullseyeCoverage的实现方式 BullseyeCoverage是Bllseye公司提供的一款C/C++代码覆盖率测试工具。

相对于Rational公司的 Pure Coverage,BullseyeCoverage支持的C/C++编译器更多，除了支持各种Unix下的编译器之外，在Windows下还支持VC、Borland C++、GNU C++和Intel C++。

其提供的代码覆盖率是基于条件/判断的分支覆盖率，而不是一般的代码行覆盖率。

BuuseyeCoverage采用的是先对代码进行插装，然后收集覆盖数据，最后分析覆盖率原理的技术。

其工作原理是：针对不同的编泽器，设计一个和真实编译器名字相同的拦截器，这些拦截器文件存放在BullseyeCoverage的bin目录下。

当覆盖编译开关打开时，文件在编译过程中将首先被这些拦截器所拦截，而不是由真实的编译器去编译源代码。

在这个拦截过程中，拦截器将一系列探针代码插入到C/C++源代码中，然后文件再次通过真实的编译器生成二进制代码。

当覆盖编译开关关闭时，这些拦截器将直接调用真实的编译器而不进行代码插装的过程。

当完成了代码插装并且将编译好的运行文件下载到嵌入式系统后，开始代码覆盖分析另外一个重要的工作过程——覆盖分析数据更新过程。

由于BullseyeCoverage需要在运行时态对经过覆盖拦截器生成的覆盖分析文件（大小一般是运行代码的1.2~1.5倍）进行读写操作，所以可以对覆盖文件的大小进行简单的估计，以便设计系统。

在数据更新过程中，BullseyeCoverage的每次读写操作范围为l字节~4 KB。

另外，BullseyeCoverage只有在测试程序触发了 cov_write函数时才会对覆盖分析文件进行更新。

如果覆盖没有更新，那么相应地也没有I/O动作发生。

针对嵌入式系统，BullseyeCoverage有两种实现的方式： ① 利用读取内存区数据的原理。

首先，通过串口、以太网或者USB将覆盖分析文件下载到嵌入式系统的某个未用内存区域；然后，修改测试工具的I/O库函数，将对覆盖分析文件操作的更新数据直接写入那块内存区域中。

这样在测试开始后，分析程序会自动更新位于内存中的覆盖分析文件。

由于覆盖分析文件在内存中，所以这种读写操作的速度会非常快。

测试完成后，通过串口、网络或者USB再次将覆盖分析文件读回到PC机中，然后利用工具对覆盖结果进行分析。

② 利用实际物理通道的原理。

系统需要对覆盖分析文件的I/O操作进行封装，将需要更新的操作命令和更新内容通过串口、网络或者USB传递给宿主系统，而宿主系统需要实现一个简单的接收更新程序对覆盖文件进行更新。

在这种实现方式中，最困难的是对每次数据传输的缓冲区大小进行估计。

由于 BullseyeCoverage每次对覆盖分析文件的读写操作的范围是1字节~4 KB，而通常情况下，更新数据会是4~8字节的小数据块（在较频繁的操作中也会有100字节~4KB数据的更新块），所以Bullseye- Coverage会采取减少数据传递次数...

软件测试类型都有哪些

测试类型有：功能测试，性能测试，界面测试。

功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。

是把测试对象看作一个黑盒子。

利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。

采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

负载测试和压力测试都属于性能测试，两者可以结合进行。

通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。

压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。

而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。

同时界面如同人的面孔，具有吸引用户的直接优势。

设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。

区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。

性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。

界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

所有嵌入式软件都要测试吗？

软件测试分类软件测试是一项复杂的系统工程，从不同的角度考虑可以有不同的划分方法，对测试进行分类是为了更好的明确测试的过程，了解测试究竟要完成哪些工作，尽量做到全面测试。

1，按是否需要执行被测软件的角度按是否需要执行被测软件的角度，可分为静态测试和动态测试，前者不利用计算机运行待测程序而应用其他手段实现测试目的，如代码审核。

（我认为主要是让测试人员对编译器发现不了的潜在错误进行分析，如无效的死循环，多余的变量等），而动态测试则通过运行被测试软件来达到目的。

2、按阶段划分： 1 单元测试单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。

它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。

因为单元测试需要知道内部程序设计和编码的细节知识，一般应由程序员而非测试员来完成，往往需要开发测试驱动模块和桩模块来辅助完成单元测试。

因此应用系统有一个设计很好的体系结构就显得尤为重要。

一个软件单元的正确性是相对于该单元的规约而言的。

因此，单元测试以被测试单位的规约为基准。

单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

2 集成测试集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。

它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。

集成测试的策略主要有自顶向下和自底向上两种。

3 系统测试系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。

因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。

软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。

4 验收测试验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。

它的测试数据通常是系统测试的测试数据的子集。

所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。

这是软件在投入使用之前的最后测试。

5 回归测试回归测试是在软件维护阶段，对软件进行修改之后进行的测试。

其目的是检验对软件进行的修改是否正确。

这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。

6 Alpha 测试：在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。

这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

7 Beta 测试：当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。

这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

3、按测试方法划分： 1 白盒测试白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

“白盒”法是穷举路径测试。

在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。

贯穿程序的独立路径数是天文数字。

但即使每条路径都测试了仍然可能有错误。

第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。

第二，穷举路径测试不可能查出程序中因遗漏路径而出错。

第三，穷举路径测试可能发现不了一些与数据相关的错误。

白盒测试可以借助一些工具来完成如Junit Framework,Jtest等。

2 黑盒测试黑盒测试是指不基于内部设计和代码的任何知识，而基于需求和功能性的测试，黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。

“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。

“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。

实际上测试情况有无穷多个，人们不仅要测试所有...