Je les remercie de m'avoir transmis de vraies valeurs, l'envie du travail bien fait, la patience et la détermination de réussir. Toutefois, la phase de tests reste la dernière étape d’un processus de développement logiciel.
Contexte : Le test de Conformit´e
Dans l'approche des tests de conformité (dont une méthode sera présentée), la construction automatique de séquences de tests est réalisée à partir d'une spécification donnée (et accessoirement d'une cible de test). Le travail consiste à développer une méthode pour tester la robustesse d'un protocole de communication.
Notre approche
Nous proposons ensuite de construire des cas de tests utilisant une spécification partielle et une propriété (à vérifier). Le test de propriété va nous permettre de mettre en place une méthode de génération de cas de test, la spécification originale servant de guide pour cette génération.
Plan du document
LTS : Syst`emes de transitions ´etiquet´ees
En projetant les séquences d'exécution sur un ensemble d'actions dans un LTS, nous définissons un langage associé à un état et un langage associé. La langue finale associée à un LTS est la langue associée à son état initial. c'est l'ensemble des traces infinies issues de l'état q).
IOLTS : Syst`emes de transitions ´etiquet´ees `a entr´ees-sorties
L'ensemble des états accessibles pour un système de transition M est l'ensemble des états accessibles depuis son état initial. L'ensemble des séquences d'exécution pour un système de transition M est l'ensemble associé aux séquences d'exécution à partir de l'état initial de M.
Les automates ´etendus et communicants
- Les automates ´etendus
- Syntaxe
- S´emantique
- Les automates ´etendus communicants
- Syntaxe
- S´emantique
Dans le contexte ρ, l'envoi est possible si et seulement si la valeur de guard [b] est évaluée à vrai (t= vrai). Dans contextr, l'envoi est possible si et seulement si la valeur de guard [b] est évaluée à true (t= true).
Conclusion
Le test de logiciels est une activité manuelle ou automatique qui prend de l'importance dans le monde industriel et donne lieu à de nombreux efforts de recherche. Généralement, les tests logiciels dépendent du niveau d'application que nous leur fournissons.
Le test de conformit´e
Une implémentation à tester I est plus petite qu'une spécification S (notée I ≤ tr S), si toutes les traces d'exécution de l'implémentation sont incluses dans les traces possibles de la spécification. Ceci est une conséquence de la difficulté de construire des cas de tests directement à partir de systèmes de transition avec des interactions symétriques (les actions d'entrée et de sortie de l'implémentation ne sont pas différenciées).
Les m´ethodes de g´en´eration de cas de test
Pour ces méthodes, il existe plusieurs façons de générer des cas de test. La seconde est la méthode de génération de cas de test basés sur des systèmes de transition.
Etat sur les outils existants pour le test de conformit´e
Génération de cas de test : L'outil de génération de cas de test est une extension de l'outil TGV. Cas de test La génération de l'outil DILL (présenté ci-dessous) est similaire à la méthode TGV.
Le test de protocole de communication
Plus le nombre de cas de test est élevé, plus la décision finale est sûre. Ce chapitre présente les différents éléments nécessaires pour générer et exécuter des cas de test.
Mod`eles de sp´ecification et d’implantation
- Mod`ele de sp´ecification
- Mod`ele d’implantation
Plus précisément, nous présentons en détail une technique de génération de cas de tests pour les tests de conformité, qui constitue la base de notre travail. Cette méthode consiste à générer des cas de tests à partir d'une spécification formelle et d'un objectif de test qui inclut les actions précises à tester.
La relation de conformit´e ioco
Définition 3.2.1 (ioco : la relation de conformité) La relation de conformité est établie entre une implémentation d'IUT et sa spécification S : IU T −−−−−→ioco. Cependant, si la spécification est complète en entrée de l’alphabet des implémentations, la formulation de la relation de conformité ioco est simplifiée.
Exemple d’implantations conformes, ou non conformes
Un outil utilise généralement une seule relation de conformité pour générer et exécuter des scénarios de test. C'est pourquoi nous présentons ici uniquement la relation ioco comme propriété de conformité, utilisée dans l'outil TGV.
G´en´eration de cas de test de conformit´e bas´ee sur les syst`emes de transitions `a
- D´eterminisation d’une sp´ecification
- Les blocages
- Objectifs de test
- Graphe de test : Produit synchrone ( ⊗ )
- Cas de test : S´election d’un cas de test
Les cas de test sont fournis avec des horloges (minuteries) et des jugements (réussite, échec et en attente). L'IOLTS pour l'objectif de test (ot) est complet, P = ∆(S)det×ot correspond à ∆(S)det (intuitivement, il préserve tout comportement).
Mod`ele d’ex´ecution
Définition 3.5.2 (Déclarations selon rejeté, accepté, non concluant) Considérez l'implémentation de l'IUT et le scénario de test CT. Un scénario de test doit nous informer de la conformité de l'implémentation par rapport à la spécification.
Explosion des ´etats
Une suite de tests ST est exhaustive pour S et ioco si et seulement si ∀IU T ∈ I,. Une suite de tests ST est correcte si ∀IUT ∈I, (IUT ioco S)=⇒ ¬(IUT est rejeté par CT) d'une suite de tests ST par rapport à S et ioco, nous avons que les IUT non conformes sont rejetées.
Conclusion
Générer et exécuter des cas de test pour les tests de fonctionnalités. 5.2 - Principe de génération automatique de cas de tests pour tester les propriétés.
Les mod`eles
- Mod`ele de sp´ecification
- Mod`ele d’implantation
Les propri´et´es
Nous illustrons le fait qu'il existe des langages ω-réguliers qui ne sont pas reconnus par l'automate déterministe de B¨uchi. Considérons l'automate déterministe de la figure 5.4 comme un automate de B¨uchi avec GB={2}, cet automate accepte toutes les séquences qui produisent l'action E ou l'action I une infinité de fois.
Relation de satisfiabilit´e
Architecture de test et cas de test de propri´et´es
Une architecture de test est compatible ObserverObs si et seulement si les contraintes suivantes sont respectées : AIO = Ac etAOO = Au etδ ∈ Au. Définition 5.5.1 (Cas de test de propriété) Soit Obs = (O,TO,CO) un observateur, AO l'ensemble des opérations, et AT = (Ac,Au) l'architecture de test compatible avec l'observateur.
Graphe de test
En particulier, l'action ?c présente dans la spécification ne sera ajoutée au graphe de test qu'après l'exécution de !b. Soit AT= (Ac, Au) une spécification S0 d'architecture de test compatible avec l'observateur et S = det(∆(SO,Ac∪Au)) un automate de suspension déterministe associé à S0.
Exemple d’un produit ´etendu entre une sp´ecification S et un observateur Obs
Si nous commençons par la séquence en cours σGT, projetons pour obtenir la séquence σObs, et considérons les trajectoires connectées ρetρ0 comme à l'étape 1, nous avons un seul état (qs, qObs) qui est un état différent de AGTrpsi et seulement si qObs est un état , ce qui diffère de l'Obs. 2) : Application des règles R2, R3 et R4 : La deuxième partie du produit étend les séquences d'exécution de la spécification.
S´election de cas de test de propri´et´es
Nous supposons que l'état 1 de l'observateur n'est pas un état distinct, que l'état 2 a le signe U et que l'état 3 a le signe L.
Ex´ecution d’un cas de test et verdicts
Ces jugements sont formalisés par une fonction Notant les séquences d'exécution par rapport à l'ensemble {Satisfait, non satisfait}. A chaque étape d'exécution, les conditions de contrôlabilité peuvent offrir le choix entre une action observable et une action contrôlable.
Conclusion
Nous allons maintenant voir comment mettre en œuvre notre méthode de test de propriétés pour effectuer. Les modifications apportées (selon nos définitions) par rapport au test de richesse sont : 1.
Environnement nominal, environnement d´egrad´e
La définition du fonctionnement ou du comportement acceptable pour une implémentation (malgré certaines erreurs). En d’autres termes, une relation de robustesse (équivalente à une relation de satisfiabilité observée dans les tests de propriétés) qui interprète les réponses d’une implémentation lorsqu’elle est exposée à des erreurs.
Un exemple
Autrement dit, les traces de l'implémentation sont incluses dans la trace de la spécification : (STrace(implementation 1)⊆STrace(S)=⇒implementation 1 ioco S). Robuste : l'implémentation 1 et l'implémentation 2 sont "supposées" robustes pour la propriété de robustesse donnée.
Le test de robustesse bas´e sur les mod`eles
La méthode de test de robustesse que nous présenterons enrichit la spécification nominale avec de nouveaux paramètres de performances de l'implémentation testée. Ensuite, dans la spécification, nous avons des spécifications supplémentaires pour générer et exécuter des cas de test, tout en conservant une description partielle du fonctionnement de l'implémentation.
Mutation d’une sp´ecification
- Techniques de test bas´ees sur la mutation
- Sp´ecification
- Mod`ele de faute
- R`egles de mutations
Un signal se compose d'un nom unique et d'un ensemble de paramètres saisis. A partir d'un modèle d'erreur MF (donné dans le tableau suivant), nous proposons une spécification mutée Smen qui applique les règles de la fonction de mutation : Apply (∆, S, MF) = Sm.
Les propri´et´es de robustesse
Dans le tableau ci-dessus, l'état 5 est un nouvel état qui n'est pas contenu dans la spécification initiale de l'IOLTS.
La relation de robustesse
Architecture de test, Graphe de test, S´election et cas de test de robustesse
Cas de test de robustesse : en ce qui concerne le test de propriété, des décisions relatives aux cas de test sont prises. Notre méthode permet de construire des cas de tests en vérifiant une propriété de la manière suivante.
Conclusion
Un prototype pour lequel générer et exécuter des cas de tests de robustesse. L’objectif de la plateforme est de fournir un cas de test de robustesse pouvant être réalisé par un testeur.
Mise en œuvre des algorithmes
- Etapes de construction d’un det(∆(S ´ m )) mini
- Construction d’un graphe de test de robustesse : GT
- Algorithme de s´election de cas de test
Le premier parcours dans [CVWY92] arrange tous les états du composant d'ordre postfixé fortement connecté dans l'état défini F à partir de l'état initial. Frontière ← S0 /* initialisation de la frontière fixée par le premier état du graphe, CT démarre toujours par l'état initial du graphe.
Conclusion
Le diagramme de la figure 8-1 montre une chaîne d'outils permettant d'exécuter des cas de tests de robustesse sur des implémentations Java. L'outil Spider pour exécuter des cas de tests de robustesse fait partie de l'outil développé par IBM Haifa dans le projet AGEDIS.
Principe de l’outil de test de robustesse
Sélection =⇒ Cette opération prend en entrée le graphe de test et ses marqueurs, le résultat est un automate IOLTS représentant un cas de test et ses marqueurs. Les données d'entrée sont un cas de test (accompagné de marqueurs), une table de correspondance, l'architecture de test.
IF : Langage de description
- D´efinitions globales
- Processus
Une instance d'un processus peut être créée ou détruite dynamiquement lors de l'exécution d'une action. La spécification de processus (= Corp Process) se compose d'un ensemble de variables locales, d'un ensemble d'états de contrôle et d'un ensemble de transitions.
Pr´esentation de l’exemple : Un distributeur de Tickets
Un contrôleur qui communique avec le chargeur en fonction des besoins de l'utilisateur. Un dialogue entre le contrôleur et le chargeur est donc nécessaire.
La sp´ecification de r´ef´erence utilis´ee par la chaˆıne d’outils
La mutation : Sp´ecification / Mod`ele de faute
Au niveau de la spécification IF, deux nouveaux signaux break() et cut() sont placés dans l'ensemble des signaux, un nouvel état est placé dans l'ensemble des états du processus "contrôleur", et de nouvelles transitions apparaissent dans le contrôleur processus.
Simulation, suspension, d´eterminisation, minimisation de la sp´ecification mut´ee
Propri´et´e, observateur et fichier de marquage .lu pour test la robustesse du
Un automate de propriétés doit être complet pour accepter toutes les entrées et sorties d’implémentation. Même si l’automate observateur décrit une propriété de sécurité, l’observateur est paramétré par des.
Graphe de test, s´election et cas de test
Ce fichier est donné sous la forme d'une chaîne qui contient initialement les états de l'observateur et leurs étiquettes correspondantes U et L. Il correspond séquentiellement à l'étiquetage des états de l'observateur, puis à l'étiquetage des états du graphe de test, et enfin à l'étiquetage des états des différents tests. cas.
Proposition d’une implantation pour le composant contrˆoleur de la Machine Ticket 162
- Les verdicts
- Les r´esultats d’ex´ecution
Chacune des interactions du scénario de test (contrôlable ou observable) est traduite au format ats. Les compteurs sont incrémentés chaque fois qu'un état respectif ∈ état U ou état L est atteint pendant l'exécution du scénario de test.
Conclusion
Exemple de syst`emes non d´eterministes
Plus précisément, on parle de « non-déterminisme observable » pour décrire l'existence d'un choix qui n'est pas contrôlé par l'environnement. Définition 1.1.17 (non-déterminisme observable) Un IOLTS n'a pas de non-déterminisme observable si dans un état q∈Q :| O(qaprès)| ≤1.
Exemple de non d´eterministe observable au sens des IOLTS
Dans le contexte ρ, la transition est possible si et seulement si la valeur de garde [b] est évaluée à vrai (t= vrai). L'attente est possible si et seulement si la valeur de la garde [b] est évaluée à vrai (t= vrai).
Repr´esentation d’un automate ´etendu
La ligne [T3] définit, dans le contexteδ, l'envoi de la valeur v, résultat de l'évaluation de l'expression un, et l'envoi se fait au travers d'un signal. De nouveaux échanges entre AEC1 et AEC2 se produisent une fois que la condition dex==1 est évaluée comme vraie.
Repr´esentation de deux automates ´etendus communicants
Après une présentation générale des tests logiciels, nous définissons les termes liés au cas particulier des tests de conformité et présentons brièvement quelques exemples d'outils existants. . Pour introduire le chapitre 3, nous conclurons ce chapitre 2 par une présentation du test de protocole de communication en détaillant ce qu'est une architecture de test, puis un testeur.
Principe g´en´eral pour le test de conformit´e
Une spécification permet l'inclusion de différentes décisions d'exécution dans les cas de test. L'architecture de test est prise en compte lors de la génération de cas de test à partir de la spécification.
Pr´esentation d’une architecture de test local
La construction et l'exécution des cas de tests sont de type boîte noire (par exemple, pour des raisons de confidentialité, le code de l'implémentation n'est pas fourni). Le testeur arrête l'exécution et rend un verdict en fonction de l'observation de la trace d'exécution de l'implémentation testée.
Pr´esentation du testeur
Une implémentation est considérée comme « conforme » si tous les cas de test exécutés par le testeur aboutissent à un verdict de réussite. Si vous souhaitez tenter d'obtenir un verdict différent (réussite ou échec, et donc chemin que le testeur peut emprunter), il est possible de relancer l'exécution avec le même scénario de test.
Sp´ecification de r´ef´erence
Implantations conformes (ioco)
Implantations non conformes (ioco)
L'outil TGV génère automatiquement des cas de tests à partir d'une spécification et d'un objectif de test donnés sous forme d'IOLTS. Les algorithmes d'exécution détectent les blocages dans les communications grâce à des temporisateurs intégrés (armés pendant l'exécution d'un test) qui garantissent l'achèvement de l'exécution.
Mod`ele de g´en´eration et d’ex´ecution de cas de test de conformit´e
Il est naturel de considérer qu’une trace d’IOLTS est un comportement du système. Cette situation de blocage est temporaire car la réception d'une action attendue permet de sortir de q : Un état q d'un IOLTS est en sortie bloquant si et seulement si ∀a∈I∪AO,q 6−→.
Une sp´ecification sous forme d’IOLTS incluant un blocage δ
Ce blocage peut être représenté par une boucle dans un état de l'IOLTS : Un état q ∈ Q d'un IOLTS est un blocage actif si et seulement si q τ τ. On note livelock(M) l'ensemble des états du chemin non vide des actions internes (le chemin menant de l'état source au même état source) d'un IOLTS M .
IOLTS de suspension apr`es la d´etection et la conservation des blocages
Un objet de test (ot) est un IOLTS sur l'alphabet des actions visibles dans la spécification. Un graphe de test est une IOLTS obtenue par un produit synchrone entre deux IOLTS : la spécification et la cible du test.
Repr´esentation du produit synchrone entre deux syst`emes de transitions
Un graphe de test est un IOLTS obtenu en exécutant le produit synchrone entre une spécification et un objectif de test (figures 3.8 et 3.9). Un cas de test est élaboré par des diagnostics exprimés sous forme d'énoncés.
Sp´ecification et objectif de test
S´election d’un cas de test
Nous avons ensuite proposé une méthode pour générer des cas de tests de robustesse. Nous faisons ce choix car la génération et l’exécution de cas de tests de propriétés constitueront la base des tests de robustesse.
Test de propri´et´es
Nous utilisons ces modèles d'automates pour décrire les propriétés et instancier les cas de tests à exécuter. L'architecture de la figure 5.2 présente la méthode de génération de nos cas de tests de propriétés.
Principe de la g´en´eration automatique de cas de test pour le test de propri´et´es
Pour l'exemple nous considérons la propriété suivante P : « un système peut toujours revenir à une situation initiale par une action I après une certaine situation provoquée par une action E ». La négation de la propriété que représente l'observateur Obs s'exprime par le langage : L= (E + I)∗Eω.
Plus précisément, le graphique de test calculé est obtenu comme suit. L'architecture de test de l'exemple de la figure 5.5 est : Au = {!a, !b, !δ}, Ac ={?c} Le graphe produit entre la spécification et l'observateur contient les séries de tests les plus pertinentes selon le test objectifs.
Graphe de test obtenu `a partir d’une sp´ecification et d’un observateur
En particulier, l'action ?c présente dans la spécification ne sera ajoutée au graphe de test qu'après l'exécution de !b. LGTn, UnGT)io`uLGTi et UiGT sont définis comme suit. Lemme II.2 Pour tous les graphes de test AGTpr construits par un observateurObs on a : L(AGTrp)⊆ L(Obs).
Produit selon les r`egles R0 et R1
Marquage des ´etats du produit
En pratique, les exécutions des cas de tests de propriété peuvent être améliorées de la manière suivante. Nous avons vu, dans les tests de propriétés, qu'une spécification peut guider la construction de cas de tests.
Configuration d’un syst`eme (composant) avec son environnement
Donne une mise en œuvre dans des conditions extrêmes et maintient un fonctionnement acceptable selon les attentes.
Un syst`eme communicant
L'environnement client se compose d'un serveur qui envoie les entiers 1 ou 2 et d'un tampon qui reçoit les entiers. Une implémentation 2 (Figure 6.6) : Un processus (client) inclut une simulation de communication peu fiable car provoquée par l'environnement dégradé.
Propri´et´e de robustesse
Une propriété : « Si l’entier 1 est reçu par le Client, l’entier 1 sera placé dans le Buffer dans un délai raisonnable, sinon la transaction sera avortée ». La propriété de robustesse que nous voulons vérifier est la suivante : « Si un entier 1 est reçu par le Clientc?s(1), un entier 1 sera inévitablement placé dans le buffered!buff f(1) dans un délai raisonnable, sinon il sera la transaction annulée c!abort”.
Sp´ecification
Implantation 1
Implantation 2 ´elabor´ee robustesse
Un syst`eme communicant suivant l’implantation 2
En fait, nous pouvons le confirmer car le modèle de représentation de l’implémentation 1 est identique à la description de la spécification. Non conforme : D'après la relation ioco et les cas de tests produits, l'implémentation 2 n'est pas conforme, soit à cause de sorties non spécifiées par la spécification nominale, soit à cause d'une absence de réponse lors de l'exécution des cas de tests devenus
Implantation 2 non conforme et robuste - Implantation 1 conforme et robuste
En effet, pour l'implémentation 1, il y a une alternance d'entiers 1 et 2 sans perte de données, donc si un entier 1 est envoyé au client, un entier 1 est envoyé au buffer. Dans l'implémentation 2, il y a une vérification des données, donc si un entier 1 est envoyé après moins de 10 tentatives (Cpt < 10) d'échanges d'accusé de réception, un entier 1 est mis en mémoire tampon.
G´en´eration de cas de test pour le test de robustesse
Il se compose d'une série d'états, de déclarations de variables et de déclarations de canaux. Ce type d'erreur peut être testé car il affecte les valeurs des actions échangées entre les composants d'un système.
Automate mut´e avec une coupure
Nous définissons, σ, la séquence d'exécution d'un scénario de test (CT) sur une implémentation sous test (IUT). Le graphe de test est construit à partir d'une spécification mutée (spécifiée, minimale compte tenu des blocages possibles) et d'un observateur.
Automate mut´e avec une panne
Mutation d’une ´emission
Mutation d’un noeud garde
Nous proposons avec l'exemple suivant de muter une spécification en appliquant les règles de mutations suggérées ci-dessus. Pour cet exemple, nous présentons une spécification S, qui effectue des actions d'entrée et de sortie visibles sur le canal c avec, s le signal, a, b, x des variables, e, e0 des expressions.
Une sp´ecification S
L'état nouvellement créé doit être un état différent des états présents dans l'ensemble des états du processus et doit intégrer cet ensemble.
Sp´ecification Mut´ee
En particulier, les séquences de l'ensemble L(IUT)∩ L(SMut´ee) -L(¬P), n'appartiendront pas à l'ensemble des cas de tests générés (bien qu'elles violent la propriété de cohérence). Exécution des cas de tests de stabilité : Les cas de tests sont exécutés avec un testeur sur les implémentations.
Plate-forme pour g´en´erer un cas de test de robustesse
Le deuxième travail est réalisé avec la spécification mutée Sm et l'architecture de test. Le dernier travail consiste à extraire un cas de test CT du graphe GT (par une méthode de sélection).
Chaˆıne d’op´erations pour obtenir : det(∆(S)) mini = une sp´ecification mut´ee,
La terminaison de l'algorithme est garantie lorsque tous les états IOLTS ont été visités. Aτ+a= AS∪δ, signifie que l'ensemble des actions Aτ+a est constitué de l'ensemble des actions AAugmenté avec l'action de blocageδ.
Graphe de test de robustesse obtenu par produit synchrone ´etendu entre un obser-
DéjàVisitedM1 est l'ensemble des marques des états visités lors du premier parcours. DéjàVisitedM2 est l'ensemble des marques des états visités lors du deuxième passage.
D´etection d’une composante connexe non triviale
La fonction de préservation de séquence menant à y(P,y) donne le chemin qui va de l'état initial de la pile P à l'état y, successeur du dernier état de P. La fonction préserve toutes les extrémités des chemins qui partir de l'état initial de la pile P. graphe GT en condition accessible.
Graphe connexe GT (gauche) et graphe ”faiblement” connexe GT 0 (droite)
Nous présentons dans cette troisième et dernière partie une chaîne complète d'outils. 8.1 : Représentation d'une chaîne complète d'outils de tests de robustesse des programmes Java (incluant les formats d'entrée).
Repr´esentation d’une chaˆıne compl`ete d’outils pour le test de robustesse des pro-
Remarque : Le calcul du changement d'échantillon est effectué lors d'un dialogue entre le chargeur et le contrôleur. Sans donner tous les détails d'un programme IF qui correspond au système Ticket Machine, nous donnons un aperçu de la spécification du programme écrit en IF.
Sp´ecification repr´esentant le comportement du contrˆoleur de la Machine Ticket
Sp´ecification mut´ee
Les composants de base de la méthode de test des propriétés sont : une ou plusieurs propriétés, a. La génération des cas de tests se fait avec une spécification et une propriété de cohérence.
Observateur de la propri´et´e de robustesse `a v´erifier
Cas de test de robustesse pour exprimer la faute de panne
Cas de test de robustesse pour exprimer la faute de coupure
Puisque l’implémentation doit renvoyer la valeur des pièces, le validateur ne sait pas exactement combien de pièces il reste dans la trémie. Si le chargeur ne fournit pas la quantité de pièces disponibles, un calcul au niveau du contrôleur est toujours possible.
Repr´esentation d’une implantation pour le contrˆoleur de la Machine Ticket
Le cas de test est un sous-graphe extrait du graphe de test (automate de Rabin paramétré). Le scénario de test contient au moins une séquence L(GT) et donc L(O).
Perspective de raffinement des mod`eles de faute
I Thomas Ostrand, redaktør, Proceedings of the 1994 International Symposium on Software Testing and Analysis (ISSTA), sider. I Proceedings of the FIP TC6 WG6.1 Joint International Conference on Formal Description Techniques for Distributed Systems and Communication Protocols (FORTE XI) and Protocol Specification, Testing and Verification (PSTV XVIII), side 93–109.
