manual de ensaio de proficiência em software · manual de ensaio de proficiência em software 4....

Manual de Ensaio de Proficiência em Software

Sumário

Introdução 1

Procedimento criptográfico para inscrição na rodada de EP 2

Procedimentos de recebimento e verificação do Pacote de EP 2

Visão geral da metodologia 3

Elementos do Ensaio de Proficiência 3

Procedimento de entrega do registro de resultados do EP 6

Exemplo do procedimento de Ensaio 7

APÊNDICE A – Geração de chaves PGP e exportação de chave pública para inscrição no Ensaio de proficiência 18

APÊNDICE B – Recebimento do Pacote de EP 21

APÊNDICE C – Entrega do registro de resultados do EP 22

APÊNDICE D – Script de comparação automática de relatórios 23

1. Introdução

O Ensaio de proficiência (EP) é um mecanismo de avaliação de desempenho de laboratórios. Ele identifica problemas de ensaio e medição, compara métodos e procedimentos, gerencia materiais de referência e satisfaz interesses de organismos reguladores e de acreditação. Esta rodada de EP foi desenvolvida para avaliar a competência de laboratórios que realizam avaliação da conformidade de software e permitir alinhamento técnico entre os mesmos. Para realizar esta rodada, um software de código aberto foi adotado como item de ensaio e 7 (sete) casos de teste foram elaborados

1


para alguns trechos desse software. Utilizando o mecanismo de cobertura de código (descrito no Plano de Trabalho), o laboratório participante deve demonstrar a competência em analisar o código reproduzindo os casos de teste e emitindo relatórios que estejam de acordo com os relatórios referência apresentados pelo Inmetro (provedor do ensaio de proficiência). O objetivo deste manual é auxiliar o laboratório participante quanto ao entendimento do pacote de EP (incluindo o item de EP, ferramentas, arquivos necessários e auxiliares) e quanto aos procedimentos de recebimento do pacote de EP e de entrega das respostas.

2. Procedimento criptográfico para inscrição na rodada de EP

Como parte da inscrição na rodada de Ensaio de Proficiência, o laboratório participante deverá informar no formulário os seguintes dados criptográficos: sua chave-pública PGP (RSA 2048), e o fingerprint dessa chave.

No APÊNDICE A, descrevemos uma forma de como gerar esses dados.

3. Procedimentos de recebimento e verificação do Pacote de EP

Previamente à data de início desta rodada, o participante receberá o link para o download do Pacote de Ensaio de Proficiência e da chave-pública PGP do Inmetro (gerada especificamente para esta rodada de EP).

Ao receber o pacote, o participante deverá verificar a sua integridade, comparando seu valor de hash (SHA-256) com o valor disponibilizado no Plano de Trabalho - EP de Software. Caso os valores sejam diferentes, sugerimos que refaça o download do pacote e repita o procedimento de verificação do valor de hash. Caso o resultado divergente permaneça, sugerimos que o participante obtenha uma cópia do pacote em mídia física, juntamente ao Inmetro.

O Pacote de EP é encriptado com um código de acesso (passphrase), o qual é disponibilizado ao início da rodada de EP. Após decriptar o pacote e verificar a assinatura digital do Inmetro, o participante deverá: verificar o valor de hash do arquivo decriptado resultante; assinar digitalmente esse valor; e informá-lo ao Inmetro como confirmação de recebimento do Pacote de EP.

No APÊNDICE B, descrevemos uma forma de como realizar esses procedimentos citados acima.

2


4. Visão geral da metodologia

Para essa metodologia de Ensaio de Proficiência, o conceito de cobertura de código e testes de unidade são utilizados de maneira diferente da abordada em Engenharia de software. Aqui é definido que, dado um código fonte de um software (item de EP) e dado um conjunto de linhas cobertas deste código (relatório de referência) por um teste de unidade de referência implementado pelo provedor da rodada, o laboratório participante deverá tentar cobrir o mesmo conjunto de linhas, elaborando um teste de unidade sem conhecer o de referência. A metodologia de EP por cobertura de código parte do princípio que a capacidade de analisar códigos fonte de um software é uma competência requerida para laboratórios envolvidos com análise de software.

O laboratório participante deverá implementar seu próprio teste de unidade e emitir seu relatório com o conjunto de linhas de código pelo teste. Depois de entregues os relatórios e testes de unidade, o provedor do EP os avalia e calcula uma nota em relação à proficiência de cada laboratório de acordo com métricas de avaliação pré-estabelecidas. Caso o laboratório obtenha uma boa avaliação, pode-se concluir que ele tem um bom entendimento do código relacionado àqueles testes e, por consequência, que o laboratório é proficiente na atividade de análise de software.

5. Elementos do Ensaio de Proficiência

5.1. Pacote de Ensaio de Proficiência

Ao início desta rodada o laboratório participante vai receber um Pacote de Ensaio de Proficiência. Esse pacote digital é uma máquina virtual (VM, virtual machine) que possui ferramentas e arquivos fundamentais e auxiliares, devidamente instalados e configurados, para a realização deste Ensaio de Proficiência. As ferramentas e arquivos fundamentais são indispensáveis para realizar esta rodada de EP, bem como suas versões. As ferramentas auxiliares podem ser substituídas por outras e os arquivos auxiliares são disponibilizados para facilitar a análise dos relatórios, mas também podem ser substituídas por outros métodos de análise. A listagem abaixo descreve o conteúdo desse ambiente virtualizado:

● Ferramentas/arquivos fundamentais:

○ Biblioteca de cobertura de código: JaCoCo 3.1.2 (Java Code Coverage Library);

3


○ Testes: Relatórios JaCoCo em xml de referência dos testes realizados pelo provedor (localizados em /home/lab/ep/T00x/ , onde “x” é um valor de 1 a 7);

○ Item de ensaio de proficiência: código-fonte e uma versão funcional do produto de software escolhido para a rodada de EP.

■ Alliance P2P - Versão 1.2.0 (build 1281)

● Ferramentas/arquivos auxiliares:

○ Eclipse IDE for Enterprise Java Developers - Versão: 2019-03 (4.11.0);

■ Java-8-Openjdk-amd64;

■ Junit 5;

○ comparaRelatorios.py: script de comparação automática para facilitar na identificação das linhas cobertas pelos testes de unidade. Mais informações podem ser encontradas no APÊNDICE D;

○ zeresima.xml: relatório JaCoCo em xml formado por linhas zeradas simulando um teste de unidade que não cobre nenhum linha. Ele auxilia na comparação aos relatórios de referência para identificação das linhas cobertas. Mais informações podem ser encontradas no APÊNDICE D.

Caso queira, o laboratório participante pode instalar todos as ferramentas separadamente (em seu ambiente próprio), sem a necessidade de utilizar as disponibilizadas na VM, apenas mantendo o item de ensaio, AllianceP2P.

A máquina virtual é um arquivo com extensão .ova, para executá-lo a máquina física (host) que irá recebê-lo deverá ter o software Oracle VirtualBox instalado, versão 6.0.8. Os arquivos desta rodada de EP estão localizados no seguinte caminho: /home/lab/ep. O sistema operacional desta máquina é o Lubuntu 19.04, as informações de para efetuar o login são:

● usuário: lab ● senha: lab123

Algumas configurações mínimas são recomendadas para que o laboratório consiga

usar o ambiente virtual sem apresentar problemas de desempenho:

● Espaço mínimo de armazenamento na máquina host de 10 GB;

● Processador Core i5 e 6GB RAM;

4


5.2. Item de Ensaio

O item de ensaio será o software Alliance P2P. Ele é um software designado para compartilhar arquivos e estabelecer comunicação entre pessoas próximas. O Alliance é composto basicamente por dois subsistemas independentes: UI, responsável pela interface gráfica com o usuário e o Core, responsável pela parte interna do sistema, onde se encontra a principal classe de entrada do software, o CoreSubsystem.

O subsistema Core é dividido em três pacotes: o Comm, que contém as classes responsáveis pelo fluxo de dados de rede; o Node, que é formado por classes com informações dos amigos; e o File, que possui classes onde é feito o gerenciamento de arquivos compartilhados. A figura 1 ilustra uma visão geral dessa divisão.

Figura 1: Visão geral do software Alliance P2P

5


Para esta rodada de EP, as classes foram selecionadas obedecendo a premissa que a classe escolhida deve pertencer a um dos pacotes do subsistema Core (Comm, File e Node). Além disso, todos os pacotes devem ter ao menos uma classe testada.

5.3. JaCoCo

JaCoCo (Java Code Coverage) é uma biblioteca livre designada para análise de cobertura de código de linguagem Java. A partir da instrumentação do código do software sendo testado, ela é capaz de medir a cobertura por linha e ramificações do código abrangido pelos casos de teste de unidade em execução. A biblioteca emite relatórios de resultado com a percentagem de código que foi coberto em três tipos de extensões de arquivo: HTML, XML e CSV.

O relatório em xml mostra detalhadamente as linhas cobertas e não-cobertas para cada caso de teste e será a extensão adotada nesta rodada. As tags <line>, dentro das tags <sourcefile>, apresentam as informações sobre as instruções e branches cobertos e não cobertos para cada linha de código.

Interpretação dos atributos da tag <line>:

nr = número da linha

mi = missed instructions (statements) - instruções perdidas (declarações)

ci = covered instructions (statements) - instruções cobertas (declarações)

mb = missed branches - branches perdidos

cb = covered branches - branches cobertos

6. Procedimento de entrega do registro de resultados do EP

Na etapa final, o laboratório participante deve entregar ao Inmetro:

1) os relatórios JaCoCo em xml;

2) seus respectivos testes de unidade (.java) que foram implementados pelo

participante;

3) e um Resumo “Executivo”.

6


Para cada teste, o nome do relatório JaCoCo (“avaliado”) em xml gerado pelo

participante deverá seguir o seguinte padrão:

“<ID_Participante>-<Número_Rodada>-<Número_Teste>.xml”

, onde <ID_Participante> é composto por “ID” + número do código de identificação do

participante após a “/”. Ex: “ID001-R001-T001.xml”.

O Resumo Executivo é um documento, em formato livre, que descreve um

apanhado geral dos testes realizados. Para cada teste, sugerimos que informe: o total de

linhas de código cobertas e não-cobertas; o percentual da cobertura de código; e um

feedback opcional sobre o teste (p. ex., nível de dificuldade, tempo gasto na solução,

observações em geral, etc).

O procedimento detalhado de entrega está descrito no APÊNDICE C.

7. Exemplo do procedimento de Ensaio

Esta seção exemplifica como o laboratório participante pode analisar o relatório de referência, elaborar seus casos de teste e emitir seus relatórios JaCoCo. Utilizando a classe {Hash.java}, descrevemos dois procedimentos de análise: sem e com ferramentas automatizadas.

O primeiro procedimento (seção 7.1) demonstra como testar a classe {Hash.java} sem o uso das ferramentas e arquivos auxiliares contidos no ambiente virtualizado. O segundo procedimento (seção 7.2) utiliza ferramentas e arquivos auxiliares para a comparação dos relatórios (referência e analisado), automatizando parte do processo. Estas ferramentas estão disponíveis no pacote recebido pelo participante.

7.1. Testes sem ferramentas e arquivos auxiliares

Este procedimento analisa o código de forma manual, mais rudimentar, verificando visualmente em todo o relatório de referência quais instructions e branches foram cobertos e não-cobertos pelo teste de unidade do provedor. Depois de identificar e analisar as classes e linhas de código que estão sendo cobertas, o laboratório participante deve implementar o seu teste de unidade e, por fim, emitir o seu relatório JaCoCo em xml.

7


Passo 1: Analisar o relatório JaCoCo em xml de referência

Neste exemplo, estamos analisando o caso de teste de exemplo (Hash.java). O relatório JaCoCo de referência para o exemplo é, portanto, o hashTest.xml (localizado em /home/lab/ep/). Primeiramente, abra esse arquivo em algum visualizador de sua preferência.

Na Figura 2, a tag <sourcefile> indica, em seu parâmetro name, a classe que está sendo executada. As linhas grifadas de amarelo indicam as linhas com covered branches e com covered instructions não zerados. O laboratório participante deve se atentar a esse trecho do relatório pois ele indica, através do atributo nr, o número da linha que o teste cobriu nessa classe. Ao final de cada <sourcefile>, o relatório exibe a totalização, por tipo de contador, de quantas linhas foram cobertas e não-cobertas.

<sourcefile name="Hash.java"> <line nr="23" mi="2" ci="0" mb="0" cb="0"/> <line nr="24" mi="4" ci="0" mb="0" cb="0"/> <line nr="25" mi="1" ci="0" mb="0" cb="0"/> <line nr="28" mi="0" ci="4" mb="0" cb="0"/> <line nr="29" mi="0" ci="1" mb="0" cb="0"/> <line nr="31" mi="0" ci="2" mb="0" cb="0"/> <line nr="32" mi="0" ci="4" mb="1" cb="1"/> <line nr="37" mi="0" ci="3" mb="0" cb="0"/> <line nr="38" mi="0" ci="1" mb="0" cb="0"/> <line nr="41" mi="3" ci="0" mb="0" cb="0"/> <line nr="49" mi="0" ci="3" mb="0" cb="2"/> <line nr="50" mi="0" ci="2" mb="0" cb="0"/> <line nr="52" mi="5" ci="2" mb="3" cb="1"/> <line nr="53" mi="0" ci="2" mb="0" cb="0"/> <line nr="55" mi="3" ci="0" mb="0" cb="0"/> <line nr="56" mi="7" ci="0" mb="2" cb="0"/> <line nr="57" mi="2" ci="0" mb="0" cb="0"/> <line nr="59" mi="9" ci="0" mb="2" cb="0"/> <line nr="60" mi="9" ci="0" mb="2" cb="0"/> <line nr="61" mi="2" ci="0" mb="0" cb="0"/> <line nr="64" mi="2" ci="0" mb="0" cb="0"/> <line nr="69" mi="0" ci="5" mb="0" cb="0"/> <line nr="70" mi="0" ci="9" mb="0" cb="2"/> <line nr="71" mi="0" ci="7" mb="0" cb="0"/> <line nr="73" mi="0" ci="2" mb="0" cb="0"/> <line nr="78" mi="0" ci="3" mb="0" cb="0"/> <line nr="82" mi="0" ci="4" mb="0" cb="0"/> <line nr="86" mi="4" ci="0" mb="0" cb="0"/> <line nr="87" mi="2" ci="0" mb="0" cb="0"/> <line nr="88" mi="4" ci="0" mb="2" cb="0"/> <line nr="89" mi="9" ci="0" mb="0" cb="0"/> <line nr="90" mi="2" ci="0" mb="2" cb="0"/> <line nr="91" mi="5" ci="0" mb="0" cb="0"/> <line nr="93" mi="4" ci="0" mb="0" cb="0"/> <line nr="95" mi="2" ci="0" mb="0" cb="0"/>

8


<line nr="99" mi="0" ci="6" mb="0" cb="0"/> <counter type="INSTRUCTION" missed="81" covered="60"/> <counter type="BRANCH" missed="14" covered="6"/> <counter type="LINE" missed="19" covered="17"/> <counter type="COMPLEXITY" missed="11" covered="9"/> <counter type="METHOD" missed="3" covered="7"/> <counter type="CLASS" missed="0" covered="1"/>

</sourcefile>

Figura 2: Relatório JaCoCo, tag sourcefile

Na Figura 3, ainda no relatório de referência, na tag <class>, é possível ver os métodos que o caso de teste percorre. Para cada linha coberta ou perdida (missed ou covered) o relatório em xml exibe um resumo que aponta o método onde ela se encontra e o tipo de contador coberto e não-coberto. O atributo sourcefilename indica o nome da classe que o teste cobriu. A tag <method>, através do atributo name, indica o nome do método. Esta parte do relatório ajuda a revisar a tag sourcefile. Os trechos grifados em amarelo, na Figura 3, também destacam os covered branches e covered instructions não zerados, como na Figura 2, porém a tag <class> permite reconhecer o método ao qual a linha coberta pertence.

<class name="org/alliance/core/file/hash/Hash" sourcefilename="Hash.java"> <method name="<init>" desc="()V" line="23"> <counter type="INSTRUCTION" missed="7" covered="0"/> <counter type="LINE" missed="3" covered="0"/> <counter type="COMPLEXITY" missed="1" covered="0"/> <counter type="METHOD" missed="1" covered="0"/>

</method> <method name="<init>" desc="(Ljava/lang/String;)V" line="28">

<counter type="INSTRUCTION" missed="0" covered="5"/> <counter type="LINE" missed="0" covered="2"/> <counter type="COMPLEXITY" missed="0" covered="1"/> <counter type="METHOD" missed="0" covered="1"/>

