Testes em aplicações de linguagem natural

1. Como ler este material

O texto antecede o encontro. A segunda metade da aula é destinada à produção de dois artefatos do projeto: o plano de teste dos requisitos não funcionais e a tabela de benchmarking dos serviços de processamento de linguagem natural considerados. A leitura prévia das seções 4 a 17 é o que torna essa produção viável no tempo disponível.

As seções 15 a 17 correspondem ao Autoestudo 1; a seção 7 corresponde ao Autoestudo 2; a seção 18 corresponde ao Autoestudo 3, de realização opcional. As seções 9 e 10 tratam da linguagem Gherkin e da demonstração conduzida em sala. As demais consolidam a exposição do encontro.

2. O problema central

A pergunta que organiza o encontro é a seguinte: o que testar e como testar uma aplicação cuja interação com o usuário se dá em linguagem natural.

Em uma aplicação convencional, a entrada é um formulário com campos tipados e domínio conhecido, e a saída esperada é única. O teste compara o resultado observado com o resultado previsto. Em uma aplicação operada por enunciados, três propriedades dessa situação desaparecem.

A primeira é a enumerabilidade da entrada. O conjunto de frases que um usuário pode proferir não é finito nem previsível, e a especificação por casos de uso cobre apenas uma fração dele. A segunda é a unicidade da saída correta: formulações distintas podem ser igualmente adequadas, de modo que a comparação literal reprova respostas válidas e aprova respostas inadequadas que coincidam com o texto esperado. A terceira é a estabilidade: modelos estatísticos produzem resultados distintos entre versões, e a mesma entrada pode gerar saídas diferentes ao longo do tempo.

A consequência para a engenharia é a seguinte: a especificação do requisito precisa declarar, antes da implementação, qual evidência será aceita como prova de conformidade — métrica, limiar, conjunto de referência e procedimento de medição.

3. A cadeia de processamento

A interação em linguagem natural não é uma operação única. Constitui uma cadeia de etapas, cada uma com entrada, saída e critério de correção próprios. Testar a cadeia inteira sem testar suas etapas produz reprovação sem diagnóstico: sabe-se que o sistema errou, não onde.

4. Níveis de teste

Cada pergunta é respondida no nível em que o defeito é isolável com o menor custo. A escolha do nível determina a velocidade da execução, a estabilidade do resultado e a precisão do diagnóstico.

5. Automação antes do teste manual

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. A precedência da automação sobre a inspeção humana decorre de três propriedades: repetição sem custo marginal, precisão de medição e capacidade de detectar regressão.

A inspeção humana permanece necessária onde o julgamento é o próprio critério: adequação do tom da resposta, clareza do pedido de desambiguação, aceitabilidade cultural do comportamento e razoabilidade do percurso no domínio de aplicação. Essa inspeção ocorre uma vez por entrega; a execução automatizada ocorre a cada alteração do repositório.

6. Requisitos não funcionais de verificação manual inviável

A reflexão proposta para o encontro consiste em identificar, no próprio projeto, os requisitos não funcionais cuja verificação por pessoas é impraticável. A tabela abaixo relaciona os casos recorrentes em aplicações de linguagem natural.

7. Testes de componentes

Corresponde ao Autoestudo 2, apoiado nas páginas 372 a 387 de Pressman. Entende-se por componente a menor unidade de software com interface declarada e responsabilidade própria. A questão central do autoestudo é por que o teste nesse nível é condição para localizar o defeito em um sistema composto por serviços de terceiros.

Técnicas estruturais

As técnicas de caixa-branca derivam os casos de teste da estrutura interna do código. O teste de caminho básico utiliza o grafo de fluxo de controle, e a complexidade ciclomática estabelece o limite superior de caminhos independentes a exercitar. Acrescentam-se a cobertura de condição, de decisão e o tratamento sistemático de laços. Aplicam-se ao código próprio: normalização do enunciado, roteamento da intenção, validação do parâmetro e política de confirmação.

Técnicas funcionais

As técnicas de caixa-preta derivam os casos da especificação, sem acesso à estrutura interna. Compreendem o particionamento em classes de equivalência, a análise de valor-limite e o teste baseado em tabela de decisão. Aplicam-se ao serviço de processamento de linguagem natural contratado, cujo código não é acessível à equipe.

8. O oráculo

Entende-se por oráculo o critério que decide se a saída observada está correta. Sem oráculo declarado não existe teste, apenas execução. Em linguagem natural, o oráculo é construído por três caminhos, frequentemente combinados.

Propriedades invariantes recorrentes

• Intenção inferida abaixo do limiar de confiança não é executada sem confirmação explícita.
• Comando com efeito financeiro ou de segurança exige parâmetro explícito, sem valor padrão.
• Execução repetida do mesmo identificador de operação não duplica o efeito.
• Toda execução produz entrada correspondente na trilha de auditoria.
• Enunciado não compreendido resulta em pedido de esclarecimento, não em ação arbitrária.

