문서요약 - 결함 허용을 위한 소프트웨어 결함 삽입 테스팅 by LAI

제목: 결함 허용을 위한 소프트웨어 결함 삽입 테스팅(Software Fault Insertion Testing for Fault Tolerance)

저자: MING-YEE LAI 외 1인, Bell Communications Research

문서유형: 연구소 기술 문서(총 21페이지), 1995년

 

결함 허용(fault tolerance)을 개선하기 위한 결함 삽입 테스팅 방법론을 제시하고, 해당 테스팅 방법론을 통신 시스템 분야 애플리케이션에 적용한 사례를 기술한 자료

---

통신 분야의 소프트웨어

• 1992년과 1993년, 연방 통신 위원회(Federal Communications Commission: FCC)의 네트워크 신뢰성 협회(Network Reliability Council: NRC)가 모든 주요 통신 시스템 공급자, 네트워크 제공자, 서비스 제공자, 사용자, 관련 연구 기관 등을 대상으로 대규모 조사를 수행하고 “Network Reliability: A Report to the Nation”라는 제목의 보고서를 발간함
• 이 보고서에 따르면 네트워크 구성 요소(예, 스위치, 디지털 교차 접속기, 신호 중계국)에 발생한 장애의 70% 이상이 소프트웨어 관련 문제에서 기인함

결함 허용(Fault tolerance)

소프트웨어 결함에 대비하여 회피(avoidance), 제거(elimination), 허용(tolerance)이라는 삼중 방어선이 존재함

• 결함 회피(Fault avoidance)는 소프트웨어의 명세, 설계, 코딩 프로세스 동안에 달성된다.
• 결함 제거(Fault elimination)는 테스팅과 유지보수 프로세스의 책임이다.
• 결함 허용(Fault tolerance)은 전개된 소프트웨어의 속성 중 하나이며, 예상되는 잠재적 실패로부터 살아남도록 설계된 것을 의미한다. 결함 회피와 결함 제거를 보완하는 결함 허용은 믿을 수 있는 통신 소프트웨어에서 없어서는 안될 것이며, 시스템 실패에 직면하여 “우아한 서비스 저하(graceful service degradation)”를 가능하게 한다.

소프트웨어 결함 삽입 테스팅(Software Fault Insertion Testing: SFIT)

• NRC 보고서는 결함 허용을 향상시키기 위하여 통신 시스템 공급자의 개발 프로세스의 한 부분으로 소프트웨어 결함 삽입 테스팅(Software Fault Insertion Testing: SFIT)을 포함할 것을 권고함
• 결함 허용을 위해 크고 복잡한 시스템을 테스팅 하는게 벅찬 일이므로, 이 일을 완수하기 위해서는 명확한 테스팅 방법론, 지원 툴, 테스팅 적정성(testing adequacy) 개념이 필수적이다.
• 소프트웨어 결함 삽입 테스팅의 주된 목적은 시스템으로 결함을 삽입함으로써 결함 허용 능력을 테스트하고, 시스템이 명세된대로(또는 고객이 기대하는대로) 결함을 발견하고 그것으로부터 회복할 수 있는지를 분석하는데 있다.
• SFIT를 수행한 결과로 개별 소프트웨어 버그를 수정하게 되거나 또는 시스템 결함 허용 측면에서 설계 미흡(design deficiencies)을 발견하게 될 수 있다.  

관련 용어 정의

국제 정보 처리 연맹(The International Federation for Information Processing: IFIP)의 실무 그룹(Working Group) 10.4가 아래와 같이 정의함. 이 논문도 소프트웨어 결함 삽입 테스팅(SFIT)을 기술하는데 있어 이 용어 정의를 따름

• 결함(Fault): 판정된(또는 가정에 의한) 에러 원인
• 에러(Error): 실패가 생기게 하기 쉬운 시스템 상태 일부, 시스템에서 결함(fault)의 존재를 나타내는 징후
• 실패(Failure): 인도된 서비스가 그 명세를 준수하지 못하고 일탈함, 정확한 서비스 인도에서 부정확한 서비스로 바뀜

각 결함(fault)은 아래와 같은 관련 속성(associated attributes)을 가진다.

• 타입(Type): 결함(fault)이 속한 분류 그룹. 예, 메모리 결함, 논리 결함
• 위치(Locality): 특정 컴포넌트에서 결함의 위치
• 잠복기(Latency): 결함의 삽입(시스템에 들어간 시점)과 관측(결함이 드러난 시점) 간의 시간 간격
• 빈도(Frequency): 주어진 시간 간격 동안 결함의 평균 발생 횟수
• 심각도(Severity): 결함이 시스템 성능에 미치는 영향의 정도를 나타냄. 결함 타입과 결함 위치의 조합에 의존하는 속성. 예, 중대 결함(critical fault), 주요 결함(major fault), 사소한 결함(minor fault)

