[Study] CSTS 1장 - 테스트 개요

테스트의 목적

시스템이 정해진 요구 사항을 만족하는지 확인하고

주어진 표준 등을 준수하는지 검증하기 위해 수행되는데,

쉽게 이야기해서 결함검출, 품질평가, 프로세스 개선을 이야기한다.

---

결함검출 및 품질개선

단순히 결함검출을 목적으로 검출된 결함을 제거해서

소프트웨어 품질을 개선하는 것이 목표다.

---

품질평가 및 의사결정 지원

소프트웨어 및 시스템에 대한 품질을 평가하기 위해 테스트를 실시하는데,

테스트 결과를 바탕으로 성능과 신뢰성 및 보안성 등의

다양한 소프트웨어 품질 특성에 대한 충족 수준을 평가 및 품질 평가를 바탕으로

소프트웨어 제품에 대한 의사결정을 수행한다.

---

개발 프로세스 개선 지원

어떠한 소프트웨어 및 시스템 개발 과정 중 어떠한 단계에서 결함이 발생하는지 분석 후

결함 검출이 왜 되지 않았는지 파악해 개발 프로세스 개선을 돕는다.

ex)

검출된 결함 중에서 요구 사항 관련 결함이 많다면,

요구분석 단계의 프로세스 개선이 필요하고,

요구분석 단계에서의 결함 검출 방법도 개선할 필요가 있다.

---

오류, 결함, 장애

소프트웨어 요구사항

소프트웨어 개발 시 약속된

소프트웨어의 동작에 대한 기준이 주어지는데,

이 동작의 기준을 정의한 것을 말한다.

ex)

"차량에 설치된 AV 시스템이라면, USB가 삽입되었을 때,

삽입된 USB에 포함된 오디오 또는 비디오가 재생되어야 한다."라는

소프트웨어 요구사항이 있을 수 있고, 만약에 소프트웨어가 요구사항과 다르게 동작을 했다... 라면

이를 장애(Failure)가 발생했다고 한다.

장애(Failure)

프로그램 실행 결과와 요구사항에 명시된 결과에

관찰이 가능한 차이가 있음을 의미하는 것을 말한다.

 

결함(Defect)

소프트웨어 내에 장애를 유발할 수 있는 문제 말한다.

결함 때문에 보통 장애가 발생하지만 결함이 있다고 해서

무조건 장애가 발생한다는 건 아니라는 점 기억해야 한다.

 

오류(Error)

위에서 언급된 결함이 생기게 한 개발자의 행위를 말한다.

사용자의 요구 사항을 잘못 파악 및 이해해서 발생하는

실수, 오타(typo)나 프로그램 명령어를 잘못 이해해서

코딩하는 경우가 이에 해당하는 것을 기억해야 한다.

---

결함 유형

효과적, 효율적으로 결함을 검출하려면

어떤 종류의 결함이 있는지 먼저 이해해야 한다.

결함의 구현을 세가지로 분류한 개념

---

누락(Omission)

요구 명세에 명시된 요구사항이

시스템 구현에 반영되지 않은 결함을 말한다.

쉽게 말해서 말 그대로 요구가 누락된 것을 말한다.

ex)

"특정 입력에 대해 A를 출력하라"라고

명세에 명시되어 있는데

구현되지 않았다면 이는 누락에 해당

 

누락 결함에는 기능, 성능, 보안, 안전, 신뢰도 등

품질 요소에 관한 누락도 포함된다.

부정확한(Incorrect)

정확하지 않은 결함을 뜻한다.

ex)

"특정 입력에 대해 A를 출력하라" 라고

명세에 명시되어 있는데

B가 출력되는 경우가 이에 해당

 

이 또한 기능, 성능, 보안, 안전, 신뢰도 등

품질 요소에 관한 부정확한

구현도 포함된다.

비관련 (Extraneous)

요구 명세와 관련되지 않은 구현을 말한다.

ex)

소스나 코드에서 어떤 부분이

요구 명세에 언급된 기능,

품질 등과 무관하면 비관련 결함에 해당

 

비관련 결함은 당장 직접적인 장애를

