BR102016026988A2 - Method for generating test cases based on automated requirements - Google Patents

Method for generating test cases based on automated requirements Download PDF

Info

Publication number
BR102016026988A2
BR102016026988A2 BR102016026988-1A BR102016026988A BR102016026988A2 BR 102016026988 A2 BR102016026988 A2 BR 102016026988A2 BR 102016026988 A BR102016026988 A BR 102016026988A BR 102016026988 A2 BR102016026988 A2 BR 102016026988A2
Authority
BR
Brazil
Prior art keywords
test
model
software
software architecture
requirements
Prior art date
Application number
BR102016026988-1A
Other languages
English (en)
Inventor
Li Meng
Richard Durling Michael
Yan Siu Kit
Oliveira Italo
Yu Han
Marasca De Conto Augusto
Original Assignee
General Electric Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by General Electric Company filed Critical General Electric Company
Publication of BR102016026988A2 publication Critical patent/BR102016026988A2/pt

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2273—Test methods
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3608—Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3676—Test management for coverage analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/368—Test management for test version control, e.g. updating test cases to a new software version
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/35—Creation or generation of source code model driven
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

trata-se de um método de geração de caso de teste baseado em exigências automatizadas que inclui construir em uma ferramenta de desenvolvimento baseada em modelo um modelo de arquitetura de software automaticamente derivado de informações de arquitetura de um modelo de projeto de software, alocar modelos de exigência em blocos/operadores do modelo de arquitetura de software e gerar casos de teste baseados em exigência de nível de componente da arquitetura de software. o método de geração de caso de teste baseado em exigências de nível de componente inclui receber uma arquitetura de software junto com modelos de exigência alocados representados em fluxograma de dados hierárquicos, selecionar um dentre os componentes de software, construir um modelo de teste intermediário com base no componente selecionado fixando-se automaticamente pelo menos um dentre objetivos ou restrições de teste aos blocos/operadores de modelo de arquitetura de software correspondentes com base na estratégia de teste selecionada e, gerar casos de teste legíveis por seres humanos e máquina com o gerador de teste para conversão automática adicional para testar artefatos executáveis e revisão de teste. um sistema e um meio legível por computador não transitório para implantar o método também são revelados.

Description

“MÉTODO PARA GERAÇÃO DE CASO DE TESTE BASEADO EM EXIGÊNCIAS AUTOMATIZADAS” Antecedentes da Invenção [001] Exige-se por padrões de certificação (por exemplo, DO-178B/C para software de aviação) que software de segurança crítica, como software de aviação, seja estritamente verificado em relação a objetivos de certificação. O teste é uma parte essencial do processo de verificação. A geração de caso de teste manual das exigências é difícil e demorada, especialmente com software grande e complexo.
[002] Procedimentos de teste e/ou casos de teste automaticamente gerados derivados das exigências de software de nível alto podem auxiliar na redução do custo introduzido por geração de caso de teste manual e atividades de revisão. Aqueles procedimentos de teste e/ou casos de teste gerados a partir do relatório descritivo podem ser executados nas implantações de projeto de nível baixo associadas através de um condutor de teste.
[003] As ferramentas e/ou modelos de teste convencionais não têm capacidade para gerar casos de teste baseados em exigências em níveis diferentes no modelo de projeto. Os casos de teste gerados produzidos por ferramentas convencionais não podem ser diretamente executados em componentes em múltiplos níveis no projeto.
Breve Descrição dos Desenhos - A Figura 1 representa um sistema para geração de caso de teste baseado em exigências automatizadas de acordo com as modalidades; - A Figura 2 representa um processo para teste de software de acordo com as modalidades; - As Figuras 3A a 3D representam um modelo de arquitetura de software automaticamente derivado de um projeto de software de acordo com as modalidades; - A Figura 4 representa um processo para geração de caso de teste de nível de componente de acordo com as modalidades; - A Figura 5 representa um modelo de exigência de acordo com as modalidades; - A Figura 6 representa a modelo de exigência com objetivos de teste fixados de acordo com as modalidades; - A Figura 7 representa um modelo de abrangência de condição de lógica com objetivos de teste fixados de acordo com as modalidades; - As Figuras 8A a 8B representam um modelo de mascaramento de entrada com objetivos de teste fixados de acordo com as modalidades; - A Figura 9 representa uma geração de script de teste e processo de revisão de acordo com as modalidades; - A Figura 10 representa uma arquitetura de projeto de software exemplificativa e as informações de rastreabilidade de exigências associadas de acordo com as modalidades; - A Figura 11 representa um script de teste de nível de unidade exemplificativo de acordo com as modalidades; e - A Figura 12 representa um script de teste de nível de integração exemplificativo de acordo com as modalidades.
Descrição [004] De acordo com as modalidades, sistemas e métodos criam automaticamente um modelo de arquitetura de software da arquitetura de projeto de software junto com modelos de exigência para automatizar geração de caso de teste baseada em exigência de arquitetura de múltiplos níveis com base no modelo de arquitetura de software proposto.
[005] De acordo com as modalidades, o modelo de arquitetura de software e sua alocação de exigências são construídos com o uso de uma ferramenta de desenvolvimento baseada em modelo (MBD) com a representação de um fluxograma de dados hierárquicos. Em oposição a ferramentas de MBD convencionais, que são tradicionalmente usadas para projeto de nível baixo, uma ferramenta de MBD de incorporação cria automaticamente o modelo de arquitetura de software da arquitetura de projeto de software e gera casos de teste correspondentes para as exigências de nível alto ou nível de sistema.
[006] Os sistemas e métodos incorporados podem implantar geração de caso de teste baseada em exigências de nível de componente para gerar automaticamente casos de teste para componentes em níveis diferentes na arquitetura de software.
[007] A Figura 1 representa sistema 100 para geração de caso de teste baseado em exigências automatizadas de acordo com as modalidades. O sistema 100 inclui processador de controle 110 que executa instruções de computador 131 para controlar a operação do sistema e seus componentes. As instruções executáveis podem ser armazenadas em armazenamento de dados 130, que também podem armazenar dados acessados e gerados pelo sistema. O processador de controle 110 pode estar localizado em um computador, ou um servidor, e interconectado aos diversos componentes por meio de enlace de comunicação 120. O enlace de comunicação pode ser um barramento interno, uma rede de comunicação eletrônica ou similares. O sistema 100 pode gerar casos de teste do sistema e/ou exigências de nível alto 132 do software crítico de segurança.
[008] A Figura 2 representa processo 200 para teste de software automatizado de acordo com as modalidades. O processo 200 deriva do modelo de arquitetura de software 134 do modelo de projeto de software. O modelo de arquitetura de software é construído, na etapa 205, no ambiente de ferramenta de desenvolvimento baseada em modelo 150 com base nas informações de arquitetura do modelo de projeto. Esse modelo de arquitetura de software pode ser automaticamente criado de acordo com algumas implantações. Os modelos de exigência são alocados, na etapa 210, em módulos diferentes no modelo de arquitetura de software conectando-se as variáveis monitoradas/controladas correspondentes (por exemplo, Figura 1. VAR1-VAR19) com as portas de entrada/saída do componente. De acordo com algumas modalidades, na etapa 205, portas de entrada para todas as variáveis de saída nos modelos de exigência podem ser adicionadas. Adicionando-se portas de entrada para todas as variáveis de saída, o gerador de caso de teste pode gerar entradas e saídas esperadas para os casos de teste em uma execução.
[009] O componente-nível unidade de gerador de caso de teste 140 pode usar o modelo de arquitetura de software com exigências alocadas para gerar, na etapa 215, casos de teste baseados em exigências de unidade/módulo. A unidade de gerador de caso de teste 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 cumpre com as exigências alocadas.
[010] As Figuras 3A-3D representam o modelo de arquitetura de software 300 construído como um fluxograma de dados hierárquicos com base na arquitetura de projeto de software de acordo com as modalidades. Cada componente Componentl, Component2, Component3, Component4 no projeto de software é um bloco/operador no modelo de arquitetura de software com portas de entrada e saída. Os blocos/operadores no modelo de arquitetura de software são conectados entre si e podem ter múltiplas camadas de sub-blocos/suboperadores. Os modelos de exigência 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 rastreabilidade fácil das exigências para o projeto de software.
[011] A Figura 4 representa o processo 400 para geração de caso de teste de nível de componente de acordo com as modalidades. O processo 400 tem como base um modelo de arquitetura de software automaticamente criado recebido, etapa 405, sob a forma de um fluxograma de dados hierárquicos com modelos de exigência alocados. Um ou mais dos componentes de software no projeto de software são selecionados, na etapa 410, com base no nível de geração de teste, e o bloco/operador de modelo de arquitetura de software correspondente é usado para geração de caso de teste. Um modelo de teste intermediário é construído, na etapa 415, com base no componente selecionado fixando-se as restrições de teste e objetivos de teste para o bloco/operador de modelo de arquitetura de software correspondente. Os objetivos de teste são fixados para satisfazer determinados critérios de cobertura no nível de exigências, como cobertura de exigências (por exemplo, todas as exigências são ativadas), cobertura de condição lógica (por exemplo, condições lógicas nas exigências são ativadas em um determinado nível), etc. As restrições de teste são fixadas ao modelo para restringir a faixa de variáveis monitoradas/controladas e para garantir que os casos de teste gerados não violem as exigências.
[012] As estratégias de geração de caso de teste automáticas (isto é, para fixar os objetivos de teste e as restrições) podem ter como base a forma geral de uma exigência. Na linguagem inglesa estrutural natural, a forma de uma exigência pode ser expressada como: <expressão antecedente > implica em <expressão consequente>.
[013] Em que <expressão antecedente> é uma expressão lógica sobre variáveis monitoradas; e a <expressão consequente> é uma expressão lógica sobre variáveis controladas.
[014] A Figura 5 representa um modelo de exigência 500 (quando expressado em Simulink) de acordo com as modalidades. O modelo de exigência inclui expressão antecedente 510 e expressão consequente 520. Essas expressões são fornecidas para bloco lógico 530, que implica em sinal de saída 540 com base nos estados de expressões (isto é, A ==> B). A fim de manter a exigência, o sinal de saída deve ser 1 ou “verdadeiro”. A unidade de gerador de caso de teste automática 140 recebe como e, a partir daquele, gera casos de teste, de acordo com uma ou mais estratégias (por exemplo, estratégia de abrangência de exigências, estratégia de abrangência de condição lógica, estratégia de mascaramento de entrada, etc.). As modalidades não são, então, limitadas, e outras estratégias para geração de caso de teste estão dentro da contemplação desta revelação.
[015] Uma estratégia de abrangência de exigências inclui, para cada exigência, gerar um caso de teste, em que a exigência deve ser satisfeita com a expressão antecedente que é verdadeira. Isso é feito inserindo-se objetivos e restrições de teste e executando um mecanismo de geração de teste que pode acionar as sequências de entrada para alcançar os objetivos de teste.
[016] A título de exemplificação, a inserção de um objetivo de teste pode ser feita com o uso de blocos de objetivo de teste e condição de teste de uma biblioteca de bloco de verificador de projeto comercial na ferramenta de desenvolvimento baseada em modelo selecionada (por exemplo, como blocos Verificadores de Projeto Simulink disponíveis junto à Simulink). O mecanismo de geração de teste pode ser usado para acionar as entradas para alcançar os objetivos de teste. A Figura 6 representa um modelo de exigência 600 com objetivos de teste fixados de acordo com as modalidades. O bloco Objetivo de Teste 610 (verificado com um “O” dentro de um círculo), é analisado pelo verificador de projeto para revelar uma combinação de designações de valor de variável VAR21, VAR22 que faz com que sua expressão antecedente, que é do tipo Booleano, seja verdadeira. O bloco de Condição de Teste 620 (verificado com um “C” dentro de um círculo), faz com que o verificador de projeto que mantém a saída do bloco de “implicações” seja verdadeiro. Um sinal de saída verdadeiro do bloco de "implicações" é uma indicação de que a exigência REQ27 é satisfeita. As designações de valor para as variáveis monitoradas e controladas são geradas automaticamente pelo verificador de projeto.
[017] Uma estratégia de cobertura de condição lógica (LCC) pode ser implantada para alcançar cobertura funcional de condições de equação lógica. Cada condição dentro de uma equação lógica é demostrada como tendo um efeito sobre o resultado da equação lógica variando-se apenas aquela condição e mantendo fixa para todas as outras que poderíam afetar o resultado. Considerar os exemplos na Tabela 1, que representa cobertura de condição 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 alcançar cobertura de LCC (V) ou não (*). Quando a expressão antecedente tem um desses operadores, 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.
Caso de teste (T = Verdadeiro, F = Falso) Operador Booleano TT TF FT FF a AND b s ■/ s x a OR b x V V V a NAND b S V ✓ x a NOR b x ✓ V λ/ a XOR b ✓ V V V
a XNORb V ✓ V V
Tabela 1 [018] A Figura 7 representa um modelo de abrangência de condição de lógica 700 com objetivos de teste fixados de acordo com as modalidades. Esse modelo de LCC tem como base modelo de exigência 600 com um padrão de blocos de condição e objetivo de teste adicionais 710, 720, 730. A fim de gerar os casos de teste, os blocos de objetivo de teste são fixados de acordo com os operadores Booleanos usados e respectivos casos na Tabela 1. Após executar o mecanismo de geração de teste, um conjunto de casos de teste é gerado para satisfazer cobertura de condição lógica. Cada caso de teste gerado também é examinado a fim de revelar quais exigências o mesmo “ativa” — ativação significa que o sinal de saída de porta de Satisfação 740 deve ser 1 ou “verdadeiro”.
[019] Uma estratégia de mascaramento de entrada pode alcançar Cobertura de Condição/Decisão Modificada de mascaramento (MC/DC). A MC/DC de mascaramento cumpre com a definição de efeito independente garantindo-se os mesmos casos de teste mínimos em cada operador lógico como uma causa exclusiva, e é aceitável para cumprir com o objetivo de MC/DC de padrões de desenvolvimento de software crítico de segurança (por exemplo, DO-178B/C). O mascaramento se refere ao conceito de que entradas específicas para uma construção lógica podem ocultar o efeito de outras entradas para construção. Por exemplo, uma entrada falsa para um operador AND mascara todas as outras entradas e uma entrada verdadeira para um operador OR mascara todas as outras entradas. O mascaramento se aproxima de MC/DC que permite que mais de uma entrada seja alterada em um par de independência, desde que a condição de interesse seja mostrada como sendo a única condição que afeta o valor do resultado de decisão. No entanto, 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 se altere.
[020] As Figuras 8A a 8B representam uma estratégica de modelo de mascaramento de entrada 800 com objetivos de teste fixados de acordo com as modalidades. Cada subexpressão representada no modelo de mascaramento de entrada 800 corresponde a uma trajetória de sinal/bloco que inicia em uma condição de entrada da expressão antecedente, envolvendo uma variável monitorada VAR23, VAR24, VAR25, e termina no sinal que representa o resultado da expressão monitorada. A partir desse modelo, casos de teste podem ser automaticamente gerados, associados às exigências REQ28 pela unidade de gerador de caso de teste automática 140 e traduzidos para um script de teste de saída.
[021] A estratégia de geração de teste de mascaramento de entrada fixa objetivos de teste de acordo com as etapas a seguir: [022] Para cada proposição básica (condição de entrada) da expressão antecedente, obter o conjunto S de todas as subexpressões que contêm essa proposição, exceto a própria preposição. Então, para cada expressão no conjunto S: (1) se a operação de nível de topo da subexpressão for uma porta OR, substituir essa expressão por sua negativa em S; (2) criar 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 de teste que deve compor expressão e verdadeiro;
[023] Novamente em referência à Figura 4, após a fixação das restrições de teste e objetivos de teste o processo 400 continua com unidade de gerador de caso de teste 140 para gerar casos de teste 136, na etapa 420. A unidade de gerador de caso de teste pode realizar métodos de verificação de modelo, solucionamento de restrição e resolução de acessibilidade no modelo de teste intermediário para gerar os casos de teste de modo a satisfazer os objetivos de teste e/ou detectar objetivos de teste inatingíveis. Os casos de teste gerados são traduzidos, na etapa 425, em Scripts de teste para artefatos de execução de teste e revisão de teste para certificação. A vantagem do método de geração de teste de nível de componente é que o método é flexível para gerar automaticamente casos de teste baseados em exigências para componentes em níveis diferentes na arquitetura de software para alcançar critérios de nível de cobertura de exigências apropriados. De acordo com as modalidades, casos de teste podem ser gerados aplicáveis ou ao teste de nível de unidade/módulo, bem como teste de nível de integração.
[024] A Figura 9 representa um processo 900 para geração de script de teste e revisão de artefato de teste de acordo com as modalidades. O formato intermediário 905 gerado pelo processo 900 pode ser lido por seres humanos e/ou máquinas. O processo 900 opera nos casos de teste de nível de componente descritos acima. Um formato intermediário é gerado, na etapa 905, a partir dos casos de teste. Esse formato intermediário pode indicar as informações de saída esperadas e de entrada. O formato intermediário também pode indicar as exigências nas quais o caso de teste retorna, o objetivo de teste que o caso de teste satisfaz, e a referência da qual o objetivo de teste é derivado. As informações intermediárias podem ser usadas para conduzir manual ou automaticamente revisões de teste. Os 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, na etapa 915, Scripts de teste executáveis adequados para execução em ambientes de teste diferentes. Os Scripts de teste também podem ser automaticamente escritos novamente, na etapa 920, para ferramentas de gerenciamento de teste e exigências (por exemplo, IBM® Rational® DOORS®).
[025] Coletivamente, as Figuras 10 a 13 representam uma ilustração de uma implantação de extremidade para extremidade de acordo com as modalidades. A Figura 10 representa um modelo de arquitetura de projeto de software exemplificativo 1000 e as informações de rastreabilidade de exigências associadas de acordo com as modalidades. O modelo de arquitetura de software pode ser construído (Figura 2, etapa 205) como um modelo Simulink (Figuras 3A a 3D). Cada bloco no projeto de arquitetura de software de modelo de projeto de software é convertido para 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 exigências com base nas informações de rastreabilidade de exigências da Figura 10. Por exemplo, na Figura 3D, quatro modelos de exigências (1010) são alocados para component2 com base nas informações na Figura 10. De modo similar, o bloco 1020 indica as informações de rastreabilidade de exigências para componentl; o bloco 1030 indica as informações de rastreabilidade de exigências para component3; e o bloco 1040 indica as informações de rastreabilidade de exigências para component4. O modelo de arquitetura de software representado nas Figuras 3A a 3D é, então, usado para gerar casos de teste baseados em exigências em níveis diferentes na arquitetura de software.
[026] Um usuário pode selecionar bloco “component2” (Figura 4, etapa 410) para gerar casos de teste em seu nível de unidade e selecionar estratégia de teste de mascaramento de entrada. De acordo com as modalidades, blocos de objetivos e restrições de teste serão automaticamente fixados a todos os modelos de exigências dentro do bloco “component2” na etapa 415. Após solicitação de Verificador de Projeto Simulink na etapa 420 e a tradução de casos de teste na etapa 425, os casos de teste que satisfazem todos os objetivos e restrições de teste para estratégia de teste de mascaramento de entrada serão gerados.
[027] A Figura 11 representa script de teste de nível de unidade exemplificativo 1100 de acordo com as modalidades. Esse script de teste de nível de unidade é um exemplo de casos de teste gerados no nível de unidade para “component2”. O caso de teste é gerado para ter capacidade para executar em ambiente de teste de SCADE no bloco “component2” no projeto. Um usuário pode selecionar de modo alternativo bloco de nível de integração que inclui componente 1 a 4 na Figura 4, na etapa 410 para gerar casos de teste de nível de integração. De acordo com as modalidades, blocos de objetivos e restrições de teste são automaticamente fixados a todos os modelos de exigências dentro do bloco de nível de integração na etapa 415. Após solicitação de Verificador de Projeto Simulink na etapa 420 e traduzir casos de teste na etapa 425, os casos de teste que satisfazem todos os objetivos e restrições de teste para estratégia de teste de mascaramento de entrada serão gerados.
[028] A Figura 12 representa script de teste de nível de integração exemplificativo 1200 de acordo com as modalidades. Esse script de teste é um exemplo para os casos de teste gerados de nível de integração. O caso de teste é gerado para ter capacidade para executar em ambiente de teste de SCADE no bloco de nível de integração no projeto.
[029] De acordo com as modalidades, um fluxograma de dados hierárquicos (isto é, modelo de arquitetura de software junto com modelos de exigência) é automaticamente criado para capturar informações de exigências e projeto. Esse fluxograma de dados hierárquicos é usado para gerar casos de teste baseados em exigências em níveis diferentes na arquitetura de software. De acordo com as modalidades, as informações de projeto de sistema são usadas para construir o fluxograma de dados hierárquicos, em que os modelos de exigências são alocados dentro de módulos do fluxograma de dados hierárquicos. As alocações de exigências têm como base as informações de rastreabilidade de módulo de exigências das informações de projeto. Os objetivos e restrições de teste podem ser fixados ao modelo de arquitetura de software de acordo com uma estratégia de teste selecionada por usuário. A geração de caso de teste automática tem como base o fluxograma de dados hierárquicos para gerar casos de teste baseados em exigências em níveis diferentes na arquitetura de projeto que satisfaz os objetivos e restrições de teste. Os casos de teste gerados podem ser diretamente executados em componentes em múltiplos níveis no projeto.
[030] De acordo com algumas modalidades, um aplicativo de programa de computador armazenado em memória não volátil ou meio legível por computador (por exemplo, memória de registro, 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 executados, podem instruir e/ou fazer com que um controlador ou processador realize métodos discutidos no presente documento como para geração de caso de teste baseado em exigências automatizadas, conforme descrito acima.
[031] O meio legível por computador poder ser uma mídia legível por computador não transitória que inclui todas as formas e tipos de memória e todas as mídias legíveis por computador, exceto um sinal de propagação transitório. Em uma implantação, a memória não volátil ou meio legível por computador pode ser uma memória externa.
[032] Embora hardware e métodos específicos tenham sido descritos no presente documento, verifique que qualquer número de outras configurações pode ser fornecido de acordo com as modalidades da invenção. Desse modo, embora tenham sido mostrados, descritos e indicados recursos inovadores fundamentais da invenção, será entendido que diversas omissões, substituições e alterações na forma e detalhes das modalidades ilustradas, e em sua operação, podem ser feitas por aqueles versados na técnica sem se afastar do espírito e do escopo da invenção. As substituições de elementos de uma modalidade para outra também são completamente planejadas e contempladas. A invenção é definida apenas em relação às reivindicações anexas na mesma, e equivalentes das recitações na mesma.
Lista De Partes NÚMERO DESCRIÇÃO 100 Sistema 110 Processador de controle 120 Enlace de comunicação 130 Armazenamento de dados 131 Instruções de computador 132 Exigências de nível alto 134 Modelo de arquitetura de software 136 Casos de Teste 140 Unidade geradora de caso de teste Ferramenta de desenvolvimento 150 baseada em modelo 300 Modelo de arquitetura de software VAR1 a VAR19 Variável REQ12 a REQ15 Modelo de Exigência Componentl a Component4 Componente 500 Modelo de Exigência 510 Expressão de antecedente 520 Expressão consequente 530 Bloco de lógica 540 Sinal de saída 600 Modelo de Exigência 610 Bloco objetivo de teste 620 Bloco de condição de teste VAR20 a VAR22 Variável REQ27 Exigência Modelo de abrangência de condição de 700 lógica 710 Bloco de condição 720 Bloco de condição 730 Bloco de condição 740 Porta de satisfação Estratégia de modelo de 800 mascaramento de entrada VAR23 a VAR25 Variável REQ28 Exigência Modelo de projeto de arguitetura de 1000 software 1010 Bloco 1020 Bloco 1030 Bloco 1040 bloco REQ1 a REQ11 Modelo de Exigência REQ16 a REQ26 Modelo de Exigência 1100 Script de teste de nível de unidade 1200 Script de teste de nível de integração Reivindicações

Claims (7)

1. MÉTODO PARA GERAÇÃO DE CASO DE TESTE BASEADO EM EXIGÊNCIAS AUTOMATIZADAS, em que o método é caracterizado pelo fato de que compreende: - construir um modelo de arquitetura de software (300) em uma ferramenta de desenvolvimento baseada em modelo (150), em que o modelo de arquitetura de software é automaticamente derivado de informações de arquitetura de um modelo de projeto de software (1000); - alocar modelos de exigência (REQ1-REQ28) em componentes diferentes de um modelo de arquitetura de software; e - uma unidade de gerador de caso de teste (140) que gera casos de teste baseados em exigência de nível de componente (136) do modelo de arquitetura de software.
2. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui alocar os modelos de exigência conectando-se variáveis monitoradas ou controladas correspondentes (VAR1-VAR25) a pelo menos uma dentre uma porta de entrada e uma porta de saída dos respectivos módulos dentre os módulos diferentes.
3. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui a unidade de gerador de caso de teste que gera casos de teste de nível de integração, e que aplica os casos de teste de nível de integração para verificar se um módulo de código cumpre com as exigências alocadas.
4. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui: - receber o modelo de arquitetura de software sob a forma de um fluxograma de dados hierárquicos derivado do projeto de software junto com os modelos de exigência alocados, em que o fluxograma de dados hierárquicos inclui um ou mais mapeamentos de blocos/operadores para componentes correspondentes (Componente1-Component4) no projeto de software; - selecionar um dentre os componentes de software do projeto de software para geração de caso de teste; e - construir um modelo de teste intermediário com base no componente selecionado fixando-se automaticamente pelo menos um dentre objetivos e restrições de teste de teste para o 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 selecionar o 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 gerar os casos de teste de acordo com pelo menos uma estratégia selecionada a partir da lista de uma estratégia de abrangência de exigências, uma estratégia de abrangência de condição lógica e uma estratégia de mascaramento de entrada.
7. MÉTODO, de acordo com a reivindicação 4, caracterizado pelo fato de que inclui: - gerar casos de teste baseados em exigências realizando-se pelo menos um dentre métodos de verificação de modelo, solucionamento de restrição e resolução de acessibilidade 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.
BR102016026988-1A 2015-11-20 2016-11-18 Method for generating test cases based on automated requirements BR102016026988A2 (pt)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/947,633 US9940222B2 (en) 2015-11-20 2015-11-20 System and method for safety-critical software automated requirements-based test case generation
US14/947,633 2015-11-20

Publications (1)

Publication Number Publication Date
BR102016026988A2 true BR102016026988A2 (pt) 2017-07-18

Family

ID=58699700

Family Applications (2)

Application Number Title Priority Date Filing Date
BR102016026988-1A BR102016026988A2 (pt) 2015-11-20 2016-11-18 Method for generating test cases based on automated requirements
BR102019004568-0A BR102019004568A2 (pt) 2015-11-20 2019-03-08 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

Family Applications After (1)

Application Number Title Priority Date Filing Date
BR102019004568-0A BR102019004568A2 (pt) 2015-11-20 2019-03-08 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

Country Status (7)

Country Link
US (2) US9940222B2 (pt)
JP (1) JP6307140B2 (pt)
CN (3) CN114996115A (pt)
BR (2) BR102016026988A2 (pt)
CA (2) CA2948250C (pt)
FR (1) FR3044126B1 (pt)
GB (1) GB2545800A (pt)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9940222B2 (en) * 2015-11-20 2018-04-10 General Electric Company System and method for safety-critical software automated requirements-based test case generation
US10025696B2 (en) 2016-02-09 2018-07-17 General Electric Company System and method for equivalence class analysis-based automated requirements-based test case generation
US20180165180A1 (en) * 2016-12-14 2018-06-14 Bank Of America Corporation Batch File Creation Service
JP6556786B2 (ja) 2017-05-17 2019-08-07 矢崎総業株式会社 端子
CN107729226A (zh) * 2017-07-13 2018-02-23 中科院合肥技术创新工程院 基于业务流的测试用例自动生成系统及方法
CN107729256A (zh) * 2017-11-16 2018-02-23 郑州云海信息技术有限公司 一种项目需求和测试用例的关联方法及系统
EP3493051A1 (en) * 2017-11-30 2019-06-05 The MathWorks, Inc. System and methods for evaluating compliance of implementation code with a software architecture specification
DE102018003142A1 (de) 2017-12-13 2019-06-13 The Mathworks, Inc. Automatische Einstellung von Multitasking-Konfigurationen für ein Codeprüfsystem
EP3572945A1 (en) * 2018-03-09 2019-11-27 General Electric Company System and method for safety-critical software automated requirements-based test case generation
CN108595318B (zh) * 2018-03-31 2021-05-14 西安电子科技大学 Rfc制导的ssl/tls实现中数字证书验证模块的差异测试方法
CN108427554B (zh) * 2018-05-14 2023-09-08 华南理工大学 一种表驱动的云模式软件自动构造方法及系统
WO2020015837A1 (de) * 2018-07-20 2020-01-23 Siemens Aktiengesellschaft Verfahren und anordnung zur bereitstellung, überprüfung und optimierung eines automatisierungsprogramms
US10585779B2 (en) 2018-07-30 2020-03-10 General Electric Company Systems and methods of requirements chaining and applications thereof
CN109344059B (zh) * 2018-09-20 2023-04-11 天津龙拳风暴科技有限公司 一种服务器压力测试方法及装置
US11138089B2 (en) 2018-12-19 2021-10-05 International Business Machines Corporation Performance benchmark generation
CN109815147B (zh) * 2019-01-21 2022-06-24 深圳乐信软件技术有限公司 测试案例生成方法、装置、服务器和介质
EP3722942B1 (en) * 2019-04-10 2023-03-22 The Boeing Company Running integration tests using unit tests
US11620454B2 (en) * 2020-02-05 2023-04-04 Hatha Systems, LLC System and method for determining and representing a lineage of business terms and associated business rules within a software application
CN111539099A (zh) * 2020-04-17 2020-08-14 北京航空航天大学 一种基于程序变异的Simulink模型验证方法
CN111679941A (zh) * 2020-05-31 2020-09-18 西南电子技术研究所（中国电子科技集团公司第十研究所） 自动识别仪器型号映射仪器指令实现仪器互换的方法
US11200069B1 (en) 2020-08-21 2021-12-14 Honeywell International Inc. Systems and methods for generating a software application
US11144436B1 (en) 2020-10-19 2021-10-12 Bank Of America Corporation System for testing an application with dynamically linked security tests
CN112231164B (zh) * 2020-12-11 2021-08-27 鹏城实验室 处理器验证方法、设备及可读存储介质
EP4050489A1 (en) * 2021-02-24 2022-08-31 The Boeing Company Automatic generation of integrated test procedures using system test procedures
CN113010152A (zh) * 2021-03-24 2021-06-22 中广核工程有限公司 一种核电厂安全级软件设计系统和方法
CN112905486B (zh) * 2021-03-26 2022-07-08 建信金融科技有限责任公司 一种服务集成测试方法、装置和系统
CN113282498B (zh) * 2021-05-31 2024-04-05 深圳赛安特技术服务有限公司 测试用例的生成方法、装置、设备及存储介质
CN115525532A (zh) * 2021-06-25 2022-12-27 华为云计算技术有限公司 一种测试用例选择方法及相关装置
CN117555812B (zh) * 2024-01-11 2024-05-17 北京捷科智诚科技有限公司 一种云平台自动化测试方法及系统

Family Cites Families (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5390325A (en) 1992-12-23 1995-02-14 Taligent, Inc. Automated testing system
US7437304B2 (en) * 1999-11-22 2008-10-14 International Business Machines Corporation System and method for project preparing a procurement and accounts payable system
US6681383B1 (en) 2000-04-04 2004-01-20 Sosy, Inc. Automatic software production system
US7272752B2 (en) 2001-09-05 2007-09-18 International Business Machines Corporation Method and system for integrating test coverage measurements with model based test generation
CA2393043A1 (en) 2002-07-11 2004-01-11 Luiz Marcelo Aucelio Paternostro Formal test case definitions
US20050043913A1 (en) 2003-08-19 2005-02-24 Rex Hyde Method of determining the level of structural coverage testing of test cases which are written for a program that does not provide for structural coverage testing
US7478365B2 (en) 2004-01-13 2009-01-13 Symphony Services Corp. Method and system for rule-based generation of automation test scripts from abstract test case representation
US7392509B2 (en) 2004-04-13 2008-06-24 University Of Maryland Method for domain specific test design automation
JP2006024006A (ja) 2004-07-08 2006-01-26 Denso Corp テストケース生成装置、テストケース生成プログラム、モデルベース開発プログラム、ソースコード生成妥当性診断装置、ソースコード生成妥当性診断プログラム、およびモデルベース開発方法。
US7865339B2 (en) 2004-07-12 2011-01-04 Sri International Formal methods for test case generation
US7979849B2 (en) 2004-10-15 2011-07-12 Cisco Technology, Inc. Automatic model-based testing
US8392873B2 (en) 2005-01-26 2013-03-05 Tti Inventions C Llc Methods and apparatus for implementing model-based software solution development and integrated change management
US7752606B2 (en) * 2005-08-10 2010-07-06 Capital One Financial Corporation Software development tool using a structured format to generate software code
KR101222860B1 (ko) 2005-09-01 2013-01-16 삼성전자주식회사 광픽업장치
US7716254B2 (en) 2005-09-12 2010-05-11 Infosys Technologies Ltd. System for modeling architecture for business systems and methods thereof
US7853906B2 (en) 2006-03-22 2010-12-14 Nec Laboratories America, Inc. Accelerating high-level bounded model checking
US20080056210A1 (en) 2006-06-14 2008-03-06 Toshiba America Research, Inc. Moving Networks Information Server
DE102006050112A1 (de) 2006-10-25 2008-04-30 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren zur Erstellung einer Anforderungsbeschreibung für ein eingebettetes System
US7644334B2 (en) * 2006-11-27 2010-01-05 Honeywell International, Inc. Requirements-based test generation
US8041554B1 (en) 2007-06-06 2011-10-18 Rockwell Collins, Inc. Method and system for the development of high-assurance microcode
US9189757B2 (en) * 2007-08-23 2015-11-17 International Business Machines Corporation Monitoring and maintaining balance of factory quality attributes within a software factory environment
US8423879B2 (en) 2008-05-14 2013-04-16 Honeywell International Inc. Method and apparatus for test generation from hybrid diagrams with combined data flow and statechart notation
US8307342B2 (en) 2008-05-14 2012-11-06 Honeywell International Inc. Method, apparatus, and system for automatic test generation from statecharts
JP5412510B2 (ja) 2008-05-19 2014-02-12 ジョンソン コントロールズ テクノロジー カンパニー １個のソフトウェアの少なくとも一部を検証するためにテストケースを自動的に形成する方法
JP2009294846A (ja) * 2008-06-04 2009-12-17 Denso Corp テストケース生成装置、テストケース生成プログラム、およびテストケース生成方法
US8260479B2 (en) 2008-12-09 2012-09-04 Honeywell International Inc. Modular software architecture for an unmanned aerial vehicle
US20100192128A1 (en) 2009-01-27 2010-07-29 Honeywell International Inc. System and methods of using test points and signal overrides in requirements-based test generation
US20110083121A1 (en) 2009-10-02 2011-04-07 Gm Global Technology Operations, Inc. Method and System for Automatic Test-Case Generation for Distributed Embedded Systems
US9298598B2 (en) * 2010-03-22 2016-03-29 Red Hat, Inc. Automated visual testing
US8849626B1 (en) 2010-06-23 2014-09-30 Iowa State University Research Foundation, Inc. Semantic translation of stateflow diagrams into input/output extended finite automata and automated test generation for simulink/stateflow diagrams
WO2012049816A1 (ja) 2010-10-14 2012-04-19 日本電気株式会社 モデル検査装置、方法及びプログラム
CN102136047A (zh) 2011-02-25 2011-07-27 天津大学 一种基于形式化及统一软件模型的软件可信工程方法
JP5814603B2 (ja) * 2011-04-21 2015-11-17 株式会社東芝 テスト仕様作成支援装置、方法及びプログラム
US8645924B2 (en) 2011-06-06 2014-02-04 Fujitsu Limited Lossless path reduction for efficient symbolic execution and automatic test generation
US8893087B2 (en) 2011-08-08 2014-11-18 Ca, Inc. Automating functionality test cases
US9063673B2 (en) * 2011-08-30 2015-06-23 Uniquesoft, Llc System and method for implementing application code from application requirements
US9360853B2 (en) 2011-09-19 2016-06-07 Dspace Gmbh Exchange of files and meta-information between system design tools and behavior modeling tools and/or simulators for the creation of ECU software
CN102693134B (zh) 2012-05-25 2014-11-19 南京邮电大学 一种基于统一建模语言的传感网软件建模平台开发方法
US9971676B2 (en) 2012-08-30 2018-05-15 Toyota Motor Engineering & Manufacturing North America, Inc. Systems and methods for state based test case generation for software validation
KR101408870B1 (ko) 2012-11-06 2014-06-17 대구교육대학교산학협력단 Ｕｍｌ ｓｄ로부터 ｍｃｃｆｇ를 기반으로 하는 다단계 테스트 케이스 생성장치 및 방법
US9747079B2 (en) 2014-12-15 2017-08-29 General Electric Company Method and system of software specification modeling
CN104991863B (zh) * 2015-07-14 2017-11-03 株洲南车时代电气股份有限公司 一种基于功能块图测试模型自动生成测试用例的方法
CN104978275B (zh) * 2015-07-16 2017-09-29 北京航空航天大学 一种面向do‑178c软件测试过程的目标验证及证据模型提取方法
CN105068927A (zh) * 2015-08-04 2015-11-18 株洲南车时代电气股份有限公司 基于关键字驱动的城轨传动控制单元自动化测试方法
US9940222B2 (en) * 2015-11-20 2018-04-10 General Electric Company System and method for safety-critical software automated requirements-based test case generation
CN107727411B (zh) * 2017-10-30 2019-09-27 青岛慧拓智能机器有限公司 一种自动驾驶车辆测评场景生成系统及方法

Also Published As

Publication number Publication date
GB2545800A (en) 2017-06-28
CN107066375A (zh) 2017-08-18
CA3035176A1 (en) 2019-09-09
US20180196739A1 (en) 2018-07-12
US9940222B2 (en) 2018-04-10
FR3044126A1 (fr) 2017-05-26
CN110245067B (zh) 2023-09-22
CA2948250A1 (en) 2017-05-20
FR3044126B1 (fr) 2022-01-14
JP2017097862A (ja) 2017-06-01
CN114996115A (zh) 2022-09-02
CA2948250C (en) 2020-05-26
JP6307140B2 (ja) 2018-04-04
CN110245067A (zh) 2019-09-17
BR102019004568A2 (pt) 2019-10-01
CN107066375B (zh) 2022-03-01
US20170147482A1 (en) 2017-05-25

Similar Documents

Publication Publication Date Title
BR102016026988A2 (pt) Method for generating test cases based on automated requirements
US8918678B2 (en) Functional testing of a processor design
BR102015030798A2 (pt) sistema e método
US9443044B2 (en) Determining a quality parameter for a verification environment
US20160266952A1 (en) Automated Qualification of a Safety Critical System
US20110083114A1 (en) Method and system for re-using digital assertions in a mixed signal design
CN107710166B (zh) 利用符号快速错误检测的硅后验证和调试
TW201546638A (zh) 用於ｉｃ設計協定的自動化功能覆蓋生成和管理的系統和方法
Caliebe et al. Dependency-based test case selection and prioritization in embedded systems
Khan et al. Importance of software testing in software development life cycle
Helmstetter et al. Automatic generation of schedulings for improving the test coverage of systems-on-a-chip
JP2007522574A (ja) デジタルシステムのｈｄｌ記述ファイルを作成する方法、および得られるシステム
US8010920B2 (en) Constraint management and validation for template-based circuit design
US9373077B1 (en) System and method for identifying constraint solver calls
Filipovikj et al. Analyzing industrial simulink models by statistical model checking
CN109144849A (zh) 一种嵌入式软件调测方法
JP5269450B2 (ja) 試験システム及びバックアノテーション方法
EP3572945A1 (en) System and method for safety-critical software automated requirements-based test case generation
Laeufer et al. Open-source formal verification for Chisel
US9104826B2 (en) Monitoring coverage for static modelling of an electronic device
Wu et al. Formal specification and transformation method of system requirements from B Method to AADL Model
Peleska et al. Model-based testing strategies and their (in) dependence on syntactic model representations
Oliveira et al. A domain specific language for automotive systems integration
Liu et al. A real-time UEFI functional validation tool with behavior Colored Petri Net model
Ranerup et al. Using formal verification to exhaustively verify SoC assemblies

Legal Events

Date Code Title Description
B03A Publication of a patent application or of a certificate of addition of invention [chapter 3.1 patent gazette]
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B11B Dismissal acc. art. 36, par 1 of ipl - no reply within 90 days to fullfil the necessary requirements