KR102496539B1 - 소프트웨어 검증 방법 및 이를 위한 장치 - Google Patents
소프트웨어 검증 방법 및 이를 위한 장치 Download PDFInfo
- Publication number
- KR102496539B1 KR102496539B1 KR1020200175233A KR20200175233A KR102496539B1 KR 102496539 B1 KR102496539 B1 KR 102496539B1 KR 1020200175233 A KR1020200175233 A KR 1020200175233A KR 20200175233 A KR20200175233 A KR 20200175233A KR 102496539 B1 KR102496539 B1 KR 102496539B1
- Authority
- KR
- South Korea
- Prior art keywords
- module
- software
- function
- design document
- test case
- Prior art date
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/362—Software debugging
- G06F11/3624—Software debugging by performing operations on the source code, e.g. via a compiler
-
- 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/3664—Environments for 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/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/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
-
- 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/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/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
-
- 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/3696—Methods or tools to render software testable
-
- 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
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)
Abstract
소프트웨어를 검증하는 방법 및 장치가 제공된다. 본 발명의 일 실시예에 따른 소프트웨어 검증 방법은 소프트웨어 설계서에 포함된 검증 대상 모듈에 의해서 호출되는 함수에 대한 정보를 획득하는 단계; 상기 획득된 정보를 이용하여 함수들의 호출 순서를 확인하고, 상기 확인된 함수들의 호출 순서를 포함하는 기능 검증 테스트케이스를 생성하는 단계; 및 디버거(debugger)에 의해서 상기 검증 대상 모듈의 소스 코드가 실행될 때에 호출되는 함수 순서와 상기 기능 검증 테스트케이스에 포함된 함수 호출 순서를 비교하여 상기 소프트웨어 설계서에 따른 상기 검증 대상 모듈의 구현 여부를 판정하는 단계를 포함할 수 있다.
Description
본 발명은 소프트웨어를 검증하기 위한 방법에 관한 것이다. 보다 자세하게는, 소프트웨어의 기능을 통합하여 검증할 수 있는 기능 검증 테스트케이스를 이용하여 설계서에 따라 소프트웨어가 구현되었는지 여부를 판정하는 소프트웨어 검증 방법 및 이를 위한 장치에 관한 것이다.
소프트웨어를 개발하기 전에, 소프트웨어 설계서가 마련되고, 개발자는 상기 소프트웨어의 설계서에 따라 소스 코드를 작성한다. 상기 소스 코드는 프로그래밍 언어를 이용하여 작성된 것으로, C언어, 자바 스크립트, 파이썬 등과 같은 다양한 프로그래밍 언어를 이용하여 작성될 수 있다.
소스 코드의 작성이 완료되면, 상기 소스 코드가 상기 소프트웨어 설계서의 규격대로 구현되었는지 여부를 검증하기 위하여 소프트웨어 검증이 진행된다. 소프트웨어 검증을 위한 다양한 툴(tool)이 개발되었는데 이 중에서 소스 커버리지를 측정하는 방법도 이용되고 있다.
상기 코드 커버리지는 소프트웨어의 테스트를 수행할 때 코드가 얼마만큼 사용되고 설계서를 커버하고 있는지를 검증하기 위해서 사용되는 툴이다. 상기 코드의 구조는 구문(statement), 조건(condition), 결정(decision)으로 구분될 수 있으며, 소스 코드가 실행될 때에 해당 소스 코드가 구문 커버리지, 조건 커버리지, 결정 커버리지 중에서 하나 이상에 해당하는지를 함으로써, 소스 코드의 커버지리를 측정할 수 있다.
그런데 이러한 소프트웨어 검증 방식은, 단일 모듈에 대한 검증만을 주로 이루어지고 있다. 부연하면, 기존의 소프트웨어 검증 방식은, 하나의 모듈 내에서 함수(function)가 정상적으로 호출되어 이용되고 있는지 여부를 판정하고 있다. 즉, 기존의 소프트웨어 검증 방식은 모듈 블록 내의 소스 코드만을 대상으로 정상적인 함수 호출 실행 여부만을 검증할 뿐, 복수의 모듈들을 통합하여 검증하는 방식을 고려하고 있지 않다.
이에 따라, 복수의 모듈을 통합하여, 소프트웨어를 검증하는 방식이 요구되고 있다.
본 발명이 해결하고자 하는 기술적 과제는, 복수의 모듈을 통합하여 검증을 수행할 수 있는 소프트웨어 검증 방법 및 이를 위한 장치를 제공하는데 있다.
본 발명이 해결하고자 하는 다른 기술적 과제는, 기능 검증 테스트케이스를 통해서 용이하게 소프트웨어를 검증하는 방법 및 이를 위한 장치를 제공하는데 있다.
본 발명이 해결하고자 하는 또 다른 기술적 과제는, 각 모듈에서 함수 호출이 순서대로 진행되고 있는지 여부를 판정할 수 있는 소프트웨어 검증 방법 및 이를 위한 장치를 제공하는데 있다.
본 발명의 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명의 기술분야에서의 통상의 기술자에게 명확하게 이해 될 수 있을 것이다.
상기 기술적 과제를 해결하기 위한, 본 발명의 일 실시예에 따른 소프트웨어 검증 방법은 소프트웨어 설계서에 포함된 검증 대상 모듈에 의해서 호출되는 함수에 대한 정보를 획득하는 단계; 상기 획득된 정보를 이용하여 함수들의 호출 순서를 확인하고, 상기 확인된 함수들의 호출 순서를 포함하는 기능 검증 테스트케이스를 생성하는 단계; 및 디버거(debugger)에 의해서 상기 검증 대상 모듈의 소스 코드가 실행될 때에 호출되는 함수 순서와 상기 기능 검증 테스트케이스에 포함된 함수 호출 순서를 비교하여 상기 소프트웨어 설계서에 따른 상기 검증 대상 모듈의 구현 여부를 판정하는 단계를 포함할 수 있다.
상기 소프트웨어 검증 방법은, 상기 소프트웨어 설계서에서 입력 인터페이스와 출력 인터페이스에 대한 파라미터를 확인하는 단계; 상기 소프트웨어 설계서에서 각 모듈에서 이용되는 함수 정보를 확인하는 단계; 각 모듈들 간에 인터페이스와 각 모듈의 알고리즘을 확인하는 단계; 및 모듈별 함수 정보, 상기 입력 인터페이스와 출력 인터페이스 및 상기 모듈별 간의 인터페이스에 근거하여, 함수의 호출 순서를 확인하는 단계를 더 포함할 수 있다.
상기 알고리즘을 확인하는 단계는, 각 모듈의 소스 코드를 분석하여, 함수 호출 조건과 파라미터 설정값을 포함하는 상기 알고리즘을 모듈별로 확인하는 단계를 포함할 수 있다.
상기 기능 검증 테스트케이스를 생성하는 단계는, 듈별 함수 정보, 아키텍처의 입/출력 인터페이스별 파라미터 및 상기 모듈별 간의 인터페이스에 근거하여, 상기 기능 검증 테스트케이스에서의 예상 출력값을 확인하는 단계; 및 상기 예상 출력값을 포함하는 상기 기능 검증 테스트케이스를 생성하는 단계를 포함할 수 있다.
일 실시에에서, 상기 소프트웨어 검증 방법은, 상기 디버거에 의해서 실행된 소스 코드의 결과와 상기 테스트케이스에 포함된 상기 예상 출력값을 비교하여, 상기 소프트웨어 설계서에 따른 상기 검증 대상 모듈의 구현 여부를 판정하는 단계를 더 포함할 수 있다.
상기 함수 정보를 확인하는 단계는, 상기 소프트웨어 설계서에 포함된 단위 설계서를 이용하여 상기 함수 정보를 확인하는 단계를 포함할 수 있다.
상기 함수 정보는, 해당 모듈에서 이용하는 호출 함수, 피호출 함수 및 각 함수의 입력 파라미터와 출력 파라미터를 포함할 수 있다.
상기 소프트웨어 검증 방법은, 상기 기능 검증 테스트케이스를 상기 소프트웨어 설계서와 매핑하여 저장하는 단계를 더 포함할 수 있다.
일 실시예에서, 상기 디버거는 상기 매핑된 기능 검증 테스트케이스에 포함된 각 모듈을 기초로, 복수의 모듈의 소스 코드를 통합하여 분석할 수 있다.
상기 기술적 과제를 해결하기 위한, 본 발명의 다른 실시예에 따른 소프트웨어 검증 장치는 소프트웨어 설계서에 포함된 검증 대상 모듈에 의해서 호출되는 함수에 대한 정보를 획득하는 설계서 분석 모듈; 상기 획득된 정보를 이용하여 함수들의 호출 순서를 확인하고, 상기 확인된 함수들의 호출 순서를 포함하는 기능 검증 테스트케이스를 생성하는 테스트케이스 생성 모듈; 상기 검증 대상 모듈의 소스 코드를 실행하는 디버거(debugger); 및 상기 디버거에 의해 호출되는 함수 순서와 상기 기능 검증 테스트케이스에 포함된 함수 호출 순서를 비교하여 상기 소프트웨어 설계서에 따른 상기 검증 대상 모듈의 구현 여부를 판정하는 검증 모듈을 포함할 수 있다.
도 1은 본 발명의 일 실시예에 따른, 소프트웨어 검증 시스템을 나타내는 도면이다.
도 2는 도 1의 소프트웨어 검증 장치의 구성을 나타내는 도면이다.
도 3은 입/출력 인터페이스별 파라미터를 예시하는 도면이다.
도 4는 모듈의 함수 정보를 예시한 도면이다.
도 5는 코드 커버리지의 측정 결과와 함수 연결 관계를 예시하는 도면이다.
도 6은 각 모듈의 알고리즘을 예시하는 도면이다.
도 7은 모듈 간에 함수가 호출되는 순서를 예시하는 도면이다.
도 8은 함수 호출 순서와 테스트 시나리오를 예시하는 도면이다.
도 9는 본 발명의 다른 실시예에 따른 소프트웨어를 검증하는 방법을 설명하기 위한 흐름도이다.
도 10은 다양한 실시예에서 컴퓨팅 장치를 구현할 수 있는 예시적인 하드웨어 구성도이다.
도 2는 도 1의 소프트웨어 검증 장치의 구성을 나타내는 도면이다.
도 3은 입/출력 인터페이스별 파라미터를 예시하는 도면이다.
도 4는 모듈의 함수 정보를 예시한 도면이다.
도 5는 코드 커버리지의 측정 결과와 함수 연결 관계를 예시하는 도면이다.
도 6은 각 모듈의 알고리즘을 예시하는 도면이다.
도 7은 모듈 간에 함수가 호출되는 순서를 예시하는 도면이다.
도 8은 함수 호출 순서와 테스트 시나리오를 예시하는 도면이다.
도 9는 본 발명의 다른 실시예에 따른 소프트웨어를 검증하는 방법을 설명하기 위한 흐름도이다.
도 10은 다양한 실시예에서 컴퓨팅 장치를 구현할 수 있는 예시적인 하드웨어 구성도이다.
이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예들을 상세히 설명한다. 본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 게시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 발명의 게시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
다른 정의가 없다면, 본 명세서에서 사용되는 모든 용어(기술 및 과학적 용어를 포함)는 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 공통적으로 이해될 수 있는 의미로 사용될 수 있다. 또 일반적으로 사용되는 사전에 정의되어 있는 용어들은 명백하게 특별히 정의되어 있지 않는 한 이상적으로 또는 과도하게 해석되지 않는다. 본 명세서에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 발명을 제한하고자 하는 것은 아니다. 본 명세서에서, 단수형은 문구에서 특별히 언급하지 않는 한 복수형도 포함한다.
이하, 도면들을 참조하여 본 발명의 몇몇 실시예들을 설명한다.
도 1은 본 발명의 일 실시예에 따른, 소프트웨어 검증 시스템을 나타내는 도면이다.
도 1에 도시된 바와 같이, 소프트웨어 검증 시스템은 클라이언트 단말(200) 및 소프트웨어 검증 장치(100)를 포함할 수 있다. 상기 클라이언트 단말(200)과 소프트웨어 검증 장치(100)는 네트워크(300)를 통해서 서로 통신할 수 있다. 상기 네트워크(300)는 이동통신망과 유선 통신망을 포함하는 것으로서, 본 발명에 있어서 주지의 관용기술에 해당하므로 자세한 설명은 생략한다.
상기 클라이언트 단말(200)은 개인용 컴퓨터, 서버, 모바일 단말 등과 같은 통신 장치로서, 소프트웨어 검증 장치(100)에 접속하여 소프트웨어 설계서와 각 모듈의 소스 코드를 소프트웨어 검증 장치(100)에 등록할 수 있다. 상기 소프트웨어 설계서는 하나 이상의 아키텍처 설계서와 하나 이상의 단위 설계서를 포함할 수 있다. 상기 아키텍처 설계서에는 입력 인터페이스와 출력 인터페이스에 대한 파라미터가 기록되고, 단위 설계서에는 각 모듈의 함수 정보가 기록될 수 있다. 상기 함수 정보는 해당 모듈에서 이용하는 호출 함수, 피호출 함수, 호출 대상 함수 및 함수별 입/출력 파라미터를 포함할 수 있다. 상기 단위 설계서에 포함된 모듈은 해당 단위 기능이 수행될 때에 이용되는 모듈일 수 있다. 또한, 호출 함수는 해당 모듈에서 이용하는 호출하는 대표 함수이고, 호출 대상 함수는 상기 호출 함수를 호출하는 함수를 나타내고, 피호출 함수는 상기 호출 함수 내에서 호출되는 함수로서, 내부 함수 또는 외부 함수일 수 있다. 상기 내부 함수는 해당 모듈에서 자체적으로 처리하여 리턴할 수 있는 함수이고, 외부 함수는 타 모듈에서 실행되어 결과값이 상기 타 모듈로부터 결과값을 리턴받는 함수일 수 있다.
소프트웨어 검증 장치(100)는 상기 소프트웨어 설계서와 모듈별 소스 코드를 분석하여, 복수의 모듈을 통합하여 기능을 검증할 수 있는 하나 이상의 기능 검증 테스트케이스를 생성할 수 있다. 상기 소프트웨어 검증 장치(100)는 상기 기능 검증 테스트케이스를 이용하여, 검증 대상이 되는 하나 이상의 모듈이 상기 소프트웨어 설계서에 따라 구현되었는지 여부를 판정할 수 있다.
도 2는 도 1의 소프트웨어 검증 장치의 구성을 나타내는 도면이다.
도 2에 도시된 바와 같이, 본 발명의 일 실시예에 따른 소프트웨어 검증 장치(100)는 설계서 분석 모듈(110), 디버거(120), 테스트케이스 생성 모듈(130) 및 검증 모듈(140)을 포함할 수 있으며, 이러한 구성요소소들은 하드웨어 또는 소프트웨어로 구현되거나 하드웨어와 소프트웨어의 결합을 통해서 구현될 수 있다. 또한, 설계서 분석 모듈(110), 디버거(120), 테스트케이스 생성 모듈(130) 및 검증 모듈(140)은 후술하는 컴퓨팅 장치(1000)에서 실행될 수 있는 컴퓨터 프로그램(1500) 형태로 메모리(1400) 또는 스토리지(1300)에 저장될 수 있다.
설계서 분석 모듈(110)은 클라이언트 단말(200)로부터 소프트웨어의 설계서와 각 모듈별 소스 코드를 수신하고, 상기 소프트웨어의 설계서를 분석할 수 있다. 일 실시예에서, 설계서 분석 모듈(110)은 상기 소프트웨어 설계서에 포함된 아키텍처 설계서를 분석하여, 상기 아키텍처 설계서에서 입력 인터페이스와 출력 인터페이스 각각에 대한 파라미터를 확인할 수 있다. 상기 설계서 분석 모듈(110)은 아키텍처 설계서에 기재된 텍스트를 약속된 규칙에 따라 파싱(parsing)함으로써, 입력 인터페이스와 출력 인터페이스 각각에 대한 파라미터를 확인할 수 있다.
도 3은 입/출력 인터페이스별 파라미터를 예시하는 도면이다.
도 3에 예시된 바와 같이, "DRV_Door"의 명칭을 가지는 입력 인터페이스는 파라미터 a와 관련되고, "RKE_Lock_SW"의 명칭을 가지는 입력 인터페이스는 파라미터 b와 관련되며, "DRV_Door_Lock_Rly"의 명칭을 가지는 출력 인터페이스는 파라미터 c와 관련될 수 있다. 설계서 분석 모듈(110)은 아키텍처 설계서를 분석하여 입력 인터페이스와 출력 인터페이스 각각과 관련된 파라미터를 확인할 수 있다.
또한, 설계서 분석 모듈(110)은 상기 소프트웨어 설계서에 포함된 단위 설계서를 분석하여, 상기 단위 설계서에서 하나 이상의 모듈에서 이용되는 함수 정보를 획득할 수 있다, 상기 함수 정보는 하나 이상의 호출 함수, 피호출 함수 및 각 함수의 입/출력 파라미터를 포함할 수 있다. 상기 설계서 분석 모듈(110)은 단위 설계서에 기재된 텍스트를 약속된 규칙에 따라 파싱(parsing)함으로써, 모듈을 식별하고 해당 모듈에서 호출하는 하나 이상의 호출 함수, 피호출 함수 및 함수의 입/출력 파라미터를 확인할 수 있다.
도 4는 모듈의 함수 정보를 예시한 도면이다.
도 4에 예시된 바와 같이, 특정 모듈은 복수의 함수 정보를 포함할 수 있다. 도 4의 (a)에 따르면, "functionA"라는 명칭을 가지는 함수는 출력 파라미터로서 a, b를 가지고, 피호출 함수로서 "functionB", "functionA1"와 연관되고, 호출 대상 함수로서 "Tack_A"라는 명칭을 가지는 함수와 연관될 수 있다. 도 4의 (a)에 따르면,"functionA"는 "Task_A"함수를 통해서 호출되어, 피호출 함수인 "functionB", "functionA1"중에서 하나 이상을 호출하고, 더불어 파라미터 a, 파라미터 b 중에서 하나 이상을 출력할 수 있다.
도 4의 (b)에 따르면, "functionB"라는 명칭을 가지는 함수는 입력 파라미터 a를 가지고, 출력 파라미터 b를 가지며, 피호출 함수로서 "functionC"와 연관되고, 호출 대상 함수로서 "functionA"함수와 연관될 수 있다. 도 4의 (b)에 따르면,"functionB"는 "functionA"함수를 통해서 호출될 수 있으며, 피호출 함수인 "functionC"을 호출할 수 있고, 파라미터 b를 출력할 수 있다. 설계서 분석 모듈(110)은 단위 설계서를 이용하고 분석하여 도 4와 같은 함수 정보를 획득할 수 있다.
다른 실시예로서, 설계서 분석 모듈(110)은 클라이언트 단말(200)로부터 입력 인터페이스와 출력 인터페이스 각각에 대한 파라미터를 입력 받을 수 있으며, 또한, 각 모듈의 함수 정보를 입력 받을 수 있다.
디버거(debugger)(120)는 단위 설계서에 포함된 모듈의 소스 코드에 대한 커버리지를 측정을 수행하고, 상기 측정한 코드 커버리지 측정 결과에 기초하여 각 모듈들 간의 인터페이스를 확인할 수 있다. 디버거(120)는 DT10, LDRA, VectorCAST, CodeScroll Controller Tester, QualityScroll Cover 등과 같은 공지된 툴을 이용하여 상기 코드 커버리지 측정을 수행할 수 있다.
도 5는 코드 커버리지의 측정 결과와 함수 연결 관계를 예시하는 도면이다.
도 5의 (a)에 예시된 바와 같이, 디버거(120)는 각 함수의 구문(statement) 커버리지와 조건(condition) 커버리지가 퍼센트(%)로 측정할 수 있다. 도 5의 (b)에 예시된 바와 같이, 디버거(120)는 코드 커버리지 측정 결과를 토대로, 각 함수의 호출 관계가 수평적 관계인지 수직적인 관계인지를 확인할 수 있다. 도 5의 (a)에 따르면, "Function A", "Function B", "Function C"각각은 수평적인 관계이고, "Function A"는 "Function A1"와 "Function A2"는 수직적인 관계일 수 있다. 수평적인 관계는 외부 함수가 이용되는 경우에 발생하고, 수직적인 관계는 내부 함수가 이용될 경우 발생할 수 있다. 상기 "Function A1"와 "Function A2"는 "Function A"에 대한 내부 함수일 수 있다.
또한, 디버거(120)는 해당 모듈의 소스 코드를 분석하여, 함수 호출 조건과 파라미터 설정값을 포함하는 각 모듈의 알고리즘을 파악할 수 있다.
도 6은 각 모듈의 알고리즘을 예시하는 도면이다.
도 6의 (a)는 모듈 A의 소스 코드를 통해서 파악된 알고리즘을 예시하는 것으로서, 초기에는 "functionA1"와 "functionB"가 호출되고, 파라미터 a와 b의 비교 결과에 따라 "functionA2"가 호출되거나, 파라미터 a와 b가 "0"으로 설정되는 것을 예시하고 있다. 도 6의 (b)는 모듈 B의 소스 코드를 통해서 파악된 알고리즘을 예시하는 것으로서, 파라미터 a가 1인지 여부에 따라"functionC"가 호출되거나, 파라미터 c가 "0"으로 설정되는 것을 예시하고 있다.
디버거(120)는 단위 설계서에 포함된 모듈의 소스코드를 분석할 때, 상기 단위 설계서가 기능 검증 테스트케이스와 매핑되어 있는 경우, 상기 단위 설계서에 포함된 복수의 모듈에 확인하고, 상기 복수의 모듈을 통합하여 소스코드를 분석할 수 있다. 상기 디버거(120)는 각 모듈의 마지막 분기점에서 이용되는 함수와 상기 함수를 제공하는 모듈을 식별함으로써, 상기 복수의 모듈들에 대한 소스코드를 통합하여 분석할 수 있다. 즉, 디버거(120)는 기능 검증 테스트케이스를 활용하여, 연관성이 있는 복수의 모듈들을 통합하여 분석할 수 있다.
테스트케이스 생성 모듈(130)은 상기 모듈별 함수 정보, 아키텍처의 입/출력 인터페이스별 파라미터, 상기 모듈들 간의 인터페이스, 상기 모듈별 알고리즘 중에서 하나 이상에 근거하여, 각 함수의 호출 순서를 확인하고 더불어 예상되는 출력 결과를 확인한 후, 상기 각 함수의 호출 순서와 출력 결과를 포함하는 기능 검증 테스트케이스를 생성할 수 있다. 상기 기능 검증 테스트케이스에는 상기 호출 순서에 따라 호출되는 함수와 관련되는 모듈들의 식별정보가 포함되어 있어, 디버거(120)에서 연관되는 각각의 모듈들을 식별할 수 있다. 상기 테스트케이스 생성 모듈(130)은 상기 생성한 기능 검증 테스트케이스를 해당 아키텍처 설계서와 단위 설계서와 매핑할 수 있다. 예컨대, 상기 기능 검증 테스트케이스가 모듈 A와 모듈 B와 관련되어 있는 경우, 상기 기능 검증 테스트케이스는 단위 설계서#1와 단위 설계서#2와 매핑될 수 있다. 상기 테스트케이스 생성 모듈(130)은 모듈별 함수 호출 순서에 따라 상기 기능 검증 테스트케이스와 관련된 모듈들을 식별할 수 있다.
도 7은 모듈 간에 함수가 호출되는 순서를 예시하는 도면이다.
도 7에 예시된 바와 같이, "Task_A"가 발생하면, 모듈 A의"functionA", 모듈 B의 "functionB", 모듈 C의 "functionC"가 순차적으로 호출되는 것을 예시하고 있다. 또한, 테스트케이스 생성 모듈(130)은 도 7에 예시된 것 이외에, 상기 모듈별 함수 정보, 아키텍처의 입/출력 인터페이스별 파라미터 및 상기 모듈별 알고리즘에 근거하여, 또 다른 함수 호출 순서를 파악할 수 있다.
도 8은 함수 호출 순서와 테스트 시나리오를 예시하는 도면이다.
도 8을 참조하면, "FunctionalTest_01"의 명칭을 가지는 기능 검증 테스트케이스는 "functionA"-> "functionA1"에 해당하는 따른 제1 함수 호출 순서, "functionA"-> "functionB"-> "functionC"에 해당하는 따른 제2 함수 호출 순서, "functionA"-> "functionA2"에 해당하는 따른 제3 함수 호출 순서를 포함할 수 있다. "FunctionalTest_01"기능 검증 테스트케이스는 테스트 시나리오로서, 입력 인터페이스 "DRV_Door"와 "RKE_Lock_SW"를 포함할 수 있으며, 또한 예상되는 출력값으로서 출력 인터페이스 "DRV_Door_Lock_Rly"가 턴온되는 것을 포함할 수 있다.
도 8에서 "InterfaceTest_01"과 "InterfaceTest_01"는 종래의 검증 방법에 따라 검증된 것을 예시하는 것으로서, 내부 인터페이스(즉, 내부 함수)인 "functionA1"과 "functionA2"가 누락되어 있다. 또한, "InterfaceTest_01"과 "InterfaceTest_01"는 특정 모듈에만 적용되는 것을 한정되어 있고, 복수의 모듈의 통합하여 이용하고 있지 않을 뿐만 아니라, 최종 출력 결과물에 대해서 전혀 예상하고 있지 못하고 있다. 즉, 종래의 검증에 따른 "InterfaceTest_01"과 "InterfaceTest_01"는 복수의 모듈을 통합하여 기능적인 검증을 수행하지 못하고 있다.
반면에, 본 실시예에 따라 생성된 기능 검증 테스트케이스인 "FunctionalTest_01"은, 복수 모듈들 간에 이용되는 함수 호출 순서를 포함하고 있으며, 더불어 최종 결과값도 예상하고 있다. 이에 따라, 본 실시예에 다른 기능 검증 테스트케이스를 이용하는 경우, 복수의 모듈을 통합하여 검증할 수 있고, 더불어 최종 결과물이 정확한지 여부도 확인할 수 있다.
검증 모듈(140)은 상기 기능 검증 테스트케이스에 관련된 복수의 모듈을 검증 대상 모듈로서 선정하고, 상기 디버거(120)를 이용하여 상기 선정된 복수의 검증 대상 모듈의 소스 코드가 분석되게 할 수 있다. 검증 모듈(140)은 디버거(120)에 의해 복수의 검증 대상 모듈에 대한 소스 코드 분석이 실행되면, 디버거에서 호출하는 함수 순서를 상기 기능 검증 테스트케이스에서 포함된 함수 호출 순서와 일치하는 여부를 확인하여, 상기 소스 코드가 상기 소프트웨어 설계서에 따라 정확하게 구현되었는지 여부를 판정할 수 있다. 상기 기능 검증 테스트케이스에 포함된 함수 호출 순서가 복수 개인 경우, 검증 모듈(140)은 디버거(120)에서 호출하는 함수 순서가 복수의 함수 호출 순서 중에서 어느 하나와 일치하는지 여부를 확인하여, 소프트웨어 구현 여부를 판정할 수 있다. 검증 모듈(140)은 디버거(120)의 함수 호출 순서가 기능 검증 테스트케이스에 포함된 호출 함수 순서와 일치하지 않으면, 소프트웨어 검증을 실패로서 판정할 수 있다.
또한, 검증 모듈(140)은 상기 디버거(120)에 의해서 출력된 결과와 상기 기능 검증 테스트케이스에 포함된 예상 출력 결과를 비교하여, 상기 소스 코드가 상기 소프트웨어 설계서에 따라 정확하게 구현되었는지 여부를 판정할 수 있다. 검증 모듈(140)은 디버거(120)의 출력 결과와 기능 검증 테스트케이스에 포함된 예상 출력 결과 중에서 어느 하나와 일치하지 않으면, 소프트웨어 검증을 실패로서 판정할 수 있다.
검증 모듈(140)은 디버거(120)의 함수 호출 순서가 기능 검증 테스트케이스에 포함된 호출 함수 순서와 일치하고, 디버거(120)에 의해서 출력된 결과와 기능 검증 테스트케이스에 포함된 예상 출력 결과가 일치하면, 소프트웨어 검증을 성공으로서 판정할 수 있다. 검증 모듈(140)은 판정된 결과를 클라이언트 단말(200)로 전송할 수 있으며, 보고서 형태로 작성하여 저장할 수도 있다.
본 실시예에 따르면, 모듈들 간의 연관성과 함수 호출 순서를 기초로 기능 검증 테스트케이스를 생성하고, 상기 기능 검증 테스트케이스를 이용하여 모듈들을 통합하여 검증할 수 있게 함으로써, 소프트웨어의 기능 검증을 수행할 때에 편의성과 정확성을 향상시킬 수 있다. 또한, 본 실시예에 따르면, 기능 검증 테스트케이스에 포함된 데이터와 디버거(120)에 의해 수행된 테스트 결과를 비교하여, 정확하게 소프트웨어를 검증함으로써, 소프트웨어의 구현 오류를 확실하게 파악할 수 있는 효과를 발휘할 수 있다.
도 9는 본 발명의 다른 실시예에 따른 소프트웨어를 검증하는 방법을 설명하기 위한 흐름도이다.
도 9를 참조하면, 설계서 분석 모듈(110)은 클라이언트 단말(200)로부터 소프트웨어의 설계서와 각 모듈별 소스 코드를 수신할 수 있다(S101).
이어서, 설계서 분석 모듈(110)은 상기 소프트웨어 설계서에 포함된 아키텍처 설계서를 분석하여, 상기 아키텍처 설계서에서 입력 인터페이스와 출력 인터페이스 각각에 대한 파라미터를 확인할 수 있다. 다음으로, 설계서 분석 모듈(110)은 상기 소프트웨어 설계서에 포함된 단위 설계서를 분석하여, 상기 단위 설계서에서 하나 이상의 모듈에서 이용되는 함수 정보를 확인할 수 있다(S103).
이어서, 디버거(120)는 단위 설계서에 포함된 소스 코드에 대한 커버리지를 측정을 수행하고, 상기 측정한 코드 커버리지 측정 결과에 기초하여 각 모듈들 간의 인터페이스를 확인할 수 있다(S105). 또한, 디버거(120)는 상기 소스 코드를 분석하여, 함수 호출 조건과 파라미터 설정값을 포함하는 각 모듈의 알고리즘을 파악할 수 있다.
다음으로, 테스트케이스 생성 모듈(130)은 상기 모듈별 함수 정보, 아키텍처의 입/출력 인터페이스별 파라미터, 상기 모듈들 간의 인터페이스, 상기 모듈별 알고리즘 중에서 하나 이상에 근거하여, 각 함수의 호출 순서를 확인하고 더불어 예상되는 출력 결과를 확인한 후, 상기 각 함수의 호출 순서와 출력 결과를 포함하는 기능 검증 테스트케이스를 생성할 수 있다(S107). 상기 기능 검증 테스트케이스에는 상기 호출 순서에 따라 호출되는 함수와 관련되는 모듈들의 식별정보가 포함되어 있다.
이어서, 테스트케이스 생성 모듈(130)은 상기 생성한 기능 검증 테스트케이스를 해당 아키텍처 설계서와 단위 설계서와 매핑할 수 있다(S109).
검증 모듈(140)은 상기 기능 검증 테스트케이스에 관련된 하나 이상의 모듈을 검증 대상 모듈로서 선정하고, 디버거(120)를 이용하여 검증 대상 모듈에 해당하는 소스 코드가 분석되게 할 수 있다. 일 실시예에서, 디버거(120)는 상기 기능 검증 테스트케이스에 근거하여, 각 검증 대상 모듈의 마지막 분기점에서 이용되는 함수와 상기 함수를 제공하는 모듈을 식별함으로써, 상기 복수의 모듈들의 소스코드를 통합하여 분석할 수 있다. 즉, 디버거(120)는 기능 검증 테스트케이스를 활용하여, 연관성이 있는 복수의 모듈들의 소스코드를 통합하여 분석할 수 있다. 이어서, 검증 모듈(140)은 디버거(120)에 의해 검증 대상 모듈에 대한 소스 코드 분석이 실행되면, 디버거(120)에서 호출하는 함수 순서를 상기 기능 검증 테스트케이스에서 포함된 함수 호출 순서와 일치하는 여부를 확인하여, 상기 소스 코드가 상기 소프트웨어 설계서에 따라 정확하게 구현되었는지 여부를 1차로 판정할 수 있다(S111).
다음으로, 검증 모듈(140)은 상기 디버거(120)에 의해서 출력된 결과와 상기 기능 검증 테스트케이스에 포함된 예상 출력 결과를 비교하여, 상기 소스 코드가 상기 소프트웨어 설계서에 따라 정확하게 구현되었는지 여부를 2차로 판정할 수 있다. 이어서, 검증 모듈(140)은 판정된 결과를 클라이언트 단말(200)로 전송할 수 있으며, 보고서 형태로 작성하여 저장할 수도 있다.
본 실시예에 따르면, 기능 검증 테스트케이스를 생성하고 상기 기능 검증 테스트케이스를 이용하여 모듈들을 통합하여 검증할 수 있는 효과를 발휘할 수 있다. 또한, 본 실시예에 따르면, 기능 검증 테스트케이스를 단위 설계서와 매핑하여 저장함으로써, 추후에 디버거(120)가 상기 단위 설계서에 해당하는 모듈을 분석할 때에, 상기 모듈과 연관된 타 모듈도 통합하여 검증되게 함으로써, 검증 시간을 단축시킬 수 있는 효과를 발휘할 수 있다.
이하, 몇몇 실시예들에 따른 예시적인 컴퓨팅 장치의 하드웨어 구성을 도 9를 참조하여 설명하기로 한다.
도 10은 다양한 실시예에서 컴퓨팅 장치를 구현할 수 있는 예시적인 하드웨어 구성도이다.
본 실시예에 따른 컴퓨팅 장치(1000)는 하나 이상의 프로세서(1100), 시스템 버스(1600), 통신 인터페이스(1200), 프로세서(1100)에 의하여 수행되는 컴퓨터 프로그램(1500)을 로드(load)하는 메모리(1400)와, 컴퓨터 프로그램(1500)을 저장하는 스토리지(1300)를 포함할 수 있다. 도 10에서는 실시예와 관련 있는 구성요소들 만이 도시되어 있다. 따라서, 본 명세서의 실시예들이 속한 기술분야의 통상의 기술자라면 도 10에 도시된 구성요소들 외에 다른 범용적인 구성 요소들이 더 포함될 수 있음을 알 수 있다.
프로세서(1100)는 컴퓨팅 장치(1000)의 각 구성의 전반적인 동작을 제어한다. 프로세서(1100)는 CPU(Central Processing Unit), MPU(Micro Processor Unit), MCU(Micro Controller Unit), GPU(Graphic Processing Unit) 또는 본 명세서의 기술 분야에 잘 알려진 임의의 형태의 프로세서 중 적어도 하나를 포함하여 구성될 수 있다. 또한, 프로세서(1100)는 다양한 실시예들에 따른 방법/동작을 실행하기 위한 적어도 하나의 애플리케이션 또는 프로그램에 대한 연산을 수행할 수 있다. 컴퓨팅 장치(1000)는 둘 이상의 프로세서를 구비할 수 있다.
메모리(1400)는 각종 데이터, 명령 및/또는 정보를 저장한다. 메모리(1400)는 본 명세서의 다양한 실시예들에 따른 방법/동작들을 실행하기 위하여 스토리지(1300)로부터 하나 이상의 프로그램(1500)을 로드(load) 할 수 있다. 메모리(1400)의 예시는 RAM이 될 수 있으나, 이에 한정되는 것은 아니다.
시스템 버스(1600)는 컴퓨팅 장치(1000)의 구성 요소 간 통신 기능을 제공한다. 상기 시스템 버스(1600)는 주소 버스(Address Bus), 데이터 버스(Data Bus) 및 제어 버스(Control Bus) 등 다양한 형태의 버스로 구현될 수 있다. 통신 인터페이스(1200)는 네트워크(300)와 연결할 수 있다. 스토리지(1300)는 하나 이상의 컴퓨터 프로그램(1500)을 비임시적으로 저장할 수 있다. 스토리지(1300)는 플래시 메모리 등과 같은 비휘발성 메모리, 하드 디스크, 착탈형 디스크, 또는 본 명세서의 실시예들이 속하는 기술 분야에서 잘 알려진 임의의 형태의 컴퓨터로 읽을 수 있는 기록 매체를 포함하여 구성될 수 있다.
컴퓨터 프로그램(1500)은 본 명세서의 다양한 실시예들에 따른 방법/동작들이 구현된 하나 이상의 인스트럭션(instruction)들을 포함할 수 있다. 컴퓨터 프로그램(1500)이 메모리(1400)에 로드 되면, 프로세서(1100)는 상기 하나 이상의 인스트럭션들을 실행시킴으로써 본 명세서의 다양한 실시예들에 따른 방법/동작들을 수행할 수 있다. 컴퓨터 프로그램(1500)은, 상술한 리퀘스트 핸들링 동작을 위한 인스트럭션들을 포함할 수 있다. 몇몇 실시예에서, 컴퓨터 프로그램(1500)은 도 2 내지 도 9를 참조하여 설명하는 설계서 분석 모듈(110)의 동작을 수행하기 위한 하나 이상의 인스트럭션, 디버거(120)의 동작을 수행하기 위한 하나 이상의 인스트럭션, 테스트케이스 생성 모듈(130)의 동작을 수행하기 위한 하나 이상의 인스트럭션 및 검증 모듈(140)의 동작을 수행하기 위한 하나 이상의 인스트럭션을 포함할 수 있다.
일 실시예에서, 상기 컴퓨터 프로그램(1500)은 소프트웨어 설계서에 포함된 검증 대상 모듈에 의해서 호출되는 함수에 대한 정보를 획득하는 동작; 상기 획득된 정보를 이용하여 함수들의 호출 순서를 확인하고, 상기 확인된 함수들의 호출 순서를 포함하는 기능 검증 테스트케이스를 생성하는 동작; 및 디버거(debugger)에 의해서 상기 검증 대상 모듈의 소스 코드가 실행될 때에 호출되는 함수 순서와 상기 기능 검증 테스트케이스에 포함된 함수 호출 순서를 비교하여 상기 소프트웨어 설계서에 따른 상기 검증 대상 모듈의 구현 여부를 판정하는 동작을 수행하기 위한 인스트럭션들을 포함할 수 있다.
지금까지 설명된 본 발명의 실시예에 따른 방법들은 컴퓨터가 읽을 수 있는 코드로 구현된 컴퓨터프로그램의 실행에 의하여 수행될 수 있다. 상기 컴퓨터프로그램은 인터넷 등의 네트워크를 통하여 제1 컴퓨팅 장치로부터 제2 컴퓨팅 장치에 전송되어 상기 제2 컴퓨팅 장치에 설치될 수 있고, 이로써 상기 제2 컴퓨팅 장치에서 사용될 수 있다. 상기 제1 컴퓨팅 장치 및 상기 제2 컴퓨팅 장치는, 서버 장치, 클라우드 서비스를 위한 서버 풀에 속한 물리 서버, 데스크탑 피씨와 같은 고정식 컴퓨팅 장치를 모두 포함한다.
상기 컴퓨터프로그램은 DVD-ROM, 플래시 메모리 장치 등의 기록매체에 저장된 것일 수도 있다.
이상 첨부된 도면을 참조하여 본 발명의 실시예들을 설명하였지만, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적인 것이 아닌 것으로 이해해야만 한다.
Claims (15)
- 소프트웨어 설계서에 포함된 검증 대상 모듈에 의해서 호출되는 함수에 대한 정보를 상기 소프트웨어 설계서에서 획득하는 단계;
상기 획득된 정보를 이용하여 함수들의 호출 순서를 확인하고, 상기 확인된 함수들의 호출 순서를 포함하는 기능 검증 테스트케이스를 생성하는 단계; 및
디버거(debugger)에 의해서 상기 검증 대상 모듈의 소스 코드가 실행될 때에 호출되는 함수 순서와 상기 기능 검증 테스트케이스에 포함된 함수 호출 순서를 비교하여 상기 소프트웨어 설계서에 따른 상기 검증 대상 모듈의 구현 여부를 판정하는 단계를 포함하는,
소프트웨어 검증 방법. - 제1 항에 있어서,
상기 소프트웨어 설계서에서 입력 인터페이스와 출력 인터페이스에 대한 파라미터를 확인하는 단계;
상기 소프트웨어 설계서에서 각 모듈에서 이용되는 함수 정보를 확인하는 단계;
각 모듈들 간에 인터페이스와 각 모듈의 알고리즘을 확인하는 단계; 및
모듈별 함수 정보, 상기 입력 인터페이스와 출력 인터페이스 및 상기 모듈별 간의 인터페이스에 근거하여, 함수의 호출 순서를 확인하는 단계를 더 포함하는,
소프트웨어 검증 방법. - 제2 항에 있어서,
상기 알고리즘을 확인하는 단계는,
각 모듈의 소스 코드를 분석하여, 함수 호출 조건과 파라미터 설정값을 포함하는 상기 알고리즘을 모듈별로 확인하는 단계를 포함하는,
소프트웨어 검증 방법. - 제2 항에 있어서,
상기 기능 검증 테스트케이스를 생성하는 단계는,
모듈별 함수 정보, 아키텍처의 입/출력 인터페이스별 파라미터 및 상기 모듈별 간의 인터페이스에 근거하여, 상기 기능 검증 테스트케이스에서의 예상 출력값을 확인하는 단계; 및
상기 예상 출력값을 포함하는 상기 기능 검증 테스트케이스를 생성하는 단계를 포함하는,
소프트웨어 검증 방법. - 제4 항에 있어서,
상기 디버거에 의해서 실행된 소스 코드의 결과와 상기 테스트케이스에 포함된 상기 예상 출력값을 비교하여, 상기 소프트웨어 설계서에 따른 상기 검증 대상 모듈의 구현 여부를 판정하는 단계를 더 포함하는,
소프트웨어 검증 방법. - 제2 항에 있어서,
상기 파라미터를 확인하는 단계는,
상기 소프트웨어 설계서에 포함된 아키텍처 설계서를 이용하여 상기 입력 인터페이스와 상기 출력 인터페이스에 대한 파라미터를 확인하는 단계를 포함하는,
소프트웨어 검증 방법. - 제2 항에 있어서,
상기 함수 정보를 확인하는 단계는,
상기 소프트웨어 설계서에 포함된 단위 설계서를 이용하여 상기 함수 정보를 확인하는 단계를 포함하고,
상기 함수 정보는, 해당 모듈에서 이용하는 호출 함수, 피호출 함수 및 각 함수의 입력 파라미터와 출력 파라미터를 포함하는 것인,
소프트웨어 검증 방법. - 제1 항에 있어서,
상기 기능 검증 테스트케이스를 상기 소프트웨어 설계서와 매핑하여 저장하는 단계를 더 포함하고,
상기 디버거는 상기 매핑된 기능 검증 테스트케이스에 포함된 각 모듈을 기초로, 복수의 모듈의 소스 코드를 통합하여 분석하는,
소프트웨어 검증 방법. - 소프트웨어 설계서에 포함된 검증 대상 모듈에 의해서 호출되는 함수에 대한 정보를 상기 소프트웨어 설계서에서 획득하는 설계서 분석 모듈;
상기 획득된 정보를 이용하여 함수들의 호출 순서를 확인하고, 상기 확인된 함수들의 호출 순서를 포함하는 기능 검증 테스트케이스를 생성하는 테스트케이스 생성 모듈;
상기 검증 대상 모듈의 소스 코드를 실행하는 디버거(debugger); 및
상기 디버거에 의해 호출되는 함수 순서와 상기 기능 검증 테스트케이스에 포함된 함수 호출 순서를 비교하여 상기 소프트웨어 설계서에 따른 상기 검증 대상 모듈의 구현 여부를 판정하는 검증 모듈을 포함하는,
소프트웨어 검증 장치. - 제9 항에 있어서,
상기 설계서 분석 모듈은, 상기 소프트웨어 설계서에서 입력 인터페이스와 출력 인터페이스에 대한 파라미터를 확인하고, 상기 소프트웨어 설계서에서 각 모듈에서 이용되는 함수 정보를 확인하고,
상기 디버거는, 각 모듈들 간에 인터페이스와 각 모듈의 알고리즘을 확인하고,
상기 테스트케이스 생성 모듈은, 모듈별 함수 정보, 상기 입력 인터페이스와 출력 인터페이스에 대한 파라미터 및 상기 모듈별 간의 인터페이스에 근거하여, 함수의 호출 순서를 확인하는,
소프트웨어 검증 장치. - 제10 항에 있어서,
상기 디버거는,
각 모듈의 소스 코드를 소스 코드를 분석하여, 함수 호출 조건과 파라미터 설정값을 포함하는 상기 알고리즘을 모듈별로 확인하는,
소프트웨어 검증 장치. - 제10 항에 있어서,
상기 테스트케이스 생성 모듈은,
모듈별 함수 정보, 아키텍처의 입/출력 인터페이스별 파라미터 및 모듈별 간의 인터페이스에 근거하여, 상기 기능 검증 테스트케이스에서의 예상 출력값을 확인하고, 상기 예상 출력값을 포함하는 상기 기능 검증 테스트케이스를 생성하는,
소프트웨어 검증 장치. - 제12항에 있어서,
상기 검증 모듈은,
상기 디버거에 의해서 실행된 소스 코드의 결과와 상기 테스트케이스에 포함된 상기 예상 출력값을 비교하여, 상기 소프트웨어 설계서에 따른 상기 검증 대상 모듈의 구현 여부를 2차 판정하는,
소프트웨어 검증 장치. - 제10 항에 있어서,
상기 테스트케이스 생성 모듈은,
상기 소프트웨어 설계서에 포함된 단위 설계서를 이용하여 해당 모듈에서 이용하는 호출 함수, 피호출 함수 및 각 함수의 입력 파라미터와 출력 파라미터를 포함하는 상기 함수 정보를 확인하는,
소프트웨어 검증 장치. - 제9 항에 있어서,
상기 테스트케이스 생성 모듈은,
상기 기능 검증 테스트케이스를 상기 소프트웨어 설계서와 매핑하여 저장하고,
상기 디버거는,
상기 매핑된 기능 검증 테스트케이스에 포함된 각 모듈을 기초로, 복수의 모듈의 소스코드를 통합하여 실행하는,
소프트웨어 검증 장치.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020200175233A KR102496539B1 (ko) | 2020-12-15 | 2020-12-15 | 소프트웨어 검증 방법 및 이를 위한 장치 |
KR1020230013606A KR102588856B1 (ko) | 2020-12-15 | 2023-02-01 | 소프트웨어 검증 방법 및 이를 위한 장치 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020200175233A KR102496539B1 (ko) | 2020-12-15 | 2020-12-15 | 소프트웨어 검증 방법 및 이를 위한 장치 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020230013606A Division KR102588856B1 (ko) | 2020-12-15 | 2023-02-01 | 소프트웨어 검증 방법 및 이를 위한 장치 |
Publications (2)
Publication Number | Publication Date |
---|---|
KR20220085290A KR20220085290A (ko) | 2022-06-22 |
KR102496539B1 true KR102496539B1 (ko) | 2023-02-06 |
Family
ID=82216967
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020200175233A KR102496539B1 (ko) | 2020-12-15 | 2020-12-15 | 소프트웨어 검증 방법 및 이를 위한 장치 |
KR1020230013606A KR102588856B1 (ko) | 2020-12-15 | 2023-02-01 | 소프트웨어 검증 방법 및 이를 위한 장치 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020230013606A KR102588856B1 (ko) | 2020-12-15 | 2023-02-01 | 소프트웨어 검증 방법 및 이를 위한 장치 |
Country Status (1)
Country | Link |
---|---|
KR (2) | KR102496539B1 (ko) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115225483A (zh) * | 2022-06-29 | 2022-10-21 | 北京天融信网络安全技术有限公司 | 数据包转发方法及电子设备、存储介质 |
US20240231786A1 (en) * | 2022-09-26 | 2024-07-11 | Rakuten Symphony Korea, Inc. | Provision of solution for assignment |
KR102567130B1 (ko) * | 2023-02-24 | 2023-08-21 | 정현우 | Fa장비 구동소프트웨어 관리시스템 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009244969A (ja) * | 2008-03-28 | 2009-10-22 | Nippon Telegr & Teleph Corp <Ntt> | プログラム動作比較装置及び方法及びプログラム |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0588861A (ja) | 1991-03-29 | 1993-04-09 | Mitsubishi Heavy Ind Ltd | ソフトウエア開発支援装置 |
KR20080068385A (ko) * | 2007-01-19 | 2008-07-23 | 슈어소프트테크주식회사 | 소프트웨어 테스트 시스템, 방법 및 그 방법을 실행하기위한 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록매체 |
KR101989802B1 (ko) * | 2017-02-28 | 2019-06-18 | 주식회사 스패로우 | 테스트 케이스를 이용하여 테스트를 수행하는 방법 및 장치 |
-
2020
- 2020-12-15 KR KR1020200175233A patent/KR102496539B1/ko active IP Right Grant
-
2023
- 2023-02-01 KR KR1020230013606A patent/KR102588856B1/ko active IP Right Grant
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009244969A (ja) * | 2008-03-28 | 2009-10-22 | Nippon Telegr & Teleph Corp <Ntt> | プログラム動作比較装置及び方法及びプログラム |
Also Published As
Publication number | Publication date |
---|---|
KR102588856B1 (ko) | 2023-10-12 |
KR20220085290A (ko) | 2022-06-22 |
KR20230019191A (ko) | 2023-02-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR102496539B1 (ko) | 소프트웨어 검증 방법 및 이를 위한 장치 | |
US10346140B2 (en) | System and method for model based technology and process for safety-critical software development | |
US9898387B2 (en) | Development tools for logging and analyzing software bugs | |
US8397104B2 (en) | Creation of test plans | |
US7895575B2 (en) | Apparatus and method for generating test driver | |
JP2010539576A (ja) | 航空機搭載システムのオペレーション・ソフトウェアの妥当性をテストするための自動スクリプト生成の方法および同方法を実施するためのデバイス | |
CN109473093A (zh) | 语音识别方法、装置、计算机设备及存储介质 | |
CN111078568A (zh) | 代码规范方法、装置、计算机设备和存储介质 | |
CN110069404B (zh) | 代码调试方法、装置、设备及介质 | |
CN109947651B (zh) | 人工智能引擎优化方法和装置 | |
Heizmann et al. | Ultimate Automizer with Array Interpolation: (Competition Contribution) | |
CN111897727A (zh) | 软件测试方法、装置、计算机设备及存储介质 | |
CN108062474B (zh) | 文件的检测方法及装置 | |
CN111124870A (zh) | 一种接口测试方法及装置 | |
CN113094252B (zh) | 测试用例生成方法、装置、计算机设备及存储介质 | |
CN112925524A (zh) | 一种检测驱动程序中不安全直接存储器访问的方法及装置 | |
KR20140088963A (ko) | 애플리케이션 개발을 위한 런타임 에러 테스팅 시스템 및 방법 | |
EP3570173B1 (en) | Equivalence verification apparatus and equivalence verification program | |
CN110633213B (zh) | 单元测试方法、装置、计算机设备和存储介质 | |
CN109684205B (zh) | ***测试方法、装置、电子设备及存储介质 | |
CN116521538A (zh) | 命令行界面自动测试方法、装置、电子设备及存储介质 | |
CN111444093A (zh) | 项目开发过程质量的确定方法、装置、计算机设备 | |
KR100777103B1 (ko) | 테스트 드라이버 생성 장치 및 방법 | |
KR20120111618A (ko) | Plc 명령어 테스트 장치 및 방법 | |
US20080052587A1 (en) | Unit Test Extender |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
E902 | Notification of reason for refusal | ||
E701 | Decision to grant or registration of patent right | ||
A107 | Divisional application of patent | ||
GRNT | Written decision to grant |