Content deleted Content added
m Reverted edits by 41.89.243.2 (talk) to last version by Walter Görlitz |
Jnestorius (talk | contribs) |
||
(24 intermediate revisions by 14 users not shown) | |||
Line 1:
{{Short description|Testing conducted on a complete software system}}
{{see also|System integration testing}}
{{Multiple issues|
Line 4 ⟶ 5:
{{unbalanced|date=October 2018}}
}}
<!-- the emphasis of the prose in the body is on software -->
'''System testing''', a.k.a. '''end-to-end (E2E) testing''', is testing conducted on a complete [[software system]].
System testing often serves the purpose of evaluating the system's compliance with its specified [[requirements]] {{Citation needed|date=April 2008}} {{endash}} often from a [[Functional requirements|functional requirement specification]] (FRS), a [[Requirements analysis|system requirement specification]] (SRS), another type of specification or multiple.
System testing can detect defects in the system as a whole.{{Citation needed|date=April 2008}} <ref>{{Cite web |title=ISTQB Standard glossary of terms used in Software Testing |url=https://glossary.istqb.org/en/search/}}</ref>
System testing is performed on the entire system in the context of either [[Functional requirements|functional requirement]] specifications (FRS) or [[Requirements analysis|system requirement]] specification (SRS), or both. System testing tests not only the design, but also the behaviour and even the believed expectations of the customer. It is also intended to test up to and beyond the bounds defined in the software or hardware requirements specification(s).{{Citation needed|date=April 2008}}▼
▲System testing
==Approaches==
* [[Destructive testing]]: tests are carried out to the specimen's failure, in order to understand a specimen's performance or material behaviour under different loads.
* [[Nondestructive testing]]: analysis techniques to evaluate the properties of a material, component or system without causing damage.
*[[Fault injection]]: A testing technique which stress the system in an unusual way to examine the system behavior.<ref>{{Cite book|last1=Moradi|first1=Mehrdad|last2=Van Acker|first2=Bert|last3=Vanherpen|first3=Ken|last4=Denil|first4=Joachim|date=2019|editor-last=Chamberlain|editor-first=Roger|editor2-last=Taha|editor2-first=Walid|editor3-last=Törngren|editor3-first=Martin|chapter=Model-Implemented Hybrid Fault Injection for Simulink (Tool Demonstrations)|title=Cyber Physical Systems. Model-Based Design|series=Lecture Notes in Computer Science|volume=11615|language=en|___location=Cham|publisher=Springer International Publishing|pages=71–90|doi=10.1007/978-3-030-23703-5_4|isbn=978-3-030-23703-5|s2cid=195769468 |chapter-url=https://figshare.com/articles/preprint/Model-Implemented_Hybrid_Fault_Injection_for_Simulink_Tool_Demonstrations_/12479930 }}</ref><ref>{{Cite journal|title=Optimizing fault injection in FMI co-simulation through sensitivity partitioning {{!}} Proceedings of the 2019 Summer Simulation Conference|url=https://dl.acm.org/doi/abs/10.5555/3374138.3374170|access-date=2020-06-15|website=dl.acm.org|date=22 July 2019 |pages=1–12 |language=EN}}</ref><ref>Moradi, Mehrdad, Bentley James Oakes, Mustafa Saraoglu, Andrey Morozov, Klaus Janschek, and Joachim Denil. "Exploring Fault Parameter Space Using Reinforcement Learning-based Fault Injection." (2020).</ref>
===Software testing===▼
==See also==
*[[Automated testing]]▼
*[[Automatic test equipment]]
*[[
*[[Quality control]]▼
*[[Test case (software)|Test case]]
*[[Test fixture]]
*[[Test plan]]
▲*[[Automated testing]]
▲*[[Quality control]]
==Notes==
Line 37 ⟶ 36:
==References==
* {{cite book |last=Black |first=Rex |date=2002 |title=Managing the Testing Process |edition=2nd |publisher=Wiley Publishing |isbn=0-471-22398-0 |url-access=registration |url=https://archive.org/details/managingtestingp00rexb }}
{{Software testing}}
[[Category:Software testing]]
|