BR102019004568A2

BR102019004568A2 - Método para geração automática de casos de teste baseada em requisitos, meio legível por computador não transitório e sistema para geração automática de casos de teste baseados em requisitos

Info

Publication number: BR102019004568A2
Application number: BR102019004568-0A
Authority: BR
Inventors: Meng Li; Augusto Marasca De Conto; Han Yu; Italo Romani de Oliveira; Kit Siu; Michael R. Durling
Original assignee: General Electric Company
Priority date: 2015-11-20
Filing date: 2019-03-08
Publication date: 2019-10-01
Also published as: GB2545800A; CN107066375A; CA3035176A1; US20180196739A1; US9940222B2; FR3044126A1; CN110245067B; CA2948250A1; FR3044126B1; JP2017097862A; CN114996115A; CA2948250C; JP6307140B2; BR102016026988A2; CN110245067A; CN107066375B; US20170147482A1

Abstract

método para geração automática de casos de teste baseada em requisitos, meio legível por computador não transitório e sistema para geração automática de casos de teste baseados em requisitos um método de geração de casos de teste baseados em requisitos automatizados inclui a construção de um modelo de arquitetura de software derivado do modelo de informações arquitetõnicas de projeto de software, alocando modelos de requisitos em blocos/ operadores de modelo de arquitetura de software, e gerando casos de teste com base em requisitos a nível componente da arquitetura de software configurados para serem executáveis em diferentes níveis na arquitetura de software. o método de geração de casos de teste baseados em requisitos a nível de componente inclui a recepção de uma arquitetura de software, junto com os modelos de requisitos alocados representados no diagrama de fluxo de dados hierárquico, selecionando um dos componentes de software, construindo um modelo de teste intermediário com base no componente selecionado anexando automaticamente a pelo menos um dos objetivos ou restrições de teste para os blocos/ operadores de modelo de arquitetura de software correspondentes com base na estratégia de teste selecionada e geração de casos de teste humanos e legíveis por máquina com o gerador de teste para posterior conversão automática para testar artefatos executáveis e de revisão de teste. um sistema e um meio não transitório legível por computador para implementar o método também são divulgados.

Description

MÉTODO PARA GERAÇÃO AUTOMÁTICA DE CASOS DE TESTE BASEADA EM REQUISITOS, MEIO LEGÍVEL POR COMPUTADOR NÃO TRANSITÓRIO E SISTEMA PARA GERAÇÃO AUTOMÁTICA DE CASOS DE TESTE BASEADOS EM REQUISITOS”

Reivindicação de Prioridade [001] Este pedido de patente reivindica o benefício de prioridade como uma continuação em parte, sob 35 U.S.C. § 120, para o Pedido de Patente US N° 14/947.633, apresentado em 20 de novembro de 2015, intitulado “SISTEMA E MÉTODO PARA GERAÇÃO DE CASOS DE TESTE BASEADA EM REQUISITOS DE SEGURANÇA CRÍTICA DE SOFTWARE AUTOMATIZADO” (agora Patente US No. TBD; emitida no DIA do mês, 2018), cuja descrição completa é aqui incorporada por referência.

Antecedentes da Invenção [002] O software crítico de segurança, como software de aviação, é exigido peios padrões de certificação (por exemplo, DO-178 BZ C para software de aviação) para ser estritamente verificado em relação aos objetivos da certificação. O teste é uma parte essencial do processo de verificação. Geração manual de casos de teste a partir dos requisitos é difícil e consome muito tempo, especialmente com softwares grandes e complexos.

[003] Casos de teste gerados automaticamente eZ ou procedimentos de teste derivados a partir dos requisitos de software de alto nível podem ajudar a reduzir o custo introduzido pelas atividades manuais de geração e revisão de casos de teste. Esses casos de teste e/ ou procedimentos de teste gerados a partir das especificações podem ser executados nas implementações de projeto de baixo nível associadas através de um condutor de teste.

[004] Ferramentas e/ ou modelos de teste convencionais não são capazes de gerar casos de teste baseados em requisitos em diferentes

2/17 níveis no modelo de projeto. Os casos de teste gerados por ferramentas convencionais não podem ser executados diretamente em componentes em vários níveis no projeto.

Breve Descrição dos Desenhos [005] A Figura 1 descreve um sistema para geração de casos de teste automática baseados em requisitos, de acordo com formas de realização;

[006] A Figura 2 descreve um processo para o teste de software de acordo com formas de realização;

[007] Figuras 3A-3D ilustram um modelo de arquitetura de software automaticamente derivado de um projeto de software de acordo com formas de realização;

[008] A Figura 4 descreve um processo para geração de caso de teste à nível de componente de acordo com formas de realização;

[009] A Figura 5 ilustra um modelo de requisito de acordo com formas de realização;

[0010] A Figura 6 descreve um modelo de requisito com objetivos do teste em anexo, em conformidade com formas de realização;

[0011] A Figura 7 ilustra um modelo de cobertura de condição lógica com objetivos de teste anexos de acordo com formas de realização;