</method> <method name="<init>" desc="([B)V" line="31">

<counter type="INSTRUCTION" missed="0" covered="10"/> <counter type="BRANCH" missed="1" covered="1"/> <counter type="LINE" missed="0" covered="4"/> <counter type="COMPLEXITY" missed="1" covered="1"/> <counter type="METHOD" missed="0" covered="1"/>

</method> <method name="array" desc="()[B" line="41">


</method> <method name="equals" desc="(Ljava/lang/Object;)Z" line="49">

<counter type="INSTRUCTION" missed="39" covered="9"/> <counter type="BRANCH" missed="9" covered="3"/>

9


<counter type="LINE" missed="7" covered="4"/> <counter type="COMPLEXITY" missed="5" covered="2"/> <counter type="METHOD" missed="0" covered="1"/>

</method> <method name="hashCode" desc="()I" line="69">


</method> <method name="toString" desc="()Ljava/lang/String;" line="78">


</method> <method name="getRepresentation" desc="()Ljava/lang/String;" line="82">


</method> <method name="createFrom" desc="(Ljava/io/DataInputStream;)Lorg/alliance/core/file/hash/Hash;" line="86">


</method> <method name="createFrom" desc="(Ljava/lang/String;)Lorg/alliance/core/file/hash/Hash;" line="99">


</method> <counter type="INSTRUCTION" missed="81" covered="60"/> <counter type="BRANCH" missed="14" covered="6"/> <counter type="LINE" missed="19" covered="17"/> <counter type="COMPLEXITY" missed="11" covered="9"/> <counter type="METHOD" missed="3" covered="7"/> <counter type="CLASS" missed="0" covered="1"/>

</class>

Figura 3: Relatório Jacoco, tag class

Passo 2: Analisar a classe a ser testada: Hash.java

Neste passo, o laboratório deve identificar os métodos cobertos no relatório. Observe que os missed instructions e os missed branches devem ser analisados, pois compõem o teste, apenas são instruções e ramificações não-cobertas.

10


A Figura 4 exibe o código fonte da classe {Hash.java} (src/org/alliance/core/file/hash) destacando em amarelo os métodos identificados no relatório JaCoCo de referência do passo 1.

... public class Hash implements Serializable { private static final long serialVersionUID = 6722610126499235070L; protected transient static final int HASH_SIZE = 24; protected byte[] hash; public Hash() { hash = new byte[HASH_SIZE]; } public Hash(String hash) { this(Base64Encoder.fromBase64String(hash)); } public Hash(byte[] hash) { if (hash.length != HASH_SIZE) { if (T.t) { T.error("Incorrect hash size!!!"); } } this.hash = hash; } public byte[] array() { return hash; } @Override public boolean equals(Object obj) { if (this == obj) { return true; } if ((obj == null) || (obj.getClass() != this.getClass())) { return false; } Hash h = (Hash) obj; if (h.array().length != hash.length) { return false; } for (int i = 0; i < hash.length; i++) { if (hash[i] != h.array()[i]) { return false; } } return true; } @Override public int hashCode() { int h = hash[0]; for (int i = 1; i < hash.length; i++) { h ^= hash[i]; } return h; }

11


@Override public String toString() { return getRepresentation(); } public String getRepresentation() { return Base64Encoder.toBase64SessionKeyString(hash); } public static Hash createFrom(DataInputStream in) throws IOException { Hash h = new Hash(); int off = 0; while (off < HASH_SIZE) { int r = in.read(h.hash, off, HASH_SIZE - off); if (r <= 0) { throw new IOException("Corrupt serialized hash?"); } off += r; } return h; } public static Hash createFrom(String base64encoded) { return new Hash(Base64Encoder.fromBase64String(base64encoded)); } }

Figura 4: Código fonte classe Hash.java

Passo 3: Criar o caso de teste: HashTest.java

Depois de identificadas as linhas e os métodos que foram testados, o participante deve implementar o caso de teste equivalente. Denominado {HashTest}, o caso de teste exemplo elaborado para a classe {Hash.java} é apresentado na Figura 5. Instanciando a classe Hash, o teste chama os métodos indicados na Figura 4, do passo 2.