소프트웨어 결함 삽입 테스팅(SFIT)의 기존 연구

소프트웨어에 결함이 삽입되는 방식으로 아래와 같은 것들이 있다.

• 사전 결정된 소스 코드의 특정 부분을 변경하여 문법적으로(syntactically) 정확하지만 의미상(semantically) 다른 뮤턴트를 생성함
• 지명된 위치에서 오브젝트 코드에 패치를 적용함
• 위 처럼 소스 코드나 오브젝트 코드를 직접 건드리는 방식이 아니라 실행 중인 시스템의 상태/동작을 변경하는 상태 삽입(state injection) 방법도 존재함. 즉, 결함이 야기하는 에러를 흉내내려는 의도의 에러 상태(erroneous state)가 조성됨 

상태 삽입을 위한 여러 방법이 존재한다.

①     프로세스 기반(Process-based): 컴퓨팅 상태를 변경시키는 높은 우선순위 프로세스를 통해 삽입. 이 방법은 종종 기저 운영 체제의 지원을 필요로 함

②     디버거 기반(Debugger-based): 디버거 기능(예, dbx, gdb)의 breakpointing, evaluating, jumping 등을 활용하여 에러가 실행 중인 프로세스로 삽입됨

③     메시지 기반(Message-based): 두 개 소프트웨어 컴포넌트 간의 메시지 주도 통신에서 메시지 기반 툴을 이용해 메시지 시퀀스를 훼손함으로써 에러 상태가 생성될 수 있음

④     스토리지 기반(Storage-based): 메모리, 디스크, 또는 테이프를 위한 스토리지 조작 툴을 사용함. 시스템 상태를 나타내는 스토리지 계층의 특정 위치의 값을 변경함으로써 에러가 시스템으로 삽입될 수 있음

⑤     커맨드 기반(Command-based): 운용자 터미널(craft interface terminal) 또는 원격 유지보수 터미널의 커맨드를 사용하여 운영/관리/유지보수/공급을 위한 시스템 엔터티의 상태를 변경함으로써 에러가 삽입될 수 있음

결함 관리자(FAULT MANAGER)

• 단순하게 보면 전형적인 통신 시스템이 결함 관리자(fault manager)와 서비스 관리자(service manager)라는 두 개의 논리적 엔터티로 구성됨
  - 결함 관리자(fault manager): 예외 처리를 전담하는 소프트웨어 보호 컴포넌트(예, 네트워크 보호, 노드 보호, 운영/관리/유지보수 소프트웨어)들의 집합
  - 서비스 관리자(service manager): 사용자에게 서비스를 제공하는 시스템의 나머지 부분
• 정상적인 운용 하에서는 결함 관리자가 서비스 관리자의 건강 상태를 지속적으로 감시하는 동안 서비스 관리자가 사용자에게 서비스를 제공함. 그러다 에러 상황이 발견되면 결함 관리자는 서비스 관리자를 정상 운용으로 되돌리기 위한 행동을 취함
• 이러한 관점에서 통신 시스템의 결함 허용을 테스팅 한다는 것은 결함 관리자를 테스팅 한다는 것과 마찬가지다. 결함 관리자의 반응을 촉발(trigger)하기 위해 소프트웨어 결함이 서비스 관리자로 삽입된다.

더 자세히는 결함 관리자가 고객에게 지속적인 서비스를 보장하기 위해 아래 기능을 제공한다(약어로 DIRR).

• 에러 발견(Error Detection): 지속적인 모니터링, 주기적인 테스트, 통화 당 테스트(per-call tests), 또는 기타 자동 프로세스를 통해 에러를 발견함. 소프트웨어 감사(Software audits)도 에러 발견 능력의 일부로 간주됨
• 에러 고립(Error Isolation): 에러를 그 소스(되도록이면 단일 컴포넌트 또는 컴포넌트의 적당한 서브셋)에 고립시킴
• 에러 복구(Error Recovery): 서비스 저하를 최소화하기 위해 자동 또는 수동 액션(예,  retry, rollback, on-line masking, restart, reload, re-configuration)을 통해 에러를 복구함
• 에러 보고(Error Reporting): 디스플레이 기기, 로깅 기기, 또는 운영 체제로 에러 메시지(에러에 대한 설명, 에러가 관측된 위치, 에러에 대한 시스템 반응)를 전송함

소프트웨어 결함, 에러, 실패의 분류(CATEGORIZATION)

