728x90
Test 란 ?
프로그램을 사용하다 한번쯤은 버그를 발견하게 됩니다. 사용하던 프로그램이 멈추거나, 오동작을 하는데요. 좀 더 잘 동작하는 프로그램을 작성하기 위해서는 테스트를 진행할 필요가 있습니다. 이번 시간에는 테스트가 필요한 이유에 대해 알아보도록 하겠습니다.
- 테스트가 필요한 이유에 대해 이해합니다.
- 테스트의 원리에 대해 이해합니다.
테스팅이란 무엇인가?
'테스팅'이란 응용 프로그램 또는 시스템(구성요소 포함)의 동작과 성능, 안정성이 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 과정이라고 말할 수 있습니다. 전통적인 테스팅 개념은 응용 프로그램 또는 시스템이 잘 작동하는지 확인하는 것입니다. 현재의 테스팅 개념은 사용자의 기대 수준과 요구 사항에 맞게 구현되고 동작하는지를 확인하고 이를 통해 결함을 발견하고, 최종적으로 결함 데이터를 근간으로 개발 프로젝트의 리스크에 대한 수치적인 판단 근거를 의사 결정권자에게 전달하는 것을 말합니다. 개발 프로젝트 초기에 개발 중간 산출물을 테스팅 관점에서 리뷰하고, 테스트 케이스를 미리 만드는 과정에서 결함을 발견하는 작업(결합 예방 활동)도 테스팅 활동의 중요한 부분이라고 말할 수 있습니다. 생각해보면 사용자에게 전혀 필요없는 부분을 개발하고 테스트하면 무의미하잖아요. '요구사항이 잘못된 것이 아닐까?'와 '개발만 하면 되지' 중 현재의 테스팅은 전자가 더 중요하다고 판단합니다. 프로그램을 개발하기 전에 요구사항 등을 리뷰하는 것을 정적 테스트라고 하고, 프로그램 개발 이후에 실제 실행하면서 테스트하는 것을 동적 테스트라고 합니다. 본 수업에서는 정적 테스트보다 동적 테스트를 하는 방법에 좀 더 초점이 맞춰져 있습니다.
소프트웨어에서 테스트가 필요한 이유
테스팅이란 사용자의 요구사항을 검증하고, 응용 프로그램 또는 시스템의 동작과 성능, 안정성이 요구 수준을 만족하는지 확인하기 위해 결함을 발견하는 과정이라고 했습니다. 이런 소프트웨어가 올바르게 동작하지 않을 경우 다음과 같은 문제가 발생하게 됩니다.
- 금전적 손실
- 시간 손실
- 비즈니스 이미지 손상
- 부상 혹은 사망
오늘날 소프트웨어는 실제 물리적인 동작을 하게 하는 것들도 많습니다. 따라서 테스팅은 이러한 소프트웨어 시스템의 문제를 최소화하기 위해 필요합니다.
소프트웨어 결함의 원인
소프트웨어가 결함이 발생하는 이유는 무엇일까요? 개발자가 잘못 작성한 오류로 인하여 결함(Bug)이 발생합니다. 결함이 있는 소프트웨어를 실행하게 되면 장애(Failure)가 발생하여 의도한대로 소프트웨어가 동작하지 않는 등의 문제가 발생합니다. 단 모든 결함의 원인이 인간의 오류 때문은 아닙니다. 시간적 압박, 복잡한 코드, 기반환경의 복잡성, 기술이나 시스템의 변경, 수많은 시스템 상호간의 연동 등의 이유로 발생할 수도 있습니다.
소프트웨어 개발, 유지보수, 운영 시 테스팅의 역할
소프트웨어는 개발이 완료되면 실제 환경에 배포를 해야 운영됩니다. 운영되는 도중에도 해당 소프트웨어를 더 이상 사용하지 않을 때까지 계속해서 유지보수를 하게 됩니다. 테스팅은 개발 시에만 필요한 것이 아니라 개발, 유지보수, 운영 시에 모두 필요합니다. 그렇다면 테스트가 언제 필요한지 살펴보겠습니다.
-) 테스팅을 통해 릴리즈 전에 발견되지 않은 결함들이 수정된다면, 운영 환경 내에서 발생하는 리스크를 줄이는데 기여할 수 있으며 소프트웨어 품질에 도움을 줍니다.
-) 테스팅은 개발 초기의 요구사항 분석 단계부터 리뷰 및 인스펙션을 통해 정적으로 이뤄질 수 있으며 각각의 개발 단계에 대응하는 테스트 레벨(test level)에 따른 테스팅이 이뤄집니다.
-) 기존에 운영되는 소프트웨어 시스템이 유지 보수 활동으로 변경 및 단종되거나 환경이 변하는 경우, 변경된 소프트웨어에 대한 테스팅과 변경된 환경에서의 운영 테스팅이 요구됩니다.
-) 소프트웨어 테스팅은 계약상(법적) 요구조건들, 또는 산업에 특화된 표준들을 만족시키기 위해서 필요합니다.
테스팅과 품질
테스팅으로 발견된 결함이 소수이거나 없을 경우에 소프트웨어의 품질에 대한 확신(Confidence)를 가지게 됩니다. 잘 설계된 테스트는 시스템의 전반적인 리스크를 감소시키고 결함을 발견합니다. 발견된 결함이 수정될 때 소프트웨어 시스템의 품질이 증가됩니다. 품질을 높이기 위해서는 이전 프로젝트를 통해 많은 테스팅 결험과 정보를 확보할 필요성이 있습니다. 다른 프로젝트에서 발견된 결함의 근본적인 원인에 대해 이애함으로써 프로세스를 개선할 수 있으며, 그러한 결함의 재발을 방지함으로써, 결과적으로 차후 시스템의 품질을 개선할 수 있게 됩니다. 개발 표준이나 교육 훈련 그리고 결함 분석 등과 함께 테스팅은 품질 보증 활동의 하나로 테스팅을 통해 소프트웨어 시스템의 품질을 확보할 수 있습니다.
테스팅은 얼마나 해야 충분한가?
테스팅이 어떤 장점들을 가지고 있는지 이해했는데요. 테스팅은 얼마나 해야 충분한 걸까요? 그냥 다다익선인 걸까요? 어느 정도 테스팅 하는 것이 적절한지를 파악하기 위해서는 다음과 같은 리스크(Risk) 수준과 프로젝트 제약사항을 고려해야합니다.
-) 기술적인 내용
-) 비즈니스 제품
-) 프로젝트 리스크
-) 시간과 비용
테스팅은 개발 프로젝트 관련자들이 테스트된 소프트웨어나 시스템의 다음 개발 단계로의 릴리즈에 대한 결정 또는 고객에게 이양(Handover)하는 릴리즈에 대한 결정을 내릴 수 있도록 충분한 정보를 제공해야 합니다.
테스팅의 일반적 원리
원리 1 - 테스팅은 결함이 존재함을 밝히는 활동이다.
{ 테스팅은 결함이 존재함을 드러내지만, 결함이 없다는 것을 증명할 수는 없습니다. 즉, 프로그램이 완벽하다고 증명할 수 없습니다. 이는 테스트 한 부분까지만 잘 동작한다고 말할 수 있고 테스트를 하지 않은 부분은 결함의 존재여부에 대해서 예측할 수 없다는 의미입니다. }
원리 2 - 완벽한 테스팅(Exhaustive testing)은 불가능하다.
{ 모든 가능성(입력과 사전 조건의 모든 조합)을 테스팅하는 것은 지극히 간단한 소프트웨어를 제외하고 가능하지 않습니다. 보통 다음과 같은 이유 때문입니다.
-) 한 프로그램 내의 내부 조건이 무수히 많음 (무한경로)
-) 입력이 가질 수 있는 모든 값의 조건이 무수히 많음 (무한 입력 값)
-) GUI 이벤트 발생 순서에 대한 조합도 무수히 많음 (무한 타이밍)
완벽한 테스팅 대신, 리스크 분석과 결정된 우선순위에 따라 테스팅 활동 노력을 집중시켜야 합니다. (Risk-based testing). 완벽한 테스팅은 우주항공, 의료 등 안전이 최우선(Safety critical)인 소프트웨어를 개발할 때 고려할 수 있으나 실제로 완벽한 것은 아니고 강력한 테스팅으로 볼 수 있습니다. }
원리 3 - 테스팅을 개발 초기에 시작한다.
{ 테스팅 활동은 소프트웨어나 시스템 개발 수명주기에서 가능한 초기에 시작되어야 하며, 설정한 테스팅 목표에 집중해야 합니다. 개발 초기에 테스팅을 시작한다는 것의 의미는 개발의 시작과 동시에 테스트를 계획하고 전략적으로 접근하는 것을 고려하는 것은 물론, 요구사항 분석서와 설계서 등의 개발 중간 산출물을 분석하여 테스트하는 것을 의미합니다. }
TDD (Test Driven Development)
테스팅이 중요하다 보니 TDD 같은 '방법론'도 존재하게 되었습니다. TDD 란 먼저 테스트 코드를 작성하고 그 다음에 프로덕션 코드를 작성하는 개발 방법론인 '테스트 주도 개발'의 약자입니다. 객체지향에서 TDD를 사용하는 이유는 다양하지만 좋은 객체 지향 설계를 갖는 시스템을 구축하기 위해서 사용합니다. 객체지향에서 테스트는 객체의 구현을 테스트하기 보다는 외부에서 접근할 수 있는 객체의 인터페이스를 테스트 하는 경우가 대부분입니다. 프로덕션 코드를 먼저 작성하는 개발 방법론은 객체의 언터페이스 보다는 내부 구현에 집중하여 개발하는 경우가 많은데 내부 구현에 집중하면서 개발하다 보면 객체 지향의 목적인 응집도 높고 결합도가 낮은 코드와 멀어지는 경우가 많이 발생합니다. TDD 를 적용해 테스트를 먼저 개발함으로써 개발자는 자연스레 객체의 내부 구현보다 객체의 인터페이스를 먼저 생각하게 되고 이는 좋은 객체 지향 설계를 가져갈 수 있는 첫 걸음이 됩니다. (응집도가 높고 결합도가 낮은 코드를 개발할 확률이 올라갑니다)
출처 : boostcourse 웹 프로그래밍(풀스택)
https://www.boostcourse.org/web316/lecture/20655?isDesc=false