BR102015030798A2

BR102015030798A2 - sistema e método

Info

Publication number: BR102015030798A2
Application number: BR102015030798A
Authority: BR
Inventors: Meng Li
Original assignee: Gen Electric
Priority date: 2014-12-10
Filing date: 2015-12-09
Publication date: 2016-06-14
Also published as: EP3032425B1; US20160170864A1; CN105701008A; CN105701008B; US10108536B2; JP6607565B2; JP2016119075A; EP3032425A1; CA2913884A1

Abstract

sistema e método de acordo com algumas realizações, trata-se de um sistema que compreende um dispositivo de comunicação operacional para se comunicar com um usuário para obter um ou mais requisitos associados a um modelo para um módulo de geração de caso de teste; um módulo de computador de tradução para receber o modelo, armazenar o modelo e gerar um modelo intermediário; um módulo de computador gerador para receber o modelo intermediário, armazenar o modelo intermediário e gerar pelo menos um caso de teste; uma memória para armazenar instruções de programa; pelo menos um processador de plataforma de geração de caso de teste, acoplado à memória e em comunicação com o módulo de computador de tradução e com o módulo de computador gerador, operacional para executar instruções de programa para: transformar o modelo em um modelo intermediário executando-se o módulo de computador de tradução; identificar um tipo de modelo associado ao modelo intermediário com base em uma análise do modelo intermediário executando-se o módulo de computador gerador; selecionar um método de geração de teste com base na análise do tipo de modelo identificado executando-se o módulo de computador gerador; gerar pelo menos um caso de teste para uso em validação e verificação de software. muitos outros aspectos são proporcionados.

Description

“SISTEMA E MÉTODO” Antecedentes [001] Desenvolver um sistema com um componente de software pode envolver frequentemente requisitos de sistema proporcionados por um cliente. Esses requisitos podem ser incorporados no software. Após o software ser projetado, o mesmo pode ser validado e verificado para confirmar que o mesmo satisfaz adequadamente os requisitos. Os processos de validação e verificação podem ser responsáveis por uma grande porção do custo do software. A pontualidade dos processos de validação e verificação pode afetar o desempenho dos negócios centrais, a satisfação do cliente e a reputação corporativa, por exemplo.

[002] Por esse motivo, seria desejável projetar um aparelho e um método que proporcionassem uma maneira mais rápida de validar e verificar que o software está em conformidade com os requisitos, funciona corretamente e cobre adequadamente os objetivos para os requisitos.

Descrição Resumida [003] De acordo com algumas realizações, um caso de teste é gerado pela aplicação de um módulo de computador de tradução e de um módulo de computador gerador e pode ser usado para verificar e validar os requisitos de software. O módulo de computador de tradução é aplicado a um ou mais modelos de especificação e modelos de projeto para gerar um modelo intermediário e, então, o caso de teste é gerado por meio de execução do módulo de computador gerador na saída do módulo de computador de tradução (por exemplo, modelo intermediário).

[004] Um efeito técnico de algumas realizações da invenção é uma técnica e um sistema aperfeiçoados para geração de caso de teste. Com essas e outras vantagens e recursos que se tornarão evidentes a seguir, uma compreensão mais completa da natureza da invenção pode ser obtida recorrendo-se à seguinte descrição detalhada e aos desenhos anexos ao presente documento.

[005] Outras realizações são associadas a instruções de armazenagem em sistemas e/ou em meio legível por computador para realizar quaisquer dos métodos descritos no presente documento.

Breve Descrição das Figuras [006] A Figura 1 ilustra um sistema de acordo com algumas realizações.

[007] A Figura 2 ilustra um diagrama de fluxo de acordo com algumas realizações.

[008] A Figura 3 ilustra um diagrama de blocos de um sistema de acordo com algumas realizações.

[009] A Figura 4 ilustra um modelo de acordo com algumas realizações.

[010] A Figura 5 ilustra um modelo de acordo com algumas realizações.

[011] A Figura 6A ilustra um modelo de acordo com algumas realizações.

[012] A Figura 6B ilustra um modelo de acordo com algumas realizações.

[013] A Figura 7 ilustra um diagrama de fluxo de acordo com algumas realizações.

[014] A Figura 8 é uma tabela de resultado de análise de caminho de acordo com algumas realizações.

[015] A Figura 9 ilustra uma interface de usuário de acordo com algumas realizações.

[016] A Figura 10 ilustra uma interface de usuário de acordo com algumas realizações.

[017] A Figura 11 ilustra um caso de teste de acordo com algumas realizações.

[018] A Figura 12 é um diagrama de blocos de uma ferramenta ou plataforma de processamento de geração de caso de teste automático de acordo com algumas realizações.

Descrição detalhada [019] Desenvolver um sistema com um componente de software pode envolver frequentemente requisitos de sistema proporcionados por um cliente. Esses requisitos podem ser incorporados ou capturados em um modelo de especificação em uma forma legível por computador. Os requisitos também podem ser capturados no modelo de especificação em uma forma legível por ser humano. Então, um modelo de projeto pode ser desenvolvido a partir dos requisitos contidos no modelo de especificação e podem expressar dados de projeto de software (por exemplo, estruturas de dados internos de componente de software prescritos, fluxo de dados e/ou fluxo de controle). O código-fonte pode, então, ser gerado automaticamente a partir do modelo de projeto com o uso de um gerador de código qualificado. Após o software ser projetado (por exemplo, modelo de projeto), o mesmo pode ser validado e verificado para confirmar que o software satisfaz adequadamente os requisitos. Os processos de validação e verificação podem ser responsáveis por uma grande porção do custo do software. A prontidão dos processos de validação e verificação pode afetar o desempenho dos negócios centrais, a satisfação do cliente e a reputação corporativa, por exemplo.

[020] Tradicionalmente, por exemplo, muitos softwares de fundamento de segurança (por exemplo, software de aviação) são requeridos a serem testados com cobertura de teste rígida, como Cobertura de Condição/Decisão Modificada (MC/DC), que requer que cada condição afete independentemente a decisão. A inspeção manual do modelo/código para identificar as sequências de entrada que dirigem uma variável interna para um valor específico é difícil e demorada, especialmente quando o software (por exemplo, software de aviação) é grande e a complexidade é crescente. Um teste tradicional sofre de pelo menos um dentre baixa cobertura estrutural/de modelo, blocos/recursos não suportados e tempo de geração de teste longo. Por exemplo, abordagens de teste tradicional podem aplicar cegamente um método de geração de teste em todos os modelos de especifícação/projeto do software. Entretanto, um método de geração de teste pode não ser adequado a todos os modelos de especificação/projeto e podem resultar em um tempo de geração de teste longo ou podem resultar em nenhum caso de teste ser gerado.

[021] Em uma abordagem tradicional, por exemplo, embora a abordagem de geração de caso de teste possa mostrar inacessibilidade a certos elementos de modelo e possa gerar entradas de teste que satisfaçam objetivos de cobertura padrão assim como objetivos e requisitos de teste definidos por usuário, a abordagem pode ter blocos não suportados (por exemplo, bloco “integrador”), pode não ter a capacidade de expressar todas as propriedades de projeto (por exemplo, propriedades de vivacidade real) e pode requerer um limite superior pré-definido de comprimento de caso de teste. Em outra abordagem tradicional, por exemplo, embora a abordagem possa usar uma combinação de teste aleatório e, por esse motivo, possa gerar casos de teste muito rapidamente, entretanto, devido à aleatoriedade da busca, é difícil alcançar uma alta cobertura (por exemplo, tamanho e complexidade do modelo podem levar uma baixa cobertura estrutural). Essa abordagem também pode ser heurística sem explicação e pode ser limitada em relação ao comprimento para gerar sinais de entrada.

[022] Algumas realizações identificam um tipo do modelo de especificação/projeto (por exemplo, aqueles com variáveis simbólicas, números reais, aritmética não linear, circuitos de retroalimentação, etc.) e, então, guiam o processo de geração de teste selecionando-se métodos/módulos de teste apropriados mais adequados para o modelo, de modo que os testes sejam gerados mais eficaz e eficientemente. Uma das vantagens de selecionar o módulo/método de teste mais adequado com base na identidade do modelo é que pode não haver a necessidade de incluir um processo de tentativa e erro demorado e a análise do modelo pode ser realizada apenas uma vez, o que também pode economizar tempo. Outra vantagem pode ser que o próprio módulo/método de teste mais adequado pode evitar esforços de geração de teste demorados (por exemplo, buscar circuitos de retroalimentação) e abstrações (por exemplo, aproximação de números reais) em comparação com outros módulos/métodos de teste e, por isso, economia tempo e alcança uma maior cobertura de teste.

[023] Outra vantagem de realizações da invenção é que o processo de seleção para selecionar o módulo/método mais adequado pode ser completamente automático. Em algumas realizações, as fórmulas matemáticas podem ser derivadas encontrando-se os caminhos de computação nos modelos intermediários, que são automaticamente traduzidos dos modelos de projeto ou de especificação, como adicionalmente descrito abaixo. As fórmulas matemáticas podem ser combinadas substituindo-se os sinais internos por suas atribuições de saída. Então, o conjunto final de fórmulas matemáticas pode incluir funções de atribuição de saída que determinam os valores dos sinais de objetivo de teste e funções de atualização de dados que determinam como o modelo irá evoluir (por exemplo, equações diferenciais). Essas fórmulas matemáticas podem ser legíveis por máquina e os tipos de modelo podem ser identificados pelo reconhecimento de padrões de fórmula consultando-se uma base de dados de padrão de fórmula. A identificação de tipo de modelo manual convencional requer conhecimento especializado e é demorada conforme o tamanho de modelo cresce e os circuitos de retroalimentação são introduzidos. O elemento de identificação de tipo de modelo automático em realizações da invenção pode identificar o tipo de modelo clicando-se em um botão, por exemplo.

[024] Algumas realizações podem tomar como entrada o modelo de especificação e o modelo de projeto e automaticamente fornecer as descrições de teste, os casos de teste e os procedimentos de teste que satisfazem os critérios de cobertura de modelo apropriados. Algumas realizações podem incluir casos e procedimentos de teste que incluem entradas e valores de saída esperados que podem ser destinados a serem executados contra o modelo de projeto e o código-fonte/código de objeto executável para verificar a conformidade dos mesmos com o modelo de especificação. Em outras palavras, em algumas realizações, os casos de teste podem ser gerados a partir do modelo de especificação e são executados no modelo de projeto para verificar se o modelo de projeto é uma implantação verdadeira dos requisitos. Em algumas realizações, casos de teste podem ser gerados a partir do modelo de projeto e executados no código-fonte/código de objeto executável para verificar se o código-fonte está em conformidade com o modelo de projeto.

[025] Algumas realizações podem identificar automaticamente um tipo de modelo de especificação/projeto com base em uma representação intermediária do modelo. Uma ou mais realizações podem reduzir automaticamente o modelo intermediário, onde o modelo reduzido também pode ser mapeado para o modelo intermediário para identificação de modelo. Uma ou mais realizações podem selecionar automaticamente o módulo geração de teste apropriado para gerar o caso de teste com base no resultado de identificação de modelo. Em uma ou mais realizações, selecionar o módulo geração de teste apropriado pode alcançar a eficiência e a eficácia.

[026] A Figura 1 é um exemplo de um sistema de desenvolvimento de software 100 de acordo com algumas realizações. O sistema 100 pode incluir requisitos de sistema 102, um modelo de especificação 104, um módulo de geração de caso de teste automático com base em requisitos 106, um modelo de projeto 108, um módulo de código-fonte 112, um módulo de código de objeto executável 114 e um módulo de análise de cobertura estrutural 124. Como usado no presente documento, “requisitos de sistema”, “requisitos de software” e “requisitos” serão usados de maneira intercambiável.

[027] Em algumas realizações, uma versão em texto de requisitos de sistema 102 a serem atribuídos ao software são adquiridos. A partir desses requisitos 102, o modelo de especificação 104 é desenvolvido. Em uma ou mais realizações, o modelo de especificação 104 pode ser desenvolvido com o uso de uma combinação de tecnologias de modelagem semântica e modelagem gráfica. Outras tecnologias de desenvolvimento de modelo de especificação adequadas podem ser usadas. Em uma ou mais realizações, o modelo de especificação 104 pode ser validado com o cliente por meio de um módulo de validação de cliente 116. Em algumas realizações, o modelo de especificação 104 pode ser analisado e verificado formalmente para exatidão e consistência com um módulo de análise de requisitos formal 118 com o uso de prova de teorema automática. Outros meios adequados de análise e verificação podem ser usados.

[028] Após o modelo de especificação 104 ser validado pelo módulo de validação de cliente 116 e pelo módulo de análise de requisitos formal 118, o modelo de especificação 104 pode ser passado como uma entrada para um time de projeto com base em modelo para criar um modelo de projeto 108. Em uma ou mais realizações, o modelo de projeto pode ser simulado com casos de teste com base em requisitos gerados a partir do modelo de especificação de modo que erros possam ser pegos ao nível de modelo de projeto. Em uma ou mais realizações, o módulo de código-fonte 112 pode ser autogerado a partir do modelo de projeto 108.

[029] Em algumas realizações, o modelo de especificação 104 pode ser usado como uma entrada para os módulo de geração de caso de teste automático com base em requisitos 106 (“módulo de caso de teste”). Casos e procedimentos de teste podem ser automaticamente gerados pelo módulo de caso de teste 106, como será descrito adicionalmente abaixo, e podem, então, ser aplicados ao modelo de projeto 108. Em uma ou mais realizações, o módulo de caso de teste 110 pode ser usado para auxiliar um engenheiro a identificar um código inalcançável e para identificar um vetor de teste que possa executar a seção específica do modelo. Em uma ou mais realizações, casos de teste gerados com o módulo de caso de teste 107 podem ser aplicados ao modelo de projeto 108 e analisados para cobertura estrutural com o modelo de análise de cobertura estrutural 124. O módulo de análise de cobertura estrutural 124 pode identificar lacunas na cobertura de teste dos casos de teste com base em requisitos executados no modelo de projeto, como, funcionalidade não intencional, código morto, requisitos derivados, etc. No caso de requisitos derivados, por exemplo, os casos de teste podem ser gerados automaticamente com o módulo de caso de teste de cobertura de modelo 110 para satisfazer a cobertura estrutural.

[030] Em uma ou mais realizações, os casos de teste também podem ser executados em código-fonte por meio do módulo de código-fonte 112 e em código de objeto executável por meio do módulo de código de objeto executável 114.

[031] Voltando-se às Figuras 2 a 6, em um exemplo de operação de acordo com algumas realizações, a Figura 2 é um diagrama de fluxo de um processo 200. O processo 200 e outros processos descritos no presente documento podem ser realizados com o uso de qualquer combinação adequada de meios de hardware (por exemplo, circuito(s)), de software ou manuais. Em uma ou mais realizações, o sistema 100 é condicionado para realizar o processo 200 de modo que o sistema 100 seja um elemento de propósito especial configurado para realizar operações não realizáveis por um computador ou dispositivo de propósito geral. Um software que incorpora esses processos pode ser armazenado em qualquer meio tangível não transitório que inclui um disco fixo, um disquete , um CD, um DVD, uma unidade Flash ou uma fita magnética. Exemplos desses processos serão descritos abaixo em relação aos elementos do sistema 100, porém as realizações não estão limitadas a isso.

[032] Inicialmente, em S210, um modelo é recebido no módulo de caso de teste 106. O modelo pode ser um dentre um modelo de especificação 104 ou um modelo de projeto 108. Em uma ou mais realizações, com o modelo de especificação 104 e o modelo de projeto 108 prontos, um usuário pode gerar os casos de teste com base em requisitos a partir do modelo de especificação 104 para avaliação no modelo de projeto 108 e pode gerar casos de teste aumentados para satisfazer a cobertura de modelo. Em uma ou mais realizações, os modelos de especificação/projeto 104/108 podem ser escritos em Simulink™/Stateflow™ ou SCADE™. Qualquer outra linguagem de desenvolvimento com base em modelo adequada pode ser usada na escrita dos modelos de especificação/projeto 104/108. Os modelos de especificação/projeto 104/108 podem ser escritos em qualquer outra linguagem adequada. Em uma ou mais realizações, um mapa variável (não mostrado) é recebido em adição aos modelos de especificação 104. Em algumas realizações, o mapa variável pode listar os nomes de variável no modelo de especificação 104 e seus nomes de variável equivalentes no modelo de projeto 108. O mapa variável pode ser proporcionado por pelo menos um dentre um engenheiro e um projetista de requisitos, por exemplo.

[033] Então, em S212, um modelo intermediário 400 (Figura 4) é gerado. Em uma ou mais realizações, uma abordagem de tradução automática pode ser aplicada ao modelo de especificação/projeto 104/108 por meio de um módulo de computador de tradução 302, “tradutor” (Figura 3), para analisar e traduzir o modelo de especificação/projeto 104/108 em um modelo intermediário 400. Em algumas realizações, o modelo intermediário 400 pode ser chamado de um Autômato Finito Estendido de Entrada/Saída (l/O-EFA). Em uma ou mais realizações, o modelo intermediário 400 pode preservar os comportamentos entre as entradas e as saídas dos requisitos observados nos tempos de amostragem. Em uma ou mais realizações, a tradução pode formalizar e automatizar o mapeamento a partir de sequências de computação de modelos de especificação/projeto 104/108 para os caminhos de computação nos modelos (l/O-EFA) intermediários 400 traduzidos. Como usado no presente documento, um caminho de computação é uma sequência de transições que são conectadas. Conforme mostrado na figura 4, pode haver mais de um caminho ou subcaminho de computação para um dado local. Embora a Figura 4 proporcione vários caminhos de computação, o exemplo a seguir focará em uma porção (transição) de dois caminhos diferentes 405a e 405b. Ambos os caminhos começam com uma primeira transição 401. No caminho 405a, a partir da transição 401, o caminho pode continuar através da transição 402, conforme indicado pela seta em negrito, para a transição 403. Como outro exemplo, em vez do caminho 405a continuar a partir de 401 para 402, para 403, o caminho 405b pode continuar a partir da transição 401 para a transição 404, conforme indicado pela seta pontilhada, para a transição 403. Em uma ou mais realizações, o caminho de computação pode descrever os comportamentos de modelo. Como usado no presente documento, uma sequência de computação é uma sequência de computações realizadas pelos modelos de especificação/projeto em um ciclo de tempo. Em algumas realizações, o modelo intermediário extrai e analisa as sequências de computação no modelo de especificação/projeto. Em uma ou mais realizações, o módulo de computador de tradução 302 pode ser a ferramenta de tradução automática SS2EFA em Matlab®. Embora os exemplos descritos no presente documento apresentem uma abordagem de tradução de Simulink™ para l/O-EFA, outras traduções para um autômato podem ser usadas (por exemplo, traduzidas para uma linguagem de modelagem unificada).

[034] Em uma ou mais realizações, os critérios de teste 306 para o modelo de especificação 104 e as lacunas em cobertura de modelo 308 para o modelo de projeto 108 podem ser convertidos em uma representação lógica 502 (Figura 5) e, então, convertidos em objetivos de teste 310 por um módulo conversor 312, “conversor” (Figura 3), e, então, o objetivo de teste 310 é fixado ao modelo intermediário 400 em S214, conforme mostrado na Figura 5. Por exemplo, o módulo conversor 312 pode receber critérios de teste/lacunas em cobertura de modelo como entrada, traduzir ou converter essas informações em uma representação lógica e, então, converter a representação lógica em um objetivo de teste ou representação matemáticos que mapeiam para o modelo intermediário. Em uma ou mais realizações, os objetivos de teste 310 podem definir as metas para um módulo de computador gerador 314, “gerador”, para as quais os modelos são dirigidos. Em uma ou mais realizações, cada objetivo de teste 310 pode ser associado a um caminho de objetivo de teste no modelo intermediário 400 de modo que o modelo intermediário com objetivo de teste 500 seja exibido na Figura 5. Como será descrito adicionalmente abaixo, o módulo de computador gerador 314 analisa o modelo intermediário com objetivo de teste 500 e aplica abordagens de geração de teste automático com base no modelo intermediário traduzido com objetivo de teste 500 para encontrar um conjunto de sequências de entrada- saída, também chamados casos de teste 304, que alcançam ou executam os objetivos de teste (por exemplo, todos os requisitos no modelo de especificação e cobertura ausente para o modelo de projeto). Em uma ou mais realizações, o módulo de caso de teste 106 pode fornecer casos de teste com base em requisitos 304 a partir de uma entrada de modelo de especificação 104 e pode fornecer casos de teste aumentados 304 para cobertura de modelo a partir de uma entrada de modelo de projeto 108. Em uma ou mais realizações, os objetivos de teste 310 podem ser fixados como estados finais no modelo intermediário 500. Em uma ou mais realizações, um objetivo de teste 310 como um estado final pode ser representado como um local (!) com nenhuma borda/seta de saída, conforme mostrado por lf na Figura 5.

[035] Um subgráfico 600 (Figura 6A) é determinado em S216. Em uma ou mais realizações, o subgráfico 600 pode afetar o objetivo. Conforme mostrado na figura 6A, o subgráfico é indicado pelo retângulo pontilhado. Em uma ou mais realizações, o modelo intermediário 400 pode incluir elementos que podem não afetar o objetivo. Por exemplo, o modelo intermediário 400 pode incluir elementos que endereçam vários requisitos e os elementos que podem afetar um requisito podem não afetar outro requisito. O subgráfico 600 pode isolar os elementos relevantes dos elementos irrelevantes, em uma ou mais realizações, para identificar apenas os elementos que afetam o objetivo de teste.

[036] Então, em S218, o modelo intermediário 400 é reduzido (Figura 6B). Em algumas realizações, o tamanho do modelo intermediário 400 pode ser reduzido de modo que o modelo intermediário reduzido (por exemplo, submodelo) inclua apenas a porção do modelo intermediário que está associada ao subgráfico 600. Em uma ou mais realizações, reduzir o tamanho do modelo intermediário pode proporcionar uma sequência menos complexa de computações a serem realizadas pelo módulo de computador gerador 314 para gerar os casos de teste e, por isso, aumentar a eficiência. Em uma ou mais realizações, o modelo é reduzido automaticamente e o modelo reduzido pode ser mapeado para o modelo intermediário 400.

