Revisões técnicas formais


IV. FASE DE VERIFICAÇÃO, LIBERAÇÃO E MANUTENÇÃO



Yüklə 248,76 Kb.
səhifə7/9
tarix01.11.2017
ölçüsü248,76 Kb.
#25554
1   2   3   4   5   6   7   8   9

IV. FASE DE VERIFICAÇÃO, LIBERAÇÃO E MANUTENÇÃO

Esta é a última etapa do processo de desenvolvimento e manutenção descrito na seção I.6. Inclui a realização de testes de unidades, integração e validação, a liberação e distribuição e por fim a manutenção do sistema. Nesta apostila serão abordadas estratégias para realização de teste de software e a manutenção.




IV.1 ESTRATÉGIAS DE TESTE DE SOFTWARE

Não é raro que uma organização de software gaste 40% do esforço total de projeto em teste. A atividade de teste de software de sistemas dos quais dependem vidas humanas (por exemplo, controle de vôo, monitoração de reatores nucleares), pode custar de três a cinco vezes mais que todos os outros passos de engenharia de software juntos !” [Pressman-95]


Teste: atividade que visa avaliar uma característica ou recurso de um programa ou sistema de software através de sua execução.
Qualquer estratégia de teste de software deve incluir as seguintes atividades:

  • Projeto de casos de teste: devem ser projetados casos de teste que tenham a mais alta probabilidade de descobrir a maioria dos erros com uma quantidade mínima de tempo e esforço. Estes casos devem constar do Plano de Teste.

  • Execução de teste: Para a realização dos testes deve-se ter a mão o Plano de Teste. Após a realização dos testes, os resultados devem ser comparados com os resultados esperados. Quando há erro deve-se realizar a depuração. Depuração: é a parte mais imprevisível do processo de teste. Um erro pode demorar uma hora, um dia ou um mês para ser diagnosticado e corrigido.

  • Coleta e avaliação de dados: à medida que os resultados de teste são reunidos e avaliados, uma indicação qualitativa da qualidade e da confiabilidade do software começa a vir à tona.


Caso de teste: um conjunto específico de dados de entrada e condições de arquivos, juntamente com os resultados esperados, relacionados a um determinado objetivo.
Plano de teste: um documento organizado que contém para cada caso de teste as seguintes informações:

  • Objetivo do teste e que parte do sistema será verificada

  • Onde e quando o teste será realizado

  • Descrição do caso de teste

  • Procedimentos operacionais


Uma estratégia de teste:

Inicialmente os testes focalizam cada módulo individualmente. Estes testes são conhecidos como testes de unidades. Em seguida os módulos devem ser montados ou integrados para formarem um pacote de software. São realizados, então, os testes de integração. Depois que o software foi integrado, um conjunto de testes de alto nível é realizado. Esses testes de alto nível são os testes de validação e de sistema.


Testes de Unidade:

  • Têm como objetivo testar os módulos do programa

  • Abordagens para seleção dos casos de teste:

  • Funcionais: independentes da lógica da codificação (Teste caixa preta): A idéia é que conhecendo-se o objetivo do módulo, testes podem ser realizados para demonstrar que cada função é totalmente operacional.

  • Estruturais: obtidos a partir da estrutura do programa (Teste caixa branca): A idéia é que conhecendo-se o funcionamento interno de um módulo, testes podem ser realizados para garantir que todas as engrenagens se encaixam, ou seja, que a operação interna do módulo tem um desempenho de acordo com as especificações e que os componentes internos foram adequadamente postos à prova.

  • Limites e situações extremas

  • Necessita-se muitas vezes de stubs e drivers. Driver é um “programa principal” que aceita dados de caso de teste, passa tais dados para o módulo ser testado e imprime os dados relevantes. Os stubs servem para substituir módulos que estejam subordinados ao módulo a ser testado. Um stub, ou “programa simulado”, usa a interface do módulo subordinado, pode fazer manipulação de dados mínima, imprime a verificação e retorna.

  • O teste de unidade é simplificado quando um módulo com elevada coesão é projetado. Quando somente uma função é endereçada por um módulo, o número de casos de teste é reduzido e os erros podem ser mais facilmente previstos e revelados.


