软件测试分类和方法

 一 、测试概念

通过手工或者工具对 "被测对象"进行测试操作

从而验证实际结果与预期结果之间是否存在差异

                                                  .......................................................

• 软件的定义
  • 软件是指在计算机和计算机系统中使用的程序，以及与程序相关的资料（比如：软件产品的在线帮助文档，软件产品说明文档等）、数据的总称。
  • 程序是计算机能够认识并理解的指令集，程序的目的是让计算机执行预设好的指令，然后提供用户需要的服务。
• 软件测试的概念
  • 软件测试就是为了发现错误的过程
  • 在规定的环境下运行被测软件，发现错误，对软件的质量进行评估
  • 在人工或自动化的手段下，运行被测系统，以发现软件是否满足规定的需求，或者预期结果与实际结果是否一致
• 软件测试的原则
  • 测试是证明软件存在缺陷：由于主观因素的影响，不同的人对于同一事物的评判标准不一致
  • 测试是不能穷尽的：测试输入的数据不可能完全列举测试，比如计算器输入框
  • 测试的2/8现象：测试过程中80%的问题是由20%的用例发现的；修改20%的问题，可以获取用户80%的满意度
  • 测试要尽早介入：把问题扼杀在摇篮之中，代价最小
  • 杀虫剂现象：规避措施（交叉测试、新手测试）
  • 避免开发测试自己写的代码
  • 测试用例的输入既要包括合理的输入，也要包括不合理的输入
• 软件测试的目的
  • 确保交给用户的软件产品满足用户的需求
  • 软件测试是程序的执行过程，目的在于发现错误
• 软件测试的对象
  • 程序
  • 数据
  • 文档
• 测试风险
  • 进度风险
  • 人员风险
  • 成本风险
  • 质量风险
  • 变更风险
• 测试人员具备的素质
  • 三心：责任心、好奇心、耐心
  • 二力：洞察力、沟通能力
  • 一精神：团队精神
• 测试人员的工作职责
  • 配置测试环境
  • 编写测试计划
  • 设计测试用例
  • 执行测试
  • 提交缺陷报告
  • 验证修正的缺陷
  • 编写测试报告

软件研发流程

• 软件研发模型是一个从软件项目需求定义开始，直至软件消亡为止，跨越整个生产周期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。常用的软件研发模型有以下几种：
  • 瀑布模型

    • 

    • 瀑布模型是一种最早以及被广泛使用的软件开发过程模型
    • 瀑布模型的阶段
      • 需求阶段---->需求说明书
      • 设计
        • 概要设计----->系统设计说明书
        • 详细设计----->详细设计说明书
      • 编码
        • 代码清单
      • 测试
        • 测试报告
      • 发布
      • 运维
    • 优缺点

      • 

  • V模型

    • 

    • 优缺点

      • 

  • W模型

    • 

    • 优缺点

      • 

  • 增量模型

    • 

    • 优缺点

      • 

  • 迭代模型

    • 

    • 迭代周期的划分
      • 迭代周期的划分原则
        • 每个迭代的周期长短依据该迭代工作量的不同而不同，如果工作量小，一周可以两个迭代；如果工作量大，可能4周一个迭代；
      • 每个迭代实现模块优先级的确定原则
        • 产品核心功能、能够给用户带来最大利益的功能，需要在前面的迭代中实现。
      • 优缺点
        • 该模型适合于一开始不能明确产品需求，计划多期开发的项目。

          

  • 迭代与增量的区别
    • 迭代是一个系统逐步优化的过程；增量是功能逐步增加的过程

      

    • 增量

      

    • 迭代

      

  • 敏捷
    • 敏捷的核心价值
      • 沟通：人与人之间的沟通
      • 反馈：发现问题及时反馈
      • 尊重：相互尊重后团队才能更加协调，工作效率才能更高
      • 勇气：不怕受挫
    • 优缺点
      • 采用短频快的方式发布产品，可以快速占领市场；
      • 产品采用模块化的分期交付，每个周期内要实现的功能非常明确，最终的产品就能越符合用的要求
      • 因为重视人与人之间的直接沟通，工作效率更高

      • 

