O que é teste baseado em modelo?

⚡ Resumo Inteligente

O teste baseado em modelo verifica o comportamento em tempo de execução do software em relação às previsões feitas por um modelo abstrato.tracO modelo do sistema gera casos de teste automaticamente a partir de máquinas de estado finito, diagramas de estado ou notações UML, em vez de manualmente.

  • 🧭 Ideia central: Um modelo descreve o comportamento esperado, e cada caso de teste é derivado desse modelo em vez de ser escrito individualmente.
  • 🔀 Duas estruturas: A geração offline constrói o conjunto de etapas antes da execução, enquanto a geração online produz as etapas dinamicamente durante a execução.
  • 📐 Notações do modelo: Máquinas de estados finitos, diagramas de estado, tabelas de decisão, grafos de fluxo de dados e de fluxo de controle, e diagramas UML.
  • ⚙️ Processo de trabalho: Construa o modelo, escolha os critérios de cobertura, gere os valores absolutos.tracRealizar testes t, concretizá-los em scripts, executá-los e, em seguida, atribuir veredictos.
  • 🛠️ Ferramentas: GraphWalker, fMBT, Conformiq, MaTeLo, MBTsuite e Spec Explorer geram caminhos a partir de grafos direcionados ou modelos de estado.
  • ⚖️ Troca: A manutenção diminui e a cobertura aumenta, mas a técnica exige habilidade de modelagem e um investimento inicial em aprendizado.

Testes baseados em modelos derivam casos de teste automaticamente a partir de um modelo comportamental do sistema.

O que é teste baseado em modelo?

Teste Baseado em Modelo É uma técnica de teste de software na qual o comportamento em tempo de execução do software em teste é verificado em relação às previsões feitas por um modelo. Um modelo é uma descrição do comportamento de um sistema, expressa em termos de sequências de entrada, ações, condições, saída e o fluxo de dados da entrada para a saída. Um modelo utilizável deve ser praticamente compreensível, reutilizável e compartilhável, e deve descrever o sistema em teste com precisão.

Existem inúmeros modelos disponíveis, e cada um descreve um aspecto diferente do comportamento do sistema. Exemplos comuns são:

O teste baseado em modelo descreve como um sistema se comporta em resposta a uma ação determinada pelo modelo. Forneça a ação e verifique se o sistema responde conforme previsto pelo modelo. Qualquer divergência entre os dois indica um defeito no software ou um erro no modelo, e ambos devem ser investigados.

É um método formal e leve para validar um sistema, aplicável tanto a testes de hardware quanto de software. Como os testes derivam de uma especificação de comportamento e não do código, a técnica se enquadra na categoria de... teste de caixa preta família de técnicas de teste de software.

Exemplo de teste baseado em modelo

A maneira mais simples de interpretar um modelo comportamental é acompanhá-lo passo a passo. O diagrama abaixo modela uma pequena tarefa de edição de texto, onde cada caixa representa um estado possível da aplicação e cada seta representa uma ação que o usuário pode realizar.

Exemplo de teste baseado em modelo, modelando os estados e ações da escrita de um poema no Bloco de Notas.

O modelo explica uma abordagem simplificada para escrever poesia no Bloco de Notas e as possíveis ações relacionadas a cada etapa. Para cada ação, como iniciar o aplicativo, inserir um poema ou salvar o arquivo, um caso de teste podem ser gerados e a saída verificada. Percorrer um caminho diferente pelo mesmo diagrama, por exemplo, começando e terminando sem salvar, produz um caso de teste diferente sem custo adicional de projeto, o que constitui o argumento econômico para toda a técnica.

Tipos de MBT

Existem dois tipos de frameworks de Teste Baseado em Modelo, e a diferença entre eles reside simplesmente no momento em que as etapas de teste são geradas:

  • Offline / a priori: Geração de conjuntos de testes antes de sua execução. Um conjunto de testes é uma coleção de casos de teste e, neste modo, o conjunto é armazenado, revisado e executado novamente como qualquer outro. teste de automação de ativos.
  • Online / em tempo real: Geração de conjuntos de testes durante a execução dos testes, em que a próxima etapa é escolhida com base em como o sistema respondeu à etapa anterior.