9. Gherkin: a especificação executável

Entende-se por Gherkin a linguagem estruturada em que o critério de aceitação é redigido em texto legível pelo parceiro e, simultaneamente, executado como teste. A linguagem provém da prática de desenvolvimento guiado por comportamento e é interpretada por arcabouços como Cucumber, behave, pytest-bdd e SpecFlow.

Em uma aplicação de linguagem natural, o cenário em Gherkin cumpre a função descrita na seção anterior: 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 é substituído ou atualizado.

Estrutura do arquivo

A primeira linha do arquivo pode declarar o idioma com # language: pt, o que habilita as palavras-chave em português. O acervo adota essa forma, de modo que o parceiro leia a especificação sem tradução.

Dado, Quando, Então

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 produz cenários que executam sem verificar comportamento.

Especificação do caso

# 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

  Regra: Comando de efeito financeiro exige confirmação quando a confiança é insuficiente

    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 |
      | preciso trancar a porta amanhã  |

  @nao-repudio
  Cenário: Reconstituição de comando contestado
    Dado que o usuário "u-1183" executou o comando "abrir_fechadura" em 18/09/2026 às 21:14
    Quando o perito consulta a trilha pelo identificador de correlação "c-99f2"
    Então o registro apresenta autor, enunciado, confiança, parâmetros e instante
    E a assinatura do registro é validada com a chave pública do serviço emissor

Vinculação dos passos ao sistema

O arquivo .feature não executa por si. Cada passo é associado a uma definição escrita em código, que concentra a chamada ao sistema e a asserção correspondente. O exemplo abaixo utiliza a sintaxe do arcabouço behave.

@given('que o limiar de confiança para execução direta é {limiar:f}')
def passo_limiar(context, limiar):
    context.assistente = Assistente(limiar_confianca=limiar)

@when('o usuário enuncia "{enunciado}"')
def passo_enunciar(context, enunciado):
    context.resposta = context.assistente.processar(enunciado)

@then('o sistema solicita confirmação explícita')
def passo_confirmacao(context):
    assert context.resposta.tipo == 'confirmacao', context.resposta

A relação com o Autoestudo 3 é direta: o conjunto de arquivos .feature especifica o comportamento, afere a conformidade a cada execução e vincula requisito, teste e alteração de código, que são as três dimensões tratadas na seção 18.

10. Demonstração em sala

Trinta minutos do encontro são destinados à demonstração do percurso completo entre um requisito do projeto e o teste que o executa. A demonstração é conduzida no projetor, com o repositório aberto, a partir de um requisito enunciado por um dos grupos.

11. Falhas na automação

A suíte de testes é software e contém defeitos. O defeito mais grave é aquele que produz aprovação indevida, porque suprime o sinal de erro em vez de emiti-lo. A pergunta do encontro — como detectar erros automaticamente quando a própria automação falha — é respondida por procedimentos que verificam a capacidade de detecção da suíte.

Impacto da falha não detectada

Considere o falso acionamento de compra por conversa ambiente, descrito na situação-problema. A falha da automação em detectá-lo produz três ordens de consequência: financeira, pela transação indevida e pelo custo de estorno; contratual, pela violação do acordo de nível de serviço e pela eventual sanção regulatória; e de confiança, pela desistência do usuário em utilizar o comando por voz para operações de efeito irreversível. A terceira é a de reversão mais lenta.

12. Detecção do erro em operação

Parte dos defeitos de uma aplicação de linguagem natural só se manifesta com entrada real, em condições que o conjunto de referência não reproduz. A detecção depende de instrumentação declarada em projeto, e não acrescentada após o incidente.

• Invariantes verificadas em execução. As mesmas propriedades asseridas em teste são verificadas a cada requisição em produção, com registro da violação.
• Telemetria com limiar. Distribuição da confiança inferida, proporção de pedidos de desambiguação, taxa de cancelamento pelo usuário e latência, com alarme sobre desvio.
• Liberação gradual. A versão candidata recebe fração do tráfego, com comparação de métricas e retorno automático à versão anterior quando o limiar é violado.
• Registro e reexecução. Enunciados registrados são reexecutados sobre a versão candidata, o que converte cada incidente em caso de teste permanente.

13. Não repúdio

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. A propriedade se distingue de duas outras com as quais é frequentemente confundida.

Conteúdo da trilha

Proteção da trilha

• Assinatura digital de cada entrada pela chave do serviço emissor.
• Encadeamento por resumo criptográfico, em que cada entrada incorpora o resumo da anterior.
• Escrita em repositório sem permissão de alteração ou remoção durante o prazo de retenção.
• Carimbo do tempo emitido por autoridade independente do operador do sistema.
• Segregação entre quem opera a aplicação e quem administra a trilha.