유발하지 않을 수 있지만,

기능, 품질에 기여하지 않는

무의미한 코드가 있다면

불필요한 분석, 테스트, 관리의 노력을 유발하고

나아가 다른 결함을 초래할 수 있다.

---

개발 단계별 결함

모든 개발 산출물에는 결함이 존재할 수 있다.

ex)

소스 코드를 구현하는 단계가 아닌

설계 명세서의 부정확한 알고리즘에 기인한 것일 수도 있으니

이 같은 경우는 "설계의 결함"이라고 볼 수 있다.

결함 발생 단계

결함 발생 시 해당하는 단계에서

적절히 검출해서 제거하지 않는다면,

소스 코드에 영향을 미치게 되어

장애를 유발

---

요구분석 단계에서의 결함 해결 비용

결함 해결 비용

결함 해결 비용을 보면

0.1에서 0.2 단계보다

유지 보수 쪽에서

결함을 해결해야 하는

비용이 더 크다는 것을 알 수 있다.

---

테스팅, 디버깅, 재테스팅

 결함 및 테스팅과 관련된 용어로 디버깅이 있다.

결함의 존재 여부를 확신할 수 없는 어떠한 것을

테스트를 통해 결함의 존재를 확인하는데,

위치나 원인을 알 수 없기에 디버깅을 진행해서

결함의 위치나 원인을 파악하고,

결함을 제거하기까지의 순으로 차이점을 알아볼 수 있다.

디버깅 (테스팅과는 다른 개념)

 

테스팅

소프트웨어 실제 동작 및 요구 사항의 차이를 확인한다.

동적 테스트는 결함 존재 여부를 알 수 없는 상황에서 결함의 발견을 목적으로 프로그램을 실행한다.

쉽게 이야기해서 장애 발생을 확인해서 소프트웨어에 결함이 있음을 간접적으로 판단하는 것을 이야기한다.

 

테스팅의 결과

결함을 검출한 테스트 케이스와

테스트 환경을 말한다.

 

쉽게 말해서,

어떤 환경에서 어떤 값을 사용했을 때

예상되는 결과와

실제 출력 결과 등을 기록하는데,

이게 어떤 모듈에서 발생했고

이것을 해결하기 위해서

소스 코드를 어떻게 수정해야

하는 것까지는 관여하지 않는다는 것이다.

테스팅 → 결함확인

 

디버깅

테스팅을 통해 결함을 확인 후에 수행된다.

결함 위치를 파악 및 제거하는 것이 목적이다.

일반적으로 결함을 검출한 입력값을 이용해 소프트웨어를 동작시킬 때

실행된 소스 코드에 결함이 존재한다.

결함 위치를 알아내면 그 결함을 제거하기 위해 소스코드를 수정해야 한다.

테스팅 → 결함확인 → 결함 위치 파악 → 결함 제거

 

 

재테스팅

 초기에 결함 검출 테스트 케이스를 이용해서 테스팅을 다시하는 것을 말한다.

---

테스트 | 현실/실제

완벽한 테스트의 비현실성

테스트를 통해 결함을 검출하려면 많은 테스트 케이스가 필요하다.

ex)

워드의 경우 워드가 글꼴을 지정한 대로 보여주는지 확인하려면,

모든 글꼴, 스타일, 크기, 색, 효과 등 이런 것들을 상호 조합을 고려해서

테스트를 해야 하는 것인데...

 

현실적으로 모든 조합을 테스트하는 것은 불가능하다.

 

(현실적) 낚시의 비유

일정 시간 동안(평생 낚시만 할 수 없으니 가져온 미끼를 다 사용하는 동안)

저수지에서 낚시를 할 때 물고기가 계속 안 잡힐 수 있는 것이다. 

실력이 부족해서 안잡힐 수 있다? 이렇게 단정 지을 수 없다.

그렇게 말하기 위해서는 물을 전부 없애고물고기가 있는지 없는지 

살펴보아야 하는 것이다.

 

이는 현실적으로 불가능한 이야기다.

 

위에서 낚시에서 사용되는 미끼를 테스트 데이터,

