Módulo 8 · Engenharia de Software · Aula 1

Plano de ensino · Testes em aplicações de linguagem natural

Níveis de teste, construção do oráculo, especificação executável em Gherkin com demonstração em sala, detecção automática de falhas da própria automação, não repúdio e benchmarking de serviços de processamento de linguagem natural.

▶ Slides 📖 Material ← Voltar ao módulo

Sobre este encontro

Testes em aplicações de linguagem natural · 18/09/2026 · Prof. Afonso

Objetivo de aprendizagem

Ao final do encontro, o estudante deve ser capaz de especificar o plano de teste de uma aplicação cuja interação ocorre em linguagem natural, declarando oráculo, métrica e limiar de cada verificação, redigindo os cenários correspondentes em Gherkin com as cláusulas Dado, Quando e Então, distinguindo o que é automatizável do que exige inspeção humana, descrevendo como detectar automaticamente a falha da própria automação, verificando o não repúdio das ações executadas e comparando serviços candidatos por benchmarking baseado em testes.

Estratégia do encontro

Exposição dialogada em blocos curtos sobre a cadeia de processamento do enunciado, níveis de teste e construção do oráculo, seguida de demonstração de trinta minutos em que um requisito trazido por um dos grupos é convertido em cenário Gherkin e executado em sala, do arquivo de funcionalidade às definições de passo; os blocos seguintes tratam das falhas da própria automação e do não repúdio, e o encontro encerra com a produção dos cenários, do plano de teste dos requisitos não funcionais e da tabela de benchmarking dos serviços considerados.

Estrutura do encontro

  1. Daily: estado dos artefatos, atividade prevista e impedimentos — 15 min
  2. Abertura: situação-problema da residência automatizada e pergunta guia — 5 min
  3. O que testar: cadeia de processamento, falhas por etapa e níveis de teste — 12 min
  4. Automação e oráculo: precedência da automação e construção do critério de correção — 10 min
  5. Gherkin e demonstração em sala: Dado, Quando e Então, do requisito ao teste que executa — 30 min
  6. Falha da automação e não repúdio: mutação, contrato, trilha assinada e verificação pericial — 18 min
  7. Aplicação: cenários, plano de teste e tabela de benchmarking do projeto — 25 min
  8. Fechamento: síntese e encaminhamento dos autoestudos — 5 min

1. Identificação

ComponenteRegistro
MóduloMódulo 8 — Arquitetura digital segura e tolerante a falhas
CursoEngenharia de Software
EncontroAula 1 — Testes em aplicações de linguagem natural
Data e duração18/09/2026 · 120 minutos
DocenteAfonso Brandão
NaturezaExposição dialogada, demonstração de 30 minutos com especificação executável e aplicação em grupo sobre o projeto do parceiro
Artefatos do móduloPlano de teste dos requisitos não funcionais; arquivo de cenários em Gherkin; tabela de benchmarking dos serviços de processamento de linguagem natural

2. Objetivo de aprendizagem

Ao final do encontro, o estudante deve ser capaz de especificar o plano de teste de uma aplicação cuja interação ocorre em linguagem natural, declarando oráculo, métrica e limiar de cada verificação, redigindo os cenários correspondentes em Gherkin com as cláusulas Dado, Quando e Então, distinguindo o que é automatizável do que exige inspeção humana, descrevendo como detectar automaticamente a falha da própria automação, verificando o não repúdio das ações executadas e comparando serviços candidatos por benchmarking baseado em testes.

Resultados observáveis

  • Identificar as etapas da cadeia de processamento e o critério de correção de cada uma.
  • Alocar cada verificação ao nível de teste adequado, com justificativa.
  • Declarar o oráculo de um requisito por conjunto de referência ou por propriedade invariante.
  • Redigir um cenário em Gherkin com uma única cláusula Quando e resultado observável em Então.
  • Distinguir redação declarativa de redação imperativa em cenários de aceitação.
  • Converter um cenário em Esquema do Cenário alimentado pelo corpus anotado.
  • Converter atributo enunciado por adjetivo em especificação com valor, unidade e instrumento.
  • Identificar requisitos não funcionais do projeto de verificação manual inviável.
  • Descrever procedimentos de detecção automática de falha da suíte de testes.
  • Distinguir autenticação, integridade e não repúdio, e indicar os mecanismos que sustentam o terceiro.
  • Especificar casos de teste que verificam a reconstituição pericial de um comando contestado.
  • Organizar a comparação de serviços em tabela com critérios, pesos e procedimento de medição.
  • Rever pesos e limiares na hipótese de operação em ambiente crítico.

3. Produtos do encontro

Plano de teste

Três requisitos não funcionais do projeto especificados com valor, unidade, limiar, nível de teste, instrumento e oráculo declarado.

