Técnicas de teste - Básico
Verificação e Testes de Programas
A etapa de design (projeto) de software (do modelo conceitual, da interface e da arquitetura) tem por objetivo encontrar as soluções que satisfaçam os requisitos do software. No design as soluções são especificadas através de formas e modelos que possibilitam diferentes visões do software. Todavia para que o software funcione é essencial que as ideias produzidas durante o projeto seja codificadas em uma linguagem de programação para que possam ser traduzidas e executadas num computador.
O código produzido durante esta etapa pode conter falhas ou erros. Visto que os erros podem ser ocasionados por diversos fatores., onde um deles pode ser a interpretação errada dos modelos produzidos durante o projeto. A complexidade de um programa, seja pela complexidade de um algoritmo ou pelo seu tamanho, pode levar ao programador a gerar um software com muitos erros de funcionamento. Assim sendo, definir o que é um erro ou falha num software não é uma tarefa simples.
Inicialmente, precisamos conhecer a diferença entre Defeitos, Erros e Falhas.
- Defeito é um to inconsciente cometido por um indivíduo ao tentar entender uma determinada informação, resolver um problema ou utilizar um método ou uma ferramenta. Por exemplo, uma instrução ou comando incorreto.
- Erro é uma manifestação concreta de um defeito num artefato de software. Diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na execução de um programa constitui um erro.
- Falha é o comportamento operacional do software diferente do esperado pelo usuário. Uma falha pode ter sido causada por diversos erros e alguns erros podem nunca causar uma falha.
A Figura 1 expressa a diferença entre esses conceitos. Defeitos fazem parte do universo físico (a aplicação propriamente dita) e são causados por pessoas, por exemplo, através do mal uso de uma tecnologia. Defeitos podem ocasionar a manifestação de erros em um produto, ou seja, a construção de um software de forma diferente ao que foi especificado (universo de informação). Por fim, os erros geram falhas, que são comportamentos inesperados em um software que afetam diretamente o usuário final da aplicação (universo do usuário) e pode inviabilizar a utilização de um software.
Podemos simplificar dizendo que um erro é quando o software não se comporta conforme foi especificado. Isto pode ocorrer quando o software não realiza um função esperada, fornece resultados não esperados, não consegue terminar quando esperado, etc. Para se avaliar o funcionamento do teste é preciso definir quais os critérios necessários para consideramos que o mesmo está correto ou não, isto é, o que pode ser considerado um erro ou falha. Além disso, é preciso determinar quais métodos ou técnicas para verificação do funcionamento serão empregadas.
Dessa forma, ressaltamos que teste de software revela simplesmente falhas em um produto. Após a execução dos testes é necessária a execução de um processo de depuração para a identificação e correção dos defeitos que originaram essa falha, ou seja, Depurar não é Testar!
VERIFICAÇÃO E VALIDAÇÃO (V&V)
Logo após finalizar o processo de implementação, o programa deve ser verificado para termos a certeza de que ele atende a sua especificação e entrega a funcionalidade solicitada pelos clientes. O processo de Verificação e Validação (V&V) é o nome dado a esse processo de verificação e analise, onde as atividades de V&V ocorrem em cada fase do processo de software, iniciando com as revisões de requisitos , continuando com o projeto e das inspeções de código até os testes de produtos.
O processo de Verificação e Validação não são a mesma coisa, uma vez que a validação se preocupa se “estamos construindo o produto certo?” e a verificação tem o foco se“estamos construindo o produto da forma correta?”. Desta maneira o papel da verificação nos faz ver se o software esta de acordo com as especificações, se atende ou não os requisitos funcionais e não-funcionais. Já a validação é um processo mais amplo, cuja finalidade é garantir que o software atenda as expectativas do cliente. O maior objetivo do processo de V&V é estabelecer a confiança de que o software esteja adequado ao proposito ao qual foi desenvolvido, porém o nível de confiabilidade depende do fim a que se presta o software, das expectativas dos usuários do sistema e do atual ambiente de mercado.
Dentro do processo de V&V podemos verificar duas abordagens para a verificação e analise de sistema, onde a primeira seria a inspeção de software ou revisões por pares também chamado de técnica de V&V estática, onde analisam e verificam as representações do sistema como um documento de requisitos, diagramas de projeto, código-fonte do programas, etc. e a segunda abordagem seria a de testes de softwaretambém conhecida com técnica de V&V dinâmica, que envolvem a execução do software com dados de testes a fim de checar as saídas do software, o comportamento operacional no intuito de verificar se o seu desempenho está conforme o desejado.
As técnicas de inspeções incluem inspeções de programa e de analise de código-fonte, porem não podem demonstrar que o software é operacionalmente útil. Embora as inspeções de software sejam amplamente usadas, os testes de programas será sempre a técnica principal de V&V do software, uma vez que exercita o programa utilizando dados reais processados pelo programa, onde descobre erros e defeitos nos programas. Há dois tipos de testes que podem ser utilizados no processo de software o teste de validação que tem a finalidade de mostrar que o software é o que o cliente deseja e teste de defeitos que é destinado a revelar defeitos no sistema em vez de simular o seu uso operacional, tendo como objetivo encontrar inconsistências entre um programa e sua especificação.
Os processos de V&V e de depuração (debugging) geralmente são intercalados, na medida em que descobre os defeitos no programa, você deve alterar o programa para corrigir esses defeitos. Porem o teste e o debugging tem finalidades diferentes, onde os testes são dedicados a estabelecer a existência de defeitos no sistema e o debugging é um processo que localiza e corrige esses defeitos.
Planejar a verificação e validação é um processo caro, pois para alguns sistemas de tempo real com restrições não-funcionais complexas, boa parte do orçamento pode ser gasto em processos de V&V. Como parte do processo de planejamento de V&V há necessidade de decidir sobre o equilíbrio entre as abordagens estática e dinâmica para os processos de V&V, especificar os padrões e procedimentos para inspeções e testes de software e por fim estabelecer o checklists para direcionar as inspeções nos programas.
O planejamento de teste concentra-se no estabelecimento de padrões para o processo de teste e não apenas na descrição dos testes. Os principais componentes de um plano de teste são:
- Processo de teste
- Rastreabilidade de requisitos
- Itens testados
- Cronograma de testes
- Procedimentos de registro de testes
- Requisitos de hardware e software
- Restrições
Os planos de testes não são documentos estáticos, pois evoluem durante o processo de desenvolvimento, ou seja, mudam devido a atrasos em outros estágios do processo de desenvolvimento.
As inspeções de software é um processo de V&V estática, onde um sistema de software é revisto para encontrar erros, omissões e anomalias. Geralmente tem o foco no código-fonte, mas em qualquer representação legível do software pode ser inspecionado (requisitos, algoritmos, etc). Quando realizamos a inspeção de um sistema, nos usamos o conhecimento do sistema, seu domínio de aplicação, a linguagem de programação ou o modelo de projeto para descobrir erros.
Inspeções é uma ideias antiga, visto que as inspeções são mais eficientes para descobrir defeitos do que testes de programas. Dentre as vantagens dos processos de inspeção podemos citar:
- Durante os testes, os erros podem ocultar outros erros, pois, uma vez que um erro é descoberto não podemos ficar seguros de se outros erros descobertos são devidos a um novo erro ou se são efeitos colaterais dos erros descobertos originalmente. Por ser um processo estático, em uma única sessão de inspeção pode-se descobrir muitos erros de um sistema.
- Versões incompletas podem ser inspecionadas, se um programa esta incompleto é necessário desenvolver um conjunto de testes especializados para essas partes disponíveis, acrescentando assim os custos do projeto.
- A inspeção deve considerar atributos de qualidade mais abrangentes de um programa tais como a conformidade com padrões, portabilidade, facilidade de manutenção, etc.
Revisões e testes tem vantagens e desvantagens que devem ser usadas em conjunto no processo de V&V. Uma das aplicações mais eficientes das revisões é revisar os casos de testes para um sistema. As revisões podem descobrir problemas com esses testes e auxiliar a projetar caminhos mais eficientes para testar um sistema. Inicialmente o V&V do sistema deve começar inspeções no inicio do processo de desenvolvimento e se este for sistema integrado, é preciso testá-lo para verificar as propriedades emergentes e se a funcionalidade do sistema é a que o cliente realmente deseja.
Na há duvidas de que as inspeções que começam no inicio os custos de V&V do sistemas e resultam em economia de custos somente depois que as equipes de desenvolvedores se tornam experientes em seu uso. Além disso as inspeções levam tempo para serem organizadas e parecem diminuir a velocidade do processo de desenvolvimento, sendo difícil de convencer um gerente com projetos em atraso de que esse tempo pode ser recuperado mais tarde pelo fato de que menos tempo será dispendido no processo de debugging.
Nenhum comentário:
Postar um comentário