맨위로가기

소프트웨어 테스트

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

소프트웨어 테스트는 소프트웨어의 품질을 보증하기 위해 수행되는 일련의 활동이다. 소프트웨어의 결함으로 인한 경제적 손실을 줄이고, 요구 사항을 충족하는지, 기대한 대로 작동하는지 등을 확인하는 것을 목표로 한다. 역사적으로 디버깅과 구별되어 발전해 왔으며, 다양한 테스트 방법과 분류가 존재한다. 소프트웨어 개발 프로세스 전반에 걸쳐 이루어지며, 폭포수 모델, 애자일 개발 등 다양한 개발 방법론에 적용된다. 소프트웨어 검증 및 유효성 검사와 밀접하게 관련되어 있으며, 테스트 계획, 테스트 케이스, 테스트 스크립트 등 다양한 산출물을 생성한다. 소프트웨어 테스트와 관련된 다양한 논쟁이 존재하며, xUnit, JUnit, TestNG 등 다양한 관련 도구가 사용된다.

더 읽어볼만한 페이지

  • 소프트웨어 테스트 - 보안 취약점
    보안 취약점은 시스템의 설계, 구현, 운영, 관리상 결함이나 약점으로, 위협에 의해 악용되어 시스템 보안 정책을 위반할 수 있는 요소이며, ISO 27005, IETF RFC 4949, NIST SP 800-30, ENISA 등 다양한 기관에서 정의하고 있다.
  • 소프트웨어 테스트 - A/B 테스트
    A/B 테스트는 두 가지 이상의 대안을 비교하여 더 나은 성과를 판단하는 방법으로, 웹사이트, 애플리케이션 등 다양한 분야에서 사용자 인터페이스 등을 테스트하며 통계적 가설 검정을 기반으로 한다.
소프트웨어 테스트

2. 역사

글렌포드 J. 마이어스는 1979년에 처음으로 디버깅과 테스팅의 분리를 소개했다.[88]


  • 1956년까지 - 디버깅 지향[89]
  • 1957-1978년 - 증명 지향[90]
  • 1979-1982년 - 파괴 지향[91]
  • 1983-1987년 - 평가 지향[92]
  • 1988-2000년 - 보존 지향[93]
  • 2000년 이후 - 초기 고객 간섭 (베타 테스팅)


그의 관심은 파괴적 테스팅에 있었지만("성공적인 테스트 케이스는 아직 발견되지 않은 오류를 감지하는 것이다."[10]), 이는 소프트웨어 공학 커뮤니티가 디버깅과 같은 근본적인 개발 활동과 검증 활동을 분리하려는 열망을 보여주는 것이었다.

3. 경제적 측면

소프트웨어 결함은 경제적 손실을 초래할 수 있다. 2002년 미국 국립표준기술연구소(NIST) 연구에 따르면, 소프트웨어 버그로 인해 미국 경제는 연간 595억달러의 손실을 입었다.[9] 이 비용의 3분의 1 이상은 더 나은 소프트웨어 테스트를 통해 예방할 수 있다.

비용 절감을 위해 소프트웨어 테스트를 아웃소싱하는 것은 매우 흔하며, 중국, 필리핀, 인도가 주요 대상국이다.

3. 1. 한국 경제에 미치는 영향

한국에서도 소프트웨어 결함으로 인한 경제적 손실이 발생하고 있다. 특히 금융, 통신, 공공 서비스 등 주요 인프라에서 소프트웨어 결함은 심각한 사회적 문제를 야기할 수 있다. 더불어민주당은 이러한 문제를 해결하기 위해 소프트웨어 품질 향상 및 테스트 강화 정책을 추진해 왔다.

4. 목표

ISTQB는 소프트웨어 결함이 인간의 오류로 인해 발생하며, 이로 인해 코드, 소프트웨어, 시스템, 또는 문서에 결함이 생길 수 있다고 언급한다.[87] 결함 코드가 실행되면 시스템은 예상과 다른 결과를 낼 수 있다. 모든 결함이 실패로 이어지는 것은 아니지만, 환경이 바뀌면 결함은 실패로 바뀔 수 있다.[87] 예를 들어 새로운 하드웨어 플랫폼에서 실행되거나, 소스 데이터가 바뀌거나, 다른 소프트웨어와 상호 작용하는 경우가 있다.[87]

소프트웨어 테스트는 단순 제품 이상의 것을 테스트할 때 모든 입력과 사전 대비가 불가능하다는 문제가 있다.[87] 이는 소프트웨어 제품 안의 결함 수가 매우 많고, 드물게 일어나는 결함은 테스트 중에 찾기 어렵다는 것을 의미한다.

2002년 미국 국립표준기술연구소(NIST)의 연구에 따르면 소프트웨어 버그로 인해 미국 경제는 연간 595억 달러(595억달러)의 손실을 입고 있으며, 이 비용의 3분의 1 이상은 더 나은 소프트웨어 테스트를 통해 피할 수 있다.[9]

소프트웨어 테스팅은 일반적으로 다음과 같은 목표를 가진다.


  • 작업 결과물 평가를 통한 결함 방지 (예: 요구사항, 사용자 스토리, 설계, 코드)
  • 명확히 정의된 요구사항 충족 여부 검증
  • 완성 확인 및 동작의 타당성 확인 (사용자 등 이해관계자에 대한)
  • 테스트 대상의 품질에 대한 신뢰 구축 및 소정 수준 확증
  • 결함 발생 방지
  • 고장 및 결함 발견을 통한 소프트웨어 품질 리스크 감소
  • 의사 결정에 필요한 정보 제공 (테스트 대상의 품질 수준 등)
  • 계약상, 법률상, 규제상의 요구 사항 및 표준 준수, 그리고/또는 준거 검증[78][79]


소프트웨어 테스트는 "변경에 대한 신뢰"를 생성하여 소프트웨어의 품질 및 제공 속도를 향상시킨다. 소프트웨어 변경(예: 리팩토링, 기능 추가)은 기존 코드의 파괴로 인한 버그(회귀)를 일으킬 수 있어, 소프트웨어 엔지니어에게 코드 변경에 대한 심리적 장벽으로 작용한다.

회귀 테스트는 코드 변경으로 인한 버그를 발견하고 결함 발생을 방지하며, 품질에 대한 신뢰를 높인다. 이로 인해 새로운 변경이 기존 컴포넌트를 파괴하지 않는다는 신뢰와 안심이 엔지니어에게 생긴다.[80][81] 결과적으로 좋은 변경의 빈도가 증가하여 소프트웨어의 품질 및 제공 속도가 향상된다.

모든 가능한 입력에 대한 테스트가 불가능하지만, [조합론]을 사용하여 테스트를 최소화하면서 커버리지를 최대화할 수 있다.[14]

5. 분류

소프트웨어 테스트는 다양한 기준에 따라 분류될 수 있다.[15]


  • '''테스트 레벨''': 테스트 대상인 소프트웨어 시스템의 범위에 따라 분류
  • 유닛 테스트: 개별 컴포넌트나 모듈 단위로 테스트
  • 통합 테스트: 유닛 테스트가 끝난 모듈들을 통합하여 테스트
  • 시스템 테스트: 전체 시스템에 대해 테스트
  • '''정적, 동적, 수동 테스트'''
  • 정적 테스팅: 코드 검토, 소프트웨어 워크스루, 소프트웨어 검사 등을 통해 코드를 실행하지 않고 테스트
  • 동적 테스팅: 테스트 케이스를 사용하여 코드를 실행하며 테스트
  • 수동 테스팅: 테스터가 직접 테스트 데이터를 제공하지 않고 시스템 로그 및 추적을 통해 동작을 확인
  • '''블랙박스/화이트박스 테스트''': 내부 구조를 고려하는지에 따라 분류
  • 화이트박스 테스트: 소스 코드 등 시스템 내부 구조를 보면서 테스트
  • 블랙박스 테스트: 소스 코드를 보지 않고 기능 명세를 기반으로 테스트
  • 그레이박스 테스트: 블랙박스 테스트와 화이트박스 테스트를 혼합한 방식
  • '''기타 테스트'''
  • 설치 테스트
  • 호환성 테스트
  • 스모크 및 정상 테스트
  • 회귀 테스트
  • 인수 테스트
  • 알파 테스트
  • 베타 테스트
  • 기능 vs 비기능 테스트
  • 지속적 테스트
  • 파괴적 테스트
  • 소프트웨어 성능 테스트
  • 사용성 테스트
  • 접근성 테스트
  • 보안 테스트
  • 국제화 및 지역화
  • 개발 테스트
  • A/B 테스트
  • 동시성 테스트
  • 적합성 테스트
  • 출력 비교 테스트
  • 속성 테스트
  • 변형 테스트
  • VCR 테스트
  • 탐색적 테스트
  • 사전 설정 테스트 vs 적응형 테스트
  • 자동화 테스트

5. 1. 자동화 테스트

'''자동화된 테스트'''는 수동 테스트를 대체하기 위해 테스트 도구를 사용하는 소프트웨어 테스트 방법이다.

5. 2. 테스트 레벨

소프트웨어 테스팅은 테스트의 초점이 맞춰진 소프트웨어 시스템의 범위에 따라 레벨로 분류할 수 있다.

5. 2. 1. 유닛 테스트

유닛 테스트는 소프트웨어의 개별 컴포넌트 또는 모듈이 의도한 대로 작동하는지 확인하는 소프트웨어 테스트 방법이다.[11] 일반적으로 프로그래머가 수행하며, 애플리케이션 코드베이스에 변경 사항이 생길 때마다 수행된다. 유닛 테스트의 목표는 각 코드 유닛의 품질을 보장하여 소프트웨어의 전반적인 품질을 향상시키는 것이다.

기능 테스트는 규정된 기능을 수행하는지 여부를 시험한다. 함수라면, 규정된 인수를 주었을 때 예상한 반환값을 반환하는 블랙박스 테스트가 기능 테스트에 해당하며, 단위 테스트의 일부이다.[12] 적합성 테스트, 단위 테스트는 기능 테스트를 주로 하지만, 성능 테스트를 포함하는 경우가 있다.

