1657134
Beschreibung
Karteikarten von Raphael Luiz Fonseca, aktualisiert more than 1 year ago
|
Erstellt von Raphael Luiz Fonseca
vor etwa 10 Jahre
|
|
| Frage | Antworten |
| - Projetar uma série de testes com a máxima probabilidade de encontrar erros | Objetivo do Teste de SW |
| - Correção de erros encontrados na verificação ou na validação | Tipos de Manutenção do SW - Corretiva |
| - Adaptação e mudanças externas | Tipos de Manutenção do SW - Adaptativa |
| - Melhorias requeridas pelos usuários | Tipos de Manutenção do SW - Melhoria ( perspectiva ) |
| - Abordagem pró-ativa com foco na melhoria da manutibilidade | Tipos de Manutenção do SW - Preventiva ou de Reegenharia |
| - Causa de uma falha ( aspecto físico ) - Ex: código incorreto, defeito de hardware | FALTA |
| - Estado intermediário, de instabilidade ( aspecto informação ) - Pode resultar numa falha, se propagado até a saída | ERRO |
| - Incapacidade do software de realizar a função requisitada (aspecto externo). - Manifestação observável - Ex: terminação anormal, restrição temporal violada. | FALHA |
| - Refere-se ao conjunto de atividades que garante que o software implementa corretamente as funções especificadas. - "Estamos construindo o produto de forma correta?" - Inspeções ( Verificação Estática ) - Testes ( Verificação Dinâmica ) | Verificação |
| - Refere-se ao conjunto de atividades que garantem que o software construído implementa o que o cliente realmente desejava. - "Estamos construindo o produto certo?" - Homologação, Teste de Aceitação - Revisões | Validação |
| - Focada no processo - Orientada a prevenção - Ex: Metodologias, padrões - Garante que você está fazendo as coisas da maneira certa. | Garantia de Qualidade |
| - Focada no produto - Orientada a detecção - Ex: Checagem de requisitos, teste de software - Garante que os resultados do seu trabalho estão de acordo com o esperado. | Controle no Produto |
| - Análise Estática - Não checam RNF's - São abordagens formais para documentar as revisões do código - A intenção é a detecção de erros e não correção. | Inspeções do Programa ( Estático ) |
| - Checa a codificação de loops, código, inalcançável | Tipos de Inspeções Automatizadas - Análise de Controle de Fluxo |
| - Detecta variáveis não inicializadas, variáveis que nunca foram usadas. | Tipos de Inspeções Automatizadas - Análise de Dados |
| - Checa a consistência de declarações de rotinas e procedimentos e como são utilizados | Tipos de Inspeções Automatizadas - Análise de Interfaces |
| - Processo de executar um programa com o objetivo de encontrar erros. - Não garante que o software está livre de erros. | Teste ( Verificação Dinâmica ) |
| - Focado nas entradas e saídas especificadas nos requisitos funcionais - Baseado em prés e pós condições - Busca erros de comportamento e desempenho - Técnicas usadas: Testes baseados em grafos, matriz, análise de valores limítrofes, particionamento de equivalências | Abordagens de Testes - Caixa Preta/Funcional |
| - Focado nas estruturas internas - Análise de caminhos lógicos - Garantir que todos os caminhos independentes de um módulo sejam executados pelo menos uma vez - Executar todas as decisões lógicas - Todos os laços | Abordagens de Testes - Caixa Branca/Estrutural |
| - Meio termo, branca e preta - Alguns conhecimentos de ambas partes. | Abordagens de Testes - Caixa Cinza/Mista |
| - Toda aplicação é construída por "objetos" - Todos objetos são projetados em gráficos - Descobrir comportamentos inesperados | Teste baseado em grafos |
| - Baseada em dividir o domínio de entradas de um programa em classe de dados | Técnica Particionamento de Equivalências |
| - Os erros acontecem nos limites do domínio de entrada e não no "centro" - Os testes devem ser gerados considerando esse valores "limítrofes" | Técnica de Análise de Valores Limítrofes |
| - Onde calcula-se a complexidade lógica do software e utiliza essa medida como base para descobrir os caminhos básicos | Testes Caixa Branca - Caminho Básico |
| - Teste de laços, condicionais, etc | Testes Caixa Branca - Teste de Estruturas de Controle |
| - Fornece uma medida quantitativa da complexidade lógica de um programa | Testes Caixa Branca - Complexidade Ciclomática ( Métrica ) |
| - Primeiro nível de testes, onde componentes individuais são testados. - Ferramenta usada: JUnit | Estágios de Teste - Teste de Unidade |
| - Framework de código aberto - Testar códigos em JAVA | JUnit |
| - Integra e testa componentes de um sistema com o objetivo de encontrar problemas durante suas interações | Teste de Integração |
| - Desenvolve o esqueleto do sistema e o preenche com os componentes do sistema | Teste de Integração - Top-Down |
| - Integra os componentes de infraestrutura e depois adiciona componentes funcionais | Teste de Integração - Bottom-Up |
| - Demonstrar a conformidade com os requisitos de software - O ambiente utilizado deve ser o mais próximo do real | Teste de Aceitação ( Validação ) |
| - Testes conduzidos pelo cliente no ambiente do desenvolvedor - Ambiente controlado | Teste de Aceitação ( Validação ) - Alfa |
| - É conduzido em um ou mais locais do cliente, pelo usuário final do produto. - O usuário anota todos os problemas e depois envia para o desenvolvedor - Ambiente real | Teste de Aceitação ( Validação ) - Beta |
| - São conduzidos em um ambiente completo e integrado, por várias pessoas. | Teste de Sistema |
| - Visa a executar um subconjunto de testes que já foram executados com o intuito de garantir que as mudanças ocorridas não propagaram efeitos indesejados. | Tipos de Testes - Regressão |
| - Refere-se ao primeiro teste realizado depois de integrar os componentes | Tipos de Testes - Teste de Fumaça |
| - Força o software a falhar e verifica se a recuperação foi feita de forma adequada. | Tipos de Testes - Recuperação |
| - O testador visa penetrar no sistema de qualquer maneira - O objetivo do teste é assegurar que a tentativa de penetração custe mais caro que os ganhos que o hacker virá a ter. | Tipos de Testes - Segurança |
| - Confrontar os programas com situações anormais - "Até onde ele aguenta?" | Tipos de Testes - Carga/Estresse |
| - Pode ocorrer durante todos os estágios de testes - Visa garantir que o sistema atende aos níveis de desempenho e tempo de resposta acordamos nos requisitos | Tipos de Testes - Desempenho |
| - Avalia o sistema do ponto de vista do usuário final | Tipos de Testes - Usabilidade |
| - É o processo que resulta na remoção de um erro encontrado | Debugging |
| - Popula-se o sistema com escritas ao console para tentar encontrar erros. - É o métodos menos eficiente | Abordagens de Debugging - Força Bruta |
| - Começando a partir de onde o erro ocorreu, deve-se rastrear o código manualmente até a fonte do erro. | Abordagens de Debugging - Backtracking |
| - Uma "hipótese de causa" é elaborada e os dados relacionados ao erro são utilizados para prová-la | Abordagens de Debugging - Eliminação de Causa |
| - Define metas e objetivos de teste no escopo da iteração | Plano de Testes ( RUP ) |
| - Tem a finalidade de identificar e comunicara as condições específicas nas quais as funcionalidades serão testadas - Define um conjunto de entradas de teste, condições de execução e resultados esperados. | Caso de Teste |
| - Descrição do Caso de Teste - Pré-Condições - Entradas - Pontos de Observação - Pontos de Controle - Resultados Esperados - Pós-Condições | Estrutura do Caso de Teste |
| - (1) aplicações clientes individuais são testadas no modo “não conectado” e a operação do servidor e a rede subjacente não são consideradas; - (2) o software cliente e as aplicações do servidor associadas são testadas em conjunto, mas as operações da rede não são explicitamente exercitadas; - (3) a arquitetura completa cliente/servidor, incluindo operações e desempenho da rede, é testada. | Teste em Cliente/Servidor |
Möchten Sie mit GoConqr kostenlos Ihre eigenen Karteikarten erstellen? Mehr erfahren.