14. Verificação do não repúdio

A propriedade é verificada por procedimento que simula a contestação descrita no encontro: o usuário alega não ter acionado um comando executado pelo sistema, e o especialista precisa estabelecer, a partir dos registros, se houve interação.

• Executar comando conhecido e reconstituir autor, parâmetros e instante exclusivamente a partir da trilha.
• Alterar uma entrada do registro e verificar que a cadeia de resumos acusa a adulteração.
• Remover uma entrada intermediária e verificar que a verificação de integridade reprova a cadeia.
• Executar comandos simultâneos de usuários distintos e verificar que os identificadores de correlação não se confundem.
• Validar a assinatura com a chave pública, sem acesso ao sistema emissor.
• Verificar a disponibilidade e a legibilidade do registro ao final do prazo de retenção declarado.

15. Benchmarking baseado em testes

Corresponde ao Autoestudo 1, apoiado em Hayahi, Arakaki e Ruggiero (2020), páginas 1 a 3. A questão inicial do artigo é como avaliar uma solução sem depender do discurso comercial do fornecedor.

A alegação do fornecedor descreve o comportamento do produto em condições escolhidas por ele: corpus, carga, região de processamento e configuração. 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 condições idênticas, com métricas declaradas antes da execução.

Etapas do experimento

1. Definir o contexto de uso e as restrições do ambiente de operação.
2. Derivar os atributos de qualidade das metas de negócio.
3. Especificar métrica, instrumento de medição e limiar de aceitação.
4. Construir o conjunto de casos representativo do domínio.
5. Executar as alternativas sob condições idênticas e registrar os resultados.
6. Registrar a decisão, as incertezas e as condições em que ela deixaria de valer.

16. Atributos de qualidade a partir de metas de negócio

Corresponde à página 5 do artigo. O atributo de qualidade é extraído de três fontes e convertido em especificação mensurável.

Para o profissional de engenharia de software, os adjetivos “bom”, “rápido” e “barato” não constituem requisito. O atributo é evidenciado por especificação técnica com valor, unidade, condição de medição e estatística de referência, e a solução é medida para verificar se o atende.

17. Comparação de alternativas e mudança de contexto

Corresponde às páginas 10 a 14 do artigo. A pergunta prática é se os serviços de processamento de linguagem natural dos grandes fornecedores atendem ao projeto e qual deles é o mais adequado. A comparação se organiza em tabela com critérios homogêneos e pesos declarados antes da medição.

A tabela é acompanhada do conjunto de casos utilizado, da data da medição e da versão de cada serviço. Sem esses três elementos o resultado não é reproduzível nem contestável, e a comparação perde valor probatório para a decisão de arquitetura.

A mesma decisão em ambiente crítico

O artigo propõe reexaminar a escolha na hipótese de aplicação em ambiente crítico, como uma mina de extração mineral, com equipamentos em operação, pessoas e ruído intenso. O conjunto de critérios permanece; alteram-se os pesos, os limiares e o desenho do experimento.

18. O teste como documentação do processo

Corresponde ao Autoestudo 3, de realização opcional, que avalia o desenvolvimento dirigido por testes aplicado ao módulo de processamento de linguagem natural em três dimensões.

• Especificação. O caso de teste enuncia, em forma executável, o comportamento exigido do componente. A especificação permanece consistente com o código porque a divergência entre ambos reprova a execução.
• Aferição. A suíte informa, a cada alteração, a proporção de requisitos verificados, a cobertura alcançada e a regressão introduzida.
• Rastreabilidade. A identificação do requisito no caso de teste e na mensagem de commit estabelece o percurso entre a exigência acordada com o parceiro, a verificação correspondente e a alteração que a implementou.

19. Atividade do encontro

Quarenta e cinco minutos em grupo, com entrega registrada no repositório do projeto ao final da aula. São produzidos dois artefatos.

20. Falhas recorrentes

• Especificar o requisito com adjetivo e sem métrica, o que impede a verificação e desloca a decisão para a percepção de quem inspeciona.
• Redigir cenários imperativos, que descrevem a operação da interface e são reescritos a cada alteração de tela.
• Medir a solução com corpus genérico do fornecedor em vez de conjunto do domínio do parceiro.
• Tratar a cobertura de código como evidência de qualidade, sem verificar a capacidade de detecção da suíte.
• Executar toda verificação em nível de sistema, o que produz suíte lenta, instável e sem diagnóstico.
• Registrar a interação em arquivo de texto sem assinatura nem encadeamento, o que não sustenta contestação.
• Reter gravação de voz sem base legal, finalidade declarada e prazo, o que cria passivo em vez de evidência.
• Comparar fornecedores pela tabela de preço divulgada, sem medir custo por transação no volume projetado.

21. 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.