Tecnicas_Caixa_Preta_Teste_de_Software_[classe_de_equivalencia]

Prévia do material em texto

<p>������������������������������������������������������</p><p>�� ��</p><p>�����������</p><p>���������</p><p>�� �������</p><p>Técnicas de Caixa Preta de Teste de Software</p><p>Na maioria de projetos de teste, o tempo para a realização dos mesmos sempre é</p><p>curto e os números de testes a serem realizados nas aplicações são inúmeros. Isso sem falar</p><p>dos testes “Não-Funcionais”, como por exemplo, os de performance, de usabilidade, de</p><p>stress, de escalabilidade, etc. É necessário se ter um planejamento bem elaborado para que</p><p>todo o projeto de testes, consiga entregar um produto com no mínimo qualidade esperada</p><p>pelo cliente e no prazo que foi acordado.</p><p>No intuito de se realizar esse processo com certa eficiência, é necessário utilizar das</p><p>técnicas de teste de software que é o tema desse artigo. Para isso, respondemos a pergunta</p><p>de como fazer o processo. Entretanto, para responder a pergunta, o que e o que priorizar</p><p>primeiro, temos que levar em consideração os riscos associados ao projeto de teste que</p><p>devem ser levantados tão logo se inicia o projeto de todo o software. Levantados e</p><p>analisados os riscos e, fazendo uso correto das técnicas de teste, é muito provável que todo</p><p>o projeto de teste consiga alcançar o mínimo de qualidade esperada.</p><p>O nome caixa preta vem do sentido de que nesse tipo de teste, não é</p><p>necessário saber a estrutura interna de como o código foi implementado ou a tecnologia que</p><p>foi utilizada. Nesse tipo de análise, essas questões são transparentes para os analistas de</p><p>teste. É claro que para se ter um projeto de teste bem sucedido, é necessário usar a técnica</p><p>de caixa preta e mais a de caixa branca, isto é, analisar, também, a estrutura interna da</p><p>aplicação.</p><p>Na nomenclatura também se utiliza o termo em inglês “Black Box” ou “Testes</p><p>Funcionais”. Aqui, listo as principais técnicas de caixa preta de teste de software, com</p><p>exemplos ilustrativos e, ainda, mostra como se medir a porcentagem de cobertura depois</p><p>que os testes são executados para cada uma das técnicas.</p><p>1) Classe de Equivalência (Equivalent Partioning)</p><p>Essa técnica é baseada na premissa que a entrada e saída de um componente podem</p><p>ser particionados em classes de equivalência que, de acordo com a especificação do</p><p>componente serão tratados similarmente pelo componente. Assim, o resultado de um teste</p><p>usando um simples valor dessa classe de equivalência é considerado representativo em</p><p>relação a uma classe.</p><p>O modelo deve compreender partições de valores de entrada e saída. Cada partição</p><p>deve conter um intervalo de valores, escolhidos de tal maneira, que todos os valores nessa</p><p>classe têm o mesmo resultado, daí o nome equivalência. Podem ser usados valores válidos e</p><p>inválidos para serem candidatos à classe de equivalência. É desejável se ter pelo menos um</p><p>caso de teste para exercitar cada uma das classes de equivalência para se ter uma máxima</p><p>cobertura da aplicação.</p><p>Um exemplo de onde essa técnica pode ser aplicada é a classificação das notas dos</p><p>alunos em A, B, C ou D de acordo com a pontuação de cada um. Se, para se conseguir uma</p><p>classificação A, o aluno tem que tirar nota entre 90 e 100, B entre 80 e 89, C entre 70 e 79 e</p><p>D abaixo de 70, sendo que o sistema só aceita caracteres numéricos.</p><p>Graficamente, temos:</p><p>������������������������������������������������������</p><p>�� ��</p><p>�����������</p><p>���������</p><p>�� �������</p><p>Para exercitar todas as classificações das notas que são as classes de equivalência A,</p><p>B,C e D é necessário ter como entradas dos casos de teste pelo menos um representante de</p><p>cada classe de equivalência, por exemplo, entradas 69 para ter como saída o valor “D”, o</p><p>valor 75 exercitar a segunda classe de equivalência e ter a classificação “C”, o valor 84,</p><p>para se obter “B” e o valor 93 para se obter “A”. Além desse conjunto de entradas válidas,</p><p>as entradas inválidas, também seriam pertinentes para avaliar o sistema, como por exemplo,</p><p>caracteres alfas-numéricos e especiais. Esses valores são mostrados na tabela abaixo:</p><p>Conjunto de Casos de Teste de Classes de Equivalência</p><p>Caso de Teste 1 2 3 4 5 6</p><p>Entrada 69 75 84 93 A &</p><p>Saída D C B A Erro Erro</p><p>Para medir a cobertura dos testes usando essa técnica, usa-se a seguinte fórmula:</p><p>Cobertura Classe de Equivalência = Número de Partições Testadas * 100 %</p><p>Total de Partições</p><p>2) Valores de Borda (Boundary Value Analysis)</p><p>Essa técnica usa um modelo de componente que particiona as entradas e saídas dos</p><p>valores de um componente em conjuntos de classificações, cujos valores de borda são</p><p>exercitados. Esses conjuntos de classificações são obtidos através de especificações do</p><p>comportamento do componente.</p><p>Primeiramente, é necessário ter em mente quais os conjuntos de classificações</p><p>compreendidas pelo sistema e, depois, levantar os valores de borda de cada um desses</p><p>conjuntos. O objetivo aqui é produzir casos de teste com entradas usando os valores de</p><p>borda de cada um desses conjuntos.</p><p>Essa técnica é uma das mais úteis, tanto para testadores quanto para</p><p>desenvolvedores, pois através dela é que são identificados muitos problemas de aceitação</p><p>de valores de entradas em um sistema, principalmente, quando se usa o valor nulo ou o</p><p>valor zero. Muitos desenvolvedores se valem dela para fazer testes unitários, pois eles</p><p>precisam analisar se o tratamento dado por eles no código está prevendo essas condições.</p><p>Como exemplo prático pode citar o exemplo anterior ou, também, para testes de</p><p>datas de um sistema. No caso do exemplo anterior, alguns valores válidos e inválidos para</p><p>se testar os valores de borda das classes de equivalências são mostrados na tabela abaixo:</p><p>Conjunto de Casos de Teste de Valores de Borda</p><p>Classe de Equivalência Entradas Saída</p><p>D 69, 68,11,1,0 D</p><p>C 70, 78, 79 C</p><p>B 80, 88, 89 B</p><p>A 90, 98, 99, 100 A</p><p>Inválida A, Y, *, ^, %, # Erro</p><p>Para se testar datas válidas de um sistema, a técnica de valores de borda pode ser</p><p>aplicada, pois sabe que os meses com trinta dias são: Abril, Junho, Setembro e Novembro,</p><p>com trinta e um dias são: Janeiro, Março, Maio, Julho, Agosto, Outubro e Dezembro e</p><p>������������������������������������������������������</p><p>�� ��</p><p>�����������</p><p>���������</p><p>�� �������</p><p>Fevereiro com vinte e oito ou vinte e nove dias dependendo se é um ano bissexto ou não.</p><p>Então podemos levantar os valores de borda para testar se um sistema está validando ou</p><p>não, as entradas de data que deve ter o formato: DD/MM/AAAA. Esses valores são</p><p>mostrados abaixo:</p><p>Conjunto de Casos de Teste de Valores de Borda</p><p>Classe de</p><p>Equivalência</p><p>Entradas Válidas Entradas Inválidas</p><p>Janeiro 01/01/2000, 30/01/2000, 31/01/2000 32/01/2000, 31/1/2000, 31/01/00</p><p>Fevereiro 01/02/2000, 28/02/2000, 29/02/2000 29/02/2001, 30/02/2000,</p><p>31/02/2000</p><p>Março 01/01/2000, 30/01/2000, 31/01/2000 32/03/2000, 31/3/2000, 31/03/00</p><p>Abril 01/04/2000, 29/04/2000, 30/04/2000 31/04/2000, 30/4/2000, 30/04/00</p><p>Maio 01/05/2000, 30/05/2000, 31/05/2000 32/05/2000, 31/5/2000, 31/05/00</p><p>Junho 01/06/2000, 29/06/2000, 30/06/2000 31/06/2000, 30/6/2000, 30/06/00</p><p>Julho 01/07/2000, 30/07/2000, 31/07/2000 32/07/2000, 31/7/2000, 31/07/00</p><p>Agosto 01/08/2000, 30/08/2000, 31/08/2000 32/08/2000, 31/8/2000, 31/08/00</p><p>Setembro 01/09/2000, 29/09/2000, 30/09/2000 31/09/2000, 30/9/2000, 30/09/00</p><p>Outubro 01/10/2000, 30/10/2000, 31/10/2000 32/10/2000, 31/0/2000, 31/10/00</p><p>Novembro 01/11/2000, 29/11/2000, 30/11/2000 31/11/2000, 30/1/2000, 30/11/00</p><p>Dezembro 01/12/2000, 30/12/2000, 31/12/2000 32/12/2000, 31/2/2000, 31/12/00</p><p>Para medir a cobertura de cobertura usando essa técnica, usa-se a seguinte fórmula:</p><p>Cobertura Valor de Borda = Número de Valores de Borda Executados * 100 %</p><p>Total de Valores de Borda</p><p>3) Transição de Estados (State Transition)</p><p>Essa técnica de caixa preta é baseada sobre a análise da especificação de um</p><p>componente para modelar o comportamento dele em transições de estados. Ela usa um</p><p>modelo de estados que o componente deve ocupar, as transições</p><p>entre esses estados, os</p><p>eventos que causam essas transições e as ações que resultam dessas transições.</p><p>O modelo é tipicamente representado por estados, transições de estados, eventos,</p><p>entradas e saídas de um componente e todos eles serem identificáveis. Os eventos causam</p><p>transições entre estados e transições podem retornar para o estado original onde eles</p><p>começaram. Eles são causados pelas ações que causam saídas nos mesmos.</p><p>Os casos de teste devem ser elaborados para exercitar todas as transições de estados</p><p>do componente. Nele deve ser especificado, o primeiro estado do componente, a entrada, as</p><p>saídas esperadas, o evento que causa a transição para o próximo estado, a ação esperada</p><p>causada pela transição e o próximo estado esperado. Graficamente, podemos ilustrar essa</p><p>técnica da seguinte maneira:</p><p>������������������������������������������������������</p><p>�� ��</p><p>�����������</p><p>���������</p><p>�� ����� �</p><p>Como exemplo de uso dessa técnica pode citar o sistema de uma companhia aérea</p><p>que mostra todos os lugares de um vôo. Os lugares podem estar ocupados, reservados ou</p><p>disponíveis. São estados que esse componente pode assumir. A entrada é a escolha de uma</p><p>poltrona por um cliente ou uma reserva. Logo após isso, o sistema dispara um evento para</p><p>atualizar aquele assento que estava disponível para ocupado ou reservado. O sistema pode</p><p>fazer mais algumas validações (eventos) do tipo, se um assento ficar por mais de um tempo</p><p>reservado, volta para disponível ou, ainda, se a pessoa ocupar a poltrona e não confirmar a</p><p>sua escolha volta de reservado para disponível.</p><p>Elaborar casos de teste para esse sistema não é uma tarefa muito fácil para os</p><p>analistas, pois eles devem cobrir todos os estados que a poltrona pode assumir e as todas as</p><p>condições em que elas ocorrem.</p><p>Para medir a cobertura de cobertura usando essa técnica, usa-se o percentual de</p><p>todos os valores válidos que foram exercitados durante o teste.</p><p>4) Gráfico de Causa e Efeito (Cause & Effect Graphing)</p><p>Gráfico de causa e efeito usa um modelo de relações lógicas entre causas e efeitos</p><p>para um componente. Cada causa é expressa como uma condição, que pode ser verdadeira</p><p>ou falsa (condição Booleana) de entrada ou uma combinação de entradas para o</p><p>componente. Cada efeito é expresso como sendo uma expressão Booleana representando</p><p>uma saída, ou uma combinação de saídas para o componente ocorrido.</p><p>O modelo é tipicamente representado como gráfico Booleano relacionando as</p><p>entradas e saídas Booleanas, usando os operadores Booleanos: AND, OR, NAND, NOR e</p><p>NOT. Desse gráfico, é produzida uma tabela de decisão representando as relações lógicas</p><p>entre causas e efeitos.</p><p>Os casos de teste devem ser projetados para exercitar as regras, que definem a</p><p>relação entre as entradas e saídas dos componentes, onde cada regra corresponde a uma</p><p>possibilidade única de entrada para o componente que tem sido expresso como booleano. O</p><p>caso de teste deve identificar o estado booleano de cada causa e o estado para cada efeito.</p><p>������������������������������������������������������</p><p>�� ��</p><p>�����������</p><p>���������</p><p>�� �����!�</p><p>Como exemplo dessa técnica pode citar os casos de teste para validar as operações</p><p>bancárias feitas por um correntista. As entradas (causas) para esse projeto de teste seria o</p><p>tipo de conta, limite máximo, saldo atual e montante de débito. Os efeitos são flag para</p><p>saber se a operação foi realizada ou não e o saldo atual da correntista. Os casos de teste que</p><p>podem ser levantados para validar essa aplicação são inúmeros e, o resultado deles,</p><p>depende das operações booleanas para saber se será possível ou não realizar a transação.</p><p>Para medir a cobertura de cobertura usando essa técnica, usa-se a seguinte fórmula:</p><p>Cobertura Causa-Efeito = Número de Regras Exercitadas * 100 %</p><p>Total de Regras</p><p>5) Técnica de Sintaxe (Syntax Testing)</p><p>Essa técnica de caixa preta é baseada sobre a análise da especificação de requisitos.</p><p>Nesse documento são especificados os valores possíveis que uma entrada do sistema pode</p><p>receber. No entanto, nesse documento, as entradas inesperadas, na maioria das vezes, não</p><p>são tratadas. É nesse contexto que se insere a técnica de “Técnica de Sintaxe”. Ela consiste</p><p>em ter como entradas esperadas e as não esperadas para validar a especificação de</p><p>requisitos e avaliar o comportamento de um sistema quando esses valores não especificados</p><p>são usados.</p><p>Ë nessa técnica onde são encontrados os principais problemas de tratamentos de</p><p>exceções, já que ela se divide em “Sintaxe Válida” e “Sintaxe Inválida”. Na primeira,</p><p>somente os valores esperados são utilizados, como por exemplo, valores numéricos em</p><p>campos que remetem a uma quantidade de dias de férias que um funcionário tem a receber,</p><p>saldo de uma conta, livros em um andar de uma biblioteca, valores alfa em campos de</p><p>nomes, sobrenomes, endereço, etc. Já na segunda técnica, a Sintaxe Inválida, o objetivo é</p><p>exercitar as entradas inválidas, como inserção de valores alfa em campos numéricos,</p><p>inserção de valores numéricos em campos de valores alfa, inserção de caracteres especiais,</p><p>inserção de valores float em campos numéricos e inteiros, inserção de valores negativos em</p><p>campos de valores numéricos e inteiros, inserção de vírgulas e pontos em campos de</p><p>valores numéricos. Todas essas entradas visam validar qual será o tratamento dado pela</p><p>aplicação quando esses valores forem usados. Ë desejável que mensagens de erro e de ajuda</p><p>sejam colocadas na tela no sentido de guiar o usuário a usar os valores corretos.</p><p>Outro aspecto que vale mencionar é que na maioria das especificações de requisitos,</p><p>nem os valores aceitáveis são especificados. Nesse caso, seria interessante descobrir quais</p><p>os tipos de valores que os campos podem receber dando uma olhada no banco de dados</p><p>dessa aplicação. O arquiteto de teste aliado a um desenvolvedor que tenha mais</p><p>proximidade consegue levantar essa informação. Nesse caso, o levantamento dessas</p><p>informações é essencial para a aplicação dessa técnica.</p><p>Para medir a cobertura de cobertura usando essa técnica, usa-se a seguinte fórmula:</p><p>Cobertura Teste Sintaxe = Número de Testes Sintaxe Exec * 100 %</p><p>Total de Casos de Teste</p><p>������������������������������������������������������</p><p>�� ��</p><p>�����������</p><p>���������</p><p>�� �����"�</p><p>6) Teste Randômico (Random Testing)</p><p>Essa técnica consiste em utilizar um algoritmo pseudo-randômico para se escolher</p><p>quais os casos de testes serão usados para validar uma funcionalidade de uma determinada</p><p>aplicação dentro um conjunto definido de valores. O objetivo aqui não é fazer testes Ad-</p><p>Hoc (testes sem resultados previamente esperados e sem um propósito) e, sim,</p><p>simplesmente, em uma escolha dos casos de teste que foram previamente elaborados.</p><p>Normalmente, se aplica essa técnica quando o tempo de teste foi reduzido em virtude de</p><p>eventualidades que aconteceram no projeto.</p><p>Um dos exemplos clássicos para exemplificar essa técnica é o “Diagrama de</p><p>Pareto”. O princípio se baseia em uma análise quantitativa, ou seja, 80% de todos os</p><p>problemas são oriundos de 20% das causas potenciais. No contexto de teste de software, se</p><p>baseia em escolher 20% de todos os casos de testes criados, cobrindo 80% das</p><p>funcionalidades de todo o projeto. Para ter esse conjunto de casos de teste, é necessário ter</p><p>uma relação de requisitos do sistema x testes criados. Depois de feita essa relação, escolher</p><p>os casos de testes que mais aparecem nessa relação.</p><p>Um exemplo que ilustra essa técnica é mostrado abaixo. Segundo a tabela abaixo,</p><p>temos um total de 30 casos de testes criados hipoteticamente ligados aos requisitos básicos</p><p>de um sistema de uma biblioteca. Seguindo o principio de Pareto, se testarmos, os casos de</p><p>teste, 2,3,7,18,22 e 25 que são os 20% principais e que mais cobrem funcionalidades,</p><p>estaremos cobrindo 80% das funcionalidades totais da aplicação.</p><p>Sistema de uma Biblioteca</p><p>Funcionalidades</p><p>Básicas Casos de Testes criados</p><p>Inclusão de Dados de Usuário 1,2,3,4,5,14</p><p>Edição de Dados de Usuário 2,5,6,7,8,9,13</p><p>Deleção de Dados de Usuário 2,3,7,10,11,12</p><p>Reserva de Livros 15,16,17,18,19,20,21,22</p><p>Adição de Livros 18,22,23,24,25,26</p><p>Remoção de Livros 25, 27,28,29,30</p><p>Para medir a cobertura de cobertura usando essa técnica, usa-se a seguinte fórmula:</p><p>Cobertura Teste Randômico = Número de Testes Exec Randomic * 100 %</p><p>Total de Casos de Teste</p>