A geração offline é adequada para ambientes regulamentados que necessitam de um conjunto de testes revisável e repetível. A geração online é adequada para sessões exploratórias de longa duração em sistemas com estado, pois o gerador pode reagir à resposta real em vez da resposta prevista.

Como funciona o teste baseado em modelo

Independentemente da estrutura utilizada, a técnica segue as mesmas cinco etapas. Cada etapa produz um artefato que a etapa seguinte utiliza, razão pela qual o modelo, e não o script de teste, torna-se o elemento que a equipe mantém.

  • Passo 1: Construir o modelo. Traduzir requisitos ou uma especificação em algo abstratotracmodelo t de comportamento esperado, definindo os estados, as transições entre eles e as entradas que desencadeiam cada transição.
  • Etapa 2: Escolha os critérios de seleção do teste. Os critérios indicam ao gerador quando parar. Os mais comuns são a cobertura de todos os estados, que visita cada estado pelo menos uma vez; a cobertura de todas as transições, que executa cada seta pelo menos uma vez; e a cobertura de caminhos ou fluxos de dados para uma exploração mais aprofundada.
  • Etapa 3: Gerar abstraccasos de teste t. A ferramenta percorre o modelo e emite sequências de valores absolutos.tract etapas que satisfazem os critérios escolhidos, juntamente com o resultado esperado em cada etapa.
  • Passo 4: Concretizar os abdominaistracTestes t. Uma camada adaptadora mapeia cada valor absoluto.tracPara realizar uma ação real contra o sistema, como uma interação com a interface do usuário, um API chamada ou mensagem de protocolo. Este mapaping É escrito uma única vez e reutilizado por todos os testes gerados.
  • Etapa 5: Executar e atribuir veredictos. Os testes concretos são realizados no sistema em teste, cada resposta observada é comparada com a previsão do modelo e um veredicto de aprovado ou reprovado é registrado. tracretornou ao elemento do modelo que o produziu.

O tracA capacidade criada na etapa 5 é o resultado prático. Quando um requisito muda, o modelo muda e os testes afetados são regenerados em vez de reescritos, razão pela qual as equipes que realizam testes com frequência teste de regressão Contra uma especificação estável, o benefício é maior.

Diferentes modelos em testes

Para entender o MBT, é necessário compreender alguns dos modelos explicados abaixo. Cada um deles equilibra poder expressivo e esforço, portanto, a escolha depende da complexidade do comportamento em teste.

Máquinas de estado finito

Este modelo ajuda os testadores a avaliar o resultado dependendo da entrada selecionada. Várias combinações de entradas podem resultar em um estado correspondente do sistema.

O sistema terá um estado específico e um estado atual, que será determinado por um conjunto de entradas fornecidas pelos testadores.

Considere o exemplo abaixo. Um sistema permite que os funcionários acessem um aplicativo. O estado atual do funcionário é "Ausente" e passa a ser "Acessado" assim que ele entra no sistema. No estado "Acessado", o funcionário pode visualizar, imprimir e digitalizar documentos no sistema.

A máquina de estados para esse exemplo é mostrada aqui, com cada seta rotulada pela entrada que causa a transição.

Modelo de máquina de estados finitos mostrando os estados de entrada e saída de um sistema de login de funcionários.

Gráficos estaduais

Um diagrama de estados é uma extensão da máquina de estados finitos e pode ser usado para sistemas complexos e de tempo real. Os diagramas de estados descrevem vários comportamentos do sistema, possuem um número definido de estados e o comportamento do sistema é analisado e representado na forma de eventos para cada estado. A extensão que importa na prática é a hierarquia: um diagrama de estados permite estados aninhados e paralelos, de modo que uma máquina que precisaria de dezenas de estados planos pode ser representada de forma compacta.

Por exemplo, os defeitos são registrados na ferramenta de gerenciamento de defeitos com o status "Novo". Assim que um defeito é corrigido pelos desenvolvedores, o status deve ser alterado para "Corrigido". Se um defeito não for corrigido, o status muda para "Reaberto". Os diagramas de estado devem ser projetados de forma que um evento seja acionado para cada estado.

