qacover
v2.0.0
QACOver ist eine Komponente zur Bewertung der Testdatenabdeckung in Bezug auf die SQL -Abfragen, die in einer Java- oder .NET -Anwendung ausgeführt werden. Die Abdeckung wird gemäß dem SQL -Kriterium (Full Predicate Deckung (SQLFPC), einer Variante von MCDC, die auf SQL -Abfragen zugeschnitten ist, gemessen. Das Kriterium bestimmt die interessierenden Situationen (Testabdeckungselemente), um eine SQL -Abfrage gegen die Testdatenbank zu testen. Diese Situationen werden als eine Reihe von Deckungsregeln dargestellt. Es besteht auch die Möglichkeit, die Abdeckung von Mutanten für SQL -Abfragen (SQLMutation -Kriterium) zu messen.
Jedes Mal, wenn die Anwendung eine Abfrage ausführt, fängt QACover die Abfrageausführung ab, generiert und bewertet die Deckungsregeln und speichert die Ergebnisse in der lokalen Entwicklungsumgebung.
Am Ende der Tests erhalten Sie die Zusammenfassung und Detailberichte über die Abdeckung von Testdaten. Dies ist ein Beispiel für den Zusammenfassungsbericht einer Testsitzung:
Beispiel für Java:
qacover-core zu Ihrem pom.xml hinzuqacover.properties und spy.properties vom qacover-core Ordner bis zur Wurzel Ihres Projekts.jdbc:sqlite:./target/TestDB.db die Verbindungszeichenfolge Ihrer Anwendung jdbc:p6spy:sqlite:./target/TestDB.db fügen jdbc ein :p6spy Dadurch werden das target/qacover/rules erstellt, der die internen Daten zur Abdeckungsbewertung enthält. So generieren Sie einen HTML -Bericht:
qacover-model-<VERSION>-report.jar von Maven Central herunter (gehen Sie zu Versionen und durchsuchen Sie die ausgewählte Version zum Herunterladen).java -jar qacover-model- < VERSION > -report.jar target/qacover/rules target/qacover/reportsindex.html , den Sie im Ordner target/qacover/reports gefunden haben. Wenn Sie feststellen, dass die Klassennamen nicht die an dem Interaktionspunkt sind, die die Abfrage ausführen, müssen Sie die Konfiguration so optimieren, dass einige Ausschlüsse für ihre Pakete enthalten sind (siehe später), entfernen Sie den Ordner target/qacover und wiederholen Sie dies erneut.
Ordner mit dem Testpaket QacoverSample enthält ein Beispiel für die Verwendung der Abdeckungsinformationen, um die Testdaten und Testfälle zu verbessern, um versteckte Fehler anzuzeigen. Es enthält drei sequenzielle Szenarien:
Veröffentlichungen der Java-Artefakte (Java 8 oder höher) werden in Maven Central unter der Gruppe ID io.github.giis-uniovi veröffentlicht. Es gibt zwei verschiedene Artefakte:
qacover-core : Das Hauptartefakt, das in Ihrer Anwendung als AA-Abhängigkeit verwendet werden soll (wie im schnellen Start gezeigt).qacover-model : Es enthält nur das Modell und die Klassen, um die Berichterstattung durchzuführen und die Deckungsregeln zu inspizieren. Verwenden Sie es, wenn Sie nur Zugriff auf zuvor generierte Deckungsregeln benötigen (z. B. Berichte aus einem Programm).Jeder von ihnen hat ein weiteres herunterladbares Glas, das zusätzliche Qualifikation enthält:
qacover-core Uber Jar. Es enthält alle benötigten Abhängigkeiten (ohne slf4j ) und sie sind schattiert (dh in einem anderen Namespace umbenannt, um Abhängigkeitskonflikte zu vermeiden):-uber -Qualifikationsmerkmal herunter, wenn Sie ihn aus irgendeinem Grund nicht als Abhängigkeit in Ihrer Anwendung verwenden können (z. B. für die Bereitstellung auf einem Anwendungsserver). Sie müssen lediglich das Glas in Ihre Serverbibliothek einfügen und die Konfiguration so einstellen, dass QACOver verwendet wird.<qualifier>uber</qualifier> zur Abhängigkeitserklärung.qacover-model -Standalone -Reporter: Laden Sie das Artefakt mit dem Qualifikationsmerkmal -report herunter, um die Berichte aus der Befehlszeile zu generieren, wie im schnellen Start gezeigt.Veröffentlichungen für .NET -Plattform werden in Nuget veröffentlicht. Das gleiche wie bei Java gibt es zwei verschiedene Pakete:
QACover : Das Hauptpaket (NetSpandard2.9), das als Paketreferenz in Ihre Projektkonfiguration aufgenommen wird (z. B. die .csproj -Datei, wenn Sie C#verwenden).QACoverReport : Ein DOTNET -Tool (netcore2.0) zum Generieren der Berichte aus der Befehlszeile: Installieren Sie das Tool mit dotnet tool install QACoverReport QACoverReport <rules folder> <reports folder> führen Sie es als Befehl aus. Auf Java müssen Sie zwei Konfigurationsdateien haben, um die Berichterstattung zu bewerten: qacover.properties und spy.properties und den Anpassen des JDBC -Treibers. Auf .NET Sie benötigen nur den ersten zusammen mit einem zusätzlichen Code, um die Abfragen abzufangen.
QACOver sucht nach den qacover.properties in dieser Reihenfolge:
Die im qacover-core Modul dieses Repo verfügbaren qacover.properties enthält eine allgemeine Konfiguration, die für gemeinsame Szenarien geeignet ist, aber manchmal muss sie angepasst werden. Weitere Informationen zu jedem Konfigurationsparameter finden Sie in der Datei. Als nächstes zeigen wir die wichtigsten, die die Einschluss- und Ausschlusskriterien sind.
Wenn eine Zeile einer Methode in Ihrer Anwendung eine SQL -Abfrage ( Interaktionspunkt ) ausführt, wird eine Kette von Aufrufen zu Methoden Ihres Frameworks ausgeführt, bis die Treibermethode erreicht wird, die die Abfrage tatsächlich ausführt. Hier ist der Punkt, an dem die tatsächliche Ausführung der Abfrage erkannt wird, aber wir wollen den Interaktionspunkt in der Anwendung bestimmen. Um dies zu erreichen, überprüft QACover den Anrufstapel am Punkt der tatsächlichen Ausführung und schließt nacheinander jeden Aufruf aus, den in jedem Framework -Paket getätigt wurde, bis der Punkt der Datenbankinteraktion in Ihrer Methode gefunden wird.
QACOver schließt die Systempakete wie die Java-, System-, P6SPY- oder die QACOver -Pakete aus. Abhängig vom Framework müssen Sie jedoch zusätzliche Ausschlüsse konfigurieren, indem Sie die Eigenschaft qacover.stack.exclusions in der Datei qacover.properties festlegen.
Beispiel : Ordner it/spring-petclinic-main enthält eine typische Probe aus Federschuh. Der Ausschluss wird deklariert als:
qacover.stack.exclusions=org.springframework.,org.hibernate.,com.zaxxer.hikari.,com.sun.,sun.reflect.
Dadurch werden die Framework -Klassen entfernt, die wir überspringen möchten, um den Interaktionspunkt zu lokalisieren, der sich in der org.springframework.samples.petclinic.PetclinicIntegrationTests -Klasse befindet.
In diesem speziellen Fall befindet sich der Interaktionspunkt jedoch unter org.springframework . Wir müssen den Parameter für Einschlüsse hinzufügen, um sicherzustellen, dass org.springframework.samples. ist nicht ausgeschlossen:
qacover.stack.inclusions=org.springframework.samples.
Es gibt andere Parameter, um Einschlusskriterien für Pakete und Ausschlusskriterien für Klassennamen oder Tabellennamen zu konfigurieren. Weitere Informationen finden Sie unter qacover.properties .
Die im qacover-core -Ordner dieses Repo verfügbaren spy.properties .
modulelist=giis.qacover.driver.InterceptorFactory muss immer vorhanden sein, um den Punkt anzugeben Weitere Informationen finden Sie in der Datei spy.properties oder P6Spy documentation .
Konfiguration für das .NET -Projekt Verwenden Sie dieselben qacover.properties wie Java, verwenden jedoch keine spy.properties . Stattdessen erfordert es eine Codierung:
DbContext erbt, siehe EG EF2InterceptorContext.cs Die Protokollierung kann für Pakete konfiguriert werden, beginnend mit giis.qacover. :
Zusätzlich zu Standardprotokollen werden andere Ordnerprotokoll- log-* im Ordner rules erstellt, um zusätzliche Debug-Informationen zu den ausgewerteten Abfragen, dem Datenbankschema und den Abdeckungsregeln anzuzeigen.
Die Berichtserzeugung erstellt im angegebenen Ordner eine Reihe statischer HTML -Dateien, um die Zusammenfassung und Details der Abdeckungsdaten problemlos zu untersuchen.
Um Berichte zu generieren, haben Sie drei Optionen:
qacover-model herunter, wie im schnellen Start und ausführen: java -jar qacover-model- < VERSION > -report.jar target/qacover/rules target/qacover/reportsqacover-model im Klassenpfad enthält: new giis . qacover . report . ReportManager (). run ( "target/qacover/rules" , "target/qacover/rules" );qacover-model als Abhängigkeit deklariert wird, führen Sie die ReportMain Methode mithilfe des exec-maven-plugin aus: < 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 > Die Datei index.html enthält die Zusammenfassung der Testdatenabdeckung für jede Klasse:
Wo:
Jeder Klassenname ist anklickbar, um einen Bericht anzuzeigen, der die Details für bewertete Abfragen enthält. Der Bericht für eine Klasse sieht aus wie:
... 
Durch Klicken auf den Abwärtspfeil in der Nähe der prozentualen Abdeckung bei der bewerteten Abfrage erweitert die Details jeder Deckungsregel (mit grün bedeckt, gelb aufgedeckt):
Die allgemeine Syntax des Berichtsgenerators verfügt über vier Parameter (nur die beiden ersten sind erforderlich, wenn Sie den Quellcode der untersuchten Klassen nicht angeben):
<rules-folder> <reports-folder> [<source-folders> [<project-folder>]]
Wenn Sie auf Java den Quellcode in die Berichte einbeziehen möchten, müssen Sie einen Wert für den dritten Parameter <source-folders> festlegen, um eine von Kommas getrennte Liste der Pfad (en) aufzunehmen, um die Quellen zu lokalisieren. Zum Beispiel:
src/main/java .module1/src/main/java,module2/src/main/java . Auf .NET müssen Sie sowohl für die dritte als auch für die vierte Parameter einen Wert festlegen: <source-folders> und <project-folder> . Der Grund dafür ist, dass der Speicherort von .NET -Quelldateien nicht genau mit den Namespaces übereinstimmt, sodass die FPC -Abdeckungsregeln den absoluten Pfad der Klassenquelldateien speichern, die vor der Berichtserzeugung auf einen relativen Pfad gelöst werden müssen. Zum Beispiel:
.../../../.. (weil das Standardverzeichnis, in dem die Tests ausgeführt werden, vier Ebenen im Lösungsordner beträgt)./app ausgeführt wird, setzen Sie die Parameter als . /app (mit dem Wert /app -Wert können Sie den relativen Pfad jeder Quelldatei aus dem Projektordner beheben). Siehe die allgemeinen Beitragsrichtlinien und Richtlinien für Giis-uniovi zu Beitrag.md.
Jetzt fügen wir einige zusätzliche technische Informationen zu Hintergrundinformationen hinzu:
QACOver nutzt P6Spy, um die JDBC -Aufrufe abzufangen, und TDRUEs, um das Datenbankschema zu erhalten, und den SQLRULES -Dienst aufzurufen, um die Abdeckungsregeln zu generieren. Die Ausführung von allem wird in Lokal gegen die in der Verbindungszeichenfolge konfigurierte Datenbank hergestellt.
Die interne Struktur der Haupt -QACOver -Pakete (Präfix giis.qacover. ) Ist unten dargestellt (die Präfixe werden zum Einfachheit halber weggelassen):
core : Enthält die Pakete driver , core und core.sevices .model : Enthält model , storage , reader und report .Dies sind die Abhängigkeiten zwischen Paketen:
Flussdiagramm TD
Treiber -> Kern
Core -> Services (Core.services)
Services -> Speicher
Speicher -> Modell
Kern -> Modell
Services -> Modell
Bericht -> Leser
Bericht -> Modell
Leser -> Modell
Leser -> Speicher
