Fully Automatic Testing with Functions as Specifications

An Adaptive Design Methodology for Reduction of Product Development Risk

“…As such VITE generates expected input test-data sequences for large variations of environment, thereby supports generation of special test sequences that span the required domain and also compares performance. It was argued that [41] functional test sequences provide formal basis to integration testing and the input sequence(TS) kx used for some functional test, can be reused for integration testing, rather than generating separate (TS) new , using any of the test-data generation methods like [42]. For testing the subsystem the data received by SAE and transformed by DRB functions only is to be given as test sequence (TS).…”

“…The integration testing of MDS can be viewed as identification of faulty communication channel [30,43] or faulty machine [30,44] problem. It is shown that mathematical functions and logical expressions can be used as, partial specifications and test data can be automatically generated [41].For the integration testing the idea of faulty communication channel is very logical, as the objective of integration testing is to uncover errors in the interaction between the components and their environment. As VITE generates the expected input data for MDS, by observing output data from MDS and comparing the same with the ideal-output data, performance can be evaluated.…”

Synthesis of Functions Using Generic Programming

“…A utom atic test system s like GVst [10] and QuickCheck [5] are designed to handle these kind of predicates. The test system is designed to falsify a property by finding a counterexam ple.…”

An Executable and Testable Semantics for iTasks

“…E xpressing th e o p erational sem antics in a F P L is as concise as in S co tt B rackets style. Using a functional program m ing language as carrier of th e specification of th e sem antics has a num ber of advantages: 1) th e ty p e sys tem perform s basic consistency checks on th e sem antics; 2) th e sem antics is executable; 3) using th e iTask system it is easy to validate th e sem antics by in teractiv e sim ulation; 4 ) using th e m odel-based te st tool GVst [5] it is possible to express properties ab o u t th e sem antics and equivalence of ta sk concisely, and to te st these p ro p erties fully autom atically. A lthough th e sem antics is executable, it is n o t an iTask system itself.…”

“…T he p ro p erty m ight hold for all o th e r values, b u t it is also possible th a t th ere exists inputs to th e task s such th a t th e p ro p e rty does not hold. T he value Undef is used as result of an existential quantified p ro p e rty (3 w .P x ) where no proof is found in th e given num ber of te st cases; th e value of th is p ro p erty is undefined[5]. This ty p e R esult is a subset of th e possible te st results handled by th e te st system GVst.…”