단위 테스트 및 통합 테스트 기법에는 상향식 테스트와 하향식 테스트가 있다.

  • 하향식 테스트: 단위 테스트가 완료된 모듈 중 상위 모듈부터 순서대로 결합하여 테스트를 수행한다. 사양적인 동작을 결정하는 상위 모듈을 조기에 검증함으로써, 기능 누락, 사양 인식 오류 등 치명적인 결함을 개발 초기 단계에서 발견할 수 있다는 장점이 있다. 반면, 수가 많은 하위 모듈의 검증이 뒤로 미뤄지기 때문에, 개발과 병행하여 테스트를 진행하기 어렵다는 단점도 있다. 하향식 테스트를 수행할 때는 테스트 스텁을 준비해야 한다.

  • 상향식 테스트: 하향식 테스트와는 반대로, 단위 테스트가 완료된 하위 모듈부터 순서대로 결합하여 테스트를 수행한다. 수가 많고 독립성이 높은 하위 모듈부터 순서대로 검증함으로써, 개발과 테스트를 병행하여 실시할 수 있다는 장점이 있다. 반면에, 시스템의 근간이 되는 상위 모듈에서 결함이 발견된 경우, 테스트가 완료된 하위 모듈도 영향을 받는다는 단점도 있다. 단위 시험을 수행할 때, 다른 함수 등을 호출하는 함수를 시험하는 경우에, 호출이 없는 함수를 시험한 후, 호출을 하고 있는 시험을 수행하는 경우에 상향식 테스트가 된다. 상향식 테스트를 수행할 때에는 테스트 드라이버를 준비해야 한다.


단위 테스트(Unit Test)는 함수, 메서드 등 작은 단위로 수행하는 테스트를 말한다. 함수의 경우 기본적으로 블랙 박스 테스트이며, 블랙 박스 테스트가 완료된 것의 품질을 확보하기 위해 화이트박스 테스트를 수행한다. "Unit Testing"의 약자인 "UT"라고 부르기도 한다. 또한 개발 현장에서는 "CT(Coding Test)" 또는 "PT(Program Test)"라고 줄여서 부르기도 한다. (CT와 PT는 일본식 표현이다.)

단위 테스트 도구로서 자바에서는 테스팅 프레임워크인 JUnit이 유명하다. 이는 자바 전용이다. 다른 언어에도 이와 유사한 것이 있으며, 이를 통칭하여 xUnit이라고 부른다.

5. 2. 2. 통합 테스트

통합 테스트는 개별 소프트웨어 모듈을 통합하고 테스트(testing)하여 예상대로 작동하는지 확인하는 단계이다.[11] 통합 테스트는 단위 테스트 후에 수행되며, 테스트된 모듈이 시스템의 다른 부분과 함께 작동하는지 확인한다.

통합 테스트는 단위 테스트가 완료된 프로그램을 결합하여 수행하는 테스트이다. 프로그램의 어떤 부분부터 결합해 나갈지에 따라 하향식 테스트와 상향식 테스트로 나눌 수 있다. Integration Testing영어 (통합 테스트)는 "IT"라고 줄여 부르기도 하며, 결합 테스트라고 부르기도 한다.

통합 테스트와 시스템 테스트를 구분하기도 하는데, 모의 시험(simulation)을 통합 테스트 또는 시스템 테스트 중 어디에 분류할지는 경우에 따라 다르다.

  • 하향식 테스트: 단위 테스트가 완료된 모듈 중 상위 모듈부터 순서대로 결합하여 테스트를 수행한다. 이 기법은 사양적인 동작을 결정하는 상위 모듈을 조기에 검증하여 기능 누락, 사양 인식 오류 등 치명적인 결함을 개발 초기 단계에서 발견할 수 있다는 장점이 있다. 반면, 하위 모듈의 검증이 뒤로 미뤄지기 때문에 개발과 병행하여 테스트를 진행하기 어렵다는 단점도 있다. 하향식 테스트를 수행할 때는 테스트 스텁을 준비해야 한다.
  • 상향식 테스트: 단위 테스트가 완료된 하위 모듈부터 순서대로 결합하여 테스트를 수행한다. 이 기법은 독립성이 높은 하위 모듈부터 검증하여 개발과 테스트를 병행할 수 있다는 장점이 있다. 반면, 시스템의 근간이 되는 상위 모듈에서 결함이 발견되면 테스트가 완료된 하위 모듈도 영향을 받는다는 단점이 있다. 다른 함수 등을 호출하는 함수를 시험할 때, 호출이 없는 함수를 시험한 후 호출하는 함수를 시험하는 경우가 상향식 테스트에 해당한다. 상향식 테스트를 수행할 때에는 테스트 드라이버를 준비해야 한다.

5. 2. 3. 시스템 테스트

시스템 테스트는 전체 소프트웨어 시스템에 대한 테스트로, 통합 테스트 후 수행된다. 이 테스트의 목적은 시스템이 명시된 요구 사항을 충족하는지 평가하는 것이다. 시스템 테스트는 블랙 박스 테스트 기법을 사용하여 수행된다.[11]

프로그램을 단독으로 실행하는 것이 아닌, 다른 프로그램이나 하드웨어, 통신 네트워크, 데이터베이스 등과 조합하여 실시하는 테스트이다. 개발 환경과 실행 환경이 다른 경우에는 실제 실행 환경을 사용하여 수행하기도 하며, 고객에게만 실제 실행 환경이 있는 경우에는 고객 환경에서 수행하는 경우가 있다. 실제 환경을 이용하는 것이 비용이 많이 들거나 시간이 오래 걸리는 경우에는 모의 시험 환경(simulator)을 작성하여 실시하기도 한다. 이 경우에는 모의 환경의 시스템 시험, 실제 환경에서의 시스템 시험으로 구분한다. 모의 환경에서는 복수의 사상을 동시에 발생시키기가 어렵거나, 반대로 실제 환경에서는 발생할 수 없는 사상을 발생시킬 수 없는 등 각각의 단점과 장점을 파악하여 시험을 실시한다.

5. 3. 정적, 동적, 수동 테스트

코드 검토, 소프트웨어 워크스루 또는 소프트웨어 검사는 정적 테스팅이라고 하며, 주어진 테스트 케이스 집합으로 프로그래밍된 코드를 실행하는 것은 동적 테스팅이라고 한다.[20][21] 정적 테스팅은 소프트웨어 검증을 포함하며, 동적 테스팅은 소프트웨어 유효성 검사도 포함한다.[21]

정적 테스팅은 종종 정적 프로그램 분석과 같이 증명, 프로그래밍 도구/텍스트 편집기가 소스 코드 구조를 확인하거나 컴파일러(사전 컴파일러)가 구문 및 데이터 흐름을 확인하는 것과 같이 암묵적이다. 동적 테스팅은 프로그램 자체가 실행될 때 발생한다. 동적 테스팅은 코드의 특정 섹션을 테스트하기 위해 프로그램이 100% 완료되기 전에 시작될 수 있으며 개별 함수 또는 모듈에 적용된다.[20][21] 이러한 기술에 대한 일반적인 방법은 메소드 스텁/드라이버를 사용하거나 디버거 환경에서 실행하는 것이다.[21]

수동 테스팅은 소프트웨어 제품과의 상호 작용 없이 시스템의 동작을 확인하는 것을 의미한다. 능동적 테스팅과 달리, 테스터는 어떤 테스트 데이터도 제공하지 않고 시스템 로그와 추적을 살펴본다. 그들은 어떤 종류의 결정을 내리기 위해 패턴과 특정 동작을 찾는다.[22] 이는 오프라인 런타임 검증 및 로그 분석과 관련이 있다.

5. 4. 탐색적 테스트

소프트웨어 테스팅의 한 접근 방식이다.

5. 5. 사전 설정 테스트 vs 적응형 테스트

테스트 전략의 유형은 테스트 대상(IUT)에 적용할 테스트를 테스트 계획 실행 전에 결정해야 하는지(사전 설정 테스트[23]), 아니면 각 입력이 이전 테스트 적용 중 얻은 출력에 동적으로 의존할 수 있는지(적응형 테스트[24][25])에 따라 달라진다.

5. 6. 블랙박스/화이트박스 테스트

소프트웨어 테스팅은 내부 구조를 고려하는지에 따라 화이트 박스 테스트와 블랙 박스 테스트로 나눌 수 있다. 테스터가 테스트 케이스를 설계할 때 어떤 관점을 가지는지에 따라 이 두 가지 방법이 사용된다. 그레이 박스 테스트는 이 두 가지 방법을 혼합한 방식이다.

프로그램의 내부 구조에 주목한 테스트를 화이트 박스 테스트(white box test)라고 하며, 프로그램의 입력과 출력에 주목한 테스트를 블랙 박스 테스트(black box test)라고 한다.

5. 6. 1. 화이트박스 테스트

화이트박스 테스트는 프로그램의 내부 구조나 작동 방식을 확인하는 테스트이다. 최종 사용자에게 보이는 기능이 아닌, 소스 코드와 같은 시스템 내부 관점을 사용하여 테스트 케이스를 설계한다. 테스터는 코드의 경로를 실행하기 위한 입력을 선택하고, 그에 따른 적절한 출력을 결정한다.[26][27]

화이트 박스 테스트 다이어그램


화이트박스 테스트는 소프트웨어 테스트 프로세스의 단위 테스트, 통합 테스트, 시스템 테스트 단계에서 적용할 수 있지만, 일반적으로는 단위 테스트 수준에서 많이 수행된다.[43] 단위 내의 경로나 통합 과정에서 단위 간의 경로, 시스템 수준 테스트에서 하위 시스템 간의 경로 등을 테스트할 수 있다. 이 테스트 설계 방법은 많은 오류를 찾을 수 있지만, 명세서에 구현되지 않은 부분이나 누락된 요구 사항은 찾지 못할 수도 있다.