• 总结
  • 每种软件开发模型都有一个完整的流程活动，增量模型和迭代模型都是以瀑布模型为基础优化而来的；而敏捷模型是迭代模型和增量模型的优化组合体；增量模型、迭代模型、敏捷模型都包含了多个周期，每一个周期内都包含了其完整的流程活动。
• 软件生命周期

  • 

• 软件研发流程

  • 

  • 回归测试：在测试过程中发现bug，提交给开发进行修改，开发修改后再发版本给测试进行验证，这样的测试就是回归测试。
• 软件测试流程

  • 

• 软件项目组成员

  • 

• 软件质量（熟记从哪8个方面对软件产品质量进行评估，给一个具体的应用场景，自己会熟练分析从哪几个方面来考虑测试点）
  • 软件质量的定义
    • 软件特性的总和，满足用户潜在和规定需求的能力
  • 软件质量评估应该从以下八个方面进行（熟悉每个质量特性包含的内容）：
    • 功能性
      •  
        • 适合性：软件产品为特定的任务和用户目标提供一组合适功能的能力；
        • 准确性：软件产品提供与实际使用场景相符的能力；（比如篮球鞋底比较厚实；足球鞋底有丁，抓地性好）
        • 功能顺从性：软件产品符合和该功能相关的标准、规范、规则或特定的能力。（比如汽车在欧美、香港地区方向盘在右边；在中国大陆方向盘在左边）
    • 安全性
      • 安全性主要是指软件产品保护信息和数据的能力，能够保证未授权的用户或系统不能阅读和修改这些信息和数据，而被授权的合法用户或系统不会被拒绝访问。
      • 它的测试主要涉及以下几个方面：
        • 用户验证：登录密码验证、IP地址访问限制等
        • 用户权限管理:验证低级别用户是否具有了高级别用户的权限，各级别用户权限都得到了实现。
        • 系统数据的保护:对例如系统文件、用户密码文件等进行隐藏、密码验证、内容加密、备份。
        • 加密、解密：在计算机通讯中，采用密码技术将信息隐蔽起来，再将隐蔽后的信息传输出去，使信息在传输过程中即使被窃取或截获，窃取者也不能了解信息的内容，从而保证信息传输的安全。
    • 可靠性
      • 可靠性主要包括如下几方面的内容：
        • 成熟性：软件产品为避免因软件故障而导致系统失效的能力；
        • 容错性：软件产品在接收了错误信息的情况下，能根据接收的错误信息给出处理出错的原因提示的能力；
        • 可恢复性：软件产品因各种原因失效时，能够恢复（自我恢复或被动恢复）的能力；
      • 可靠性顺从性：软件产品在可靠性方面要遵循的标准、规则或约定的能力。
      • 可靠性顺从性举例：比如我们的电信系统，在运行过程中，一年的故障率不能超过多少；系统故障后，恢复时间不能超过多久。
    • 易用性
      • 易理解性：使用户能理解软件产品是否适合自己的具体使用场景的能力；
      • 易学性：使用户能学习软件产品的能力；
      • 易操作性：软件产品使用户能够使用它的能力；
      • 吸引性：软件产品吸引用户的能力；
      • 易用性的依从性：软件产品遵从与易用性相关的标准、约定和风格的能力。
    • 效率性，主要包括如下几方面的内容：
      • 时间性：在规定条件下，软件产品执行其功能时所花费时间的能力；
      • 资源利用率：在规定条件下，软件产品执行其功能时，使用合适数量和种类的资源的能力；
      • 效率依从性：软件产品遵循与效率相关的标准或约定的能力；
    • 可维护性，主要包括如下几方面的内容：
      • 可分析性：当软件产品发生错误时，产品提供信息进行错误原因分析的能力；
      • 可修改：软件产品能够被修改的能力；
      • 稳定性：软件产品被修改后，产品能提供持续稳定工作的能力；
      • 可测试性：软件产品被修改部分能够被验证是否与预期相符；
      • 可维护性的依从性：软件产品遵循的与维护性相关的规则和约定的能力。
    • 可移植性，主要包括如下几方面的内容：
      • 适应性：软件产品在规定的不同环境中正常提供服务的能力；
      • 可安装性：软件产品在指定环境中被安装的能力；
      • 共存性：软件产品在公共环境下与其它独立软件分享公共资源共存的能力；
      • 易替换性：软件产品在相同的环境下，替换另一个功能相同的指定软件的能力；
      • 可移植性的依从性：软件产品遵循的与可移植性相关的标准和规则的能力。
    • 兼容性
      • 兼容性：主要是指软件产品与一个或多个特性、系统相互配合的能力。
      • 它主要涉及以下两个方面：
        • 共存性：主要指软件产品与其它软件产品共用系统公共资源，正常运行的能力。
        • 互操作性：主要指软件产品与其它软件产品或硬件资源进行数据交换和共享的能力。
    • 从质量属性维度划分，测试类型分为以下几种（能够根据具体场景熟练应用这八个方面进行测试分析）：
      • 功能测试：验证产品能否满足用户特定功能要求并做出正确响应。
      • 安全性测试：验证产品是否有保护数据的能力。
      • 兼容性测试：验证产品是否能够和其他相关产品顺利对接。
      • 配置测试：验证产品是否能够在推荐配置上顺利运行。
      • 可靠性测试：验证产品在长时间运行下能否满足保证系统的性能水平；在存在异常的情况下系统是否依然可靠。
      • 易用性测试：验证产品是否易于理解、易于学习和易于操作。
      • 性能测试：测试产品提供某项功能时的时间和资源使用情况。
      • 安装测试：测试产品能否被正确安装并运行。
    • 质量保证
      • 为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动。
      • 当前的软件研发过程中，通常定义了2个软件质量相关的角色：
      •  
        • QA即英文QUALITYASSURANCE 的简称，中文意思是质量保证
        • QC即英文QUALITYCONTROL的简称，中文意义是质量控制
      • QA和QC的区别
        • QC和QA的主要区别：前者是保证产品质量符合规定,后者是建立体系并确保体系按要求运作,以提供内外部的信任
        • QC就是测试人员，职责是尽可能早地发现软件的缺陷，并确保缺陷得到修复（有些企业里，测试人员被称为SQA）
        • QA是流程的监督者，职责是创建和执行改进软件开发过程，并防止软件缺陷发生 的标准和方法

        • 

