System testing: Difference between revisions

Revision as of 11:24, 15 March 2019

Latest revision as of 11:35, 16 August 2025

(35 intermediate revisions by 21 users not shown)

Line 1:

{{Short description|Testing conducted on a complete software system}}

{{refimprove|date=January 2013}}

{{unbalanced|date=October 2018}}<!-- the emphasis of the prose in the body is on software -->

{{see also|System integration testing}}

{{Multiple issues|

{{refimproveMore citations needed|date=January 2013}}

{{unbalanced|date=October 2018}}

}}

{{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''' isdescribes testing conductedat onthe asystem completelevel integratedto systemcontrast to evaluatetesting at the [[system's complianceintegration withtesting|system its specifiedintegration]], [[requirementsintegration testing|integration]].{{Citation neededor [[unit testing|date=Aprilunit]] 2008}}level.

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 takes, as its input, all of the integrated components that have passed [[integration testing]]. The purpose of integration testing is to detect any inconsistencies between the units that are integrated together (called ''assemblages''). System testing seeks to detect defects both within the "inter-assemblages" and also within the system as a whole.{{Citation needed|date=April 2008}} The actual result is the behavior produced or observed when a component or system is tested.<ref>{{Cite web|url=http://glossar.german-testing-board.info/|title=ISTQB Standard glossary of terms used in Software Testing|last=|first=|date=|website=|archive-url=|archive-date=|dead-url=|access-date=}}</ref>

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 can verify the design, the behavior and even the believed expectations of the customer. It is also intended to test up to and beyond the bounds of specified software and hardware requirements.{{Citation needed|date=April 2008}}

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}} Confidence testing is a term used to define the repeat (duplicate) of any other test more than the absolute minimum to achieve it's given success criteria. The number of repeat or duplicate tests is an arbitrary number based on the user's experience and trust in the system. {{Citation needed|date=April 2008}}

==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>

==Subject-specific test methods==

===Software testing===

[[Software testing]] is an investigation conducted to provide stakeholders with information about the quality of the software product or service under test.<ref name="Kaner 1">{{cite conference | url = http://www.kaner.com/pdfs/ETatQAI.pdf | title = Exploratory Testing |authorlink=Cem Kaner | last = Kaner | first = Cem |conference=''Quality Assurance Institute Worldwide Annual Software Testing Conference'' | ___location = Orlando, FL | date = November 17, 2006 | access-date = November 22, 2014}}</ref> Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Software testing involves the execution of a software component or system component to evaluate one or more properties of interest. In general, these properties indicate the extent to which the component or system under test meets the requirements that guided its design and development, responds correctly to all kinds of inputs, performs its functions within an acceptable time, is sufficiently usable, can be installed and run in its intended environments, and achieves the general result its stakeholders desire. As the number of possible tests for even simple software components is practically infinite, all software testing uses some strategy to select tests that are feasible for the available time and resources.

===Mobile-device testing===

[[Mobile-device testing]] assures the quality of mobile devices, like mobile phones, PDAs, etc. The testing will be conducted on both hardware and software. And from the view of different procedures, the testing comprises R&D testing, factory testing and certificate testing. Mobile-device testing involves a set of activities from monitoring and trouble shooting mobile application, content and services on real handsets. Testing includes verification and validation of hardware devices and software applications.

==See also==

*[[Automated testing]]

*[[Automatic test equipment]]

*[[TestMobile-device casetesting]]

*[[Quality control]]

===*[[Software testing===]]

*[[Test case (software)|Test case]]

*[[Test fixture]]

*[[Test plan]]

*[[Automated testing]]

*[[Quality control]]

==Notes==

Line 31 ⟶ 35:

==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]]