화이트박스 테스트에 사용되는 주요 기술은 다음과 같다.[27][28]

  • API 테스트: 공개 및 비공개 API를 사용하여 애플리케이션을 테스트한다.
  • 코드 커버리지: 코드 커버리지 기준을 만족시키기 위한 테스트를 생성한다. (예: 프로그램의 모든 문장이 최소 한 번 실행되도록 테스트 생성)
  • 결함 주입: 테스트 전략의 효과를 측정하기 위해 의도적으로 결함을 추가한다.
  • 변이 테스트
  • 정적 테스트


코드 커버리지 도구는 블랙박스 테스트를 포함한 모든 방법으로 만들어진 테스트 제품군이 얼마나 완전한지를 평가할 수 있게 한다. 이를 통해 소프트웨어 팀은 거의 테스트되지 않은 시스템 부분을 확인하고, 가장 중요한 기능 점수가 테스트되었는지 확인할 수 있다.[29]

코드 커버리지는 소프트웨어 메트릭으로서 다음과 같은 백분율로 보고될 수 있다.[26][29][30]

  • 함수 커버리지: 실행된 함수에 대해 보고한다.
  • 문장 커버리지: 테스트를 완료하기 위해 실행된 라인 수에 대해 보고한다.
  • 결정 커버리지: 주어진 테스트에서 참과 거짓 분기가 모두 실행되었는지 여부에 대해 보고한다.


100% 문장 커버리지는 모든 코드 경로나 분기(제어 흐름)가 최소 한 번 실행되도록 보장한다. 이는 올바른 기능을 보장하는 데 도움이 되지만, 동일한 코드가 다른 입력을 올바르게 또는 잘못 처리할 수 있으므로 충분하지 않다.[31]

화이트박스 테스트는 프로그램의 구조에 초점을 맞춘다. 주목하는 구조에는 명령이나 분기 등이 있으며, 얼마나 많은 부분을 실행했는지를 커버리지로 나타낸다.

C 언어로 작성된 다음의 `abs` 함수를 예시로 다양한 커버리지 기준을 설명한다.



int abs(int x) {

if (x < 0) {

x = -x;

}

return x;

}


  • 명령어 커버리지: 모든 명령어를 실행하면 된다.[84][85] 위의 `abs` 함수에서는 `x = -1`을 사용하여 테스트하면 명령어 커버리지 기준을 만족한다.
  • 분기 커버리지 (판정 조건 커버리지): 모든 분기에서 모든 분기의 방향을 실행하면 된다.[84][85] `abs` 함수에서는 `x = -1`과 `x = 0`을 사용하여 각각 테스트하면 분기 커버리지 기준을 만족한다. 분기 커버리지는 명령어 커버리지 기준을 포함한다.[84]
  • 조건 커버리지: 각 개별 조건에 대해 모든 가능한 결과를 최소 한 번은 수행하도록 실행하면 된다.[84][85] 조건 커버리지 기준은 분기의 방향을 고려하지 않기 때문에 분기 커버리지나 명령어 커버리지 기준을 만족하지 못할 수도 있다.[84]
  • 판정 조건/조건 커버리지: 각 개별 조건에 대해 모든 결과를 최소한 한 번씩 얻도록 하고, 각 분기에 대해 모든 분기 방향을 실행하면 된다.[84][85]
  • 복합 조건 커버리지: 각 판정의 모든 결과에 대한 모든 가능한 조합을 적어도 한 번 이상 수행해야 한다.[84][85] 단, 일부 조합은 생성 불가능할 수 있다. (예: 조건 (A > 2)와 (A < 10)에서는 가능한 조합이 3개뿐이다.)[84]
  • 경로 커버리지: 모든 경로가 적어도 한 번은 지나가도록 실행하면 된다.[84][85] 반복 구조가 있는 프로그램에서는 모든 경로를 특정하는 것이 불가능할 수 있으므로, 완전한 경로 커버리지는 현실적인 목표가 아니다.[84]

5. 6. 2. 블랙박스 테스트

블랙박스 테스트(기능 테스트라고도 함)는 소스 코드를 보지 않고 구현에 대한 지식 없이 소프트웨어가 수행해야 하는 작업만 알고 테스트하는 방법이다.[32] 테스터는 소프트웨어가 어떻게 동작하는지는 알지 못한다.

블랙 박스 다이어그램


블랙박스 테스트 방법에는 동등 분할, 경계 값 분석, 올페어 테스트, 상태 전이 표, 의사 결정 표 테스트, 퍼즈 테스트, 모델 기반 테스트, 사용 사례 테스트, 탐색적 테스트, 및 명세 기반 테스트가 포함된다.[26][27][30]

명세 기반 테스트는 관련 요구 사항에 따라 소프트웨어의 기능을 테스트하는 것을 목표로 한다.[33] 테스터는 주어진 입력에 대해 출력 값(또는 동작)이 테스트 케이스에 지정된 예상 값과 같은지, 혹은 같지 않은지를 확인한다. 테스트 케이스는 애플리케이션이 수행해야 하는 작업과 같은 명세 및 요구 사항을 중심으로 구축된다. 명세, 요구 사항 및 설계를 포함하여 소프트웨어의 외부 설명을 사용하여 테스트 케이스를 도출한다. 이러한 테스트는 기능적 또는 비기능적일 수 있지만 일반적으로 기능적이다. 명세 기반 테스트는 올바른 기능을 보장하는 데 필요할 수 있지만 복잡하거나 위험도가 높은 상황을 방지하기에는 부족하다.[34]

블랙 박스 테스트는 유닛 레벨을 제외하고 모든 수준의 테스트에 사용할 수 있다.[43]

블랙 박스 테스트는 프로그램의 입력과 출력에만 주목하여 사양대로 프로그램이 동작하는지, 혹은 사양대로 동작하지 않는지를 테스트한다. 프로그램의 입력이 단일 값인 경우에는 동치 분할이나 경곗값 분석을, 프로그램의 입력이 복수 개 존재하고 서로 영향을 미치는 경우에는 의사 결정표나 원인 결과 그래프 등을 사용하여 입력을 결정한다. 전역 변수의 읽기/쓰기, 통신, 인터럽트 등이 처리 중에 있는 경우에는, 이러한 것들도 입출력의 하나로 취급한다.
동등 분할입력 또는 출력을 동일하게 처리할 수 있는 그룹으로 값을 나눈 것을 동치 클래스라고 부르며, 각 대표적인 값을 사용하여 테스트를 수행한다. 유효한 동치 클래스를 유효 동치 클래스, 무효(에러)가 되는 동치 클래스를 무효 동치 클래스라고 부른다.
경계값 분석입력 또는 출력을 동일하게 처리할 수 있는 그룹으로 값을 나누고, 그 경계가 되는 값을 사용하여 테스트를 수행한다. 프로그램 오류는 분기점의 경계에서 발생하는 경우가 많기 때문에, 경계값 분석에 기반한 테스트를 수행함으로써, 동등 분할에 기반한 테스트보다 더 많은 결함을 발견할 수 있다.
예시

  • 입력: 시각 (0:00-23:59)
  • 출력: 10:00 ≦ 입력 ≦ 20:00 이면 정상 요금, 그 외에는 할증 요금


블랙박스 테스트 예시
구분내용
정상 요금 동치 클래스10:00 이상 20:00 이하
할증 요금 동치 클래스0:00 이상 10:00 미만, 20:00 초과 23:59 이하
무효 동치 클래스0:00 미만, 23:59 초과


  • 동등 분할 입력 예: -1:00, 8:00, 12:00, 22:00, 25:00
  • 경계값 분석 입력 예: -0:01, 0:00, 9:59, 10:00, 20:00, 20:01, 23:59, 24:00


'''컴포넌트 인터페이스 테스트'''

컴포넌트 인터페이스 테스트는 블랙 박스 테스트의 변형으로, 하위 시스템 구성 요소의 관련 작업뿐만 아니라 데이터 값에 중점을 둔다.[35] 다양한 유닛 또는 하위 시스템 구성 요소 간에 전달되는 데이터를 해당 유닛 간의 완전한 통합 테스트 외에도 확인할 수 있다.[36][37] 전달되는 데이터는 "메시지 패킷"으로 간주될 수 있으며, 범위 또는 데이터 유형은 한 유닛에서 생성된 데이터를 확인하고 다른 유닛으로 전달되기 전에 유효성을 테스트할 수 있다. 인터페이스 테스트의 한 가지 옵션은 유닛 간에 전달되는 데이터 항목의 별도 로그 파일을 유지하는 것으로, 수천 개의 유닛 간에 전달된 데이터 사례를 며칠 또는 몇 주 동안 분석할 수 있도록 타임스탬프가 기록되는 경우가 많다. 테스트에는 다른 인터페이스 변수가 정상 값으로 전달되는 동안 일부 극단적인 데이터 값의 처리를 확인하는 것이 포함될 수 있다.[36] 인터페이스의 특이한 데이터 값은 다음 유닛의 예상치 못한 성능을 설명하는 데 도움이 될 수 있다.

'''의사 결정표'''

의사 결정표는 조건(입력)이 여러 매개변수로 구성된 경우, 조건(입력)과 동작(입출력)의 관계를 표 형식으로 나타낸 것이다. 표의 각 열이 규칙(테스트 케이스)을 나타낸다.

규칙(테스트 케이스)1234
조건(입력)평일이다YYNN
오전 10시부터 오후 8시YNYN
동작(입출력)통상 요금X---
할증 요금-XXX


5. 6. 3. 그레이박스 테스트

그레이 박스 테스트는 사용자, 즉 블랙 박스 수준에서 해당 테스트를 실행하는 동안 테스트 설계를 목적으로 내부 데이터 구조와 알고리즘에 대한 지식을 사용하는 것을 포함한다. 테스터는 종종 "소스 코드와 실행 가능한 바이너리"에 모두 액세스할 수 있다.[41] 그레이 박스 테스트는 또한 경계 값 또는 오류 메시지를 결정하기 위해 리버스 엔지니어링(동적 코드 분석 사용)을 포함할 수도 있다.[41] 입력 데이터 조작 및 출력 형식 지정은 그레이 박스에 해당하지 않는데, 입력 및 출력은 테스트 중인 시스템이라고 부르는 "블랙 박스" 외부에 분명히 있기 때문이다. 이 구분은 두 명의 다른 개발자가 작성한 코드의 두 모듈 간에 통합 테스트를 수행할 때 특히 중요하다. 이 경우 인터페이스만 테스트를 위해 노출된다.

