WO2006070113A2 - Procede pour l’evaluation de caracteristiques operationnelles d’un programme - Google Patents

Procede pour l’evaluation de caracteristiques operationnelles d’un programme Download PDF

Info

Publication number
WO2006070113A2
WO2006070113A2 PCT/FR2005/003241 FR2005003241W WO2006070113A2 WO 2006070113 A2 WO2006070113 A2 WO 2006070113A2 FR 2005003241 W FR2005003241 W FR 2005003241W WO 2006070113 A2 WO2006070113 A2 WO 2006070113A2
Authority
WO
WIPO (PCT)
Prior art keywords
program
execution
test
operational characteristics
certainty
Prior art date
Application number
PCT/FR2005/003241
Other languages
English (en)
Other versions
WO2006070113A3 (fr
Inventor
Eric Vetillard
Renaud Marlet
Original Assignee
Trusted Logic
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Trusted Logic filed Critical Trusted Logic
Priority to EP05850582A priority Critical patent/EP1836580A2/fr
Publication of WO2006070113A2 publication Critical patent/WO2006070113A2/fr
Publication of WO2006070113A3 publication Critical patent/WO2006070113A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3696—Methods or tools to render software testable
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs

Definitions

  • the present invention relates to a method for the evaluation of operational characteristics of a program as well as to an execution system implementing said method.
  • An application can for example perform illegal operations (divulge a secret code, connect to unauthorized sites, silently send messages, etc.), perform lawful operations but for which it does not have the appropriate rights, consume more resources than it can claim and thus deprive other applications, alter valuable data, etc.
  • an application may use hardware or software functionalities that prove not to be present on the execution platform (for example because they are optional) or that are present unexpectedly or inappropriate (eg because they are limited or because of a version mismatch). In this case, the application does not work or malfunctions, which the end user may wrongly attribute to the service or hardware provider.
  • a correction check consists of checks that are specific to a program and its specification, whereas checks of a validity check may be identical for all programs in a class of programs (for example: games , couriers, banking applications, etc.) based in particular on the expected use of system resources for the type of program assumed.
  • the same "policy" is applied to a set of programs.
  • An example of a correction check is the verification of orders accepted by a smart card application.
  • Smartcard applications are programs that receive input byte sequences and output byte sequences.
  • An input byte sequence typically represents a command (APDU command, "Application Protocol Data Unit") that the program must execute.
  • API command "Application Protocol Data Unit”
  • the validity check is governed by the a priori definition of a policy, applicable to a set of programs and defined as a set of criteria to be met or rules to be met.
  • security criteria can be derived from a prior risk analysis, which notably assesses the assets to be protected on the platform and in the programs, the threats against these assets, and the measures to be taken for to protect them.
  • Interoperability criteria can be drawn from the technical specifications of the different execution platforms, the error cases reported by the test teams and the users, the good programming experience of the developers, etc.
  • CS-DESKeyStrength can stipulate that it is forbidden to use "DES” keys that are too weak, for example less than 128 bits long.
  • an interoperability criterion could for example stipulate not to use an "RSA” key (for example because the target platform does not allow this type of key to be handled), or no "RSA" key of length greater than 1024 bits (for example because the target platform does not allow to handle keys of this size).
  • the "buf”, “off” and “len” values are dynamic arguments provided to the “install” method.
  • the “buf” table contains the sequence of bytes transmitted to the map, and “off” and “len” determine the corresponding segment in “buf”.
  • “buf [offj” (the byte stored at the “off” index of the table “buf") is equal to "TYPE_DES” and that "getShort ⁇ uf, off + 1)” (the Short integer stored at the "off + 1" and “off + 2" indexes of the "buf” table) is less than 128.
  • an application may only run in a particular context.
  • the life cycle of a smart card application usually begins with a phase of card loading, installation, and customization, which are typically done under the control of the institution issuing the card. under the control of the application provider.
  • the interactions with the application during these phases are not arbitrary.
  • the application does not meet the security criterion in the strict sense (that is, for any possible execution, especially for any input provided to the program), the criterion is nevertheless satisfied in practice (ie ie for a given execution class, especially for a given class of inputs).
  • the "legal entries" are the entries compatible with said context, and a "legal execution” of the application is an execution on legal entries.
  • it is important to define the context of execution considered and in particular the class of the legal entries of the application in this context for example: any entry possible from the application, arguments with a fixed value or in a fixed range of values, etc.
  • the situation is the same for the case of the correction check: the verification of the suitability to a specification may relate only to particular execution contexts, including particular input classes, given by the frame (s) ) using the application.
  • CS-NoSMSInLoop can prohibit the sending of SMS (text messages) inside a programming loop (iterative or recursive construction) to avoid a number of unintended and unintentional mailings. doubt unjustified.
  • CS-NoSMS Surtax can prohibit the use of surcharged SMS, that is to say for which the consumer will be charged in addition to the price of a simple SMS. For example, currently in France, the SMS numbers of the form “3xxxx” (where each "x" is any number) are not surcharged, those of the form “4xxxx” are surcharged by 5 euro cents, those of the form “Ixxxx” are surcharged by 50 euro cents.
  • correction and validity checks do not necessarily concern strict Boolean properties that can only be true or false, such as the equality between two values.
  • the validity in this case is characterized by the number of bytes allocated. Depending on the context of use, this number may turn out to be lower or higher than certain thresholds, thus determining validity in the particular context.
  • a program may correspond more or less well (to different degrees) to what is stipulated in its specification, and it is only given a particular context that the implementation can be considered correct or not, with different degree and level of trust.
  • a program may satisfy different validity criteria more or less, and it is also only given a particular context that the implementation can be considered valid or not, to such a degree and with such a level of confidence .
  • An operational characteristic of a program is a value (more or less complex) associated with the execution of the program, such as the memory consumption, the execution time, the list of the routines of the system called during the execution of the program as well as the corresponding values of the arguments, etc.
  • Operational features also include the status of controls, including correctness and validity, which judge whether the behavior of a program matches that stipulated in a specification or whether the program meets a number of validity criteria.
  • the evaluation of an operational characteristic can often be seen as the result of a combination of more basic evaluation fragments.
  • the memory consumption can be constructed from a combination operation which is the sum function, and evaluation fragments which are the number of bytes requested during execution, at the various memory allocation sites.
  • a control can be expressed using a combination operation that is the logical conjunction as well as evaluation fragments that are the verification of logical conditions that must all be true for the control not to detect. abnormality.
  • An operational characteristic of a program, and particularly a validity criterion may or may not relate to a particular location of the program execution.
  • the "CS-DESKeyStrength" criterion is uniformly expressed throughout the program and is not tied to a particular code area, nor is a correction check performed on an output of the program.
  • the "CS-NoSMSInLoop" criterion controls the type of program area where SMS sending can occur.
  • the transgression of a criterion usually occurs in specific places of the program or the execution.
  • a program point is an address in the program code, usually an instruction or an executable operation.
  • An execution path represents a finite or infinite sequence of successive program points in the same execution of the program. In the case of a program with loops, an execution path may have several times (possibly infinitely many times) the same program point.
  • a class of execution paths can be represented by a subgraph of the control flow and / or program flow graph, a grammar, a transition system, a time logic expression with the basic state of the points program, etc.
  • An execution point represents a moment in the execution of a program, usually an instant determined by a given current program point and / or a condition on the current state of the program and / or the history of the program. the execution.
  • An execution point represents a moment in the execution of a program. At a run-point corresponds a current program point, as well as an execution path from the program start point to the current program point. In addition, the execution of a program is punctuated by the occurrence of events, internal or external to the program, which may or may not be relevant for determining the operational characteristics of the program.
  • Hardware events such as pressing a key on the keyboard by the user or the arrival of a call on a mobile phone, result in software events after processing by the execution platform and possible crossing of layers of the runtime system.
  • Software events may include simple, localized, qualified and / or composite events:
  • Simple events include: executing certain instructions or operations, program calls to runtime routines, runtime system calls to program routines, program interrupts, and / or failover system interrupts. executing, throwing an exception, catching an exception, changes in program state and / or runtime, variations in runtime resource availability, time stamps in the execution of the program (total time and / or detailed time for the various operations performed), etc.
  • Localized events are events that occur at specific locations in the program and / or when entering particular places and / or when leaving particular places. A particular place may be for example a program point, an execution path, a routine, a programming loop (iterative and / or recursive), an exception or interrupt catch-up code, etc.
  • Qualified events consist of events dealing with particular values or classes of values: parameters of statements or operations, routines called, arguments of routines, type of exception thrown or caught, state of the program and / or system, state of availability of the execution system resources, value of the time spent in the execution of the program (total time and / or detailed time for the various operations performed), etc.
  • Compound events consist of combinations of events that can be used to express the history of the execution via the sequence of events, for example the fact that the call to a certain routine occurs only after the call of another.
  • a typical qualified event is the call of a given routine with arguments of given value or within given value ranges.
  • criteria such as, for example, validity criteria, are expressed as rules.
  • a rule is satisfied if its logical value is true. It is transgressed if its logical value is false. It is indeterminate (or unresolved) if its logical value is indeterminate.
  • the conditions Cy, ..., CN can relate in particular to the nature of the event E, but also to the values manipulated by the program and / or the execution system at the moment when the event occurs, on the flow control of the program (for example, the presence of the execution point inside a programming loop), at the particular place of the program where the event occurs (for example, given program points or routines) etc.
  • the validity criteria given as examples above are special cases of such rules.
  • the criterion "CS-DESKeyStrength" of minimum key length DES can be expressed as follows: if the method "buildKey" is called with the first argument "TYPE-DES" then the second argument must be greater than or equal to 128.
  • the criterion "CS-NoSMSInLoop" of non-sending SMS in loop can be expressed as follows: if the method "MessageConnection.send” is called, then the calling point must not be inside a programming loop .
  • the criterion "CS-NoSMSSurtax" for non-sending overtaxed SMS can be expressed as follows: if the method "Connector.open” is called with an argument starting with "sms: // ", then this argument must be of the form” sms: // 3xx; ⁇ ".
  • conditions do not necessarily have to be related to computable elements or properties. For example, they may relate to ethical and ethical principles (no sexual, critic, etc.), which can only be controlled by a human being and not by a machine. The same goes for most display conditions, such as Look and Feel. This type of condition is not automatically verifiable; it requires the advice of a human operator.
  • control is static (before running on the platform) or dynamic (during execution);
  • control is "black box” (without looking at the code, observing only the reactions to the entries) or "white box” (looking at the code and / or the internal state of the running program);
  • the control is "manual” (performed by a human) or automatic (performed by a decision tool).
  • a control can be "semi-automatic” (with human intervention and decision tools).
  • the control can be "gray box” in the case where only a part of the state of execution of the program is observable.
  • the program can also be tested in "black box” or “gray box”, without accessing the code to analyze it, only in response to stimuli. With this approach, the program is executed in a number of supposedly representative circumstances, and its behavior is observed from the outside (or in part from the inside in the case of the gray box) to judge whether it corresponds to the behavior. expected and / or meets the criteria set. •
  • the program can also be controlled automatically, using an analysis tool, provided of course that the controls are automatable.
  • Some tools check with a static analysis that the code of a program follows general rules of good training and good typing, which provides some guarantees of basic operation, regardless of the platform target. This is the case, for example, of verifiers for virtual machines ("bytecode verifiers") associated with "Java” runtime environments (including “Java Card”). Such type analyzers can work on both source code and object code. However, they do not meet specific criteria, for example regarding security or interoperability.
  • French Patent No. 03 15544 filed December 30, 2003 in the name of the Applicant, provides a method for determining the operational characteristics of a program, based on static analysis techniques.
  • static analysis techniques are numerous: abstract interpretation, control flow analysis, data flow analysis, model checking, formal proofs, and so on.
  • the information resulting from a static analysis may make it possible to deduce certain operational characteristics of a program, for example memory consumption or execution time, and in particular to carry out validity checks. But static analysis also allows in some cases to perform some correction checks.
  • the commands that a Java Card application can answer can be determined by exploring all the execution paths that start from the "Applet.process” method, by examining all comparison operations on the first byte (byte class "CLA") and the second byte (instruction byte "INS") of the byte array constituting the "APDU buffer", and observing the status of command returns (normal execution or error).
  • the commands accepted by the application correspond to the values of the first and second bytes for which the program does not throw an exception.
  • the implementation is correct with respect to the accepted commands if the values determined by the static analysis are equal to the values indicated in the specification.
  • Another example is the verification that certain actions do not occur, in particular that certain sensitive data, such as a PIN (Personal Identification Number), are manipulated only in the circumstances provided by the specification.
  • PIN Personal Identification Number
  • a static analysis can explore all the execution paths that start from the recognition of this command and check that none of them does not affect a PIN object (including its verification status and its successive unsuccessful test counter).
  • a static analysis does not always make it possible to precisely determine any operational characteristic of a program. This may be due to a combination of various factors: difficulty or inability to automate the evaluation of the operational characteristic (for example, ergonomics, ethics or ethical issues), variable behavior according to program inputs, lack of precision of the static analysis, intrinsic complexity of the program, etc.
  • the specification of a "Java Card” application complying with the ISO 7816 standard may stipulate that the "GET DATA" command (whose INS byte is equal to 202) does not implement a security measure (the octet CLA is equal to 0) and the "PUT DATA" command (whose INS byte is equal to 218) implements a proprietary security measure (the CLA byte is equal to 132).
  • an analysis can simply determine that the second argument of the "buildKey” method is between 96 and 192, without further precision. In this case, it is not possible to establish with certainty whether the key length security criterion mentioned above (length at least 128) is satisfied or transgressed.
  • a program analysis can provide relevant information to assist in diagnosis: locating the potential offense, the approximate status of the program and / or the program delivery path, etc. This information is also useful in the case where the program is incorrect (respectively invalid) with certainty, in order to know where and possibly how to correct it.
  • test is a different approach. This is the most commonly used solution for both the correction check and the validity check.
  • a test includes a scenario of interactions with the program as well as evaluations of operational characteristics, based on the observed behavior of the program.
  • Interactions include entries to submit to the program (input data provided and actions performed including interrupts, variations of availability of resources, time marks, etc.) and outputs produced (output data and produced actions). Some entries can reach the program via the runtime system (operating system, virtual machine, software interface, etc.) over which the program runs, for example as a call to program routines or under form of return values provided to system routines called by the program. The same goes for program outputs, which can pass through the runtime system.
  • runtime system operating system, virtual machine, software interface, etc.
  • Operational feature assessments are treatments that focus on inputs to the program and outputs produced. For example, executing on a simulator commands for installing and customizing a smart card application results in the execution of memory allocation operations; several executions of this type, with values representative of a certain context of use, make it possible to estimate approximately the memory consumption of the application.
  • the test scenario also includes stopping conditions, for example: exhaustion of the behaviors to be observed, number of errors or transgressions exceeding a certain threshold, time spent in the execution of the test (which has an impact on the cost of the test run, especially in the presence of a test operator), etc.
  • a scenario can simply stipulate to browse "as much as possible" the various screens of the application in order to check the texts displayed are written in the target language and not are not truncated. For example, one or more hours can be left for a test operator to perform several such checks at the same time. There is no this case guaranteed result but effort guarantee, the quality of the final status depends a lot on the test operator.
  • tests are usually necessary to approach an operational characteristic, or to make a judgment of correction or validity. These tests are grouped in a test suite.
  • the program is run using the runtime device of a test platform.
  • This execution device can be based on the program's target execution platform or on any equivalent execution platform: simulator, emulator, and so on.
  • a test platform may need to be configured with respect to the target execution platforms as well as the intended context and execution environment.
  • the test platform may have to offer the program a more or less complete runtime environment. For example, to test a mobile phone application, it may be necessary to have the network of a telephone operator (simulated if necessary), an operational server at the content provider, etc.
  • Some execution devices may also have introspection facilities to provide, in addition to regular program outputs, information on the states and internal actions in progress. This information can be provided by the platform in a passive manner (during execution, the platform reports events and state changes) or active (running, the platform may be questioned about his condition).
  • Some enforcement devices may also provide a means of acting on enforcement. This is particularly the case when they include a debugger or the features of a debugger. It is then in particular possible to interrupt the execution temporarily, in particular following the setting of breakpoints (at certain program points, at the entry of certain routines, etc.).
  • Target platforms in general do not allow introspection or action for various reasons: security, robustness, design, etc.
  • test platform does not include introspection or action on execution, it may be possible to have such features by instrumenting the program.
  • the program can be instrumented before execution to make this information more easily accessible or accessible with greater precision.
  • the program can be instrumented to produce, in addition to its original outputs, additional outputs that provide information on its state and its internal actions.
  • the instrumentation may be such that these additional outputs are generated spontaneously during program execution or produced in response to particular inputs of the program.
  • Said particular entries may be original inputs of the program and / or additional entries explicitly introduced by the instrumentation in order to query the program and / or the execution system on their state and / or their actions.
  • a smart card application can be instrumented to first count the number of bytes allocated since the beginning of the execution and secondly accept an additional command (or an additional parameter to an existing command, for example of type "GET DATA") which returns this value.
  • the program can also be instrumented to act on its execution, in particular to interrupt it temporarily (for example while waiting for a particular entry). This allows in particular to provide performance checks when the execution platform does not have them. For example, it is possible to simulate certain debugger functions, such as setting a breakpoint at certain program points, entering certain routines, and so on.
  • the program can also be instrumented to, in addition to its original effects, dynamically perform the evaluation of some of the desired operational characteristics and produce the result of this evaluation as an additional output.
  • the operational characteristics to be evaluated include checks to be carried out or rules to be verified
  • the program may be instrumented to, in addition to its original effects, dynamically perform the check or dynamically check the rule and produce a status of that check or this verification (satisfaction or transgression).
  • the instrumentation may precede all occurrences of calls to the method "Connector.open” of a test on the string given as argument of this method to check that if it starts with "sms: //", then it is not followed a premium number, for example of the form "Ixxxx”.
  • the instrumentation can be manual and / or automatic.
  • Automatic instrumentation may include recognizing particular patterns ("patterns") of code and modifying them systematically. For example, in the case of a "Java Card” application, it is possible to identify all the occurrences of allocation instructions (of the "new" type) as well as all occurrences of calls to allocation methods of objects (of the type "makeTransientByteArray", "buildKey”, etc.) and precede them with the increment a count of the number of bytes allocated by the dynamic value requested at runtime.
  • the behavior of the program is monitored by observing the outputs produced by the program in response to the inputs made and / or by interrogating the program on its state and its internal actions if it is instrumented at this time. effect and / or by interrogating the test platform if this allows it (this is usually the case of a test platform based on a simulator or an emulator).
  • the information collected on the behavior of the program can be made available via a control device of the test platform, which can in particular provide means for representing the outputs made by the program, means for representing the current state and actions performed by the program and / or the execution system (including an indication of program points and / or execution points achieved since the execution of the test or a set of tests); interrogation of the program and / or the test platform, and storage means and representation of the execution history.
  • a control device of the test platform can in particular provide means for representing the outputs made by the program, means for representing the current state and actions performed by the program and / or the execution system (including an indication of program points and / or execution points achieved since the execution of the test or a set of tests); interrogation of the program and / or the test platform, and storage means and representation of the execution history.
  • this control device allows a test operator to answer questions asked in the test scripts, including the conditions for stopping a test.
  • test scenario is executed by an executable test script that installs and / or launches the program on the test platform and / or links the different interactions stipulated in the scenario.
  • a manual test it is a test operator who installs and / or launches the program on the test platform and / or performs the various interactions recorded in the scenario.
  • a single test can combine automated operations with manual operations.
  • program entries can be provided automatically by the test script and / or manually by a test operator.
  • controls can be performed automatically by the test script and / or manually by a test operator.
  • test operator In the case where a test operator must intervene, the interactions can be described in a test specification and / or requested by the test script executed, for example via a display on a control station. In the latter case, the test operator is guided in the test scenario by requests for entries and / or checks made by the test script and by the observations he can obtain on the execution of the program. This allows in particular to make entries or controls impossible to achieve by a machine. It also provides information to decide when to stop a test. For example, a test operator may decide to terminate an execution when a group of execution points of a program (for example, all execution points, all execution points associated with a rule, etc.) have been reached by performing one or more tests.
  • a group of execution points of a program for example, all execution points, all execution points associated with a rule, etc.
  • Providing performance information (execution points so far, called routines, program status and / or runtime system, etc.) also allows the test operator to guess what type Interaction allows to reach such or such point or zone of program and / or to trigger this or that type of event.
  • test In the case where a test must evaluate the satisfaction of a rule of the form "if E then Ci and ... and CM", the test must include evaluations of the logical expressions that are the condition of occurrence of the event E and the conditions to be fulfilled Ci, ...,
  • test platform is a simulator or emulator of the target platforms
  • information for example, the current program point, the status of the program and / or the execution system, etc.
  • This additional information can in particular make it possible to automatically determine the logical value of some of the conditions of the rules defined as "if E then Cj and ... and CV".
  • test platform In the case where the test platform is the target platform itself, only the external effects are usually visible, not the internal events. Verification of the occurrence of an event may, however, be indirect. For example, the test operator may observe the dialed telephone number when sending an SMS with an authorization request. On the other hand, some information may remain inaccessible, such as the current execution point or the fact that this execution point is in a programming loop. Some information may, however, be made available after instrumentation of the program.
  • test When an event associated with a rule occurs, after automatic or manual determination of satisfaction, transgression or irresolution, it is necessary to decide whether or not to continue the test.
  • the condition for stopping the execution of a test is stipulated in its scenario. It may depend on various factors relating to rule status, possibly at the point of execution where it is controlled. A test may also be interrupted after a given execution time, for example because it is judged that obtaining additional information would not be profitable, that is to say, would require too much time.
  • the quality of a test suite depends in particular on its degree of coverage in different aspects, including:
  • control flow coverage a posteriori measurement of the proportion of control flow elements (instructions, execution branches, execution paths, iterative structures, etc.) that are run during the test suite execution for a given implementation. In practice, checking the elements of the control flow that are traversed requires the ability to observe the execution and / or to be able to instrument the code.
  • test suite In addition to coverage, other parameters affect the quality of a test suite, including the amount of resources it requires: equivalent tested functionality, better a test that runs in a short time, consuming little memory, etc.
  • the degree of coverage and the amount of testing depend on the methodology of test development and the care of the tester. The higher the coverage, the greater the effort required to design and perform the tests. However, in the software industry, productivity can be such an important parameter if it is more than safety or proper functioning criteria.
  • All or part of the data of a test suite can also be generated automatically from a formalization of the application specification.
  • one of the advantages is to be able to offer guarantees on the degree of coverage of a formal specification.
  • the tools capable of producing relevant test data in this way are still rare.
  • automatically generated test suites are subject to the same limitations as hand-written test suites.
  • test suffers from several limitations. This is a well-adapted approach for correction control (comparing its actual outputs to expected outputs), but less for validity checking.
  • test classes are often under-specified, such as, for example, running tests of applications for mobile phones; many of these tests involve running the application in a limited time as an ordinary user and noting some abnormal behavior of the application.
  • the human test operator is not sure what to look for or how to find it. At best he has a list of test objectives and he tries to wait for a maximum number of goals.
  • test operator does not always have the means to evaluate the quality of his work.
  • he remains powerless in front of malicious code, designed to remain hidden and to act only in particular circumstances that do not occur during the first rapid and superficial use of the application.
  • the object of the invention is an evaluation of the operational characteristics of a program, which notably allows the development of correction or validity control tools that provide a high level of certainty and / or productivity. . It thus makes it possible to obtain better compromises in efforts to provide and resulting confidence.
  • This method proposes a method for the evaluation of operational characteristics of a program, this method implementing a test platform (hardware and / or software) allowing the execution and the control of said program as well as a series of tests for evaluating said operational characteristics.
  • This method is characterized in that it comprises an evaluation procedure comprising the following steps:
  • a first step where the program is subjected to a static analysis which determines the operational characteristics of said program, with greater or lesser precision and which produces a set of test requirements intended to evaluate the operational characteristics which have not been determined with sufficient precision;
  • a third step where the program executed on said test platform is subjected to a test suite parameterized according to the test requirements generated during the first step; a fourth step where the operational characteristics of the program are formed from the operational characteristics determined by said static analysis, supplemented by the operational characteristics evaluated by said test suite.
  • the static analysis performed in the first step takes into account the assumption that only the input sequences possible program are sequences of legal entries.
  • the operational characteristics determined by the static analysis include one or more of the following information: the control flow, the data flow, the memory consumption, the execution time, the list of routines of the system called during the execution of the program, the corresponding values of the arguments, the status of the correction or validity checks.
  • Some tests in the test suite may have parameters that affect the operations performed during test execution and that may be adjusted to vary the accuracy with which the program's operational characteristics are evaluated.
  • the static analysis may produce parameter values for some of the selected tests to restrict said tests to only those operations that may improve said accuracy.
  • the tests may include:
  • test suite may include tests: • whose entries to submit are provided by a test program and / or by a test operator, the test program can indicate to the test operator specific operations to be performed on the test platform, and
  • a control device may assist the test operator by recording the observations of the test operator and presenting him with an up-to-date view of the operational characteristics evaluated until then so that he can may consider whether to continue the test or whether the accuracy achieved is sufficient.
  • the vision of the evaluated operational characteristics presented to the test operator may include a vision of program execution consisting of a representation indicating whether certain events have already occurred and / or under which circumstances, including:
  • Some of the above operational characteristics may be dependent on one or more target (target hardware and / or software) execution environments for the program as well as one or more target configurations of said environments (particularly with respect to resources and / or features available and / or allowed in said environments), and the test platform includes and / or emulates and / or simulates said target execution environments with their target configurations.
  • the aforementioned operational characteristics to be evaluated may include the verification of properties and that: In the first step, the static analysis determines properties that the program satisfies with certainty and properties that the program transgress with certainty (the other properties being properties that the analysis does not determine with certainty as being satisfied or transgressed); - In the second step, the program is subjected to the tests of the test suite which concern the properties of the program that the static analysis has not determined with certainty as satisfied or transgressed.
  • the static analysis may in particular determine on the one hand what are the execution points in which said event occurs with certainty or can occur and, secondly, the truth value of said conditions at said execution points when said event occurs, and in the second step, when during a test said event occurs or can occur at a PE execution point, only evaluated conditions that were not established by the static analysis as true with certainty at the PE execution point when said event occurs.
  • the aforesaid operational features to be evaluated include checking rules that determine whether the program is valid (respectively correct), in the third step, the operational characteristics of the program comprising the rule check being constituted according to the following procedure:
  • Test requirements are information that guides the execution of tests. They may include particular interactions with the program and specific assessments to be made. Specific interactions - specific entries to be submitted to the program.
  • the guiding of the execution of the tests can result in a parameterization of the execution device of the test platform (including the instrumentation of the platform) and / or an instrumentation of the program including in particular the installation of point systematic shutdowns, the installation of conditional stop points, the production of information enabling the evaluation of operational characteristics.
  • the program is subjected to a series of tests intended to evaluate said operational characteristics.
  • the static analysis has determined a satisfactory framework (as needed) for the consumption application memory, it is not necessary to test installation and customization commands with various values to try to estimate the memory consumption of the application.
  • the static analysis has determined with certainty the status of a control, for example the satisfaction or violation of a rule on the sending of SMS, it is useless to perform tests that try to verify whether this rule is respected or not in various circumstances.
  • test fragments capable of performing the evaluation fragments that the static analysis has not determined with sufficient precision are executed; the remaining evaluation fragments are provided by the static analysis.
  • operational characteristics are controls to be performed or rules to be verified, only the test fragments capable of performing the evaluation fragments which the static analysis has not determined with sufficient precision for to rule.
  • the tests are run on the test platform, configured if necessary against the program's target execution platforms.
  • This configuration may be restricted to only those cases which concern the operational characteristics that the static analysis has not determined with sufficient precision.
  • the operational characteristics are controls to be carried out or rules to check
  • the configuration can be restricted to cases that concern controls or rules on which the static analysis has not determined with certainty.
  • the instrumentation of the program may notably be based on information extracted by the static analysis of the first phase and on the particular operational characteristics to be evaluated, in order, for example, to minimize the additional consumption of resources (memory, execution time, etc.) and / or instrumentation limitations inherent in the program and / or the execution platform.
  • the instrumentation tool can be parameterized using the information provided by the static analysis.
  • the representation (respectively storage) of the information in the control device of the test platform can be made in such a way as to minimize the irrelevant information, in particular by limiting the representation (respectively memorization) to the only information necessary for establishing the data. operational characteristics that the analysis has not determined with sufficient precision. This allows a better comfort and greater productivity of the test operator (respectively an economy of resources in terms of memory and execution time).
  • This limitation of the representation (respectively storage) can be obtained by a parameterization of the control platform. This control platform can be directly parameterized by the results of the static analysis.
  • the information necessary to establish the occurrence or non-occurrence of an event may concern not only the current state of said execution but also the history of this execution.
  • This information can be provided automatically or not by the test platform and / or by a test operator, in particular at the request of the test script and / or with the aid of the control device of the test platform. . It is possible that some information remains indeterminate. When in doubt, the occurrence of the event should be considered as possible. This situation may arise in particular if the test operator can not, does not know or does not want to decide on issues that are his responsibility. There may be several reasons for this, for example: ignorance of the question asked or actions to be taken, lack of additional information, lack of time to provide an answer, etc.
  • the program When the question of the occurrence or not of an event arises, the program is in a certain execution point PE (or in a succession of execution points if the program is not interrupted momentarily waiting for a special entry). This execution point may not be immediately known outside the execution platform; it is therefore determined only with more or less precision.
  • the test may continue. Otherwise, checks are needed to check the truth value of the conditions in order to try to determine the satisfaction or violation of the rule, before making the decision to continue the test or to interrupt it.
  • condition C 7 is true at the PE execution point.
  • condition C 7 It is unclear whether condition C 7 is true or false at the PE enforcement point.
  • the verification of the condition must be automatable and the information necessary to determine with certainty if the condition is true (respectively false) must be available at this point of execution.
  • the information necessary to establish with certainty the truth value of a condition may relate to the execution history as well as the current state of said execution. This information can be provided by the test platform and / or by a test operator, in particular at the request of the test script.
  • test operator can not, does not know or does not want to decide on the information necessary to establish the truth value of a condition. This may be due to lack of knowledge of the question, lack of additional information, lack of time, etc. In this case, the condition must be considered unresolved, that is, possibly true or false.
  • the R rule is considered to be transgressed with certainty at the PE enforcement point for some program entries.
  • the execution of the test can be continued automatically (for example, to find more occurrences of transgressions), to terminate automatically (for example because a single transgression is sufficient to invalidate the rule), or continue only after agreement of the test operator (who is then judge of the relevance of the continuation of the test).
  • At least one of the dynamically falsifiable conditions is not established as true with certainty at the PE execution point and none of the dynamically falsifiable conditions is established as definitely false at the PE execution point: In this case, the rule R is considered unresolved at the PE enforcement point for some program entries.
  • the execution of the test may continue automatically, terminate automatically, or continue only after agreement of the test operator (who is then judge of the relevance of continuing the test).
  • the following particular case of the invention is considered, allowing the assisted certification of applications.
  • the execution device of the test platform allows the setting of breakpoints and the performance of introspection functions. If the execution device does not allow these features, the program can be instrumented for this purpose.
  • control device of the test platform can be programmed to keep a history of certain information (including past events) and / or to evaluate expressions (in particular by using the functions of introspection and / or history) and / or to ask a test operator to evaluate answering certain questions.
  • condition Ki the verification of the occurrence of the event E ⁇ is automatable, but that of the condition K 2 is not; only a human test operator can determine whether the display contains a warning, an authorization request, and so on.
  • Step 1 static analysis
  • the program is subjected to a static analysis that seeks to determine whether the rules are satisfied or transgressed in said execution context.
  • rule R is not satisfied at an execution point.
  • R is of indeterminate status
  • rule R is transgressed into an execution point.
  • execution point PE there exists an execution point PE such that E is determined with certainty as true and at least one of the conditions Q is determined with certainty as false.
  • the result of the static analysis includes a set of information about the rules that are satisfied at any point of execution or transgressed at an execution point, as well as a set of test requirements.
  • test requirements include in particular the set of indeterminate status rules in at least one execution point and / or, for any rule "if E then Q and ... and C # " of said set, the set PP R program points where the rule may be of indeterminate status and / or, for any PP program point of PPR, event E if it is dynamically falsifiable (ie undetermined) in PP as well as the subset of conditions "Ci, ..., CN" which are dynamically falsifiable in PP.
  • Sets of program points belonging to the same class of program points may be grouped together as one program area, such as all program points of a particular routine, a programming loop, and so on.
  • the program is subjected to a test suite that seeks to satisfy the test requirements produced by the first step.
  • test platform configured as follows. For any rule R of indeterminate status for said test, a breakpoint is set in each of the PP program points of PPR.
  • the device evaluates the event E of R if it is dynamically falsifiable and if the event occurs in PP, the control device also evaluates the subsets of R conditions that are dynamically falsifiable. If the verification of a dynamically falsifiable condition or the occurrence of event E is not automated, the test operator is queried, which can answer "true”, "false", or "undetermined".
  • the control device continuously records the details and the total number of occurrences of application of each rule to the different program points as well as the different statuses obtained (satisfied, indeterminate, transgressed).
  • the execution may continue automatically, stop automatically, or continue only after agreement of the test operator. For example, the execution can be continued even if a rule is satisfied, in order to reach a number of occurrences of satisfied rule deemed convincing. Similarly, one can continue the execution even after a transgression to try to find more cases.
  • breakpoints are posed to PP2 program points, PPs and PP 4.
  • the condition Kj is evaluated: if the argument of the method "Connector.open” is of the form “sms: // 3xxxx", the number of cases where rule Rj is satisfied is incremented; otherwise the number of application cases where the rule Ri is transgressed is incremented and the test operator is notified, who can decide whether or not to interrupt the test.
  • the condition K 2 is evaluated: the question "did the program display a message signaling the sending of an SMS and asked permission of the user? ".
  • the number of application cases where the rule R 2 is satisfied, indeterminate, or transgressed is incremented according to whether the operator answered "yes", “no” or "I do not know", respectively.
  • the test operator may also decide to interrupt the test; otherwise the test execution continues.
  • rule evaluations are only performed at PE enforcement points that are:
  • the information from the static analysis and those from the test suite execution are gathered in a single diagnosis.
  • the diagnosis can be qualified in terms of confidence depending on the number of remaining indeterminations and the coverage rate of the program points listed among the test requirements (eg, number of program points never achieved).
  • the instrumentation of the platform in particular of virtual machine (JVM), can be pushed even further by considering evaluation fragments in execution points, events, conditions, etc.
  • the execution device can be coupled to a real debugger allowing to examine in more detail the causes of a problem as soon as it is identified.
  • the protocol used to allow the control device to control the execution device may be based on the Java Virtual Machine Debug Interface (JVMDI) used for debugging Java applications.
  • JVMDI Java Virtual Machine Debug Interface

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Stored Programmes (AREA)
  • Testing Or Measuring Of Semiconductors Or The Like (AREA)
  • Inorganic Insulating Materials (AREA)
  • Apparatuses And Processes For Manufacturing Resistors (AREA)

Abstract

Le procédé selon l'invention comprend une étape d'analyse statique du programme qui détermine ses caractéristiques opérationnelles et qui produit des exigences de tests destinées à évaluer les caractéristiques opérationnelles imprécises, une étape où le programme est soumis à une sélection de tests constituée par les seuls tests et/ou fragments de tests qui concernent les caractéristiques opérationnelles imprécises, une étape où le programme est soumis à une suite de tests paramétrée selon les exigences de test générées lors de la première étape et une étape où les caractéristiques opérationnelles du programme sont constituées à partir des caractéristiques déterminées par l'analyse statique, complétées par les caractéristiques opérationnelles évaluées par la suite de tests.

Description

PROCEDE POUR L'EVALUATION DE CARACTERISTIQUES OPERATIONNELLES D'UN PROGRAMME.
La présente invention concerne un procédé pour l'évaluation de caractéristiques opérationnelles d'un programme ainsi qu'un système d'exécution mettant en œuvre ledit procédé.
Elle s'applique notamment dans le cas où l'analyse statique du programme effectuée dans le cadre de la détermination de caractéristiques opérationnelles de ce programme n'a pas été suffisamment précise ou même lorsque beaucoup de caractéristiques sont difficiles, voire impossibles à déterminer par analyse statique et, qu'en conséquence, on doit se contenter des déterminations très approximatives du test.
D'une manière générale, on sait que la plupart des petits systèmes embarqués (terminaux de paiement, organiseurs électroniques, téléphones mobiles, cartes à puce, etc.) réalisés il y a quelques années étaient des systèmes fermés ne pouvant exécuter que des programmes déterminés, installés lors de la fabrication. De même, bien que fonctionnellement plus ouverts, la plupart des ordinateurs étaient déconnectés de tout réseau et les quelques programmes qu'ils exécutaient avaient pour origine des éditeurs de logiciels bien identifiés. Du fait de cette faible variabilité, il était alors possible de « contenir » les défauts de fonctionnement des plates-formes d'exécution et des programmes.
Aujourd'hui, la tendance est à l'ouverture des systèmes, y compris les petits systèmes embarqués : même si la maîtrise n'en revient pas toujours directement à l'utilisateur final, on peut désormais charger de nouveaux programmes sur ces plates-formes d'exécution. Par ailleurs, beaucoup d'ordinateurs et de systèmes embarqués sont connectés, temporairement ou non, à des réseaux (Internet, téléphonie mobile, etc.) sur lesquels peuvent être téléchargés des programmes aux origines souvent inconnues et aux fonctionnalités souvent indéterminées. Enfin, la segmentation des marchés et la multiplication des fournisseurs, des modèles matériels et des versions logicielles conduisent, malgré la définition de standards, à des combinaisons de configurations qui n'ont pas toujours été anticipées.
Cette situation accentue les risques de dysfonctionnement, notamment en ce qui concerne l'interopérabilité (bon fonctionnement d'une même application sur plusieurs plates-formes d'exécution) et la sécurité.
Volontaires ou involontaires, les dysfonctionnements sécuritaires d'une application sont particulièrement dommageables. Une application peut par exemple effectuer des opérations illicites (divulguer un code secret, se connecter à des sites non autorisés, effectuer silencieusement des envois de messages, etc.), effectuer des opérations licites mais pour lesquelles elle n'a pas les droits appropriés, consommer plus de ressources que ce à quoi elle peut prétendre et ainsi en priver d'autres applications, altérer des données précieuses, etc.
Un autre souci majeur concerne la portabilité et l'interopérabilité. En effet, une application peut faire appel à des fonctionnalités matérielles ou logicielles qui s'avèrent ne pas être présentes sur la plate-forme d'exécution (par exemple parce qu'elles sont optionnelles) ou qui sont présentes d'une manière inattendue ou inappropriée (par exemple parce qu'elles sont limitées ou à cause d'une incompatibilité de version). Dans ce cas, l'application ne fonctionne pas ou fonctionne mal, ce que l'utilisateur final peut imputer à tort au fournisseur du service ou du matériel.
Même lorsque la sécurité et l'interopérabilité sont bien maîtrisés, la complexité croissante des systèmes et des programmes fait qu'ils comportent souvent des bogues (défauts de conception ou de réalisation se manifestant par des anomalies de fonctionnement). Ces bogues correspondent le plus souvent à des différences entre la spécification d'une application (cahier des charges) et son implémentation (la réalisation effective du cahier des charges sous forme d'un programme exécutable). Ces bogues conduisent généralement à des interruptions inopinées de l'exécution (« plantages »), parfois avec perte ou altération de données ; elles peuvent aussi conduire à des failles de sécurité.
Outre les problèmes de fonctionnement purs, certains fournisseurs d'applications ou de contenu veulent aussi appliquer une discipline de déontologie (par exemple, pour le contrôle d'accès des mineurs), des principes d'ergonomie ou des règles de style (par exemple, pour le respect d'un « Look and Feel »).
Les conséquences d'un dysfonctionnement peuvent être très graves dans le cas de systèmes critiques où la sécurité est primordiale. C'est le cas par exemple pour les applications dans le domaine de la banque, de la santé, du transport, de l'identité, etc.
Même lorsque les dysfonctionnements sont mineurs pour les utilisateurs et ne se soldent que par de faibles dégâts ou des indisponibilités des systèmes, les retombées commerciales peuvent être désastreuses pour les fournisseurs de matériel ou de logiciels : non seulement cela peut parfois nécessiter de coûteux rappels de matériel, mais surtout cela peut endommager leur image auprès des consommateurs. Le risque est notamment manifeste pour les opérateurs téléphoniques qui permettent à leurs clients de télécharger de nouveaux programmes dans leurs téléphones mobiles.
Pour se prémunir contre les risques de dysfonctionnement, un contrôle des programmes est nécessaire. Il existe en fait deux grands types de contrôle :
• Contrôle de la correction d'un programme : étant donnés un programme et une spécification, ce contrôle consiste à vérifier que le comportement du programme correspond bien à celui qui est stipulé dans la spécification.
• Contrôle de la validité d'un programme : étant donnés un programme et des critères de validité (pouvant porter sur la sécurité, l'interopérabilité, etc.), ce contrôle consiste à vérifier que le programme satisfait bien chacun desdits critères. Ces critères définissent s'il est acceptable ou non que le programme soit exécuté sur une plate-forme cible donnée (ou un ensemble de plates-formes) par certains groupes d'utilisateurs donnés. Ces critères forment une « politique » de validité pouvant notamment concerner la sécurité, l'interopérabilité, etc. Ces deux types de contrôles diffèrent sur plusieurs points. En particulier, alors que le contrôle de correction porte sur ce que produit le programme et son adéquation à des productions attendues, le contrôle de validité se concentre davantage sur la manière de produire ainsi que sur l'autorisation et la possibilité de ces productions pour une plate-forme d'exécution et un environnement cibles donnés.
De plus, un contrôle de correction consiste en des vérifications qui sont spécifiques à un programme et à sa spécification, alors que les vérifications d'un contrôle de validité peuvent être identiques pour tous les programmes d'une classe de programmes (par exemple : jeux, messageries, applications bancaires, etc.) en fonction notamment de l'usage attendu des ressources du système pour le type de programme supposé. Dans ce second cas, une même « politique » est ainsi appliquée à un ensemble de programmes.
À titre d'exemple de contrôle de correction, on peut citer la vérification des commandes acceptées par une application pour carte à puce.
Les applications pour carte à puce sont des programmes qui reçoivent des séquences d'octets en entrée et qui produisent des séquences d'octets en sortie. Une séquence d'octet en entrée représente généralement une commande (commande APDU, « Application Protocol Data Unit ») que le programme doit exécuter. Selon la norme ISO 7816, les deux premiers octets de cette séquence, l'octet de classe « CLA » et l'octet d'instruction « INS », identifient la commande et son niveau de sécurité, et les octets suivants représentent les arguments de cette commande.
Dans le cas d'applications écrites en langage « Java Card » (une version du langage « Java » spécialisée pour la carte à puce), une séquence d'octets en entrée se traduit par l'appel de la méthode « Applet.process » avec en argument un objet permettant d'accéder à un tableau d'octets, le « buffer APDU ». (« Java » et « Java Card » sont des marques déposées de Sun Microsystems.)
En voici un exemple. (Pour des raisons de lisibilité, les préfixes de classe pour l'appel de méthode et l'accès aux champs sont volontairement omis quand ils ne sont pas ambigus.) void process(APDU apdu) { byte[] buf = apdu.getBuffer(); byte cla ≈ buf[O]; byte ins = buf[l]; switch(cla) { case 0: // Pas de mesure sécuritaire switch(ins) { case (byte) 202: // GET DATA
break; default: throwIt(SW_INS_NOT_SUPPORTED);
} break; case (byte) 132: // Mesure de sécurité propriétaire switch(ins) { case (byte) 218: // PUT DATA
break; default: throwIt(SW_INS_NOT_SUPPORTED);
} break; default: throwIt(SW_CLA_NOT_SUPPORTED);
}
}
La spécification de l'application peut par exemple stipuler d'une part que les deux seules commandes acceptées par l'application, c'est-à-dire ne se traduisant pas systématiquement par la levée d'une exception, sont une version non sécuritaire de la commande « GET DATA » (avec CLA = 0 et INS = 202) et une version sécuritaire propriétaire de la commande « PUT DATA » (avec CLA= 132 et INS = 218) et d'autre part que toute commande qui n'est pas acceptée doit être refusée par la levée d'une exception ISO avec comme statut « SW_CLA_NOT_SUPPORTED » ou « SW_INS_NOT_SUPPORTED ».
Le fragment de programme ci-dessus est correct par rapport à ces deux aspects de la spécification : toute configuration d'octets autre que « CLA = 0 et INS = 202 » ou « CLA = 132 et INS = 218 » conduit à une levée d'exception ISO systématique.
Alors que le contrôle de correction est directement dirigé par la donnée de la spécification, qui a aussi dirigé la réalisation du programme, le contrôle de validité est gouverné par la définition a priori d'une politique, applicable à un ensemble de programmes et définie comme un ensemble de critères à remplir ou de règles à satisfaire.
Des critères de sécurité peuvent par exemple être issus d'une analyse de risque préalable, qui évalue notamment les biens à protéger sur la plate-forme et dans les programmes, les menaces à rencontre de ces biens, et les mesures à prendre pour s'en prémunir. Des critères d'interopérabilité peuvent être tirés des spécifications techniques des différents plates-formes d'exécution, des cas d'erreur signalés par les équipes de test et les utilisateurs, de l'expérience de bonne programmation des développeurs, etc.
Par exemple, dans le cas d'application pour cartes à puce, un critère sécuritaire "CS- DESKeyStrength" peut stipuler qu'il est interdit d'utiliser des clés « DES » trop faibles, par exemple d'une longueur inférieure à 128 bits. De même, un critère d'interopérabilité pourrait par exemple stipuler de ne pas utiliser de clé « RSA » (par exemple parce la plate-forme cible ne permet pas de manipuler ce type de clé), ou bien pas de clé « RSA » de longueur supérieure à 1024 bits (par exemple parce que la plate-forme cible ne permet pas de manipuler des clés d'une telle taille).
Pour pouvoir être vérifiés de manière non ambiguë, les critères doivent être clairement formulés. Un critère s'exprime souvent sous forme de contraintes concernant l'usage de routines ou de classes de librairies. Dans le cas d'applications « Java Card », l'exemple de critère sécuritaire "CS-DESKeyStrength" ci-dessus s'exprimer de manière plus explicite de la manière suivante : La méthode « buildKey(keyType, keyLength, ...) » n'est pas appelée avec un argument « keyLength » inférieur à 128 si l'argument « keyType » est égal à la valeur de la constante « TYPEJ)ES ».
Le fragment de programme suivant satisfait le critère sécuritaire CS-
DESKeyStrength : void install(byte[] buf, short off, short len) {
switch(buf[offj) { case 1 : // Use DES 128 bits key = buildKey(TYPE_DES, LENGTH_DES3_2KEY); break; case 2: // Use DES 192 bits key = buildKey(TYPE_DES, LENGTH_DES3_3KEY); break; case 3: // Use RSA 1024 bits key = buildKey(TYPE_RSA_PRIVATE, LENGTH_RSA_1024); break; }
}
En effet, quels que soient les chemins d'exécution, la méthode « buildKey » est toujours appelée avec des arguments compatibles avec le critère : ou bien
« keyType » vaut « TYPE_DES » et « keyLength » vaut
« LENGTH_DES3_2KEY » (égal à 128) ou « LENGTH_DES3_3KEY » (égal à
196), ou bien « keyType » vaut « TYPE_RSA_PRTVATE » (différent de
« TYPE_DES »).
En revanche, le fragment de programme suivant ne satisfait pas le critère CS-
DESKeyStrength : void install(byte[] buf, short off, short len) {
key = buildKey(buf[off], getShort(buf, off+1));
}
En effet, les valeurs « buf», « off » et « len » sont des arguments dynamiques fournis à la méthode « install ». (Le tableau « buf » contient la séquence d'octets transmise à la carte, et « off» et « len » déterminent le segment correspondant dans « buf ».) Il est donc possible de construire des clés de type et de longueur arbitraire. En particulier, il est donc possible que « buf[offj » (l'octet stocké à l'index « off» du tableau « buf ») soit égal à « TYPE_DES » et que « getShortφuf, off+1) » (l'entier court stocké aux index « off+1 » et « off+2 » du tableau « buf») soit inférieur à 128.
Toutefois, il peut arriver qu'une application ne s'exécute que dans un contexte particulier. Par exemple, le cycle de vie d'une application pour carte à puce commence habituellement par une phase de chargement sur la carte, d'installation et de personnalisation, phases qui sont généralement effectuées sous le contrôle de l'institution qui émet la carte ou sous le contrôle du fournisseur d'application. Les interactions avec l'application lors de ces phases ne sont pas quelconques.
En particulier, si des clés « DES » doivent être créées comme avec l'exemple de la méthode « install » ci-dessus, il peut être garanti par l'institution qui émet la carte ou le fournisseur d'application que la taille de la clé passée en argument de la commande « install » (l'entier court stocké aux index « off+2 » et « off+3 » du tableau « buf ») sera toujours supérieur ou égal à 128.
Ainsi, même si l'application ne satisfait pas le critère sécuritaire au sens strict (c'est- à-dire pour toute exécution possible, notamment pour toute entrée fournie au programme), le critère est néanmoins satisfait en pratique (c'est-à-dire pour une classe d'exécutions donnée, notamment pour une classe donnée d'entrées). Pour un contexte d'exécution donné, les « entrées légales » sont les entrées compatibles avec ledit contexte, et une « exécution légale » de l'application est une exécution sur des entrées légales. Avant d'établir un jugement sur la satisfaction ou la transgression d'un critère de validité, il importe donc de définir le contexte d'exécution considéré et notamment la classe des entrées légales de l'application dans ce contexte, par exemple : toute entrée possible de l'application, arguments avec une valeur fixée ou dans un intervalle de valeurs fixé, etc. La situation est identique pour le cas du contrôle de correction : la vérification de l'adéquation à une spécification peut ne porter que sur des contextes d'exécution particuliers, notamment des classes d'entrées particulières, données par le(s) cadre(s) d'utilisation de l'application.
Pour ce faire, il peut aussi être important de séparer les différentes origines des entrées d'une même application : utilisateur, opérateur télécom, fournisseur de contenu, etc. Suivant les circonstances et les critères, on peut alors distinguer les entrées d'acteurs de confiance et les entrées d'acteurs à risque.
II existe nombre de critères similaires au critère "CS-DESKeyStrength" dans le cas de programmes "Java" pour téléphones mobiles exploitant l'interface logicielle « MIDP » (Mobile Information Device Profile). Par exemple, un critère d'ordre sécuritaire "CS-NoSMSInLoop" peut interdire l'envoi de SMS (texto) à l'intérieur d'une boucle de programmation (construction itérative ou récursive) pour éviter un nombre d'envois inconsidéré et sans doute injustifié.
Ainsi, le fragment de programme suivant transgresse-t-il le critère sécuritaire : void expensiveLoop() { String address = "sms://+33687654321"; smsconn = (MessageConnection) Connector.open(address); srrisconn.newMessage(MessageConnection.TEXT_MESSAGE); for (int i = 0 ; i < 1000 ; i++) sendMesg(smsconn); smsconn. close();
} void sendMesg(MessageConnection smsconn) { txtmesg.setPayloadText(" Je suis un parasite qui coûte cher"); smsconn.send(txtmesg); } Un autre critère sécuritaire "CS-NoSMS Surtax" peut interdire l'usage de SMS surtaxés, c'est-à-dire pour lequel le consommateur sera facturé en plus du prix d'un simple SMS. Par exemple, actuellement en France, les numéros de SMS de la forme « 3xxxx » (où chaque « x » est un chiffre quelconque) ne sont pas surtaxés, ceux de la forme « 4xxxx » sont surtaxés de 5 centimes d'euro, ceux de la forme « Ixxxx » sont surtaxés de 50 centimes d'euro.
Ainsi, le fragment de programme suivant transgresse-t-il le critère sécuritaire : void surtax() {
String address = "sms://34589"; if (pirateMode) address = address.replace('3',7'); smsconn = (MessageConnection) Connector.open(address); smsconn.newMessage(MessageConnection.TEXT_MESSAGE); smsconn. send(txtmesg) ; smsconn.close(); }
Les contrôles de correction et de validité ne concernent pas nécessairement des propriétés booléennes strictes qui peuvent uniquement être vraies ou fausses, comme par exemple l'égalité entre deux valeurs.
Par exemple, il peut être important de savoir combien d'octets une application pour carte à puce consomme en terme d'allocations dynamiques de mémoire persistante
(respectivement temporaire) avant de la charger dans une carte déjà bien pleine
(respectivement disposant de peu de mémoire vive). La validité dans ce cas est caractérisée par le nombre d'octets alloués. Suivant le contexte d'utilisation, ce nombre pourra se révéler être inférieur ou supérieur à certains seuils, déterminant ainsi la validité dans le contexte particulier.
De même, il peut importer de savoir quelles commandes sont acceptées ou non par une application pour carte à puce (quelles combinaisons d'octets CLA et INS ne conduisent pas à une levée d'exception). Outre les questions de correction, dans le cas où certaines commandes sont optionnelles dans la spécification, cela permet aussi de savoir ce qu'une implémentation particulière permet ou non. C'est ensuite qu'un jugement sur le respect d'une spécification ou d'un critère de sécurité peut être produit.
En fait, un programme peut correspondre plus ou moins bien (à différents degrés) à ce qui est stipulé dans sa spécification, et ce n'est qu'étant donné un contexte particulier que l'implémentation peut être considérée comme correcte ou non, avec différents degré et niveau de confiance. De même, un programme peut satisfaire plus ou moins bien différents critères de validité, et ce n'est aussi qu'étant donné un contexte particulier que l'implémentation peut être considérée comme valide ou non, à tel degré et avec tel niveau de confiance.
C'est donc plus généralement des caractéristiques opérationnelles arbitraires du programme qu'il importe d'évaluer et non simplement des propriétés booléennes.
Une caractéristique opérationnelle d'un programme est une valeur (plus ou moins complexe) associée à l'exécution du programme, comme par exemple la consommation mémoire, le temps d'exécution, la liste des routines du système appelées durant l'exécution du programme ainsi que les valeurs correspondantes des arguments, etc. Les caractéristiques opérationnelles incluent également les statuts de contrôles, notamment de correction et de validité, qui jugent si le comportement d'un programme correspond bien celui stipulé dans une spécification ou si le programme satisfait bien des critères de validité.
On peut noter que l'évaluation d'une caractéristique opérationnelle peut souvent être vue comme le résultat d'une combinaison de fragments d'évaluation plus élémentaires. Par exemple, la consommation mémoire peut être construite à partir d'une opération de combinaison qui est la fonction somme, et de fragments d'évaluation qui sont les nombres d'octets demandés en cours d'exécution, aux divers sites d'allocation mémoire. De même, un contrôle peut s'exprimer à l'aide d'une opération de combinaison qui est la conjonction logique ainsi que de fragments d'évaluation qui sont la vérification de conditions logiques qui doivent toutes être vraies pour que le contrôle ne décèle pas d'anomalie. Une caractéristique opérationnelle d'un programme, et notamment un critère de validité, peut porter ou non sur une localisation particulière de l'exécution du programme. Par exemple, le critère "CS-DESKeyStrength" s'exprime uniformément sur tout le programme et n'est pas lié à une zone de code particulière, pas plus que ne l'est un contrôle de correction effectué sur une sortie du programme. En revanche, le critère "CS-NoSMSInLoop" contrôle le type de zone de programme où peut se produire un envoi de SMS. Par ailleurs, la transgression d'un critère se produit généralement en des lieux précis du programme ou de l'exécution.
La terminologie suivante sera adoptée pour désigner les divers types de localisation et d'instants liés à l'exécution d'un programme :
• Un point de programme est une adresse dans le code du programme, généralement d'une instruction ou d'une opération exécutable. • Un chemin d'exécution représente une suite finie ou infinie de points de programme successifs dans une même exécution du programme. Dans le cas d'un programme avec des boucles, un chemin d'exécution peut comporter plusieurs fois (possiblement une infinité de fois) le même point de programme. Une classe de chemins d'exécution peut être représentée par un sous-graphe du graphe de flot de contrôle et/ou d'appel du programme, une grammaire, un système de transition, une expression de logique temporelle ayant comme état de base les points de programme, etc.
• Un point d'exécution représente un instant dans l'exécution d'un programme, généralement un instant déterminé par un point de programme courant donné et/ou une condition pourtant sur l'état courant du programme et/ou sur l'historique de l'exécution.
• Un point d'exécution représente un instant dans l'exécution d'un programme. À un point d'exécution correspond un point de programme courant, ainsi qu'un chemin d'exécution depuis le point de lancement du programme jusqu'au point de programme courant. Par ailleurs, l'exécution d'un programme est ponctuée par l'occurrence d'événements, intérieurs ou extérieurs au programme, qui peuvent être pertinents ou non pour la détermination des caractéristiques opérationnelles du programme.
Les événements matériels, comme l'appui sur une touche du clavier par l'utilisateur ou l'arrivée d'un appel sur un téléphone mobile, se traduisent en des événements logiciels après traitement par la plate-forme d'exécution et traversée éventuelle des couches du système d'exécution.
Les événements logiciels peuvent notamment être des événements simples, localisés, qualifiés et/ou composés :
• Les événements simples comprennent notamment : l'exécution de certaines instructions ou opérations, les appels du programme aux routines du système d'exécution, les appels du système d'exécution aux routines du programme, les interruptions du programme et/ou du système d'exécution, la levée d'une exception, le rattrapage d'une exception, les changements d'état du programme et/ou du système d'exécution, les variations de disponibilité des ressources du système d'exécution, les marques de temps passé dans l'exécution du programme (temps total et/ou temps détaillé pour les diverses opérations effectuées), etc. • Les événements localisés sont des événements se produisant en des lieux particuliers du programme et/ou lors de l'entrée en des lieux particuliers et/ou lors de la sortie de lieux particuliers. Un lieu particulier peut être par exemple un point de programme, un chemin d'exécution, une routine, une boucle de programmation (itérative et/ou récursive), un code de rattrapage d'exception ou d'interruption, etc.
• Les événements qualifiés consistent en des événements portant sur des valeurs ou des classes de valeurs particulières : paramètres des instructions ou opérations, routines appelées, arguments des routines, type d'une exception levée ou rattrapée, état du programme et/ou du système, état de disponibilité des ressources du système d'exécution, valeur du temps passé dans l'exécution du programme (temps total et/ou temps détaillé pour les diverses opérations effectuées), etc. • Les événements composés consistent en des combinaisons d'événements permettant notamment d'exprimer l'historique de l'exécution via la succession d'événements, par exemple le fait que l'appel d'une certaine routine se produise uniquement après l'appel d'une autre.
Un événement qualifié typique est l'appel d'une routine donnée avec des arguments de valeur donnée ou à l'intérieur d'intervalles de valeurs donnés.
Habituellement, les critères tels que, par exemple, les critères de validité, sont exprimés sous la forme de règles.
À titre d'exemple non limitatif, on considère le cas particulier où les caractéristiques opérationnelles à évaluer sont des règles à vérifier. Chacune de ces règles est ici définie comme une relation entre l'occurrence d'un événement et un ensemble de vérifications : quand l'événement E se produit, les conditions Ci, ..., CN doivent être remplies. On note une telle règle R = « si E alors Ci et ... et CN ».
Une règle est satisfaite si sa valeur logique est vraie. Elle est transgressée si sa valeur logique est fausse. Elle est indéterminée (ou irrésolue) si sa valeur logique est indéterminée.
On peut remarquer que cette formulation permet aussi d'exprimer qu'un événement E ne doit jamais se produire : une telle règle peut se traduire par « si E alors C » avec C - faux. En effet, si l'événement E se produit, alors la condition C est toujours fausse, donc la règle est considérée comme transgressée.
Les conditions Cy, ..., CN peuvent notamment porter sur la nature de l'événement E, mais aussi sur les valeurs manipulées par le programme et/ou le système d'exécution au moment où se produit l'événement, sur le flot de contrôle du programme (par exemple, la présence du point d'exécution à l'intérieur d'une boucle de programmation), sur le lieu particulier du programme où se produit l'événement (par exemple, points de programme ou routines donnés), etc. Les critères de validité donnés en exemple ci-dessus sont des cas particuliers de tels règles. Le critère "CS-DESKeyStrength" de longueur minimale de clé DES peut s'exprimer ainsi : si la méthode « buildKey » est appelée avec comme premier argument « TYPE-DES » alors le second argument doit être supérieur ou égal à 128. Le critère "CS-NoSMSInLoop" de non-envoi de SMS en boucle peut s'exprimer ainsi : si la méthode « MessageConnection.send » est appelée, alors le point d'appel ne doit pas être à l'intérieur d'une boucle de programmation. En restreignant le champ des numéros de SMS possibles, le critère "CS-NoSMSSurtax" de non-envoi de SMS surtaxé peut s'exprimer ainsi : si la méthode « Connector.open » est appelée avec un argument commençant par "sms://", alors cet argument doit être de la forme "sms://3xx;α".
Il faut noter que les conditions n'ont pas nécessairement à être liées à des éléments ou des propriétés calculables. Par exemple, elles peuvent porter sur des principes d'éthique et de déontologie (pas de message à caractère sexuel, raciste, etc.), qui ne peuvent être contrôlés que par un être humain et non par une machine. Il en va de même de la plupart des conditions portant sur l'affichage, comme par exemple le « Look and Feel ». Ce type de condition n'est pas vérifiable automatiquement ; il requiert l'avis d'un opérateur humain.
Dans le cas où ces règles représentent un contrôle de validité, on cherche à attribuer à un programme l'une des propriétés suivantes (exclusives les unes des autres) :
(1) II est certain que le programme est valide.
(2) II est vraisemblable que le programme soit valide. (3) II est possible, mais pas certain, que le programme soit valide.
(4) II est certain que le programme est invalide.
Dans tous les cas, et notamment dans les cas (3) et (4), on souhaite en outre obtenir le maximum d'informations sur les règles (qu'elles soient satisfaites, transgressées ou de statut indéterminé), ainsi que sur les circonstances : point d'exécution, état du programme, entrées légales compatibles avec l'exécution correspondante, etc. Dans le cas où la vraisemblance de validité n'est pas davantage prisée que la simple possibilité de validité, la catégorie (2) peut être considérée comme incluse dans la catégorie (3).
En ce qui concerne le contrôle effectif d'un programme, l'état de l'art peut se résumer comme suit :
Pour déterminer si un programme donné implémente correctement une spécification donnée (contrôle de correction) ou satisfait des critères de validité donnés pour une plate-forme d'exécution donnée (contrôle de validité), plusieurs approches sont aujourd'hui employées. Elles se distinguent selon divers aspects :
• le contrôle est statique (avant l'exécution sur la plate-forme) ou dynamique (pendant l'exécution) ;
• le contrôle est « boîte noire » (sans regarder le code, en n'observant que les réactions aux entrées) ou « boîte blanche » (en regardant le code et/ou l'état interne du programme en cours d'exécution) ;
• le contrôle est « manuel » (effectué par un humain) ou automatique (effectué par un outil de décision).
Il y a bien entendu des situations intermédiaires, entre les différents « pôles » ci- dessus. Par exemple, un contrôle peut être « semi-automatique » (avec intervention humaine et aide d'outils de décision). De même, le contrôle peut être « boîte grise » dans le cas où seule une partie de l'état de l'exécution du programme est observable.
Les contrôles couramment employés sont les suivants : • Les critères, notamment sécuritaires, peuvent être mis en oeuvre par des contrôles dynamiques effectués au cours de l'exécution du programme. Cette approche a trois désavantages majeurs. Tout d'abord, elle découvre les problèmes trop tard, une fois le programme déjà chargé et en cours d'exécution. Ensuite, parce qu'elle n'a qu'une vision « boîte noire » de l'application, elle nécessite de borner arbitrairement l'exploitation des fonctionnalités et ressources de la plate-forme
(par exemple, pas d'envoi de plus de trois messages). Enfin, elle ne résout pas les problèmes d'interopérabilité et elle ne permet pas non plus de vérifier la correction d'un programme. • Le programme peut être contrôlé manuellement, avant son exécution sur la plateforme cible, en regardant le code mais sans l'aide d'un outil d'analyse. Cette solution de test en « boîte blanche » (avec accès au code) a de nombreux désavantages. Un tel contrôle est en effet long (donc coûteux) et fastidieux, ce qui interdit en pratique le traitement de gros volumes de programmes. Il n'est pas non plus systématique dans le sens où une erreur ou une transgression peuvent passer inaperçues à l'œil de l'examinateur humain. Par ailleurs, il faut repayer le coût du contrôle à chaque nouvelle version du programme, de la spécification, de la plate-forme d'exécution ou des critères. En outre, cette approche suppose en pratique que le code source du programme est disponible, ce qui est peu souvent le cas pour des raisons de confidentialité ou de propriété industrielle. Lorsque seul le code objet est disponible, l'analyse manuelle devient extrêmement longue et difficile, et le risque d'une erreur humaine est multiplié d'autant.
• Le programme peut aussi être testé en « boîte noire » ou « boîte grise », sans accéder au code pour l'analyser, uniquement en réaction à des stimuli. Avec cette approche, le programme est exécuté dans un certain nombre de circonstances supposées représentatives, et son comportement est observé de l'extérieur (ou en partie de l'intérieur dans le cas de la boîte grise) pour juger s'il correspond au comportement attendu et/ou s'il respecte les critères fixés. • Le programme peut aussi être contrôlé automatiquement, à l'aide d'un outil d'analyse, à condition bien entendu que les contrôles soient automatisables. Plusieurs types d'outil existent aujourd'hui :
- Certains outils vérifient à l'aide d'une analyse statique que le code d'un programme respecte des règles générales de bonne formation et de bon typage, ce qui apporte certaines garanties de bon fonctionnement de base, quelle que soit la plate-forme cible. C'est par exemple le cas des vérificateurs de code pour machines virtuelles (« bytecode verifiers ») associés aux environnements d'exécution « Java » (y compris « Java Card »). De tels analyseurs de types peuvent fonctionner aussi bien sur le code source que sur le code objet. Ils ne répondent toutefois pas à des critères particuliers, concernant par exemple la sécurité ou l'interopérabilité.
- D'autres outils, encore rares et surtout destinés aux développeurs, vérifient à l'aide d'une analyse statique que le code d'un programme ne peut pas effectuer d'opérations qui n'ont pas de sens, comme de déréférencer un pointeur nul ou accéder à un élément de tableau hors des limites. Ces outils apportent ainsi certaines garanties de bon fonctionnement, quelle que soit la plate-forme cible. Mais comme pour les analyseurs de type, ils ne répondent pas à des critères particuliers. - Certains outils examinent le code du programme, source ou objet, pour rechercher des occurrences d'appels de routines. Ils permettent ainsi d'appliquer des critères spécifiques qui interdisent l'usage de certaines routines (que ce soit pour des raisons de sécurité ou d'interopérabilité) : ils rejettent tout programme qui comportent des appels à des routines interdites. Cependant, de tels outils ne peuvent pas non plus vérifier le genre de règle mentionné ci-dessus. Par exemple, pour le critère CS-DESKeyStrength, il faut non seulement détecter que la méthode « buildKey » est appelée mais aussi savoir si son premier argument est égal à « TYPE_DES » et son deuxième argument inférieur à 128. - Enfin, il existe un petit nombre d'outils qui effectuent des analyses statique poussées du code du programme (analyse de flot de contrôle, analyse de flot de données, etc.) pour chercher à vérifier toute une gamme de règles, notamment liées à la sécurité et l'interopérabilité. De tels outils sont par exemple capables de traiter le critère "CS-DESKeyStrength" en déterminant la valeur des arguments avec lesquels la méthode « buildKey » est appelée.
Dans les paragraphes qui suivent sont davantage détaillées les deux techniques sur lesquelles s'appuie l'invention : l'analyse statique et le test.
Encore peu utilisée, l'analyse statique est une approche récente et prometteuse pour le contrôle d'applications, et plus généralement pour la détermination des caractéristiques opérationnelles d'un programme.
Ainsi, le brevet français No 03 15544, déposé le 30 décembre 2003 au nom de la Demanderesse, fournit un procédé de détermination des caractéristiques opérationnelles d'un programme, basé sur des techniques d'analyse statique. Ces techniques d'analyse statique sont nombreuses : interprétation abstraite, analyses de flot de contrôle, analyses de flots de données, vérification de modèle (« model checking »), preuves formelles, etc.
L'analyse statique d'un programme permet notamment de déterminer :
• le flot de contrôle, c'est-à-dire une représentation des chemins d'exécutions possibles du programme,
• le flot de données, c'est-à-dire les valeurs de variables, registres, mémoires, expressions et états du programme en divers points d'un chemin d'exécution.
Les informations issues d'une analyse statique peuvent permettent de déduire certaines caractéristiques opérationnelles d'un programme, comme par exemple la consommation mémoire ou le temps d'exécution, et notamment d'effectuer des contrôles de validité. Mais l'analyse statique permet aussi dans certains cas d'effectuer certains contrôles de correction.
Par exemple, les commandes auxquelles peut répondre une application « Java Card » peuvent être déterminées en explorant tous les chemins d'exécution qui partent de la méthode « Applet.process », en examinant toutes les opérations de comparaison portant sur le premier octet (octet de classe « CLA ») et le deuxième octet (octet d'instruction « INS ») du tableau d'octets constituant le « buffer APDU », et en observant les statuts de retours des commandes (exécution normale ou erreur). Les commandes acceptées par l'application correspondent aux valeurs des premiers et seconds octets pour lequel le programme ne lève pas d'exception. L'implémentation est correcte en ce qui concerne les commandes acceptées si les valeurs déterminées par l'analyse statique sont égales aux valeurs indiquées dans la spécification.
Un autre exemple est la vérification que certaines actions ne se produisent pas, en particulier que certaines données sensibles, comme par exemple un code PIN (Personal Identification Number), ne sont manipulées que dans les circonstances prévues par la spécification. Ainsi, si une commande d'une application « Java Card » n'est pas censée avoir d'impact sur le PIN, comme par exemple une commande de type « GET DATA », une analyse statique peut explorer tous les chemins d'exécution qui partent de la reconnaissance de cette commande et vérifier qu'aucun d'entre eux n'affecte un objet PIN (y compris son statut de vérification et son compteur d'essais infructueux successifs).
Néanmoins, une analyse statique ne permet pas toujours de déterminer avec précision toute caractéristique opérationnelle d'un programme. Cela peut être imputable à une combinaison de divers facteurs : difficulté ou impossibilité d'automatiser l'évaluation de la caractéristique opérationnelle (par exemple pour les questions d'ergonomie, d'éthique ou de déontologie), comportement variable selon les entrées du programme, manque de précision de l'analyse statique, complexité intrinsèque du programme, etc.
Par exemple, la spécification d'une application "Java Card" respectant la norme ISO 7816 peut stipuler que la commande « GET DATA » (dont l'octet INS est égal à 202) ne met pas en œuvre de mesure sécuritaire (l'octet CLA est égal à 0) et que la commande « PUT DATA » (dont l'octet INS est égal à 218) met en œuvre une mesure de sécurité propriétaire (l'octet CLA est égal à 132). Il est possible qu'une analyse parvienne uniquement à établir que le fait que l'application accepte des commandes dont l'octet de classe CLA est égal à 0 ou 132, et dont l'octet d'instruction INS est égal à 202 ou 218. Autrement dit, l'analyse ne réussit pas à déterminer que les seules combinaisons acceptées par l'application sont (CLA=O, INS=202) et (CLA=128, INS=218), excluant les cas (CLA=O, INS=218) et (CLA=128, INS=202). Dans cette circonstance, il n'est pas possible de déterminer avec certitude la correction de l'application.
De même, une analyse peut déterminer simplement que le deuxième argument de la méthode « buildKey » est compris entre 96 et 192, sans plus de précision. Dans ce cas, il n'est pas possible d'établir avec certitude si le critère sécuritaire de longueur de clé mentionné ci-dessus (longueur au moins égale à 128) est satisfait ou transgressé.
Semblablement, une analyse peut diagnostiquer que l'argument de la méthode « Connecter. open » est une chaîne de caractère qui commence par "sms://", sans pouvoir toutefois déterminer les caractères suivants, par exemple parce qu'ils sont le résultat d'un calcul compliqué ou parce qu'ils dépendent de valeurs entrées par l'utilisateur. Dans ce cas, il n'est pas possible d'établir avec certitude si le critère sécuritaire "CS-NoSMSSurtax" mentionné ci-dessus concernant la non surtaxe des SMS (uniquement des numéros de la forme « 3xxxx ») est satisfait ou transgressé.
De fait, il n'est pas toujours possible d'effectuer avec certitude un contrôle de correction ou de validité.
L'interprétation des résultats d'une analyse statique pour un contrôle de correction (respectivement de validité) admet de ce fait trois cas possibles (exclusifs les uns des autres) : • Le programme est correct (respectivement valide) avec certitude.
• L'analyse statique ne permet pas de déterminer avec certitude si le programme est correct (respectivement valide) ou non.
• Le programme est incorrect (respectivement invalide) avec certitude.
Même dans le cas incertain, une analyse de programme peut toutefois fournir des informations pertinentes pour aider au diagnostic : localisation de l'infraction potentielle, état approché du programme et/ou du chemin d'exécution du programme, etc. Ces informations sont également utiles dans le cas où le programme est incorrect (respectivement invalide) avec certitude, afin de savoir où et éventuellement comment le corriger.
Outre la possibilité de fournir des garanties fortes de correction (respectivement de validité), un des avantages importants de l'analyse statique est son faible coût car elle est généralement totalement automatisée.
Le test est une toute autre approche. C'est la solution la plus couramment employée, tant pour le contrôle de correction que pour le contrôle de validité.
Un test comprend un scénario d'interactions avec le programme ainsi que des évaluations de caractéristiques opérationnelles, basées sur le comportement observé du programme.
Les interactions comprennent des entrées à soumettre au programme (données d'entrées fournies et actions effectuées y compris interruptions, variations de disponibilité des ressources, marques de temps, etc.) et des sorties produites (données de sorties et actions produites). Certaines entrées peuvent parvenir au programme via le système d'exécution (système d'exploitation, machine virtuelle, interface logicielle, etc.) au dessus duquel s'exécute le programme, par exemple sous forme d'appel à des routines du programme ou sous forme de valeurs de retour fournies aux routines du système appelées par le programme. Il en va de même pour les sorties du programme, qui peuvent transiter via le système d'exécution.
Les évaluations de caractéristiques opérationnelles sont des traitements qui portent sur les entrées fournies au programme et sur les sorties produites. Par exemple, l'exécution sur un simulateur des commandes d'installation et de personnalisation d'une application pour carte à puce se traduit par l'exécution d'opérations d'allocation mémoire ; plusieurs exécutions de ce type, avec des valeurs représentatives d'un certain contexte d'utilisation, permettent d'évaluer de manière approximative la consommation mémoire de l'application.
Un cas particulier important est le test en vue d'un contrôle de correction (respectivement de validité). Dans ce cas, les sorties produites sont comparées à des sorties possibles attendues. Si les sorties produites diffèrent (ou diffèrent trop) des sorties attendues, alors le programme est considéré incorrect (respectivement invalide). Sinon, il peut être jugé vraisemblablement correct (respectivement valide).
Le scénario du test comprend également des conditions d'arrêt, par exemple : exhaustion des comportements à observer, nombre d'erreurs ou de transgressions dépassant un certain seuil, temps passé dans l'exécution du test (ce qui a un impact sur le coût de revient du passage du test, notamment en la présence d'un opérateur de test), etc.
Certains scénarios peuvent être assez peu précis. Par exemple, dans le cas de la vérification de critères de validité sur téléphones mobiles, un scénario peut simplement stipuler de parcourir « autant que possible » les différents écrans de l'application afin de vérifier les textes affichés sont écrits dans la langue cible et ne sont pas tronqués. On peut laisser par exemple une heure au maximum à un opérateur de test pour effectuer simultanément plusieurs contrôles de ce type. Il n'y a pas dans ce cas garantie de résultat mais garantie d'effort, la qualité du statut final dépendant beaucoup de l'opérateur de test.
Plusieurs tests sont généralement nécessaires pour approcher une caractéristique opérationnelle, ou pour émettre un jugement de correction ou de validité. Ces tests sont regroupés dans une suite de tests.
Inversement, on peut n'effectuer qu'une fraction d'un test donné. On peut par exemple ne pas pratiquer certaines évaluations spécifiées dans le scénario de test. On peut aussi omettre (sauter) certaines interactions lorsqu'on sait ou que l'on fait l'hypothèse qu'elles n'ont pas d'influence sur les futures évaluations à effectuer. En particulier, on peut interrompre un test avant sa terminaison ordinaire.
Pour effectuer un test, le programme est exécuté à l'aide du dispositif d'exécution d'une plate-forme de test. Ce dispositif d'exécution peut être basé sur la plate-forme d'exécution cible du programme ou sur toute plate-forme d'exécution équivalente : simulateur, émulateur, etc.
Une plate-forme de test peut avoir à être configurée par rapport aux plates-formes d'exécution cibles ainsi que par rapport au contexte et à l'environnement d'exécution visés.
En fonction des tests, la plate-forme de test peut avoir à offrir au programme un environnement d'exécution plus ou moins complet. Par exemple, pour tester une application pour téléphone mobile, il peut être nécessaire de disposer du réseau d'un opérateur téléphonique (simulé si nécessaire), d'un serveur opérationnel chez le fournisseur de contenu, etc.
Certains dispositifs d'exécution peuvent aussi disposer de facilités d'introspection afin de fournir, outre les sorties régulières du programme, des informations concernant les états et les actions internes en cours d'exécution. Ces informations peuvent être fournies par la plate-forme de manière passive (au cours de l'exécution, la plate-forme signale des événements et changements d'états) ou active (en cours d'exécution, la plate-forme peut-être interrogée sur son état). Certains dispositifs d'exécution peuvent également fournir des moyens d'agir sur l'exécution. C'est notamment le cas lorsqu'ils comprennent un débogueur ou les fonctionnalités d'un débogueur. Il est alors notamment possible d'interrompre temporairement l'exécution, en particulier à la suite de la pose de points d'arrêt (en certains points de programme, à l'entrée de certaines routines, etc.).
Seules les plates-formes destinées au test disposent généralement de facilités d'introspection et d'action sur l'exécution. Les plates-formes cibles (carte à puce, téléphones mobiles, etc.) en général ne permettent ni introspection ni action pour des diverses raisons : sécurité, robustesse, design, etc.
Toutefois, même si la plate-forme de test ne comporte pas de moyens d'introspection ou d'action sur l'exécution, il peut être possible de disposer de telles fonctionnalités en instrumentant le programme.
En particulier, si des tests ne peuvent produire certaines informations avec suffisamment de précision ou s'ils ne les produisent que difficilement, le programme peut être instrumenté avant exécution pour rendre ces informations plus facilement accessibles ou accessibles avec une meilleure précision.
Plus précisément, le programme peut être instrumenté pour produire, outre ses sorties originelles, des sorties supplémentaires qui fournissent des informations sur son état et ses actions internes. L'instrumentation peut être telle que ces sorties supplémentaires sont produites de façon spontanée lors de l'exécution du programme ou bien produites en réponse à des entrées particulières du programme. Lesdites entrées particulières peuvent être des entrées originelles du programme et/ou des entrées supplémentaires introduites explicitement par l'instrumentation afin d'interroger le programme et/ou le système d'exécution sur leur état et/ou leurs actions.
Par exemple, une application pour carte à puce peut être instrumentée pour d'une part comptabiliser le nombre d'octets alloués depuis le début de l'exécution et d'autre part accepter une commande supplémentaire (ou un paramètre supplémentaire à une commande existante, par exemple de type « GET DATA ») qui retourne cette valeur.
Le programme peut aussi être instrumenté pour agir sur son exécution, notamment pour l'interrompre temporairement (par exemple en l'attente d'une entrée particulière). Cela permet en particulier d'offrir des contrôles sur l'exécution quand la plate-forme d'exécution n'en dispose pas. On peut par exemple ainsi simuler certaines fonctionnalités de débogueurs, comme la pose de point d'arrêt à certains point de programme, à l'entrée de certaines routines, etc.
Le programme peut également être instrumenté pour, outre ses effets originels, effectuer dynamiquement l'évaluation de certaines des caractéristiques opérationnelles recherchées et produire le résultat de cette évaluation en tant que sortie supplémentaire. Dans le cas particulier où les caractéristiques opérationnelles à évaluer comprennent des contrôles à effectuer ou des règles à vérifier, le programme peut être instrumenté pour, outre ses effets originels, effectuer dynamiquement le contrôle ou vérifier dynamiquement la règle et produire un statut de ce contrôle ou de cette vérification (satisfaction ou transgression).
Par exemple, dans le cas d'une application pour téléphone mobile, si seuls sont autorisés les envois de SMS à des numéros qui ne sont pas surtaxés (voir le critère "CS-NoSMSSurtax" ci-dessus), l'instrumentation peut faire précéder toutes les occurrences d'appels à la méthode « Connector.open » d'un test sur la chaîne de caractères donnée en argument de cette méthode pour vérifier que si elle débute par "sms://", alors elle n'est pas suivie d'un numéro surtaxé, par exemple de la forme "Ixxxx".
Par ailleurs, l'instrumentation peut être manuelle et/ou automatique. Une instrumentation automatique peut notamment consister à reconnaître des motifs (« patterns ») de code particuliers et à les modifier de façon systématique. Par exemple, dans le cas d'une application « Java Card », on peut identifier toutes les occurrences d'instructions d'allocation (de type « new ») ainsi que toutes les occurrences d'appels à des méthodes d'allocation d'objets (du type « makeTransientByteArray », « buildKey », etc.) et les faire précéder de l'incrément d'un compteur du nombre d'octets alloués par la valeur dynamique demandée lors de l'exécution.
Lors de l'exécution d'un test, le comportement du programme est suivi en observant les sorties produites par le programme en réponse aux entrées effectuées et/ou en interrogeant le programme sur son état et ses actions internes s'il est instrumenté à cet effet et/ou en interrogeant la plate-forme de test si celle-ci le permet (c'est le cas en général d'une plate-forme de test basée sur un simulateur ou un émulateur).
Les informations recueillies sur le comportement du programme peuvent être rendues disponibles via un dispositif de contrôle de la plate-forme de test, qui peut notamment offrir des moyens de représentation des sorties effectuées par le programme, des moyens de représentation de l'état courant et des actions effectuées par le programme et/ou le système d'exécution (notamment une indication des points de programmes et/ou des points d'exécution atteints depuis l'exécution du test ou d'un ensemble de tests), des moyens d'interrogation du programme et/ou de la plate-forme de test, et des moyens de mémorisation et de représentation de l'historique de l'exécution.
Par exemple : les points de programme (d'exécution) atteints, le nombre de fois, dans quelles conditions, l'évaluation des caractéristiques opérationnelles en ces points de programme, ...
C'est notamment ce dispositif de contrôle qui permet à un opérateur de test de répondre à des questions posées dans les scripts de test, y compris pour les conditions d'arrêt d'un test.
Les informations sur le comportement passé et présent du programme permettent d'évaluer certaines caractéristiques opérationnelles du programme lors de son exécution. Suivant les circonstances, cette évaluation peut être manuelle (laissée à la responsabilité d'un opérateur de test), semi-automatique (avec l'aide d'un outil de décision automatique et d'informations fournies par un opérateur de test) ou automatique (sous le seul contrôle d'un outil de décision automatique). L'exécution d'un test peut être plus ou moins automatisée. En cas d'automatisation, le scénario du test est exécuté par un script de test exécutable qui installe et/ou lance le programme sur la plate-forme de test et/ou enchaîne les différentes interactions stipulées dans le scénario. En cas de test manuel, c'est un opérateur de test qui installe et/ou lance le programme sur la plate-forme de test et/ou qui effectue les différentes interactions inscrites dans le scénario.
Un même test peut combiner des opérations automatisées et des opérations manuelles. Ainsi, les entrées du programme peuvent être fournies automatiquement par le script du test et/ou manuellement par un opérateur de test. De même, les contrôles peuvent être effectués automatiquement par le script du test et/ou manuellement par un opérateur de test.
Dans le cas où un opérateur de test doit intervenir, les interactions peuvent être décrites dans une spécification de test et/ou demandées par le script de test exécuté, par exemple via un affichage sur une station de contrôle. Dans ce dernier cas, l'opérateur de test est guidé dans le scénario du test par les demandes d'entrées et/ou de contrôles effectuées par le script de test et par les observations qu'il peut obtenir sur l'exécution du programme. Cela permet notamment d'effectuer des entrées ou des contrôles impossibles à réaliser par une machine. Cela permet aussi de fournir des informations permettant de décider de l'arrêt d'un test. Par exemple, un opérateur de test peut décider de terminer une exécution quand un groupe de points d'exécution d'un programme (par exemple, tous les points d'exécution, tous les points d'exécution associés à une règle, etc.) ont été atteints par l'exécution d'un ou plusieurs tests. La fourniture d'informations concernant l'exécution (points d'exécution atteints jusqu'à lors, routines appelées, état du programme et/ou du système d'exécution, etc.) permet aussi à l'opérateur de test de deviner quel type d'interaction permet d'atteindre tel ou tel point ou zone de programme et/ou de déclencher tel ou tel type d'événement.
Dans le cas où un test doit évaluer la satisfaction d'une règle de la forme « si E alors Ci et ... et CM », le test doit comporter des évaluations des expressions logiques que sont la condition d'occurrence de l'événement E et les conditions à remplir Ci, ...,
CN- Dans le cas où ces événements et conditions font référence à des états et actions internes au programme et au système d'exécution, en particulier qui ne peuvent être déduits des comportements observables, il est indispensable que la plate-forme de test et/ou le programme dispose de facultés d'introspection.
En particulier, dans le cas où la plate-forme de test est un simulateur ou un émulateur des plates-formes cibles, il est généralement possible de savoir en cours d'exécution si un événement donné E se produit, ainsi que de connaître des informations complémentaires sur les circonstances comme par exemple, le point de programme courant, l'état du programme et/ou du système d'exécution, etc. Ces informations complémentaires peuvent notamment permettent de déterminer automatiquement la valeur logique de certaines des conditions des règles définies comme « si E alors Cj et ... et CV ».
Dans le cas où la plate-forme de test est la plate-forme cible elle-même, seuls les effets extérieurs sont généralement visibles, pas les événements internes. La vérification de l'occurrence d'un événement peut toutefois être indirecte. Par exemple, l'opérateur de test peut observer le numéro de téléphone composé lors de l'envoi d'un SMS avec demande d'autorisation. En revanche, certaines informations peuvent rester inaccessibles, comme par exemple le point d'exécution courant ou le fait que ce point d'exécution se trouve dans une boucle de programmation. Certaines informations pourraient toutefois être rendues accessibles après instrumentation du programme.
Lorsqu'un événement associé à une règle se produit, après détermination automatique ou manuelle de la satisfaction, transgression ou irrésolution, il faut décider de la poursuite ou non du test. La condition d'arrêt de l'exécution d'un test est stipulée dans son scénario. Elle peut dépendre de différents facteurs portant sur le statut de règle, possiblement au point d'exécution où elle est contrôlée. Un test peut aussi être interrompu après un temps d'exécution donné, par exemple parce qu'on juge que l'obtention d'informations supplémentaires ne serait pas rentable, c'est-à-dire demanderait trop de temps. La qualité d'une suite de tests dépend en particulier de son degré de couverture sur différents aspects, notamment :
• couverture de la spécification : mesure a priori de la proportion de description de l'application mise à l'épreuve dans la suite de tests ; • couverture des critères : mesure a priori de la proportion de critères mis à l'épreuve dans la suite de tests ;
• couverture des interactions avec le programme : mesure a priori de la représentativité des interactions (entrées fournies et réponses produites) auxquelles l'application est soumise dans la suite de tests, en particulier les valeurs aux limites et les combinaisons variables de données ;
• couverture du flot de contrôle : mesure a posteriori de la proportion d'éléments du flot de contrôle (instructions, branches d'exécution, chemins d'exécution, structures itérative, etc.) parcourue lors de l'exécution de la suite de tests pour une implémentation donnée. En pratique, vérifier les éléments du flot de contrôle qui sont parcourus nécessite de pouvoir observer l'exécution et/ou de pouvoir instrumenter le code.
Outre la couverture, d'autres paramètres jouent sur la qualité d'une suite de tests, notamment la quantité de ressources qu'elle nécessite : à fonctionnalité testée équivalente, mieux vaut un test qui s'exécute en peu de temps, en consommant peu de mémoire, etc.
Le degré de couverture et la quantité de tests dépendent de la méthodologie de développement des tests et du soin du testeur. Plus la couverture est élevée, plus grand est aussi l'effort nécessaire pour concevoir et réaliser les tests. Or, dans l'industrie logicielle, la productivité peut être un paramètre aussi important si ce n'est plus que des critères de sécurité ou de bon fonctionnement.
Tout ou partie des données d'une suite de test peut également être généré automatiquement à partir d'une formalisation de la spécification de l'application. Outre la productivité accrue, un des avantages est de pouvoir offrir des garanties sur le degré de couverture d'une spécification formelle. Les outils capables de produire ainsi des données de test pertinentes (en quantités pertinentes) sont encore rares. Quoiqu'il en soit, les suites de test générées automatiquement sont soumises aux mêmes limitations que les suites de tests écrites à la main.
Le test souffre en effet de plusieurs limitations. C'est une approche bien adaptée pour le contrôle de correction (comparer ses sorties effectives à des sorties attendues), mais moins pour le contrôle de validité.
Car si le test permet de répondre à certaines questions pratiques liées à l'ergonomie, il ne procure pas de garantie forte sur les questions d'interopérabilité et surtout de sécurité. En effet, on n'examine avec cette méthode qu'un petit nombre de chemins d'exécution possibles, alors qu'il en existe une infinité. Par exemple, l'absence de chevaux de Troie (programme ou données qui semblent inoffensives lorsqu'elles sont chargées sur la plate-forme mais qui facilitent ensuite une attaque, par exemple par un pirate ou un virus) ne peut pas être prouvée avec certitude.
Le problème vient de ce que la combinatoire des différentes interactions possibles avec le programme rend impraticable l'examen de tous les cas d'exécution possibles. Il n'est donc généralement pas possible d'obtenir de certitude, sauf lorsqu'un dysfonctionnement est révélé au cours de l'exécution d'un test. Les seuls cas de figure sont alors les suivants :
• L'application est incorrecte (respectivement invalide) avec certitude.
• Les tests ne permettent pas de déterminer avec certitude si l'application est correcte (respectivement valide) ou non.
En pratique, bien que l'absence de dysfonctionnement lors des tests ne garantisse pas qu'un programme fonctionne bien en toute circonstance, un programme qui passe avec succès les tests sera considéré comme « suffisamment » correct (respectivement valide). Le degré de confiance dans ce jugement repose sur la qualité et la pertinence des tests, c'est-à-dire en grande partie sur le degré de couverture des tests.
De plus, certaines classes de test sont souvent sous-spécifiées, comme par exemple les tests de bon fonctionnement d'applications pour téléphones mobiles ; beaucoup de ces tests consistent à exécuter l'application dans un temps limité en tant qu'utilisateur ordinaire et à noter au passage certains comportements anormaux de l'application. Dans de tels cas, l'opérateur de test humain ne sait pas très bien ce qu'il doit chercher ni comment il peut le trouver. Au mieux il dispose d'une liste d'objectifs de tests et il essaie d'attendre un nombre maximal d'objectif.
En outre, l'opérateur de test n'a pas toujours les moyens d'évaluer la qualité de son travail. Il reste notamment sans pouvoir devant du code malicieux, conçu pour rester dissimulé et n'agir que dans des circonstances particulières qui ne se produisent pas lors des premières utilisations, rapides et superficielles, de l'application.
Par ailleurs, faire exécuter des tests par un opérateur de test a un coût élevé du fait de la main d'œuvre humaine, en comparaison avec des approches automatisées.
Au vu de ce qui précède, si l'on compare les avantages et inconvénients respectifs de l'analyse statique et du test, il faut reconnaître qu'aucune des deux techniques n'est systématiquement supérieure à l'autre. Suivant notamment le niveau de garantie cherché (confiance et/ou degré de précision) et l'effort à fournir (en particulier, le degré d'automatisation), on peut employer l'une ou l'autre de ces techniques.
En fait, on peut observer que l'analyse statique et le test sont d'une certaine manière complémentaires :
• Seule l'analyse statique peut permettre de déterminer avec certitude qu'un programme est correct (respectivement valide).
• Seul le test peut fournir une mesure de vraisemblance de la correction ou de la validité d'un programme, quand une analyse statique ne peut statuer avec certitude : l'absence d'erreur ou de transgression observable lors de l'exécution des tests sert de gage à la présomption de correction ou de validité.
• Les analyses statiques étant principalement automatiques, elles ne peuvent répondre à des questions auxquelles seul un humain peut répondre, comme par exemple les questions liées à l'ergonomie, la déontologie, etc. En revanche, ces questions peuvent trouver une réponse simple et immédiate lors d'un test avec un opérateur humain.
• Même quand l'analyse statique ne parvient pas à statuer pas avec certitude sur la correction ou de la validité d'un programme, elle peut fournir des informations sur les zones de programmes problématiques ou douteuses, et sur les circonstances qui pourraient conduire à un comportement incorrect ou invalide, ce qui est hors de portée du test.
• Bien que l'analyse statique permet parfois de découvrir des cas certains de comportements incorrects ou invalides, elle est peu adaptée à cela et fourni le plus souvent dans ce cas des résultats indéterminés. C'est plutôt au test qu'il revient alors de déterminer qu'un programme est incorrect (respectivement invalide) avec certitude.
Compte tenu des problèmes précédemment évoqués, l'invention a pour objet une évaluation de caractéristiques opérationnelles d'un programme, qui permette notamment le développement d'outils de contrôle de correction ou de validité qui apportent un haut niveau de certitude et/ou de productivité. Elle permet ainsi d'obtenir de meilleurs compromis en efforts à fournir et confiance résultante.
- À cet effet, elle propose un procédé pour l'évaluation de caractéristiques opérationnelles d'un programme, ce procédé mettant en oeuvre une plate-forme de test (matérielle et/ou logicielle) permettant l'exécution et le contrôle dudit programme ainsi qu'une suite de tests destinés à évaluer lesdites caractéristiques opérationnelles. Ce procédé est caractérisé en ce qu'il comprend une procédure d'évaluation comportant les étapes suivantes :
- une première étape où le programme est soumis à une analyse statique qui détermine les caractéristiques opérationnelles dudit programme, avec une plus ou moins grande précision et qui produit un ensemble d'exigences de tests destinées à évaluer les caractéristiques opérationnelles qui n'ont pas été déterminées avec suffisamment de précision ;
- une deuxième étape où le programme, exécuté sur ladite plate-forme de test, est soumis à une sélection de tests constituée par les seuls tests et/ou fragments de tests qui concernent les caractéristiques opérationnelles que l'analyse statique n'a pas déterminé avec suffisamment de précision ;
- une troisième étape où le programme, exécuté sur ladite plate-forme de test, est soumis à une suite de tests paramétrée selon les exigences de test générées lors de la première étape ; - une quatrième étape où les caractéristiques opérationnelles du programme sont constituées à partir des caractéristiques opérationnelles déterminées par ladite analyse statique, complétées par les caractéristiques opérationnelles évaluées par ladite suite de tests.
Avantageusement, :
- Dans le cas où un ou plusieurs contextes d'exécution cibles du programme définissent les séquences d'entrées du programme considérées comme légales, l'analyse statique effectuée lors de la première étape prend en compte l'hypothèse que les seules séquences d'entrées possible du programme sont des séquences d'entrées légales.
- Les caractéristiques opérationnelles déterminées par l'analyse statique comprennent une ou plusieurs des informations suivantes : le flot de contrôle, le flot de données, la consommation mémoire, le temps d'exécution, la liste des routines du système appelées durant l'exécution du programme, les valeurs correspondantes des arguments, les statuts de contrôles de correction ou de validité.
- Certains tests de la suite de tests pourront avoir des paramètres qui influent sur les opérations effectuées lors de l'exécution des tests et qui peuvent être ajustés pour faire varier la précision avec laquelle les caractéristiques opérationnelles du programme sont évaluées.
- Quand elle ne détermine pas des caractéristiques opérationnelles avec suffisamment de précision, l'analyse statique pourra produire des valeurs de paramètres pour certains des tests sélectionnés afin de restreindre lesdits tests aux seules opérations susceptibles d'améliorer ladite précision.
- Les tests pourront notamment comprendre :
- des entrées (notamment inputs et/ou variations de disponibilité des ressources et/ou interruptions et/ou marques de temps) à soumettre au programme et/ou au système d'exécution, et
- des sorties (notamment outputs et/ou événements) à observer pour évaluer lesdites caractéristiques opérationnelles.
- La susdite suite de tests pourra comprendre des tests : • dont les entrées à soumettre sont fournies par un programme de test et/ou par un opérateur de test, le programme de test pouvant indiquer à l'opérateur de test des opérations particulières à effectuer sur la plate-forme de test, et
• dont les sorties à observer sont contrôlées par un programme de test et/ou par un opérateur de test, le programme de test pouvant poser des questions à l'observateur concernant ses observations.
- Durant l'exécution des tests avec opérateur de test, un dispositif de contrôle pourra assister l'opérateur de test en consignant les observations dudit opérateur de test et en lui présentant une vision actualisée des caractéristiques opérationnelles évaluées jusqu'à lors afin qu'il puisse estimer s'il y a lieu de poursuivre le test ou si les degrés de précision atteints sont suffisants.
- La vision des caractéristiques opérationnelles évaluées présentées à l'opérateur de test pourra comprendre une vision de l'exécution du programme constituée par une représentation indiquant si certaines événements ont déjà eu lieu et/ou dans quelles circonstances, notamment :
• indiquant si certains points et/ou branches et/ou chemins d'exécution ont déjà ou n'ont pas encore été parcourus lors de l'exécution, et/ou
• comportant des informations sur l'état du programme et/ou du système d'exécution en lesdits points et/ou lesdites branches et/ou lesdits chemins d'exécution.
- Certaines des susdites caractéristiques opérationnelles pourront dépendre d'un ou plusieurs environnements d'exécution (matériels et/ou logiciels) cibles pour le programme ainsi que d'une ou plusieurs configurations cibles desdits environnements (notamment en ce qui concerne les ressources et/ou fonctionnalités disponibles et/ou autorisées dans lesdits environnements), et la plate-forme de test inclut et/ou émule et/ou simule lesdits environnements d'exécution cibles avec leurs configurations cibles.
- Les susdites caractéristiques opérationnelles à évaluer pourront comprendre la vérification de propriétés et que : Lors de la première étape, l'analyse statique détermine des propriétés que le programme satisfait avec certitude et des propriétés que le programme transgresse avec certitude (les autres propriétés étant des propriétés que l'analyse ne détermine pas avec certitude comme satisfaites ou transgressées) ; - Lors de la seconde étape, le programme est soumis aux seuls tests de la suite de tests qui concernent les propriétés du programme que l'analyse statique n'a pas déterminées avec certitude comme satisfaites ou transgressées.
- Lors de la première étape du procédé selon l'invention, l'analyse statique pourra notamment déterminer d'une part quels sont les points d'exécution en lesquels ledit événement se produit avec certitude ou peut se produire et, d'autre part, la valeur de vérité desdites conditions auxdits points d'exécution lorsque ledit événement se produit, et lors de la seconde étape, lorsqu'au cours d'un test ledit événement se produit ou peut se produire en un point d'exécution PE, seules sont évaluées les conditions qui n'ont pas été établies par l'analyse statique comme vraies avec certitude au point d'exécution PE lorsque ledit événement se produit. Les susdites caractéristiques opérationnelles à évaluer comprennent la vérification de règles qui déterminent si le programme est valide (respectivement correct), lors de la troisième étape, les caractéristiques opérationnelles du programme comprenant la vérification de règle étant constituées selon la procédure suivante :
• Si les résultats de l'analyse statique de la première étape indiquent que chacune desdites règles est satisfaite avec certitude, alors il est établi que le programme est valide (respectivement correct) avec certitude. • Si les résultats de l'analyse statique de la première étape et/ou de l'exécution des tests de la deuxième étape indiquent qu'aucune desdites règles n'est transgressée avec certitude et qu'au moins une desdites règles est de statut indéterminé, alors il est établi que le programme est peut-être valide (respectivement correct), peut-être invalide (respectivement incorrect). • Si les résultats de l'analyse statique de la première étape et/ou de l'exécution des tests de la deuxième étape indiquent qu'au moins une règle est transgressée avec certitude pour certaines entrées du programme, alors il est établi que le programme est invalide (respectivement incorrect) avec certitude.
• Si les résultats de l'analyse statique de la première étape et/ou de l'exécution des tests de la deuxième étape indiquent qu'aucune desdites règles n'est transgressée avec certitude et qu'au moins une desdites règles est de statut indéterminé et que chacune desdites règles de statut indéterminé est systématiquement satisfaite lors des tests de la deuxième étape, alors il est établi que le programme est vraisemblablement valide (respectivement correct). - Les susdites caractéristiques opérationnelles pourront comprendre la satisfaction de règles de bon fonctionnement et/ou de portabilité et/ou d'interopérabilité et/ou de sécurité et/ou d'éthique et/ou de déontologie et/ou d'ergonomie et/ou de style.
Les différentes étapes du procédé selon l'invention (analyse, test, certification assistée) sont décrites plus précisément ci-après :
Analyse
Les exigences de test sont des informations qui guident l'exécution des tests. Elles peuvent notamment porter sur des interactions particulières à effectuer avec le programme et sur des évaluations particulières à pratiquer. Les interactions particulières - entrées particulières à soumettre au programme.
Le guidage de l'exécution des tests peut se traduire par un paramétrage du dispositif d'exécution de la plate-forme de test (incluant l'instrumentation de la plate-forme) et/ou une instrumentation du programme comprenant notamment la pose de point d'arrêts systématiques, la pose de point d'arrêts conditionnels, la production d'informations permettant l'évaluation des caractéristiques opérationnelles.
Test
Dans une deuxième étape, le programme est soumis à une suite de tests destinés à évaluer lesdites caractéristiques opérationnelles.
Dans le cadre de l'invention, seuls sont effectués les tests qui concernent les caractéristiques opérationnelles que l'analyse statique n'a pas déterminées avec suffisamment de précision. Dans le cas particulier où les caractéristiques opérationnelles à évaluer sont des contrôles à effectuer, seuls sont effectués les tests qui concernent les contrôles sur lesquels l'analyse statique n'a pas statué avec certitude. Dans le cas particulier où les contrôles à effectuer sont des règles à vérifier, seuls sont effectués les tests qui concernent les règles dont l'analyse statique n'a pas déterminé le statut (satisfaction ou transgression) avec certitude.
Par exemple, dans le cas d'une application pour carte à puce, si l'analyse statique a déterminé un encadrement satisfaisant (suivant les besoins) de la consommation mémoire de l'application, il n'est pas nécessaire d'effectuer des tests des commandes d'installation et de personnalisation avec des valeurs diverses pour tenter d'estimer la consommation mémoire de l'application. De même, si l'analyse statique a déterminé avec certitude le statut d'un contrôle, par exemple la satisfaction ou la transgression d'une règle sur l'envoi de SMS, il est inutile d'effectuer des tests qui tentent de vérifier si ladite règle est respectée ou non dans diverses circonstances.
De plus, pour un test à effectuer donné, seuls sont exécutés les fragments de tests capables d'effectuer les fragments d'évaluation que l'analyse statique n'a pas déterminés avec suffisamment de précision ; les fragments d'évaluation restants sont fournis par l'analyse statique. Dans le cas particulier où les caractéristiques opérationnelles sont des contrôles à effectuer ou des règles à vérifier, seuls sont exécutés les fragments de tests capables d'effectuer les fragments d'évaluations que l'analyse statique n'a pas déterminées avec suffisamment de précision pour pouvoir statuer.
Par exemple, dans le cas d'une application pour carte à puce, si l'analyse statique a déterminé avec précision le nombre d'octets demandé par les allocations mémoires de la commande d'installation, mais en revanche n'a pas pu déterminer les demandes d'allocation faites en personnalisation, il est inutile lors des tests d'examiner les allocations faites lors de l'installation ; seules le nombre d'octets demandé par les allocations mémoires des commandes de personnalisation reste à évaluer pour que, combiné et sommé aux valeurs déterminées par l'analyse statique pour l'installation, soit fourme une évaluation générale de la consommation mémoire. De même, si un contrôle s'exprime comme une conjonction de conditions, seuls sont à évaluer lors des tests les conditions que l'analyse statique n'a pas déterminées comme vraies ou fausses avec certitude.
Les tests sont exécutés sur la plate-forme de test, configurée si nécessaire par rapport aux plates-formes d'exécution cibles du programme. Cette configuration peut être restreinte aux seuls cas qui concernent les caractéristiques opérationnelles que l'analyse statique n'a pas déterminées avec suffisamment de précision. Dans le cas particulier où les caractéristiques opérationnelles sont des contrôles à effectuer ou des règles à vérifier, la configuration peut être restreinte aux seuls cas qui concernent les contrôles ou les règles sur lesquels l'analyse statique n'a pas statué avec certitude.
L'instrumentation du programme peut être notamment basée sur des informations extraites par l'analyse statique de la première phase et sur les caractéristiques opérationnelles particulières à évaluer, ceci afin par exemple de minimiser la consommation supplémentaire de ressources (mémoire, temps d'exécution, etc.) et/ou les limitations d'instrumentation inhérentes au programme et/ou à la plate-forme d'exécution.
Dans le cadre de l'invention, seules sont effectuées les instrumentations nécessaires aux tests qui concernent les caractéristiques opérationnelles que l'analyse statique n'a pas déterminées avec suffisamment de précision. Dans le cas particulier où les caractéristiques opérationnelles sont des contrôles à effectuer ou des règles à vérifier, seuls sont effectués les instrumentations nécessaires aux tests qui concernent les contrôles ou les règles sur lesquels l'analyse statique n'a pas statué avec certitude.
Par exemple, il est inutile d'instrumenter une application pour qu'elle signale chaque allocation mémoire effectuée ou réponde à des demandes concernant la consommation mémoire si l'analyse statique a déterminé avec suffisamment de précision cette consommation, rendant superflu l'exécution des tests. De même, il est inutile d'instrumenter une application pour qu'elle signale ou contrôle chaque envoi de SMS si l'analyse statique a déterminé que tous les emplois de SMS étaient valides.
De plus, pour un test à effectuer donné, seules sont effectuées les instrumentations nécessaires aux fragments d'évaluation que l'analyse statique n'a pas déterminés avec suffisamment de précision. Dans le cas particulier où les caractéristiques opérationnelles sont des contrôles à effectuer ou des règles à vérifier, seules sont effectuées les instrumentations nécessaires aux fragments d'évaluations que l'analyse statique n'a pas déterminées avec suffisamment de précision pour pouvoir statuer.
Par exemple, il est inutile d'instrumenter les instructions d'allocations mémoire que l'analyse statique a déterminées avec suffisamment de précision, car l'information sera superflue lors des tests. De même, seuls sont à instrumenter les envois de SMS qui correspondent à des usages que l'analyse statique n'a pas déterminés valides avec certitude.
Dans le cas d'une instrumentation automatique, l'outil d'instrumentation peut être paramétré à l'aide des informations fournies par l'analyse statique.
La représentation (respectivement mémorisation) des informations dans le dispositif de contrôle de la plate-forme de test peut être faite de manière à minimiser les informations non pertinentes, notamment en limitant la représentation (respectivement mémorisation) aux seules informations nécessaires à l'établissement des caractéristiques opérationnelles que l'analyse n'a pas déterminées avec suffisamment de précision. Cela permet un meilleur confort et une plus grande productivité de l'opérateur de test (respectivement une économie des ressources en terme de mémoire et de temps d'exécution). Cette limitation de la représentation (respectivement mémorisation) peut être obtenue par un paramétrage de la plateforme de contrôle. Cette plate-forme de contrôle peut être directement paramétrée par les résultats de l'analyse statique.
En particulier, pour une caractéristique opérationnelle qui est une règle de la forme « si E alors Q et ... et CN », il est possible d'évaluer en cours d'exécution tout ou partie de certains événements et conditions.
Trois cas de figure (exclusifs les uns des autres) sont possibles :
• II est certain que l'événement E se produit. • II est possible, mais pas certain, que l'événement E se produise.
• II est certain que l'événement E ne se produit pas.
Les informations nécessaires pour établir l'occurrence ou la non-occurrence d'un événement peuvent concerner non seulement l'état courant de ladite exécution mais aussi l'historique de cette exécution. Ces informations peuvent être fournies automatiquement ou non par la plate-forme de test et/ou par un opérateur de test, notamment à la demande du script du test et/ou à l'aide du dispositif de contrôle de la plate-forme de test. II est possible que certaines informations restent indéterminées. Dans le doute, l'occurrence de l'événement doit alors être considérée comme possible. Cette situation peut notamment se produire si l'opérateur de test ne peut, ne sait ou ne veut statuer sur des questions qui sont de son ressort. Il peut y avoir plusieurs raisons à cela, par exemple : méconnaissance de la question posée ou des actions à effectuer, manque d'information complémentaire, manque de temps pour fournir une réponse, etc.
Quand se pose la question de l'occurrence ou non d'un événement, le programme est en un certain point d'exécution PE (ou en une succession de points d'exécution si le programme n'est pas interrompu momentanément en attente d'une entrée particulière). Ce point d'exécution peut ne pas être immédiatement connu hors de la plate-forme d'exécution ; il n'est donc déterminé qu'avec une plus ou moins de précision.
Dans le cas d'un simulateur par exemple, il est généralement possible de connaître le point de programme courant d'une exécution. La mémorisation de l'historique, par exemple via un dispositif de contrôle sur la plate-forme de test, permet aussi de déterminer des informations sur le chemin emprunté par l'exécution en cours depuis le lancement du programme. Elle permet notamment de répondre ainsi à des questions concernant la séquence d'événements qui précède.
S'il est certain que l'événement ne se produit pas au point d'exécution courant, le test peut se poursuivre. Sinon, des vérifications sont nécessaires pour contrôler la valeur de vérité des conditions afin de tenter de déterminer la satisfaction ou la transgression de la règle, avant de prendre la décision de poursuivre l'exécution du test ou de l'interrompre.
Parmi les fragments d'évaluation nécessaires pour établir si l'événement E se produit ou peut se produire, certains peuvent être déterminés par l'analyse statique.
Seules sont effectuées les actions des tests qui permettent d'évaluer les informations nécessaires pour établir si l'événement E se produit ou peut se produire, que l'analyse statique n'a pas déterminées avec suffisamment de précision. Pour sa part, l'analyse statique détermine, pour une règle « si E alors C; et ... et CN », quelles conditions C,- sont statiquement déterminées comme vraies, c'est-à-dire vraies avec certitude lorsque l'événement E se produit au point de programme PE. Une condition C7 dynamiquement falsifiable, c'est-à-dire qui n'est pas statiquement déterminée comme vraie, peut avoir trois statuts différents :
• II est certain que la condition C7 est vraie au point d'exécution PE.
• II est certain que la condition C7 est fausse au point d'exécution PE.
• II n'est pas établi avec certitude si la condition C7 est vraie ou fausse au point d'exécution PE.
Pour déterminer avec certitude que la condition est vraie (respectivement fausse), la vérification de la condition (respectivement de la négation de la condition) doit être automatisable et les informations nécessaires pour déterminer avec certitude si la condition est vraie (respectivement fausse) doivent être disponibles en ce point d'exécution.
Comme pour le cas des occurrences d'événements, les informations nécessaires pour établir avec certitude la valeur de vérité d'une condition peuvent concerner l'historique de l'exécution ainsi que l'état courant de ladite exécution. Ces informations peuvent être fournies par la plate-forme de test et/ou par un opérateur de test, notamment à la demande du script du test.
Également comme pour le cas des occurrences d'événements, il est possible que l'opérateur de test ne puisse, ne sache ou ne veuille statuer sur des informations nécessaires à l'établissement de la valeur de vérité d'une condition. Ce peut être notamment par méconnaissance de la question qui lui est posée, par manque d'information complémentaire, par manque de temps, etc. Dans ce cas, la condition doit être considérée comme irrésolue, c'est-à-dire possiblement vraie ou fausse.
Trois cas exclusifs les uns des autres sont alors aussi possibles lorsque l'événement E se produit ou peut se produire au point d'exécution PE : • II est certain que chacune des conditions dynamiquement falsifiables est vraie au point d'exécution PE : Dans ce cas, la règle R est considérée comme satisfaite avec certitude au point d'exécution PE pour certaines entrées du programme. Suivant la condition d'arrêt stipulée dans le scénario du test, l'exécution du test peut se poursuivre automatiquement (par exemple parce qu'une seule occurrence de règle satisfaite n'est pas assez convaincante), se terminer automatiquement (par exemple parce qu'une seule occurrence de règle satisfaite est suffisamment convaincante et parce que le test ne contrôle pas d'autres règles), ou ne continuer qu'après accord de l'opérateur de test (qui est alors juge de la pertinence de la poursuite du test).
• II est certain qu'au moins une des conditions dynamiquement falsifiables est fausse au point d'exécution PE : Dans ce cas, la règle R est considérée comme transgressée avec certitude au point d'exécution PE pour certaines entrées du programme. Suivant la condition d'arrêt stipulée dans le scénario du test, l'exécution du test peut se poursuivre automatiquement (par exemple, pour trouver davantage d'occurrences de transgressions), se terminer automatiquement (par exemple parce qu'une seule transgression suffît à invalider la règle), ou ne continuer qu'après accord de l'opérateur de test (qui est alors juge de la pertinence de la poursuite du test). • Au moins une des conditions dynamiquement falsifiables n'est pas établie comme vraie avec certitude au point d'exécution PE et aucune des conditions dynamiquement falsifiables n'est établie comme fausse avec certitude au point d'exécution PE : Dans ce cas, la règle R est considérée comme irrésolue au point d'exécution PE pour certaines entrées du programme. Suivant la condition d'arrêt stipulée dans le scénario du test, l'exécution du test peut se poursuivre automatiquement, se terminer automatiquement, ou ne continuer qu'après accord de l'opérateur de test (qui est alors juge de la pertinence de poursuivre le test).
Interruption des tests quand toutes les exigences de test ont été « satisfaites » (sollicitées, pratiquées, ...).
Certification assistée
À titre d'exemple non limitatif, on considère le cas particulier suivant de l'invention, permettant la certification assistée d'applications. On considère le cas où le dispositif d'exécution de la plate-forme de test permet la pose de points d'arrêt et l'exécution de fonctions d'introspection. Si le dispositif d'exécution ne permet pas ces fonctionnalités, le programme peut être instrumenté à cet effet.
On considère aussi le cas où le dispositif de contrôle de la plate-forme de test peut être programmé pour conserver un historique de certaines informations (notamment des événements passés) et/ou pour évaluer des expressions (notamment en faisant appel aux fonctions d'introspection et/ou à l'historique) et/ou pour demander à un opérateur de test d'évaluer de répondre à certaines questions.
On considère le cas de la vérification d'un ensemble de règles de la forme « si E alors Ci et ... et CH ». Parmi les conditions E, Ci, ..., C^, certaines portent sur des quantités directement liées à l'exécution et leur vérification est automatisable ; les autres conditions ne peuvent trouver de possible réponse qu'en interrogeant un opérateur de test.
À titre d'exemple illustratif, on considère les deux règles suivantes. La règle Ri exprime qu'on ne peut faire de SMS qu'à des numéros de la forme "3xxxx" : « si la méthode "Connector.open" est appelée avec un argument commençant par "sms://"
(événement Ei), alors cet argument doit être de la forme "smsjβxxxx" (condition
Ki) ». La vérification de l'événement Ei et de la condition Ki de cette règle est automatisable. La règle R∑ dit que le programme doit demander l'autorisation à l'utilisateur avant tout envoi de SMS : « si la méthode "MessageConnection.send" est appelée (événement Ei), le programme a affiché un message signalant l'envoi d'un
SMS et demandé l'autorisation de l'utilisateur (condition Ki) ». Dans ce second cas, la vérification de l'occurrence de l'événement E∑ est automatisable, mais celle de la condition K2 ne l'est pas ; seul un opérateur de test humain peut déterminer si l'affichage contient un avertissement, une demande d'autorisation, etc.
Étant donné un contexte d'exécution du programme définissant la classe d'entrées légales auxquelles il peut être soumis, la mise en œuvre du procédé pour la vérification de ces règles comprend alors les trois étapes suivantes. Etape 1 : analyse statique
Dans une première étape, le programme est soumis à une analyse statique qui cherche à déterminer si les règles sont satisfaites ou transgressées dans ledit contexte d'exécution.
Pour chacune des règles R à vérifier définies comme « si E alors Ci et ... et CV », trois cas exclusifs les uns des autres sont possibles :
• II est certain que la règle R est satisfaite en tout point d'exécution. Autrement dit, pour tout point d'exécution :
- ou bien E est déterminé avec certitude comme faux,
- ou bien E n'est pas déterminé avec certitude comme faux mais chacune des conditions Q est déterminée avec certitude comme vraie.
• II est possible, mais pas certain, que la règle R ne soit pas satisfaite en un point d'exécution. Autrement dit, il existe un point d'exécution où R est de statut indéterminé, c'est-à-dire tel que :
- ou bien E est indéterminé et au moins une des conditions C,- n'est pas vraie avec certitude (c'est-à-dire C1- est fausse avec certitude ou indéterminée),
- ou bien E est déterminé avec certitude comme vrai, aucune des conditions C,- n'est déterminée avec certitude comme fausse, et au moins une des conditions
Q est indéterminée.
• II est certain que la règle R est transgressée en un point d'exécution. Autrement dit, Autrement dit, il existe un point d'exécution PE tel que E est déterminé avec certitude comme vrai et au moins une des conditions Q est déterminée avec certitude comme fausse.
Le résultat de l'analyse statique comprend notamment un ensemble d'informations concernant les règles satisfaites en tout point d'exécution ou transgressées en un point d'exécution, ainsi qu'un ensemble d'exigences de test. Ces exigences de test comprennent notamment l'ensemble des règles de statut indéterminé en au moins un point d'exécution et/ou, pour toute règle « si E alors Q et ... et C# » dudit ensemble, l'ensemble PPR des points de programme où la règle peut être de statut indéterminé et/ou, pour tout point de programme PP de PPR, l'événement E s'il est dynamiquement falsifiable (c'est-à-dire indéterminé) en PP ainsi que le sous- ensemble des conditions « Ci, ..., CN » qui sont dynamiquement falsifiables en PP.
Des ensembles de points de programmes appartenant à une même classe de points de programme peuvent être regroupés une zone de programme, comme par exemple tous les points de programme d'une routine particulière, d'une boucle de programmation, etc.
Dans le cas de l'exemple illustratif ci-dessus, on suppose que le programme comporte deux appels à « Connector.open » aux points de programme PPi et PP 2, le premier que l'analyse statique peut déterminer comme étant de la forme "sms://3:oxc", l'autre restant indéterminé, et deux appels à « MessageConnection.send » au point de programme PP 3 et PP 4. Les exigences de test comprennent alors les deux règles R1 et
R2, les deux points de programme PP 2, PP 3 et PP 4, et pour PP 2 la condition Ki, pour PP3 et PP4 la condition K2.
Etape 2 : test
Dans une deuxième étape, le programme est soumis à une suite de tests qui cherche à satisfaire les exigences de test produites par la première étape.
Pour tout test portant sur des règles de statut indéterminé par l'analyse statique, la plate-forme de test configurée de la manière suivante. Pour toute règle R de statut indéterminé pour ledit test, un point d'arrêt est posé en chacun des points de programme PP de PPR.
Par ailleurs, lors de l'exécution dudit test, à chaque fois que l'exécution s'interrompt quand un point d'arrêt est atteint en un point de programme PP appartenant à un ensemble PPR correspondant à une certaine règle R, le dispositif de contrôle évalue l'événement E de R s'il est dynamiquement falsifiable et si ledit événement se produit en PP, le dispositif de contrôle évalue également le sous-ensembles des conditions de R qui sont dynamiquement falsifiables. Si la vérification d'une condition dynamiquement falsifiable ou de l'occurrence de l'événement E n'est pas automatisée, l'opérateur de test est interrogé, qui peut répondre « vrai », « faux », ou « indéterminé ». Le dispositif de contrôle comptabilise en permanence le détail et le total des nombres d'occurrences d'application de chaque règle aux différents points de programme ainsi que les différents statuts obtenus (satisfaite, indéterminé, transgressée). En fonction du nombre de satisfactions, indéterminations et transgressions, suivant le scénario de test, une politique programmée préétablie ou à la convenance de l'opérateur de test, l'exécution peut se poursuivre automatiquement, s'interrompre automatiquement, ou ne se poursuivre qu'après accord de l'opérateur de test. On peut par exemple poursuivre l'exécution même si une règle est satisfaite, afin d'atteindre un nombre d'occurrences de règle satisfaite jugé convaincant. De même, on peut poursuivre l'exécution même après une transgression pour essayer d'en trouver davantage de cas.
Dans le cas de l'exemple illustratif ci-dessus, des points d'arrêt sont posés aux points de programme PP2, PPs et PP4. À chaque fois que l'exécution atteint le point de programme PP^5 la condition Kj est évaluée : si l'argument de la méthode « Connector.open » est de la forme "sms://3xxxx", le nombre de cas d'application où la règle Rj est satisfaite est incrémenté ; sinon le nombre de cas d'application où la règle Ri est transgressée est incrémenté et l'opérateur de test est averti, qui peut décider ou non d'interrompre le test. De même, à chaque fois que l'exécution atteint le point de programme PP 3 ou PP 4, la condition K2 est évaluée : la question « est-ce que le programme a affiché un message signalant l'envoi d'un SMS et demandé l'autorisation de l'utilisateur ? ». Le nombre de cas d'application où la règle R2 est satisfaite, indéterminée, ou transgressée est incrémenté suivant, respectivement, que l'opérateur a répondu « oui », « non » ou « je ne sais pas ». En cas d'indétermination ou de transgression, l'opérateur de test peut aussi décider d'interrompre le test ; sinon l'exécution du test se poursuit.
Grâce aux résultats de l'analyse statique, certaines opérations sont superflues :
• Seuls sont effectués les tests qui portent sur des règles R qui sont de statut indéterminé par l'analyse statique.
• De plus, lors de l'exécution de ces tests particuliers, les évaluations des règles ne sont pratiquées qu'aux seuls points d'exécution PE qui sont :
- ou bien indéterminés par les évaluations du test, - ou bien déterminés par les évaluations du test et tels que R est indéterminée en PE par l'analyse statique,
- ou éventuellement dans un ou plusieurs états intermédiaires compris entre indéterminé et déterminé. « En outre, en ces points d'exécution particuliers :
- seules sont évaluées les occurrences d'événements de statut indéterminé par l'analyse statique, et
- lorsque l'occurrence d'un événement est déterminée avec certitude comme vraie par l'analyse statique ou les évaluations du test, seules sont évaluées les conditions Q qui sont indéterminée par l'analyse statique.
Etape 3 : diagnostic
À la fin de l'exécution de la suite de test, les informations issues de l'analyse statique et celles issues de l'exécution de la suite de tests (c'est-à-dire les informations gérées dans le dispositif de contrôle) sont rassemblées en un diagnostic unique.
Pour chaque règle R définie comme « si E alors Q et ... et C^ », quatre cas exclusifs les uns des autres sont possibles :
• Si les résultats de l'analyse statique indiquent que la règle R est satisfaite avec certitude, quelles que soient les entrées légales du programme, alors il est établi que la règle R est satisfaite dans toute exécution légale.
• Si les résultats de l'analyse statique indiquent que le statut de la règle est indéterminé et si les résultats de l'exécution de la suite de tests indiquent qu'à chaque occurrence (possible ou avérée) de l'événement E lors des tests, la règle a été satisfaite avec certitude, alors il est établi que la règle est de statut indéterminé mais qu'elle a toutefois systématiquement été satisfaite lors des tests.
• Si les résultats de l'analyse statique indiquent que le statut de la règle est indéterminé et si les résultats de l'exécution de la suite de tests indiquent qu'à au moins une occurrence (possible ou avérée) de l'événement E lors des tests, la règle est restée irrésolue, alors il est établi que le statut de la règle est globalement indéterminé.
• Si les résultats de l'analyse statique et/ou de l'exécution de la suite de tests indiquent que la règle R est transgressée avec certitude pour certaines entrées légales du programme, alors il est établi que la règle est transgressée dans une exécution légale.
Dans les trois derniers cas, des informations complémentaires (issues de l'analyse statique et/ou de l'exécution de la suite de tests) permettant de caractériser les transgressions possibles ou avérées peuvent être fournies, notamment : séquences d'entrées du programme, points de programme, nombre d'occurrences observées de l'événement (sur le total de la suite de tests, par test, etc.).
Si le test se termine sans que le point de programme PP 3 ne soit jamais été atteint le regroupement du diagnostic de chaque règle répond au problème posé :
• S'il est établi que chacune des règles R est satisfaite dans toute exécution légale, alors il est certain que le programme est valide.
• S'il est établi qu'il existe une règle de statut indéterminé mais qu'aucune règle n'est transgressée dans une exécution légale, alors il est possible que le programme soit valide.
• S'il est établi qu'au moins une règle est transgressée dans une exécution légale, alors il est certain que le programme est invalide.
Le diagnostic peut être qualifié en terme de confiance en fonction notamment du nombre d'indéterminations restantes et du taux de couverture des points de programme listés parmi les exigences de tests (par exemple, nombre de points de programme jamais atteints).
Ainsi, s'il est établi que pour toute règle R, soit R est satisfaite dans toute exécution légale, soit R est de statut indéterminé mais a toutefois systématiquement été satisfaite lors des tests, et que tous les points de programme listés parmi les exigences de tests ont été atteint, alors il est vraisemblable que le programme soit valide.
L'instrumentation de la plate-forme, en particulier de machine virtuelle (JVM), peut être poussée plus loin encore en considérant des fragments d'évaluation dans les points d'exécution, les événements, les conditions, etc. Dans le cas d'une utilisation par des développeurs d'applications, le dispositif d'exécution peut être couplé à un véritable débogueur permettant ainsi d'examiner plus en détails les causes d'un problème dès son identification.
Le protocole utilisé pour permettre au dispositif de contrôle de piloter le dispositif d'exécution peut être basé sur le protocole JVMDI (« Java Virtual Machine Debug Interface ») utilisé pour la mise au point d'applications "Java".

