독일 내무부 산하의 정보 기술국(BIT)은 Java기반의 GUI 자동 테스트 솔루션으로 여러 대안 중 Squish를 선택했습니다.

'EPOS'는 독일 정부의 많은 행정 기관이 사용하는 관리 및 관리 시스템입니다. 독일 BIT (Federal Office of IT)는 EPOS GUI의 추가 개발 과정에서 지속적인 품질을 보장하기 위해 자동화 된 GUI 테스트 솔루션을 선택하기위한 연구를 수행했습니다.

Squish는 다양한 GUI 기술을 기반으로하는 응용 프로그램에 대해 자동화 된 GUI 테스트를 작성하고 실행할 수있는 전문적인 크로스 플랫폼 GUI 및 회귀 테스트 도구입니다. 여기에는 Java SWT / Eclipse RCP, Java AWT / Swing, Nokia Qt, Web / HTML / AJAX 및 기타 여러 UI 기술을 기반으로하는 응용 프로그램이 포함됩니다. Squish는 각각의 지원되는 GUI 기술과의 긴밀한 통합 덕분에 다른 GUI 테스트 도구보다 우수합니다. 이는 Squish로 생성 된 GUI 테스트가 매우 견고하고 안정적이라는 것을 보장하는 기능입니다.

Java GUI 테스트 도구에 대한 연구를 위해 독일 연방 IT 사무국에서는 기준 테이블을 기반으로 Squish for Java (froglogic), QF-Test (Quality First Software) 및 SilkTest (Borland)를 평가하고 비교했습니다. froglogic의 Squish for Java 제품이 명확한 승자가 되었고 업무 진행을 위해 최종 선택되었습니다.


 

froglogic의 Squish GUI Tester 및 
Squish Coco Code Coverage 도구 관련 문의 

모아소프트 장정훈 부장 
02.6945.2120 
jhjang@moasoftware.co.kr

 

froglogic Squish GUI Tester  Squish Coco Code Coverage 도구는 석유 및 가스, EDA, 우주 항공, 의료, 자동차, 언론 및 미디어, IT 등과 같은 산업에서 사용됩니다. froglogic의 고객은 소규모 기업부터 다국적 기업에 이르기까지 다양합니다.

현재 전 세계적으로 3000 개 이상의 회사가 GUI 테스트를 자동화하고 테스트의 코드 범위를 측정하며 전반적인 품질 보증 프로세스를 개선하기 위해 froglogic의 도구를 사용합니다.

오늘은 froglogic의 주요고객 중 하나인 '모 국제항공회사'를 통해 성공적인 Squish 도입사례를 살펴보도록 하겠습니다. 
https://www.froglogic.com/squish/success-stories/international-aviation-company/

 

 

국제 항공 회사, AIX 및 Linux 상에서 Squish를 사용한 Java 기반 항공 시스템 테스트

 

전세계의 주요 항공사에 대한 산업별 컨설팅 및 IT 서비스는 물론, 솔루션 개발 및 구현을 제공하는 모 국제 항공 회사가 GUI 자동화 테스트를 위해 Squish를 선택했습니다. 

항공 회사, 특히 비행 계획 및 가상화 솔루션을 제공하는 회사는 정밀 테스트를 거쳐 항공 산업이 기대하는 신뢰성과 정확성을 보장해야합니다. 


이 국제 항공 회사는 대규모 데이터 센터 운영 외에도 효율성 최적화를 위한 소프트웨어 솔루션을 생산합니다. Java를 사용하여 구축 된 항공 애플리케이션은 항공기 상황 표시 기능으로  양방향의 비행 계획, 비행 조작 시각화, 위상 분석 및 최적화, 전 세계 항공 데이터 범위를 생성합니다. 

 


왜 Squish인가요?

 

최근 Openroad에서 Java SWT로의 이동으로, 그 회사는 제품 수명 주기에 자동화된 테스트 통합을 하기 위해 automated GUI regression testing tools를 연구했습니다.

먼저 신뢰성을 확보하기 위한 솔루션 자동화를 모색하는 평가를 실시하여, 확인된 주요 테스트 사례를 성능 저하 없이 자동화할 수 있는지 확인했습니다.  평가판은 TestPlant의 eggPlant와 froglogic의 Squish의 두 가지 도구로 나뉩니다. 

