qacover
v2.0.0
O QACover é um componente para avaliar a cobertura dos dados do teste em relação às consultas SQL que são executadas em um aplicativo Java ou .NET. A cobertura é medida de acordo com o critério de cobertura de predicado total do SQL (SQLFPC), uma variante do MCDC adaptada às consultas SQL. O critério determina as situações de interesse (itens de cobertura de teste) para testar uma consulta SQL em relação ao banco de dados de teste. Essas situações são representadas como um conjunto de regras de cobertura . Há também uma opção para medir a cobertura de mutantes para consultas SQL (critério de Sqlmuation).
Cada vez que o aplicativo executa uma consulta, o Qacover intercepta a execução da consulta, gera e avalia as regras de cobertura e armazena os resultados no ambiente de desenvolvimento local.
No final dos testes, você pode obter os relatórios de resumo e detalhamento da cobertura de dados de teste. Este é um exemplo do relatório resumido de uma sessão de teste:
Exemplo para Java:
qacover-core ao seu pom.xmlqacover.properties and spy.properties da pasta qacover-core para a raiz do seu projeto.:p6spy afer jdbc (por exemplo, se sua sequência de conexão for jdbc:sqlite:./target/TestDB.db deve se tornar jdbc:p6spy:sqlite:./target/TestDB.db ). Isso cria o target/qacover/rules que contêm os dados internos sobre a avaliação da cobertura. Para gerar um relatório HTML:
qacover-model-<VERSION>-report.jar da Maven Central (vá para versões e, em seguida, navegue na versão selecionada para download).java -jar qacover-model- < VERSION > -report.jar target/qacover/rules target/qacover/reportsindex.html que você encontrará na pasta target/qacover/reports . Se você achar que os nomes da classe não são os que estão no ponto de interação que executa a consulta, você precisará ajustar a configuração para incluir algumas exclusões para seus pacotes (veja posteriormente), remova a pasta target/qacover e repita novamente.
A pasta com o pacote de teste Qacoversample contém um exemplo de como usar as informações de cobertura para melhorar os dados de teste e os casos de teste para revelar bugs ocultos. Ele contém três cenários seqüenciais:
Os lançamentos dos artefatos Java (Java 8 ou superior) são publicados no Maven Central sob o grupo ID io.github.giis-uniovi . Existem dois artefatos diferentes:
qacover-core : o artefato principal a ser usado como dependência de AA em seu aplicativo (como mostrado no início rápido).qacover-model : Inclui apenas o modelo e as classes para reportar e inspecionar as regras de cobertura. Use -o se você precisar apenas de acesso a regras de cobertura geradas anteriormente (por exemplo, para gerar relatórios de um programa).Cada um deles possui outro frasco para download que inclui qualificador adicional:
qacover-core . Inclui todas as dependências necessárias (excluindo slf4j ) e elas são sombreadas (ou seja, renomeada em um espaço para nome diferente para evitar conflitos de dependência):-uber se, por qualquer motivo, você não puder usá -lo como uma dependência em seu aplicativo (por exemplo, implantar em um servidor de aplicativos). Você simplesmente precisa colocar o frasco na biblioteca do seu servidor e definir a configuração para usar o QACover.<qualifier>uber</qualifier> à declaração de dependência.qacover-model : Baixe o artefato com o qualificador -report para gerar os relatórios da linha de comando, conforme mostrado no início rápido.Os lançamentos para a plataforma .NET são publicados em NuGet. O mesmo que para Java, existem dois pacotes diferentes:
QACover : o pacote principal (NetStandard2.9) para incluir como uma referência de pacote na configuração do seu projeto (por exemplo, o arquivo .csproj se você estiver usando C#).QACoverReport : Uma ferramenta DOTNET (NETCORE2.0) para gerar os relatórios da linha de comando: instale a ferramenta com dotnet tool install QACoverReport e execute -o como um comando QACoverReport <rules folder> <reports folder> . No Java, você precisa ter dois arquivos de configuração para avaliar a cobertura: qacover.properties and spy.properties e personalizar o driver JDBC. No .NET, você só precisa do primeiro, juntamente com algum código adicional para interceptar as consultas.
Qacover procura o qacover.properties nesta ordem:
O qacover.properties disponíveis no módulo qacover-core deste repo contém uma configuração geral adequada para cenários comuns, mas às vezes deve ser personalizada. Consulte o arquivo para obter detalhes em cada parâmetro de configuração. Em seguida, destacamos os mais importantes que são os critérios de inclusão e exclusão.
Quando uma linha de um método em seu aplicativo executa uma consulta SQL ( ponto de interação ), uma cadeia de chamadas para métodos da sua estrutura é executada até atingir o método do driver que realmente executa a consulta. Aqui está o ponto em que a execução real da consulta é detectada, mas o que queremos é determinar o ponto de interação no aplicativo. Para conseguir isso, o Qacover verifica a pilha de chamadas no ponto da execução real e exclui sucessivamente todas as chamadas feitas em qualquer pacote de estrutura até localizar o ponto da interação do banco de dados em seu método.
O QACover exclui os pacotes do sistema como os pacotes Java, System, P6SPY ou QACover, mas, dependendo da estrutura, você deve configurar exclusões adicionais definindo a propriedade qacover.stack.exclusions no arquivo qacover.properties .
Exemplo : Pasta it/spring-petclinic-main contém uma amostra típica da bota de mola. A exclusão é declarada como:
qacover.stack.exclusions=org.springframework.,org.hibernate.,com.zaxxer.hikari.,com.sun.,sun.reflect.
Isso remove as classes de estrutura que queremos pular para localizar o ponto de interação que está na classe org.springframework.samples.petclinic.PetclinicIntegrationTests .
No entanto, nesse caso em particular, o ponto de interação está em org.springframework . Devemos adicionar o parâmetro de inclusões para garantir que org.springframework.samples. não é excluído:
qacover.stack.inclusions=org.springframework.samples.
Existem outros parâmetros para configurar critérios de inclusão para pacotes e critérios de exclusão para nomes de classe ou nomes de tabela. Consulte qacover.properties para obter mais detalhes.
O spy.properties disponíveis na pasta qacover-core deste repo contém a configuração mínima exigida pelo P6SPY:
modulelist=giis.qacover.driver.InterceptorFactory deve estar sempre presente para indicar o ponto em que o P6SPY passa o controle para Qacover Consulte o arquivo spy.properties ou a P6Spy documentation para obter mais detalhes.
Configuração para o projeto .NET Use o mesmo qacover.properties que o Java, mas não usa spy.properties . Em vez disso, requer alguma codificação:
DbContext , consulte EF2InterceptContext.cs O registro pode ser configurado para pacotes começando com giis.qacover. :
Além dos logs padrão, outras pastas log-* são criadas na pasta rules para exibir informações adicionais de depuração sobre as consultas avaliadas, o esquema do banco de dados e as regras de cobertura.
A geração do relatório cria um conjunto de arquivos HTML estáticos na pasta designada, para inspecionar facilmente o resumo e os detalhes dos dados de cobertura.
Para gerar relatórios, você tem três opções:
qacover-model como mostrado no início rápido e execute: java -jar qacover-model- < VERSION > -report.jar target/qacover/rules target/qacover/reportsqacover-model no ClassPath: new giis . qacover . report . ReportManager (). run ( "target/qacover/rules" , "target/qacover/rules" );qacover-model for declarado como uma dependência, execute o método ReportMain usando o 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 > O arquivo index.html contém o resumo da cobertura de dados de teste para cada classe:
onde:
Cada nome da classe é clicável para exibir um relatório que contém os detalhes das consultas que foram avaliadas. O relatório para uma aula parece:
... 
Clicar na seta para baixo perto da porcentagem de cobertura na consulta avaliada expande os detalhes de cada regra de cobertura (coberta em verde, descoberta em amarelo):
A sintaxe geral do gerador de relatórios possui quatro parâmetros (apenas os dois primeiros são necessários se você não incluir o código -fonte das classes em teste):
<rules-folder> <reports-folder> [<source-folders> [<project-folder>]]
No Java, se você deseja incluir o código-fonte nos relatórios, precisará definir um valor para o terceiro parâmetro <source-folders> para incluir uma lista separada por vírgula do (s) caminho (s) para localizar as fontes. Por exemplo:
src/main/java .module1/src/main/java,module2/src/main/java . No .NET, você deve definir um valor para o terceiro e o quarto parâmetros: <source-folders> e <project-folder> . O motivo é que o local dos arquivos de origem .NET não corresponde exatamente aos espaços para nome, de modo que as regras de cobertura do FPC armazenam o caminho absoluto dos arquivos de origem da classe que devem ser resolvidos para um caminho relativo antes da geração de relatórios. Por exemplo:
.../../../.. (porque o diretório padrão em que os testes são executados em quatro níveis na pasta da solução)/app , defina os parâmetros como . /app (o valor /app permite resolver o caminho relativo de cada arquivo de origem da pasta do projeto). Veja as políticas e diretrizes de contribuição geral para GIIS-UNIOVI em contribuindo.md.
Agora incluímos algumas informações técnicas adicionais de fundo:
O QACover faz uso do P6SPY para interceptar as chamadas JDBC, TDRULES para obter o esquema do banco de dados e invocar o serviço SQLRULES para gerar as regras de cobertura. A execução de tudo é feita no local contra o banco de dados configurado na string de conexão.
A estrutura interna dos principais pacotes QACover (prefixo giis.qacover. ) É mostrada abaixo (os prefixos são omitidos por simplicidade):
core : contém os pacotes driver , core e core.sevices .model : contém pacotes de model , storage , reader e report .Estas são as dependências entre os pacotes:
Fluxograma TD
Driver -> Core
núcleo -> serviços (Core.Services)
Serviços -> Armazenamento
Armazenamento -> Modelo
núcleo -> modelo
Serviços -> Modelo
Relatório -> leitor
Relatório -> Modelo
Leitor -> Modelo
Leitor -> Armazenamento