저수지의 물고기를 프로그램의 결함라고 생각해보자,

 

이처럼 프로그램의 테스트 기술의 한계를 다익스트라(Dijkstra)라고 표현한다.

다익스트라(Dijkstra)

기술의 한계를 이야기한다.

 

 

프로그램 테스트는 결함이 있음을 보일 수는 있지만, 결함이 없음을 보일 수는 없다.

 

따라서 주어진 인력과 시간을 바탕으로 최대한의 효과적, 효율적인 테스트를

수행할 수 있도록 체계적인 테스트가 수행되어야 한다.

 

동적 테스트 : 실행하는 방식으로 테스트를 수행하는 것을 말한다.

 

효과적, 효율적 테스트는 중요한 이슈다.

동적테스트의 경우 이러한 테스트의 한계를 충분히 고려해서

동등분할, 경곗값 분석, 조합 테스트 등의 다양한 방법이 존재한다.

 

위험 기반 테스트 방법을 적용할 수도 있는데,

테스트 대상에서 테스트할 각각의 특성에 대한 위험 분석을 바탕으로 테스트할 범위를 선정하고,

이에 따라 테스트 전략을 수립해서 한정된 비용과 일정 내에서 테스트 효과를 최대화할 수 있다.

---

테스트 진화 과정

[겔퍼린, 헤첼]

소프트웨어 테스트 개념 진화 과정의 5Lv

 

Lv1

우연히 발견된 결함을 수정하는 디버깅에 중점을 둔다.

 

Lv2

프로그램 작동 사실 입증을 위한 테스트를 수행한다.

결함을 찾을 확률이 높은 테스트 케이스를 설계하기보다

시스템의 정상작동을 증명하는데 초점이 맞추어져 있다.

 

Lv3

프로그램 결함이 존재한다는 것을 보여주기 위한 테스트를 수행한다.

프로그램이 작동하지 않는다는 사실을 보여주려는 의도로 테스트 케이스를 설계한다.

 

Lv4

Lv3 에 확장된 테스트로 소프트웨어 개발 전 단계에서 발생하는

결함을 발견한다는 개념으로 확장된 테스트다

코딩이 완료된 후 테스트를 시작하는 게 아닌 개발 초기 단계부터 지속적으로 리뷰 등을 통해

시스템을 평가하는 작업을 이야기하는 것이다.

 

Lv5

아예 결함이 발생하지 않도록 사전에 방지하는 것이 목적이다.

프로그램을 개발할 때 처음부터 테스트가 용이하도록 시스템을 설계해야 한다는 개념을 추구하고,

결함을 미연에 방지하기 위한 가장 효과적인 방법은 테스트케이스를 미리 설계하는 것이다.

---

테스트 원칙

G. J. 마이어스(G. J Myers) 등은 "The Art of Software Testing"에서

기본적으로 테스트를 수행할 때 따라야 할 원칙을 소개했는데

테스트는 반드시 프로그램을 개발한 프로그래머나 팀과는 무관한 그룹이 수행해야 한다.

 

사람 심리 상 자신이 작성한 프로그램에 대해서 방어적 경향을 띄우기 때문에

자신이 담당한 부분의 요구사항을 제대로 해석하지 못했을 가능성이 있어

테스트를 철저히 수행하더라도 결함을 발견하지 못할 가능성이 크다는 것.

 

결함이 발견되지 않다는 가정하에 테스트 계획을 수립해서는 안 된다.

 

테스트는 프로그램이 올바르게 동작하는 것을 보여주는 게 아니라

결함을 발견하려는 의도의 과정이기 때문이다.

 

타당한 경우뿐만 아닌, 예상치 못한 경우에 대해서도 테스트를 수행하라.

일반적으로 프로그램을 작성할 때 타당한 조건을 만족하는 입력만 고려해서 테스트하는 경향이 있는데

예상치 못한 방식으로 사용되는 경우에 많은 결함이 발생한다.

 

프로그램의 어떤 부분에 결함이 남아 있을 확률은 그 부분에서 이미 발견된 결함의 수에 비례한다.
프로그램의 결함의 80%는 20%의 모듈에서 발생한다.

결함이 많이 발생한 부분에 테스트 노력을 집중하는 편이 효과적이다. 

테스트 케이스를 체계적으로 관리하라.

 

테스트 케이스 설게는 시간 및 노력이 많이 투입되는 작업이다.

올바르게 프로그램이 수정되었는지, 수정으로 인해 기존 기능이 영향을 받았는지 다시 테스트해야 한다.

이에 새 테스트 케이스를 만들려면 많은 작업량이 필요하여 기존 테스트 케이스를 재사용해 테스트하는 것이 바람직하다.

각각의 테스트 결과를 철저하게 점검하라.

 

주의 깊게 각 테스트 결과를 점검하여 결함의 발견 확률을 높일 수 있다.

---

테스트와 품질 평가

품질 평가는 테스트 목적 중 하나이다.

 

ISO 25010에서의 주특징

주특성	설명
기능 적합성	요구된 기능을 만족시키는 능력을 말한다.
성능 효율성	적절한 자원 사용 및 적정 반응시간 정도를 말한다.
호환성	타 시스템과 상호 연동 능력을 말한다.
사용성	사용자 이해 난이도를 말한다.
신뢰성	규정된 기간 동안 오작동 없이 의도된 기능을 수행하는 소프트웨어의 능력을 말한다.
보안성	정보 및 데이터를 보호하는 능력을 말한다.
유지보수성	소프트웨어 유지보수의 용이성을 말한다.
이식성	다양한 플랫폼에서 운영될 수 있는 소프트웨어의 능력을 말한다.

 

대표적인 요구사항 명세

기능 요구사항, 품질요구 사항을 포함한다.

소프트웨어 = 기능적 동작 뿐 아닌 성능, 호환, 사용성 등의 품질 특성에 대한 요구를 충족해야 한다.

 

기능(Functional) 테스트

테스트를 수행할 때에는 기능적 측면에 더해 비기능적 측면의 결함을 검출해야 한다.

이때 기능 요구사항에 중점을 둔 테스트이다.

 

비기능(Non-Functional) 테스트

품질 요구사항에 초점을 둔 테스트이다.

 

유형 테스트

성능을 확인하기 위해 보안 테스트를 수행하듯,

각 품질 특성별로 수행되는 테스트를 말한다.

유형 테스트 = 성능, 보안, 신뢰성 테스트등의 테스트를 부르는 용어다.

---

테스트와 품질 보증

3가지 용어의 포함관계 (품질보증, V&V, 테스트 개념)

 

V&V

Verification(검증)과 Velidation(확인)의 약어이며,

품질 보증을 위한 핵심개념이다.

 

Verification(검증)

개발 과정에서 수행한 활동 적합성 검사에 초점을 둔다.

 

Velidation(확인)

결과물의 적합성에 초점을 둔다.

ex)

요구 분석 단계 결과물인 요구 사항 명세서가

구조 설계 및 상세 설계의 결과물에 적절하게 반영되었는지

조사하는 추적성 확인은 검증에 해당한다.

반면,

동작하는 소프트웨어가 주어진 요구사항을 중족 하는지

확인하는 것은 Velidation(확인)에 해당한다.

V&V의 다양한 수행 방법

IEEE Std. 1012-2012

요구 분석, 설계, 구현 당계등 개발 단계별로 적용할 수 있는 V&V 방법을 제시한다.

ex)

요구 분석 단계에 적용할 수 있는 V&V 방법

요구 사항 평가, 인터페이스 분서, 추적성 분석, 심각성 분석 등이 있다.

ISO/IEC/IEEE 29119-1의 부록

테스트를 포함한 V&V 활동의 분류를 소개한다. (아래 그림 참고)

V&V 활동 분류

V&V

정형방법, 테스팅, 그리고 V&V 분석으로 분류된다.

 

정형방법

모델체킹과 정확성 증명이 있다.

 

테스팅

동적, 정적 테스팅으로 분류된다.

 

V&V 분석의 유형

시뮬레이션과 평가가 있다.

 

(소프트웨어 생명주기 프로세스에 대한 표준)

ISO/IEC 12207:2017에서의 품질 보증

"의도한 목적에 적합한 품질의 소프트웨어 제품을 개발하였는가?"

"그러한 소프트웨어 프로세스가 적합한가?" 에 대한 확신을 주기 위해 수행되는

다양한 활동이라고 정의하고 이다.

 

규칙, 규제, 법규 등을 포함한 이해관계자의 요구 사항을 바탕으로

프로세스와 시스템, 소프트웨어 개발 측면에 대한 모든 것을 포함한다.

프로세스 요구사항과 시스템 요구사항이

이해관계자 요구사항과 부합하는지

소프트웨어 요구 사항이 시스템 요구 사항에 부하하는지

프로세스 표준 및 절차가 프로세스 요구사항에 부합하는지

프로세스 활동의 수행이 프로세스 표준 및 절차에 부합하는지

소프트웨어가 소프트웨어 요구사항에 부합하는지 등을 확인한다.

---

테스트 기본 용어

테스트 기본 용어 (동적 테스트를 수행할 때 반드시 이해해야 할 기본 용어)

---

테스트 대상과 테스트 라벨

테스트 대상

테스트를 통해 결함을 검출하려는 대상 소프트웨어를 말한다.

시스템 구성의 전체 소프트웨어가 테스트 대상이 될 수 있고,

전체 소프트웨어의 일부분이 대상이 될 수 있다.

전체 시스템의 일부분을 먼저 테스트한 후에 각 부분을 통합해서 전체를 대상으로 테스트를 수행하는 것이 효과적이다.

 

시스템 테스트

전체 소프트웨어 대상으로 한 테스트

 

컴포넌트 테스트 or 단위 테스트

부분 대상으로 한 테스트

 

통합 테스트

시스템을 구성하는 각 부분의 연결에 초점을 둔 테스트

 

레벨 테스트

테스트 대상에 따라 수행되는 컴포넌트 테스트, 통합 테스트, 시스템 테스트 등을 통칭한다. 

시스템 테스트를 수행할 때 테스트 대상 = 전체 소프트웨어
컴포넌트, 단위 테스트를 수행할 때 테스트 대상 = 시스템의 부분

---

피처와 테스트 유형

피처(Feature)

테스트 대상 특성 중 테스트하고자 하는 측면, 관점을 뜻한다.

ex 1)

차량을 태상으로 테스트를 수행한다 가정해보자,

차량 결함을 검출하려 차량의 다양한 관점, 측면이 조사되어야 한다는 것.

 

ex 2)

주행 시험 관점에서는 정상 노면과 눈, 비에 젖은 노면에서 운전대가 향하는 바향으로,

가속 페달을 누르는 강도에 따라 차량이 주행하는지 테스트하고,

제동 시험 관점에서는 제동 장치를 구동하면

약속된 거리 이내에서 차량이 멈추는가? 테스트를 할 수 있다.

 

다양한 측면, 관점의 소프트웨어에 대한 요구

요구 분석 단계를 거쳐 요구 사항 명세서에 기록된다.

요구사항 명세서에 성능 요구사항이 명시되었다면,
성능 테스트를 수행해야 하고 보안 요구사항이 명시되었으면, 보안 테스트를 수행해야 한다.

 

피저에 따른 테스트 유형

대강 보면

1번에서는 기능 테스트를 요구하고,

2번에서는 품질 테스트를 요구하는 것을 볼 수 있다.

 

픽처는 테스트 계획을 수립할 때 식별되어 테스트 범위로 기술된다.

테스트 설계 활동을 통해서 피처가 구체화되며,

이를 기준으로 테스트 케이스 및 테스트 절차가 개발된다.

---

테스트 설계 기법

테스트 대상 결함을 효과적, 효율적으로 검출하기 위한 것으로

정적 테스트를 수행하기 위한 기법과 동적 테스트를 수행하기 위한 기법으로 분류된다.

---

정적 테스트

테스트 대상을 실행하지 않고 테스트를 수행하는 방식이다.

두 개의 방법이 있는데, 리뷰의 방법과 정적분석의 방법이 있다.

 

리뷰

각 개발 단계별로 해당 단계의 산출물이 품질 목표에 부합하는지 점검하거나

산출물에 존재하는 결함을 검출하려는 목적으로,

산출물을 실행하지 않고 검사하는 방법이다.

 

정적분석

소스 코드를 대상으로 결함으로 판단할 수 있는 특정 패턴이 소스코드에 있는지 분석한다.

예시로 변수 초기화하지 않고 그 값에 접근하려 하는 패턴은 소프트웨어의 결함이라 볼 수 있다.

즉, 소스 코드를 분석해서 초기화 하지 않고 사용되는 변수를 파악함으로써 결함을 검출한다.

 

정적 테스트의 장점

테스트 대상을 실행하지 않기 때문에 실행환경을 필요로 하지 않는다는 점

소스코드가 작성되기 전 개발, 요구분석, 구조설계, 상세설계 단계 등에서

산출물에 대한 테스트를 수행할 수 있다는 점이 있어 경제적이다. 

자동화된 도구를 이용해 대규모 소스 코드 분석이 가능하기에 사용이 증가하는 추세이며,

MISRA C, MISRA C++, JSF AV C++ 등은 자동차, 항공기를 포함해서

안전이 중요시되는 소프트웨어 개발에 필수로 요구되어 자동화된 도구의 사용이 일반적이다.

 

정적 테스트의 단점

자동화 도구가 결함이 아닌 문제를 결함으로 보고하는 오검지(False positive)의 단점이 있고,

오검지(False positive) 비율이 높아지게 되면 개발자가 도구의 테스트 결과 자체를 신뢰하지 않는 부작용이 발생할 수 있다.

---

동적 테스트

소프트웨어를 실행하는 방식으로 결함을 검출한다.

실행 가능한 소프트웨어가 필요하고, 소스코드는 사용되지 않는다.

소스 코드가 없는 경우에도 수행할 수 있다는 특징이 있다.

 

요구사항

어떠한 입력에 대한 기대 결과를 명시하고,

소프트웨어를 실행해서 해당 입력을 넣었을 때

요구사항의 기대 결과와 다른 결과가 발생하는 경우

소프트웨어에 결함이 있다고 판단할 수 있다.

---

동적 테스트를 수행하는 방법

명세 기반 방법

프로그램 내부 논리 구조를 참조하지 않고,

사용자 요구 및 명세나 설계 정보 등을 이용해 테스트 케이스를 개발한다.

대상 시스템의 명세 정보를 얻을 수 있는 한 적용 대상에 제한이 없고,

컴포넌트, 통합, 시스템 테스트 및 인수 테스트 등 전 과정에 걸쳐 사용될 수 있다.

 

구조 기반 방법

프로그램 제어 흐름 및 자료 흐름 정보를 이용해 테스트 케이스를 설계하는 방법이다.

프로그램 내부 구조 정보를 기반으로 테스트 케이스를 설계한다는 측면에서

구조적 테스트, "화이트박스 테스트" 또는 "글래스 박스 테스트"라고도 한다.

 

경험 기반 테스트

테스트 케이스 설계를 바탕으로 테스트를 수행하지 않고 도메인에 대한 테스터의 경험,

기존 테스트 결과, 테스터의 직관을 주로 활용하여 테스트를 수행한다.

경험 기반 테스트의 대표적 방법으로 오류추정과 탐색적 테스트가 있다.

 

동적 테스트의 장점

소스 코드가 없어도 수행이 가능하다.

 

동적 테스트의 단점

소프트웨어 실행시키기 위한 환경이 요구되며,

일부 요구 사항은 정적 테스트로 확인 하기 어려운 경우가 있다는 단점이 있다.

소프트웨어의 품질 요구사항인 가용성, 확장성, 신뢰성 등도 동적 테스트를 통해서 확인이 가능하다.

---

테스트 케이스

입력과 대응되는 예상 결과를 묶어서 일반적으로 "테스트 케이스"라고 부른다.

 

실제 테스트 케이스

입력 값 뿐 아닌, 입력값을 테스트 대상에 제공하는 방법

그리고

예상 결과와 실제 결과를 비교하는 방법도 포함된다.

 

