테스트

소프트웨어 테스트의 정의

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

소프트웨어 테스트의 목표

• 작은 의미
• 원시 코드 속에 남아 있는 오류를 발견하는 것
• 결함이 생기지 않도록 예방하는 것
• 큰 의미
• 개발된 소프트웨어가 고객의 요구를 만족시키는지 확인시켜주는 것
• 개발자와 고객에게 사용하기에 충분한소프트웨어임을 보여주는 것
• 결과적으로 테스트의 목표는 개발된 소프트웨어에 신뢰성을 높여주는 것

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

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

핵심 용어

• 오류 : 오류는 소프트웨어 개발에 의해 생기는 실수로 결함의 원인이 된다.
• 결함 : 결함은 오류에 의해 프로그램이 완전치 못한 것으로, 고장의 원인이 된다.
• 고장 실패, 문제, 장애 : 고장. 실패, 문제, 장애 등은 시스템이 요구사항대로 작동하지 않는 것을 말한다.

테스트 절차

테스트의 분류

크게 4가지로 분류 한다.

• 시각에 따른 테스트
• 사용 목적에 따른 테스트
• 프로그램 실행 여부에 따른 테스트
• 소프트웨어 개발 단계에 따른 테스트

시각에 따른 테스트

1. 확인 테스트
2. 검증 테스트

사용 목적에 따른 테스트 

1. 성능 테스트
2. 스트레스 테스트
3. 보안 테스트
4. 안정성 테스트
5. 복원 가능성 테스트

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

1. 정적 테스트
2. 동적 테스트

정적 테스트

• 프로그램 코드를 실행하지 않고 여러 참여자가 모여 소프트웨어 개발 중에 생성되는 모든 명세나 코드를 검토해서 실패보다는 결함을 찾아내는 방법
• 정적 테스트를 위해 도구를 사용하면 프로그램 코드 분석 뿐만 아니라 마크업 언어로 작성한 파일과 같은 산출물도 검토할 수 있다.

정적 테스트 방법

비공식 검토

• 소프트웨어 개발 과정에서 생성되는 문서, 프로그램과 같은 산출물을 동료와 함께 책상에서 검사하는 것
• 제품을 검토할 목적으로 하는 간단한 만남 등이 이에 속한다.
• 개별 검토와 동료 검토가 주로 해당된다.

공식 검토

• 동료와 소프트웨어 기술 전문가들이 수행하는 소프트웨어 품질 제어 활동
• 결함을 찾기 위해 정의된 절차에 따라 적절히 계획되고 통제
• 검토 회의와 소프트웨어 검사가 주로 이런 방식으로 수행된다.

공식 검토에서는 다음과 같은 내용을 검토한다.

• 원시 코드상에 존재하는 오류를 검토
• 소프트웨어가 사용자의 요구를 충분히 반영했는지 검토
• 소프트웨어가 미리 정의된 표준을 지키는지 검토
• 소프트웨어 개발 방식이 일관적인지 검토
• 소프트웨어가 관리하기 쉬운지 검토

공식 검토 수행 절차

공식 검토 수행 절차

동적 테스트

명세 기반 테스트

입력 값에 대한 예상 출력 값을 정해 놓고 그대로 결과가 나오는지를 확인함으로써 오류를 찾는다.

프로그램이 기능을 어떻게 수행하는가보다는 사용자가 원하는 기능을 수행하는가에 대해 테스트한다.

명세 기반 테스트의 대표적인 방법으로는 아래와 같은 테스트 기법들이 있다.

1. 신택스 기법
2. 동등 분할 기법
3. 경계 값 분석 기법
4. 원인-결과 그래프 기법

구현 기반 테스트

입력 데이터를 가지고 실행 상태를 추적함으로써 오류를 찾아내기 때문에 동적 테스트 부류에 속한다.

프로그램 내부에서 사용되는 변수나 서브루틴 등의 오류를 찾기 위해 프로그램 코드의 내부 구조를 테스트 설계의 기반으로 사용한다.

테스트 절차는 아래와 같다.

