FR2879775A1 - Procede pour l'evacuation de caracteristiques operationnelles d'un programme - Google Patents

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

La présente invention concerne un procédé pour l'évaluation de

caractéristiques 10 opérationnelles d'un programme ainsi qu'un système d'exécution mettant en oeuvre 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 Peel ).

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[] bd.= apdu.getBufferQ; byte cla = buf[0]; byte ins = buf[1]; switch(cla) { case 0: // Pas de mesure sécuritaire switch(ins) { case (byte) 202: // GET DATA break; default: throwlt(S W_INS_NOT_SUPPORTED); } break; case (byte) 132: // Mesure de sécurité propriétaire switch(ins) { case (byte) 218: // PUT DATA break; default: throwlt(S W_1NS_NOT_SUPPORTED); } break; default: throwlt(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 25 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 à l'encontre 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 "CSDESKeyStrength" 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 TYPE DES .

_

Le fragment de programme suivant satisfait le critère sécuritaire CSDESKeyStrength: void install(byte[] buf, short off, short len) { switch(buf[off]) { 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; 20} 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 PRIVATE (différent de TYPE DES ).

En revanche, le fragment de programme suivant ne satisfait pas le critère CSDESKeyStrength: void install(byte[] buf, short off, short len) { key = buildKey(buftoff], getShort(buf, off+l)); 5} 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[off] (l'octet stocké à l'index off du tableau buf ) soit égal à TYPE_DES et que getShort(buf, off+l) (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.

Il 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); smsconn.newMessage(MessageConnection.TEXT_MES SAGE); for(inti=0;i<1000; i++) sendMesg(smsconn); smsconn.closeO; void sendMesg(MessageConnection smsconn) { txtmesg.setPayloadText("Je suis un parasite qui coûte cher"); smsconn.send(txtmesg); 35} - 10 - Un autre critère sécuritaire "CSNoSMSSurtax" 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 7xxxx sont surtaxés de 50 centimes d'euro.

Ainsi, le fragment de programme suivant transgresse-t-il le critère sécuritaire: 10 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.closeQ; 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 1NS 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 15 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.

- 12 - 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.

- 13 - 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 plateforme 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 10 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 Cl, ..., 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 20 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 CI, ..., 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. - 15 - 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://3xxxx".

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 peuventporter 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 Peel . 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) Il est certain que le programme est valide.

(2) Il est vraisemblable que le programme soit valide.

(3) Il est possible, mais pas certain, que le programme soit valide.

(4) Il 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 plate-forme 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'oeil 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 - 18 - 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 CSDESKeyStrength, 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 30 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. 10 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 oeuvre 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 oeuvre 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 Connector.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 - 21 - 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 30 é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 - 22 - 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 - 23 - 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 plateforme 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).

- 24 - 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 15 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 - 25 - 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-NoSMS Surtax" 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 "7xxxx".

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 - 26 - 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 25 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).

- 27 - 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 Cl et... et CN , 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 etactions 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 CI et... et CN .

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.

- 29 - 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.

- 30 - 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'oeuvre 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 20 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 25 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 30 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 - 32 - 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; - 33 - 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 30 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: - 34 - É 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 20 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) ; -35 - 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 - 37 - 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 fournie 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 - 38 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 - 39 - 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 5 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 plate-forme 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 20 si E alors CI 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: É Il est certain que l'événement E se produit.

É Il est possible, mais pas certain, que l'événement E se produise.

É Il est certain que l'événement E ne se produit pas.

Les informations nécessaires pour établir l'occurrence ou la nonoccurrence 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 plateforme 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.

Il 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 êtreimmé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 30 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. -41 -

Pour sa part, l'analyse statique détermine, pour une règle si E alors Cl 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 CC dynamiquement falsifiable, c'est-à-dire qui n'est pas statiquement déterminée comme vraie, peut avoir trois statuts différents: É Il est certain que la condition C; est vraie au point d'exécution PE.

É Il est certain que la condition C; est fausse au point d'exécution PE.

É Il n'est pas établi avec certitude si la condition CÉ 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: - 42 - É Il 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).

É Il 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 suffit à 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 30 (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.

- 43 - 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 Cl et... et CN . Parmi les conditions E, CI, ..., CN, 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 "sms://3xxxx" (condition KI) . La vérification de l'événement El et de la condition KI de cette règle est automatisable. La règle R2 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 E2), le programme a affiché un message signalant l'envoi d'un SMS et demandé l'autorisation de l'utilisateur (condition K2) . Dans ce second cas, la vérification de l'occurrence de l'événement E2 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 oeuvre 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 Cl et... et CN , trois cas exclusifs les uns des autres sont possibles: É Il 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 C; est déterminée avec certitude comme vraie.

É Il 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 C; 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 C; est indéterminée.

É Il 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 C; 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 CI et... et CN 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 - 45 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 PP1 et PP2, le premier que l'analyse statique peut déterminer comme étant de la forme "sms://3xxxx", l'autre restant indéterminé, et deux appels à MessageConnection.send au point de programme PP3 et PP4. Les exigences de test comprennent alors les deux règles RI et R2, les deux points de programme PP2, PP3 et PP4, et pour PP2 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é .

- 46 - 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, PP3 et PP4. À chaque fois que l'exécution atteint le point de programme PP2, la condition KI 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 RI 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 PP3 ou PP4, 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 30 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 C, 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 Cl et... et CN , 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 PP3 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 15 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. - 49 - 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 (23)

- 50 - 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 15 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 - 52 - 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 - 53 - 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: - 54 - 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 CN où E est un événement et CI, ..., CN 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 C, 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 C, 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 - 55 - 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 5 spécification.

23. Système d'exécution mettant en oeuvre le procédé selon l'une des revendications précédentes.