소프트웨어 공학 (Software Engineering ) 테스트 (Test) 문양세 강원대학교 IT 대학 컴퓨터과학전공

소프트웨어 공학 (Software Engineering) 테스트 (Test) 문양세 강원대학교 IT대학 컴퓨터과학전공

CDMA 이동통신 개발 조직 (1/2) – from 개요 테스트 (Test) 개발 조직을 다음과 같이 엔티티별로 구성해 보았다. 개발 대장 MSC BSC BTS HLR … Software Test Hardware System Engineering Software Test Hardware System Engineering Software Test Hardware System Engineering Software Test Hardware System Engineering Software Test Hardware System Engineering

CDMA 이동통신 개발 조직 (2/2) – from 개요 테스트 (Test) 개발 조직을 다음과 같이 기능별로도 구성해 보았다. 개발 대장 Hardware Software System Eng. Test BSC HLR … MSC BTS MSC BTS MSC BTS BSC HLR … BSC HLR … BSC HLR … MSC BTS

In this chapter … 테스트 (Test) • 실제로 현장(real world)에서 테스트에 드는 노력은총 비용의 50% 이상,총 개발 기간의 50% 정도에 해당한다. • 테스트의 목적은 소프트웨어의 기능을 시험하는 것이 아니라,소프트웨어의 오류를 찾아내어 그 품질(quality)을 향상시키는데 있다. 매우 여러 종류의 여러 단계의 테스트를 수행한다. • We will cover … • 테스트 개요 및 테스트 원리 • 화이트 박스 테스트 (white box test) • 블랙 박스 테스트 (black box test) • 자료 구조 중심 테스트 (data structure oriented test) • 통합 테스트 (integration test) • 인수 테스트 (acceptance test) • 테스트 자동화 도구

We are now … 테스트 (Test) 테스트 개요 및 테스트 원리 화이트 박스 테스트 (white box test) 블랙 박스 테스트 (black box test) 자료 구조 중심 테스트 (data structure oriented test) 통합 테스트 (integration test) 인수 테스트 (acceptance test) 테스트 자동화 도구

테스트 개요 테스트 (Test) • 테스트? • 테스트에 필요한 시간과 노력  매우 크다. • 그러나, 테스트는 대부분 초보자나 개인의 역량에 맡기는 경우가 많다. Low level 작업이라는 인식이 넓게 퍼져 있다. • 정의 • 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 수동/자동 방법을 동원하여 검사/평가하는 일련의 과정[IEEE, 1993] • 숨어있는 결함을 찾기 위해 소프트웨어를 작동 시키는 일련의 행위와 절차  결함이 없음을 증명하는 것이 아니고, 결함이 존재함을 보여주는 작업 • 테스트: 분석, 설계 도중에 일어나는 검증, 검토 등 품질보증을 위한 모든 행위

최근엔? – 테스트 전문가자격증 테스트 (Test)

소프트웨어 테스트 엔지니어 테스트 (Test)

테스트와 개발 단계 (V 모형) 테스트 (Test) 테스트 단계와 소프트웨어 개발 단계의 관계 테스트 단계 개발 단계 고객(사용자) 범위와 목표 인수테스트 시험자 요구 분석 시스템 테스트 리그레션 테스트 시험자, 프로그래머 구조 설계 통합 테스트 프로그래머 프로그램 설계 단위 테스트 코 딩 Regression Test (회귀 테스트) • 두 가지 의미 • 오류를 발견하여 고치고 다시 원래 문제를 일으켰던 것을 테스트 확인, 수정이 예상대로 되었는지 확인하고, 수정된 것을 반복 테스트 • 수정된 부분이 다른 부분에 영향을 주어 예상하지 않은 오류를 발생시키지않는지 확인, 수정 후 프로그램의 통합이 제대로 이루어졌는지 확인

