[소프트웨어 공학] - 소프트웨어 테스팅

 

프로그램 테스트는 프로그램이 의도한 대로 작동하고, 사용하기 전에 프로그램 결함을 발견하기 위해 수행되는 작업ㅇ디ㅏ.

테스트를 할 때는 인위적인 데이터를 사용하여 프로그램을 진행한다.

테스트의 결과를 확인하여 오류, 이상 현상 또는 프로그램의 비기능적 속성에 대한 정보를 확인한다.

오류의 존재를 확인할 수 있지만, 오류의 부재를 볼 수는 없다.

 

테스트의 주된 목표는 소프트웨어가 요구사항을 충족시키는지를 개발자와 고객에게 증명하기 위해서이다.

 

맞춤형 소프트웨어

• 요구 사항 문서에 기재된 각 요구사항에 대해 적어도 하나의 테스트가 있어야 한다.

일반소프트웨어

• 모든 시스템 기능과 이러한 기능들의 조합에 대한 테스트

결함테스트는 시스템 충돌, 다른 시스템과의 상호작용, 잘못된 계산 및 데이터 손상과 같은 원하지 않는 시스템 동작을 

발견하는데 관심이 있다.

 

Validation and defect testing

 

첫 번째 목표는 검증 테스트이다.

• 검증테스트란 시스템이 예상된 사용을 반영하는 특정한 케이스르 사용하여 정확하게 동작할 것을 기대하는 테스트이다.
• 개발자와 시스템 고객에게 소프트웨어 요구사항을 충족시킨다는 것을 입증하기 위해 수행된다.
• 성공적인 테스트는 시스템이 의도한 대로 작동함을 보여준다.

두 번째는 결함테스트이다.

• 결함을 노출시키기 위해서는 설계된 테스트케이스를 사용한다.
• 소프트웨어의 동작이 잘못되거나 명세와 일치하지 않는 결함을 발견하기 위해 수행된다.
• 성공적인 테스트는 시스템을 잘못 작동하도록 만들어 결함을 노출시킨다.

 

검증과 결함

 

검증

• 제품을 올바르게 만들고 있는가? -> 명세에 준수해야 함.

유효성 검사

• 올바른 제품을 만들고 있는가? -> 사용자의 실제 요구사항을 충족

 

V & V의 목표는 시스템이 목적에 맞게 적합하다는 신뢰를 확립하는 것이다.

시스템의 목적, 사용자의 기대 및 마케팅 환경에 따라 달라진다.

 

소프트웨어 목적

• 소프트웨어가 조직에게 얼마나 중요한지에 따라 신뢰 수준이 달라짐.

사용자의 기대

• 사용자는 특정 종류의 소프트웨어에 대해 기대치가 낮을 수 있다.

마케팅 환경

• 제품을 빠르게 출시하는 것이 결함을 찾는 것보다 중요할 수 있다.

 

소프트웨어 검토

• 정적 시스템 표현의 분석을 통해 문제를 발견하는 것 (정적검증)
• 도구 기반 문서 및 코드 분석

소프트웨어 테스트

• 제품동작을 실행하고 관찰하는 것에 관련됨(동적검증)
• 시스템은 테스트 데이터와 함께 실행되며 운영 동작이 관찰된다.

 

검토의 장점

• 검토는 정적인 과정이기에, 오류 간의 상호작용에 대해 걱정할 필요가 없다.
• 결함을 찾는 것에 그치지 않고, 표준 순수, 이식성 및 유지보수성과 같은 더 넓은 품질 속성도 고려할 수 있다.

검토와 테스트는 상호 보완적인 검증 기법이지, 대립 기법이 아니다.

검토는 명세와의 일치를 확인하지만 고객의 실제 요구사항과의 일치는 확인하지 않는다.

검토는 비기능적 특성을 확인할 수 없다.

 

개발테스팅은 시스템이 개발 중에 버그와 결함을 발견하기 위해 테스트되는 단계

릴리스 테스팅은 별도의 테스트팀이 시스템의 완전한 버전을 사용자에게 제공하기 전에 테스트하는 단계

사용자 테스팅은 시스템의 사용자 또는 잠재적 사용자가 자신의 환경에서 시스템을 테스팅하는 단계

 

개발 테스팅

• 유닛 테스팅 : 개별 프로그램이나 객체 클래스를 테스트, 객체나 메서드의 기능에 초점
• 컴포넌트 테스팅 : 여러 개별 유닛을 통합하여 복합 컴포넌트를 생성
  컴포넌트 인터페이스를 테스트하는데 초점
