Content deleted Content added
Mishi.javed (talk | contribs) m →Software quality assurance: Added a missing citation |
Jnestorius (talk | contribs) |
||
Line 85:
=== Static, dynamic, and passive testing ===
There are many approaches to software testing. [[Code review|Reviews]], [[software walkthrough|walkthrough]]s, or [[Software inspection|inspections]] are referred to as static testing, whereas executing programmed code with a given set of [[Test case (software)|test case]]s is referred to as [[dynamic testing]].<ref name="GrahamFoundations08">{{Cite book |last1=Graham, D. |url=https://books.google.com/books?id=Ss62LSqCa1MC&pg=PA57 |title=Foundations of Software Testing |last2=Van Veenendaal, E. |last3=Evans, I. |publisher=Cengage Learning |year=2008 |isbn=978-1-84480-989-9 |pages=57–58}}</ref><ref name="OberkampfVerif10">{{Cite book |last1=Oberkampf, W.L. |url=https://books.google.com/books?id=7d26zLEJ1FUC&pg=PA155 |title=Verification and Validation in Scientific Computing |last2=Roy, C.J. |publisher=Cambridge University Press |year=2010 |isbn=978-1-139-49176-1 |pages=154–5}}</ref>
Static testing is often implicit, like proofreading, plus when programming tools/text editors check source code structure or compilers (pre-compilers) check syntax and data flow as [[static program analysis]]. Dynamic testing takes place when the program itself is run. Dynamic testing may begin before the program is 100% complete in order to test particular sections of code and are applied to discrete [[Function (computer science)|functions]] or modules.<ref name="GrahamFoundations08" /><ref name="OberkampfVerif10" /> Typical techniques for these are either using [[Method stub|stubs]]/drivers or execution from a [[debugger]] environment.<ref name="OberkampfVerif10" />
Line 134:
Black-box testing (also known as functional testing) describes designing test cases without knowledge of the implementation, without reading the source code. The testers are only aware of what the software is supposed to do, not how it does it.<ref name="Patton">{{Cite book |last=Patton |first=Ron |url=https://archive.org/details/softwaretesting0000patt |title=Software Testing |publisher=Sams Publishing |year=2005 |isbn=978-0-672-32798-8 |edition=2nd |___location=Indianapolis}}</ref> Black-box testing methods include: [[equivalence partitioning]], [[boundary value analysis]], [[all-pairs testing]], [[state transition table]]s, [[decision table]] testing, [[fuzz testing]], [[model-based testing]], [[use case]] testing, [[exploratory testing]], and specification-based testing.<ref name="LimayeSoftware09" /><ref name="SalehSoftware09" /><ref name="BlackPragmatic11" />
Specification-based testing aims to test the functionality of software according to the applicable requirements.<ref>{{Cite thesis |last=Laycock |first=Gilbert T. |title=The Theory and Practice of Specification Based Software Testing |degree=dissertation |publisher=Department of Computer Science, [[University of Sheffield]] |url=https://www.cs.le.ac.uk/people/glaycock/thesis.pdf |year=1993 |access-date=January 2, 2018}}</ref> This level of testing usually requires thorough [[Test case (software)|test case]]s to be provided to the tester, who then can simply verify that for a given input, the output value (or behavior), either "is" or "is not" the same as the expected value specified in the test case. Test cases are built around specifications and requirements, i.e., what the application is supposed to do. It uses external descriptions of the software, including specifications, requirements, and designs, to derive test cases. These tests can be [[functional testing|functional]] or [[non-functional testing|non-functional]], though usually functional. Specification-based testing may be necessary to assure correct functionality, but it is insufficient to guard against complex or high-risk situations.<ref>{{Cite journal |last=Bach |first=James |author-link=James Bach |date=June 1999 |title=Risk and Requirements-Based Testing |url=https://www.satisfice.com/articles/requirements_based_testing.pdf |journal=Computer |volume=32 |issue=6 |pages=113–114 |access-date=August 19, 2008}}</ref>
Black box testing can be used to any level of testing although usually not at the unit level.<ref name="AmmannIntro16" />
Line 373:
* [[Requirements analysis]]: testing should begin in the requirements phase of the [[software development life cycle]]. During the design phase, testers work to determine what aspects of a design are testable and with what parameters those tests work.
* Test planning: [[test strategy]], [[test plan]], [[testbed]] creation. Since many activities will be carried out during testing, a plan is needed.
* Test development: test procedures, [[Scenario test|test scenarios]], [[Test case (software)|test case]]s, test datasets, test scripts to use in testing software.
* Test execution: testers execute the software based on the plans and test documents then report any errors found to the development team. This part could be complex when running tests with a lack of programming knowledge.
* Test reporting: once testing is completed, testers generate metrics and make final reports on their [[test effort]] and whether or not the software tested is ready for release.
Line 438:
====Test case====
{{Main|Test case (software)}}
A [[Test case (software)|test case]] normally consists of a unique identifier, requirement references from a design specification, preconditions, events, a series of steps (also known as actions) to follow, input, output, expected result, and the actual result. Clinically defined, a test case is an input and an expected result.<ref>{{Cite book |last=IEEE |title=IEEE standard for software test documentation |title-link=IEEE 829 |publisher=IEEE |year=1998 |isbn=978-0-7381-1443-9 |___location=New York}}</ref> This can be as terse as "for condition x your derived result is y", although normally test cases describe in more detail the input scenario and what results might be expected. It can occasionally be a series of steps (but often steps are contained in a separate test procedure that can be exercised against multiple test cases, as a matter of economy) but with one expected result or expected outcome. The optional fields are a test case ID, test step, or order of execution number, related requirement(s), depth, test category, author, and check boxes for whether the test is automatable and has been automated. Larger test cases may also contain prerequisite states or steps, and descriptions. A test case should also contain a place for the actual result. These steps can be stored in a word processor document, spreadsheet, database, or other common repositories. In a database system, you may also be able to see past test results, who generated the results, and what system configuration was used to generate those results. These past results would usually be stored in a separate table.
====Test script====
| |||