|
|
知识路径： > 嵌入式系统的项目开发与维护知识 > 嵌入式系统软件测试 > 嵌入式软件测试技术 >
|
被考次数：19次
被考频率：高频率
总体答错率：48%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：16个
|
|
|
|
|
根据是否执行软件，将软件测试方法分为静态测试和动态测试。动态测试是建立在程序的执行过程中，根据是否要求了解被测对象的内部，分为黑盒测试和白盒测试。
|
|
|
|
|
|
|
|
静态测试方法包括检查单和静态分析方法，对软件文档的静态测试方法主要是以检查单的形式进行文档审查，而对软件代码的静态测试方法一般采用代码审查、代码走查和静态分析的形式进行。
|
|
|
|
静态分析是一种对代码的机械性和程序化的特性分析方法。一般包括控制流分析、数据流分析、接口分析和表达式分析。
|
|
|
|
代码审查是检查代码和设计的一致性、代码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性以及代码的可读性。代码审查应根据所使用的语言和编码规范确定审查所用的检查单，检查单的设计或采用应经过评审。
|
|
|
|
代码走查是由测试人员组成小组，准备一批有代表性的测试用例，集体扮演计算机的角色，按照程序的逻辑，逐步运行测试用例，查找被测软件缺陷。代码走查应由测试人员集体阅读讨论程序，是用“人脑”执行测试用例并检查程序。
|
|
|
|
对于规模较小、安全性要求很高的代码也可进行形式化证明。静态分析常需要使用软件工具进行。
|
|
|
|
静态测试的特点有：不必设计在计算机上执行的测试用例；可充分发挥人的逻辑思维优势；不需特别条件，容易开展；发现错误的同时也就定位了错误，不需作额外的错误定位工作。
|
|
|
|
|
|
动态测试是建立在程序的执行过程中，根据是否对被测对象内部的了解，分为黑盒测试和白盒测试。
|
|
|
|
黑盒测试是一种按照软件功能说明设计测试数据的技术，不考虑程序内部结构和编码结构，也不需考虑程序的语句及路径，只需了解输入／输出之间的关系，依靠这一关系和软件功能说明确定测试数据，判定测试结果的正确性。黑盒测试又称功能测试、数据驱动测试或基于需求的测试。
|
|
|
|
白盒测试是一种按照程序内部逻辑结构和编码结构设计测试数据的技术，可以看到程序内部结构，并根据内部结构设计测试数据，使程序中的每个语句、每个条件分支、每个控制路径的覆盖情况都在测试中受到检验。白盒测试又称结构测试、逻辑测试或基于程序的测试。
|
|
|
|
动态测试的特点有：实际运行被测程序；必须设计测试用例来运行；测试结果分析工作量大，测试工作费时、费力；投入人员多、设备多，处理数据多，要求有较好的管理和工作规程。
|
|
|
|
在软件动态测试过程中，应采用适当的测试方法，实现测试要求。配置项测试和系统测试一般采用黑盒测试方法；部件测试一般主要采用黑盒测试方法，辅助以白盒测试方法；单元测试一般采用白盒测试方法，辅助以黑盒测试方法。
|
|
|
|
|
|
黑盒测试方法一般采用功能分解、等价类划分、边界值分析、判定表、因果图、随机测试、猜错法和正交试验法等。
|
|
|
|
|
|
功能分解是将需求规格说明中每一个功能加以分解，确保各个功能被全面地测试。功能分解是一种较常用的方法。
|
|
|
|
|
|
（1）使用程序设计中的功能抽象方法把程序分解为功能单元。
|
|
|
|
（2）使用数据抽象方法产生测试每个功能单元的数据。
|
|
|
|
功能抽象中程序被看成一种抽象的功能层次，每个层次可标识被测试的功能，层次结构中的某一功能有由其下一层功能定义。按照功能层次进行分解，可以得到众多的最低层次的子功能，以这些子功能为对象，进行测试用例设计。
|
|
|
|
数据抽象中，数据结构可以由抽象数据类型的层次图来描述，每个抽象数据类型有其取值集。程序的每一个输入和输出量的取值集合用数据抽象来描述。
|
|
|
|
|
|
等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试用例。
|
|
|
|
|
|
（1）划分有效等价类：对规格说明是有意义、合理的输入数据所构成的集合。
|
|
|
|
（2）划分无效等价类：对规格说明是无意义、不合理的输入数据所构成的集合。
|
|
|
|
|
|
（4）为每一个等价类设计一组测试用例，确保覆盖相应的等价类。
|
|
|
|
|
|
边界值分析是针对边界值进行测试的。使用等于、小于或大于边界值的数据对程序进行测试的方法就是边界值分析方法。
|
|
|
|
|
|
（1）通过分析需求规格说明，找出所有可能的边界条件。
|
|
|
|
（2）对每一个边界条件，给出满足和不满足边界值的输入数据。
|
|
|
|
|
|
对满足边界值的输入可以发现计算错误，对不满足的输入可以发现域错误。该方法会为其他测试方法补充一些测试用例，绝大多数测试都会用到本方法。
|
|
|
|
|
|
判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件组合的取值及其相应要执行的操作构成规则，条目中的每一列是一条规则。
|
|
|
|
条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试用例。
|
|
|
|
建立并优化判定表，把判定表中每一列表示的情况写成测试用例。
|
|
|
|
|
|
（1）需求规格说明以判定表形式给出，或是很容易转换成判定表。
|
|
|
|
|
|
|
|
（4）每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
|
|
|
|
（5）如果某一规则的条件的满足，将执行多个操作，这些操作的执行与顺序无关。
|
|
|
|
|
|
因果图方法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试用例。
|
|
|
|
|
|
（1）分析需求规格说明，引出原因（输入条件）和结果（输出结果），并给每个原因和结果赋予一个标识符。
|
|
|
|
（2）分析需求规格说明中语义的内容，并将其表示成连接各个原因和各个结果的“因果图”。
|
|
|
|
|
|
（4）通过跟踪因果图中的状态条件，把因果图转换成有限项的判定表。
|
|
|
|
|
|
如果需求规格说明中含有输入条件的组合，宜采用本方法。有些软件的因果图可能非常庞大，根据因果图得到的测试用例数目非常多，此时不宜使用本方法。
|
|
|
|
|
|
随机测试指测试输入数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难，多用于可靠性测试和系统强度测试。
|
|
|
|
|
|
猜错法是有经验的测试人员，通过列出可能有的错误和易错情况表，写出测试用例的方法。
|
|
|
|
|
|
正交实验法是从大量的实验点挑出适量的、有代表性的点，应用正交表，合理地安排实验的一种实验设计方法。
|
|
|
|
利用正交实验法来设计测试用例时，首先要根据被测软件的需求规格说明找出影响功能实现的操作对象和外部因素，把它们当作因子，而把各个因子的取值当作状态，生成二无的因素分析表。然后，利用正交表进行各因子的状态的组合，构造有效的测试输入数据集，并由此建立因果图。这样得出的测试用例的数目将大大减少。
|
|
|
|
|
|
白盒测试方法一般包括控制流测试（语句覆盖测试、分支覆盖测试、条件覆盖测试、修订的条件／判定覆盖MC/DC、条件组合覆盖测试、路径覆盖测试）、数据流测试、程序变异、程序插桩、域测试和符号求值等。
|
|
|
|
|
|
控制流测试依据控制流程图产生测试用例，通过对不同控制结构成分的测试验证程序的控制结构。所谓验证某种控制结构即指使这种控制结构在程序运行中得到执行，也称这一过程为覆盖。以下介绍几种覆盖：
|
|
|
|
（1）语句覆盖。语句覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每一条语句至少被遍历，语句覆盖在测试中主要发现错误语句。
|
|
|
|
（2）分支覆盖。分支覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每个真值分支和假值分支至少执行一次，分支覆盖也称判定覆盖。
|
|
|
|
（3）条件覆盖。条件覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中的每个条件的可能取值至少满足一次。
|
|
|
|
（4）修订的条件／判定覆盖（MC/DC——Modified Condition/Decision Coverage）。修订的条件／判定覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判定中的每个条件都曾独立的影响判定的结果至少一次（独立影响意思是在其他的条件不变的情况下，只改变一个条件，就可影响整个判定的值）。
|
|
|
|
对安全性要求比较高的软件，一般采用此覆盖要求。此覆盖要求在测试用例的效率和数量之间较为平衡。
|
|
|
|
（5）条件组合覆盖。条件组合覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中条件的各种组合至少出现一次，这种方法包含了“分支覆盖”和“条件覆盖”的各种要求。
|
|
|
|
（6）路径覆盖。路径覆盖要求设计适当数量的测试用例，运行被测程序，使得程序沿所有可能的路径执行，较大程序的路径可能很多，所以在设计测试用例时，要简化循环次数。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
控制流图是描述程序控制流的一种图示方式，它由结点和定向边构成。控制流图的结点代表一个基本块，定向边代表控制流的方向。其中要特别注意的是，如果判断中的条件表达式是复合条件，即条件表达式是由一个或多个逻辑运算符连接的逻辑表达式，则需要改变复合条件的判断为一系列单个条件的嵌套的判断。控制流图的基本结构如下图所示。
|
|
|
|
|
|
|
|
|
|
数据流测试是用控制流程图对变量的定义和引用进行分析，查找出未定义的变量或定义了而未使用的变量，这些变量可能是拼错的变量、变量混淆或丢失了语句。数据流测试一般使用工具进行。
|
|
|
|
数据流测试通过一定的覆盖准则，检查程序中每个数据对象的每次定义、使用和消除的情况。
|
|
|
|
|
|
|
|
（2）在每个链路上标注对有关变量的数据操作的操作符号或符号序列。
|
|
|
|
|
|
|
|
|
|
动态数据流异常检查在程序运行时执行，获得的是对数据对象的真实操作序列，克服了静态分析检查的局限，但动态方式检查是沿与测试输入有关的一部分路径进行的，检查的全面性和程序结构覆盖有关。
|
|
|
|
|
|
程序变异是一种错误驱动测试，是为了查出被测软件在做过其他测试后还剩余一些的小错误。本方法应用于测试工具。
|
|
|
|
|
|
程序插装是向被测程序中插入操作以实现测试目的方法。程序插装不应该影响被测程序的运行过程和功能。
|
|
|
|
有很多的工具有程序插装功能。由于数据记录量大，手工进行将是一件很烦琐的事。
|
|
|
|
|
|
域测试是要判别程序对输入空间的划分是否正确。该方法限制太多，使用不方便，供有特殊要求的测试使用。
|
|
|
|
|
|
符号求值是允许数值变量取“符号值”以及数值。符号求值可以检查公式的执行结果是否达到程序预期的目的；也可以通过程序的符号执行，产生出程序的路径，用于产生测试数据。符号求值最好使用工具，在公式分支较少时手工推导也是可行的。
|
|
|