결함 분류(Fault Categorization)

결함 분류는 개발 동안에 결함 예방(fault prevention)의 목적을 위해 광범위하게 연구되어 왔다. 이 연구에서는 결함 예방과 제거를 위한 결함 분류 보다는 결함 허용(fault tolerance)을 위한 결함 분류를 강조한다. 아래는 흔히 나타나는 단일 결함 타입의 예이다.

• 모듈 내 결함(Intra-module faults)
  - 메모리 결함(Memory faults): 불법 액세스(illegal access), 불법 쓰기(illegal write), 너무 큰 포인터, 범위를 벗어난 어레이 인덱스, 미할당 메모리, 버퍼 오버플로우, 미할당 버퍼, 초기화 안된 변수를 불법 참조
  - 로직 결함(Logic faults):  미정의 상태(undefined state), case 문에서 일부 case 누락, 에러가 있는 제어문, 틀린 알고리즘, 데이터 또는 프로그램에서 부정확한 값
  - 뮤테이션 결함(Mutation faults): 원래 의도와 다른 잘못된 연산자나 피연산자를 사용
• 모듈 간 결함(Intermodule faults)
  - 부정확한 입력(Incorrect input): 유효 범위를 벗어난 입력 값, 매칭 안되는 데이터 타입을 가진 입력
  - 부정확한 출력(Incorrect output): 유효하지 않은 출력 값
  - 부정확한 시퀀스/타이밍: 두 모듈 간의 잘못된 메시지 시퀀스, 너무 오래 지연된 메시지, 병행성 제어 결여(lack of concurrency control)

에러와 실패 분류(Error and Failure Category)

에러 또는 실패는 특정 조건 하에서 활성화된 결함에 의해 야기된다. 결함을 삽입하는 대신에 에러/실패를 직접 삽입하면 결함 잠복 시간(fault latency)이 짧아질 수도 있다. 예를 들어, 프로세서 크래시(crash)를 흉내내기 위해서는 프로세스로 결함을 삽입하는 것보다 크래시 메시지를 보내는게 프로세스를 실제로 크래시 시키기 더 쉽다. 아래는 현장에서 흔히 나타나는 에러/실패 타입의 예이다.

• 프로세스 에러(Process errors): 데드락, 라이브락(live locks), 프로세스 루핑(looping), 프로세스 무응답(process hung), 너무 많은 시스템 리소스 사용
• 메시지 에러(Message errors): 소실된 메시지, 훼손된 메시지, 순서가 뒤바뀐 메시지, 중복 메시지, 메시지를 기다리다 타임아웃
• 운영 체제 에러(Operating system errors): 잡 오버플로우(프로세스 과부하), 리소스 고갈(resources thrashing), 잘못된 신호, 잘못된 승인(acknowledgement)
• 데이터 에러(Data errors): 훼손된 데이터 값과 구조, 데이터 불일치, 데이터 무결성 위반
• Hanging 리소스: 알람, 터미널, I/O, 라인, 트렁크, CPU 등이 그대로 동결(반응 없음)
• CPU 또는 스토리지 기기 크래시
• 기기 또는 CPU 과부하
• 네트워크 에러(Network errors): 네트워크 정체(트래픽 오버플로우), 링크 변동(link oscillation), 라우팅 에러
• 운영 절차 에러(Operational procedure errors): 오퍼레이터에 의해 입력된 잘못된 데이터, 부정확한 유지보수 절차

소프트웨어 결함 삽입 테스팅 방법론(SFIT METHODOLOGY)

테스팅 생명 주기 중에서 시스템 테스팅 또는 승인 테스팅(acceptance testing) 단계에서 SFIT를 수행할 것이 권고되는데, 그래야 결함/에러/실패에 대한 시스템의 전체적인 반응을 관측하고 분석할 수 있기 때문이다. 하지만 결함 관리자 기능이 로컬 서브시스템 레벨에 놓인 몇몇 경우에는 SFIT가 단위 테스팅 레벨에서도 수행될 수 있다. 아래 그림은 체계적으로 결함 허용 능력을 입증하기 위한 SFIT 방법론을 나타낸다.

A - 사전 단계(Pre-SFIT Steps)

1. 소프트웨어 아키텍쳐 분석(Software Architecture Analysis)

SFIT를 수행하기 전에 소프트웨어와 그 아키텍쳐에 대한 충분한 지식이 필요함. 선행적으로 수행되는 이 분석은 아래와 같은 세 개의 주요 부분으로 구성됨

