|
|
知识路径： > 嵌入式系统的项目开发与维护知识 > 嵌入式系统软件测试 > 嵌入式软件测试技术 >
|
被考次数：4次
被考频率：中频率
总体答错率：63%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：31个
|
|
|
|
|
按照测试内容划分，测试类型一般有逻辑测试、功能测试、性能测试、接口测试、人机交互界面测试、强度测试、余量测试、安全性测试、恢复性测试、边界测试、数据处理测试、安装性测试、容量测试等。
|
|
|
|
（1）逻辑测试。逻辑测试是测试程序逻辑结构的合理性、实现的正确性。逻辑测试由测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。逻辑测试根据不同的软件级别一般需进行语句覆盖、分支覆盖、条件覆盖、条件组合覆盖、路径覆盖、MC/DC覆盖等。
|
|
|
|
（2）功能测试。功能测试是对软件需求规格说明或设计文档中的功能需求逐项进行的测试，以验证其功能是否满足要求。功能测试一般需进行：用正常值的等价类输入数据值测试；用非正常值的等价类输入数据值测试；进行每个功能的合法边界值和非法边界值输入的测试；用一系列真实的数据类型和数据值运行，测试超负荷、饱和及其他“最坏情况”的结果；在配置项测试时对配置项控制流程的正确性、合理性等进行验证。
|
|
|
|
（3）性能测试。性能测试是对软件需求规格说明或设计文档中的性能需求逐项进行的测试，以验证其性能是否满足要求。性能测试一般需进行：测试在获得定量结果时程序计算的精确性（处理精度）；测试其时间特性和实际完成功能的时间（响应时间）；测试为完成功能所处理的数据量；测试程序运行所占用的空间；测试其负荷潜力；测试配置项各部分的协调性；在系统测试时测试软件性能和硬件性能的集成；在系统测试时测试系统对并发事物和并发用户访问的处理能力。
|
|
|
|
（4）接口测试。接口测试是对软件需求规格说明或设计文档中的接口需求逐项进行的测试。接口测试一般需进行：测试所有外部接口，检查接口信息的格式及内容；对每一个外部输入／输出接口必须做正常和异常情况的测试；测试硬件提供的接口是否便于使用；测试系统特性（如数据特性、错误特性、速度特性）对软件功能、性能特性的影响；对所有的内部接口的功能、性能进行测试。
|
|
|
|
（5）人机交互界面测试。人机交互界面测试是对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户的要求。人机交互界面测试一般需进行：测试操作和显示界面及界面风格与软件需求规格说明中要求的一致性和符合性；以非常规操作、误操作、快速操作来检验人机界面的健壮性；测试对错误命令或非法数据输入的检测能力与提示情况；测试对错误操作流程的检测与提示；对照用户手册或操作手册逐条进行操作和观察。
|
|
|
|
（6）强度测试。强度测试是强制软件运行在不正常到发生故障的情况下（设计的极限状态到超出极限），检验软件可以运行到何种程度的测试。强度测试一般需：提供最大处理的信息量；提供数据能力的饱和实验指标；提供最大存储范围（如常驻内存、缓冲、表格区、临时信息区）；在能力降级时进行测试；在人为错误（如寄存器数据跳变、错误的接口）状态下进行软件反应的测试；通过启动软件过载安全装置（如临界点警报、过载溢出功能、停止输入、取消低速设备等）生成必要条件，进行计算过载的饱和测试；需进行持续一段规定的时间，而且连续不能中断的测试。
|
|
|
|
（7）余量测试。余量测试是对软件是否达到需求规格说明中要求的余量的测试。若无明确要求时，一般至少留有20%的余量。根据测试要求，余量测试一般需提供：全部存储量的余量；输入／输出及通道的吞吐能力余量；功能处理时间的余量。
|
|
|
|
（8）安全性测试。安全性测试是检验软件中已存在的安全性、安全保密性措施是否有效的测试。测试应尽可能在符合实际使用的条件下进行。安全性测试一般需进行：对安全性关键的软件部件，必须单独测试安全性需求；在测试中全面检验防止危险状态措施的有效性和每个危险状态下的反应；对设计中用于提高安全性的结构、算法、容错、冗余及中断处理等方案，必须进行针对性测试；对软件处于标准配置下其处理和保护能力的测试；应进行对异常条件下系统／软件的处理和保护能力的测试（以表明不会因为可能的单个或多个输入错误而导致不安全状态）；对输入故障模式的测试；必须包含边界、界外及边界结合部的测试；对“0”、穿越“0”以及从两个方向趋近“0”的输入值的测试；必须包括在最坏情况配置下的最小输入和最大输入数据率的测试；对安全性关键的操作错误的测试；对具有防止非法进入软件并保护软件的数据完整性能力的测试；对双工切换、多机替换的正确性和连续性的测试；对重要数据的抗非法访问能力的测试。
|
|
|
|
（9）恢复性测试。恢复性测试是对有恢复或重置功能的软件的每一类导致恢复或重置的情况逐一进行的测试，以验证其恢复或重置功能。恢复性测试是要证实在克服硬件故障后，系统能否正常地继续进行工作，且不对系统造成任何损害。恢复性测试一般需进行：探测错误功能的测试；能否切换或自动启动备用硬件的测试；在故障发生时能否保护正在运行的作业和系统状态的测试；在系统恢复后，能否从最后记录下来的无错误状态开始继续执行作业的测试。
|
|
|
|
（10）边界测试。边界测试是对软件处在边界或端点情况下运行状态的测试。边界测试一般需进行：软件的输入域或输出域的边界或端点的测试；状态转换的边界或端点的测试；功能界限的边界或端点的测试；性能界限的边界或端点的测试；容量界限的边界或端点的测试。
|
|
|
|
（11）数据处理测试。数据处理测试是对完成专门数据处理功能所进行的测试。数据处理测试一般需进行：数据采集功能的测试；数据融合功能的测试；数据转换功能的测试；剔除坏数据功能的测试；数据解释功能的测试。
|
|
|
|
（12）安装性测试。安装性测试是对安装过程是否符合安装规程的测试，以发现安装过程中的错误。安装性测试一般需进行：不同配置下的安装和卸载测试；安装规程的正确性测试。
|
|
|
|
（13）容量测试。容量测试是检验软件的能力最高能达到什么程度的测试。容量测试一般应测试到在正常情况下软件所具备的最高能力，如：响应时间或并发处理个数等能力。
|
|
|
|
根据软件开发阶段和测试对象，一般可分为单元测试、部件测试（也称为集成测试或组装测试）、配置项测试和系统测试。
|
|
|
|
|
|
单元测试的对象是软件单元。软件单元测试的目的是检查每个软件单元能否正确地实现设计说明中的功能、性能、接口和其他设计约束等要求，发现单元内可能存在的各种错误。一般由软件的供方组织并实施软件单元测试，也可委托第三方进行软件单元测试。软件单元测试可根据软件单元的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。单元测试一般应符合以下的技术要求：
|
|
|
|
（1）在对软件单元进行动态测试之前，应对软件单元的源代码进行静态测试。
|
|
|
|
（2）应建立测试软件单元的环境，如桩模块和驱动模块，其测试环境应通过评审。
|
|
|
|
（3）对软件设计文档规定的软件单元的功能、性能、接口等应逐项进行测试。
|
|
|
|
（4）软件单元的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖。
|
|
|
|
（5）测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。
|
|
|
|
|
|
|
|
|
|
软件单元测试一般应采用静态测试方法和动态测试方法。通常静态测试先于动态测试。软件单元测试完成后形成的文档有：软件单元测试计划；软件单元测试说明；软件单元测试报告；软件单元测试记录；软件单元测试问题报告。
|
|
|
|
|
|
部件测试的对象包括软件部件的组装过程和组装得到的软件部件，软件部件由软件单元组成。软件部件测试的目的是检验软件单元和软件部件之间的接口关系，并验证软件部件是否符合设计要求。软件部件测试一般由软件供方组织并实施，测试人员与开发人员应相对独立；也可委托第三方进行软件部件测试。软件部件测试可根据软件部件的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。部件测试一般应符合以下技术要求：
|
|
|
|
（1）应对构成软件部件的每个软件单元的单元测试情况进行检查。
|
|
|
|
（2）若对软件部件进行必要的静态测试，应先于动态测试。
|
|
|
|
|
|
（4）应建立部件测试环境，如桩模块和驱动模块，其测试环境应通过评审。
|
|
|
|
（5）应逐项测试软件设计文档规定的软件部件的功能、性能等特性。
|
|
|
|
（6）软件部件的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖。
|
|
|
|
（7）测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。
|
|
|
|
（8）应测试软件单元和软件部件之间的所有调用，达到要求的测试覆盖率。
|
|
|
|
|
|
（10）应测试软件部件之间、软件部件和硬件之间的所有接口。
|
|
|
|
（11）应测试运行条件（如数据结构、输入／输出通道容量、内存空间、调用频度等）在边界状态下，进而在人为设定的状态下，软件部件的功能和性能。
|
|
|
|
（12）应按设计文档要求，对软件部件的功能、性能进行强度测试。
|
|
|
|
（13）对安全性关键的软件部件，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。
|
|
|
|
|
|
软件部件测试一般应采用静态测试方法和动态测试方法。静态测试方法常采用静态分析、代码审查等方法，动态测试方法常采用白盒测试方法和黑盒测试方法。通常，静态测试先于动态测试。
|
|
|
|
在由软件单元和软件部件组装成新的软件部件时，应根据软件单元和软件部件的特点选择便于测试的组装策略。按测试过程中，组合软件单元的方式，有两种不同的组装策略，即一次性组装策略和增值式组装策略。
|
|
|
|
一次性组装策略是一种非增值集成方式，首先完成全部软件单元测试，然后再把所有的软件单元集成在一起进行测试，最终得到要求的软件系统。一次性组装策略的优点是工作量相对较小，缺点是定位错误比较困难。
|
|
|
|
增值式组装策略也称为递增集成法，即依次将软件单元增加到已测试完成的软件部件中，将已测试的软件部件组装为更大的软件部件，在组装的过程中边增加边测试，以便发现组装过程中的问题。最后增值逐步组装为要求的软件系统。根据组装的过程又可分为自顶向下组装、自底向上组装、“三明治”组装、定向冒险组装、功能定向组装等策略。
|
|
|
|
软件部件测试完成后形成的文档包括：软件部件测试计划；软件部件测试说明；软件部件测试报告；软件部件测试记录；软件部件测试问题报告。
|
|
|
|
|
|
配置项测试的对象是计算机软件配置项（CSCI，以下简称配置项），软件配置项是为独立的配置管理而设计的并且能满足最终用户功能的一组软件。软件配置项测试的目的是检验软件配置项与软件需求规格说明的致一性。配置项测试可根据软件配置项的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。配置项测试一般应符合以下技术要求：
|
|
|
|
|
|
（2）应逐项测试软件需求规格说明规定的配置项的功能、性能等特性。
|
|
|
|
（3）配置项的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖。
|
|
|
|
（4）测试用例的输入应至少包括有效等价类值、无效等价值和边界数据值。
|
|
|
|
|
|
（6）应测试人机交互界面提供的操作和显示界面，包括用非常规操作、误操作、快速操作测试界面的可靠性。
|
|
|
|
（7）应测试运行条件在边界状态和异常状态下，或在人为设定的状态下，配置项的功能和性能。
|
|
|
|
（8）应按软件需求规格说明的要求，测试配置项的安全性和数据的安全保密性。
|
|
|
|
（9）应测试配置项的所有外部输入、输出接口（包括和硬件之间的接口）。
|
|
|
|
（10）应测试配置项的全部存储量、输入／输出通道的吞吐能力和处理时间的余量。
|
|
|
|
（11）应按软件需求规格说明的要求，对配置项的功能、性能进行强度测试。
|
|
|
|
（12）应测试设计中用于提高配置项的安全性和可靠性的方案，如结构、算法、容错、冗余、中断处理等。
|
|
|
|
（13）对安全性关键的配置项，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。
|
|
|
|
（14）对有恢复或重置功能需求的配置项，应测试其恢复或重置功能和平均恢复时间，并且对每一类导致恢复或重置的情况进行测试。
|
|
|
|
|
|
应保证软件配置项测试工作的独立性。软件配置项测试一般由软件的供方组织，由独立于软件开发的组织实施。软件配置项测试一般应采用黑盒测试方法。
|
|
|
|
软件配置项测试完成后形成的文档有：软件配置项测试计划；软件配置项测试说明；软件配置项测试报告；软件配置项测试记录；软件配置项测试问题报告。
|
|
|
|
|
|
系统测试的对象是完整的、集成的计算机系统（CS），重点是新开发的配置项的集合。系统测试的目的是在真实系统工作环境下检验完整的软件配置项能否和系统正确连接，并满足系统／子系统设计文档和软件开发任务书规定的要求。可根据软件系统的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。系统测试一般应符合以下技术要求：
|
|
|
|
（1）应按系统／子系统设计说明的规定，逐项测试系统的功能、性能等特性。
|
|
|
|
（2）系统的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖。
|
|
|
|
（3）测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。
|
|
|
|
|
|
（5）应测试配置项之间及配置项与硬件之间的所有接口。
|
|
|
|
（6）应在边界状态、异常状态或在人为设定的状态的运行条件下，测试系统的功能和性能。
|
|
|
|
|
|
（8）应测试系统的全部存储量、输入／输出通道的吞吐能力和处理时间的余量。
|
|
|
|
（9）应按系统或子系统设计文档的要求，对系统的功能、性能进行强度测试。
|
|
|
|
（10）应测试人机交互界面提供的操作和显示界面，包括用非常规操作、误操作、快速操作测试界面的可靠性。
|
|
|
|
（11）应测试设计中用于提高系统安全性和可靠性的方案，如结构、算法、容错、冗余、中断处理等。
|
|
|
|
（12）对安全性关键的系统，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。
|
|
|
|
（13）对有恢复或重置功能需求的系统，应测试其恢复或重置功能和平均恢复时间，并且对每一类导致恢复或重置的情况进行测试。
|
|
|
|
|
|
|
|
系统测试一般由软件的需方组织，由独立于软件开发的组织实施。系统测试一般应采用黑盒测试方法。
|
|
|
|
系统测试完成后形成的文档包括：系统测试计划；系统测试说明；系统测试报告；系统测试记录；系统测试问题报告。
|
|
|
|
|
