Please enable JavaScript.
Coggle requires JavaScript to display documents.
Resumo - EC206 (Cap. 5 - Estratégias de teste de software (Estratégia de…
Resumo - EC206
Cap. 5 - Estratégias de teste de software
Quando um software não é bem testado, suas falhas podem passar para a distribuição e serem detectadas e/ou exploradas por usuários
Teste é o processo de exercitar um programa com o intuito específico de encontrar problemas antes que seja entregue para o usuário final, sendo a atividade que requer mais esforço do que qualquer outra da engenharia de software
Estratégia de teste
Planejamento do teste
Projeto dos casos de teste
Execução dos testes
Coleta e avaliação dos dados
Grupo de garantia da qualidade - SQA
Verificação
Garante que o software implemente uma função específica corretamente
Validação
Garante que o software atende aos requisitos do cliente
No processo de teste de software o deslocamento é de dentro para fora, começando nos componentes e seguindo em direção ao sistema
Software convencional
Do módulo para integração
Teste unitário
Foco dentro dos limites do componente, aplicando casos de teste e analisando resultados
Teste de integração
Estratégia bigbang
Tudo integrado de uma só vez, deve ser evitada pois dificulta o isolamento de causas
Estratégia top-down
Módulos testados com Driver e pseudocontrolados
Estratégia bottom-up
Módulos testados com pseudocontroladores e então agrupados em builds e integrados
Estratégia sanduíche
Top-down + bottom -up
Teste de sistema
Teste fumaça
Automatizado que roda periodicamente ou sob demanda
Software OO
A unidade passa a ser uma classe, seguindo à comunicação e colaboração com outras
No processo de software, o deslocamento é de fora para dentro, de alto para baixo nível, tornando-se mais específico
Qual estratégia utilizar
Executar os testes somente com o sistema completo, visando encontrar erros
Não funciona
Executar testes diariamente, sempre que uma parte do sistema for construida
Eficaz, mas não muito usada
Abordagem mista, sendo uma visão incremental dos testes
Cap. 2 - Métricas de Processo e Projeto
Assim como as métricas de produto, são quantitativas para se determinar a eficácia do processo de software e dos projetos executados nesse processo. Sua análise depende de histórico.
Métricas de processo
Usadas para fins estratégicos, visam a melhoria contínua do processo e devem ser coletadas em todos os projetos, por longos períodos.
Podem ser públicas ou privadas
Privadas devem servir apenas como indicador individual, como forma de motivação. Ex.: taxa de defeito por pessoa
Públicas são coletadas para avaliação de desempenho do time e do processo organizacional. Ex.: quantidade de bugs
Métricas de projeto
Usadas para fins táticos, minimizando o cronograma para evitar atrasos e avaliando a qualidade do produto de forma contínua.
Permitem ao gerente
Avaliar o estado do projeto
Rastrear os riscos
Agir de forma preventiva
Ajustar o fluxo das tarefas
Aferir a qualidade do resultado
Medidas de software
Podem ser diretas ou indiretas
Diretas são mais fáceis de medir. Ex.: esforço, custo, LOC, erros, defeitos
Indiretas são mais difíceis de medir. Ex.: funcionalidade, qualidade, complexidade, eficiência
Métricas de diferentes projetos só podem ser combinadas através da normalização
Métricas orientadas a tamanho
Podem ser criadas a partir de registros simples normalizando-se as medidas de qualidade e/ou produtividade relacionadas ao tamanho do software
Métricas orientadas a função
Usam uma medida da funcionalidade fornecida pela aplicação como um valor de normalização. Pode-se utilizar PF ou LOC, dependendo da linguagem de programação usada.
Métricas orientadas a objeto
´Número de scripts de cenário
Número de classes-chave, classes de apoio e média de CA para cada CC
Número de subsistemas
Métricas orientadas a casos de uso
Sua aplicação é suspeita, pois ainda não existe uma média padronizada do que é um caso de uso
Métricas de projeto WebApp
Grau de personalização para WebApp
C = Ndp / [Ndp + Nsp]
Varia de 0 a 1, sendo que quanto maior C, mais o nível de personalização se torna um aspecto técnico
Métricas para qualidade de software
Abordagem expandida de erro e defeito de Pressman
Falha acontece no teste do software executável, caso os defeitos não tenham sido corrigidos
Erros acontecem durante o desenvolvimento, quando um desenvolvedor não corrige o problema que criou
Defeito acontece quando um erro de um desenvolvedor gera problemas para outro
Bugs são falhas que não foram identificadas e/ou corrigidas antes do software ser entregue ao cliente
Medição de qualidade
Corretude
Grau com o qual o software executa sua função
Manutenibilidade
Facilidade com que o programa pode ser corrigido
Integridade
Habilidade de um sistema em resistir aos ataques à sua segurança
Usabilidade
Quantificação da facilidade de uso de um software
Eficiência na remoção de defeitos
DRE = E / E + D
Integrando métricas dentro do processo de software
Os benefícios das medidas são tão atraentes que compensam o trabalho duro de implementá-las na organização
O estabelecimento de uma baseline para métricas permite que projetos passados sejam usados como referência para projetos correntes ou futuros
Dados devem ser coletados em todas as fases de um software, para poder calcular as métricas e então obter indicadores
Cap. 1 - Métricas de Produto
Estrutura
Métrica
Indicador
Medição
Coleção
Análise
Interpretação
Feedback
Formulação
Para modelo de requisitos
Pontos de Função
Derivados de relação empírica sobre medidas de contagem do domínio de informação do software e sua complexidade.
Qualidade de especificação
Métrica que avalia a interpretação de cada requisito pelos revisores. Quanto mais próximo de 1, menos ambíguas as interpretações.
Para modelo de projeto
Arquitetural
Complexidade estrutural
Calculada sobre a quantidade de módulos no sistema
S(i) = E[Fout(i)^2]
Complexidade de dados
Complexidade interna de um módulo
D(i) = V(i) / [Fout(i) + 1]
Complexidade do sistema
Quanto maior a complexidade do sistema, haverá mais trabalho de integração e teste.
C(i) = S(i) + D(i)
Orientado a Objeto
Extensão da árvore de herança
Número de filhas
Acoplamento entre objetos de classes
Número de colaborações listadas para uma classe
Resposta para uma classe
Conjunto de métodos que podem potencialmente ser executados em resposta a uma mensagem recebida por um objeto daquela classe
Falta de coesão em métodos
Tamanho da classe
Número total de operações que são encapsuladas dentro da classe
WebApps
Interface
Estética
Conteúdo
Navegação
Para teste Orientado a Objeto
Falta de coesão em métodos
Porcentagem pública e protegida
Acesso público a membros de dados
Número de classes raiz
Fan-in
Indicação de herança múltipla
Número de filhos e altura da árvore de herança
Métodos de superclasse terão de ser retestados para cada subclasse
Para manutenção
Índice de maturidade de software
SMI = [Mt - (Fa + Fc + Fd)] / Mt
Quando se aproxima de 1, o produto começa a estabilizar
Cap. 3 - Projeto da Arquitetura
Concentra-se na representação dos componentes de software, suas propriedades e interações.
É uma representação que permite ao engenheiro de software analisar a efetividade do projeto quanto à aderência a seus requisitos, reduzir os riscos associados à construção e considerar alternativas em um estágio que seja fácil.
Gêneros de arquitetura
O gênero normalmente ditará a abordagem de arquitetura específica para a estrutura que deve ser construída, sendo uma categoria específica no domínio de software geral
Estilos de arquitetura
É um mecanismo descritivo que evoca uma imagem geral do projeto e serve como um template da construção
Cada estilo descreve uma categoria de sistema que engloba
Um conjunto de componentes
Um conjunto de conectores
Restrições
Modelos semânticos
Centrada em dados
Repositório central é acessado pelo software-cliente
Centrada em fluxo de dados
Estrutura de tubos e filtros, com características de comandos
Centrada em chamadas e retornos
Programa principal e subprograma, com características hierárquicas
Centrada em Orientação a objetos
Depende da associação de suas classes, que se comunicam por troca de mensagens
Centrada em camadas
Várias camadas realizando operações de níveis diferentes, da IU à interface com o SO. Características de SO
Projeto da arquitetura
Diagrama de contexto
Define as entidades externas com as quais o software interage, a partir da engenharia de requisitos
Estrutura
Sistemas superiores
Usam o sistema-fonte como parte de algum esquema de processamento de mais alto nível
Sistemas subordinados
Fornecem dados ou processamento para completar a funcionalidade do sistema-alvo
Sistemas pares
Informações produzidas ou consumidas pelos pares e sistema-alvo
Atores
Entidades que produzem ou consomem informações do sistema-alvo
Identificação dos arquétipos
Classe ou padrão que representa uma abstração central crítica para o projeto de uma arquitetura para o sistema-alvo
Refinamento da arquitetura
À medida que a arquitetura é refinada em componentes, a estrutura do sistema fica visível
Descrição das instâncias
Nesse ponto o contexto já foi representado, os arquétipos definidos, a estrutura global do sistema está evidente e os principais componentes foram identificados
É desenvolvida uma instância real da arquitetura, para demonstrar que é apropriada
Cap. 4 - Projeto de interface de usuário
Interfaces podem ser entre
Componentes de um software
Software e outros produtores e consumidores de informação
Ser humano e computador
Precisa ser fácil de usar, entender e aprender, e não ser frustrante
Envolve conhecimento das pessoas e de tecnologias
Erros típicos
Sem guia/ajuda
Falta de consistência
Memorização muito elevada
Sem sensibilidade a conteúdo
Resposta pobre
Arcaico/não amigável
O estudo das versões do Windows mostra que qualquer empresa, por maior e mais poderosa que seja, pode perder sua hegemonia se continuar insistindo em não obedecer as regras de ouro para a IU
Coloque o usuário no controle
Meios de interação, sem detalhes
Reduza a carga de memória recente do usuário
Metáforas do mundo real, defaults significativos, etc.
Torne a interface consistente
Contexto signifiactivo, atenda a expectativa
Modelos de projeto de IU
Modelo de usuário
Um perfil de todos os usuários finais do sistema
Modelo de projeto
A realização do projeto do modelo de usuário
Modelo mental
Imagem mental do usuário de como é a IU
Modelo de implementação
Aparência da IU combinada com a informação de suporte, descrevendo sua sintaxe e semântica
Gap mental é a diferença entre o modelo de implementação e o modelo mental