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.

Critérios Baseados em Fluxo de Controle e Exemplo de Aplicação

Introdução ao Teste de Software

Conheça os instrutores