在嵌入式领域目标系统的应用系统日趋复杂，而由于竞争要求产品快速上市，开发技术日新月异，同时硬件发展的日益稳定，而软件故障却日益突出，软件的重要性逐渐引起人们的重视，越来越多的人认识到嵌入式系统的测试势在必行。提到嵌入式软件测试，首先要简单介绍一些软件工程的一些观点，现在，被普遍接受的软件的定义是：软件(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测试策略可极大的提高嵌入式软件开发测试的水平和效率，提高嵌入式软件的质量。

作者：陈绍英 来源：希赛网软件测试频道

在大多数的性能测试工作中，我们可以看出很多内容都是互相关联的。这就给我们提供了一思路：性能测试的很多内容可以经过一定的组织统一来进行。统 一开展性能测试的巨大好处是可以由浅入深按照层次对系统进行测试，进而减少不必要的工作量，以实现节约测试成本的目的。为此，本文提出了“全面性能测试模 型”的概念。 “全面性能测试模型”提出的主要依据就是一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试，而这些类型的测试实施也是很类似的。例如： 针对一个网站进行测试，模拟10到50个用户
就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了强度测试。
1．全面性能测试模型在“全面性能测试模型”中，把Web性能测试分为八个类别。
下面首先介绍八个性能测试类别的主要内容。
（1）预期指标的性能测试 系统在需求分析和设计阶段都会提出一些性能指标，这些指标是性能测试要完成的首要工作之一，本模型把预先确定的一些性能指标的测试称为预期指标的性能测 试。 这些指标主要是指诸如“系统可以支持并发用户1000”、“系统响应时间不得高于10秒”等在产品说明书等文档中中十分明确的内容，对这种预先承诺的性能 要求，测试小组应该“首当其冲”完成这类测试。
（2）独立业务性能测试 独立业务主要是指一些核心业务模块，这些模块通常具有功能比较复杂、使用比较频繁、属于核心业务等特点。这类特殊的、功能比较独立的业务模块始终都是性能 测试重点。我们通常不但要测试这类模块的一些和性能相关的算法，还要测试这类模块对并发用户的响应情况。 核心业务模块在需求阶段就可以确定，在系统测试阶段开始单独测试其性能。如果是系统类软件或者特殊应用的软件，通常从单元测试阶段就开始进行测试，在后继 的集成测试、系统测试、验收测试中进一步进行测试，以保证核心业务模块的性能稳定。 用户并发测试是核心业务模块的重“并发”的主要内容是模拟一定数量的用户同时使用某一核心模块的“相同”或者“不同”的功能，并且持续一段时间。对“相 同”的功
能进行并发测试分为两种类型，一类是在同一时刻进行完全一样的操作，例如打开同一条数据记录进行查看；另外一类是在同一时刻使用完全一样的功能，例如同时提交数据进行保存。可以看出后者是包含前前者的，后者是前者的特例，这种并发测试都要持续一定的时间。
从微观角度讲，同时使用某一核心模块“不同”的功能，也是一种组合业务性能测试，只不过这种组合的相关业务大分类是一致的。
（3）组合业务性能测试 通常不会所有的用户只使用一个或者几个核心业务模块，每个功能模块都可能被使用到，所以Web性能测试既要模拟多用户的“相同”操作(这里的“相同”
指很多用户使用同一功能)，又要模拟多用户的“不同”操作(这里的“不同”指很多用户同时对一个或者多个模块的不同功能进行操作)对多个业务进行 组合性能测试。组合业务测试是最接近用户实际使用情况的测试，因而是性能测试的核心内容。我们通常按照用户的实际使用情况来模拟使用各个模板的人数比例。 由于组合业务测试是最反映用户使用系统情况
的测试，因而组合测试往往和服务器（操作系统、Web服务器、数据库服务器）性能测试
结合起来，在通过工具模拟用户行为的同时，还通过测试工具的监控功能采集服务器的计数器信息，进而全面分析系统的瓶颈，为改进系统提供有利的依据。用户并发测试是组合业
务测试的核心内容。“组合”并发的突出特点是分成不同的用户组进行并发，每组的用户比例要根据实际情况来进行匹配。组合业务测试可以理解为包含了“核心业务模块并发”和“非核心业务模块并发”同时进行的并发用户测试。
（4）疲劳强度性能测试 疲劳强度测试是在系统稳定运行下模拟较大的用户数量、并长时间运行系统的测试，通过综合分析执行指标和资源监控来确定系统处理最大业务量时的性能，
主要目的是为了测试系统的稳定性。
（5）大数据量性能测试 大数据量测试分为两种：一种是针对某些系统存储、传输、统计查询等业务进行大数据量的测试，主要是测试数据增多时的性能情况，这类一般都是针对某些特殊的 核心业务或者一些日常比较常用的组合业务的测试。 第二种是极限状态下的数据测试，主要是指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核心业务或者日常常用的组合业 务。例如系统的数据每年只备份转移一次，可分别选择一个季度、半年、一年作为参考，模拟输入各个时间段的预计数据量，然后测试系统的性能，进而预估系统的 性能走向。 由于大数据量仍然是为了测试系统的业务处理能力，
因此大数据量性能测试可以独立进行，也可以和前面的独立、组合业务测试结合起来进行，主要由性能测试策略来决定。由于大数据量测试一般在投产环 境进行，因此本书把它单独独立出来，和疲劳强度测试放在一起，在整个性能测试的后期进行。大数据量测试可以理解为特定条件下的核心业务或者组合业务测试。
（6）网络性能测试 网络性能测试主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。在实际的软件项目中，主要是测试用户数目与网络带宽的关系。
网络性能测试一般有专门的工具，因此本书不研究网络测试，网络测试的任务通常由系统集成人员来完成。
（7）服务器性能测试 服务器性能测试（操作系统、Web服务器、数据库服务器）分为初级和高级两种形式。“初级服务器性能测试”主要是指在业务系统工作或者进行前面其它
种类性能测试的时候，监控服务器的一些计数器信息，通过这些数据对服务器进行综合性能分析，找出系统瓶颈，为调优或者提高性能提供依据。“高级服 务器性能测试”一般不由测试人员进行，由专门的系统管理员来进行，例如数据库服务器由专门的DBA来进行测试和调优。本书主要讨论在测试中常用到的“初级 服务器性能测试”，既通过工具对服务器资源进行监控的性能测试。
（8）一些特殊测试 主要是指配置测试、内存泄漏测试一些特殊的Web性能测试。这类性能测试或者和前面的测试结合起来进行，或者在一些特殊情况下会独立进行，本书重点来讨论 前一种情况，因为后一种情况往往通过特有的工具、较大投入的进行，可以不作为性能测试的范畴来研究。
主办：希赛网（www.csai.cn） 承办：希赛网软件测试频道（testing.csai.cn）