17.소프트웨어 공학 테스트 (1)

1. 테스트의 이해

테스트와 소프트웨어 테스트

소프트웨어 오류로 인한 사고 사례

• 걸프전 당시 페트리어트 미사일 실패(0.5~1초 미세한 오차)
• 방사선 치료기 테락-25의 사고(테락-20만 믿고 테락-25의 전체 코드에 대한 테스트 생략)
• 상업용 우주선 아리안 5호의 공중 폭발(64비트->16비트 변환 과정 오버플로우, 불필요한 데드 코드 간과)

테스트의 필요성과 특징

전문가들이 정의한 소프트웨어 테스트

IEEE

시스템이 명시된 요구를 잘 만족하는지, 즉 예상된 결과와 실제 결과가 어떤 차이를 보이는지 수동,자동으로 검사하고 평가하는 작업을 의미

조하 만나

테스트는 시스템의 명세까지 옳다고 확실할 수 없고, 테스트 시스템 그 자체가 맞다고 증명할 수 없기 때문에 프로그램을 완전히 테스트할 수 없음

소프트웨어 테스트의 정의

소프트웨어에 내에 존재하지만 드러나지 않고 숨어 있는 오류를 발견할 목적으로, 개발 과정에서 생되는 문서나 프로그램에 있는 오류를 여러 기술을 이용해 검출하는 작업 오류를 찾아내 정상적으로 실행될 수 있도록 하는 정도이지, 소프트웨어에 오류가 없음을 확인시켜주지는 못함 테스트는 오류를 찾고 올바르게 수정하여 프로그램을 작동시킬 수는 있지만, 그 프로그램이 완전하고 정확하다고 증명할 수는 없음

소프트웨어 테스트의 목표

작은 의미

원시 코드 속에 남아 있는 오류를 발견하는 것 결함이 생기지 않도록 예방하는 것

큰 의미

개발된 소프트웨어가 고객의 요구를 만족시키는지 확인시켜주는 것 개발자와 고객에게 사용하기에 충분한 소프트웨어임을 보여주는 것 결과적으로 테스트의 목표는 ‘개발된 소프트웨어에 신뢰성을 높여주는 것

소프트웨어 테스트 수행의 어려움

• 테스트 케이스가 적어 효과에 한계가 있음 • 완벽한 테스트 케이스를 도출하기 어려움 • 테스트를 위한 실제 사용 환경을 구축하기 어려움 • 작은 실수를 발견하기 어려움 • 테스트 중요성에 대한 인식이 부족함 • 고객의 요구 사항을 충족시켜야 함 • 테스트 단계에서만 수행되는 단순한 활동이 아니라 개발 단계와 함께함 • 파레토원리를적용할수있음 • 모듈 단위를 점점 확대해나가며 진행함 • 완벽한 테스트는 불가능 • 개발자와 다른 별도의 팀에서 수행 • 살충제 패러독스(테스트 내성) 문제 해결을 위해 테스트 케이스 업데이트가 필요함

소프트웨어 테스트 결함 관련 용어

오류

• 소프트웨어 개발자에 의해 만들어지는 실수로 결함의 원인

결함

• 오류에 의해 프로그램이 완전치 못한 것으로, 고장의 원인 • 주로 프로그램에 필요 없는 정보를 포함하거나 필요한 정보가 없는 경우 • 결함으로 인해 프로그램이 실행 중에 멈추거나 예외 처리 모듈이 작동될 수 있고 시스템이 작동 불능 상태에 빠질 수 있음

고장, 실패, 문제, 장애

• 시스템이 요구 사항대로 작동하지 않는 것 • 요구분석명세서가 잘못되었거나, 이 명세서에 요구사항이 충분히 반영되지 않을 때 • 기술적으로 불가능한 요구사항이 포함된 경우와 같은 결함에 의해 발생 • 모든 결함이 반드시 실패를 유발하지는 않음

테스트 절차

테스트 절차

측정 도구나 장비를 이용해 구현된 소프트웨어가 사용자의 요구를 만족하는지를 테스트하는 절차 소프트웨어 개발 단계와 연계해 구성

테스트 계획 -> 테스트 케이스 설계 -> 테스트 실행 및 측정 -> 테스트 결과 분석 -> 오류 추척 및 수정

테스트 계획

• 테스트 목표를 정의하고, 테스트 대상 및 범위를 결정하며, 테스트 계획서를 작성하고 검토

