소프트웨어 테스팅이란?

1. 테스팅이란 무엇인가?

'테스팅'

응용 프로그램 또는 시스템(구성요소 포함)의 동작과  성능, 안정성이 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 과정

전통적인 테스팅 개념은 응용 프로그램 또는 시스템이 잘 작동하는지 확인하는 것

현재의 테스팅 개념은 사용자의 기대 수준과 요구 사항에 맞게 구현되고 동작하는지를 확인하고 이를 통해 결함을 발견하고, 최종적으로 결함 데이터를 근간으로 개발 프로젝트의 리스크(Risk)에 대한 수치적인 판단 근거를 의사 결정권자(프로젝트 관리자 등)에게 전달하는 것

 

개발 프로젝트 초기에 개발 중간 산출물(Work products)을 테스팅 관점에서 리뷰(Review)하고, 테스트 케이스를 미리 만드는 과정에서 결함을 발견하는 작업(결함 예방 활동)도 테스팅 활동의 중요한 부분이라고 말할 수 있습니다.

 

생각해 보세요. 사용자에게 전혀 필요없는 부분을 개발하고 개발한 부분을 테스트한다면 무의미 하지 않을까요?

'요구사항이 잘못된것 아닐까?'와 같은 리뷰가 중요할까요? 개발이 중요한 것일까요?

이 2가지 물음 중에서 현재의 테스팅은 전자가 더 중요하다고 생각합니다.

 

프로그램을 개발하기 전에 요구사항 등을 리뷰하는 것을 정적 테스트라고 하고,

프로그램 개발 이후에 실제 실행하면서 테스트하는 것을 동적 테스트라고 합니다.

 

본 수업에서는 정적 테스트보다 동적 테스트를 하는 방법에 좀 더 초점이 맞춰져 있습니다.

 

 

2. 소프트웨어에서 테스트가 필요한 이유

소프트웨어가 올바르게 동작하지 않는 경우,  다음과 같은 문제가 발생할 수 있습니다.

 

1) 금전적인 손실

2) 시간 낭비

3) 비즈니스의 이미지 손상

4) 부상이나 사망

 

소프트웨어가 올바르게 동작하지 않는다고 해서 부상이나 사망을 할 수 있다는 문제에 대해 의아해 할수 있습니다.

하지만 오늘날에는 우주선, 비행기, 선박, 자동차 등 다양한 곳에서 소프트웨어가 사용되기 때문에

오동작을 일으킬 경우 실제로 부상이나 사망까지도 일어나게 할 수 있습니다.

 

따라서, 테스팅은 이러한 소프트웨어 시스템의 문제를 최소화기 위해 필요합니다.

 

 

3. 소프트웨어 결함의 원인

소프트웨어가 결함이 발생하는 이유는 무엇일까요?

개발자가 잘못 작성한 오류로 인하여 결함(Defects 또는 Bug)이 발생합니다.

결함이 있는 소프트웨어를 실행하게 되면 장애(Failure)가 발생하여 의도한대로 소프트웨어가 동작하지 않거나

또는 소프트웨어가 동작하지 않아야 하는 상황에서 동작하는 문제가 발생할 수 있습니다.

단, 모든 결함의 원인이 인간이 범하는 오류 떄문 만은 아닙니다.

 

인간이 오류를  범하기 쉽기 때문에 발생하는 결함도 있지만 시간적인 압박, 복잡한 코드, 기반환경의 복잡성,

기술이나 시스템의 변경, 그리고  수많은 시스템 상호간의 연동 등의 이유로 발생할 수도 있습니다.

 

 

4. 소프트웨어 개발, 유지보수, 운영 시 테스팅의 역할

소프트웨어는 개발이 완료되고 실제 환경에 배포를 해야 운영됩니다.

운영되는 도중에도 해당 소프트웨어를 더 이상 사용하지 않을 때까지 계속해서 유지보수를 하게 됩니다. 

테스팅은 개발 시에만 필요한 것이 아니라 개발, 유지보수, 운영 시에 모두 필요합니다.

그렇다면 테스트가 언제 필요한지 알아볼까요?

 

 

1) 테스팅을 통해 릴리즈 전에 발견되지 않은 결함들이 수정된다면, 

운영 환경 내에서 발생하는 리스크(risk)를 줄이는데 기여할 수 있으며 

소프트웨어 품질에 도움을 줍니다.

 

2) 테스팅은 개발 초기의 요구사항 분석 단계부터 리뷰 및 인스펙션을 통해 정적으로 이뤄질 수 있으며

각각의 개발 단계에 대응하는 테스트 레벨(test level)에 따른 테스팅이 이뤄집니다.

 

