v100b01软件故障报告（精选3篇）
v100b01软件故障报告 第1篇
笔者最开始修理硬盘时，常常是什么软件都乱用一通，结果经常搞得硬盘连原厂的DM工具甚至BIOS都不认，现在我接到要修的硬盘一定会确认两件事，一是里面的数据重不重要，二是BIOS能不能认。如果数据比硬盘值钱，我会让该用户花钱找专业人员;如果BIOS都不认该硬盘那我就没办法啦。然后再上网，找找有关型号的资料(故障原因、处理办法、原厂工具)。最后才开始动手。
我处理的流程是：
第一，先用原厂的工具，例如DM等先对硬盘进行“清零”、“低格”等处理。
这样做有以下好处：一是毕竟原厂的工具更安全，二是小问题DM都可能解决，三是有些硬盘修复软件会将硬盘搞得连原厂的工具都不认，到时才想起原厂的工具就太迟了。经上面处理过后再用其它软件，硬盘修复时间会大为缩短。因为有些软件、病毒或因不正常开关机而将硬盘的某些地方标上“坏”的标志，当这些坏簇连成一片时，直接用其它软件处理，其耗时可能超出你的想象。我曾遇到过一个硬盘，有10MB左右的坏簇是连在一起的，有上万个坏簇，而HDDREG、MHDD等一个小时才处理几百个，你算一算要花多长时间?用DM搞过后再用其它软件修复，这个区再也见不到坏簇，整个硬盘才几百个，修复起来快多了。
第二，用修复软件。HDDREG、MHDD、FB都很好找，也很好用。
HDDREG安装较烦，我用131版，是要安装在硬盘上。先从一些网站下载，安装时会让你再到 下载一个新的安装程序，安装完后再制作一个软盘，然后就可以用它修复硬盘了。最好多复制几个软盘，因为软盘会经常读写，如果坏簇多、软盘读写次数会大大增加，很容易将软盘搞坏。该软件可以在Windows以及DOS下使用，你还可以决定从第几MB开始处理，不过不能决定在哪里结束。
MHDD、FB直接解压就可以用，但只可以在DOS下使用。你也可以将它俩COPY到软盘，总共才几百KB。在使用方面，FB、HDDREG都很容易使用，启动它们就会将电脑中的硬盘列出，你只要选定所要修的硬盘再回车它就自动完成。FB到结束时会自动将你的硬盘坏道隐藏，将好的进行分区，但最多挑出4块最大的给你用，询问你是否同意，你选“Y”，就相当于Fdisk一次，但重启电脑后还要格式化才可使用，
(注意：当硬盘坏道较多较分散时你的硬盘容量会损失很大，我试过直接用它维修一个2.5GB和一个4.3GB的硬盘，结果一个只有1.8GB可用，一个只有800MB可用。)
MHDD的使用有点烦，但功能最多。启动时它会先将一些参数命令列出，然后就等你输入命令。按F2键是硬盘设定，按F4键是参数设定界面，默认全是OFF，即只扫描不修理，速度较快。你还可以设定从哪里开始从哪里结束。参数一般将REMAP(坏道映射)以及LOOPTHETEST/REPAIR(循环/修复，即修完一次再来一次，直到你叫停!)设为ON就可以了，再按F4键开始工作。中途还可以按键盘的箭头快进或后退。它工作时会有一个类似MS的SCANDISK的示意图给你看，很直观，使你对该硬盘的质量可以心中有数。
在使用这些软件前一定要先将BIOS的病毒功能、软硬盘写保护关闭。FB会损坏数据，MHDD与HDDREG则只会对坏区里的数据有损。它们之间还会“打架”，这个说OK，那个又说有错。上面几个软件很难说哪个最好。软件修复硬盘所费时间都很长，三两个小时是很平常的。如果硬盘不太重要且硬盘坏道较多时，我会在夜晚开机启动软件，然后关显示器，上床睡觉，明天早上醒来就差不多了。如果舍不得硬盘响几个钟头，可以每个把小时就退出(中途退出可以按“Ctrl+Break”组合键，但未完成的就退出，下次开机操作系统会报被修的硬盘有错，进行扫描，你大可不管按X键退出)，并记住位置，关机，让它休息十来分钟再从停的地方继续修复，今天干不完还可以明天接着干(但FB好像没这功能)。如用FB分区觉得不满意可用DISKGENIUS或PQ等合并，但如果坏道多用DG会太烦，PQ也会报硬盘有错。如果容量损失不大，还是等FB自己弄好了。
附：
工作流程：
普通硬盘：DM(清零，低格)FB，如可用容量超过50%就完工，否则再来：DMHDDREGMHDDFB。HDDREG、MHDD在睡前开动，醒来“收货”。
重要硬盘：DMHDDREGMHDDFB。用HDDREG、MHDD时最好每小时退出休息一下。
软件故障模型驱动软件测试 第2篇
1 软件故障与软件测试
蔡开元先生对软件失效机理进行了如下描述:软件错误是一种人为错误, 一个软件错误必定会产生一个或多个软件缺陷;当一个软件缺陷被激活时, 便产生一个软件故障。同一个软件缺陷在不同条件下被激活, 可能产生不同的软件故障;软件故障如果没有及时的容错处理, 便不可避免的导致软件失效, 同一个软件故障在不同条件下可能产生不同的软件失效。这样的复杂关系如图1所示。
图1可以很好地说明软件故障产生与测试的复杂性, 软件功能层面的失效往往是由各种特定的条件和环境决定的, 存在必然的复杂性和多样性。而测试虽然能从软件的不同层次开展测试, 但如果不能从问题的根源处着手, 要测试出全部问题是不可能的, 这也导致了测试再充分也不能保证测试后的软件没有问题。同样地, 我们也能看出, 如果从问题产生的根源出发开展软件的测试, 是可以将后续环境中无穷发散的问题解决的。这无疑是改善测试不确定性和盲目性的一个有效办法。
2 用软件故障模型驱动软件测试
软件故障模型 (SFMEA) 从发生的软件错误入手探究和分析导致软件故障模型, 是寻找软件问题产生的根源的一种有效方法, 是软件测试的基础。这里以成熟的动态内存故障模型为例阐述利用故障模型来驱动软件测试的方法。
2.1 动态内存故障分析
(1) 动态内存是一个自由存储区域, 编程人员根据需要, 利用编程语言提供的动态内存管理命令, 进行动态内存的分配、访问、回收等操作。各类操作后的结果与该内存区域当前所处状态紧密相关, 由此产生了动态内存使用过程中的各类问题, 在分析导致其错误的原因的基础上, 可以建立动态内存故障模型。如图2所示。
Start表示开始状态;Memory Allocate表示对内存进行动态内存分配, 若没有足够的动态内存, 则内存指针为N ULL;Ch ec k Memory检查动态内存分配的结果, 以保证后续动态内存操作的正确性;Access Memory表示对动态内存中的内容进行写、读、修改等操作;Free Memory表示动态内存操作结束, 进行动态内存的释放;End表示结束状态;
(2) 动态内存的四个核心操作缺一不可, 且在不同状态下操作也有约束, 由此导致了诸多与动态内存使用相关的问题, 如图3所示。
图3中的连线表示了引起动态管理错误出现的几种操作, 箭尾表示当前的动态内存管理状态, 箭头表示在当前状态下的操作请求, 将引起动态内存错误产生的操作请求进行分类, 可分为如下几类:1) Memory allocate操作请求引起的错误, 在图中, 6, 5, 7表示了与动态内存分配操作请求有关的错误。2) Check memory操作请求引起的错误, 图中连线10表示了动态内存检测操作有关的错误。导致错误发生的原因是在动态内存释放之后, 又对动态内存进行检测 (试图重新使用已回收的动态内存) 。3) Accessmemory操作请求有关的错误。在图中, 3、9表示了由内存访问引起的错误。导致该错误出现的原因有两个, 3表示在动态内存访问之前未进行指针P的检测, 本文将这种错误定义为空指针引用, 操作9表示在动态内存释放之后, 重新进行动态内存的访问, 从而造成动态内存的未分配使用错误。4) Freememory操作请求引起的错误, 1, 11表示了由动态内存回收操作引起的错误, 1表示没有进行动态内存的分配而进行动态内存的释放, 11表示在对指针变量P进行了动态内存的释放之后, 重新进行释放工作, 这两种情况是等价的, 即在没有可以用的动态内存的情况下, 尝试使用动态内存空间, 产生了动态内存未分配使用错误。5) 与end有关的错误。在图中, 2, 6, 8表示在程序结束阶段出现的错误, 导致错误产生的原因是在进行了动态内存的分配、检测或访问之后, 没有进行动态内存的释放, 因此, 造成了内存泄露的问题。
以上就是动态内存故障模型分析的核心部分, 这样的故障模型能从问题产生的根源出发阐述软件缺陷发生的机制, 为软件测试提供了一个寻求有效测试方法的窗口。
2.2 故障模型驱动软件测试
(1) 在有了软件故障模型之后, 在软件测试时即可针对这类故障的根源开展测试, 做到有的放矢, 达到通过测试将该类软件问题从程序中剔除的目的。动态内存故障模型从动态内存故障产生机理开展分析, 切入软件代码编写的最初级过程, 我们这里以C语言为例阐述利用动态内存故障模型驱动软件测试的过程。C语言中与动态内存管理相关的操作有几类, 可以分别与动态内存管理的四个阶段对应:1) 动态内存分配类操作:如malloc;calloc;realloc等动态内存分配类函数。2) 动态内存检测类操作:内存指针检测if (p!=NULL) , 动态内存初始化memset等操作。3) 动态内存读写访问类操作:各种动态内存空间赋值、引用、函数间的调用等, 都可能形成动态内存的读写操作。4) 动态内存释放类操作:如free等内存释放函数。
(2) 与故障模型进行对应之后 (见图4) , 即可开展软件测试工作, 最简单的方式就是采用人工走查代码的方式进行, 这类方法对程序结构简单、规模不大的程序还是很有效的, 可通过同行评审等方式开展, 能很快排除与动态内存故障模型相关的软件错误, 进而达到根除该类软件错误的目标。
(3) 软件系统高速发展的今天, 小规模、结构简单的程序越来越少, 动态内存管理越来越复杂, 通过简单的人工代码走查方式明显跟不上时代的发展, 随之各类软件测试工具供应商推出了多种软件测试工具来解决这种大规模复杂情况下的软件代码故障检测问题。比如klockwork、C++Test等等, 成为了帮助软件开发、测试人员发现并解决软件问题的有力工具, 其核心也是依据不同软件故障模型对程序代码进行检测, 提供明确的软件故障指示。针对动态内存管理故障模型, 检测软件一般通过数据流分析、制定检测规则、软件故障检测三个过程来检测问题。1) 数据流分析:程序中的数据流分析可以描述出程序的结构流程, 变量间的定值与引用关系, 为故障检测提供有力支撑, 主要方法有到达-定值数据流分析法和活跃变量数据流分析法。2) 制定检测规则:在数据流分析的基础上, 通过抽象命名, 把规则涉及实体进行命名, 再依据软件故障模型制定工具检测遵循的规则, 并将规则转化为方便工具自动处理的“语言”。3) 软件故障检测:在数据流分析和检测规则的基础上, 完成对软件特定故障的检测, 并提供个性化的展示、统计和分析能力。
综上所述, 在软件故障模型成熟之后, 据此开展更有效的软件测试活动是可行的, 也为软件自动化测试工具设计提供了依据。使用软件故障模型驱动软件测试可以按如图5所示流程开展。
首先在故障模型研究的基础上, 对需测试的对象按照故障模型进行实例化, 完成由模型向具体问题的转化;然后对模型实例进行分析, 研究发掘更优更有效的测试方法, 并用测试方法对对象进行测试确认, 不断循环分析和方法优化的过程, 直至找最适合的方法;用寻找到的方法对一类问题进行普适性确认, 因为故障模型本身就是从众多实例中抽象提炼出来的模型, 因此普适性验证重点关注方法的效率和重用度;对于重用度高, 通过工具可以大幅提高效率的方法还可设计自动化测试工具对方法进行固化。
3 结语
现代信息技术的不断发展, 软件应用已经无处不在, 通过软件故障模型来指导软件测试是提高软件可靠性的一个有效办法, 其核心是不断地总结提炼科学有效的软件故障模型, 在应用场景和方式也日趋复杂的今天形成准确的软件故障模型是件不容易的事情, 特别是从覆盖度上要能让软件故障模型覆盖所有的软件故障更是困难, 即便如此, 发掘和提炼软件故障模型仍然是值得的, 可以让测试更有针对性, 更自信, 更有效。提炼软件故障模型需要大量的工程实践作为基础, 通过假设故障存在、反向推理、实践验证的方式进行。当前软件故障模型偏重于由软件代码层次, 对软件应用环境、模式、行业特点等方面指导系统级测试的软件故障模型还很欠缺。完善软件故障模型并应用到测试行为当中还是一个很长期的过程。
参考文献
软件故障注入方法探究 第3篇
关键词：故障注入；缺点；常用方法
中图分类号：TN958文献标识码：A文章编号：1007-9599 (2011) 16-0000-01
Software Fault Injection Method Research
Feng Xuan
(School of Computer Science&Software Engineering,Tianjin Polytechnic University,Tianjin300387,China)
Abstract:This paper studied the existing software fault injection tool,summarized the various methods and shortcomings of fault injection and introduced the commonly used methods on this basis.It has a guiding role on the software fault injection technology research for other people.
Keywords:Fault injection;Shortcomings;Common method
一、软件故障注入方法
软件故障注入方法是通过特定的程序对系统软件、硬件错误状态进行仿真。这种方法容易扩展新的故障类型。故障注入原理是通过修改程序执行语句，增加、修改、删除数据或直接修改寄存器或存储器的内容来模拟硬件或软件故障的发生。下面介绍了常用的故障注入方法，并举了具有代表性的工具。
（一）基于调试器原理的故障注入。基于调试器的故障注入（如FERRARI）使用和调试器相同的接口进行故障注入。这些故障注入器在目标程序中设置断点，单步调试或跟踪系统调用。当目标程序运行到断点处时，目标程序被挂起，控制权转交给故障注入器，从而可以进行故障注入。在Unix平台下，故障注入器使用ptrace接口。ptrace接口的功能在大多数Unix系统上都很相似，只是参数类型和常数的名称有少许差别。
（二）基于驱动器原理的故障注入。在很多情况下，用户级的故障注入器不能注入故障，可能是因为权限不足而不能访问某些数据，或者因为在需要注入的时刻，操作系统不分配给故障注入器时间片。比如，当系统运行在临界区时，一个软件故障注入器便无法进行注入。一个可以克服大部分权限障碍的解决方法就是，使用设备驱动器来注入故障，因为设备驱动器比用户级代码有更高的权限。一个基于驱动器的故障注入器可以将故障注入到系统内存空间的任何位置。这样的设备驱动器提供两类函数，一类是在特定地址注入故障的函数，另一类是获取目标应用程序内存信息的函数。设备驱动器使用ioct1调用来允许用户进程调用这些函数。这样的驱动器在Linux、LynxOS，Windows 2000下都存在。
（三）基于驱动器的性能故障注入。这种方式通过性能故障，而不是破坏内存映像来影响系统性能。使CPU瘫痪或使系统资源申请失败（如内存或打开文件句柄）都属于性能故障。性能故障能够模拟现实中经常发生的事件的影响，如文件错误、多bug的用户进程、系统资源泄漏等。企业版计算机系统中，通常配有EDAC（错误检测与纠正）保护机制的内存和冗余CPUs，对于这些计算机系统注入性能故障，会比传统的内存位翻转故障更加有效，而且会导致更高的系统是效率。
（四）基于网络通信的故障注入。前面两种故障注入方法，针对的都是独立运行的计算机。对于实际的分布式系统来说，故障不仅在单个节点上出现，在各节点间进行通信过程中，一些硬件因素（如通信鏈路），软件因素（如通信协议，应用程序本身），或者网络因素（网络拥挤、拥塞等）都会引起数据的丢失或破坏。因此，基于网络通信的故障注入也具有很重要的意义。这种方法可以采用包装与设备I/O操作相关的几个系统调用来实现，如Linux系统下的函数open、read、write和close。
二、软件故障注入的缺点
（一）无法将故障注入到软件无法到达的地方。
（二）软件设备化会干扰目标系统上运行的工作负载，甚至会改变原始的软件结构。仔细的设计注入环境能将对工作量的影响最小化。
（三）糟糕的时间分辨率会带来准确性问题。对于潜伏期较长的故障，例如存储器故障，较低的时间分辨率不是问题。但对于潜伏期较短的故障，例如总线和CPU故障，就有可能捕捉不到某些错误行为，比如说传播类错误。混合近似法，将软件注入的灵活性和硬件监视的准确性结合起来。这种方法很适合于检测非常短的潜伏期的故障。然而，使用硬件监视器会增加成本，而且由于对观察点数量和数据存贮区大小的限制，降低了灵活性。
三、软件故障注入工具常用的方法介绍
ORCHSTR用于测试分布式协议的正确性，采用称为脚本驱动（script-driven）的故障注入方法，在协议层之间加入故障注入层，用来测试故障注入层之上的协议层实现的正确性。FERRARY注入故障和错误的方法是采用软件陷阱（trap），在适当的时刻或者程序位置捕获被注入的程序，然后注入选择的故障或错误。这种方法利用了UNIX系统中ptrace（）函数的跟踪子进程功能。
DEFINE依靠修改系统的陷阱处理程序和硬时钟中断程序来实现故障注入。故障注入程序使用硬时钟中断来控制注入的时刻，并且激活软件陷阱来注入故障。该工具还提供软件监视器来跟踪指令执行流程和内核中的关键变量。
DOCTOR则结合了多种方法来触发故障注入，包括用定时中断和陷阱来触发故障，以及通过修改代码来注入故障，因而具有广泛的适应性，能够注入低级的CPU和内存故障以及更高级别的网络通信错误。
Xception也针对目前先进的微处理器进行故障注入。这些微处理器包含调试和性能监视功能，可直接对目标处理器的调试硬件编程。复杂的调试异常处理机制允许定义多种故障触发方式，利用处理器内部的性能监视硬件可以记录故障注入之后目标处理器行为的详细信息。上述两种方法都对系统的负载干扰较少，克服了多数软件故障注入工具干扰负载运行的缺陷。
作者简介：