Claims

Revendications
1. Procédé pour l'évaluation de caractéristiques opérationnelles d'un programme, ce procédé mettant en oeuvre une plate-forme de test (matérielle et/ou logicielle) permettant l'exécution et le contrôle dudit programme ainsi qu'une suite de tests destinés à évaluer lesdites caractéristiques opérationnelles, caractérisé en ce qu'il comprend une procédure d'évaluation comportant les étapes suivantes :
- une première étape où le programme est soumis à une analyse statique qui détermine les caractéristiques opérationnelles dudit programme, avec une plus ou moins grande précision et qui produit un ensemble d'exigences de tests destinées à évaluer les caractéristiques opérationnelles qui n'ont pas été déterminées avec suffisamment de précision ;
- une deuxième étape où le programme, exécuté sur ladite plate-forme de test, est soumis à une sélection de tests constituée par les seuls tests et/ou fragments de tests qui concernent les caractéristiques opérationnelles que l'analyse statique n'a pas déterminé avec suffisamment de précision ;
- une troisième étape où le programme, exécuté sur ladite plate-forme de test, est soumis à une suite de tests paramétrée selon les exigences de test générées lors de la première étape ; - une quatrième étape où les caractéristiques opérationnelles du programme sont constituées à partir des caractéristiques opérationnelles déterminées par ladite analyse statique, complétées par les caractéristiques opérationnelles évaluées par ladite suite de tests.
2. Procédé selon la revendication 1, caractérisé en ce que, dans le cas où un ou plusieurs contextes d'exécution cibles dudit programme définissent les séquences d'entrées du programme considérées comme légales, l'analyse statique effectuée lors de la première étape prend en compte l'hypothèse que les seules séquences d'entrées possibles du programme sont des séquence d'entrées légales.
3. Procédé selon la revendication 1, caractérisé en ce que les caractéristiques opérationnelles déterminées par ladite analyse statique comprennent une ou plusieurs des informations suivantes : le point de programme, le flot de contrôle, le flot de données, la consommation mémoire, le temps d'exécution, la liste des routines du système appelées durant l'exécution du programme, les valeurs correspondantes des arguments, les statuts de contrôles de correction ou de validité.
4. Procédé selon la revendication 1, caractérisé en ce que : - certains tests de la suite de tests ont des paramètres qui influent sur les opérations effectuées lors de l'exécution des tests et qui peuvent être ajustés pour faire varier la précision avec laquelle les caractéristiques opérationnelles du programme sont évaluées, et
- l'analyse statique, quand elle ne détermine pas des caractéristiques opérationnelles avec suffisamment de précision, produit des valeurs de paramètres pour certains des tests sélectionnés afin de restreindre lesdits tests aux seules opérations susceptibles d'améliorer ladite précision.
5. Procédé selon la revendication 1, caractérisé en ce que certains des tests portent notamment sur les occurrences et/ou successions de certains événements lors de l'exécution du programme et en ce que :
- la plate-forme de test détectant et signalant certains de ces événements, et/ou
- le programme étant instrumenté pour signaler certains de ces événements.
6. Procédé selon la revendication 5, caractérisé en ce que lesdits événements peuvent notamment être des événements simples, qualifiés, composés ou localisés.
7. Procédé selon la revendication 6, caractérisé en ce que les événements simples comprennent notamment : l'exécution de certaines instructions ou opérations, les appels du programme aux routines du système d'exécution, les appels du système d'exécution aux routines du programme, les interruptions du programme et/ou du système d'exécution, la levée d'une exception, le rattrapage d'une exception, les changements d'état du programme et/ou du système d'exécution, les variations de disponibilité des ressources du système d'exécution, les marques de temps passé dans l'exécution du programme (temps total et/ou temps détaillé pour les diverses opérations effectuées), etc.
8. Procédé selon la revendication 6, caractérisé en ce que les événements localisés sont des événements se produisant en des lieux particuliers du programme et/ou lors de l'entrée en des lieux particuliers et/ou lors de la sortie de lieux particuliers. Un lieu particulier peut être par exemple un point de programme, un chemin d'exécution, une routine, une boucle de programmation (itérative et/ou récursive), un code de rattrapage d'exception ou d'interruption, etc.
9. Procédé selon la revendication 6, caractérisé en ce que les événements qualifiés consistent en des événements portant sur des valeurs ou des classes de valeurs particulières : paramètres des instructions ou opérations, routines appelées, arguments des routines, type d'une exception levée ou rattrapée, état du programme et/ou du système, état de disponibilité des ressources du système d'exécution, valeur du temps passé dans l'exécution du programme (temps total et/ou temps détaillé pour les diverses opérations effectuées), etc.
10. Procédé selon la revendication 6, caractérisé en ce que les événements composés consistent en des combinaisons d'événements permettant notamment d'exprimer l'historique de l'exécution via la succession d'événements, par exemple le fait que l'appel d'une certaine routine se produise uniquement après l'appel d'une autre.
11. Procédé selon la revendication 1, caractérisé en ce que les tests comprennent notamment :
- des entrées (notamment inputs et/ou variations de disponibilité des ressources et/ou interruptions et/ou marques de temps) à soumettre au programme et/ou au système d'exécution, et - des sorties (notamment outputs et/ou événements) à observer pour évaluer lesdites caractéristiques opérationnelles.
12. Procédé selon l'une des revendications précédentes, caractérisé en ce que la suite de tests comprend des tests : - dont les entrées à soumettre sont fournies par un programme de test et/ou par un opérateur de test, le programme de test pouvant indiquer à l'opérateur de test des opérations particulières à effectuer sur la plate-forme de test, et - dont les sorties à observer sont contrôlées par un programme de test et/ou par un opérateur de test, le programme de test pouvant poser des questions à l'observateur concernant ses observations.
13. Procédé selon l'une des revendications précédentes, caractérisé en ce que, durant l'exécution des tests avec opérateur de test, un dispositif de contrôle assiste l'opérateur de test en consignant les observations dudit opérateur de test et en lui présentant une vision actualisée des caractéristiques opérationnelles évaluées jusqu'à lors afin qu'il puisse estimer s'il y a lieu de poursuivre le test ou si les degrés de précision atteints sont suffisants.
14. Procédé selon la revendication 13, caractérisé en ce que la vision des caractéristiques opérationnelles évaluées présentées à l'opérateur de test comprend une vision de l'exécution du programme constituée par une représentation indiquant si certaines événements ont déjà eu lieu et/ou dans quelles circonstances, notamment :
- indiquant si certains points et/ou branches et/ou chemins d'exécution ont déjà ou n'ont pas encore été parcourus lors de l'exécution, et/ou
- comportant des informations sur l'état du programme et/ou du système d'exécution en lesdits points et/ou lesdites branches et/ou lesdits chemins d'exécution.
15. Procédé selon la revendication 1, caractérisé en ce que :
- certaines desdites caractéristiques opérationnelles dépendent d'un ou plusieurs environnements d'exécution (matériels et/ou logiciels) cibles pour le programme ainsi que d'une ou plusieurs configurations cibles desdits environnements (notamment en ce qui concerne les ressources et/ou fonctionnalités disponibles et/ou autorisées dans lesdits environnements), et
- la plate-forme de test inclut et/ou émule et/ou simule lesdits environnements d'exécution cibles avec leurs configurations cibles.
16. Procédé selon la revendication 1, caractérisé en ce que lesdites caractéristiques opérationnelles à évaluer comprennent la vérification de propriétés et en ce que : - lors de la première étape, l'analyse statique détermine des propriétés que le programme satisfait avec certitude et des propriétés que le programme transgresse avec certitude (les autres propriétés étant des propriétés que l'analyse ne détermine pas avec certitude comme satisfaites ou transgressées) ;
- lors de la seconde étape, le programme est soumis aux seuls tests de la suite de tests qui concernent les propriétés du programme que l'analyse statique n'a pas déterminées avec certitude comme satisfaites ou transgressées.
17. Procédé selon l'une des revendications précédentes, caractérisé en ce que, pour toute propriété qui est une règle de la forme « si E alors Ci et ... et CM » où E est un événement et Ci, ..., C^ sont des conditions :
- lors de la première étape, l'analyse statique détermine l'ensemble des points d'exécution tels que : - ou bien E est indéterminé et au moins une des conditions Ct n'est pas vraie avec certitude (c'est-à-dire C, est fausse avec certitude ou indéterminée), - ou bien E est déterminé avec certitude comme vrai, aucune des conditions Ci n'est déterminée avec certitude comme fausse, et au moins une des conditions C, est indéterminée ;
18. Procédé selon l'une des revendications précédentes, caractérisé que ce que :
- lors de la première étape, l'analyse statique détermine d'une part quels sont les points d'exécution en lesquels ledit événement se produit avec certitude ou peut se produire, et d'autre part la valeur de vérité desdites conditions auxdits points d'exécution lorsque ledit événement se produit ;
- lors de la seconde étape, lorsqu'au cours d'un test ledit événement se produit ou peut se produire en un point d'exécution PE, seules sont évaluées les conditions qui n'ont pas été établies par l'analyse statique comme vraies avec certitude au point d'exécution PE lorsque ledit événement se produit.
19. Procédé selon la revendication 1, caractérisé en ce que lesdites caractéristiques opérationnelles à évaluer comprennent la vérification de règles qui déterminent si le programme est valide (respectivement correct) et en ce que, lors de la troisième étape, les caractéristiques opérationnelles du programme comprenant la vérification de règles sont constituées selon la procédure suivante :
- Si les résultats de l'analyse statique de la première étape indiquent que chacune desdites règles est satisfaite avec certitude, alors il est établi que le programme est valide (respectivement correct) avec certitude.
- Si les résultats de l'analyse statique de la première étape et/ou de l'exécution des tests de la deuxième étape indiquent qu'aucune desdites règles n'est transgressée avec certitude et qu'au moins une desdites règles est de statut indéterminé, alors il est établi que le programme est peut-être valide (respectivement correct), peut-être invalide (respectivement incorrect).
- Si les résultats de l'analyse statique de la première étape et/ou de l'exécution des tests de la deuxième étape indiquent qu'au moins une règle est transgressée avec certitude pour certaines entrées du programme, alors il est établi que le programme est invalide (respectivement incorrect) avec certitude.
20. Procédé selon la revendication 1, caractérisé en ce que, si les résultats de l'analyse statique de la première étape et/ou de l'exécution des tests de la deuxième étape indiquent qu'aucune desdites règles n'est transgressée avec certitude et qu'au moins une desdites règles est de statut indéterminé et que chacune desdites règles de statut indéterminé est systématiquement satisfaite lors des tests de la deuxième étape, alors il est établi que le programme est vraisemblablement valide (respectivement correct).
21. Procédé selon la revendication 1, caractérisé en ce que lesdites caractéristiques opérationnelles comprennent la satisfaction de règles de bon fonctionnement et/ou de portabilité et/ou d'interopérabilité et/ou de sécurité et/ou d'éthique et/ou de déontologie et/ou d'ergonomie et/ou de style.
22. Procédé selon la revendication 1, caractérisé en ce que lesdites caractéristiques opérationnelles à évaluer :
- sont indépendantes du programme, et/ou - portent sur la ou les classes d'applications auxquelles appartient le programme et comprennent des vérifications de propriétés spécifiques à cette ou ces classes, et/ou
- portent sur le comportement attendu du programme étant donné sa spécification.
23. Système d'exécution mettant en œuvre le procédé selon l'une des revendications précédentes.
PCT/FR2005/003241 2004-12-22 2005-12-20 Procede pour l’evaluation de caracteristiques operationnelles d’un programme WO2006070113A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP05850582A EP1836580A2 (fr) 2004-12-22 2005-12-20 Procede pour l'evaluation de caracteristiques operationelles d'un programme

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0413768 2004-12-22
FR0413768A FR2879775B1 (fr) 2004-12-22 2004-12-22 Procede pour l'evacuation de caracteristiques operationnelles d'un programme

Publications (2)

Publication Number Publication Date
WO2006070113A2 true WO2006070113A2 (fr) 2006-07-06
WO2006070113A3 WO2006070113A3 (fr) 2007-07-26

Family

ID=34955138

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/003241 WO2006070113A2 (fr) 2004-12-22 2005-12-20 Procede pour l’evaluation de caracteristiques operationnelles d’un programme

Country Status (3)

Country Link
EP (1) EP1836580A2 (fr)
FR (1) FR2879775B1 (fr)
WO (1) WO2006070113A2 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5832270A (en) * 1994-06-23 1998-11-03 International Business Machines Corporation System having automatic insertion of hooks into object-oriented software for visualizing execution thereof

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0869433A3 (fr) * 1997-03-31 1999-10-06 Siemens Corporate Research, Inc. Système et procédé de dévelopement de test pour logiciel avec interface utilisateur graphique
US6421822B1 (en) * 1998-12-28 2002-07-16 International Business Machines Corporation Graphical user interface for developing test cases using a test object library

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5832270A (en) * 1994-06-23 1998-11-03 International Business Machines Corporation System having automatic insertion of hooks into object-oriented software for visualizing execution thereof

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CASSET L ET AL: "Formal development of an embedded verifier for java card byte code" PROCEEDINGS INTERNATIONAL CONFERENCE ON DEPENDABLE SYSTEMS AND NETWORKS. DSN 2002. WASHINGTON, D.C., JUNE 23 - 26, 2002, INTERNATIONAL CONFERENCE ON DEPENDABLE SYSTEMS AND NETWORKS, LOS ALAMITOS, CA, IEEE COMP. SOC, US, 23 juin 2002 (2002-06-23), pages 51-56, XP010600283 ISBN: 0-7695-1597-5 *
ERIC VÉTILLARD: "Proactive Security for Mobile Applications" TRSUTED LOGIC ONLINE PUBLICATIONS, octobre 2004 (2004-10), pages 1-7, XP002344467 http://www.trustedlogic.com/presentations. html *
PFAHLER AND GÜNTHER: "Cate: A System for Analysis and Test of Java Card Applications" PROCEEDINGS OF 1ST INT. WORKSHOP ON SOFTWARE QUALITY, octobre 2004 (2004-10), pages 157-163, XP008052392 *

Also Published As

Publication number Publication date
FR2879775A1 (fr) 2006-06-23
EP1836580A2 (fr) 2007-09-26
FR2879775B1 (fr) 2007-03-02
WO2006070113A3 (fr) 2007-07-26

Similar Documents

Publication Publication Date Title
Li et al. Static analysis of android apps: A systematic literature review
Bhoraskar et al. Brahmastra: Driving Apps to Test the Security of {Third-Party} Components
Artzi et al. Finding bugs in dynamic web applications
US8516449B2 (en) Detecting and localizing security vulnerabilities in client-server application
US9043761B2 (en) Fault localization using condition modeling and return value modeling
Böhme STADS: Software testing as species discovery
Finifter Exploring the relationship between web application development tools and security
Iannillo et al. Chizpurfle: A gray-box android fuzzer for vendor service customizations
Antunes et al. Penetration testing for web services
Berlato et al. A large-scale study on the adoption of anti-debugging and anti-tampering protections in android apps
Anderson et al. Inglorious Installers: Security in the Application Marketplace.
US20150143342A1 (en) Functional validation of software
Cotroneo et al. Evolutionary fuzzing of android OS vendor system services
Qiu et al. AppTrace: Dynamic trace on Android devices
EP1700218A2 (fr) Procede de determination de caracteristiques operationnelles d&#39;un programme
WO2020192179A1 (fr) Procédé, dispositif et système de détection de sécurité sur la base d&#39;une application ios
Antunes et al. Evaluating and improving penetration testing in web services
Soud et al. A fly in the ointment: an empirical study on the characteristics of Ethereum smart contract code weaknesses
Xiao et al. Understanding and mitigating remote code execution vulnerabilities in cross-platform ecosystem
Vimpari An evaluation of free fuzzing tools
WO2006070113A2 (fr) Procede pour l’evaluation de caracteristiques operationnelles d’un programme
Li Boosting static security analysis of android apps through code instrumentation
Meghanathan Source code analysis to remove security vulnerabilities in java socket programs: A case study
Ma Android application install-time permission validation and run-time malicious pattern detection
Lee et al. QDroid: Mobile application quality analyzer for app market curators

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2005850582

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2005850582

Country of ref document: EP