嵌入式软件基于故障模型的缺陷分类
作者:网络转载 发布时间:[ 2012/12/25 9:36:53 ] 推荐标签:
2、计算型
包括变量的定义与使用方面的错误、数据的冗余、全局变量与局部变量(静态变量与动态变量)的混淆、数组变量的越界错误、用错指针变量、数据类型不匹配的错误、还有数据操作方面错误,包括函数调用参数传递错误、赋值语句错误等,该模型应该尽可能包括关于计算方面的各种错误。
3、分支型
主要是对分支结构进行建模,因为分支结构会在整个程序中占有很大比例,所以这种模型的建立是非常重要的。该模型中应该包括谓词的错误、包括判定变量被赋予了错误的值、谓词操作符不正确或少操作符、谓词中的变量不正确或少变量、谓词的结构不正确(if else 不匹配,分号位置不对)、少默认情况或默认情况不对,少动作或动作不对、出现额外动作等故障。
4、循环型
这也是一种程序控制流的模型,是对程序中同样占很大比例的循环结构建立的模型。主要包括永不循环故障或死循环故障,这主要是由循环变量引起的。因此这种模型中包括的物理故障有:循环谓词中循环变量被赋予了错误的值、循环谓词中操作符不正确或缺少操作不符、谓词中的变量本省不正确或少变量。
5、功能型
是指一些软件功能或性能不完善的故障。具体包括功能或性能规定的有错误、遗漏了某些功能、规定的某些冗余的功能、为用户提供的信息有错误、对意外情况的处理有错误、设计界面用户不满意、功能的结果不完善、提供的用户接口不完善等等。在很多应用商业软件中,这种故障模型所覆盖的故障占有相当大的比例。
6、死锁型
对于一些实时控制程序,如果需同时处理的任务较多的时候,往往需要多线程进行并行处理,当遇到多个线程相互等待的时候进入了死锁。产生死锁的根本原因在于系统提供的资源少并发线程所要求的该类资源数。为了测试死锁是否发生,当线程进行资源请求时检查并发进程组是否构成资源的请求和保持环路。有限状态转移图和petriNet等技术都可用来有效的判断死锁发生。
四、结束语
软件缺陷作为软件开发过程的产物隐含了许多的信息,通过对这些缺陷的深入分析,不仅可以发现引发软件缺陷的根本原因,还能对软件进行更有效的测试。本文针对嵌入式软件的特点,提出按故障模型分类的嵌入式软件缺陷分类方法,在嵌入式软件测试中能有效的发现一些极易疏忽的软件故障。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11