FR3047824B1 - Procede d'aide a la validation d'un systeme et dispositif d'aide associe - Google Patents

Abstract

Ce procédé (10) permet d'établir automatiquement, à partir d'exigences systèmes (Eg) devant être vérifiées et de tests (Ti) destinés à être appliqués au système au cours de la phase de validation, un rapport (R) de couverture et de traçabilité associant, à chaque test, une liste des exigences qu'il permet de vérifier. Ce procédé consiste à : formaliser (12) les exigences (Eg) en objectif (Oi); traduire (14) chaque objectif (Oi) en une pluralité de formules logiques (Fik) ; transformer (22) chaque script associé à un test (Tj) en un automate à états (Aj) ; appliquer (32) un algorithme de vérification de modèle pour vérifier si, oui ou non, chaque formule logique (Fik) est vérifiée par chaque automate à états (Aj), et obtenir un verdict de bas niveau (Vik,j); agréger les verdicts de bas niveau (Vik,j) correspondant à un même objectif (Oi) de manière à obtenir un verdict de haut niveau (Vi) ; et générer (34) le rapport (R) à partir des verdicts de haut niveau (Vi) et des verdicts de bas niveau (Vik,j).

Description

PROCEDE D’AIDE A LA VALIDATION D’UN SYSTEME ET DISPOSITIF D’AIDE ASSOCIE L’invention a pour domaine celui des procédés et des dispositifs d’aide à la validation d’un système.

Une phase importante du cycle de vie d’un système est constituée par la phase de validation. En tenant compte des fonctionnalités qu’un système doit offrir, ainsi que de son contexte d’utilisation, la phase de validation doit permettre de vérifier qu’un certain nombre d’exigences sont effectivement respectées par le système. De telles exigences sont par exemple constituées par les besoins des utilisateurs finaux du système, le comportement opérationnel nominal attendu du système, la compatibilité du système avec des niveaux de sûreté prédéterminés, le respect de contraintes de sécurité, les objectifs de performance attendues du système, etc.

Compte tenu d’une pluralité d’exigences, un ensemble de tests est mis au point pour valider le système selon ces exigences. Les tests de cet ensemble de tests peuvent être écrits manuellement par un expert métier et/ou générés automatiquement en utilisant un outil informatique adapté, notamment fondé sur un modèle informatique du système à valider. De tels outils sont connus de l’homme du métier.

Cependant, étant donné un ensemble de tests, il est difficile de déterminer a posteriori et rigoureusement qu’elles sont les exigences qui sont effectivement couvertes et vérifiées dans la mise en oeuvre de ces tests et/ou quels sont les tests qui sont redondants, c’est-à-dire que leur mise en oeuvre conduit à la validation du système selon la même exigence.

De plus, à chaque modification apportée au système, il est nécessaire de le valider à nouveau. Une modification d’un système peut induire de nouvelles exigences, ne serait-ce que fonctionnelles. L’ensemble de tests initialement généré et utilisé pour la validation du système n’est alors plus forcément adapté au système modifié et aux exigences associées. Des tests existants doivent être modifiés et/ou de nouveaux tests doivent être ajoutés pour valider les modifications apportées au système.

Les tests à modifier ou à ajouter sont rarement déterminés avec rigueur et ils viennent souvent en redondance avec des tests existants. Par exemple, il est difficile de déterminer de manière automatique le plus petit sous-ensemble de tests à modifier ou à ajouter.

Il est donc recommandé de générer à nouveau un ensemble de tests pour chaque modification du système. L’invention a donc pour but de résoudre ce problème, en proposant notamment un procédé d’aide à la décision pour la phase de validation d’un système permettant de générer automatiquement un rapport de couverture et de traçabilité des exigences d’un système par un ensemble de tests.

Pour cela, l’invention a pour objet un procédé d’aide à la décision pour une phase de validation d’un système permettant d’établir automatiquement, à partir d’une pluralité d’exigences systèmes que le système doit vérifier et d’un ensemble de tests destinés à être appliqués au système au cours d’une phase de validation, un rapport de couverture et de traçabilité associant à chaque test de l’ensemble de tests, une liste des exigences que le test considéré permet effectivement de vérifier, le procédé consistant à : - formaliser les exigences systèmes en objectif ; - traduire chaque objectif en une pluralité de formules logiques ; - transformer chaque script associé à un test de l’ensemble de tests en un automate à états ; - appliquer un algorithme de vérification de modèle pour vérifier si, oui ou non, chaque formule logique est vérifiée par chaque automate à états, l’issue de la vérification correspondant à un verdict de bas niveau ; - agréger les verdicts de bas niveau des formules logiques correspondant à un même objectif de manière à obtenir un verdict de haut niveau, chaque verdict de haut niveau correspondant ainsi à un objectif ; et - générer le rapport de couverture et de traçabilité à partir, respectivement, des verdicts de haut niveau et des verdicts de bas niveau.