O ciclo de vida do defeito é ilustrado abaixo, com cada status representado como um estado e cada ação do fluxo de trabalho como o evento que move o defeito entre eles.

Diagrama de estados do ciclo de vida de um defeito, passando pelos status Novo, Corrigido e Reaberto.

Linguagem de modelagem unificada (UML)

Linguagem de modelagem unificada (UML) UML é uma linguagem de modelagem padronizada de propósito geral. Ela inclui um conjunto de técnicas de notação gráfica usadas para criar modelos visuais que podem descrever o comportamento de sistemas muito complexos.

UML possui notações como:

  • Atividades
  • Atores
  • Processo de negócio
  • Componentes
  • Linguagem de programação

Os diagramas de atividade e de máquina de estados são os que os criadores de testes leem com mais frequência, como ilustra o modelo UML de exemplo abaixo.

A notação de diagrama UML é usada como modelo de origem para gerar casos de teste.

Ferramentas de teste baseadas em modelos

Um modelo em papel não gera nada por si só. É necessário um gerador para percorrer o modelo e emitir caminhos de teste, e o mercado de ferramentas se divide em geradores de código aberto e plataformas comerciais de projeto de testes.

  • GraphWalker — uma ferramenta de código aberto que lê modelos com formato de grafos direcionados e gera caminhos de teste a partir deles, com geradores e condições de parada selecionáveis.
  • fMBT — um conjunto de ferramentas de teste baseado em modelos de código aberto da Intel que oferece suporte à geração e execução de testes em modelos de estado.
  • Conformiq — um produto comercial de projeto de testes automatizados que deriva casos de teste e scripts de modelos comportamentais gráficos.
  • MaTeLo e MBTsuite — plataformas comerciais voltadas para modelos estatísticos de uso e para a geração de testes em estruturas de automação existentes.
  • Explorador de especificações - MicrosoftExtensão de teste baseada em modelo para Visual Studio, amplamente citada na literatura sobre teste de protocolos.

A seleção depende menos de listas de funcionalidades do que de duas questões: qual notação a equipe consegue efetivamente desenhar e se a ferramenta consegue gerar testes para a estrutura de automação já em uso. Um gerador que produz suítes que ninguém consegue executar adiciona uma etapa ao processo em vez de eliminar uma.

Testes baseados em modelos versus projeto de testes tradicional

Vale a pena destacar o contraste com o planejamento de testes manuscritos, pois as duas abordagens falham em pontos diferentes, e não há simplesmente uma que seja melhor que a outra.

Aspecto Teste Baseado em Modelo Projeto de teste tradicional
Fonte dos casos de teste Gerado automaticamente a partir de um modelo comportamental. Escrito individualmente por um testador a partir dos requisitos.
Efeito de uma mudança de requisito Atualize o modelo e regenere os testes afetados. Localize e edite manualmente cada caso de teste afetado.
Global Medido em relação a critérios de modelo, como todos os estados ou todas as transições. Comparado aos requisitos e dependente do julgamento do testador.
Custo inicial Alto: habilidade de modelagem, configuração de ferramentas e uma camada adaptadora. Baixo: um testador pode começar a escrever imediatamente
Melhor ajuste Sistemas com estado, de longa duração e com especificação estável. Projetos curtos, trabalhos únicos e projetos exploratórios.
Modo de falha principal Um modelo incorreto ou desatualizado gera silenciosamente testes incorretos. Lacunas e duplicatas se acumulam em um conjunto amplo de dados.

A evolução descrita abaixo contextualiza a técnica: a execução manual de testes deu lugar à execução automatizada, e as abordagens baseadas em modelos antecipam a automação em um nível, integrando-a ao próprio projeto de testes.

Evolução dos testes de software: da execução manual à automação e aos testes baseados em modelos.

Desafios dos testes baseados em modelos