• 서비스 관리자 분석(service manager analysis): (a) 신규 또는 변경된 소프트웨어 컴포넌트, (b) 기능상 중요한 컴포넌트, (c) 에러 가능성이 높은 컴포넌트, (d) 테스트 커버리지가 낮은 컴포넌트 (e) 나쁜 소프트웨어 속성(예, 내부 테스팅 동안의 결함 밀도, 설계/코드 복잡도)을 가진 컴포넌트 등을 기반으로 잠재적인 위험 영역을 특정한다. 이 분석의 결과물로는 결함/에러 타입, 특정 테스트 케이스 관련 서비스 관리자에서 결함/에러 삽입 지점 등이 있다.
• 결함 관리자 분석(fault manager analysis): 결함 처리 메커니즘(fault handling mechanisms), 관측 메커니즘(observation mechanisms), 결함 관리자 내 모듈 인터액션을 분석한다.
• 결함 관리자/서비스 관리자 인터페이스 분석: 에러 코드와 그 속성(에러 설명, 심각도, 복구 액션 루틴), 인터페이스를 가로지르는 이벤트 시퀀스(에러 코드와 복구 액션으로 구성됨)를 분석한다.

 

2. 근본 원인 분석(Root Cause Analysis)

내부 테스팅의 결과와 외부 현장의 문제점들이 제품의 신뢰성에 대한 좋은 지표가 됨. 따라서 내부 문제 보고서 및 고객 서비스 보고서에 대한 근본 원인 분석은 SFIT에서 조명될 필요가 있는 공통적인 문제(테스트되어야 할 영역과 결함/에러 타입)를 식별하는데 테스팅 조직에게 도움을 줄 수 있다. 

3. 테스트 집합 선정(Test Set Selection)

• 테스트 집합 선정 동안 아래의 두 측면이 식별되어야 함
  - 결함이 삽입된 상황에서 결함 관리자의 올바른 동작을 평가하기 위해 체크해야할 속성/프레디켓(즉, 예상되는 시스템 동작)
  - 상응하는 프레디켓(즉, 실제 시스템 동작)의 어써션 검증을 위해 관측할 내용
• 실제 SFIT 테스팅에 앞서서 여러 요소(예, 테스트 커버리지, 가용한 테스팅 리소스)를 고려하여 테스트 집합이 선정되어야 함. 예를 들면, 아래와 같은 기준이 고려될 수 있다.
  - 테스트 커버리지를 향상시키는 테스트 케이스들
  - 현장에서 발생한 것과 유사한 결함/에러를 흉내내는 테스트 케이스들
  - 고객 서비스에 직접적 영향을 미치는 결함/에러를 겨냥한 테스트 케이스들
  - High 프로파일 결함/에러(예, 일반 대중의 관심을 끄는 결함)를 위한 테스트 케이스들
• 테스트 집합 선정에 있어서 또 하나의 중요한 요소는 테스팅에 가용한 시간이다. SFIT가 파괴적인 성격을 가지므로 시스템을 정상 조건으로 회복시키는데 걸리는 시간이 중요한 부분을 차지함

4. 테스트 계획(Test Planning)

테스트 집합이 선정된 후에는 테스팅을 계획해야 한다. 예를 들어, 선정된 테스트 집합에 기반하여 테스트 스크립트가 준비되어야 하고, 코드 기반 삽입의 경우 소프트웨어 패치가 미리 준비되어야 한다. 상태 기반 삽입의 경우는 시스템의 상태 변경을 위한 적절한 툴이 준비되어야 한다. 테스팅이 원격에서 수행되는 경우라면, 적절한 링크와 전문가 지원이 사전에 확립되어 있어야 한다. 사용자의 통상적인 오퍼레이션 프로파일 또는 비정상적 트래픽 상황을 시뮬레이션 하기 위해서 테스트 케이스의 백그라운드 트래픽이 계획되어야 한다. 

B - SFIT 단계

1. 결함/에러/실패 삽입(Fault/Error/Failure Insertion)

모든 테스트 케이스에 대해서 결함/에러/실패를 실제 삽입하는 단계. 결함/에러의 위치가 이 단계 동안에 식별되어야 한다. 사용되는 삽입 방법(예, 프로세스 기반, 디버거 기반, 메시지 기반)에 따라서 그에 상응하는 툴을 통해 결함/에러/실패를 삽입한다.

 

2. 테스트 실행 트리거(Test Execution Trigger)

시스템에 결함이 삽입되었어도 그게 활성화되지 않을 수도 있음. 따라서 삽입된 결함을 활성화시키는 테스트 트리거(사용자 입력 값, 내/외부 이벤트, 내/외부 메시지)가 이 단계 동안 설정될 필요가 있다.

 

