qacover
v2.0.0
Qacover est un composant pour évaluer la couverture des données de test par rapport aux requêtes SQL qui sont exécutées dans une application Java ou .NET. La couverture est mesurée selon le critère de couverture de prédicat SQL (SQLFPC), une variante de MCDC adaptée aux requêtes SQL. Le critère détermine les situations d'intérêt (éléments de couverture de test) pour tester une requête SQL par rapport à la base de données de test. Ces situations sont représentées comme un ensemble de règles de couverture . Il existe également une option pour mesurer la couverture des mutants pour les requêtes SQL (critère SQLMutation).
Chaque fois que l'application exécute une requête, Qacover intercepte l'exécution de la requête, génère et évalue les règles de couverture et stocke les résultats dans l'environnement de développement local.
À la fin des tests, vous pouvez obtenir le résumé et les rapports détaillés de la couverture des données de test. Ceci est un exemple du rapport de résumé d'une session de test:
Exemple pour Java:
qacover-core à votre pom.xmlqacover.properties et spy.properties du dossier qacover-core à la racine de votre projet.:p6spy AFER jdbc (par exemple, si votre chaîne de connexion est jdbc:sqlite:./target/TestDB.db Il doit devenir jdbc:p6spy:sqlite:./target/TestDB.db ). Cela crée la target/qacover/rules qui contient les données internes sur l'évaluation de la couverture. Pour générer un rapport HTML:
qacover-model-<VERSION>-report.jar de Maven Central (allez dans les versions, puis parcourez la version sélectionnée à télécharger).java -jar qacover-model- < VERSION > -report.jar target/qacover/rules target/qacover/reportsindex.html que vous trouverez dans le dossier target/qacover/reports . Si vous constatez que les noms de classe ne sont pas ceux au point d'interaction qui exécute la requête, vous devrez modifier la configuration pour inclure des exclusions pour leurs packages (voir plus tard), supprimez le dossier target/qacover et répétez à nouveau.
Le dossier avec le package de test Qacoversamp contient un exemple de la façon d'utiliser les informations de couverture pour améliorer les données de test et les cas de test pour révéler des bogues cachés. Il contient trois scénarios séquentiels:
Les sorties des artefacts Java (Java 8 ou plus) sont publiées dans Maven Central sous le groupe Id io.github.giis-uniovi . Il y a deux artefacts différents:
qacover-core : L'artefact principal à utiliser comme dépendance AA dans votre application (comme indiqué dans le démarrage rapide).qacover-model : Il inclut uniquement le modèle et les classes à faire des rapports et pour inspecter les règles de couverture. Utilisez-le si vous n'avez besoin que d'accès aux règles de couverture générées précédemment (par exemple pour générer des rapports à partir d'un programme).Chacun d'eux a un autre pot téléchargeable qui comprend un qualificatif supplémentaire:
qacover-core . Il comprend toutes les dépendances nécessaires (à l'exclusion de slf4j ) et elles sont ombrées (c'est-à-dire renommées dans un espace de noms différent pour éviter les conflits de dépendance):-uber si pour une raison quelconque, vous ne pouvez pas l'utiliser comme dépendance dans votre application (par exemple, pour déployer dans un serveur d'applications). Vous devez simplement mettre le pot dans la bibliothèque de votre serveur et définir la configuration pour utiliser QACOver.<qualifier>uber</qualifier> à la déclaration de dépendance.qacover-model HAUTALONE REPORTER: Téléchargez l'artefact avec le qualificatif -report pour générer les rapports à partir de la ligne de commande comme indiqué dans le démarrage rapide.Les versions de .NET Platform sont publiées dans NuGet. Comme pour Java, il y a deux packages différents:
QACover : le package principal (netstandard2.9) à inclure en tant que référence de package dans la configuration de votre projet (par exemple, le fichier .csproj si vous utilisez C #).QACoverReport : Un outil DOTNET (Netcore2.0) Pour générer les rapports à partir de la ligne de commande: Installez l'outil avec dotnet tool install QACoverReport et exécutez-le en tant que dossier de commande QACoverReport <rules folder> <reports folder> . Sur Java, vous devez avoir deux fichiers de configuration pour évaluer la couverture: qacover.properties et spy.properties et pour personnaliser le pilote JDBC. Sur .NET, vous n'avez besoin que du premier avec un code supplémentaire pour intercepter les requêtes.
Qacover recherche le qacover.properties dans cet ordre:
Le qacover.properties disponibles dans le module qacover-core de ce référentiel contient une configuration générale adaptée aux scénarios communs, mais parfois il doit être personnalisé. Voir le fichier pour plus de détails sur chaque paramètre de configuration. Ensuite, nous soulignons les plus importants qui sont les critères d'inclusion et d'exclusion.
Lorsqu'une ligne d'une méthode dans votre application exécute une requête SQL ( point d'interaction ), une chaîne d'appels aux méthodes de votre cadre est exécutée jusqu'à atteindre la méthode du pilote qui exécute réellement la requête. Voici le point où l'exécution réelle de la requête est détectée, mais ce que nous voulons, c'est déterminer le point d'interaction dans l'application. Pour y parvenir, Qacover vérifie la pile d'appels au point de l'exécution réelle et exclut successivement chaque appel fait dans n'importe quel package de framework jusqu'à ce qu'il localise le point de l'interaction de la base de données dans votre méthode.
Qacover exclut les packages système comme les packages Java, System, P6Spy ou Qacover, mais en fonction du framework, vous devez configurer des exclusions supplémentaires en définissant la propriété qacover.stack.exclusions dans le fichier qacover.properties .
Exemple : le dossier it/spring-petclinic-main contient un échantillon typique de Spring Boot. L'exclusion est déclarée:
qacover.stack.exclusions=org.springframework.,org.hibernate.,com.zaxxer.hikari.,com.sun.,sun.reflect.
Cela supprime les classes de framework que nous voulons ignorer pour localiser le point d'interaction qui se trouve à la classe org.springframework.samples.petclinic.PetclinicIntegrationTests .
Cependant, dans ce cas particulier, le point d'interaction est sous org.springframework . Nous devons ajouter le paramètre Inclusions pour nous assurer que org.springframework.samples. n'est pas exclu:
qacover.stack.inclusions=org.springframework.samples.
Il existe d'autres paramètres pour configurer les critères d'inclusion pour les packages et les critères d'exclusion pour les noms de classe ou les noms de table. Voir qacover.properties pour plus de détails.
Le spy.properties disponibles dans le dossier qacover-core de ce dépôt contient la configuration minimale requise par P6Spy:
modulelist=giis.qacover.driver.InterceptorFactory doit toujours être présent pour indiquer le point où P6Spy passe le contrôle à Qacover Voir le fichier spy.properties ou la P6Spy documentation pour plus de détails.
Configuration pour .NET Project Utilisez le même qacover.properties que Java, mais n'utilise pas spy.properties . Au lieu de cela, cela nécessite un codage:
DbContext , voir par exemple ef2interceptorcontext.cs La journalisation peut être configurée pour les packages en commençant par giis.qacover. :
En plus des journaux standard, d'autres dossiers log-* sont créés dans le dossier rules pour afficher des informations de débogage supplémentaires sur les requêtes qui sont évaluées, le schéma de base de données et les règles de couverture.
La génération de rapports crée un ensemble de fichiers HTML statiques dans le dossier désigné, pour inspecter facilement le résumé et les détails des données de couverture.
Pour générer des rapports, vous avez trois options:
qacover-model comme indiqué dans le démarrage rapide et exécutez: java -jar qacover-model- < VERSION > -report.jar target/qacover/rules target/qacover/reportsqacover-model dans le chemin de classe: new giis . qacover . report . ReportManager (). run ( "target/qacover/rules" , "target/qacover/rules" );qacover-model est déclaré comme dépendance, exécutez la méthode ReportMain à l'aide de l' exec-maven-plugin : < plugin >
< groupId >org.codehaus.mojo</ groupId >
< artifactId >exec-maven-plugin</ artifactId >
< version >1.6.0</ version >
< executions >
< execution >
< id >qacover-report</ id >
< phase >post-integration-test</ phase >
< goals >
< goal >java</ goal >
</ goals >
< configuration >
< classpathScope >test</ classpathScope >
< classpath />
< mainClass >giis.qacover.report.ReportMain</ mainClass >
< arguments >
< argument >target/qacover/rules</ argument >
< argument >target/qacover/reports</ argument >
</ arguments >
</ configuration >
</ execution >
</ executions >
</ plugin > Le fichier index.html contient le résumé de la couverture des données de test pour chaque classe:
où:
Chaque nom de classe est cliquable pour afficher un rapport qui contient les détails des requêtes qui ont été évaluées. Le rapport pour une classe ressemble:
... 
Cliquez sur la flèche vers le bas près de la couverture en pourcentage de la requête évaluée élargit les détails de chaque règle de couverture (couvert de vert, découvert en jaune):
La syntaxe générale du générateur de rapports a quatre paramètres (seuls les deux premiers sont requis si vous n'incluez pas le code source des classes testées):
<rules-folder> <reports-folder> [<source-folders> [<project-folder>]]
Sur Java, si vous souhaitez inclure le code source dans les rapports, vous devez définir une valeur pour le troisième paramètre <source-folders> pour inclure une liste séparée par des virgules du (s) chemin (s) pour localiser les sources. Par exemple:
src/main/java .module1/src/main/java,module2/src/main/java . Sur .NET, vous devez définir une valeur pour les troisième et quatrième paramètres: <source-folders> et <project-folder> . La raison en est que l'emplacement des fichiers source .NET ne correspond pas exactement aux espaces de noms, de sorte que les règles de couverture FPC stockent le chemin absolu des fichiers source de classe qui doit être résolu en un chemin relatif avant la génération de rapport. Par exemple:
.../../../.. (Parce que le répertoire par défaut où les tests s'exécutent est de quatre niveaux dans le dossier de solution)/app , définissez les paramètres AS . /app (la valeur /app permet de résoudre le chemin relatif de chaque fichier source à partir du dossier du projet). Voir les politiques et directives de contribution générales pour Giis-Uniovi à contribution.md.
Nous incluons maintenant quelques informations techniques de fond supplémentaires:
Qacover utilise P6Spy pour intercepter les appels JDBC, TDRULES pour obtenir le schéma de la base de données et invoquer le service SQLRULES pour générer les règles de couverture. L'exécution de tout est faite en local par rapport à la base de données configurée dans la chaîne de connexion.
La structure interne des packages QACOver principaux (préfixe giis.qacover. ) Est illustré ci-dessous (les préfixes sont omis pour la simplicité):
core : contient le driver , core et core.sevices .model : contient le model , storage , reader et les packages report .Ce sont les dépendances entre les packages:
Organigramme TD
Conducteur -> Core
Core -> Services (Core.Services)
services -> stockage
stockage -> modèle
Core -> modèle
services -> modèle
Rapport -> lecteur
Rapport -> modèle
lecteur -> modèle
lecteur -> stockage