Cenários em Gherkin

Arquivo .feature com ao menos três cenários do projeto, incluindo um Esquema do Cenário alimentado pelo conjunto de referência.

Verificação do não repúdio

Casos de teste que reconstituem autor, enunciado, parâmetros e instante do comando de maior consequência do projeto.

Tabela de benchmarking

Comparação dos serviços candidatos por custo, desempenho, precisão e complexidade, com pesos justificados e decisão fundamentada.

Registro transversal

Os dois artefatos são versionados no repositório do grupo ao final do encontro. A tabela de benchmarking sem conjunto de casos, data de medição e versão dos serviços é considerada incompleta.

4. Preparação

Responsabilidade dos grupos

  • Ler as seções 4 a 17 do material antes do encontro.
  • Realizar o Autoestudo 1 (páginas 1 a 5 e 10 a 14 do artigo) e o Autoestudo 2 (Pressman, 372 a 387).
  • Levar a lista de requisitos não funcionais já acordados com o parceiro.
  • Levar a relação dos serviços de processamento de linguagem natural em consideração.
  • Levar amostra de enunciados reais ou plausíveis do domínio do parceiro.
  • Levar o repositório do projeto com a suíte de testes existente em condição de execução.
  • Definir quem redige o plano, quem executa a medição e quem registra a decisão.

Responsabilidade do docente

  • Confirmar a disponibilidade do vídeo da situação-problema e o funcionamento da projeção.
  • Preparar o exemplo de trilha de auditoria encadeada utilizado na demonstração.
  • Preparar o repositório da demonstração com o arcabouço de desenvolvimento guiado por comportamento instalado e a execução verificada.
  • Registrar previamente a saída esperada de cada passo da demonstração.
  • Preparar a tabela de benchmarking em branco para distribuição aos grupos.
  • Verificar se os grupos possuem credenciais de acesso aos serviços a comparar.
  • Registrar as lacunas identificadas nos planos para retomada na aula seguinte do módulo.

5. Cronograma

TempoBlocoConteúdo
15 minDailyEstado dos artefatos, atividade prevista para o encontro e impedimentos de cada grupo.
5 minAberturaSituação-problema da residência automatizada e enunciado da pergunta guia.
12 minO que testarCadeia de processamento, falhas por etapa e alocação das verificações por nível de teste.
10 minAutomação e oráculoPrecedência da automação, requisitos não funcionais de verificação manual inviável e construção do oráculo.
30 minGherkin e demonstraçãoEstrutura do arquivo de cenários, semântica de Dado, Quando e Então, redação declarativa e demonstração em sala do requisito ao teste que executa.
10 minFalha da automaçãoDefeitos da própria suíte, detecção por mutação e contrato, instrumentação em operação e impacto do erro não detectado.
8 minNão repúdioDefinição, mecanismos de trilha assinada e encadeada, e casos de verificação pericial.
25 minAplicaçãoProdução dos cenários em Gherkin, do plano de teste e da tabela de benchmarking, com acompanhamento por grupo.
5 minFechamentoSíntese das seis proposições e encaminhamento dos autoestudos.

6. Roteiro de condução

  1. Apresentar o caso da residência automatizada e solicitar que cada grupo aponte qual etapa da cadeia produziria o acionamento indevido descrito.
  2. Expor a cadeia de processamento e registrar no quadro, com a turma, o critério de correção de cada etapa.
  3. Solicitar que cada grupo classifique duas verificações do próprio projeto por nível de teste e apresentar as divergências.
  4. Expor a precedência da automação e conduzir o levantamento dos requisitos não funcionais inviáveis de verificar manualmente.
  5. Demonstrar a construção do oráculo com o exemplo do corpus anotado e das propriedades invariantes.
  6. Apresentar a estrutura do arquivo de cenários e a semântica de Dado, Quando e Então, contrastando redação imperativa e declarativa.
  7. Conduzir a demonstração de 30 minutos: converter em Funcionalidade um requisito enunciado por um grupo, redigir o primeiro cenário, executar com passos indefinidos, implementar as definições de passo, obter a reprovação por comportamento ausente, implementar o comportamento mínimo até a aprovação e converter o cenário em Esquema do Cenário com a tabela de Exemplos.
  8. Encerrar a demonstração removendo a cláusula Então de efeito e exibindo a aprovação indevida, o que introduz o bloco de falhas da automação.
  9. Apresentar a tabela de falhas da automação e solicitar que cada grupo identifique qual delas o próprio repositório apresenta.
  10. Demonstrar a trilha encadeada, alterar uma entrada e exibir a reprovação da verificação de integridade.
  11. Enunciar a atividade, distribuir a tabela em branco e acompanhar os grupos, verificando a declaração de oráculo em cada linha do plano.
  12. Solicitar a um grupo a apresentação da decisão de benchmarking e conduzir a arguição sobre a mudança de pesos em ambiente crítico.
  13. Fechar com a síntese e a indicação do autoestudo opcional sobre desenvolvimento dirigido por testes.