• 测试需求分析
  • 测试需求评审
    • 完整性审查：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求（这个要基于测试人员丰富的业务知识）
    • 准确性审查：应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据。
• 测试用例设计
  • 测试用例写作注意点
    • 用语简洁清晰，但不能过于简单
    • 用语无歧义，尽量少用过长的句子
    • 用例的各个基本要素要齐备，不能缺失
    • 用例的步骤应该足够详细，操作应该明确
    • 容易被其它测试工程师读懂，并能顺利执行
  • 测试用例粒度
    • 尽量一个测试用例对应一个测试点
  • 测试用例状态
    • 当用例还尚未被执行时，是No Test未执行状态
    • 当执行结果与预期结果相符时，是Pass通过状态
    • 当执行结果与预期结果不符时，是Fail失败状态
    • 当因为软件有缺陷而妨碍了用例步骤的执行，且该缺陷并不是我们的测试点，则用例是Block阻碍状态。
    • 当用例正在执行中，但是需要耗较多时间去观察其结果，是Investigate观察中状态。
  • 测试用例写作模板

    • 

• 测试执行
  • 软件bug的定义：
    • 软件未实现需求和规格要求的功能；
    • 软件出现了需求和规格指明不该出现的错误；
    • 软件未实现需求和规格未明确提出，但应该具备的能力；
    • 软件难以理解、运行缓慢、不易使用，或者最终用户可能会认为不好；
    • 测试用例执行过程中发现与预期结果不相符的情况。
  • 软件bug等级划分：
    • 致命：具体包括内存泄漏、用户数据丢失或破坏、导致系统崩溃/死机、模块无法启动或异常退出、功能实现与需求设计严重不符、其它导致测试无法进行的错误；
    • 严重：软件产品的次要功能缺失，或者主要功能在某些场景下会出错；
    • 一般：软件产品在某些情况下会出错，但是造成的结果影响不大；
    • 提示：在某些情况下会出错，但是造成的结果影响很小。
  • bug的流程（生命周期）

    • 

  • bug单的模板

    • 

  • bug相关的术语
    • 缺陷密度=缺陷权值/代码行（KLOG）
    • 缺陷权值计算：致命问题权值为5，严重问题为3，一般问题为1，提示问题为0.1。
    • 这里的代码行（KLOG）是指每千行代码。
    • 缺陷修复率=累计关闭缺陷数/累计发现缺陷数*100%
    • 缺陷类型分布：按照软件产品质量模型的不同方面进行测试时，各自发现的缺陷分布的百分比。
  • 测试执行过程中的注意事项：
    • 搭建测试环境
    • 注意测试用例的前提条件和特殊说明
    • 测试用例要全部执行
    • 不要忽视任何偶然现象
    • 加强测试过程的记录，如详细测试步骤、日志
    • 提交缺陷时注意与开发人员的沟通
    • 注意问题单的规范
    • 及时补充、更新测试用例

二、测试分类和方法

三、黑白测试区别

黑盒测试

黑盒测试也称功能测试，把被测系统当作一个黑盒子，不关注内部结构和逻辑，只关注输入数据和输出数据。

1、等价类划分法  ——  较少用例、较高覆盖、避免重复

有效等价类：

完全满足程序输入的规格说明，有意义的输入数据的集合

无效等价类：

不满足输入要求或无效的输入数据的集合

2、边界值分析法  ——  考虑特殊值

概念：

某个输入变量范围的边界上，验证系统功能是否正常运行的测试方法。

与等价类划分法的区别：

1、以输入边界作为测试条件

2、不仅考虑输入条件，还要考虑输出空间

设计方法：

1、值的范围

2、值的位数

3、若输入是有序集合，选取第一个和最后一个元素测试

3、错误推断法  ——  根据需求分析及经验

概念：

基于经验和直觉推测程序中可能存在的情况，从而有针对性的设计。

优点：

充分借鉴经验，在测试小组中集思广益；在测试基础较差的情况下，方便实用。

缺点：

不是一个系统的测试方法，所以只能作为辅助手段，补充测试。

难以知道测试覆盖率

主观测试行为，难以复现

• 错误推导法（会应用）是指测试者根据自己的经验和直觉，推测系统可能存在错误的场景，从而构造数据进行验证的测试方法。
  • 错误推导法是一种基于经验的测试设计方法，其经验主要来自于对产品缺陷的分析。

  • 

4、判定表法  ——  列出输入条件与输出条件

概念：

一种能考虑输入域关联性的设计方法，等价类只考虑了输入条件的限制，未考虑输入条件间的关联性。

优点：

充分考虑了输入条件的组合情况，降低了漏测风险；利用判定表可推断出需求规格本身的逻辑性，反向验证需求的正确性。

缺点：

输入项过多时，规则数（测试次数）以指数级增加，判定表将会非常庞大。

5、因果图法  ——  考虑输入与输入、输入与输出的逻辑

概念：

用于描述被测对象输入与输入、输入与输出之间的约束关系，因果图绘制的过程中，可以理解为用例设计者针对因果关系业务的建模过程。

步骤：

首先根据需求规格绘制因果图，然后将其转为判定表再进行用例设计；

 一般将因果图理解为判定表的前置过程，如果逻辑关系较为简单，可直接绘制判定表

基本图像符号：（条件与结果的关系）

  恒等  非关系  与关系  或关系

6、功能图法  ——  不仅考虑输入条件，也考虑输入顺序

概念：

使用动态描述来生成测试用例的方法，其本质是一种白盒和黑盒测试方法组合的测试用例设计方法。关注数据的次序和转移的次序。

当程序中过于复杂并且存在大量的组合时，仅仅使用静态说明设计的测试用例，往往是考虑不够的，所以采用动态说明来补充一定的测试用例时必要的。

步骤：

1、明确节点数量及相互迁移关系

2、绘制状态迁移图

3、绘制状态迁移树

4、根据状态迁移树，抽取路径设计用例

7、正交试验设计法  ——  系统庞大和逻辑复杂时，可节省时间和资源

概念：

根据研究多因子(因素)多水平(状态)的正交试验法，挑选有代表性的点进行测试。

具备了“均匀分散、齐整可比”的特点

基于正交表的、高效率、快速、经济的方法。

适用场景：

输入条件和输出结果之间的关系有时候很难从需求规格说明中得到；或者因果关系非常庞大，导致测试用例数目非常大，为了有效地、合理地减少测试资源的浪费，就可以使用正交试验法。

注意：