철저한 평가를 거친이 항공 회사는 froglogic의 Squish를 선택했습니다. eggPlant가 이미지 기반 객체 인식을 사용하여 객체를 찾는 경우, Squish는 기본적으로 응용 프로그램에 연결하고, 객체로 직접 작업하며, 객체 속성을 식별하고 사용하여 테스트중인 응용 프로그램과 상호 작용합니다. Squish는 또한이 항공 회사 측의 활용도가 높았던 AIX 및 Linux를 포함한 여러 플랫폼 및 기술 전반에 걸쳐 운영됩니다. 또한 테스트 설계의 유연성, 익숙한 Eclipse 기반 GUI, 스크립팅 언어 선택, 버전 제어 시스템 선택 및 문서 및 지식 기반을 통한 원활한 유지 관리가 Squish를 GUI 자동화 솔루션으로 구현하기로 결정하는 데 기여했습니다.

항공회사의 구매 담당자는 Squish를 발견하여 보다 유연한 솔루션을 제공함으로써 사용자가 시험 설계 방법을 결정할 수 있게 하였습니다. 기록 및 재생 진행 시 애플리케이션 모델 접근성뿐만 아니라 복잡한 객체 지향 프레임워크 옵션에 이르기까지, 스노쿨링은 테스트 대상 애플리케이션과 성공적으로 상호 작용합니다.

 


 

Squish 도입을 망설이지 마세요.

 

항공회사의 실행 팀이 자동화 테스트 제품 군을 계속 구축하고 유지함에 따라 Squish의 강력한 기능 중 일부는 엄청난 가치가 있음을 입증했습니다. 응용 프로그램 수준의 세부 정보를 쉽게 얻을 수있을뿐만 아니라 테스트 유지 관리 및 개발 비용을 줄여주는 시간 절약 조치 및 최적화를 제공하였습니다. 

Object Spy를 사용하여 응용 프로그램 수준 세부 정보를 보면 사용자는 응용 프로그램에서 Squish가 컨트롤을 보는 방법을 관찰 할 수 있습니다. 결과적으로 항공 회사는 Object Map을 최적화하여 테스트 유지 보수 및 개발 비용을 줄였습니다. 

이 항공 회사는 Squish를 통해 애플리케이션 라이프 사이클의 필수 구성 요소임을 입증하여 주요 및 마이너 릴리스 모두에 대해 상당한 테스트 커버리지를 향상 시켰으며, 각 단계별 실행보고서를 품질 관련 정보를 제공받고 있습니다.


froglogic의 Squish GUI Tester 및 
Squish Coco Code Coverage 도구 관련 문의 


모아소프트 장정훈 부장 
02.6945.2120 
jhjang@moasoftware.co.kr

 

froglogicSquish GUI Tester Squish Coco Code Coverage 도구는 석유 및 가스, EDA, 우주 항공, 의료, 자동차, 언론 및 미디어, IT 등과 같은 산업에서 사용됩니다. froglogic의 고객은 소규모 창업 기업부터 다국적 기업에 이르기까지 다양합니다.

현재 전 세계적으로 3000 개 이상의 회사가 GUI 테스트를 자동화하고 테스트의 코드 범위를 측정하며 전반적인 품질 보증 프로세스를 개선하기 위해 froglogic의 도구를 사용합니다.

오늘은 froglogic의 주요고객 중 하나인 'NOKIA'를 통해 성공적인 Squish 도입사례를 살펴보도록 하겠습니다.
https://www.froglogic.com/squish/success-stories/nokia-shortens-testing-cycles-ovi-store-froglogic-squish/

Nokia, froglogic Squish로 Ovi 스토어 테스트주기 단축

노키아 인도 Pvt. Ltd.는 모바일 하드웨어 및 소프트웨어 분야의 세계적인 선두 기업이자 인터넷과 통신 산업 간의 융합에 관한 노키아의 자회사입니다. 노키아는 전세계 150여 개국에서 13 만명이 넘는 직원을 고용하고 있으며 인도에서는 약 2,500 명의 직원을 고용하고 있습니다.

수석 테스트 엔지니어 인 Vijay V. Kalkundri는 Nokia India의 Squish 테스트 경험을 froglogic와 공유 할만큼 고객사 이상의 관계를 유지하고 있습니다. (Vijay는 6 년 동안 Squish를 이용하여 소프트웨어 테스팅을 해왔고 QTP, Selenium 및 회사 별 내부 테스트 도구를 포함하여 시중의 다양한 테스트 도구에 대한 경험이 있습니다.)


노키아 인도의 응용 프로그램

Nokia India는 자사의 자체 하드웨어 제품, 사내 사용 및 외부 고객 용 소프트웨어를 제작하는 회사며, 대부분의 소프트웨어는 Squish를 사용하여 테스트하고 있습니다.

그들이 생산하는 주요 소프트웨어 제품 중 하나는 모바일 장치 (예 : 휴대폰)와 개인용 컴퓨터간에 동기화 서비스를 제공하는 Nokia Ovi Suite (아래 그림)입니다. 또한 Nokia India는 Ubuntu Linux에서 실행되는 사내 애플리케이션을 제작합니다.


 

 

