KR20210004656A - 차량 기능 테스트 장치 및 그 제어 방법 - Google Patents

차량 기능 테스트 장치 및 그 제어 방법 Download PDF

Info

Publication number
KR20210004656A
KR20210004656A KR1020190081419A KR20190081419A KR20210004656A KR 20210004656 A KR20210004656 A KR 20210004656A KR 1020190081419 A KR1020190081419 A KR 1020190081419A KR 20190081419 A KR20190081419 A KR 20190081419A KR 20210004656 A KR20210004656 A KR 20210004656A
Authority
KR
South Korea
Prior art keywords
test
defect
design
function
unit
Prior art date
Application number
KR1020190081419A
Other languages
English (en)
Inventor
장훈
채현아
최병주
Original Assignee
현대자동차주식회사
이화여자대학교 산학협력단
기아자동차주식회사
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 현대자동차주식회사, 이화여자대학교 산학협력단, 기아자동차주식회사 filed Critical 현대자동차주식회사
Priority to KR1020190081419A priority Critical patent/KR20210004656A/ko
Priority to US16/908,307 priority patent/US11599453B2/en
Priority to CN202010636930.1A priority patent/CN112181800A/zh
Publication of KR20210004656A publication Critical patent/KR20210004656A/ko

Links

Images

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
    • 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/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • 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/26—Functional testing
    • G06F11/263—Generation of test inputs, e.g. test vectors, patterns or sequences ; with adaptation of the tested hardware for testability with external testers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3013—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, automotive or aircraft systems
    • 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/362—Software debugging
    • G06F11/366—Software debugging using diagnostics
    • 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/3688—Test management for test execution, e.g. scheduling of test suites
    • 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/3692—Test management for test results analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)
  • Automation & Control Theory (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Human Computer Interaction (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)

Abstract

본 발명은 차량 기능 안전성에 대한 테스트 장치 및 그 제어 방법에 관한 것으로, 보다 상세히는 결함주입 기법 기반의 테스트 케이스 생성이 가능한 테스트 장치 및 그 제어 방법에 관한 것이다. 본 발명의 일 실시예에 따른 테스트 장치의 제어방법은, 소프트웨어 상세 디자인을 기반으로 테스트 대상 프로그램에서 적어도 하나의 시험 대상 함수를 식별하는 단계; 적어도 상기 식별된 적어도 하나의 시험 대상 함수의 기능과 관련하여 발생 가능한 결함 위치 및 상기 결함 위치에 주입할 결함 유형을 기반으로 테스트 설계서를 생성하는 단계; 상기 생성된 테스트 설계서 및 상기 테스트 대상 프로그램의 소스 코드를 기반으로 상기 추출된 결함 위치 중 주입할 결함 위치를 탐색하는 단계; 결함 주입 방식 및 결함 타입을 결정하는 단계; 및 상기 탐색된 위치에 상기 결함 주입 방식 및 상기 결함 유형에 대응되는 결함 주입에 따른 예상 결과를 예측하여 테스트 케이스를 생성하는 단계를 포함할 수 있다.

Description

차량 기능 테스트 장치 및 그 제어 방법{APPARATUS AND CONTROL METHOD FOR VEHICLE FUNCTION TEST}
본 발명은 차량 기능 안전성에 대한 테스트 장치 및 그 제어 방법에 관한 것으로, 보다 상세히는 결함주입 기법 기반의 테스트 케이스 생성이 가능한 테스트 장치 및 그 제어 방법에 관한 것이다.
자동차 기능 안전성 표준인 ISO 26262에서는 소프트웨어의 단위 및 통합테스트시 구현된 안전 메커니즘이 제대로 작동하는지 위한 방법의 일원으로 결함 주입 테스트(FIT: Fault Injection Test)를 권장하고 있다. 그러나, 차량용 소프트웨어의 기능 안전에 대한 요구조건의 표준화만으로는 소프트웨어의 기능 안전성 검증을 목적으로 하는 결함 주입 테스트의 신뢰성을 확보하는데 한계가 있다.
이러한 한계를 극복하기 위해 차량용 소프트웨어의 결함 주입 테스트 수행 시 설계 단계에서 도출한 소프트웨어 설계 문서 및 안전성 요구사항 문서를 적용하여 테스트케이스를 생성할 수 있는 방법이 요구된다.
본 발명은 보다 편리한 기능을 제공하는 차량용 테스트 장치 및 그 제어 방법을 제공하기 위한 것이다.
특히, 본 발명은 결함주입 기법 기반의 테스트 케이스 생성이 가능한 테스트 장치 및 그 제어 방법에 관한 것이다.
본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
상기와 같은 기술적 과제를 해결하기 위하여, 본 발명의 일 실시예에 따른 테스트 장치의 제어방법은, 소프트웨어 상세 디자인을 기반으로 테스트 대상 프로그램에서 적어도 하나의 시험 대상 함수를 식별하는 단계; 적어도 상기 식별된 적어도 하나의 시험 대상 함수의 기능과 관련하여 발생 가능한 결함 위치 및 상기 결함 위치에 주입할 결함 유형을 기반으로 테스트 설계서를 생성하는 단계; 상기 생성된 테스트 설계서 및 상기 테스트 대상 프로그램의 소스 코드를 기반으로 상기 추출된 결함 위치 중 주입할 결함 위치를 탐색하는 단계; 결함 주입 방식 및 결함 타입을 결정하는 단계; 및 상기 탐색된 위치에 상기 결함 주입 방식 및 상기 결함 유형에 대응되는 결함 주입에 따른 예상 결과를 예측하여 테스트 케이스를 생성하는 단계를 포함할 수 있다.
또한, 본 발명의 일 실시예에 따른 소프트웨어의 테스트 장치는, 상기 테스트 대상 프로그램으로부터 안전 메커니즘과 관련된 함수 및 호출관계에 기반하여 테스트 범위를 추출하는 테스트 범위 결정부; 상기 테스트 범위 및 적어도 하나의 요구사항 문서에 따라 주입할 결함 위치, 결함 유형 및 위배할 정상조건 중 적어도 하나를 포함하는 테스트 설계서를 생성하는 테스트 설계서 생성부; 및 상기 테스트 대상 프로그램의 소스 코드 및 상기 테스트 설계서에 기반하여 테스트 케이스를 생성하는 테스트 케이스 생성부를 포함할 수 있다.
상기와 같이 구성되는 본 발명의 적어도 하나의 실시예에 관련된 테스트 장치는 보다 편리하고 신뢰성 있는 차량용 소프트웨어의 안전성 검증이 가능하다.
특히, 본 발명의 실시예들에 의하면, 소스 코드를 대상으로 안전 매커니즘 동작의 확인을 위한 테스트 케이스가 자동 생성되므로, 결함주입 기법 기반의 데스트 수행시 테스트 절차에 대한 신뢰성 확보와 개발 기간 단축이 가능하다.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 발명의 일 실시예에 따른 테스트 장치 구성의 일례를 나타내는 블럭도이다.
도 2는 본 발명의 일 실시예에 따른 사용자 인터페이스를 통해 입력되는 프로그램 형태의 일례를 나타낸다.
도 3은 본 발명의 일 실시예에 따른 테스트 장치에서 수행되는 단위 테스트 과정의 일례를 나타내는 순서도이다.
도 4는 본 발명의 일 실시예에 따른 테스트 장치에서 수행되는 통합 테스트 과정의 일례를 나타내는 순서도이다.
도 5는 본 발명의 일 실시예에 따른 테스트 설계서 형태의 일례를 나타낸다.
도 6은 본 발명의 일 실시예에 따른 테스트 케이스 형태의 일례를 나타낸다.
아래에서는 첨부한 도면을 참고로 하여 본 발명의 실시 예에 대하여 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다. 그리고 도면에서 본 발명을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.
명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성 요소를 더 포함할 수 있는 것을 의미한다. 또한, 명세서 전체에 걸쳐서 동일한 참조번호로 표시된 부분들은 동일한 구성요소들을 의미한다.
본 발명의 일 실시예에서는 차량 구성 요소에 탑재되는 소프트웨어의 안전성을 검증하기 위한 결함주입 테스트 수행 시 요구사항/설계 문서와 프로그램 코드의 입력으로 필요한 테스트 케이스를 자동으로 생성하는 테스트 장치 및 그 제어 방법을 제안한다.
특히, 본 실시예에서는 개방형 자동차 표준 소프트웨어 구조(AUTOSAR: AUTomotive Open System ARchitecture) 기반 소프트웨어를 대상으로 결함 주입 테스트를 수행할 때 요구사항/설계 문서와 프로그램 코드로부터 텍스트 처리를 통하여 유의미한 테스트 케이스를 자동으로 생성하는 테스트 장치 및 그 제어 방법을 제안한다. 바람직하게, 요구사항/설계 문서는 자연어로 기술된 것일 수 있다.
먼저, 도 1을 참조하여 실시예에 따른 테스트 장치의 구성을 설명한다.
도 1은 본 발명의 일 실시예에 따른 테스트 장치 구성의 일례를 나타내는 블럭도이다.
도 1을 참조하면, 실시예에 따른 테스트 장치는 테스트 대상 프로그램의 코드를 저장/관리하는 프로그램 코드 관리부(101), 테스트 대상 프로그램에 관한 요구사항 문서들을 저장/관리하는 요구사항 문서 관리부(102), 테스트 대상 프로그램으로부터 안전 메커니즘과 관련된 함수 및 호출관계를 추출하는 테스트 범위 결정부(103), 테스트 범위와 요구사항 문서에 따라 테스트 주입할 결함 위치, 유형 그리고 위배할 정상조건을 포함하는 테스트 설계서를 생성하는 테스트 설계서 생성부(104) 및 프로그램 코드와 테스트 설계서에 기반하여 테스트 케이스(300)를 생성하는 테스트 케이스 생성부(105)를 포함한다.
여기서, 테스트 장치는 사용자 인터페이스(200)를 통해 테스트 관련 정보를 입력받거나 출력할 수 있다. 예를 들어, 사용자 인터페이스(200)는 키보드, 마우스 등과 같은 입력 장치로부터 테스트 케이스 생성을 위한 각종 정보를 획득하고 디스플레이 수단이나 인쇄 수단을 통해 테스트 설계서 및 테스트 케이스 생성 결과와 서버에 저장된 기타 내용들을 표시/출력할 수 있다.
이하, 실시예에 따른 테스트 장치의 각 구성요소를 보다 상세히 설명한다.
먼저, 프로그램 코드 관리부(101)는 테스트 프로그램에 대한 코드를 저장하여 코드 기반의 결함 주입 테스트 케이스 생성 시 구체적인 결함 주입 위치가 포함될 수 있도록 한다. 여기서, 테스트 프로그램에 대한 코드는 소스 코드를 의미할 수 있다. 이러한 경우, 단순히 시스템 요구사항을 기반으로 한 모델이 아닌, 실제 차량 구성요소(예컨대, 제어기)에 탑재된 소프트웨어의 소스 코드가 검증 대상이 되므로 테스트의 활용성과 실효성이 보장될 수 있다.
프로그램 코드 관리부(101)의 구체적인 코드 관리 형태를 도 2 및 표 1을 참조하여 설명한다. 도 2는 본 발명의 일 실시예에 따른 사용자 인터페이스를 통해 입력되는 프로그램 형태의 일례를 나타낸다.
도 2를 참조하면, 3개의 함수(410, 420, 430)를 포함하는 프로그램(400)이 사용자 인터페이스(300)를 통해 테스트 장치에 입력될 수 있다. 그에 따라, 프로그램 코드 관리부(101)는 아래 표 1과 같은 형식으로 입력된 프로그램(400)을 관리/저장할 수 있다.
Figure pat00001
위 표 1에서, Line 항목은 "함수ID_함수 내 라인 수"의 형식으로 저장되며 함수 ID는 소프트웨어 상세 설계 문서 상의 함수 ID를 의미한다. 결국, 표 1을 통해, 소프트웨어 상세 설계 문서 상에서는 각 함수가 개별적인 ID를 가지고 관리됨을 알 수 있다.
다시 도 1로 복귀하여, 요구사항 문서 관리부(102)는 테스트 케이스(300) 생성을 위해 사용자로부터 획득한 문서들뿐만 아니라 테스트 케이스 생성을 위한 중간 단계의 문서들을 모두 관리/저장하며 문서 간 추적성을 위하여 필요한 정보를 저장할 수 있다.
테스트 범위 결정부(103)는 요구사항 문서 관리부(102)에 저장된 소프트웨어 상세 설계서를 사용하여 전체 프로그램 중 테스트를 수행할 범위를 결정할 수 있다. 테스트 범위는 안전 메커니즘과의 관련성, 즉 기술 안전 요구사항(TSR: Technical Safety Requirement)이 반영된 함수 및 해당 함수와 호출관계에 있는 함수에 해당하는지 여부에 따라 결정될 수 있다. 여기서, 기술 안전 요구사항은 ISO 26262 표준에 정의된 것일 수 있다.
테스트 설계서 생성부(104)는 테스트 범위 내에 있는 함수들에 관한 소프트웨어 상세 설계서를 사용하여 Safety Description(SD)를 탐색할 수 있다. 테스트 설계서 생성부(104)는 SD에 해당하는 FIT 관련정보로부터 결함을 주입할 위치(Injecting Location)를 테스트 설계서에 추가하게 되는데, 이때 주입 위치에 SD와 관련된 에러 타입이 발생하지 않을 경우 이를 제외한다. 테스트 설계서 생성부(104)는 주입 위치가 결정되면 결함 유형 체계표(FIT Faults)를 토대로 SD 형식으로부터 주입할 결함 유형(Injecting Details)을 테스트 설계서에 추가할 수 있다. 결함 유형 체계표의 구체적인 형태는 아래 표 2에 나타난 바와 같다.
테스트단계 결함발생위치 결함유형 Id
단위 Runnable 변수 전역변수 Data Error Invalid Value 1
테스트
SW-SW 통합 테스트 Runnable- Caller Parameter Data Error Invalid Value 2
Runnable 호출구문자체 Program Flow Error Uncalled Function 3
Bypass Function Call 4
Illegal Instruction 5
Callee 전역변수 Data Error Invalid Value 6
Access Error Invalid Address 7
리턴문 Data Error Invalid Value 8
Program Flow Error Illegal Instruction 9
Timing Error Data Loss 10
CPU Clock Corruption 11
SWC Caller Parameter Data Error Invalid Value 12
- Timing Error Data Delay 13
RTE Data Loss 14
호출구문자체 Program Flow Error Uncalled Function 15
Bypass Function Call 16
Illegal Instruction 17
Timing Error CPU Clock Corruption 18
Callee 전역변수 Data Error Invalid Value 19
Access Error Invalid Address 20
리턴문 Data Error Invalid Value 21
Program Flow Error Illegal Instruction 22
Timing Error Data Loss 23
No Response 24
CPU Clock Corruption 25
Asymmetric Error Asymmetric Value 26
SWC Caller Parameter Data Error Invalid Value 27
-
BSW Timing Error Data Delay 28
호출구문자체 Program Flow Error Uncalled Function 29
Bypass Function Call 30
Illegal Instruction 31
Timing Error CPU Clock Corruption 32
Callee 전역변수 Data Error Invalid Value 33
Access Error Invalid Address 34
리턴문 Data Error Invalid Value 35
Program Flow Error Illegal Instruction 36
Timing Error Data Loss 37
No Response 38
CPU Clock Corruption 39
Asymmetric Error Asymmetric Value 40
SWC Caller Parameter Data Error Invalid Value 41
- Timing Error Data Delay 42
ECU HW 호출구문자체 Program Flow Error Uncalled Function 43
Bypass Function Call 44
Illegal Instruction 45
Timing Error CPU Clock Corruption 46
Callee 전역변수 Data Error Invalid Value 47
Access Error Invalid Address 48
리턴문 Data Error Invalid Value 49
Program Flow Error Illegal Instruction 50
Timing Error Data Loss 51
No Response 52
CPU Clock Corruption 53
Asymmetric Error Asymmetric Value 54
표 2를 참조하면, 결함 유형 체계표(FIT Faults)는 개별적으로 ID가 할당된 결함 유형들을 복수의 카테고리에 따라 구분하여 정의한다. 예를 들어, 가장 큰 카테고리 구분은 테스트 단계이며, 테스트 단위별로 결함 발생 위치와 결함 유형 카테고리에 따라 세부 결함 유형들이 정의된다. 물론, 이러한 결함 유형 체계표는 예시적인 것으로, 반드시 표 2에 나타난 바와 동일해야 하는 것은 아니다.
주입할 결함 유형(Injecting Details)이 추가되면, 테스트 설계서 생성부(104)는 기술 안전 요구사항(TSR)으로부터 결함 발생 시 탐지/해결하는 메커니즘을 확인하여 최종적으로 테스트 설계서를 생성할 수 있다. 이때, 테스트 설계서 생성부(104)는 자연어로 작성된 TSR, 후술할 SDD 등에서 발생시 결함을 감지/해결하는 메커니즘을 텍스트처리를 통해 도출해낼 수 있다.
다음으로, 테스트 케이스 생성부(105)는 테스트 설계서 생성부(104)로부터 생성된 테스트 설계서와 프로그램 코드 관리부(101)에 저장된 프로그램 코드를 바탕으로 테스트 케이스(300)를 생성할 수 있다. 테스트 케이스는 ID, 주입 결함(Injected Fault(Line, Type, Code)) 및 예상 결과(Expected Results)를 포함할 수 있다. 여기서, 주입 결함 라인(Injected Fault Line)의 경우 테스트 설계서의 주입위치(Injecting Location)를 프로그램 코드에서 탐색하여 추출될 수 있며, 주입 결함 타입(Injected Fault Type)은 G(생성: Generation)과 M(변화: Mutation) 중 하나가 선택될 수 있다. 주입 결함 코드(Injected Fault Code)는 테스트 설계서의 정상 상태(Normal Condition) 항목을 위배하도록 생성되며 예상 결과(Expected Results)는 테스트 설계서의 핸들링(Handling) 항목을 통해 생성될 수 있다.
표 2에서 나타난 바와 같이, 테스트는 크게 단위 테스트와 통합 테스트로 구분될 수 있다. 단위 테스트는 단일 함수에 대한 테스트를 의미할 수 있으며, 통합 테스트는 서로 연관된(예컨대, 호출 관계) 둘 이상의 함수에 대한 테스트를 의미할 수 있다. 이하에서는 도 1을 참조하여 전술한 테스트 장치의 구성을 바탕으로, 도 3 및 도 4를 참조하여 단위 테스트와 통합 테스트 과정을 각각 설명한다.
도 3은 본 발명의 일 실시예에 따른 테스트 장치에서 수행되는 단위 테스트 과정의 일례를 나타내는 순서도이다.
도 3에 도시된 순서도의 순서를 설명하기 앞서, 입출력값을 먼저 설명한다.
소프트웨어 상세 디자인(Software Detailed Design)은 결함 주입 테스트를 위한 테스트 대상 식별 및 추후 테스트 케이스 생성 절차를 보다 수월하게 진행하기 위하여 보완된 소프트웨어 상세 설계 디자인 문서(SDD, Software Detailed Design)를 의미한다. 소프트웨어 상세 설계 디자인 문서의 일례가 아래 표 3에 나타나 있다.
Figure pat00002
표 3을 참조하면, SDD에는 소프트웨어를 구성하는 함수들에 대한 맵 구성, 관련 기술 안전 요구사항(TSR) 정보, 결함 주입 테스트와 관련된 전역변수, 리턴문, 호출 함수, 파라미터 정보 등이 포함될 수 있다.
이러한 SDD 문서는 다음과 같은 주의 사항에 따라 작성되는 것이 바람직하다.
소프트웨어 상세 설계 문서의 경우 소프트웨어의 기능적 행동뿐 아니라 내부에 설계된 안전 메커니즘에 대한 명세(SD, Safety Description)가 포함되어야 하며 모두 자연어로 기술하되 SD의 경우 아래 표 4와 같이 AUTOSAR 에러 타입에 기반하여 작성 형식을 구분한다.
Figure pat00003
표 4의 세부 내용은 아래와 같이 정의될 수 있다.
1) Data Value Requirement
- The SWC shall define VAR1 with range C1 to C2.
- The value of VAR1 shall be no greater(less) than C1.
2) Program Flow Requirement
- The correct reading of VAR1 through BSW/RTE shall be ensured.
- The correct transformation of VAR1 to CAN/SPI shall be ensured.
3) Access Address Requirement
- The reading/writing of VAR1 shall be done through BSW/RTE.
4) Timing Requirement
- The SWC shall set VAR1 on command, if a fault on VAR1 is detected for more than C1.
5) Asymmetric Requirement
- The correct routing of the output VAR1 shall be ensured.
위 정의에서, SWC는 소프트웨어 컴포넌를, VAR#은 변수를, C#은 상수를, CAN/SPI는 CAN, SPI 인터페이스 관련 함수를, BSW/RTE는 BSW, RTE계층 함수를 각각 나타낸다.
또한, 결함 유형 체계표(FIT Faults)는 표 2를 참조하여 전술한 바와 같다.
다음으로, 기술 안전 요구사항(Technical safety Requirement)은 ISO 26262표준에 정의된 기술 안전 요구사항(TSR)을 의미할 수 있다. TSR의 예시가 아래 표 5에 나타나 있다.
Figure pat00004
아울러, 프로그램 코드(program code)는 MATLAB이나 Simulink와 같이 모델 기반 개발을 지원하는 도구로부터 자동 생성되거나 개발자가 직접 작성한 프로그램 코드를 의미할 수 있다.
도 3을 참조하면, 단위 테스트 단계의 경우 먼저 테스트 범위 결정부(103)에서 소프트웨어 결함주입시험(SW FIT) 단위 시험 대상이 되는 소프트웨어 단위(즉, 함수)가 식별될 수 있다(S21). 테스트 대상은 소프트웨어 컴포넌트(Software Component, .c파일) 내의 함수 중 안전 메커니즘(Safety Mechanism)이 반영된 함수가 되는 것이 바람직하다. 이를 통해 식별된 테스트 대상은 FIT 대상 체계표의 형태로 요구사항 문서 관리부(102)에 저장/관리될 수 있다.
이후, 테스트 설계서 생성부(104)에서 단위 함수의 기능과 관련하여 발생 가능한 결함 위치가 추출될 수 있다(S22). 여기서, 발생 가능한 결함이란 소프트웨어가 안전한 상태(safe state)를 벗어나도록 유도하는 결함을 의미할 수 있다. 구체적으로, 테스트 설계서 생성부(104)는 테스트 대상으로 식별된 함수에 대해서는 소프트웨어 상세 설계 문서(Software Detailed Design)를 통해 함수 내 안전 메커니즘과 그와 관련된 전역 변수를 식별한 뒤 전역 변수 값의 오염으로 인해 발생 가능한 결함(Potential Causes of Failure)을 추출할 수 있다.
또한, 테스트 설계서 생성부(104)는 이전 단계(S22)에서 추출한 발생 가능한 결함 중 탐지 및 해결할 수 있는 안전 메커니즘이 시스템 내에 있는 것이 확인되면 결함 유형 체계표(FIT Faults)에 정의된 유형(예컨대, 표1의 54가지 FIT Fault 유형) 중 적용 가능한 결함 유형을 결정할 수 있다(S23).
이후, 테스트 설계서 생성부(104)는 결함 주입 전 상태를 확인할 수 있다(S24). 여기서, 결함 주입 전 상태란 결함을 주입하기 전 함수 혹은 변수의 상태, 즉, 정상 조건을 의미하며, 추후 테스트 케이스는 해당 상태를 벗어나도록 설계될 수 있다. 결함 주입 이전의 상태는 소프트웨어 상세 설계서(SDD)를 통해 확인 가능하며 구체적인 방법은 아래 표 6과 같은 정상 조건표를 확인하는 형태가 될 수 있다.
Figure pat00005
표 6을 참조하면, SD 형태(Form)에 따른 SD 상세(detail) 별로, 정상 상태(Normal Condition)가 정의되어 있다.
다음으로, 테스트 설계서 생성부(104)는 시스템 레벨의 설계 단계에서 작성한 기술 안전 요구사항 명세서를 참조하여 실제 결함 발생 시 이를 탐지하거나 해결할 수 있는 안전 메커니즘이 있는지 확인한다(S25).
이러한 과정들(S22 내지 S25)을 통해, 테스트 설계서 생성부(104)는 테스트 설계서를 생성할 수 있다.
테스트 설계서가 생성되면, 테스트 케이스 생성부(105)는 테스트 설계서 생성시 추출된 결함 위치를 프로그램 코드 내에서 탐색할 수 있다(S26).
주입할 결함 위치가 탐색되면, 테스트 케이스 생성부(105)는 컴파일 타임의 결함 주입 방식인 뮤테이션(M)과 제너레이션(G) 중 결함을 주입할 방식을 결정할 수 있다(S27).
다음으로, 테스트 케이스 생성부(105)는 실제 코드에 주입할 결함의 구체적인 내용을 결정할 수 있다(S28). 여기서, 주입 결함은 테스트 설계서 생성 시 확인한 결함 주입 이전의 정상 상태를 벗어나도록 설계되는 것이 바람직하다.
이후 테스트 케이스 생성부(105)는 결함 주입 이후 시스템/소프트웨어의 결과를 예측할 수 있다(S29). 이때, 결함 주입은 안전 메커니즘이 구현된 소프트웨어에서 이루어지므로 예상 결과는 에러 처리 메커니즘의 동작이 될 수 있다.
상술한 과정을 거쳐, 테스트 케이스 생성부(105)는 FIT 테스트 케이스를 생성할 수 있다.
다음으로, 도 4를 참조하여 통합 테스트 과정을 설명한다.
도 4는 본 발명의 일 실시예에 따른 테스트 장치에서 수행되는 통합 테스트 과정의 일례를 나타내는 순서도이다.
도 4에 도시된 과정은 도 3에 도시된 단위 테스트 과정과 유사하므로, 명세서의 간명함을 위하여 차이점만을 설명하기로 한다.
통합 테스트 과정에서는 단위 테스트에 적용되는 SDD 대신, AUTOSAR 계층별 설계 문서(Design Documents for each Autosar layer)가 테스트 범위 결정부(103) 및 테스트 설계서 생성부(104)의 입력값으로 사용된다. 따라서, 함수 식별 과정(S21)은 테스트 대상 내 호출관계에 있는 함수 정리 과정(S31)으로, 단위 함수 기능과 관련하여 발생 가능한 결함 위치 추출 과정(S22)은 함수간 호출 시 발생 가능한 결함 위치 추출 과정(S32)으로 각각 대체될 수 있다.
이후의 S33 내지 S39 과정은 전술한 S23 내지 S29 과정에 각각 대응되므로, 중복되는 기재는 생략하기로 한다.
이하에서는, 도 2에 예시된 프로그램을 참조하여 테스트 장치의 동작을 다시 설명하기로 한다.
먼저, 테스터는 사용자 인터페이스(200)를 통해 기술 안전 요구사항(TSR)과 소프트웨어 상세 설계서(SDD)를 불러와 요구사항 문서 관리부(102)에 저장한다. TSR은 표 5에 나타난 바와 같은 형태가, SDD는 표 3에 나타난 바와 같은 형태가 각각 될 수 있다.
유사하게, 예시된 프로그램에 대한 소스코드도 사용자 인터페이스(200)를 통해 프로그램 코드 관리부(101)에 저장될 수 있으며, 그 저장 형태는 전술한 바와 같이 표 1의 형태로 변환될 수 있다.
테스트 범위 결정부(103)는 단위 테스트의 경우 함수 FuncA()(410), FuncB()(420), FuncC()(430) 중 안전 메커니즘이 구현된(즉, TSR이 반영된) 함수 FuncA()(410)만을 테스트 대상으로 결정할 수 있다.
통합 테스트의 경우, 테스트 범위 결정부(103)는 안전 메커니즘이 구현된 FuncA()와의 호출관계(예컨대, FuncA()-FuncB()간의 함수호출, FuncA()-FuncC()간의 함수호출)를 테스트 대상으로 결정할 수 있다.
단위 테스트의 경우, 테스트 설계서 생성부(104)는 함수 FuncA()의 전역변수 "g_var1"이 주입위치(Injecting Location)의 후보로 판단할 수 있다. 테스트 설계서 생성부(104)는 SDD에 기술된 내용이 SD Form의 "Data value requirement"에 해당하고 표 2에 의하면 데이터 에러(data error)의 경우 전역변수에서 발생 가능하므로 "g_var1"을 결함 주입 위치로 선정할 수 있다.
통합 테스트의 경우, 테스트 설계서 생성부(104)는 FuncA()-FuncB()간 함수호출에서는 함수호출 구문 FuncB()와 FuncB()의 리턴문 "return5;"가 주입 위치(Injecting Location) 후보로 판단하며, FuncA()-FuncC()간 함수호출에서는 함수호출 구문 FuncC()와 파라미터 "var2"가 주입위치 후보로 판단할 수 있다. 테스트 설계서 생성부(104)는 SDD에 기술된 내용이 모두 "Data value requirement"에 해당하지만 표 2에 의하면 데이터 에러(data error)의 경우 전역변수, 파라미터, 리턴문에서만 발생 가능하므로 FuncB()와 FuncC()는 결함 주입 위치에서 제외된다.
이러한 과정을 통해 테스트 설계서 생성부(104)가 생성한 테스트 설계서의 형태가 도 5에 도시된다.
도 5는 본 발명의 일 실시예에 따른 테스트 설계서 형태의 일례를 나타낸다.
도 5를 참조하면, 테스트 설계서는 단위 테스트(510)의 경우 하나의 함수에 대한 ID, 주입위치, 결함타입, 정상상태, 디텍션 및 핸들링 값이 정의될 수 있으며, 통합 테스트(520)의 경우 호출관계를 갖는 함수들 중 결함 주입 위치에 해당하는 두 함수에 대하여 ID, 주입위치, 결함타입, 정상상태, 디텍션 및 핸들링 값이 각각 정의될 수 있다.
다음으로, 도 5와 같이 생성된 테스트 설계서에 따라 테스트 케이스 생성부(105)의 동작을 도 6을 참조하여 설명한다.
도 6은 본 발명의 일 실시예에 따른 테스트 케이스 형태의 일례를 나타낸다.
도 6을 참조하면, 테스트 케이스 생성부(105)는 단위 테스트(610)의 경우 테스트 설계서(510)의 "TS_001_1"과 관련해서 "g_var"의 위치 "001_2"가 Injected Fault Line이 되며 테스트 설계서의 "normal condition(range 0 to 10)"을 위배하기 위해 g_var의 값을 경계 값인 -1과 11로 만드는 코드를 Injected Fault Code로 결정할 수 있다. 예상 결과(Expected Results)는 테스트 설계서의 핸들링(Handling) 항목(TSR_002)이 될 수 있다.
통합 테스트(620)의 경우, 테스트 설계서(520)의 "TS_001_2"와 관련해서 리턴문 "return5;"의 위치 "002_1"이 Injected Fault Line이 되며, 테스트 설계서(520)의 "normal condition(no greater than 10)"을 위배하기 위해 리턴값을 경계 값인 11로 만드는 코드가 Injected Fault Code가 될 수 있다. 예상 결과(Expected Results)는 테스트 설계서의 핸들링(Handling) 항목(TSR_004)이 될 수 있다. 테스트 설계서(520)의 "TS_001_3"으로 부터의 테스트 케이스 생성 과정 역시 "TS_001_2"와 유사한 바, 중복되는 기재는 생략하기로 한다.
지금까지 설명한 실시예들에서, 테스트 장치의 프로그램 코드 관리부(101)와 요구사항 문서 관리부(102) 중 적어도 하나는 별도의 장치로 대체되거나 프로그램 기록 장치(메모리 등)나 차량용 제어기(ECU: Electronic Control Unit)로 분리되어 구현될 수도 있다.
또한, 테스트 케이스 생성부(105)는 자동 생성된 테스트케이스를 출력하는 것에 더불어, ECU등 프로그램 대상 결함주입 테스트 자동수행 및 판정, 결함주입 테스트 수행 결과 출력, 결함주입 시 Fail Safe 로직 누락되어 프로그램 오류발생 시 Fail Safe 로직 추천하여 코드수정 원활화 등의 동작을 더욱 수행할 수도 있다.
아울러, 도 3이나 도 4에서, SDD 대신 양산차량의 자동차 소프트웨어에서 과거 주로 발생하였던 결함패턴이 입력될 수도 있으며, 테스트 설계서 생성부(104)는 결함 발생시 탐지/해결 매커니즘의 존재를 확인할 뿐 아니라, 탐지/해결 매커니즘이 누락되었을 경우 적절한 탐지/해결 매커니즘을 추천하도록 구성될 수도 있다.
지금까지 설명한 본 발명의 실시예들에 의하면, 다음과 같은 장점이 있다.
본 발명의 실시예들은 AUTOSAR 기반 소프트웨어의 테스트케이스 생성방법 및 장치에 관한 것으로, 자연어로 기술된 요구사항(TSR, SD 등) 문서로부터 텍스트 처리를 통해 소스코드를 대상으로 소프트웨어 내 안전 메커니즘 동작을 확인하기 위한 테스트케이스를 자동 생성할 수 있어 편리하다.
또한, 본 발명에 따르면 결함주입 기법을 사용하여 AUTOSAR 기반의 소프트웨어의 단위 및 통합 테스트 수행 시 테스트 절차에 대한 신뢰성 확보와 개발 기간의 단축이 가능하다.
아울러, AUTOSAR 기반 소프트웨어에서 발생 가능한 결함 유형을 AUTOSAR 표준으로부터 정의하고 소프트웨어 안전 요구사항의 형식을 규정하여 주관이 개입되는 요구사항 작성을 객관화하며 텍스트 처리를 통해 자동으로 테스트 케이스의 생성이 가능하다.
전술한 본 발명은, 프로그램이 기록된 매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 매체는, 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 매체의 예로는, HDD(Hard Disk Drive), SSD(Solid State Disk), SDD(Silicon Disk Drive), ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장 장치 등이 있다.
따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.