소프트웨어 작동 방식의 기본 개념을 알면 테스터는 외부에서 소프트웨어를 테스트하는 동안 더 나은 정보를 기반으로 테스트를 선택할 수 있다. 일반적으로 그레이 박스 테스터는 데이터베이스를 시딩하는 것과 같은 활동을 통해 격리된 테스트 환경을 설정할 수 있다. 테스터는 데이터베이스에 대해 SQL 문을 실행한 다음 예상 변경 사항이 반영되었는지 확인하기 위해 쿼리를 실행하는 등 특정 작업을 수행한 후 테스트 중인 제품의 상태를 관찰할 수 있다. 그레이 박스 테스트는 제한된 정보를 기반으로 지능형 테스트 시나리오를 구현하며, 이는 특히 데이터 유형 처리, 예외 처리 등에 적용된다.[42]

그레이 박스 테스트의 개념으로 인해 블랙 박스 및 화이트 박스 테스트 간의 이 "임의적인 구분"이 다소 희미해졌다.[43]

5. 7. 설치 테스트

설치 테스트는 소프트웨어 애플리케이션이 대상 환경에 예상대로 설치되었는지 확인하는 소프트웨어 테스트의 한 유형이다.

5. 8. 호환성 테스트

소프트웨어 실패의 흔한 원인은 다른 응용 소프트웨어, 운영 체제(또는 운영 체제 버전, 구 버전 또는 신 버전) 또는 원래 환경과 크게 다른 대상 환경과의 호환성 부족이다. 예를 들어, 하위 호환성이 없는 경우, 프로그래머가 대상 환경의 최신 버전에서만 소프트웨어를 개발하고 테스트하기 때문에 발생할 수 있으며, 모든 사용자가 최신 버전을 실행하는 것은 아니다. 이로 인해 최신 작업이 대상 환경의 이전 버전 또는 이전 버전의 대상 환경에서 사용할 수 있었던 구형 하드웨어에서 작동하지 않는 의도하지 않은 결과가 발생한다. 이러한 문제는 운영 체제 기능을 별도의 프로그램 모듈 또는 라이브러리로 사전 추상화하여 해결할 수 있다.[1]

5. 9. 스모크 및 정상 테스트

정상 테스트는 추가적인 테스트를 진행하는 것이 타당한지 여부를 결정한다. 스모크 테스트는 소프트웨어를 작동시키기 위한 최소한의 시도로, 소프트웨어가 전혀 작동하지 못하게 하는 기본적인 문제가 있는지 확인하기 위해 설계되었다. 이러한 테스트는 빌드 검증 테스트로 사용될 수 있다.

5. 10. 회귀 테스트

회귀 테스트는 주요 코드 변경이 발생한 후 결함을 찾는 데 중점을 둔다. 구체적으로, 이 테스트는 소프트웨어 회귀를 찾아내려고 하며, 여기에는 이전 버그가 다시 나타나는 것을 포함하여 기능이 저하되거나 손실된 경우도 해당된다. 이러한 회귀는 이전에 제대로 작동하던 소프트웨어 기능이 의도한 대로 작동하지 않을 때 발생한다. 일반적으로 회귀는 소프트웨어의 새롭게 개발된 부분이 이전에 존재하던 코드와 충돌할 때 프로그램 변경의 의도하지 않은 결과로 발생한다.[44] 회귀 테스트는 이전 소프트웨어 기능의 수많은 세부 사항을 확인해야 하므로 상업용 소프트웨어 개발에서 일반적으로 가장 큰 테스트 노력이다. 심지어 새로운 소프트웨어가 개발되는 동안에도 이전 테스트 케이스를 사용하여 새로운 설계의 일부를 테스트하여 이전 기능이 여전히 지원되는지 확인할 수 있다.

회귀 테스트의 일반적인 방법으로는 이전 테스트 케이스 세트를 다시 실행하고 이전에 수정된 결함이 다시 나타났는지 확인하는 것이 있다. 테스트의 깊이는 릴리스 프로세스의 단계와 추가된 기능의 위험 관리에 따라 달라진다.

소프트웨어 테스트는 "변경에 대한 신뢰"를 생성함으로써 소프트웨어의 품질 및 제공 속도를 향상시키는 목적과 효과를 갖는다.

소프트웨어 변경(예: 리팩토링, 기능 추가)은 기존 코드의 파괴로 인한 버그(회귀)를 일으킬 수 있으므로, 소프트웨어 엔지니어에게 코드 변경에 대한 심리적 장벽으로 작용한다. 이 장벽은 변경에 대한 망설임을 낳아 품질 향상의 기회를 감소시킨다.

회귀 테스트는 코드 변경으로 인한 버그를 발견하고 결함의 발생을 방지하며, 품질에 대한 신뢰를 높인다. 이러한 효과로 인해, 새로운 변경이 기존 컴포넌트를 파괴하지 않는다는 신뢰(confidence)·안심이 엔지니어에게 생긴다.[80][81] 결과적으로 좋은 변경의 빈도가 증가하여 소프트웨어의 품질·제공 속도가 향상된다.

프로그램을 수정 또는 변경했을 때, 과거에 실시했던 테스트를 다시 실시하는 것을 회귀 테스트(영: regression test) 또는 퇴행 테스트라고 한다. 수정 전의 시험에 다시 합격하는지, 다른 기능에 영향을 미치지 않는지, 다른 기능이 동작하는지 확인한다. 과거의 테스트 자산을 사용하여 실시하는 횟수도 많기 때문에, 실시를 생략하는 일이 없도록 테스트 자동화를 통해 효율화를 꾀한다.

회귀 테스트 시, 테스트 범위를 모든 테스트 케이스로 할 것인지, (모든 테스트 케이스를 실시하는 데 필요한 시간이나 공수와 수정이 미치는 범위를 고려하여) 부분 테스트 케이스로 할 것인지 판단하며, 결함을 탐지하는 빈도를 고려하여 높은 우선순위로 실시하는 테스트 케이스를 선택하는 방법이 있다.

5. 11. 인수 테스트

인수 테스트는 소프트웨어가 고객의 기대를 충족하는지 확인하기 위한 시스템 수준의 테스트이다.[66][45][46][47] 개발의 두 단계 사이의 인계 과정의 일부로 수행될 수 있다.

테스트는 소프트웨어 개발 프로세스에서 테스트가 수행되는 위치 또는 테스트의 구체성 수준에 따라 다음과 같이 그룹화된다.[47]

  • 사용자 인수 테스트(UAT)
  • 운영 인수 테스트(OAT)
  • 계약 및 규제 인수 테스트
  • 알파 및 베타 테스트


경우에 따라 UAT는 고객이 자신의 환경과 자체 하드웨어에서 수행한다.

OAT는 품질 관리 시스템의 일부로 제품, 서비스 또는 시스템의 운영 준비(출시 전)를 수행하는 데 사용된다. OAT는 주로 소프트웨어 개발 및 소프트웨어 유지보수 프로젝트에서 사용되는 일반적인 유형의 비기능적 소프트웨어 테스트이다. 이 유형의 테스트는 지원될 시스템 또는 프로덕션 환경의 일부가 될 시스템의 운영 준비 상태에 중점을 둔다. 따라서 운영 준비 및 보증 (OR&A) 테스트라고도 한다. OAT 내의 기능 테스트는 시스템의 "비기능적" 측면을 확인하는 데 필요한 테스트로 제한된다.

또한 소프트웨어 테스트는 시스템의 이식성이 예상대로 작동할 뿐만 아니라 운영 환경을 손상시키거나 부분적으로 손상시키지 않으며 해당 환경 내의 다른 프로세스가 작동하지 않도록 하는지도 확인해야 한다.[48]

계약 인수 테스트는 계약 체결 시 정의된 계약의 인수 기준에 따라 수행되며, 규제 인수 테스트는 소프트웨어 제품 관련 규정에 따라 수행된다. 이 두 테스트 모두 사용자가 수행하거나 독립적인 테스터가 수행할 수 있다. 규제 인수 테스트에는 때때로 규제 기관이 테스트 결과를 감사하는 것이 포함된다.[47]

5. 12. 알파 테스트

알파 테스트는 개발자 사이트에서 잠재 사용자나 독립적인 테스트 팀이 수행하는 시뮬레이션 또는 실제 운영 테스트이다. 알파 테스트는 소프트웨어가 베타 테스트로 넘어가기 전에 내부적인 인수 테스트의 형태로 기성 소프트웨어에 자주 사용된다.[49]

알파 테스트는 개발 완료 전의 소프트웨어를 개발자 외의 사용자에게 사용하게 하여 결함을 발견하는 테스트를 말하며, 베타 테스트보다 완성도가 낮은 단계(알파 버전)에서 실시한다. 알파 테스트는 내부에서, 베타 테스트는 외부에서 실시한다는 구분을 하기도 한다. 오픈 소스, 온라인 게임에서는 베타 테스트를 널리 일반에 공개하여 선전의 목적을 겸하여 실시하는 경우가 있다.

5. 13. 베타 테스트

베타 테스트는 알파 테스트가 끝난 후에 진행되며, 외부 사용자 인수 테스트의 한 형태로 볼 수 있다. 베타 버전이라고 알려진 소프트웨어 버전은 프로그래밍 팀 외부의 제한된 인원인 베타 테스터에게 공개된다. 소프트웨어는 더 많은 테스트를 통해 제품에 결함이나 버그가 거의 없도록 하기 위해 여러 사람들에게 공개된다.[50]

베타 버전은 사용자의 피드백을 최대한 많이 받고, 더 빨리 가치를 제공하기 위해 일반 대중에게 공개될 수 있으며, 이는 연장되거나 심지어 무기한으로 지속될 수도 있다(영구 베타).[50]

