티스토리 뷰

디버깅/테스트하기

테스트 레벨별 계획 수립

고객의 요구사항을 반영하여 개발된 앱을 테스트 레벨별(단위/통합/시스템/인수 테스 트)로 검증할 수 있도록 테스트 계획을 수립할 수 있다.

소프트웨어 테스트

V모델

V모델은 Water-fall의 확장형으로, Water-fall 모델의 개발 각 단계를 각각 대칭되는 4가 지 단계의 테스팅 모델로 정의하여 테스트 절차를 강화한 개발 모델이다. V모델은 개발 및 테스트 단계를 기준으로 개발 모델상의 구현을 수행하는 좌측의 Verification(검증) 테스트 영역과 개발이 된 시스템을 가지고 테스트를 하는 Validation(확 인) 영역으로 나뉜다.

좌측 부분에 대한 ‘검증’을 ‘Verification’이라고 하는데, Verification의 의미는 ‘우리 가 맞는(right) 제품을 만들고 있는가?’를 검증하는 것이고, 우측 부분에 대한 ‘확인’은 ‘Validation’으로 그 의미는 ‘우리가 제품을 맞게(right) 만들고 있는가?’를 검증하는 것이다. Verification 작업을 하기 위해서는 제품을 개발하기 전에 요구사항이나 디자인이 옳은지 를 점검하게 되는데, 이러한 작업은 주로 문서를 기반으로 이루어진다. 이렇게 실제로 작 동하는 시스템이 아닌 문서와 같이 정적인 것을 가지고 검증을 하는 것을 정적 테스트 (static test)라고 한다. 이 정적인 것이란 ‘소스코드, 설계문서, 요구사항 정의서’와 같은 산출물이 중심이 된다.

우측 영역인 동적 테스트는 작동이 가능한 실제 시스템을 기반으로 테스트를 수행한다. 동 적 테스트의 각 테스트 단계는 좌측 영역에 맵핑되는 각 단계의 내용을 기반으로 하여 검 증을 수행한다. 단위 테스트 단계에서는 구현에 대한 신뢰성 검증을, 통합 테스트는 상세설계에 대한 유효성 검증을, 시스템 테스트 단계에서는 설계에 대한 검증을, 그리고 인수 테스트 단계에서는 사용자 요구사항에 대한 만족도를 중심으로 테스트를 수행하게 된다.

테스트 레벨

V모델에 따르면, 동적 테스트는 단계별로 테스트의 범위와 주체에 따라 단위 테스트, 통 합 테스트, 시스템 테스트, 인수 테스트 4가지로 분리될 수 있다.

소프트웨어 테스트 프로세스

테스트 프로세스는 테스트의 목표를 수립하는 계획 단계, 결함을 검출하기 위해 효과적인 테스트 데이터를 준비하는 테스트 설계 단계, 소프트웨어에 입력하여 결과를 얻어내는 테 스트 실행 단계, 테스트에서 얻어진 결과를 분석하고 기록하는 평가 단계 등 총 4가지 프 로세스로 구성된다. 이 프로세스는 단위 테스트 과정에서는 사용되지 않고, 단위 테스트 이상의 통합, 시스템, 인수 테스트 과정에서만 사용된다. 단위 테스트는 개발자 또는 개발 자와 단위 테스터가 함께 개발 과정 중에 병행해서 진행하기 때문에 이렇게 복잡한 테스 트 프로세스를 필요로 하지 않는다.

테스트 계획

테스트 계획(test plan)은 프로젝트 계획서, 요구사항 명세서를 바탕으로 테스트의 목표를 수립하고, 테스트 대상 및 범위를 선정하는 활동이다. 효율적인 테스트를 위한 전략, 일정 등을 포함한 테스트 계획서를 작성한다. 테스트 활동 전체에 대한 최상위 테스트 계획서 (master test plan)는 프로젝트의 개발 생명주기 내에서 각 단계별로 적절한 테스틀 활동 을 통해 오류 검출 및 추적을 할 수 있도록 계획을 세우는 전체적인 테스트 지침 문서이 다. 최상위 테스트 계획서를 작성하는 목적은 포괄적인 테스트 계획과 여러 테스트 단계 를 관리하기 위해서이다. 이 문서를 통해 각각의 테스트 단계에 이루고자 하는 목적과 테 스트를 수행하는데 소요되는 노력(시간과 자원)을 정의하며, 각 단계 간의 연관성을 밝힌 다. 또한 품질보증 계획에 따라 각 단계에서 충족해야 할 목표를 제시한다.

테스트 분석 및 디자인(설계)

테스트에 사용할 특정한 입력 값을 테스트 케이스라 부른다. 테스트에 필요한 최적의 입 력 값을 찾아내는 것을 테스트 케이스 설계 또는 간단히 테스트 설계(test design)라고 한 다. 훌륭한 테스트 설계는 적은 수의 테스트 케이스를 사용하여 오류를 검증할 확률이 높도록 구성하는 것이다. 물론 테스트를 제대로 수행하기 위해 명세서가 반드시 있어야 하 고, 의도한 내용이 명세서에 빠짐없이 반영되어야 하며, 개발자가 명세서 내용을 정확히 코드에 반영할 수 있 있어야 한다. 각 테스트 단계별로 이루어지는 테스트 케이스 설계는 우선 어떤 테스트 기법을 선정하여 시험할 입력 값을 얻을지 정하고, 이를 바탕으로 테스트할 입력 값(테스트 케이스)을 도출 하고, 테스트 절차 및 환경을 구축한다.

테스트 설계단계의 주요 산출물인 IEEE standard for software test documentation(IEEE std 829-1998)에서 권고하는 테스트 설계서(test design specification), 테스트 케이스 명세 서(test case specification), 테스트 절차서(test procedure specification)를 작성한다.

테스트 케이스 구현 및 수행(테스트 실행)

테스트 실행(test execution) 단계는 테스트 계획 단계에서의 계획서와 테스트 설계 단계에 서의 테스트 케이스 설계서, 테스트 절차서를 기반으로 구현된 소프트웨어를 구동시켜 테 스트를 실시하는 단계이다. 이 단계에서는 실제 테스트를 수행하고 그 결과를 기록한 테 스트 상황 기록 문서를 생성한다. 테스트 상황 기록 문서에는 테스트를 수행하며 발생하는 사항을 시간대별로 기록한다. 자 동화된 도구를 사용해 작성된 로그를 활용하기도 한다.

테스트 결과 평가 및 리포팅

테스트 활동의 결과와 얻어진 출력 값을 분석하여 테스트 성공 여부에 대하여 평가하고 권고사항을 작성하는 등 테스트 결과 분석 및 평가(test result analysis and evaluation)를 한다. 프로젝트에서 정의한 각각의 테스트 단계에 대한 테스트 보고서를 작성해야 한다 (예를 들어 단위 테스트 보고서, 인수 테스트 보고서). 테스트 보고서에는 테스트 사건 보고서와 테스트 요약 보고서의 내용이 포함된다.

UI/UX Design

UI/UX 환경 분석

UI/UX 계획 수립

사용자 리서치

UI/UX 요구 분석

UI/UX 콘셉트 기획

UI 아키텍쳐 설계

댓글
댓글쓰기 폼