1. 테스트 데이터 적합성 기준을 선정한다.
2. 테스트 데이터를 생성한다.
3. 테스트를 실행한다.

대표적인 구현 기반 테스트 방법으로는 다음과 같은 것들이 있다.

1. 문장 검증 기준
2. 분기 검증 기준
3. 조건 검증 기준
4. 분기/조건 검증 기준
5. 다중 조건 검증 기준
6. 기본 경로 테스트

소프트웨어 개발 단계에 따른 테스트

아래 그림은 테스트 과정의 단위 테스트, 통합 테스트, 시스템 테스트, 인수테스트가 V자로 연결된다고 해서

개발 단계에 따른 테스트를 V 모델이라고도 한다.

단위 테스트

• 프로그램의 기본 단이인 모듈을 테스트
• 구현 단계에서 각 모듈의 개발을 완료한 후 개발자가 요구분석명세서대로 정확히 구현되었는지 테스트
• 개별 모듈이 제대로 구현되어 정해진 기능을 정확히 수행하는지를 테스트
• 한 모듈을 테스트하려면 그 모듈과 직접 관련된 상위 모듈과 하위 모듈까지 모두 존재해야 한다.

드라이버와 스텁

• 테스트 드라이버 : 상위 모듈의 역할을 하는 가상의 모듈, 테스트할 모듈을 호출하는 역할
• 스텁 : 하위 모듈의 역할을 하는 가상의 모듈, 테스트할 모듈이 호출할 때 인자를 통해 받은 값을 가지고 수행한 후 그 결과를 테스트할 모듈에 넘겨주는 역할
• 드라이버와 스텁 모듈은 테스트할 때 필요한 기능만 제공할 수 있도록 단순하게 구현

단위 테스트 수행 후 발견 되는 오류

• 잘못 사용한 자료형
• 잘못된 논리 연산자
• 알고리즘 오류에 따른 원치 않는 결과
• 틀린 계산 수식에 의한 잘못된 결과
• 탈출구가 없는 반복문의사용

통합 테스트

• 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생할 수 있는 오류를 찾는 테스트
• 모듈 간의 상호작용이 정상적으로 수행되는가를 테스트
• 모듈 사이의 인터페이스 오류는 없는지, 모듈이 올바르게 연계되어 동작하고 있는지 체크

모듈 통합 방법에 따른 분류

• 한꺼번에 하는 방법 : big-bang 테스트
• 점진적으로 하는 방법 : 하향식 기법, 상향식 기법

시스템 테스트

• 시스템 전체가 정상적으로 작동하는지를 체크
• 모듈이 모두 통합된 후 사용자의 요구 사항들을 만족하는지 테스트
• 사용자에게 개발된 시스템을 전달하기 전에 개발자가 진행하는 마지막 테스트
• V & V에서 확인에 해당
• 실제 사용 환경과 유사하게 테스트 환경을 만들고 요구 분석 명세서에 명시한 기능적, 비기능적 요구 사항을 충족하는지 테스트
• 주로 부하를 주는 상황에서 수행하고, 비기능적 테스트를 중심으로 수행한다.

인수 테스트

• 시스템이 예상대로 동작하는지 확인하고, 요구사항에 맞는지 확신하기 위해 하는 테스트
• 시스템을 인수하기 전 요구분석명세서에 명시된 대로 모두 충족시키는지 사용자가 테스트
• 인수 테스트가 끝나면 사용자는 인수를 승낙한 것
• 시스템이 사용자에게 정상적으로 인수되면 프로젝트는 종료된다.
• 인수 테스트 시 인수테스트 계획서는 사용자가 직접 작성하거나, 개발자가 작성한 것을 사용자가 승인
• 알파 테스트와 베타 테스트 등이 있다.

회귀 테스트

• 확정 테스트
• 회귀 테스트
• 수정을 위한 회귀 테스트
• 점진적 회귀 테스트

이상으로 포스팅을 마칩니다. 감사합니다.

 

참고자료

쉽게 배우는 소프트웨어 공학 2판 (9단원 테스트)

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791156645429 

쉽게 배우는 소프트웨어 공학 - 교보문고