FR3044126A1

FR3044126A1 - Systeme et procede pour creer automatiquement des cas de tests a base d'exigences liees a un logiciel critique

Info

Publication number: FR3044126A1
Application number: FR1661158A
Authority: FR
Inventors: Meng Li; Michael Richard Durling; Kit Yan Siu; Italo Oliveira; Han Yu; Conto Augusto Marasca De
Original assignee: General Electric Co
Current assignee: General Electric Co
Priority date: 2015-11-20
Filing date: 2016-11-17
Publication date: 2017-05-26
Anticipated expiration: 2036-11-17
Also published as: GB2545800A; CN107066375A; CA3035176A1; US20180196739A1; US9940222B2; CN110245067B; CA2948250A1; FR3044126B1; JP2017097862A; CN114996115A; CA2948250C; JP6307140B2; BR102016026988A2; CN110245067A; BR102019004568A2; CN107066375B; US20170147482A1

Abstract

Un procédé pour générer automatiquement des cas de tests à base d'exigences comporte la construction (205) dans un outil de mise au point à base de modèles, d'un modèle d'architecture logicielle dérivé automatiquement d'informations architecturales d'un modèle de conception logicielle, l'attribution (210) de modèles d'exigences à des blocs/opérateurs du modèle d'architecture logicielle, et la création (215), à partir de l'architecture logicielle, de cas de tests à base d'exigences au niveau composants.

Description

Système et procédé pour créer automatiquement des cas de tests à base d'exigences liées à un logiciel critique

Un logiciel critique tel qu'un logiciel à usage aéronautique doit, conformément à des normes de certification (p.ex. DO-178B/C pour un logiciel à usage aéronautique), faire l'objet d'une vérification rigoureuse en regard d'objectifs de certification. Les tests représentent une part essentielle du processus de vérification. Générer manuellement des cas de tests à partir des exigences est difficile et chronophage, surtout avec un gros logiciel complexe.

Des cas de tests et/ou des procédures de tests générés automatiquement sur la base des exigences liées à un logiciel de haut niveau peuvent contribuer à réduire le coût induit par des activités manuelles de création de cas de tests et de vérification. Ces cas de tests et/ou procédures de test générés à partir des spécifications peuvent être exécutés à l'aide d'un conducteur de tests sur les mises en œuvre associées de conception de bas niveau.

Les outils et/ou modèles de tests selon la technique antérieure ne sont pas à même de générer des cas de tests à base d'exigences à différents niveaux dans le modèle de conception. Les cas de tests générés produits par des outils classiques ne peuvent pas être directement exécutés sur les composants à multiples niveaux de conception. L'invention sera mieux comprise à l'étude détaillée de quelques modes de réalisation pris à titre d'exemples non limitatifs et illustrés par les dessins annexés sur lesquels : -la Figure 1 représente un système pour générer automatiquement des cas de tests à base d'exigences selon des formes de réalisation ; -la Figure 2 illustre un processus pour tester un logiciel selon des formes de réalisation ; -les figures 3A à 3D illustrent un modèle d'architecture logicielle dérivé automatiquement d'une conception logicielle selon des formes de réalisation ; -la Figure 4 illustre un processus pour la création de cas de tests au niveau composants selon des formes de réalisation ; -la Figure 5 représente un modèle d'exigences selon des formes de réalisation ; -la Figure 6 représente un modèle d'exigences avec des objectifs de tests associés selon des formes de réalisation ; -la Figure 7 représente un modèle de couverture d'états logiques avec des objectifs de tests associés selon des formes de réalisation ; -les figures 8A et 8B représentent un modèle de masquage d'entrées avec des objectifs de tests associés selon des formes de réalisation ; -la Figure 9 illustre un processus de création et de vérification de scripts de tests selon des formes de réalisation ; -la Figure 10 illustre un exemple de conception d'architecture logicielle et les informations de traçabilité d'exigences correspondantes selon des formes de réalisation ; la Figure 11 représente un exemple de script de test au niveau unitaire selon des formes de réalisation ; et -la Figure 12 représente un exemple de script de test au niveau de l'intégration selon des formes de réalisation.