7. Metodologia

Exposição dialogada organizada por blocos curtos, cada um seguido de aplicação imediata ao projeto do grupo, demonstração de 30 minutos conduzida no projetor com o repositório aberto, e bloco final destinado à produção dos artefatos com acompanhamento do docente. A situação-problema é retomada ao final de cada bloco conceitual, o que mantém a exposição vinculada a um caso concreto e permite verificar o entendimento sem avaliação formal. A demonstração emprega um requisito trazido pelos próprios grupos, de modo que o percurso exibido seja transferível ao repositório de cada projeto.

8. Verificação da aprendizagem

CritérioEvidência esperadaIndício de insuficiência
Especificação do requisitoValor, unidade, condição de medição e limiar declarados.Atributo enunciado por adjetivo, sem instrumento de medição.
OráculoConjunto de referência versionado ou propriedade invariante asserida.Comparação literal com uma única resposta esperada.
Cenário em GherkinUm Quando por cenário, resultado observável em Então e vocabulário do domínio.Cenário que descreve cliques, seletores e chamadas de função.
Nível de testeVerificação alocada ao nível em que o defeito é isolável.Toda verificação prevista no nível de sistema.
Falha da automaçãoProcedimento declarado de verificação da capacidade de detecção da suíte.Cobertura de código apresentada como única evidência de qualidade.
Não repúdioCasos que reconstituem autor, enunciado, parâmetros e instante a partir da trilha.Registro em arquivo sem assinatura nem encadeamento.
BenchmarkingCritérios, pesos, corpus do domínio, data e versões registrados.Comparação apoiada em material de divulgação do fornecedor.

9. Recursos

  • Deck de slides do encontro e material de leitura publicados no acervo.
  • Projeção com áudio para a exibição do vídeo da situação-problema.
  • Repositório do projeto de cada grupo, com a suíte de testes existente.
  • Repositório da demonstração com arcabouço de desenvolvimento guiado por comportamento — Cucumber, behave, pytest-bdd ou SpecFlow — instalado e verificado.
  • Credenciais de acesso aos serviços de processamento de linguagem natural a comparar.
  • Artigo do Autoestudo 1 e acesso ao capítulo de Pressman pela biblioteca.
  • Modelo em branco da tabela de benchmarking.

10. Riscos e contingências

Grupos sem credenciais de acesso

A medição é substituída pelo desenho do experimento: os grupos especificam o procedimento, o corpus e os limiares, e executam a medição fora do encontro.

Ausência de requisitos não funcionais acordados

O grupo deriva três atributos a partir das metas de negócio declaradas no termo de abertura do projeto, seguindo a seção 14 do material.

Autoestudos não realizados

A exposição dos blocos de benchmarking e de testes de componentes é conduzida com o exemplo do material, e a leitura é reencaminhada como pendência registrada.

Atraso no bloco expositivo

O bloco de detecção em operação é reduzido à enumeração dos quatro mecanismos, preservando os 25 minutos de aplicação.

Falha do ambiente na demonstração

A demonstração prossegue sobre a saída de execução registrada na preparação, exibida passo a passo, e o ambiente é reconstituído fora do encontro.

11. Fechamento

O encontro encerra com a síntese das seis proposições e com o registro, por grupo, das lacunas identificadas no próprio plano de teste. As pendências são retomadas na verificação dos artefatos da sprint, e o autoestudo opcional sobre desenvolvimento dirigido por testes é indicado aos grupos cujo repositório não permite reconstituir os requisitos a partir dos testes existentes.

12. Referências

  • HAYAHI, S.; ARAKAKI, R.; RUGGIERO, W. Benchmarking baseado em testes, 2020. Documento do autoestudo.
  • PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. Páginas 372 a 387. Código na plataforma da biblioteca: 9786558040118.
  • Cucumber — documentação de referência da linguagem Gherkin e das definições de passo.
  • NORTH, D. Introducing BDD, 2006 — origem da formulação Dado, Quando, Então.
  • SMART, J. F. BDD in Action — especificação por exemplos e documentação viva.
  • ISO/IEC 25010 — modelo de qualidade de produto de software.
  • ISO/IEC/IEEE 29119 — processo, documentação e técnicas de teste de software.
  • ISO/IEC 27001 e 27002 — registro de eventos e proteção da trilha de auditoria.
  • BRASIL. Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais.
  • Smart House, Rema 1000 — referência audiovisual da Instrução 2. youtu.be/nwPtcqcqz00.