동적 테스트를 수행할 때

테스트 대상을 실행하기 위해 적절한 입력값을 주어야한다.

 

테스트의 목적이 결함 검출임을 전제로 하면,

결함의 검출 가능성이 큰 입력값을 결정해야 한다는 점을 알아야한다.

특정 입력 값으로 테스트 대상을 실행 했을 때 기대되는 값도 결정해야 한다.

 

테스트 대상을 실행 했을 때 기대되는 값을 결정해야 하는 이유

실제 출력이 예상 기댓값과 다른 경우 테스트 대상은 결함을 가지고 있다고 간주할 수 있기 때문이다.

...

입력값에 대응되는 기대되는 예상값이 항상 결정되어야한다.

---

테스트 절차

준비, 실행, 결과 관찰, 기록의 절차를 정의한것이다.

 

테스트를 수행하기 위해서는 환경이 구축되어야 하고,

준비된 테스트 케이스의 입력값을 실제 테스트 대상에 입력 해서

테스트 대상을 실행해야 한다는점, 테스트 대상의 동작을 관찰해서

실제 수행 결과를 추출하고 이를 테스트 케이스의 예상결과와 비교해야한다.

테스트를 보다 객관적이고 효율적으로 수행하기 위해

이러한 과정을 명시적으로 정의하고 기록할 필요가 있다.

 

테스트 절차가 명확하게 정의 되지 않고 문서화 되지 않은 경우

테스트를 수행 시 다른 결과가 나올 위험이 있다.

 

테스트에서 결함이 발견되었을 때

디버깅을 하기 위해 동일 한 결함이 나오는 상황을 재연해야 한다.

 

테스트 실행

테스트 절차에 따라수행된다.

 

테스트 절차

검출된 결함을 재연할 때도 사용된다.

 

결함의 재연이 가능하도록 테스트 절차를 구체적,

명확하게 기술하여 해당 결함을 제거(디버깅)하는 데 도움이 된다.

 

스크립트

테스트 절차를 문서로기록하는 대신 자동화 도구가 해석하고

실행하는 언어로 작성한 것을 말한다.

 

테스트 환경

테스트 대상을 실행하는 모든 환경으로 하드웨어, 운영 체제를 포함하는 시스템 소프트웨어,

외부 연동 시스템, 공존하는 응용 소프트웨어, 테스트 도구 등을 포함한다.

ex)

네비게이션 소프트웨어를 테스트 하려면

네비게이션 소프트웨어를 작동시킬 하드웨어와

운영체제 GPS 등을 포함한 장치가 필요한것을 예로 들수 있다.

컴포넌트, 단위 테스트의 경우

테스트 대상이 소프트웨어 전체가 아닌 일부분인데,

컴포넌트 자체가 독립적으로 실행이 되지 않기 때문에

사용자, 환경으로 부터 입력을 대상 컴포넌트에 전달 하기 위한 다른 모듈이 필요할 수 있고,

테스트 대상 컴포넌트가 다른 컴포넌트를 이용 하거나 호출 하면 피호출 컴포넌트가 필요하다.

이러한 목적으로 "드라이버"와 "스텁"이 사용되고, 이 또한 테스트 환경에 해당된다.

테스트 실행 시 사용될 수 있는 다양한 테스트 도구도 테스트 환경으로 간주된다.

ex)

테스트 절차를 자동으로 실행, 테스트 실행 결과를 추출,

테스트 실행 결과의 예상 결과를 비교하는 도구들도 테스트 환경에 포함된다는 것이다.

시스템이 동작하는 실제환경과 최대한 유사한 환경에서 테스트를 수행하는것이 중요하다.

테스트 환경과 실제 동작 환경의 차이가 클수록 테스트를 통해 검증되었던

테스트 케이스가 실패할 가능성이 커지기 때문이다.

 

테스트 커버리지

테스트가 테스트 요구 사항을 얼마나 만족하는지 나타내는 용어이며,

"테스팅 정도에 대한 양적평가"를 결정하는 것이다.

이를 근거로 테스트를 얼마나 더 해야할 지 멈추어야 할지 결정한다.