Nokia Ovi Suite
왜 Squish인가요?

Nokia India의 주요 소프트웨어 제품 중 3 개 (Nokia Ovi Suite 포함)는 Qt를 사용하여 제작되었습니다. Vijay는 Windows 및 Linux의 여러 버전에 대한 Qt 응용 프로그램의 소프트웨어 테스팅을 자동화해야한다고 말했습니다.
Vijay의 팀은 인터넷에서 테스트 솔루션을 검색하고 Squish를 발견했습니다. 그들은 여러 표준 스크립팅 언어에 대한 Squish의 지원을 필요로 했으며 사용하기 쉽고 설명서가 친숙하기 때문에 Squish를 시험해보기로 결정했습니다.

Squish at Nokia India

Nokia India의 Qt 소프트웨어는 여러 플랫폼에서 테스트해야합니다. Vijay는 Squish를 사용하여 32 비트 및 64 비트 버전의 Windows (XP, Vista 및 7) 및 32 비트 및 64 비트 버전의 Linux에서 응용 프로그램을 테스트 할 수 있다는 사실에 특히 만족한다고 말했습니다.

Vijay의 팀은 Squish 테스트가 다양한 표준 스크립팅 언어를 사용하여 기록되거나 편집 될 수 있다는 점에 만족했지만 지금까지 개발 한 200 여가지 이상의 테스트 케이스에 Python 2를 사용하기로 결정했습니다.
Squish가 제공 할 것으로 예상되는 정상적인 테스트 기능을 뛰어 넘는 유용한 기능 중 하나가 공유 파일입니다. 이 기능은 여러 테스트 케이스 테스트 스크립트에서 기능을 공유하기위한 메커니즘으로 광범위하게 사용되어 테스트 케이스간에 복사하지 않고 재사용 가능한 기능을 공유합니다. 또한 Squish Spy를 사용하여 실제 응용 프로그램 개체를 검사하고 Squish가 데이터 기반 테스트를 위해 외부 데이터 파일을 읽을 수 있는지 확인합니다.

객체 식별은 전통적으로 GUI 테스트, 특히 화면 좌표를 사용하여 객체를 식별하는 구형 도구에서 문제가되었습니다. Squish는 객체를 위치보다는 객체로 식별하는 훨씬 강력하고 안정적인 접근 방식을 사용합니다. 물론 일부 개체의 속성이 동적으로 변경되지만 Squish는 이러한 속성에 대해 와일드 카드 및 정규식 패턴 일치를 사용하여이 문제에 대처할 수 있습니다. 이는 Vijay의 팀에서 활발하게 활용 한 기능입니다.

Nokia Ovi Suite는 개인용 컴퓨터와 모바일 장치간에 동기화되므로 전화기가 컴퓨터에 연결되어있을 때 응용 프로그램을 테스트 할 수 있어야합니다. Vijay는 이러한 용도로 테스트 할 때 Squish를 사용하여 문제가 없었습니다. 실제로 Vijay는 Squish 테스트를 전반적인 프로세스에 통합하는 것이 "매우 쉽고 매끄럽다"고 말했습니다.

Vijay의 팀이 직면한 한 가지 특별한 도전 과제는 두 개의 개별 응용 프로그램 (Windows에서 실행되는 응용 프로그램과 Ubuntu Linux에서 실행되는 응용 프로그램)을 테스트하는 것이 었습니다. 첫 번째 응용 프로그램은 두 번째 응용 프로그램에서 읽은 데이터를 생성하고 두 응용 프로그램은 모두 비동기적으로 실행했습니다.

Vijay는 Squish를 사용하여 전체 프로세스를 테스트했습니다. 그는 Windows 응용 프로그램이 쓸 수 있고 Ubuntu Linux 응용 프로그램에서 읽을 수있는 공유 폴더를 만들었습니다. 그런 다음 Windows 용 Squish 용 테스트 스크립트를 만들어 Windows 응용 프로그램을 실행하고 출력을 공유 폴더에 쓰게했습니다. 그는 또한 Ubuntu Linux 응용 프로그램을 실행하고 데이터가 나타날 때까지 기다리는 공유 폴더를 볼 수 있는 Linux 용 Squish 용 테스트 스크립트를 만들었습니다. 일단 모든 데이터가 도착하면 테스트 스크립트는 Ubuntu Linux 애플리케이션을 사용하여 데이터를 읽고 프로세스의 일부를 완료했습니다. 두 응용 프로그램의 모든 동작 전반에 걸쳐 Squish가 확인하므로 모든 회귀가 즉시 감지됩니다.