Suivant des modes particuliers de réalisation, le procédé comporte une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les combinaisons techniquement possibles : les formules logiques sont exprimées dans un langage logique du type logique à modalité temporelle. l’étape de traduction d’un objectif en une pluralité de formules logiques met en oeuvre au moins un patron de traduction. le procédé comporte une étape de minimisation du nombre de tests dans l’ensemble de tests, en fonction du rapport de couverture et de traçabilité généré. le procédé comporte une étape consistant à analyser automatiquement l’impact d’une modification de la pluralité des exigences système par rapport à un ensemble de tests prédéfini, à partir de la comparaison des rapports de couverture et de traçabilité obtenus avant et après ladite modification de la pluralité des exigences système. L’invention a également pour objet un dispositif d’aide à la validation d’un système permettant d’établir automatiquement, à partir d’une pluralité d’exigences systèmes que le système doit vérifier et d’un ensemble de tests destinés à être appliqués au système au cours d’une phase de validation, un rapport de couverture et de traçabilité associant à chaque test de l’ensemble de tests, une liste des exigences que le test considéré permet effectivement de vérifier, le dispositif étant un ordinateur programmé pour mettre en oeuvre le procédé présenté ci-dessus. L’invention et ses avantages seront mieux compris à la lecture de la description détaillée qui va suivre d’un mode de réalisation particulier, donné uniquement à titre d’exemple non limitatif, cette description étant faite en se référant aux dessins annexés sur lesquels : - la figure 1 est une représentation schématique sous forme de blocs du procédé selon l’invention d’aide à la décision par la mesure de la couverture et du degré de qualité d’un ensemble de tests pour une phase de validation d’un système ; et, - la figure 2 est une représentation schématique d’un dispositif pour la mise en oeuvre du procédé de la figure 1.

De manière générale, le procédé 10 d’aide à la décision pour la phase de validation d’un système prend, en entrée, une pluralité d’exigences système Eg (i étant un entier d’indexation des exigences) associées au système à valider, d’une part, et un ensemble de tests T, (j étant un entier d’indexation des tests) développés pour valider ledit système vis-à-vis de certaines exigences, qui ne se retrouvent pas forcément parmi les exigences Eg (dans le cas d’une modification du système à valider par exemple), d’autre part.

Il est à noter que les tests T, de l’ensemble de test peuvent avoir été générés automatiquement, au moyen par exemple d’un outil de test basé sur un modèle du système, ou à la main, par un agent métier.

La manière d’obtenir les exigences Eg et les tests T, est hors de la portée de la présente invention.

Le procédé 10 permet de générer, en sortie, un rapport R de traçabilité et de couverture de la pluralité d’exigences système Eg par l’ensemble de tests Tj.

Les exigences Eg peuvent se présenter sous différentes formes. Ces exigences peuvent par exemple se présenter sous la forme d’un texte et/ou d’un texte structuré et/ou d’un modèle. Les exigences Eg, qui constituent un ensemble hétérogène, ne peuvent donc pas être immédiatement comparées aux tests T,. C’est la raison pour laquelle le procédé 10 débute par une étape 12 de formalisation des exigences Eg de manière à en obtenir une description homogène sous forme d’objectifs O,. Cette étape 12 de formalisation est réalisée par des agents métiers spécialistes de la validation.

Avantageusement, l’étape 12 de formalisation s’appuie sur l’utilisation de patrons afin de faciliter la définition des objectifs O, de tests vis-à-vis des exigences Eg initiales.

Un patron se présente sous la forme d’une structure syntaxique prédéfinie, par exemple une forme : C => P. Les patrons sont composables entre eux via l’utilisation des opérateurs logiques usuels.

Un exemple d’un patron est l’étude de cas selon un ensemble de classes d’équivalence fonctionnelle C défini sur n variables du système :

Dans ce patron, l’expert métier identifie selon des plages de valeurs E,m (correspondant à la valeur de la variable vm lorsque l’exigence E, est remplie) les propriétés P, qui doivent être respectées par le système.

Le procédé 10 se poursuit par une étape 14 de traduction automatique de chaque objectifs O, en une pluralité de formules logique Fik(où k est un entier indexant l’ensemble des formules logiques associées à un même objectif O,). Les formules logiques respectent par exemple un langage, de préférence un langage du type logique à modalité temporelle. Cette étape 14 de traduction est systématique, au sens où elle est appliquée à chacun des objectifs O, dérivant des exigences systèmes.

