Encontro expositivo e aplicado · 18/09/2026
O que testar e como testar uma aplicação cuja interação com o usuário se dá em linguagem natural, quando a entrada é aberta, a saída não é determinística e o resultado precisa ser auditável.
Ritual do projeto
Cada grupo informa o avanço dos artefatos, a atividade prevista para o encontro e os impedimentos que exigem decisão.
Exposição em blocos curtos, demonstração de trinta minutos de especificação executável em Gherkin e vinte e cinco minutos de aplicação ao projeto.
O vídeo apresentado na Instrução 2 é retomado como caso de referência do encontro.
Uma residência é operada por assistente de voz integrado a iluminação, climatização, fechaduras e compras em comércio eletrônico. O sistema reconhece o enunciado, infere a intenção, extrai os parâmetros e aciona o dispositivo ou a transação correspondente. Em operação, registram-se acionamentos divergentes do que o morador declara ter solicitado: compras confirmadas sem pedido reconhecido pelo usuário, comandos disparados por conversa ambiente e ordens executadas com parâmetro distinto do enunciado.
Vocabulário irrestrito, sotaque, ruído, sobreposição de vozes e frases incompletas. O conjunto de entradas possíveis não é enumerável.
Modelos estatísticos produzem saídas distintas para entradas equivalentes, e a mesma entrada pode produzir resultados diferentes entre versões do serviço.
O acionamento incorreto abre fechadura, altera temperatura, emite pedido de compra e gera obrigação financeira.
Referência audiovisual da Instrução 2 — Smart House, Rema 1000: youtu.be/nwPtcqcqz00
O que testar e como testar uma aplicação cuja interação é em linguagem natural.
A especificação por casos de uso não cobre o espaço de enunciados. O teste passa a operar sobre classes de entrada e sobre propriedades que devem valer para todas elas.
Formulações distintas podem ser corretas. A comparação literal com uma resposta esperada reprova saídas válidas e aprova saídas erradas de igual redação.
Entende-se por oráculo o critério que decide se a saída observada está correta. Sem oráculo definido, não existe teste, apenas execução.
A interação em linguagem natural é uma cadeia de etapas. Cada etapa tem entrada, saída e critério de correção próprios, e falha de modo distinto.
Cada pergunta é respondida no nível em que o defeito é isolável com menor custo. O nível errado produz teste lento, instável e de diagnóstico impreciso.
Entende-se por teste automatizado o programa que exercita outro programa, compara o resultado observado com o critério declarado e reprova a execução quando há divergência.
Verificações repetitivas, numerosas, sensíveis a regressão e dependentes de medição precisa são automatizadas antes de qualquer inspeção humana. A pessoa examina o que exige julgamento: adequação da resposta, clareza da desambiguação e aceitabilidade do comportamento no domínio.
A execução automatizada roda a cada alteração do repositório; a inspeção manual ocorre uma vez por entrega.
O componente é a menor unidade com interface declarada e responsabilidade própria. Testá-lo isoladamente localiza o defeito no ponto em que foi introduzido.
Quando não existe saída única esperada, o critério de correção é construído por conjunto de referência, por propriedade invariante ou por comparação com implementação alternativa.
Enunciados coletados no domínio, rotulados com intenção e parâmetros corretos. Fornece acurácia, precisão, revocação e medida F1 por intenção.
Exige versionamento e revisão periódica, sob pena de medir o passado.
Regras que devem valer independentemente da formulação: intenção abaixo do limiar de confiança exige confirmação; comando financeiro exige parâmetro explícito; execução repetida do mesmo identificador não duplica o efeito.
Execução do mesmo conjunto em dois serviços ou em duas versões, com investigação das divergências. Fundamenta o benchmarking tratado no Autoestudo 1.
Gherkin é a linguagem estruturada em que o critério de aceitação é redigido em texto legível pelo parceiro e, ao mesmo tempo, executado como teste.
Funcionalidade — o comportamento sob especificação.Regra — a norma de negócio que agrupa cenários.Contexto — pré-condições comuns a todos os cenários.Cenário — um caso concreto do comportamento.Esquema do Cenário com Exemplos — o mesmo cenário sobre uma tabela de dados.Dado, Quando, Então, E, Mas — as cláusulas de cada passo.@ — seleção de subconjuntos na execução.O cenário declara o oráculo no vocabulário do domínio, sem referência à implementação, e por isso permanece válido quando o serviço de processamento de linguagem natural é substituído.
A tabela de Exemplos recebe o corpus anotado: cada linha do conjunto de referência passa a ser um caso executado.
O arquivo atende às três dimensões do Autoestudo 3: especifica o comportamento, afere a conformidade a cada execução e vincula requisito, teste e código.
.feature permanece legível; a definição de passo concentra a chamada ao sistema.As três cláusulas repartem o cenário em estado anterior, evento único e resultado observável. A troca de função entre elas é a origem da maior parte dos cenários inúteis.
| Cláusula | O que declara | Exemplo do caso | Erro recorrente |
|---|---|---|---|
| Dado Given | Estado do mundo anterior à ação, posto sem descrever interação do usuário. | O limiar de confiança para execução direta é 0,85. | Descrever a ação do usuário como pré-condição. |
| Quando When | O evento único cujo efeito se quer verificar. | O usuário enuncia “compra mais leite”. | Mais de um Quando no mesmo cenário. |
| Então Then | Resultado observável na fronteira do sistema. | O sistema solicita confirmação explícita. | Verificar estado interno ou registro do banco. |
| E · Mas | Continuação da cláusula imediatamente anterior. | E nenhum pedido é emitido ao comércio eletrônico. | Alternar de cláusula sem retomar a palavra-chave. |
“Quando o usuário abre o aplicativo, toca no botão do microfone, aguarda dois segundos e fala.” O cenário passa a depender da interface e é reescrito a cada alteração de tela.
“Quando o usuário enuncia ‘compra mais leite’.” O cenário permanece válido sob qualquer interface e é compreendido pelo parceiro sem tradução.
Especificação da confirmação de comando de compra e do descarte de enunciados captados do ambiente, escrita em português com a diretiva de idioma.
# language: pt
Funcionalidade: Confirmação de comando de compra por voz
Contexto:
Dado que o assistente está ativo na cozinha
E que o limiar de confiança para execução direta é 0,85
Cenário: Intenção reconhecida com confiança insuficiente
Dado que o serviço reconhece a intenção "comprar_item" com confiança 0,62
Quando o usuário enuncia "compra mais leite"
Então o sistema solicita confirmação explícita
E nenhum pedido é emitido ao comércio eletrônico
E a interação é registrada na trilha de auditoria
Esquema do Cenário: Enunciado captado do ambiente
Quando o sistema processa "<enunciado>" sem palavra de ativação
Então nenhum comando é executado
E o evento é registrado como descartado
Exemplos:
| enunciado |
| acho que acabou o leite |
| ela mandou comprar pilhas ontem |Então, e a tabela de Exemplos recebe as linhas do corpus anotado.Percurso completo de um requisito do projeto até o teste que executa, conduzido no projetor com o repositório aberto.
Um grupo enuncia em prosa um requisito do próprio projeto; o enunciado é convertido em Funcionalidade e Contexto.
Redação de Dado, Quando e Então. A execução acusa passos indefinidos e imprime os esqueletos das definições.
Implementação das definições com chamada ao sistema. A execução reprova por comportamento ausente, com a mensagem de asserção exibida.
Implementação da regra de confirmação sob baixa confiança até a aprovação do cenário.
Conversão em Esquema do Cenário com a tabela de Exemplos alimentada por linhas do conjunto de referência.
Remoção deliberada da cláusula Então de efeito: a suíte aprova o comportamento incorreto, o que retoma a seção seguinte.
A suíte automatizada é software e contém defeitos. O defeito mais grave é o que produz aprovação indevida, pois suprime o sinal de erro em vez de emiti-lo.
| Falha | Manifestação | Detecção automática |
|---|---|---|
| Asserção ausente | O teste executa o percurso e não verifica o resultado; aprova qualquer saída. | Teste de mutação: defeitos injetados no código devem reprovar a suíte. |
| Duplo permissivo | O substituto do serviço externo devolve sempre resposta válida e esconde o tratamento de erro. | Teste de contrato contra o serviço real e injeção de falha e de tempo limite. |
| Oráculo obsoleto | O conjunto de referência não representa mais o vocabulário em uso; a métrica permanece alta em campo degradado. | Amostragem periódica de tráfego real e comparação com a distribuição do conjunto. |
| Teste instável | Resultado alterna entre aprovação e reprovação sem alteração do código; a equipe passa a reexecutar até passar. | Reexecução programada da suíte sem alteração e registro do índice de instabilidade. |
| Cobertura inerte | Linhas executadas sem verificação de comportamento; a métrica de cobertura sobe sem ganho de detecção. | Cobertura de decisão combinada ao escore de mutação. |
Parte dos defeitos de uma aplicação de linguagem natural só se manifesta com entrada real. A detecção depende de instrumentação declarada em projeto.
Regras verificadas a cada requisição: confiança mínima, parâmetro obrigatório presente, identificador de operação único.
Distribuição de confiança, proporção de desambiguação, taxa de cancelamento pelo usuário e latência, com limiar de alarme.
Nova versão exposta a fração do tráfego, com comparação de métricas e retorno automático quando o limiar é violado.
Enunciados registrados são reexecutados sobre a versão candidata, o que transforma incidente em caso de teste permanente.
Entende-se por não repúdio a propriedade que impede o autor de uma ação de negar validamente tê-la praticado, por existir evidência verificável por terceiro.
Estabelece a identidade no momento do acesso. Isoladamente, não sustenta prova posterior sobre um comando específico.
Garante que o registro permanece como foi gravado. Sem vínculo com o autor, não atribui a ação a ninguém.
Vincula autor, ação, parâmetros e instante em registro íntegro, verificável por quem não participou da operação.
O não repúdio de uma interação em linguagem natural exige que a cadeia entre o enunciado e o efeito permaneça reconstituível.
A propriedade é verificada por procedimento automatizado que simula a contestação e tenta produzir o resultado que ela deveria impedir.
A reconstituição é considerada suficiente quando um terceiro, sem acesso privilegiado ao sistema, consegue estabelecer que determinado usuário emitiu determinado enunciado em determinado instante e que o comando executado corresponde ao enunciado registrado.
O ensaio pericial é conduzido por pessoa que não participou do desenvolvimento, com o mesmo procedimento que seria empregado em contestação real.
HAYAHI; ARAKAKI; RUGGIERO (2020). Páginas 1 a 3: como avaliar uma solução computacional sem depender do discurso do fornecedor.
A alegação do fornecedor descreve o comportamento do produto em condições que ele escolheu. A decisão técnica exige medição conduzida pelo comprador, no contexto de uso previsto, com procedimento reproduzível.
Entende-se por benchmarking o experimento comparativo que submete alternativas ao mesmo conjunto de casos, sob as mesmas condições, com métricas declaradas antes da execução.
Artigo do autoestudo: acesso ao documento
Página 5 do artigo. O atributo é extraído de três fontes e convertido em especificação mensurável.
Funções expostas ao usuário e condições de execução: comando por voz em ambiente doméstico, operação contínua, resposta imediata.
Propriedades do ambiente: ruído, sotaque regional, vocabulário técnico, intermitência de rede, presença de terceiros.
Resultado esperado pela organização: redução do custo de atendimento, retenção do cliente, obrigação regulatória, prazo contratual.
| Enunciado inadequado | Especificação técnica correspondente | Instrumento de medição |
|---|---|---|
| “Precisa ser rápido” | Latência de resposta no percentil 95 igual ou inferior a 800 ms com 50 sessões concorrentes. | Ensaio de carga com carga sintética e registro de distribuição. |
| “Precisa ser preciso” | Acurácia de intenção igual ou superior a 0,92 e medida F1 de extração de parâmetros igual ou superior a 0,88. | Execução sobre corpus anotado versionado do domínio. |
| “Precisa ser barato” | Custo por transação igual ou inferior a R$ 0,012 no volume mensal projetado. | Contagem de transações e tabela de preço do fornecedor. |
Páginas 10 a 14 do artigo. A comparação entre fornecedores é organizada em tabela com critérios homogêneos e pesos declarados antes da medição.
| Critério | Peso | Métrica e instrumento | Observação para a decisão |
|---|---|---|---|
| Custo | R$/transação | Preço por requisição no volume projetado, incluindo tarifa mínima e excedente. | Verificar o degrau de preço por faixa e o custo de reprocessamento. |
| Desempenho | ms | Latência média e percentil 95 sob concorrência, medida a partir da região de uso. | Separar o tempo do serviço do tempo de rede e de fila interna. |
| Precisão | 0–1 | Acurácia de intenção e medida F1 de parâmetros sobre o mesmo corpus anotado. | O corpus decide a comparação; conjunto genérico mede outro problema. |
| Complexidade | porte | Esforço de integração, dependências operacionais e conhecimento exigido da equipe. | Considerar retenção de dados, região de processamento e dependência do fornecedor. |
Pergunta do autoestudo: a escolha seria a mesma em uma mina de extração mineral, com equipamentos, pessoas e ruído intenso.
Avaliação do desenvolvimento dirigido por testes aplicado ao módulo de processamento de linguagem natural, em três dimensões.
O caso de teste enuncia, em forma executável, o que o componente deve fazer. A especificação permanece consistente com o código porque a divergência reprova a execução.
A suíte informa, a cada alteração, a proporção de requisitos verificados, a cobertura alcançada e a regressão introduzida.
A identificação do requisito no caso de teste e na mensagem de commit estabelece o percurso entre a exigência acordada, a verificação e a alteração que a implementou.
Quarenta e cinco minutos em grupo, com entrega registrada no repositório do projeto ao final da aula.
Seis proposições para a verificação da solução do parceiro.
A interação em linguagem natural é verificável quando o critério de correção, a evidência aceita e o procedimento de medição são declarados antes da implementação.
Sem métrica, limiar e conjunto de referência, a execução não constitui teste. O cenário em Gherkin registra esse critério em forma executável.
O que é repetitivo, numeroso e sensível a regressão é verificado por programa; a pessoa examina o que exige julgamento.
O defeito é isolado no nível de componente; o nível de sistema confirma o percurso completo.
Mutação, contrato e injeção de falha verificam a capacidade de detecção da própria automação.
O não repúdio exige trilha assinada, encadeada e verificável por terceiro.
A escolha do serviço decorre de experimento comparativo reproduzível, com pesos derivados da consequência do erro.
Leituras do encontro e fontes para a atividade.
Acesso ao livro de Pressman pela plataforma da biblioteca, código 9786558040118. Artigo do Autoestudo 1: documento no Drive.
Testes em aplicações de linguagem natural · 18/09/2026 · Prof. Afonso
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.
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.