Teste de Software

  • 0

Teste de Software

Categoria: Gestão em TI

Imagem de Teste

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 previstos na norma ISO 9126 que são: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. 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.

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 têm grande valia para os sistemas orientados 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.

Caixa-Branca

Técnica de teste que avalia o comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código-fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos e teste de caminhos lógicos. Os aspectos avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a construção do componente de software, cabendo portanto avaliação mais aspectos que os citados anteriormente. O testador 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 componente de software. Dessa maneira, todas as variações originadas por estruturas de condições são testadas. Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre JUnit para desenvolvimento de classes de teste (test cases) para testar classes ou métodos desenvolvidos na Java. Também se enquadram nessa técnica testes manuais ou testes efetuados com apoio de ferramentas para verificação de aderência a boas práticas de codificação reconhecidas pelo mercado de software. A aderência a padrões e boas práticas visa principalmente a diminuição da possibilidade de erros de codificação e a busca de utilização de comandos que gerem a melhor performance de execução possível. Apesar de muitos desenvolvedores alegarem que não há ganhos perceptíveis com essa técnica de teste aplicada sobre unidades de software, devemos lembrar que, no ambiente produtivo, cada programa pode vir a ser executado milhares ou milhões de vezes em intervalos de tempo pequenos. É na realidade de produção que a soma dos aparentes pequenos tempos de execução e consumo de memória de cada programa poderá levar o software a deixar de atender aos objetivos esperados. A técnica de teste de Caixa-Branca é recomendada para as fases de Teste da Unidade e Teste da Integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que por sua vez conhecem bem o código-fonte produzido.

Caixa-Preta

Técnica de teste em que o componente de software a ser testado é abordado como se fosse uma caixa-preta, ou seja, não se considera o comportamento interno do mesmo. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. Haverá sucesso no teste se o resultado obtido for igual ao resultado esperado. O componente de software a ser testado pode ser um método, uma função interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade. A técnica de teste de Caixa-Preta é aplicável a todas as fases de teste – fase de teste de unidade (ou teste unitário), fase de teste de integração, fase de teste de sistema e fase de teste de aceitação. A aplicação de técnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situações de teste). A aplicação combinada de outra técnica – Técnica de Particionamento de Equivalência (ou uso de Classes de Equivalência) permite avaliar se a quantidade de casos de teste produzida é coerente. A partir das classes de equivalência identificadas, o testador irá construir casos de teste que atuem nos limites superiores e inferiores destas classes, de forma que um número mínimo de casos de teste permita a maior cobertura de teste possível.

Outras Técnicas

Outras técnicas de teste podem e devem ser utilizadas de acordo com necessidades de negócio ou restrições tecnológicas. Destacam-se as seguintes técnicas: Teste de Performance, Teste de Usabilidade, Teste de Carga, Teste de Stress, Teste de Confiabilidade e Teste de Recuperação. Alguns autores chegam a definir uma técnica de Teste Caixa Cinza, que seria um mesclado do uso das técnicas de Caixa Preta e Caixa Branca, mas, como toda execução de trabalho relacionado à atividade de teste utilizará simultaneamente mais de uma técnica de teste, é recomendável que se fixem os conceitos primários de cada técnica.

Teste de software 2

Fases de Teste

Teste de Unidade

Também conhecida como Teste Unitário. É a fase do processo de teste em que se testam as menores unidades de software desenvolvidas( 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.

Teste de Integração

Na fase de teste de integração o objetivo é encontrar falhas provenientes da integração interna dos componentes de um sistema. Geralmente os tipos de falhas encontradas são de envio e recebimento de dados. Por exemplo, um objeto A pode estar aguardando o retorno de um valor X ao executar um método do objeto B, porém este objeto B pode retornar um valor Y, desta forma gerando uma falha. Não faz parte do escopo dessa fase de teste o tratamento de interfaces com outros sistemas (integração entre sistemas). Essas interfaces são testadas na fase de teste de sistema, apesar de, a critério do gerente de projeto, estas interfaces poderem ser testadas mesmo antes de o sistema estar plenamente construído..

Teste de Sistema

Na fase de Teste de Sistema o objetivo é executar o sistema sob ponto de vista de seu usuário final, varrendo as funcionalidades em busca de falhas. Os testes são executados em condições similares – de ambiente, interfaces sistêmicas e massas de dados – àquelas que um usuário utilizará no seu dia-a-dia de manipulação do sistema. De acordo com a política de uma organização podem ser utilizadas condições reais de ambiente, interfaces sistêmicas e massas de dados.

Teste de Aceitação

Fase de Teste em que o teste é conduzido por usuários finais do sistema. Os testes são realizados, geralmente, por um grupo restrito de usuários 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.

 Teste de Operação

Fase de Teste em que o teste é conduzido pelos administradores do ambiente final onde o sistema ou software entrará em ambiente produtivo. Vale ressaltar que essa fase é aplicável somente a sistemas de informação próprios de uma organização, cujo acesso pode ser feito interna e/ou externamente a essa organização. Nessa fase de teste devem ser feitas simulações para garantir que a entrada em produção do sistema será bem sucedida. Envolve testes de instalação, simulações com backup e restore das bases de dados, etc. Em alguns casos um sistema entrará em produção para substituir outro e é necessário garantir que o novo sistema continuará garantindo o suporte ao negócio.

 Teste de Regressão

Fase de Teste aplicável a uma nova versão de software ou à necessidade de se executar um novo ciclo de teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que ja foram aplicados nas versões ou ciclos de teste anteriores do sistema. Inclui-se nesse contexto a obervação de fases e técnicas de teste de acordo com o impacto de alterações provocado pela nova versão ou cilo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, é recomendada a utilização de ferramentas de automação de testes, de forma que, sobre a nova versão ou ciclo de teste, todos os testes anteriores possam ser reexecutados com maior agilidade.

Testes Alpha, Beta e Gama

Em casos especiais de processos de desenvolvimento de software – Sistemas Operacionias, Sistemas Gerenciadores de Bancos de Dados(SGBD), e outros softwares comerciais disponibilizados no mercado nacional e internacional – os testes requerem fases também especiais antes do produto ser disponibilizado todos os usuários.O 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. PRESSMAN afirma que o teste alfa é conduzido na instalação do desenvolvedor com o cliente. O software é usado num ambiente natural com o desenvolvedor “olhando sobre o ombro” do usuário e registrando erros e problemas de uso. Testes alfa são conduzidos num ambiente controlado.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. O Teste Beta também é um teste de aceitação voltado para softwares cuja distribuição atingirá grande número de usuários de uma ou várias empresas compradoras. PRESSMAN afirma que o teste beta é conduzido, em uma ou mais instalações do cliente, pelo usuário final do software. Diferente do teste alfa, o desenvolvedor geralmente não está presente. Conseqüentemente o teste beta é uma aplicação “ao vivo” do software num ambiente que não pode ser controlado pelo desenvolvedor. O cliente registra todos os problemas (reais ou imaginários) que são encontrados durante o teste beta e os relata ao desenvolvedor em intervalos regulares. Como resultado dos problemas relatados durante os testes beta, os engenheiros de software fazem modificações e depois se preparam para liberar o produto de software para toda a base de clientes.

Os testes Gama não são propriamente testes de software. A comunidade do teste de software usa este termo de forma sarcástica referindo-se aos produtos que são mal testados e são entregues aos utilizadores para que estes encontrem os defeitos já em fase de produção.


Deixe seu comentário