qacover
v2.0.0
Qacover es un componente para evaluar la cobertura de datos de prueba en relación con las consultas SQL que se ejecutan en una aplicación Java o .NET. La cobertura se mide de acuerdo con el criterio de cobertura de predicado completo SQL (SQLFPC), una variante de MCDC adaptada a las consultas SQL. El criterio determina las situaciones de interés (elementos de cobertura de prueba) para probar una consulta SQL en la base de datos de prueba. Estas situaciones se representan como un conjunto de reglas de cobertura . También hay una opción para medir la cobertura de mutantes para consultas SQL (criterio SQLMutation).
Cada vez que la aplicación ejecuta una consulta, Qacover intercepta la ejecución de la consulta, genera y evalúa las reglas de cobertura y almacena los resultados en el entorno de desarrollo local.
Al final de las pruebas, puede obtener los informes resumidos y detallados de la cobertura de datos de la prueba. Este es un ejemplo del informe resumido de una sesión de prueba:
Ejemplo para Java:
qacover-core a su pom.xmlqacover.properties and spy.properties desde la carpeta qacover-core hasta la raíz de su proyecto.:p6spy afer jdbc (por ejemplo, si su cadena de conexión es jdbc:sqlite:./target/TestDB.db debe convertirse en jdbc:p6spy:sqlite:./target/TestDB.db ). Esto crea la carpeta target/qacover/rules que contiene los datos internos sobre la evaluación de la cobertura. Para generar un informe HTML:
qacover-model-<VERSION>-report.jar de Maven Central (vaya a versiones y luego busque la versión seleccionada para descargar).java -jar qacover-model- < VERSION > -report.jar target/qacover/rules target/qacover/reportsindex.html que encontrará en la carpeta target/qacover/reports . Si encuentra que los nombres de clases no son los que están en el punto de interacción que ejecuta la consulta, deberá ajustar la configuración para incluir algunas exclusiones para sus paquetes (ver más adelante), eliminar la carpeta target/qacover y repetir nuevamente.
La carpeta con el paquete de prueba Qacoversample contiene un ejemplo de cómo usar la información de cobertura para mejorar los datos de prueba y los casos de prueba para revelar errores ocultos. Contiene tres escenarios secuenciales:
Los lanzamientos de los artefactos de Java (Java 8 o superior) se publican en Maven Central bajo el grupo ID io.github.giis-uniovi . Hay dos artefactos diferentes:
qacover-core : el artefacto principal a usar como dependencia de AA en su aplicación (como se muestra en el inicio rápido).qacover-model : solo incluye el modelo y las clases para hacer informes e inspeccionar las reglas de cobertura. Úselo si solo necesita acceso a reglas de cobertura generadas anteriormente (por ejemplo, para generar informes de un programa).Cada uno de ellos tiene otro frasco descargable que incluye un calificador adicional:
qacover-core Uber Jar. Incluye todas las dependencias necesarias (excluyendo slf4j ) y están sombreadas (es decir, renombradas en un espacio de nombres diferente para evitar conflictos de dependencia):-uber si por alguna razón no puede usarlo como dependencia en su aplicación (por ejemplo, implementar en un servidor de aplicaciones). Simplemente debe colocar el jar en la biblioteca de su servidor y establecer la configuración para usar Qacover.<qualifier>uber</qualifier> a la declaración de dependencia.qacover-model Standalone Reporter: Descargue el artefacto con el calificador -report para generar los informes desde la línea de comando como se muestra en el inicio rápido.Los lanzamientos para la plataforma .NET se publican en Nuget. Lo mismo que para Java, hay dos paquetes diferentes:
QACover : el paquete principal (NetStandard2.9) incluirá como referencia de paquete en la configuración de su proyecto (por ejemplo, el archivo .csproj si está utilizando C#).QACoverReport : una herramienta Dotnet (NetCore2.0) para generar los informes desde la línea de comando: Instale la herramienta con dotnet tool install QACoverReport y ejecutarla como un comando QACoverReport <rules folder> <reports folder> . En Java, debe tener dos archivos de configuración para evaluar la cobertura: qacover.properties y spy.properties y personalizar el controlador JDBC. En .NET solo necesita el primero junto con algún código adicional para interceptar las consultas.
Qacover busca el qacover.properties en este orden:
El qacover.properties disponibles en el módulo qacover-core de este repositorio contiene una configuración general adecuada para escenarios comunes, pero a veces debe ser personalizado. Consulte el archivo para obtener detalles sobre cada parámetro de configuración. A continuación, destacamos los más importantes que son los criterios de inclusión y exclusión.
Cuando una línea de un método en su aplicación ejecuta una consulta SQL ( punto de interacción ), una cadena de llamadas a los métodos de su marco se ejecuta hasta alcanzar el método del controlador que realmente ejecuta la consulta. Aquí está el punto en el que se detecta la ejecución real de la consulta, pero lo que queremos es determinar el punto de interacción en la aplicación. Para lograr esto, Qacover verifica la pila de llamadas en el punto de la ejecución real y excluye sucesivamente cada llamada realizada en cualquier paquete de marco hasta que localice el punto de la interacción de la base de datos en su método.
Qacover excluye los paquetes del sistema como Java, System, P6SPY o los paquetes Qacover, pero dependiendo del marco, debe configurar exclusiones adicionales configurando la propiedad qacover.stack.exclusions en el archivo qacover.properties .
Ejemplo : la carpeta it/spring-petclinic-main contiene una muestra típica del arranque de resorte. La exclusión se declara como:
qacover.stack.exclusions=org.springframework.,org.hibernate.,com.zaxxer.hikari.,com.sun.,sun.reflect.
Eso elimina las clases de marco que queremos omitir para localizar el punto de interacción que se encuentra en la clase org.springframework.samples.petclinic.PetclinicIntegrationTests .
Sin embargo, en este caso particular, el punto de interacción está bajo org.springframework . Debemos agregar el parámetro de inclusión para garantizar que org.springframework.samples. no está excluido:
qacover.stack.inclusions=org.springframework.samples.
Existen otros parámetros para configurar los criterios de inclusión para los paquetes y los criterios de exclusión para nombres de clases o nombres de tabla. Consulte qacover.properties para obtener más detalles.
El spy.properties disponible en la carpeta qacover-core de este repositorio contiene la configuración mínima requerida por P6SPY:
modulelist=giis.qacover.driver.InterceptorFactory siempre debe estar presente para indicar el punto en el que P6SPY pasa el control a Qacover Consulte el archivo spy.properties o la P6Spy documentation para obtener más detalles.
Configuración para el proyecto .NET Use la misma qacover.properties que Java, pero no usa spy.properties . En cambio, requiere algo de codificación:
DbContext , ver EF EF2Interceptorcontext.cs El registro se puede configurar para paquetes que comienzan con giis.qacover. :
Además de los registros estándar, otros log-* de carpetas se crean en la carpeta rules para mostrar información de depuración adicional sobre las consultas que se evalúan, el esquema de la base de datos y las reglas de cobertura.
La generación de informes crea un conjunto de archivos HTML estáticos en la carpeta designada, para inspeccionar fácilmente el resumen y los detalles de los datos de cobertura.
Para generar informes, tiene tres opciones:
qacover-model como se muestra en el inicio rápido y ejecuta: java -jar qacover-model- < VERSION > -report.jar target/qacover/rules target/qacover/reportsqacover-model en el classpath: new giis . qacover . report . ReportManager (). run ( "target/qacover/rules" , "target/qacover/rules" );qacover-model se declara como una dependencia, ejecute el método ReportMain utilizando el 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 > El archivo index.html contiene el resumen de la cobertura de datos de prueba para cada clase:
dónde:
Cada nombre de clase se puede hacer clic para mostrar un informe que contiene los detalles de las consultas que se han evaluado. El informe para una clase parece:
... 
Al hacer clic en la flecha hacia abajo cerca del porcentaje de cobertura en la consulta evaluada, expande los detalles de cada regla de cobertura (cubierta de verde, descubierta en amarillo):
La sintaxis general del generador de informes tiene cuatro parámetros (solo se requieren los dos primeros si no incluye el código fuente de las clases en prueba):
<rules-folder> <reports-folder> [<source-folders> [<project-folder>]]
En Java, si desea incluir el código fuente en los informes, debe establecer un valor para el tercer parámetro <source-folders> para incluir una lista separada por comas de las rutas para localizar las fuentes. Por ejemplo:
src/main/java .module1/src/main/java,module2/src/main/java . En .NET, debe establecer un valor para el tercer y cuarto parámetros: <source-folders> y <project-folder> . La razón es que la ubicación de los archivos de origen .NET no coincide exactamente con los espacios de nombres, de modo que las reglas de cobertura de FPC almacenan la ruta absoluta de los archivos de origen de clase que deben resolverse a una ruta relativa antes de la generación de informes. Por ejemplo:
.../../../.. (porque el directorio predeterminado donde se ejecutan las pruebas son cuatro niveles en la carpeta de la solución)/app , establezca los parámetros como . /app (el valor /app permite resolver la ruta relativa de cada archivo de origen en la carpeta del proyecto). Consulte las políticas y directrices de contribución general para GIIS-Uniovi en Caboning.md.
Ahora incluimos información técnica de fondo adicional:
Qacover hace uso de P6SPY para interceptar las llamadas JDBC, tdRules para obtener el esquema de la base de datos e invocar el servicio SQLRULUS para generar las reglas de cobertura. La ejecución de todo se realiza en local en la base de datos configurada en la cadena de conexión.
La estructura interna de los principales paquetes Qacover (prefijo giis.qacover. ) Se muestra a continuación (los prefijos se omiten por simplicidad):
core : contiene los paquetes de driver , core y core.sevices .model : contiene los paquetes de model , storage , reader e report .Estas son las dependencias entre paquetes:
TD de diagrama de flujo
Conductor -> Core
Core -> Servicios (core.services)
Servicios -> Almacenamiento
Almacenamiento -> Modelo
Core -> Modelo
Servicios -> Modelo
Informe -> Lector
Informe -> Modelo
Lector -> Modelo
Lector -> Almacenamiento