class HashTest { @Test void test() {

Hash hash = new Hash("7c740870f5d39986b84790a6577ba51a66e4096a37533b13"); hash.hashCode(); hash.toString(); Hash.createFrom("c740870f5d39986b84790a6577ba51a66e4096a37533b13"); hash.equals(null); hash.equals(hash);

} }

Figura 5: Código fonte do teste HashTest.java

12


Passo 4: Emitir os relatórios JaCoCo em xml (executar o agente no modo de servidor)

Para emitir o relatório o laboratório vai precisar utilizar o terminal do seu sistema operacional. Dois arquivos deverão ser baixados no site da JaCoCo (https://www.jacoco.org/jacoco/trunk/index.html): o {jacococli.jar} e o {jacocoagent.jar}.

O JaCoCo Java Agent coleta informações de execução e as salva num arquivo jacoco.exec, a pedido da JVM ou quando sua execução é encerrada. Neste arquivo estão os dados JaCoCo dos testes realizados, no caso do nosso exemplo apenas o {HashTest}. O arquivo {jacocoagent.jar} faz parte da distribuição do JaCoCo e inclui todas as dependências necessárias. Para informações de como executar o Java Agent acesse o endereço https://www.eclemma.org/jacoco/trunk/doc/agent.html.

O JaCoCo vem com uma Interface de Linha de Comando (Command Line Interface) para executar operações básicas a partir do terminal. A emissão do relatório é obtida por esta ferramenta, que possui todas as dependências empacotadas no arquivo {jacococli.jar}. Para informações de como executar o Command Line Interface acesse o endereço: https://www.jacoco.org/jacoco/trunk/doc/cli.html.

No final desse passo deve ser gerado um arquivo de extensão xml em JaCoCo. Esse arquivo é o relatório da cobertura do teste de unidade (“relatório avaliado”) realizado na classe {Hash.java}. O relatório deve conter informações similares ao das Figuras 2 e 3, que justamente deverá ser similar/igual ao relatório de referência.

7.2. Testes com ferramentas automatizadas

O participante pode, se assim quiser, fazer uso da ferramenta disponibilizada pelo provedor deste ensaio para facilitar a análise dos relatórios e automatizar parte do processo. O comparaRelatorios.py é um script que, quando recebe como parâmetros o relatório de referência e o relatório avaliado, emite um arquivo texto que indica a diferença entre os dois relatórios em relação às linhas cobertas/não-cobertas, totaliza as percentagens de cobertura em relação ao relatório de referência, e calcula as métricas de avaliação do participante para o caso de teste em questão.

Passo 1: Reconhecendo as linhas que o teste de unidade cobriu

Um arquivo denominado {zeresima.xml} é disponibilizado como um relatório JaCoCo com instruções zeradas, ou seja, ele simula um relatório onde um suposto teste não cobriu

13

https://www.jacoco.org/jacoco/trunk/index.html

https://www.eclemma.org/jacoco/trunk/doc/agent.html

https://www.jacoco.org/jacoco/trunk/doc/cli.html


nenhuma linha de código do software Alliance. Neste primeiro momento, o participante deve usá-lo no script {comparaRelatórios.py} para reconhecer quais linhas foram cobertas pelo caso de teste. Tomando como exemplo a classe {Hash.java}, o script deve receber o relatório {HashTest.xml} como referência e o {zeresima.xml} como avaliado. Ambos arquivos xml e o script se encontram na pasta /home/lab/ep.

> python3 comparaRelatorios.py -r <HashTest.xml> -a <zeresima.xml> Assim, executando o script comparaRelatórios.py, é possível identificar as linhas por onde o teste percorreu, analisando o arquivo texto gerado, nomeado {Resultado_comparaRelatorios.txt}.

Passo 2: Criar o teste de unidade: {HashTest.java}

Agora é hora de elaborar o teste de unidade que será avaliado com base nas linhas identificadas no passo 1. Esta etapa é idêntica ao passo 3 do subitem 3.2. Utilizando a IDE Eclipse, crie uma nova classe chamada hashTest.java e digite os comandos como na figura 5, ela contém os métodos que foram testados para que as linhas indicadas fossem cobertas. Vale ressaltar que já disponibilizamos o arquivo HashTest.java como exemplo. Ele se encontra em Alliance/testes/testes/, e pode ser visualizado no Package Explorer do Eclipse. Recomendamos que todos os outros testes feitos pelo participante sejam criados no mesmo caminho do teste de exemplo citado.

Passo 3: Executando o teste com o JUnit

Utilizando a IDE Eclipse, o participante deve executar o HashTest.java como JUnit. Para isso, clique com o botão direito sobre a classe de teste (Figura 6), selecione a opção Coverage As → JUnit Test. A cobertura do software aparecerá na tela como mostra a Figura 7.

14


Figura 6: Cobertura do teste unitário HashTest

Figura 7: Cobertura do teste de unidade HashTest

15


Passo 4: Emitir os relatórios JaCoCo xml

Para gerar o relatório de cobertura, na aba Coverage clique com o botão direito sobre o projeto e clique na opção Export Session, como indica a Figura 8. Na próxima janela, na opção Format, escolha a opção XML File e a pasta onde deseja salvar o arquivo. Isso é melhor ilustrado na Figura 9. Para fins de distinção, salve esse arquivo como HastTestLab.xml (lembrando que o padrão de nome de cada teste que será elaborado pelo participante está descrito na seção 6).

Figura 8: Exportando sessão no Eclipse

16


Figura 9: Cobertura do teste unitário HashTest

Neste passo, o participante pode novamente fazer o uso do script comparaRelatorios.py e, desta vez, como <avaliado> entrar com o relatório {HastTestLab.xml}, e como relatório de referência o {HashTest.xml}. Desta forma, é possível confirmar, no arquivo texto gerado pelo script, que nenhuma linha diverge entre os relatórios, ou seja, o avaliado está idêntico ao de referência.

> python3 comparaRelatorios.py -r <HashTestLab.xml> -a <HashTest.xml>

O script pode ser rodado a cada vez é gerado um novo relatório avaliado. Mais informações de como executar o comparaRelatórios.py podem ser encontradas no APÊNDICE D – Script de comparação automática.

17


APÊNDICE A – Geração de chaves PGP e exportação de chave pública para

inscrição no Ensaio de proficiência

1) Instalar a ferramenta GnuPG (Linux derivados de Debian). Todos os procedimentos