3. 동작 관측(Observe Behavior)

삽입된 결함/에러에 대한 시스템 반응을 일정 시간대 동안 관측한다. 

C - 사후 단계(Post-SFIT Steps)

1. 테스트 결과 평가(Test Result Evaluation)

테스트 결과는 테스트 케이스의 효과성을 밝히고, 시스템 결함 허용 능력(fault tolerance capability) 관련 취약점을 드러나게 할 수 있음. 테스트 결과 평가 단계는 효과성 낮은 테스트 케이스를 제거하고, 시스템 결함 허용 능력에서 개선이 필요한 부분을 식별하는데 도움을 준다.

 

2. 테스트 커버리지 평가(Assess Test Coverage)

테스트 커버리지 적정성(test coverage adequacy)을 위한 기준으로 아래와 같은 것들이 있다.

-          라이브러리에 있는 결함/에러/실패 타입의 커버리지

-          결함 관리자의 기능적 커버리지(결함 관리자에 있는 모든 기능을 테스트)

-          결함 관리자의 구조적 커버리지(결함 관리자에 있는 모든 브랜치를 테스트)

-          서비스 관리자에 있는 위험 컴포넌트의 커버리지

-          소프트웨어의 결함 트리 분석으로부터 생성된 커버리지

 

적절한 테스트 적정성 수준을 선택함으로써 테스트 중단 규칙(test stopping rule)을 명세할 수도 있다.

 

3. SFIT 테스트 케이스 라이브러리 업데이트

공통적으로 흔히 발생하는 결함/에러/실패를 그 속성(발생 빈도, 심각도)과 함께 수집하여 저장해야 함. 이 라이브러리가 결함 허용 테스팅을 위한 테스트 입력을 정의하는데 사용될 수 있으며, 주기적으로 업데이트 된다. 공통적인 결함 타입 뿐만 아니라 드물고 예외적인 결함 허용 조건을 테스트하기 위해 설계된 결함(시스템 아키텍쳐 분석이나 결함 관리자의 취약점에 대한 이해를 통해 생성됨)도 라이브러리로 추가된다. 

샘플 SFIT 테스트 계획

복구 액션을 위한 테스트 계획(Test Plan for Recovery Actions)

일반적인 통신 시스템의 서비스 복구란 서비스 저하를 최소화하기 위해 취해진 자동 또는 수동의 보호 액션을 의미한다. 아래는 복구 루틴을 위한 SFIT 테스트 계획의 샘플이다.

 

A 포괄적 복구(Generic Recovery)

1. 설계대로 자동 복구가 수행되는지 보기 위해서 결함을 삽입하고 활성화시켜 서비스 복구 액션이 시작되도록 한다.

2. 결함을 삽입하고 활성화시켜 자동 서비스 복구가 시작되도록 하고 stable calls이 유지되는지 체크한다. transient calls의 경우 고객이 결함 존재를 인지 못한 채로 자동 서비스 복구가 만족스럽게 완료되어야 한다.

3. 각 복구 레벨에 대해 결함을 삽입하고 활성화시켜서 적절한 복구 액션이 시작되도록 한다(이것이 설계대로 동작하는지 보기 위해 시스템 반응을 관측함). 예를 들어, 시스템 운영에 사소한 영향을 주는 결함은 소규모 로컬 레벨의 복구를 불러오는 반면 심각한 서비스 영향을 주는 결함은 더 극적인 반응(예, 대규모 재시작, 소프트웨어 재로드)을 낳는다.

4. 시스템이 서비스 복구의 자동 승강(escalation)을 제공하는지 테스트하기 위해 결함을 삽입한다. 시스템이 아래를 수행할 수 있는지 분석하고 관측한다.

-          하드웨어와 소프트웨어를 알려진 상태로 복구함

-          콜/메시지 처리가 안전한 지점에서 재개되는 것을 허용함

-          이전 하위 레벨에서 보다 더 많은(추가된) 소프트웨어와 하드웨어를 포함함

-          서비스에 영향을 주는 레벨의 사용을 제한함. 특히, stable calls에 영향을 주는 레벨과 최근 변경 데이터는 수동 액션을 요구해야 함. 그 외 다른 레벨은 자동 복구가 허용됨

5. 수동 서비스 복구를 요구하는 결함을 삽입한다. 자동 복구 기능을 보완하는 여러 레벨의 초기화와 재구성 기능이 가용한지 보기 위해 테스트 한다. 

B 통화 처리 한정 복구(Call-Processing Specific Recovery)

