surrealCode

테스트 도구

Stair — Thu, 12 Feb 2026 20:57:38 +0900

테스팅 지원 도구

테스트 도구는 다양한 테스트 활동을 지원하고 촉진한다

- 테스트 관리 도구 : 소프트웨어 개발수명주기, 요구사항, 테스트, 결함, 형상 관리를 용이하게 해서 효율성을 높인다.

- 정적 테스팅 도구 : 테스터의 리뷰와 정적 분석 수행을 지원한다.

- 테스트 설계 및 테스트 구현 도구 : 테스트 케이스, 테스트 데이터, 테스트 절차 생성을 용이하게 한다.

- 테스트 실행 및 테스트 커버리지 도구 : 자동 테스트 실행 및 커버리지 측정을 지원한다.

- 비기능 테스팅 도구 : 수동으로 실행하기 어렵거나 불가능한 비기능 테스트를 테스터가 수행할 수 있게 한다.

- 데브옵스 도구 : 데브옵스 배포 파이프라인, 작업 흐름 추적, 자동 빌드 프로세스, 지속적인 통합 및 배포를 지원한다.

- 협업도구 : 원활한 커뮤니케이션을 지원한다.

- 확장성 및 배포 표준화 지원 도구 : 가상 머신, 컨테이너화 도구 등

- 테스팅에 도움 되는 기타 도구 : 테스팅에 활용하면 스프레드시트도 테스트 도구가 된다.

테스트 자동화의 효과와 리스크

도구를 도입했다고 성공이 보장되진 않는다.

실질적이고 지속적인 효과를 얻기 위해서는 새로운 도구를 도입할 때마다 노력을 들여야 한다.

테스트 자동화가 가져올 수 있는 효과는 다음과 같다.

- 반복적 수작업을 줄여 시간 절약

- 일관성 및 재현성 향상으로 사람의 단순 실수 방지

- 보다 객관적인 평가, 사람이 판단하기 어려운 복잡한 측정치의 제공

- 테스트 관리 및 테스트 보고를 지원하기 위한 테스팅 정보에 더 쉽게 접근 가능

- 결함 조기 식별, 빠른 피드백, 출시 시간 단축을 가능하게 하는 테스트 실행 시간 단축

- 테스터가 새로운, 더 심층적이며 효과적인 테스트를 설계할 시간 확보

테스트 자동화 활용 시 잠재적 리스크는 다음과 같다.

- 도구의 효과에 대한 비현실적인 기대

- 도구 도입, 테스트 스크립트 유지 관리, 기존 수동 테스트 프로세스 변경에 필요한 시간, 비용, 노력에 대한 부정확한 추정

- 수동 테스팅이 더 적합한 곳에 테스트 도구 사용

- 도구에 지나치게 의존

- 폐업, 도구 지원 중단, 다른 공급 업체로 도구 매각, 열악한 지원 등 문제가 생길 수 있는 도구 공급업체에 대한 종속성

- 지원이 중단되거나, 추가 개발을 통해 내부 컴포넌트를 빈번하게 업데이트 해야 할 필요가 있는 오픈소스 SW의 사용

- 자동화 도구가 개발 플랫폼과 호환되지 않을 수 있음

- 규제 요건이나 안전 표준을 준수하지 않은 부적합한 도구의 선택

테스트 활동 관리

Stair — Wed, 11 Feb 2026 20:29:31 +0900

테스트 계획

테스트 계획서의 목적과 내용

테스트 계획서

- 테스트 목적 달성을 위한 방법과 일정을 문서화

- 수행한 테스트 활동이 정해진 기준을 충족하는데 도움

- 팀원과 기타 이해관계자의 의사소통 수단으로 사용

- 테스팅이 수립한 테스트 정책 및 전략을 준수함

테스트 계획 활동 : 테스터가 리스크, 일정, 인력, 도구, 비용, 노력 등 향후 문제를 고민하도록 한다.

테스트 계획서를 준비하는 과정은 테스트 목적을 달성하는 데 필요한 노력을 추론하는 유용한 방법이다.

테스트 계획서의 포함 내용

- 테스팅 정황(테스트 범위, 테스트 목적, 테스트 베이시스)

- 테스트 프로젝트의 가정 및 제약 사항

- 이해관계자(역함, 책임 등)

- 의사소통(의사소통 방법 및 빈도, 문서 양식 등)

- 리스크 목록

- 테스트 접근법

- 예산 및 일정

반복 주기와 릴리스 계획에 대한 테스터의 기여

SDLC에서 두가지의 계획, 릴리스 계획과 반복 주기 계획이 이루어진다.

릴리스 계획

제품 릴리스를 계획하는 단계로 제품 백로그를 정의하며, 큰 사용자 스토리를 작은 사용자 스토리들로 세분화 하는 작업을 포함할 수 있다. 개별 반복 주기의 테스트 접근법과 테스트 계획을 위한 기반이 된다.

반복 주기 계획

개별 반복 주기를 계획하는 것으로 반복 주기 백로그와 관련이 있다. 반복 주기 계획에 참여하는 테스터는 사용자 스토리의 구체적인 리스크 분석에 참여하고, 사용자 스토리의 테스트 용이성을 판단하고, 사용자 스토리를 업무 단위로 분류하고, 각 테스팅 업무에 필요한 테스트 노력을 추정한다.

시작 조건과 완료 조건

시작 조건 : 어떤 활동을 수행하기 위한 전제 조건을 정의, 시작 조건을 충족하지 못하면 해당 활동을 수행하는 것이 어려워져 들어가는 시간과 비용이 늘어난다.

--> 많이 사용하는 시작 조건 : 자원의 가용성, 테스트웨어 가용성, 테스트 대상의 초기 품질 수준

완료 조건 : 특정 활동의 종료를 선언하기 위해 달성해야 하는 사항들을 정의한다.

--> 일반적인 테스트 완료 조건 : 커버리지 수준, 미해결 결함 수, 결함 밀도, 예/아니오로 판단되는 기준

시작 조건과 완료 조건은 각 테스트 레벨에 대해 정의해야 하며, 테스트 목적에 따라 달라진다.

*시간 및 예산의 소진도 유효한 완료 조건으로 볼 수 있다.

**애자일 소프트웨어 개발에서 완료 조건을 완료의 정의라고 하는 경우가 많으며 릴리스 가능 항목에 대해 메트릭을 정의한다.

추정 기법

테스트 프로젝트의 테스트 목적을 달성하는 데 필요한 테스트 관련 작업량을 예측하는 것이다.

추정에는 항상 오류가 있을 수 있다는 점을 이해관계자가 명확하게 알고 있어야 한다.

보통은 큰 규모가 작은 규모 작업보다 부정확하다.

추정 기법중 4가지는 다음과 같다.

비율 기반 추정 : 메트릭 기반 기법, 이전 프로젝트 수치를 수집해 표준 비율을 도출

외삽법 : 메트릭 기반 기법, 현재 프로젝트에서 데이터 수집을 위해 가능한 빨리 측정을 수행. 이후 외삽법을 적용해 남은 작업에

필요한 근사치를 추정 -> 반복적 SDLC에 매우 적합

와이드밴드 델파이 : 반복적, 전문가 기반 기법으로 전문가의 경험을 기반으로 추정함. 각 전문가는 독립적으로 노력을 추정

합의된 범위를 벗어나는 편차가 없을 때까지 추정치를 논의 후 새로운 추정치를 제시, 플래닝 포커와 비슷

3점 추정 : 전문가 기반 기법, 전문가가 세개의 추정치를 도출. 낙관적, 확률적, 비관적 추정치를 가지고 계산

테스트 케이스 우선 순위 지정

테스트 케이스와 테스트 절차를 도출해서 테스트 스위트로 조립하고 나면 테스트 스위트를 테스트 일정으로 구성할 수 있다.

테스트 일정은 테스트 실행 순서를 정의한다. 테스트 케이스의 우선 순위를 정할 때 다양한 요소를 고려할 수 있다.

- 리스크 기반 우선순위 지정 : 리스크 분석 결과에 따라 테스트 실행 순서를 결정한다.

- 커버리지 기반 우선순위 지정 : 가장 높은 커버리지를 달성하는 테스트 케이스를 먼저 실행한다.

- 요구사항 기반 우선순위 지정 : 실행 순서를 테스트 케이스의 기반이 되는 요구사항의 우선순위에 따라 결정한다.

위에서 언급한 것 중 하나 또는 여러 전략을 사용해 우선순위를 지정해서 테스트 케이스 실행 순서를 도출하는 것이 이상적이다.

그러나 TC, 테스트 대상 기능이 종속성을 가진 경우 그렇게 하기 힘들 수 있다.

-> 테스트 실행 순서에는 자원의 가용성도 고려해야 한다.

테스트 피라미드

테스트 피라미드 : 테스트에 따라 세분화 수준이 다를 수 있다는 것을 보여주는 모델이다.

테스트 피라미드 모델은 다양한 테스트 목표가 서로 다른 테스트 자동화 수준에 따라 지원된다는 것을 보여줌으로써 팀의 테스트 자동화와 테스트 노력 할당을 지원한다.

층이 높아질수록 테스트 세분화 정도는 낮아지고, 격리는 낮아지며(시스템의 다른 요소에 대한 의존도), 테스트 실행 시간은 길어진다. 아래층에 있는 테스트는 규모가 작고, 독립적이며 빠르다.

아래층 테스트는 기능이 작기 때문에 적절한 커버리지를 달성하기 위해 많은 테스트가 필요한 경우가 많다.

높은 층은 복잡하고 상위 수준의 엔드 투 엔드 테스트를 대변한다.

테스팅 사분면

브라이언 마릭이 정의한 테스팅 사분면은 애자일 소프트웨어 개발에서 테스트 레벨을 적합한 테스트 유형, 활동, 테스트 기법, 작업 산출물과 묶고 있다.

이 모델은 이런 사항들을 시각화해서 테스트 관리자가 필요한 모든 테스트 유형과 테스트 레벨을 소프트웨어 개발수명주기에 포함한다.

네개의 사분면은 다음과 같다

- 1사분면(기술 측면, 팀 지원) : 컴포넌트 테스트 및 컴포넌트 통합 테스트를 포함한다. 자동화 해야하며 CI에 포함되어야 한다.

- 2사분면(비즈니스 측면, 팀 지원) : 기능 테스트, 예제, 사용자 스토리 테스트 등을 포함한다. 인수 조건을 확인

- 3사분면(비즈니스 측면, 제품 평가) : 사용성, 사용자 인수테스팅 포함, 사용자 중심으로 이루어지며 수동으로 실행이 많다.

- 4사분면(기술 측면, 제품 평가) : 스모크 테스트와 비기능 테스트를 포함한다. 자동화 되는 경우가 많다.

리스크 관리

리스크 관리 : 조직이 목표를 달성할 가능성과 제품의 품질을 높이고, 이해관계자의 신뢰와 믿음을 얻을 수 있게 한다.

리스크 관리 활동은 다음과 같다

- 리스크 분석

- 리스크 제어

리스크 분석과 리스크 제어를 기반으로 텍스트 활동을 선택하고, 우선순위를 정해 관리하는 테스트 접근법을 리스크 기반 테스팅이라고 한다.

리스크의 정의와 리스크의 속성

리스크는 발생 시 부정적인 영향을 미칠 수 있는 잠재적인 사건, 위험, 위협 또는 상황을 말한다.

리스크는 두가지 요소로 특정 지을 수 있다.

- 리스크 발생 가능성 : 리스크 발생 확률(0보다 크고 1보다 작음)

- 리스크 영향(피해) : 발생했을 때 생기게 될 피해

두가지 요소로 리스크 수준을 표현한다. 리스크 수준은 리스크를 측정한 값이 된다.

프로젝트 리스크와 제품 리스크

일반적으로 소프트웨어 테스팅에서 두가지 유형의 리스크가 있다.

프로젝트 리스크 : 프로젝트 관리 및 제어와 관련이 있다. 프로젝트 리스크는 다음이 포함된다.

- 조직 문제

- 인력 문제

- 기술적 문제

- 공급업체 문제