[037] Um tipo de modelo é identificado em S220. Em uma ou mais realizações, o módulo de computador gerador 314 recebe o modelo intermediário reduzido com objetivos de teste 500, analisa o modelo intermediário reduzido e, com base na análise do modelo intermediário reduzido, identifica o tipo de modelo, como será descrito adicionalmente abaixo em relação à Figura 7. Em uma ou mais realizações, o tipo de modelo identificado pode se basear nos tipos de computações (por exemplo, propriedades matemáticas) no modelo intermediário reduzido, por exemplo, o tipo de modelo pode ser um dentre um tipo de modelo variável simbólico/booliana, um tipo de modelo de restrições de número real, um tipo de modelo aritmético não linear, e um tipo de modelo de circuito dinâmico ou de retroalimentação. Outros tipos de modelo adequados podem ser usados.

[038] Após o tipo de modelo ser identificado, um método de geração de teste é selecionado em S222 e um caso de teste é gerado automaticamente com base no tipo de modelo identificado por meio de execução do módulo de computador gerador 314 em S224. Em uma ou mais realizações, o módulo de computador gerador 314 pode analisar o tipo de modelo identificado e gerar os casos de teste por meio de aplicação de um dentre um módulo de verificação de modelo 316, um módulo de solução de restrição 318 ou um módulo de resolução de acessibilidade 320, por exemplo, conforme selecionado pelo módulo de computador gerador 314 com base nos tipos de computações no modelo intermediário por tipo de modelo identificado. Os casos de teste podem ser gerados pelo módulo de computador gerador 314 por meio da execução de outros módulos adequados.

[039] Em uma ou mais realizações, o módulo de verificação de modelo 316 pode ser aplicado a modelos intermediários reduzidos identificados como tipos de modelo variável simbólico/booliana. O módulo de verificação de modelo 316 pode mapear o modelo intermediário reduzido (l/O-EFA) para uma linguagem de verificador de modelo (por exemplo, NuSMV). O módulo de verificação de modelo 316 pode verificar a acessibilidade de cada requisito no modelo de especificação 104 e gerar casos de teste a partir dos contraexemplos em uma ou mais realizações.

[040] Em uma ou mais realizações, o módulo de solução de restrição 318 pode ser aplicado a modelos intermediários reduzidos identificados como tipos de modelo de restrição de número real ou de aritmética não linear. O módulo de solução de restrição 318 pode reunir as restrições de cada requisito no modelo (por exemplo, ao longo dos caminhos para cada objetivo de teste) e aplicar otimização matemática para obter uma sequência de entrada-saída que satisfaz o requisito (por exemplo, objetivo de teste) em algumas realizações.

