Fault injection was initially developed in the context of hardware faults. Traditional fault injection techniques can emulate transient and permanent hardware faults using simple bit-flip or stuck-at models. The need for SFI arose with the emergence of software faults as a major cause of system failures, leading to the development of several SFI approaches. The realistic emulation of residual software faults by fault injection is difficult and it still represents an open issue. The injection of software faults in software components to assess the impact of these faults on other components or on the system as a whole, allowing the evaluation of fault tolerance, is relatively new compared to decades of research on hardware fault injection. This paper presents an extensive experimental study to evaluate the representativeness of faults injected by a state-of-the-art approach a result, complex software will eventually execute under faulty conditions that have not been foreseen during testing . To face this problem, it is well known, even recommended by some safety standards that software developers adopt software fault tolerance mechanisms. A wrong state of the system in order to provide a fail-stop behavior or a degraded mode of service the effectiveness of fault tolerance mechanisms, it becomes important to evaluate the system behavior under unforeseen faulty conditions. This can be done by deliberately injecting a fault condition into the system. the works that use the insertion of software faults in programs such as mutation testing, and those that specifically address SFI, including an overview of existing approaches and tools and typical scenarios where it has been used. Many fault injection approaches have been proposed in the last four decades. As it is generally well accepted that simple hardware fault models such as bit-flip or bit stuck-at do represent real hardware faults, the first fault injection approaches consisted of injecting physical faults into the target system hardware the fault.