입력	처리	결과
- 프로젝트 계획서 - 요구분석명세서	- 테스트 목표 정의 - 테스트 대상 및 범위 결정 - 테스트 계획서 작성 및 검토	- 테스트 요구사항 정의서 - 테스트 계획서

테스트 목표 정의

• 요구분석명세서를 기반으로 테스트할 목표를 정의
• 테스트 항목 중에서 어떤 항목을 중점적으로 테스트할 것인지 명확히 나타냄 (예: 보안성과 안정성 중 무엇을 중점적으로)

테스트 대상 및 범위 결정

• 테스트할 대상과 범위를 결정하는데, 이때는 업무 시스템별로 구분할 수 있음

테스트 계획서 작성 및 검토

• 테스트의 목적, 담당 인원, 테스트 전략과 접근 방법 수립, 필요한 자원 및 자원 확보 일정, 실시할 테스트의 종류, 적용할 테스트 기법, 일정 등에 관한 정보를 기록

• 작성된 테스트 계획서를 가다듬고, 이를 확정

• 테스트 설계 기법을 정의하고, 도출된 테스트 케이스에 입력 값으로 사용 할 원시 데이터를 작성

입력	처리	결과
- 테스트 계획서	- 테스트 설계 기법 정의 - 테스트 케이스 도출 - 원시 데이터 작성	- 테스트 케이스 명세소 - 테스트 설계서 - 테스트 절차서

테스트 케이스 설계 기법 정의

• 테스트할 프로젝트 문제의 성격을 파악하고 이 문제에 적합한 테스트 기법을 선정

테스트 케이스 도출

• 테스트 기법이 결정되면 이 기법을 이용해 테스트 케이스를 도출

원시 데이터 작성

• 결정된 테스트 케이스를 수행하기 위해 필요한 원시 데이터를 작성

테스트 실행 및 측정

• 테스트 환경을 구축하고 도출된 테스트 케이스를 이용해 테스트를 실시하고 테스트 실행 결과를 문서화

입력	처리	결과
- 프로젝트 계획서 - 요구분석명세서	- 테스트 목표 정의 - 테스트 대상 및 범위 결정 - 테스트 계획서 작성 및 검토	- 테스트 요구사항 정의서 - 테스트 계획서

테스트 환경 구축

• 테스트 계획서에 정의된 환경 및 자원을 설정해 테스트를 실행할 준비를 함

테스트 실행 및 측정

• 정의된 테스트 케이스를 실행하고 실행 결과를 측정

• 테스트가 끝나면 계획 대비 결과를 비교·분석하고 테스트 결과에 대한 보고서를 작성

입력	처리	결과
- 테스트 계획 단계의 목표 값 - 테스트 활동을 통해 얻은 결과 값	- 테스트 결과 분석 - 보고서 작성	- 테스트 케이스별 결과 분석서 - 소프트웨어 상태 보고서 - 테스트 결과 보고서

테스트 결과 분석

• 테스트 활동을 통해 얻은 결과 값과 테스트 계획 단계에서 목표한 값을 비교
• 예정된 테스트 품질 목표가 달성되었는지를 비교·분석

보고서 작성 테스트 결과

• 분석을 기반으로 테스트 결과 보고서를 작성
• 테스트 보고서에는 테스트를 수행한 결과와 테스트를 수행하는 데 사용된 방법 등을 기술
• 결과에 따른 평가와 권고 사항도 기술

오류 추적 및 수정

• 테스트 결과 어디에서, 어떤 종류의 오류가 발생했는지 확인하고 수정

입력	처리	결과
- 테스트 계획 단계의 목표 값 - 테스트 활동을 통해 얻은 결과 값	- 테스트 결과 분석 - 보고서 작성	- 테스트 케이스별 결과 분석서 - 소프트웨어 상태 보고서 - 테스트 결과 보고서

오류 수정 계획

• 테스트 결과 보고서를 기반으로 오류가 발생한 위치를 찾아냄
• 오류 수정 우선순위를 결 정해 오류 제거 계획을 설립

오류 수정

• 오류 제거 계획을 기초로 디버깅 도구 등을 이용해 오류를 수정

수정된 내용 검토

• 수정된 코드를 검토한 후 오류 수정 결과 보고서를 작성

2. 테스트의 분류

시각에 따른 테스트

확인 테스트

잘못 개발된 연산 프로그램의 예시