소프트웨어 심리 (1/2) 테스트 (Test) • 프로그래머의 심리 • 자신의 프로그램이 옳다고 생각, 그러나 프로그램의 오류는 테스트에 의하여 확인됨  디버깅이 안되면 주저하지 말고 실력이 있든 없든 옆 사람에게 도움을 청하라. • 프로그램 안의 오류를 인신 공격, 또는 개인 평가로 해석하여 테스트를 기피 특히, 우리나라는 버그를 잡아주면 고마워하지 않고 미워한다? • 심리적 불안 • 테스트는 파괴적인 과정(destructive process)으로 생각 심혈을 기울여 구조적으로 짠 것인데, 그 버그 때문에 망가지는군… • 이를 극복하기 위하여 테스트하기 전에 예상 결과를 준비 예를 들어, “경험상 테스트 결과 코드의 50%는 바뀔 각오를 해라”는 당연한 논리 설파 • independent test, test automation

소프트웨어 심리 (2/2) 테스트 (Test) 모든 소프트웨어는 테스트를 통해서 강해집니다. 절대로 비판을 두려워하지 마세요.  버그나 오류를 지적해 주는 사람에게 고마워하세요. 급할 수록 돌아가라는 속담은 진실입니다. 철저히 검사하세요.  나중에(고객에게 팔려서, 사이트에서 돌아가는 경우), 버그가 발견되면 수습하기가 더욱 어려워집니다.

테스트 이슈 (1/2) 테스트 (Test) • 소프트웨어 신뢰도 요구의 증가 • 갈수록 오류가 적은/없는 소프트웨어를 원하고 있음 • MS Windows의 경우, 예전에 툭하면 Blue Screen, 요즘엔 … 쓸만하죠? • 오류의 방지 • 개발 단계에서의 오류 유입 방지 (가능한 조심스럽게) • 테스트 케이스 설계 기술(오류/버그가 빠져나갈 수 없는 테스트 케이스 설계를 목표로…) • 모듈화 설계가 테스트에 드는 노력을 줄임(작게 잘라서, 작은 것을 완벽히 한 후, 통합을 실시)

테스트 (Test)

안드로이드 애플리케이션 에러 테스트 (Test)

테스트 이슈 (2/2) 테스트 (Test) • 개발 全 단계에서의 많은 검증 노력이 요구됨 명언: 코딩을 늦게 시작할 수록 개발에 걸리는 시간이 적게 걸린다. • 대부분의 오류는 설계 단계에서의 정보 관리 부재에 기인 • 설계 오류가 제일 많음 • 오류 수정에 드는 비용은 절대 무시할 수 없음 • 테스트는 全 개발 단계에서 이루어져야 함 • 소프트웨어 테스트에 대한 이론적 기초 • 소프트웨어 오류의 성질을 이해 오류에는 어떤 것이 있는가? 어떤 경우에 오류가 잘 발생하는가? 오류를 빨리 확인하기 위하여 어떤 테스트를 수행해야 하는가?

테스트 유형 (1/2) 테스트 (Test) • Validation(확인): Are we building the right product? 만든 제품이 바른 제품이야? (기능적 측면) • Verification(검증): Are we building the product right? 만든 제품이 바르게 동작하는 거야? (품질 측면) • 인증(Certification): A written guarantee • 정적 분석(Static Analysis): 코드/문서를 보면서 • 동적 분석(Dynamic Analysis): 프로그램을 돌려 가면서 • 단계별 • 단위 테스트(unit test) • 통합 테스트(integration test) • 인수 테스트(acceptance test)

테스트 유형 (2/2) 테스트 (Test) • 시험 방법 • 화이트 박스 테스트 • 블랙 박스 테스트 • 기능 시험 • 성능 시험 • 스트레스 시험 ( 고온에서 시험…) • Benchmark 시험 • Field 시험 • Regression test • 품질 보증 (Quality assurance)

테스트 단계 테스트 (Test) 1) 테스트에 의하여 무엇을 점검할 것인지 정한다.예) 테스트의 목표 - 기능의 완벽성, 신뢰도 2) 테스트 방법을 결정한다.예) 검사, 증명, 블랙박스 테스트, 화이트 박스 테스트, 자동화 도구 3) 테스트 케이스를 개발한다.예) 테스트 자료, 시행 조건, 시험 계획서 4) 테스트의 예상되는 올바른 결과를 작성한다.테스트 오라클(test oracle,모든 테스트에 대한 예상 결과 모음) 5) 테스트 케이스로 실행시킨다.테스트 하니스(test harness, 테스트를 위해 일부 기능을 변경하는 작업)가 필요

