Técnicas de Desenho de Testes

As técnicas de desenho de testes são o coração dos testes. Existem inúmeras vantagens em se usar técnicas de desenho de testes, entre as quais se destacam:

• Suporte para o trabalho sistemático torna a especificação de testes mais eficiente.
• O desenho dos casos de teste pode facilmente ser repetido por outros.
• Quando utilizadas é possível determinar as coberturas associadas a uma especificação.

Durante a fase de desenho e planeamento de testes, facilmente percebemos que as combinações, variações dos dados a usar nos testes e que podem ser usados como entrada para os casos de testes podem ser infinitas. Daqui rapidamente se concluí que testar exaustivamente cada caso não é possível, é necessário então usar técnicas de teste que permitam diminuir o número de casos e cenários de teste, permitindo a maior cobertura de testes com um esforço mínimo. Na elaboração deste testes é importante compreender as várias técnicas de desenho de testes disponíveis.

Se é necessário executar um número infinito de testes então é necessário transformar esta infinidade numa quantidade adequada de trabalho. As técnicas de teste de software existem para reduzir o número de testes a ser executados, enquanto fornecem uma cobertura suficiente do sistema em análise.

A utilização de várias técnicas de testes em simultâneo num mesmo projecto ou esforço de testes têm provado ser mais eficaz de que nos concentramos apenas numa técnica.

Black Box Testing

Caixa preta e caixa-branca são os métodos mais conhecidos de desenho de testes. Os testes de caixa preta tratam o sistema como uma “caixa preta”, e por isso não usam explicitamente o conhecimento da estrutura interna.

Os testes de caixa preta são casos de testes construídos tendo como base as especificações e funcionalidades do software. Estes testes usam as descrições externas do software, incluindo especificações, requisitos e design para elaborar casos de teste. O tester selecciona entradas válidos e inválidos e determina a saída correcta. Neste tipo de testes não existe qualquer conhecimento da estrutura interna do objecto de teste.

Entre as numerosas técnicas de testes disponíveis as mais conceituadas e que melhores resultados têm produzido encontram-se as seguintes: análise funcional, equivalence partitioning, path anlysis, orthogonal array testing e state transition testing.

White Box Testing

Os testes de caixa branca são de uma natureza diferente dos testes caixa preta. No teste de caixa preta, o foco das actividades é apenas sobre a funcionalidade do sistema e não no que está acontecendo dentro do sistema.  Por outro lado os objectivos de testes de caixa branca é ter certeza de que a funcionalidade é adequada, usando para tal informação sobre o desenho e implementação destas funcionalidades para elaborar os testes. Os testes de caixa branca são essencialmente efectuados pelas equipas de desenvolvimento, geralmente a partir da criação de testes unitários.

Uma das características dos testes de caixa branca é que permitem avaliar qual a cobertura do código que estamos a analisar. Existem várias possibilidades para verificar a cobertura que pode ser medida aquando do uso de testes de caixa-branca, entre os quais se destacam: Statement coverage, Function coverage, Decision coverage  e Data-Flow Coverage.

Bom espero ter esclarecido quais as principais (pelo menos) diferenças entre Black Box e White Box Testing.

 

Bom, até à próxima.

Entre a execução manual e a automática

Automação de testes é o uso de aplicações de software, scripts e/ou outros aplicativos de modo a  controlar a execução dos testes. Estes permitem a comparação dos resultados reais com os resultados previstos. Normalmente  usa-se  a automação de testes com o objectivo de automatizar um processo manual já existente de modo a eliminar que tarefas repetitivas e aborrecidas sejam feitas por humanos. 

Testes com execuções Manuais

O Tester tem a necessidade de executar todas as etapas do teste de modo manual e informar o sistema do resultado obtido. Existem várias ferramentas para gestão de testes que incluem uma interface gráfico que permite aligeirar a tarefa de cada utilizador.

Algumas vantagens de efectuar testes manuais são:

• O teste manual é preferível para produtos com ciclos de vida curtos.
• O teste manual é preferível para os produtos que possuem interfaces gráficas que mudam constantemente.
• Requerem menos tempo e dinheiro para começar o teste manual produtivo, i.e., têm um retorno mais rápido.
• A automação não consegue substituir a intuição e o raciocínio humano.
• Com um teste automatizado não é possível mudar de rumo no meio de um teste para examinar algo que anteriormente não haviam sido considerado, ou um qualquer pormenor estranho que não faz parte do plano original.

Testes Automáticos

Existem inúmeros modos se implementar inúmeros testes automatizados. Para tal é necessário que a ferramenta de gestão de testes seja compatível com os próprios testes. Para isso, as ferramentas de gestão de testes podem propor estruturas de automação de propriedades ou APIs para interface com terceiros. De modo a que o utilizador consiga cumprir o objectivo pretendido.

Benefícios da Automação de Testes

• Fiabilidade – O teste efectua exactamente a mesma operação cada vez que é executado.
• Velocidade – Sendo o processo automático não é necessária a presença humana para a sua execução, pelo que esta pode ser desviada para outras tarefas acelerando assim o processo. Além disso ferramentas automáticas tendem a executar mais rapidamente do que humanos.
• Reutilização – O teste pode ser utilizado inúmeras vezes entre diferentes versões do software.
• Melhor Qualidade do Software – Como é possível correr mais testes com o mesmo conjunto de recurso o que irá levar a um aumento da cobertura do software e a uma consequente melhoria da qualidade do software.

Contras da Automação de Testes

Embora a automação de testes traga muitas vantagens, a mesma também possui um conjunto de desvantagens. Algumas das desvantagens são:

• È necessária bastante proficiência para se criar scripts automatizados, pois estes por norma exigem bons conhecimentos de programação assim como do domínio da aplicação.
• A correcção do script de teste é algo também bastante importante e que pode ser uma fonte de dores de cabeça. Com a automação começam a surgir problemas de termos testes falhados não porque o comportamento da aplicação está incorrecto mas porque o script foi mal codificado. Por outro lado também podemos ter situações de falsos positivos. Automatizar é na prática escrever código para ser executado que está, obviamente, sujeito a erros tal como o código desenvolvido e alvo de testes.
• Testes a interfaces gráficos podem se tornar bastante caros. Porque uma pequena mudança no interface da aplicação irá obrigar à correcção do script de teste.
• A gestão de dados de testes torna-se complexa quando se possui um modelo de dados em “constante movimento”.

Linhas de Guia para a construção de testes automatizados

Cada requisito especificado é passível de ser automatizado. Idealmente todos os testes poderiam ser automatizados. Seria muito bom ter sempre tudo automatizado, mas infelizmente a automação é processo lento e complexo e pondo, para cada caso, em cima da mesa a relação custo/benefício de automatizar um caso de teste rapidamente chegamos à conclusão que existem inúmeros testes que ficam muito mais caros se forem automatizados do que corridos manualmente. Isto porque a automação desse caso pode ser complexa ou demorada, ou porque apenas precisamos de correr o teste uma vez, ou ainda porque o interface da aplicação vai sofrer alterações na distribuição seguinte. Sendo assim deixo alguns critérios para ajudar a escolher de forma mais adequada quais os testes a automatizar.

As seguintes áreas devem ser automatizados em primeiro lugar:

• Tarefas repetitivas e redundantes que são aborrecidas e que tendem a causar erros humanos com facilidade.
• Partes mais estáveis da aplicação. Não vale a pena automatizar partes que sabemos que vão ser modificadas um pouco depois.
• Funcionalidades mais críticas. Estando estas funcionalidades automatizadas é possível correr estes testes mais vezes.

A criação de testes automatizados deve seguir, sempre que possível, o seguinte conjunto de critérios:

• Conciso – Deve ser o mais simples quanto possível e não mais simples.
• Auto-Verificação – Efectua a verificação dos seus próprios resultados de teste sem a necessidade de intervenção humana.
• Repetitivo - O teste têm de poder ser executado várias vezes.
• Robusto – Várias execuções do mesmo teste devem devolver o mesmo resultado, desde que as condições do software se mantêm as mesmas.
• Claro – Cada instrução do script deve ter um objectivo fácil de entender.
• Específico – Cada teste deve efectuar uma verificação a uma funcionalidade específica do software.
• Independente - Cada teste deve correr individualmente ou como parte de uma suite mais alargada com uma ordem de execução arbitrária.
• Sustentável - Os testes devem ser fáceis de compreender, de modificar e melhorar.
• Rastreáveis – Deve ser possível ligar cada teste aos requisito e ao código coberto.

Alguns critérios para decidir se um teste deve ou não ser automatizado:

• Quantidade de vezes que se pretende executar o teste.
• Complexidade necessário para automatizar o teste.
• Importância da função alvo de teste.

Observações:

• Se a empresa ou instituição nunca teve qualquer tipo de processo de testes até ao momento, não será recomendável partir logo para a automação. Os resultados obtidos provavelmente não iram ser os melhores o que pode levar a frustrações e a conclusões erradas de que um processo de testes não trás vantagens.

Bom, até à próxima.

Processo de Testes

Um processo de testes deve, pelo menos, incluir as seguintes actividades:

• Planeamento dos testes – O planeamento dos teste é a actividade que define e verifica missão do teste, especificando os objectivos do teste e definindo as actividades a realizar a fim cumprir a missão. O planeamento pode ser documentado num plano de testes. Neste documento é definida a abordagem utilizada assim como os critérios de saída para os testes (Conjunto de critérios que nos possibilitam saber quando parar de testar, cobertura de requisitos é muitas das vezes usadas para este efeito). Nesta fase efectua-se uma estimativa do tempo de trabalho necessário.
• Análise e Desenho - A análise e o desenho de um plano de testes é a actividade onde os objectivos gerais do teste são transformados em condições e em situações de teste reais. È aqui que se identifica o que pode ser testado é o que não pode, que se prepara o ambiente de testes, e se efectua uma análise dos requisitos e documentação existentes.
• Implementação e execução - A implementação e a execução de casos de teste são uma actividade onde os procedimentos de teste são especificados combinando as situações de teste em uma ordem particular, incluindo também a informação necessária para a execução do teste. Aqui o ambiente de testes está pronto e testes são executados. Esta é uma fase em que se faz o desenvolvimento dos casos de teste, se verifica que os ambientes de teste estão funcionais e se dá inicio à execução dos testes, efectuando o registo de situações que não correspondam ao previsto. 
• Avaliação de Critérios de saída e relatórios – Quando são iniciados um conjuntos de testes deve existir sempre pré-definido qual o critério que definirá quando deveremos parar. Estes critérios podem passar por objectivos como: A cobertura de requisitos deve ser superior a 80%. Não podem ser encontrados mais de 2 defeitos muito graves e os menos graves têm de ser inferiores a 20.
• Actividades de fecho – Depois de concluída a execução de um plano de teste é necessário passar o conhecimento adquirido para os restantes elementos da equipa. Podendo deste modo a gestão decidir ajuizadamente sobre o lançamento de uma nova versão de software ou não. E também para permitir à equipa de desenvolvimento perceber o que correu mal de modo a corrigir os problemas encontrados.

Obviamente, estas não são as únicas actividades que devem existir, mas são o conjunto de actividades que não podem deixar de existir, sob pena de se começar a perder alguma credibilidade no processo em causa.

 

Bom, até à próxima.