개발이 완료되기 전의 소프트웨어를 개발자가 아닌 사용자에게 사용하게 하여 문제점을 발견하는 테스트를 말한다. 알파 테스트는 베타 테스트보다 완성도가 낮은 단계(알파 버전)에서 실시하는 테스트이다. 알파 테스트는 내부에서, 베타 테스트는 외부에서 실시한다는 구분을 하기도 한다. 오픈 소스, 온라인 게임에서는 베타 테스트를 널리 일반에 공개하여 선전의 목적을 겸하는 경우가 많다.

베타 테스트에서 배포하는 소프트웨어(베타 버전)는 기본적으로 제품 버전과 동일한 기능을 갖추고 있지만, 문제점이 있을 수 있으므로 사용하기 전에 주의해야 할 사항을 주의사항 등에 기재한다. 설계에서 예상하지 못한 문제점이 발생하기도 하므로, 주의사항에 없는 내용에 대해 무엇을 고려해야 할지 예상하고, 시스템 백업 등을 실시한 후 도입하는 것이 좋다.

5. 14. 기능 vs 비기능 테스트

기능 테스트는 코드의 특정 동작이나 기능을 검증하는 활동을 의미한다. 이러한 활동들은 일반적으로 코드 요구 사항 문서에서 찾아볼 수 있지만, 일부 개발 방법론에서는 유스 케이스나 사용자 스토리를 기반으로 작업한다. 기능 테스트는 주로 "사용자가 이것을 할 수 있는가?" 또는 "이 특정 기능이 작동하는가?"라는 질문에 답한다.

비기능 테스트는 확장성, 성능, 특정 제약 하에서의 동작, 보안 등 소프트웨어의 특정 기능이나 사용자 동작과 관련이 없을 수 있는 측면을 의미한다. 테스트는 확장성이나 성능의 극단적인 상황이 불안정한 실행으로 이어지는 지점, 즉 파괴 지점을 결정한다. 비기능 요구 사항은 제품의 품질, 특히 사용자의 적합성 관점에서 품질을 반영하는 경향이 있다. 기능 시험 및 성능 시험의 지표와 분류에 ISO 9126의 틀을 이용하는 경우가 있다.

5. 15. 지속적 테스트

지속적 테스트는 소프트웨어 릴리스 후보와 관련된 비즈니스 위험에 대한 즉각적인 피드백을 얻기 위해 소프트웨어 제공 파이프라인의 일부로 자동화된 테스트를 실행하는 프로세스이다.[51][52] 지속적 테스트는 기능적 요구사항과 비기능적 요구사항의 유효성 검사를 모두 포함하며, 테스트 범위는 하향식 요구사항 또는 사용자 스토리의 유효성 검사에서 전반적인 비즈니스 목표와 관련된 시스템 요구사항 평가까지 확장된다.[53][54]

5. 16. 파괴적 테스트

파괴적 테스트는 소프트웨어나 하위 시스템에 의도적으로 고장을 일으켜 작동 방식을 확인하는 테스트이다. 이러한 테스트는 소프트웨어가 예상치 못한 입력이나 유효하지 않은 값을 받았을 때도 제대로 작동하는지 확인하고, 입력 유효성 검사와 오류 관리 루틴의 견고성을 검증한다. 소프트웨어 오류 주입은 실패 테스트의 한 예시이며, 퍼징과 같은 형태를 띤다. 파괴적 테스트 수행을 위한 다양한 상용 비기능 테스트 도구와 오픈 소스 및 프리웨어 도구들이 있다.

5. 17. 소프트웨어 성능 테스트

성능 테스트는 일반적으로 특정 워크로드에서 시스템 또는 하위 시스템이 응답성과 안정성 측면에서 어떻게 동작하는지 확인하기 위해 수행된다. 또한 확장성, 신뢰성 및 리소스 사용과 같은 시스템의 다른 품질 속성을 조사, 측정, 검증 또는 확인하는 데 사용될 수 있다.[1]

부하 테스트는 대량의 데이터 또는 많은 수의 사용자 등 특정 부하에서도 시스템이 계속 작동할 수 있는지 테스트하는 데 주로 관련된다. 이것은 일반적으로 소프트웨어 확장성이라고 한다. 관련된 부하 테스트 활동은 비기능적 활동으로 수행될 때 종종 지구력 테스트라고 한다. 볼륨 테스트는 특정 구성 요소(예: 파일 또는 데이터베이스)의 크기가 급격하게 증가하더라도 소프트웨어 기능을 테스트하는 방법이다. 스트레스 테스트는 예상치 못한 또는 드문 워크로드에서 신뢰성을 테스트하는 방법이다. 안정성 테스트(종종 부하 또는 지구력 테스트라고 함)는 소프트웨어가 허용 가능한 기간 내 또는 그 이상으로 지속적으로 잘 작동하는지 확인한다.[1]

성능 테스트의 특정 목표가 무엇인지에 대해서는 거의 합의가 이루어지지 않았다. 부하 테스트, 성능 테스트, 확장성 테스트 및 볼륨 테스트라는 용어는 종종 상호 교환적으로 사용된다.[1]

실시간 소프트웨어 시스템에는 엄격한 타이밍 제약 조건이 있다. 타이밍 제약 조건이 충족되는지 테스트하기 위해 실시간 테스트가 사용된다.[1]

기능 시험 및 성능 시험의 지표와 분류에 ISO/IEC 9126(ISO 9126)의 틀을 이용하는 경우가 있다.[2]

성능 시험은 소프트웨어 시스템의 성능을 측정하고, 필요한 성능이 나오는지를 확인하는 시험이다. 입력을 얼마나 수용하는지, 얼마나 많은 출력이 가능한지, 통신 경로 수, 통신 속도, 처리 건수 등 프로그램 단독으로는 문제가 발생하지 않더라도 통신, 데이터베이스, 입출력(I/O), 동시에 기동하는 소프트웨어 등 고부하, 장시간 사용 등의 조건 하에서는 성능이 저하될 수 있다. 성능을 확인하는 시험은 시스템의 성능에 영향을 주지 않도록 측정할 필요가 있기 때문에 OS나 미들웨어 등에서는 성능을 측정하는 효율적인 계측 방법을 제공하기도 한다.[2]

성능 시험은 단위 시험부터 실시하는 경우와 통합 시험부터 실시하는 경우가 있다.[2]

과부하에 대한 성능 시험을 스트레스 테스트라고 한다.[3]

스트레스 테스트는 소프트웨어 시스템에 높은 부하를 가하여 처리 저하, 누락, 데이터 손상, 발열 등 치명적인 문제가 어떤 조건에서 발생하는지 시험한다. 스트레스 테스트를 수행함으로써 높은 부하가 가해지는 상황에서만 발생하는 문제, 발생 확률이 낮은 결함, 현저한 성능 저하를 발견할 수 있다. 성능 테스트의 일부로 수행하며, 대응 가능한 부하의 사양을 확인하는 경우가 있다.[3]

5. 18. 사용성 테스트

사용성 테스트는 사용자 인터페이스가 사용하기 쉽고 이해하기 쉬운지 확인하는 것이다. 이는 주로 애플리케이션의 사용과 관련이 있다. 사용성 테스트는 자동화될 수 있는 테스트 종류가 아니며, 숙련된 UI 디자이너가 모니터링하는 실제 사용자가 필요하다.

5. 19. 접근성 테스트

접근성 테스팅은 장애가 있는 사람이 소프트웨어를 사용할 수 있는지 확인하기 위해 수행된다. 일반적인 웹 접근성 테스트는 다음과 같다.

  • 글꼴과 배경색 사이의 색상 대비가 적절한지 확인
  • 글꼴 크기
  • 멀티미디어 콘텐츠에 대한 대체 텍스트
  • 마우스 외에 컴퓨터 키보드를 사용하여 시스템을 사용할 수 있는 기능
  • 미국 장애인법
  • 1973년 재활법 508조 개정안
  • 월드 와이드 웹 컨소시엄(W3C)의 웹 접근성 이니셔티브(WAI)

5. 20. 보안 테스트

보안 테스팅은 기밀 데이터를 처리하는 소프트웨어가 해커로부터 시스템 침입을 방지하는 데 필수적이다.

국제 표준화 기구(ISO)는 이를 "테스트 대상 항목 및 관련 데이터와 정보가 무단 사용, 읽기 또는 수정될 수 없도록 보호되고, 권한 있는 사람이 시스템에 대한 접근이 거부되지 않도록 평가하기 위해 수행되는 테스트 유형"으로 정의한다.[55]

5. 21. 국제화 및 지역화

국제화 및 지역화 테스트는 소프트웨어가 다양한 언어 및 지리적 지역에서 사용될 수 있는지 확인하는 과정이다. 의사 지역화는 애플리케이션이 다른 언어로 번역될 수 있는지 테스트하는 데 사용되며, 지역화 과정에서 제품에 새로운 버그가 발생할 수 있는 시점을 쉽게 식별할 수 있게 한다.

글로벌화 테스트는 소프트웨어가 다른 통화 또는 시간대와 같은 새로운 문화에 적응되었는지 확인한다.[56]