正交表本身是从数学公式引申而来的，所以在使用过程中无法考虑输入参数相互组合的实际意义。需要人为删除无效组合，补充有效组合。

相关术语：

1.因子：通常指输入条件。

2.水平：通常指输入条件的可选取值，将其称为某个因子的水平。

3.对于一个具有m个因子，每个因子具有n个水平的实验，最少需要m*(n-1)+1个测试用例。

8、场景法  ——  根据功能实际应用场景来设计测试用例

概念：

通过运用场景来对系统的功能点或业务流程的描述，一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。

适用场景：

现在的系统基本上都是由事件来触发控制流程的。在面向对象的软件开发中，事件触发机制是编程中经常遇到的。

相关术语：

1、基本流：功能按照正确的事件流实现的一条正确流程。

2、备选流：由基本流引出，当功能出现故障或缺陷时，执行另一条流程。

3、异常流：不能跑通的流程。

• 场景分析法（会应用）是分析软件产品的实际使用场景，从用户的角度出发，覆盖各种场景的业务流程的测试设计方法。
  • 在场景分析法中，一般会把业务处理流程分为以下三种：
    • 基本流：基本流表示通过业务流程时输入都正确，能达到目标的流程。
    • 备选流：备选流表示通过业务流程时输入错误（或者操作错误）导致流程存在反复，但是经过纠正后仍能达到能达到目标的流程。
    • 异常流：异常流表示通过业务流程时输入错误（或者操作错误）产生异常终止流程 。
    • 场景分析法应用举例：ATM机取款业务处理
      • 基本流：插卡-->输入正确密码-->输入金额-->取款-->取卡
      • 备选流：插卡-->输入错误密码-->输入正确密码-->输入金额-->取款-->取卡
      • 异常流：插卡-->输入3次错误密码-->吞卡
  • 使用场景分析法设计测试用例的步骤如下：
    • 步骤一:理解需求，确定业务流程（基本流程、备选流程、异常流程）；
    • 步骤二：绘制流程图，再次确认流程路径；
    • 步骤三：根据业务流程图，抽取测试路径（每一路径需含一个未走过得路径）；
    • 步骤四：细化路径，利用等价类边界值方法细化路径，抽取测试用例。
  • 场景分析法的应用示例：

    

白盒测试

白盒测试也称逻辑驱动测试或基于代码的测试。指打开盒子，去研究内部的代码和运行逻辑。

一、逻辑覆盖：

1、语句覆盖

概念：

程序中每个可执行语句都能执行一次

优点：

直观地从源代码得到测试用例，无需细分每条判定表达式

缺点：

仅针对程序逻辑中显式存在的语句，但对于隐藏的条件是无法测试的。

如在多分支的逻辑运算中无法全面的考虑。语句覆盖是最弱的逻辑覆盖

2、判定覆盖

概念：

程序中每个判断的取真和取假至少经历一次

一个判定往往代表着一个分支，所以也叫分支覆盖。

优点：

覆盖率比语句覆盖多一倍，设计难度与语句覆盖一样简单

缺点：

若程序中语句存在多个逻辑条件和组合

只考虑结果为真、假，容易缺失不同条件选取的情况

3、条件覆盖

概念：

程序中每个判断中的每个条件的可能取值至少满足一次，常为多条件组合

优点：

相比判定覆盖，增加了对条件的覆盖情况，增加了测试量

缺点：

条件覆盖不一定包含判定覆盖

条件覆盖只能保证每个条件至少有一次为真、为假

而不考虑所有的判定结果

4、判定/条件覆盖

概念：

程序所有条件可能取值至少执行一次，所有判断的可能结果至少执行一次

优点：

结合了判定覆盖与条件覆盖

缺点：

未考虑条件组合的情况，无法列出条件的所有组合

5、条件组合覆盖

概念：

程序中所有条件的组合至少出现1次

优点：

能显示每个条件对判定结果的影响

缺点：

测试用例数量非常大，不一定包含路径覆盖

6、路径覆盖

概念：

覆盖程序中的所有路径情况

优点：

对程序进行彻底的测试，最广的覆盖方法

缺点：

路径覆盖包含循环、条件组合、分支选择等各种情况，需要大量、复杂的用例。

实际情况中，某些路径是不可能被执行的

二、基本路径法

基本路径法：