[0012] As Figuras 8A-8B ilustram um modelo de disfarce de entrada com os objetivos do teste em anexo, em conformidade com formas de realização;

[0013] A Figura 9 ilustra um processo de geração e revisão de script de teste de acordo com as formas de realização;

[0014] A Figura 10 ilustra um projeto de arquitetura de software exemplificativo e a informação de rastreabilidade de requisitos associada de acordo com formas de realização;

[0015] A Figura 11 ilustra um exemplo de script de teste de nível

3/17 de unidade, de acordo com formas de realização; e [0016] A Figura 12 descreve um script de teste de nível de integração exemplificativo de acordo com formas de realização.

Descrição da Invenção [0017] De acordo com as formas de realização, os sistemas e métodos criam automaticamente um modelo de arquitetura de software a partir da arquitetura de projeto de software, junto com modelos de exigência para automatizar a geração de casos de teste com base em requisitos de arquitetura de vários níveis com base no modelo de arquitetura de software proposto.

[0018] De acordo com as formas de realização, o modelo de arquitetura de software e sua alocação de requisitos são construídos usando uma ferramenta de desenvolvimento baseado em modelo (MBD) com a representação de um diagrama de fluxo de dados hierárquico. Ao contrário de ferramentas MBD convencionais, que são tradicionalmente utilizadas para o projeto de baixo nível, uma ferramenta que contém MBD cria automaticamente o modelo de arquitetura de software a partir da arquitetura de software e gera casos de teste correspondentes para os requisitos de nível de sistema ou de alto nível.

[0019] Os sistemas e métodos das formas de realização podem implementar a geração de casos de teste baseados em requisitos a nível de componente para gerar automaticamente casos de teste para componentes em diferentes níveis na arquitetura de software.

[0020] A Figura 1 ilustra o sistema (100) para geração automática de casos de teste baseados em requisitos de acordo com formas de realização. O sistema (100) inclui o processador de controle (110), que executa as instruções do computador (131) para controlar o funcionamento do sistema e dos seus componentes. As instruções executáveis podem ser armazenadas no armazém de dados (130), que também pode armazenar dados acessados e

4/17 gerados pelo sistema. O processador de controle (110) pode estar localizado em um computador, ou em um servidor, e interligado aos vários componentes através da ligação de comunicação (120). A ligação de comunicação pode ser um barramento interno, uma rede de comunicação eletrônica ou semelhante. O sistema (100) pode gerar casos de teste do sistema e/ ou requisitos de alto nível (132) do software crítico de segurança.

[0021] A Figura 2 descreve o processo (200) para o teste de software automatizado, de acordo com formas de realização. O processo (200) obtém o modelo de arquitetura de software (134) a partir do modelo de projeto de software. O modelo de arquitetura de software é construído, na etapa (205), em ambiente de ferramenta de desenvolvimento baseado em modelo (150) com base em informações de arquitetura do modelo de projeto. Este modelo de arquitetura de software pode ser criado automaticamente de acordo com algumas implementações. Os modelos de requisitos são alocados, na etapa (210), em diferentes módulos no modelo de arquitetura de software, conectando as variáveis monitoradas/ controladas correspondentes (por exemplo, Figura 1: VAR1-VAR19) com as portas de entrada/ saida do componente. De acordo com algumas formas de realização, na etapa (205), podem ser adicionadas portas de entrada para todas as variáveis de saída nos modelos de requisitos. Ao adicionar portas de entrada para todas as variáveis de saída, o gerador de casos de teste pode gerar entradas e saídas esperadas para os casos de teste em uma execução.

[0022] A unidade geradora de casos de teste a nível de componente (140) pode usar o modelo de arquitetura de software com requisitos alocados para gerar, na etapa (215), casos de teste baseados em requisitos de nível de unidade/ módulo. A unidade geradora de caso de teste gerador (140) também pode gerar, na etapa (220), casos de teste de nível de integração para verificar se o componente ou integração de código está em

5/17 conformidade com os requisitos alocados.

[0023] As Figuras 3A-3D ilustram o modelo de arquitetura de software (300) construído como um diagrama de fluxo de dados hierárquico com base na arquitetura de projeto de software, de acordo com formas de realização. Cada componente Componentel, Componente2, Componente3, Componente4 no projeto de software é um bloco/ operador no modelo de arquitetura de software com portas de entrada e saída. Blocos/ operadores no modelo de arquitetura de software estão conectados uns com os outros e podem ter múltiplas camadas de sub-blocos/ sub-operadores. Os modelos de requisitos REQ12, REQ13, REQ14, REQ15 são alocados no modelo de arquitetura de software e conectados às portas de entrada e saída. O processo de construção é automático, sistemático e modular. O fluxo de dados hierárquico fornece boa visualização e fácil rastreabilidade, desde os requisitos até o projeto do software.