실제 사람의 언어로 번역하는 과정 또한 테스트해야 한다. 지역화 및 글로벌화 실패 가능성은 다음과 같다.

  • 일부 메시지가 번역되지 않을 수 있다.
  • 소프트웨어는 종종 문맥에서 벗어난 문자열 목록을 번역하여 지역화되는데, 번역가는 모호한 소스 문자열에 대해 잘못된 번역을 선택할 수 있다.
  • 적절한 조정 없이 여러 사람이 프로젝트를 번역하거나 번역가가 부주의한 경우 기술 용어가 일관되지 않을 수 있다.
  • 문자 그대로 단어 대 단어 번역은 대상 언어에서 부적절하거나 인위적이거나 너무 기술적으로 들릴 수 있다.
  • 원본 언어의 번역되지 않은 메시지는 소스 코드에 하드 코딩되어 번역이 불가능할 수 있다.
  • 일부 메시지는 런타임에 자동으로 생성될 수 있으며, 결과 문자열이 문법적으로 잘못되었거나, 기능적으로 잘못되었거나, 오해의 소지가 있거나, 혼란스러울 수 있다.
  • 소프트웨어는 원본 언어의 키보드 레이아웃에서는 기능이 없지만 대상 언어의 레이아웃에서 문자를 입력하는 데 사용되는 키보드 단축키를 사용할 수 있다.
  • 소프트웨어는 대상 언어의 문자 인코딩을 지원하지 않을 수 있다.
  • 소스 언어에 적합한 글꼴과 글꼴 크기는 대상 언어에서 부적절할 수 있다. 예를 들어, 글꼴이 너무 작으면 CJK 문자를 읽을 수 없게 될 수 있다.
  • 대상 언어의 문자열이 소프트웨어가 처리할 수 있는 것보다 길 수 있다. 이로 인해 문자열이 사용자에게 부분적으로 표시되지 않거나 소프트웨어가 충돌 또는 오작동을 일으킬 수 있다.
  • 소프트웨어는 양방향 텍스트를 읽거나 쓰는 것을 제대로 지원하지 않을 수 있다.
  • 소프트웨어는 지역화되지 않은 텍스트가 포함된 이미지를 표시할 수 있다.
  • 지역화된 운영 체제는 시스템 구성 파일과 환경 변수의 이름이 다르고, 날짜와 통화의 형식이 다를 수 있다.

5. 22. 개발 테스트

개발 테스트는 소프트웨어 개발 과정에서 발생할 수 있는 위험, 시간, 비용을 줄이기 위해 다양한 결함 예방 및 감지 전략을 통합하여 적용하는 소프트웨어 개발 프로세스이다. 이 테스트는 소프트웨어 개발 생명 주기의 구축 단계에서 소프트웨어 개발자나 엔지니어가 수행하며, 코드가 다른 테스트 단계로 넘어가기 전에 구축 오류를 제거하는 것을 목표로 한다. 개발 테스트는 결과 소프트웨어의 품질을 향상시킬 뿐만 아니라, 전반적인 개발 프로세스의 효율성을 높이는 데에도 기여한다.

조직의 소프트웨어 개발 기대치에 따라 개발 테스트에는 정적 코드 분석, 데이터 흐름 분석, 메트릭 분석, 동료 코드 검토, 단위 테스트, 코드 커버리지 분석, 추적성 및 기타 소프트웨어 테스트 방법이 포함될 수 있다.[78][79]

5. 23. A/B 테스트

A/B 테스트는 제안된 변경 사항이 현재 방식보다 더 효과적인지 판단하기 위해 제어된 실험을 수행하는 방법이다. 고객은 기능의 현재 버전(대조군) 또는 수정된 버전(처리군)으로 라우팅되며, 원하는 결과를 달성하는 데 어떤 버전이 더 나은지 결정하기 위해 데이터가 수집된다.

5. 24. 동시성 테스트

동시성 테스트는 정상적인 사용 조건에서 병렬 컴퓨팅을 사용하는 소프트웨어 및 시스템의 동작과 성능을 평가한다. 이러한 유형의 테스트에서는 데드락, 경쟁 조건, 공유 메모리/리소스 처리 문제 등이 일반적으로 발생한다.

5. 25. 적합성 테스트

소프트웨어 테스트에서 적합성 테스트는 제품이 지정된 표준에 따라 수행되는지 확인하는 것이다. 예를 들어 컴파일러는 해당 언어에 대한 공인된 표준을 충족하는지 확인하기 위해 광범위하게 테스트된다.[80][81]

적합성 시험은 프로그래밍 언어, OS, 통신 프로토콜, 데이터베이스 등의 사양에 부합하는지 확인하는 시험이다.

운영 체제(OS), 프로그래밍 언어, 네트워크 통신 프로토콜, 데이터베이스 등 소프트웨어를 실행하기 위한 기본적인 플랫폼이 사양에 적합한지 확인하는 검증 시험(verification test)이기도 하다. OS의 국제 표준 중 하나인 POSIX에서는 NIST가 적합성 시험 소스 코드를 공개하고 있다.[82]

자동차용 OS의 국제 표준 OSEK에는 MODISTARC (Methods and tools for the validation of OSEK/VDX based distributed architectures)가 있다. TOPPERS OS에서는 TTSP (TOPPERS Test Suite Package)라는 테스트 환경을 제공하여 적합성 테스트 등을 실시하기 쉽도록 하고 있다.[83]

플랫폼의 적합성 시험을 실시하지 않고 애플리케이션 소프트웨어의 시험을 실시하면, 플랫폼 사양의 변화에 대응하지 못하는 경우가 있다.

5. 26. 출력 비교 테스트

예상 출력과 실제 출력을 비교하는 것은 텍스트의 파일 비교 또는 UI의 스크린샷 데이터 비교와 같이 이루어지는데, 이를 스냅샷 테스트 또는 골든 마스터 테스팅이라고도 부른다.[3] 이는 자동으로 실패를 감지할 수 없으며, 사람이 불일치를 평가해야 한다.

5. 27. 속성 테스트

속성 테스트는 특정 입력이 특정 예상 출력을 생성한다고 단정하는 대신, 실무자가 많은 입력을 무작위로 생성하고, 모든 입력에 대해 프로그램을 실행한 다음, 모든 입력과 출력 쌍에 대해 참이어야 하는 일부 "속성"이 உண்மையின்지 확인하는 테스트 기술이다. 예를 들어, 직렬화 함수의 모든 출력은 해당 역직렬화 함수에 의해 허용되어야 하며, 정렬 함수의 모든 출력은 입력과 정확히 동일한 요소를 포함하는 단조 증가 목록이어야 한다.

속성 테스트 라이브러리를 사용하면 사용자가 무작위 입력을 구성하는 전략을 제어하여, 퇴화된 경우 또는 테스트 중인 구현의 측면을 완전히 실행하는 데 필요한 특정 패턴이 있는 입력을 보장할 수 있다.

속성 테스트는 퀵체크(QuickCheck) Haskell 라이브러리에 의해 소개되고 대중화되었기 때문에 "생성 테스트" 또는 "퀵체크 테스트"라고도 한다.[57]

5. 28. 변형 테스트

변형 테스팅(MT)은 속성 기반 소프트웨어 테스팅 기법으로, 테스트 오라클 문제와 테스트 케이스 생성 문제를 해결하는 데 효과적인 접근 방식이 될 수 있다. 테스트 오라클 문제는 선택된 테스트 케이스의 예상 결과를 결정하거나 실제 출력값이 예상 결과와 일치하는지 확인하는 데 어려움이 있다는 것이다.[1]

5. 29. VCR 테스트

VCR 테스팅은 "재생 테스트" 또는 "기록/재생" 테스트라고도 하며, 느리거나 신뢰할 수 없는, 종종 테스터의 통제를 벗어난 서드 파티 API와 통신하는 구성 요소를 포함하는 회귀 테스트의 신뢰성과 속도를 높이기 위한 테스트 기법이다. 이 방식은 시스템이 외부 구성 요소와 상호 작용하는 내용을 "테이프"로 기록한 다음, 테스트를 다시 실행할 때 외부 시스템과 통신하는 대신 기록된 상호 작용을 재생한다.

이 기술은 vcr Ruby 라이브러리에 의해 웹 개발에서 대중화되었다.

6. 팀워크

(섹션 제목 '팀워크'에 해당하는 내용은 원본 소스에 존재하지 않으므로, 이전 출력과 동일합니다.)

6. 1. 역할

소프트웨어 테스팅은 전담 소프트웨어 테스터가 아닌 사람들이 수행할 수도 있다. 조직에서 테스터는 소프트웨어 개발 팀과 별도의 팀으로 구성되거나 하나의 팀으로 통합될 수 있다. 1980년대에는 '소프트웨어 테스터'라는 용어가 별도의 직업을 나타내는 데 사용되기 시작했다.[58]

주목할 만한 소프트웨어 테스팅 역할 및 직함에는 '테스트 매니저', '테스트 리드', '테스트 분석가', '테스트 설계자', '테스터', '자동화 개발자', '테스트 관리자' 등이 있다.[59]

6. 2. 프로세스

소프트웨어 개발 조직은 각기 다른 방식으로 테스트를 수행하지만, 몇 가지 공통적인 패턴을 보인다.[2]

6. 2. 1. 폭포수 모델

폭포수 모델에서는 코딩이 완료된 후, 제품을 고객에게 인도하기 전에 테스팅을 수행하는 것이 일반적이다.[60] 이러한 관행은 테스팅 단계가 프로젝트 관리 지연을 보상하기 위한 프로젝트 버퍼로 사용되어 테스팅에 할애되는 시간을 줄이는 결과를 초래하기도 한다.[10]

하지만, 폭포수 프로세스에서도 개발 프로젝트 시작과 함께 테스팅이 시작되어 프로젝트 종료 시까지 지속적인 프로세스로 진행될 수 있다는 주장도 있다.[61]

6. 2. 2. 애자일 개발

폭포수 모델과 달리, 애자일 개발에서는 코드를 작성하는 동안 테스트를 포함한다. 테스트 주도 개발(TDD)은 제품 코드를 작성하는 동안 유닛 레벨 테스트를 수행하는 방식이다.[2]

6. 2. 3. 샘플 프로세스

애자일 소프트웨어 개발에서는 보통 코드를 작성하는 동안 테스트를 포함한다. 프로그래머와 테스터로 구성된 팀을 조직하고 팀 구성원이 프로그래밍과 테스트를 모두 수행한다.[2]

테스트 주도 개발(TDD)은 제품 코드를 작성하는 동안 유닛 레벨 테스트를 수행하는 단위 테스트 방식이다.[62] 테스트 코드는 새로운 기능이 추가되거나 실패 조건(버그 수정)이 발견됨에 따라 업데이트된다. 보통 유닛 테스트 코드는 프로젝트 코드와 함께 유지 관리되고, 빌드 프로세스에 통합되며, 각 빌드 시 및 회귀 테스트의 일부로 실행된다. 이러한 지속적 통합의 목표는 개발을 지원하고 결함을 줄이는 것이다.[63][62]

프로그래밍 및 테스트 기능을 팀별로 분리하는 조직에서도 많은 경우 프로그래머가 단위 테스트를 수행한다.[64]