[041 j Em uma ou mais realizações, o módulo de resolução de acessibilidade 320 pode ser aplicado a modelos intermediários reduzidos identificados como tipos de modelo de circuito dinâmico ou de retroalimentação. O módulo de resolução de acessibilidade 320 pode usar um modelo compacto e solucionar analiticamente as equações dinâmicas para reduzir o espaço de busca de geração de teste para modelos com dinâmica. Em uma ou mais realizações, cada local do modelo compacto pode ser um caminho de computação no modelo intermediário. O módulo de resolução de acessibilidade 320 pode usar a transição no modelo compacto para representar a troca de modo do modelo de um caminho de computação para outro caminho de computação.

[042] Após o caso de teste 304 ser gerado em S224, o caso de teste 304 é exibido em S226. Em uma ou mais realizações, o caso de teste podem estar em um formato de arquivo .sss. O caso de teste pode estar em outros formatos de arquivo adequados. Conforme descrito acima, o caso de teste 304 pode ser usado para verificar e validar se o modelo de projeto satisfaz os requisitos de software ou a implantação (por exemplo, código-fonte/código de objeto) é consistente com o modelo de projeto.

[043] Voltando-se à Figura 7, um exemplo de operação de acordo com algumas realizações, a Figura 7 é um diagrama de fluxo de um processo 700 para identificar um tipo de modelo por S220 do processo 200 mostrado na Figura 2.

[044] Inicialmente, em S710, o modelo intermediário é reduzido por S218. Então, em S712, os caminhos de computação 402 e os caminhos de objetivo de teste são extraídos do modelo intermediário reduzido e analisados. Em uma ou mais realizações, a análise pode determinar se o caminho é válido ou não (por exemplo, representa um comportamento de modelo). Em uma ou mais realizações, os caminhos de computação válidos podem descrever comportamentos de modelo e os caminhos de objetivo de teste podem descrever objetivos de teste. A extração e análise dos caminhos pode proporcionar uma determinação das restrições e dos dados de caminho para cada caminho. Como usado no presente documento, as restrições de caminho podem ser condições de entrada para o caminho de computação; e os dados de caminho podem ser dados realizados ao longo do caminho após o caminho ser inserido. Em uma ou mais realizações, a identificação de tipo de modelo se baseia na identificação das restrições e dos dados de caminho. As restrições e os dados extraídos podem ser identificados em S714. Por exemplo, a Figura 8 exibe uma tabela 800 gerada por 106, que mostra a extração/análise/identificação de caminho para o modelo intermediário 400 mostrado na Figura 4. Em uma ou mais realizações, a tabela 800 pode listar, para cada caminho 802, o predicado de caminho (condição de entrada de caminho) 804, os dados de caminho (atualização de dados de caminho) 806 e as saídas de caminho (valores de saída esperados) 808. Em S716, é determinado se há ou não há aritmética não suportada nas restrições e nos dados de caminho que nenhum dentre o módulo de verificação de modelo 316, o módulo de solução de restrição 318 ou o módulo de resolução de acessibilidade 320 possam suportar. Se há aritmética não suportada em S718, o processo 700 prossegue para S718, e o processo termina e uma mensagem de erro é gerada. Se não há aritmética não suportada em S716, o processo 700 prossegue para S720, e é feita uma determinação se há ou não há aritmética não linear ou números reais nas restrições e nos dados de caminho. Se não há aritmética não linear ou números reais em S720, o processo 700 prossegue para S722, e o módulo de verificação de modelo 316 é aplicado ao modelo intermediário reduzido. Então, em S730, o caso de teste 304 é gerado, conforme descrito acima em relação a S222. Se há aritmética não linear ou números reais em S720, o processo 700 prossegue para S724, e é feita uma determinação se há ou não há equações diferenciais nos dados de caminho. Se em S724 é determinado que não há equações diferenciais ou nem todas as equações diferenciais são suportadas nos dados de caminho, o processo 700 prossegue para S726 e o módulo de solução de restrição 318 é aplicado ao modelo intermediário reduzido. Então, em S730, o caso de teste 304 é gerado, conforme descrito acima em relação a S222. Se em S724 é determinado que não há equações diferenciais não suportadas nos dados de caminho, o processo 700 prossegue para S728 e o módulo de resolução de acessibilidade 320 é aplicado ao modelo intermediário. Então, em S730, o caso de teste 304 é gerado, conforme descrito acima em relação a S222. Em uma ou mais realizações, algumas equações não lineares podem não ser suportadas dependendo da capacidade do módulo de otimização (não mostrado) usado no módulo de solução de restrição 318. Os modelos com essas equações não lineares podem levar a término com mensagem de erro S718.

[045] Voltando-se às Figuras 9 a 11, uma interface de usuário 900 exemplificativa para gerar casos de teste é proporcionada. Em uma ou mais realizações, por exemplo, após um usuário selecionar um modelo para gerar casos de teste (S210) por meio de seleção do botão “escolher modelo” 902, e um mapa variável por meio da aplicação de um botão “escolher mapa variável”(não mostrado) para modelos de especificação, o usuário pode selecionar o tipo de teste para gerar. Em uma ou mais realizações, uma janela de tipo de teste 904 pode ser populada com testes adequados para os modelos de especificação que são usados. Por exemplo, para modelos de especificação, os testes podem ser testes de cobertura de requisito, testes de condição de lógica ou quaisquer outros testes adequados; enquanto para modelos de projeto, os testes podem ser testes MC/DC, testes de cobertura de decisão ou quaisquer outros testes adequados. Em uma ou mais realizações, um teste de cobertura de requisito pode gerar casos de teste para cobrir todos os requisitos; enquanto um teste de condição de lógica pode gerar casos de teste para cobrir todos os requisitos e as condições de lógica em cada requisito. Então, o usuário pode selecionar um botão “gerar testes” 906 para começar o processo 200 descrito acima para gerar casos de teste com base em requisitos com base no tipo de teste selecionado. A Figura 10 mostra que quatro testes foram gerados na janela Resultados 1000. Em particular, há quatro casos de teste com base em requisitos gerados para os quatro requisitos no modelo de especificação. Cada arquivo de caso de teste 1002 pode ser aberto para inspeção selecionando-se o número de ID de Requisito e selecionando-se o botão “abrir arquivo selecionado” 1004. Em uma ou mais realizações, uma janela de status de execução 1006 proporciona o status do módulo de geração de caso de teste automático com base em requisitos 106. Por exemplo, a janela de status de execução 1006 pode exibir uma mensagem indicando que os testes estão sendo gerados em um local específico e, então, que a geração de teste foi concluída. A Figura 11 mostra o caso de teste 1100 gerado para o requisito R1. O caso de teste gerado 1100 pode incluir, em uma ou mais realizações, a descrição do requisito relacionado 1102, um conjunto de variáveis (entrada) monitoradas 1104 (que pode incluir os tipos de nomes, valores e dados) e um conjunto de saída esperada 1106 para a variável (saída) controlada (que pode incluir os tipos de nomes, valores e dados). Uma vez que os casos de teste com base em requisitos são gerados, os mesmos podem ser testados no modelo de projeto. Em uma ou mais realizações, os casos e procedimentos de teste consistem em entradas e valores de saída esperados e podem ser executados contra o modelo de projeto 108 e código-fonte/código de objeto executável para verificar sua conformidade com o modelo de especificação 104. Em uma ou mais realizações, os casos de teste podem ser aplicados ao modelo de projeto e a saída gerada a partir da aplicação pode ser analisada para determinar funcionalidade correta, assim como cobertura estrutural do modelo de projeto.

[046] Observa-se que as realizações descritas no presente documento podem ser implantadas com o uso de qualquer quantidade de configurações de hardware diferentes. Por exemplo, a Figura 12 ilustra uma plataforma de processamento de geração de caso de teste automático 1200 que pode ser, por exemplo, associada ao sistema 100 da Figura 1. A plataforma de processamento de caso de teste automático 1200 compreende um processador de plataforma de geração de caso de teste 1210 (“processador”), como uma ou mais Unidades de Processamento Central (CPUs) disponíveis comercialmente na forma de microprocessadores de circuito integrado único, acoplado a um dispositivo de comunicação 1220 configurado para se comunicar por meio de uma rede de comunicação (não mostrada na Figura 12). O dispositivo de comunicação 1220 pode ser usado para comunicação, por exemplo, com um ou mais usuários. A plataforma de geração de caso de teste automático 1200 inclui adicionalmente um dispositivo de entrada 1240 (por exemplo, um mouse e/ou um teclado para inserir informações sobre variáveis, clustering e otimização) e um dispositivo de saída 1250 (por exemplo, para fornecer e exibir as amostras selecionadas).

[047] O processador 1210 também se comunica com um dispositivo de memória/armazenagem 1230. O dispositivo de armazenagem 1230 pode compreender qualquer dispositivo de armazenagem de informações apropriado, que inclui combinações de dispositivos de armazenagem magnéticos (por exemplo, uma unidade de disco rígido), dispositivos de armazenagem ópticos, telefones móveis e/ou dispositivos de memória semicondutores. O dispositivo de armazenagem 1230 pode armazenar um programa 1212 e/ou uma lógica de processamento de geração de caso de teste automático 1214 para controlar o processador 1210. O processador 1210 realiza instruções dos programas 1212, 1214 e, por isso, opera de acordo com quaisquer das realizações descritas no presente documento. Por exemplo, o processador 1210 pode receber modelos de especificação e/ou de projeto e, então, pode aplicar o módulo de computador de tradução 302 e, então, o módulo de computador gerador 314 por meio das instruções dos programas 1212, 1214 para gerar um caso de teste 304.

[048] Os programas 1212, 1214 podem ser armazenados em um formato compactado, não compilado e/ou criptografado. Os programas 1212, 1214 podem incluir, além disso, outros elementos de programa, como um sistema operacional, um sistema de gerenciamento de base de dados e/ou unidades de dispositivo usadas pelo processador 1210 para fazer interface com dispositivos periféricos.

[049] Como usado no presente documento, informações podem ser “recebidas” de ou “transmitidas” para, por exemplo: (i) a plataforma 1200 de outro dispositivo; ou (ii) uma aplicação de software ou módulo na plataforma 1200 de outra aplicação de software, módulo ou qualquer outra fonte.

[050] Como será entendido pelo versado na técnica, aspectos da presente invenção podem ser incorporados como um sistema, método ou produto de programa de computador. Consequentemente, aspectos da presente invenção podem assumir a forma de uma realização totalmente realizada em hardware, uma realização totalmente realizada em software (inclusive firmware, software residente, microcódigo, etc.) ou uma realização combinando aspectos de software e de hardware que podem todos ser geralmente chamados, no presente documento, de “circuito”, “módulo” ou “sistema”. Além disso, aspectos da presente invenção podem assumir a forma de um produto de programa de computador incorporado em um ou mais meios legíveis por computador tendo, integrado aos mesmos, código de programa legível por computador.

[051] O fluxograma e os diagramas de bloco nas Figuras ilustram a arquitetura, funcionalidade e operação de possíveis implantações de sistemas, métodos e produtos de programa de computador de acordo com várias realizações da presente invenção. Nesse sentido, cada bloco no fluxograma ou nos diagramas de bloco pode representar um módulo, segmento ou porção de código, que compreende uma ou mais instruções executáveis para implantar a(s) função(ões) de lógica especificada(s). Também deve ser observado que, em algumas implantações alternativas, as funções indicadas no bloco podem ocorrer fora da ordem indicada nas figuras. Por exemplo, dois blocos mostrados em sucessão podem, de fato, ser executados de modo substancialmente simultâneo ou os blocos podem, algumas vezes, ser executados na ordem inversa, dependendo da funcionalidade envolvida. Também será observado que cada bloco da ilustração de diagramas de bloco e/ou de fluxograma, e combinações de blocos na ilustração de diagramas de bloco e/ou de fluxograma, pode ser implantado por sistemas com base em hardware de propósito especial que realizam as funções ou atos especificados ou combinações de hardware de propósito especial e instruções de computador.

[052] Deve ser observado que quaisquer dos métodos descritos no presente documento podem incluir uma etapa adicional de proporcionar um sistema que compreende módulos de software distintos incorporados em um meio de armazenagem legível por computador; os módulos podem incluir, por exemplo, quaisquer ou todos os elementos ilustrados nos diagramas de bloco e/ou descritos no presente documento; a título de exemplo e não limitação, um módulo de computador de tradução e um módulo de computador gerador. As etapas do método podem, então, ser conduzidas com o uso dos módulos e/ou submódulos de software distintos do sistema, conforme descrito acima, que são executados em um ou mais processadores de hardware 1210 (Figura 12). Adicionalmente, um produto de programa de computador pode incluir um meio de armazenagem legível por computador com código adaptado para ser implantado para conduzir uma ou mais etapas do método descritas no presente documento, incluindo a provisão do sistema com os módulos de software distintos.

[053] Esta descrição escrita usa exemplos para revelar a invenção, inclusive as realizações preferenciais, e também possibilita que qualquer pessoa versada na técnica pratique a invenção, inclusive produza e use quaisquer dispositivos ou sistemas e execute quaisquer métodos incorporados. O escopo patenteável da invenção é definido por meio das reivindicações, e pode incluir outros exemplos que ocorram àqueles versados na técnica. Tais outros exemplos são planejados para estarem dentro do escopo das reivindicações se possuírem elementos estruturais que não os diferenciem a partir da linguagem literal das reivindicações, ou se eles incluírem elementos estruturais equivalentes com diferenças insubstanciais a partir das linguagens literais das reivindicações. Aspectos das várias realizações descritas, assim como outros equivalentes conhecidos para cada um de tais aspectos, podem ser misturados e combinados por um indivíduo de habilidade comum na técnica para construir realizações e técnicas adicionais, de acordo com princípios desse pedido.

[054] Os versados na técnica compreenderão que várias adaptações e modificações das realizações descritas acima podem ser configuradas sem se afastar do escopo e do espírito das reivindicações. Por esse motivo, deve ser entendido que as reivindicações podem ser praticadas de outro modo além de como especificamente descritas no presente documento.

Claims

1. SISTEMA, caracterizado pelo fato de que compreende: um dispositivo de comunicação operacional para se comunicar com um usuário para obter um ou mais requisitos associados a um modelo para um módulo de geração de caso de teste; um módulo de computador de tradução para receber o modelo, armazenar o modelo e gerar um modelo intermediário; um módulo de computador gerador para receber o modelo intermediário, armazenar o modelo intermediário e gerar pelo menos um caso de teste; uma memória para armazenar instruções de programa; pelo menos um processador de plataforma de geração de caso de teste, acoplado à memória e em comunicação com o módulo de computador de tradução e o módulo de computador gerador, operacional para executar instruções de programa para: transformar o modelo em um modelo intermediário executando-se o módulo de computador de tradução; identificar um tipo de modelo associado ao modelo intermediário com base em uma análise do modelo intermediário executando-se o módulo de computador gerador; selecionar um método de geração de teste com base na análise do tipo de modelo identificado executando-se o módulo de computador gerador; e gerar pelo menos um caso de teste para uso em validação e verificação de software.

2. SISTEMA, de acordo com a reivindicação 1, caracterizado pelo fato de que o modelo é um dentre um modelo de especificação e um modelo de projeto.

3. SISTEMA, de acordo com a reivindicação 1, caracterizado pelo fato de que cada requisito inclui uma ou mais variáveis de entrada e uma ou mais variáveis de saída.

4. SISTEMA, de acordo com a reivindicação 3, caracterizado pelo fato de que o pelo menos um caso de teste gerado inclui uma descrição do requisito, um conjunto de variáveis de entrada e um conjunto de saída esperada, em que o conjunto de saída esperada se baseia nas uma ou mais variáveis de saída.

5. SISTEMA, de acordo com a reivindicação 1, caracterizado pelo fato de que o tipo de modelo é pelo menos um dentre um tipo de modelo variável simbólico, um tipo de modelo de número real, um tipo de modelo aritmético não linear e um tipo de modelo de circuito de retroalimentação.

6. SISTEMA, de acordo com a reivindicação 1, caracterizado pelo fato de que o modelo intermediário preserva um ou mais comportamentos por um tempo de amostragem associado a partir do pelo menos um modelo.

7. SISTEMA, de acordo com a reivindicação 6, caracterizado pelo fato de que o módulo de computador de tradução mapeia uma ou mais sequências de computação do pelo menos um modelo para um ou mais caminhos de computação no modelo intermediário.

8. SISTEMA, de acordo com a reivindicação 7, caracterizado pelo fato de que compreende adicionalmente um módulo conversor operacional para converter um ou mais critérios de teste em um ou mais objetivos de teste, em que cada objetivo de teste está associado a um caminho de objetivo de teste.

9. SISTEMA, de acordo com a reivindicação 8, caracterizado pelo fato de que os um ou mais objetivos de teste são fixados no modelo intermediário.

10. SISTEMA, de acordo com a reivindicação 9, caracterizado pelo fato de que os caminhos de computação descrevem comportamentos de modelo e os caminhos de objetivos de teste descrevem objetivos de teste.

11. SISTEMA, de acordo com a reivindicação 8, caracterizado pelo fato de que o módulo de computador gerador é operacional para gerar uma tabela que inclui uma ou mais restrições de caminho e um ou mais dados com base nos caminhos de computação e nos caminhos de objetivo de teste.

12. SISTEMA, de acordo com a reivindicação 11, caracterizado pelo fato de que o módulo de computador gerador é operacional para identificar os tipos de computações no modelo intermediário.

13. SISTEMA, de acordo com a reivindicação 12, caracterizado pelo fato de que o módulo de computador gerador é operacional para selecionar um dentre um módulo de verificação de modelo, um módulo de solução de restrição e um módulo de resolução de acessibilidade para aplicar ao modelo intermediário para gerar casos de teste com base no tipo de computação.

14. SISTEMA, de acordo com a reivindicação 1, caracterizado pelo fato de que o modelo intermediário é reduzido para incluir apenas uma porção do modelo intermediário associado a um dado objetivo.

15. MÉTODO, caracterizado pelo fato de que compreende: receber um ou mais requisitos associados a um modelo para geração de caso de teste; transformar o modelo em um modelo intermediário pela execução de um módulo de computador de tradução; identificar um tipo de modelo associado ao modelo intermediário com base em uma análise do modelo intermediário pela execução de um módulo de computador gerador; selecionar um método de geração de teste com base no tipo de modelo identificado pela execução do módulo de computador gerador; e gerar pelo menos um caso de teste para uso em validação e verificação de software.

16. MÉTODO, de acordo com a reivindicação 15, caracterizado pelo fato de que o tipo de modelo é pelo menos um dentre um tipo de modelo variável simbólico, um tipo de modelo de número real, um tipo de modelo aritmético não linear e um tipo de modelo de circuito de retroalimentação.

17. MÉTODO, de acordo com a reivindicação 15, caracterizado pelo fato de que o modelo é um dentre um modelo de especificação e um modelo de projeto.

18. MÉTODO, de acordo com a reivindicação 15, caracterizado pelo fato de que compreende adicionalmente: converter um ou mais critérios de teste em um ou mais objetivos de teste.

19. MÉTODO, de acordo com a reivindicação 15, caracterizado pelo fato de que compreende adicionalmente: determinar um tipo de computação no modelo intermediário.

20. MÉTODO, de acordo com a reivindicação 19, caracterizado pelo fato de que compreende adícionalmente: selecionar um dentre um módulo de verificação de modelo, um módulo de solução de restrição e um módulo de resolução de acessibilidade para aplicar ao modelo intermediário para gerar casos de teste com base no tipo de computação.