État de l'Intelligence Artificielle appliquée à l'Ingénierie de la Qualité 2021-2022
Section 3.2 : Traitement du langage

Chapitre 2 by Capgemini

Le NLP pour les artefacts dupliqués et orphelins

Métier ●○○○○
Technique ●●●●○

Download the "Section 3.2: Inform & Interpret" as a PDF

Use the site navigation to visit other sections and download further PDF content

By submitting this form, I understand that my data will be processed by Sogeti as described in the Privacy Policy.*

Dans le chapitre précédent, nous avons couvert l'étendue des approches et des outils du PNA. Le PNA a un large éventail d'applications pratiques dans divers domaines de l'ingénierie de la qualité. Cela inclut - mais n'est pas limité à - l'automatisation des procédures de test à l'aide de commentaires en langage naturel, la compréhension du risque inhérent au code à partir des commentaires de commit record, et l'évaluation de la répartition des efforts des ingénieurs sur un projet en cours. Compte tenu des progrès réalisés dans le domaine du langage naturel et de l'utilisation généralisée des applications d'IA au cours des dernières années, il est évident que le langage naturel peut aider les organisations à résoudre de nombreux problèmes liés à la qualité des produits. Dans ce chapitre, nous examinons plusieurs cas d'utilisation concrets où le traitement automatique des langues peut nous aider à prendre des décisions basées sur l'intelligence plutôt que sur les données :

  1. Défauts et cas de test dupliqués
  2. Défauts et cas de test orphelins
  3. Analyse et exploitation des journaux
  4. Analyse de sentiments

Cas d'utilisation n° 1 : duplication des défauts et des scénarios de test

Les défauts peuvent être découverts presque tout au long du processus de test. Sogeti TMAP décrit les différentes étapes que le testeur doit effectuer lorsqu'un défaut est découvert. Celles-ci comprennent, entre autres, l'établissement de la confirmation d'une anomalie, sa reproduction et la détermination de sa cause. L'une des étapes de ce processus consiste à déterminer si une anomalie est clairement un doublon. De nombreuses anomalies dupliquées sont une indication évidente d'une méthodologie de test inefficace. Alors que nous étudions comment l'IA peut nous aider à résoudre ce problème, notre recommandation est de recentrer l'attention sur la stratégie globale de test.

Nous proposons ici une approche technique pour traiter les anomalies dupliquées (par description/par résumé) et les cas de test (par noms/par description).

Étapes de prétraitement

Il y a certaines étapes à suivre pour transformer les données textuelles non structurées en une forme de données structurées afin de pouvoir les analyser. Les étapes générales du prétraitement sont les suivantes :

  1. Mise en minuscules des documents
  2. Tokenisation : Tokenisation des mots ou Tokenisation des phrases : découpage en mots/sentences
  3. Suppression des signes de ponctuation
  4. Supprimer les chiffres si nécessaire.
  5. Supprimez les espaces blancs supplémentaires
  6. Supprimez les mots d'arrêt tels que déterminants, verbe être, certaines conjonctions de coordinations, "il y a", etc.
  7. Dissociation et dématisation : Convertir les mots sous diverses formes en leur racine, par exemple : joué, jouant sera transformé en un seul mot : jouer.

Transformation des données

Après l'étape de prétraitement, nous transformons les données en un format structuré et pour ce faire, nous calculons les métriques ci-dessous :

  1. Fréquence des termes (TF) : Combien de fois un mot est apparu dans le document. Un mot apparaissant plus fréquemment aura plus d'importance.
  2. Fréquence inverse des documents (IDF) : Dans combien de documents un mot particulier est apparu. Le mot apparaissant le plus souvent peut ne pas être très important, par exemple des mots comme "le/la", "non", "être" peuvent avoir une fréquence plus élevée mais ne pas être très importants. Pour supprimer cela, nous trouvons la fréquence inverse des documents.
  3. Fréquence des termes - Fréquence inverse des documents (TFIDF) : Produit de la TF et de l'IDF qui supprime les mots triviaux et met en évidence les mots les moins fréquents en même temps.

Après avoir converti les données non structurées en format structuré, il est temps de les comparer et de déterminer leur degré de similitude. Pour trouver la similarité entre deux documents texte, nous avons utilisé la matrice de similarité Cosinus.

Cosinus de similarité (A, B) = A.B/ (||A||.||B||)

= ∑ (A*B) / {sqrt (∑ (A2)) * sqrt (∑ (B2))}

 

Où A et B sont deux vecteurs de documents et sqrt (a) est la racine carrée de a. La valeur de similarité varie de 0 à 1. La similarité en cosinus = 0 signifie que les deux documents A et B n'ont aucun mot similaire en commun et la similarité en cosinus = 1 signifie que les deux documents A et B contiennent exactement les mêmes mots (en ignorant les mots vides).

Ensuite, nous trouvons les 3 meilleures correspondances pour chaque document dans cette matrice de produits croisés correspondant à chaque entité du document. Voici les noms des entités utilisées pour trouver les correspondances dans le cas d'utilisation mentionné ci-dessus.

  • Défauts en double :
    • Par résumé : Chaque résumé de défaut est comparé à tous les autres résumés de défauts d'un projet et les 3 meilleures correspondances pour ce résumé sont sélectionnées sur la base de la valeur de similarité en cosinus.
    • Par description : Chaque description de défaut est comparée à toutes les descriptions de défauts restantes dans un projet et les 3 meilleures correspondances sont sélectionnées en fonction de la valeur de similarité du cosinus.By Summary : Each Defect
  • Cas de test dupliqués :
    • Par nom : Chaque nom de cas de test est comparé à tous les noms de cas de test restants dans un projet et les 3 meilleures correspondances sont choisies en fonction de leur valeur de similarité en cosinus.
    • Par description : Chaque description de cas de test est comparée à toutes les descriptions de cas de test restantes dans un projet et les 3 meilleures correspondances sont choisies en fonction de leur valeur de similarité en cosinus.
Figure: Outcome of the textual data analysis, with measured similarities

 

Figure: Résultat de l'analyse des données textuelles, avec les similarités mesurées.

Cas d'utilisation n° 2 : défauts et scénarios de test orphelins

En théorie, tous les actifs de test doivent avoir une relation correcte avec leurs entités respectives. Par exemple, toutes les anomalies découvertes pendant la phase d'exécution du test doivent être associées aux cas de test correspondants, et tous les cas de test doivent être associés aux exigences correspondantes. Cependant, dans la pratique, tous les actifs ne sont pas connectés à leurs autres entités correspondantes. Les actifs orphelins sont ceux qui n'ont pas de connexion avec les entités correspondantes.

À cet égard, nous avons les artefacts orphelins suivants :

  1. Défauts orphelins : défauts qui ne sont liés à aucun des cas de test jusqu'à présent.
  2. Cas de test orphelins : cas de test qui ne sont liés à aucune des exigences (ALM)/ histoires d'utilisateur (Jira).

Ensuite, à l'aide de l'analyse de texte ou du traitement du langage naturel, nous tentons de relier ces actifs à leurs entités connexes (NLP) :

  1. Défauts orphelins : Défauts orphelins : Correspondance entre les défauts et les cas de test en utilisant la description du défaut et le nom du cas de test.
  2. Cas de test orphelin : mappage du cas de test à l'exigence à l'aide du nom du cas de test et du nom de l'exigence (ALM) / résumé de l'histoire de l'utilisateur (Jira).

L'approche générale de ces utilisations est similaire. Ils utilisent tous les mêmes processus de prétraitement du texte, et leurs métriques pour comparer deux documents textuels distincts sont identiques : le cosinus de similarité.

Les étapes du prétraitement du texte sont les mêmes que celles décrites dans le cas d'utilisation précédent.

La principale distinction réside dans ce qui est comparé à quoi.

Ce qui suit contient les noms d'entités qui sont utilisés pour localiser une correspondance dans les scénarios d'utilisation susmentionnés.

  1. Correspondance entre défauts et scénarios de test : Chaque description de défaut est comparée à tous les noms de cas de test dans un projet et les 3 meilleures correspondances pour chaque description sont sélectionnées sur la base de leur valeur de similarité en cosinus.
  2. Traçabilité des cas de test aux exigences (ALM) : Chaque nom de scénario de test est comparé à tous les noms d'exigences au sein d'un projet et les 3 meilleures correspondances pour chaque nom de scénario de test sont sélectionnées en fonction de leur valeur de similarité en cosinus.
  3. Traçabilité des cas de test aux histoires d'utilisateurs (Jira) : Chaque nom de cas de test est comparé à tous les résumés d'histoire d'utilisateur dans un projet et les 3 meilleures correspondances pour chaque nom de cas de test sont sélectionnées en fonction de leur valeur de similarité en cosinus.
Figure: Outcome of the textual data analysis, with measured similarities

Figure: Résultat de l'analyse des données textuelles, avec les similarités mesurées

Le coin des experts : les librairies utilisées dans les cas d'utilisation #1 et #2

Python

(NLTK): NLTK est une plateforme de premier plan pour la création de programmes python destinés à travailler avec des données sur le langage humain. Il fournit une interface facile à utiliser pour plus de 50 corpus et ressources lexicales telles que WordNet, ainsi qu'une suite de bibliothèques de traitement de texte pour la classification, la tokénisation, l'épointage, le balisage, l'analyse syntaxique et le raisonnement sémantique.

  1. corpus() : est une collection de documents.
  2. re() : pour nettoyer le mot de toutes les étiquettes html et aussi les ponctuations.
  3. lower() : Mettre les documents en minuscules.
  4. Tokenization() : pour diviser une phrase en tokens.
  5. Stop-words() : Les mots d'arrêt sont considérés comme des données inutiles pour un moteur de recherche. Les mots tels que les articles, les prépositions, etc. sont considérés comme des mots d'arrêt et nous allons les supprimer.
  6. PorterStemmer() : pour ramener les mots à leur racine. Exemples : Running-Run , cookies-cooki et flying-fly
  7. tf_idf() : Convertit une collection de documents bruts en une matrice de caractéristiques TF-IDF.
  8. count_vect() : Transforme un texte en une matrice de caractéristiques de n-grammes.
  9. cosine_similarity() : Elle calcule la similarité en cosinus entre les vecteurs et construit une matrice.

