|
|
知识路径： > 嵌入式系统的项目开发与维护知识 > 嵌入式系统软件测试 > 软件测试实践 >
|
|
相关知识点：4个
|
|
|
|
|
在软件测试过程中，测试人员不仅需要熟悉一些基本的测试概念和测试方法，而且需要通过对软件设计和算法的理解，运用测试概念和方法进行基于需求的测试用例设计，不仅需要选择恰当的测试方法，而且需要保证测试用例的充分性。
|
|
|
|
|
|
某嵌入式刹车控制软件应用于汽车刹车控制器，该软件需求如下：
|
|
|
|
（1）模式选择：采集模式控制离散量信号In_D1并通过模式识别信号灯显示软件当前工作模式。在信号In_D1为低电平时进入正常工作模式（模式识别信号灯为绿色），为高电平时进入维护模式（模式识别信号灯为红色）。软件在正常工作模式下仅进行刹车控制和记录刹车次数，在维护模式下仅进行中央控制器指令响应。
|
|
|
|
（2）刹车控制：采用定时中断机制，以5ms为周期，采集来自驻车器发出的模拟量信号In_A1以及来自刹车踏板发出的模拟量信号In_A2，并向刹车执行组件发送模拟量信号Out_A1进行刹车控制。
|
|
|
|
（3）记录刹车次数：在Out_A1大于4V时，读出非易失存储器NVRAM中保存的刹车次数记录进行加1操作，然后保存至非易失存储器NVRAM中。
|
|
|
|
（4）响应中央控制器指令：接收来自中央控制器的串行口指令字In_S1，回送串行口响应字Out_S1。当接收的指令字错误时，软件直接丢弃该命令字，不进行任何响应。
|
|
|
|
|
|
|
|
|
|
|
|
1．请简述本软件串行输入接口测试的测试策略及测试内容。针对上表中“读取刹车次数指令”进行鲁棒性测试时应考虑哪些情况？
|
|
|
|
2．某测试人员设计了下表所示的操作步骤对模式选择功能进行测试（表中END表示用例到此结束）。
|
|
|
|
|
|
|
|
为进一步提高刹车控制软件的安全性，在需求中增加了设计约束：软件在单次运行过程中，若进入正常工作模式，则不得再进入维护模式。请参照上表的测试用例完成下表，用于测试该设计约束。
|
|
|
|
|
|
|
|
3．本项目在开发过程中通过测试发现了17个错误，后期独立测试发现了31个软件错误，在实际使用中用户反馈了两个错误。请计算缺陷探测率（DDP）。
|
|
|
|
|
|
1．对所有的测试而言，都必须进行正常测试和异常测试，在本问题中对测试对象实例化为串行输入接口。串行输入接口在本题的需求描述中，根据下表内容，负责接收读取刹车次数和清除刹车次数两种指令，故测试内容为此两种指令。对“读取刹车次数指令”进行鲁棒性测试时应考虑的情况，其实也是接口鲁棒性测试概念的一个实例化，对接口的数据包而言，至少应该包括帧头错误、数据长度错误、数据错误、校验和错误、校验码错误以、帧尾错误以及其他防止指令错误手段的错误等。对本题的实例化而言，具体包括帧头错误、指令码错误、帧长错误、帧尾错误以及整个指令长度超过4字节的情况。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对“读取刹车次数指令”鲁棒性测试时应考虑输入接口帧头错误、指令码错误、帧长错误、帧尾错误以及整个指令长度超过4字节的情况。
|
|
|
|
|
|
|
|
2．如果不考虑约束，软件工作状态从组合的角度来说，上表的测试顺序完全符合要求。但是许多软件在实际使用中，由于真实情况的限制，不能从理论的情况进行组合，对一些条件必须要进行约束。例如本题中，在单次进入正常工作模式后，就不能进入维护模式，因为维护模式是一种检修模式，不能再正常工作中，进行检修，所以必须保证在正常工作模式下，对维护模式命令不响应。所以此题的前提条件应该为“上电前置In_D1为高电平，给测试环境上电，模式识别信号灯为红色”，即在上电后首先让工作模式为维护模式；然后再发送进入正常工作模式命令，灯变绿，进入工作模式；最后在正常工作模式下，发送进入维护模式命令，此时软件应该不响应，灯继续为绿色，表示在工作模式，完成带约束条件的状态转换测试。如果此题继续上表的测试前提条件，不管发送什么命令，灯一直不会变化，就无法判断是软件问题还是测试设备问题，无法完成测试。完善后的下表如下。
|
|
|
|
|
|
|
|
3．缺陷探测率（DDP）定义为测试发现的软件问题与软件中总共发现的问题之比。
|
|
|
|
对于本问题，缺陷探测率（DDP）=（17+31）/（17+31+2）=96%
|
|
|
|
|
|
某嵌入式系统中，存在16路数据采集通道，为了提高数据采集的可靠性，对16路采集通道均采用双余度设计，为了监控采集通道是否发生故障，对各路双余度通道采集值进行比较，只有当该通道两个余度设备采集值均不小于45时，才表示该路通道正常。设计人员设计函数num_of_passer用于统计无故障通道数目，在该函数的设计中考虑了如下因素：
|
|
|
|
|
|
|
|
|
|
|
|
（4）该函数需要两个输入参数，第一个参数是用于存储通道号及余度采集值的数组，第二个参数为通道总数目。
|
|
|
|
开发人员根据上述要求使用ANSI C对代码实现如下（代码中第一个数字代表行号）：
|
|
|
|
|
|
|
|
1．嵌入式软件中通常使用圈复杂度来衡量程序的可维护性（一般要求圈复杂度不大于10），请计算函数num_of_passer的圈复杂度。
|
|
|
|
2．作为测试人员，请参照下表序号1的方式使用代码审查的方法找出该程序中所包含的至少三处错误。
|
|
|
|
|
|
|
|
3．覆盖率是度量测试完整性的一个手段，也是度量测试有效性的一个手段。在嵌入式软件白盒测试过程中，通常以语句覆盖率、分支覆盖率和MC/DC覆盖率作为度量指标，请指出对函数num_of_passer达到100%语句覆盖、100%分支（DC）覆盖和100%MC/DC覆盖所需的最少测试用例数目。
|
|
|
|
|
|
1．控制流程图分析是一个静态的分析过程，它提供静态的度量标准技术，一般主要运用在白盒测试的方法中，控制流图是McCabe复杂度计算的基础，McCabe度量标准是将软件的流程图转化为有向图，然后以图论的知识和计算方法来衡量软件的质量。McCabe复杂度包括圈复杂度（Cyclomatic complexity）、基本复杂度、模块涉及复杂度、设计复杂度和集成复杂度等。
|
|
|
|
嵌入式软件中通常使用圈复杂度来衡量程序的可维护性，一般要求圈复杂度不大于10。函数num_of_passer的处理流程如下图所示。
|
|
|
|
|
|
|
|
在软件测试的概念里，圈复杂度“用来衡量一个模块判定结构的复杂程度，数量上表现为独立线性路径条数，即合理的预防错误所需测试的最少路径条数，圈复杂度大说明程序代码可能质量低且难于测试和维护，根据经验，程序的可能错误和高的圈复杂度有着很大关系”。圈复杂度大说明程序代码的判断逻辑复杂，可能质量低且难于测试和维护。程序的可能错误和高的圈复杂度有着很大关系。
|
|
|
|
|
|
|
|
|
|
②给定流程图G的圈复杂度V（G），定义为V（G）=E-N+2，E是流图中边的数量，N是流图中结点的数量。
|
|
|
|
③给定流程图G的圈复杂度V（G），定义为V（G）=P+1，P是流图G中判定结点的数量。
|
|
|
|
按第1种没有流程图的算法，函数num_of_passer中一个for，两个if，但是一个if是三个复合条件应该加3，另一个if是两个组合条件，应该加2，所以圈复杂度为基数（1）+for（1）+if（3）+if（2）=7，圈复杂度为7。
|
|
|
|
按第2种圈复杂度V（G），定义为V（G）=E-N+2算法，函数num_of_passer流程图中E为16，N为11，所以V（G）=16-11+2=7。
|
|
|
|
按第3种圈复杂度V（G），定义为V（G）=P+1，函数num_of_passer流程图中P为6，所以V（G）=P+1=6+1=7。
|
|
|
|
上述三种算法中的任意方法，函数num_of_passer的圈复杂度都计算为7。
|
|
|
|
2．代码审查是不执行软件代码，而通过阅读软件代码发现代码可能存在的错误的过程。代码审查的测试内容包括检查代码和设计的一致性；检查代码执行标准的情况；检查代码逻辑表达的正确性；检查代码结构的合理性；检查代码的可读性。通过对说明的阅读，按照说明中描述的要求进行函数num_of_passer的代码审查。
|
|
|
|
阅读第1行，函数返回值定义为unsigned int；而在说明的第（2）条描述了当输入参数异常时，函数返回-1；这样发现说明和代码不一致，显然代码定义的unsigned int不能返回-1，此为第1处错误。修改函数返回值的定义为int类型即可。为了让大家理解题意，将本处错误作为回答问题的举例列了出来。
|
|
|
|
阅读第3行，定义了无故障通道数目counter，在定义时未进行初始化，并且在第8行使用前依然未初始化。这就导致counter的初值为非确定值，可能出错，此为第2处错误。在第3行定义counter时初始化为0或者在使用前进行初始化为0均可。
|
|
|
|
阅读第4行，对模块输入参数进行合法性检查，num合法值为1至16；然后查找使用num之处，在第6行对num进行了使用，但第6行使用时却从0开始，而且是小于等于num，这就意味着如果第4行num值为最大值16，在第6行就需要循环判断17次（0到16），而本题的说明中描述很清楚，最多就16路通道，此为第3处错误。但此问题的更改有两种方案，方案1可以更改第4行num>16为num>=16，缩小此参数的合法范围；方案2可以更改第6行n<=num为n
|
|
|
|
阅读第7行，对每个通道采集的双余度值进行有效性判断。按照说明，当余度设备采集值均不小于45时，才表示该路通道正常；但代码中使用当余度设备采集值均大于45时，表示该路通道正常，在对边界点45的处理上与说明不一致，此为第4处错误。将第7行代码中的两个>符号修改为>=即可与说明一致。完善后的下表如下。
|
|
|
|
|
|
|
|
3．覆盖率是度量测试完整性的一个手段，也是度量测试有效性的一个手段。在嵌入式软件白盒测试过程中，通常以语句覆盖率、分支覆盖率和MC/DC覆盖率作为度量指标。
|
|
|
|
|
|
|
|
MC/DC覆盖率指在一个程序中每一种输入／输出至少应出现一次，在程序中的每一个条件必须产生所有可能的输出结果至少一次，并且每个判定中的每个条件必须能够独立影响一个判定的输出，即在其他条件不变的前提下仅改变这个条件的值，而使判定结果改变。
|
|
|
|
对于函数num_of_passer来说，为了使其中所有的语句至少执行一次，程序中的两种返回值必须各覆盖一次，所以为达到100%语句覆盖率，至少需要两个测试用例，即参数异常的测试用例和参数正常测试用例。
|
|
|
|
函数num_of_passer在第4行和第7行有两处条件判断，为了使程序中每个判定取所有可能值至少一次，第4行需要取TRUE和FALSE，第7行需要取TRUE和FALSE。由于第4行取FALSE时，就能覆盖到第7行判定，同时又由于第7行的判定在一个大于一次的循环中，一个测试用例就可以覆盖到第7行的TRUE和FALSE，所以函数num_of_passer 100%的分支覆盖也最少两个测试用例就可以满足，即一个第4行取TRUE的测试用例和一个第4行取FALSE、第7行取TRUE和FALSE的测试用例即可，由于第7行的条件判断在多次循环中，取TRUE和FALSE的测试用例也比较好构造。
|
|
|
|
函数num_of_passer的组合条件也出现在第4行和第7行。对第4行的组合条件需要4个测试用例来满足MC/DC覆盖，分别为①参数array为NULL，②array不为NULL且num为0，③array不为NULL且num为大于16的值，④array不为NULL且num为1到16之间的值。
|
|
|
|
对第7行的组合条件需要3个测试用例来满足MC/DC覆盖，分别为①Value1>45且Value 12>45，②Value1>45且Value2<=45，③Value1<=45且Value2为任意值。由于取第4行array不为NULL且num为1到16之间值的测试用例时，程序将执行到第7行，这时由于第7行在一个多次循环中，第7行需要的3个测试用例都可以在此用例中进行覆盖，所以最少需要4个测试用例就可以使函数num_of_passer满足100%的MC/DC覆盖。
|
|
|
|
|
|
某飞行器供油阀控制软件通过控制左右两边的油箱BL、BR向左右发动机EL、ER供油，既要保证飞行器的正常飞行，又要保证飞行器的平衡，该软件主要完成的功能如下：
|
|
|
|
（1）无故障情况下，控制左油箱BL向左发动机EL供油，右油箱BR向右发动机ER供油，不上报故障；
|
|
|
|
（2）当左油箱BL故障时，控制右油箱BR分别向左、右发动机EL和ER供油，并上报二级故障——左油箱故障；
|
|
|
|
（3）当右油箱BR故障时，控制左油箱BL分别向左、右发动机EL和ER供油，并上报二级故障——右油箱故障；
|
|
|
|
（4）当左发动机EL故障时，根据左右油箱的剩油量决定（如果左右油箱剩油量之差大于等于50L，则使用剩油量多的油箱供油，否则同侧优先供油）左油箱BL还是右油箱BR向右发动机ER供油，并上报一级故障——左发动机故障；
|
|
|
|
（5）当右发动机ER故障时，根据左右油箱的剩油量决定（如果左右油箱剩油量之差大于等于50L，则使用剩油量多的油箱供油，否则同侧优先供油）左油箱BL还是右油箱BR向左发动机EL供油，并上报一级故障——右发动机故障；
|
|
|
|
（6）当一个油箱和一个发动机同时故障时，则无故障的油箱为无故障发动机供油，并上报一级故障——故障油箱和发动机所处位置；
|
|
|
|
（7）当两个油箱或两个发动机同时故障或存在更多故障时，则应进行双发断油控制，并上报特级故障——两侧油箱或两侧发动机故障；
|
|
|
|
（8）故障级别从低到高依次为二级故障、一级故障和特级故障，如果低级故障和高级故障同时发生，则只上报最高级别故障。
|
|
|
|
|
|
1．在嵌入式软件测试中，一般采用的测试方法有白盒测试、黑盒测试和灰盒测试方法，白盒测试方法中，需要基于（1）进行测试；根据本题给定的条件，最恰当的测试方法应选择（2）。
|
|
|
|
2．覆盖率是度量测试完整性的一个手段，也是度量测试有效性的一个手段。在嵌入式软件白盒测试过程中，通常以语句覆盖率、分支覆盖率和MC/DC覆盖率作为度量指标。
|
|
|
|
在实现第6条功能时，设计人员对部分功能采用了下列算法：
|
|
|
|
|
|
请指出对上述算法达到100%语句覆盖、100%分支（DC）覆盖和100%MC/DC覆盖所需的最少测试用例数目。请完成下表中的（1）～（3）填空，并将答案填写在答题纸的对应栏中。
|
|
|
|
|
|
|
|
3．为了测试此软件功能，测试人员设计了下表所示的测试用例，请填写该表中的空（1）～（9），并将答案填写在答题纸的对应栏中。
|
|
|
|
|
|
|
|
|
|
1．在嵌入式软件测试过程中，一般采用的测试方法有白盒测试、黑盒测试和灰盒测试方法。
|
|
|
|
白盒测试也称为结构测试、逻辑测试或基于程序源代码的测试，这种测试应了解程序的内部构造，并且根据内部构造设计测试用例。
|
|
|
|
黑盒测试又称功能测试、数据驱动测试或基于规格说明的测试，这种测试不必了解被测对象的内容情况，而依靠需求规格说明中的功能来设计测试用例。
|
|
|
|
灰盒测试是介于白盒测试与黑盒测试之间的一种测试方法，既关注输出对于输入的正确性，同时也关注代码的内部结构，但这种关注不像白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒测试方法。
|
|
|
|
根据本题的条件，给定的说明为功能说明，故应该采用黑盒测试方法。
|
|
|
|
因此，问题中的空（1）应填入“软件源代码”，空（2）应填入“黑盒”。
|
|
|
|
2．此问题主要考查对语句覆盖、条件覆盖和MC/DC覆盖概念的掌握以及应用。
|
|
|
|
语句覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每一条语句至少被运行一遍，语句覆盖在测试中主要发现错误语句。
|
|
|
|
分支覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每个真值分支和假值分支至少执行一次，分支覆盖也称判定覆盖。
|
|
|
|
修正判定条件覆盖（MC/DC）要求设计适当数量的测试用例，保证在一个程序中每一种输入／输出至少得出现一次，在程序中的每一个条件必须产生所有可能的输出结果至少一次，并且每个判断中的每个条件必须能够独立影响一个判断的输出，即在其他条件不变的前提下仅改变这个条件的值，而使判断结果改变。
|
|
|
|
按照上述语句覆盖要求，语句覆盖就要使得问题2中的所有语句执行一次，问题2中只有一个语句块，故为了使问题2中的一个语句块执行一次，仅仅需要1个测试用例来覆盖。
|
|
|
|
按照上述分支覆盖要求，分支覆盖要使得程序中每个真值分支和假值分支至少执行一次。对问题2中的判断条件进行分析，只有一个判断条件，取真值分支和假值分支即可满足，故最少需要2个测试用例来满足分支覆盖要求。
|
|
|
|
按照上述MC/DC覆盖要求，即每个判断中的每个条件必须能够独立影响一个判断的输出。对问题2中的一个判断进行分析，此判断有两个条件，两个条件共有四种组合，即TT（TRUE和TRUE）、TF（TRUE和FALSE）、FT（FALSE和TRUE）和FF（FALSE和FALSE）。但是由于此判断为逻辑与条件，当前一个条件为FALSE时，其整个判断值为FALSE，后一个条件的真或假均不能独立影响整个判断的输出，所以只需要TT、TF和FX（X表示后一个条件为TRUE或FALSE都可以）三种情况就可以，故此判断最少需要3个测试用例即可满足MC/DC覆盖要求。
|
|
|
|
因此，下表中的空（1）应填入1，空（2）应填入2，空（3）应填入3。
|
|
|
|
|
|
|
|
3．为了测试某飞行器供油阀控制软件的功能，就要依据题目说明中对某飞行器供油阀控制软件的具体功能描述，进行测试用例的设计。此题考察测试用例的设计，不仅包括输入数据的设计，还包括前置条件（例如剩油量）及预期输出的设计（例如给发动机供油的邮箱和上报故障情况），条件较多，需要综合考虑。
|
|
|
|
序号1，前置条件中两个油箱BL、BR剩余油量均为200L，左、右油箱BL、BR与左、右发动机EL、ER均无故障，依据第1条设计说明，输出控制左油箱BL向左发动机EL供油，右油箱BR向右发动机ER供油，不上报故障。
|
|
|
|
序号2，前置条件中两个油箱BL、BR剩余油量均为200L，左油箱BL故障，右油箱BR与左、右发动机EL、ER均无故障，依据第2条设计说明，输出控制右油箱BR分别向左、右发动机EL和ER供油，并上报二级故障——左油箱故障。
|
|
|
|
序号3，前置条件中两个油箱BL、BR剩余油量均为200L，右油箱BR故障，左油箱BL与左、右发动机EL、ER均无故障，依据第3条设计说明，输出控制左油箱BL分别向左、右发动机EL和ER供油，并上报二级故障——右油箱故障。
|
|
|
|
序号4，前置条件中左油箱BL剩余油量为130L，BR剩余油量为120L，左右油箱剩油量之差为10L，左发动机EL故障，左、右油箱BL、BR与右发动机ER均无故障，依据第4条设计说明，输出控制左发动机EL断油，油箱BR向右发动机ER供油，并上报一级故障——左发动机故障。
|
|
|
|
序号5，前置条件中左油箱BL剩余油量为150L，BR剩余油量为90L，左右油箱剩油量之差为60L，左发动机EL故障，左、右油箱BL、BR与右发动机ER均无故障，依据第4条设计说明，如果左右油箱剩油量之差大于等于50L，则使用剩油量多的油箱供油，则应输出控制左发动机EL断油，油箱BL向右发动机ER供油，并上报一级故障——左发动机故障。
|
|
|
|
序号6，前置条件中两个油箱BL、BR剩余油量均为200L，左右油箱剩油量之差等于0L，右油箱BR与右发动机ER均故障，左油箱BL与左发动机EL均无故障，依据第6条设计说明，输出控制故障发动机（右发动机ER）断油，无故障的油箱（左油箱BL）为无故障发动机（左发动机EL）供油，并上报一级故障——右发动机ER故障。
|
|
|
|
序号7，前置条件中两个油箱BL、BR剩余油量均为200L，左右油箱剩油量之差等于0L，右油箱BR与左发动机EL均故障，左油箱BL与右发动机ER均无故障，依据第6条设计说明，输出控制故障发动机（左发动机EL）断油，无故障的油箱（左油箱BL）为无故障发动机（右发动机ER）供油，并上报一级故障——左发动机EL故障。
|
|
|
|
序号8，前置条件中两个油箱BL、BR剩余油量均为200L，左右油箱剩油量之差等于0L，左油箱BL与右发动机ER均故障，右油箱BR与左发动机EL均无故障，依据第6条设计说明，输出控制故障发动机（右发动机ER）断油，无故障的油箱（右油箱BR）为无故障发动机（左发动机EL）供油，并上报一级故障——右发动机ER故障。
|
|
|
|
序号9，前置条件中两个油箱BL、BR剩余油量均为200L，左右油箱剩油量之差等于0L，左、右油箱BL、BR均故障，左、右发动机EL、ER均无故障，依据第7条设计说明，输出控制左、右发动机EL、ER均断油，并上报特级故障——两侧油箱均故障。
|
|
|
|
序号10，前置条件中两个油箱BL、BR剩余油量均为200L，左右油箱剩油量之差等于0L，左、右油箱BL、BR均无故障，左发动机EL故障，右发动机ER未知，但是输出控制左、右发动机EL、ER均断油，并上报特级故障，依据第7条设计说明，只有当两个油箱或两个发动机同时故障或存在更多故障时，才会得到如此的控制，故断定右发动机ER一定故障。
|
|
|
|
序号11，前置条件中两个油箱BL、BR剩余油量均为200L，左右油箱剩油量之差等于0L，左油箱BL故障，左、右发动机EL、ER均故障，只有右油箱BR无故障，依据第7条和第8条设计说明，输出控制左、右发动机EL、ER均断油，并上报特级故障——两侧发动机均故障。左油箱故障的二级故障和两侧发动机均故障的特级故障同时发生，只上报特级故障。
|
|
|
|
|
|
|
|
|
|
（1）BR（2）BL（3）BR（4）BL（5）BL
|
|
|
|
|