Au cours de l’étape 14, lorsque des patrons sont utilisés, un patron est traduit automatiquement en 2(k+1 ) formules logiques. Plus précisément, pour chaque branche de la forme C => P, sont générées :

Une formule E0((Ca-> P)A(OFail)) qui permet de vérifier que si il existe un chemin dans un test tel que si jamais la propriété P n’est pas vérifiée lorsque les variables sont évaluées selon la classe d’équivalence C alors le test conduira à un verdict « Fail >>. En d’autres mots, le test sera en capacité de détecter les défauts du système relatif à cette exigence.

Une formule A(-iPass W (CaP)) qui permet de vérifier que dans tous les chemins d’un test, le verdict « Pass >> est émis si P est vérifié lorsque les

variables sont évaluées selon la classe d’équivalence C. En d’autres mots, le test sera en capacité de vérifier et d’émettre un verdict relativement à l’exigence.

Parallèlement, les entrées constituées par les différents tests Tj5 qui se présentent sous la forme de script, sont transformés à l’étape 22 en autant d’automate à états A? A l’étape 32 du procédé 10, un algorithme de vérification de modèle (« model checker >> en anglais) est utilisé afin d’établir, pour chaque automate à états Aj et pour chaque formule logique Fik, si, oui ou non, la formule logique considérée est vérifiée par le test considéré. Le résultat binaire de cette vérification est stocké dans une variable VikJ, dénommée verdict de bas niveau. A la sortie de l’étape 32, on obtient donc une série de verdicts, chaque verdict étant un nombre binaire 0 ou 1. Le nombre de verdicts est le produit du nombre de formules logiques, résultant de la traduction des objectifs, multiplié par le nombre d’automates à états, c’est-à-dire le nombre de tests de l’ensemble des tests. A l’étape 34, les verdicts de bas niveau Vikj obtenus en sortie de l’étape 32 et correspondant à un même objectif O, sont agrégés afin d’obtenir des verdicts de niveau intermédiaire Vijk.

Enfin à l’étape 36, les verdicts de niveau intermédiaire Vijk sont agrégés en un verdict haut niveau V,. Chaque verdict de haut niveau V, correspond donc à un objectif O,. Il quantifie par un facteur allant de 0 à 100 (c’est-à-dire en pourcentage) le taux de couverture de l’objectif O, par l’ensemble de tests T, pris en entrée.

Plus précisément, les étapes d’agrégation sont formalisées comme suit : - Vijk correspond à la conjonction des VikJ, en d’autres termes il vaut 0 si aucun test ne vérifie la formule Fik et 1 sinon ; - V, est la somme sur k des Vik divisée par la borne supérieur de k, le tout multiplié par 100 ;

Puis à l’étape 40, le rapport R de couverture et de traçabilité de l’ensemble de tests Tj pour la pluralité d’exigences systèmes Eg est produit.

De préférence, un tel rapport R associe sous forme tabulaire à chaque test Tj5 les exigences Eg qu’il permet effectivement de couvrir au cours de la validation du système, ainsi qu’un taux de couverture global de la pluralité d’exigences Eg par rapport à l’ensemble de tests T,. Ce taux de couverture correspond à une mesure par exemple exprimée en pourcentage du nombre total d’exigences vérifiées. Cette mesure peut par exemple affecter des poids différents aux objectifs en fonction de leur importance.

Par exemple, le taux de couverture Vg de l’exigence Eg relativement à l’objectif O, est calculé en pondérant le taux de couverture V, de l’objectif O, par le taux que représente cette exigence Eg dans le fichier de description de l’objectif O,.

Par exemple, la traçabilité s’exprime sous la forme d’une matrice de traçabilité entre tests et objectifs se calcule en considérant les variables Vikj. En effet, il existe un lien de traçabilité entre l’objectif O, et le test T, si et seulement il existe au moins un k tel que Vikj est égale à 1. Par transitivité sur les liens entre objectifs et exigences déclarés dans le fichier de description des objectifs, la matrice de traçabilité entre test T, et exigence Eg est déduite. A la figure 2, on a représenté schématiquement un dispositif 110 d’aide à la validation d’un système. Il s’agit d’un dispositif informatique comportant des moyens de calcul tels qu’un processeur, et des moyens de mémorisation, tels que des mémoires vives et mortes. Les moyens de mémorisation stockent notamment les instructions de programmes d’ordinateur propres à être exécutées par les moyens de calcul. En particulier, les moyens de mémorisation (111 sur la figure 2) stockent un programme permettant, lors de son exécution par les moyens de calcul, de mettre en oeuvre le procédé 10 selon l’invention.

