A necessidade das empresas em produzir software com qualidade tem aumentado a demanda por profissionais com conhecimentos e habilidades em Teste de Software. Entretanto, existe uma escassez de mão-de-obra especializada nesta área. Considerando essa lacuna, o curso de Introdução ao Teste de Software foi planejado para servir como um guia para pessoas que necessitam de uma fonte de consulta e/ou aprendizado na área.
Ao completar o curso, os estudantes serão capazes de planejar e aplicar as principais técnicas, critérios e ferramentas de teste em variados domínios e tipos de software. Adicionalmente, terão a oportunidade de desenvolver habilidades essenciais para um testador, tais como pensar a partir da perspectiva do cliente, habilidade para raciocinar e se comunicar efetivamente, capacidade de se adaptar às mudanças do projeto, curiosidade para compreender o produto que será testado, busca constante pela qualidade, dentre outras.
Na lição
Teste Estrutural
Ao final deste módulo, espera-se que você seja capaz de compreender a técnica de Teste Estrutural e seus principais critérios.
Doutoranda em Ciências de Computação e Matemática Computacional pela Universidade de São Paulo (USP). Professora efetiva no IFSULDEMINAS Campus Muzambinho. Ciência da Computação
Stevao Alves de Andrade
Doutorando em Ciências de Computação e Matemática Computacional pela Universidade de São Paulo (USP). Universidade de São Paulo (ICMC/USP)
Draylson Micael de Souza
Doutor em Ciências da Computação e Matemática Computacional Universidade de São Paulo (ICMC/USP)
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.
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
Márcio Eduardo DelamaroProfessor Associado
Ellen Francine BarbosaProfessor Associado
Aracele Garcia de Oliveira FassbinderDoutoranda em Ciências de Computação e Matemática Computacional pela Universidade de São Paulo (USP). Professora efetiva no IFSULDEMINAS Campus Muzambinho.
Stevao Alves de AndradeDoutorando em Ciências de Computação e Matemática Computacional pela Universidade de São Paulo (USP).
Draylson Micael de SouzaDoutor em Ciências da Computação e Matemática Computacional
