Talk:Model-based testing

Untitled
MBT tools: I have web page (http://mit.bme.hu/~micskeiz/pages/modelbased_testing.html) with a detailed list of model-based test generation tools, which might be useful to add as an external link. Opinions? Micskeiz (talk) 18:24, 17 January 2010 (UTC)
 * Your page is great, and i think you should definitely add it. It gives a good entry point (unlike this article) Stoilkov (talk) 18:06, 11 November 2011 (UTC)

The functional scope of model-based testing (MBT) is expanding, with the expansion being driven by greater adoption of Business Process Modeling (BPM) & Business Process Testing (BPT), as well as the development of interfaces between various tools. The only statement in the main article I'd like to challenge is the comment that model-based testing is black box. My challenge is simply that the functional expansion of MBT is moving the discipline to Grey Box. I don't see White Box in its future, but grey is a reality. I'll add a section to the main article in the next couple weeks and explain. In the mean time, great topic, great article, and informative comments. — Preceding unsigned comment added by JHGiddings (talk • contribs) 13:05, 5 March 2013 (UTC)

External links modified (February 2018)
Hello fellow Wikipedians,

I have just modified 2 external links on Model-based testing. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20120825215944/http://www.cs.waikato.ac.nz/research/mbt/ to http://www.cs.waikato.ac.nz/research/mbt/
 * Added archive https://web.archive.org/web/20120201171940/http://www.cs.waikato.ac.nz/research/mbt/ to http://www.cs.waikato.ac.nz/research/mbt

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 07:29, 3 February 2018 (UTC)

Missing info
I am missing information about test selection and diagnosis.
 * Since most models enable the generation of an infinite amount of test cases, one would like to select the most relevant ones first. Selection criteria include model coverage, code coverage, usage profiles, changes in requirements/features/model, minimize according to risk model.
 * Automatic diagnosis helps to simplify the result for the user and can add additional information (e.g. error only occurs when sum of two variables exceeds 2^32).

I am missing some links to properties of the system under test, like non-determinism, real-time, data, state, etc.

I am missing a link to IOCO (https://research.utwente.nl/en/publications/a-formal-approach-to-conformance-testing) and UIOCO (https://research.utwente.nl/en/publications/action-refinement-in-testing-with-uioco).

Should there be a MBT tools page (and this page links to that one?), since many tools exist (QuickCheck, Axini's Test Manger, NModel, SpecExplorer, PICT, JTorX, TorXakis, GraphWalker, ...) — Preceding unsigned comment added by 165.225.80.121 (talk) 16:02, 2 November 2018 (UTC)

Proposed change: Add section on "Input space modeling"
I propose to add a new section for "Input space modeling". See proposed text below. Why? Because this in an important field in model-based testing that is not otherwise recognized in this article. This is a personal interest for me -- I have created an open-source tool for input space modeling, which is freely available as open-source and from which I derive no financial gain. I do cite my tool, but I also reference several others. I believe this section is neutral, unopinionated, reliably supported, and a worthy contribution to common knowledge.

In support of that claim, I'll note that input space modeling is given its own chapter in a well-known textbook by Paul Amman and Jeff Offut. See http://cc.ee.ntu.edu.tw/~farn/courses/ST/slides/Ch4-ISP.pdf. CornutumProject (talk) 22:12, 18 October 2019 (UTC)

Abstract test cases can be generated automatically from a model of the "input space" of the SUT. The input space is defined by all of the input variables that affect SUT behavior, including not only explicit input parameters but also relevant internal state variables and even the internal state of external systems used by the SUT. For example, SUT behavior may depend on state of a file system or a database. From a model that defines each input variable and its value domain, it is possible to generate abstract test cases that describe various input combinations. Input space modeling is a common element in combinatorial testing techniques. Combinatorial testing provides a useful quantification of test adequacy known as "N-tuple coverage". For example, 2-tuple coverage (all-pairs testing) means that for each pair of input variables, every 2-tuple of value combinations is used in the test suite. Tools that generate test cases from input space models often use a "coverage model" that allows for selective tuning of the desired level of N-tuple coverage.

— Preceding unsigned comment added by CornutumProject (talk • contribs) 22:12, 18 October 2019 (UTC)
 * The request is promotional in that it uses references linked to the COI editor's test cases. Regards, Spintendo  23:26, 18 October 2019 (UTC)