Ainsi, le dispositif 110 comporte une interface homme machine 112 permettant à un agent métier de formaliser les exigences systèmes sous forme d’objectifs.

Le dispositif 110 comporte un module 114 de traduction qui, lorsqu’il est appelé, permet de mettre les objectifs appliqués en entrée sous forme d’une ou plusieurs formules logiques.

Le dispositif 110 comporte un module 122 propre à lire les scripts correspondant à l’ensemble de tests et contenus dans les moyens de mémorisation de manière à générer automatiquement autant d’automate à états.

Le dispositif 110 comporte un module 132 de vérification propre, lorsqu’il est appelé, à lancer l’exécution de l’algorithme de vérification de modèle de manière à générer, à partir d’une pluralité de formules logiques et d’une pluralité d’automates à états, une série de verdicts de bas niveau.

Le dispositif 110 comporte un module 134 d’élaboration de verdict de niveau intermédiaire à partir des différents verdicts de bas niveau des formules logiques associées au même objectif et un module 136 d’élaboration de verdict haut niveau à partir des différents verdicts de niveau intermédiaire.

Enfin, le dispositif 110 comporte un module 140 de compilation des verdicts de haut niveau de manière à générer en sortie un rapport de couverture et de traçabilité.

La présente invention est ainsi fondée sur un algorithme de vérification de modèle. Cette famille d’algorithmes est connue en soi. D’un point de vue général, un tel algorithme consiste à prendre en entrée le modèle que l’on souhaite vérifier, en particulier un modèle se présentant sous la forme d’un automate à états, ainsi que la propriété que doit vérifier ledit modèle, par exemple exprimée sous la forme d’une proposition logique. L’algorithme de vérification de modèle va alors explorer l’ensemble de l’espace des états atteignables par le modèle puis vérifier si la propriété est vraie ou fausse pour chacun de ces états atteignables.

Si la propriété est fausse pour l’un de ces états atteignables, alors l’algorithme de vérification de modèle donnera le chemin, en termes de suite d’états de l’automate à états, menant vers cet état invalidant la propriété. Un tel chemin est généralement dénommé contre-exemple.

Il existe plusieurs techniques pour que l’algorithme de vérification de modèle explore l’espace des états possibles du modèle : structure de Kripke, diagramme de décision binaire dit BDD (selon l’acronyme anglais), formule SMT (« Satisfiability Modulo Théories >> ), etc.

De même, différents langages logiques peuvent être utilisés pour formaliser la propriété : LTL, CTL, CTL* etc. L’homme du métier constatera que, dans la présente invention, l’algorithme de vérification de modèle est détourné de son utilisation classique. En effet, dans la présente invention on ne cherche pas à vérifier un modèle du système, mais à évaluer la capacité d’un ensemble de tests à vérifier des propriétés sur un système. Cette utilisation de l’algorithme de vérification de modèle est rendue possible grâce à la transformation de chaque script de test en un automate à états, ainsi que l’expression des exigences système en formules logiques. Pour rendre possible cette vérification il est de plus nécessaire de retranscrire la sémantique propre à l’action de tester un système dans les automates correspondant aux tests et dans les formules logiques correspondant aux objectifs de test. Par exemple, pour vérifier qu’une propriété P est bien testée par l’ensemble de tests pour un système donné, il est nécessaire de trouver un ou des tests qui amènent le système dans un ou des états où cette propriété P peut être évaluée et que tous les états des tests accessibles à partir de ces états sont des états de verdicts correctes (« Fail si -> P» et « Pass si P >>). L’invention permettant d’évaluer automatiquement les exigences parmi une pluralité d’exigences systèmes effectivement couvertes par un ensemble de tests, elle peut être avantageusement mise en oeuvre dans des procédés plus généraux.

En effet, disposant maintenant d’un procédé automatique pour évaluer la pertinence d’un ensemble de tests vis-à-vis d’une pluralité d’exigences, il est possible de proposer des procédés permettant de rejeter des tests qui ne sont pas ou peu pertinents dans un ensemble de tests prédéfini. Cette pertinence peut s’évaluer par exemple en mesurant le gain obtenu lors de l’adjonction d’un nouveau test sur le taux de couverture global. Ce type de procédé peut s’utiliser dans des cas variés comme lorsque : - le développement des tests est sous-traité à une tierce partie. En effet, seul les tests pertinents seront acceptés et livrés.