[0024] A Figura 4 ilustra o processo (400) para geração de caso de teste à nível de componente de acordo com formas de realização. O processo (400) baseia-se em um modelo de arquitetura de software recebido, criado automaticamente na etapa (405), na forma de um diagrama de fluxo de dados hierárquico com modelos de requisitos alocados. Um, ou mais, dos componentes de software no projeto do software é selecionado na etapa 410, com base no nível de geração de teste, e o modelo de arquitetura de software de bloco / operador correspondente é utilizado para geração de casos de teste. Um modelo de teste intermediário é construído, na etapa 415, com base no componente selecionado anexando as restrições de teste e os objetivos de teste ao bloco/ operador do modelo de arquitetura de software correspondente. Os objetivos do teste são anexados para satisfazer determinados critérios de cobertura no nível de requisitos, como cobertura de requisitos (por exemplo, todos os requisitos são ativados), cobertura de condição lógica (por exemplo,

6/17 condições lógicas nos requisitos são ativadas em determinado nível) etc. As restrições de teste estão ligadas ao modelo para restringir as faixas de variáveis monitoradas/ controladas e para assegurar que os casos de teste gerados não violem os requisitos.

[0025] As estratégias de geração automática de casos de teste (isto é, para anexar os objetivos do teste e as restrições) pode ser baseadas na forma geral de um requisito. Em linguagem natural estrutural em Português, a forma de um requisito pode ser expressa como:

<expressão antecedente> implica <expressão consequente>, onde <expressão antecedente> é uma expressão lógica em variáveis monitoradas;

e <expressão consequente> é uma expressão lógica em variáveis controladas.

[0026] A Figura 5 ilustra um modelo de requisito (500) (quando expressa em Simulink) de acordo com formas de realização. O modelo de requisito inclui a expressão antecedente (510) e a expressão consequente (520). Estas expressões são fornecidas ao bloco lógico (530), que implica o sinal de saída (540) com base nos estados das expressões (isto é, A ==> B). Para que o requisito seja mantido, o sinal de saida deve ser 1 ou “verdadeiro”. A unidade geradora de caso de teste automático (140) recebe e, a partir dela, gera casos de teste, de acordo com uma ou mais estratégias (por exemplo, estratégia de cobertura de requisitos, estratégia de cobertura condição lógica, estratégia de disfarce de entrada, estratégia de análise de integridade de dados, estratégia de evento, estratégia lista, estratégia de decomposição e equação, estratégia de classe de equivalência, a estratégia de análise de valor limite, estratégia de robustez, estratégia de temporização, etc.). As formas de realização não são tão limitadas e outras estratégias para geração de casos de teste estão dentro da contemplação desta invenção.

7/17 [0027] A estratégia de cobertura de requisitos inclui, para cada requisito, gerar um caso de teste, onde o requisito deve ser satisfeito com a expressão antecedente sendo verdadeira. Isso é feito inserindo os objetivos e restrições de teste e executando um mecanismo de geração de testes que pode orientar as sequências de entrada para alcançar os objetivos do teste.

[0028] A título de exemplo, a inserção de um objetivo de teste pode ser feita usando blocos de objetivo de teste e de condição de teste de uma biblioteca de blocos de verificador de projeto comercial na ferramenta de desenvolvimento baseada em modelo selecionada (por exemplo, blocos Simulink Design Verifier disponíveis no Simulink). O mecanismo de geração de testes pode ser usado para direcionar as entradas para atingir os objetivos do teste. A Figura 6 ilustra o modelo de requisito (600) com objetivos de teste anexos de acordo com formas de realização. O bloco de Objetivo de Teste (610) (anotado com um “O” dentro de um círculo), é analisado pelo verificador de projeto para encontrar uma combinação de atribuições de valores de variáveis VAR21, VAR22 que causam sua expressão antecedente, que é do tipo booleano, ser verdade. O bloco de condições de teste (620) (anotado com um “C dentro de um círculo), faz com que o verificador de projeto mantenha a saída do bloco “implicações como verdadeira. Um verdadeiro sinal de saída do bloco “implicações é uma indicação de que o requisito REQ27 está satisfeito. As atribuições de valor para as variáveis monitoradas e controladas são geradas automaticamente pelo verificador de projeto.

[0029] Uma estratégia de cobertura de condição lógica (LCC) pode ser implementada para alcançar uma cobertura funcional das condições de equação lógica. Cada condição dentro de uma equação lógica demonstra ter um efeito no resultado da equação lógica, variando apenas aquela condição e mantendo fixo para todos os outros que poderíam afetar o resultado. Considere os exemplos na Tabela 1, que descreve a cobertura da condição

8/17 lógica para duas variáveis, em que dois valores booleanos (a e b) são as condições para os operadores booleanos listados. A Tabela 1 indica se um caso de teste é necessário para atingir cobertura LCC ( ) ou não ( ). Quando a expressão antecedente possui um desses operadores, os casos de teste são gerados para cada uma das combinações correspondentes marcadas com ( ), e isso é generalizável para qualquer número de operandos.

Tabela 1

Operador Booleano	Caso de Teste (T = Verdadeiro, F = Falso)
	TT	TF	FT	FF
a E b
a OUb
a NE b
a NOU b
aXOUb
a XNOUb

