소프트웨어 테스팅

<소프트웨어 재앙>
- 소프트웨어가 문제가 생기면?
  - http://cafe.naver.com/softwarequality/480
  - 이스라엘의 텔아비브 대학(Tel Aviv)의 웹 사이트

- 어떻게 해야 하는가?
  - 소프트웨어가 오작동이 발생할 위험(risk)를 줄여야 한다
  - 위험: (발생확률) X (발생했을 때 끼치는 손실)
  - 소프트웨어 테스팅은 위험에서 발생 확률을 줄이는 작업

- 테스팅 목적
  - 결함 발견
  - 품질과 잔존 위험(residual risk)에 대한 정보 제공







<소프트웨어 테스팅>
- 정적 테스팅
  - 프로그램 실행을 하지않고 프로그램 코드나 산출물(문서) 결함을 찾는 활동
  - IEEE 1024 (리뷰)
    - 관리 리뷰 (Management Review)
    - 기술 리뷰 (Technical Review)
    - 인스펙션 (Inspection)
    - 워크쓰루 (walk-through)
    - 감사 (Audit)

- 동적 테스팅
  - 컴퓨터 결함을 발견할 의도로 프로그램이나 시스템을 '실행'하는 과정 (Meyers)

<테스트 오라클 기능>
- 생성기능: 각 테스트에 대해 예상 또는 기대되는 결과를 생성하여 제공하는 기능
- 평가기능: 예상 또는 기대 결과와 실제로 프로그램을 실행하여 얻어진 결과를 비교하여 테스트가 통과되었는지를 판단하는 기능







<Error>
- 부정확한 결과를 야기하는 '개발자의 행위'이다. 
- 사용자의 요구사항을 잘못 파악 하거나 typo나 프로그래밍 언어의 문법을 잘못 이해하여 코딩하는 경우에 발생할 수 있다. 






<Fault(결함)>
- 프로그램 기능을 제대로 수행하지 못하게 하는 '프로그램의 흠'
  - 잘못된 정보를 반영하는 경우(commission): 안 해야할 일을 하는 경우
  - 올바른 정보를 빠뜨리는 경우(omission): 해야할 일을 안하는 경우
  - 알고리즘 결함. 알고리즘 결함은 잘못된 프로그램 경로를 수행하도록 하는 제어 흐름과 관련된 결함이나 대상이 되는 프로그램의 외부와 통신과 관련된 인터페이스 결함 및 잘못된 자료 구조의 사용으로 인한 결함: 할일을 올바르지 않게 하는 경우
- 프로그램 코드에서 문제를 일으키는 정적인 부분

 
 
 
<예제>

<Failure(오작동)>
- 프로그램의 실행 결과와 기대 결과와의 (관찰가능한) 차이를 말한다. 
- 프로그램이 명세와는 다르게 동작하는 것이 외부에서 관찰되는 상황이다 







<완전한 테스트(Exhaustive Test)>
- 완전하게 테스트한다는 의미는 모든 입력 조건 조합에 대하여 테스트한다는 의미
- ex) 계산기

<테스트 한계>
- 테스트는 오류가 없음을 보여주지 않는다.
- 언제 테스트를 종료 할 것인가?
- 테스트 종료 조건







<동적 테스트 설계 기법>
1. 명세기반 테스트
- 출력 인터페이스 정보나 명세정보를 이용하여 테스트 케이스를 설계
- 블랙박스 테스팅

2. 구조기반 테스트
- 프로그램 코드 로직 정보를 이용하여 테스트 케이스 설계
- 화이트박스 테스팅

<테스트 커버리지>
- 얼마나 충분하게 테스트가 되었는지 알려주는 척도
- 테스트 커버리지 아이템: 테스트 케이스에 의해 포함되거나 실행될 필요가 있는 명세나 프로그램 항목
- 커버리지(%) = (테스트 케이스에 의해 실행된 테스트 커버리지 아이템 개수/전체 테스트 커버리지 아이템 개수) * 100
- '테스트 종료(완료) 기준'으로도 사용할 수 있다.




 
<예제>

<How?>
- 누락된 요구사항 검출(missing requirements): 요구사항 명세서에 요구사항을 추가한 후에 실행이 되지 않은 부분을 실행할 수 있는 테스트 케이스를 추가
- 누락된 테스트 검출(missing tests): 실행되지 않은 부분을 실행할 수 있는 테스트 케이스 추가
- 의도되지 않은 기능 검출: 프로그램에서 제거
- Dead code 검출: 프로그램에서 제거
- 활성화 되지 않은 코드 검출(Deactivated code): 현 시스템에서는 사용하지 않으나 특정 상황에서는 필요한 코드임을 보인다.
 
 

<경험 기반 테스팅>
- 테스터의 경험이나 지식 및 직관을 기반으로 테스트 케이스를 설계하는 방법
- 오류 추정(error guessing)은 대표적인 경험 기반 테스트 설계 기술이다. 오류 추정은 과거의 유사한 프로그램을 테스트 했던 경험이나 테스터의 직관을 바탕으로 일반적으로 발생할 수 있는 오작동의 원인이나 문제가 될 만한 영역 등을 추정하여 테스트 케이스를 설계하는 방법
- 오류 추정은 테스트 케이스를 설계하는 특별한 규칙이나 가이드라인이 없으며 독단적으로 사용되기 보다는 명세 기반 테스트 테스팅 등에 의해 검출되는 오류 유형들을 보완하기 위해 사용
 
 
 
<예제>