테스트에 대한 올바른 이해 (1/2) 테스트 (Test) 테스트는 프로그램이 잘 돌아가는지를 보려고 수행하는 것이 아니다. 내 프로그램 정확하니, 한번 확인해 봐 라는 식으로 테스트에 임한다. 이렇게 되면, 테스트 결과에 대체로 불만족스러워 한다. 테스트는 오류를 발견하려고 프로그램을 수행시키는 것이다. 절대 소극적으로 수행하지 않아야 한다. 잘못하면, 나중에는 더 큰 악재로 다가온다.

테스트에 대한 올바른 이해 (2/2) 테스트 (Test) • 테스트에 의하여 오류가 발견되지 않았다고 하여 프로그램에 오류가 없는 것은 아님 • 완벽한 테스트는 불가능하다. 일반적으로 전체 검수가 아닌 부분 검수에 해당… • 테스트는 창조적인 일이며 힘든 일이다. 효율적인 테스트를 위해서는 소프트웨어를 잘 이해하여야 하며,창조력을 지닌 전문가에 의해서 행해져야 한다. • 테스트는 오류의 유입을 방지할 수 있다. 개발 과정에 많은 테스트를 할 수록 궁극적으로 오류를 줄일 수 있다. • 테스트는 구현에 관계없는 독립된 팀에 의하여 수행되어야 한다. 자기가 자기 것을 테스트 하는 것은 고양이에게 생선을 맡긴 꼴이다.

오류 (발생) 패턴 테스트 (Test) 테스트는 시스템의 오류 패턴과 매우 밀접한 관련 처음에는 적당히 분산되어 고르게 오류가 발견되는 듯 하다가, 테스트를 하면 할 수록 오류가 많은 부분에서 더 많은 오류가 발생한다. 모듈에 오류가 너무 많다면 오류 없는 모듈이 될 수 있도록 테스트하여 고치는 것은 한계가 있다.  오류가 많다면… 다시 짜는 것이 상책이다. 이런 일은 비일비재한데…, 얼마나 큰 비애를 느낄까요?

화이트 박스 테스트 (1/2) 테스트 (Test) • 모듈 안의 작동을 자세히 관찰하는 시험 각각의 라인이 제대로 수행되는지를 철저하게 시험 • (길이가 짧은) 특수 프로그램에 대해서나 적용 가능한 방법… • 검증 기준 (test coverage) • Statement coverage: 원시 코드의 모든 문장을 한번 이상 수행 • Decision coverage: 선택 구조 조건의 모든 경우가 적어도 한번씩 테스트 • Loop coverage: 루프 구조를 완벽히 테스트 ① 반복조건을 만족하지 못하여 루프를 수행시키지 못한 경우 ② 루프 안의 내용을 한번만 수행 ③ 한번 이상 수행

화이트 박스 테스트 순서 (2/2) 테스트 (Test) • 화이트 박스 테스트 순서1) 논리 흐름도에 의한 표현2) 테스트 케이스 생성 • 논리 흐름도: 모듈 내의 제어흐름을 간선으로 표시한 그래프 • 세그먼트(begin-end)  노드(node) • 제어흐름  간선(edge) • 세그먼트의 발견  NS-도표 (나씨-슈나이더) 활용

논리 흐름도 표현의 예 (1/2) 테스트 (Test) • 점수의 평균을 구하는 프로그램  교재 참조 • NS-도표 작성  교재 참조 • 논리 흐름도 

논리 흐름도 표현의 예 (2/2) 테스트 (Test) • 테스트 케이스 작성: 검증 기준에 따라 논리 흐름도의 경로를 적어도 한번씩 방문하도록 테스트 케이스를 추출 • 예제 테스트 케이스 경로 score=89.0 a, b, d, h, c, i <eof> a, c score=53.41, -77.0 a, b, d, h, b, e, h, c, j • 화이트 박스 실행: 모든 경우에 대한 테스트 실행표를 만들고, 실험을 수행하면서 정상적으로 동작하는지 검사  화이트 박스 테스트는 이론적으로는 가능한 이야기이나,실제 소프트웨어에 적용하는데 한계가 있음

블랙 박스 테스트 테스트 (Test) • 모듈이 요구에 맞게 잘 작동하는가에 초점을 맞춘다. • 모듈의 기능 시험에 해당한다. • 모듈의 외형 (입력, 출력) • 모듈의 기능 위주의 검사 현실적으로 사용 가능한 테스트 방법이다.특히, 제 3자가 테스트를 수행할 경우, 블랙 박스 테스트가 적합하다.

