|
|
知识路径： > 嵌入式系统的项目开发与维护知识 > 嵌入式系统软件测试 > 软件测试实践 > 测试实例 >
|
|
相关知识点：3个
|
|
|
|
|
某嵌入式刹车控制软件应用于汽车刹车控制器，该软件需求如下：
|
|
|
|
（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%
|
|
|