• 시스템 테스팅 : 컴포넌트 간 상호작용을 테스트하는데 초점

 

Unit test

• 개별 컴포넌트를 독립적으로 테스트 하는 과정
• 결함 테스트 과정
  • 유닛은 객체 내 개별 함수, 메서드, 객체 클래스 등이 있다.

객체 클래스 테스팅

• 객체와 연관된 모든 동작을 테스트 하는 과정
  • 메서드와 함수의 테스트
  • 객체 속성의 설정 및 검색
  • 객체를 가능한 모든 상태에서 실행하는 것을 포함
• 상속이 포함된 경우 어렵다.
  • 테스트할 정보가 고립되지 않기 때문, 부모와의 상호작용을 고려

 

Automated testing

• unit 테스트는 자동화되어 수동 개입 없이 테스트가 실행되고 확인될 수 있어야 한다.
• 단위 테스트 프레임워크는 특정 테스트 케이스를 생성하기 위해 확장하는 일반적인 테스트 클래스를 제공

구성요소

• 설정 : 테스트케이스, 입력과 예상 출력으로 시스템을 초기화
• 호출 : 테스트할 객체나 메서드를 호출
• 어서션 : 호출의 결과를 예상 결과와 비교한다. true->성공, false -> 실패

 

테스트 케이스는 테스트 대상 컴포넌트가 예상대로 작동하는지 보여줘야 한다.

결함이 있다면 이러한 결함들은 테스트 케이스에 의해 드러나야 한다.

두 가지 유형의 unit test

1. 컴포넌트가 예상대로 작동하는 지를 보여주는 것
2. 비정상적인 입력을 사용하여 이를 적절하게 처리하고 컴포넌트가 충돌하지 않는 지를 확인

 

파티션 테스트

• 공통된 특성을 가진 입력 그룹을 식별, 해당 그룹에서 테스트
• 테스트 케이스는 각 분할에서 선택되어야 한다.

가이드라인 기반 테스트

•  테스트 가이드라인을 사용하여 테스트 케이스를 선택하는 방법

일반적인 가이드라인

• 모든 오류 메시지를 생성하도록 하는 입력을 선택한다.
• 입력 버퍼가 오버플로우 되도록 하는 입력을 설계
• 동일한 입력 또는 일련의 입력을 여러반 바보가
• 유효하지 않은 출력이 생성되도록 강제
• 계산 결과가 너무 크거나 너무 작게 나오도록 한다.

 

인터페이스 테스팅

• 인터페이스 오류나 인터페이스에 대한 잘못된 가정으로 인한 결함을 감지하는 것이 목표
• 유형
  • 매개변수 인터페이스 
  • 공유 메모리 인터페이스
  • 절차 인터페이스
  • 메시지 전달 인터페이스

 

인터페이스 오류

• 인터페이스 오용
  • 호출하는 컴포넌트가 다른 컴포넌트를 호출하고 인터페이스 사용에 오류가 발생
• 인터페이스 오해
  • 호출하는 컴포넌트가 호출된 컴포넌트의 동작에 대해 잘못된 가정을 포함
• 타이밍 오류
  • 호출된 컴포넌트와 호출하는 호출하는 컴포넌트가 다른 속도로 동작, 

 

시스템 테스트

• 개발 중 시스템 테스트는 컴포넌트를 통합하여 시스템의 버전을 생성한 다음 통합된 시스템을 테스트하는 과정
• 중점은 컴포넌트 간의 상호작용을 테스트
  • 컴포넌트가 호환되며 올바르게 상호작용하고 인터페이스를 통해 올바른 시간에 올바른 데이터를
    전송하는지를 확인

 

Use-case testing

• 시스템 상호작용을 사용자의 관점에서 설명하는 유스케이스를 시스템 테스팅의 기반으로 사용하는 기법
• 해당 유스케이스를 테스트하는 것은 이러한 구성 요소들의 상호작용이 올바르게 이루어지는지를 확인하기 위한 것
• 유스케이스와 관련된 시퀀스 다이어그램은 구성요소와 상호작용을 시각적으로 표현
  • 다이어그램은 테스트 케이스를 설계하고 테스트 중에 시스템의 예상 동작을 결정하는데 도움이 된다.

 

 

Test -driven development TDD

• TDD는 테스트와 코드 개발을 번갈아가며 진행하는 소프트웨어 개발 기법
• 코드 작성 전에 테스트를 작서앟고, 테스트를 통과하는 것이 개발의 주요 동력
• 테스트에 대응하는 코드를 점진적으로 개발.
  이전에 개발한 코드가 해당 테스트를 통과할 때까지 다음 단계로 넘어가지 않는다.