동치 분해 (Equivalence Partitioning) (1/2) 테스트 (Test) • 입력 조건을 여러 개의 동치 클래스로 나눔 • 방법 1) 입력이 일정한 범위 안의 값을 가져야 한다면, 최소한 세 개의 동치 클래스가 존재한다. • 범위보다 작은 값 • 범위 내의 값 • 범위보다 큰 값 예) 현금 자동 지급기 지급 범위가 10,000원 ~ 30만원이라면 • 범위보다 작은 값  10,000원보다 작은 비정상 값 • 범위 내의 값  10,000원 ~ 30만원 정상 값 • 범위보다 큰 값  30만원보다 큰 비정상 값

동치 분해 (Equivalence Partitioning) (2/2) 테스트 (Test) • 방법 2) 이산적 집합(T/F)에 속하는 값이어야 정상 입력이라면, 두 가지 동치 클래스가 존재한다. • 정상 입력에 속하는 값 • 그 이외의 값 예) 학적 관리 시스템에서의 재학 상태 • 재학 상태의 정상적인 값, 즉, 재학, 휴학, 졸업, 중퇴 • 그 외의 비정상적인 값

식료품 이름 및 무게 예제 (1/2) 테스트 (Test) • 입력 조건 (품명, 무게1, 무게2, …) • 품명은 2 ~ 15 자리의 영문자 • 무게는 1 ~ 48 범위의 숫자(정수) • 무게는 오름차순으로 정렬 • 품명이 먼저 입력되고, 쉼표가 나오고, 무게 값의 리스트가 나옴 1. 품명의 이름은 영문자이어야 한다. 1) 영문자가 이름(정상): AbcDef 2) 영문자가 아닌 이름(비정상): A2X?/ 2. 품명은 2 ~ 15의 영문자이어야 한다. 3) 길이가 2 미만의 문자열(비정상): A 4) 2 이상 15 이하의 문자열(정상): AbcDef 5) 길이가 15보다 큰 문자열(비정상): abcdefghijklmnopqrstivwxyz

식료품 이름 및 무게 예제 (2/2) 테스트 (Test) 3. 무게는 1 ~ 48 사이의 정수 6) 1보다 작은 값(비정상): -1 7) 1 ~ 48 사이의 값(정상): 24 8) 48보다 큰 값(비정상): 127 9) 정수(정상): 24 10) 실수(비정상): 5.3 11) 숫자(정상): 24 12) 숫자 아님(비정상): 3A 4. 무게는 오름차순 이어야 함 13) 오름차순의 무게(정상): 1, 2, 3 14) 오름차순이 아닌 무게(비정상): 2, 1, 3 ......  나머지는 교재 참조

경계 테스트 (Boundary Test) 테스트 (Test) 많은 오류가 자료 값 범위의 경계에서 발생한다는 경험에 따라, 경계 값에 대해서 테스트를 수행한다. 예: 무게가 1 ~ 48이면, 1과 48, 그리고 0과 49를 시험한다.

자료 구조 중심 테스트 테스트 (Test) • 자료구조, 특히 배열(array) 및 구조(structure)와 관련된 오류를 검출하기 위한 테스트 • 예) 연결된 리스트(linked list)나 배열 1. 배열이나 리스트의 요소가 하나도 없음 2. 하나의 요소만 가짐 3. 배열이나 리스트가 가질 수 있는 최대 크기 보다 하나 작은 요소를 가짐 4. 배열이나 리스트가 가질 수 있는 최대 크기의 요소를 가짐 • 유사한 방법으로 구조체(structure) 타입도 테스트

자료 구조 중심 테스트 예제 테스트 (Test) 학교 A를 설립하려고 한다. 학교 A에서는 학생의 레코드를 배열에 저장하려 하고, 최대 학생 수는 2,000명이라고 하자. 학교가 설립될 당시는 학생 수가 0이므로, 이때 배열이 바르게 동작하는지 확인한다. 학생들이 증가하여 1 혹은 1999명이 되었을 때, 배열이 바르게 동작하는지 확인한다. 학생 수가 최대치인 2,000명에 이르렀을 때, 배열이 바르게 동작하는지 확인한다.

