|
'''Data-driven testing''' ('''DDT'''), also known as '''table-driven testing''' or '''parameterized testing''', is a [[software testing]] technique that isuses useda in the testingtable of [[computerdata]] [[software]]that todirects describetest testingexecution doneby usingencoding ainput, tableexpected of conditions directly as test inputsoutput and verifiable outputs as well as the process where test -environment settings and control are not hard-coded.<ref>{{cite web |title=golang/go TableDrivenTests |url=https://github.com/golang/go/wiki/TableDrivenTests |website=GitHub |language=en}}</ref><ref>{{cite web |title=JUnit 5 User Guide |url=https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests |website=junit.org}}</ref> One advantage of DDT over other testing techniques is relative ease to cover an additional [[test case (software)|test case]] for the [[system under test]] by adding a line to a table instead of having to modify test [[source code]].
Often, a table provides a complete set of stimulus input and expected outputs in each row of the table. StinulusStimulus input values typically cover values that correspond to boundary or partition input spaces . In advanced testing systems, data can be harvested from a running system using a purpose-built tool (sniffer). The DDT framework can playback harvested data; producing a regression testing tool. ▼Many techniques are available for testing [[software]]. They co-exist because they differ in the effort required to create and subsequently maintain. The advantage of data-driven testing is the ease to add additional inputs to the table when new partitions are discovered or added to the product or [[system under test]]. Also, in the data-driven testing process, the test environment settings and control are not hard-coded. The cost aspect makes DDT cheap for automation but expensive for manual testing.
DDT involves a [[software framework |framework]] that executes tests based on input data. The framework is a [[software reuse |re-usable]] test asset that can reduce maintenance of a test [[codebase]]. DDT allows for anything that has a potential to change to be segregated from the framework; stored in an external asset. The framework might manage storage of tables and test results in a [[database]] such as [[data pool]], [[Data access object |DAO]] and [[ActiveX Data Objects |ADO]]. An advanced framework might harvest data from a running system using a purpose-built tool (sniffer). The DDT framework can playback harvested data for [[regression testing]].
==Overview==
Data-driven testing involves a framework that executes tests based on an input table. The framework provides re-usable test logic to reduce maintenance. Input and result data can be stored in centralized storage or [[database]]s.
Automated test suites contain user 's interactions through the system's GUI, for repeatable testing. Each test begins with a copy of the "before" image reference database. The "user interactions" are replayed through the "new" GUI version and result in the "post test" database. The ''reference'' "post test" database is compared to the "post test" database, using a tool.<ref>{{cite web |url=http://www.diffkit.org/ |title=Home |website=diffkit.org}}</ref> Differences reveal probable regression. Navigation the [[System Under Test]] user interface, reading data sources, and logging test findings may be coded in the table. ▼▲Often, a table provides a complete set of stimulus input and expected outputs in each row of the table. Stinulus input values typically cover values that correspond to boundary or partition input spaces. In advanced testing systems, data can be harvested from a running system using a purpose-built tool (sniffer). The DDT framework can playback harvested data; producing a regression testing tool.
▲Automated test suites contain user's interactions through the system's GUI, for repeatable testing. Each test begins with a copy of the "before" image reference database. The "user interactions" are replayed through the "new" GUI version and result in the "post test" database. The ''reference'' "post test" database is compared to the "post test" database, using a tool.<ref>{{cite web |url=http://www.diffkit.org/ |title=Home |website=diffkit.org}}</ref> Differences reveal probable regression. Navigation the [[System Under Test]] user interface, reading data sources, and logging test findings may be coded in the table.
==Data driven==
Anything that has a potential to change (also called "variability," and includes elements such as environment, end points, test data, locations, etc.) is separated out from the test logic (scripts) and moved into an 'external asset'. This can be a configuration or test dataset. The logic executed in the script is dictated by the data values.
[[Keyword-driven testing]] is similar except that the logic for the test case itself is encoded as data values in the form of a set of "action words", and not embedded or "hard-coded" in the test script. The script is simply a "driver" (or delivery mechanism) for the data that is held in the data source.
The databases used for data-driven testing can include:
* [[Data pool]]s
* [[Data access object|DAO]] objects
* [[ActiveX Data Objects|ADO]] objects
==See also==
* [[{{Annotated link |Control table ]]}}▼
* [[{{Annotated link |Keyword-driven testing ]]}}▼* [[{{Annotated link |Test automation framework ]]}}▼▲* [[Keyword-driven testing]]
* [[{{Annotated link |Test-driven development ]]}}▼▲* [[Test automation framework]]
* {{Annotated link |Modularity-driven testing}}
▲* [[Test-driven development]]
* [[Modularity{{Annotated link |Model-drivenbased testing]]}}
* [[Model-based testing]]
==References==
{{Reflist}}
{{refbegin}}
* Carl Nagle: ''Test Automation Frameworks''[httphttps://safsdev.sourceforge.net/FRAMESDataDrivenTestAutomationFrameworks.htm], Software Automation Framework Support on SourceForge [http://safsdev.sourceforge.net/Default.htm], Data-driven testing approach [https://www.katalon.com/resources-center/tutorials/data-driven-testing/#]{{refend}}
[[Category:Software testing]]
| 