[0030] A Figura 7 ilustra o modelo de cobertura de condições lógicas (700) com objetivos de teste anexos de acordo com formas de realização. Este modelo LCC é baseado no modelo de requisito (600) com um padrão de objetivo de teste adicional e blocos de condição (710, 720, 730). Para gerar os casos de teste, os blocos de objetivo de teste são anexados de acordo com os operadores booleanos utilizados e respectivos casos na Tabela 1. Depois de executar o mecanismo de geração de teste, um conjunto de casos de teste é gerado para satisfazer a cobertura da condição lógica. Cada caso de teste gerado também é examinado para descobrir quais requisitos ele ativa'’ ____ativação significa que o sinal de saída da porta de Satisfação (740) deve ser 1 ou “verdadeiro”.

9/17 [0031] Uma estratégia de disfarce de entrada pode alcançar Condição Modificada/ Cobertura de Decisão disfarçada (MC/ DC), O disfarce MC/ DC atende a definição de efeito independente, garantindo os mesmos casos de teste mínimos em cada operador lógico como uma causa única, e é aceitável para atender ao objetivo MC/ DC de padrões de desenvolvimento de software crítico para segurança (por exemplo, DO-178 B/ C). O disfarce se refere ao conceito de que entradas especificas a uma construção lógica podem ocultar o efeito de outras entradas na construção. Por exemplo, uma entrada falsa para um operador E disfarça todas as outras entradas, e uma entrada verdadeira para um operador OU disfarça todas as outras entradas. A abordagem de disfarce para MC/ DC permite que mais de uma entrada seja alterada em um par independente, desde que a condição de interesse seja mostrada como a única condição que afeta o valor do resultado da decisão. Entretanto, a análise da lógica interna da decisão é necessária para mostrar que a condição de interesse é a única condição que faz com que o valor do resultado da decisão mude.

[0032] As Figuras 8A-8B descrevem a estratégia de modelo de disfarce de entrada (800) com objetivos de teste anexos em acordo com as formas de realização. Cada sub-expressão ilustrada no modelo de disfarce de entrada (800) corresponde a um caminho de sinal/ bloco que começa em uma condição de entrada da expressão antecedente, envolvendo uma variável monitorada VAR23, VAR24, VAR25 e termina no sinal que ilustra o resultado da expressão monitorada. A partir deste modelo, os casos de teste podem ser gerados automaticamente, associados aos requisitos REQ28 pela unidade geradora de caso de teste automático (140) e traduzidos para um script de teste de saída.

[0033] A estratégia de geração de testes de disfarce de entrada anexa os objetivos de teste de acordo com as seguintes etapas:

10/17 [0034] Para cada proposição básica (condição de entrada) da expressão antecedente, obter o conjunto S de todas as sub-expressões que contenham essa proposição, exceto a proposição em si. Então, para cada expressão no conjunto S: (1) se a operação de nível superior da sub-expressão for uma porta OU, substitui essa expressão por sua negação em S; (2) cria uma expressão e, que é o conjunto de todas as expressões em S e a proposição básica de cima; e (3) criar um objetivo do teste que deve fazer expressão e verdadeira.

[0035] Uma estratégia de análise de completude de dados pode analisar uma ou mais variáveis que aparecem no requisito e seleciona objetivos de teste para testar diferentes pontos dentro do intervalo físico ou funcional das variáveis particulares. A seleção dos objetivos do teste pode ser baseada, por exemplo, no tipo de variável. Em uma forma de realização, variáveis numéricas poderíam ser testadas em seu mínimo, máximo, limites, etc.; e enumeradas e variáveis booleanas podem ser testadas em todos os valores possíveis e/ ou estados.

[0036] Uma estratégia de evento pode garantir que cada evento possa ser acionado pelo menos uma vez. Essa estratégia também pode verificar se um evento não é acionado continuamente. Os casos de teste gerados e procedimentos podem acionar determinados eventos e verificar se as saídas com outras condições de entrada permanecem constantes.

[0037] Uma estratégia de lista pode analisar variáveis de lista e operadores que aparecem no requisito e seleciona objetivos de teste para testar diferentes propriedades de listas. Por exemplo, essa estratégia pode determinar se as operações de lista ocorrem em posições diferentes das listas e garantir que cada variável de lista seja testada pelo menos em um comprimento de lista mínimo e máximo.

[0038] Uma estratégia de decomposição e equação pode analisar

11/17 funções e/ ou equações dentro do requisito. Estas funções e/ ou equações podem ser indefinidas em algumas implementações. Objetivos de teste podem ser selecionados através da análise dos parâmetros de entrada e/ ou de saída das funções ou equações, e pontos propensos a erro nas funções ou equações definidas.

[0039] Uma estratégia de classe de equivalência, uma estratégia de análise de valor limite, e uma estratégia de robustez cada uma pode analisar desigualdades no requisito e selecionar objetivos de teste com base nas partições de classe de equivalência que podem ser induzidas pelas desigualdades. Uma estratégia de classe de equivalência pode selecionar um ou mais objetivos de teste para cada classe de equivalência normal; uma estratégia de análise de valor limite pode selecionar um ou mais objetivos de teste nos limites entre cada duas classes de equivalência; e uma estratégia de robustez pode selecionar um ou mais objetivos de teste para as classes de equivalência anormais.

