下载文档原格式
嵌入式软件的测试方法与技术引言嵌入式软件的测试方法与技术是保证嵌入式系统质量的关键环节。
随着科技的发展，嵌入式系统在各个领域得到了广泛应用，从家用电器到汽车，从医疗设备到航空航天，都离不开嵌入式软件。
而这些应用领域对于系统的可靠性和安全性要求越来越高，因此对于嵌入式软件的测试方法与技术也提出了更高要求。
一、嵌入式软件测试方法概述1.1 黑盒测试黑盒测试是一种基于功能需求和接口规范来进行测试的方法。
在黑盒测试中，我们不关心被测系统内部是如何实现的，只关注其输入和输出之间是否符合预期。
这种方法可以很好地验证系统是否满足需求，并且可以提前发现潜在问题。
1.2 白盒测试白盒测试是一种基于代码内部结构来进行测试的方法。
通过分析代码逻辑、覆盖率等指标来评估被测系统是否符合预期。
白盒测试可以发现代码中隐藏的逻辑错误和漏洞，并且可以提供更详细的测试覆盖率信息。
1.3 灰盒测试灰盒测试是黑盒测试和白盒测试的结合，既关注系统功能，也关注系统内部结构。
在灰盒测试中，可以利用黑盒测试的方法验证系统功能，同时通过白盒测试的方法发现潜在问题。
这种方法可以综合利用黑白两种方法的优点。
二、嵌入式软件测试技术2.1 静态分析技术静态分析技术是一种通过分析源代码或二进制代码来发现潜在问题的方法。
静态分析可以帮助开发人员在编码阶段发现错误和漏洞，并且可以提供代码质量评估和优化建议。
2.2 动态分析技术动态分析技术是一种通过运行时监测来评估系统行为和性能的方法。
动态分析可以帮助开发人员了解系统运行时状态，并且可以提供性能优化建议。
2.3 模糊测试技术模糊测试是一种通过生成大量随机输入来验证系统鲁棒性和安全性的方法。
模糊测试可以帮助开发人员找到输入错误处理不当或存在漏洞的地方，并且可以提供安全防护建议。
2.4 测试自动化技术测试自动化技术是一种通过编写测试脚本和使用自动化工具来提高测试效率和准确性的方法。
测试自动化可以帮助开发人员快速执行大量的测试用例，并且可以提供准确的测试结果。
嵌入式软件测试方法详解嵌入式软件测试是指针对嵌入式系统中的软件进行测试的过程。
嵌入式系统是指集成了软件和硬件的复杂系统，这些系统通常嵌入在一些设备中，如手机、汽车、电视等。
为了确保嵌入式系统的正常运行和稳定性，嵌入式软件测试变得极其重要。
本文将详细介绍嵌入式软件测试的方法。
一、静态测试方法静态测试方法是在嵌入式软件开发的早期阶段就进行的测试方法。
它主要通过代码审查和静态分析来发现潜在的问题和错误。
代码审查是指通过人工检查代码的规范性、可读性和实现逻辑等方面的错误和问题。
静态分析是指使用工具对代码进行扫描，以发现潜在的问题和错误。
静态测试方法可以帮助开发人员在开发的早期阶段就发现并修复问题，从而减少后期测试阶段的工作量。
二、单元测试方法单元测试方法是对嵌入式软件中的各个模块进行独立测试的方法。
它通常是使用白盒测试技术，开发人员可以直接查看代码并编写测试用例。
单元测试旨在检查模块是否按照预期执行，并验证其输出是否正确。
单元测试方法可以帮助开发人员在开发过程中对每个模块进行细致的测试，以确保其功能的正确性和稳定性。
三、集成测试方法集成测试方法是对嵌入式软件的各个模块进行整合测试的方法。
在嵌入式系统中，各个模块通常是独立开发的，集成测试旨在测试模块之间的接口和交互是否正常。
通过集成测试，可以发现并解决模块之间的兼容性问题、数据传输问题以及接口交互问题。
集成测试可以确保整个系统的功能正常运行，并保证各个模块之间的协调性。
四、系统测试方法系统测试方法是对整个嵌入式系统进行测试的方法。
系统测试旨在验证系统是否满足需求规格说明书中的要求，并检查系统在不同环境下的性能和稳定性。
系统测试一般包括功能测试、性能测试、兼容性测试、安全性测试等多个方面。
通过系统测试，可以发现并修复系统中的问题，确保系统的完整性和可靠性。
五、回归测试方法回归测试方法是在系统发生变更后对系统进行重新测试的方法。
嵌入式软件开发过程中，经常需要对系统进行改进和升级，回归测试旨在验证系统的改动是否对原有功能和模块产生了影响。
软考嵌入式软件工程师考试大纲软考嵌入式软件工程师考试大纲主要包括以下几个方面：一、嵌入式系统基础知识1. 计算机科学基础* 数制及转换：二进制、八进制、十进制和十六进制等常用数制及其相互转换* 数据的表示：数的机内表示（原码、反码、补码、移码，定点和浮点，精度和溢出）* 字符、汉字、声音、图像的编码方式* 校验方法和校验码（奇偶验码、海明校验码、循环校验码）* 算术和逻辑运算：计算机中的二进制数运算方法* 逻辑代数的基本运算和逻辑表达式的化简* 计算机系统结构和重要部件的基本工作原理：CPU和存储器的组成、性能、基本工作原理* 常用I/O设备、通信设备的性能，以及基本工作原理* I/O接口的功能、类型和特点* 虚拟存储存储基本工作原理，多级存储体系* 安全性、可靠性与系统性能评测基础知识：诊断与容错* 系统可靠性分析评价* 计算机系统性能评测方法2. 嵌入式系统硬件知识* 数字电路和逻辑电路基础* 组合电路和时序电路二、嵌入式系统软件知识1. 操作系统基础知识2. 嵌入式软件开发环境与工具3. 嵌入式软件设计模式与架构设计4. 嵌入式软件系统分析与评估5. 嵌入式软件测试与可靠性技术6. 嵌入式软件系统安全与防护7. 嵌入式软件系统维护与升级8. 嵌入式软件系统应用开发与实例分析9. 嵌入式软件系统新技术与发展趋势10. 其他相关领域知识：如物联网、智能家居等新兴领域的知识。
三、嵌入式系统开发实践1. 嵌入式系统开发流程与方法论2. 嵌入式系统硬件平台选型与评估3. 嵌入式系统软件开发环境搭建与配置4. 嵌入式系统软件设计、编码与调试技术5. 嵌入式系统测试与可靠性评估方法6. 嵌入式系统维护与升级策略制定与实践操作7. 嵌入式系统安全防护措施实施方案设计与实践操作8. 其他相关领域实践经验分享与案例分析。
![嵌入式软件测试技术[基础篇]](https://img.taocdn.com/s1/m/0223026d31b765ce05081443.png)
嵌入式软件测试方法嵌入式软件测试方法是针对嵌入式系统开发的软件测试方法。
嵌入式系统是指嵌入在各种设备中的计算机系统，如智能手机、家庭电器、汽车、医疗设备等。
嵌入式软件测试的目标是确保嵌入式系统的软件质量和可靠性。
以下是常用的嵌入式软件测试方法：1.静态分析：静态分析是一种基于源代码或二进制代码的分析方法，用于检查代码中的错误和潜在的问题。
它通常包括代码审查、代码规范和代码耦合分析等。
静态分析可以在开发早期识别问题，并且可以帮助改进代码质量。
2.单元测试：单元测试是针对软件模块或功能的测试方法。
在嵌入式系统中，软件通常被分为多个模块，每个模块都有其特定的功能。
单元测试通过对每个模块进行测试，以确保它们按照预期运行。
单元测试可以使用各种测试技术，如白盒测试和黑盒测试。
3.集成测试：集成测试是将不同的模块或功能组合在一起进行测试的方法。
在嵌入式系统中，不同的模块通常需要相互协作才能实现系统的功能。
集成测试通过模拟实际的运行环境，测试模块之间的接口和交互，确保整个系统按照预期工作。
4.验收测试：验收测试是在开发完成后对整个系统进行的一系列测试。
验收测试的目标是确认系统是否符合用户需求和规格说明。
它通常由系统开发人员和最终用户共同进行，以确保系统的功能和性能满足用户的期望。
5.性能测试：性能测试是评估系统在不同负载条件下的性能和响应时间的方法。
在嵌入式系统中，性能测试可以用来评估系统的运行速度、内存使用情况和功耗等。
性能测试可以通过模拟实际的使用情况或使用工具和设备进行。
6.可靠性测试：可靠性测试是评估系统在长时间运行中的稳定性和可靠性的方法。
在嵌入式系统中，可靠性测试可以通过模拟不同的环境和使用条件，以确保系统在各种情况下都能正常工作。
7.安全测试：安全测试是评估系统的安全性和防护措施的方法。
嵌入式系统通常需要保护用户的隐私和数据安全。
安全测试可以通过模拟攻击、检查系统的漏洞和弱点等方式进行。
总的来说，嵌入式软件测试方法是多样的，旨在保证嵌入式系统的软件质量和可靠性。
了解嵌入式技术测试方法的基本步骤嵌入式技术是指将计算机系统嵌入到其他设备、产品中，以实现特定功能的技术。
在现代科技发展的时代，嵌入式技术已经普遍应用于各种领域，如汽车、电子设备、医疗设备等。
为了确保嵌入式系统的质量和性能，进行全面的测试是非常重要的。
嵌入式技术测试是指在开发、制造或运维嵌入式系统过程中，使用测试方法、工具和技术来确定系统是否满足设计要求和需求。
以下是了解嵌入式技术测试方法的基本步骤。
1. 确定测试目标和范围在进行嵌入式技术测试之前，首先需要明确测试目标和范围。
测试目标可以是验证系统的功能、性能、可靠性和安全性，也可以是发现系统中的缺陷和问题。
测试范围可以是系统的整体测试，也可以是某个模块或功能的测试。
2. 制定测试计划制定测试计划是测试工作的重要一步，它包括了测试资源的分配、测试环境的搭建、测试用例的编写和测试进度的安排。
在制定测试计划时，需要考虑到测试资源的可用性和测试的时间限制，并确保测试计划能够全面覆盖系统的功能和需求。
3. 编写测试用例测试用例是测试工作的核心，它描述了在给定条件下的输入、预期输出和测试步骤。
编写测试用例需要根据系统需求和设计文档，考虑到各种可能的输入情况和边界条件。
测试用例应该覆盖系统的所有功能和操作，并且应该确保用例的可重现性和可维护性。
4. 执行测试用例在执行测试用例时，需要按照测试计划中的安排，使用测试工具和设备来模拟系统运行环境，对系统进行功能测试、性能测试和安全性测试等。
在执行测试用例的过程中，要记录测试的结果和日志，以便后续的问题分析和解决。
5. 分析测试结果在测试工作完成后，需要对测试结果进行分析和评估。
分析测试结果可以发现系统中的缺陷、问题和性能瓶颈，并根据测试结果来制定相应的改进措施和优化方案。
评估测试结果可以对系统的质量和性能进行评价，以便决策是否满足了设计要求和需求。
6. 缺陷管理和优化迭代在测试过程中，发现的缺陷和问题需要进行管理和追踪。
嵌入式系统设计师软考大纲嵌入式系统设计师的软考大纲主要包括以下内容：1. 嵌入式系统基础知识计算机科学基础：包括数制及转换、数据的表示、算术和逻辑运算、计算机系统结构和重要部件的基本工作原理等。
嵌入式系统硬件知识：包括数字电路和逻辑电路基础等。
2. 嵌入式系统分析系统需求分析：能根据用户需求进行系统分析，确定系统的主要功能和性能指标。
系统设计：根据系统需求，进行系统总体设计和详细设计，确定系统的硬件和软件结构，选择合适的开发工具和开发平台。
3. 嵌入式系统设计与开发嵌入式系统软件设计：能根据系统需求和硬件平台，进行嵌入式系统的软件设计，包括操作系统、驱动程序、应用程序等的设计。
嵌入式系统硬件设计：能根据系统需求和硬件平台，进行嵌入式系统的硬件设计，包括电路板、芯片、传感器等的设计。
4. 嵌入式系统实施系统集成与测试：能根据系统的设计和需求，进行系统的集成和测试，确保系统的功能和性能符合要求。
系统部署与实施：能根据实际应用场景，进行系统的部署和实施，包括设备安装、调试、优化等。
5. 嵌入式系统运行维护系统运行与维护：能根据系统的运行状态，进行系统的运行和维护，包括故障排查、系统升级等。
系统性能优化：能根据系统的性能表现，进行系统的性能优化，提高系统的运行效率。
6. 信息化基础知识与信息技术标准了解信息化基础知识、信息技术引用的基础知识。
了解信息技术标准、安全，以及有关法律的基本知识。
7. 外语能力正确阅读和理解计算机及嵌入式领域的英文资料。
8. 其他要求了解嵌入式技术发展趋势。
熟悉考试科目1嵌入式系统基础知识中的选择题答题方式。
考试时间为150分钟，笔试。
熟悉考试科目2嵌入式系统应用技术（案例分析）的答题方式。
考试时间为150分钟，笔试，问答题。
以上是嵌入式系统设计师软考大纲的主要内容，仅供参考，具体考试内容和要求可能会根据实际情况有所调整。
一、嵌入式系统与嵌入式操作系统1、嵌入式系统嵌入式系统是以嵌入式计算机为技术核心，面向用户、面向产品、面向应用，软硬件可裁减的；适用于对功能、可靠性、成本、体积、功耗等综合性能有严格要求的专用计算机系统。
嵌人式系统应具有的特点是：高可靠性；在恶劣的环境或突然断电的情况下，系统仍然能够正常工作；许多嵌人式应用要求实时性，这就要求嵌入式操作系统具有实时处理能力；嵌入式系统和具体应用有机地结台在一起，它的升级换代也是和具体产品同步进行；嵌入式系统中的软件代码要求高质量、高可靠性；一般都固化在只读存储器中或间存中，也就是说软件要求固态化存储，而不是存储在磁盘等载体中。
2、嵌入式操作系统嵌入式操作系统EOS（Embedded Operating System）是一种用途广泛的系统软件，过去它主要应用于工业控制和国防系统领域。
EOS负责嵌人系统的全部软、硬件资源的分配、调度工作，控制。
协调并发活动；它必须体现其所在系统的特征，能够通过装卸某些模块来达到系统所要求的功能。
目前，已推出一些应用比较成功的EOS产品系列。
随着Internet技术的发展、信息家电的普及应用及EOS的微型化和专业化，EOS开始从单一的弱功能向高专业化的强功能方向发展。
嵌人式操作系统在系统实时高效性、硬件的相关依赖性、软件固态化以及应用的专用性等方面具有较为突出的特点。
EOS是相对于一般操作系统而言的，它除具备了一般操作系统最基本的功能，如任务调度、同步机制、中断处理、文件功能等外，还有以下特点：(1)可装卸性。
开放性、可伸缩性的体系结构。
(2)强实时性。
EOS实时性一般较强，可用于各种设备控制当中。
(3)统一的接口。
提供各种设备驱动接日。
(4)操作方便、简单、提供友好的图形GUI，图形界面，追求易学易用。
(5)提供强大的网络功能，支持TCP门P协议及其它协议，提供TCP／UDP／IP／PPP协议支持及统一的MAC访问层接口，为各种移动计算设备预留接口。
嵌入式软件测试基本概念本文内容来源于互联网这里讨论的嵌入式软件测试是一个系统测试的概念。
即将开发的软件系统（包括嵌入式操作系统和嵌入式应用软件）、硬件系统和其它相关因素（如人员的操作、数据的获取等）综合起来，对整个产品进行的全面测试。
嵌入式系统的系统测试比PC系统软件测试要困难得多，主要体现如下：1.测试软件功能依赖不需编码的硬件功能，快速定位软硬件错误困难；2.强壮性测试、可知性测试很难编码实现；3.交叉测试平台的测试用例、测试结果上载困难；4.基于消息系统测试的复杂性，包括线程、任务、子系统之间的交互，并发、容错和对时间的要求；5.性能测试、确定性能瓶颈困难；6.实施测试自动化技术困难。
嵌入式软件测试和传统软件测试异同点嵌入式软件与别的软件相比，它具有专用性，它只能在需求所指定的硬件平台上执行，并且嵌入式软件的开发环境和运行环境是不一致的，因此即使宿主机环境下测试再充分，也不能说明在目标机环境下运行该软件就不出问题。
因而，嵌入式软件还面临着目标环境的测试。
这不仅增加了测试的代价，而且还带来了嵌入式软件的测试策略问题，即哪些测试分配在宿主环境进行，哪些测试分配到目标环境下进行（户军茹，2007）。
所以嵌入式软件测试更有它的必要性，而且比一般的软件测试存在更多的困难。
嵌入式软件测试与普通软件测试的相同之处传统的软件测试是将软件分在不同的层面上进行测试，包括模块测试（或单元测试），集成测试，系统测试等。
嵌入式软件测试和一般的软件测试存在着许多相似的问题和相似的解决方法。
这就是我们寻找的嵌入式软件的通用的测试方法。
按阶段可分为单元测试、集成测试、系统测试和确认测试。
单元测试(Unit testing):完成对最小的软件设计单元的验证工作，只有在该基础之上才能保证后续的测试工作。
主要采用白盒测试技术，用来保证单元的最大覆盖率和发现编码和详细设计中的错误。
单元测试一般可以就在宿主环境上运行。
嵌入式测试系统一般分为以下几个单元:预处理和词法语法分析单元、插桩单元和测试信息分析和显示单元以及测试用例单元。
嵌入式软件测试基础知识测试是传统软件开发的最后一步。
整个软件开发过程，需要收集要求、进行高层次的设计、详细设计、创建代码、进行部分单元测试，然后集成，最后才开始最终测试。
最佳的开发实践应包含代码检查这个步骤。
然而代码检查一般只能找出70%的系统错误，因此完美的测试环节绝对必不可少。
测试就像个复式记帐系统，可以确保将缺陷扼杀在最终推出的产品之前。
在所有其它的工程实践中，测试都被视为基本环节。
比如，在美国，每一座联邦政府出资修建的桥都必须经过大量的风洞测试。
而在软件领域，测试并没有很受重视。
尽管测试是所有工程实践准则的关键部分，但编写测试程序却感觉是在浪费时间。
好在嵌入式系统设计界内的许多领域已经将测试作为其工作的核心部分，他们认识到将这个关键步骤放在项目末期极不明智，因而主张同步地编写测试程序和应用程序。
嵌入式系统软件测试在诸多方面都与应用软件测试一样。
不过，应用测试与嵌入式系统测试之间还是存在一些重要差异。
嵌入式开发人员一般会用到基于硬件的测试工具，而这类工具通常不会用于应用开发过程中。
此外，嵌入式系统一般都有些独一无二的特性，这些特性应该在测试计划中得以体现。
本文将介绍测试和测试案例开发的基础知识，并指出整个嵌入式系统测试工作的特有细节。
何时测试以及如何测试从图1可以看出，在可行的条件下，测试应尽早展开。
一般来讲，最早的测试是由最初的开发人员进行的模块或单元测试。
遗憾的是，开发人员大多对如何建构一整套测试例程以进行测试所知不足。
由于精心设计的测试例程通常直到集成测试时才能使用，因此许多在单元测试过程中就能找出的缺陷直到集成测试时才会被发现。
比如，硅谷的一家大型网络设备厂商为找出其软件集成问题的关键原因，进行了一项研究。
这家厂商发现，在项目集成阶段找出的缺陷中，有70%是由在集成之前从没被执行过的程序所产生的。
2012-3-16 11:05:05 上传下载附件 (9.94 KB)图1：改正问题的成本。
单元测试：开发人员在单独进行模块级测试时一般是编写存根代码(stub code)取代余下的系统软硬件。
在开发周期的这个环节，测试主要侧重于代码的逻辑性能。
通常，开发人员会分别使用某些平均值、高值或低值、以及某些超出范围的值(以测试代码的异常处理功能)进行测试。
但这些基于“黑匣子”的测试仅能对模块中整个代码的一部分进行测试。
回归测试：测试不应是一劳永逸的。
每次修改程序后都应该重新进行测试，以确保这些更改不会无意中“误伤”某些不相关的行为。
称为回归测试的这类测试，一般是通过测试脚本自动进行的。
比如，如果你设计了一组100个输入/输出(I/O)测试，回归测试脚本会自动执行这100个测试，然后将输出与一组“黄金标准”输出进行对比。
每次对代码的任何部分进行修改时，都要对包含被修改代码的整个程序运行整套回归测试程序包，以确保修改过程中不会“误伤”其余代码。
测试什么因为没有一个实际的测试集可以证明一个程序是正确的，因此关键问题变成了哪个测试子集最有可能检测到最多的错误。
选择合适的测试例程的问题被称为测试例程设计。
虽然存在数十种测试案例的设计方法，但它们通常可归为两种截然不同的方法：功能测试和覆盖测试。
功能测试(也称为黑匣子测试)选择可评估实现与需求规格符合程度的测试。
覆盖测试(也称为白匣子测试)选择可执行代码某些部分的测试例程。
(过后，将详细讨论这两种方法。
)这两种测试都是对嵌入式设计进行严格测试所必需的。
其中，覆盖测试表示代码的稳定性，所以这种测试是用于已经完成或将近完成的产品的。
另一方面，可在编写要求文档时，同时编写功能测试。
事实上，从功能测试开始入手，可以最大限度地降低重复劳动和重写测试案例的工作。
因此，在我看来，要先考虑功能测试。
每个人都同意先编写功能测试这个观点，有人认为，功能测试在系统集成阶段(而不是在单元测试时)最有用。
以下是整合功能测试和覆盖测试方法的一个简单处理流程：1．找出哪些功能未被功能测试完全覆盖。
2．找出每个功能的哪些部分没被执行。
3．找出需要哪些额外的覆盖测试。
4．运行新增的额外测试。
5．重复以上步骤。
何时停止测试？最通用的停止标准(按可靠性排序)如下：1．老板命令停止测试2．新的测试周期找到的新缺陷少于X个3．在没有发现任何新缺陷的情况下已经满足了某个覆盖阀限无论你多么彻底地测试了程序，都无法保证找出所有缺陷。
这引发了另一个有趣的问题：你可容忍多少缺陷？假设在极端软件压力测试过程中，你发现系统每进行大约20小时的测试就会锁定。
你仔细地检查程序，但是仍无法找出这个错误的根源。
这个时候你应该交付产品吗？多少测试才“足够好”？这个我说不好。
但遵循一些久经时间考验的规则总是好的：“如果方法Z预估Y行代码中的缺陷少于X个，那么就可放心地发布程序了。
”也许有一天会出现这种标准。
编程行业仍然相对年轻，还达不到类似建筑业那样的成熟度。
许多厚厚的建筑手册和大本规范是多年经验的结晶，它们可为建筑师、土木工程师和结构工程师提供按工期在预算内、建造一栋安全建筑所需的全部信息。
偶尔虽仍会有建筑倒塌，但毕竟很少见。
在编程行业制定出类似标准前，“多少测试才足够？”就是个主观判断问题。
选择测试案例在理想情况下，你可能想要测试程序中每一个可能的行为。
这意味着每一种可能的输入组合或者每一种可能的判定路径至少测试一次。
这是个崇高但完全不切实际的目标。
比如，Glen Ford Myers在其《软件测试的艺术》一书中就描述了一个只用五个判定条件就可有1014个不同执行路径的小程序。
他指出，如果你能够每五分钟就能编写、执行并验证一个测试例程的话，那么全面彻底地测试完这个小程序需要10亿年时间。
显然，理想的状况是无法实现的，因此你必须采用接近这种理想状况的标准。
如你所见，功能测试与覆盖测试相结合可以提供合理的次优选择方案。
基本方法是选择最有可能发现错误的测试(一部分功能测试，一部分覆盖测试)。
1．功能测试功能测试一般称为黑匣子测试，因为在编写功能测试的测试例程时并没有涉及实际的代码。
换句话说，没有触及到“匣子内”。
嵌入式系统有输入和输出，并在输入和输出之间执行某些算法。
黑匣子测试是根据对哪些输入应该是可接受的以及这些输入应与输出有何种关系的了解来进行的。
黑匣子测试完全不了解输入与输出之间的算法是如何实现的。
黑匣子测试的示例包括：压力测试：有意使输入通道、内存缓冲器、磁盘控制器、存储器管理系统等过载的测试边界值测试：表示特定范围内的“边界”的输入(例如，对于整数输入而言，是最大和最小整数以及-1、0、+1)；以及应使输出在输出范围的类似边界出现跨变的输入值。
异常测试：能触发故障模式或异常模式的测试。
错误推测：根据以前的软件测试经验或者从测试类似程序获得的经验进行的测试。
随机测试：通常，这是效率最低的一种测试方法，但却仍然广泛用于评估用户界面代码的鲁棒性。
性能测试：由于性能预期是产品要求的一部分，因此性能分析属于功能测试的范畴。
由于黑匣子测试仅取决于程序要求及其I/O行为，因此一旦完成功能要求的编写，即可开发这类测试。
这使得黑匣子测试例程的开发可以与余下的系统设计同步进行。
与所有测试一样，功能测试应被设计得具有破坏性，也即，要试图证明程序无法工作。
这包括使输入通道过载、随意地敲打键盘，以及故意地做程序员认为会破坏其程序的所有事情。
作为研发产品经理，这是我的主要测试方法之一。
如果产品在经过40个小时的极限测试(abuse testing)后，并没发现任何严重或者致命的缺陷，那么就可以发布这个产品了。
如果找到了一个重大的缺陷，那么修正这个缺陷后，还必须重复前面的测试步骤。
2．覆盖测试功能测试的缺点是其很少执行全部代码。
覆盖测试则试图规避这个缺点，它采用的方法是(理想地)确保每一条代码语句、判定点或者判定路径都至少被测试一次。
覆盖测试还可以显示已经访问的数据空间大小。
覆盖测试也称为白匣子测试或玻璃匣子测试，这类测试的设计需要全面了解软件的实现方式，也就是说，它要“看到匣子里面”。
白匣子测试利用了源代码所能提供的方便。
白匣子测试充分借力了程序员对程序API、内部控制结构的知识，分享了程序员的异常处理能力。
由于白匣子测试取决于具体的实现决策，因此要到应用代码完成后，才能动手设计这类测试。
从嵌入式系统的角度来看，覆盖测试是最重要的测试，这是因为只要你把握已在多大程度上对代码进行了测试，你就可很好地预警出现未发现缺陷的风险。
白匣子测试的示例包括：语句覆盖：选择的测试案例可以至少将程序中的每一条语句执行一次。
判定或分支覆盖：选择的测试例程可以使每一个分支（条件为真和假的路径）至少执行一次。
条件覆盖：选择的测试例程可以强制判定中的每一个条件(项)都包含所有可能的逻辑值。
理论上，白匣子测试可以利用或控制所需的任何对象来执行其测试。
因此，白匣子测试可能使用JTAG接口强制设定特定的存储器值作为测试的一部分。
实践上，白匣子测试可以分析逻辑分析仪报告的执行路径。
3．灰匣子测试由于白匣子测试可以深入代码内部，因此与黑匣子测试相比，这类测试的维护成本更高。
只要要求和I/O关系保持稳定，黑匣子测试就会一直有效；但每次修改代码后，可能都需要重新进行白匣子测试。
因此成本效益最高的白匣子测试一般是那些在不深入编程细节的情况下利用实现知识进行的测试。
较少涉及代码细节的测试有时也称为灰匣子测试。
当与“错误推测”配合使用时，灰匣子测试非常有效。
如果你知道(或者至少猜到)代码中的弱点在哪里，那么你就可以设计出对这些弱点“施压”的测试案例。
因为这些测试覆盖了代码的特定部分，因此这些测试是灰匣子测试；因为这些测试是根据可能会出现哪些错误的猜测而选择的，因此这些测试是错误推测测试。
在整合新功能与稳定的旧代码库时，这种测试策略非常有用。
由于代码库已经过全面的测试，因此将测试重点集中在新、旧代码交集处可以起到事半功倍的效果。
