WO2012033237A1 - 시스템 테스트 방법 - Google Patents

시스템 테스트 방법 Download PDF

Info

Publication number
WO2012033237A1
WO2012033237A1 PCT/KR2010/006068 KR2010006068W WO2012033237A1 WO 2012033237 A1 WO2012033237 A1 WO 2012033237A1 KR 2010006068 W KR2010006068 W KR 2010006068W WO 2012033237 A1 WO2012033237 A1 WO 2012033237A1
Authority
WO
WIPO (PCT)
Prior art keywords
control block
process control
performance
monitoring
kernel
Prior art date
Application number
PCT/KR2010/006068
Other languages
English (en)
French (fr)
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 KR1020127034454A priority Critical patent/KR101438990B1/ko
Priority to JP2013518210A priority patent/JP2013533553A/ja
Priority to CA2800271A priority patent/CA2800271A1/en
Priority to EP10857024.3A priority patent/EP2615552A4/en
Priority to PCT/KR2010/006068 priority patent/WO2012033237A1/ko
Priority to CN201080067546.9A priority patent/CN103109276B/zh
Priority to CN201180032537.0A priority patent/CN102959519B/zh
Priority to KR1020127034163A priority patent/KR101459867B1/ko
Priority to JP2013518216A priority patent/JP5719930B2/ja
Priority to PCT/KR2011/001803 priority patent/WO2012002635A1/ko
Priority to CA2802415A priority patent/CA2802415C/en
Priority to EP11801042.0A priority patent/EP2587379B1/en
Priority to US13/704,490 priority patent/US9354996B2/en
Publication of WO2012033237A1 publication Critical patent/WO2012033237A1/ko
Priority to US13/693,136 priority patent/US20130096880A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0428—Safety, monitoring
    • 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/30—Monitoring
    • G06F11/3089—Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents
    • G06F11/3096—Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents wherein the means or processing minimize the use of computing system or of computing system component resources, e.g. non-intrusive monitoring which minimizes the probe effect: sniffing, intercepting, indirectly deriving the monitored data from other directly available data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • 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/362—Software debugging
    • G06F11/3644—Software debugging by instrumenting at runtime
    • 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/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/23—Pc programming
    • G05B2219/23283—Debugging, breakpoint
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software