descritos neste manual foram testados com GnuPG 2.2.4 e libgcrypt 1.8.1 (obs: versões

anteriores do GnuPG possuem algumas diferenças tanto na sintaxe de comandos, quanto

na saída produzida). > apt-get install gnupg

2) Gera par de chaves (escolher parâmetros) > gpg --full-generate-key

2.1) Escolher as seguintes opções (par de chaves RSA de 2048 bits, com 2 anos de

validade): (1) RSA and RSA (default)

What keysize do you want? 2048

Key is valid for? 2y

Is this correct? (y/N) y

2.2) Inserir as informações do usuário para identificar a chave: Real name: Laboratório XYZ

Email address: [email protected]

Comment:

You are using the 'utf-8' character set.

You selected this USER-ID:

"Laboratório XYZ <[email protected]>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o

18


2.3) Quando perguntado, inserir a senha (passphrase) duas vezes (essa senha protege a

utilização das chaves). O processo de geração da chave pode demorar alguns minutos.

3) Listar as chaves no chaveiro: > gpg --list-keys

pub rsa2048 2019-07-26 [SC] [expires: 2021-07-25]

B83541049F044621A78FE50CE3587EB214755CA1

uid [ultimate] Laboratório XYZ <[email protected]>

sub rsa2048 2019-07-26 [E] [expires: 2021-07-25]

3.1) O hexadecimal destacado é o fingerprint da chave. Anotá-lo para envio na ficha de

inscrição.

4) Exportar chave pública gerada - substituir o hexadecimal ao final pelo fingerprint da

chave pública do laboratório: > gpg --armor --export --output lab_pubkey.asc

B83541049F044621A78FE50CE3587EB214755CA1

Abrir o arquivo gerado, copiar seu conteúdo e copiá-lo no campo correspondente na ficha

de inscrição. Abaixo, segue um exemplo do formato de chave pública requerido na ficha

de inscrição (incluir as linhas de BEGIN e END):

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBF07MycBCAC/S8735NuRzNVwQo8xfLyWz7QffV6iIdTnvrEh3rm0RpumJQFi

1dWUijtnHkmvQXzs/j3SaZsfJgVC1+kmQYrKytbIxFrVOATIvkMaXWFuMQrKzYZF

oUbzt3KUh4E5tnY0aWjpI3fynH6D0nhZuYGAubxdyVYFPzX/CIuWA2gVGNIVBUwm

SqPjJmSBUM+/ZclEbSrqVa2ek36UAbKhMVa8jXEthjNHRJZXVj0h0UjX+HDU+uo9

…

[conteúdo suprimido]

...

DngbaLNaOxDv5RWcT5337Be3ZWMsu3WLyWeyrvFxhtLhtGo+H2V+fGbpgxNvhCgN

djoZtHY4NOWfk4Ci5xdIOaL7UrO+cteFno4DGUYAEC5zyY7tftzwAtJm7a0ApVKd

19


BSPhxOU5S3XS0ar60Nb+6XQ2HWgI+QVLp4i72wfpjyKv1/R0gqK2vrWACvKWXtSq

Yw==

=T8mH

-----END PGP PUBLIC KEY BLOCK-----

20


APÊNDICE B – Recebimento do Pacote de EP

1) Calcular valor de hash do Pacote EP encriptado, a fim de que o laboratório confira a

integridade do arquivo baixado: > gpg --print-md SHA256 PacoteEP.ova.gpg > PacoteEP.ova.gpg.sha256

2) Importar a chave pública PGP do Lainf/Inmetro para o seu chaveiro: > gpg --import lainf_pubkey.asc

3) Após o código de acesso do pacote ser revelado, descompactar (ZIP), verificar a

assinatura e decriptar (AES-256) o Pacote EP (esse passo levará alguns minutos devido

ao tamanho do pacote): > gpg --output PacoteEP.ova --decrypt PacoteEP.ova.gpg Quando perguntado, inserir o código de acesso recebido.

4) Calcular valor de hash do pacote decriptado e gerar um arquivo com esse valor: > gpg --print-md SHA256 PacoteEP.ova > PacoteEP.ova.sha256

5) Assinar digitalmente o arquivo contendo o valor do hash (substituir o hexadecimal pelo

fingerprint da chave do laboratório participante): > gpg --local-user BE8A17DAFD6C3146BFB0C40C80CBF6A1257DFC62 --sign

PacoteEP.ova.sha256 O arquivo de saída (PacoteEP.ova.sha256.gpg) + o arquivo contendo a chave-pública

PGP do laboratório (exportada no procedimento do APÊNDICE A) deverão ser enviados

ao Inmetro como confirmação de recebimento do pacote.

21


APÊNDICE C – Entrega do registro de resultados do EP

1) O laboratório deve compactar (algoritmo ZIP) manualmente todos os arquivos que

integram o pacote de resultados do EP para gerar um único arquivo nomeado de acordo

com o padrão a seguir: “<ID_Participante>-<Número_Rodada>.zip”

, onde <ID_Participante> é composto por “ID” + número do código de identificação do

participante após a “/”. Ex: “ID001-R001.zip”

2) Assinar o pacote de respostas (substituir o hexadecimal pelo fingerprint da chave do

laboratório participante): > gpg --local-user B83541049F044621A78FE50CE3587EB214755CA1 --digest-algo SHA256

--sign ID001-R001.zip Saída: ID001-R001.zip.gpg (Este arquivo será enviado ao Inmetro).

22


APÊNDICE D – Script de comparação automática de relatórios

O script comparaRelatorios.py compara dois arquivos xml no formato de relatório JaCoCo.

Entradas:

- O relatório “referência”;

- O relatório “avaliado”.

Saídas:

- A cobertura de código (linha por linha, totalizada e percentual) do relatório avaliado

em relação ao relatório referência;

- A avaliação do teste obtida segundo as métricas estipuladas.

Modo de usar: > python3 comparaRelatorios.py -r <referência> -a <avaliado> Onde <referência> e <avaliado> são os caminhos para os relatórios JaCoCo em xml.

Para cada teste, o nome do relatório JaCoCo (“avaliado”) gerado pelo participante

deverá seguir o seguinte padrão:

<ID_Participante>-<Número_Rodada>-<Número_Teste>.xml

onde <ID_Participante> é composto por “ID” + número do código de identificação do

participante após a “/”. Ex: “ID001-R001-T001.xml”

23

manual de ensaio de proficiência em software · manual de ensaio de proficiência em software 4....

Documents