Testes de integração:

  • Têm como objetivo testar interfaces.

  • Apesar de todos os módulos funcionarem corretamente individualmente, podem surgir problemas ao serem colocados juntos. Dados podem ser perdidos ao longo de uma interface; um módulo pode ter um efeito inesperado, sobre outro; as subfunções quando combinadas, podem não produzir a função principal esperada; uma imprecisão individualmente aceitável pode ser ampliada até níveis inaceitáveis; as estruturas de dados globais podem apresentar problemas. Etc...

  • Não é bom testar tudo junto já que fica difícil determinar as causas de erros encontrados. Pode-se adotar uma estratégia de integração incremental. O programa é construído e testado em pequenos segmentos, ficando mais fácil isolar os erros e corrigi-los.



Testes de Sistema:

  • Visam a realização de uma série de testes de forma a observar se os elementos do sistema foram adequadamente integrados, se estão realizando as funções especificadas e se o desejado desempenho global do sistema foi atingido.

  • Podem ser realizados os seguintes tipos de teste:

  1. Recuperação: Este teste força o sistema a falhar de diversas maneiras e verifica se a recuperação é adequadamente executada. Verifica, por exemplo, se o tempo médio até o reparo se encontra dentro dos limites aceitáveis.

  2. Segurança: Verifica se todos os mecanismos de proteção do sistema o protegerão de fato no caso de acessos indevidos.

  3. Stress: Realizado para verificar como o sistema se comporta em situações de stress. Exemplo:

  • Testes que gerem um número maior de interrupções do que a média esperada.

  • Testes em que os índices de entrada de dados são aumentados.

  • Testes que exigem o máximo de memória ou outros recursos.

  • Testes que provocam procura excessiva por dados.



Testes de aceitação ou validação:


  • Têm como objetivo demostrar que o sistema está pronto para ser colocado em operação.

  • Quem dirá que o sistema está pronto ? Depende do que foi definido na Especificação de Requisitos com relação aos critérios de validação.

  • Escolha dos casos de teste: a cargo dos usuários com a assessoria técnica dos responsáveis pelos testes

  • Pode ser realizado em um ou mais dias de trabalho usando os dados reais num processamento em paralelo ao sistema atual

  • Se o software for desenvolvido como um produto a ser usado por muitos clientes, torna-se pouco prático realizar testes de aceitação com cada um. Usa-se então um processo denominado teste alpha e teste beta.

  • Teste alpha: Realizado por um cliente nas instalações do desenvolvedor.

  • Teste beta: Realizado em uma ou mais instalações do cliente pelo usuário final do software. O desenvolvedor normalmente não está presente.


Organização para a realização de teste de software:

A atividade de teste é realizada pela equipe de desenvolvimento do software e para grandes projetos por um grupo de teste independente.

“Como qualquer construtor, o engenheiro de software sente-se orgulhoso do edifício que construiu e parece olhar de esguelha para qualquer um que tente derrubá-lo. Quando os testes iniciam há uma sutil, mas definida, tentativa de quebrar o que o engenheiro de software construiu. Do ponto de vista do construtor, a atividade de teste pode ser vista psicologicamente com destrutiva. Sendo assim, o construtor pisa de leve projetando e executando testes que demonstrem que o programa funciona em vez de descobrir erros. Infelizmente os erros estarão presentes. Em se o engenheiro de software não os encontrar, o cliente o fará !” [Pressman-95]

Assim, é necessária a consciência de que é melhor encontrar antes os erros. A equipe de desenvolvimento é sempre responsável por testar os módulos do programa, para garantir que cada uma execute a função para a qual foi projetada. Em muitos casos a equipe de desenvolvimento também realiza testes de integração. Só depois que a arquitetura de software está completa é que um grupo de teste independente poderá envolver-se. Este grupo deve trabalhar unido ao longo do projeto de software a fim de garantir que testes cuidadosos sejam levados a efeito. Enquanto a atividade de teste é realizada, a equipe de desenvolvimento deve estar à disposição para corrigir erros que sejam descobertos pela equipe de testes.


Conclusão:

  • Realizar testes é uma atividade difícil e criativa

  • Testes atuam também prevenindo erros

  • Testes devem ser planejados

  • Realizar teste exige independência

  • O armazenamento de informações, como quantidade e tipo de erros encontrados durante o desenvolvimento e a manutenção, é fundamental na determinação da qualidade de programas e sistemas que venham a ser desenvolvidos.


Yüklə 248,76 Kb.

Dostları ilə paylaş:
1   2   3   4   5   6   7   8   9




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2024
rəhbərliyinə müraciət

gir | qeydiyyatdan keç
    Ana səhifə


yükləyin