基本路径法事基于程序控制流程图(控制流程图和程序的语句可以说是对应)的一种对某段代码的各个执行路径进行测试的方法。

控制流程图：

符号⚪为控制流程图的一个节点，表示一个源程序语句，箭头为边，表示控制流的方向

黑白区别对比

 黑盒测试内容（测试点）

1、功能测试（通过测试+失败测试）

对产品各功能进行逐项验证，检查功能是否正确实现

正确的输入对应正确输出，错误的输入提示错误

1、客户要求应有的功能是否实现

2、客户未要求，但应有的功能是否实现

3、客户明确不应有的功能是否避免

4、客户未明确，但不应有的功能是否避免

2、规格指标测试

准确性  ——  雷达已实现测距功能，检查测距精度是否合格；对应软件距离计算精确度

及时性  ——  系统已实现预警功能，预警及时性是否合格；对应软件运行的实时性、处理能力

稳定性  ——  长时间依然达标；对应软件的内存泄露，指针不规范，异常措施等

3、一致性测试

相同环境下，同型号产品测试结果的一致性

不同环境下，同一个产品测试结果的一致性

4、易用性测试

易理解  ——  产品的功能、逻辑、使用方法是否容易被理解

易学习  ——  实际使用产品是否能够快速上手

易操作       ——  实际操作是否方便，简单

5、兼容性测试

向上兼容  ——  可在未来更高的硬件平台上运行

向下兼容  ——  可在以前的硬件平台上运行，新程序能够处理以往版本的数据

注：硬件兼容

嵌入式产品软件与硬件是绑定的，但仍存在兼容性问题。应考虑各元器件在不同型号间的兼容性。

两个原因：避免供应商无法供货带来的风险，避免商谈价格过于被动，供应商随意定价。

 白盒测试内容（测试点）

1、功能测试

对代码进行功能测试，关注功能是否与软件设计书一致；

哪些代码执行了，哪些没有执行，比例如何，执行结果是否正确

注：黑盒功能关注结果是否正确，白盒功能还要关注过程是否正确

2、性能测试（系统的整体能力与强度、压力、负载测试密切相关，一般是同时进行）

负载测试  ——  不同负载情况的表现，包含最大负载情况下的运行状态

压力测试  ——  高负载状态下，长时间运行的稳定性

强度测试  ——  超过极限负载的异常情况下运行，对异常的抵抗能力

并发测试  ——  主要目的是发现并发方式带来的其他问题，而不是性能

关注：响应时间、吞吐量、并发数、资源使用率（CPU、内存、IO）

负载可以是同时处理多份常规数据，也可以是处理一份庞大数据

3、失效恢复测试：验证在局部故障情况下，持续运行能够支持的功能和性能，及故障能否恢复

成熟性  ——  软件避免内部错误扩散导致系统失效的能力

容错性  ——  软件避免外部错误扩散导致系统失效的能力

易恢复性  ——  系统失效后，重新恢复原有的功能和性能的能力

4、接口测试

接口是指外部系统与系统之间以及内部各子系统之间的交互点

包括外部接口、内部接口，内部接口又包括：上层服务与下层服务接口、同级接口

应该包含：接口描述、请求方式、请求参数、参数类型、参数含义说明、取值限制、返回参数、成功与失败示例等

5、内存测试

内存泄露  ——  分配的内存未及时释放，导致内存耗尽

内存碎片  ——  内存不断被分为不连续的小块内存，当需要申请大块内存时，就会失败

内存崩溃  ——  数组访问越界、写已经释放的内存，指针错误等

四、嵌入测试

1．嵌入式软件测试是在特定的硬件环境下才能运行的软件。

2．嵌入式软件测试除了要保证嵌入式软件在特定环境下运行的高可靠性，还要保证嵌入式软件系统的实时性。

3．嵌入式软件产品为了满足高可靠性的要求，不允许在运行时有内存泄漏等情况发生，因此嵌入式软件测试相较于普通软件测试，还要对内存进行测试。

4．嵌入式产品不同于一般软件产品，在嵌入式软件和硬件集成测试完成之后，并不代表测试全部完成，在第一件嵌入式产品生产出来之后，还需对其进行产品测试。

5．嵌入式软件测试的最终目的是使嵌入式产品在能够满足所有功能的同时安全可靠的进行。