1. 시스템 전체의 복구 액션이 아니라 로컬 복구를 제공하는 시스템에 대해서는 이 시스템이 설계대로 반응하는지 보기 위해 각 로컬 복구 영역을 테스트 하는 결함을 삽입한다.

 

C 데이터베이스 관리 복구(Database Management Recovery)

1. 데이터베이스 관리 시스템(DBMS)의 복구 메커니즘이 설계대로 동작하는지 검증하기 위해 트랙잭션 중단(aborted) 실패를 삽입한다.

2. DBMS의 복구 메커니즘이 설계대로 동작하는지 검증하기 위해 잠금 충돌 발견/해결 실패를 삽입한다.

3. DBMS의 복구 메커니즘이 설계대로 동작하는지 검증하기 위해 타임아웃 실패를 삽입한다.

 

D 메모리 관리 복구(Memory Management Recovery)

1. 메모리 관리의 에러 복구가 설계대로 동작하는지 검증하기 위해 메모리 오퍼레이션 에러를 삽입한다.

 

E 프로세스 간 통신 복구(Inter-Process Communication Recovery)

1. 시스템의 무결성(integrity)이 설계대로 유지되는지 검증하기 위해 메시지 에러를 입력한다.

 

F 네트워크 관리 복구(Network Management Recovery)

1. 네트워크 관리 기능 관련해서는 네트워크의 결함 처리 적정성을 관측하기 위해서 네트워크 관리 기능 패러미터를 훼손하는 결함을 삽입한다. 패러미터의 예로 아래를 들 수 있다.  

-          네트워크 성능 패러미터: 회선 포착 후 응답률(Answer-Seizure Ratio), 오버플로우 백분율(%OFL), 시간당 회선 포착률(seizures per circuit per hour), 시간 당 회선당 비트 수(bits per circuit per hour), 라우트 로드(occupancy)

-          교환 패러미터: 교환 입력 로드, 코드 발송자/수신자 라우트 로드, 프로세서 로드

-          트렁크 루트와 목적지 성능 패러미터: 라우트 오버플로우(congestion), 라우트 로드, 라우트 블로킹, 라우트 포착 후 응답률(route answer-seizure ratio), 라우트 교란 포착율(route disturbance seizure ratio)

2. 전환 절차(Changeover Procedure): 실패한 링크로부터 대기중인 정상 링크로 트래픽을 이동시키도록 소프트웨어에 결함을 삽입한다(예, CCS 체인지오버 소프트웨어).

3. 링크 복원 절차(Link Restoration Procedure): 실패 링크로부터의 복원을 수행하는 소프트웨어에 결함을 삽입한다(예, CCS 시그널링 링크 복원)

4. 전송 금지 절차(Transfer Prohibited Procedure): 전송 금지 절차를 처리하는 소프트웨어에 결함을 삽입한다(예, CCS TFP 절차).

5. 전송 허용 절차(Transfer Allowed Procedure): 전송 허용 절차를 처리하는 소프트웨어에 결함을 삽입한다(예, CCS TFA 절차).

6. 전송 제어 절차(Transfer Controlled Procedure): 전송 제어 절차를 처리하는 소프트웨어에 결함을 삽입한다(예, CCS TFC 절차).

7. 트래픽 흐름 제어 절차(Traffic Flow Control Procedure): 신호 트래픽 흐름 제어 절차를 처리하는 소프트웨어에 결함을 삽입한다(예, CCS 시그널링 트래픽 흐름 제어 절차).

감사 기능을 위한 테스트 계획(Test Plan for Audit Functions)

통신 시스템 소프트웨어에는 프로그램과 데이터의 유효함(validity)을 검사하고, 메모리 에러에 대한 보호를 제공하고, 문제 해결을 위한 알람/보고서를 생성하는 다양한 감사 프로그램(audit programs)이 존재한다. 감사 프로그램에서 사용할 수 있는 여러 감사 기법도 존재하는데, 예를 들면 아래와 같은 것들이 있다.  

• 중복 소프트웨어 체킹(Redundant Software Checking)
• 임시 메모리 덮어쓰기(Overwriting of Temporary Memory)
• 이미지 체킹(Image Checking)
• 일관성 체킹(Consistency Checking)
• 범위 체크(Range Check)
• 기간 체크(Duration Check)
• 데이터 정의 체크(Data Definition Check)
• 입/출력 체크(Input/Output Check)
• 체크섬(Checksumming)
• 불확실 상태 발견(Limbo States Detection)
• 포인트 투 체크, 포인트 백 체크(Point-to, Point-back Check)
• 초기화(Initialization)

아래는 소프트웨어 감사와 시스템 감사를 위한 테스트 계획 샘플이다.

1. 소프트웨어 감사(Software Audits)