[0040] Uma estratégia de temporização pode analisar um ou mais operadores de temporização no requisito e selecionar os objetivos de teste para testar diferentes pontos no intervalo de tempo - como, por exemplo, um acionador principal e/ ou um acionador de atraso. Os eventos podem ser levados em consideração para que os eventos nem sempre sejam acionados no intervalo de tempo.

[0041] Com referência novamente à Figura 4, depois da fixação das restrições de teste e processo de objetivos do teste (400) continua com a unidade geradora de caso de teste (140) gerando caso de teste (136), na etapa (420). A unidade geradora de caso de teste pode realizar verificação de modelo, demonstração de teoremas, solução de restrição e métodos de resolução de acessibilidade no modelo de teste intermediário para gerar os casos de teste, de modo a satisfazer os objetivos do teste e/ ou detectar

12/17 objetivos do teste não alcançáveis.

[0042] A verificação de modelo e o teorema que fornecem métodos cada um pode utilizar ferramentas de métodos formais que são, respectivamente, com base em verificação de modelo ou teorema provando técnicas que verificam a satisfação da negação dos objetivos de teste contra os requisitos. Se não estiver satisfeito, um contraexemplo pode ser gerado, o que pode ser usado para gerar casos de teste; Se estiver satisfeito, o objetivo do teste em particular é inacessível.

[0043] O método de resolução de restrições pode usar solucionadores de restrições e/ ou ferramentas de otimização para resolver as restrições no objetivo do teste para encontrar uma solução viável como um caso de teste. Se as restrições forem identificadas como inviáveis, o objetivo do teste correspondente é inacessível.

[0044] O método de resolução de capacidade pode modelar um conjunto de requisitos como um modelo híbrido que combina transições e dinâmicas discretas (se os requisitos forem com estado (stateful)). O modelo pode então ser analisado para encontrar um caminho viável a partir das condições iniciais para atingir o objetivo do teste, onde as dinâmicas são aproximadas e/ ou analiticamente resolvidas durante a descoberta do caminho. Se um caminho viável for identificado, ele pode ser usado para gerar casos de teste; se nenhum caminho viável puder atingir o objetivo do teste, o objetivo do teste será identificado como inalcançável.

[0045] Com referência novamente à Figura 4, os casos de teste gerados são traduzidos, na etapa (425), em scripts de teste para execução de teste e artefatos de revisão de teste para certificação. A vantagem do método de geração de teste a nível de componente é que o método é flexível para gerar automaticamente casos de teste baseados em requisitos para componentes em diferentes níveis na arquitetura de software para obter os

13/17 critérios de cobertura apropriados no nível dos requisitos. De acordo com as formas de realização, os casos de teste podem ser gerados aplicáveis a qualquer teste de nível de unidade/ módulo, bem como teste de nível de integração.

[0046] A Figura 9 ilustra o processo (900) para geração de script de teste e testa a revisão de artefato de acordo com as formas de realização. O formato intermediário (905) gerado pelo processo (900) pode ser lido por humanos e/ ou máquinas. O processo (900) opera nos casos de teste em nível de componente descritos acima. Um formato intermediário é gerado, na etapa (905), a partir dos casos de teste. Este formato intermediário pode indicar as informações de entrada e saída esperadas. O formato intermediário também pode indicar os requisitos para os quais o caso de teste é rastreado, o objetivo de teste que o caso de teste está atendendo e a referência da qual o objetivo de teste é derivado. As informações intermediárias podem ser usadas para realizar, manualmente ou automaticamente, revisões de teste. Artefatos de certificação são gerados, na etapa (910), a partir das informações intermediárias. As informações intermediárias podem ser usadas para gerar, scripts de teste executáveis na etapa (915), adequados para execução em diferentes ambientes de teste. Os scripts de teste também podem ser gravados automaticamente, etapa (920), para requisitos e ferramentas de gerenciamento de teste (por exemplo, IBM® Rational® DOORS®).

[0047] Coletivamente, as Figuras 10 a 13 ilustram uma ilustração de uma implementação de ponta a ponta de acordo com formas de realização. A Figura 10 ilustra o modelo de projeto de arquitetura de software exemplificativo (1000) e as informações de rastreabilidade de requisitos associadas de acordo com formas de realização. O modelo de arquitetura de software pode ser construído (Figura 2, na etapa (205)) como um modelo Simulink (Figuras 3A-3D). Cada bloco no projeto de arquitetura de software de

14/17 modelo de projeto de software é convertido em um bloco no modelo de arquitetura de software em Simulink com a mesma interface e informações de arquitetura. Cada bloco no modelo de arquitetura de software também é alocado com um conjunto de modelos de requisitos com base nas informações de rastreabilidade de requisitos da Figura 10. Por exemplo, na Figura 3D, quatro modelos de requisitos (1010) são alocados ao componente2 com base nas informações da Figura 10. Da mesma forma, o bloco (1020) indica a informação de rastreabilidade de requisitos ao componentel; o bloco (1030) indica a informação de rastreabilidade de requisitos para o componente3; e o bloco (1040) indica a informação de rastreabilidade de requisitos para o componente4. O modelo de arquitetura de software ilustrado nas Figuras 3A3D é então usada para gerar casos de teste baseados em requisitos em diferentes níveis na arquitetura de software.

