Teste de software
Origem: Wikipédia, a enciclopédia livre.
| Processo de Desenvolvimento de Software |
|---|
| Este artigo é parte da série Processo de desenvolvimento de software |
| Atividade e Passos |
| Requirimentos | Arquitetura | Especificação | Implementação | Teste | Implantação | Manutenção |
| Modelos |
| Ágil | Cleanroom | Interativo | RAD | RUP | Spiral | Waterfall | XP | Scrum |
| Disciplinas de Apoio |
| Gerenciamento de configuração | Documentação | Gerenciamento de Projeto |
O teste do software é uma das fases do processo de engenharia de software que visa atingir um nível de qualidade de produto superior. O objetivo, por paradoxal que pareça, é mesmo o de encontrar defeitos no produto, para que estes possam ser corrigidos pela equipe de programadores, antes da entrega final. A maioria das pessoas pensa que o teste de software serve para demonstrar o correto funcionamento de um programa, quando na verdade ele é utilizado como um processo da engenharia de software para encontrar defeitos. O conceito de teste de software pode ser compreendido através de uma visão intuitiva ou mesmo de uma maneira formal. Existem atualmente várias definições para esse conceito. De uma forma simples, testar um software significa verificar através de uma execução controlada se o seu comportamento corre de acordo com o especificado. O objetivo principal desta tarefa é encontrar o número máximo de erros dispondo do mínimo de esforço, ou seja, mostrar aos que desenvolvem se os resultados estão ou não de acordo com os padrões estabelecidos.
Índice |
[editar] Introdução
Em uma situação ideal, nós como programadores partindo do princípio que somos bons no que fazemos poderíamos garantir que todos os programas funcionariam corretamente. Infelizmente esta não é a realidade. Isso porque os programas possuem um grande número de estados com fórmulas complexas, atividades e algoritmos. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais a complexidade. Assim, a presença de falhas é inevitável. Mas o que significa dizer que um programa falhou? Basicamente significa que o funcionamento do programa não está de acordo com o esperado pelo usuário. Por exemplo, quando um usuário da linha de produção efetua consultas no sistema das quais só a gerência deveria ter acesso. Esse tipo de falha pode ser originado por diversos motivos, como os listados abaixo:
- A especificação pode estar errada ou incompleta.
- A especificação pode conter requisitos impossíveis de serem implementados, devido à limitações de hardware ou software.
- Talvez a base de dados esteja organizada de forma que não seja permitido distinguir os tipos de usuário.
- Pode ser que haja um erro no algoritmo de controle dos usuários
- Pode ser que haja erros no código, o algoritmo pode estar implementado de forma errada ou incompleta.
Portanto, uma falha é o resultado de um ou mais defeitos em algum aspecto do sistema. O teste de software pode ser visto como uma parcela do processo de qualidade de software. A qualidade da aplicação pode, e normalmente, varia significativamente de sistema para sistema mas os atributos qualitativos comuns incluem fiabilidade, estabilidade, portabilidade, manutenção, flexibilidade e usabilidade.
[editar] Qualidade de Software
Um desenvolvimento organizado de software tem como premissa uma metodologia de trabalho. Esta deve ter como base conceitos que visem a construção de um produto de software de forma eficaz. Dentro desta metodologia estão definidos os passos necessários para chegar ao produto final esperado. Esse é o campo de estudos da Qualidade de Software, uma sub-área da Engenharia de Software.
Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software espera-se um produto final que melhor agrade tanto aos clientes quanto ao próprio fornecedor, ou seja, a empresa de desenvolvimento.
Observando este aspecto, não faz sentido iniciar a construção de um produto de software sem ter uma metodologia de trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no processo. Porém, além de uma crescente demanda por softwares de qualidade, as empresas de desenvolvimento de software sofrem cada vez mais pressão por parte dos clientes para que o produto seja entregue num curto período de tempo. Este fato pode fazer com que uma sólida metodologia de trabalho acabe por se desequilibrar.
Independentemente da metodologia de trabalho empregada no desenvolvimento de um software, para que se obtenha um produto final com um certo nível de qualidade é imprescindível a melhoria dos processos de engenharia de software.
Uma maneira viável para se assegurar a melhoria de tais processos seria tomar como base modelos sugeridos por entidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situações e ambientes específicos ou para soluções genéricas, existem alguns que são mais utilizados e tidos como eficientes, como por exemplo os SW-CMM, SE-CMM, ISO 15504 e o mais conhecido CMMI.
Outro factor com grande influência sobre a qualidade do software a ser produzido é o que diz respeito aos testes que serão executados sobre tal produto. Todas as metodologias de desenvolvimento de software têm uma disciplina dedicada aos testes. Atualmente esta é uma tarefa indispensável, porém muitas vezes efetuada de maneira ineficiente, seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de recursos humanos e financeiros.
[editar] Técnicas de Teste
Atualmente existem muitas maneiras de se testar um software. Mesmo assim, existem as técnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje tem grande valia para os sistemas orientado a objeto. Apesar de os paradigmas de desenvolvimento serem completamente diferentes, o objetivo principal destas técnicas continua a ser o mesmo: encontrar falhas no software. Abaixo estão descritas as três técnicas mais conhecidas.
[editar] Caixa-Branca
Dentro desta categoria de teste de software o desenvolvedor tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e componentes. Este tipo de teste é desenvolvido analisando-se o código fonte e elaborando-se casos de teste que cubram todas as possibilidades do programa. Dessa maneira, todas as variações originadas por estruturas de condições são testadas. Um exemplo bem prático deste teste é o JUnit para desenvolvimento com a linguagem Java.
[editar] Caixa-Preta
Neste tipo de teste de software o desenvolvedor dos testes não possui acesso algum ao código fonte do programa. O objetivo é efetuar operações sobre as diversas funcionalidades e verificar se o resultado gerado por estas está de acordo com o esperado. Para esta categoria podem ser levados em consideração todos os eventos que podem ser disparados pelo usuário, como por exemplo, cada clique de mouse a ser realizado em uma interface.
[editar] Caixa-Cinza
O termo caixa-cinza (gray box ou grey box) aparece com muitas interpretações na literatura de testes.
Uma definição deste tipo de teste seria um ponto de equilíbrio virtual entre o teste de caixa-branca e o caixa-preta. De uma maneira mais clara, o desenvolvedor dos testes não tem acesso ao código fonte da aplicação, porém tem conhecimento dos algoritmos que foram implementados, como também pode efetuar manipulações em arquivos de entrada e saída do tipo XML ou mesmo acessos ao banco de dados da aplicação para simples conferência de dados ou alteração de parâmetros considerados nos casos de teste.
Outros autores definem caixa-cinza como o teste de integração, onde você vê o sistema até o nível de módulo, mas não pode ver no interior dos módulos. Ainda é possível encontrar a definição de caixa-cinza como um teste onde algumas partes estão disponíveis como caixa-branca e outras como caixa-preta.
[editar] Testes Alpha, Beta e Gama
No processo de desenvolvimento, os testes preferencialmente devem ser executados antes do produto ser disponibilizado aos usuários. Esse período entre o término do desenvolvimento e da entrega é conhecido como fase alpha e os testes executados nesse período como testes alpha. No início dos testes da fase alpha são utilizadas técnicas de caixa-branca. Posteriormente, os desenvolvedores dos testes aplicam técnicas de caixa-preta como complemento da primeira parte de testes. Completada a fase alpha de testes, são lançadas a grupos restritos de usuários versões de teste do sistema, denominadas versões beta. Conseqüentemente este período fica denominado como fase beta. Através deste tipo de teste os usuários finais do produto podem encontrar defeitos peculiares de tarefas costumeiramente executadas por eles. Visando um maior retorno de informações sobre o mal funcionamento do sistema algumas empresas distribuem as versões betas para todo o universo de utilizadores. Paralelamente podem ser executados testes de caixa-preta durante essa fase, dando assim maior eficiência no processo.
[editar] Versões Candidatas (Release Candidates)
Ultimamente, e principalmente na comunidade de software livre, é comum utilizar o termo release candidate para indicar uma versão que é candidata a ser a versão final, em função da quantidade de erros encontradas.
As RC, como são chamadas, são um passo além do teste beta, sendo divulgadas para toda a comunidade.
[editar] Categorias de Testes
[editar] Teste de Unidade
Também conhecido como testes unitários. É um tipo de atividade que visa testar pequenas partes ou unidades do sistema. O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo.
[editar] Teste de Componente
Este tipo de teste possui um universo um pouco maior ao teste unitário. Seu propósito é testar o componente como um todo e não apenas as suas funções ou métodos. Mesmo assim, o teste continua a ser executado sem considerar a iteração com outras partes do sistema, ou seja, leva-se apenas em consideração o componente a ser testado e nenhuma outra entidade do sistema.
[editar] Teste de Integração
O teste de integração, como o próprio nome já diz, visa encontrar falhas provenientes da integração dos componentes do sistema. Geralmente os tipos de falhas encontradas são de envio e recebimento de dados. Por exemplo, um objeto A pode estar esperando o retorno de um valor x ao executar um método do objeto B, porém este objeto B pode retornar um valor y...
[editar] Teste de Sistema
Este é um teste de grande importância. Sua principal filosofia é varrer o sistema em busca de falhas através da utilização do mesmo, como se fosse um usuário final. Dessa maneira, os testes são executados nos mesmos ambientes, com as mesmas condições e com os mesmos dados de entrada que um usuário utilizaria no seu dia-a-dia de manipulação do sistema.
[editar] Teste de Aceitação
São realizados geralmente por um restrito grupo de usuários de aos finais do sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado. Teste formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o sistema. Validação de um software pelo comprador, pelo usuário ou por terceira parte, com o uso de dados ou cenários especificados ou reais. Pode incluir testes funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho.
[editar] Recursos humanos
[editar] Líder do Projeto de Testes
Técnico responsável pela liderança de um projeto de teste específico,normalmente relacionado a um sistema de desenvolvimento, seja um projeto novo ou uma manutenção.
[editar] Arquiteto de Teste
É o técnico reponsável pela montagem da infraestrutura de teste, montando o ambiente de teste, escolhendo as ferramentas de teste e capacitando a equipe para executar o seu trabalho nesse ambiente.
[editar] Analista de Teste
É o técnico reponsável pela modelagem e elaboração dos Casos de Teste e pelos Scripts de Teste.Pode ser que em alguns casos os Scripts de Teste sejam elaborado pelos testadores.
[editar] Testador
Técnico responsável pela execução dos Casos de Teste e Script de Teste.
[editar] Bibliografia
- KOSCIANSKI, A., Soares, M. S. Qualidade de Software. Editora Novatec, 2006.
- PRESSMAN, R. S.. Engenharia de Software. Ed. McGraw Hill, 2002.