Claims (19)

  1. 소프트웨어 상세 디자인을 기반으로 테스트 대상 프로그램에서 적어도 하나의 시험 대상 함수를 식별하는 단계;
    적어도 상기 식별된 적어도 하나의 시험 대상 함수의 기능과 관련하여 발생 가능한 결함 위치 및 상기 결함 위치에 주입할 결함 유형을 기반으로 테스트 설계서를 생성하는 단계;
    상기 생성된 테스트 설계서 및 상기 테스트 대상 프로그램의 소스 코드를 기반으로 상기 추출된 결함 위치 중 주입할 결함 위치를 탐색하는 단계;
    결함 주입 방식 및 결함 타입을 결정하는 단계; 및
    상기 탐색된 위치에 상기 결함 주입 방식 및 상기 결함 유형에 대응되는 결함 주입에 따른 예상 결과를 예측하여 테스트 케이스를 생성하는 단계를 포함하는, 테스트 장치의 제어방법.
  2. 제1 항에 있어서,
    상기 식별하는 단계는,
    단위 테스트의 경우 단위 함수를 식별하는 단계를 포함하는, 테스트 장치의 제어방법.
  3. 제2 항에 있어서,
    상기 테스트 설계서를 생성하는 단계는,
    상기 식별된 단위 함수의 기능과 관련하여 발생 가능한 결함 위치를 추출하는 단계를 포함하는, 테스트 장치의 제어방법.
  4. 제1 항에 있어서,
    상기 식별하는 단계는,
    통합 테스트의 경우 호출 관계에 있는 함수를 정리하는 단계를 포함하는, 테스트 장치의 제어방법.
  5. 제4 항에 있어서,
    상기 테스트 설계서를 생성하는 단계는,
    상기 정리된 함수간 호출시 발생 가능한 결함 위치를 추출하는 단계를 포함하는, 테스트 장치의 제어방법.
  6. 제1 항에 있어서,
    상기 테스트 설계서를 생성하는 단계는,
    상기 소프트웨어 상세 디자인을 기반으로 결함 주입 전 정상 상태를 확인하는 단계; 및
    결함 발생 시 탐지 및 해결 매커니즘을 기술 안전 요구사항(TSR)을 기반으로 확인하는 단계를 더 포함하는, 테스트 장치의 제어방법.
  7. 제6 항에 있어서,
    상기 테스트 케이스는,
    식별자(ID), 상기 결함 주입에 대응되는 라인, 상기 결함에 대응되는 유형, 상기 결함에 대응되는 결함 코드 및 상기 예상 결과 중 적어도 하나를 포함하는, 테스트 장치의 제어방법.
  8. 제7 항에 있어서,
    상기 결함 코드는, 상기 정상 상태을 위배하도록 생성되는, 테스트 장치의 제어방법.
  9. 제1 항에 있어서,
    상기 식별하는 단계는,
    안전 메커니즘이 반영된 함수 및 상기 안전 메커니즘이 반영된 함수와 호출 관계에 있는 함수에 대하여 수행되는, 테스트 장치의 제어방법.
  10. 제1 항 내지 제9 항 중 어느 한 항에 따른 테스트 장치의 제어방법을 실행시키기 위한 프로그램을 기록한 컴퓨터 해독 가능 기록 매체.
  11. 소프트웨어의 테스트 장치에 있어서,
    상기 테스트 대상 프로그램으로부터 안전 메커니즘과 관련된 함수 및 호출관계에 기반하여 테스트 범위를 추출하는 테스트 범위 결정부;
    상기 테스트 범위 및 적어도 하나의 요구사항 문서에 따라 주입할 결함 위치, 결함 유형 및 위배할 정상조건 중 적어도 하나를 포함하는 테스트 설계서를 생성하는 테스트 설계서 생성부; 및
    상기 테스트 대상 프로그램의 소스 코드 및 상기 테스트 설계서에 기반하여 테스트 케이스를 생성하는 테스트 케이스 생성부를 포함하는, 테스트 장치.
  12. 제11 항에 있어서,
    상기 소스 코드를 저장 및 관리하는 프로그램 코드 관리부; 및
    상기 적어도 하나의 요구사항 문서를 저장 및 관리하는 요구사항 문서 관리부를 더 포함하는, 테스트 장치.
  13. 제12 항에 있어서,
    상기 프로그램 코드 관리부는,
    상기 소스 코드를 소프트웨어 상세 설계 문서 상의 함수 식별자 및 동일 함수 식별자에 해당하는 함수의 라인에 따라 관리하는, 테스트 장치.
  14. 제11 항에 있어서,
    상기 테스트 범위 결정부는,
    단위 테스트의 경우 단위 함수를 상기 테스트 범위로 식별하고,
    통합 테스트의 경우 호출 관계에 있는 함수를 정리하여 상기 테스트 범위로 식별하는, 테스트 장치.
  15. 제14 항에 있어서,
    테스트 설계서 생성부는,
    상기 단위 테스트의 경우 상기 식별된 단위 함수의 기능과 관련하여 발생 가능한 결함 위치를 추출하고,
    상기 통합 테스트의 경우 상기 정리된 함수간 호출시 발생 가능한 결함 위치를 추출하는, 테스트 장치.
  16. 제11 항에 있어서,
    상기 테스트 설계서 생성부는,
    상기 테스트 범위에 대하여 소프트웨어 상세 설계서를 기반으로 안전 매커니즘을 탐색하고, 결함 유형 체계표를 기반으로 상기 주입할 결함 위치를 결정하는, 테스트 장치.
  17. 제16 항에 있어서,
    상기 테스트 설계서 생성부는,
    상기 안전 매커니즘과 관련된 에러 타입이 발생하지 않는 결함 위치를 상기 주입할 결함 위치에서 제외시키는, 테스트 장치.
  18. 제11 항에 있어서,
    상기 적어도 하나의 요구사항 문서는 자연어로 작성되고,
    상기 테스트 설계서 생성부는,
    상기 자연어로 작성된 상기 적어도 하나의 요구사항 문서로부터 텍스트 처리를 통해 결함 발생 시 탐지 및 해결 매커니즘을 확인하는, 테스트 장치.
  19. 제11 항에 있어서,
    상기 테스트 케이스는,
    식별자(ID), 결함 주입 라인, 상기 결함 유형, 상기 위배할 정상조건에 해당하는 결함 코드 및 예상 결과 중 적어도 하나를 포함하는, 테스트 장치.