3) 기존에 운영되는 소프트웨어 시스템이 유지 보수 활동으로 변경 및 단종되거나 

환경이 변하는 경우, 변경된 소프트웨어에 대한 테스팅과 

변경된 환경에서의 운영 테스팅이 요구됩니다.

 

4) 소프트웨어 테스팅은 계약상(법적) 요구조건들, 또는 산업에 특화된 표준들을 만족시키기 위해서 필요합니다.

 

 

5. 테스팅과 품질

테스팅으로 발견된 결함이 소수이거나 없을 경우에 소프트웨어의 품질에 대한 확신(Confidence)를 가지게 됩니다.

잘 설계된 테스트는 시스템의 전반적인 리스크를 감소시키고 결함을 발견합니다.

발견된 결함이 수정될 때 소프트웨어 시스템의 품질 증가됩니다.

 

품질을 높이기 위해서는 이전 프로젝트를  통해 많은 테스팅 경험과 정보를 확보할 필요성이 있습니다. 

다른 프로젝트에서 발견된 결함의 근본적인 원인에 대한 이해함으로써 프로세스를 개선할 수 있으며, 그러한 결함의 재발을  방지함으로써, 결과적으로, 차후 시스템의 품질을 개선할 수 있게 됩니다.

 

개발 표준이나 교육 훈련 그리고 결함 분석 등과 함께 테스팅은 품질 보증 활동의 하나로 테스팅을 통해 소프트웨어 시스템의 품질을 확보할 수 있습니다.

 

 

6. 테스팅은 얼마나 해야 충분한가?

어느 정도 테스팅 하는 것이 적절한지를 파악하기 위해서는 다음과 같은 리스크(Risk) 수준과 프로젝트 제약사항을 고려해야합니다.

 

1) 기술적인 내용

2) 비즈니스 제품

3) 프로젝트 리스크

4) 시간과 비용

 

테스팅은 개발 프로젝트 관련자들이 테스트된 소프트웨어나 시스템의 다음 개발 단계로의 릴리즈(Release)에 대한 결정 또는 고객에게 이양(Handover)하는 릴리즈에 대한 결정을 내릴 수 있도록 충분한 정보를 제공해야 합니다.

 

 

7. 테스팅의 일반적인 원리

원리 1 – 테스팅은 결함이 존재함을 밝히는 활동이다.

테스팅은 결함이 존재함을 드러내지만, 결함이 없다는 것을 증명할 수 없습니다. 

즉, 프로그램이 완벽하다고 증명할 수 없습니다. 

이는 테스트 한 부분까지만 잘 동작한다고 말할 수 있고 테스트를 하지 않은 부분은 결함 있는지 또는 없는지에 대해서 예측할 수 없다는 의미입니다.

 

원리 2 – 완벽한 테스팅(Exhaustive testing)은 불가능하다.

모든 가능성(입력과 사전 조건의 모든 조합)을 테스팅하는 것은 지극히 간단한 소프트웨어를 제외하고 가능하지 않습니다.

보통 다음과 같은 이유 때문입니다.

 

- 한 프로그램 내의 내부 조건이 무수히 많음. (무한 경로)

- 입력이 가질 수 있는 모든 값의 조건이 무수히 많음 (무한 입력 값)

- GUI 이벤트 발생 순서에 대한 조합도 무수히 많음 (무한 타이밍)

 

완벽한 테스팅 대신, 리스크 분석과 결정된 우선순위에 따라 테스팅 활동 노력을 집중시켜야 합니다. (Risk-based testing) 

완벽한 테스팅은 우주항공, 의료 등 안전이 최우선인 소프트웨어를 개발할 때 고려할 수 있으나 실제로 완벽한 것은 아니고 강력한 테스팅으로 볼 수 있습니다.

 

원리 3 – 테스팅을 개발 초기에 시작한다.

테스팅 활동은 소프트웨어나 시스템 개발 수명주기에서 가능한 초기에 시작되어야 하며,  설정한 테스팅 목표에 집중해야 합니다. 

개발 초기에 테스팅을 시작한다는 것의 의미는 개발의 시작과 동시에 테스트를 계획하고 전략적으로 접근하는 것을 고려하는 것은 물론, 요구사항 분석서와 설계서 등의 개발 중간 산출물을 분석하여 테스트하는 것을 의미합니다.

 

 

8. 통합 테스트 / 단위 테스트

통합 테스트(integration test) : 하나의 빈을 테스트할 때 관련된 빈들이 모두 잘 동작하는지 테스트하는 것 

단위 테스트(unit test) : 관계된 다른 클래스와는 상관 없이 특정 빈이 가지고 있는 기능만 잘 동작하는지 확인하는 것

 

참고
https://www.boostcourse.org/web326/lecture