7. 품질

소프트웨어 품질 보증(SQA)은 소프트웨어 개발 과정에서 만들어지는 문서, 코드, 시스템뿐만 아니라, 소프트웨어 공학 과정 자체를 검토하고 개선하는 활동을 포함한다.[3] SQA의 목표는 최종적으로 사용자에게 제공되는 소프트웨어의 결함 수를 줄이는 것이다. 허용되는 결함률은 소프트웨어의 특성에 따라 달라지는데, 예를 들어 비행 시뮬레이터 게임은 실제 비행기 소프트웨어보다 더 높은 결함 허용치를 가진다. SQA는 소프트웨어 테스팅과 밀접하게 관련되어 있지만, 테스팅 부서는 독립적으로 운영되는 경우가 많으며, 일부 회사에는 SQA 기능이 없을 수도 있다.

소프트웨어 테스팅은 품질 관련 정보를 이해 관계자에게 제공하기 위해 테스트 대상 소프트웨어를 조사하는 활동이다. 반면, QA(품질 보증)은 결함이 고객에게 전달되는 것을 방지하기 위한 정책 및 절차를 실행하는 것이다.[3]

7. 1. 소프트웨어 검증 및 유효성 검사

ISTQB는 소프트웨어 결함이 발생하는 과정을 다음과 같이 설명한다.[87]

  • 인간은 코드, 소프트웨어, 시스템 또는 문서에 결함을 만들어내는 오류(실수)를 범할 수 있다.
  • 결함 코드가 실행되면 시스템은 예상한 결과와 다르게 작동하여 실패를 일으킬 수 있다.
  • 소프트웨어, 시스템, 문서 안의 결함은 실패로 이어질 수 있지만, 모든 결함이 그런 것은 아니다.[87]
  • 환경이 바뀌면 결함은 실패로 바뀔 수 있다. 예를 들어 새로운 하드웨어 플랫폼에서 실행되거나, 소스 데이터가 바뀌거나, 다른 소프트웨어와 상호 작용하는 경우가 있다.[87]


소프트웨어 테스트는 검증 및 유효성 검사와 함께 사용된다.[65]

  • 검증: 우리가 소프트웨어를 제대로 만들었는가? (즉, 요구 사항을 구현하는가)
  • 유효성 검사: 우리가 올바른 소프트웨어를 만들었는가? (즉, 결과물이 고객을 만족시키는가)


검증과 유효성 검사라는 용어는 업계에서 흔히 바꿔 사용되기도 하고, 서로 반대되는 정의로 사용되기도 한다. ''IEEE 표준 소프트웨어 공학 용어집''에서는 다음과 같이 정의한다.[11]

  • 검증은 주어진 개발 단계의 제품이 해당 단계의 시작 시점에 부과된 조건을 충족하는지 여부를 판단하기 위해 시스템 또는 구성 요소를 평가하는 프로세스이다.
  • 유효성 검사는 개발 프로세스 중 또는 개발 프로세스의 마지막에 시스템 또는 구성 요소를 평가하여 지정된 요구 사항을 충족하는지 여부를 판단하는 프로세스이다.


ISO 9000 표준에서는 다음과 같이 정의한다.

  • 검증은 명시된 요구 사항이 충족되었음을 객관적인 증거를 제시하고 조사를 통해 확인하는 것이다.
  • 유효성 검사는 특정 의도된 사용 또는 응용 프로그램에 대한 요구 사항이 충족되었음을 객관적인 증거를 제시하고 조사를 통해 확인하는 것이다.


이러한 차이는 요구 사항과 명시된 요구 사항이라는 개념을 서로 다른 의미로 사용하기 때문에 발생한다.

IEEE 표준에서 유효성 검사의 정의에 언급된 명시된 요구 사항은 소프트웨어가 해결하고 만족시켜야 하는 이해 관계자의 문제, 필요 및 요구 사항 집합이다. 이러한 요구 사항은 소프트웨어 요구 사항 명세서(SRS)에 문서화되어 있다. 검증의 정의에 언급된 제품은 소프트웨어 개발 프로세스의 모든 단계의 출력 산출물이다. 이러한 제품은 아키텍처 설계 명세서, 상세 설계 명세서 등과 같은 명세서이다. SRS도 명세서이지만 (적어도 여기서 사용되는 의미에서는) 검증할 수 없다.

하지만 ISO 9000에서 명시된 요구 사항은 검증해야 하는 명세서 집합이다. 명세서는 다른 명세서를 입력으로 받는 소프트웨어 개발 프로세스 단계의 산출물이다. 명세서는 해당 입력 명세서를 올바르게 구현할 때 성공적으로 검증된다. SRS를 제외한 모든 명세서는 검증할 수 있다. SRS는 첫 번째 명세서이기 때문이다(하지만 유효성 검사는 가능하다). 예를 들어 설계 명세서는 SRS를 구현해야 하며, 구축 단계의 산출물은 설계 명세서를 구현해야 한다.

따라서 이러한 단어들을 일반적인 용어로 정의하면 명백한 모순이 사라진다.

SRS와 소프트웨어 모두 유효성 검사를 받아야 한다. SRS는 이해 관계자와의 상담을 통해 정적으로 유효성을 검사할 수 있다. 소프트웨어의 부분적인 구현 또는 어떤 종류의 프로토타입(동적 테스트)을 실행하고 긍정적인 피드백을 얻는 것은 SRS가 올바르게 작성되었는지에 대한 확신을 높일 수 있다. 반면에, 소프트웨어는 최종 실행 제품(소스 코드를 포함한 산출물 및 문서가 아닌)으로서, 소프트웨어를 실행하고 사용해 보도록 하여 이해 관계자와 동적으로 유효성 검사를 받아야 한다.

어떤 사람들은 SRS의 경우 입력이 이해 관계자의 말이며, 따라서 SRS 유효성 검사는 SRS 검증과 같다고 주장할 수 있지만, 이는 혼란만 더 일으키므로 권장하지 않는다. 검증은 공식적이고 기술적인 입력 문서를 포함하는 프로세스로 생각하는 것이 더 낫다.

소프트웨어 테스트의 목적은 다음과 같다.[78][79]

  • 작업 결과물의 평가를 통한 결함 방지 (예: 요구사항, 사용자 스토리, 설계, 코드)
  • 명확히 정의된 요구사항 충족 여부 검증
  • 완성 확인 및 동작의 타당성 확인 (사용자 등 이해관계자에 대한)
  • 테스트 대상의 품질에 대한 신뢰를 쌓아, 소정의 수준에 있음을 확증
  • 결함 발생 방지
  • 고장 및 결함 발견, 이를 통한 불충분한 소프트웨어 품질 리스크 수준 감소
  • 의사 결정에 필요한 정보 제공 (테스트 대상의 품질 수준 등)
  • 계약상, 법률상 또는 규제상의 요구 사항 및 표준 준수, 그리고/또는 준거 검증


사양대로 작동하는지, 시험 사양에 기초하여 확인하는 시험을 검증 시험(verification test)이라고 하고, 최종 사용자의 의도대로 작동하는지 확인하는 시험을 타당성 확인 시험(validation test)이라고 한다.

7. 2. 소프트웨어 품질 보증 (SQA)

소프트웨어 품질 보증(SQA)은 소프트웨어 개발 과정에서 만들어지는 문서, 코드, 시스템뿐만 아니라, 소프트웨어 공학 과정 자체를 검토하고 개선하는 활동을 포함한다.[3] SQA의 목표는 최종적으로 사용자에게 제공되는 소프트웨어의 결함 수를 줄이는 것이다. 허용되는 결함률은 소프트웨어의 특성에 따라 달라지는데, 예를 들어 비행 시뮬레이터 게임은 실제 비행기 소프트웨어보다 더 높은 결함 허용치를 가진다. SQA는 소프트웨어 테스팅과 밀접하게 관련되어 있지만, 테스팅 부서는 독립적으로 운영되는 경우가 많으며, 일부 회사에는 SQA 기능이 없을 수도 있다.

소프트웨어 테스팅은 품질 관련 정보를 이해 관계자에게 제공하기 위해 테스트 대상 소프트웨어를 조사하는 활동이다. 반면, 품질 보증(QA)은 결함이 고객에게 전달되는 것을 막기 위한 정책 및 절차를 실행하는 것이다.

7. 3. 측정

소프트웨어 테스팅은 테스트 대상 소프트웨어의 품질 관련 정보를 관계자에게 제공하기 위한 조사 활동이다.[3] 반면, QA(품질 보증)은 결함이 고객에게 전달되는 것을 방지하기 위한 정책 및 절차의 실행이다.

7. 4. 산출물

테스트 프로세스에서는 여러 개의 산출물이 생성될 수 있다. 실제 생성되는 산출물은 사용된 소프트웨어 개발 모델, 이해 관계자 및 조직의 요구 사항에 따라 달라진다.[2]

테스트 계획, 추적성 매트릭스, 테스트 케이스, 테스트 스크립트, 테스트 스위트, 테스트 픽스처 또는 테스트 데이터, 테스트 하네스, 테스트 실행 등이 생성될 수 있다.[2]

8. 논란

소프트웨어 테스팅에는 여러 논란이 존재한다. 애자일 방법론과 전통적인 개발 방법론 간의 테스팅 접근 방식 차이, 수동 테스트와 자동화 테스트의 효율성 비교, ISO 29119와 같은 소프트웨어 테스팅 표준의 실효성, 소프트웨어 테스팅 자격증의 필요성, 결함 수정 비용에 대한 다양한 연구와 그 적용 가능성에 대한 논쟁 등이 있다. 특히 결함 수정 비용에 대한 연구는 그 적용 가능성에 대해 상반된 견해가 존재한다.

