Mastering Test Generation from Smart Card Software Formal Models

Abstract

Abstract. The growing complexity of new smart card platforms, including multi-subscription or multi-application functionalities, led up to more and more difficulty in testing such systems. In previous work, we have introduced a new method for automated test generation from statebased formal specifications (B abstract machines, UML/OCL models, Z specifications). This method uses cause-effect analysis and boundary computation to produce test cases as sequences of operation invocations. This method is embedded in a model-based test generator which has been exercised on several applications in the domain of smart card software (GSM 11-11 application, electronic purse system and Java Card transaction mechanism). In all these applications, a B abstract machine was built specifically for automatic test generation by an independent validation team. Writing a specific formal model for testing has been shown to be cost-effective, and has the advantages that it can be tailored towards the desired test objectives. This paper focuses on showing the application of this test generation process from formal models in the context of Smart Card applications. We describe how the test generation can be controlled by using several model coverage criteria. These criteria are of three kinds: multiple condition coverage, boundary-value coverage and behavior coverage. This makes it possible to generate a systematic minimal test suite achieving strong coverage results. The test engineer chooses the criteria depending on the application test objectives and then fully controls the test generation process.

Automatic Test Data Generation for Java Card Applications Using Genetic Algorithm

“…Model-based testing can be easily introduced to the development process of the smart card, automatic test generation process saves 30% of labor when modeling task is included compared with manual testing. However, model-based testing is limited to functional testing [19]. Martin and Bousquet (2001) proposed a solution for JSC applet validation.…”

“…Van Weelden, et al (2005) showed that automated, formal, specification-based testing of smart card applets is feasible, and that errors can be detected [21]. Bouquet, et al (2005) focused on functional testing based on formal models of functional specifications of the software under test to automatically generate test data. Functional testing aims at ensuring the correctness of operations and their conformance to the functional requirements.…”

“…Functional testing aims at ensuring the correctness of operations and their conformance to the functional requirements. Unfortunately, formal methods demand real effort in order to formalize the specifications of the smart card applications [19].…”

Automatic Test Generation on a (U)SIM Smart Card

“…For example, [8] represents results on the CEPS standard, [3] shows validation results on the GSM 11.11 standard [12], [31] used automated test generation on the WAP Identity Module, [5] describes techniques which can be apply at different levels of smart card software, [6] represents an automatic test generation with the LEIRIOS tool [26] from B specifications, [29] presents a method to automatically generate test for Java card applets and [7] offers a semi formal model of Java Card applications in UML.…”

“Integrare”, a Collaborative Environment for Behavior-Oriented Design

“…In contrast, the formal semantics of the BT notation has been stressed from the beginning; a formal semantic language Behavior Tree Specific Language (BTSL) has been developed [11], and a BT can be automatically translated into formal languages such as CSP [9] and SAL [10], and described by a metamodel [8]. Even though a BT is a formal specification, unlike formal languages such as CSP, SAL or B notation [41], the flowchart-styled graphic notation of BT can be easily understood by non-experts. Therefore, the BT notation has both advantages as a formal language with precise semantics so it can be mechanically checked, analyzed and simulated, as well as a soft and casual modeling [5] that non-technical stakeholders find appealing.…”