Syllabus CTFL Foundation Level

1. Fundamentos do Teste
1. 1.1 Porque é necessário testar?
2. 1.2 O que é teste?
3. 1.3 Os sete princípios do teste
  1. Princípio 1 – Teste demonstra a presença de defeitos
  2. Princípio 2 – Teste exaustivo é impossível
  3. Princípio 3 – Teste antecipado
  4. Princípio 4 – Agrupamento de defeitos
  5. Princípio 5 – Paradoxo do Pesticida
  6. Princípio 6 – Teste depende do contexto
  7. Princípio 7 – A ilusão da ausência de erros
4. 1.4 Fundamentos do processo de teste
5. 1.5 A psicologia do teste
2. Teste durante o ciclo de vida do software
3. Técnicas Estáticas
1. 3.1 Revisão e o Processo de Teste
  1. Teste estático não necessita da execução do software. Teste dinâmico é a execução do código.
  2. Revisão testa o produto do software (especificação, diagramas, código, casos de teste, etc), pode ser feito antes do teste dinâmico. Os benefícios são redução tempo do teste, menos defeitos, melhoria comunicação, etc.
  3. Revisões encontram defeitos. Testes dinâmicos encontram falhas.
2. 3.2 Processo de Revisão
  1. A forma como uma revisão é conduzida depende do seu objetivo, que pode ser encontrar defeitos, compreender, decidir ou tomar decisões. Podem ser formais ou informais.
  2. 3.2.1 Fases de uma revisão formal
    1. Planejamento
      1.  Definir os critérios de revisão.  Selecionar a equipe.  Alocar as funções.  Definir os critérios de entrada e de saída para os diversos tipos de revisão formal (ex.: inspeção).  Selecionar quais as partes dos documentos será visto.  Checar os critérios de entrada (para diversos tipos de revisão formal).
    2. Kick-off
      1.  Distribuir os documentos.  Explicar os objetivos, processos e documentos para os participantes.
    3. Preparação individual
      1.  Análise da documentação para a reunião de revisão.  Anotar os defeitos em potenciais, questões e comentários.
    4. Reunião de revisão
      1.  Discussão ou registro, com resultados documentados ou anotações (para os tipos de revisões mais formais).  Anotar os defeitos, fazer recomendações para o tratamento de defeitos ou tomar decisões sobre os defeitos.  Examinar, avaliar e registrar questões durante as reuniões de acompanhamento.
    5. Retrabalho
      1.  Resolver defeitos encontrados, tipicamente feitos pelo autor.  Registrar os status atuais dos defeitos (para revisões formais).
    6. Acompanhamento
      1.  Checar se os defeitos foram encaminhados.  Obter métricas.  Checar os critérios de saída (para tipos de revisões formais).
  3. 3.2.2 Papéis e responsabilidades
    1. Gerente
      1. toma decisão durante a realização da revisão, aloca tempo nos cronogramas de projeto e determina se o objetivo da revisão foi atingido
    2. Moderador
      1. a pessoa que lidera a revisão dos documentos, incluindo o planejamento da revisão, e o acompanhamento após a reunião. Se necessário, mediará entre os vários pontos de vista e é muitas vezes quem responderá pelo sucesso da revisão.
    3. Autor
      1. é a pessoa que escreveu ou que possui a responsabilidade pelos documentos que serão revisados.
    4. Revisores ou Inspetores
      1. indivíduos com conhecimento técnico ou de negócio, que identificam e descrevem os defeitos encontrados no produto em revisão. Podem ser escolhidos para representar diferentes funções e perspectivas no processo de revisão, e é parte integrante de qualquer reunião de revisão.
    5. Redator
      1. documenta todo o conteúdo da reunião, problemas e itens em aberto que foram identificados durante a reunião.
  4. 3.2.3 Tipos de revisão
    1. Revisão informal
      1.  A documentação é opcional.  Principal propósito: uma forma de obter algum benefício a um baixo custo.
    2. Acompanhamento
      1.  Reunião conduzida pelo autor.  Na prática pode variar de informal para muito formal.  Principal propósito: aprendizagem, obtenção de entendimento e encontrar defeitos.
    3. Revisões técnicas
      1.  Documentado, processo de detecção de defeito, inclui colegas especialistas ou técnicos.  Idealmente são conduzidas por um moderador treinado (que não seja o autor).  Elaboração de um relatório de revisão.  Principais propósitos: discussão, tomada de decisões, avaliar alternativas, encontrar defeitos, resolver problemas técnicos e checar a conformidade da padronização das especificações.
    4. Inspeção
      1.  Conduzida pelo moderador (que não seja o autor).  Papéis definidos.  Utilização de métricas.  Processo formal baseado em regras e utilização de check-list.  Relatório de inspeção, lista de defeitos encontrados.  Principal propósito: encontrar defeitos.
    5. Um único documento pode ser objeto para mais de uma revisão.
  5. 3.2.4 Fatores de sucesso para as revisões
    1.  Cada revisão tem um objetivo claramente definido.
    2.  A pessoa adequada para os objetivos da revisão deve ser envolvida.
    3.  Testadores são valorizados como revisores que contribuem para a revisão e aprendizado sobre o produto o que lhes permite preparar os testes facilmente.
    4.  Defeitos encontrados são encorajados e expressados objetivamente.
    5.  Técnicas de revisão são aplicadas de forma a combinar com o tipo e nível do software e revisores.
    6.  Caso necessário, check-lists ou papéis são utilizados para aumentar a eficiência na identificação de defeitos.