(a)     프로그램에 대한 물리적 감사(Physical audits on programs): 감사 프로그램이 (체크섬 같은걸 통해) 비트 결함을 발견 및 수정할 수 있는지 보기 위해서, 프로그램 또는 데이터 영역에 비트 결함을 생성하는 결함을 삽입한다.

(b)    데이터에 대한 물리적 감사(Physical audits on data): 데이터 불일치나 데이터 무결성 위반 같은 결함을 삽입하고 감사 프로그램이 그것을 발견할 수 있는지 본다.

(c)     메모리 결함(Memory faults): 불법 메모리 액세스, 불법 쓰기, 너무 큰 포인터, 범위를 벗어난 어레이 인덱스, 미할당 메모리, 버퍼 오버플로우, 초기화 안된 변수 불법 참조 등을 생성하는 결함을 삽입하고, 감사 프로그램이 해당 결함을 발견할 수 있는지 본다.

(d)    잔존 설계 에러, 오퍼레이터 입출력 에러 등에 대한 논리적 감사(Logical audits): 범위 체크나 기간 체크 같은 기법에 의해 발견될 수 있는 논리적 에러를 테스트 하기 위해 결함을 삽입한다. 시스템이 설계된 대로 반응하는지 보기 위해 시스템 동작을 관측하고 분석한다.

 

2. 시스템 감사(System Audits)

(a)     콜 처리(Call processing): 개별 통화의 통화 처리 진행을 테스트 하기 위한 결함을 삽입한다.

(b)    콜 완성(Call completion): 감사 프로그램이 콜 완성률(the call completion rate)을 제대로 모니터하는지 테스트 하기 위한 결함을 삽입한다.

(c)     장비(Equipment): 하드웨어 장비(예, 라인, 트렁크, 코드 발신기와 수신기, 디스크 스토리지)에 대해 하드웨어 문제를 흉내내는 결함(예, device hanging)을 생성하고, 감사 프로그램이 이를 발견할 수 있는지 본다.

(d)    운영 체제(Operating system): 메모리 할당, 큐, 버퍼와 관련하여 감사 프로그램이 에러를 탐지하고 수정할 수 있는지 보기 위해서, 메모리를 훼손하는(또는 버퍼 오버플로우를 만드는) 결함을 생성한다.

(e)     프로세스 에러(Process errors): 잘못된 주소로 전송, 데드락, 라이브락, 프로세스 루핑, 프로세스 헝(process hung), 과도한 리소스 사용 같은 결함/에러를 삽입하고, 감사 프로그램이 그것을 발견할 수 있는지 본다.

(f)      메시지 에러(Message errors): 소실된 메시지, 훼손된 메시지, 순서가 틀린 메시지, 중복 메시지, 메시지 대기 타임아웃 같은 결함/에러를 삽입하고, 감사 프로그램이 그걸 발견할 수 있는지 본다.

(g)    알람(Alarms): 각 알람 상황에 대해 적정한 알람 수준이 활성화되고 보고되었는지 확인하기 위해 알람을 활성화하는 결함을 삽입한다. 또한 문제가 해결된 후에 알람이 리셋되는지도 확인한다.

(h)    네트워크 관련 에러(Network related errors): 네트워크 정체(트래픽 오버로드), 링크 변동, 라우팅 에러 같은 네트워크 이상(network anomalies)을 흉내내는 에러를 삽입하고, 감사 프로그램이 그걸 탐지할 수 있는지 본다.

SFIT 적용 사례

독립된 에이전트인 Bellcore가 이 논문에서 제안된 SFIT 방법론을 아래를 포함한 10개 이상의 통신 시스템에 적용함

• 단말국 회선 교환(end-office circuit switches)
• 공통선 신호 방식(common channel signaling systems)
• 신호 중계점(signal transfer points)
• 광대역 비동기 전송 모드 시스템(Broadband Asynchronous Transfer Mode systems)
• SONET 기반 분기결합 다중화기(Add-Drop Multiplexers)
• 디지털 교차 접속 시스템(digital cross-connect systems)

 

테스트된 시스템의 코드 라인 수가 5십만라인에서 5백만라인 이상에 달했으며, 테스트 대상 업체의 개발/테스팅/품질보증 조직이 SFIT 수행에 잘 협조하는 경우 2~10%의 히트율(총 테스트 수 대비 식별된 문제의 백분율)을 보임. 이 히트율에는 설계/구현 상의 미흡함(deficiencies)과 프로그램에 존재하는 실제 소프트웨어 버그가 포함됨

공통적으로 나타나는 소프트웨어 문제 예로 아래와 같은 것들이 있다.