Squish에 대한 Vijay와 Squish의 팀 경험은 압도적으로 긍정적입니다. 그들은 froglogic의 기술 지원이 특히 유용하다는 것을 알았습니다. Vijay는 우리에게 말했습니다 :
"froglogic에서 빠르고 반응이 빠른 지원은 Squish를 매우 즐거운 경험으로 만듭니다."
Nokia India는 Squish를 사용하여 테스트주기를 단축하고 전반적인 테스트 시간을 단축 시켰습니다. Squish를 사용하여 테스트 커버리지를 향상시키고 훨씬 더 큰 테스트 신뢰성을 얻을 수있었습니다. 이 모든 것이 테스트하는 소프트웨어의 개발 프로세스로 되돌아 왔고 애플리케이션 품질이 향상되었습니다.


froglogic의 Squish GUI Tester 및
Squish Coco Code Coverage 도구 관련 문의

모아소프트 장정훈 부장
02.6945.2120
jhjang@moasoftware.co.kr

최근 개발되고 있는 다양하고 복잡한 GUI 어플리케이션의 테스팅 자동화와 코드 커버리지 분석을 지원합니다.
솔루션담당 장정훈 부장 02.6945.2120 

Squish (GUI 테스팅 자동화 도구)
-GUI 테스트케이스의 Recoding 기능 제공
- Recoding된 테스트 스크립트 자동 수행
- 다양한 스크립트 언어 지원
- 시나리오 기반으로 간편한 테스트 케이스 작성 및 수행
- 하이브리드 어플리케이션 테스트 가능


지원 환경
- Qt, QML, QtQuick and QtWebKit
- Native Window Controls
- Mac OS X Cocoa and Carbon
- iOS Native and web GUIs
- Android Native and Web GUIs
- Web and Flex in multiple browsers
- and more

 

Squish Coco (코드 커버리지 분석 도구)
- C, C++, C#, Tcl 어플리케이션의 코드 커버리지 분석
- Function, Line, Branch, Branch Decision and Condition Coverage 지원
- Unit, Automated, Manual 테스트 지원
- Untested Code 및 Dead Code 발견에 용이
- 서로 다른 버전의 어플리케이션 커버리지 비교 기능 지원
- 실행 결과의 누적 Report 제공

Squish Coco Toolchain
- CoverageScanner: C, C++, C# 과 Tcl 어플리케이션의 분석
- CoverageBrowser: 복잡한 GUI의 분석 데이터 및 결과의 관리 및 디스플레이
- Microsoft® Visual Studio Add-in: Visual Studio IDE에서 개발된 C, C++, C# 프로젝트의 코드 커버리지 측정을 위한 구성 생성


지원 플랫폼
- Windows (32-bit and 64-bit)
- Linux (32-bit and 64-bit)
- mac OS X(32-bit and 64-bit)
- Embedded Operating Systems
- UNIX(Solaris, AIX,...)

 

MISRA-C의 두번째 개정판 'MISRA-C:2004'

 

MISRA-C:2004 MISRA-C의 두번째 개정판(Guidelines for the use of the C language in critical systems)으로 자동차 뿐만 아니라 안전에 민감한 시스템(Critical System)에 사용될 수 있도록 만들어 졌습니다. MISRA-C:2004는 현재 높은 소프트웨어 신뢰성이 필요한 항공, 자동차, 우주, 원전 사업 등에 가장 널리 사용되고 있습니다. 141개의 룰이 있으며, 121개의 필수 룰과 20개의 권고 룰로 구성되어 있습니다. 각각의 룰들은 아래의 이미지에서 확인할 수 있듯이 "Environment" 부터 "Run-time failure"까지 21개의 그룹으로 구성되어 있습니다.

 

 

 

 

룰 가운데, 이번 포스트를 통해 EnvironmentLanguage Extensions에 대해 알아보겠습니다.

 

Environment

Rule1.1 All code shall conform to ISO 9899:1990 “Programming languages – C”, amended and corrected by ISO/IEC 9899/COR1:1995, ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/COR2:1996.

(필수)모든 코드는 ISO/IEC 9899:1990, Programming language – C (ISO/IEC 9899/COR 1:1995, ISO/IEC 9899/AMD 1:1995 ISO/IEC 9899/COR 2:1996에 의해서 추가 및 개정된 것)를 따라야 한다.

 

Rule1.2 No reliance shall be placed on undefined or unspecified behavior.

(필수) 미 정의 또는 미 규정 된 동작에 의존해서는 안 된다.

 

Rule1.3 Multiple compilers and/or languages shall only be used if there is a common defined interface standard for object code to which the languages/compilers/assemblers conform.

(필수) 여러 개의 언어나 컴파일러를 사용할 경우, object code에 대한 공통적인 인터페이스가 있어야 한다.

 