제품 리스크 : 제품 품질 특성과 관련이 있다. 제품리스크가 발현되면 다음과 같은 부정적 결과를 초래할 수 있다.

- 사용자 불만족

- 매출, 신뢰, 평판 손실

- 제 3자 피해

- 높은 유지보수 비용, 고객지원 부서의 과부화

- 형사 처벌

- 극단적 경우 신체적 손상, 부상, 사망

제품 리스크 분석

테스팅 관점에서 제품 리스크 분석의 목표는 제품 리스크를 인식함으로써 잔존 제품 리스크 수준을 최소화하는 방향으로 테스트 노력을 집중할 수 있도록 하는 것이다. 제품 리스크 분석은 소프트웨어 개발수명주기 초기에 하는 것이 이상적이다.

제품 리스크 분석은 식별과 평가로 이루어진다.

리스크 식별 : 포괄적인 리스크 목록을 생성, 우선순위를 결정, 조치 방법 포함

리스크 평가 : 정략적 또는 정성적 접근법 사용, 정량적 접근법 리스크 발생 가능성과 리스크 영향을 곱함, 정성적 리스크 행렬 사용

제품 리스크 분석은 테스팅의 철저함 정도와 테스트 범위에 영향을 미칠 수 있다. 분석 결과는 다음과 같이 활용한다.

- 수행할 테스트 범위 결정

- 테스트 레벨 결정 및 수행할 테스트 유형 제안

- 사용할 테스트 기법과 달성할 커버리지 결정

- 업무별 필요 테스트 노력 추정

- 중요 결함을 가능한 한 빨리 식별하기 위한 테스트 우선순위지정

- 리스크를 줄이기 위해 테스팅 외 다른 활동을 할 수 있는지 판다

제품 리스크 제어

제품 리스크 제어 : 식별 및 평가된 제품 리스크에 대응해 취하는 모든 조치를 말한다.

제품 리스크 완화를 위해 취할 수 있는 조치는 다음과 같다.

- 주어진 리스크 유형에 적절한 경험과 기술을 갖춘 테스터 선정

- 적절한 수준의 테스팅 독립성 적용

- 리뷰 및 정적 분석 수행

- 적절한 테스트 기법 및 커버리지 수준 적용

- 영향을 받는 품질 특성을 다루는 적절한 테스트 유형 적용

- 리그레션 테스팅을 포함한 동적 테스팅 수행

테스트 모니터링, 테스트 제어, 테스트 완료

테스트 모니터링 : 테스팅에 대한 정보 수짐 -> 테스트 진행 상황 평가 및 완료 조건 관련된 테스트 작업이 충족되었는지 측정에 사용

테스트 제어 : 테스트 모니터링에서 얻은 정보를 기반으로 효과적이고 효율적인 테스팅을 위한 제어 지침 등을 제공

테스트 완료 : 끝난 테스트 활동에서 데이터를 수집하여 경험, 테스트웨어, 기타 관련 정보를 수집

테스팅에 사용하는 메트릭

테스트 메트릭 : 계획한 테스트 일정 및 예산 대비 현재 진행 상황, 테스트 대상의 현재 품질, 테스트 목적이나 반복 주기 목표 대비 테스트 활동의 효과를 보여주기 위해 수집한다.

많이 사용하는 테스트 메트릭은 다음과 같다

- 프로젝트 진행 상황 메트릭

- 테스트 진행 상황 메트릭

- 제품 품질 메트릭

- 결함 메트릭

- 리스크 메트릭

- 커버리지 메트릭

- 비용 메트릭

테스트 보고서의 목적, 내용, 대상

테스트 보고 : 테스팅 도중과 이후에 테스트 정보를 요약하고 전달하는 활동

테스트 진행상황 보고서 : 테스트 제어를 지원하며, 계획에서 벗어나거나 상황이 바뀌어 테스트 일정, 자원 테스트 계획을 수정해야 할 경우 그것을 할 수 있는 충분한 정보를 제공해야 한다.

테스트 진행 상황 보고서의 포함 내용은 다음과 같다

- 테스팅 기간

- 테스팅 진행 상황

- 테스팅 진행 방해 요소와 대응 방법

- 테스트 메트릭

- 테스팅 중 식별한 신규 및 변경된 리스크

- 다음 주기에 예정된 테스팅

테스트 완료 보고서 : 프로젝트, 테스트 레벨, 테스트 유형이 끝나고 작성된다.

테스트 완료 보고서의 포함 내용은 다음과 같다.

- 테스트 요약

- 원래 테스트 계획에 기반한 테스팅 및 제품 품질 평가

- 테스트 계획과의 편차

- 테스팅 방해 요소와 대응 방법

- 테스트 진행 상황 보고서를 기반으로 한 테스트 메트릭

- 완화되지 않은 리스크, 수정되지 않은 결함

- 테스팅 관련 교훈

보고하는 대상에 따라 보고서에 들어갈 정도가 달라지고, 보고의 형식과 빈도도 달라진다. 같은 팀 구성원에게 테스트 진행 상황을 보고할때는 빈번하고 비공식적인 경우가 많지만, 테스트완료 보고는 정해진 템플릿을 따르며 한 번만 이루어지는 것이 일반적이다.

테스팅 상황 전달

테스트 상황을 전달하는 가장 좋은 의사소통 방법은 테스트 관리자의 관심, 조직의 테스트 전략, 규제 표준 등에 따라 달라진다.

- 팀원 및 기타 이해관계자와의 대화

- 대시보드

- 전자 통신 채널

- 온라인 문서

- 공식 테스트 보고서

이런 선택지 중 하나 이상을 사용할 수 있다. 물리적 거리나 시차로 인해 직접적인 대화가 어려운 팀은 더욱 공식적인 의사소통 방법을 사용하는 것이 적합할 수 있다.

형상 관리

형상 관리 : 테스트 계획서, 테스트 전략서, 테스트 컨디션, 테스트 케이스, 테스트 스크립트 등 작업 산출물을 형항 항목으로 식별, 제어, 추적한다.

형상관리는 새 베이스라인을 만들 때 변경된 형상 항목에 대한 기록을 유지한다. 이전 베이스라인으로 되돌리면 이전 테스트 결과를 재현할 수 있게 된다.

테스팅을 적절히 지원하기 위해 형상 관리는 다음을 보장한다

- 테스트 항목을 포함한 모든 형상 항목에는 고유한 식별자가 부여되고, 버전이 관리되며, 변경사항이 있는지 추적된다

- 식별된 모든 문서와 소프트웨어 항목은 테스트웨어 내에 명확하게 참조되어야 한다.

결함 관리

*테스트의 주요 목적 중 하나가 결함 식별이므로 잘 확립된 결함 관리 프로세스가 필요하다. 여기서 '결함'이라고 부르고 있지만, 보고된 이상 사항은 실제로 결함일수도 아닐수도 있다. 이 문제는 결함 보고서를 처리하는 과정에서 해결된다.

이상 사항은 소프트웨어 개발수명주기 모든 단계에서 보고될 수 있으며, 그 양식은 소프트웨어 개발수명주기에 따라 달라진다.

일반적인 결함 보고서는 다음과 같은 목적을 가진다.

- 결함을 처리 및 해결하는 책임을 진 사람에게 문제 해결을 위한 충분한 정보 제공

- 작업 결과물의 품질을 추적할 수 있는 수단 제공

- 개발 및 테스트 프로세스 개선을 위한 아이디어 제공

일반적으로 동적 테스팅 중에 작성하는 결함 보고서는 다음을 포함한다.

- 고유 식별자

- 보고하는 이상 사항을 요약하는 제목

- 이상 사항이 관찰된 날짜, 보고 주체 조직, 작성자

- 테스트 대상 및 테스트 환경 식별 정보

- 결함의 정황

- 이상 사항을 발견한 절차, 관련 테스트 로그, 데이터베이스 덤프, 스크린샷, 녹음 파일 등

- 기대 결과와 실제 결과

- 결함이 이해관계자의 이익 또는 요구사항에 끼치는 영향의 심각도

- 수정 우선순위

- 결함 상태

- 참조 사항

이런 데이터 중 일부는 결함 관리 도구를 사용하면 자동으로 포함된다.

테스트 분석과 설계

Stair — Tue, 10 Feb 2026 10:54:55 +0900

테스트 기법 개요

테스트 기법은 테스터의 테스트 분석(무엇을 테스트할지)와 테스트 설계(어떻게 테스트할지) 작업을 지원한다.

테스트 기업은 적은 수이지만, 충분한 TC를 체계적인 방식으로 개발할 수 있도록 해준다.

테스트 기법은 테스터가 체스트 분석과 설계에서 테스트 컨디션을 정의하고, 커버리지 항목과 테스트 데이터를 식별하는 데 도움을 준다.

테스트 기법은 세가지로 분류된다.

- 블랙박스 테스트 기법(명세 기반 기법) : 내부 구조를 참조하지 않고, 명시된 동작에 대한 분석을 기반으로 한다. TC는 소프트웨어

구현방식에 의존하지 않는다. 구현이 바뀌어도 동작이 동일하면 TC는 유효하다.

- 화이트박스 테스트 기법(구조 기반 기법) : 테스트 대상의 내부 구조와 처리에 대한 분석을 기반으로 한다. TC는 소프트웨어 설계

방식에 의존하기 때문에 테스트 대상의 설계나 구현이 끝난 후에 만들 수 있다.

- 경험 기반 테스트 기법 : 테스터의 지식과 경험을 테스트 케이스의 설계 및 구현에 효과적으로 활용하게 한다. 이 기법의 효과성은

테스터의 능력에 따라 크게 달라진다. 경험 기반 테스트 기법은 블랙박스, 화이트박스 기법으로 식별하지

못하는 결함을 찾을 수 있게 해준다.

블랙박스 테스트 기법

많이 사용되는 블랙박스 테스트 기법은 다음과 같다

- 동등 분할

- 경계값 분석

- 결정 테이블 테스팅

- 상태 전이 테스팅

동등 분할

동등 분할은 테스트 대상이 하나의 분할에 포함된 모든 요소를 동일한 방식으로 처리할 것이라는 가정 하에 데이터를 분할 단위로 나눈다. 동등 분할에 속한 특정 값을 테스트 하는 테스트 케이스로 결함을 식별할 수 있다면, 같은 동등 분할의 다른 어떤 값을 테스트하는 TC라도 해당 결함을 식별할 수 있어야 한다는 것이다.

-> 따라서 각 분할에 대해 하나의 테스트만 수행하면 충분하다.

분할을 연속적이거나 아닐수도 있으며, 유한 또는 무한일수도, 정렬되어 있을수도 있다. 분할은 겹치지 않아야 하며, 값이 없는 공집합일 수는 없다. 단순한 테스트일 경우, 동등 분할을 적용하기가 쉽지만, 실제로는 테스트 대상이 다양한 값을 어떻게 처리하는지 이해하기 어려울 때가 많다. 따라서 분할 식별은 신중하게 해야 한다.

유효한 값을 포함하는 분할을 유효 분할, 비유요한 값을 포함하는 분할을 비유효 분할이라고 한다.

동등 분할에서 커버리지 학목은 각 분할이 된다. 이 테스트 기법으로 100%커버리지를 달서앟려면 테스트 케이스로 각 분할을 최소 한번씩 다뤄 식별한 모든 분할이 실행되도록 해야 한다.

많은 테스트 항복이 다수의 분할 집합을 가지고 있기 때문에 하나의 테스트 케이스는 여러 분할 집합에 속한 분할을 다루게 된다. 분할 집합이 다수인 경우, 가장 간단한 커버리지 기준을 이치 초이스 커버리지 라고 한다.

이치 초이스 커버리지는 테스트 케이스가 모든 분할 집합의 각 분할을 최소 한번은 실행할 것을 요구한다.

--> 이치 초이스 커버리지에서는 분할의 조합은 고려하지 않는다.

경계값 분석

경계값 분석은 동등 분할의 경계 실행을 기반으로 하는 테스트 기법이다. 따라서 경계값 분석은 정렬된 분할에만 사용할 수 있다.

분할의 최솟값과 최댓값이 경계값이 된다. 경계값 분석에서 두 값이 같은 분할에 속하는 경우, 둘 사이의 모든 값도 해당 분할에 속해야 한다.

개발자가 분할의 경계에 있는 값을 다룰 떄 오류를 범할 가능성이 높기 때문에 경계값 분석은 분할의 경계에 있는 값에 초점을 두게 된다. 경계값 분석으로 많이 찾는 결함은 구현된 경계가 의도한 위치보다 위나 아래에 잘못 배치되거나 누락된 결함이다.

경계값 분석은 두가지 유형이 있다.

- 두 개 선택 경계값 분석

- 세 개 선택 경계값 분석

두 유형은 100%의 커버리지를 달성을 위해 실행해야 하는 경계별 커버리지 항목의 수에서 차이가 난다.

두 개 선택 경계값 분석은 각 경계값에 대해 두 개의 커버리지 항목을 도출한다.

경계값과 인전 분할에 속한 가장 가까운 값이 커버리지 항목이다. 두 개 선택 경계값 분석에서 100%커버리지를 달성하려면, 테스트케이스로 모든 커버리지 항복, 식별한 모든 경계값을 실행해야 한다. 커버리지는 실행한 경계값의 수/경계값의 총 수 이다.

세 개 선택 경계값 분석은 각 경계값에 대해 세 개의 커버리지 항목을 도출한다.

이웃한 양쪽의 값 모두가 커버리지 항목이다. 따라서 세 개 선택 경계값 분석에서는 경계값이 아닌 커버리지 항목도 있을 수 있다. 세 개 선택 경계값 분석에서 100% 커버리지를 달성하려면, 테스트 케이스로 모든 커버리지 항목, 식별한 경계값과 그 이웃 값을 실행해야 한다. 커버리지는 실행한 경계값과 이웃한 값의 수/식별한 경계값과 이웃 값의 총 수 이다.

결정 테이블 테스팅

결정 테이블은 서로 다른 조건 조합으로 달라지는 결과를 나타내는 방식으로 요구사항이 제대로 구현되었는지를 테스트 하는 데 사용한다. 결정 테이블은 비즈니스 규칙과 같은 복잡한 논리를 기록하는 효과적인 방법이다.

결정 테이블을 만들 때 조건들과 그에 따른 시스템의 동작 결과를 정의한다.

조건의 표기법은 T, F, -, N/A로 표기한다.

전체 결정 테이블에는 모든 조건 조합을 포함할 수 있는 충분한 열이 있다. 실현 불가능한 조건 조합열을 삭제해 테이블을 더 단순화 할 수 있다.

일부 조건이 결과에 영향을 미치지 않는 열들을 하나로 병합해 테이블을 최소화 할 수도 있다.

이 기법으로 100%커버리지를 달성하려면 테스트케이스가 이런 열을 모두 실행해야 한다.

커버리지는 실행된 열의 수/실행 가능한 열의 총 수로 나눈 값으로 측정하며 백분율로 표시한다.

결정테이블의 장점 : 간과했을 수도 있는 조합을 포함한 모든 조건 조합을 식별하는 체계적인 방법을 제공한다.

결정테이블의 단점 : 조건이 많으면 규칙의 수가 기하급수적으로 늘어 오랜 시간이 걸릴 수 있다.

상태 전이 테스팅

상태 다이어그램(state diagram)은 가능한 상태와 유효한 상태 전이를 표시해 시스템 동작을 모델링한다.

전이는 하나의 이벤트에 의해 발생하며, 별도의 가드 조건이 있을 수 있다. 전이는 즉각적인 것으로 간주되며, 소프트웨어의 어떤 동작으로 연결되기도 한다.

상태 테이블은 상태 다이어그램을 다르게 표현한 모델이다. 행은 상태를 나타내고, 열은 이벤트를 나타낸다. 테이블 항목은 전이를 나타네며, 정의되어 있는 경우에는 목표 상태와 그에 따른 결과 동작도 함께 포함한다. 상태 전이 다이어그램과 달리 상태 테이블은 유효하지 않은 전이를 "빈 셀"로 명확하게 보여준다.

상태 다이어그램이나 상태 테이블을 기반으로 하는 테스트 케이스는 보통 일련의 이벤트 순서와 그 결과로 생기는 상태 변화로 표현된다. 하나의 테스트 케이스는 대부분의 경우 여러 개의 상태 전이를 포함한다.

상태 전이 테스팅에는 세가지 커버리지 측정 기준이 있다.

- 모든 상태 커버리지 : 커버리지 항목은 상태이다. 100%커버리지를 달성하려면 모든 상태가 실행되도록 TC를 구성해야 한다.

- 유효 전이 커버리지 : 각 유효 전이가 커버리지 항목이다. 100%커버리지를 달성하려면 TC가 모든 유효 전이를 실행해야 한다.

- 모든 전이 커버리지 : 상태 테이블에 표시된 모든 전이들이 항목이다. 100%를 달성하려면 TC로 모든 유효 전이를 실행하고

유효하지 않은 비유효 전이의 실행도 시도해야 한다. 오직 하나의 비유효 전이만을 테스트 하는 것은

결함 마스킹을 방지하는 데 도움이 된다.

모든 상태 커버리지는 일반적으로 모든 전이를 실행하지 않고도 달성하기 때문에 유효 전이 커버리지보다 약하다.

유효 전이 커버리지는 가장 널리 사용하는 커버리지 조건이다.

유효 전이 커버리지 100%를 달성하면 모든 상태 커버리지도 달성된다.

모든 전이 커버리지 100%를 달성하면 모든 상태 커버리지와 유효 전이 커버리지도 모두 모장된다.

모든상태 < 유효전이 < 모든전이

미션과 안전에 치명적인 소프트웨어의 경우 이것을 충족해야 할 최소 기준으로 삼으면 된다.

화이트박스 테스트 기법

화이트 박스 테스트는 다음 두가지 기법이 가장 널리 사용된다.

- 구문 테스팅

- 분기 테스팅

안전이나 미션에 치명적이거나 무결성이 높아야 하는 환경에서는 철저한 코드 커버리지를 달성하기 위해 보다 엄격한 화이트박스 기법이 사용된다. 또한 상위 테스트 레벨에 사용하거나, 코드와 관련 없는 커버리지를 사용하는 화이트 박스 테스트 기법도 있다.

구문 테스팅과 구문 커버리지

구문 테스팅에서 커버리지 항목은 실행 가능한 구문이 된다.

코드 구문을 실행하는 테스트 케이스를 설계해서 허용할 수 있는 수준의 커버리지를 달성하는 것이다. 커버리지는 테스트 케이스가 실행한 구문 수를 코드의 실행 가능한 구문 총수로 나누어 계산하며 백분율로 표시한다.

100% 구문 커버리지를 달성하면 코드의 모든 실행 가능한 구문을 적어도 한 번은 실행하겠다는 것이 보장된다. 이는 결함이 있는 모든 구문도 실행해 결함 존재를 식별할 수 있는 장애가 났타났어야 함을 의미한다고 여길 수 있다.

그러나 TC로 구문을 실행했다고 결함이 반드시 식별되는 것은 아니다. ex)데이터에 종속적인 결함 등

또한 100%구문 커버리지가 모든 결정 논리를 테스트했다고 보장하는 것도 아니다.

분기 테스팅과 분기 커버리지

분기는 제어 흐름 그래프에서 두 노드 간의 제어 이동으로 테스트 대상에서 소스 코드 구문의 실행 가능 순서를 보여준다.

제어의 이동은 조건 없이 또는 조건에 따라 이루어질 수 있다.

분기 테스팅에서 커버리지 항목은 분기이며, 목적은 코드의 분기를 실행하는 TC를 설계해서 허용할 수 있는 수준의 커버리지를 달성하는 것이다.

100% 분기 커버리지를 달성하면 코드의 모든 분기를 테스트 케이스로 실행하게 된다.

분기 커버리지는 구문 커버리지를 포함한다. 100% 분기 커버리지를 달성하는 테스트 케이스 집합은 100% 구문 커버리지도 달성

화이트박스 테스팅의 가치

화이트박스 테스트 장점 : 테스트 중 전체 소프트웨어 구현을 고려하므로 소프트웨어 명세가 모호하거나 뒤떨어지고 불완전한 경우에도 결함을 쉽게 찾을 수 있다.

화이트박스 테스트 단점 : 소프트웨어가 하나 이상의 요구사항을 구현하지 않는 경우 누락 됐다는 결함을 식별하지 못할 수 있다.

화이트박스 테스트 기법은 정적 테스팅에 사용할 수 있다. 아직 실행할 준비가 되지 않은 코드 외에도 슈도코드 또는 제어 흐름 그래프로 모델링 할 수 있는 상위 수준 및 하향식 논리를 검토하는 데 적합핟.

** 블랙박스 테스팅만 수행해서는 실제 코드 커버리지 측정치를 얻을 수 없다. 화이트박스 커버리지 측정치는 객관적인 커버리지 측정 값을 제공하고, 이 커버리지를 높이기 위해 추가 테스트 생성을 위한 정보도 제공함으로써, 코드 신뢰도를 높일 수 있다.

경험 기반 테스트 기법

경험 기반 테스트 기법 중 주요한 3가지는 다음과 같다.

- 오류 추정

- 탐색적 테스팅

- 체크리스트 기반 테스팅

오류 추정

오류 추정 : 테스터의 지식을 기본으로 오류, 결함, 장애 발생을 예측하는 데 사용하는 테스트 기법이다.

테스터의 지식에는 다음이 포함된다.

- 애플리케이션의 과거 동작

- 개발자가 범하기 쉬운 오류 유형과 이런 오류로 인해 발생하는 결함 유형

- 다른 유사 애플리케이션에서 발생한 장애 유형

일반적으로 오류, 결함, 장애는 입력, 출력, 논리, 계산, 인터페이스, 데이터와 관련 있을 수 있다.

결함 공격 : 오류 추정을 구현하는 방법 중 하나이다. 테스터가 발생 가능한 오류, 결함, 장애 목록을 만들거나 획득하여 오류와 관련된 결함을 식별 및 노출하거나 장애를 유발하는 테스트를 설계하도록 한다.

탐색적 테스팅

탐색적 테스팅 : 테스터가 테스트 대상에 대해 배워가면서 테스트의 설계, 실행, 평가를 동시에 하게 된다. 이 테스팅은 테스트 대상에 대해 더 배우고, 집중하고 있는 테스트는 더 깊이 탐색하고, 테스트 되지 않은 영역에 대한 테스트를 만들기 위해 사용된다.

탐색적 테스팅은 떄로 테스팅을 구조화하기 위해 세션 기반 테스팅을 사용하기도 한다. 세션 기반 접근법에서는 탐색적 테스팅을 시간을 정해놓고 수행한다. 테스터는 테스트 목적이 정의된 테스트 차터를 테스팅 지침으로 사용한다.

탐색적 테스팅은 명세가 버ㅜ족하거나 부적합할 경우, 테스트에 시간적 압박이 심할 때 유용하다. 탐색적 테스팅은 다른 공식 테스트 기법을 보완하기에도 유용하다.

체크리스트 기반 테스팅

체크리스트 기반 테스팅에서 테스터는 체크리스트를 활용해 테스트 컨디션을 확인하는 테스트를 설계, 구현, 실행한다.

체크리스트는 경험, 사용자에게 중요한 것이 무엇인지에 대한 지식 또는 소프트웨어가 실패하는 이유와 방법에 대한 이해를 바탕으로 작성할 수 있다.

자동으로 점검할 수 있는 항목, 시작 조건, 종료 조건으로 더 적합한 항목, 너무 일반적인 항목은 체크리스트에 포함해서는 안된다.

체크리스트 항목을 질문 형식으로 표현하는 경우가 많다. 각 항목은 개별적이면서 직접적으로 확인할 수 있어야 한다. 이런 항목은 요구사항, 그래픽 인터페이스 속성, 품질 특성 또는 기타 유형의 테스트 컨디션일 수 있다.

체크리스트는 기능 및 비기능 테스트를 포함한 다양한 테스트 유형을 지원하기 위해 만들 수 있다.