• 부정확한 조건 체크(Incorrect condition check): 프로세싱 정보 앞에 조건 체크를 빠트림, 부정확한 경계 조건 체크(예, 체크된 값에 1의 오차가 있음), 부정확한 시맨틱 조건 체크(예, 체킹 프레디켓이 부정확한 값/변수를 포함)
• 부정확한 데이터 값을 사용(Use of incorrect data value): 예를 들어, 여러 다른 상황에서 값이 변경되게 되는 변수를 사용하는 대신에 프로그래머가 실제 숫자를 하드코드로 박아 넣음(프로그램 유연성 저하). 또 다른 예로 의도한 변수와 비슷하지만 틀린 변수명을 가진 변수에 액세스 함
• 소실된 또는 부정확한 신호 데이터(Missing or incorrect signal data): 부정확한 신호를 다른 소프트웨어 컴포넌트로 전송하거나 또는 정확한 신호이지만 부정확한 데이터 값을 가진 신호를 전송
• 부정확한 변수 세팅 또는 리세팅(Incorrect set or reset of variables): 데이터에 부정확한 값이 할당됨. 초기화 안된 변수 또는 포인터
• 부정확한 분기(Incorrect branching): 스파게티 코드를 가진 소프트웨어 시스템에서 흔한 결함 타입. GOTO 문이 많은 프로그램에서 부정확한 함수/서브루틴으로 분기하기 쉬움. 부정확한 분기가 IF-THEN-ELSE 문에서도 종종 발생함(프로그래머가 실수로 THEN과 ELSE 조건을 반대로 함)
• 누락된 또는 불필요한 코드(Missing or extra code): 예를 들어, 루프에서 EXIT 문이 누락되거나 메모리 버퍼를 리셋하는 인스트럭션이 누락됨
• 부정확한 실행 순서(Incorrect execution order): 실행 순서가 소프트웨어에서 액션 시퀀스를 결정하므로, 실행 순서가 뒤집혔을 때 부작용이 발생할 수 있음

SFIT 테스트 케이스 통과는 단지 시스템이 삽입된 결함에 대해 설계된 대로 반응한다는 의미일뿐 설계 자체가 정확하거나 충분하다는 의미는 아니다(저자의 경험을 보면 결함 허용 측면에서 설계 개선의 여지가 많음). SFIT 동안 발견된 설계 미흡(design deficiencies)의 예가 아래와 같다.

• 소프트웨어 감사 결여(Lack of software audits): 프로그램과 데이터에 있는 비일관성을 발견하고 수정하는데 소프트웨어 감사가 사용되는데, 많은 경우 프로그램/데이터의 일관성 체킹이 적절하지 않았음. 서비스 품질을 손상시키지 않도록 우선순위를 매긴 소프트웨어 감사가 지속적으로 또는 주기적으로 수행되어야 하는데, 이런 목표가 일부 설계에서 종종 무시된다.
• 부적정한 시스템 복구(Inadequate system recovery): 소프트웨어 에러에 대한 대응으로 전체 시스템을 재시작하여 모든 변수와 카운터를 청소하는게 현재 많은 통신 시스템의 관행. 하지만 이 시간 동안 고객은 연결이 끊기고 신호음이 사라지는 불편을 겪게 된다. 고객에게 미치는 서비스 영향을 최소화하기 위해서는 에러의 심각도와 빈도에 따라 여러 다른 수준의 복구 액션이 제공되어야 하고 또한 복구 액션의 시간도 최소화되어야 한다.
• 복구 액션이 너무 극단적(Recovery action too drastic): SFIT를 수행하는 동안 많은 경우에 단순한 실수에도 시스템 재시작이 이루어지면서 수천명의 가입자에게 영향을 미치는 결과를 낳았음. 결함에 대한 이런 시스템 반응(즉, 시스템 재시작)이 문제를 해결할지는 모르지만 고객에게 영향을 최소화해야 한다는 측면에서는 부적절한 설계로 볼 수도 있다.
• 시스템 복구 승강 메커니즘의 결여(Lack of system recovery escalation mechanism): 로컬 레벨의 액션이 소프트웨어 문제를 해결할 수 없으면 보통의 통신 시스템은 이 문제를 더 높은 레벨로 올리는데, 이를 복구 승강(recovery escalation)이라 부른다. 하지만 많은 테스트 케이스에서 언제 문제를 상위 레벨로 올려야 하는지에 대한 가이드라인이 존재하지 않는걸 발견함. 또한 시스템에 여러 다른 복구 승강 메커니즘이 존재하고, 이것들이 일관성 없이 적용되는 경우도 발견함