Levantamento, Análise e Gestão...
Transcript of Levantamento, Análise e Gestão...
Validação:● Critérios● Revisões dos Requisitos● Prototipação● Geração de Casos de Teste● Funcionais
Agenda
● Certificar que o documento de requisitos é uma descrição aceitável do sistema a implementar● Verificar se o documento de requisitos:
● É completo e consistente● Está em conformidade com os padrões da
organização● Não existem conflitos entre requisitos● Não existem erros técnicos● Não existem requisitos ambíguos
● Validação é importante uma vez que o custo para remover um erro de requisitos é grande
Validação de Requisitos
● Os requisitos estão claramente estabelecidos?● A fonte (pessoa, regulamento, documento) do requisito está identificada?● O requisito está limitado em termos quantitativos?● Que outros requisitos se relacionam a este requisito?● O requisito viola alguma restrição do domínio?● O requisito pode ser testado? É possível definir critérios de validação para os requisitos?● A especificação está estruturada, levando a fácil entendimento?● Os requisitos associados com o desempenho, comportamento e características operacionais do sistema foram claramente declarados?
Checklist para Validação de Requisitos
● Documento de requisitos● Versão completa do documento formatado● Organizado de acordo com os padrões da empresa
● Conhecimento organizacional● Conhecimento implícito da organização● Usado para avaliar o realismo do requisitos
● Padrões da organização● Usar padrões locais para a organização do
documento de requisitos
Itens para Validação de Requisitos
● Problemas:● São encontrados no documento de requisitos● Podem ter várias ações corretivas● Podem não ter quaisquer ações associadas
● Criar um Lista de Ações acordada em resposta aos problemas encontrados
Problemas na Validação de Requisitos
● Revisão de requisitos● Análise manual sistemática dos requisitos
● Prototipação● Uso de um modelo executável do sistema
para checar os requisitos● Geração de casos de teste
● Desenvolver testes para os requisitos a fim de verificar a testabilidade
Técnicas de Validação de Requisitos
Durante uma reunião...- O sistema que queremos deve fazer isto, isto, e
nesse caso também isto...- Sim, Sim, estou anotando...- Conversei com os usuários e basicamente este é o
sistema que teremos que desenvolver.- Sim- Ótimo, começaremos a especificar os requisitos
imediatamente.
Revisões de Requisitos – Um Caso Comum
Quatro meses depois ...- Senhores usuários, após o emprego das mais
modernas técnicas de especificação, produzimos este documento que descreve minuciosamente o Sistema.
- Ótimo! Bom! Hum! ... É um documento com 300 páginas e todos estes gráficos, tabelas. Enfim, vamos analisá-los e voltamos a falar.
Revisões de Requisitos – Um Caso Comum
Mais um mês e meio...- Sr. Analista, nosso pessoal
analisou com cuidado o documento. Tivemos muitas dificuldades em entendê-lo. Mas o que percebemos é que NÃO FOMOS CORRETAMENTE ENTENDIDOS!!!
- Como não? Tudo que está aí foi fruto de nosso entendimento pessoal. REALMENTE VOCÊS NÃO SABEM O QUE QUEREM!!!
Revisões de Requisitos – Um Caso Comum
Clientes Satisfeitos
10/08/11
● Estão assim quando: Atende todas expectativas Entrega no prazo Entrega no orçamento
● Tudo começa com Requisitos
Definindo o Sucesso de Software
Especificação
Desenvolvimento
Validação
Versão Inicial
Vesão InicialVesão InicialVersões Intermediárias
Versão Final
DescriçãoAlto Nível
Prototipação
Prototipação – Vantagens
● Contribuem para melhorar a qualidade da especificação dos futuros programas● Leva à diminuição dos gastos com manutenção• O treinamento dos usuários pode ser feito antes do produto ficar pronto• Algumas partes do protótipo podem vir a ser usadas no desenvolvimento do sistema finalObs: comum em métodos ágeis!
• Em geral o grande argumento contra a construção de protótipos é o custo• A construção do protótipo atrasa o início daimplementação do sistema final• Atrasos são um dos maiores problemas dos projetos de software• Construir um protótipo pode não ser tão mais rápido do que construir o sistema final• Se os ambientes utilizados forem diferentes este custo será um custo extra
Prototipação – Desvantagens
● Verificação – conjunto de atividades que garante que o software implemente corretamente uma função específica Estamos construindo certo o produto?● Validação – refere-se a um conjunto de atividades que garante que o software foi construído de acordo com as exigências do cliente Estamos construindo o produto certo?
Verificação e Validação
Os programas possuem um grande número de estados com rotinas complexas, atividades e algoritmosO tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumenta ainda mais a complexidade
Falha de Software
● Dizer que um programa falhou significa que o seu funcionamento não está de acordo com o esperado● A falha pode ser originada por diversos motivos, como:
● A especificação pode estar errada ou incompleta● A especificação pode conter requisitos impossíveis de
serem implementados ● 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
Falha de Software
● Atividade de teste inicia-se no nível de módulos e prossegue “para fora” na direção da integração de todo o sistema baseado em computador● Diferentes técnicas de teste são apropriadas e diferentes pontos do tempo● Realizada pela equipe de desenvolvimento ou por um grupo de teste independente● Atividades de teste e de depuração são diferentes, a depuração deve ser acompanhada de uma estratégia de teste
Abordagem Estratégica ao Teste de Software
● Depois da integração os critérios de validação especificados na análise de requisitos devem ser testados● Garante exigências funcionais, comportamentais e de desempenho● Após a realização do teste: As características de função ou desempenho
conformam-se as especificações e são aceitas Se um desvio é descoberto e uma lista de
deficiências é criada
Estratégica ao Teste de Software
Modelo de TesteMétodo da Caixa Branca ● Método estrutural avalia o comportamento interno do componente de software para determinar defeitos na estrutura interna ou no código-fonte do software● Desenvolvido analisando-se o código-fonte e elaborando-se casos de teste que cubram todas as possibilidades do algoritmo implementado● Todas as variações originadas por estruturas de condições são testadas● São de responsabilidade dos desenvolvedores, já que estes têm conhecimento amplo do código-fonte● Recomendado para as fases de Teste de Unitário e de Integração
Método da Caixa Preta
● Tem por objetivo determinar se os requisitos foram total ou parcialmente satisfeitos pelo software● Verifica apenas os resultados produzidos e não requer conhecimento interno do sistema, apenas conhecimento dos requisitos do negócio● É aplicável a todas as fases de teste do processo de software● Devem ser desenvolvidos pelos membros da equipe que melhor conhecem os requisitos do sistema
Modelo de Teste
Estrutural (estamos construindo certo o produto?)Casos de teste concentrados na estrutura de controle, em nível de módulo de programa
Caixa Branca
Funcional (estamos construindo o produto certo?)Casos de teste concentrados nos requisitos
Caixa Preta
Modelo de Teste
● Atualmente, existem muitas maneiras de se testar um software:
● Teste de Unidade ou Unitário● Teste de Integração● Teste de Sistema● Teste de Aceitação● Teste de Recuperação● Teste de Segurança● Teste de Stress● Teste de Desempenho● Teste de Operação● Teste de Regressão
Estratégica ao Teste de Software
● Testar 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 pequenos trechos de código● O objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema
1. Teste Unitário
● Precedência aritmética incorreta● Inicialização incorreta● Erro de precisão● Representação simbólica incorreta de uma expressão● Variáveis de laço impropriamente modificadas
Teste Unitário – Erros Comuns
Casos de teste devem descobrir erros de fluxo de controle e comparações:● Comparação de diferentes tipos de dados● Operadores lógicos ou precedência incorreta● Expectativa de igualdade quando um erro de
precisão torna a igualdade improvável● Comparação ou variável incorreta● Término de laço impróprio ou inexistente● Variáveis de laço impropriamente modificadas
Teste Unitário – Erros Comuns
● Descrição do erro é inteligível● Erro apontado não corresponde ao erro encontrado● Condição de erro provoca intervenção no sistema
antes do tratamento do erro● Processamento das condições de exceção é incorreto● Descrição do erro não oferece nenhuma informação
que ajude na localização da causa do erro
Teste Unitário – Erros Comuns
2. Teste de Integração
Máxima: Se todos os módulos funcionam individualmente porque se tem dúvida de que eles funcionarão quando colocados juntos?
● Dados podem ser perdidos ao longo da interface● Um módulo pode ter um efeito inesperado● Funções quando combinadas podem não produzir a função principal esperada
● Integração big-bang o programa completo é testado como um todo● Integração incremental o programa é construído e testado em pequenos segmentos, os erros são mais fáceis de serem encontrados e corrigidos
Tipos de Teste de Integração
M1
M3
M7
M4M2
M5 M6
M8
● Os módulos são integrados movimentando-se de cima para baixo● módulos subordinados podem ser incorporados de uma maneira depth-first ou breadth-first
Teste de Integração – Top Down
M1
M3M2
Módulos são integradosmovimentando-se de baixo para cima
D1 D2
Cluster
Teste de Integração – Buttom Up
● Tipo de teste caixa preta cujo objetivo é testar todos os elementos do sistema de ponta a ponta● Normalmente realizado quando o software esta funcionando completamente
3. Teste de Sistema
● Verificar se elementos como hardware, pessoas, bancos de dados, ou outros estão adequados em função do desempenho global do sistema:
● Projetar casos de teste que simulem todas as entradas de dados de outros sistemas
● Realizar testes simulando dados ruins ou erros em potencial para a interface
● Registrar e documentar o caso de testes● Participar do planejamento para garantir que o
teste seja adequado
Teste de Sistema
4. Teste de Aceitação
● Teste conduzido por usuários finais do sistema● Simula operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado● 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
● Capacitam o cliente a validar todos os requisitos● Realizado pelo usuário final e não pelo desenvolvedor do sistema:
Teste Alfa – é levado a efeito por um cliente nas instalações do desenvolvedor. Erros e problemas serão registrados durante a interação
Teste Beta – é realizado nas instalações do cliente pelo usuário final. A interação não é controlada pelo desenvolvedor, problemas encontrados são relatados posteriormente ao desenvolvedor
Teste Gama – 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 usuários para que estes encontrem os defeitos já em fase de produção
Tipos de Teste de Aceitação
● Um processo altamente gerenciado e costuma ser uma extensão do teste do sistema ● Os testes são planejados e projetados com o mesmo cuidado e nível de detalhe do teste do sistema● Os casos de teste escolhidos devem ser um subconjunto dos que foram realizados no teste do sistema● É importante não se distanciar de nenhuma forma dos casos de teste escolhidos● Em muitas organizações, o teste de aceitação formal é totalmente automatizado
Teste de Aceitação Formal
● Funções e os recursos a serem testados são conhecidos● Detalhes dos testes são conhecidos e podem ser medidos● Testes podem ser automatizados, o que permite o teste de regressão● Progresso dos testes pode ser medido e monitorado● Critérios de aceitabilidade são conhecidos
Benefícios do Teste de Aceitação Formal
● Procedimentos para executar o teste não são definidos com tanto rigor como no teste de aceitação formal● Funções e as tarefas de negócios a serem exploradas são identificadas e documentadas, mas não há casos de teste específicos para seguir● Testador individual determina o que fazer● Essa abordagem de teste de aceitação não é tão controlada como o teste formal e é mais subjetiva do que o tipo formal
Teste de Aceitação Informal
● Funções e os recursos a serem testados são conhecidos● Progresso dos testes pode ser medido e monitorado● Critérios de aceitabilidade são conhecidos● Serão revelados defeitos mais subjetivos do que no teste de aceitação formal
Benefícios do Teste de Aceitação Informal
● Forçar o software a falhar de diversas maneiras ● Verificar se a recuperação é adequadamente executada● Verificar a robustez e também a capacidade de um determinado software● Retornar a um estado operacional após estar em um estado de falha
5. Teste de Recuperação
● Verificar se todos os mecanismos de proteção embutidos em um sistema, de fato, estão ativos
O papel do projetista do sistema é fazer com que o acesso custe mais do que o valor da informação que será obtida
6. Teste de Segurança
● Executar o sistema de forma a exigir recursos em quantidade, frequência e volume anormais
Exemplo: Casos de teste que exigem máxima memória
7. Teste de Stress
●Testar o desempenho de run-time do software dentro do contexto de um sistema integrado● Ocorre ao longo de todos os processos de teste, porém só quando todos os módulos estão interligados é que o desempenho real pode ser verificado
8. Teste de Desempenho
9. Teste de Operação
● Teste que é conduzido pelos administradores do ambiente final onde o sistema ou software entrará em ambiente produtivo● Aplicável somente a sistemas de informação próprios de uma organização● Nessa fase de teste devem ser feitas simulações para garantir que a entrada em produção do sistema será bem sucedida● Envolver os testes de instalação, simulações com backup e restauração das bases de dados, entre outros
10. Teste de Regressão
● 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
● Consistir em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema● Observar o impacto de alterações provocado pela nova versão ou ciclo de teste
Dúvidas? AgradecimentosDúvidas? Agradecimentos
Home PageHome Pagehttp://fernandoans.site50.nethttp://fernandoans.site50.net
BlogBloghttp://fernandoanselmo.blogspot.comhttp://fernandoanselmo.blogspot.com
X25 Home PageX25 Home Pagehttp://www.x25.com.brhttp://www.x25.com.br
Fernando AnselmoFernando [email protected]@x25.com.br