• 사용자가 1부터 10까지 곱하는 프로그램을 주문했는데, 개발자가 착각해 1부터 10까지 더하는 프로그램을 개발 할 경우
• 확인 테스트를 수행하면 1부터 10까지 더하는 계산과정이 정확하고, 결과가 55가 맞는지 체크
• 하지만 사용자가 원하는 것은 덧셈이 아닌 곱셈이므로 확인 테스트만으로는 사용자가 원하는 것을 개발했는지 알 수 없음

확인 테스트의 개요

• 각 단계에서 개발자의 시각으로 테스트하는 것으로, 설계서대로 만들었는지를 테스트
• 이전 단계에서 생성된 산출물이 현 단계의 산출물에 정확히 반영되었는지를 테스트
• 요구분석명세서의 내용이 설계서에 전부 반영되어 있어야 하고, 설계서의 내용대로 코딩이 이루어져야 함

확인 테스트의 한계

• 설계서가 요구분석명세서를 완벽하게 반영하지 않을 경우에는 결국 틀린(또는 부족한) 요구사항을 가지고 개발
• 개발 과정을 완벽하게 테스트했다고 해도 사용자에게는 쓸모없거나 불완전한 개발 결과가 나오게 됨

검증 테스트

• 앞의 예시에서 검증테스트를 실시할 경우 곱셈을 했는지 체크, 즉 사용자의 요구사항대로 만들었는지를 테스트
• 사용자의 목적에 맞게 개발했는지는 요구분석명세서대로 만들었는지가 기준
• 확인 테스트와 검증 테스트를 함께 사용해야 좀 더 강력한 테스트가 될 수 있으며, 이 둘을 묶어 V & V

사용 목적에 따른 테스트

목적에 따른 분류

성능 테스트

• 소프트웨어의 효율성을 진단하는 테스트
• 사용자의 요구사항 중에서 성능과 관련된 요구사항을 시스템이 얼마나 준수하는지 테스트
• 시스템의 전 후 관계에서 소프트웨어 실행 시간을 테스트
• 일반적으로 예상된 부하에 대한 실행 시간 , 응답 시간, 처리 능력 등을 체크하고, 자원 사용량 등을 테스트

스트레스 테스트

• 평소보다 많은 비정상적인 값, 양, 빈도, 부피 등으로 부하를 발생시켜 부하가 최고치인 상황에서 시스템의 반응을 살피고 이때 발생하는 오류를 찾는 것
• 비정상적이고 과도한 부하 상황에서 시스템이 잘 견디는지, 발생하는 오류에는 어떤 것들이 있는지를 확인

보안 테스트

• 부당하고 불법적인 침입을 시도해, 시스템을 보호하기 위해 구축된 보안 시스템이 불법적인 침투를 잘 막아내는지 테스트
• 외부 해커의 입장에서 비밀번호를 알려고 시도하거나, 구축해 놓은 방어 체계를 뚫거나 파괴하는 등 여러 가지 방법을 사용

안정성 테스트

• 며칠 동안 부하를 주면서 시스템이 안정적으로 돌아가는지를 테스트
• 메모리 누수: 소프트웨어 프로그램은 메모리가 필요할 때 요청해 사용하는데 사용 후 메모리를 반납하지 않아 사용 가능한 메모리양이 점점 줄어드는 현상

복원 가능성 테스트

• 소프트웨어를 고장 나게 해 놓고  소프트웨어 복구가 잘 되는지 확인해보는 테스트
• 만약 소프트웨어에서 자동으로 회복이 이루어진다면 소프트웨어 회복의 완벽성을 평가
• 기술자에 의해 소프트웨어가 복구된다면 복원 가능성 테스트에서 검사
• 복원 가능성 테스트는 운영체제, DBMS, 통신용 소프트웨어의 안정성 테스트에 적용 가능

프로그램 실행 여부에 따른 테스트

동적 테스트와 정적 테스트의 차이를 이해하고, 각 테스트 유형의 적절한 사용 사례를 공부합니다.

정적 테스트

• 자동차 수리시 보닛을 열어 부품 상태는 괜찮은지, 나사가 잘 조여 있는지 등을 면밀히 살펴보고 고장 난 곳을 찾음

• 정적 테스트: 프로그램을 실행하지 않고 코드를 검토하며 오류를 찾는 방법

동적 테스트

• 직접 주행하면서 엔진 소리가 필요 이상으로 크지는 않은지, RPM 수가 정상 수치보다 높게 올라가는지 확인
• 핸들의 떨림 현상이나 브레이크를 밞았을 때 밀리는 정도를 체크해 고장의 원인을 찾음

•동적 테스트: 프로그램을 실행하면서 찾는 경우