嵌入式软件的测试方法和工具
由安博测试空间技术中心https://www.doczj.com/doc/922824704.html,/提供
通常嵌入式系统对可靠性的要求比较高。嵌入式系统安全性的失效可能会导致灾难性的后果，即使是非安全性系统，由于大批量生产也会导致严重的经济损失。这就要求对嵌入式系统，包括嵌入式软件进行严格的测试、确认和验证。随着越来越多的领域使用软件和微处理器控制各种嵌入式设备，对门益复杂的嵌入式软件进行快速有效的测试愈加显得重要。
软件测试的目的是保证软件满足需求规格说明。系统失效是系统没有满足—个或多个正式需求规范中所要求的需求项。嵌入式软件有其特殊的失效判定准则，但是，嵌入式软件测试的日的与非嵌入式软件是相同的。在嵌入式系统设计中，软件正越来越多地取代硬件，以降低系统的成本，获得更大的灵活性，这就需要使用更好的测试方法和工具进行嵌入式和实时软件的测试。本文讨论可应用于嵌入式软件的测试方法：介绍现有嵌入式软件的测试工具。
一、嵌入式软件的测试方法
一般来说，软件测试有7个基本阶段，即单元或模块测试、集成测试、外部功能测试、回归测试、系统测试、验收测试、安装测试。嵌入式软件测试在4个阶段上进行，即模块测试、集成测试、系统测试、硬件/软件集成测试。前3个阶段适用于任何软件的测试，硬件/软件集成测试阶段是嵌入式软件所特有的，目的是验证嵌入式软件与其所控制的硬件设备能否正确地交互。
1、白盒测试与黑盒测试
一般来说，软件测试有两种基本的方式，即白盒测试方法与黑盒测试方法，嵌入式软件测试也不例外。
白盒测试或基本代码的测试检查程序的内部设计。根据源代码的组织结构查找软件缺陷，一股要求测试人员对软件的结构和作用有详细的了解，白盒测试与代码覆盖率密切相关，可以在白盒测试的同时计算出测试的代码的覆盖率，保证测试的充分性。把100％的代码都测试到几乎是不可能的，所以要选择最重要的代码进行白盒测试。由于严格的安全性和可靠性的要求，嵌入式软件测试同非嵌入式软件测试相比，通常要求有更高的代码覆盖率。对于嵌入式软件，白盒测试一般不必在目标硬件上进行，更为实际的方式是在开发环境中通过硬件仿真进行，所以选取的测试工具应该支持在宿主环境中的测试。
黑盒测试在某些情况下也称为功能测试。这类测试方法根据软件的用途和外部特征查找软件缺陷，不需要了解程序的内部结构。黑盒测试最大的优势在于不依赖代码，而是从实际使用的角度进行测试，通过黑盒测试可以发现白盒测试发现不了的问题。因为黑盒测试与需求紧密相关，需求规格说明的质量会直接影响测试的结果，黑盒测试只能限制在需求的范围内进行。在进行嵌入式软件黑盒测试时，要把系统的预期用途作为重要依据，根据需求中对负载、定时、性能的要求，判断软件是否满足这些需求规范。为了保证正确地测试，还须要检验软硬件之间的接口。嵌入式软件黑盒测试的一个重要方面是极限测试。在使用环境中，通常要求嵌入式软件的失效过程要平稳，所以，黑盒测试不仅要检查软件工作过程，也要检查软件换效过程。
2、目标环境测试和宿主环境测试
在嵌入式软件测试中，常常要在基于目标的测试和基于宿主的测试之间作出折衷。基于目标的测试消耗较多的经费和时间，而基于宿主的测试代价较小，但毕竟是在模拟环境中进行的。目前的趋势是把更多的测试转移到宿主环境中进行，但是，目标环境的复杂性和独特性不可能完全模拟。
在两个环境中可以出现不同的软件缺陷，重要的是目标环境和宿主环境的测试内容有所选择。在宿主环境中，可以进行逻辑或界面的测试、以及与硬件无关的测试。在模拟或宿主环境中的测试消耗时间通常相对较少，用调试工具可以更快地完成调试和测试任务。而与定时问题有关的白盒测试、中断测试、硬件接口测试只能在目标环境中进行。在软件测试周期中，基于目标的测试是在较晚的“硬件/软件集成测试”阶段开始的，如果不更早地在模拟环境中进行白盒测试，而是等到“硬件/软件集成测试”阶段进行全部的白盒测试，将耗费更多的财力和人力。
二、嵌入式软件的测试工具
用于辅助嵌入式软件测试的工具很多，下面对几类比较有用的有关嵌入式软件的测试工具加以介绍和分析。
1、内存分析工具
在嵌入式系统中，内存约束通常是有限的。内存分析工具用来处理在动态内存分配中存在的缺陷。当动态内存被错误地分配后，通常难以再现，可能导致的失效难以追踪，使用内存分析工具可以避免这类缺陷进入功能测试阶段。目前有两类内存分析工具——软件和硬件的。基于软件的内存分析工具可能会对代码的性能造成很大影响，从而严重影响实时操作；基于硬件的内存分析工具价格昂贵，而且只能在工具所限定的运行环境中使用。
2、性能分析工具
在嵌入式系统中，程序的性能通常是非常重要的。经常会有这样的要求，在特定时间内处理一个中断，或生成具有特定定时要求的一帧。开发人面临的问题是决定应该对哪一部分代码进行优化来改进性能，常常会花大量的时间去优化那些对性能没有任何影响的代码。性能分析工具会提供有关的数据，说明执行时间是如何消耗的，是什么时候消耗的，以及每个例程所用的时间。根据这些数据，确定哪些例程消耗部分执行时间，从而可以决定如何优化软件，获得更好的时间性能。对于大多数应用来说，大部分执行时间用在相对少量的代码上，费时的代码估计占所有软件总量的5%-20%。性能分析工具不仅能指出哪些例程花费时间，而且与调试工具联合使用可以引导开发人员查看需要优化的特定函数，性能分析工具还可以引导开发人员发现在系统调用中存在的错误以及程序结构上的缺陷。
3、GUI测试工具
很多嵌入式应用带有某种形式的图形用户界面进行交互，有些系统性能测试足根掘用户输入响应时间进行的。GUI测试工具可以作为脚本工具有开发环境中运行测试用例，其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程。很多嵌入式设备没有GUI，但常常可以对嵌入式设备进行插装来运行GUI测试脚本，虽然这种方式可能要求对被测代码进行更改，但是节省了功能测试和回归测试的时间。
4、覆盖分析工具
在进行白盒测试时，可以使用代码覆盖分析工具追踪哪些代码被执行过。分析过程可以通过插装来完成，插装可以是在测试环境中嵌入硬件，也可以是在可执行代码中加入软件，也可以是二者相结合。测试人员对结果数据加以总结，确定哪些代码被执行过，哪些代码被巡漏了。覆盖分析工具一般会提供有关功能覆盖、分支覆盖、条件覆盖的信息。对于嵌入式软件来说，代码覆盖分析工具可能侵入代码的执行，影响实时代码的运行过程。基于硬件的代码覆盖分析工具的侵入程度要小一些，但是价格一般比较昂贵，而且限制被测代码的数量。
结论
嵌入式系统在人类生活中发挥着重要的作用，包括飞行控制器这样的控制系统，以及洗衣机这样的家用电器。日前，嵌入式系统中软件的比重越来越大，也越来越复杂，保证嵌入式软件的可靠性正面临严峻的挑战。
大多数软件测试方法都可以直接或间接地用于嵌入式软件的测试，但是由于操作系统的实时和嵌入式特性，嵌入式软件测试也面临一些特殊的问题。虽然日前已经有一些针对嵌入式软件的测试和调试工具，但是在有些方面仍存在不足，包括许多任务操作系统的并发、非侵入式的测试和凋试、嵌入式系统的软件抽象等。对于嵌入式软件测试技术的研究人选测试工具有待开发，仍须要做很多进一步的工作。
软件测试缺陷报告写作标准
提供准确、完整、简洁、一致的缺陷报告是体现软件测试的专业性、高质量的主要评价指标。遗憾的是，一些缺陷报告经常包含过少或过多信息，而且组织混乱，难以理解。由此
导致缺陷被退回，从而延误及时修正，最坏的情况是由于没有清楚地说明缺陷的影响，开发
人员忽略了这些缺陷，使这些缺陷随软件版本一起发布出去。
因此，软件测试工程师必须认识到书写软件缺陷报告是测试执行过程的一项重要任务，首先要理解缺陷报告读者的期望，遵照缺陷报告的写作准则，书写内容完备的软件缺陷报告。
本文将阐述软件测试缺陷报告的读者，描述软件缺陷报告的主要组成部分和各部分的书写要
求，指出某些常见错误和实用改进方法，最后总结了缺陷报告的写作要点。
1. 缺陷报告的读者对象
在书写软件缺陷报告之前，需要明白谁是缺陷报告的读者对象，知道读者最希望从缺陷报告中获得什么信息。通常，缺陷报告的直接读者是软件开发人员和质量管理人员，除此之
外，来自市场和技术支持等部门的人也可能需要查看缺陷情况。每个阅读缺陷报告的人都需
要理解缺陷针对的产品和使用的技术。另外，他们不是软件测试人员，可能对于具体软件测
试的细节了解不多。
概括起来，缺陷报告的读者最希望获得的信息包括：
?易于搜索软件测试报告的缺陷；
?报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确；
?软件开发人员希望获得缺陷的本质特征和复现步骤；
?市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。
软件测试人员的任务之一就是需要针对读者的上述要求，书写良好的软件缺陷报告。
2. 缺陷报告的写作准则
书写清晰、完整的缺陷报告是对保证缺陷正确处理的最佳手段。它也减少了工程师以及其它质量保证人员的后续工作。
为了书写更优良的缺陷报告，需要遵守“5C”准则：
?Correct（准确）：每个组成部分的描述准确，不会引起误解；
?Clear（清晰）：每个组成部分的描述清晰，易于理解；
?Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；
?Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；
?Consistent（一致）：按照一致的格式书写全部缺陷报告。
3. 缺陷报告的组织结构
尽管不同的软件测试项目对于缺陷报告的具体组成部分不尽相同，但是基本组织结构都是大同小异的。一个完整的软件缺陷报告通常由下列几部分组成：
?缺陷的标题；
?缺陷的基本信息；
o测试的软件和硬件环境；
o测试的软件版本；
o缺陷的类型；
o缺陷的严重程度；
o缺陷的处理优先级。
?复现缺陷的操作步骤；
?缺陷的实际结果描述；
?期望的正确结果描述；
?注释文字和截取的缺陷图像。
对于具体测试项目而言，缺陷的基本信息通常是比较固定的，也是很容易描述的。实际书写软件缺陷报告容易出现问题的地方就是标题、操作步骤、实际结果、期望结果和注释部分。下面针对这些“事故多发地带”具体论述如何提供完整的信息，由于英文是软件开发的主要语言，以下的软件缺陷报告的信息都使用英文书写。
4. 缺陷报告的写作技术
4.1 标题（Title）
标题应该保持简短、准确，提供缺陷的本质信息，并且便于读者搜索查寻。
良好的缺陷标题应该按照下列方式书写：
?
尽量按缺陷发生的原因与结果的方式书写（“执行完A 后，发生B ，”或者“发生B ，当A 执行完后”）； ?
避免使用模糊不清的词语，例如“功能中断，功能不正确，行为不起作用，”等。应该使用具体文字说明功能如何中断，如何不正确，或如何不起作用； ?
为了方便搜索和查询，请使用关键字； ? 为了便于他人理解，避免使术语、俚语或过分具体的测试细节。
请查看下面的表格，该表格列出了有问题的标题，给出了如何改进的示例。
原始描述 错误原因 改进的标题 原始描述 错误原因
改进的标题 Hyphenation does not work 描述太笼统。什
么时候不起作
用？ Text breaks at line's end, but no hyphen
appears
Incorrect behavior with paragraph alignment 描述太笼统。不
正确的行为是什
么？ Justified
alignment leaves gaps in text composition
when tracking is
also applied
Assert:CmdAssertHereInsertSomethingBad-Happens 没有包含原因与
结果信息。断言（Assert ）太长。 Assert,
"SomethingBad" when attempting
to update linked bitmap stored on
server
After each launch then clicking edit and then
copy/paste, there is too much delay 没有指明原因与结果，包含了过分详细的细节信息。
Performance
slows noticeably after ?rst launch
and copy/paste Quotes appear as symbols when they are imported 信息没有充分隔离。所有的引号都如此吗？什么类型的符号？
Imported smart
quotes from
Word appear as
unrecognized
characters 提示
使用"after"，"when"或"during"等连结词有助于描述缺陷的原因和结果，例如： ?
Application crashes after input any letters in numeric field. ? Internal error occurs when closing application.
?Application suspended during email transmission."
4.2 复现步骤（Reproducible Steps）
复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。
但是实际软件测试过程中，总是存在一些不良的缺陷报告，主要的问题在于以下三个方面：
?复现步骤包含了过多的多余步骤，而且句子结构混乱，可读性很差，难于理解；
?复现步骤包含了过少的信息，丢失操作的必要步骤。由于提供的步骤不完整，开发人员经常需要种种猜测，努力尝试复现的步骤，浪费了大量时间。由于缺少关键步
骤，这些缺陷通常被工程师以“不能复现”为由再次发送给测试人员；
?测试人员没有对软件缺陷发生的条件和影响区域进行隔离，软件开发人员无法判断该缺陷影响的软件部分，不能进行彻底修正。
为了避免出现这些问题，良好的复现步骤应该包含本质的信息，并按照下列方式书写：
?提供测试的预备步骤和信息；
o环境变量。例如，如果默认项或预设、调试版本或发布版本等存在问题，请指明使用的操作系统和应用程序的环境变量；
o设置变量：指明哪种打印机、字体或驱动程序是复现Bug所必需的信息；
o复现路径。如果有多种方法触发该缺陷，请在步骤中包含这些方法。同样地，如果某些路径不触发该缺陷，也要包含这些路径。
?简单地一步一步地引导复现该缺陷；
?每一个步骤尽量只记录一个操作；
?每一个步骤前使用数字对步骤编号；
?尽量使用短语和短句，避免复杂句型和句式；
?复现的操作步骤要完整，准确，简短；
?没有缺漏任何操作步骤；
?每个步骤都是准确无误的；
?没有任何多余的步骤；
?将常见步骤合并为较少步骤，例如：
1. Create text frame.
2. Add text.
可以简单的合并成一步：
1. Create a new text frame and add text.
?只记录各个操作步骤是什么，不要包括每个操作步骤执行后的结果
需要再次引起注意的是，缺陷报告的读者对技术有基本的了解，但是对软件测试的细节可能所知有限。因此，一方面，没有必要在缺陷报告中告诉启动产品或者如何打开一个文件等简单操作方法。另一方面，不要包含软件测试过分详细的技术细节，除非这些是缺陷至关重要的信息。
4.3 实际结果（Actual result）
实际结果是执行复现步骤后软件的现象和产生的行为。
实际结果的描述很像缺陷的标题，是标题信息的再次强调，要列出具体的表现行为，而不是简单的指出“不正确”或“不起作用”。
如果一个动作产生彼此不同的多个缺陷结果。为了易于阅读，这些结果应该使用数字列表分隔开来。例如：
Actual result:
1. Assert “CmdLineofCodeHere…”
2. Assert “AlsoBrokenHere…”
有时，一个动作将产生一个结果，而这个结果又产生另一个结果。这种情况可能难以清晰、简洁地总结。例如：
Actual Result：
1. Assert:“CmdLineofCodeBlahBlah…”
2. When this assert is dismissed, app becomes active but all text is unrecognizable.
3. After selecting the text by dragging the text tool, the text appears normally once again.
对于这些较难处理的情况，有多种使之易于阅读的解决方法：
?尽可能将缺陷分解成多个缺陷报告，并使用交叉引用说明彼此之间的联系。这些动作的结果通常比较相似但缺陷不同。首先进行更多的隔离测试，缩小产生缺陷的范
围，查看是否产生多个缺陷；
?在实际结果部分，仅列出缺陷的一到两个表现特征。使用注释（Notes）部分列出缺陷的其它问题；
?在缺陷的第一个表现特征后，将随后的步骤和缺陷表现特征移到注释部分。重要的信息几乎总是包含在第一个断言或错误里，其它错误都是第一个错误的变种。
4.4 期望结果（Expected result）
期望结果的描述应该与实际结果的描述方式相同。通常需要列出期望结果的应该是什么，并且给出期望结果的原因，可能是引用的规格说明书、前一版本的表现行为、客户一般需求、
排除杂乱信息的需要等等。
为了更清楚地理解良好的期望结果应该包含什么信息，请看下面的例子：
Expected result：
The text that appears should be fully highlighted so that if the user wishes to make changes, they don't have to manually highlight and then type (as in Mac OS 10.x and Windows behavior.)
为什么说这个例子很好呢？因为它包含了如下内容：
?应该产生的正确现象：The text that appears should be fully highlighted
?为什么应该产生：…so that if the user wishes to make changes, they don't have to manually highlight and then type.
?给出了具体得参考对象：As in OS 10.x and Windows behavior.
4.5 注释（Notes）
注释应该包括复现步骤中可能引起混乱的补充信息，是对操作步骤的进一步描述，这些补充信息是复现缺陷或隔离缺陷的更详细的内容。
注释部分可以包含以下各方面的内容：
?截取缺陷特征图像文件（Screenshots）；
?测试过程需要使用的测试文件；
?测试附加的打印机驱动程序；
?再次描述重点，避免开发人员将缺陷退回给测试人员补充更多信息；
?再次指明该缺陷是否在前一版本已经存在；
?多个平台之间是否具有不同表现；
?注释包含缺陷的隔离信息，指出缺陷的具体影响范围。
例如，缺陷的注释可能包含下面的内容：
Notes：
1.Text displays outside frame in Win2000 and WinXP, but not Win98.
2.Does not happen after screen has redrawn.
3.Does not occur when two documents are open.
4.Refer to attached screenshots and testing file
5. 缺陷报告的写作注意事项
提高缺陷报告的写作水平是不断积累经验，循序渐进的过程。在正式提交缺陷报告前，请对缺陷报告的内容和格式进行自我检查，避免很多不必要的错误。
5.1 自我检查和提问
?缺陷报告已经向读者包含完整、准确、必要的信息了吗？
?一个缺陷报告中是否之报告了一种缺陷？
?读者是否能容易的搜索该缺陷？
?步骤是否可以完全复现而且表达清楚吗？
?是否包含了复现该缺陷需要的环境变量或测试所用的数据文件？
?缺陷的标题是按照原因与结果的方式书写的吗？
?实际结果和期望结果是否描述不够清楚而容易引起歧义吗？
5.2 避免常见的错误
?使用“I（我）”、“You（你）”等人称代词。可以直接使用动词或必要时使用“User （用户）”代替；
?使用情绪化的语言和强调符号，例如黑体、全部字母大写、斜体、感叹号、问号等。
只要客观地反映出缺陷的现象和完整信息即可，不要对软件的质量优劣做任何主观性强烈的批评、嘲讽；
?使用诸如“Seems（似乎）”、“Appears to be（看上去可能）” 等含义模糊的词汇，而需要报告确定的缺陷结果；
?包含认为比较幽默的内容，因为不同读者的文化和观念不同，很多幽默内容在别人看来，往往难以准确理解，甚至可能引起误解。只需客观地描述缺陷的信息即可；?将不确定的测试问题（Issues）放在缺陷管理数据库中。如果对测试软件的某个现象不确定是否是软件缺陷，可以通过电子邮件或口头交流，确认是缺陷后再报告到数据库中。避免查询和统计结果的不准确性。