scholarly journals Applying GA with Tabu list for Automatically Generating Test Cases Based on Formal Specification

2015 ◽  
pp. 17-31
Author(s):  
Yuqin Zhou ◽  
Taku Sugihara ◽  
Yuji Sato
Keyword(s):  
Formal Specification ◽  
Test Cases ◽  
Tabu List

scholarly journals Formal Specification Based Automatic Test Generation for Embedded Network Systems

2014 ◽  
Vol 2014 ◽  
pp. 1-21
Author(s):  
Eun Hye Choi ◽  
Hideaki Nishihara ◽  
Takahiro Ando ◽  
Nguyen Van Tang ◽  
Masahiro Aoki ◽  
...  
Keyword(s):  
Test Generation ◽  
Formal Specification ◽  
Test Cases ◽  
Practical Case ◽  
Automatic Test Generation ◽  
Automatic Test ◽  
Network Systems ◽  
Embedded Network ◽  
Efficient Test ◽  
Design And Testing

Embedded systems have become increasingly connected and communicate with each other, forming large-scaled and complicated network systems. To make their design and testing more reliable and robust, this paper proposes a formal specification language calledSENSand aSENS-based automatic test generation tool calledTGSENS. Our approach is summarized as follows: (1) A user describes requirements of target embedded network systems by logical property-based constraints usingSENS. (2) GivenSENSspecifications, test cases are automatically generated using a SAT-based solver. Filtering mechanisms to select efficient test cases are also available in our tool. (3) In addition, given a testing goal by the user, test sequences are automatically extracted from exhaustive test cases. We’ve implemented our approach and conducted several experiments on practical case studies. Through the experiments, we confirmed the efficiency of our approach in design and test generation of real embedded air-conditioning network systems.

Mengukur Paras Kesahsahihan Spesifikasi Z Dalam Penilaian Spesifikasi Keperluan Pelajar Melalui Pendekatan Pelaksanaan Bersimbol

2012 ◽  
Author(s):  
Zarina Shukur ◽  
Ahmad Rizal Mohd. Yusof
Keyword(s):  
Key Words ◽  
Formal Specification ◽  
Symbolic Execution ◽  
Test Cases ◽  
User Requirements ◽  
Testing Technique ◽  
Software Specification ◽  
Requirement Specification ◽  
Validation Measure

Kertas ini mengesyorkan kaedah pengukuran paras kesahsahihan spesifikasi formal perisian. Pengesahsahihan dilakukan untuk memastikan spesifikasi menyatakan kelakuan program dengan tepat dan memenuhi keperluan pengguna. Paras kesahsahihan ini ingin diukur khususnya untuk kegunaan guru dalam menilai spesifikasi keperluan yang disediakan oleh pelajar. Pengesahsahihan dilakukan dengan menggunakan teknik pengujian, iaitu spesifikasi yang dihasilkan (oleh pelajar) dilaksanakan secara bersimbol terhadap sejumlah kes ujian yang disediakan secara bermakna dengan bantuan pelanggan (diwakili oleh guru). Seterusnya output ujian dalam bentuk predikat matematik antara pelanggan (guru) dan penspesifikasi (pelajar) dibandingkan. Hasil daripada perbandingan ini adalah suatu nilai numerik yang mencerminkan paras kesahsahihan spesifikasi berkaitan. Kata kunci: Spesifikasi formal, pengesahsahihan spesifikasi, perlaksanaan bersimbol, paras kesahsahihan, ukuran kesahsahihan spesifikasi This paper proposes a method to measure the level of formal software specification validity. The validation of a specification is done in order to ensure that the specification correctly specify the program behaviour and fulfill the user requirements. We wish to measure the level of validity for teacher purposes in evaluating requirement specification which is written by students. The validation is done by using testing technique that is; the specification (which is prepared by the student) will be symbolically executed against several test cases which have been prepared earlier (by the teacher). Then, the output from the test, which is in the form of mathematical predicates will be compared against the expected answer. The result from the comparison is a numeric value which represents the level of the specification validity. Key words: Formal specification, specification validation, symbolic execution, validity level, specification validation measure

Usage notes

1994 ◽  
Author(s):  
Douglas Schenck ◽  
Peter Wilson
Keyword(s):  
Formal Specification ◽  
Object Oriented ◽  
Data Type ◽  
Test Case ◽  
Test Cases ◽  
Formal Definition ◽  
Actual Parameter ◽  
Parameter Values ◽  
Individual Objects

Now we discuss some of the potential uses of the EXPRESS-I language. In Object-Oriented terms, an EXPRESS entity would be called a class, and an instance of a class is termed an object. One object may reference another object. EXPRESS, though, distinguishes between entities and types (i.e., the enumeration, select and the defined data type) as entities may be subtyped whereas types cannot be. EXPRESS-I treats entity instances as objects in the OO sense. It also allows types to be treated as objects in that they can be instantiated and referenced. Alternatively, type values may be embedded in entity instances. The simplest use of EXPRESS-I is as a paper exercise in displaying examples of EXPRESS declarations that are populated with data. The language allows the display of entity instances as referenceable objects. Types instances may also be displayed as referenceable objects, or they may appear as unreferenceable values within other objects' values. Examples in this book show both forms of type instantiation. Values of explicit entity attributes are required. The values of derived or inverse attributes need not be displayed, except as exemplars, because as noted, these are essentially calculable from the values of the explicit attributes. Examples of EXPRESS schemas can also be displayed, as well as individual objects. The EXPRESS-I model construct is provided to enable the display of multiple schemas. Typically, a model would be used when two or more EXPRESS schemas interact with each other. Note that EXPRESS itself does not support such a construct. Note: We do not discuss models in this book. The test case construct is provided to assist in the formal specification of test cases against the implementation of an EXPRESS schema. EXPRESS itself does not provide an equivalent construct. For a test case, a base set of EXPRESS-I objects must be defined which will be the objects (and their supporting data) to be tested. The values of these objects may be in the form of parameters, whose formal definition are given in an enclosing context. A series of test cases may then be defined on the context, by providing actual parameter values.

Linear Visco-Resistive Computations of Magnetohydrodynamic Waves: I. The Code and Test Cases

1994 ◽  
Vol 144 ◽  
pp. 503-505
Author(s):  
R. Erdélyi ◽  
M. Goossens ◽  
S. Poedts
Keyword(s):  
Resonant Absorption ◽  
Numerical Code ◽  
Mhd Waves ◽  
Test Cases ◽  
Numerical Accuracy ◽  
Element Discretization ◽  
Flux Tubes ◽  
Magnetohydrodynamic Waves ◽  
Viscosity Coefficients ◽  
Magnetic Flux Tubes

AbstractThe stationary state of resonant absorption of linear, MHD waves in cylindrical magnetic flux tubes is studied in viscous, compressible MHD with a numerical code using finite element discretization. The full viscosity tensor with the five viscosity coefficients as given by Braginskii is included in the analysis. Our computations reproduce the absorption rates obtained by Lou in scalar viscous MHD and Goossens and Poedts in resistive MHD, which guarantee the numerical accuracy of the tensorial viscous MHD code.

Formal Specification and Design

1992 ◽  
Author(s):  
L. M. G. Feijs ◽  
H. B. M. Jonkers
Keyword(s):  
Formal Specification

Necessary test cases for Decision Coverage and Modified Condition / Decision Coverage

2008 ◽  
Vol 52 (3-4) ◽  
pp. 187 ◽  
Author(s):  
Zalán Szűgyi ◽  
Zoltán Porkoláb
Keyword(s):  
Test Cases
Sign in / Sign up

Export Citation Format

Share Document