Selon des formes de réalisation, des systèmes et des procédés créent automatiquement un modèle d'architecture logicielle à partir de l'architecture de conception logicielle, ainsi que des modèles d'exigences pour automatiser la création de cas de tests sur la base d'exigences architecturales multiniveaux conformément au modèle d'architecture logicielle proposé.

Selon des formes de réalisation, le modèle d'architecture logicielle et son attribution d'exigences sont construits à l'aide d'un outil de mise au point à base de modèles (MBD) avec la représentation d'un organigramme hiérarchique de données. A la différence d'outils de MBD classiques, traditionnellement utilisés pour la conception de bas niveau, un outil de MBD selon des formes de réalisation crée automatiquement le modèle d'architecture logicielle d'après l'architecture de conception logicielle et crée des cas de tests correspondants pour les exigences au niveau système ou de niveau haut.

Des formes de réalisation de systèmes et procédés peuvent mettre en œuvre la création de cas de tests à base d'exigences au niveau composants afin de générer automatiquement des cas de tests pour des composants à différents niveaux dans l'architecture logicielle.

La Figure 1 représente un système 100 pour la création automatisée de cas de tests sur la base d'exigences selon des formes de réalisation. Le système 100 comporte un processeur de commande 110 qui exécute des instructions informatiques 131 pour commander le fonctionnement du système et de ses composants. Les instructions exécutables peuvent être stockées dans une mémoire de données 130, laquelle peut également stocker des données consultées et générées par le système. Le processeur de commande 110 peut être logé dans un ordinateur ou un serveur, et être interconnecté avec les divers composants par l'intermédiaire d'une liaison de communication 120. La liaison de communication peut être un bus interne, un réseau de communication électronique ou autre. Le système 100 peut générer des cas de tests à partir d'exigences au niveau système et/ou de niveau haut 132 du logiciel critique.

La Figure 2 illustre un processus 200 pour des tests logiciels automatisés selon des formes de réalisation. Le processus 200 obtient un modèle d'architecture logicielle 134 à partir du modèle de conception logicielle. Le modèle d'architecture logicielle est construit, étape 205, dans l'environnement d'un outil de mise au point 150 à base de modèles reposant sur les informations architecturales du modèle de conception. Ce modèle d'architecture logicielle peut être généré automatiquement selon certaines mises en œuvre. Des modèles d'exigences sont attribués, étape 210, à différents modules du modèle d'architecture logicielle en connectant les variables contrôlées/commandées correspondantes (p.ex., sur la Figure 1 : VAR1-VAR19) aux ports d'entrée/sortie du composant. Selon certaines formes de réalisation, lors de l'étape 205, des ports d'entrée pour toutes les variables de sortie présentes dans les modèles d'exigences peuvent être ajoutés. En ajoutant des ports d'entrée pour toutes les variables de sortie, le générateur de cas de tests peut générer d'un seul coup des sorties attendues et des entrées pour les cas de tests.

Le générateur 140 de cas de tests au niveau composants peut utiliser le modèle d'architecture logicielle avec des exigences attribuées pour générer, étape 215, des cas de tests à base d'exigences au niveau unitaire/modulaire. Le générateur 140 de cas de tests peut aussi générer, étape 220, des cas de tests au niveau intégration pour vérifier si l'élément de code ou l'intégration est conforme aux exigences attribuées.

Les figures 3A à 3D illustrent un modèle d'architecture logicielle 300 construit sous la forme d'un organigramme hiérarchique de données reposant sur l'architecture de conception logicielle selon des formes de réalisation. Chaque composant Composantl, Composant2, Composant 3, Composant 4 de la conception logicielle est un bloc/opérateur du modèle d'architecture logicielle avec des ports d'entrée et de sortie. Les blocs/opérateurs du modèle d'architecture logicielle sont connectés les uns aux autres et peuvent avoir de multiples couches de sous-blocs/sous-opérateurs. Des modèles d'exigences REQ12, REQ13, REQ14, REQ15 sont attribués au modèle d'architecture logicielle et sont connectés aux ports d'entrée et de sortie. Le processus de construction est automatique, systématique et modulaire. L'organigramme hiérarchique de données assure une bonne visualisation et facilite la traçabilité depuis les exigences jusqu'à la conception logicielle.

La Figure 4 illustre un processus 400 pour la création de cas de tests au niveau composants selon des formes de réalisation. Le processus 400 repose sur un modèle reçu, étape 405, d'architecture logicielle généré automatiquement, sous la forme d'un organigramme hiérarchique de données avec des modèles d'exigences attribués. Un ou plusieurs des composants logiciels de la conception logicielle est/sont sélectionné(s), étape 410, d'après le niveau de création de test, et le bloc/opérateur de modèle d'architecture logicielle correspondant est utilisé pour la création de cas de tests. Un modèle intermédiaire de tests est construit, étape 415, d'après le composant sélectionné en adjoignant les contraintes des tests et les objectifs des tests au bloc/opérateur de modèle d'architecture logicielle correspondant. Les objectifs des tests sont annexés pour satisfaire certains critères de couverture au niveau exigences, tels que la couverture d'exigences (par exemple, toutes les exigences sont activées), la couverture d'états logiques (par exemple, des états logiques dans les exigences sont activés à un certain niveau), etc. Les contraintes des tests sont adjointes au modèle pour limiter l'étendue des variables contrôlées/commandées et pour assurer que les cas de tests générés ne vont pas à l'encontre des exigences.

Les stratégies de création automatique de cas de tests (à savoir pour adjoindre les objectifs et les contraintes des tests) peuvent reposer sur la forme générale d'une exigence. En langage naturel structuré, la forme d'une exigence peut être exprimée ainsi : <expression précédente>implique<expression consécutive>, où < expression précédente> est une expression logique sur des variables contrôlées, et <expression consécutive> est une expression logique sur des variables commandées.

La Figure 5 illustre le modèle d'exigences 500 (exprimé en Simulink) selon des formes de réalisation. Le modèle d'exigences comprend l'expression précédente 510 et l'expression consécutive 520. Ces expressions sont fournies au bloc logique 530, ce qui implique un signal de sortie 540 reposant sur les états des expressions (c'est-à-dire que A ==> B). Pour que l'exigence tienne, le signal de sortie doit être 1 ou “vrai”, bloc/opérateur de modèle d'architecture logicielle correspondant C'est ce que reçoit le générateur automatique 140 de cas de tests qui, sur cette base, génère des cas de tests selon une ou plusieurs stratégie(s) (p.ex. une stratégie de couverture d'exigences, une stratégie de couverture d'états logiques, une stratégie de masquage d'entrées, etc.). Les formes de réalisation ne se limitent pas à cela, et d'autres stratégies pour la création de cas de tests entrent dans le cadre de la présente invention.

Une stratégie de couverture d'exigences comprend, pour chaque exigence, la création d'un cas de test où l'exigence doit être satisfaite, l'expression précédente étant vraie. A cette fin, des objectifs et des contraintes sont insérés et un moteur de création de tests apte à activer des séquences d'entrée est mis en marche pour atteindre les objectifs du test. A titre d'exemple, l'insertion d'un objectif de test peut se faire à l'aide de blocs d'objectifs de tests et de conditions de tests issus d'une bibliothèque commerciale de blocs de vérification de conception dans l'outil sélectionné de mise au point à base de modèles (p.ex. tels que les blocs Simulink Design Vérifier disponibles avec Simulink). Le moteur de création de tests peut servir à activer les entrées pour atteindre les objectifs de tests. La Figure 6 illustre un modèle d'exigences 600 avec des objectifs de tests annexés selon des formes de réalisation. Le bloc 610 d'Objectifs de Tests (noté avec un “O” cerclé) est analysé par le vérificateur de conception pour trouver une combinaison d'attributions de valeurs de variables VAR21, VAR22 qui amènent l'expression précédente, qui est de type booléen, à être vraie. Le bloc 620 de Conditions de Tests (noté avec un “C” cerclé) amène le vérificateur de conception à maintenir vraie la sortie du bloc “implique”. Un signal de sortie vraie du bloc “implique” est une indication de ce que l'exigence REQ27 est satisfaite. Les attributions de valeurs aux variables contrôlées et commandées sont générées automatiquement par le vérificateur de conception.

Une stratégie de couverture d'états logiques (LCC) peut être mise en œuvre pour parvenir à une couverture fonctionnelle de conditions d'équations logiques. Il est démontré que chaque condition dans une équation logique a un effet sur le résultat de l'équation logique en ne faisant varier que cette condition et en maintenant inchangées toutes les autres susceptibles d'affecter le résultat. On considérera les exemples du Tableau 1, qui illustrent la couverture d'états logiques pour deux variables, où deux valeurs booléennes (a et b) sont les conditions pour les opérateurs booléens cités. Le Tableau 1 indique si un cas de test est nécessaire pour obtenir une couverture LCC (V) ou non (xx). Lorsque l'expression précédente a l'un de ces opérateurs, des cas de tests sont générés pour chacune des combinaisons correspondantes marquées par un (W), ce qui est généralisable à n'importe quel nombre d'opérandes.

Tableau 1

La Figure 7 illustre un modèle de couverture 700 d'états logiques avec des objectifs de tests adjoints selon des formes de réalisation. Le modèle de LCC repose sur le modèle d'exigences 600 avec une combinaison de blocs supplémentaires d'objectifs et de conditions de tests 710, 720, 730. Afin de générer les cas de tests, les blocs d'objectifs de tests sont annexés selon les opérateurs booléens utilisés et les cas respectifs du Tableau 1. Après que le moteur de création de tests a tourné, une série de cas de tests sont générés pour satisfaire la couverture d'états logiques. Chaque cas de test généré est également examiné afin que soient découvertes les exigences qu'il “active” - l'activation signifiant que le signal de sortie du port de Satisfiabilité 740 doit être 1 ou “vrai”.

Une stratégie de masquage d'entrées peut réussir un masquage Etat Modifié/Couverture de Décisions (EM/CD). Le masquage EM/CD est conforme à la définition d'effet indépendant en garantissant comme cause exclusive les mêmes cas de tests minimaux à chaque opérateur logique, et est acceptable pour se conformer à l'exigence d'EM/CD de normes de mise au point à base d'objectifs (p.ex. DO-178B/C). Le masquage se rapporte au concept selon lequel des entrées spécifiques d'une construction logique peuvent cacher l'effet d'autres entrées de la construction. Par exemple, une entrée fausse d'un opérateur ET masque toutes les autres entrées et une entrée vraie d'un opérateur OU masque toutes les autres entrées. L'approche de ΓΕΜ/CD par masquage permet le changement de plus d'une entrée dans une paire d'indépendances, pour autant qu'il soit démontré que la condition concernée est la seule condition qui affecte la valeur du résultat de la décision. Cependant, il faut analyser la logique interne de la décision pour démontrer que la condition concernée est la seule condition provoquant un changement de la valeur du résultat de la décision.

Les figures 8A et 8B illustrent une stratégie 800 à modèle de masquage d'entrées avec des objectifs de tests annexés selon des formes de réalisation. Chaque sous-expression figurant dans le modèle 800 de masquage d'entrées correspond à une propagation de signal/bloc qui débute dans un état d'entrée de l'expression précédente, impliquant une variable contrôlée VAR23, VAR24, VAR25, et prend fin au signal qui représente le résultat de l'expression contrôlée. Avec ce modèle, des cas de tests associés à des exigences REQ28 peuvent être générés automatiquement par le générateur 140 de cas de tests et être transcrits en scripts de tests de sortie.

La stratégie de création de tests de masquage d'entrées adjoint des objectifs de tests conformément aux étapes suivantes :

Pour chaque proposition de base (état d'entrée) de l'expression précédente, obtenir l'ensemble S de toutes les sous-expressions qui contiennent cette proposition, hormis la proposition elle-même. Ensuite, pour chaque expression de l'ensemble S : (1) si l'opération de niveau haut de la sous-expression est une fonction OU, substituer à cette expression sa négation dans S ; (2) générer une expression e qui est la conjonction de toutes les expressions de S et de la proposition de base précitée ; et (3) générer un objectif de test qui doit rendre vraie l'expression e.

Considérant à nouveau la Figure 4, après l'adjonction des contraintes de tests et des objectifs de tests, le processus 400 se poursuit avec la création de cas de tests 136, étape 420 par le générateur 140 de cas de tests. Le générateur de cas de tests peut exécuter des procédés de vérification de modèle, de résolution de contraintes et de résolution d'accessibilité sur le modèle intermédiaire de tests afin de générer les cas de tests de manière à satisfaire les objectifs de tests et/ou à détecter des objectifs de tests inaccessibles. Les cas de tests générés sont transcrits, étape 425, en scripts de tests pour l'exécution de tests et en artefacts d'examen de tests pour certification. L'avantage du procédé de création de tests au niveau composants consiste en ce que le procédé est souple pour générer automatiquement des cas de tests à base d'exigences pour des composants à différents niveaux dans l'architecture logicielle afin de respecter les critères appropriés de couverture au niveau exigences. Selon des formes de réalisation peuvent être générés des cas de tests applicables à des tests au niveau unitaire ou modulaire, ainsi qu'à des tests au niveau intégration.

La Figure 9 illustre un processus 900 pour la création de scripts de tests et l'examen d'artefacts de tests selon des formes de réalisation. Le format intermédiaire 905 généré par le processus 900 est exploitable par un humain et par une machine. Le processus 900 agit sur les cas de tests au niveau composants décrits plus haut. Un format intermédiaire est généré, étape 905, à partir des cas de tests. Ce format intermédiaire peut indiquer les informations d'entrée et les informations de sortie attendues. Le format intermédiaire peut également indiquer les exigences à l'origine du cas de test, l'objectif de test que satisfait le cas de test et la référence dont est dérivé le cas de test. Les informations intermédiaires peuvent servir à mener, manuellement ou automatiquement, des examens de tests. Des artefacts de certification sont générés, étape 910, à partir des informations intermédiaires. Les informations intermédiaires peuvent servir à générer, étape 915, des scripts de tests exécutables dans différents environnements de tests. Les scripts de tests peuvent aussi être ré-écrits automatiquement, étape 920, en outils de gestion d'exigences et de tests (p.ex. IBM® Rational®DOORS®).

Collectivement, les figures 10 à 13 présentent une illustration d'une mise en œuvre intégrale selon des formes de réalisation. La Figure 10 illustre un exemple de modèle de conception architecturale 1000 et les informations correspondantes de traçabilité d'exigences selon des formes de réalisation. Le modèle d'architecture logicielle peut être construit (Figure 2, étape 205) sous la forme d'un modèle Simulink (figures 3A à 3D). Chaque bloc de la conception d'architecture logicielle de modèle de conception logicielle est converti en bloc dans le modèle d'architecture logicielle de Simulink avec les mêmes informations d'interface et d'architecture. Chaque bloc du modèle architectural logiciel se voit également attribuer un ensemble de modèles d'exigences d'après les informations de traçabilité d'exigences de la Figure 10. Par exemple, sur la Figure 3D, quatre modèles d'exigences (1010) sont attribués au composant2 d'après les informations de la Figure 10. De même, le bloc 1020 indique les informations de traçabilité d'exigences pour le composantl ; le bloc 1030 indique les informations de traçabilité d'exigences pour le composant3 : et le bloc 1040 indique les informations de traçabilité d'exigences pour le composant4. Le modèle d'architecture logicielle illustré sur les figures 3A à 3D sert ensuite à générer des cas de tests à base d'exigences à différents niveaux dans l'architecture logicielle.

Un utilisateur peut sélectionner le bloc “composant2” (Figure 4, étape 410) pour générer des cas de tests à ce niveau unitaire et sélectionner une stratégie de test à masquage d'entrées. Selon des formes de réalisation, des blocs d'objectifs et de contraintes de tests seront automatiquement annexés à tous les modèles d'exigences à l'intérieur du bloc “composant2” lors de l'étape 415. Après une sollicitation du Vérificateur de Conception Simulink lors de l'étape 420 et une transcription de cas de tests lors de l'étape 425, les cas de tests qui satisfont la totalité des objectifs et contraintes de tests pour la stratégie de test à masquage d'entrées seront générés.

La Figure 11 illustre un exemple de script 1100 de test au niveau unitaire selon des formes de réalisation. Ce script de test au niveau unitaire est un exemple de cas de test généré au niveau unitaire pour le “composant2”. Le cas de test est généré pour se prêter à une exécution dans un environnement de test SCADE sur le bloc “composant2” de la conception. Selon une autre possibilité, un utilisateur peut sélectionner un bloc au niveau intégration qui comprend les composants 1 à 4 de la Figure 4, étape 410, afin de générer des cas de tests au niveau intégration. Selon des formes de réalisation, des blocs d'objectifs et de contraintes de tests sont adjoints automatiquement à tous les modèles d'exigences à l'intérieur du bloc au niveau intégration lors de l'étape 415. Après une sollicitation du Vérificateur de Conception Simulink lors de l'étape 420 et une transcription de cas de tests lors de l'étape 425, les cas de tests qui satisfont la totalité des objectifs et contraintes de tests pour la stratégie de test à masquage d'entrées seront générés.

La Figure 12 illustre un exemple de script 1200 de test au niveau intégration selon des formes de réalisation. Ce script de test est un exemple pour les cas de tests au niveau intégration générés. Le cas de test est généré pour se prêter à une exécution dans un environnement de test SCADE sur le bloc au niveau intégration de la conception.

Selon des formes de réalisation, un organigramme hiérarchique de données (c'est-à-dire un modèle d'architecture logicielle accompagné de modèles d'exigences) est généré automatiquement pour saisir des informations d'exigences et de conception. Cet organigramme hiérarchique de données sert à générer des cas de tests à base d'exigences à différents niveaux dans l'architecture logicielle. Selon des formes de réalisation, des informations de conception de système servent à construire l'organigramme hiérarchique de données, des modèles d'exigences étant attribués à l'intérieur de modules de l'organigramme hiérarchique de données. Les attributions d'exigences reposent sur les informations de traçabilité de module d'exigences issues des informations de conception. Des objectifs et contraintes de tests peuvent être annexés au modèle d'architecture logicielle suivant une stratégie de test choisie par l'utilisateur. La création automatique de cas de tests repose sur l'organigramme hiérarchique de données pour générer, à différents niveaux dans l'architecture de conception, des cas de tests à base d'exigences qui satisfont les objectifs et contraintes de tests. Les cas de tests générés peuvent être directement exécutés sur des composants à de multiples niveaux de la conception.

Selon certaines formes de réalisation, une application de programme informatique stockée dans une mémoire rémanente ou sur un support exploitable par ordinateur (p.ex. une mémoire à registre, une mémoire cache de processeur, une mémoire vive, une mémoire morte, un disque dur, une mémoire flash, un CD-ROM, des supports magnétiques, etc.) peut contenir un code ou des instructions exécutables qui, lorsqu'ils sont exécutés, peuvent demander à un automate ou un processeur et/ou amener celui de/à mettre en œuvre des procédés présentés ici, notamment pour la création automatisée de cas de tests à base d'exigences, décrite plus haut.

Le support exploitable par ordinateur peut consister en supports non transitoires exploitables par ordinateur, comprenant la totalité des formes et types de mémoires et tous les supports exploitables par ordinateur, sauf un signal transitoire se propageant. Dans une mise en œuvre, la mémoire rémanente ou le support exploitable par ordinateur peut être une mémoire externe.

Liste des repères 100 Système 110 Processeur de commande 120 Liaison de communication 130 Mémoire de données 131 Instructions informatiques 132 Exigences de niveau haut 134 Modèle d'architecture logicielle 136 Cas de tests 140 Générateur de cas de tests 150 Outil de mise au point à base de modèles 300 Modèle d'architecture logicielle VAR1 à VAR19 Variable REQ12 à REQ15 Modèle d'exigence

Composantl à

Composant4 Composant 500 Modèle d'exigence 510 Expression précédente 520 Expression consécutive 530 Bloc logique 540 Signal de sortie 600 Modèle d'exigences 610 Bloc d'objectifs de tests 620 Bloc de conditions de tests VAR20 à VAR22 Variable REQ27 Exigence 700 Modèle de couverture d'états logiques 710 Bloc d'état 720 Bloc d'état 730 Bloc d'état 740 Port de satisfiabilité 800 Stratégie à modèle de masquage d'entrées VAR23 à VR25 Variable REQ28 Exigence 1000 Modèle de conception d'architecture logicielle 1010 Bloc 1020 Bloc 1030 Bloc 1040 Bloc REQ1 àREQll Modèle d'exigences REQ16 à REQ26 Modèle d'exigences 1100 Script de test au niveau unitaire 1200 Script de test au niveau intégration

Claims

REVENDICATIONS

1. Procédé pour générer automatiquement des cas de tests à base d'exigences, le procédé, comportant : la construction d'un modèle d'architecture logicielle (300) dans un outil de mise au point (150) à base de modèles, le modèle d'architecture logicielle étant dérivé automatiquement d'informations architecturales d'un modèle de conception logicielle (1000)Ί l'attribution de modèles d'exigences (REQ1 à REQ28) à différents composants d'un modèle d’architecture logicielle ; et la création, à partir du modèle d'architecture logicielle, des cas de tests (136) à base d'exigences au niveau composants, dans lequel les cas de tests (136) à base d'exigences au niveau composants sont générés en accord avec au moins une stratégie choisie sur une liste comprenant une stratégie de couverture d'exigences, une stratégie de couverture d'états logiques et une stratégie de masquage d'entrées.
2. Procédé selon la revendication 1, comportant l'attribution des modèles d'exigences en connectant des variables contrôlées ou commandées correspondantes (VAR1 à VAR25) à un port d'entrée et/ou un port de sortie de modules respectifs parmi les différents modules.
3. Procédé selon la revendication 1, dans lequel la génération des cas de tests (136) à base d'exigences au niveau composants comprend la création de cas de tests au niveau intégration et l'application des cas de tests au niveau intégration afin de vérifier si un module de code est conforme aux exigences attribuées.
4. Procédé selon la revendication 1, comportant : la réception du modèle d'architecture logicielle sous la forme d'un organigramme hiérarchique de données dérivé de la conception logicielle, ainsi que des modèles d'exigences attribués, l'organigramme hiérarchique de données comprenant un ou plusieurs blocs/opérateurs mappés avec des composants correspondants (Composant 1 à Composant 4) dans la conception logicielle ; la sélection d'un des composants logiciels dans la conception logicielle pour la création de cas de tests ; et la construction d'un modèle intermédiaire de tests sur la base du composant sélectionné en adjoignant automatiquement des objectifs de tests et/ou des contraintes de tests au bloc/opérateur correspondant de modèle d'architecture logicielle.
5. Procédé selon la revendication 4, comportant la sélection du composant logiciel sur la base d'un niveau de création de test.
6. Procédé selon la revendication 4, comportant : la création de cas de test à base d’exigences par l'exécution, sur le modèle intermédiaire de tests, d'un procédé parmi un procédé de vérification de modèle, un procédé de résolution de contraintes et un procédé de résolution d'accessibilité ; et la transcription des cas de tests générés en scripts de tests pour l'exécution de tests, et en artefacts de tests pour un examen.