Les tests sont générés automatiquement par un outil dédié. Dans ce contexte ce mécanisme permet de discriminer des tests peu pertinents et de réorienter la génération de tests ou encore de fournir un critère d’arrêt à la génération de tests.

De même, disposant d’une estimation quantitative pour étiqueter chaque test avec les exigences qu’il permet de couvrir, il est possible de proposer des procédés de détermination de l’ensemble minimum de tests qui couvre l’ensemble des exigences définies en entrée. Un tel procédé met en oeuvre une procédure d’optimisation combinatoire et d’évaluation automatique de la pertinence d’un ensemble de tests sur la base de rapport obtenus par la mise en oeuvre du présent procédé.

Enfin il est possible de proposer des procédés d’analyse automatique de l’impact d’une modification des exigences systèmes sur la couverture offerte par un ensemble de tests prédéfini.

Ainsi, la présente invention permet d’évaluer quantitativement et a postériori la capacité d’un ensemble de tests à vérifier à un certain nombre d’exigence système. Cette évaluation est dite a postériori puisqu’elle est complètement indépendante de la manière dont sont obtenus les ensembles de tests à évaluer. La présente invention convient donc parfaitement au cas où les ensembles de tests générés sont importants, où la combinatoire de traçabilité et d’évaluation de couverture devient difficile à maîtriser et où les critères de qualité sont importants. En particulier cette invention donne des gages de qualité aux processus de validation dans les cas relativement courant où les équipes de spécification et d’architecture d’un système sont différentes et éloignées physiquement des équipes de développement des scripts de validation.

La présente invention est particulièrement utile dans un contexte où l’ensemble des tests est généré de différentes manières, soit par des outils dédiés, soit par des agents métiers, et où les exigences que le système doit vérifier sont hétérogènes (exigences opérationnelles, de sûreté, de performance, etc.)

Claims (6)

1. REVENDICATIONS

   1. - Procédé (10) d’aide à la décision pour une phase de validation d’un système permettant d’établir automatiquement, à partir d’une pluralité d’exigences systèmes (Eg) que le système doit vérifier et d’un ensemble de tests (Ti) destinés à être appliqués au système au cours d’une phase de validation, un rapport (R) de couverture et de traçabilité associant à chaque test de l’ensemble de tests, une liste des exigences que le test considéré permet effectivement de vérifier, le procédé consistant à : - formaliser (12) les exigences systèmes (Eg) en objectif (O,); - traduire (14) chaque objectif (O,) en une pluralité de formules logiques (Fik) ; - transformer (22) chaque script associé à un test (Tj) de l’ensemble de tests en un automate à états (Aj) ; - appliquer (32) un algorithme de vérification de modèle pour vérifier si, oui ou non, chaque formule logique (Fik) est vérifiée par chaque automate à états (A,), l’issue de la vérification correspondant à un verdict de bas niveau (Vikj); - agréger les verdicts de bas niveau (Vikj) des formules logiques (Fik) correspondant à un même objectif (O,) de manière à obtenir un verdict de haut niveau (V,), chaque verdict de haut niveau correspondant ainsi à un objectif ; et - générer (40) le rapport (R) de couverture et de traçabilité à partir, respectivement, des verdicts de haut niveau (V,) et des verdicts de bas niveau (Vikj).
2. 2. - Procédé selon la revendication 1, dans lequel les formules logiques sont exprimées dans un langage logique du type logique à modalité temporelle.
3. 3. - Procédé selon l’une quelconque des revendications précédentes, dans lequel l’étape de traduction (14) d’un objectif (O,) en une pluralité de formules logiques (Fik) met en œuvre au moins un patron de traduction.
4. 4. - Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comporte une étape de minimisation du nombre de tests dans l’ensemble de tests, en fonction du rapport de couverture et de traçabilité généré.
5. 5. - Procédé selon l’une quelconque des revendications 1 à 3, comportant une étape consistant à analyser automatiquement l’impact d’une modification de la pluralité des exigences système par rapport à un ensemble de tests prédéfini, à partir de la comparaison des rapports de couverture et de traçabilité obtenus avant et après ladite modification de la pluralité des exigences système.
6. 6.- Dispositif (110) d’aide à la validation d’un système permettant d’établir automatiquement, à partir d’une pluralité d’exigences systèmes (Eg) que le système doit vérifier et d’un ensemble de tests (T,) destinés à être appliqués au système au cours d’une phase de validation, un rapport (R) de couverture et de traçabilité associant à chaque test de l’ensemble de tests, une liste des exigences que le test considéré permet effectivement de vérifier, le dispositif étant un ordinateur programmé pour mettre en œuvre le procédé d’aide selon l’une quelconque des revendications 1 à 5.