[0048] Um usuário pode selecionar o bloco “Componente2” (Figura 4, etapa (410)) para gerar casos de teste neste nível de unidade e selecionar a estratégia de teste de disfarce de entrada. De acordo com formas de realização, os objetivos de teste e os blocos de restrições serão ligados automaticamente a todos os modelos de requisitos dentro do bloco “componente2 na etapa (415). Depois de chamar o Simulink Design Verifier na etapa (420) e traduzir os casos de teste na etapa (425), os casos de teste que satisfazem todos os objetivos de teste e restrições para a estratégia de teste de disfarce de entrada serão gerados.

[0049] A Figura 11 ilustra um script de teste de nível de unidade exemplificativo (1100) de acordo com formas de realização. Este script de teste de nível de unidade é um exemplo de casos de teste gerados no nível de unidade para “componente2. O caso de teste é gerado para ser capaz de executar no ambiente de teste SCADE no bloco “componente2” no projeto. Um usuário pode alternativamente, selecionar o bloco de nível de integração que

15/17 inclui o componente 1-4 na Figura 4, na etapa (410), para gerar casos de teste de nível de integração. De acordo com formas de realização, os objetivos de teste e os blocos de restrições são automaticamente ligados a todos os modelos de requisitos dentro do bloco de nível de integração na etapa (415). Depois de chamar o Simulink Design Verifier na etapa (420) e traduzir os casos de teste na etapa (425), os casos de teste que satisfazem todos os objetivos de teste e restrições para a estratégia de teste de disfarce de entrada serão gerados.

[0050] A Figura 12 descreve um script de teste de nível de integração exemplificativo (1200) de acordo com formas de realização. Este script de teste é um exemplo para os casos de teste de nível de integração gerados. O caso de teste é gerado para ser capaz de executar no ambiente de teste SCADE no bloco de nível de integração no projeto.

[0051] De acordo com as formas de realização, um diagrama de fluxo de dados hierárquico (isto é, modelo de arquitetura de software junto com modelos de requisitos) é criado automaticamente para capturar requisitos e informações de projeto. Esse diagrama de fluxo de dados hierárquico é usado para gerar casos de teste baseados em requisitos em diferentes níveis na arquitetura de software. De acordo com as formas de realização, as informações de projeto do sistema são usadas para construir o diagrama de fluxo de dados hierárquico, onde os modelos de requisitos são alocados dentro dos módulos do diagrama de fluxo de dados hierárquicos. As alocações de requisitos são baseadas na informação de rastreabilidade de requisitos de módulo a partir da informação de projeto. Os objetivos e restrições de teste podem ser anexados ao modelo de arquitetura de software de acordo com uma estratégia de teste selecionada pelo usuário. A geração automática de casos de teste é baseada no diagrama de fluxo de dados hierárquicos para gerar casos de teste baseados em requisitos em diferentes níveis na arquitetura de projeto que atendem aos

16/17 objetivos e restrições de teste. Os casos de teste gerados podem ser executados diretamente em componentes em vários níveis no projeto.

[0052] De acordo com algumas formas de realização, uma aplicação de programa de computador armazenada em memória não volátil ou meio legível por computador (por exemplo, memória de registrador, cache de processador, RAM, ROM, disco rígido, memória flash, CD-ROM, mídia magnética, etc.) pode incluir código ou instruções executáveis que, quando executadas, podem instruir e/ ou fazer com que um controlador ou processador execute os métodos discutidos aqui, como para geração automática de casos de teste baseada em requisitos, conforme descrito acima.

[0053] O meio legível por computador pode ser uma mídia não transitória legível por computador, incluindo todas as formas e tipos de memória e todas as mídias legíveis por computador, exceto por um sinal de propagação transitório. Em uma implementação, a memória não volátil ou mídia legível por computador pode ser memória externa.

[0054] Embora o hardware e os métodos específicos tenham sido aqui descritos, note que qualquer número de outras configurações pode ser proporcionado de acordo com formas de realização da invenção. Assim, embora tenham sido mostradas, descritas e indicadas características inovadoras fundamentais da invenção, será entendido que várias omissões, substituições e alterações na forma e detalhes das formas de realização ilustradas, e na sua operação, podem ser feitas pelos técnicos no assunto sem se afastar do espírito e escopo da invenção. As substituições de elementos de uma forma de realização por outros também são totalmente planejadas e contempladas. A invenção é definida unicamente em relação às reivindicações anexas, e equivalentes das suas declarações.

Lista de partes

NÚMERO DESCRIÇÃO

17/17

100

110

120

130

131

132

134

136

140

150

300

VAR1 a VAR19

REQ12 a REQ15

Componentel a Componente4

500

510

520

530

540

600

610

620

VAR20 a VAR22

REQ27

700

710

720

730

740

800