시간이 지남에 따라 개발자가 같은 오류를 범하지 않게 됨으로써 일부 체크리스트 항목은 점차 효과가 떨어질 수 있다.

새로 발견한 심각도가 높은 결함으로 인해 새로운 항목을 추가해야 할 수도 있다.

-> 따라서 체크리스트는 정기적으로 업데이트 해야 한다.

협업 기반 테스트 접근법

협업 기반 접근법은 협업과 커뮤니케이션을 통한 결함 예방에 초점을 둔다.

협업 기반 사용자 스토리 작성

사용자 스토리는 사용자 또는 구매자에게 가치를 제공하는 기능을 나타낸다.

사용자 스토리는 다음 세가지 중요 요소를 가지고 있다. 이를 3C라고 부른다.

- 카드(Card) : 사용자 스토리를 설명하는 매체

- 대화(Conversation) : 소프트웨어 사용 방법에 대한 설명

- 확인(Confirmation) : 인수 조건

사용자 스토리의 가장 일반적인 형식은 "'역할'로서 '목표'를 달성해 [역할이 얻게 될 비즈니스 가치]를 얻기를 원한다"이며, 이 후 인수 조건이 뒤따르는 형식이다.

협업 기반 사용자 스토리 작성은 브레인스토밍, 마인드 매핑과 같은 기법을 사용한다.

좋은 사용자 스토리는 독립적이고, 협상 가능하고, 가치 있고, 추정 가능하고, 작고, 테스트 가능해야 한다(INVEST)

이해 관계자가 사용자 스토리를 테스트 하는 방법을 모른다면, 그 사용자 스토리가 명확하지 않거나 사용자에게 중요한 내용이 반영되어 있지 않거나, 이해관계자가 테스트를 수행하는 데 있어 도움이 필요하다는 것을 의미할 수 있다.

인수 조건

사용자 스토리의 인수 조건은 사용자 스토리 구현 결과를 이해관계자가 승인하기 위해 충족되어야 하는 조건이다.

인수 조건은 3C 중 대화(Conversation)을 통해 결정된다.

인수 조건은 다음을 위해 사용된다

- 사용자 스토리 범위 정의

- 이해관계자 간 합의 도출

- 긍정과 부정 시나리오 설명

- 사용자 스토리 인수 테스팅의 베이시스 제공

- 정확한 계획 및 추정

다양한 사용자 스토리의 인수 조건 작성법이 있으며 일반적인 형태는 두가지이다

- 시나리오 기반

- 규칙 기반

인수 테스트 주도 개발

인수 테스트 주도 개발은 테스트 우선 접근법이다. TC는 사용자 스토리 구현 전에 만들어진다.

테스트 케이스는 사용자 스토리의 모든 특성을 다뤄야 하며 스토리를 벗어나면 안된다.

테스트 자동화 프레임워크가 지원하는 형식으로 작성하면 개발자는 사용자 스토리에서 설명하는 기능을 구현할 때 필요한 코드를 작성해 테스트 케이스를 자동화 할 수 있다. 그러면 인수 테스트가 실행 가능한 요구사항이 된다.

정적 테스팅

Stair — Mon, 9 Feb 2026 11:28:57 +0900

정적 테스팅의 기초

정적 테스팅은 대상 소프트웨어를 실행하지 않아도 된다.

코드, 프로세스 명세, 시스템 아키텍쳐 명세, 기타 작업 산출물을 수동(ex : 리뷰)으로 또는 도구를 사용해 평가한다.

정적 분석 테스팅 목표 : 품질 개선, 결함 식별, 가독성/완전성/정확성/테스트 용이성/일관성 등의 특성 평가

** 정적 테스팅은 베리피케이션과 밸리데이션 모두에 적용할 수 있다.

정적 분석은 테스트 케이스가 필요하지 않다. 도구를 사용하는 경우가 많다.

- 상대적으로 적은 노력으로 동적 테스팅 전에 문제를 식별할 수 있다.

- 정적 분석을 CI 프레임워크에 통합하는 경우가 많다.

정적 분석의 사용처 : 구체적인 코드 결함을 식별하는데 사용, 유지보수성과 보안을 평가하는 데도 사용

정적 분석 도구 ex) 맞춤법 검사기, 가독성 도구

정적 테스팅으로 검사 가능한 작업 산출물

정적 테스트를 사용하여 거의 모든 작업 산출물을 검토할 수 있다.

ex) 요구사항 명세서, 소스 코드, 테스트 계획서, 테스트 케이스, 제품 백로그 항목, 테스트 차터, 프로젝트 문서, 계약서, 모델

읽고 이해할 수 있는 모든 작업 산출물은 리뷰 대상이 될 수 있다. 그러나 작업 산출물을 검토할 수 있는 기준이 되는 구조가 필요하다(모델, 공식 문법이 정해진 코드나 텍스트)

사람이 해석하기 어려운 것과 도구로 분석해서 안되는 작업 산출물(ex : 법적으로 문제가 되는 타사 코드)는 정적 테스트에 적합하지 않다.

정적 테스팅의 가치

정적 테스팅은 소프트웨어 개발수명주기(SDLC) 초기 단계에서 결함을 식별하기 때문에 조기 테스팅의 원리를 지킬 수 있게 한다.

또한 동적 테스팅으로 식별할 수 없는 결함(도달 불가능한 코드, 원하는대로 구현되지 않는 설계 패턴, 비실행 작업 산출물의 결함)등도 찾을 수 있다.

정적 테스팅은 작업 산출물의 품질을 평가하고 신뢰를 쌓을 방법을 제공한다. 또한 문서화 된 요구사항을 확인함으로써 요구사항이 실제로 자기가 필요한 것을 묘사하고 있는지 확인할 수 있다.

정적 테스팅은 SDLC 초기에 수행할 수 있으므로 이해관계자 간 공통된 이해를 형성할 수 있다.

이해관계자 간 의사소통도 개선된다.

리뷰 구축 비용은 많이 들 수 있으나, 프로젝트 후반에 결함을 수정하는 시간과 노력이 줄어들어 전체 프로젝트 비용이 낮아질 수 있다.

일부 코드 결함은 동적 테스팅보다 정적 분석을 통해 더 효율적으로 식별할 수 있다. -> 코드 결함이 줄고, 개발 노력도 감소

정적 테스팅과 동적 테스팅의 차이

정적 테스팅과 동적 테스팅은 서로를 보완한다. 두 활동은 작업 산출물 결함의 식별을 지원하는 듯 비슷하지만 다음과 같은 차이도 있다.

- 정적 테스팅이나 동적 테스팅 중 한가지로만 식별할 수 있는 겷함 유형도 있다.

- 정적 테스팅은 결함을 직접 식별하는 반면, 동적 테스팅은 장애를 일으킨 후 연관된 결함을 후속 분석을 통해 찾아낸다.

- 정적 테스팅은 실행되지 않거나, 동적으로 도달하기 어려운 코드 경로에 있는 결함을 쉽게 발견할 수 있다.

- 정적 테스팅은 비-실행(non-executable) 작업 산출물에도 적용할 수 있지만, 동적 테스팅은 실행 가능한 작업에만 적용

- 정적 테스팅은 코드 실행에 의존하지 않는 품질 특성(유지보수)측정, 동적은 코드 실행의 의존적인 품질 특성(성능 효율성) 측정

정적 테스팅을 통해 더 쉽게 적은 비용으로 식별할 수 있는 결함은 다음과 같다.

- 요구사항 결함

- 설계 결함

- 특정 유형의 코딩 결함

- 표준 위반

- 잘못된 인터페이스 명서

- 특정 유형의 보안 취약성

- 테스트 베이시스 커버리지의 차이 또는 부정확성

피드백과 리뷰 프로세스

이해관계자 피드백을 조기에 자주 받을 떄의 이점

피드백을 조기에 자주 받으면 잠재적인 품질 문제를 조기에 파악할 수 있다. SDLC동안 이해관계자의 참여가 적으면 개발 중인 제품이 이해관계자의 초기 및 현재 요구를 충족하지 못할 수 있다.

이해관계자가 원하는 것을 전달하지 못하면 큰 비용이 드는 재작업, 납기일 지연, 서로 간의 비난 등이 발생할 수 있으며, 프로젝트가 실패할수도 있다.

SDLC 전반에 걸쳐 이해관계자의 피드백을 자주 받으면, 요구사항에 대한 오해를 방지하고, 요구사항 변경을 조기에 이해하고 구현할 수 있다.

리뷰 프로세스 활동

ISO/IEC 20246 표준은 특정 상황에 맞게 리뷰 프로세스를 조정할 수 있는 체계적이면서 유연한 프레임워크를 정의한다 필요한 리뷰가 공식적일수록 각 활동에 대한 설명된 작업 중 수행할 것이 더 많아지게 된다.

작업 산출물이 너무 커서 한번의 리뷰로 다룰 수 없는 경우도 많다. 작업 산출물의 리뷰를 끝내기 위해 여러번 수행할 수도 있다.

리뷰 프로세스에 포함되는 활동은 다음과 같다.

- 계획 : 목적, 리뷰 대상 작업 산출물, 평가할 품질 특성, 집중할 영역, 완료 조건 등으로 리뷰의 범위를 정의해야 한다.

- 리뷰 착수 : 관련된 모든 사람과 사항이 시뷰를 시작할 준비가 되었는지 확인하는 것이다.

- 개별 리뷰 : 하나 이상의 리뷰 기법을 적용해 리뷰중인 작업 산출물의 품질을 평가하고, 의문사항 등을 식별하기 위해 수행한다.

리뷰어는 식별한 모든 이상 사항, 권장 사항, 의문 사항을 기록한다.

- 논의 및 분석 : 리뷰 중에 확인한 이상 사항이 반드시 결함은 아니므로 모든 이상 사항에 대해 분석하고 논의한다.

리뷰 회의를 통해 작업 산출물의 품질 수준, 필요한 후속 조치 등도 결정한다.

조치 완료를 위한 후속리뷰가 필요할수도 있다.

- 수정 및 보고 : 모든 결함에 대한 결함 보고서를 작성해 후속 조치가 추적 가능하도록 한다.

완료 조건을 충족하면 작업 결과물을 승인할 수도 있다.

리뷰에서의 역할과 책임

리뷰에서는 다양한 이해관계자가 참여하며, 한 명이 여러 역할을 동시에 맡을 수도 있다.

- 관리자 : 리뷰할 내용을 결정하고, 리뷰에 필요한 사람과 시간 등 자원을 제공한다.

- 저자 : 리뷰 대상 작업 산출물을 작성하고 수정한다.

- 중재자 : 중재, 시간 관리, 모든이가 자유롭게 발언할 수 있는 안전한 리뷰 환경 조성 등 리뷰 회의의 효과적인 운영을 담당한다.

- 서기 : 리뷰어로부터 이상 사항을 수집하고, 결정 사항이나 리뷰 회의 중에 발견한 새로운 이상 등 리뷰 정보를 기록한다.

- 리뷰어 : 리뷰를 수행한다. 리뷰어는 프로젝트에 참여하는 사람 또는 주제 전문가, 기타 이해관계자가 될 수 있다.

- 리뷰 리더 : 리뷰에 참여할 사람을 결정하고, 리뷰 시간과 장소를 협의하는 등 리뷰에 대한 전반적인 책임을 진다.

리뷰 유형

리뷰는 비공식, 공식 리뷰 등 다양한 유형이 있다.리뷰가 어느정도로 공식적이어야 하는지는 소프트웨어 개발수명주기, 프로세스의 성숙도, 산출물의 중요도와 복잡성 등에 따라 달라진다. 처음에는 비공식적으로 리뷰 후 나중에 보다 공석적으로 리뷰하는 등, 같은 작업 산출물도 여러 형태로 리뷰할 수 있다.

리뷰 유형은 다음과 같다.

- 비공식 리뷰 : 비공식 리뷰는 정의된 프로세스를 따르지 않으며 공식적인 결과 문서도 요구하지 않는다.

목적은 이상 사항을 식별하는 것이다.

- 워크쓰루 : 저자가 리더가 된다. 작업 산출물에 대한 신뢰 구축, 리뷰어 교육, 아이디어 창출, 이상 사항 발견 등

여러 목적을 달성할 수 있다. 리뷰어는 워크쓰루 전에 개별리뷰를 수행할 수도 있지만 필수는 아니다.

- 기술 리뷰 : 기술 리뷰는 기술적인 자격을 갖춘 리뷰어가 수행하고, 중재자가 리더가 된다. 기술 문제에 대한 합의를 도출하고, 결정을 내리는 것 뿐만 아니라 이상 사항 식별, 품질 평가 및 작업 산출물에 대한 신뢰 구축 등 저자가 개선할 수

있도록 동기를 부여하고 지원하는 것이다.

- 인스펙션 : 가장 공식적인 리뷰 유형, 이상 사항을 최대한 많이 찾는 것, 메트릭을 수집해 리뷰 프로세스를 포함한 전체

소프트웨어 개발수명주기를 개선하는데 사용한다.

리뷰의 성공 요소

리뷰의 성공 여부를 결정하는 요소는 다음과 같은 것들이 있다.

- 명확한 목표와 측정 가능한 완료 조건을 정의. 참가자의 평가가 목적이 되어서는 안된다.

- 주어진 목표를 달성할 수 있으면서, 유형, 참여자, 요구사항 등 정황에 맞는 리뷰 유형을 선택한다.

- 리뷰어가 개별 리뷰 또는 회의에서 집죽력을 잃지 않도록 작은 단위로 리뷰를 진행한다.

- 이해관계자와 저자에게 리뷰 피드백을 제공해 제품 및 활동을 개선할 수 있게 한다.

- 참가자가 리뷰를 준비할 수 있는 충분한 시간을 제공한다.

- 리뷰 프로세스를 관리층이 지원한다.

- 학습 및 프로세스 개선 촉진을 위해 리뷰가 조직 문화의 일부가 되도록 한다.

- 모든 참가자가 자신의 역할을 어떻게 충족해야 하는 지 알 수 있도록 적절한 교육을 제공한다.

- 회의에 퍼실리테이션을 적용한다.

소프트웨어 개발수명주기(SDLC)와 테스팅

Stair — Sun, 8 Feb 2026 09:21:55 +0900

소프트웨어 개발수명주기(SDLC)에서의 테스팅

소프트웨어 개발수명주기(SDLC) : 상위 수준에서 소프트웨어 개발 프로세스를 추상적으로 표현한 것

소프트웨어 개발수명주기 모델 : 개발 프로세스의 여러 단계와 활동 유형이 논리적, 시간상으로 서로 어떻게 연관되는지 정의한다.

SDLC 예 : 순차적 개발 모델(폭포수 모델, V-모델), 반복적 개발 모델(나선형 모델, 프로토타이밍), 점진적 개발 모델(통합 프로세스)등

소프트웨어 개발 프로세스 내 일부 활동을 구체적인 소프트웨어 개발 방법과 애자일 프랙티스로 설명하기도 한다.

인스 테스트 주도 개발(ATDD), 행위 주도 개발(BDD), 도메인 주도 설계(DDD), 익스트림 프로그래밍(XP), 기능 주도 개발(FDD), 칸반(kanban), 린(lean) IT, 스크럼(scrum), 테스트 주도 개발(TDD)등이 여기에 해당한다.

소프트웨어 개발수명주기(SDLC)가 테스팅에 미치는 영향

테스팅의 성공을 위해 소프트웨어 개발수명주기에 맞는 조정이 필요하다. 모델의 선택은 다음에 영향을 미친다.

- 테스트 활동 범위 및 시기(ex : 테스트 레벨 및 테스트 유형)

- 테스트 문서 상세화 수준

- 테스트 기법 및 테스트 접근법 선택

- 테스트 자동화 범위

- 테스터의 역할과 책임

순차적 개발 모델 : 테스터는 초기 단계에서 요구사항 리뷰, 테스트 분석과 설계에 참여. 코드는 개발 후반에 생성되므로 소프트웨어 개발수명주기 초기에 수행하지 못할 수 있음

반복적 모델, 점진적 개발 모델 : 각 반복주기마다 동작하는 프토로타입이나 제품 증분이 만들어진다고 가정. 반복 주기마다 모든 테스트 레벨에서 정적 테스팅과 동적 테스팅을 수행할 수 있음, 증분을 자주 하기 위해서 빠른 피드백과 광범위한 리그레션 테스팅이 필요

애자일 소프트웨어 개발 : 프로젝트의 어느 시점에도 변화가 생길 수 있다고 가정. 애자일 프로젝트는 리그레션 테스팅을 수월하게 하는 가벼운 작업 산출물과 테스트 자동화를 선호. 수동 테스팅도 경험 기반 테스트 기법으로 진행하는 경향이 있음

소프트웨어 개발수명주기(SDLC)와 좋은 테스팅 프랙티스

선택한 SDLC 모델에 상관없이, 다음과 같은 좋은 테스팅 프랙티스가 있다.

- 모든 소프트웨어 개발 활동에 상응하는 테스트 활동을 두어, 모든 개발 활동이 품질 제어의 대상이 되게 한다.

- 테스트 레벨마다 구체적이면서 독립적인 테스트 목적을 설정해, 중복은 피하고, 적절하면서 포괄적인 테스팅이 가능하게 한다.

- 특정 테스트 레벨을 위한 테스트 분석과 설계를 소프트웨어 개발수명주기의 상응하는 각 개발단계에서 시작해 조기 테스팅 원칙을 준수할 수 있게 한다.

- 테스터가 이들 산출물의 문서 초안이 가용한 즉시 작업 산출물 리뷰에 참여하도록 해서 이 조기 테스팅과 결함 발견이 시프트 레프트 전략을 지원할 수 있도록 한다.

소프트웨어 개발 주도를 위한 테스팅

테스트 주도 개발, 인스 테스트 주도 개발, 행위 주도 개발은 서로 유사한 개발 접근법으로 개발 방향 결정을 위한 수단으로 테스트를 정의한다. 각 접근법은 코드 작성 전에 테스트를 정의하므로, 조기 테스팅 원리와 시프트 레프트 접근법을 따르게 한다.

반복적 개발 모델을 지원하며, 다음과 같은 특징을 가진다.

테스트 주도 개발(TDD)

- (광범위한 소프트웨어 설계 대신)테스트 케이스를 통해 코딩 주도

- 테스트를 먼저 작성하고 이를 충족하도록 코드를 작성한 다음, 테스트와 코드를 리팩토링

인수 테스트 주도 개발(ATDD)

- 시스템 설계 프로세스 중 인수 조건에서 테스트 도출

- 테스트는 해당 테스트를 만족해야 할 애플리케이션 영역을 개발하기 전에 작성

행위 주도 개발(BDD)

- 애플리케이션의 기대 동작을 이해관계자가 이해하기 쉽도록, 간단한 자연어로 작성해 테스트 케이스로 표현

일반적으로 Given/When/Then 형태를 사용

- 이후 테스트 케이스는 자동으로 실행 가능한 테스트로 변환

위의 모든 접근법에서 테스트는 향후 구현/리팩토링 시 코드 품질 보장을 위해 자동화 테스트로 유지할 수 있다.

데브옵스(DevOps)와 테스팅

데브옵스(DevOps) : 소프트웨어 개발(Development)와 IT 운영(Operations)의 합성어로, 개발팀과 운영팀 사이의 장벽을 허물고 하나의 팀처럼 협력하여 소프트웨어를 더 빠르고 안정적으로 배포하기 위한 문화이자 철학이다.

데브옵스 : 개발과 운영이 협력해 공통된 목표를 달성하기 위한 시너지 창출을 목표로 하는 조직 차원의 접근법이다.

데브옵스는 개발(테스팅 포함)과 운영이 가진 생각의 차이를 줄입과 동시에 각자 하는 일의 가치를 서로 동등하게 보도록 하는 조직 문화의 변화가 필요하다. 데브옵스는 팀의 자율성, 빠른 피드백, 통합된 도구 체인, 지속적 통합(CI)과 지속적 배포(CD)와 같은 기술 프랙티스를 장려한다. 팀은 데브옵스 배포 파이프라인(pipeline)을 통해 높은 품질의 코드를 더 빠르게 빌드, 테스트, 릴리즈 할 수 있다.

테스팅 관점에서 데브옵스의 이점은 다음과 같다.

- 코드 품질, 변경사항이 기존 코드에 악영향을 미치는지 여부에 대한 빠른 피드백을 제공한다.

- 지속적 통합은 개발자가 컴포넌트 테스트 및 정적 분석과 함께 높은 품질의 코드를 제출하도록 장려함으로써 시프트 레프트 테스팅 접근법을 장려한다

- 안정적인 테스트 환경 구축을 촉진하는 지속적 통합(CI)/지속적 배포(CD)와 같은 자동화 프로세스를 장려한다.

- 비기능 품질 특성(예 : 성능 효율성, 신뢰성)에 대한 가시성이 향상된다.

- 배포 파이프라인을 통한 자동화로 반복적인 수동 테스팅의 필요성을 줄여준다.

- 자동 리그레션 테스트의 규모와 범위가 늘어나 리그레션 발생 리스크가 최소화된다.

** 지속적 통합(CI) : 개발자가 작업한 코드를 자주, 자동으로 통합하고 테스트

** 지속적 배포(CD) : CI를 통해 성공적으로 통합된 코드를 사용자에게 전달하는 과정을 자동화 하는 단계

데브옵스의 리스크 및 어려움은 다음과 같다

- 데브옵스 배포 파이프라인을 정의하고 설정해야 한다.

- 지속적 통합/지속적 배포 도구를 도입하고 유지보수 해야 한다.

- 테스트 자동화를 위한 추가 자원이 필요하며, 그것을 설정 및 유지보수하기가 어려울 수 있다.

데브옵스는 높은 수준의 테스팅 자동화를 동반하지만, 수동 테스팅 또한 여전히 필요하다.

시프트 레프트 접근법(Shift Left)

조기 테스팅 원리는 테스트를 소프트웨어 개발수명주기 초기에 수행하도록 하는 접근법이기 때문에 *시프트레프트 라고 지칭하기도 한다.

시프트 레프트 : 기본적으로 테스트를 더 일찍 수행해야 한다는 것을 의미(ex : 코드가 구현되거나 컴포넌트의 통합을 기다리지 않고), 그렇다고 개발수명주기 후반의 테스트를 무시해도 된다는 의미는 아니다.

다음과 같은 테스팅에서 시프트 레프트를 달성하기 좋다.

- 테스터 관점에서 명세를 리뷰한다. 명세 리뷰 활동을 통해 모호성, 불완전성, 불일치 등 잠재적 결함을 발견하는 경우가 많다.

- 코드를 작성하기 전에 TC를 작성하고, 코드 구현 중 코드를 테스트 하네스에서 실행한다.

- 빠른 피드백을 제공하고, 코드 저장소에 소스 코드를 저장할 때 자동 컴포넌트 테스트를 함께 제출하도록 하는 CI/CD를 적용한다.

- 동적 테스팅 전 또는 자동화된 프로세스의 일부로 소스 코드의 정적 분석을 완료한다.

- 가능한 한 컴포넌트 테스트에서부터 비기능 테스팅을 수행한다. 비기능 테스트는 완성 시스템과 실제 환경을 대변하는 테스트 환경이 가용한 소프트웨어 개발수명주기 후반에 수행하는 경향이 있으므로 이는 일종의 시프트레프트가 된다.

시프트 레프트 접근법은 프로세스 초기에 훈련, 공수, 비용이 추가로 들지만, 프로세스 후반의 공수와 비용의 절감을 기대할 수 있다.

시프트 레프트 접근법을 위해서는 이해관계자들이 개념을 이해하고 받아들이는 것이 중요하다.

회고 및 프로세스 개선

회고 : 프로젝트나 반복 주기가 끝날 때, 릴리즈 마일스톤에서 또는 필요 시 진행할 수 있다. 회고의 시기와 구성은 사용중인 소프트웨어 개발수명주기 모델에 따라 달라진다. 이 회의에서 참가자는 다음에 대해 논의한다.

- 무엇이 성공적이었고, 유지해야 할 것은 무엇인가?

- 무엇이 부족했고, 개선할 수 있는 점은 무엇인가?

- 향후 개선 사항을 도입하고, 성공 요소를 유지하려면 어떻게 해야 하는가?

결과는 기록해야 하며, 테스트 완료 보고서에 포함하는 경우가 많다. 회고는 지속적인 개선을 성공적으로 구현하기 위해 반드시 필요하며, 권장된 모든 개선 사항에 대한 후속 조치가 이루어지는 것이 중요하다.

테스팅 관점에서 회고의 이점은 다음과 같다

- 테스트 효과성/효율성 향상(ex : 프로세스 개선 권고 사항 구현을 통해)

- 테스트웨어 품질 향상(ex : 테스트 프로세스를 함께 검토함으로써)

- 팀의 결속 및 학습 향상(ex : 문제를 제기하고, 개선점을 제안할 기회를 제공함으로써)

- 테스트 베이시스 품질 개선(ex : 요구사항의 범위나 품질에서 부족한 점을 발견하고 수정함으로써)

- 개발과 테스팅 간의 협업 개선(ex : 정기적으로 협업 과정을 검토하고 최적화함으로써)

테스트 레벨과 테스트 유형

테스트 레벨은 함께 구성하고 관리하는 테스트 활동 집합이다.

각 테스트 레벨은 특정 개발 단계의 소프트웨어와 관련해 수행하는 테스트 프로세스의 인스턴스이다.

단계에 따라 소프트웨어는 개별 컴포넌트부터 완성된 시스템에 이를 수 있으며, 경우에 따라서는 시스템의 시스템일수도 있다.

테스트 레벨 : 소프트웨어 개발수명주기 내의 다른 활동과 연관성을 가진다.

ex) 순차적 소프트웨어개발수명주기 모델 : 한 레벨의 완료 조건이 다음 레벨의 시작 조건에 포함되도록 테스트 레벨을 정의

ex) 반복적 모델 : 개발활동이 여러 테스트 레벨에 걸쳐 진행되고, 시간이 지나면서 테스트 레벨이 겹치기도 한다.

테스트 유형 : 특정 품질 특성 관련된 테스트 활동의 집합으로, 테스트 활동은 대부분 테스트 레벨에서 수행할 수 있다.

테스트 레벨

테스트 레벨은 총 다섯가지 레벨이 있다.

- 컴포넌트 테스팅(단위 테스팅) : 컴포넌트를 개별적으로 테스트, 테스트 하네스, 단위테스트 프레임워크 등을 사용, 개발자가 자신의 개발환경에서 수행

- 컴포넌트 통합 테스팅(단위 통합 테스팅) : 컴포넌트 간의 인터페이스와 상호 작용을 테스트하는데 중점을 둔다. 컴포넌트 통합 테스팅은 상향식, 하향식, 빅뱅 등 통합 전략에 따라 크게 달라진다.

- 시스템 테스팅 : 전체 시스템 또는 제품의 전반적인 동작과 기능에 중점을 둔다. 엔드투엔드 동작과 비기능 테스트가 많다. 서브-시스템에 대한 시뮬레이션을 사용하기도 한다.

시스템 테스팅은 독립된 테스트팀이 수행할 수 있고, 명세와 관련 있다.

- 시스템 통합 테스팅 : 다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트하는데 중점을 둔다.

가급적 운영 환경과 유사한 적절한 테스트 환경을 사용한다.

- 인수 테스팅 : 밸리데이션과 배포할 준비, 시스템이 사용자의 비즈니스에 필요한 사항을 충족하는지를 확인하는 데 중점을 둔다.

인수 테스팅은 실제 사용자가 수행하는 것이 이상적이다.

유형으로는 사용자 인수 테스트, 운영 인수 테스트, 계약 인수 테스팅과 규제 인수 테스팅, 알파, 베타 테스팅이 있다.

테스트 유형

테스트 유형에는 네가지 테스트 유형이 있다.

기능 테스팅 : 컴포넌트, 시스템이 수행해야 하는 기능을 평가한다. 테스트 대상이 '무엇을' 해야 하는지 의미한다.

기능 테스팅의 주요 목적은 기능 성숙도(완전성), 기능 정확성, 기능 타당성을 확인하는 것이다.

비기능 테스팅 : 컴포넌트 또는 시스템의 기능 특성 이외의 속성을 평가한다. 비기능 테스팅은 "시스템이 얼마나 잘 동작하는지"

를 테스트 한다. 비기능 품질 특성은 다음과 같다.

품질 특성 : 수행 효율성, 호환성, 유용성(상호작용 능력), 신뢰도, 보안, 유지가능성, 이동성(유연성), 안전성

블랙박스 테스팅 : 명세를 기반으로 하며, 테스트 대상의 내부 구조와 관련 없는 문서로부터 테스트를 도출한다.

블랙박스 테스팅의 주요 목적은 명세와 시스템의 동작을 확인하는 것이다.

화이트박스 테스팅 : 구조 기반이며, 시스템의 구현 또는 내부 구조에서 테스트를 도출한다.

테스트를 통해 내부 구조를 인수에 필요한 수준까지 충분히 커버하는 것이다.

네가지 테스팅 유형은 모든 테스트 레벨에서 사용할 수 있지만, 레벨마다 관심의 대상은 다를 수 있다.

언급한 테스트 유형 모두 테스트 컨디션과 테스트 케이스를 도출하기 위해 다양한 테스트 기법을 사용할 수 있다.

확인 테스팅 및 리그레션 테스팅

컴포넌트나 시스템을 변경하는 이유는 새로운 기능을 추가해 개선하거나 결함을 제거해 수정하기 위함이다. 이때는 테스팅에 확인 테스팅과 리그레션 테스팅을 추가할 필요가 있다.

확인 테스팅 : 원래 결함이 성공적으로 수정됐는지 확인한다.

리스크에 따라 다음과 같은 여러가지 방법으로 수정된 소프트웨어 버전을 테스트할 수 있다.

- 해당 결함으로 이전에 실패했던 모든 테스트 케이스를 실행

- 해당 결함을 수정하기 위해 변경한 사항을 확인하는 새로운 테스트를 추가

리그레션 테스팅 : 변경으로 인해 부정적인 영향이 없었는지 확인하는 것. 이미 테스팅이 끝난 수정 사항도 여기서 말하는 변경에 포함된다. 테스트 대상 자체에만 국한되지 않고, 환경과도 관련 있을 수 있다. 리그레션 테스팅의 범위를 파악하기 위해 영향도 분석을 수행하는 것이 좋음

리그레션 테스트 : 리그레션 테스트 스위트는 반복적으로 실행되며, 반복 주기 또는 릴리즈때마다 리그레션 테스트 케이스 수가

늘어나므로 리그레션 테스트는 자동화하기 매우 적합한 대상이 된다. 이런 테스트의 자동화는 프로젝트 초기에

시작해야 한다. 데브옵스와 같이 지속적 통합 사용 시 자동으로 포함하는 것이 좋은 프랙티스이다.

유지보수 테스팅

유지보수의 범주 : 문제 수정을 위한 유지보수, 환경 변화, 성능, 유지보수성 개선

유지보수는 계획된 릴리스/배포 또는 계획되지 않은 릴리스/배포 모두와 연관돼 있다. 변경 전에도 영향도 분석을 수행해 시스템의 다른 영역에 미칠 잠재적 영향을 변경사항 결정에 참고할 수 있다.

유지보수 테스팅의 범위

- 변경의 리스크 수준

- 기존 시스템의 크기

- 변경사항의 크기

유지보수와 유지보수 테스팅의 계기는 다음과 같이 분류할 수 있다.

- 계획된 개선사항(릴리즈 기반), 수정을 위한 변경, 핫픽스와 같은 수정사항 때문인 경우

- 운영 환경의 업그레이드나 마이그레이션으로 인한 경우

- 애플리케이션의 수명이 다하는 등의 단종으로 인한 경우

테스팅의 기초(Fundamentals of Testing)

Stair — Sat, 7 Feb 2026 10:44:16 +0900

테스팅이란?

소프트웨어 테스팅은 소프트웨어 품질을 평가하고, 소프트웨어 사용 시 나타날 수 있는 장애의 위험을 줄여줄 수 있다.

소프트웨어 테스팅이란?

결함을 식별하고 소프트웨어 산출물의 품질을 평가하는 일련의 활동

- 이러한 산출물을 테스트 대상(test object)라고 한다.

소프트웨어 테스팅은 테스트 실행에 국한되는 것이 아니라 다양한 활동을 포함하며, 소프트웨어 개발수명주기(SDLC)에 따라 달라진다.

테스팅은 베이리케이션(Verification) + 밸리데이션(Validation)을 포함한다.

시스템이 주어진 요구사항을 충족함과 동시에 운영 환경에서 사용자 또는 기타 이해 관계자가 필요한 바를 만족해야 한다.

테스팅은 정적, 동적으로 수행할 수 있다.

동적 테스트 : 소프트웨어를 실행하며 테스트 -- 테스트 케이스를 도출하기 위해 다양한 테스트 기법과 테스트 접근법을 사용한다.

정적 테스트 : 소프트웨어를 실행하지 않으며 테스트

테스팅은 적절한 계획/관리/추정/모니터링/제어가 필요하다.

테스팅은 테스터가 전문 지식을 갖추고 분석 기술을 사용해서 비판적 사고와 시스템적 사고를 적용하는 지적인 활동이다.

ISO/IEC/IEEE 29119-1 표준은 소프트웨어 테스팅의 개념을 설명하고 있다

테스트 목적

- 요구사항, 사용자 스토리, 설계ㅖ, 소스 코드 등 작업 산출물 평가

- 장애 유발 및 결함 식별

- 테스트 대상에 대해 요구된 커버리지 보장

- 소프트웨어 품질 부족으로 인한 리스크 수준의 완화

- 정의된 요구사항의 충족 여부를 확인하는 베리피케이션

- 테스트 대상의 계약, 법률, 규제 요구사항 준수 여부를 확인하는 베리피케이션

- 이해관계자가 정보에 입각한 결정을 내리는데 필요한 정보 제공

- 테스트 대상의 품질에 대한 자신감 획득

- 테스트 대상의 완성 여부와 이해관계자의 기대 충족 여부를 확인하는 밸리데이션

테스팅 목적은 정황에 따라 달라진다. 정황에는 테스트 대상 작업물 산출물, 테스트 레벨, 리스크, 사용하는 소프트웨어 개발수명주기, 기업 구조, 경쟁사 구도, 시장 출시 시기 등의 비즈니스 정황도 포함된다.

테스팅과 디버깅

테스팅과 디버깅은 별개의 활동이다.

테스팅 : 소프트웨어 결함으로 인한 장애를 유발하거나(동적 테스팅), 테스트 대상에 있는 결함을 직접 찾아낸다(정적테스팅)

디버깅 : 장애의 원인(결함)을 찾고, 원인을 분석하고 제거한다.

디버깅 프로세스

장애 재현 - 분석(결함 찾기) - 결함 수정

확인 테스팅 : 디버깅 한 이후 문제가 제대로 수정됐는지 확인한다. 처음 테스트를 수행한 사람이 다시 수행하는 것이 바람직함

리그레션 테스팅 : 수정 사항이 테스트 대상의 다른 부분에 장애를 일으키지 않았는지 확인하는 테스팅이다.

정적 테스팅으로 결함 식별 시 디버깅은 결함을 제거하는데 중점을 둔다.

장애를 유발하지 않고, 직접 결함을 식별하기 때문에 장애를 재현하고 분석할 필요는 없다.

테스팅이 왜 필요한가?

테스팅 : 품질 제어 활동의 일환으로 정해진 범위, 시간, 품질, 예산 내에서 합의된 테스트 목표를 달성하는데 도움을 준다.

테스팅은 테스트팀의 활동으로 국한되지 않는다. 모든 이해관계자들은 자신이 가진 테스트 기술을 활용해 성공에 기여할 수 있다.

컴포넌트, 시스템, 관련 산출물(문서)를 대상으로 한 테스팅은 소프트웨어 결함을 식별하는 데 도움이 된다.

테스팅이 성공에 기여하는 방법

테스팅 : 결함을 식별하는 비용 효율적인 방법이다. 식별한 결함은 디버깅을 통해 제거할 수 있기에 품질 향상에 간접적으로 기여하게 된다.

테스팅은 소프트웨어 개발수명주기의 여러 단계에서 테스트 대상의 품질을 직접 평가할 수 있는 방법을 제공한다.

평과 결과 -- 프로젝트 관리 활동에 사용 -- 소프트웨어 개발수명주기 다음 단계로 넘어가는 것을 판단하는 결정 등에 기여하게 된다.

테스팅은 개발 프로젝트에서 사용자를 간접적으로 대변한다. 테스터는 개발수명주기 전반에 걸쳐 그들이 이해하고 있는 사용자 요구사항이 반영되게 된다.

+ 계약 또는 법적 요구사항을 충족하거나, 규제 표준 준수를 위해 테스팅이 필요할 수도 있다.

테스팅과 품질 보증(QA)

품질 보증(QA, Quality Assurance)과 테스팅이라는 용어를 혼용해서 사용하는 경우가 많지만, 품질 보증과 테스팅은 같지 않다.

테스팅 : 제품 지향적, 품질 달성을 지원하는 활동에 초점을 맞춘 교정 접근법이다. 품질 제어의 주요 활동이다

ex) 정형 기법(모델 확인 및 정확성의 증명), 시뮬레이션, 프로토타이핑

품질 보증 : 프로세스의 구현과 개선에 초점을 맞춘 프로세스 중심의 예방 접근법이다. 좋은 프로세스를 올바르게 준수하면 좋은 제 품이 만들어진다는 가정을 기반으로 한다. 개발 및 테스팅 프로세스에 모두 적용. 프로젝트에 참여하는 모두의 책임

테스트 결과 : 품질 보증과 테스팅에 모두 사용.

- 테스팅 측면 : 결함을 수정하는데 사용

- 품질 보증 측면 : 개발 및 테스트 프로세스가 잘 동작하고 있는지 확인하기 위한 피드백으로 사용

오류, 결함, 장애, 근본 원인

사람은 오류(실수)를 저지르며 이에 따라 결함(결점, 버그)이 발생하고, 이는 결국 장애로 이어질 수 있다.

사람은 시간적인 압박, 작업 산출물의 복잡성, 프로세스, 인프라, 상호작용 등의 다양한 이유로 or 단순히 피로하거나 훈련이 부족하여 오류를 범할 수 있다.

결함 : 요구사항 명세서나 테스트 스크립트와 같은 문서, 소스 코드, 필드 파일 등의 지원 산출물에서도 나올 수 있다.

SDLC 초기에 만든 산출물의 결함을 발견하지 못할 경우 종종 수명주기 후반 산출물의 결함을 이어지는 경우가 많다.

소스코드에 있는 결함이 수행되면 수행해야 할 작업을 수행하지 못하거나, 수행하지 않아야 할 작업을 수행해 장애를 일으킬 수 있다. 특정 상황에서만 장애를 일으키거나 장애로 이어지지 않는 결함도 있다.

환경 조건(방사선, 전자기장)등이 펌웨어에 문제가 생기게 하는 경우처럼 환경 조건으로 발생하는 장애도 있다.

테스팅의 원리

테스팅에 적용할 수 있는 포괄적 지침 테스팅 원리 7가지는 다음과 같다.

1. 테스팅은 결함의 존재를 밝히는 활동이지, 결함이 없음을 증명하지는 않는다.

2. 완벽한 테스팅은 불가능하다.

3. 조기 테스팅으로 시간과 비용을 절약할 수 있다.

4. 결함은 집중된다.

5. 같은 테스트를 반복하면 신규 결함 식별 효과는 줄어들게 된다. but 자동리그레션 테스팅처럼 반복하는 것이 유익한 경우도 있다.

6. 테스팅은 정황에 의존적이다. 모든 상황에 적용할 수 있는 하나의 접근법은 없다.

7. 결함-부재는 궤변이다. 요구사항을 철저히 테스트하고 결함을 수정했더라도 사용자의 요구나 기대에 못미치면 안된다. 밸리데이션도 수행되어야 한다.

테스트 활동, 테스트웨어, 테스트 역할

테스팅은 정황에 의존적이다.

but 그에 관계 없이 목적을 달성하기 위해 필요한 보편적인 테스트 활동들이 있다. 이런 활동이 테스트 프로세스(Test process)를 구성하게 된다.

테스트 프로세스는 여러 요인을 기반으로 주어진 상황에 맞게 조정될 수 있다. 테스트 프로세스에 포함될 테스트 활동과 그러한 활동의 구체적인 수행 방법과 시기는 해당 상황에 필요한 테스트 계획을 짤 떄 결정한다.

ISO/IEC/IEEE 29119-2 표준은 테스트 프로세스에 대한 상세 정보를 제공한다.

테스트 활동과 업무

테스트 프로세스를 구성하는 주요 활동은 다음과 같다.

- 테스트 계획(Test planning) : 테스트 목적을 정의한 다음 전반적인 상황에 따른 제약 조건 내에 목적을 가장 잘 달성할 수 있는 접근법을 선택하는 과정

- 테스트 모니터링(Test monitoring) : 지속적으로 모든 테스트 활동을 점검하고, 실제 상황을 계획과 비교하는 활동

- 테스트 제어(Test control) : 테스트 목적을 달성하는데 필요한 조치를 하는 활동

- 테스트 분석(Test analysis) : 테스트 베이시스를 분석해 테스트 가능한 기능을 식별, 리스크 수준을 고려해 정의 및 우선순위를 매김, 테스트 분석을 지원하기 위해 테스트 기법을 사용하는 경우가 많음, "무엇을 테스트 할 것인가?"라는 질문에 측정 가능한 커버리지 조건으로 답을 제공, 테스트 베이시스와 테스트 대상 또한 그 안에 있을 수 있는 결함을 식별하고 평가하기 위해 함께 분석 됨

- 테스트 설계(Test design) : 테스트 컨디션을 테스트 케이스와 기타 테스트웨어(ex : 테스트 차터)로 구체화 하는 작업을 포함, 이 활동을 위해 테스트 기법 사용 가능, "어떻게 테스트할 것인가?"라는 질문에 답을 제공

- 테스트 구현(Test implementation) : 테스트 실행에 필요한 테스트웨어를 만들거나 획득하는 작업을 포함. 테스트 케이스는 테스트 절차(test procedure)로 묶을 수 있으며, 테스트 스위트(test suite)로 조합하는 경우도 많다. 수동 및 자동 테스트 스크립트도 만들게 된다.

- 테스트 실행(Test execution) : 테스트 실행 일정에 따라 테스트를 수행하는 것을 포함, 수동 및 자동으로 실행 가능, 지속적 테스팅(continuous testing), 페어 테스팅 세션(pair testing sessions)등 다양한 형태로 이루어질 수 있다.

- 테스트 완료(Test completion) : 프로젝트 마일스톤에서 수행됨, 해결되지 않은 결함에 대해서는 변경서 및 백로그 항목을 만듦, 향후 유용할 수 있는 테스트웨어를 식별해서 보관하거나 적절한 팀에 인계, 테스트 환경은 합의된 상태로 종료하게 됨, 테스트 활동을 분석해 향후 프로젝트를 위한 교훈과 개선 사항을 파악

정황에 따른 테스트 프로세스

테스팅은 단독으로 수행되지 않는다.

테스트 활동은 조직에서 수행하는 개발 프로세스의 필수적인 부분이다.

테스팅 비용은 이해관계자가 부담하게 되며, 이해관계자의 비즈니스 목표 달성을 지원하기 위해 테스팅을 진행한다.

테스팅 수행 방식은 다음과 같은 요소에 따라 달라진다

- 이해관계자(필요, 기대, 요구사항, 협력 의지)

- 팀원(기술, 지식, 경험 수준, 가용성, 훈련 필요성)

- 비즈니스 도메인(테스트 대상의 중요도, 식별된 리스크, 시장 요구사항, 구체적인 법적 규제)

- 기술적 요인(소프트웨어 유형, 제품 아키텍쳐, 사용된 기술)

- 프로젝트 제약 조건(범위, 시간, 예산, 자원 등)

- 조직적 요인(조직 구조, 기존 정책, 적용한 프랙티스)

- 소프트웨어 개발수명주기(SDLC)(공학적 프랙티스, 개발 방법론)

- 도구(가용성, 사용성, 규정 준수)

위와 같은 요소들은 테스트 전략, 적용된 테스트 기법, 테스트 자동화 수준, 필요 커버리지 수준, 테스트웨어의 상세화 수준, 테스트 보고 등 많은 테스트 관련 문제에 영향을 미친다.

테스트웨어

테스트웨어 : 소프트웨어 테스트 과정을 수행하기 위해 필요한 모든 산출물을 통칭한다.

테스트웨어는 테스트 활동의 결과물로 만들어진다. 조직마다 테스트웨어를 생성, 구체화, 명명, 관리하는 방식에는 상당한 차이가 있다.

적절한 형상관리는 작업 산출물의 일관성과 무결성을 보장한다.

- 테스트 계획 작업 산출물 : 테스트 계획, 테스트 일정, 리스크 관리 대장, 시작 및 완료 조건

- 테스트 모니터링과 테스트 제어 작업 산출물 : 테스트 진행 상황 보고서, 제어 지침 문서, 리스크 정보

- 테스트 분석 작업 산출물 : 테스트 컨디션(우선 순위가 지정된), 테스트 베이시스의 결함에 관한 결함 보고서

- 테스트 설계 작업 산출물 : 테스트 케이스, 테스트 차터, 커버리지 항목, 테스트 데이터 요구사항, 테스트 환경 요구사항

- 테스트 구현 작업 산출물 : 테스트 절차, 수동 및 자동 테스트 스크립트, 테스트 스위트, 테스트 데이터, 테스트 실행 일정,테스트 환경 요소(스텁, 드라이버, 시뮬레이터, 서비스 가상화)

- 테스트 실행 작업 산출물 : 테스트 로그, 결함 보고서

- 테스트 완료 작업 산출물 : 테스트 완료 보고서, 향후 프로젝트에서 개선할 실천 항목, 문서로 기록한 교훈, 변경 요청서

테스트 베이시스와 테스트웨어 간의 추적성

테스트 베이시스 : 테스트의 근거가 되는 모든 문서나 정보

효과적인 테스트 모니터링과 제어를 구현하려면 테스트 베이시스의 개별 요소, 개별요소와 관련된 테스트웨어, 테스트 결과, 결함 간의 추적성을 구축하고 유지하는 것이 중요하다.

정확한 추적성은 커버리지 평가를 지원하며, 측정 가능한 커버리지 조건이 테스트 베이시스에 정의되어 있다면 매우 유용할 수 있다. 커버리지 조건은 테스트 목적을 어느정도 달성했는지 나타내는 활동들을 촉진하는 핵심 성과 지표로 사용될 수 있다.

- 테스트 케이스에서 요구사항으로의 추적성을 통해 테스트 케이스가 요구사항을 커버하고 있는지 확인할 수 있다.

- 테스트 결과에서 리스크로의 추적성을 통해 테스트 대상의 잔존 리스크 수순을 평가할 수 있다.

좋은 추적성 : 커버리지 평가 외에 변경 사항의 영향을 파악할 수 있게 한다. 테스트 감사를 용이하게 한다. 운영 및 관리 기준을 충족하는데 도움이 된다. 좋은 추적성은 테스트 베이시스 요소들의 상태를 명시함으로써, 테스트 진행 상황 및 테스트 완료 보고서를 더 쉽게 이해할 수 있도록 해준다.

테스팅에서의 역할

테스팅에서는 두가지 주요 역할이 있다(테스팅 역할, 테스트 관리 역할)

이 두 역할에 할당되는 활동과 업무는 프로젝트 및 제품의 정황, 역할 담당자의 기술 수준, 조직 상황 등 요소에 따라 달라진다.

- 테스트 관리 역할 : 테스트 프로세스, 테스트 팀, 테스트 활동 리더십에 대한 전반적인 책임을 진다. 주요 관심 영역은 테스트 계획, 테스트 모니터링, 테스트 제어, 테스트 완료 활동이다. 테스트 관리 역할의 수행 방식은 정황에 따라 달라진다.

- 테스팅 역할 : 테스팅의 공학(기술)적인 측면에 대한 전반적인 책임을 진다. 테스팅 역할은 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행 활동에 초점을 준다.

상황에 따라 역할을 수행하는 사람이 달라진 수 있다. 또한 한 사람이 테스팅과 테스트 관리 역할을 동시에 수행하는 경우도 있다.

테스팅의 필수 기술 및 모범 사례

기술 : 어떤 일을 잘 해내는 능력으로 그 사람이 가진 지식, 경험, 적성에서 비롯된다.

우수한 테스터는 업무를 잘 수행하기 위한 몇가지 필수적인 기술을 갖추어야 한다. 우수한 테스터는 팀플레이, 협업에 능한 사람이어야 하며, 다양한 수준의 독립성에서 테스팅을 수행할 수 있어야 한다.

테스팅에 보편적으로 필요한 기술

- 테스팅 지식

- 철저함, 신중함, 호기심, 세부사항에 대한 주의력, 체계적인 접근

- 우수한 의사소통 기술, 경청하는 자세, 팀플레이

- 분석적 사고, 비판적 사고, 창의성

- 기술 지식

- 도메인 지식

테스터는 좋지 않은 소식을 전해야 하는 경우가 많다. 나쁜 소식일 경우 그것을 전하는 사람을 탓하는 것은 인간이 가지고 있는 기본 성향 중 하나이다. 따라서 테스터에게 의사소통 기술은 매우 중요하다.

테스트 결과의 전달을 제품이나 작성자에 대한 비판으로 오해할 소지가 있다.

확증 편향은 현재 가지고 있는 믿음과 맞지 않는 정보를 받아들이기 어렵게 만든다. 따라서 테스팅이 프로젝트 성공과 제품 품질에 상당한 기여를 함에도 불구하고, 테스팅을 파괴적인 활동으로 간주하는 사람이 있다. 이런 인식을 개선하려면 결함과 장애 정보를 건설적인 방법으로 전달해야 한다.

전체 팀 접근법

테스터에게 중요한 기술 : 팀 환경에서 효과적으로 일하고, 팀 목표에 긍정적으로 기여하는 능력

전체 팀 접근법 : 익스트림 프로그래밍에서 시작, 필요 지식과 기술을 갖춘 팀원이라면 누구나 어떤 작업이던 수행 가능, 모든 팀원이 품질에 대한 책임을 진다. 의사소통과 상호작용을 용이하게 하기 위해 (물리적 또는 가상의)작업 공간을 공유한다.

테스터는 필요한 수준의 품질 달성을 위해 팀원과 긴밀히 협력하게 된다.

비즈니스 담당자와 협력해 적절한 인수 테스트를 작성하고, 개발자와 협력해 테스트 전략을 협의하고, 테스트 자동화 접근법을 결정하는 것도 포함된다. 테스터는 테스팅 지식을 다른 팀원과 공유하며 개발에 영향을 준다.

**정황에 따라 전체 팀 접근법이 적절하지 않을 수 있다. 안전이 치명적인 경우에는 높은 수준의 테스트 독립성이 필요할수 있다.

테스팅의 독립성

일정 수준의 독립성은 저자와 테스터의 인지 편향 차이로 테스터가 결함을 더 효과적으로 식별할 수 있도록 한다.

그러나 독립성이 친숙함을 대체하는 것은 아니다. 예를 들어, 개발자는 자신이 작성한 코드에서 많은 결함을 효율적으로 찾아낼 수 있다.

- 저자가 직접 테스트(독립성 없음)

- 같은 팀 동료가 테스트(일정 수준의 독립성)

- 팀 외부에 있지만 같은 조직 내에 있는 테스터가 테스트(높은 독립성)
- 조직 외부의 테스터가 테스트(매우 높은 독립성)

대부분의 프로젝트는 여러 수준으로 독립성으로 테스팅을 수행하는 것이 가장 좋다.

독립적인 테스팅의 이점 : 독립적인 테스터는 배경, 기술적 관점, 편향이 다르기 때문에 개발자와 다른 유형의 장애와 결함을 식별할 가능성이 높다. 독립적인 테스터는 시스템 명세를 작성하고 구현하는 과정에서 이해관계자가 한 가정을 검증하고 그것에 대한 이의를 제기하거나 반증할 수 있다.

독립적인 테스팅의 단점 : 독립적인 테스터는 개발팀과 차단되어 협업과 의사소통이 어려울 수 있다. 개발팀과 적대적인 관계로 이어질 수 있다. 개발자가 품질에 대한 책임감을 잃울 수도 있다. 독립적인 테스터가 병목으로 인식되거나, 출시 지연의 원인으로 비판받을수도 있다.

컨테이너 조회, 중지, 삭제

Stair — Wed, 4 Feb 2026 09:03:38 +0900

docker에서 컨테이너를 조회하려면 docker ps 명령어를 통해 조회할 수 있다.

docker ps : 현재 실행중인 컨테이너가 확인 된다.

동작을 중지한 컨테이너까지 포함하여 조회하려면 ps -a를 통해 조회하면 된다.

docker ps -a : [작동 중인 컨테이너 + 작동을 멈춘 컨테이너] 모두 조회

컨테이너를 멈추는 방법은 두가지가 있다.

docker stop과 docker kill

** kill은 무식하게 강제 종료하는 방법이고, stop은 프로세스를 정상적으로 종료하는 방법이다.

docker rm으로 중지되어 있는 특정 컨테이너를 삭제할 수 있다.

docker rm [컨테이너명 or 컨테이너ID]

실행되고 있는 컨테이너 또한 삭제 할 수 있는데 -f 를 붙혀야 한다.

docker rm - f [컨테이너명 or 컨테이너ID]

중지되어 있는 모든 컨테이너를 삭제하는 명령어는 다음과 같다.

docker rm $(docker ps -qa)

마찬가지로 실행되고 있는 모든 컨테이너를 삭제하려면 -f를 붙혀주면 된다.

Docker 컨테이너 생성, 실행

Stair — Tue, 3 Feb 2026 12:21:31 +0900

컨테이너 생성

이미지를 바탕으로 컨테이너를 생성한다. 이 때는 컨테이너를 실행시키지는 않는다.

(컨테이너를 실행하지 않고 생성만 하는 경우는 별로 없기 때문에 이 명령어는 잘 사용되지 않는다.)

docker ps -a : 모든 컨테이너 조회

docker start로 정지되어 있는 컨테이너를 실행시킨다.

docker ps로 실행중인 컨테이너를 조회한다.

현업에서는 컨테이너를 생성하고, 실행하는 동작을 분리해서 하진 않고, 보통 run이라는 명령어로 한번에 퉁쳐서 생성하고 실행하게 된다.(run : 컨테이너 생성 + 실행)

그냥 run을 하게 되면 문제가 하나 있다. 실행한 작업이 포그라운드에서 동작하는 문제이다.

- foreground : 내가 실행시킨 프로그램의 내용이 화면에서 실행되고 출력되는 상태

- background : 내가 실행시킨 프로그램이 컴퓨터 내부적으로 실행되는 상태

포그라운드에서 동작하기 때문에 파워쉘 창에서 다른 명령어를 입력할 수 없게 된다.

백그라운드에서 작업을 실행시키려면 -d를 붙혀주면 된다.

이 특성을 이용하여 다른 명령어를 추가로 입력할 수 있고, 새로운 프로그램을 조작할 수도 있다.

컨테이너에 이름을 붙혀서 생성 및 실행도 가능하다.

#docker run -d --name [컨테이너 이름] 이미지명[:태그명]을 사용하여 컨테이너이 이름 붙히기가 가능하다.

docker에서 컨테이너를 생성하여 nginx를 80번 포트로 실행하면, 크롬 웹브라우저에서 localhost:80을 입력하여 연결을 할 수 있을 것 같지만 실상은 그렇지 않다.

docker에 올라간 컨테이너는 "독립된 개별 컴퓨터"라고 생각하면 된다. 따라서 호스트 컴퓨터에서 한번 더 연결을 해주어야 한다.(포트 포워딩)

-d (Detached): 컨테이너를 백그라운드에서 실행한다.
-p 4000:80 (Publish): 이 부분이 핵심인 포트 포워딩 설정.
- 4000 (Host Port): 여러분의 실제 컴퓨터(호스트)에서 사용할 문 번호
- 80 (Container Port): Nginx 컨테이너 내부에서 웹 서버가 기본적으로 기다리고 있는 문 번호
nginx: 사용할 이미지 이름입니다.

localhost:4000 으로 접근 -> docker 엔진이 호스트의 4000번으로 들어온 신호를 낚아 챔 ->

이 신호를 컨테이너 내부의 80번 포트로 넘김 -> 컨테이너 안에 nginx가 신호를 받아 페이지를 출력

Docker Image 관련 CLI

Stair — Fri, 23 Jan 2026 09:00:10 +0900

Docker를 조작하려면 터미널에서 명령어(CLI)를 통해 Docker를 조작한다.

docker image ls를 통해 조회하면 다음과 같은 결과가 나타난다.(ls : list의 약자)

nginx에 대한 보다 자세한 내용이 나오게 된다.

docker GUI 화면에서 nginx 상태도 확인 가능하다.

name : 이미지 이름

Tag : 이미지 태그명

Image ID : 이미지 ID

CREATED : 이미지가 생성된 날짜 (다운받은 날짜 X)

SIZE : 이미지 크기

이제 docker에서 이미지를 삭제해 보자.

이미지를 삭제하는 명령어는 다음과 같다

docker image rm (이미지 ID or 이미지명)

- rm : remove의 약자

- 이미지ID륻 입력할 때 전체를 다 입력하지 않고, ID의 일부만 입력해도 괜찮다.

현재 상태에서 nginx를 지워보도록 하자.

지우려고 하니 Error가 발생했다.

단순한 rm으로는 컨테이너에서 사용되지 않는 image만 지울 수 있다.

우린 예전에 nginx로 컨테이너를 만들어 웹 서버를 띄웠던 적이 있기 때문에 컨테이너에 nginx가 꽂혀있는 상황이다.

그래서 단순 rm으로는 nginx를 삭제할 수 없다.

[중지된 컨테이너에서 사용하고 있는 이미지 강제 삭제하기]

- rm -f를 사용하여 중지된 컨테이너에서 사용하고 있는 이미지를 강제로 삭제한다.

[전체 이미지 삭제]

- docker images -q : 시스템에 있는 모든 이미지의 ID를 반환한다. 여기서 -q 옵션은 quite를 의미하며, 상세 정보 대신 각 이미지의 고유한 ID만 표시하도록 지시한다.

도커 흐름 파악하기

Stair — Thu, 22 Jan 2026 15:31:35 +0900

docker를 조작하려면 터미널 명령어를 통해 docker를 조작한다.

** nginx : 여러 기능을 가진 서버

- 웹서버 기능

- 로드 밸런싱

- 리버스 프록시

nginx를 다운받고 사용해보자

docker pull nginx를 하여 nginx를 설치한다.

nginx는 이미지이다(닌텐도 칩셋 같은 개념)

docker에 nginx 이미지가 제대로 다운받아졌는지 리스트를 확인해보자.

docker image ls 명령어를 통해 다운받은 image 파일 리스트를 확인한다.

현재는 nginx만 설치하여 nginx만 보이고 있다.

그럼 nginx를 실행시켜보자.

nginx 기능 중 웹 서버 기능을 사용해보자.

docker run --name webserver -d -p 80:80 nginx 를 통해 실행시킨다.

이름은 webserver이고 80번 포트를 사용한다는 내용의 명령어이다.

웹을 통해 localhost:80을 접속해보면 nginx가 정상적으로 동작하는 걸 알 수 있다.

우리가 실행한 컨테이너를 정지하려면 다음과 같은 명령어를 통해 정지할 수 있다.

docker stop (이름)

정상 정지를 확인할 수 있다.