통합 테스트 (Integration Test) 테스트 (Test) • 통합 테스트의 목적 • 시스템을 구성하는 모듈의 인터페이스와 결합을 테스트 • 시스템 전체의 기능과 성능을 테스트 • 통합 순서에 따라 • 동시식(big-bang)  단번에 해치워… • 하향식(top-down)  위에서부터 아래로… • 상향식(bottom-up)  아래서부터 위로… • 연쇄식(threads)  중요한 것을 중심으로 동시에… • 통합 시 필요한 소프트웨어 • 테스트 하니스(harness): 부분적인 테스트를 위하여 코드에 삽입하는 프로그램 추후 삭제됨 • 스텁(stub): 시험 대상 모듈이 호출하는 모듈 대신에 만들어진 모의 서브루틴 • 드라이버(driver): 시험 대상 모듈을 호출하는 모의 모듈 Driver 테스트 대상 Harness Stub

동시식 통합 (Big Bang) 테스트 (Test) 모든 모듈을 한꺼번에 통합하여 테스트 단위 테스트에 많은 시간이 필요 시스템의 중요 부분과 부수적인 부분을 구별하지 않음 일정 계획에 융통성이 없음 오류가 있을 경우 어떤 모듈이 변경되어야 하는지 파악하기 어려움

하향식 통합 (Top-down) 테스트 (Test) 시스템 구조도의 위에 있는 모듈부터 아래 층의 모듈로 내려 오면서 통합 점증적 통합이므로 하드웨어의 사용이 분산되고 오류의 원인을 찾아 내기 쉬움 상위층의 중요한 모듈을 먼저 시험  시스템의 골격을 조기에 테스트 함 스텁의 사용으로 시스템의 모양을 사용자에게 조기에 보여줄 수 있음 프로그래머가 시스템의 작동에 대한 확신을 유지시킬 수 있음

상향식 통합 (Bottom-up) 테스트 (Test) 최하위 모듈을 먼저 시험 드라이버가 필요 (특성상, 스텁은 거의 필요치 않음) 오류 발견이 쉽고 하드웨어의 사용을 분산 하위층의 모듈을 상위층 보다 더 많이 시험 테스트의 초기에 뼈대가 갖추어지지 않음

연쇄식 통합 (Threads) 테스트 (Test) 최선의 통합 방법 어느 정도의 기본 기능을 수행하는 모듈(thread)로부터 통합 시스템의 중요한 기능을 담당하는 모듈부터 통합 초기에 시스템을 골격을 보여주고 사용자의 의견을 받아 수정 가능  주요 테스트 작업을 동시에 진행할 수도 있음 (independent한 경우)

기타 통합 테스트 테스트 (Test) • 구조 테스트 • 각 모듈의 입력, 출력 매개변수 • 유틸리티 호출을 포함한 모든 모듈의 호출 • 기능 테스트 • 시스템 전체를 하나의 블랙박스로 보고 시험 • 정상적인 입력에 대하여 시험 • 입력과 출력 예상 결과를 비교 • 성능 테스트: 트래픽 처리, 가입자 용량, … • 스트레스 테스트: 고온/저온 테스트, 고압/저압 테스트, …

통합 작업 일정 테스트 (Test)

테스트 항목 예제 테스트 (Test)

시험 절차서 예제 테스트 (Test)

인수 테스트 테스트 (Test) • 목적 • 시스템이 사용할 수 있도록 모든 준비가 되어 있는지를 보이는 것 • 사용할 모든 준비가 되었다는 것을 확인시켜 주는 작업 • 테스트 방법은 사용자가 선택 • 인수 테스트 방법의 대부분은 통합 테스트와 같음.다른 점은 (시험 환경이 아닌) 사용자 환경에서 한다는 것 • 알파 테스트: 사내 고객들을 대상으로 시험 • 베타 테스트 • 고객의 사용 환경에서 시험 • 개발자 없이, 실제 사용 환경에 소프트웨어를 설치하여 시험

알파 테스트 관련 기사 테스트 (Test)

베타 테스트 관련 기사 테스트 (Test)

소프트웨어 공학 (Software Engineering ) 테스트 (Test) 문양세 강원대학교 IT 대학 컴퓨터과학전공