• TDD는 애자일 방법론의 일부로 소개되었지만, 계획 중심적인 개발에서도 사용가능

 

TDD process 활동

• 필요한 기능의 증분을 식별
• 기능에 대한 테스트를 작성하고, 자동화된 테스트로 구현
• 새로 작성한 테스트와 이전에 작성한 모든 테스트를 실행,
  초기에는 기능이 구현되지 않아서, 새로운 테스트는 실패
• 기능을 구현하고 테스트를 다시 실행
• 모든 테스트가 성공적으로 실행되면, 다음 증분의 기능을 구현하기 위해 넘어감.

 

TDD의 이점

• 코드 보호
  • 작성한 모든 코드 세그먼트는 적어도 하나의 연관된 테스트를 가지며, 즉 모든 코드는 적어도 하나의 테스트를 가지도록 한다
• 회귀 테스트
  • 회귀 테스트는 프로그램이 개발됨에 따라 점진적으로 개발됨
• 단순화된 디버깅
  • 테스트가 실패하면 문제의 위치가 명확해짐.
  • 새로 작성한 코드를 확인하고 수정
• 시스템 문서화
  • 테스트 자체가 코드가 수행해야 하는 동작을 설명하는 형태의 문서로 사용됨.

 

회귀 테스트

• 시스템을 테스트하여 이전에 작동하던 코드가 변경으로 인해 손상되지 않았는지 확인
• 수동 테스트는 회귀 테스트 비용이 많이 든다.
• 자동화된 테스트를 사용하면 간단하고 직관적이다.
• 프로그램에 변경이 이루어질 때마다 모든 테스트를 다시 실행한다.
• 변경사항이 커밋되기 전에 테스트가 성공적으로 실행되어야 한다.
• 변경된 코드가 이전에 작성된 코드를 통과해야 함.

 

 

릴리스테스팅은 시스템 테스팅의 한 형태

주요 차이점은 개발에 참여하지 않아도 가능

릴리스 테스팅의 목적은 요구사항을 충족하고 외부 사용에 적합한지 확인하는 유효성 테스팅이다.

시스템 테스팅은 결함 테스팅이다.

 

요구사항 기반 테스팅  : 요구사항을 검토하고 해당 요구사항에 대한 테스트 또는 테스트를 개발하는 것을 의미

 

성능 테스팅

• 일련의 테스트 계획을 수립하여 부하를 점진적으로 증가시켜 시스템 성능이 불허할 정도로 나타날 때까지 테스트하는 것을 의미
• 스트레스 테스팅은 시스템을 고의로 과부 한 상태로 만들어 실패 동작을 테스트

 

User testing

• 사용자 또는 고객 테스팅은 시스템 테스트에 대한 입력과 조언을 제공하는 테스팅 과정의 한 단계
• 사용자나 고객의 관점과 요구사항을 반영하여 시스템의 동작과 성능을 평가하고 개선하는데 도우밍 된다.
• 사용자 테스팅은 포괄적인 시스템 및 릴리스 테스팅이 수행되었을지라도 필수적이다.

 

User testing 종류

• 알파테스팅 : 소프트웨어 사용자와 개발자 협력, 소프트웨어의 동작과 문제점을 파악하는 데 사용됨
• 베타테스팅 : 릴리스버전을 사용자들이 실험하고 발견한 문제점을 시스템 개발자에게 보고
• 인수 테스팅 : 고객들이 시스템을 테스트하여 시스템 개발자들로부터 인수하고 고객 환경에 배포할 준비가 되었는지를 결정하는
  과정

 

인수 테스팅 과정

• 인수 기준 정의
• 인수 테스트 계획
• 인수 테스트 유도
• 인수 테스트 실행
• 테스트 결과 협상
• 시스템 거부/수락

 

요약

• 테스트는 프로그램 내에 오류가 존재함을 보여줄 수 있짖만, 남아있는 결함이 없음을 입증할 수는 없다.
• 개발 테스팅은 소프트웨어 개발팀의 책임.
• 개발 테스팅은 유닛 테스팅, 컴포넌트 테스팅, 시스템 테스팅을 포함함
• 가능한 경우 자동화된 테스트를 작성
• 테스트 우선 개발은 테스트 코드를 작성한 후에 실제 코드를 작성하는 접근 방식
• 인수 테스트는 사용자 테스트 과정으로, 소프트웨어가 운영 환경에서 배포되고 사용하기에 좋은지 결정하는 것이 목표