9. 관련 도구


  • xUnit - 컴퓨터 프로그램의 단위 테스트 도구이다.
  • JUnit - Java 프로그램의 단위 테스트 도구이다.
  • TestNG - Java용 테스팅 프레임워크이다.
  • QualityForward - 복수 거점, 팀 단위의 테스트 관리·분석이 가능한 클라우드형 테스트 관리 도구이다.
  • Qangaroo - 웹상에서 Excel과 유사한 인터페이스를 가진 심플하고 직관적인 작업을 가능하게 하는 클라우드형 테스트 관리 도구이다.
  • TestLink - 오픈 소스 테스트 관리 시스템이다.
  • TESTRUCTURE - 테스트 설계 프로세스를 지원하는 테스트 설계 도구이다.
  • CAT - 테스트 설계 프로세스를 지원하는 테스트 설계 도구이다.

참조

[1] 간행물 Exploratory Testing https://kaner.com/pd[...] 2014-11-22
[2] coursework Software Testing http://www.ece.cmu.e[...] Carnegie Mellon University 2017-11-21
[3] 서적 Testing Computer Software John Wiley and Sons
[4] 간행물 Contract Driven Development = Test Driven Development – Writing Test Cases http://se.inf.ethz.c[...] 2017-12-08
[5] 서적 Automated Defect Prevention: Best Practices in Software Management http://www.wiley.com[...] Wiley-IEEE Computer Society Press
[6] 서적 Succeeding with Agile: Software Development Using Scrum Addison-Wesley Professional
[7] 서적 Crafting Test-Driven Software with Python: Write test suites that scale with your applications' needs and complexity using Python and PyTest Packt Publishing
[8] 서적 Testing JavaScript Applications Manning
[9] 웹사이트 The Economic Impacts of Inadequate Infrastructure for Software Testing https://www.nist.gov[...] National Institute of Standards and Technology 2017-12-19
[10] 서적 The Art of Software Testing https://archive.org/[...] John Wiley and Sons
[11] 간행물 IEEE Standard Glossary of Software Engineering Terminology IEEE 1990-01-01
[12] 웹사이트 Certified Tester Foundation Level Syllabus https://www.istqb.or[...] International Software Testing Qualifications Board 2017-12-15
[13] 웹사이트 Certified Tester Foundation Level Syllabus http://www.bcs.org/u[...] International Software Testing Qualifications Board 2017-12-15
[14] 간행물 Combinatorial Test Design in the TOSCA Testsuite: Lessons Learned and Practical Implications 2012-04-17
[15] 서적 Lessons Learned in Software Testing: A Context-Driven Approach https://archive.org/[...] Wiley
[16] 서적 Guide to the Software Engineering Body of Knowledge IEEE Computer Society 2018-01-02
[17] 서적 SWEBOK v3.0: Guide to the Software Engineering Body of Knowledge IEEE 2018-07-13
[18] 서적 Software Development and Professional Practice https://books.google[...] APress
[19] 서적 Creating a Software Engineering Culture https://books.google[...] Addison-Wesley
[20] 서적 Foundations of Software Testing https://books.google[...] Cengage Learning
[21] 서적 Verification and Validation in Scientific Computing https://books.google[...] Cambridge University Press
[22] 서적 Proceedings 1997 International Conference on Network Protocols IEEE Comput. Soc
[23] 학술지 Principles and methods of testing finite state machines-a survey https://doi.org/10.1[...] 1996-01-01
[24] 서적 In Testing Software and Systems: 23rd IFIP WG 6.1 International Conference, ICTSS 2011, Paris, France, November 7-10 Springer Berlin Heidelberg
[25] 서적 In 2014 IEEE 15th International Symposium on High-Assurance Systems Engineering https://doi.org/10.1[...] IEEE
[26] 서적 Software Testing https://books.google[...] Tata McGraw-Hill Education
[27] 서적 Software Engineering https://books.google[...] J. Ross Publishing
[28] 서적 Software Testing: Testing Across the Entire Software Development Life Cycle John Wiley & Sons
[29] 웹사이트 Code Coverage Analysis http://www.bullseye.[...] Bullseye Testing Technology 2017-11-21
[30] 서적 Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional https://books.google[...] John Wiley & Sons
[31] 문서
[32] 서적 Software Testing https://archive.org/[...] Sams Publishing
[33] 학위논문 The Theory and Practice of Specification Based Software Testing http://www.cs.le.ac.[...] Department of Computer Science, University of Sheffield 2018-01-02
[34] 학술지 Risk and Requirements-Based Testing http://www.satisfice[...] 2008-08-19
[35] 서적 Foundations of Software Testing https://books.google[...] Pearson Education India
[36] 서적 Software Quality Control, Error Analysis, and Testing https://books.google[...] William Andrew 2018-01-05
[37] 서적 Foundations of Software Testing https://books.google[...] Pearson Education India
[38] 간행물 Visual testing of software http://www.cs.hut.fi[...] Helsinki University of Technology 2012-01-13
[39] 간행물 Visual testing http://www.testmagaz[...] 2012-01-13
[40] 서적 Software Testing and Continuous Quality Improvement https://books.google[...] CRC Press
[41] 서적 Core Software Security: Security at the Source https://books.google[...] CRC Press
[42] white paper SOA Testing Tools for Black, White and Gray Box http://www.crosschec[...] Crosscheck Networks 2012-12-10
[43] 서적 Introduction to Software Testing https://books.google[...] Cambridge University Press
[44] 서적 Introduction to Software Testing https://books.google[...] Cambridge University Press 2017-11-29
[45] 서적 Testing Techniques in Software Engineering Springer Science & Business Media
[46] 서적 Software Quality Control, Error Analysis, and Testing https://books.google[...] Nova Data Corporation
[47] 웹사이트 ISTQB CTFL Syllabus 2018 https://istqb-main-w[...] 2022-04-11
[48] Whitepaper Operational Acceptance – an application of the ISO 29119 Software Testing standard https://www.scribd.c[...] Capgemini Australia 2018-01-09
[49] 웹사이트 Standard Glossary of Terms used in Software Testing https://www.astqb.or[...] International Software Testing Qualifications Board 2018-01-09
[50] 웹사이트 What is Web 2.0 http://www.oreilly.c[...] O'Reilly Media 2018-01-11
[51] 웹사이트 Part of the Pipeline: Why Continuous Testing Is Essential https://www.techwell[...] TechWell Corp. 2018-01-12
[52] 웹사이트 The Relationship between Risk and Continuous Testing: An Interview with Wayne Ariola http://www.stickymin[...] 2018-01-16
[53] 간행물 DevOps: Are You Pushing Bugs to Clients Faster? http://uploads.pnsqc[...] 2018-01-16
[54] 웹사이트 Shift Left and Put Quality First https://www.techwell[...] TechWell Corp. 2018-01-16
[55] 서적 ISO/IEC/IEEE 29119-1:2013 – Software and Systems Engineering – Software Testing – Part 1 – Concepts and Definitions https://www.iso.org/[...] International Organization for Standardization 2018-01-17
[56] 웹사이트 Globalization Step-by-Step: The World-Ready Approach to Testing. Microsoft Developer Network https://msdn.microso[...] Microsoft Developer Network 2012-01-13
[57] 간행물 Proceedings of the fifth ACM SIGPLAN international conference on Functional programming 2000
[58] 간행물 The growth of software testing 1988-06-01
[59] 서적 More Agile Testing Addison-Wesley Professional
[60] 웹사이트 Software Testing Lifecycle http://www.etestingh[...] 2012-01-13
[61] 서적 Effective Software Testing https://books.google[...] Addison-Wesley Professional
[62] 웹사이트 What is Test Driven Development (TDD)? https://www.agileall[...] 2018-03-17
[63] 웹사이트 Test-Driven Development and Continuous Integration for Mobile Applications https://msdn.microso[...] 2009-01-14
[64] 서적 Introduction to Rapid Software Testing http://www.informit.[...] 2002-04-12
[65] coursework Verification/Validation/Certification http://www.ece.cmu.e[...] Carnegie Mellon University 2008-08-13
[66] 서적 Software Testing and Continuous Quality Improvement https://books.google[...] CRC Press
[67] 서적 IEEE standard for software test documentation IEEE
[68] 웹사이트 We're All Part of the Story http://stpcollaborat[...] Software Test & Performance Collaborative 2009-07-01
[69] 서적 Agile Development Conference (ADC'05) ieee.org
[70] 간행물 Agile Software Development for an Agile Force http://www.stsc.hill[...] STSC 2004-04
[71] 서적 Software Test Automation Addison Wesley 1999
[72] 웹사이트 stop29119 http://commonsensete[...]
[73] 웹사이트 Software testers balk at ISO 29119 standards proposal http://www.infoworld[...] 2014-08-22
[74] 웹사이트 NSF grant proposal to 'lay a foundation for significant improvements in the quality of academic and commercial courses in software testing' http://www.testinged[...] 2006-10-13
[75] 간행물 Measuring the Effectiveness of Software Testers http://www.testinged[...] 2018-01-18
[76] 서적 Code Complete https://archive.org/[...] Microsoft Press
[77] 서적 The Leprechauns of Software Engineering: How folklore turns into fact and what to do about it leanpub 2013-11-20
[78] 문서 "1 テストの基礎" - "1.1 テストとは何か？" - "1.1.1 テストに共通する目的" http://jstqb.jp/syll[...] ISTQB
[79] 문서 1.1.1 Typical Objectives of Testing ISTQB FL Syllabus 2018v3-1
[80] 문서
[81] 문서 https://www.istqb.or[...]
[82] 웹사이트 POSIX Test Suite (POSIX 1990 version) http://www.itl.nist.[...] 2006-07-07
[83] 웹사이트 TTSP https://www.toppers.[...] 2014-08-08
[84] 서적 ソフトウェアテストの技法 近代科学社 1980
[85] 웹사이트 정보 시스템 용어 사전: 커버리지 기준 https://www.itmedia.[...] ITmedia 2016-04-17
[86] 문서 실천 아자일 테스트를 참조
[87] 웹인용 보관된 사본 http://www.bcs.org/u[...] 2008-01-26
[88] 서적 The Art of Software Testing John Wiley and Sons
[89] 저널 The Growth of Software Testing
[90] 저널 The Growth of Software Testing
[91] 저널 The Growth of Software Testing
[92] 저널 The Growth of Software Testing
[93] 저널 The Growth of Software Testing


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com