A implementação do MBT em uma organização requer um investimento considerável de dinheiro e esforço. A seguir, são apresentadas as desvantagens do MBT em Engenharia de software:

  • Os testadores precisam de habilidades de modelagem que o design de testes tradicional não exige.
  • A curva de aprendizado é longa, e o primeiro projeto geralmente custa mais do que economiza.
  • O próprio modelo pode ser difícil de entender e analisar, principalmente quando cresce.
  • Um modelo que se desvia da especificação gera testes confiantes, porém incorretos.
  • A camada adaptadora que transforma o ABStracOs passos para a ação concreta precisam ser documentados e mantidos separadamente.
  • O tamanho do modelo cresce rapidamente, portanto, um modelo de estado irrestrito pode produzir mais caminhos do que qualquer equipe consegue executar.

Nenhuma dessas razões justifica evitar a técnica, mas, em conjunto, explicam por que o MBT geralmente é implementado primeiro em um subsistema estável, em vez de em todo o sistema. ciclo de vida de teste de software de uma vez só.

Vantagens dos testes baseados em modelos

Considerando esses custos, os benefícios da MBT são:

  • Manutenção facilitada dos casos de teste e do conjunto de testes, pois o modelo é editado em vez dos testes individuais.
  • Redução de custos ao longo da vida útil de um projeto de longa duração.
  • Melhorado cobertura de teste, visto que o gerador explora caminhos que uma pessoa normalmente ignoraria.
  • Diferentes conjuntos de testes gerados podem ser executados em paralelo em qualquer número de máquinas.
  • Detecção precoce de defeitos, pois ambiguidades surgem durante a construção do modelo, antes da execução de qualquer código.
  • Um aumento no número de defeitos encontrados para o mesmo esforço de teste.
  • Economia de tempo no projeto de testes, uma vez que o modelo e o adaptador já existam.
  • Aumento da satisfação dos testadores no trabalho, à medida que o esforço passa da criação repetitiva de scripts para a modelagem e análise.

Os testadores já constroem modelos mentais enquanto trabalham, e a MBT simplesmente transfere esses modelos mentais para o papel, onde podem ser revisados, versionados e reutilizados. A posição dessa técnica em relação às outras abordagens disponíveis é apresentada em [referência]. tipos de testes de software.

Perguntas Frequentes

Caixa preta. Os testes são derivados de um modelo de comportamento especificado, não do código-fonte. A técnica se torna caixa cinza somente quando o modelo é construído a partir de documentos de projeto internos, em vez de requisitos externos.

Modele apenas os comportamentos que justifiquem a criação de testes. Modele um fluxo de trabalho com estado, como um processo de finalização de compra ou o ciclo de vida de um defeito, no nível mais amplo que ainda permita distinguir resultados reais. Modelar tudo produz uma explosão de estados que ninguém consegue executar.

O modelo deve ser controlado por versão juntamente com o código, com um responsável definido e uma etapa de revisão no mesmo processo de alteração da especificação. Um modelo sem responsável fica desalinhado, e um modelo desalinhado gera testes confiantes, porém incorretos.

Não. Um gerador explora apenas o que o modelo descreve, portanto, qualquer coisa que o modelo omita permanece sem ser testada. As sessões exploratórias continuam sendo a maneira pela qual as equipes descobrem comportamentos que ninguém especificou e, muitas vezes, revelam as lacunas que o modelo então preenche.

Sistemas com estado de longa duração e com especificação escrita: protocolos de comunicação, controladores embarcados e automotivos, dispositivos médicos, fluxos de trabalho bancários e equipamentos de telecomunicações. Esses domínios combinam uma especificação estável com um número excessivo de sequências legais para serem enumeradas manualmente.

Quando a especificação muda mais rápido do que o modelo consegue acompanhar, quando a funcionalidade é pequena ou de curta duração, ou quando ninguém na equipe consegue manter a notação, os casos escritos à mão têm um custo menor ao longo do projeto.

O aprendizado de máquina infere modelos de estado preliminares a partir de registros de produção e sessões gravadas, sinaliza transições que o modelo nunca cobre e classifica os caminhos gerados pelo histórico de defeitos, de modo que as sequências de maior risco sejam executadas primeiro. Os engenheiros ainda validam o modelo inferido.

Sim, principalmente para a camada de adaptador: os métodos de etapa, objetos de página e asserções que vinculam abstracO modelo não adapta as ações às chamadas reais. Decidir o que o modelo deve conter e quais critérios de cobertura são importantes continua sendo uma decisão de projeto.

Resuma esta postagem com: