Olá, nos vídeos anteriores nós vimos qual é o propósito do teste estrutural, e falamos também sobre os critérios que compõem esse tipo de teste. Então no vídeo de hoje eu vou apresentar para vocês uma ferramenta que nos permite aplicar na prática o teste estrutural, mais especificamente baseado fluxo de controle. Imagine que você tem o seu programa, como o Identifier que eu estou mostrando aqui, e que você quer exercitar o código usando os critérios de fluxo de controle. A medida que você executa os casos de teste, como que você vai saber quais trechos foram executados e quais não foram executados? Para isso existem diversas ferramentas que ajudam nessa tarefa. Por exemplo, a ferramenta jaBUTi, a Eclemma, a Cobertura, que são ferramentas para Java, e o gcc, gcov, e o gcovr. Basicamente o que essas ferramentas fazem é informar a medida que você fornece os casos de teste do seu programa, e que falta ser executada. Ou seja, quais os requisitos que já foram executados e quais ainda não foram executados. Especificamente nesse vídeo eu vou falar para vocês como usar o conhecido compilador gcc para realizar o teste estrutural baseado fluxo de controle. O gcc, que é provávelmente dos compiladores mais utilizados no desenvolvimento de software, ele permite que a gente compile o nosso programa e crie código que a gente chama de código instrumentado, e que permite que a gente colha informações sobre quais trechos do programa foram executados. Para usar o gcc a primeira coisa a fazer é compilar o nosso program. No caso, vou utilizar de novo o identifier.c usando esses dois argumentos específicos. [SEM_ÁUDIO] O fprofile-arts e o ftests-coverage. Com isso, além do programa executável que vemos aqui que é o identifier, o nosso compilador vai criar outro arquivo que é o arquivo identifier.cgno. Esse gcno basicamente descreve o gráfico de fluxo de controle do nosso programa. Executando essa versão instrumentada do identifier usando como parâmetro o string vazio, vemos que a resposta é identificador inválido, e vemos que ao final da execução foi criado outro arquivo O identifier.gcda. Temos aqui, então a execução do código instrumentado criou esse novo arquivo, e esse arquivo possui informações sobre quais partes do programa são executadas. E seguida a gente precisa verificar o que foi coberto e o que não foi coberto. Para isso então precisamos extrair essa informação do arquivo gcda, e para isso precisamos de programa que faça isso. Usaremos aqui o gcovr que extrai essa informação dos arquivos gcno e gcda, e nos mostra num fomato amigável. Esse formato pode ser formato texto simples, ou como estou mostrando aqui, formato html. Veja que eu chamei o gcovr passei alguns parâmetros, e pedi para ele criar como saída identifier.html que foi criado aqui. Então, além do identifier.html ele criou mais alguns arquivos html aqui. Então esse é o identifier.html que é o arquivo gerado pelo gcvr. Ele tem as métricas de cobertura, de comandos, e desvios, pelo programa como todo aqui do lado direito, e para cada arquivo que compõe esse programa, podemos ter diversos arquivos, no caso a gente tem apenas o identifier.c, ele vai mostrar essas mesmas métricas de cobertura. Ou seja, quanto foi coberto de nós ou seja, de linhas de códigos, e quantos desvios foram cobertos. Se a gente clicar cima do nome do nosso arquivo, ele vai mostrar com detalhes qual foi a cobertura do código que se encontra nesse arquivo identifier.c. Aqui eu estou mostrando justamente os detalhes da execução do código que estão no arquivo identifier.c. Vejam que não é apresentado explicitamente o gráfico de fluxo de controle, os nós, arestas e tudo mais conforme vimos anteriormente mas de uma outra forma essa informação de cobertura está representada aqui nesse arquivo. Vejam, o código que está pintado verde foi o código que foi executado pelo meu caso de teste. Esses números a esquerda mostram quantas vezes cada comando foi executado. O código vermelho é o trecho que ainda não foi executado. Além disso cada uma das condições existem esses sinais indicando quais ramos foram executados, e quais não foram executados. Por exemplo, nesse primeiro caso apenas o ramo falso foi executado, e está indicado por esse sinal verde. Já o ramo verdadeiro dessa condição não foi executado ainda, indicado por esse sinal vermelhinho aqui. Aqui baixo vejam que nós temos três cláusulas, e por isso nós temos seis ramos a serem cobertos. Desses seis ramos apenas deles foi executado. Então essa é a informação que o gcvr apresenta para a gente. Voltando aos casos de teste, vou adicionar mais dois casos de testes. Vou utilizar o string abc, e o string a*c. Vou rodar então o Indentifier com esses dois casos de teste, e vou gerar de novo o identifier.html para que eu tenha as novas informações sobre esses novos casos de teste que eu adicionei. Vejam que olhando o resultado, todos os comandos dessa função agora foram executados com esses três casos de teste, mas notamos que ainda existem alguns desvios que não foram executados. Aqui, e aqui temos alguns desvios não executados. O que precisaremos fazer então seria projetar novos casos de testes para fazer com que todos esses desvios fossem cobertos, e também eu gostaria provavelmente de olhar as demais funções. Vejam que nesse slide eu estou mostrando apenas uma das funções. Eu gostaria que todas as funções tivessem todos os seus requisitos cobertos pelos meus casos de teste. Nesse vídeo de hoje nós vimos como utilizar na prática os critérios de fluxo de controle, todas as coberturas de nós e a cobertura de ramos, e com isso terminamos essa série de vídeos sobre teste estrutural.
