이 책은 프로그램이 실행될 때 일어나는 내부 동작원리를 익혀 더욱 효율적인 프로그래밍이 가능하도록 방향을 제시하였다. 특히 한권으로 CPU의 구조부터 OS 내부 동작원리까지, 프로그래밍의 가장 깊은 곳의 원리부터 상위 원리까지 순차적으로 학습할 수 있도록 했다. C에 대해서는 어느 정도 기초 지식이 있는 독자층을 주로 염두에 두고 쓰여진 책이다. 따라서 단순히 문법만 터득하여 기능적으로 구현하는 프로그램이 아니라 동작의 본질을 이해하고 프로그램을 제작할 수 있도록 하였다.
크게 세 3파트로 구성되어진 이 책에서는 CPU와 고급언어에 대해, 마지막 장에서는 운영체제의 역할과 그 구성에 대해 설명해 두었다. 이론과 실전의 연결이 가능하도록 교차되는 내용을 싣고자 노력하였다.
저자 : 한세경
한양대학교 전기컴퓨터 공학부를 졸업하고, 서울대학교 전기공학부에서 제어 및 임베디드 시스템을 전공하여 현재 SK(주) 기술원에서 근무하고 있다.
학부 1학년 때부터 삼성 소프트웨어 멤버쉽 활동을 시작한 이후 각 IT분야에서 다양한 개발 경험을 축적하였으며 4개국어에 능통할 정도로 자기 개발에 철저하다. 또한 현재 레이스 선수로 활동하는 열혈 바이크 매니아이다
목차
Part1. CPU와 친해지기 - 누구나 알기 쉬운 CPU의 구조
1장. 0과 1의 세상
2장. 논리회로
3장. 조합 및 순차 논리회로
4장. 컴퓨터의 두뇌 - CPU
5장. CPU의 필수 도구 - 레지스터와 클럭
6장. CPU의 언어 - 인스트럭션
7장. 실전 인스트럭션 셋 - MIPS
8장. 실전 CPU 설계 - MIPS의 데이터 경로
9장. 쉴틈없이 일하라 - 파이프라이닝
Part2. 인간의 말을 배운 컴퓨터 - 아무도 알려주지 않는 C의 비밀
10장. 컴파일러의 등장
11장. 변수의 정체
12장. 메모리 나누기 - 코드, 데이터, 스택, 힙
13장. 함수가 호출되기까지
Part3. 프로그램의 정부 - 운영체제(OS)
14장. OS의 정체
15. OS와 친해지기 - 핵심 OS 요소
16. OS 속 들여다 보기 - OS의 내부 동작 원리
4.1 Identifying test conditions and designing test cases
테스트 조건(test conditions)과 테스트를 설계하는 것은 여러 단계로 구성된다.
• 테스트 조건을 정의함으로써 테스트를 설계하는 것 • 테스트 케이스를 명세하는 것 • 테스트 절차 (test procedure)를 명세하는 것
프로세스는 문서가 거의 없는 매우 비형식적인 것에서 부터 매우 형식적인 것까지(이것은 다음 섹션에서 설명될 것이다.) 여러가지 방법으로 수행될 수 있다. 형식성의 레벨은 다음과 같은 테스팅 내용에 따라 다르다. - 테스팅 조 직, 테스팅과 개발 프로세스의 성숙도(maturity), 시간 제약, 관련된 사람들
테스트 설계(test design) 동안에, 테스트 조건을 정의하는 것과 같이 무엇을 테스트 할지 결정하기 위하여, 테스트 기반이 되는 문서들을 분석한다. 테스트 조건은 하나 또는 그 이상의 테스트 케이스로 검증될 수 있는 항목(item)이나 이벤트로서 정의된다.(e.g 기능, 트랜잭션, 품질 특성 또는 구조 적인 요소)
테스트 조건에서 역으로 명세와 요구사항으로 추적성(traceability)을 만드는 것은 요구사항이 변경되었을 경우의 영향 분석과 과 테스트 셋에 대하여 결정되어야 하는 요구사항 커버리지 분석을 모두 가능하게 한다. 테스트 설계 동안에 ,상세한 테스트 기법은 여러가지 고려 사항 가운데 정의된 위험에 기반하여 구현된다.
테스트 케이스 명세 동안에, 테스트 설계 기법에 의하여 테스트 케이스 들과 테스트 데이터가 개발되고 상세하게 서술된다. 테스트 케이스는 입력 값의 집합(set of input values), 실행 선행조건(execution preconditions), 예상 결과(expected results) 그리고 실행 후조건(execution post-conditions)으로 구성되며, 어떤 테스트 조건(들)을 커버하기 위하여 개발된다. "소프트웨어 테스트 문서화를 위한 표준"(Standard for Software Test Documentation) (IEEE 829)는 테스트 디자인 명세와 테스트 케이스 명세의 내용을 설명한다.
예상결과는 반드시 테스트 케이스 명세의 일부분으로 제공되어야 하며 , 출력, 테이터와 상태의 변경사항, 그리고 테스트의 또다른 결과를 포함하여햐 한다. 만약 에상 결과가 정의되지 않는다면, 그럴듯해 보이지만 잘못된 결과가 올 바른 것으로 판단 될 수 있다.
테스트 케이스는 실행가능한 순서로 작성된다.; 이것이 테스트 절차(test procedure) 명세이다. 테스트 절차(또는 수동 테스트 스크립트) 명세는 테스트 실행에 대한 액션의 시퀀스를 명세한다. 만약 테스트가 테스트 실행 도구를 이용하여 실행된다면, 액션의 시퀀스는 테스트 스크립트(이것은 자동화된 테스트 절차이다.)안에 명세 된다.
테스트 절차나 스크립트가 누눈가에 의하여 수행될 때, 다양한 테스트 절차들과 자동화된 테스트 스크립들은 테스트 절차나 자동화된 테스트 스크립트의 순서를 정의하는 테스트 실행 스케줄을 구성한다. 테스트 실행 스케쥴은 회귀 테스트(regression test), 우선 순위화(prioritization), 그리고 기술적이고 논리적인 의존관계(dependencies)와 같은 요소들을 고려해야 한다.
4.2 Categories of test design techniques (K2)
테스트 설계 기법의 목적은 테스트 조건(test conditions)과 테스트 케이스(test cases)를 정의하는 것이다.
테스트 기법의 고전적인 분류 방법은 블랙 박스 테스트와 화이트 박스 테스트로 표기하는 것이다. 블랙 박스 기법(명세 기반 기법으로도 불린다)은 컴포넌트나 시스템에 대하여 내부적인 구조에 대한 참조없이, 기능과 비기능 모두 테스트 기반 문서의 분석에 기반하여, 테스트 조건과 테스트 케이스를 유도하고 선택하는 방법이다. 화이트 박스 기법(구조적 혹은 구조 기반 기법으로 불린다.)은 컴포넌트나 시스템의 내부적인 구조의 분석에 기반한 방법이다.
대부분의 기법들은 명확하게 하나의 범위에 속한다. 나머지들은 하나 이상의 범주 요소를 갖는다. 이 요약서에서는 블랙 박스 기법으로는 명세 기반이나 경험 기반 접근 방식을 말하며, 화이트 박스 기법으로는 구조 기반 방식을 말한다.
명세 기반 기법(Specification-based techniques)의 일반적인 특징은 다음과 같다.
• 소프트웨어나 소프트웨어 컴포넌트의 모델들은, 형식적이건 비형식적이건 모두 풀어야 할 문제의 명세를 위해 사용된다. • 이러한 모델로 부터 테스트 케이스들은 체계적으로 유도될 수 있다.
구조 기반 기법(Structure-based techniques)의 일반적인 특징은 다음과 같다.
• 소프트웨어가 어떻게 구성되었는가에 대한 정보, 예를 들어 코드와 디자인은 테스트 케이스들을 유도하는데 사용된다. • 소프트웨어 커버리지 범위는 존재하는 테스트 케이스로 측정할 수 있다. 커버리지를 증가시키기 위해서 더 많은 테스트 케이스들이 규칙적으로 유도될 수 있다.
경험 기반 기법(Experience-based techniques)의 일반적인 특징은 다음과 같다.
• 경험과 지식이 있는 사람들이 테스트 케이스를 추출한다. - 테스터, 개발자, 사용자와 여러 이해 당사자(stakeholders)의 소프트웨어, 소프트웨어의 사용과 환경에 대한 지식 - 있음직한 결함(defect)과 분포에 대한 지식
▪ 명세기반 기법 - 일반적으로 공식적/비공식적 모델이 명세화를 위해 사용됨 - 테스트 케이스를 모델로부터 체계적으로 도출 - 문서기반
- Equivalence Partitioning, Boundary value analysis, Decision table testing, State transition testting, Use case testing
▪ 구조기반 기법 - SW 코드나 설계 등 구조를 보여주는 정보로부터 테스트 케이스 도출 - 소프트웨어의 커버리지 정도가 기존 테스트 케이스로부터 측정되고 커버리지를 늘리기 위하여 추가적 테스트 케이스가 체계적으로 도출
▪ 경험기반 기법 - 테스터, 개발자, 사용자 등의 지식활용 - 발생가능한 결함과 그 분포 등에 대한 지식 - 문서화 필요
4.3 Specification-based or black-box techniques
4.3.1 동등 분할 (Equivalence partitioning) (K3)
소프트웨어나 시스템의 입력은 비슷한 행위를 가지는 그룹으로 나뉘어지며 같은 그룹에 속하는 입력들은 같은 방법으로 처리 된다. 동등 분할(또는 분류)은 유효한 데이터와 유효하지 않은 데이터, 예를 들어 거부되어야 하는 값들에서 발견 될 수 있다. 분할(partitions)들은 결과, 내부적인 값들, 시간에 관련된 값들(e.g 이벤트 전후의), 그리고 인터페이스 파라미터(e.g 통합 테스팅 동안의)에 대하여도 정의된다. 테스트는 분할들을 커버할 수 있도록 설계되어야 한다. 동등 분할(EP)은 모든 레벨의 테스팅에 적용이 가능하다.
기법으로써의 동등 분할은 입력과 출력 커버리지를 얻기 위하여 사용될 수 있다. 이것은 사람을 통한 입력, 인터페이스를 통한 시스템에 대한 입력, 또는 통합 테스팅에서의 인터페이스 파라미터들에 적용될 수 있다.
4.3.2 경계값 분석 (Boundary value analysis) (K3)
각각의 동등분할의 경계에서의 행위는 더욱 잘못될 경우가 많다. 따라서 경계(boundaries)들은 결함(defect)을 포함할 것 확률이 높은 테스팅 영역이다. 분할 부분의 최대값과 최소값이 분할된 부분의 경계값이다. 유효한 분할 부분의 경계값은 유효한 경계값이다. 마찬가지로 유효하지 않은 분할 부분의 경계값은 유효하지 않은 경계값이다. 테스트는 유효한 경계값과 유효하지 않은 경계값 모두를 커버하도록 설계될 수 있다. 테스트 케이스를 설계할 때, 각각의 경계에 대한 값이 선택되어야 한다.
경계값 분석은 모든 단계의 테스트에 적용될 수 있다. 이것은 일반적으로 적용하기 쉬우며, 결함(defect)를 발견하는 능력이 높다.; 자세한 명세는 도움이 된다.
이 기법은 종종 동등 분할의 확장으로 간주된다. 그리고 인간에 의한 입력은 물론, 시간이나 테이블 경계들에 대한 입력에도 사용될 수 있다. 또한 경계값은 테스트 데이터 선택을 위하여 사용될 수도 있다.
4.3.3 의사결정 테이블 (Decision table testing) (K3)
의사결정 테이블(decision table)은 논리적인 조건을 포함하고 있는 시스템의 요구사항을 찾아내고, 내부적인 시스템의 설계를 문서화하는 좋은 방법이다. 의사결정 테이블들은 시스템이 구현해야 하는 복잡한 업무규칙(bisiness rule)을 기록하기 위하여 사용할수도 있다. 명세가 분석되고, 시스템의 조건과 동작(actions)이 정의된다. 입력 조건과 행위는 대부분의 경우 true나 false 모두를 가질 수 있는 방법(Boolean)으로 지정된다. 의사결정 테이블은 트리거 조건, 모든 입력 조건들에 대한 true, false의 조합, 그리고 각각의 조건의 조합에 대한 결과 행위를 포함한다. 테이블의 각 컬럼은 규칙과 연관된 행위의 실행의 결과로 나타나는 조건들의 유일한 조합을 정의하는 업무규칙(bisiness rule)과 관련이 있다. 일반적으로 의사결정 테이블 테스팅에 사용되는 커버리지 표준은 일반적으로 트러거 되는 조건들의 모든 조합을 커버하는 것을 포함하는 각 컬럼마다 하나의 테스트 케이스를 갖는 것이다.
의사결정 테이블 테스팅의 강점은 테스팅 동안에 실행되지 않을 수 있는 조건들의 조합을 만들어낸다는 것이다. 의사결정 테이블 테스팅은 몇가지 논리적인 결정들에 의존하는 소프트웨어의 동작(action)때의 모든 상황에 적용 할 수 있다.
4.3.4 상태 전이 테스팅 (State transition testing) (K3)
시스템은 현재의 조건이나 이전 히스토리(시스템의 상태)에 의존하는 각기 다른 결과를 보여줄 수 있다. 이러한 시스템의 측면은 상태 전이 다이어그램으로 보여질 수 있다. 상태 전이 다이어그램은 테스터가 시스템을 시스템의 상태, 상태들 사이의 전이, 상태의 변화(트랜잭션)을 일으키는 입력이나 사건 그리고 이러한 트랜잭션의 결과가 될 수 있는 행위의 관점에서 보는 것을 가능하게 한다.
테스트시의 시스템 상태 또는 객체들은 분리 될 수 있고, 식별이 가능해야 하며, 그 수가 제한된다.상태 테이블은 상태와 입력 사이의 관계를 보여주고, 무효화 될 가능성이 있는 트랜잭션을 강조하여 보여줄 수 있다. 테스트는 전형적인 상태의 시퀀스를 커버하고, 모든 상태를 커버하고, 모든 트랙잭션을 실행하고, 특정 트랜잭션의 시퀀스를 실행하거나 유효하지않은 트랜잭션을 테스트 하도록 설계 될 수 있다.
상태 전이 테스팅은 일반적으로 기술적인 자동화와 임베디드 소프트웨어 산업분야에서 더 많이 사용된다. 그러나, 이러한 기법은 특정 상태를 갖는 비지니스 객체의 모델링이나 화면 형식의 대화형 플로우 테스팅(testing screen-dialog flows)(e.g 인터넷 응용 프로그램이나 업무 시나리오)에 대해서도 역시 적용가능하다.
4.3.5 유스케이스 테스팅 (Use case testing) (K2)
테스트들은 유스케이스나 업무 시나리오에서 명세 될 수 있다. 유스케이스는 시스템 사용자에 대하여 가치있는 결과를 생산하는 시스템과 사용자를 포함하는 액터들 사이의 상호작용을 묘사한다. 각각의 유스케이스는 유스케이스가 성공적으로 작동하기 위하여 만족시켜야 하는 선행조건(preconditions)을 가진다. 각각의 유스케이스는 관찰 가능한 시스템의 상태와 결과를 가진 후행조건(post-conditions)으로 종료된다. 일반적으로 유스케이스는 하나의 주된(i.e 가장 있음직한) 시나리오와 때때로의 분기점들을 갖는다.
유스케이스는 실제로 있음직한 시스템의 사용을 통하여 "프로세스 흐름(process flows)"을 묘사한다. 따라서 유스케이스에서 유도된 테스트 케이스들은 시스템 실사용 동안의 프로세스 흐름내에 존재 할 수 있는 결함들(defects)을 발견하는데 유용하게 사용된다. 유스케이스는 종종 시나리오로서 언급되며, 고객/사용자가 참여하는 승인 테스트를 설계하는데 매우 유용하다. 유스케이스는 개별적인 컴포넌트 테스팅에서는 볼 수 없는 여러가지 컴포넌트의 간섭과 상호작용이 원인이 되는 커버되지 않는 통합적인 결함(integration defects)를 고치는데 도움이 된다.
명세서를 테스트 하는 것은 정적 블랙박스 테스트에 해당한다. 명세서를 테스트하는 것은 명세서에 대한 개괄적인 검토를 하는 첫번째 단계와 명세서에 대한 세부적인 검토를 하는 2단계로 나눌수 있다.
[명세서에 대한 개괄적인 검토]
명세서에 대한 개괄적인 검토는 당장에 버그를 찾아내는 것이 아니라 넓은 범위에서 명세서의 근본적인 문제나 간과한 부분, 누락된 부분을 찾아내는 것이다. 이러한 조사는 소프트웨어의 역할에 대한 이해를 돕는다. 이 단계에서의 가이드라인은 다음과 같다.
• 사용자 입장에서 생각하라. 고객의 요구사항을 이해하는 것은 중요하다. 이러한 요구사항을 이해한 다음에 테스트를 하여야한다. 추측은 금물이다. 이해하지 못한 부분이 있다면 반드시 이해하도록 노력해야 한다. • 존재하는 표준과 지침을 조사하라. - 존재하는 표준과 지침으로는 회사내의 용어 및 관례, 업계의 요구 사항, 정부 기준(특히 국방 관련), GUI, H/W 및 네트워크 표준 • 유사한 소프트웨어 검토 및 테스트 - 이 작업은 테스트 상황과 접근법을 생가해 보는데 도움을 준다.
[명세서에 대한 세부적인 검토]
제품 명세에 대한 고수준의 검토가 끝나면 제품의 종류와 어떤 외부적 요소가 설계에 고려되었는지 이해가 될 것이다. 이 정보를 참고하여 좀 더 자세한 테스트를 할 수 있다.
• 일반적으로 잘 만들어진 명세서는 다음의 속성을 가진다. - 완결성, 정확성, 정밀함, 명백함, 일관성, 연관성, 실행 가능성,코드의 배제, 테스트 가능성 - 이러한 속성을 충족시키지 않는 부분이 버그이며, 이는 보고의 대상이 된다. • 명세서를 검토하는 동아나 명세에 쓰여진 용어 역시 적절한가를 검토해야 한다. 명세서에서 명확히 정의되어 있는 경우는 문제가 되지 않지만 모호한 경우는 버그로 생각해야 한다.
동적 블랙박스 테스트
코드의 세부 사항에 대한 통찰 없이 소프트웨어를 테스트하는 것이 동적 블랙 박스 테스트이다. 이 경우 고객이 사용하는 것처럼 프로그램을 실행하기 때문에 동적이며, 작동 방법에대해서는 모르는 상태이기 때문에 블랙 박스 테스트이다. 일반적으로 동작 테스트라고 불리며, 효과적으로 수행하기 위해서는 소프트웨어의 역할에 대한 정의 즉 요구사항 문서 또는 제품 명세서가 필요하다. 여기서는 소프트웨어 내부에서의 동작은 알 필요가 없이 입력에 대한 출력 만을 알면된다.
[통과 테스트 (Test to Pass)와 실패 테스트 (Test to Fail)]
통과 테스트의 경우 소프트웨어가 최소한 작동한다는 사실이 확인되어야 한다. 여기에서는 소프트웨어의 성능은 시험하지 않는다. 따라서 가장 단순하고 간단한 테스트 케이스만을 적용하여 테스트한다. 테스트 케이스를 설계하고 실행할 때 항성 성공 테스트를 먼저해야 한다. 보통의 상황에서 소프트웨어가 지정된 대로 작동한다는 것을 확실히 확인한 다음에는 예외 상황 즉, 정도를 벗어난 극단적인 방법으로 소프트웨어를 취급하여 버그를 찾아야 한다. 실패 테스트는 소프트웨어의 일반적인 약점을 조사하기 위하여 전략적으로 선택된 케이스들이다.
[동등분할 (Equivalence Partitioning)]
동등 분할의 목표는 가능한 테스트 케이스의 수를 테스트하기에 충분하게 작고 처리하기 쉬운 수로 축소하는 것이다. 단 테스트 케이스의 수를 줄이려고 노력하는 동등 분할 작업을 너무 많이 하다보면 버그를 발견할 수 있는 테스트를 생략할 가능성이 있다. 또한 동등 분할은 주관적이다. 따라서 다른 작업자들이 분할을 검토하여 충분히 소프트웨어를 테스트 할 수 있는지를 판단해야 한다.
▪ Input/output space를 유한개의 상호 독립적인 집합(mutual disjoint subset)들로 나누어 관리 ▪ 등가 집합을 만든 후 각 등가집합의 원소 중 하나의 대표값을 선택하여 testcase를 선정한다. ▪ Weak Equivalence Class Testing : 등가집합의 각각에 대하여 하나의 대표값을 이용하여 test case 구성 ▪ Strong Equivalence Class Testing : 각 domain의 등가 집합들 사이의 조합으로 나타낼 수 있는 모든 경우의 수를 고려
[데이터 테스팅 (Data Testing)]
소프트웨어에 대한 간단한 견해는 데이터와 프로그램 영역으로 나누는 것이다. 데이터를 소프트웨어로 테스트하는 경우 사용자가 입력하는 정보, 얻게 되는 결과, 소프트웨어 내부의 모든 중간 결과가 정확하게 취급되는지 확인하게 된다. 복잡한 프로그램을 테스트 할 수 있게 만들어주는 비결은 경계 조건, 하위 경계조건, 잘못된 데이터 등 몇몇 개념에 기초한 동등 분할에 의하여 테스트 사례의 수를 줄이는 것이다.
▪ 테스트 대상 시스템의 입력 혹은 출력 영역의 경계 값에 초점을 맞추어 테스트 케이스 도출
▪ 경계조건(Boundary Condition) : 한 소프트웨어가 성능의 한계점에서도 잘 동작한다면 보통의 상황에서도 잘 동작할 것이다. 경계조건의 유형으로는 숫자, 속도, 문자, 위치, 장소, 크기, 양 등이 있으며, 동등 분할에 어떤 데이터를 포함할 지 결정했다면 경계에 해당하는 데이터를 선택하는 것이 좋다. ▪ 하위 경계 조건(Sub-Boundary Conditions) : 소프트웨어 내부에 있는 어떤 경계는 최종 사용자에게 나타나지 않지만 소프트웨어 테서트의 확인이 필요한 경우가 있다. 이것을 하위 경계 조건 또는 내부 경계 조건이라 한다.
[상태 테스팅 (State Testing)]
소프트웨어 테스터는 프로그램의 상태와 상태 사이의 전환 과정을 테스트해야 한다.
▪ 소프트웨어의 논리적 흐름 테스팅 : 소프트웨어의 상태와 논리적 흐름을 테스트하는 것은 동일한 문제로 모든 상태를 테스트하는 것은 간단한 프로그램을 제외하고는 불가능하다. 이런 경우 먼저 상태 도표를 만들어야 한다. 상태 도표에는 소프트웨어가 처할 수 있는 고유한 상태, 한 상태에서 다른 상태로 전환하는 입력 또는 상태, 상태가 입력 또는 선택될 때의 조건과 해당 출력 설정이 포함되어야 한다. 도표가 만들어졌다면 많은 수의 가능성을 작업 가능한 크기의 테스트 케이스로 다음 기준을 참고삼아 축소해야 한다.
- 각 상태를 최소한 한 번 거친다. - 가장 흔하고 많이 쓰이는 상태 사이의 변환을 테스트 한다. - 상태에 이르는 거의 사용되지 않는 경로를 테스트한다. - 모든 오류 상태를 확인하고 오류 상태에서 원래대로 돌아오는지 확인한다. - 무작위로 상태 변환을 확인한다.
▪ 실패 상태 테스트 : 이 경우는 소프트웨어가 장애를 일으키는 테스트 케이스를 찾는 것으로 다음의 경우이다.
- 경쟁 상태 및 잘못된 타이밍 - 반복, 스트레스, 부하 테스트
이 경우 고려해야 하는 사항으로는 다음의 두가지 사항이 있다.
- 팀의 프로그래머 또는 프로젝트 매니저는 소프트웨어를 파괴하려는 당신의 노력에 우호적이지 않다. - 프로그램을 열고 닫는 수많은 반복 작업을 수행하는 것이 불가능할지도 모른다.
▪ 이벤트, 액션, 활동, 상태, 상태, 상태전환 사이의 관계를 검증하는 테스팅 기법(모든 상태/이벤트 조합을 커버-both legal and illegal) ▪ 시스템/소프트웨어 상태기밥 행위가 명세된 내용과 일치함을 검증 ▪ 상태기반 시스템의 결함은 상태, 상태전환, 가드, 이벤트 결함 등으로 분류 ▪ 결함은 "구현이 잘못된 경우"와 "명세가 잘못된 경우"가 존재 ▪ 테스팅 절차 1. 상태-이벤트 테이블 구성 2. 전환 트리 구성 3. Legal 테스트 스크립트-테스트 케이스 구성 4. Illegal 테스트 스크립트-테스트 케이스 구성 5. 테스트 스크립트-가드 구성 ▪ 모델상의 결함(Faults in model) -• 초기 상태 누락 -• 가드(guards)가 "전환" 대신 상태에 표기 -• 가드의 중복 -• ... 인스펙션, 정적 분석(도구)로 결함 발견 ▪ 구현상의 결함(Faults in implementation) -• Extra/missing/corrupt state -• 액션이 틀리거나 누락 -• 스니크 패스(Sneak paths); 트랩 도어(trap doors).. -• ... 테스트 만이 결함을 발견하는 방법 • 테스트 스크립트 가드 구성시 - 가드가 경계값을 갖는 조건문으로 구성되어 있으면 "경계값 분석" 기법 적용 - 가드가 복잡한 조건문으로 구성되어 있으면 "Modified condition/decision coverage" 기법 적용
4.4 Structure-based or white-box techniques (K3)
구조 기반 기법/화이트 박스 테스팅은 다음의 예제에서 보여지듯 시스템이나 소프트웨어의 정의된 구조에 기반한다.
• 컴포넌트 레벨 (Component Level) :
여기서의 구조는 코드 그 자체의 구조이다. i.e 문장(statements), 결정(decision), 분기(branches)
• 통합 레벨 (Integration Level) :
여기서의 구조는 호출 트리(Call tree)가 될 수 있다. (다른 모듈을 호출하는 모듈을 내부에 가진 다이어그램)
• 시스템 레벨 (System Level) :
여기서의 구조는 메뉴 구조, 업무 프로세스 구조나 웹 페이지 구조가 될 수 있다.
이번 섹셕에서, 문장, 결정에 기반한, 두가지 코드와 관련된 구조적인 기법이 논의된다. 결정 테스팅(decision testing)에 대해서는, 컨트롤 플로우 다이어그램이 각각의 결정에 대한 선택사항을 가시화하기 위하여 사용될 수 있다.
4.4.1 문장 테스팅과 커버리지 (Statement testing and coverage)(K3)
컴포넌트 테스팅에서 문장 커버리지는 테스트 케이스 슈트(test case suite)에 의하여 동작된 실행 가능한 문장을 페센티지(%)로 평가한 것이다. 일반적으로 문장 커버리지를 증가시키기 위하여, 문장 테스팅은 특정 문장의 실행을 위한 테스트 케이스를 유도한다.
4.4.2 결정 테스팅과 커버리지 (Decision testing and coverage)(K3)
분기 테스팅과 관련된 결정 커버리지는 테스트 슈트에 의하여 실행된 결정 결과(e.g IF문에서의 true, false 옵션)들의 백분율(%)를 평가하는 것이다. 일반적으로 결정 커버리지를 증가시키기 위하여, 결정 테스팅은 특정 결정 결과를 실행하기 위한 테스트 케이스를 유도한다.
결정 테스팅은 결정 지점(decision point)을 통하여 특정 컨트롤 플로우를 생성시키는 컨트롤 플로우 테스팅(control flow testing)의 한 형식이다. 결정 커버리지는 문장 커버리지보다 강력하다. 100% 결정 커버리지는 100% 문장 커버리지를 보증하지만 반대는 그렇지 않다.
4.4.3 다른 구조 기반 기법들 (Other structure-based techniques)(K1)
조건 커버리지와 다중 조건 커버리지와 같은 결정 커버리지를 넘어서는 강력한 레벨의 구조적인 커버리지가 있다.
물론 커버리지 개념은 테스트 케이스 슈트(test case suite)에 의하여 실행된 모듈, 컴포넌트, 또는 클래스의 퍼센티지는 모듈 커버리지, 컴포넌트 커버리지, 클래스 커버리지로 표현될 수 있는 것처럼, 다른 테스트 레벨(e.g 통합 레벨)에도 적용 될 수 있다.
정적 화이트 박스 테스트는 소프트웨어를 실행하지 않은 채 설계, 구조 또는 버그의 코드를 주의 깊고 조직적으로 검토하는 방법이다. 때로는 구조 분석이라 불리며, 정적 화이트 박스 테스트를 수행하는 이유는 조기에 버그를 발견하고, 나중에 수습하기 어려운 버그나 동적 블랙박스 테스트로는 발견하기 어려운 버그를 찾아내기 위해서이다. 소프트웨어를 검토하는 사람이 독립적일수록 이 방법이 효과적이며, 특히 개발 주기의 초기 단계에서의 개략적인 테스트에 효과적이다.
[공식적인 검토(Formal Reviews)]
공식적인 검토는 아래의 네가지 필수 요소가 있다.
▪ 문제 찾기 - 틀린 항목만이 아니라 누락된 항목도 포함되며 모든 비판은 코드 작성자가 아닌 코드 자체에 집중되어야 한다. 참가자들은 비난을 개인적으로 받아들여서는 안된다. ▪ 규칙 준수 - 규칙을 따라야 한다. 규칙은 검토해야 할 코드의 양, 소요시간, 회의 내용등을 결정
한다. ▪ 준비 - 각각의 참가자는 검토에 대하여 준비하고 도움을 주어야 한다. ▪ 보고서 작성 - 검토 작업의 결과를 요약하는 문서를 작성해야 하며 이 보고서를 제품 개발 팀의 나머지 구성원에 공개하여야 한다.
확립된 절차를 따라야 공식적인 검토의 효과를 볼 수 있다. 검토가 제대로 이루어진다면 이 작업이 초기에 버그를 발견하는 데 많은 도움이 된다는 것을 증명할 수 있다. 이외에 다음과 같은 간접적인 이점을 얻을 수 있다.
- 의사소통 - 품질 - 동료의식 - 솔루션
▪ Peer Reviews (동료들의 검토) ▪ Walkthroughs (워크스루) ▪ Inspection(인스펙션) - 가장 형식적인 과정으로 참가자에 대한 교육이 필요하다.
[코딩의 표준 및 지침]
표준이나 지침을 따라야 하는 이유는 다음과 같다.
1. 표준이나 지침에 따라 코드를 작성하는 것이 신뢰도가 더 높다. 2. 표준이나 지침을 따른 코드가 읽고 이해하기 쉬우며, 유지 관리가 쉽다. 3. 쉽고 간단하게 다른 플랫폼으로 코드를 이전할 수 있다.
[일반적인 코드 검토 점검표]
코드 검토 점검표는 표준이나 지침과 코드를 비교하고, 코드가 프로젝트의 설계 요구 사항을 충족하는지를 확읺는 것으로 다음의 사항이 포함된다.
▪ 데이터 참조 오류 ▪ 데이터 선언 오류 ▪ 계산 오류 ▪ 비교 오류 ▪ 제어 흐름 오류 ▪ 서브루틴 파라미터 오류 ▪ 입력/출력 오류 ▪ 다른 검사 사항
동적 화이트 박스 테스팅
동적 화아트박스 테스트는 코드의 역할과 작동 방법을 관찰하여 얻은 정보를 사용하여 테스트 할 대상과 테스트에서 배재할 대상, 테스트 접근 방법등을 결정하는 것이다. 동적 화이트 박스는 구조적 테스팅이라고도 불리는데 이는 코드의 근본적인 구조를 관찰하고 이를 사용하여 테스트를 설계하고 수행하기 때문이다. 동적 화이트 박스 테스트는 코드의 역할을 살펴보는데 그치지 않는다. 이 테스트에서는 직접 테스트를 해보고 소프트웨어를 제어해 본다. 화이트 박스에 포함되는 네가지 영역은 다음과 같다.
1. 직접 기능, 프로시저, 서브루틴, 라이브러리를 테스트한다. 2. 최종 단계에서 완결된 프로그램의 형태로 소프트웨어를 테스트한다. 하지만 이때 소프트웨어의 동작에 대한 지식에 기초하여 테스트 사례를 조정한다. 3. 생각대로 테스트가 진행되고 있는지 살펴보기 위하여 소프트웨어에서 변수 및 상태 정보를 읽을 수 있도록 액세스 한다. 보통 테스트에서는 수행하기 어려운 동작을 소프트웨어에서 수행해 볼 수 있다. 4. 테스트 수행시 얼마나 많은 코드를 대상으로 하는지, 특히 어떤 코드를 대상으로 하게 되는지 측정한 다음 중복되는 테스트 사례를 제거하고 누락된 것을 추가하는 등 테스트를 조정한다.
[동적 화이트 박스 테스트 대 디버깅]
동적 화이트 박스 테스트의 목표는 버그 발견이다. 디버그의 목표는 버그의 수정이다. 하지만 버그가 발생하는 장소, 원인을 분리하려는 영역에서는 중복된다.
[데이터 영역(Data Coverage)]
▪ 데이터 흐름 ▪ 하위 경계 ▪ 공식과 방정식 ▪ 오류만들기 ▪ 오류 메시지 만들기
[코드 영역(Code Coverage)]
소프트웨어의 모든 모듈을 시작하고 종료하고, 코드의 모든 라인을 조사하고,모든 논리와 결정 경로를 조사해야 한다. 이렇게 세부적인 수준으로 소프트웨어를 조사하는 것은 코드 영역 분석이라 부른다. 코드 영역 분석에 액세스 하여 테스트 케이스를 실행할 때 소프트웨어의 어떤 부분을 통과하는지 봐야 한다는 점에서 동적 화이트 박스 테스트 기법이 된다. 코드 영역 분석의 가장 단순한 형태는 컴파일러의 디버거를 사용하여 프로그램에 접근할 때 방문하는 코드의 라인을 살펴보는 것이다.
▪ 프로그램 문장 및 라인 영역 (Program Statement and Line Coverage) ▪ 분기 영역 (Branch Coverage) ▪ 조건 영역(Condition Coverage)
- Statement Coverage :
프로그램내의 모든 명령문을 적어도 한번 수행하도록 테스트 케이스를 산출
- Decision Coverage :
프로그램 내의 결정 명령문이 적어도 한번은 "true"와 "false"의 결과가 되도록 테스트 케이스를 산출 - Condition Coverage :
결정 명령문 내의 각 조건이 적어도 한번은 "true"와 "false"의 결과가 되도록 테스트 케이스를 산출한다. - Decision/Condition Coverage :
결정 명령문 및 명령문내의 각 조건이 적어도 한번은 "true"과 "false"을 취하고 모든 명령문이 적어도 한번은 수행하도록 테스트 케이스 산출 - All Path Coverage :
모든 경로를 적어도 한번 수행하도록 테스트 케이스 산출
4.5 Experience-based technique (K2)
아마도 가장 널리 쓰이는 테스팅 기법은 에러를 추정하는 것일 것이다. 테스트는 테스터(tester)의 기술(skill)과 직관 그리고 유사한 시스템(similar system)과 기술에 대한 경험으로 부터 유도된다. 체계적인 기법을 확대하여 사용할 때, 직관적인 테스팅은 매우 형식적인 방법을 적용한 후에 정형적인 기법으로 쉽게 찾을 수 없는 특별한 테스트들을 정의하는데 유용할 수 있다. 하지만 이 기법은 테스터의 경험에 의존하기 때문에 효용성의 정도는 다양할 수 있다. 에러를 추정하는 기법에 대한 구조적인 접근 방식은 가능한 에러의 리스트를 열거하고 이러한 에러들을 찾아내는 테스트들을 설계하는 것일 것이다. 이러한 결점과 실패 리스트는 경험, 이용가능한 결함(defect)과 실패(failure)의 자료, 그리고 소프트웨어가 왜 실패하는가에 대한 일반적인 지식에 기반하여 만들 수 있다.
탐색적인 테스팅(Exploratory testing)은 테스트 설계(test design), 테스트 실행, 테스트 로깅과 지식의 습득을 동반하며, 테스트 목표들을 포함하는 테스트 문서에 기반하고, 타임 박스 안에서 수행된다. 이러한 접근 방식은 소량이거나 불충분한 명세와 심각한 시간의 압박이 있는 경우, 또는 매우 형식적인 테스팅을 확대하거나 보층할 때 유용하다. 이 기법은 대부분의 심각한 결함이 발견되었다는 것을 확인 할 수 있는 테스트 프로세스 점검용으로도 사용될 수 있다.
▪ 유사 SW나 기술에의 경험을 바탕으로 직감적으로 테스트하는 기법 ▪ Formal 기법과 같이 사용 ▪ Formal 기법이 찾기 어려운 결함 발견 기나능 - 테스트의 경험에 따라 효과가 다르기 때문에 리관성이 떨어지면 관리가 어렵다.
▪ 탐색적 테스팅 (Exploratory Testing) ◦ 테스트 목표를 포함하는 테스트 차터(charter)를 기반으로 정해진 시간내에 테스트 설계, 수행, 기록과 학습하는 테스팅 기법 ◦ 명세가 거의 없고 시간이 부족한 경우 ◦ Formal 기법을 보충할 경우 ◦ 가장 심각한 결함을 모두 발견했다는 것을 확인하는 목적으로 사용하는 경우 적합
▪ Error guessing ◦ 가능한 결함을 리스트업하고 이를 발견하기 위한 테스트케이스 작성 ◦ 가능한 결함(에러, 오류)은 상식, 기존 경험과 기존 데이터를 통해 도출가능
▪ 일반적인 경험과 노하우의 반영믈 - 체크리스트 ◦ 문서 기반의 테스트 케이스를 작성시에도 체크리스트의 경험과 노하우를 반영하는 노력 요구
◆ Classification Tree Method
▪ 블랙 박스 기반 ▪ 명세가 없는 경우 ▪ 비공식적 - 비공식적이라고 나쁜 기법이 아니다. ▪ 테스트 아이디어 시각화 ▪ 복잡성 처리 - 중복성을 피하고 한가지 기능만 테스트 하는 경우 회피 가능 ▪ 개발 설계 체크 ▪ 테스트 비용 측정 가능
◆ 통계적 사용기반 기법
▪ 어떤 상황에서 어떤 동작이 수행될 가능성이 높은가? ▪ 상태와 이벤트 조합 확률에 의존 (Operational profiles) ▪ 다수의 테스트 케이스 ; Operational profiles에 비례 ▪ Rare Event Testing은 확률이 낮은 이벤트에 집중
그레이 박스 테스팅
그레이 박스 테스팅은 블랙박스 테스트와 화이트 박스 테스트의 혼합한 형태로, 두 가지 테스트 형태의 경계에 존재한다. 여기서는 소프트웨어를 블랙 박스 형태로 테스트하며, 화이트 박스와 같이 상세하지는 않지만 소프트웨어의 작동 원리에 대해 알아보는
4.6 Choosing test techniques (K2)
사용하기 위한 테스트 기법의 선정은 시스템 타입, 표준의 준수, 고객 또는 계약 요구사항, 위험 레벨, 테스트 목적, 문서화 가능여부, 테스터의 지식, 시간과 예산, 개발 주기, 유스케이스 모델과 발견된 결함 타입에 대한 이전 경험을 포함하는 인자(factor)의 수에 의존한다.
정적 테스팅 기법(Static testing techniques)은 테스트되는 소프트웨어를 실행하지않는다.; 정적 테스팅 기법은 매뉴얼 리뷰 또는 자동화된 정적 분석 기법들이다.
리뷰(Reviews)는 소프트웨어 작업 산출물(코드를 포함해서)을 테스트 하는 방법이며, 동적 테스트(dynamic test)에 실행 전에 수행 될 수 있다. 수명주기(life cycle) 초기 리뷰동안에 감지된 결함(defects)들은 테스트를 실행하는 동안에 감지된 결함들보다 제거하는 비용이 적게 든다.(e.g 요구사항에서 발견된 결점)
리뷰는 전적으로 인력을 요하는 액티비티이지만, 도구를 이용하는 것 역시 가능하다. 인력을 요구하는 주된 액티비티는 작업 산출물(work products)을 시험하고, 그에 대한 논평을 하는 것이다. 요구 사항문서, 디자인 명세, 테스트 케이스, 테스트 스크립트, 사용자 가이드 또는 웹 페이지를 포함한 모든 소프트웨어 작업 산출물은 리뷰의 대상이 될 수 있다.
리뷰의 해택은 초기의 결점 발견과 정정, 개발 생산성 향상, 개발 시간 축소, 테스팅 비용과 시간의 축소, 개발 비용 축소, 더 적은 결함과 커뮤니케이션의 증가를 포함한다. 예를 들어, 리뷰는 동적 테스팅에서 발견할 수 없는 요구사항의 빠진 부분을 발견 할 수 있다.
리뷰, 정적 분석과 동적 테스팅은 동일한 목적-결함을 찾는것-을 가진다. 이들은 상호보완적이다. 각기 다른 기법들은 여러가지 종류의 결함을 효과적이고 효율적으로 찾을 수 있다. 동적 테스팅과 대조하여, 리뷰는 실패(failures)보다 결함(defects)를 찾는다.
표준의 미준수(deviations from standards), 요구사항내의 결함(requirements defects), 설계상의 결함(design defects), 불충분한 유지보수성(insufficent maintainability)과 잘못된 인터페이스 명세(incorrect interface specifications)와 같은 전형적인 결함들은 동적 테스팅보다 리뷰에서 쉽게 발견된다.
▪ SW 중간 산출물을 테스팅하는 방법 - 프로그램 코드, 요구사항 명세서, 설계 명세서 - 테스트 계획서, 테스트 설계서, 테스트 케이스, 테스트 스크립트 사용자 지침서
▪ 소프트웨어 개발 생명 주기의 앞부분에서 수행하여 결함 제거 비용이 저럼
▪ 개발 생산성 향상, 개발 시간 단축, 테스트 비용과 시간 단축 - 보다 적은 내재 결함 수와 향상된 의사 소통으로 위 사항을 가능케 한다.
▪ 테스팅 기법별로 다른 종류의 결함 발견 (상호보완적) - 리뷰 : 코드 또는 문서상의 결함 (failure는 발견하지 못함) 표준과의 불일치성, 설계 결함, 유지보수의 불충분성, 인터페이스 명세 결함 - 정적분석 : 코드의 복잡도, 구문 에러, Missing 파라미터, Dead 코드 등
Review의 필요성
▪ 테스팅 보다는 Review에서 결함을 발견하는 것이 더 효율적 - 단위 테스트에서 시간당 2~4개 정도의 결함을 발견한다면 - Code Review에서는 6~10개 정도의 결함을 발견
▪ 단위 테스트 후의 결함제거에는 많은 비용이 필요 - 통합 및 시스템 테스트에서 각각의 결함을 발견하고 수정하는 데 걸리는 시간은 10~40 M/H 정도 - Inspection은 결함당 1시간 이내 소요
▪ 빠른 결함 제거 시 시간과 비용 절감 효과가 있다. - 개발 후반기 결함을 발견하고 수정하는 경우 더 많은 결함 비용 소모 - 개발 완료 후 결함을 발견하고 수정하는 경우에는 보다 많은 결함 비용 소요
◆ Informal Review VS Technical Review
| Informal Review | Technical Review -------------------------------------------------------------------------------- 주요 목적 | 저비용 문서/코드 검토 | 기술적 문제 해결 | | 토론, 의사결정, 대안 평가, 결함발견 | | 명세서 또는 표준과의 적합성 체크 -------------------------------------------------------------------------------- 참여자 | (선택적) Pair 프로그램밍 or | 동료 또는 기술 전문가가 문서화되고 | 기술 선임자가 설계와 코드 리뷰 | 정의된 결함 발견 프로세스에 참여 -------------------------------------------------------------------------------- 문서화 여부 | (선택적) 문서화 |실무에서는 Informal 또는 formal -------------------------------------------------------------------------------- 효과 | 리뷰어에 따라 효과가 다양 | 실무에서는 Informal 또는 formal -------------------------------------------------------------------------------- 사전준비 | | 미팅 사전 준비 단계 거침 -------------------------------------------------------------------------------- 미팅 주도 및 | | 이상적으로는 Moderator가 미팅 주도 활용 도구 | | (선택적) 체크리스트, 리뷰 리포트 (문서) | | 인시던트 리스트, 경영층 참여 활동 --------------------------------------------------------------------------------
◆ 리뷰 성공 요소
▪ 각각의 리뷰가 명확하게 기정의된 목적이 있어야 함 ▪ 적합한 인력이 선택되어야 함 ▪ 결함 발견은 언제나 환영하는 분위기이고 결함은 객관적으로 표현되어야 함 ▪ People issues와 심리적인 측면이 고려되어야 함 ▪ 리뷰 기법이 적절히 적용되어야 함 ▪ 효과적/효율적인 결함 발견을 위하여 필요시 체크리스트 활용 (역할 분담도 적절히 활용) ▪ 리뷰 기법에 대한 교육 훈련 제공 (특히, 인스펙션의 경우) ▪ 경영층이 리뷰 프로세스를 지원 (프로젝트에서 리뷰 기법 적용에 충분한 일정 할애) ▪ 학습과 프로세스 개션에 대한 강조
3.2 Review process
리뷰(Reviews)는 비형식적인 것에서 부터 매우 형식적인 것(i.e 잘 구조화되어 있고, 규칙적인)까지 다양하다. 리뷰 프로세스의 형식(formaility)은 개발 프로세스의 성숙도, 법적(legal) 요구사항과 규정(regulatory) 요구사항 또는 감사 추적(audit trail)에 대한 필요성과 관련이 있다.
리뷰를 수행하는 방법은 합의된 리뷰의 목적에 의존한다. (e.g 결함의 발견, 이해의 획득, 또는 여론에 의한 논의와 결정)
3.2.1 형식적 리뷰의 단계 (Phase of a formal review)
전형적인 형식 리뷰는 다음의 주요한 단계(Phase)를 갖는다.
• 계획(Planning) :
계획 단계에서는 인력을 선발하고, 각 개인에게 역할(role)을 할당하며 문서들의 어떤 부분들을 살펴 볼 것인가를 결정한다. 그리고, 점검(inspection)과 같이 좀더 형식적인 리뷰를 위해서 시작과 좋료 조건(entry and exit criteria)을 정의한다.
• 킥 오프(Kick-Off) :
Kick-Off 단계에서는 문서를 분배하고, 참가자들에게 리뷰 목적, 프로세스, 문서들에 대해 설명한다. 그리고, 좀더 형식을 필요로 하는 리뷰들을 위해서 시작 조건을 확인한다.
• 개별 준비(Individual preparation) :
개별 준비 단계에서는 참가자 개개인들 스스로가 리뷰 미팅 전에 잠재적인 결함, 질문과 코맨트들을 기록한다.
• 리뷰 미팅(Review meeting) :
(좀 더 형식적인 리뷰 타입을 위한) 문서화 된 기록 또는 상세한 기록과 더불어 논의와 로깅을 한다. 미팅 참석자들은 결함(defects)을 처리하기 위한 충고사항을 제시하거나 결함에 대한 결정을 하기 위하여 간단하게 결함을 기록할 수 있다.
• 재작업(Rework) :
발견된 결함을 고친다. 일반적으로 작성자(Author)에 의하여 행해진다.
• 추가작업(follow up) :
사후 점검 단계에서는 처리된 결점을 확인하고 측정 기준들을 수집한다. 또한 좀더 형식적인 리뷰들을 위해서 종료 조건에 대한 확인도 한다.
3.2.2 역할과 책임 (Roles and responsibilities) (K1)
• 관리자 (Manager) :
리뷰 실행에 대한 결정을 하고, 프로젝트 일정내에 리뷰 시간을 할당한다. 그리고 리뷰의 목표가 달성되었는가를 결정한다.
• 중재자 (Moderator) :
리뷰 계획, 미팅의 운영, 그리고 미팅 후 추가 사항을 포함하는 문서 혹은 문서 셋(document set)의 리뷰를 이끄는 사람을 말한다. 중재자는 다양한 관점들 사이를 중재할 수 있으며, 때때로 리뷰의 나머지 부분을 이끈다.
• 작성자(Author) :
작가 혹은 리뷰된 문서에 대한 주된 책임을 가지고 있는 사람
• 리뷰어(Reviewer) :
특정 기술 혹은 비지니스 배경을 가지고 있는 개인 (Checker 또는 Inspector로 불려질 수 있다.)으로 필요한 준비후에 리뷰 동안에 제품에서 발견된 사항(e.g 결함)을 정의하고 묘사하는 사람. 리뷰어는 리뷰 프로세스에서 표현되는 다양한 관점과 역할을 선택할 수 있어야 하며, 모든 리뷰 미팅에 참가해야 한다.
• 필기자(또는 서기)(Scribe(or recorder)) :
모든 이슈사항, 문제 그리고 미팅 동안에 정의되어야 하는 문제점(-미정사항open points)을 문서화한다.
여러가지 관점에서 문서를 살펴보는 것과 체크 리스트(checklists)를 이용하는 것은 리뷰를 더욱 효과적이고 효율적으로 만들 수 있다. 예를 들어, 사용자, 유지 보수인력(maintainer), 테스터 또눈 운영자 같은 측면에 기반한 체크 리스트나 전형적인 요구사항 문제들에 대한 체크 리스트는 리뷰를 더욱 효과적이고 효율적으로 만들 수있다.
3.2.3 리뷰 타입 (K2)
하나의 문서는 하나 이상의 리뷰의 주제가 될 수 있다. 만약 한 종류 이상의 리뷰가 수행된다면, 순서는 매우 다양해 질 수 있다. 예를 들어 비형식적인 리뷰(informal review)를 테크니컬 리뷰(technical review)에 앞서 수행 할 수 있다. 또한 요구사항 명세에 대하여 수행되는 점검(Inspection)은 고객과 함께하는 walkthrough 전에 수행될 수 있다. 일반적인 리뷰 타입들의 주요한 특성, 옵션과 목적은 다음과 같다.
비형식 리뷰 (Informal Review)
주요 특성 • 형식적인 프로세스가 없다. • 쌍으로 하는 프로그래밍(Pair programming)이나 기술 리더가 디자인과 코드를 리뷰하는 것이 될 수 있다. • 조건적에 따라 문서화 될 수 있다. • 리뷰어에 의존하여 유용성이 변할 수 있다. • 주요 목적 : 임의의 혜택을 얻는 비용이 많이 들지 않는 방법
Walkthrough
주요 특성 • 작성자(Author)에 의해 주도되는 미팅 • 시나리오들, 리허설(dry runs), 동료 그룹 • 미 종결된 세션 • 조건적인 리뷰어들의 선 미팅 준비(pre-meeting preparation), 리뷰 리포트, 발견 사항과 필기자(scribe)의 리스트 • 실제로 상당히 비형식적인 것에서 부터 매우 형식적인 까지 다양하다. • 주요 목적 : 배우고, 이해하고, 결점을 찾는다.
기술 리뷰 (Technical Review)
주요 특성 • 문서화 되고, 동료와 기술적인 전문가를 포함하는 결함 탐지(defect-detection)을 위한 정의된 프로세스 • 관리자의 참가없이 동료가 리뷰를 함으로써 수행될 수 있다. • 이상적으로는 훈련된 조정자(작성자가 아닌)에 의하여 주도된다. • 선 미팅 준비 (pre-meeting preparation) • 때때로 체크 리스트, 리뷰 리포트, 발견 사항의 리스트를 사용하고 관리자가 참여한다. • 실제로 상당히 비형식적인 것에서 부터 매우 형식적인 까지 다양하다. • 주요 목적 : 논의, 결정, 대안 사항의 평가, 결함(defect)의 발견, 기술적인 문제 해결, 명세와 표준의 준수 확인
점검 (Inspection)
주요 특성 • 훈련된 조정자(moderator)에 의하여 주도된다. • 동료에 의한 평가가 일반적이다. • 정의된 역할 • 특성(metrics)을 포함한다. • 항목(entry)과 종료 특성(exit criteria)을 가진 규칙(rules)과 체크 리스트(checklists)에 기반한 형식적인 프로세스 • 선 미팅 준비 (pre-meeting preparation) • 점검 보고서(Inspection report), 발견사항 리스트(list of findings) • 형식적인 사후 처리 프로세스 (formal follow-up process) • 때때로, 프로세스 향상과 리더(reader)가 필요하다. • 주요 목적 : 결함의 발견
3.2.4 리뷰의 성공 요소 (K2)
리뷰의 성공 요소는 다음을 포함한다.
• 각각의 리뷰는 명확하게 미리 정의된 목표를 갖는다. • 리뷰 목적에 맞는 적절한 인력이 포함되어야 한다. • 결함의 발견은 환영되어야 하며, 객관적으로 표현되어야 한다. • 사람들의 이슈사항과 심리학적인 측면을 다룬다.(e.g 작성자에게 긍정적인 경험으로 만든다.) • 리뷰 기법이 적용되며, 리뷰 기법은 소프트웨어 작업 산출물과 리뷰어의 레벨과 종류에 적합해야 한다. • 만약 결함 확인의 효과를 증가시키는데 적당하다면, 체크 리스트와 역할이 사용된다. • 리뷰 기술에 대한 훈련을 받는다. 특히 점검(Inspection)과 같은 매우 형식적인 기법에 대해서는 • 관리자가 옳바른 리뷰 프로세스를 지원한다. (e.g 프로젝트 리뷰 액티비티에 대한 적당한 시간을 짜 넣으므로써) • 학습과 프로세스 향상에 대하여 강조한다.
▪ SW 중간 산출물을 테스팅 하는 방법 - 프로그램 코드, 요구사항 명세서, 설계 명세서 - 테스트 계획서, 테스트 설계서, 테스트 케이스, 테스트 스크립트, 사용자 지침서 ▪ 소프트웨어 개발 생명주기의 앞부분에서 수행하여 결함제거가 저렴 ▪ 개발 생산성 향상, 개발 시간 단축, 테스팅 비용과 시간 단축 - 보다 적은 내재 결함 수와 향상된 의사소통으로 위 사항을 가능케 함 ▪ 테스팅 기법별로 다른 종류의 결함 발견(상호보완적) - 리뷰 : 코드 또는 문서상의 결함 발견 (Failure는 발견 못함) 표준과의 불일치성, 설계 결함, 유지보수의 불충분성, 인터페이스 명세 결함 - 정적분석 : 코드의 복잡도, 구문에러, Missing 파라미터, Dead 코드 등
◆ 리뷰(Review)의 필요성
▪ 테스팅 보다는 Review에서 결함을 발견하는 것이 더 효율적이다. ▪ 단위 테스트 후의 결함 제거에는 많은 비용이 필요하다.
◆ 리뷰(Review) 프로세스
▪ Formal 리뷰 구성 요소 - 높은 수준의 개발 프로세스 성숙도 - 법적 또는 제도적 요구사항이 있을 때 - 감사를 받고자 할 때 ▪ 리뷰의 다양한 목적(목적에 따라 리뷰 방식이 다름) -결함 발견, 이해도 증진, 토론과 의견일치에 의한 결정
◆ 리뷰(Review) 프로세스 단계
▪ 1. 계획활동 - 역할 분담, 시작/종료 기준 정의, 검토할 문서 설정 ▪ 2. 시작(Kick-off) - 문서 배포,목표/리뷰 프로세스/문서에 대한 설명, 시작 기준(조건) 확인 ▪ 3. 개별준비 - 잠재 결함을 체크, 회의에서 제기할 질문가 코멘트 준비 ▪ 4. 리뷰미팅 - 토론하고 기록함 (보다 formal한 경우 상세 회의록 작성) - 단순한 결함 체크-> 결함 대처안 제안 -> 결함 (처리)여부를 결정 (Inspection에서는 하지 말라고 하는 것 ) ▪ 5. 재작업(rework) - 발견한 결함 수정 (typically by the author) ▪ 6. Follow-up - 발견된 결함이 처리되었는지 확인, 매트릭 수집 & 확인, 리뷰 종료 기준 체크
◆ Fagan Inspection Process (7단계)
▪ 1. Planning - Inspection 할 산출물이 entry criteria를 만족함을 확인 - Inspector 역할 할당 (Moderator, Authoer, Reader, Tester) - 다음 4단계에 대한 일정 확보 - 2.4.5 단계를 위한 회의실 확보 ▪ 2. Overview - Inspection 팀이 preparation 단계를 잘 실행할 수 있도록 배경 설명, context, rationale에 대한 교육 실시 ▪ 3. Preparation - 각자 Inspection 할 산출물의 습득 - 각자 맞겨진 역할을 수행할 수 있도록 준비 - Defect로 단정 짓지 말고 Inspection 회의 시 질문 사항 기록 ▪ 4. Inspection meeting - Find Defect (defect 해결책 또는 개선책을 거론하지 말 것) ▪ 5. Process Improvement - 향후 defect 발견을 향상 시킬 수 있도록 1~4 단계 검토 - Systemmatic defect 식별과 Recommended fixes ▪ 6. Rework - 모든 발견된 defects 수정 및 조사항목 보완 ▪ 7. Follow-up - 모든 보완 사항과 해결책이 적합한가를 검증 (20% defects의 근본 원인이 bad fixes)
◆ Inspector 역할
▪ Moderator - 7단계의 Fagan Inspection Process 실행 동안 Inspection 팀을 Lead하며 본인도 Inspector의 역할 담당, 팀의 synergy를 자극하며 phantom inspector 효과를 이끌어 냄 - 자격 요건 : Fagan defect-free process를 잘 이해하며, Inspection 할 산출물을 작성할 수 있을 정도의 기술능력을 보유하고, 여러 사람과 협력하여 일을 추진할 수 있는사람 ▪ Author - Inspection 할 산출물의 작성자이며 동시에 적극적으로 Inspector 역할 담당 - 현재 상태에서 가능한 모든 defect를 발견하는 것이 가장 중요한 사람(방어태세 지양) ▪ Reader(Reviewer) - 보편적으로 본인의 업무가 inspection할 산출물에 크게 의존될 사람이 reader로 선정됨 - Inspection 회의 시 본인이 다음 단계 업무를 수행할 수 있는 정도의 관점과 이해력을 가지고 본인이 이해한 대로 각 statement를 설명함 ▪ Tester - 어떻게 시험할 것인가에 관점을 두어서 inspection 회의 시 질문
◆ Inspection의 주요 특징
▪ 주요 목적 : 결함 발견 ▪ 저자가 아닌 훈련된 Moderator에 의한 진행 및 제어 ▪ 주로 동료 검사 ▪ 역할이 정의되어 있음 ▪ 매트릭을 수집하고 활용함 ▪ 체크리스트와 규칙을 기반으로 하는 정식 프로세스 ▪ 미팅 전 준비 과정 거침 ▪ 인스펙션 리포트와 발견사항 리스트 산출 ▪ 정식적인 결함 수정 확인 ▪ 프로세스 개선(선택적)
◆ Walkthrough의 주요 특징
▪ 주요 목적 : 결함 발견, 학습, 시스템에 대한 이해 향상 ▪ 저자에 의한 진행 및 제어 ▪ 시나리오, dry run, 동료 그룹 ▪ Open-ended 세션 ▪ (선택적) 미팅 전 준비과정 거침(리뷰어, 리뷰 리포트, 인시던트 리스트, 서기 지정) ▪ 실무에서는 Informal 또는 Formal 하게 할 수 있음
3.3 Static analysis by tools (K2)
정적 분석(Static analysis)의 목적은 소프트웨어 소스 코드나 소프트웨어 모델에서 결함(defects)을 발견하는 것이다. 정적 분석은 도구에 의하여, 시험되어지는 소프트웨어의 실제적인 실행없이 수행된다. 동적 테스팅(dynamic testing)은 소프트웨어 코드를 실행시킨다. 정적 분석은 테스팅에서 발견하기 어려운 결함들의 위치를 알아낸다. 리뷰와 더불어, 정적 분석은 실패(failure)보다는 결함(defects)를 찾는다. 정적 분석 도구는 프로그램 코드를 분석(e.g 컨트롤 플로우와 데이터 플로우)하며, HTML과 XML과 같은 결과물을 생성한다.
정적 분석의 가치는 다음과 같다.
• 테스트 실행 이전 결점의 조기 감지 • 높은 복잡성(complexity) 측정과 같은 특성(metrics) 계산에 의한 코드 또는 설계의 의심스러운 측면에 대한 초기 경고 • 동적 테스팅에 의하여 쉽게 발견되지 않는 결함의 정의 • 링크와 같은 소프트웨어 모델에서의 의존성과 불일치성 감지 • 코드와 디자인의 유지보수성(maintainability) 향상 • 개발에서 배워진 교훈이 있다면, 결함의 방지
정적 분석 도구에 의하여 발견되는 전형적인 결점들은 다음을 포함한다.
• 정의 되지 않은 값을 가진 변수의 참조 • 모듈과 컴포넌트 사이의 일관적이지 않은 인터페이스 • 사용되지 않는 변수 • 실행할 수 없는(죽은) 코드 • 프로그래밍 표준 위반 사항 • 보안 취약성들 • 코드와 소프트웨어 모델의 구문 위반사항(syntax violations)
컴포넌트 테스팅과 통합 테스팅 하는 동안이나 그 이전에, 그리고 디자이너가 소프트웨어 모델링을 하는 동안에, 정적 분석 도구들은 일반적으로 (미리 정의된 규칙 혹은 프로그래밍 표준에 대한 확인을 위하여) 개발자에 의하여 사용된다. 정적 분석 도구는 가장 효과적인 도구의 사용을 위하여 제대로 관리되는 것이 필요한 많은 수의 경고 메시지를 만들어 낼 것이다.
컴파일러들은 특성의 계산(calculation of metrics)을 포함한 일부 정적 분석 기능을 지원할 수 있다.
1. Find defects in software source code and software models 2. Performed withtout actually executing the software being examined 3. Locates defects that are hard to find in testing 4. Finds failures rather than defects
◆ 정적 분석의 가치
▪ 테스트 수행전 결함 발견 ▪ 의심스러운 코드와 설계에 대한 조기 경보 (프로그램 복잡도 등의 매트릭을 계산해서...) ▪ 동적 테스팅에서 발견하기 어려운 결함 발견 ▪ 소프트웨어 모델에서의 의존성과 불일치성 발견 ▪ 코드와 설계의 유지보수성 향상 ▪ 결함 예방 (if lessons are learned in development)
◆ 정적 분석을 통해 발견되는 결함
▪ 정의되지 않은 값으로 변수 참조 ▪ 모듈과 컴포넌트 간에 일관되지 않은 인터페이스 ▪ 사용되지 않는 변수 ▪ 사용되지 않는 코드 (Dead Code) ▪ 코딩 표준 위반 ▪ 보안 취약성 ▪ 코드와 소프트웨어 모델의 syntax 위반
실제로 V모델에서는 소프트웨어 제품과 프로젝트에 따라서, 개발과 테스팅 레벨에 변화를 주거나 특정 레벨을 추가 또는 삭제 할 수도 있다. 예를 들어, 컴포넌트 테스트 후에 컴포넌트 통합 테스팅이 있을 수 있으며, 시스템 테스팅 후에 시스템 통합 테스팅이 있을수 있다.
개발 동안에 만들어진 소프트웨어 작업 산출물들(비지니스 시나리오 혹은 유스케이스, 요구사항 명세, 설계 문서, 코드)등은 때때로 하나 혹은 그 이상의 테스트 레벨에서의 테스팅의 기반이 된다. 일반적인 작업 산출물을 위한 참고에 CMMI나 'Software life cycle processes'(IEEE/IEC 12207)를 포함한다. 검증(Verification)과 유효성 검사(Validation) (그리고 초기 테스트 설계)은 소프트웨어 작업 산출물 개발 동안에 수행되어져야 한다.
2.1.2 반복 개발 모델(Iterative development models) (K2)
반복 개발은 요구사항 작업, 설계, 시스템의 구축과 테스팅 프로세스를 작은 개발의 시리즈로 행하는것이다. 반복 개발의 예로서는 프로토타입핑(Prototyping), RAD(Rapid Application Development), RUP(Rational Unified Process) 그리고 에자일(agile) 개발 모델이 있다. 반복동안에 만들어진 추가 부분은 개발의 한 부분으로써 여러가지 레벨에서 테스트 될 것이다.
이전에 개발된 다른 부분에 추가된, 점정 증가하는 부분적인 시스템을 형성하는, 추가 개발 부분 역시 테스트 되어야 한다.
회귀 테스팅(Regression testing)은 첫번째 반복 이후의 모든 반복에서 중요성이 증가한다. 검증(Verification)과 유효성 검사(Validation)은 각각의 인크리먼트(Increment)에서 수행되어야 한다.
2.1.3 개발 주기 모델에서의 테스팅(K2)
모든 개발 주기 모델에는, 좋은 테스팅의 몇가지 특성이 있다.
• 모든 개발 액티비티와 관련있는 테스팅 액티비티가 있다. • 각각의 레벨은 그 레벨에 맞는 테스트 목표를 가진다. • 주어진 레벨에 대한 테스트의 분석과 설계는 관련된 개발 액티비티 동안에 시작되어야 한다. • 개발 수명 주기 모델에서 문서들의 배포판들이 이용가능하게 되면, 문서 리뷰시 반드시 테스터들이 포함되야 한다.
테스트 레벨들은 시스템 아키텍쳐나 프로젝트의 본질에 의존하여 조합되거나 재조직되어야 한다. 예를 들어, 사용 소프트웨어 제품의 시스템의 통합을 위해, 구매자는 시스템 레벨의 통합 테스트(예를 들어 다른 시스템과 기반 구조(Infrastructure)에 대한 통합 혹은 시스템 배치(Deployment))와 승인 테스트(기능/비기능 테스트, 그리고 사용자/운영 테스팅)를 수행해야 한다.
명시된 요구사항들을 만족하는지 여부를 확인하기 위해 개발단계 말이나 중간에 구성요소나 시스템을 평가하는 프로세스(IEEE/ANSI) * 특징 :
컴퓨터 기반 테스팅(Compoter-Based Testing) - 실제적으로 소프트웨어를 실행한다.
* 종류 :
하위 레벨 테스팅 (Low-Level-Testing)과 상위 레벨 테스팅(High-Level-Testing) - 하위 레벨 테스팅 - 단위 테스팅(Unit Testing)과 통합 테스팅(Integration Testing) - 상위 레벨 테스팅 - 사용성 테스팅(Usability Testing), 기능 테스팅(Function Testing), 시스템 테스팅(System Testing), 인수 테스팅(Acceptance Testing)
Verfication
* 정의 :
개발 단계의 산출물이 그 단계의 초기에 설정된 조건을 만족하는지 여부를 결정하기 위해 구성 요소나 시스템을 평가하는 프로세스 (IEEE/ANSI) , 본격적인 구축(Implementation) 단계 이전에 요구사항 명세서, 설계 명세서, 코드등과 같은 산출물을 대상으로 평가(Evaluating), 검토(Reviewing) 점검(Inspecting)등을 하는 프로세스 * 특징 :
인간에 의한 테스팅(Human Testing) - 주로 산출물 위주의 검토 형태 * 종류 :
점검(Inspection), 워크스루(Walkthrough), 동료에 의한 검토(Buddy Checks)
각각의 테스트 레벨에 대하여 다음의 것들이 정의될 수 있다.: 테스트 레벨의 일반적인 목표들, 테트 케이스를 유도하기 위하여 참조되는 작업 산출물(e.g 테스트 기반), 테스트 목표(예를 들어 무엇이 테스트 되어야 하는가?), 발견되어야 하는 일반적인 결점(defects)과 실패(failures), 테스트 설비 요구사항과 도구 지원, 그리고 특정 테스트 방법과 책임들
2.2.1 컴포넌트 테스팅(Component Testing) (K2)
컴포넌트 테스팅은 개별적으로 테스트가능한 소프트웨어(예를 들어, 모듈, 프로그램, 객체, 클래스 등)안의 결점을 찾고, 기능을 검증한다. 컴포넌트 테스팅은 시스템의 나머지 부분과 고립되어 실행되며, 개발 생명 주기와 시스템의 내용(context)에 의존한다. 스텁(stub), 드라이버(drivers) 그리고 시뮬레이터(simulators)가 사용될 수 있다.
컴포넌트 테스팅은 기능적인 특성과 자원의 작용(예를 들어, 메모리 누수)과 같은 비기능적인 특성이나 견고성(robustness) 테스팅, 구조적인(structual) 테스팅(예를 들어 브랜치 커버리지)도 포함할 수 있다. 테스트 케이스들은 컴포넌트 명세(specification), 소프트웨어 설계(design) 혹은 데이터 모델과 같은 작업 산출물로부터 유도된다.
일반적으로, 컴포넌트 테스팅은 실제로 테스트 되는 코드를 가지고 단위 테스트 프레임윅(unit test framework) 혹은 디버깅 도구 같은 개발 환경의 지원하에 하며, 일반적으로 코드를 작성한 프로그래머를 포함시킨다. 결점(defects)들은 부가사항(incident)의 기록없이(기록할 필요 없이) 발견 되자마자 바로 수정된다.
컴포넌트를 테스팅하는 한가지 방법은 코딩전에 테스트 케이스를 준비하고 자동화시키는 것이다. 이것은 테스트 우선 접근방법(test-first approach) 혹은 테스트 주도 개발(test-driven development)이라 불린다. 이러한 접근 방법은 매우 반복적이며 테스트 케이스 개발의 주기(cycle)에 기반한다. 따라서 작은 코드의 조각들을 생성하고 통합하고 그들이 패스할 때까지 컴포넌트 테스트를 실행한다.
2.2.2 통합 테스팅(Integration Testing) (K2)
통합 테스팅은 컴포넌트들 사이의 인터페이스, 운영 시스템, 파일 시스템, 하드웨어나 시스템 사이의 인터페이스와 같은 시스템의 여러 부분에 대한 상호작용(interactions)을 테스트한다.
한 단계의 이상의 통합 테스팅이 될 수(하나 이상의 통합 테스팅 단계가 있을 수) 있으며 다양한 크기의 테스트 객체에 대하여 수행될 수 있다.
예를 들어;
• 컴포넌트 통합 테스팅은 소프트웨어 컴포넌트 사이의 상호작용을 테스트한다. 그리고 컴포넌트 테스팅 후에 행해진다. • 시스템 통합 테스팅은 여러가지 시스템 사이의 상호작용을 테스트하며 시스템 테스팅 후에 행하여진다. 이러한 경우, 개발 조직은 인터페이스의 한쪽만 통제하기 때문에 변경사항은 불안정 해질수 있다. 비즈니스 프로세스(business processes)는 시스템의 시리즈에 포함 될 수 있는 워크플로(workflow)로써 구현된다. 교차 플랫폼 문제가 중요해질 수 있다.
통합되는 범위(scope)이 커질수록, 특정 시스템이나 컴포넌트로부터 위험을 증가시킬 수 있는 실패들(failures)을 고립(isolate)시키는 것이 더욱 어려워진다.
시스템적인 통합 전략들은 시스템 아키텍쳐(하향식과 상향식), 기능적인 작업, 트랜잭션 프로세싱 시퀀스, 시스템 혹은 컴포넌트의 다른 측면들에 기반을 둘 수 있다. 늦은 결점 발견의 위험을 줄이기 위하여 통합은 한번에 모든 것을 끝내는 것(big-bang)보다는 일반적으로 점증적이어야한다.
특정 비기능적인 특성들(예를 들어 성능)의 테스팅은 통합 테스팅에 포함될 수 있다.
각각의 통합 단계에서, 테스터들은 오직 통합 그 자체에만 집중해야한다. 예를 들어, 테스터들이 모듈 A를 모듈 B와 통합한다면, 그들은 이 모듈들 사이의 커뮤니케이션을 테스팅하는데 관심을 가져야하며, 각각의 모듈의 기능에 관심을 가지면 안된다. 기능적인 접근 방법과 구조적인 접근 방법 모두 사용될 수 있다.
이상적으로, 테스터들은 아키텍쳐와 통합 계획에 영향을 주는 것을 이해하여야 한다. 만약 컴포넌트나 시스템들이 구축되기 전에 통합 테스트가 계획된다면, 테스터들은 가장 효과적인 테스팅 순서를 정할수 있다.
2.2.3 시스템 테스팅(System Testing) (K2)
시스템 테스팅은 개발 프로젝트나 프로그램의 범위에 의하여 정의된 전체 시스템/제품의 행위에 관심을 둔다.
시스템 테스팅에서, 테스트 환경은 환경으로 인한(environment-specific) 실패의 위험이 발견되지 않도록 가능한한 최종 타켓이나 생산 환경과 연관되어야 한다.
시스템 테스팅은 요구사항 명세, 비즈니스 프로세스, 유스케이스, 혹은 시스템 행위의 상위 레벨의 묘사, 운영 시스템과의 상호작용 그리고 시스템 자원이나 위험에 기반한 테스트들을 포함한다.
시스템 테스팅은 시스템의 기능요구사항과 비기능 요구사항 모두를 반드시 조사해야 한다. 요구사항은 텍스트와/혹은 모델들로 존재할 수 있다. 또한 테스터들은 불완전하거나 문서화되지 않은 요구사항도 다루어야 할 필요가 있다. 시스템의 기능 요구사항 테스팅은 테스트 되어야 하는 시스템 측면에 대한 가장 적당한 규격 기반(블랙박스) 기술을 사용하여 시작한다. 예를 들어, 의사 결정 테이블(decision table)은 비즈니스 규칙들에 설명된 효과의 조합들을 위해 만들어 질 수 있다. 그런 다음, 메뉴 구조나 웹 페이지 네비게이션과 같은 구조 기반의 기술(화이트 박스)은 구조적인 요소의 측면에서 테스팅한 성능을 평가하는데 사용될 수 있다. (See Chapter 4)
독립적인 테스트 팀이 종종 시스템 테스팅을 수행한다.
2.2.4 승인 테스팅(Acceptance Testing) (K2)
승인 테스팅은 주로 시스템의 사용자나 고객의 책임이다. 물론 다른 이해당사자가 포함될 수 있다. 승인 테스팅의 목적은 시스템, 시스템의 부분이나 시스템의 특정 비기능적인 특성들에 대한 확신을 갖는 것이다. 결점을 발견하는 것이 승인 테스팅의 중점사항은 아니다. 승인 테스팅은 비록 절대적으로 시스템의 최종 단계의 테스팅은 아니지만, 시스템의 사용과 배치를 위한 시스템의 준비정도를 평가할 수 있다. 예를 들어, 대규모 시스템의 통합 테스팅은 시스템에 대한 승인 테스팅 다음에 할 수 있다.
승인 테스팅은 단일 테스트 레벨보단 여러 레벨에서 일어날 수 있다. 예를 들어
• 상용 소프트웨어 제품(COTS software product)은 설치되거나 통합되기 전에 승인 테스팅을 받을 수 있다. • 컴포넌트의 가용성(usablity) 승인 테스팅은 컴포넌트 테스팅 동안에 행해질 수 있다. • 새로운 기능 향상을 위한 승인 테스팅은 시스템 테스팅 전에 행할 수 있다.
승인 테스팅의 전형적인 형식은 다음을 포함한다.
사용자 승인 테스팅(User acceptance testing) 일반적으로 비즈니스 사용자에 의하여 시스템의 사용에 대한 적합성(fitness)을 검증한다.
운영 (승인) 테스팅 (Operational (acceptance)testing) 시스템 관리자에 의하여 행하여지는 시스템의 승인 테스팅은 다음을 포함한다.
• 백업과 복원(restore)의 테스팅 • 재난시 복구(recovery) • 사용자 관리 • 관리 작업 • 주기적인 보안 취약점의 확인.
계약, 규정 승인 테스팅 (Contract and regulation acceptance testing)
계약 승인 테스팅은 맞춤형으로 개발된 소프트웨어에 대하여 생산된 계약자의 승인 특성(acceptance criteria)에 대하여 수행된다. 규정 승인 테스팅은 정부나 법률 혹은 안전 규정과 같은 반드시 지켜야 하는 모든 규정(regulations)에 대하여 수행된다.
알파, 베타(또는 필드) 테스팅 (Alpha and beta (or field) testing)
시장제품, 상용제품, 또는 소프트웨어의 개발자는 때때로 시장에 소프트웨어 제품을 상업적으로 판매하기에 앞서, 잠재고객이나 기존의 고객들로부터 피드백을 받기를 원한다. 알파 테스팅은 개발 조직의 사이트에서 수행된다. 배타 테스팅 혹은 필드 테스팅은 사람들에 의하여 그들이 있는 장소에서 수행된다. 두가지 제품의 개발자가 아니라 모두 잠재적인 고객에 의해여 수행된다. 여러 조직들에서는 고객 사이트에 이동하기 전과 후에 테스트 되어야 하는 시스템에 대하여 제조 승인 테스팅(factory acceptance testing)과 사이트 승인 테스팅(site acceptance testing)과 같은 다른 용어를 사용할 수 있다.
▪ 한번에 총체적으로 조직화되고 관리되는(하는) 테스트 활동 - Unit, Integration, System, Acceptance Test Level - SW/HW 모두 포함한다. ▪ 독립적 테스트 계획 ▪ 독립적으로 테스트 된다. ▪ 독립적 테스트 환경
알파 릴리즈
몇몇 주요 고객 또는 마케팅 시연 목적으로 제한된 숫자만 배포되는 초기 빌드. 실제 사용을 위해 제작된 빌드는 아니다. 알파 릴리즈를 사용하게 될 사용자는 빌드의 정확한 컨텐트와 제한된 품질 수준을 이해하고 있어야 한다.
베타 릴리즈
잠재적 고객에게 광범위하게 배포되는 공식적인 빌드. "버그 파티 및 베타 테스트"에서 베타 테스트를 수행하는 특정한 이유를 정의해야 한다는 점을 기억하라
테스팅은 소프트웨어 개발 공정 중에서 가장 노력과 비용이 집중적으로 투자되는 작업으로 기능과 성능을 확인하는 작업이다. 일반적으로 오류의 종류와 프로그램이 비교 테스트되는 기준에 따라 단위 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅과 같은 네가지 성격의 테스팅 방법이 있다.
1. 단위 시험 (Unit Testing, Component Testing)
단위 시험은 소프트웨어 설계의 기본 단위인 모듈 내부적인 오류를 발견하기 위한 시험이다. 단위 시험은 화이트 박스 방식과 블랙 박스 방식으로 수행할 수 있으며 일반적으로 화이트 박스 중심의 시험을 사용한다.
단위 시험시 결과 테이터 구조에 대한 조사, 제어 흐름에 정확성에 대한 조사, 최대점, 최소점 바로 위와 아래의 데이터 값들의 조사하는 테스트 케이스들은 오류를 쉽게 발견할 수 있다는 것을 알 수 있다. 모듈은 독립형 프로그램이 아니기 때문에 시험시 드라이버나 스텁이 필요하다. 그러나 드라이버와 스텁은 개발될 소프트웨어에 포함될 사항이 아니므로 시험시의 오버헤드에 해당한다. 하지만 오버헤드를 줄이기 위해 간단하게 드라이버와 스텁을 구성하는 것은 적절한 시험을 불가능하게 한다.
▪ 하나의 소프트웨어 모듈이 정상적으로 기능을 수행하는지의 여부를 테스트
▪ 원시 코드를 시험 대상으로 하며 주된 테스트 방법은 화이트 박스 테스트임
▪ 단위 프로그램별로 설계서 상에 정의된 기능을 제대로 수행하는지 검증
▪ 해당 개발자에 의해서도 수행될 수 있으나 타개발자나 3자에 의해서도 실시
▪ 개발 과정에서 수행하는 테스트
▪ 소프트웨어 각각의 단위(모듈)을 다른 부분과의 연계성을 고려치 않고 격리하여 테스트
목적
▪ 기본적 패스(path)를 확인
▪ 모든 에러 핸들링 패스를 확인
▪ 모듈 인터페이스 확인
▪ 로컬 데이터 확인, 경계값 확인
◆ 단위 테스트 기법 - Control flow 테스트
- Condition decision (branch)
- 커버리지 테스트 (Elementary comparison test)
- 등가 분할 & 경계값 테스트
◆ 단위 테스트 완료 조건 ▪ AI(Application Integrator)가 통합 테스트로의 entry criteria를 만족시켰다고 판단하는 경우 (품질 수준을 개발 프로젝트 리더, 팀 리더가 결정) - 기 결정한 테스트 커버리지 달성 - 특정 테스트 기법 사용 확인 - 단위 테스트 케이스와 결과 검토 및 워크스루를 통해 결정 ▪ QA enterance 조건을 만족시킴 (통합테스트와 단위테스트를 구별하지 않는 경우) ▪ 개발 관리자가 완료로 결정함(일반적인 경우)
2. 통합 시험
각 모듈들에게 서비스를 요청하고 그 결과를 정확하게 연결시켜 주는 부분의 역할이 중요하다. 문제점은 모든 모듈을 하나로 만드는 인터페이싱이다. 통합 시험은 이와 같은 인터페이싱과 관련된 오류를 발견하는 시험을 수행하고 동시에 프로그램 구조를 구성하는 체계적인 기법이다. 이 시험의 목적은 모듈이 시험한 단위를 택하여 설계에서 지시한 프로그램 구조로 구성하는 것이다.
모든 모듈을 사전에 미리 결합하고 전체 프로그램을 하나로 시험하게 되면, 대단히 혼란스러운 결과가 나타나고 많은 오류가 발생한다. 전체 프로그램이 광범위해서 생기는 여러 원인을 제거하는 작업이 복잡하기 때문에 수정 작업도 어렵다. 일단 이러한 오류들이 수정되면, 새로운 오류들이 나타나고 끝도 없이 이러한 과정이 지속된다. 이와 같은 문제점을 제거하기 위해서는 체계적인 접근이 필요하며 조금씩 통합하고, 통합 후 시험하는 작업을 반복하는 것이 현명한 방법이 된다. 점증적 통합(Incremental Integration)을 이용하여 프로그램을 작은 단위로 추가해가면 시험해 나가면 오류를 정확히 찾아낼 수 있으며, 수정하는 것도 쉽고, 인터페이스를 완벽하게 시험할 수 있어서 체계적인 시험 접근법을 적용시킬 수 있다.
▪ 시스템이나 시스템 구성요소(component) 또는 소프트웨어 프로그램의 데이터 및 기능의 인터페이스가 정상적으로 작동하는지에 중점을 두고 수행하는 테스트 ▪ 단위 테스트들 통과한 개발 소프트웨어/하드웨어 컴포넌트(모듈)간 인터페이스 및 연동 기능 등을 구조적으로 접근하여 테스트 하는 방법 ▪ 개발자가 효과적(effective)으로 테스트 할 수 있는 방법 단위 테스트로 개발자가 테스트에 흥미를 잃을 수 있음 ▪ 테스트 라이프사이클에서 단위 레벨과 시스템 레벨의 중간 레벨을 테스트
◆ 통합 테스트 종류
- 빅뱅 통합 - Bottom up 통합 - Top down 통합 - 백본 (Backbone) 통합 - 중심(Central) 통합, 협업(Collaboration) 통합, 계층(Layer) 통합, C/S 통합
3. 시스템 시험
소프트웨어는 대형 컴퓨터 시스템의 하나의 요소일 뿐이다. 소프트웨어는 다른 시스템 요소인 하드웨어, 정보들과 통합되어 일련의 시스템 통합과 검증 시험이 수행된다. 이러한 시험은 소프트웨어 개발자가 단독으로 수행하는 것이 아니다. 그러나 소프트웨어 설계와 시험동안에 수행된 단계들은 대형 시스템에서 성공적인 시스템 통합의 가능성을 크게 향상시킨다.
시스템 시험은 컴퓨터 시스템을 완벽하게 검사하는 주요 목적을 가진 일련의 또 다른 시험 방법이다. 비록 시험이 다른 목적을 갖고 있어도 모든 작업은 모든 시스템 요소가 적절히 통합되고 할당된 기능을 수행하는지를 검증한다.
▪ 실 사용 환경과 동일한 모의 시스템을 구성 ==> Environment Specific failure을 일으킬 risk를 최소화 ▪ 시스템 성능과 관련된 고객의 요구사항이 완벽하게 수행되는지를 테스트 ▪ 시스템 시험을 성공적으로 수행하기 위해서는 성능 요구사항을 명확히 하여야 함 ▪ 현장에서 적용 가능한 시스템 테스트: 스트레스 테스트와 볼륨 테스트 ▪ 단위/통합 시험이 완료되어 기능상 문제가 없는 상태여야 함 ▪ 개발 조직과 테스트 조직이 원활히 정보를 공유하고 협력하여야 함
◆ 시스템 테스팅의 기반 - 요구사항 명세서
(요구사항은 주로 텍스트 또는 모델의 형태로 존재하지만 불완전하고 문서화하지 않은 요구사항이 대부분이다.) - 리스크 분석 결과 - 비지니스 절차 - 유스케이스 - 상위 레벨의 시스템 행동 기록 문서 - OS, 시스템 리소스와의 상호작용
◆ 시스템 테스팅은 기능적 요구사항과 비기능적 요구사항을 커버
▪ 기능적 요구사항 테스트 기법 - 명세 기반 기법(Black-box) : Decision Table ▪ 비기능적 요구사항 테스트 기법 - 구조기반 기법(White-box) : 메뉴 구조 또는 웨 페이지 네비게이션 등의 구조적 요소에 대한 테스팅 커버리지(thoroughness) - 성능 테스트 - 보안 테스트
4. 인수 시험
주문 소프트웨어가 고객을 위하여 구축된 경우, 고객의 모든 요구사항을 만족하는지 확인하도록 하는 인수 시험(Acceptance test)가 수행된다. 인수 시험은 시험 드라이브에서 계획적이고 체계적으로 수행되는 일련의 시험까지 포함되어 실시된다. 대부분의 소프트웨어 개발자는 최종 사용자만이 찾을 수 있는 오류를 발견하기 위하여 알파 테스트와 베타 테스트를 수행한다. 알파 테스트는 고객이 개발자의 위치에서 실행하는 시험이다. 이때 소프트웨어 개발자가 참여하여 오류와 사용법 문제를 기록하면서 사용자에게 도움을 줄 수 있는 통제된 환경에서 수행된다. 반면에 베타 테스트는 개발자가참여하지 않은 상황에서 실질적으로 프로그램을 실행하여 사용하는 환경에서 수행된다. 고객은 베타 시험에서 발생한 문제를 기록하여 개발자에게 보고하고, 개발자는 이를 바탕으로 소프트웨어를 수정한다.
▪ 계약상의 요구 사항이 만족되었는지를 확인하기 위해, 설치 후 구입자 운영 환경에서 납품자도 참가하여 구입자에 의하여 실시되는 시스템 또는 기능 단위의 공식 테스트 ▪ 이 결과를 기초로 고객(구매자)이 개발된 시스템을 인수할 것인지를 결정
여러 종류의 테스트 액티비티들의 목적은 특정 이유나 테스팅의 대상에 기반한 소프트웨어 시스템(또는 시스템의 일부분)을 검증하는 것이 이다.
한 테스팅의 타입은 특정한 테스트 목표에 초점을 두며, 소프트웨어에 의하여 수행되어야 하는 기능을 테스팅할 수 있다 - 신뢰성(reliability)또는 가용성(usability)와 같은 비기능적인 특성들, 또는 소프트웨어나 시스템의 아키텍쳐(architecture)나 구조(structure), 또는 관련된 변경사항들, 예를 들어 결함(defect)가 고쳐졌다는 다는 것을 확인하는 것 (확인 테스팅)과 의도되지 않은 변경 사항을 찾는 것(회귀 테스팅)등을 테스팅 할 수 있다.
소프트웨어의 모델은 개발될 수 있으며 구조적 테스팅(structural testing)과 기능적 테스팅(functional testing)에 사용될 수 있다. 기능 테스팅에서의 프로세스 플로우 모델(process flow model), 상태 전이 모델(state transition model) 또는 일반적인 언어 명세, 그리고 구조적인 테스팅에서의 컨트롤 플로우 모델(control flow model) 또는 메뉴 구조 모델(menu structure model)을 예로 들 수 있다.
2.3.1 기능 테스팅 (functional testing) (K2)
시스템, 서브 시스템, 또는 컴포넌트의 기능(function)이 수행하여야 하는 것은 요구사항 명세, 유스케이스 또는 기능 명세나 문서화되지 않은 무엇과 같은 작업 산출물(work product)에 설명되어 있을 수 있다. 이러한 기능들(functions)들은 시스템이 무엇(what)을 하는가 이다.
기능 테스트들은 (문서에 기술되어 있거나 테스터에 의하여 이해된) 이러한 기능(functions)과 특성(features)에 기반하며, 모든 테스트 레벨에서 수행되어 질 수 있다. (예를 들어, 컴포넌트에 대한 테스트는 컴포넌트 명세에 기반할 수 있다.)
소프트웨어나 시스템의 기능으로 부터 테스트 조건(test conditions)과 테스트 케이스를 유도하는데에 명세 기반 기법들(specification-based technique)이 사용될 수 있다. (4장을 보라). 기능 테스팅은 소프트웨어의 외부적인 동작을 고려한다. (블랙 박스 테스팅)
기능 테스팅의 한 타입인 보안 테스팅(security testing)은 악의적인 외부(mailcious outsiders)로 부터의 바이러스와 같은 위협의 감지와 관련된 기능을 조사한다.
2.3.2 소프트웨어 제품 특성의 테스팅 (non-functional testing) (K2)
비기능 테스팅(Non-functional testing)은 성능 테스팅(performance testing), 부하 테스팅(load testing), 스트레스 테스팅(stress testing), 사용성 테스팅(usability testing), 상호연동 테스팅(interoperability testing), 유지보수성 테스팅(maintainability testing), 그리고 이식성 테스팅(portability testing)을 포함하지만, 이러한 것들에 의하여 제한되지는 않는다. 이것은 시스템이 어떻게(how) 동작하는가에 대한 테스팅이다.
비기능 테스팅은 모든 테스팅 레벨에서 수행될 수 있다. 비기능적인 테스팅이란 용어는 성능 테스팅에서의 응답 시간(response time)과 같이 다양한 규모의 수량화(quantified) 될 수 있는 시스템과 소프트웨어의 특성들의 측정을 요구하는 테스트를 말한다. 이러한 테스트들은 "소프트웨어 공학-소프트웨어 제품 품질"(ISO 9126)에 정의된 것과 같은 품질 모델(Quality Model)을 참조할 수 있다.
2.3.3. 소프트웨어 구조/아키텍쳐의 테스팅 (structure testing) (K2)
구조 테스팅(화이트 박스)은 모든 테스트 레벨에서 수행될 수 있다. 구조적인 기법들(structural techniques)은 한 종류의 구조의 커버리지 측정을 통하여 테스팅이 완벽한가를 측정하기 위하여 명세 기반 기법(specification-based technique) 다음으로 가장 많이 사용된다.
커버리지(Coverage)는 테스트 슈트(test suite)에 의하여 테스트 된 구조의 범위로, 처리된 항목의 퍼센티지(%)로 표현된다. 만약 커버리지가 100%가 아니라면, 더 많은 테스트들이 테스트에서 빠진 항목의 테스트를 위하여 설계되어야 한고 이러한 방식으로 커버리지가 증가한다. 커버리지 기법들은 4장에서 처리한다.
모든 테스트 레벨에서, 특히 컴포넌트 테스팅과 컴포넌트 통합 데스팅에서 문장(statements)이나 분기(decisions)와 같은 요소들의 코드 커버리지를 측정하는데 도구를 사용할 수 있다. 구조적인 테스팅은 호출 계층 구조(calling hierachy)와 같은 시스템의 아키텍쳐에 기반을 둘 수 있다.
구조적인 테스팅 접근 방법은 시스템, 시스템 통합 또는 승인 테스트 레벨에도 역시 적용할 수 있다. (예를 들어 비지니스 모델이나 메뉴 구조)
2.3.4 변경 사항에 관련된 테스팅(confirmation and regression testing)
결함이 검출되고 고쳐진 다음, 소프트웨어는 반드시 원래의 결점이 성공적으로 제거되었는지 확인하기 위하여 다시 테스트되어야 한다. 이것을 확인 테스팅(confirmation testing)이라고 부른다. 디버깅(결점의 수정)은 개발 액티비티이지, 테스팅 액티비티가 아니다.
회귀 테스팅(regression testing)은 이미 테스트된 프로그램을 변경(modification)후에 변경(들)의 결과로 커버되지 않았거나 발견되지 않은 결점을 발견하기 위하여 반복해서 테스팅하는 것이다. 이러한 결점들은 테스트 된 소프트웨어 내에 있거나 다른 연관된 소프트웨어 컴포넌트나 연관되지 않은 소프트웨어 내에 있을 수 있다. 회귀 테스팅은 소프트웨어나 환경(environment)이 변경되었을 때 수행된다. 회귀 테스팅의 확장은 이전 부터 동작해 왔던 소프트웨어 내의결점을 발견하지 못하는 위험(risk)에 기반한다.
확인 테스팅을 사용하고, 회귀 테스팅을 지원하기 위해서는 테스트는 반복적이어야 한다.
회귀 테스팅은 모든 테스트 레벨에서 수행될 수 있다. 그리고 기능, 비기능, 구조적 테스팅에 적용된다. 회귀 테스트 슈트(regression test suite)는 여러 번 수행되고 일반적으로 천천히 진화된다. 따라서 회귀 테스팅은 자동화를 위한 강력한 후보이다.
블랙 박스 테스트(Black-Box test)와 화이트 박스 테스트(White-Box test)
블랙 박스 테스트에서 테스터는 소프트웨어가 가져야할 기능을 알고 있지만, 이 기능이 어떻게 작동되는지는 볼 수 없다. 어떤 내용을 입력 했을 때 특정 출력을 얻게 되지만 테서트는 작동 원리와 이유에 대해서는 모르고 있다. 블랙 박스 테스트에서는 소프트웨어가 어떤 과정을 거쳤는지는 중요하지 않다. 결과만이 중요하다.
화이트 박스 테스트에서 소프트웨어 테스터는 프로그램의 코드에 접근하여 결과에 대한 원인을 살펴볼 수 있다. 조사한 결과에 기초하여 테스터는 특정 종류의 입력에서 오류가 발생할 가능성이 있는지 없는지에 대한 여부를 판단하고 이 정보에 따라 테스트를 수행할 수 있다.
정적 테스트(Static test)와 동적 테스트(Dynamic test)
정적 테스트는 실행 중이 아닌 제품을 테스트하는 것, 즉 조사하거나 검토하는 것을 뜻한다.
동적 테스트는 우리가 흔히 테스트 작업 이라고 생각하는 것, 즉 소프트웨어를 실행한 다음 테스팅하는 것을 뜻한다.
◆ Quality Model
▪ Functionality (기능성) : 규정된 기능 및 성능을 정확하게 충족시키는 능력 ▪ Reliability (신뢰성) : 고장없이 성능 수준을 지속적으로 유지시키는 능력 ▪ Usability (사용성) :사용자가 쉽게 이해하고 배울 수 있게 하는 능력 ▪ Efficieny (효율성) : 부하변동에 대한 자원의 효율적인 운영 능력 ▪ Maintainability (유지보수성) : 소프트웨어의 수정, 개선을 용이하게 하는 능력 ▪ Portability (이식성) : 다양한 운영 환경에 적응할 수 있는 능역
◆ 테스트 종류
▪ 기능 테스팅 ▪ 비기능 테스팅 ▪ 구조적 테스팅 (Testing of SW structure/architecture) ▪ 확인/회귀 시험 (Testing related to changes)
◆ 기능 테스팅 (Functional Testing)
▪ 소프트웨어 기능 중심의 테스팅 ▪ 테스트 케이스 (대부분을 차지함) - 메뉴, 사용자 매뉴얼 챕터 제목이나 목차에서 기능 추출 - 각각의 기능에 대해 기준, 출력, 내부 조건, 내부 상태를 파악하여 테스트 케이스 작성
◆ 비기능 테스팅 (Non-functional Testing)
▪ 소프트웨어 제품 특성을 테스팅 ▪ 성능 테스팅, 부하 테스팅, 스트레스 테스팅 ▪ 사용성 테스팅 ▪ 호환성 테스팅, 유지보수 테스팅, 신뢰성 테스팅, 이식성 테스팅 ▪ 보안성 테스팅
◆ Stress, Load, Performance Testing
▪ 스트레스 테스트 - 시스템을 의도적으로 규정된 한계치 이상의 스트레스를 가하는 테스트 - 시스템이 다운될 때까지 스트레스를 가하여 최대로 견디는 지점 파악 - 시스템이 설계된대로 복원하는지 확인 ▪ 부하 테스트 - 실제 환경을 가정하고 일반적으로 부하의 최대치를 발생시켜 시스템이 안정적으로 작동하는지를 확인하는 테스트 ▪ 성능 테스트 - 비지니스 사용자가 기 정의한 성능 기대 레벨과 비교하여 측정하는 시험 - 일반적으로 모든 성능 관련 테스트를 총칭하는 용어로 쓰임
소프트웨어 시스템은 한번 배치되면(deployed), 종종 수년이나 수십년 동안 운용된다. 이 기간 동안에 시스템과 시스템의 환경은 자주 수정되고(corrected), 변경되거나(changed) 확장된다(extended). 유지보수 테스팅(Maintenance testing)은 기존의 운영되는 시스템에서 행하여지며, 소프트웨어 시스템의 변경(modification), 이전(migration) 혹은 퇴역(retirement)에 의하여 유발된다.
변경(Modification)은 계획된 성능 향상을 위한 변경(e.g 릴리즈에 기반한), 수정(corrective)에 의한 변경사항과 긴급한 변경사항, 그리고 계획된 운영 시스템이나 데이터베이스의 업그레이드, 새로 나타나거나 발견된 운영 시스템의 취약성에 대한 패치와 같은 환경의 변경을 포함한다.
이전(Migration)(e.g 한 플랫폼에서 다른 플랫폼으로)을 위한 유지보수 테스팅은 반드시 변경된 소프트웨어는 물론 새로운 환경에 대한 운영 테스트를 포함하여야 한다.
퇴역(retirement)하는 시스템에 대한 유지보수 테스팅은 긴 시간의 데이터 유지기간이 필요하다면 테이터 이전 혹은 저장에 대한 테스팅을 포함할 수 있다.
무엇이 변경되었는지에 대한 테스팅에 더하여, 유지보수 테스팅은 변경되지 않은 시스템의 부분들에 대한 대규모의 회귀 테스팅을 포함한다. 유지보수 테스팅의 범위(scope)는 기존 시스템의 크기(size)와 변경의 위험(risk)과 관련된다. 변경에 종속되어, 유지보수 테스팅은 모든 테스트 레벨에서 행하여 질 수 있으며, 일부 혹은 모든 테스트 종류에 대하여 행하여 질 수 있다.
변경 사항에 의하여 기존의 시스템이 어떻게 영향을 받는가를 결정하는 것은 영향 분석(impact analysis)라고 부른다. 그리고 영향 분석은 얼마나 많은 회귀 테스팅을 해야 하는가를 결정하는 것을 돕는다.
만약 명세서(specifications)들이 오래 되었거나 분실되었다면, 유지보수 테스팅은 어려워 질 수 있다.
왜 나의 하루는 항상 똑같을까? 왜 나는 내일의 행복보다는 오늘의 달콤한 유혹 앞에 머뭇거리고 있을까? 이런 고민에 빠진 사람들을 위해 당대 최고의 동기부여가인 저자가 꿈과 용기의 시간으로 독자들을 초대한다. 이 책은 성공의 마시멜로를 찾아 떠난 찰리와 조나단의 감동 스토리를 통해 오늘 무엇을 할 것인지에 따라 내일의 행복이 결정된다는 점을 일깨워준다. 적당한 ‘만족’과 ‘타협’이 가져다주는 은밀한 유혹에 빠져 하루하루를 살아가고 있는 사람들에게 평범한 ‘오늘’을 특별한 ‘내일’로 만드는 소중한 지혜를 전해 줄 것이다.
저자 : 호아킴 데 포사다
세계적인 대중연설가이자 자기계발 전문가인 그는 대표작인 『마시멜로 이야기』를 통해 전세계 수많은 기업과 독자들의 삶을 아주 특별하게 바꾸고 있다. 그의 e메일 박스는 세계 곳곳에서 보내오는 감동과 칭찬의 메시지로 가득 차 있다. 사람들의 ‘내일’을 꿈과 용기의 시간으로 변화시킨 그는 당대 최고의 동기부여가이자 탁월한 이야기꾼임에 틀림없다.
그의 대표작 『마시멜로 이야기』는 '성공'에 대한 지혜로운 성찰을 다룬 책이다. 마시멜로의 실험 결과를 통해 삶의 행복과 성공의 진정한 의미를 전하면서 독자로 하여금 성공을 향한 꿈과 용기와 열정, 그리고 실천에 대해 깊이 생각해볼 수 있는 기회를 제공한다. 안일한 만족과 나태함으로 하루하루를 살아가고 있는 사람들에게 『마시멜로 이야기』는 평범한 ‘오늘’을 특별하고 즐거운 ‘내일’로 만드는 소중한 지혜를 선사할 것이다.
저자 : 엘런 싱어
20년 이상 비즈니스 분야에서 활발한 창작활동을 해왔다. 그 경험을 토대로 문화콘텐츠 회사인 텐세컨드솔루션(TenSecondSolution)을 설립, 전세계 기업가와 법인 고객을 위해 홍보 활동을 펼치고 있다.
역자 : 정지영
21세기 한국을 대표하는 가장 지적인 방송인으로 폭넓은 사랑을 받고 있다. 이화여대 정치외교학과를 졸업하고 1998년 SBS에 입사한 후 〈SBS 뉴스 퍼레이드〉 〈한밤의 TV연예〉 〈접속 무비 월드〉 〈출발 모닝 와이드〉 등을 통해 시청자들과 친숙해진 그녀는 현재 〈TV문화지대-낭독의 발견〉을 진행하면서 고급문화의 대중화를 성공적으로 이끌어내고 있다. 7년째 진행하고 있는 SBS 파워FM 〈정지영의 스위트 뮤직박스〉는 밤을 지키는 청취자와 누리꾼들에게 진정한 행복에 대해 차분하게 돌아볼 수 있는 따뜻한 기회를 선사하고 있다.
목차
한국 독자들에게
아주 특별하고 놀라운 이야기에 앞서
1. 당신의 ‘오늘’을 특별한 ‘내일’로 만들어라
2. 눈부신 유혹을 이기면 눈부신 성공을 맞이하리라
3. 남들이 가지 않는 길을 기꺼이 가라
4. 성공은 준비된 자만이 가질 수 있는 마시멜로다
5. 세상에서 가장 아름다운 유혹은 ‘성공’이다
6. 변화한 당신, 성공을 향해 힘찬 닻을 올려라
7. 내일의 성공을 향해 쏴라
8. 성공 이상의 성공을 꿈꾸며
마시멜로 이야기를 마치며
옮긴이의 말
소프트웨어 시스템들은 비지니스 응용 프로그램(ex 뱅킹 프로그램)에서 소비재(ex 자동차)까지 생활에 있어서 차지하는 부분이 증가하고 있다. 대부분의 사람들은 소프트웨어가 (자신들이) 예상한 것처럼 동작하지 않은 경험을 가지고 있다. 소프트웨어가 올바르게 동작하지 않는 것은 비용, 시간 또는 사업적인 평판을 포함한 많은 문제를 야기시킬수 있으며, 심지어 상해나 사망의 원인이 될 수도 있다.
1.1.2 소프트웨어 결함의 원인(K2)
인간은 문서내에서, 시스템이나 소프트웨어에서, 코드내에서 결함을 생성하는 에러(실수)를 만들수 있다. 만약 코드내의 결함이 실행되면, 시스템은 의도한 동작을 하지 못하고(또는 해서는 않되는 동작을 하고), 이는 실패의 원인이 된다. 소프트웨어, 시스템 혹은 문서상의 결함들은 실패의 원인이 될 수 있지만 모든 결함들이 실패(failures)의 원인이 되는 것은 아니다.
결함(Defects)은 인간이 오류에 빠지기 쉽고, 시간의 압박이나 복잡한 코드, 하부 구조의 복잡성, 기술의 변경, 그리고/또는 많은 시스템들의 상호작용 때문에 생긴다.
실패(Failures)는 환경적인 조건이 원인이 될 수 있다. 발열, 자기장, 전기장, 그리고 오염은 펌웨어(firmware)내의 결점(faults)의 원인이 될 수 있으며, 하드웨어 조건의 변경은 소프트웨어가 동작하는데 영향을 줄 수 있다.
1.1.3 소프트웨어 개발, 유지, 운용에 있어서 테스팅의 역할
만약 발견될 결함들이 시스템이 운영을 위해 릴리즈되기 전에 고쳐진다면, 시스템과 문서에 대한 엄격한 테스팅은 운영 환경내에서 발생하는 문제들의 위험을 줄이는데 도움이 될 수 있으며, 소프트웨어 시스템의 품질에도 도움을 준다.
소프트웨어 테스팅은 계약상(법적) 요구조건들, 또는 산업에 특화된 표준들을 만족시키기 위하여 요구될 수 있다.
1.1.4 테스팅과 품질
테스팅 발견된 결함으로 소프트웨어의 기능적/ 비기능적 요구사항과 특성들 - (신뢰성(reliability), 사용성(usability), 효율성(efficiency), 그리고 유지보수성(maintainability)) - 을 만족시키는 것에 대한 소프트웨어의 품질을 측정하는 것이 가능하다.
비기능적인 테스팅에 대한 더 많은 내용을 위해서는 2장을 보면 된다. 소프트웨어 특성에 대한 더 많은 정보를 원한다면 'Software Engineering - Software Product Quality'(ISO 9126)을 보라.
만약 발견된 결함이 없거나 그 수가 적다면, 테스팅은 소프트웨어 품질에 대한 확신을 줄 수 있다. 적절하게 설계된 테스트를 통과하는 것은 시스템이 가지는 위험(Risk)의 전반적인 수준을 낮춘다. 테스팅이 결함을 발견하고, 이러한 결함들이 수정될 때, 소프트웨어의 품질은 높아진다.
학습자들은 이전 프로젝트에서 배워야 한다. 다른 프로젝트들에서 발견된 결함의 근본 원인을 이해함으로써, 이러한 결함들이 다시 발생하는 것을 방지하고 프로세스가 향상 될 수 있으며, 결과적으로는 향후 시스템의 품질이 향상되게 된다. 테스팅은 품질 보증 활동(Quality assurance activities)의 하나로써 통합되어야 한다.
1.1.5 얼마만큼의 테스팅이 적당한가?
얼마만큼의 테스팅이 적당한가를 결정하는 것은 기술적인 산출물과 업무적인 산출물, 프로젝트 위험, 그리고 시간과 비용 같은 프로젝트 제약사항을 포함한 위험 수준을 고려해야만 한다 (위험에 대해서는 5장에서 더 논의된다.)
테스팅은 다음 개발 단계나 고객에 양도를 위하여, 테스트 되는 시스템이나 소프트웨어의 릴리즈에 관한 확실한 결정을 내릴 수 있도록, 이해당사자(stakeholders)에게 충분한 정보를 제공해야 한다.
일반적으로 테스팅이란 소프트웨어를 실행하는 것처럼 테스트를 수행하는 것이다라고만 생각 할 수 있지만, 이것은 테스팅의 한 영역이지 전부는 아니다.
테스트 활동은 테스트 계획과 통제, 테스트 조건의 선택, 테스트 케이스(test case) 디자인, 그리고 결과의 확인과 완료 특성(criteria) 평가, 테스트 프로세스와 테스트하는 시스템에 대한 보고, 최종 승인과 (테스트 국면(phase)이 완수된 후의) 종료 작업 같은 테스트 실행 전과 테스트 실행 후에 모두 존재한다. 테스팅은(소스 코드를 포함한) 문서의 리뷰와 정적 분석(static analysis) 역시 포함한다.
동적 테스팅(Dynamic Testing)과 정적 테스팅(Static Testing) 모두 비슷한 목표를 이루기 위하여 사용될 수 있으며, 테스트 될 시스템과 개발/테스팅 프로세스 모두를 개선 시킬수 있는 정보 또한 제공할 것이다.
다음과 같은 여러가지 테스팅 목적이 있을 수 있다.
* 결함(defects)의 발견 * 품질 수준에 대한 확신을 얻고, 정보를 제공하는것 * 결함의 방지
개발 주기(life cycle) 초기에 테스트를 설계하는 프로세스를 생각하는 것(테스트 설계를 통하여 테스트 기본 사항들을 검증하는 것)은 코드 속에 포함되는 결함들을 예방하는데 도움을 줄 수 있다. 문서들(예를 들어 요구사항 문서)을 검토하는 것 역시 코드에 나타나는 결함을 방지하는데 도움을 준다.
테스팅에 대한 여러가지 관점들은 각기 다른 여러가지 목적을 가진다. 예를 들어, 개발 테스팅(Development Testing - 예를 들어 컴포넌트 테스팅, 통합 테스팅 그리고 시스템 테스팅)에서의 주된 목적은 소프트웨어에서 실패(failure)의 원인이 될 수 있는 결함(defects)을 가능한 한 많이 확인하고 고치는 것이다. 승인 테스트(Acceptance Test)에서 주된 목적은 시스템이 예상대로 작동하는 것을 확인하고, 시스템이 요구사항을 만족한다는 확신을 얻는 것이다.
어떤 경우에는, 결함을 고치려는 의도가 아니라 단지 소프트웨어 품질 평가가 테스팅의 목적이 되기도 한다. 이런 품질 평가 결과로 이해당사자는 계획된 시간의 시스템 릴리즈는 위험하다는 것을 알 수 있다.
유지보수 테스팅(Maintenance Testing)은 종종 개발 동안의 변경에 기인한 새로운 에러들이 없다는 것을 알려주는 테스트를 포함한다. 운영 테스팅(Operational Testing) 동안에 주된 목적은 신뢰성(reliability)과 가용성(availability)와 같은 시스템의 특성을 평가하는 것이 될 수 있다.
디버깅(Debugging)과 테스팅은 다른 것이다. 테스팅은 결함(defects)에 의한 실패(failures)를 보여줄 수 있다. 디버깅은 결점의 원인을 확인하고, 코드를 수정하고, 결점이 올바르게 고쳐졌는가(fixed)를 확인하는 개발 활동(development activitiy)이다. 테스터에 의한 계속되는 확정 테스팅(confirmation testing)은 실패(failure)가 실제로 고쳐졌다는 것을 보증한다. 각각의 활동(activity)에 대한 책임(responsibility)는 매우 다르다. 예를 들어 테스터(tester)는 테스트에 대한 책임이 있고, 개발자(developer)는 디버깅에 대한 책임이 있다.
소프트웨어를 개발하는데 있어 실수와 오류를 범할 가능성은 매우 높다. 테스팅은 개발자, 사용자 모두 자신의 불완전함과 실수를 가정하는데서 출발한다. 테스트는 인간의 불완전성을 극복하고 높은 품질의 제품을 만들기 위한 노력이다. 모든 가능한 데이터를 사용하여 모든 경우의 수에 대하여 철저히 시험하는것은 일반적으로 가능하지 않다. 결국 선택된 데이터를 기초로 시험이 이루어지며 높은 확률로 버그를 찾아낼 수 있도록 좋은 테스트 케이스(test case)를 만들어야 한다.
소프트웨어 시험의 목적은 "소프트웨어의 품질을 향상시키기 위하여 결함(defect)을 발견하는 것"이다.
주요 이유
- 잔존 결함 발견 - 명세 충족 확인 - 사용자 및 비지니스의 요구 충족 확인 - 비지니스 리스크를 감소시키는 Well-informed 조언 제공
(발견된 결함 기반의 수치적 데이터 제공)
기타 이유
- 개발 시스템/SW에 대한 자신감 부여 - 개발 프로세스 점검, 이슈제기 - 논리적 설계의 구현 검증 (Validate) - 시스템/SW가 적절히 동작함을 확인
주의사항)
1. 완벽한 테스트는 불가능하다.
2. 테스트는 오류가 없음을 보여주려는 것이 아니다.
3. 주어진 시간과 인력 및 리소스로 오류를 발견할 확률이 높은 테스트 케이스를 찾아내고 실행 해야 한다.
4. 한계를 인정해야 한다.(모든 입력값을 테스트 할 수 없음, 모든 경로(Path)를 테스트 할 수 없음, 모든 타이밍을 테스트할 수 없음)
◆ Testing ROI (Return On Investment)
품질비용 (Cost of poor quality)
▪ Cquality = Cconformance + Cnon-conformance ▪ Conformance costs : 테스팅(결함 발견)과 QA (결함 예방) - 수동/자동/정적 테스팅 (QA 제외) ▪ Non-conformance costs : 결함 수정, 재시험(retesting), 불만족 고객대응, 회사 이미지 손상, 사업 기회 상실 등 - 결함수정 (수치화 하기 어려운 것들 제외)
지난 40년에 걸쳐 많은 수의 테스팅 원칙들이 제안되었다. 그리고 모든 테스팅에 대하여 가이드라인이 제공되었다.
원칙 1 - 테스팅은 결함의 존재를 보여준다.
테스팅은 결함(defect)이 존재하는 것을 보여줄 수 있다. 그러나 결함이 없다는 것을 증명하진 못한다. 테스팅은 소프트웨어에 확인되지 않은 결점이 남아 있을 확률을 줄인다. 그러나 결점이 발견되지 않는다고 하여도 이것이 완전하다는 증명이 될 수 없다.
(= 테스트 작업으로 버그가 존재하지 않는다는 사실을 입증할 수 없다.)
원칙 2 - 소모적인 테스팅은 불가능하다.
사소한 경우를 제외하고 모든 것을 테스팅하는 것(입력과 선행조건의 조합)은 불가능하다. 소모적인 테스팅 대신에, 우리는 위험(risk)와 우선순위(priorities)를 이용하여 테스팅하는데 드는 노력에 초점을 맞춘다.
프로그램을 완전히 테스트하는 것은 불가능하다. 간단한 소프트웨어라고 해도 프로그램을 완전히 테스트하는 것은 불가능하다. 불필요하다고 느껴서 혹은 시간을 절약하기 위해 특정 조건에서의 테스트를 건너뛰기로 결정하는 것은 프로그램을 완전히 테스트하지 않는다는 것을 뜻한다.
모든것을 테스트하려고 하면 비용은 엄청나게 증가하며 놓치게 되는 버그의 숫자는 일정 수준으로 감소하기 때문에 이와 같은 작업을 계속하는 것은 비용 면에서 효율적이지 못하다. 테스트를 축소시키거나 테스트할 대상에 올바른 판단을 내리지 못하면 비용은 감소하지만 많은 버그를 방치하게 된다. 따라서 너무 많지도 적지도 않은 적절한 양의 테스트 작업을 수행하는 것이 중요하다.
원칙 3 - 초기 테스팅(Early Testing)
소프트웨어나 시스템 개발주기에서 가능한 빨리 테스트 활동을 시작하여야 하며, 정의된 목표에 초점을 두어야 한다.
원칙 4 - 결점의 군집화(Defect Clustering)
작은 수의 모듈이 선행 배포(Pre-release) 테스팅 동안에 발견된 대부분의 결함을 포함하거나, 대부분의 운영 실패(oprational failure)를 보여준다.
종종 테스터들이 오랜 시간 동안 버그를 발견하지 못하다가 하나를 발견하면, 바로 또 다른 버그들을 연이어 발견하는 것을 볼 수 있다. 그 이유는 - 프로그래머들도 사람이기 때문에 작업 품질이 일정하지 않을 수 있기 때문이다 - 프로그래머도 사람이기 때문에 습관에 따른 특정 오류를 만들어 내며 같은 실수를 반복할 수 있다. - 소프트웨어의 설계나 구조에 근본적인 결함이 있는 경우가 많다. 이런 경우 여러 개의 관계 없는 버그가 발견되지만 나중에 모든 버그가 하나의 심각한 원인으로부터 생긴 것임을 발견 할 수 있다.
원칙 5 - 살충제 패러독스(Pesticide paradox)
동일한 테스트가 계속적으로 반복된다면, 실제적으로 동일한 테스트 케이스의 집합은 더 이상 새로운 버그를 발견하지 못할 것이다. 이러한 "살충제 패러독스(Pesticide paradox)"를 극복하기 위해서는 테스트 케이들이 주기적으로 검토되고 새로이 고안되어야 하며, 잠재적으로 좀 더 많은 결함을 발견하기 위하여 소프트웨어나 시스템의 다양한 부분들을 실행하도록 다양한 테스트 케이스들(test cases)을 작성해야 한다.
소프트웨어나 시스템에 대한 잠재적인 더 많은 결점을 발견하기 위하여 여러 부분을 테스트하기 위해 작성된 다양한 새로운 테스트들이 필요하다.
원칙 6 - 테스팅은 내용(context)에 종속적이다.
테스팅은 다양한 내용에 따라서 다르게 행하여진다. 예를 들어, 안전에 민감한 소프트웨어는 전자 상거래 사이트와는 다르게 테스트 된다.
원칙 7 - 에러 부재 오류
만일 구축된 시스템이 쓸모 없으며, 사용자의 요구와 기대를 채우지 못한다면, 결함을 찾고 고치는 것은 의미가 없는 일이다.
테스팅의 가장 명백한 부분은 테스트를 실행하는 것이다. 그러나 효과적이고 효율적인 테스팅이 되기 위해서는 테스트를 계획하고, 테스트 케이스를 설계하고, 실행을 준비하고 상태를 평가하는데 보내는 시간 역시 포함되어야 한다.
기본적인 테스트 프로세스는 다음의 주된 액티비티들(activities)로 구성된다.
• 계획과 통제 (Planning and Control) • 분석과 설계 (Analysis and Design) • 구현과 실행 ( Implementation and Execution) • 종료 기준의 평가와 보고 (Evaluating exit criteria and Reporting) • 테스트 종료 액티비티들 (Test closure activities)
논리적으로는 순차적이지만, 프로세스내에서 액티비티들은 중첩되거나 동시에 진행될 수 있다.
1.4.1 테스트 계획(Planning)과 통제(Control)
테스트 계획(Test planning)은 테스트의 목적과 임무(mission)를 만족시키기 위하여 테스팅의 임무을 검증하고, 테스팅의 목적과 테스트 액티비티들의 명세를 정의하는 액티비티이다.
테스트 통제(Test Control)은 실제 진행상황과 계획을 비교하고, 계획의 오차를 포함한 진행 상태를 보고하는 계속 진행되는 액티비티이다. 테스트 통제는 프로젝트의 임무와 목표를 만족시키기 위하여 필요한 액션들(actions)을 포함한다. 테스팅을 통제하기 위해서는, 프로젝트 전체에 걸쳐 모니터링 되어야 한다. 테스트 계획은 모니터링과 통제 액티비티로 부터 피드백(feedback)을 받는다.
테스트 계획(Test Planning)은 다음의 주요 작업들(tasks)을 포함한다.
• 테스팅의 범위(scope)와 위험(risk)를 결정하고, 테스팅의 목표를 정한다. • 테스트 방법을 정한다.(기법, 테스트 항목, 적용 범위, 테스팅에 포함되는 팀들간의 정의와 조정, 테스트웨어) • 요구되는 테스트 자원을 정의한다. (e.g 인력, 테스트 환경, PC등) • 테스트 정책과/또는 테스트 전략을 결정한다. • 테스트 분석과 설계 작업을 계획한다. • 테스트 구현과 실행 그리고 평가를 계획한다. • 종료 기준을 결정한다.
테스트 통제(Test Control)는 다음의 주요한 작업들을 포함한다.
• 결과의 측정과 분석 • 프로세스, 테스트 커버리지(test coverage), 그리고 종료 기준(exit criteria)의 모니터링과 문서화 • 올바른 동작의 초기화 • 의사결정
1.4.2 테스트 분석(Analysis)과 설계(Design)
테스트 분석과 설계는 일반적인 테스팅 목표를 구체적인 테스트 조건과 테스트 설계로 변환하는 액티비티이다.
테스트 분석과 설계는 다음의 주요한 작업을 포함한다.
• 테스트 관련 기본사항을 검토한다.(요구사항, 아키텍쳐, 디자인, 인터페이스) • 테스트 조건 또는 테스트 요구사항과 테스트 항목, 명세, 동작과 구조에 분석을 기초로 필요한 테스트 데이터를 정의한다. • 테스트들(tests)을 설계한다. • 시스템과 요구사항의 테스트 가능성을 평가한다. • 테스트 환경을 설정하고, 테스트에 요구되는 기반 구조와 도구를 정의한다.
1.4.3 테스트 구현(Implementation)과 실행(execution)
테스트 구현과 실행은 테스트 조건들이 테스트 케이스(test case)와 테스트웨어(testware) 그리고 테스트 설정 환경으로 변환되는 액티비티이다.
테스트 구현과 실행은 다음의 주요한 작업을 포함한다.
• 테스트 케이스의 개발과 우선 순위화, 테스트 데이터의 생성, 테스트 절차(test procedures)의 작성, 그리고 테스트 장치의 준비와 자동화된 테스트 스크립트 작성 • 효과적인 테스트 실행을 위한 테스트 케이스들로 부터의 테스트 슈트(test suite) 작성 • 테스트 환경이 올바르게 설정되었는지의 검증 • 계획된 순서에 따라 수동이나 테스트 실행 도구에 의한 테스트 케이스의 실행 • 테스트 실행의 결과 로깅(logging)과 테스트웨어, 그리고 테스트 도구, 테스트 중인 소프트웨어의 버전과 특성(identities)들을 기록 • 실제 테스트 결과와 예상 테스트 결과의 비교 • 실제 테스트와 예상 테스트 결과 사이의 불일치(discrepancies)를 보고하고, 그 원인을 찾기 위하여 분석한다. (e.g 코드, 특정 테스트 데이터, 테스트 문서안의 결점이나 실행된 테스트 방법 내의 잘못) • 각각의 불일치에 대하여 취해진 행위의 결과와 같은 테스트 액티비티를 반복한다. 예를 들어, 이전에 실패한(failed) 테스트의 재실행(re-excution)은 잘못을 수정한 것을 확인하기 위한 것이다. (확인 테스트-confirmation test) 정정된 테스트의 실행과/또는 다른 테스트들의 수행은 소프트웨어의 변경되지 않은 부분에는 아직 결점이 나타나지 않았다는 것과 결점을 고친 것이 다른 결점들을 커버 하였다는 것을 확신하기 위해서 진행된다.(회귀테스팅-regression testing)
1.4.4 종료 기준(Exit criteria) 평가와 보고(Reporting)
종료 기준을 평가하는 것은 테스트의 실행이 정해진 목표에 대한 것인지를 평가하는 액티비티이다. 이것은 각각의 테스트 레벨에 대하여 반드시 수행되어져야 한다.
종료 기준을 평가하는 것은 다음의 주요한 작업을 포함한다.
• 테스팅 계획에 정의된 종료 기준에 비교하여 테스트 로그들(logs)을 확인한다. • 더 많은 테스트가 필요한지, 정의된 종료 기준이 변경되어져야 하는지를 평가한다. • 이해당사자를 위한 테스트 요약 보고서를 작성한다.
1.5.5 테스트 종료(Test Closure) 액티비티
테스트 종료 액티비티는 경험, 테스트웨어, 실제 사실과 숫자들을 통합하기 위하여 종료된 테스트 액티비티로부터 데이터를 수집한다. 예를 들어, 소프트웨어 시스템이 릴리즈되면, 테스트 프로젝트가 완료되며(또는 취소되며), 목표(milestone)가 성취되었거나 유지보수를 위한 배포가 완료된 것이다.
테스트 종료 액티비티는 다음의 주요한 작업을 가진다.
• 부가적인 사건의 종료 보고서와 오픈된(opened) 상태로 남아 있는 부분에 대하여 일어나는 변경 기록들, 그리고 시스템의 승인에 대한 문서와 같은 계획된 소프트웨어 구성요소들(deliverables)이 전달되었는가 확인한다. • 테스트웨어, 테슽 환경 그리고 테스트 기반 구조를 정리하고 최종적으로 승인한다. • 유지보수 조직에 테스트웨어를 이양한다. • 다음 프로젝트와 릴리즈 그리고 테스트 성숙도의 향상을 위하여 경험으로 배운 사항(lessons learned)을 분석한다.
* 소프트웨어 업계에서는 일단 제작되어 다른 사람에게 전달되는 소프트웨어 제품 구성요소를 deliverable이라 한다.
* 초기 구상 단계부터 대중에게 출시되기까지 소프트웨어 제품을 만드는 데 사용되는 과정을 소프트웨어 수명주기 모델이라고 한며 가장 많이 사용되는 모델은 다음의 4가지 모델이다.
- 빅뱅 (Big-bang) 모델
- 코딩- 수정(Code-and-Fix) 모델
- 폭포(Waterfall) 모델
- 나선형(Spiral) 모델
◆ Test Plan ▪ Purpose - Test의 개요를 정의한다. - 테스트 전략 및 테스트 수행의 개요를 정의한다. ▪ Goal of the Test - Test의 최종 목표를 정의한다. ▪ Scope of the Test - 테스트 대상 기능과 비 대상 기능을 정의한다. 해당 기능들은 업무요구 사항 및 기술 요구사항에 정의되어 있어야 한다.
◆ Test Estimation ▪ 예측 방법 - 과거 프로젝트나 유사 프로젝트의 매트릭을 근거로 테스트 업무량(effort) 예측 - 전문가나 테스크의 주체에 의한 예측 ▪ 테스팅 업무량에 영향을 주는 요소들 - 제품의 특성 : 테스트 베이스의 품질, 제품 사이즈, 문제 도메인의 복잡성, 신뢰성 및 보안성 요구수준, 문서화 요구수준 - 개발 프로세스 특성 : 조직의 안정성, 사용한 틀, 테스트 프로세스, 관여자들의 스킬 수준, 시간 압박 정도 - 테스팅 결과물 : 결함 수와 요구되는 재작업량
◆ Test approaches ▪ 분석적 접근법 (Analytical approachs) : Risk-based testing ▪ 모델 기반 접근법(Model-based approaches) : Stochastic testing(reliability growth model, operational profiles) ▪ Methodical approaches : Failure based(error guessing, fault-attacks), check-list based, quality characteristic based ▪ Process - or standard-compliant approaches ▪ Dynamic and heuristic approaches ▪ Consultative approaches (by expert advice) ▪ Regression-averse approaches (reuse of existing test materials and automation)
◆ Test Strategies and factors ▪ 테스트 전략은 무엇을 어떻게 테스트하고 어느 정도의 깊이/커버리지로 할 것인지를 결정하는 것으로 리스크 기반 테스트 전략이 대표적이다. ▪ 테스트 전략의 결정 요소로는 Product technology, product criticality, product complexity, component selection 등이 있다.
◆ Risk - 시간과 자원의 한계를 고려 ▪ Defect -> Failure -> Risk (*Error - relate to human) ▪ Defect : Failure 원인 (a specific cause of failure) (Related to product) ▪ Failure : 의도된 기능을 수행하지 못한것 (relate to events) ▪ Risk : failure 때문에 주어진 기간에 발생하는 비용 Risk = failure 가능성 * Damage Chance of Failure = frequency of use * chance of fault
◆ Exhaustive 테스팅 전략 ▪ 모든 가능한 경우를 테스팅 ▪ 생명 관련 소프트웨어 -> Exhaustive 테스팅 & 안전분석 필요 ▪ 안전 분석을 위한 Safety manager와 엔지니어가 있어야 함
◆ Test Environment ▪ 테스트가 수행될 물리적 환경, H/W 환경을 정의한다. ▪ 테스트가 수행될 S/W 환경을 정의한다.
소프트웨어 수명 주기 모델 (참고)
빅뱅 모델 (Big-Bang Model)
우주의 생성을 설명하는 이론 중 하나가 빅뱅이론이다. 수 십억년전 우주는 무한한 에너지로 인한 한 번의 거대한 폭팔로 인해 생성되었다는 것이 이 이론이다. 소프트웨어 개발에서의 빅뱅 모델도 같은 이론을 따른다. 많은 양의 물질(사람과 자본)이 한데 모여 종종 매우 격렬하게 많은 양의 에너지가 소모되고 그 결과 완벽한 소프트웨어 제품이 탄생하거나 혹은 그 반대가 된다.
빅뱅이론의 장점은 간단함이다. 계획, 일정 또는 형식적인 개발 과정이 포함된다면 이 이론의 매력은 반감된다. 모든 노력은 소프트웨어를 개발하고 코드를 작성하는데 사용되어야 한다. 이 방법은 제품의 요구사항이 분명하지 않고 최종 출시 날짜가 변동 가능할 경우에 이상적이다. 고객의 요구사항이 유동적이이어야 한다는 점 역시 중요하다. 마지막 순간까지 어떤 제품이 나올지 모르기 때문이다. 대부분의 빅뱅 모델에서는 형식적인 테스팅이 아예 없거나 거의 이루어지지 않는다. 테스팅 과정이 있는 경우에는 제품이 출시되기전 아주 잠깐 동안만 이루어진다.
코딩-수정 모델 (Coding-Fix Model)
코드-수정 모델은 프로젝팀이 특별히 다른 모델을 사용하려는 노력을 기울이지 않는 한 대개 기본적으로 안주하게 되는 모델이다. 적어도 이 모델에서는 제품의 요구 사항이 무엇인지에 대한 생각을 필요로 한다는 점에서, 절차상으로는 빅뱅 모델보다 한 단계 위에 위치한다. 이 접근 방법을 사용하는 팀은 대개 그들이 원하는 바에 대한 대략적인 아이디어만 가지고 간단한 설계 작업을 하고 코딩, 테스팅, 버그 수정의 단계를 끊임없이 반복한다.
이 모델의 경우 계획과 문서화하는 단계가 거의 없기 때문에 프로젝트 팀은 즉시 결과를 보여줄 수 있다. 이러한 이유로 코딩-수정 모델은 프로토타입, 데모 등 빠른 시간 내에 제작하고 제작이 끝나면 금방 버리도록 계획된 작은 규모의 프로젝트에 매우 적합하다. 하지만 코딩-수정 모델은 규모가 크고 잘 알려진 많은 소프트웨어 제품에 사용되고 있다. 빅뱅 모델과 같이 코딩-수정 모델에서도 테스팅 작업이 특별히 요구되지 않지만 코딩 작업과 수정 작업 사이에 매우 중요한 역할을 담당한다.
폭포수 모델 (Waterfall Model)
이 모델에서 중요한 세가지 사실은
1. 어떤 제품을 만들 것인가를 명확히 해 두는 것이 매우 중요하다. 개발 및 코딩은 제품에 있어 하나의 단계에 지나지 않음을 명심해야 한다. 2. 단계는 분리되어 있고 겹치는 일이 없다. 3. 이전 단계로 되돌아 갈 수 없다. 한 단계에 발을 들여 놓은 다음에는 해당 단계에 대한 작업을 완전히 마무리 지은 후 다음 단계로 이동해야 한다.
나선형 모델 (Spiral Model)
나선형 모델의 기본 아이디어는 처음 시작 단계에서는 모든 세부 사항을 정의 할 수 없다는 것에서 출발한다. 중요한 기능을 정의하여 시도해보고 고객의 의견을 수렴한 후 다음 단계로 이동한다. 나선형 모델은 다음의 단계를 반복한다.
1. 목표, 대안, 장해 요인 결정 2. 위험 요인 확인 및 분석 3. 대안 평가 4. 현재 단계 개발 및 테스트 5. 다음 단계 계획 6. 다음 단계에 대한 접근 방법 결정
◆ Iterative and Incremental Developement & Approach
▪ 점진적으로 효과적인 결과물(해결책)을 산출하기 위해 일련의 활동(Requirement -> Analysis -> Design -> Implmentation -> System Test)을 반복적으로 적용하는 개발 스타일 ▪ Interative (반복적인) : 핵심적인 개발 활동을 "리스크(우선순위)"에 따라 반복적/발전적으로 적용하여 결과물/해결책 도출 ▪ Incremental (점차적으로 증가하는) : 반복 사이클을 통해 개발이 진행됨에 따라 "문제"에 대한 이해를 높여, 해결능력을 향상시킨다.
◆ Waterfall VS Iterative
▪ Waterfall은 결과물로 수행전까지 문서만 존재하지만 Iterative는 각 Iteration 별 실제 개발
결과물이 존재한다. ▪ Waterfall은 Risk를 프로젝트 중간이후의 코딩 단계까지 가지고 가지만 Iterative는 Risk를 개발 앞단에서 처리 ▪ Waterfall은 개발 프로젝트 예측이 어렵지만 Iterative는 개발 프로젝트 예측이 용이하다.
1.5 The psychology of testing
테스팅하고 검토하는 동안의 사고방식과 분석하고 개발하는 동안의 사고방식은 다르다. 올바른 사고를 가진 개발자들이 자신의 코드를 스스로 테스트 할 수 있지만, 각자 맡은 일에 집중할 수 있도록 도와주고 훈련된 전문 테스팅 인력들에 의한 독립적인 관점을 얻을 수 있는 혜택을 더하기 위해서 테스터에게 테스팅 책임을 분리하여 준다. 독자적인 테스팅은 테스팅의 모든 레벨에서 수행될 수 있다.
(저자의 편향을 피하는) 독립적인 어떤 단계는 종종 결점이나 실수를 발견하는데 더 효과적이다. 그러나 독립성은 정통함의 대체수단은 아니며 개발자들은 효과적으로 자신의 코드에서 많은 결점을 발견할 수 있다. 다음과 같이 독립성의 몇가지 레벨이 정의될 수 있다 :
• 테스트중인 소프트웨어를 작성한 사람(들)에 의하여 설계된 테스트 (낮은 수준의 독립성) • 다른 사람(들)에 의하여 설계된 테스트 (e.g 개발팀에 의해 설계된 테스트) • 다른 조직이나 그룹의 사람(들)에 의하여 설계된 테스트(e.g 독립적인 테스팅 팀) • 다른 조직이나 회사의 사람(들)에 의하여 설계된 테스트(e.g 아웃소싱 혹은 외부의 인증)
조직 구성원들은 관리자와 다른 이해당사자들에 의해 설정된 목표에 자신들의 계획(예를들어, 결함 찾기, SW 정상 동작 확인)을 맞추려는 경향이 있다. 따라서 테스팅의 목적을 명확히 하는 것은 중요하다.
테스팅 동안에 실패들을 정의하는 것은 제품이나 저자에 대한 비평으로 인식될 수 있다. 그러므로 테스팅은 비록 제품의 위험 관리에 있어서 매우 건설적이더라도 종종은 파괴적인 액티비티로 보여질 수 있다. 시스템에서 실패를 찾는 것은 호기심, 전문적인 비관론, 비평적인 눈, 세부사항에 관한 관심, 개발자 동료와의 건전한 의사소통, 그리고 기본적인 에러를 추측하는 경험등을 요구한다.
만약, 에러나 결점 혹은 오류들이 건설적인 방법으로 전달된다면, 테스터와 분석가, 설계자와 개발자 사이의 나쁜 감정들을 회피할 수 있다. 이것은 테스팅은 물론 검토(reviewing)에서 적용된다.
테스터와 테스트 리더는 결점, 진보, 그리고 위험에 대한 사실적인 정보를 건설적인 방법으로 전달하기 위한 좋은 대인관계의 스킬이 필요하다. 소프트웨어나 문서의 저자들은 결점에 대한 정보를 통하여 그들의 기술을 향상시킬 수 있다. 테스팅 동안의 결점 발견과 수정은 나중에 들어갈 시간과 비용을 절약해 줄 것이다. 그리고 위험을 줄인다.
만약 테스터들이 결점에 대한 원하지 않는 소식의 전달자로만 보여진다면, 의사소통에 문제가 일어날 수도 있다. 그렇지만, 다른 사람과 테스터 사이의 의 사소통과 관계를 향상시키는 몇가지 방법이 있다.
• 전투보다는 협력으로 시작하라 - 모두의 공통적인 목적은 더 좋은 품질의 시스템인 것을 생각하라 • 제품을 생산한 사람에 대하여 비판하는 것없이 제품에 대한 발견사항을 중립적이고 사실에 중점을 둔 방법으로 전달하다. 예를 들어, 객관적이고 실질적인 사건 보고서와 발견 사항에 대한 검토 보고서를 작성하라. • 다른 사람이 어떻게 느끼는지와 왜 그들이 그렇게 반응하는가를 이해하려고 노력하라. • 다른 사람이 당신이 말한 것을 이해했는지를 확인하라 그리고 반대 상황도 마찬가지이다.
네이버 영어회화 카페 검색 1위 '리얼타임 스피킹(RTS)'에서 활용중인 영어 말하기 프로그램. 영어 말하기가 실시간 흐름 속에서 이루어지는 ‘언어 행동’이라는 데 초점을 두어 할 말을 의미단위로 추출하고 영어로 변환하고 빠르게 흐름구사하는 3단계 훈련을 거치면서 초심자들이 자신의 생각을 영어로 구사할 수 있도록 돕는다. 국내 학습자들의 입장에서 영어 말하기가 가능한 조건과 훈련법을 다루었다.
* 샘플 강의와 자료 및 RTS훈련 후기
네이버 RTS 카페(http://cafe.naver.com/rtsenglish)
저자의 홈페이지(www.rtsenglish.com)
목차
Preface
Part 01 리얼타임 스피킹 Real Time Speaking의 세계
Part 02 진짜 영어 말하기는 나 자신의 일거수일투족에서 시작된다!
Part 03 지금, 당장 떠오른 것을 영어로 말할 수 있게 되다니!
Part 04 절대로 실패하지 않는 영어 말하기 생활법