VAR23 a VAR25

REQ28

1000

1010

1020

1030

1040

REQ1 a REQ11

REQ16 a REQ26

1100

1200

Sistema

Processador de controfe

Link de comunicação

Armazém de dados

Instruções de computador

Requisitos de alto nível

Modelo de arquitetura de software

Casos de teste

Unidade geradora de casos de teste

Ferramenta de desenvolvimento baseada em modelo

Modelo de arquitetura de software

Variável

Modelo de Requisitos

Componente

Modelo de Requisitos

Expressão Antecedente

Expressão Consequente

Bloco lógico

Sinal de saída

Modelo de Requisitos

Bloco de objetivo de teste

Bloco de condição de teste

Variável

Requerimento

Modelo de cobertura de condição lógica

Bloco de condição

Porta de satisfação

Estratégia de modelo de disfarce de entrada

Variável

Requerimento

Modelo de projeto de arquitetura de software

Bloco

Modelo de Requisito

Script de teste a nívei de unidade

Script de teste a nível de integração

Claims

Reivindicações

1. MÉTODO PARA GERAÇÃO AUTOMÁTICA DE CASOS DE TESTE BASEADA EM REQUISITOS, o método caracterizado pelo fato de que compreende:

construir um modelo de arquitetura de software em uma ferramenta de desenvolvimento baseada em modelo, o modelo de arquitetura de software derivado automaticamente a partir de informações arquitetônicas de um modelo de projeto de software;

alocar modelos de requisitos em diferentes componentes de um modelo de arquitetura de software;

uma unidade geradora de casos de teste gerando casos de teste baseados em requisitos a nível de componente de um ou mais níveis do modelo de arquitetura de software; e os casos de teste baseados em requisitos gerados configurados para serem executáveis em diferentes níveis na arquitetura de software.
2. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui alocar os modelos de requisito, conectando as variáveis monitoradas ou controladas correspondentes com, pelo menos, uma de uma porta de entrada e uma porta de saída das respectivas dos diferentes módulos.
3. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui a unidade geradora de casos de teste gerando casos de teste de nível de integração e aplicando os casos de teste de nível de integração para verificar se um módulo de código está em conformidade com os requisitos alocados.
4. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui:

receber o modelo de arquitetura de software na forma de

2/7 um diagrama de fluxo de dados hierárquico derivado do projeto de software junto com os modelos de requisitos alocados, o diagrama de fluxo de dados hierárquico incluindo um ou mais mapeamentos de blocos/ operadores para componentes correspondentes no projeto de software;

selecionar um dos componentes de software do projeto de software para geração de casos de teste; e construção de um modelo de teste intermediário com base no componente selecionado, anexando automaticamente pelo menos um objetivo de teste e restrições de teste ao bloco/ operador de modelo de arquitetura de software correspondente.
5. MÉTODO, de acordo com a reivindicação 4, caracterizado pelo fato de que inclui a seleção do componente de software com base em um nível de geração de teste.
6. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui a geração de casos de teste de acordo com pelo menos uma estratégia selecionada da lista de uma estratégia de cobertura de requisitos, uma estratégia de cobertura de condição lógica, uma estratégia de disfarce de entrada, uma estratégia de análise de completude de dados, uma estratégia de evento, uma estratégia de lista, uma estratégia de decomposição e equação, uma estratégia de classe de equivalência, uma estratégia de análise de valor limite, uma estratégia de robustez e uma estratégia de temporização.
7. MÉTODO, de acordo com a reivindicação 4, caracterizado pelo fato de que inclui:

gerar casos de teste baseados em requisitos executando pelo menos um dos métodos de verificação de modelo, prova de teorema, resolução de restrições e resolução de alcançabilidade no modelo de teste intermediário; e

3/7 traduzir os casos de teste gerados em scripts de teste para execução de teste e em artefatos de teste para revisão,
8. MEIO LEGÍVEL POR COMPUTADOR NÃO TRANSITÓRIO, caracterizado pelo fato de que tem armazenado no mesmo instruções que quando executadas por um processador fazem com que o processador execute um método para geração automática de casos de teste baseada em requisitos, o método compreendendo:

construir um modelo de arquitetura de software, o modelo de arquitetura de software derivado automaticamente de informações arquitetônicas de um modelo de projeto de software;

alocar modelos de requisitos em diferentes blocos/ operadores de um modelo de arquitetura de software;

gerar casos de teste baseados em requisitos a nível de componente de um ou mais níveis do modelo de arquitetura de software; e os casos de teste baseados em requisitos gerados configurados para serem executáveis em diferentes níveis na arquitetura de software.
9. MEIO LEGÍVEL POR COMPUTADOR NÃO TRANSITÓRIO, de acordo com a reivindicação 8, caracterizado pelo fato de que inclui instruções para fazer com que o processador aloque os modelos de requisito conectando variáveis monitoradas ou controladas correspondentes a uma porta de entrada ou uma porta de saída dos respectivos módulos diferentes.
10. MEIO LEGÍVEL POR COMPUTADOR NÃO TRANSITÓRIO, de acordo com a reivindicação 8, caracterizado pelo fato de que inclui instruções para fazer com que o processador gere casos de teste de nível de integração, e aplique os casos de teste de nível de integração para verificar se um módulo de código está em conformidade com os requisitos