Rule1.4 The compiler/linker shall be checked to ensure that 31 character significance and case sensitivity are supported for external identifiers.

(필수) 컴파일러나 링커가 외부 식별자에 대하여 최대 31문자까지 지정이 가능하고, 대문자/소문자의 구분을 지원하고 있는지 검토되어야 한다.

 

Rule1.5 Floating-point implementations should comply with a defined floating-point standard.

(권장) 부동소수점의 사용은 정의된 부동소수점 규격에 따라야 한다.

 

 

Language extensions

 

Rule2.1 Assembly language shall be encapsulated and isolated.

(필수) 어셈블리 언어는 캡슐화되어 격리되어야 한다.

 

Rule2.2 Source code shall only use /* ... */ style comments.

(필수) 소스 코드에는  /*…*/ 스타일의 주석 표기법 만을 사용해야 한다.

 

Rule2.3 The character sequence /* shall not be used within a comment.

(필수) 주석의 시작은 /*에서 */로 끝나야 한다. 중간에 /*이 포함되어 있으면 안된다.

 

Rule2.4 Sections of code should not be “Commented out?”

(권장) 코드의 일부를 코멘트아웃 해서는 안된다. 필요 시 조건부 컴파일(#if…#endif)를 사용한다.

 

 

DO-178C SOFTWARE PLANNING PROCESS Objective-5의 이해


* 시작에 앞서 용어는 Section4 의 게시물을 참고하면 된다.

 

1. Objective – 5 의 개요

생산될 소프트웨어에 대해 시스템 안전 달성요건(system safety objective)에 부합하는 소프트웨어 개발 표준을 정의한다.

 

2. Activity


4.2 Software Planning Process Activities


b. 프로젝트에 사용될 소프트웨어 개발 표준은 정의되거나 선택되어야 한다.

g. 소프트웨어 계획 프로세스가 완료 될 때까지, 소프트웨어 계획과 소프트웨어 개발 표준은 변경 통제 및 검토완료 되어야한다.

 

4.5 Software Development Standards

소프트웨어 개발 표준은 소프트웨어 개발 프로세스에 대한 규칙과 제약을 정의한다. 소프트웨어 개발 표준은 소프트웨어 요구사항 표준, 소프트웨어 설계 표준, 소프트웨어 코드 표준을 포함한다. 소프트웨어 검증 프로세스는 이러한 표준을 실제 산출물과 의도한 산출물 간의 적합성을 평가하기 위한 기준으로써 사용한다. 소프트웨어 표준 개발에 대한 활동은 아래를 포함한다.


a. 소프트웨어 개발 표준은 11장을 따라야 한다.

b. 소프트웨어 개발 표준은 주어진 소프트웨어 제품 또는 관련된 제품의 집합이 균등하게 설계되고 실행될 수 있도록 해야 한다.

c. 소프트웨어 개발 표준은 입증 될 수 없거나 안전관련 요구사항과 호환 가능하지 않은 산출물을 생산하는 방법 또는 구성물의 사용을 불가능하게 해야 한다.

d. 강건성은 소프트웨어 개발 표준에서 고려되어져야 한다.

 

3. Applicability by Software Level

해당 ObjectiveSW 레벨 A-C에서는 모두 수행해야 한다.

 

4. Outputs(산출물)

SW Requirements Standards

  소프트웨어 요구사항 표준 자세한 내용은 DO-178C11.6 항목 참조

• SW Design Standards

  소프트웨어 설계 표준 자세한 내용은 DO-178C11.7 항목 참조

• SW Code Standards

  소프트웨어 코드 표준 자세한 내용은 DO-178C11.8 항목 참조

     

    
5. Control Category by Software Level(SW
레벨에 따른 형상관리 수준)

SW 레벨 A, B에서의 산출물 SW Requirements Standards, SW Design Standards, SW Code StandardsCC1 수준으로 형상 관리한다.

SW 레벨 C에서는 산출물 SW Requirements Standards, SW Design Standards, SW Code StandardsCC2 수준으로 형상 관리한다.

 

6. 달성방법

시스템 안전성 목표에 일치하는 요구사항 표준, 설계 표준, 코드 표준을 정의함

요구사항 표준에는 구조적 방법, 식별체계, 표현방법(data flow diagram, UML), 요구사항 개발 및 관리 tool(DOORS), 제약사항. 파생 요구사항 제공 방법 등을 정의함

설계 표준에는 표현방법, 명명규칙, 제어조건, 설계도구 사용상의 제약사항, 복잡도 제한사항 등을 정의함

코드 표준은 Programming 언어, 소스코드 표현방식, 변수/함수 명명규칙, 조건사항, 코딩도구에 대한 제약사항 등을 정의함

 

다음에는 Objective – 6에 대해 알아보도록 하자.

MISRA LDRA 적용


현재 신뢰성을 높이기 위해 다양한 코딩 룰이 존재합니다. 가장 잘 알려진 코딩 룰은 아마도 1998년에 처음 발표 된 MISRA(Motor Industry Software Reliability Association)일 것입니다. 최초 의도는 자동차 산업에서의 사용이었지만 현재 우주/항공, 의료장비, 국방, 철도 등 다양한 산업에서 광범위하게 적용되고 있습니다. MISRA Rule Mandatory, Required, Advisory로 구분되어 있습니다. 처음 발표 된 MISRA C ruleMISRA-C:1998이고, 2004년 이래로 새로운 표준인 MISRA-C:2004로 갱신되었으며, 현재는 MISRA C:2012까지 업데이트 되었습니다.



 

1. LDRA에서 MISRA 구분


 


 Default Strength 분류


  • (M) Mandatory         치명적인 결함을 일으킬 수 있는 필수적으로 지켜야하는 룰

  • (C) Checking             치명적인 결함을 일으키지는 않지만 지켜야하는 룰

  • (O) Optional             추가적으로 개발자의 재량으로 선택할 수 있는 룰

2. LDRA에 적용되어 있는 MISRA 룰 개수 및 구성


MISRA-C:1998

- 127 rules


119 implemented by LDRA


3 partially implemented by LDRA

5 not deemed to be statically analysable



MISRA-C:2004

- 141 rules


123 implemented by LDRA


4 partially implemented by LDRA


14 not deemed to be statically analysable


MISRA-C:2012

- Enhanced Guidelines


               ​119 implemented by LDRA

               。3 partially implemented by LDRA

               。5 not deemed to be statically analysable


- C90 / C99 support

- ​Directives / Rules

- Undecidable / Decidable rules

3. LDRA에서 MISRA 선택 방법

 


 

 

Code Warrior & on Target 시험 사례

무인기체계 SWTarget 환경 구축에 따른 지원 결과 중, Code Warrior를 이용한 구축 사례에 대해 살펴 보겠습니다.


시험환경

IDE: Code Warrior 10.5 

Compiler: CodeWarrior

Target Chip : Freescale MPC 5674F 


환경구축 소요기간

60일 소요 (소요시간 단축 가능)

          계획수립: 2

          환경조사: 10

           환경개발연구: 20

          TLP 구축: 28


 


 

 

 

신뢰성 시험 흐름 구성도

 



 

 

시험과정 및 결과

Plugin 기능으로 CCS 에서 LDRA 실행

 

  

iSystem winIDEA Debugger와 연동되어 Test Case가 실제 Target 에서 수행

Debug -> Files for Download

파일 생성

LDRA TBrun에서 Create New Test Case 실행

 

 

 

 

Target에서 수행된 결과를 Host로 가져와 Coverage 달성

 


 

DO-178C SOFTWARE PLANNING PROCESS

Objective - 4의 이해


 

* 시작에 앞서 용어는 Section4의 게시물을 참고 바랍니다.

 

1. Objective - 4의 개요

필요하다면 기존의 SW의 재활용, Tool 검증, 다양한 방법 등 추가적인 사항을 고려한다.


 

2. Activity

4.2 Software Planning Process Activities

f. 여러 버전의 상이한 SW(Multi-version dissimilar software)가 시스템에서 사용될 때,

SW 계획 과정에서 시스템 안전 목표(safety objectives)를 만족하는데 필요한 상이점(Dissimilarity)을 달성하기 위한 방법 및 도구를 선택해야 한다.

 

h. 비 활성화 코드(deactivated code)를 계획한다면, SW 계획 과정에서는 비 활성화 메커니즘(deactivation mechanism) 및 비 활성화 코드가 시스템 안전목표를 만족시키기 위해 어떻게 정의되고 검증(verify)되어야 하는지 서술해야 한다.

 

i. 사용자 수정 가능 SW(User-modifiable software)를 계획한다면, 그러한 설계를 입증하기 위해 관련된 프로세스, 도구, 환경, 그리고 데이터 아이템들(data items)(5.2.3 참고)이 소프트웨어 계획 및 표준에 명시되어야 한다.

 

j. 매개변수 데이터 항목(parameter data items)을 계획할 경우에는, 아래와 같은 항목을 고려해야 한다..

 

    1. 매개변수 데이터 항목을 사용하는 방법.

    2. 매개변수 데이터 항목의 SW 레벨.

    3. 매개변수 데이터 항목을 변경, 검증, 개발하기 위한 절차와 관련된 툴 인증

    4. SW 탑재 제어(load control) 및 호환성.

 

k. SW 계획 단계에서는 적용 가능한 추가적인 고려사항(additional considerations)을 다루어야 한다.

 


3. Applicability by Software Level

해당 ObjectiveSW 레벨 A~D 에서는 모두 수행해야 한다.

 

4. Outputs(산출물)

  • PSAC (Plan for Software Aspects of Certification)

         소프트웨어 인증계획 문서 자세한 내용은 DO-178C11.1항목 참조

  • SDP (Software Development Plan)

         소프트웨어 개발 계획 문서 자세한 내용은 DO-178C11.2항목 참조

  • SVP (Software Verification Plan)  

         소프트웨어 검증 계획 문서 자세한 내용은 DO-178C11.3항목 참조

  • SCM Plan (Software Configuration Management Plan)

         소프트웨어 형상 관리 계획 문서 자세한 내용은 DO-178C11.4항목 참조

  • SQA Plan (Software Quality Assurance Plan)

         소프트웨어 품질 보증 계획 문서 자세한 내용은 DO-178C11.5항목 참조

 

5, Control Category by Software Level (SW 레벨에 따른 형상관리 수준)

SW 레벨 A, B에서의 산출물 PSAC, SDP, SVP, SCM Plan, SQA Plan CC1 수준으로 형상 관리한다.

SW 레벨 C, D에서는 산출물 PSAC CC1수준으로, 산출물SDP, SVP, SCM Plan, SQA Plan CC2수준으로 형상 관리한다.

 

6. 달성방법

  • 기존에 개발되어 있는 SW를 재활용하는 경우에는 SW Safety Level 재평가, 개발환경 재정의, 형상관리 등을 추가로 고려함

  • Tool Qualification이 필요한 Tool에 대하여는 objective - 3을 참조함

  • Formal Method, Exhaustive Input Testing, 동일기능 이종 SW등과 같이 추가로 사용될 방법이나 기법에 대하여도 PSAC에 정의하여야 하며, 또한 SW 개발 결과물에 미치는 영향분석 및 선정 사유를 명시함

  • 이러한 도구나 방법에 대하여도 적절한 검증을 수행함

 

다음 포스팅에서는 Objective - 5에 대해 알아보도록 하자.

DO-178C SOFTWARE PLANNING PROCESS

Objective - 3의 이해


  

1. Objective - 3의 개요

SW 라이프 사이클 프로세스의 활동을 위해 사용되는 방법. 도구 등을 포함하는 SW 라이프 사이클 환경이 선정되고 정의되어야 한다. (DO-178C 4.4참조)

 


2. Activity 

  • SW 개발환경

SW개발 환경은 높은 품질의 SW를 개발하는데 있어 중요한 요소이다. SW개발 시 몇 가지 환경들은 악영향을 끼칠 수 있다. 예를 들어 컴파일러(compiler)는 오류 있는 데이터를 만들어 에러를 일으킬 수 있고, 링커(linker)는 메모리할당 에러가 있는 것을 나타내지 못할 수도 있다. SW 개발 환경 방법 및 도구의 선택을 위한 활동은 아래와 같다.


  1. SW 계획 단계에서, SW 개발 환경은 소프트웨어 개발 시 잠재적인 위험을 줄일 수 있도록 선택해야 한다.

  2. 도구의 사용 또는 도구와 일부 SW 개발환경과의 결합은 어떤 한 부분에서 유입된 에러를 다른 부분에서 발견할 수 있을 정도의 확신 수준이 달성될 수 있도록 선택되어야 한다. 두 부분이 지속적으로 함께 사용되는 경우에 수용가능한 환경이 만들어 진다. 이러한 선택은 tool qualification필요성 여부에 대한 평가도 포함한다.

  3. SW 검증 절차 활동 또는 SW 개발 표준은 SW 등급을 고려하여 잠재적인 SW 개발 환경과 관련된 에러를 줄이기 위해 정의해야 한다.

  4. 도구의 사용을 위해 도구에 대한 certification이 필요하다면 도구의 사용절차가 계획에 적절하게 명시되어야 한다.

  5. 특정 프로젝트에서 SW 도구의 부가적인 옵션이 선택된다면, 옵션의 영향성은 계획단계에서 검토 및 명시되어야 한다. 이것은 특히 컴파일러와 자동코드 생성기에 중요한 사항이다.

  6. 도구의 알려진 문제점 및 한계점은 반드시 평가해야 하며 항공 SW에 부정적인 영향을 끼칠 수 있는 이런 이슈들은 반드시 다뤄져야 한다.

 

  • 언어 및 컴파일러 고려사항

    SW 제품의 검증이 성공적으로 완료된다면 컴파일러는 해당 제품에 적합하다고 여겨진다. 이 활동이 유효 하려면, SW 검증 절차는 프로그래밍 언어 및 컴파일러의 특별한 특성을 고려할 필요가 있다 SW 계획 과정은 검증을 위한 프로그래밍 언어 및 계획을 선택할 때 위와 같은 특성을 고려해야 한다. 활동은 아래와 같다.

    1. 어떤 컴파일러는 오브젝트코드의 성능을 최적화하려는 특성이 있다. 만약 SW 레벨에 적절하게 테스트케이스가 작성되었다면 최적화의 정확성은 검증될 필요가 없다. 그렇지 않다면, 구조적 커버리지(structural coverage) 분석에 대한 이러한 특징의 영향이 결정되어야 한다. 추가적인 정보는 DO-178C 6.4.4.2에 기술되어 있다.

    2. 특정기능을 구현하기위해, 몇 개의 컴파일러는 소스코드로 직접 추적할 수 없는 오브젝트코드를 생성 한다. 예를 들어 초기화, 내장(built-in)된 에러 검출, 예외처리가 있으며 추가적인 정보는 DO-178C 6.4.4.2.b에 서술되어 있다. SW계획 절차에서 오브젝트코드의 검출 및 범위(coverage)를 검증하기 위한 수단을 제공해야 하며, 적합한 계획(appropriate plan)에서 수단을 정의해야 한다.

    3. 만약 새로운 컴파일러, linkage editor 또는 로더(loader) 버전이 도입되거나, SW 라이프 싸이클 동안 컴파일러 옵션이 변경될 경우, 기존에 테스트 및 커버리지 분석은 더 이상 유효하지 않을 수 있다. 검증 계획은 DO-178C 6장 및 12.1.3장과 일관되는 재검증 수단을 제공해야 한다.

 

  • SW 테스트환경

    SW 테스트 환경 계획은 통합 프로세스의 결과를 시험하기 위해 사용될 방법, 도구, 절차, HW를 정의한다. 테스팅은 target computer, target computer emulator, 또는 host computer simulator을 이용하여 수행된다.

    테스팅의 활동들은 다음과 같다.

  •  

  1. Emulator 또는 simulatorDO-178C 12.2장에 기술된 것처럼 툴 자격을 갖춰야 한다.

  2. Target computeremulator(또는 simulator)의 차이점 및 에러를 검출하고 기능을 검증하는 능력에 대한 target computeremulator(or simulator)차이점의 결과를 고려해야 한다. SW 검증 프로세스에 의해 에러가 검출되어야 하며 SW 검증 계획(SVP)에서 에러 검출방법이 명시되어야 한다.

 

3. Applicability by Software Level

해당 ObjectiveSW 레벨 A~C 에서는 모두 달성해야 하며 레벨 D SW는 해당되지 않는다.

 

 

4. Outputs(산출물)


  • PSAC (Plan for Software Aspects of Certification)

         소프트웨어 인증계획 문서 자세한 내용은 DO-178C11.1항목 참조

  • SDP (Software Development Plan)

         소프트웨어 개발 계획 문서 자세한 내용은 DO-178C11.2항목 참조

  • SVP (Software Verification Plan)  

         소프트웨어 검증 계획 문서 자세한 내용은 DO-178C11.3항목 참조

  • SCM Plan (Software Configuration Management Plan)

         소프트웨어 구성 관리 계획 문서 자세한 내용은 DO-178C11.4항목 참조

  • SQA Plan (Software Quality Assurance Plan)

         소프트웨어 품질 보증 계획 문서 자세한 내용은 DO-178C11.5항목 참조


 

5. Control Category by Software Level

SW 레벨 A, B의 산출물 PSAC, SDP, SVP, SCM Plan, SQA Plan CC1을 기준으로 형상 관리하며, SW 레벨 C, D의 산출물 PSAC CC1을 기준으로, 산출물SDP, SVP, SCM Plan, SQA Plan CC2기준으로 형상 관리한다.

 

6. 달성방안

  • SDP SW 개발 절차 및 활동에서 활용하는 방법, 도구(Tool), HW장비를 선정한다.

  • Development Tools, Coding Rule, Programming Language, Editor, Compiler

  • Verification Tools: LDRA Testbed/TBrun, Debugging Tool

  • Management Tools: MS-Project, PMS, ClearCase, CVS, Doors

  • Tool 중에서는 Tool Qualification을 받아야 하는 것을 명시한다. (Ref. DO-178C 12.2)

  • Tool을 선정할 때에는 SW의 잠재적인 위험 및 결함을 최소화할 수 있는지를 고려한다.

  • SW가 탑재될 HW장비 또는 그 장비를 대신할 Emulator 또는 Simulator를 선정한다.

 

다음에는 Objective - 4에 대해 알아보도록 하자.


+ Recent posts