KR1020190081419A 2019-07-05 2019-07-05 차량 기능 테스트 장치 및 그 제어 방법 KR20210004656A (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
KR1020190081419A KR20210004656A (ko) 2019-07-05 2019-07-05 차량 기능 테스트 장치 및 그 제어 방법
US16/908,307 US11599453B2 (en) 2019-07-05 2020-06-22 Vehicle function test apparatus and method of controlling the same
CN202010636930.1A CN112181800A (zh) 2019-07-05 2020-07-03 车辆功能测试装置及其控制方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020190081419A KR20210004656A (ko) 2019-07-05 2019-07-05 차량 기능 테스트 장치 및 그 제어 방법

Publications (1)

Publication Number Publication Date
KR20210004656A true KR20210004656A (ko) 2021-01-13

Family

ID=73919668

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020190081419A KR20210004656A (ko) 2019-07-05 2019-07-05 차량 기능 테스트 장치 및 그 제어 방법

Country Status (3)

Country Link
US (1) US11599453B2 (ko)
KR (1) KR20210004656A (ko)
CN (1) CN112181800A (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024053772A1 (ko) * 2022-09-08 2024-03-14 슈어소프트테크주식회사 단위 테스트 재사용 방법 및 컴퓨터 판독 가능 기록매체

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113535547B (zh) * 2021-06-18 2022-08-02 中汽研（天津）汽车工程研究院有限公司 一种基于功能安全的测试方法
CN114338451B (zh) * 2021-12-31 2023-10-13 武汉思普崚技术有限公司 一种控制器局域网总线测试***、方法和存储介质
CN114741284B (zh) * 2022-03-30 2023-02-07 中国电子产品可靠性与环境试验研究所（（工业和信息化部电子第五研究所）（中国赛宝实验室）） 任务可靠性评估方法、装置、计算机设备和存储介质
CN116431135B (zh) * 2023-06-12 2023-09-22 江西五十铃汽车有限公司 汽车代码编写方法、***、计算机及可读存储介质
CN117130945B (zh) * 2023-10-26 2024-02-09 中国证券登记结算有限责任公司 一种测试方法和装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101269549B1 (ko) * 2009-05-08 2013-06-04 한국전자통신연구원 오류 주입을 이용한 소프트웨어 신뢰성 테스트 시스템 및 방법
US8752027B2 (en) * 2011-09-14 2014-06-10 Microsoft Corporation Injecting faults into program for testing software
US9317408B2 (en) * 2011-12-15 2016-04-19 The Mathworks, Inc. System and method for systematic error injection in generated code
KR101291817B1 (ko) 2012-04-26 2013-07-31 비티에스테크놀로지스(주) 요구사항 모델 기반 테스트 케이스 자동 생성 시스템 및 방법
KR101695015B1 (ko) 2012-07-05 2017-01-11 한국전자통신연구원 오류 기반 소프트웨어 시험 방법 및 오류 기반 소프트웨어 시험 시스템
US9195555B2 (en) * 2013-05-24 2015-11-24 International Business Machines Corporation Error injection into the leaf functions of call graphs
US10108536B2 (en) * 2014-12-10 2018-10-23 General Electric Company Integrated automated test case generation for safety-critical software
KR20190079809A (ko) * 2017-12-28 2019-07-08 현대자동차주식회사 결함 주입 테스트 장치 및 그 방법
US10824529B2 (en) * 2017-12-29 2020-11-03 Intel Corporation Functional safety system error injection technology

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024053772A1 (ko) * 2022-09-08 2024-03-14 슈어소프트테크주식회사 단위 테스트 재사용 방법 및 컴퓨터 판독 가능 기록매체

Also Published As

Publication number Publication date
US11599453B2 (en) 2023-03-07
CN112181800A (zh) 2021-01-05
US20210001870A1 (en) 2021-01-07

Similar Documents

Publication Publication Date Title
KR20210004656A (ko) 차량 기능 테스트 장치 및 그 제어 방법
US8627296B1 (en) Unified unit and integration test with automatic mock creation
US8397104B2 (en) Creation of test plans
US10049031B2 (en) Correlation of violating change sets in regression testing of computer software
CN109726107A (zh) 测试方法、装置、设备及存储介质
US9619356B2 (en) Detection of hardware errors using periodically synchronized redundant transactions and comparing results from cores of a multi-core processor
CN111209206B (zh) 一种软件产品的自动测试方法及***
US10209984B2 (en) Identifying a defect density
CN103257919A (zh) 脚本程序检查方法和装置
CN101308471A (zh) 一种恢复数据的方法及装置
CN112241370B (zh) 一种api接口类的校验方法、***及装置
CN108572895B (zh) 一种Linux下自动检查软硬件配置的稳定性测试方法
US11288171B2 (en) Data verification apparatus, method and medium for determining whether referring parts of source code are executed
CN112925524A (zh) 一种检测驱动程序中不安全直接存储器访问的方法及装置
CN103365772B (zh) 软件测试自动评价装置以及方法
KR101563494B1 (ko) 파일 변경에 따른 실시간 소스코드 보안 약점 탐지 장치 및 방법
Flemström et al. Exploring test overlap in system integration: An industrial case study
CN115757099A (zh) 平台固件保护恢复功能自动测试方法和装置
JP5670156B2 (ja) テスト結果照合システム、方法、及びプログラム
CN109374038B (zh) 一种基于应用样机的核安全级仪控产品的变更测试方法
KR102176133B1 (ko) 소프트웨어 테스트 케이스 자동 생성 방법 및 장치
KR101534493B1 (ko) 구조 변환에 기초한 소스코드 보안 약점 탐지 장치 및 방법
US10970195B2 (en) Reduction of test infrastructure
JP2023000907A (ja) ソースコード修正支援装置及びソースコード修正支援方法
CN113157594B (zh) 一种用户权限测试方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
A201 Request for examination