4/7 alocados.
11. MEIO LEGÍVEL POR COMPUTADOR NÃO TRANSITÓRIO, de acordo com a reivindicação 8, caracterizado pelo fato de que inclui instruções para fazer com que o processador:

receba o modelo de arquitetura de software na forma de um diagrama de fluxo de dados hierárquico derivado do software projeto, junto com os modelos de requisitos alocados, o diagrama de fluxo de dados hierárquico incluindo um ou mais de mapeamento de blocos/ operadores de componentes correspondentes no projeto de software;

selecione um dos componentes de software do projeto de software para geração de casos de teste; e construa um modelo de teste intermediário com base no componente selecionado, anexando automaticamente pelo menos um objetivo de teste e restrições de teste ao bloco/ operador do modelo de arquitetura de software correspondente.
12. MEIO LEGÍVEL POR COMPUTADOR NÃO TRANSITÓRIO, de acordo com a reivindicação 10, caracterizado pelo fato de que inclui instruções para fazer com que o processador gere os casos de teste de acordo com pelo menos uma estratégia selecionada a partir da lista de uma estratégia de cobertura de requisitos, uma estratégia de cobertura de condição lógica, uma estratégia de disfarce de entrada, uma estratégia de análise de completude de dados, uma estratégia de evento, uma estratégia de lista, uma estratégia de decomposição e equação, uma estratégia de classe de equivalência, uma estratégia de análise de valor limite, uma estratégia de robustez e uma estratégia de temporização.

___
13. MEIO LEGÍVEL POR COMPUTADOR NÃO TRANSITÓRIO, de acordo com a reivindicação 11, caracterizado pelo fato de que inclui instruções para fazer com que o processador:

5/7 gerar casos de teste baseados em requisitos executando pelo menos um dos métodos de verificação de modelo, prova de teorema, resolução de restrições e resolução de alcançabilidade no modelo de teste intermediário; e traduzir os casos de teste gerados em scripts de teste para execução de teste e em artefatos de teste para revisão.
14. SISTEMA PARA GERAÇÃO AUTOMÁTICA DE CASOS DE TESTE BASEADOS EM REQUISITOS, o sistema caracterizado pelo fato de que compreende:

uma ferramenta de desenvolvimento baseada em modelo, incluindo um processador de controle configurado para executar instruções, o processador de controle conectado a um link de comunicação;

uma unidade geradora de caso de teste a nível de componente para gerar automaticamente casos de teste.
15. SISTEMA, de acordo com a reivindicação 14, caracterizado pelo fato de que inclui o processador de controle configurado para executar instruções que fazem com que o processador de controle execute as etapas de:

derivar o modelo de arquitetura de software do projeto de software alocar modelos de requisitos em diferentes blocos/ operadores de um modelo de arquitetura de software;

gerar casos de teste baseados em requisitos a nível de componente.
16. SISTEMA, de acordo com a reivindicação 15, caracterizado pelo fato de que inclui o processador de controle configurado para executar instruções que fazem com que o processador de controle gere casos de teste de nível de integração e aplique os casos de teste de nível de

6/7 integração para verificar se um módulo de código está em conformidade com o modelo de arquitetura de software e modelos de requisitos alocados.
17. SISTEMA, de acordo com a reivindicação 15, caracterizado pelo fato de que inclui o processador de controle configurado para executar instruções que fazem com que o processador de controle:

receba o modelo de arquitetura de software na forma de um diagrama de fluxo de dados hierárquico derivado do projeto de software junto com os modelos de requisitos alocados, o diagrama de fluxo de dados hierárquico incluindo um ou mais mapeamentos de blocos/ operadores para componentes correspondentes no projeto de software;

selecione um dos componentes de software do projeto de software para geração de casos de teste; e construa um modelo de teste intermediário com base no componente selecionado, anexando automaticamente pelo menos um objetivo de teste e restrições de teste ao bloco/ operador de modelo de arquitetura de software correspondente.
18. MÉTODO, de acordo com a reivindicação 6, caracterizado pelo fato de que a estratégia de disfarce de entrada inclui disfarce de Condição Modificada/ Cobertura de Decisão (MC/ DC) para permitir que mais do que uma entrada de uma condição de entrada altere em um par independente.
19. MEIO LEGÍVEL POR COMPUTADOR NÃO TRANSITÓRIO, de acordo com a reivindicação 12, caracterizado pelo fato de que a estratégia de disfarce de entrada inclui disfarce de Condição Modificada/ Cobertura de Decisão (MC/ DC) para permitir que mais do que uma entrada de uma condição de entrada altere em um par independente.
20. SISTEMA, de acordo com a reivindicação 15, caracterizado pelo fato de que os casos de teste baseados em requisitos a nível de componente gerados incluindo uma estratégia de disfarce de entrada

7/7

que permite que mais de uma entrada de uma condição de entrada mude em um par independente.