Ensuite, nous trouvons les 3 meilleures correspondances pour chaque document dans cette matrice de produits croisés correspondant à chaque entité du document.

Langage de programmation R

En R, il existe de nombreux paquets disponibles pour effectuer ces tâches tels que openNLP, tm, Quanteda, tidytext etc.

Parmi ceux-ci, nous avons utilisé le package Quanteda en raison de sa simplicité, de ses meilleures performances et de sa rapidité. L'approche de tous ces paquets est plus ou moins similaire, à l'exception de quelques différences de fonctionnalité.Dans le package Quanteda, pour réaliser les tâches mentionnées ci-dessus, nous avons utilisé les fonctions mentionnées ci-dessous :

  1. corpus() : pour construire un corpus de textes et leurs valeurs d'identification correspondantes.
  2. tokens() : pour transformer les phrases en mots.
  3. token_wordstem() : pour ramener les tokens à leur forme racine.
  4. dfm() : pour construire une matrice de caractéristiques de document qui a les documents en lignes et les mots/caractéristiques en colonnes. Chaque ligne correspond à un document différent et chaque colonne représente un mot/une caractéristique différent(e). Ensuite, les données résultantes sont transformées au format d'une matrice simple de triplets afin qu'il soit facile de calculer son produit croisé en utilisant la fonction
  5. tcrossprod_simple_triplet_matrix(). Et c'est ainsi que la matrice de similarité en cosinus est construite.

Ensuite, nous trouvons les 3 meilleures correspondances pour chaque document dans cette matrice de produit croisé correspondant à chaque entité du document.

About the authors

Vivek Jaykrishnan

Vivek Jaykrishnan

Vivek Jaykrishnan is an enterprise test consultant and architect with extensive experience. He has over 22 years of experience leading Verification and Validation functions, including functional, system, integration, and performance testing, in leadership positions with reputable organizations. Vivek has demonstrated success working across a variety of engagement models, including outsourced product verification and validation in service organizations, independent product verification and validation in captive units, and globally distributed development in a product company. Additionally, Vivek has extensive experience developing and implementing test strategies and driving testing in accordance with a variety of development methodologies, including continuous delivery, agile, iterative development, and the waterfall model. Vivek is passionate about incorporating cognitive intelligence into testing and is also interested in exploring the frontiers of IoT testing.

Vivek Sejpal

Vivek Sejpal

Vivek is an passionate data scientist with more than five years of experience in analytics and machine learning. He is currently engaged in the design and development of intelligent data-driven assets for quality engineering applications. Vivek works with customers on end-to-end engagements to demonstrate the value of various Intelligent asset offerings across domains/industries. Additionally, Vivek contributes to the research and development of new intelligent assets for the purpose of resolving critical business problems through a data-driven approach that is consistent with business requirements.

Abhinandan H PatilAbhinandan H Patil

Abhinandan is Author of 10 Technology Books and 14 Scientific Articles in Journals. Before this, he has worked in Wireless Network Software Organization as Lead Software Engineer for close to a decade. Abhinandan was in USA for two long stints and was instrumental in Releases of Mobility Manager at Motorola USA as Single Point of Contact for Network Simulator Tool. His Research is available as Books and Thesis in IJSER, USA. His Thesis published as Book is rated as one of the best Books of all time for Regression testing by BookAuthority.org. Awarded RULA Award for the same Thesis in 2019. He is Active Researcher in the field of Machine Learning, Deep Learning, Data Science, Artificial Intelligence, Regression Testing applied to Networks, Communication and Internet of Things. He is active contributor of Science, Technology, Engineering and Mathematics. He is currently working on few Undisclosed Books. He has started Blogging recently on Technology and Allied Areas. He is a RULA Research Awardee in 2019. He is Adarsh Vidya Saraswati Rashtriya Puraskar Awardee in year 2020. Abhinandan is Senior IEEE member since 2013 and is member of Smart Tribe and Cheeky Scientists Association. He also holds mini MBA from IBMI, Germany. UGC-NET Qualified (2012). Recipient of several Bravo awards for deserving work at Motorola. He is on the Editorial Board of few Scientific Journals. Dr. Patil is an ardent reader of STEM( Science, Technology, Engineering and Mathematics). He has a desire to contribute more to STEM.

About Capgemini

Capgemini is a global leader in partnering with companies to transform and manage their business by harnessing the power of technology. The Group is guided everyday by its purpose of unleashing human energy through technology for an inclusive and sustainable future. It is a responsible and diverse organisation of 270,000 team members in nearly 50 countries. With its strong 50 year heritage and deep industry expertise, Capgemini is trusted by its clients to address the entire breadth of their business needs, from strategy and design to operations, fueled by the fast evolving and innovative world of cloud, data, AI, connectivity, software, digital engineering and platforms. The Group reported in 2020 global revenues of €16 billion.

Get the Future You Want  I  www.capgemini.com

 

 

 

Capgemini logo