Testes em aplicações de linguagem natural

1. Como ler este material

O texto antecede o encontro. A primeira hora da aula é ocupada por cinco decisões de arquitetura submetidas à turma, uma por categoria de exceção, e a hora seguinte pela enumeração das exceções do próprio projeto e pela redação dos cenários correspondentes. A leitura prévia é o que torna essa produção viável no tempo disponível.

As seções 3 a 4 apresentam o caso discutido em sala e as alternativas em disputa; as seções 5 e 6 estabelecem o eixo do encontro, que é a enumeração das exceções fora do caminho feliz por categoria. As seções 7 a 12 tratam do objeto e dos níveis de teste, da automação e do oráculo. A seção 13 apresenta a ISO/IEC 25010, e as seções 14 e 15 tratam da redação dos cenários em Gherkin e do ciclo de desenvolvimento dirigido por testes, este último em vídeo. As seções 16 a 22 aprofundam falhas da automação, não repúdio e benchmarking, e correspondem, respectivamente, ao Autoestudo 2 na seção 11 e ao Autoestudo 1 nas seções 20 a 22.

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 paráfrases corretas e aprova apenas a resposta que coincide com a redação da referência. 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 situação-problema: segurança no PIX

O caso a seguir é submetido à turma antes de qualquer exposição conceitual e organiza as cinco questões do encontro.

4. As cinco questões do encontro

O caso é percorrido por cinco questões, cada uma referente a uma categoria de exceção que sai do caminho feliz. Cada questão apresenta quatro táticas com ganho e custo declarados, e nenhuma é correta em abstrato: cada uma responde a uma classe de falha e permanece exposta a outra.

O percurso de cada questão

A decisão é tomada duas vezes sobre o mesmo cardápio de alternativas, na sala de aprendizagem em equipe publicada no acervo. A primeira ocorre com a distribuição da turma oculta, em três minutos, de modo que a escolha decorra do argumento e não da adesão à maioria. Seguem-se quatro minutos de discussão, em que as justificativas são lidas sem identificação, e dois minutos para decidir outra vez. A síntese projeta as duas distribuições e o deslocamento entre elas antes de a questão seguinte abrir.

O dado novo da terceira questão

A discussão da terceira questão abre com a classificação individual das 1.870 ocorrências. Em 78% delas não houve erro de reconhecimento nem chave divergente: o titular autenticado enunciou o comando pretendido, ouviu a leitura de volta, confirmou a ordem e a instituição executou exatamente o que foi pedido. A transação foi obtida por engano do titular, nas modalidades de falso funcionário da instituição, falso parente em situação de urgência e coação presencial. A meta do conselho, o prazo e as quatro alternativas permanecem os mesmos, e o critério da decisão se desloca.

5. O caminho feliz e as exceções

A conclusão que o caso sustenta é a seguinte: o sistema percorreu o caminho feliz sem defeito e a perda ocorreu. A confirmação explícita foi concluída em 96% das ocorrências de engano do titular, e a verificação biométrica da voz correspondeu ao titular em 100% delas.

Entende-se por caminho feliz o percurso em que a entrada é a prevista, a dependência externa responde dentro do prazo e a regra de negócio encontra todos os parâmetros que exige. É o primeiro percurso implementado, o primeiro testado e o que reprova com menor frequência. Um trecho de código exercitado apenas por esse percurso permanece sem especificação para todas as demais condições de execução.

A atitude de qualidade que o encontro propõe consiste em enumerar essas demais condições antes da implementação. A lista de exceções é o produto central: cada item descreve uma condição fora do percurso previsto, a consequência de não tratá-la e a verificação que demonstra o tratamento. A lista é especificação, e cada linha se converte em caso de teste.

6. As cinco categorias de exceção

A enumeração por categoria substitui a inspiração individual por uma varredura sistemática. Cada categoria interroga o trecho de código por um ângulo distinto, e a ausência de itens em alguma delas indica lacuna de análise, não ausência de exceção.

Procedimento de enumeração

1. Delimitar o trecho sob análise por arquivo e função, e enunciar o comportamento esperado no percurso previsto.
2. Percorrer a cadeia de processamento descrita na seção seguinte, etapa por etapa.
3. Em cada etapa, aplicar as cinco perguntas da tabela acima e registrar as exceções encontradas.
4. Para cada exceção, declarar a consequência da ausência de tratamento, em termos financeiros, contratuais, regulatórios ou de confiança.
5. Associar a exceção à característica de qualidade correspondente da ISO/IEC 25010.
6. Converter a exceção em requisito verificável, com valor, unidade, limiar, nível de teste e oráculo declarado.

7. A cadeia de processamento

A interação em linguagem natural constitui uma cadeia de etapas, cada uma com entrada, saída e critério de correção próprios. O teste da cadeia inteira sem o teste de suas etapas produz reprovação sem diagnóstico, que registra o erro do sistema sem localizar a etapa em que ocorreu.

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

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

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

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

12. O oráculo

Entende-se por oráculo o critério que decide se a saída observada está correta. A execução sem oráculo declarado não constitui teste. 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, sem execução de ação.

13. ISO/IEC 25010: o vocabulário dos requisitos não funcionais

A norma ISO/IEC 25010 organiza a qualidade do produto de software em características e subcaracterísticas. Sua função no encontro é dupla: nomear a preocupação a que cada exceção pertence e revelar as categorias que a análise do grupo ainda não examinou.

14. 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: Execução de comandos 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

  Regra: Enunciado sem palavra de ativação não produz comando

    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ã  |

  Regra: Todo comando executado é reconstituível a partir da trilha de auditoria

    @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}')
def passo_limiar(context, limiar):
    context.assistente = Assistente(limiar_confianca=float(limiar.replace(',', '.')))

@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

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. O ciclo em que essa especificação é escrita antes da implementação é tratado na seção seguinte.

15. O ciclo do desenvolvimento dirigido por testes

O percurso entre o cenário redigido e o código que o aprova é apresentado em vídeo, de realização individual antes ou depois do encontro. O vídeo conduz o ciclo em três movimentos: escrever o teste que reprova por comportamento ausente, implementar o comportamento mínimo que o aprova e reorganizar o código com a suíte como rede de proteção.

Test-Driven Development In Python: the power of red-green-refactor. Disponível em youtube.com/watch?v=B1j6k2j2eJg.

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

A falha da automação em detectar o falso acionamento de compra por conversa ambiente, descrito na situação-problema, 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.

17. 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, antes da ocorrência de incidentes.

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

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

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

20. Benchmarking baseado em testes

Corresponde ao Autoestudo 1, apoiado em Hayashi, 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.

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

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

23. Atividade do encontro

Produção em grupo sobre o projeto do parceiro, registrada no repositório ao final da aula. São produzidos dois artefatos encadeados: a lista de exceções e os cenários que a tornam executável.

24. 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 constitui tratamento irregular de dado pessoal.
• Comparar fornecedores pela tabela de preço divulgada, sem medir custo por transação no volume projetado.

25. Referências

• HAYASHI, 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.
• Test-Driven Development In Python: the power of red-green-refactor — vídeo do autoestudo, incorporado à seção 15. youtube.com/watch?v=B1j6k2j2eJg.
• Smart House, Rema 1000 — referência audiovisual sobre acionamento indevido em assistente de voz. youtu.be/nwPtcqcqz00.
• BANCO CENTRAL DO BRASIL — Mecanismo Especial de Devolução e limites de valor do PIX.