3. 3.3 Análise Estática por Ferramentas
  1. Análise estática pode localizar defeitos que são dificilmente encontrados em testes. Como as revisões, a análise estática encontra defeitos ao invés de falhas.
  2. Benefícios
    1.  Detecção de defeitos antes da execução do teste.  Conhecimento antecipado sobre aspectos suspeitos no código ou programa através de métricas, por exemplo, na obtenção de uma medida da alta complexidade.
    2.  Identificação de defeitos dificilmente encontrados por testes dinâmicos.  Detecção de dependências e inconsistências em modelos de software, como links perdidos.
    3.  Aprimoramento da manutenibilidade do código e construção.  Prevenção de defeitos, se as lições forem aprendidas pelo desenvolvimento.
  3. Defeitos mais comuns descobertos
    1.  Referência a uma variável com valor indefinido.  Inconsistências entre as interfaces dos módulos e componentes.
    2.  Variáveis que nunca são usadas ou impropriamente declaradas.  Código morto.
    3.  Falta de lógica ou lógica errada (loops infinitos).  Construções excessivamente complicadas.
    4.  Violação de padrões de programação.  Vulnerabilidade na segurança.  Violação de sintaxe e de modelos.
  4. Ferramentas de análise estática analisam o código do programa, gerando arquivos do tipo HTML e XML, por exemplo.
  5. Ferramentas de análises estáticas são tipicamente usadas por desenvolvedores antes e durante o teste de componente e de integração e por projetistas durante a modelagem do software.
4. Técnica de Modelagem de Teste
1. 4.1 Identificando as condições de testes e projetando os casos de testes
  1. Durante a análise de teste
    1. a documentação é analisada para determinar o que testar, essas condições de teste são definidas como um item ou evento que pode ser verificado por um ou mai casos de teste
    2. estabelecer a rastreabilidade das condições de testes na volta até as especificações e requisitos permitem analisar o impacto quando os requisitos mudam
  2. Durante a modelagem de teste
    1. os casos de teste e os dados de teste são especificados e criados
    2. um caso de teste consiste de um conjunto de valores de entrada, pré-condições de execução, resultados esperados e pós-condições de execução, desenvolvidos para cobrir certas condições de teste
  3. Durante a implementação do teste
    1. os casos de teste são desenvolvidos, implementados, priorizadas e organizadas na especificação de procedimento de teste
    2. O procedimento de teste especifica a sequência de ações para a uma execução de teste
2. 4.2 Categorias das técnicas de modelagem de teste
  1. O propósito da técnica de modelagem de teste é identificar as condições e os casos de testes
  2. Classificar testes como caixa-preta ou caixa-branca é uma diferenciação clássica
  3. Técnicas Caixa-Preta
    1. técnicas baseadas em especificação
    2. são uma forma de derivar e selecionar as condições e casos de testes baseados na análise da documentação
      1. isto inclui testes funcionais e não funcionais, para um componente ou sistema sem levar em consideração a sua estrutura interna
  4. Técnicas Caixa-Branca
    1. técnicas estruturais ou baseadas em estrutura
    2. são baseadas na estrutura interna de um componente ou sistema.
3. 4.3 Técnicas baseadas em especificação ou Caixa-Preta
  1. 4.3.1 Partição de Equivalência
    1. as entradas do software ou sistema são divididas em grupos que tenham um comportamento similar, podendo ser tratados da mesma forma
  2. 4.3.2 Análise do Valor Limite
  3. 4.3.3 Tabela de Decisão
  4. 4.3.4 Teste de transição de estados
  5. 4.3.5 Teste de Caso de Uso
4. 4.4 Técnicas baseadas em estrutura ou Caixa-Branca
  1. 4.4.1 Teste e Cobertura de Sentença
  2. 4.4.2 Teste e Cobertura de Decisão
  3. 4.4.3 Outras técnicas baseadas na estrutura
5. 4.5 Técnicas baseadas na experiência
6. 4.6 Escolhendo as técnicas de teste
5. Gerenciamento de Teste

Siguiente

Syllabus CTFL Foundation Level

Descripción

Resumen del Recurso

Similar

	Creado por Juliete Rios hace casi 7 años