Definitions

  • the present invention relates to a system test method.
  • embedded software is software tailored to specific hardware and features. Most embedded software is designed to work optimally for constraints that do not afford system resources such as memory. Therefore, embedded software operating in the target environment has a problem that resource constraints are severe when operating the system compared to general software operating in the host environment.
  • operation by various types of external input such as electronic signals or communication protocols is more important than operation by user commands such as menu selection. Therefore, there is a problem that it is difficult to apply the conventional software test techniques and test tools mainly operated by user commands to embedded software tests.
  • the conventional software test technique is regarded as a symptom that represents a performance bottleneck only if high processor utilization persists in the performance test. In this case, if the processor utilization of a critical component falls below the basic performance, it is not regarded as an abnormal symptom. Therefore, there is a problem that the performance of the system can not be accurately tested.
  • the present invention relates to a technique for a system test method that collects data for identifying performance bottlenecks and their causes and locations without affecting the operating environment of the system with minimal use of resources required for system operation.
  • the present invention provides a system test method comprising identifying the location of a process control block, accessing the location of the process control block, and monitoring the performance elements of the process control block.
  • the present invention has the advantage that it is possible to test the system without affecting the operating environment of the system by using the minimum resources necessary for operating the system.
  • the present invention has the advantage that the system can be tested based on data input from the outside of the system.
  • the present invention has the advantage of being able to test whether the bottleneck is a case even when the utilization rate of the processor falls below the reference.
  • FIG. 1 is a flow chart showing a system test method according to the present invention.
  • FIG. 2 is a program code for implementing a system test method according to the present invention.
  • FIG. 3 illustrates the structure of a system that executes a system test method according to the present invention.
  • the system test method of the present invention includes identifying a location of a process control block, accessing a location of the process control block, and monitoring a performance element of the process control block.
  • a process control block refers to a data structure in which an operating system manages execution information of processes running in a system.
  • the process control block may refer to a kernel data structure that manages the latest execution information of processes running in the system in real time.
  • the system test method hooks a function table associated with the memory through a process control block to find a fault that has occurred in the memory of the system.
  • system test method may analyze system performance by hacking system execution information such as page fault rate and processor utilization to analyze a performance bottleneck and its cause among data of a process control block.
  • Process control block hacking minimizes test system performance degradation by centralizing the collection of data needed for performance analysis into one process control block.
  • the present invention can satisfy the performance test requirements in the system operating environment while minimizing the system performance degradation as described above.
  • system test method according to the present invention may be performed under the following conditions.
  • Test Coverage Performance testing of a system in which all hardware and software components in the overall system are operating.
  • Test Methods Run-time testing in a way that does not re-compile, re-link, or re-execute to ensure how the system runs.
  • Tested A test on binaries loaded on the system without changing the original source / binary code of the software under test that does not contain additional code such as debugging information.
  • Performance data Collects performance data that can take into account not only the processor but also memory, I / O, and network resources as the cause of performance bottlenecks.
  • Bottleneck location tracking Collect location data for source-level analysis, such as functions, to locate performance bottlenecks.
  • Performance Latency Minimize system performance latency due to testing to ensure real time operation.
  • Code addition rate Minimize code addition rate due to testing to operate within limited resources.
  • Process control blocks are kernel data structures that contain information about the execution of processes running on the system.
  • the process control block also includes performance factors such as processor usage and free memory size to determine performance bottlenecks, and these values are always kept up to date by the kernel.
  • the system test method according to the present invention can be used for performance analysis for developing agents that hack these values. Below we look at the performance factors and associated process control block structures needed to analyze the cause of performance bottlenecks.
  • Performance refers to the extent to which a system or component performs its function within the constraints of a given system. Performance testing is an evaluation of whether a system meets specific performance requirements.
  • a system's performance bottleneck is the performance degradation of the system due to competition for limited resources such as memory, I / O devices, and networks.
  • the causes of system performance bottlenecks can vary, such as lack of resources, contention for shared resources, resource monopoly, misconfiguration of resources, or misbehaving resources.
  • Page faults and memory usage are the key memory performance factors that can identify low memory symptoms.
  • the system test method according to the present invention can identify various performance bottlenecks.
  • the system test method according to the present invention may determine a memory bottleneck based on a page fault.
  • a high page fault may be a memory bottleneck.
  • Page faults occur when a program tries to access data or code that exists in its address space but does not currently exist in the system's memory.
  • the operating system imports the data into memory so that the program continues to run as if no page fault occurred. Due to the exception handling of the page fault of the operating system, the processing time of the application is delayed and the overall system performance is affected.
  • system test method may identify a performance bottleneck through memory usage.
  • System memory has physical memory usage and virtual memory usage, and can be divided into heap memory usage by each process.
  • the system test method according to the present invention determines the performance bottleneck based on the sum of these memory usages.
  • system test method may identify a performance bottleneck through processor usage (or CPU usage).
  • the system test method according to the present invention may determine that there is a bottleneck in the CPU when there is free memory while the processor usage is kept high. On the other hand, if the processor usage is high and the memory is exhausted, the performance problem may be more of a memory bottleneck than a CPU.
  • the system test method according to the present invention may identify a performance bottleneck according to processor usage.
  • Process usage is the execution time of the system, which means the total CPU usage minus idle time.
  • the system test method according to the present invention can determine the performance bottleneck according to the user time (User Time).
  • Usage time refers to the time the execution stays in user space, which means the execution time of the application.
  • system test method according to the present invention may determine the performance bottleneck according to the kernel time.
  • Kernel usage time is the time the execution stays in kernel space, which means the service processing time of the kernel.
  • Process control blocks are data structures managed by the operating system kernel for the purpose of controlling processes at run time.
  • process control blocks store execution information such as process identifiers, register contexts, process address spaces, process memory usage, shared function lists, resources owned by processes, process priorities, and states.
  • FIG. 1 is a flowchart illustrating a system test method according to the present invention.
  • the system test method may include identifying a location of a process control block (S100), accessing a process control block (S200), and monitoring performance factors of the process control block (S300). ).
  • the position where the process control block is stored is not determined because the process control block is also generated and disappears when the process is created and disappeared.
  • the process control of the current process is because the base address of the process control block for the current process that occupies the processor (e.g. CPU) is managed in a specific memory space or, in some cases, a fixed address in advance.
  • the block information can be known.
  • the process control block base address of the current process may be calculated as a stack pointer, and as in line 31, the process control block of all processes may be accessed.
  • step S200 of accessing the location of the process control block the process control block is present in the kernel memory space.
  • the pseudo code can be implemented in the form of virtual driver to share the kernel address space as shown in the following program code to access the process control block in the kernel memory space.
  • the timer-interrupt may be used as in line 61 and line 65 of the program code of FIG. 2 and the performance data may be measured at a specified time interval (eg 1 sec, 100 msec). .
  • the performance factor while circulating the process and thread lists of the process control block as in line 31 and line 33 of the program code of FIG. Can be measured.
  • the call stack information is stored per thread to track in detail where the system performance bottleneck occurs. Performance factors measured by each monitoring unit are as follows.
  • the performance factor of the process control block may include one or more of processor usage, memory usage, and page faults.
  • the performance factor for the process of the process control block may include one or more of an ID, a process state, a process priority, a heap usage, a process operating time, a use time, and a kernel use time.
  • Performance factors for threads in a process control block may include one or more of: ID, Run State, Default Priority, Current Priority, Usage Time, Kernel Usage Time, and Call Stack Information.
  • FIG. 3 shows a structure of a system for executing a system test method according to the present invention.
  • a system for executing a system test method according to the present invention includes an agent unit 120 and a test manager 210.
  • the agent unit 120 is included in the target system to be tested, and performs a role of measuring performance data.
  • the agent unit 120 executes the algorithm shown in FIG.
  • the test management unit 210 is included in a host system 200 such as a personal computer (PC) to analyze performance data collected from the agent unit 120 to detect performance bottlenecks and analyze test coverage.
  • a host system 200 such as a personal computer (PC) to analyze performance data collected from the agent unit 120 to detect performance bottlenecks and analyze test coverage.
  • PC personal computer
  • the agent unit 120 is mounted together with the target system disposed in the operating environment, and operates the system according to the test start and end commands of the user, and periodically measures data related to system performance.
  • the agent unit 120 may include PerfAgent.dll and PerfROBO.exe.
  • PerfAgent.dll is a virtual kernel device driver that implements the algorithm shown in FIG. 1 and hacks the process control block information of the kernel for performance testing.
  • PerfROBO.exe acts as a test server that controls whether PerfAgent.dll is activated by user's test start and stop commands.
  • the test is terminated by executing the system performance monitoring module through the timer setting and ending the set timer even when the test is terminated by the user request.
  • the test manager 210 may store the collected performance data in a designated storage medium.
  • the test manager 210 analyzes the log file of the host system 200 and detects a performance bottleneck occurred at an operating time.
  • test management unit 210 stores the performance data as binary code in a storage medium
  • the test management unit 210 inputs binary execution code and collected profiling data for a test target, and test coverage and performance.
  • the location information of which function location has occurred can be displayed together with the call stack information.
  • an analysis code can be inserted into the kernel. This technique inserts analytical code into the kernel either statically or dynamically.
  • Dynamic insertion techniques allow you to insert analysis code into the kernel code at run-time, in which case you can insert code that gathers data for performance analysis without rebooting the system.
  • the technique of static insertion uses a prebuilt kernel.
  • a method using a simulator as a performance monitoring technique may be used. This is useful when looking at the performance of a system early in the development phase.
  • Hardware can be used as a performance monitoring technique.
  • Hardware performance elements represent a specially designed set of registers, and it is possible to monitor the performance associated with CPU, cache, and memory with less system overhead than software-based performance elements. This way, you don't have to modify the source or binary code.
  • the present invention can test a system without affecting the operating environment of the system by using a minimum amount of resources required for operating the system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Automation & Control Theory (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

본 발명은 프로세스 제어 블록(Process Control Block)의 위치를 식별하는 단계, 프로세스 제어 블록의 위치에 접근하는 단계, 및 프로세스 제어 블록의 성능 요소를 모니터링하는 단계를 포함하는 시스템 테스트 방법을 제공한다.

Description

시스템 테스트 방법
본 발명은 시스템 테스트 방법에 관한 것이다.
최근 자동차와 같은 기계 산업 분야에서도 전자제어 기술에 대한 관심이 크다. 전자제어 기술의 핵심은 임베디드 소프트웨어이며, 이들 소프트웨어의 품질이 전체 제품의 품질에 큰 영향을 미친다.
종래에도 품질에 도움을 주는 소프트웨어 테스트 기술과 테스트 도구들이 개발되었다. 하지만 임베디드 소프트웨어의 고유한 특징들 때문에, 이들을 그대로 임베디드 소프트웨어 테스트에 적용하기에는 여러가지 문제가 있다.
첫째, 임베디드 소프트웨어는 특정 하드웨어와 기능에 맞춤되어 제작되는 소프트웨어이다. 대부분의 임베디드 소프트웨어는 메모리와 같은 시스템 자원의 여유가 없는 제약적 조건에 최적화되어 동작하도록 설계한다. 따라서 타겟 환경에서 동작하는 임베디드 소프트웨어는 호스트 환경에서 동작하는 일반 소프트웨어와 비교했을 때 시스템 운용 시 자원 제약이 심하다는 문제점이 있다. 둘째, 임베디드 소프트웨어는 메뉴 선택과 같은 사용자 명령에 의한 동작보다 전자적 시그널이나 통신 프로토콜과 같은 다양한 유형의 외부 입력에 의한 동작이 더 많은 비중을 차지한다. 따라서 사용자 명령에 의해 주로 동작하는 종래의 소프트웨어 테스트 기술과 테스트 도구들을 임베디드 소프트웨어 테스트에 그대로 적용하기 어렵다는 문제점이 있다.
셋째, 종래의 소프트웨어 테스트 기술은 성능 테스트 시에 높은 프로세서 사용율이 지속되는 경우에만 성능 병목을 나타내는 증후로 간주한다. 이 경우 중요한 컴포넌트의 프로세서 사용율이 기본 성능 이하로 떨어지는 경우에는 이상 징후로 판단하지 않는다. 따라서 시스템의 성능을 정확하게 테스트할 수 없다는 문제점이 있다.
본 발명은 시스템 운용 시에 필요한 자원을 최소한으로 사용하여 시스템의 운용 환경에 영향을 주지 않으면서 성능 병목과 그 원인 및 위치를 식별하기 위한 데이터를 수집하는 시스템 테스트 방법에 관한 기술과 관련된다.
본 발명은 프로세스 제어 블록(Process Control Block)의 위치를 식별하는 단계, 프로세스 제어 블록의 위치에 접근하는 단계, 및 프로세스 제어 블록의 성능 요소를 모니터링하는 단계를 포함하는 시스템 테스트 방법을 제공한다.
본 발명은 시스템 운용에 필요한 자원을 최소한으로 사용하여 시스템의 운용 환경에 영향을 주지 않으면서 시스템을 테스트할 수 있다는 장점이 있다.
추가적으로, 본 발명은 시스템의 외부로부터 입력되는 데이터를 기반으로 시스템을 테스트할 수 있다는 장점이 있다.
추가적으로, 본 발명은 프로세서의 사용율이 기준 이하로 떨어지는 경우에 대해서도 병목 현상인지 여부를 테스트할 수 있다는 장점이 있다.
도 1은 본 발명에 따른 시스템 테스트 방법을 나타내는 순서도.
도 2는 본 발명에 따른 시스템 테스트 방법을 구현하는 프로그램 코드.
도 3은 본 발명에 따른 시스템 테스트 방법을 실행하는 시스템의 구조를 나타내는 도면.
본 발명의 시스템 테스트 방법은 프로세스 제어 블록(Process Control Block)의 위치를 식별하는 단계, 프로세스 제어 블록의 위치에 접근하는 단계, 및 프로세스 제어 블록의 성능 요소를 모니터링하는 단계를 포함한다.
아래에서는 도면을 참고하여, 본 발명의 다양한 실시예를 구체적으로 살펴본다.
본 발명에 따른 시스템 테스트 방법에서, 프로세스 제어 블록(Process Control Block)은 운용 체제가 시스템에 운용되고 있는 프로세스들의 실행 정보를 관리하는 자료 구조를 의미한다.
예를 들어, 프로세스 제어 블록은 시스템에 운용 중인 프로세스들의 최신 실행 정보를 실시간으로 관리하는 커널의 자료 구조를 의미할 수 있다.
본 발명에 따른 시스템 테스트 방법은 시스템의 메모리에 발생한 결함을 발견하기 위해, 프로세스 제어 블록을 통해 메모리와 관련된 함수 테이블을 후킹한다.
특히 본 발명에 따른 시스템 테스트 방법은 프로세스 제어 블록의 데이터 중 성능 병목과 그 원인을 분석하기 위해 페이지 폴트율과 프로세서 사용율과 같은 시스템 실행 정보들을 해킹하여 시스템 성능을 분석할 수 있다.
프로세스 제어 블록 해킹은 성능 분석에 필요한 데이터 수집을 프로세스 제어 블록 한 곳으로 집중시킴으로써 테스트로 인한 시스템 성능 저하를 최소화할 수 있다.
또한 본 발명은 위와 같은 시스템 성능 저하를 최소화하면서, 동시에 시스템 운용 환경에서의 성능 테스트 요구사항을 만족시킬 수 있다.
예를 들어, 본 발명에 따른 시스템 테스트 방법은 다음과 같은 조건을 가정하고 수행될 수 있다.
[시스템 테스트 조건]
1. 테스트 범위: 전체 시스템내의 모든 하드웨어와 소프트웨어 컴포넌트들이 동작하는 상황의 시스템에 대한 성능 테스트.
2. 테스트 방식: 시스템 실행 방식을 보장하기 위해 re-compile, re-link, re-execute 되지 않는 방식으로 런-타임 테스트.
3. 테스트 대상: 디버깅 정보와 같은 부가적인 코드를 포함하지 않는 테스트 대상 소프트웨어의 원본 소스/이진 코드 변경 없이 시스템에 로딩된 바이너리를 대상으로 한 테스트.
4. 성능 데이터: 성능 병목의 원인으로 프로세서뿐만 아니라 메모리, I/O, 네트워크 자원까지 고려할 수 있는 성능 데이터 수집.
5. 병목 위치 추적: 성능 병목의 위치로 함수와 같이 소스 레벨 분석이 가능한 위치 데이터 수집.
6. 하드웨어 독립성: 테스트를 위한 별도의 하드웨어 추가나 의존성 없이 시스템 운용 환경과 동일한 하드웨어 조건에서의 테스트.
7. 소프트웨어 독립성: 테스트를 위해 특별히 제작된 커널 (Instrumented Kernel)이나 가상머신을 사용하지 않는 시스템 운용 환경과 동일한 소프트웨어 조건에서의 테스트.
8. 성능 지연율: 실시간 동작을 보장하기 위해 테스트로 인한 시스템 성능 지연 율 최소화.
9. 코드 추가율: 제한된 자원 내에서 동작하기 위해 테스트로 인한 코드 추가 율 최소화.
하지만 이러한 조건은 시스템 운용 환경에 따라 얼마든지 변화할 수 있으며, 본 발명은 이러한 시스템 운용 환경에 제한되지 않고 적용될 수 있다.
프로세스 제어 블록은 시스템에 운용되는 프로세스의 실행 정보를 담고 있는 커널 자료구조이다. 프로세스 제어 블록에는 성능 병목을 판단할 프로세서 사용량과 여유 메모리 사이즈와 같은 성능 요소들도 포함되어 있으며, 커널에 의해 이들 값은 항상 가장 최근 값으로 유지된다.
본 발명에 따른 시스템 테스트 방법은 이 값들을 해킹하는 에이전트 개발을 위한 성능 분석에 사용될 수 있다. 아래에서는 성능 병목의 원인을 분석하기 위해 필요한 성능 요소 및 연관된 프로세스 제어 블록 구조를 살펴본다.
성능은 시스템이나 컴포넌트들이 주어진 시스템의 제약 조건 내에서 기능을 수행하는 정도를 의미한다. 성능 테스트는 특정 성능 요구사항을 시스템이 만족하는 지에 관한 평가이다.
이러한 성능 테스트를 통해 성능 병목과 그 원인을 분석하여 이를 해결함으로 시스템의 성능을 개선할 수 있다.
시스템의 성능 병목은 메모리, I/O 디바이스, 네트워크와 같은 제한된 자원들에 대한 경쟁으로 시스템의 성능이 저하되는 현상이다. 시스템 성능 병목의 원인은 자원 부족, 공유자원 경합, 자원 독점, 자원의 잘못된 구성 혹은 자원의 잘못된 동작과 같이 다양하다.
먼저 메모리가 원인이 되는 성능 병목은 사용 가능한 메모리가 부족할 때에 발생할 수 있으며, 메모리 부족 증후를 식별할 수 있는 핵심적인 메모리 성능 요소로 페이지폴트와 메모리 사용량이 있다.
본 발명에 따른 시스템 테스트 방법은 다양한 성능 병목들을 식별할 수 있다.
먼저 본 발명에 따른 시스템 테스트 방법은 페이지폴트를 기준으로 메모리 병목을 판단할 수 있다.
예를 들어, 페이지 폴트가 높으면 메모리 병목일 수 있다. 페이지폴트란 프로그램이 자신의 주소 공간에는 존재하지만 시스템의 메모리에는 현재 없는 데이터나 코드에 접근 시도하였을 경우 발생하는 현상이다. 페이지폴트가 발생하면 운영체제는 그 데이터를 메모리로 가져와서 마치 페이지폴트가 전혀 발생하지 않은 것처럼 프로그램이 계속적으로 작동하도록 한다. 운영체제의 페이지폴트에 대한 예외처리 때문에 어플리케이션의 처리시간은 지연되며, 전체 시스템 성능에 영향을 준다.
또한 본 발명에 따른 시스템 테스트 방법은 메모리 사용량을 통해 성능 병목을 식별할 수 있다. 시스템의 메모리는 물리 메모리 사용량, 가상 메모리 사용량이 있고, 프로세스 별로 힙 메모리 사용량으로 구분할 수 있다. 본 발명에 따른 시스템 테스트 방법은 이러한 메모리 사용량들의 합을 기준으로 성능 병목을 판단한다.
또한 본 발명에 따른 시스템 테스트 방법은 프로세서 사용량 (혹은 CPU 사용량)을 통해 성능 병목을 식별할 수 있다.
예를 들어, 본 발명에 따른 시스템 테스트 방법은 프로세서 사용량이 높게 유지되면서 여유 메모리가 있는 경우는 CPU에 병목이 있다고 판단할 수 있다. 반면 프로세서 사용량이 높고 메모리도 고갈되었다면 성능 문제는 CPU보다 메모리 병목으로 판단할 수 있다.
또한 본 발명에 따른 시스템 테스트 방법은 프로세스 사용량 (Processor Usage)에 따라 성능 병목을 식별할 수 있다. 프로세스 사용량은 시스템의 실행 시간으로 전체 CPU 사용량에서 대기 시간(Idle Time)을 제외한 시간을 의미한다.
또한 본 발명에 따른 시스템 테스트 방법은 사용 시간 (User Time)에 따라 성능 병목을 판단할 수 있다. 사용 시간은 실행이 사용자 공간에서 머무른 시간을 의미하며, 곧 어플리케이션의 실행 시간을 의미한다.
또한 본 발명에 따른 시스템 테스트 방법은 커널 사용 시간 (Kernel Time)에 따라 성능 병목을 판단할 수 있다. 커널 사용 시간은 실행이 커널 공간에서 머무른 시간으로, 커널의 서비스 처리 시간을 의미한다.
프로세스 제어 블록은 런-타임에 프로세스들을 제어하기 위한 목적으로 운영체제 커널이 관리하는 자료구조이다. 일반적으로 프로세스 제어 블록에는 프로세스 식별자, 레지스터 컨텍스트, 프로세스의 주소 공간, 프로세스의 메모리 사용량, 공유 함수 목록, 프로세스가 소유하는 자원들, 프로세스의 우선순위와 상태 같은 실행 정보들이 저장되어있다.
도 1은 본 발명에 따른 시스템 테스트 방법을 나타내는 순서도이다.
도 2는 본 발명에 따른 시스템 테스트 방법을 구현하는 프로그램 코드이다.
도 1을 참고하면, 본 발명에 따른 시스템 테스트 방법은 프로세스 제어 블록의 위치를 식별하는 단계(S100), 프로세스 제어 블록에 접근하는 단계(S200) 및 프로세스 제어 블록의 성능 요소를 모니터하는 단계(S300)를 포함한다.
프로세스 제어 블록의 위치를 식별하는 단계(S100)에서, 프로세스가 생성되고 사라질 때 그 프로세스 제어 블록도 함께 생성되고 사라지기 때문에 프로세스 제어 블록이 저장되는 위치는 결정되어 있지 않다.
그러나 프로세서(예를 들어, CPU)를 점유하는 현행 프로세스 (Current Process)에 관한 프로세스 제어 블록의 base address는 특정 메모리 공간에 관리되거나, 경우에 따라 미리 고정된 주소로 관리되기 때문에 현행 프로세스의 프로세스 제어 블록 정보를 알 수 있다.
예를 들어, 도 2의 프로그램 코드의 line 7 에서 처럼 현행 프로세스의 프로세스 제어 블록 base address를 스택 포인터로 계산하고, line 31처럼 모든 프로세스의 프로세스 제어 블록으로 접근할 수 있다.
프로세스 제어 블록의 위치에 접근하는 단계(S200)에서, 프로세스 제어 블록은 커널 메모리 공간에 존재한다.
이 경우 커널 공간에는 보안(Security) 차원에서 접근을 허용하지 않을 수 있다. 이처럼 커널 공간에 대한 접근이 차단될 때, 아래 프로그램 코드처럼 pseudo codes를 커널 주소 공간을 공유할 수 있도록 가상 드라이버 형태로 구현하여 커널 메모리 공간에 존재하는 프로세스 제어 블록에 접근할 수 있다.
프로그램 제어 블록의 성능 요소를 모니터하는 단계(S300)에서, 도 2의 프로그램 코드의 line 61와 line 65처럼 timer-interrupt를 사용하며 지정된 시간 간격 (e.g. 1sec, 100msec) 마다 성능 데이터를 측정할 수 있다.
또한 본 발명에 따른 시스템 방법에서는 시스템 성능을 시스템 단위뿐만 아니라 프로세스와 쓰레드의 단위로까지 분석하기 위해 도 2의 프로그램 코드의 line 31과 line 33처럼 프로세스 제어 블록의 프로세스와 쓰레드 리스트들을 순환하면서 성능 요소를 측정할 수 있다.
이 경우 시스템 성능 병목이 발생하는 위치를 자세히 추적하기 위해 쓰레드 별로 콜스택(Callstack) 정보를 저장한다. 각 모니터링 단위 별 측정하는 성능 요소는 다음과 같다.
프로세스 제어 블록의 성능 요소는 프로세서 사용량, 메모리 사용량, 페이지 폴트(Page Fault) 중 하나 이상을 포함할 수 있다.
프로세스 제어 블록의 프로세스에 대한 성능 요소는 아이디(ID), 프로세스의 상태, 프로세스의 우선 순위, 힙(Heap) 사용량, 프로세스의 동작 시간, 사용 시간, 커널 사용 시간 중 하나 이상을 포함할 수 있다.
프로세스 제어 블록의 쓰레드에 대한 성능 요소는 아이디, 운영 상태(Run State), 기본 우선 순위, 현재 우선 순위, 사용 시간, 커널 사용 시간, 콜스택 정보 중 하나 이상을 포함할 수 있다.
도 3은 본 발명에 따른 시스템 테스트 방법을 실행하는 시스템의 구조를 나타낸다.
도 3을 참고하면, 본 발명에 따른 시스템 테스트 방법을 실행하는 시스템은 에이전트부(120) 및 테스트 관리부(210)를 포함한다.
에이전트부(120)는 테스트의 대상이 되는 타켓 시스템에 포함되어, 성능 데이터를 측정하는 역할을 수행한다. 에이전트부(120)는 도 1에 도시된 알고리즘을 실행한다.
테스트 관리부(210)는 PC (Personal Computer)와 같은 호스트 시스템(200)에 포함되어, 에이전트부(120) 로부터 수집된 성능 데이터를 분석하여 성능 병목을 검출하고 테스트 커버리지를 분석한다.
구체적으로, 에이전트부(120)는 운용 환경에 배치된 타겟 시스템에 함께 탑재되어 사용자의 테스트 시작과 종료 명령에 따라 시스템이 운영되면서 주기적으로 시스템 성능과 관련된 데이터를 측정하는 역할을 수행한다.
예를 들어, 에이전트부(120)는 PerfAgent.dll 및 PerfROBO.exe를 포함할 수 있다.
PerfAgent.dll은 도 1에 도시된 알고리즘을 구현하는 가상의 커널 디바이스 드라이버로 성능 테스트를 위해 커널의 프로세스 제어 블록 정보를 해킹한다.
PerfROBO.exe는 사용자의 테스트 시작과 종료 명령에 의해 PerfAgent.dll의 활성화 여부를 제어하는 테스트 서버 역할을 수행한다.
테스트 시작 명령에 의해 PerfAgent.dll이 활성화되면, 타이머 설정을 통해 시스템 성능 모니터링 모듈을 실행시키고 사용자 요구에 의해 테스트를 종료할 때에도 설정된 타이머를 종료시킴으로써 테스트를 종료한다.
한편 테스트 관리부(210)는 수집된 성능 데이터를 지정된 저장 매체에 저장할 수 있다. 테스트 관리부(210)는 호스트 시스템(200) 로그 파일을 분석하여 운영 타임에 발생한 성능 병목을 검출하는 역할을 수행한다.
예를 들어, 테스트 관리부(210)가 성능 데이터를 저장 매체에 이진 코드로 저장한다면, 테스트 관리부(210)는 테스트 대상에 대한 이진 실행 코드와 수집된 프로파일링 데이터를 입력으로 하며, 테스트 커버리지와 성능 정보를 출력할 때 콜-스택정보를 기반으로 어느 함수 위치에서 문제가 발생하였는지의 위치 정보를 함께 디스플레이할 수 있다.
본 발명에 따른 시스템 테스트 방법에서, 시스템의 성능을 모니터링하는 다양한 방법이 사용 가능하다.
먼저 커널에 분석코드를 삽입하는 방법이 사용될 수 있다. 이 기술은 커널에 분석코드를 정적으로 혹은 동적으로 삽입시킨다.
동적으로 삽입하는 기술로는 런-타임에 커널 코드에 분석 코드를 삽입할 수 있으며, 이 경우 시스템을 재부팅하지 않으면서 성능 분석에 필요한 데이터를 수집하는 코드를 삽입할 수 있다.
정적으로 삽입하는 기술은 미리 제작된 커널을 사용한다.
예를 들어, 커널 내부에 중요한 시스템 성능 요소를 모니터링하는 분석코드를 심어둘 수 있다. 성능 모니터를 할 경우, 커널 내부에 미리 삽입되어 있는 분석코드를 통해 성능 데이터를 전송받는다. 그 결과 성능 모니터링을 할 때, 프로세서 사용량, 메모리 사용량을 포함하여 굉장히 다양한 시스템 성능 요소의 측정이 가능하다.
추가적으로, 성능 모니터링 기술로 시뮬레이터를 이용하는 방법이 사용될 수 있다. 이 방식은 개발 단계 초기의 시스템의 성능을 살펴보는 경우에 유용하다.
추가적으로, 성능 모니터링 기술로 하드웨어를 사용할 수도 있다. 하드웨어 성능 요소들은 특별히 제작된 레지스터 집합을 의미하며, 소프트웨어 기반 성능 요소에 비해 적은 시스템 오버헤드로 CPU, 캐시, 메모리와 연관된 성능을 모니터링하는 것이 가능하다. 이 방식은 소스코드나 이진코드를 수정하지 않아도 된다.
본 발명은 시스템 운용에 필요한 자원을 최소한으로 사용하여 시스템의 운용 환경에 영향을 주지 않으면서 시스템을 테스트할 수 있다.

Claims (12)

  1. 프로세스 제어 블록(Process Control Block)의 위치를 식별하는 단계;
    상기 프로세스 제어 블록의 위치에 접근하는 단계; 및
    상기 프로세스 제어 블록의 성능 요소를 모니터링하는 단계를 포함하는 시스템 테스트 방법.
  2. 청구항 1에 있어서,
    상기 프로세스 제어 블록은
    커널 메모리 내부에 위치하는 것을 특징으로 하는 시스템 테스트 방법.
  3. 청구항 2에 있어서,
    상기 프로세스 제어 블록의 위치에 접근하는 단계에 있어서,
    가상 드라이버를 사용하여 상기 커널 메모리에 접근하는 것을 특징으로 하는 시스템 테스트 방법.
  4. 청구항 1에 있어서,
    상기 프로세스 제어 블록의 성능 요소를 모니터링하는 단계에 있어서,
    미리 설정된 시간 간격마다 상기 프로세스 제어 블록의 성능 요소를 측정하는 것을 특징으로 하는 시스템 테스트 방법.
  5. 청구항 2에 있어서,
    상기 프로세스 제어 블록의 성능 요소를 모니터링하는 단계에 있어서,
    상기 프로세스 제어 블록의 프로세스 및 쓰레드(Thread)에 대한 성능 요소를 측정하는 것을 특징으로 하는 시스템 테스트 방법.
  6. 청구항 5에 있어서,
    상기 프로세스 제어 블록의 성능 요소는
    프로세서 사용량, 메모리 사용량, 페이지 폴트(Page Fault) 중 하나 이상을 포함하는 것을 특징으로 하는 시스템 테스트 방법.
  7. 청구항 6에 있어서,
    상기 프로세스 제어 블록의 프로세스에 대한 성능 요소는
    아이디(ID), 프로세스의 상태, 프로세스의 우선 순위, 힙(Heap) 사용량, 프로세스의 동작 시간, 사용 시간, 커널 사용 시간 중 하나 이상을 포함하는 것을 특징으로 하는 시스템 테스트 방법.
  8. 청구항 6에 있어서,
    상기 프로세스 제어 블록의 쓰레드에 대한 성능 요소는
    아이디, 운영 상태(Run State), 기본 우선 순위, 현재 우선 순위, 사용 시간, 커널 사용 시간, 콜 스택(Call Stack) 중 하나 이상을 포함하는 것을 특징으로 하는 시스템 테스트 방법.
  9. 청구항 1에 있어서,
    상기 프로세스 제어 블록은
    프로세스의 식별자, 레지스터 컨텍스트(Context), 프로세스의 어드레스, 메모리 사용량, 공유 함수 목록, 프로세스의 자원(Resource), 프로세스의 우선 순위, 프로세스의 상태 중 하나 이상에 대한 정보를 저장하는 것을 특징으로 하는 시스템 테스트 방법.
  10. 청구항 1에 있어서,
    상기 프로세스 제어 블록의 성능 요소를 모니터링하는 단계는
    커널에 분석 코드를 삽입하여 상기 프로세스 제어 블록의 성능 요소를 모니터링하는 것을 특징으로 하는 시스템 테스트 방법.
  11. 청구항 1에 있어서,
    상기 프로세스 제어 블록의 성능 요소를 모니터링하는 단계는
    시뮬레이션 프로그램을 사용하여 상기 프로세스 제어 블록의 성능 요소를 모니터링하는 것을 특징으로 하는 시스템 테스트 방법.
  12. 청구항 1에 있어서,
    상기 프로세스 제어 블록의 성능 요소를 모니터링하는 단계는
    레지스터를 포함하는 하드웨어를 사용하여 상기 프로세스 제어 블록의 성능 요소를 모니터링하는 것을 특징으로 하는 시스템 테스트 방법.
PCT/KR2010/006068 2010-06-28 2010-09-07 시스템 테스트 방법 WO2012033237A1 (ko)

Priority Applications (14)

Application Number Priority Date Filing Date Title
KR1020127034454A KR101438990B1 (ko) 2010-09-07 2010-09-07 시스템 테스트 방법
JP2013518210A JP2013533553A (ja) 2010-09-07 2010-09-07 システムテスト方法
CA2800271A CA2800271A1 (en) 2010-09-07 2010-09-07 System test method
EP10857024.3A EP2615552A4 (en) 2010-09-07 2010-09-07 METHOD OF SYSTEM TESTING
PCT/KR2010/006068 WO2012033237A1 (ko) 2010-09-07 2010-09-07 시스템 테스트 방법
CN201080067546.9A CN103109276B (zh) 2010-09-07 2010-09-07 系统测试方法
KR1020127034163A KR101459867B1 (ko) 2010-06-28 2011-03-15 시스템 테스트 장치
CN201180032537.0A CN102959519B (zh) 2010-06-28 2011-03-15 系统测试设备
JP2013518216A JP5719930B2 (ja) 2010-06-28 2011-03-15 システムテスト装置
PCT/KR2011/001803 WO2012002635A1 (ko) 2010-06-28 2011-03-15 시스템 테스트 장치
CA2802415A CA2802415C (en) 2010-06-28 2011-03-15 System test apparatus
EP11801042.0A EP2587379B1 (en) 2010-06-28 2011-03-15 System test apparatus
US13/704,490 US9354996B2 (en) 2010-06-28 2011-03-15 System test apparatus
US13/693,136 US20130096880A1 (en) 2010-09-07 2012-12-04 System test method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/KR2010/006068 WO2012033237A1 (ko) 2010-09-07 2010-09-07 시스템 테스트 방법

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/693,136 Continuation US20130096880A1 (en) 2010-09-07 2012-12-04 System test method

Publications (1)

Publication Number Publication Date
WO2012033237A1 true WO2012033237A1 (ko) 2012-03-15

Family

ID=45810821

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2010/006068 WO2012033237A1 (ko) 2010-06-28 2010-09-07 시스템 테스트 방법

Country Status (7)

Country Link
US (1) US20130096880A1 (ko)
EP (1) EP2615552A4 (ko)
JP (1) JP2013533553A (ko)
KR (1) KR101438990B1 (ko)
CN (1) CN103109276B (ko)
CA (1) CA2800271A1 (ko)
WO (1) WO2012033237A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103914653A (zh) * 2012-12-31 2014-07-09 现代自动车株式会社 用于检查软件的方法及系统

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5719930B2 (ja) 2010-06-28 2015-05-20 ヒョンダイ モーター カンパニー システムテスト装置
WO2012124841A1 (ko) 2011-03-15 2012-09-20 현대자동차 주식회사 통신 테스트 장치 및 방법
WO2013000494A1 (en) * 2011-06-30 2013-01-03 Telefonaktiebolaget L M Ericsson (Publ) Flexible data communication
US8996919B2 (en) * 2012-03-13 2015-03-31 Invensense, Inc. Method and system providng a self-test on one or more sensors coupled to a device
US9087041B2 (en) * 2012-07-24 2015-07-21 Michael Weir Enterprise test system platform and associated method for interoperable test data management, test development, test libraries and test workflow management and automation
CN105468397A (zh) * 2014-09-11 2016-04-06 腾讯科技（深圳）有限公司 软件运行数据处理方法及软件运行数据处理装置
WO2016084150A1 (ja) * 2014-11-26 2016-06-02 株式会社日立製作所 サーバ計算機、計算機システム、及び、方法
CN104850478B (zh) * 2014-12-19 2017-06-06 北汽福田汽车股份有限公司 一种建立待测对象模型的方法及虚拟测试方法
CN106293890B (zh) * 2015-06-09 2019-11-05 阿里巴巴集团控股有限公司 一种基于复杂度的业务处理方法和装置
CN111488290B (zh) * 2020-04-28 2021-01-22 南方电网数字电网研究院有限公司 基于智能电表操作系统的线程测试方法和装置
CN112306803A (zh) * 2020-10-29 2021-02-02 金蝶云科技有限公司 一种性能监控方法及相关设备
CN114968745B (zh) * 2022-06-10 2023-06-16 北京世冠金洋科技发展有限公司 一种处理系统模型的运行信息的方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20030041612A (ko) * 2001-11-20 2003-05-27 (주)유니트시스템즈 서버 병목을 실시간으로 분석하는 방법
KR20080079343A (ko) * 2006-12-15 2008-09-01 주식회사 케이티프리텔 이동통신망의 미들웨어 서버를 모니터링하는 서버 및 그방법
KR20090001897A (ko) * 2007-05-29 2009-01-09 주식회사 케이티프리텔 턱시도 미들웨어 환경의 모니터링 시스템 및 방법
KR20090081749A (ko) * 2008-01-25 2009-07-29 삼성전자주식회사 응용프로그램의 자원 모니터링 방법 및 그 장치

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10269110A (ja) * 1997-03-26 1998-10-09 Toshiba Corp 計算機システムのハングアップ回避方法並びにこの方法を用いた計算機システム。
US6175916B1 (en) * 1997-05-06 2001-01-16 Microsoft Corporation Common-thread inter-process function calls invoked by jumps to invalid addresses
JP2001318805A (ja) * 2000-05-08 2001-11-16 Nec Corp 組み込みシステムのテスト方法及びテストシステム
US6988263B1 (en) * 2000-07-10 2006-01-17 International Business Machines Corporation Apparatus and method for cataloging symbolic data for use in performance analysis of computer programs
JP4562568B2 (ja) * 2005-03-28 2010-10-13 富士通テン株式会社 異常検出プログラムおよび異常検出方法
EP1962192A1 (en) * 2007-02-21 2008-08-27 Deutsche Telekom AG Method and system for the transparent migration of virtual machine storage
CN101398780B (zh) * 2007-09-27 2011-08-24 国际商业机器公司 可基于进程定制调试器的即时调试的方法和系统
JP5719930B2 (ja) * 2010-06-28 2015-05-20 ヒョンダイ モーター カンパニー システムテスト装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20030041612A (ko) * 2001-11-20 2003-05-27 (주)유니트시스템즈 서버 병목을 실시간으로 분석하는 방법
KR20080079343A (ko) * 2006-12-15 2008-09-01 주식회사 케이티프리텔 이동통신망의 미들웨어 서버를 모니터링하는 서버 및 그방법
KR20090001897A (ko) * 2007-05-29 2009-01-09 주식회사 케이티프리텔 턱시도 미들웨어 환경의 모니터링 시스템 및 방법
KR20090081749A (ko) * 2008-01-25 2009-07-29 삼성전자주식회사 응용프로그램의 자원 모니터링 방법 및 그 장치

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103914653A (zh) * 2012-12-31 2014-07-09 现代自动车株式会社 用于检查软件的方法及系统
CN103914653B (zh) * 2012-12-31 2018-10-02 现代自动车株式会社 用于检查软件的方法及系统

Also Published As

Publication number Publication date
CN103109276B (zh) 2016-01-20
EP2615552A1 (en) 2013-07-17
EP2615552A4 (en) 2014-08-06
CN103109276A (zh) 2013-05-15
KR101438990B1 (ko) 2014-09-05
KR20130031860A (ko) 2013-03-29
JP2013533553A (ja) 2013-08-22
US20130096880A1 (en) 2013-04-18
CA2800271A1 (en) 2012-03-15

Similar Documents

Publication Publication Date Title
WO2012033237A1 (ko) 시스템 테스트 방법
Fu et al. Space traveling across vm: Automatically bridging the semantic gap in virtual machine introspection via online kernel data redirection
Williams et al. Device Driver Safety Through a Reference Validation Mechanism.
JP6095682B2 (ja) プログラム・イベント記録イベントのランタイム計装イベントへの変換
US7200776B2 (en) System and method for generating trace data in a computing system
US7047521B2 (en) Dynamic instrumentation event trace system and methods
KR19990077479A (ko) 데이터처리시스템및애플리케이션의구조화된프로파일링방법및장치
WO2013154365A1 (ko) 단말기에서 태스크 스케줄링을 수행하는 방법 및 장치
KR19990077480A (ko) 데이터처리시스템및애플리케이션의구조화된프로파일링방법및장치
JP6138142B2 (ja) 被管理ランタイムのためのハードウェア・ベース・ランタイム計装機構
WO2012002635A1 (ko) 시스템 테스트 장치
CN107066390B (zh) 一种动态内存泄漏检测方法及系统
WO2014088144A1 (ko) 단위 테스트 케이스 재사용 기반의 함수 테스트 장치 및 그 함수 테스트 방법
WO2015072689A1 (ko) 안티디버깅 방법
WO2013134206A1 (en) Automatically bridging the semantic gap in machine introspection
US20070226697A1 (en) Autonomic performance management
US8875114B2 (en) Employing identifiers provided by an operating system of a processing environment to optimize the processing environment
WO2013165180A1 (ko) 로그 모니터링 방법, 그 서버 및 기록 매체
JP2015516602A (ja) ランタイム計装制御の状況の決定のためのコンピュータ・プログラム、方法、およびシステム
US8307246B2 (en) Real time monitoring of computer for determining speed of various processes
WO2022124720A1 (ko) 운영체제 커널 메모리의 실시간 오류 검출 방법
WO2013168947A1 (ko) 모니터링 자원의 사용량 표현 방법, 컴퓨팅 장치 및 그 방법을 실행시키기 위한 프로그램을 기록한 기록 매체
EP2690558B1 (en) Semiconductor device
Seo et al. A profiling method by PCB hooking and its application for memory fault detection in embedded system operational test
US20100153926A1 (en) Operating system aided code coverage

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201080067546.9

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10857024

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013518210

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2800271

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2010857024

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20127034454

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE