소프트웨어 테스트

Software testing
에 관한 시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원학문
관행
도구들
표준 및 지식 체계
용어집
개요

소프트웨어 테스트는 검증 및 검증을 통해 테스트 대상 소프트웨어의 인공물과 동작을 검사하는 행위입니다. 또한 소프트웨어 테스트를 통해 기업이 소프트웨어 구현의 위험을 이해하고 이해할 수 있도록 소프트웨어에 대한 객관적이고 독립적인 관점을 제공할 수 있습니다. 테스트 기술에는 다음이 포함되지만 이에 국한되지는 않습니다.

  • 업계 관점, 비즈니스 관점, 구현 가능성 및 실행 가능성, 사용성, 성능, 보안, 인프라 고려 사항 등 다양한 맥락에서 완전성 및 정확성에 대한 제품 요구 사항 분석
  • 제품 아키텍처 및 제품의 전체적인 디자인 검토
  • 경계 조건 등 다양한 기법을 기반으로 코드의 일부로 작성할 수 있는 코딩 기법, 디자인 패턴, 테스트 등의 개선에 대해 제품 개발자와 협력합니다.
  • 행동을 조사할 목적으로 프로그램 또는 응용 프로그램 실행
  • 배포 인프라 및 관련 스크립트 및 자동화 검토
  • 모니터링 및 관찰 기술을 사용하여 생산 활동에 참여합니다.

소프트웨어 테스트는 소프트웨어의 품질과 소프트웨어의 실패 위험에 대한 객관적이고 독립적인 정보를 사용자나 스폰서에게 제공할 수 있습니다.[1]

소프트웨어 테스트는 몇 가지 특정 가설을 가정하여 소프트웨어의 정확성을 판단할 수 있지만(아래 테스트 난이도 계층 참조), 테스트가 소프트웨어 내의 모든 고장을 식별할 수는 없습니다.[2] 대신 제품의 상태와 동작을 테스트 오라클(누군가가 문제를 인식할 수 있는 원리 또는 메커니즘)과 비교하는 비판 또는 비교를 제공합니다. 이러한 오라클에는 사양, 계약,[3] 비교 가능한 제품, 동일한 제품의 과거 버전, 의도되거나 예상되는 목적에 대한 추론, 사용자 또는 고객의 기대, 관련 표준, 적용 가능한 법률 또는 기타 기준이 포함될 수 있습니다.

테스트의 주요 목적은 소프트웨어 장애를 감지하여 결함을 발견하고 수정할 수 있도록 하는 것입니다. 테스트를 통해 제품이 모든 조건에서 제대로 작동하는지 확인할 수 없고 특정 조건에서 제대로 작동하지 않는다는 것만 확인할 수 있습니다.[4] 소프트웨어 테스트의 범위는 코드의 검사뿐만 아니라 다양한 환경과 조건에서 코드를 실행하는 것, 즉 코드가 해야 할 일을 하고 필요한 일을 하는 것을 포함할 수 있습니다. 현재 소프트웨어 개발 문화에서 테스트 조직은 개발 팀과 별개일 수 있습니다. 팀원 테스트를 위한 다양한 역할이 있습니다. 소프트웨어 테스트에서 파생된 정보는 소프트웨어가 개발되는 프로세스를 수정하는 데 사용될 수 있습니다.[5]: 41–43

모든 소프트웨어 제품에는 타겟 고객이 있습니다. 예를 들어, 비디오 게임 소프트웨어의 청중은 은행 소프트웨어의 청중과 완전히 다릅니다. 따라서 조직이 소프트웨어 제품을 개발하거나 투자할 때 최종 사용자, 대상 고객, 구매자 및 기타 이해 관계자가 소프트웨어 제품을 수용할 수 있는지 여부를 평가할 수 있습니다. 소프트웨어 테스트는 이러한 평가를 수행하는 데 도움이 됩니다.

고장과 고장

소프트웨어 오류는 다음 프로세스를 통해 발생합니다. 프로그래머가 오류(실수)를 범하면 소프트웨어 소스 코드에 오류(불량, 버그)가 발생합니다. 이 고장이 실행되면 특정 상황에서 시스템이 잘못된 결과를 생성하여 고장이 발생합니다.[6]: 31

모든 결함이 반드시 실패로 이어지는 것은 아닙니다. 예를 들어, 데드 코드의 결함은 결코 실패로 이어지지 않습니다. 고장이 드러나지 않은 고장은 환경이 바뀌었을 때 고장이 발생할 수 있습니다. 이러한 환경 변화의 예로는 새로운 컴퓨터 하드웨어 플랫폼에서 실행되는 소프트웨어, 소스 데이터의 변경 또는 다양한 소프트웨어와의 상호 작용이 있습니다.[7] 하나의 결함으로 인해 광범위한 고장 증상이 나타날 수 있습니다.

모든 소프트웨어 오류가 코딩 오류로 인해 발생하는 것은 아닙니다. 비용이 많이 드는 결함의 한 가지 일반적인 원인은 요구 사항 격차, 즉 프로그램 설계자의 누락 오류를 초래하는 인식되지 않은 요구 사항입니다.[5]: 426 요구사항 격차는 종종 테스트 가능성, 확장성, 유지보수 가능성, 성능 및 보안과 같은 비기능적 요구사항일 수 있습니다.

입력 조합 및 전제 조건

소프트웨어 테스트의 근본적인 문제는 단순한 제품을 사용하더라도 입력 및 전제 조건(초기 상태)의 모든 조합에서 테스트가 가능하지 않다는 것입니다.[4]: 17–18 [8] 이는 소프트웨어 제품의 결함 수가 매우 많을 수 있으며 드물게 발생하는 결함은 테스트 및 디버깅에서 찾기 어렵다는 것을 의미합니다. 더욱 중요한 것은 품질의 비기능적 차원(사용성, 확장성, 성능, 호환성 및 신뢰성)은 매우 주관적일 수 있으며, 한 사람에게 충분한 가치를 구성하는 것은 다른 사람에게 견딜 수 없는 것일 수 있습니다.

소프트웨어 개발자는 모든 것을 테스트할 수는 없지만 조합 테스트 설계를 사용하여 원하는 커버리지를 얻기 위해 필요한 최소 테스트 수를 식별할 수 있습니다. 조합 테스트 설계를 통해 사용자는 더 적은 테스트로 더 많은 테스트 적용 범위를 얻을 수 있습니다. 속도 또는 테스트 깊이를 원하는 경우 조합 테스트 설계 방법을 사용하여 테스트 사례에 구조적인 변형을 구축할 수 있습니다.[9]

경제학

2002년 NIST가 실시한 연구에 따르면 소프트웨어 버그로 인해 미국 경제에 연간 595억 달러의 손실이 발생한다고 합니다. 소프트웨어 테스트를 더 잘 수행하면 이 비용의 3분의 1 이상을 피할 수 있습니다.[10][dubious – discuss]

비용 때문에 소프트웨어 테스트를 아웃소싱하는 것은 매우 일반적이며, 중국, 필리핀, 인도가 선호하는 대상입니다.[11]

역할

소프트웨어 테스트는 전담 소프트웨어 테스터가 수행할 수 있습니다. 1980년대까지는 일반적으로 "소프트웨어 테스터"라는 용어가 사용되었지만 나중에는 별도의 직업으로 간주되기도 했습니다. 소프트웨어 테스트의 기간 및 다양한 목표와 [12]관련하여 테스트 관리자, 테스트 리드, 테스트 분석가, 테스트 설계자, 테스터, 자동화 개발자 및 테스트 관리자와 같은 다양한 역할이 설정되었습니다. 소프트웨어 테스트는 전용이 아닌 소프트웨어 테스터도 수행할 수 있습니다.[13]

역사

Glenford J. Myers는 1979년에 디버깅과 테스트의 분리를 처음 도입했습니다.[14] 비록 그의 관심은 파손 테스트("성공적인 테스트 케이스는 아직 발견되지 않은 오류를 감지하는 케이스")[14]: 16 에 집중했지만, 이는 디버깅과 같은 근본적인 개발 활동을 검증 활동과 분리하려는 소프트웨어 엔지니어링 커뮤니티의 열망을 보여주었습니다.

시험방법

정적, 동적 및 수동 테스트

소프트웨어 테스트에서 사용할 수 있는 많은 접근 방식이 있습니다. 검토, 워크스루 또는 검사를 정적 테스트라고 하며, 주어진 테스트 케이스 세트로 프로그래밍된 코드를 실행하는 것을 동적 테스트라고 합니다.[15][16]

정적 테스트는 종종 교정과 같이 암시적이며 프로그래밍 도구/텍스트 편집기가 소스 코드 구조를 확인하거나 컴파일러(사전 컴파일러)가 구문 및 데이터 흐름을 정적 프로그램 분석으로 확인할 때 추가됩니다. 동적 테스트는 프로그램 자체가 실행될 때 이루어집니다. 동적 테스트는 코드의 특정 섹션을 테스트하기 위해 프로그램이 100% 완료되기 전에 시작되어 이산 기능 또는 모듈에 적용될 수 있습니다.[15][16] 이에 대한 일반적인 기술은 스터브/드라이버를 사용하거나 디버거 환경에서 실행하는 것입니다.[16]

정적 테스트에는 검증이 포함되지만 동적 테스트에는 검증도 포함됩니다.[16]

패시브 테스트는 소프트웨어 제품과의 상호 작용 없이 시스템 동작을 검증하는 것을 의미합니다. 능동 테스트와 달리 테스터는 테스트 데이터를 제공하지 않고 시스템 로그와 트레이스를 살펴봅니다. 그들은 일종의 결정을 내리기 위해 패턴과 특정 행동을 마이닝합니다.[17] 이는 오프라인 런타임 검증 및 로그 분석과 관련이 있습니다.

탐색적 접근

이 섹션은 탐색적 테스트에서 발췌한 내용입니다.[편집]
탐색적 테스트는 동시 학습, 테스트 설계 및 테스트 실행으로 간결하게 설명되는 소프트웨어 테스트에 대한 접근 방식입니다. 1984년 이 용어를 만든 쳄 카너([18]Cem Kaner)는 탐색적 테스트를 "테스트 관련 학습, 테스트 설계, 테스트 실행을 다루면서 지속적으로 자신의 작업의 품질을 최적화하기 위해 개별 테스터의 개인적 자유와 책임을 강조하는 소프트웨어 테스트 스타일"이라고 정의합니다. 그리고 결과 해석을 프로젝트 전반에 걸쳐 병렬적으로 실행되는 상호 지원 활동으로 테스트합니다."[19]

사전 설정 테스트 대 적응 테스트

수행할 테스트 전략의 유형은 테스트 계획이 실행되기 시작하기 전에 IUT에 적용할 테스트를 결정해야 하는지(사전 설정 테스트[20]) 또는 IUT에 적용할 각 입력이 이전 테스트를 적용하는 동안 얻은 출력에 동적으로 의존할 수 있는지(적응 테스트[21][22])에 따라 달라집니다.

"박스" 접근법

소프트웨어 테스트 방법은 전통적으로 화이트와 블랙박스 테스트로 나뉩니다. 이 두 가지 접근 방식은 테스트 사례를 설계할 때 테스트자가 취하는 관점을 설명하는 데 사용됩니다. 그레이박스 테스트라는 하이브리드 접근 방식은 소프트웨어 테스트 방법론에도 적용될 수 있습니다.[23][24] 특정 디자인 요소에서 테스트를 개발하는 그레이박스 테스트(Grey-box testing)라는 개념이 부각되면서 블랙박스와 화이트박스 테스트 간의 이러한 "임의적인 구분"은 다소 희미해졌습니다.[25]

화이트박스 테스트

주요 기사: 화이트박스 테스트
White Box Testing Diagram
화이트 박스 테스트 다이어그램

화이트박스 테스트(클리어 박스 테스트, 유리 박스 테스트, 투명 박스 테스트, 구조 테스트라고도 함)는 최종 사용자에게 노출되는 기능과 달리 프로그램의 내부 구조 또는 작동을 확인합니다. 화이트박스 테스트에서는 시스템의 내부 관점(소스 코드)과 프로그래밍 기술을 사용하여 테스트 사례를 설계합니다. 테스터는 코드를 통해 경로를 연습할 입력을 선택하고 적절한 출력을 결정합니다.[23][24] 이는 회로 내 노드를 테스트하는 것과 유사합니다. 예를 들어, 회로 내 테스트(ICT).

화이트박스 테스트는 소프트웨어 테스트 프로세스의 단위, 통합 및 시스템 수준에서 적용할 수 있지만 일반적으로 단위 수준에서 수행됩니다.[25] 단위 내 경로, 통합 중 단위 간 경로, 시스템 수준 테스트 중 하위 시스템 간 경로를 테스트할 수 있습니다. 이러한 테스트 설계 방법은 많은 오류나 문제를 발견할 수 있지만 사양의 구현되지 않은 부분이나 누락된 요구 사항을 감지하지 못할 수 있습니다.

화이트박스 테스트에 사용되는 기술은 다음과 같습니다.[24][26]

  • API 테스트 – 공용 및 사설 API(응용 프로그래밍 인터페이스)를 사용한 애플리케이션 테스트
  • 코드 적용 범위 – 코드 적용 범위의 일부 기준을 만족시키기 위한 테스트 생성(예: 테스트 설계자는 프로그램의 모든 문이 적어도 한 번 실행되도록 테스트를 생성할 수 있음)
  • 고장 주입 방법 – 의도적으로 고장을 도입하여 테스트 전략의 효과를 측정합니다.
  • 변이시험방법
  • 정적시험방법

코드 적용 도구는 블랙박스 테스트를 포함한 모든 방법으로 생성된 테스트 제품군의 완전성을 평가할 수 있습니다. 이를 통해 소프트웨어 팀은 거의 테스트되지 않은 시스템의 일부를 검사하고 가장 중요한 기능 지점이 테스트되었는지 확인할 수 있습니다.[27] 소프트웨어 메트릭으로서의 코드 적용 범위는 다음에 대한 백분율로 보고될 수 있습니다.[23][27][28]

  • 기능 적용 범위, 실행된 기능을 보고합니다.
  • 테스트를 완료하기 위해 실행된 행 수를 보고하는 문 적용 범위
  • 특정 테스트의 True 및 False 분기가 모두 실행되었는지 여부를 보고하는 의사 결정 범위

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

블랙박스 테스트

본문: 블랙박스 테스트
블랙박스 다이어그램

블랙박스 테스트(기능 테스트라고도 함)는 소프트웨어를 "블랙박스"로 취급하여 내부 구현에 대한 지식 없이 소스 코드를 보지 않고 기능을 검사합니다. 테스터는 소프트웨어가 무엇을 해야 하는지만 알고 있을 뿐, 어떻게 해야 하는지는 알지 못합니다.[30] 블랙박스 테스트 방법에는 동등성 분할, 경계값 분석, 전체 쌍 테스트, 상태 전환 테이블, 의사 결정 테이블 테스트, 퍼지 테스트, 모델 기반 테스트, 사용 사례 테스트, 탐색 테스트 및 사양 기반 테스트가 포함됩니다.[23][24][28]

사양 기반 테스트는 해당 요구 사항에 따라 소프트웨어의 기능을 테스트하는 것을 목표로 합니다.[31] 이 수준의 테스트는 일반적으로 철저한 테스트 사례를 테스터에게 제공해야 하며, 테스터는 주어진 입력에 대한 출력 값(또는 동작)이 테스트 사례에 지정된 기대 값과 "같음" 또는 "아니오"인지 간단히 확인할 수 있습니다. 테스트 케이스는 사양 및 요구 사항, 즉 애플리케이션이 수행해야 할 작업을 중심으로 구축됩니다. 사양, 요구 사항 및 설계를 포함한 소프트웨어의 외부 설명을 사용하여 테스트 사례를 도출합니다. 이러한 테스트는 일반적으로 작동하지만 기능적이거나 비기능적일 수 있습니다.

올바른 기능을 보장하기 위해서는 사양 기반 테스트가 필요할 수 있지만 복잡하거나 위험이 높은 상황을 보호하기에는 부족합니다.[32]

블랙박스 기술의 한 가지 장점은 프로그래밍 지식이 필요 없다는 것입니다. 프로그래머들이 어떤 편향을 가지고 있었든 간에, 테스터는 다른 세트를 가지고 있을 가능성이 높으며, 다양한 기능 영역을 강조할 수 있습니다. 반면 블랙박스 테스트는 '손전등 없이 어두운 미로를 걷는 것과 같다'는 평가를 받아왔습니다.[33] 소스 코드를 검사하지 않기 때문에 검사자가 하나의 테스트 케이스만으로 테스트할 수 있었던 것을 확인하기 위해 많은 테스트 케이스를 작성하거나 프로그램의 일부 부분을 테스트하지 않은 상태로 두는 경우가 있습니다.

이 테스트 방법은 유닛, 통합, 시스템 및 수락과 같은 모든 수준의 소프트웨어 테스트에 적용할 수 있습니다.[25] 일반적으로 모든 테스트가 상위 레벨의 테스트는 아닐지라도 대부분의 테스트로 구성되지만 단위 테스트도 지배할 수 있습니다.

구성요소 인터페이스 테스트

구성 요소 인터페이스 테스트는 하위 시스템 구성 요소의 관련 작업을 넘어 데이터 값에 초점을 맞추는 블랙박스 테스트의 변형입니다.[34] 구성 요소 인터페이스 테스트 실무는 다양한 구성 요소 간에 전달되는 데이터 또는 하위 시스템 구성 요소 간의 완전한 통합 테스트를 넘어 해당 구성 요소 간에 전달되는 데이터의 처리를 확인하는 데 사용될 수 있습니다.[35][36] 전달되는 데이터는 "메시지 패킷"으로 간주할 수 있으며 범위 또는 데이터 유형을 확인하고 한 유닛에서 생성된 데이터를 확인한 후 다른 유닛으로 전달하기 전에 유효성을 테스트할 수 있습니다. 인터페이스 테스트를 위한 한 가지 옵션은 전달되는 데이터 항목에 대한 별도의 로그 파일을 유지하는 것이며, 종종 타임스탬프가 기록되어 며칠 또는 몇 주 동안 유닛 간에 전달되는 수천 개의 데이터 사례를 분석할 수 있습니다. 검정에는 다른 인터페이스 변수가 정규 값으로 통과되는 동안 일부 극단적인 데이터 값의 처리를 확인하는 것이 포함될 수 있습니다.[35] 인터페이스의 비정상적인 데이터 값은 다음 장치에서 예상치 못한 성능을 설명하는 데 도움이 될 수 있습니다.

시각적 테스트

시각적 테스트의 목적은 개발자가 필요로 하는 정보를 쉽게 찾을 수 있고 정보가 명확하게 표현되는 방식으로 데이터를 제시함으로써 소프트웨어 장애 시점에서 무슨 일이 일어나고 있었는지 검토할 수 있는 능력을 개발자에게 제공하는 것입니다.[37][38]

시각적 테스트의 핵심은 누군가에게 문제(또는 테스트 실패)를 보여주는 것이 아니라 명확성과 이해를 크게 높인다는 생각입니다. 따라서 시각적 테스트를 수행하려면 테스트 시스템에서 발생하는 모든 것을 비디오 형식으로 캡처하여 전체 테스트 프로세스를 녹화해야 합니다. 출력 비디오는 사진 속 웹캠을 통한 실시간 테스터 입력과 마이크의 오디오 해설로 보완됩니다.

시각적 테스트는 여러 가지 장점을 제공합니다. 테스터가 문제(및 그로 인한 이벤트)를 단순히 설명하는 것이 아니라 개발자에게 보여줄 수 있기 때문에 의사소통의 품질이 급격히 향상되고 많은 경우 테스트 실패를 복제할 필요성이 사라집니다. 개발자는 테스트 실패에 대해 필요한 모든 증거를 확보하고 대신 결함의 원인과 해결 방법에 초점을 맞출 수 있습니다.

임시 테스트와 탐색 테스트는 소프트웨어 무결성을 검사하는 데 중요한 방법론입니다. 구현하는 데 필요한 준비 시간이 적은 반면 중요한 버그는 빠르게 찾을 수 있기 때문입니다.[39] 테스트가 즉흥적이고 즉흥적인 방식으로 이루어지는 임시 테스트에서 테스트자가 문서화된 방법을 기반으로 테스트를 수행한 다음 이러한 테스트의 변형을 즉흥적으로 수행하는 능력은 결함 수정을 보다 엄격하게 검사하는 결과를 초래할 수 있습니다.[39] 그러나 절차에 대한 엄격한 문서화가 유지되지 않는 한 임시 테스트의 한계 중 하나는 반복성이 부족하다는 것입니다.[39]

추가 정보: 그래픽 사용자 인터페이스 테스트

그레이박스 테스트

주요 기사: 그레이박스 테스트

그레이박스 테스트(미국식 철자: 그레이박스 테스트)는 사용자 또는 블랙박스 수준에서 테스트를 실행하면서 테스트를 설계하기 위한 목적으로 내부 데이터 구조와 알고리즘에 대한 지식을 갖추는 것을 포함합니다. 테스터는 종종 "소스 코드와 실행 가능한 바이너리" 모두에 액세스할 수 있습니다.[40] 그레이박스 테스트에는 예를 들어 경계값 또는 오류 메시지를 결정하기 위한 역공학(동적 코드 분석 사용)도 포함될 수 있습니다.[40] 입력 데이터를 조작하고 출력을 포맷하는 것은 그레이박스에 해당하지 않습니다. 입력과 출력이 테스트 대상 시스템이라고 부르는 "블랙박스"의 외부에 분명히 있기 때문입니다. 이러한 구분은 두 명의 다른 개발자가 작성한 두 개의 코드 모듈 간의 통합 테스트를 수행할 때 특히 중요하며, 테스트를 위해 인터페이스만 노출됩니다.

소프트웨어가 어떻게 작동하는지에 대한 기본 개념을 알고 있기 때문에 테스터는 외부에서 소프트웨어를 테스트하면서 더 나은 정보에 입각한 테스트 선택을 합니다. 일반적으로 그레이박스 테스터는 데이터베이스 시드와 같은 활동으로 격리된 테스트 환경을 설정할 수 있습니다. 테스터는 데이터베이스에 대해 SQL 문을 실행한 다음 쿼리를 실행하여 예상되는 변경 사항이 반영되었는지 확인하는 등의 특정 작업을 수행한 후 테스트 중인 제품의 상태를 관찰할 수 있습니다. 그레이박스 테스트는 제한된 정보를 기반으로 지능적인 테스트 시나리오를 구현합니다. 이는 특히 데이터 유형 처리, 예외 처리 등에 적용됩니다.[41]

시험수준

일반적으로 단위 테스트, 통합 테스트 및 시스템 테스트의 세 가지 수준이 있습니다.[42][43][44][45] 그러나 네 번째 수준인 허용 테스트는 개발자에 의해 포함될 수 있습니다. 이는 운영 수락 테스트의 형태일 수도 있고 소프트웨어가 기능적 기대를 충족하는지 확인하기 위한 테스트인 단순한 최종 사용자(베타) 테스트일 수도 있습니다.[46][47][48] ISTQB Certified Test Foundation Level 강의 계획서를 기반으로 테스트 레벨에는 해당 4개 레벨이 포함되며, 네 번째 레벨은 합격 테스트로 명명됩니다.[49] 테스트는 소프트웨어 개발 프로세스에서 추가되는 위치 또는 테스트의 특수성 수준에 따라 이러한 수준 중 하나로 그룹화되는 경우가 많습니다.

단위시험

주요 기사: 단위시험

단위 테스트는 일반적으로 기능 수준에서 특정 코드 섹션의 기능을 확인하는 테스트를 말합니다. 객체 지향 환경에서는 일반적으로 클래스 수준이며 최소 단위 테스트에는 생성자와 생성자가 포함됩니다.[50]

이러한 유형의 테스트는 일반적으로 특정 기능이 예상대로 작동하는지 확인하기 위해 개발자가 코드(화이트 박스 스타일)에서 작업할 때 작성합니다. 하나의 함수에는 여러 개의 테스트가 있을 수 있습니다. 코드의 코너 케이스나 다른 분기를 탐지할 수 있습니다. 단위 테스트만으로는 소프트웨어의 기능을 확인할 수 없으며 소프트웨어의 구성 요소가 서로 독립적으로 작동하는지 확인하는 데 사용됩니다.

단위 테스트는 소프트웨어 개발 위험, 시간 및 비용을 줄이기 위해 광범위한 결함 예방 및 탐지 전략을 동기화하여 적용하는 소프트웨어 개발 프로세스입니다. 소프트웨어 개발 수명 주기의 구축 단계에서 소프트웨어 개발자 또는 엔지니어에 의해 수행됩니다. 단위 테스트는 코드가 추가 테스트로 승격되기 전에 구성 오류를 제거하는 것을 목표로 합니다. 이 전략은 전체 개발 프로세스의 효율성뿐만 아니라 결과 소프트웨어의 품질을 향상시키기 위한 것입니다.

소프트웨어 개발에 대한 조직의 기대에 따라 유닛 테스트에는 정적 코드 분석, 데이터 흐름 분석, 메트릭 분석, 동료 코드 검토, 코드 적용 범위 분석 및 기타 소프트웨어 테스트 방법이 포함될 수 있습니다.

통합시험

주요 기사: 통합시험

통합 테스트는 소프트웨어 설계에 대해 구성 요소 간의 인터페이스를 확인하려는 모든 유형의 소프트웨어 테스트입니다. 소프트웨어 구성 요소는 반복적인 방식으로 또는 모두 함께 통합될 수 있습니다("빅뱅"). 일반적으로 전자는 인터페이스 문제를 보다 신속하게 찾고 해결할 수 있기 때문에 더 나은 방법으로 간주됩니다.

통합 테스트는 인터페이스의 결함과 통합 구성 요소(모듈) 간의 상호 작용을 노출하는 데 사용됩니다. 아키텍처 설계의 요소에 해당하는 테스트된 소프트웨어 구성 요소 그룹은 소프트웨어가 시스템으로 작동할 때까지 통합되고 테스트됩니다.[51]

시스템 테스트

주요 기사: 시스템 테스트

시스템 테스트는 완전히 통합된 시스템을 테스트하여 시스템이 요구 사항을 충족하는지 확인합니다.[6]: 74 예를 들어, 시스템 테스트는 로그인 인터페이스를 테스트한 다음 항목을 만들고 편집하며 결과를 보내거나 인쇄한 다음 항목을 요약 처리하거나 삭제(또는 보관)한 다음 로그오프하는 것을 포함할 수 있습니다.

합격시험

주요 기사: 합격시험

합격 테스트에는 일반적으로 다음 네 가지 유형이 포함됩니다.[49]

  • UAT(사용자 수용성 테스트)
  • 운영수용시험(OAT)
  • 계약 및 규정 수용도 테스트
  • 알파 및 베타 테스트

UAT뿐만 아니라 알파 및 베타 테스트는 다음 테스트 유형 섹션에 설명되어 있습니다.

운영 수락은 품질 관리 시스템의 일부로서 제품, 서비스 또는 시스템의 운영 준비(사전 릴리스)를 수행하는 데 사용됩니다. OAT는 주로 소프트웨어 개발 및 소프트웨어 유지보수 프로젝트에 사용되는 일반적인 유형의 비기능 소프트웨어 테스트입니다. 이러한 유형의 테스트는 지원되는 시스템의 운영 준비 상태 또는 운영 환경의 일부가 되는 것에 중점을 둡니다. 따라서 운영 준비 테스트(ORT) 또는 운영 준비 및 보장 테스트(OR&A)라고도 합니다. OAT 내의 기능 테스트는 시스템의 비기능적인 측면을 확인하기 위해 필요한 테스트로 제한됩니다.

또한 소프트웨어 테스트를 통해 시스템의 휴대성은 물론 예상대로 작동할 수 있으므로 운영 환경이 손상되거나 부분적으로 손상되거나 해당 환경 내의 다른 프로세스가 작동하지 않도록 해야 합니다.[52]

계약 수락 테스트는 계약 합의 시 정의된 계약 수락 기준을 기반으로 수행되며, 규제 수락 테스트는 소프트웨어 제품에 대한 관련 규정을 기반으로 수행됩니다. 이 두 가지 테스트는 모두 사용자 또는 독립적인 테스트자가 수행할 수 있습니다. 규제 승인 테스트에는 때때로 규제 기관이 테스트 결과를 감사하는 것이 포함됩니다.[49]

시험 유형, 기법 및 전술

서로 다른 레이블과 그룹화 테스트 방법은 테스트 유형, 소프트웨어 테스트 전술 또는 기술일 수 있습니다.[53]

테스팅 컵 - 폴란드 소프트웨어 테스팅 챔피언십, 카토비체, 2016년 5월

설치 테스트

이 섹션은 설치 테스트에서 발췌한 내용입니다.[편집]

대부분의 소프트웨어 시스템에는 주요 목적으로 사용하기 전에 필요한 설치 절차가 있습니다. 이러한 절차를 테스트하여 사용할 수 있는 설치된 소프트웨어 시스템을 달성하는 것을 설치 테스트라고 합니다.[54]: 139 이러한 절차에는 전체 또는 부분 업그레이드 및 설치/제거 프로세스가 포함될 수 있습니다.

  • 사용자는 다양한 옵션을 선택해야 합니다.
  • 종속 파일 및 라이브러리를 할당, 로드 또는 위치해야 합니다.
  • 올바른 하드웨어 구성이 있어야 합니다.
  • 소프트웨어 시스템은 다른 소프트웨어 시스템에 연결하기 위해 연결이 필요할 수 있습니다.[54]: 145

호환성 테스트

주요 기사: 호환성 테스트

소프트웨어 장애(실제 또는 인식)의 일반적인 원인은 다른 애플리케이션 소프트웨어, 운영 체제(또는 운영 체제 버전, 구 버전 또는 새 버전)와의 호환성 부족입니다. 또는 원래와 크게 다른 대상 환경(예: 데스크톱에서 실행되도록 의도된 단말기 또는 GUI 애플리케이션이 웹 브라우저에서 렌더링해야 하는 웹 애플리케이션이 되는 경우). 예를 들어 하위 호환성이 부족한 경우 프로그래머가 대상 환경의 최신 버전에서만 소프트웨어를 개발하고 테스트하기 때문에 이러한 현상이 발생할 수 있으며, 모든 사용자가 실행 중인 것은 아닙니다. 이로 인해 최신 작업이 대상 환경의 이전 버전 또는 대상 환경의 이전 버전이 사용할 수 있었던 이전 하드웨어에서 작동하지 않을 수 있다는 의도하지 않은 결과가 발생합니다. 때로는 운영 체제 기능을 별도의 프로그램 모듈이나 라이브러리로 사전에 추상화하여 이러한 문제를 해결할 수 있습니다.

매연 및 위생 시험

주요 기사: 매연시험(소프트웨어)

건전성 검사는 추가 검사를 진행하는 것이 타당한지 여부를 결정합니다.

연기 테스트는 소프트웨어가 작동하지 않도록 하는 기본적인 문제가 있는지 여부를 판단하기 위해 설계된 소프트웨어를 작동하기 위한 최소한의 시도로 구성됩니다. 이러한 테스트는 빌드 검증 테스트로 사용할 수 있습니다.

회귀 검정

본문: 회귀 검정

회귀 테스트는 주요 코드 변경이 발생한 후 결함을 찾는 데 중점을 둡니다. 구체적으로 소프트웨어 회귀 현상을 성능 저하 또는 손실된 기능으로 파악하고자 하며, 여기에는 오래된 버그도 포함됩니다. 이러한 회귀는 이전에 올바르게 작동하던 소프트웨어 기능이 의도한 대로 작동하지 않을 때마다 발생합니다. 일반적으로 소프트웨어의 새로 개발된 부분이 이전 코드와 충돌할 때 프로그램 변경으로 인해 의도하지 않은 결과로 회귀가 발생합니다. 회귀 테스트는 일반적으로 이전 소프트웨어 기능의 수많은 세부 사항을 확인하기 때문에 [55]상용 소프트웨어 개발에서 가장 큰 테스트 노력이며, 일부 오래된 테스트 사례를 사용하여 새로운 설계의 부품을 테스트하면서 새로운 소프트웨어를 개발하여 이전 기능이 여전히 지원되는지 확인할 수 있습니다.

회귀 테스트의 일반적인 방법에는 이전 테스트 사례 세트를 다시 실행하는 것과 이전에 고정된 오류가 다시 발생했는지 여부를 확인하는 것이 포함됩니다. 테스트의 깊이는 릴리스 프로세스의 단계와 추가된 기능의 위험에 따라 달라집니다. 변경 사항이 릴리스 초기이거나 위험성이 낮다고 판단되는 경우, 릴리스 후반에 추가된 변경 사항이나 위험성이 있다고 판단되는 변경 사항의 경우, 또는 각 기능에 대한 양성 테스트로 구성된 매우 얕은 변경 사항일 수 있습니다.

합격시험

주요 기사: 합격시험

합격 테스트는 다음 두 가지 중 하나를 의미할 수 있습니다.

  1. 연기 테스트는 추가 테스트 전, 예를 들어 통합 또는 회귀 전에 빌드 승인 테스트로 사용됩니다.
  2. 고객이 자체 하드웨어로 실험실 환경에서 수행하는 수락 테스트를 사용자 수락 테스트(UAT)라고 합니다. 승인 테스트는 두 단계의 개발 간의 핸드오프 프로세스의 일부로 수행할 수 있습니다.[citation needed]

알파 테스트

알파 테스트는 잠재적 사용자/고객 또는 개발자 사이트의 독립적인 테스트 팀에 의해 모의 또는 실제 운영 테스트를 수행합니다. 알파 테스트는 종종 소프트웨어가 베타 테스트에 들어가기 전에 내부 승인 테스트의 한 형태로 기성 소프트웨어에 사용됩니다.[56]

베타 테스트

참고 항목: 소프트웨어 릴리스 수명 주기 § 베타

베타 테스트는 알파 테스트 후에 이루어지며 외부 사용자 허용 테스트의 한 형태로 간주될 수 있습니다. 베타 버전으로 알려진 소프트웨어의 버전은 베타 테스터로 알려진 프로그래밍 팀 외부의 제한된 청중에게 공개됩니다. 소프트웨어는 추가 테스트를 통해 제품에 결함이나 버그가 거의 없는지 확인할 수 있도록 여러 사람에게 배포됩니다. 베타 버전을 공개하여 피드백 필드를 최대 수의 미래 사용자에게 제공하고 더 일찍 가치를 제공할 수 있습니다(영구 베타).[57]

기능 테스트 대 비기능 테스트

기능 테스트는 코드의 특정 동작이나 기능을 확인하는 활동을 말합니다. 일부 개발 방법론은 사용 사례 또는 사용자 스토리에서 작동하지만 일반적으로 코드 요구 사항 설명서에서 이를 찾을 수 있습니다. 기능 테스트는 "사용자가 이것을 할 수 있습니까?" 또는 "특정 기능이 작동합니까?"라는 질문에 답하는 경향이 있습니다.

비기능 테스트는 확장성 또는 기타 성능, 특정 제약 조건 하에서의 동작 또는 보안과 같은 특정 기능 또는 사용자 조치와 관련이 없을 수 있는 소프트웨어의 측면을 나타냅니다. 테스트를 통해 극단적인 확장성 또는 성능이 불안정한 실행으로 이어지는 중단점이 결정됩니다. 비기능적 요구사항은 특히 사용자의 적합성 관점에서 제품의 품질을 반영하는 요구사항인 경향이 있습니다.

지속적인 테스트

주요 기사: 지속적인 테스트

지속적인 테스트는 소프트웨어 릴리스 후보와 관련된 비즈니스 위험에 대한 즉각적인 피드백을 얻기 위해 소프트웨어 전송 파이프라인의 일부로 자동화된 테스트를 실행하는 프로세스입니다.[58][59] 지속적인 테스트에는 기능적 요구 사항과 비기능적 요구 사항 모두에 대한 검증이 포함됩니다. 테스트의 범위는 상향식 요구 사항 또는 사용자 스토리를 검증하는 것에서 전체적인 비즈니스 목표와 관련된 시스템 요구 사항을 평가하는 것까지 확장됩니다.[60][61]

파괴시험

주요 기사: 파괴시험

파괴 테스트는 소프트웨어 또는 하위 시스템의 고장을 유발하려고 시도합니다. 소프트웨어가 잘못되거나 예상치 못한 입력을 받았을 때도 제대로 작동하는지 확인하여 입력 검증 및 오류 관리 루틴의 견고성을 확립합니다.[citation needed] 퍼징(fuzzing) 형태의 소프트웨어 결함 주입은 고장 테스트의 한 예입니다. 소프트웨어 장애 주입 페이지에서 다양한 상용 비기능 테스트 도구가 연결되어 있으며, 파괴 테스트를 수행하는 수많은 오픈 소스 및 무료 소프트웨어 도구도 있습니다.

추가 정보: 예외 처리 및 복구 테스트

소프트웨어 성능 테스트

주요 기사: 소프트웨어 성능 테스트

성능 테스트는 일반적으로 시스템 또는 하위 시스템이 특정 워크로드 하에서 응답성 및 안정성 측면에서 어떻게 수행되는지를 결정하기 위해 실행됩니다. 또한 확장성, 신뢰성 및 리소스 사용과 같은 시스템의 다른 품질 속성을 조사, 측정, 검증 또는 검증하는 역할을 할 수 있습니다.

부하 테스트는 주로 시스템이 많은 양의 데이터든 많은 사용자든 특정 부하 하에서 계속 작동할 수 있는지 테스트하는 것과 관련이 있습니다. 이를 일반적으로 소프트웨어 확장성이라고 합니다. 비기능적 활동으로 수행되는 경우의 관련 하중 테스트 활동을 내구성 테스트라고 합니다. 볼륨 테스트는 특정 구성 요소(예: 파일 또는 데이터베이스)의 크기가 급격히 증가하는 경우에도 소프트웨어 기능을 테스트하는 방법입니다. 스트레스 테스트는 예상치 못한 또는 드문 워크로드에서 신뢰성을 테스트하는 방법입니다. 안정성 테스트(흔히 부하 또는 내구성 테스트라고 함)는 소프트웨어가 허용 가능한 기간 내 또는 그 이상으로 지속적으로 잘 작동할 수 있는지 확인합니다.

성능 테스트의 구체적인 목표가 무엇인지에 대해서는 거의 일치하지 않습니다. 부하 테스트, 성능 테스트, 확장성 테스트 및 볼륨 테스트라는 용어는 종종 서로 교환하여 사용됩니다.

실시간 소프트웨어 시스템에는 엄격한 타이밍 제약이 있습니다. 타이밍 제약 조건이 충족되는지 여부를 테스트하기 위해 실시간 테스트를 사용합니다.

사용성 시험

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

접근성 테스트

접근성 테스트는 장애인이 소프트웨어에 접근할 수 있는지 확인하기 위해 수행됩니다. 일반적인 웹 접근성 테스트 중 일부는 다음과 같습니다.

  • 글꼴과 배경색의 색상 대비가 적절한지 확인합니다.
  • 글꼴 크기
  • 멀티미디어 컨텐츠에 대한 대체 텍스트
  • 마우스 외에 컴퓨터 키보드를 사용하여 시스템을 사용할 수 있는 기능입니다.

규정 준수를 위한 공통 표준

보안 테스트

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

국제표준화기구(ISO)는 이를 "인증되지 않은 사람이나 시스템이 이를 사용, 판독 또는 수정할 수 없고, 인증된 사람이나 시스템이 이에 대한 접근이 거부되지 않도록 시험 항목 및 관련 데이터와 정보가 보호되는 정도를 평가하기 위해 수행되는 시험 유형"으로 정의합니다.[62]

국제화 및 현지화

국제화 및 현지화 테스트를 통해 소프트웨어가 다양한 언어 및 지리적 지역에서 사용될 수 있는지 확인합니다. 의사 현지화 프로세스는 응용 프로그램이 다른 언어로 번역되는 능력을 테스트하고 현지화 프로세스가 제품에 새로운 버그를 도입할 수 있는 시기를 쉽게 식별하는 데 사용됩니다.

글로벌화 테스트는 소프트웨어가 새로운 문화(예: 서로 다른 통화 또는 시간대)에 맞게 조정되었는지 확인합니다.[63]

실제 인간 언어로의 번역도 테스트해야 합니다. 발생 가능한 현지화 및 글로벌화 실패 사례는 다음과 같습니다.

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

개발시험

주요 기사: 개발시험

개발 테스트는 소프트웨어 개발 위험, 시간 및 비용을 줄이기 위해 광범위한 결함 예방 및 탐지 전략을 동기화하여 적용하는 소프트웨어 개발 프로세스입니다. 소프트웨어 개발 라이프사이클의 구축 단계에서 소프트웨어 개발자 또는 엔지니어에 의해 수행됩니다. 개발 테스트는 코드가 다른 테스트로 승격되기 전에 구성 오류를 제거하는 것을 목표로 합니다. 이 전략은 전체 개발 프로세스의 효율성뿐만 아니라 결과 소프트웨어의 품질을 높이기 위한 것입니다.

소프트웨어 개발에 대한 조직의 기대에 따라 개발 테스트에는 정적 코드 분석, 데이터 흐름 분석, 메트릭 분석, 동료 코드 검토, 단위 테스트, 코드 적용 범위 분석, 추적 가능성 및 기타 소프트웨어 테스트 관행이 포함될 수 있습니다.

A/B 테스트

주요기사 : A/B시험

A/B 검정은 제안된 변경 사항이 현재 접근 방식보다 더 효과적인지 여부를 결정하기 위해 통제된 실험을 실행하는 방법입니다. 고객은 기능의 현재 버전(제어) 또는 수정된 버전(처리)으로 라우팅되며 원하는 결과를 달성하는 데 더 나은 버전을 결정하기 위해 데이터가 수집됩니다.

동시 테스트

주요 기사: 동시 테스트

동시성 또는 동시성 테스트는 일반적으로 일반적인 사용 조건에서 동시 컴퓨팅을 사용하는 소프트웨어 및 시스템의 동작과 성능을 평가합니다. 이 유형의 테스트에서 노출되는 일반적인 문제는 데드락, 레이스 상황, 공유 메모리/리소스 처리 문제 등입니다.

적합성 시험 또는 형식 시험

주요기사 : 적합성 시험

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

출력비교시험

텍스트의 데이터 비교나 UI의 스크린샷과 같은 디스플레이 예상 출력을 생성하는 것은 [4]: 195 다른 많은 형태의 테스트와 달리 스냅샷 테스트 또는 Golden Master 테스트라고 불리기도 합니다. 이는 자동으로 장애를 감지할 수 없으며 대신 사람이 출력의 불일치를 평가해야 합니다.

특성시험

속성 테스트 알고리즘과 혼동하지 마십시오.

속성 테스트는 특정 입력이 특정 예상 출력을 생성한다고 주장하는 대신 실무자가 무작위로 많은 입력을 생성하고 모든 입력에 대해 프로그램을 실행하며 모든 입력과 출력 쌍에 대해 참이어야 하는 일부 "속성"의 진실을 주장하는 테스트 기술입니다. 예를 들어, 직렬화 함수의 모든 출력은 해당 병렬화 함수에 의해 받아들여져야 하며, 정렬 함수의 모든 출력은 입력과 정확히 동일한 요소를 포함하는 단조롭게 증가하는 목록이어야 합니다.

속성 테스트 라이브러리를 통해 사용자는 무작위 입력을 구성하는 전략을 제어하고, 퇴화된 사례의 적용 범위를 보장하거나, 테스트 중인 구현의 측면을 완전히 활용하는 데 필요한 특정 패턴을 특징으로 하는 입력을 보장할 수 있습니다.

속성 테스트는 Haskell 라이브러리 QuickCheck에 의해 도입되고 대중화되었기 때문에 "생성 테스트" 또는 "QuickCheck 테스트"라고도 합니다.[64]

변성시험

주요 기사: 변성시험

변형 테스트(MT)는 속성 기반 소프트웨어 테스트 기법으로, 테스트 오라클 문제 및 테스트 케이스 생성 문제를 해결하는 데 효과적인 접근 방식이 될 수 있습니다. 테스트 오라클 문제는 선택한 테스트 사례의 예상 결과를 결정하거나 실제 결과가 예상 결과와 일치하는지 여부를 결정하기 어렵다는 것입니다.

VCR 테스트

VCR 테스트는 "재생 테스트" 또는 "기록/재생" 테스트라고도 하며, 종종 테스트자가 통제할 수 없는 타사 API와 통신하기에 느리거나 신뢰할 수 없는 구성 요소를 포함하는 회귀 테스트의 신뢰성과 속도를 높이기 위한 테스트 기술입니다. 외부 구성 요소와 시스템의 상호 작용을 기록("카세트")한 다음, 테스트의 후속 실행 시 외부 시스템과 통신하기 위한 대용으로 기록된 상호 작용을 재생하는 작업이 포함됩니다.

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

시험공정

전통적인 폭포 개발 모델

폭포 개발의 일반적인 관행은 테스트가 독립적인 테스터 그룹에 의해 수행된다는 것입니다. 이런 일이 발생할 수 있습니다.

  • 기능이 개발된 후, 그러나 고객에게 배송되기 전에.[65] 이러한 관행으로 인해 테스트 단계가 프로젝트 지연을 보상하기 위한 프로젝트 버퍼로 사용되는 경우가 많아 테스트에 전념하는 시간이 단축됩니다.[14]: 145–146
  • 개발 프로젝트가 시작되는 동시에 프로젝트가 끝날 때까지 지속적인 프로세스로 진행됩니다.[66]

하지만 폭포 개발 모델에서도 유닛 테스트는 별도의 팀에서 추가 테스트를 수행하는 경우에도 소프트웨어 개발 팀에서 수행하는 경우가 많습니다.[67]

추가 정보: 공정 능력 성숙도 모형 통합 및 폭포 모형

민첩성 또는 XP 개발 모델

이와는 대조적으로, 익스트림 프로그래밍이나 민첩한 소프트웨어 개발 운동과 같은 일부 신흥 소프트웨어 분야는 "테스트 중심 소프트웨어 개발" 모델을 고수합니다. 이 과정에서 단위 테스트는 소프트웨어 엔지니어에 의해 먼저 작성됩니다(종종 극한 프로그래밍 방법론에서 페어 프로그래밍을 사용함). 테스트는 처음에 실패할 것으로 예상됩니다. 각각의 실패한 테스트는 통과할 수 있을 만큼의 코드를 작성한 후에 이루어집니다.[68] 이는 새로운 고장 조건 및 코너 사례가 발견됨에 따라 테스트 제품군이 지속적으로 업데이트되고 개발된 모든 회귀 테스트와 통합됨을 의미합니다. 유닛 테스트는 소프트웨어 소스 코드의 나머지 부분과 함께 유지되며 일반적으로 빌드 프로세스에 통합됩니다(본질적으로 대화형 테스트는 부분적으로 수동 빌드 수락 프로세스로 강등됨).

이 테스트 프로세스의 궁극적인 목표는 지속적인 통합을 지원하고 불량률을 줄이는 것입니다.[69][68]

이 방법론은 모든 공식 테스트 팀에 도달하기 전에 개발에 의해 수행되는 테스트 노력을 증가시킵니다. 일부 다른 개발 모델에서는 요구 사항이 정의되고 코딩 프로세스가 완료된 후에 테스트 실행이 대부분 이루어집니다.

샘플 테스트 주기

조직 간 편차가 존재하지만 테스트에는 일반적인 주기가 있습니다.[2] 아래의 샘플은 Waterpall 개발 모델을 사용하는 조직들 사이에서 공통적으로 사용되는 것입니다. 다른 개발 모델에서도 동일한 방식이 일반적으로 발견되지만, 명확하거나 명확하지 않을 수 있습니다.

  • 요구사항 분석: 테스트는 소프트웨어 개발 수명 주기의 요구 사항 단계에서 시작해야 합니다. 설계 단계에서 테스터는 설계의 어떤 측면이 테스트 가능한지, 어떤 매개 변수로 테스트가 작동하는지 확인합니다.
  • 테스트 계획: 테스트 전략, 테스트 계획, 테스트 베드 생성. 테스트를 진행하는 동안 많은 활동들이 진행될 것이기 때문에 계획이 필요합니다.
  • 테스트 개발: 테스트 절차, 테스트 시나리오, 테스트 사례, 테스트 데이터 세트, 테스트 스크립트를 테스트 소프트웨어에 사용합니다.
  • 테스트 실행: 테스터는 계획 및 테스트 문서를 기반으로 소프트웨어를 실행한 다음 발견된 오류를 개발 팀에 보고합니다. 프로그래밍 지식이 부족한 상태에서 테스트를 실행할 때 이 부분이 복잡할 수 있습니다.
  • 테스트 보고: 테스트가 완료되면 테스터는 메트릭을 생성하고 테스트 작업과 테스트한 소프트웨어가 출시 준비가 되었는지 여부에 대한 최종 보고서를 작성합니다.
  • 시험결과 분석: 또는 결함 분석(Defect Analysis)은 일반적으로 클라이언트와 함께 개발 팀이 수행하여 할당, 수정, 거부(예: 제대로 작동하는 소프트웨어 발견) 또는 나중에 처리를 연기해야 하는 결함을 결정합니다.
  • 결함 재검사: 일단 개발팀에서 결함을 처리하면 테스트팀에서 다시 테스트합니다.
  • 회귀 검정: 최신 제공이 아무 것도 망치지 않고 소프트웨어 제품 전체가 여전히 올바르게 작동하는지 확인하기 위해 새 소프트웨어, 수정 소프트웨어 또는 고정 소프트웨어의 각 통합에 대해 테스트의 하위 집합으로 구성된 소규모 테스트 프로그램을 사용하는 것이 일반적입니다.
  • 테스트 종료: 테스트가 종료 기준을 충족하면 프로젝트와 관련된 주요 결과물, 학습된 교훈, 결과물, 로그, 문서 등의 캡처와 같은 활동이 보관되어 향후 프로젝트에 참조로 사용됩니다.

자동화된 테스트

주요 기사: 테스트 자동화

많은 프로그래밍 그룹이[like whom?] 자동화된 테스트, 특히 테스트 중심 개발을 사용하는 그룹에 점점 더 많이[vague] 의존하고 있습니다. 테스트를 작성하기 위한 많은 프레임워크가[specify] 있으며, 지속적인 통합 소프트웨어는 버전 제어 시스템에 코드가 체크인될 때마다 테스트를 자동으로 실행합니다.

자동화는 인간이 할 수 있는 모든 것(그리고 그것을 할 생각을 하는 모든 방법)을 재현할 수는 없지만 회귀 테스트에 매우 유용할 수 있습니다. 그러나 실제로 유용하기 위해서는 잘 개발된 테스트 스크립트 세트가 필요합니다.

시험도구

프로그램 테스트 및 장애 감지는 테스트 도구 및 디버거를 통해 크게 도움을 받을 수 있습니다. 테스트/디버그 도구에는 다음과 같은 기능이 포함됩니다.

이러한 기능 중 일부는 단일 복합 도구 또는 통합 개발 환경(IDE)에 통합될 수 있습니다.

캡처 및 재생

캡처 및 재생 테스트는 애플리케이션과 상호 작용하는 동안 엔드 투 엔드 사용 시나리오를 수집하고 이러한 시나리오를 테스트 사례로 변환하는 것으로 구성됩니다. 캡처 및 재생의 가능한 적용에는 회귀 테스트 생성이 포함됩니다. SCARPE 도구는 실행 중인 응용 프로그램의 하위 집합을 선택적으로 캡처합니다. JRapture는 실행 중인 Java 프로그램과 파일 또는 그래픽 사용자 인터페이스의 이벤트와 같은 호스트 시스템의 구성 요소 간의 상호 작용 시퀀스를 캡처합니다. 그런 다음 관찰 기반 테스트를 위해 이러한 시퀀스를 재생할 수 있습니다.[71] Saieva 등은 중요한 보안 버그에 대한 후보 패치를 테스트하기 위해 기록된 사용자 실행 추적을 재생하는 애드혹 테스트를 생성할 것을 제안합니다.[72]

소프트웨어 테스트에서의 측정

주요 기사: 소프트웨어 품질

품질 척도에는 정확성, 완전성, 보안과 같은 주제와 능력, 신뢰성, 효율성, 휴대성, 유지보수성, 호환성 및 사용성과 같은 ISO/IEC 9126 요구 사항이 포함됩니다.

소프트웨어의 상태 또는 테스트의 적정성을 결정하는 데 도움이 되는 데 사용되는 자주 사용되는 소프트웨어 메트릭 또는 조치가 있습니다.

아티팩트 테스트 중

소프트웨어 테스트 프로세스는 여러 아티팩트를 생성할 수 있습니다. 실제 생산된 인공물은 사용된 소프트웨어 개발 모델, 이해관계자 및 조직의 요구 요소입니다.

시험계획

주요 기사: 시험계획

테스트 계획은 의도된 테스트 활동을 위해 취할 접근 방식을 자세히 설명하는 문서입니다. 계획에는 목표, 범위, 프로세스 및 절차, 인력 요구 사항 및 비상 계획과 같은 측면이 포함될 수 있습니다.[46] 시험 계획은 모든 시험 유형(합격 또는 시스템 시험 계획 등)과 계획 고려 사항을 포함하는 단일 계획 형태로 제공될 수도 있고, 하나 이상의 세부 시험 계획(계획)의 개요를 제공하는 마스터 시험 계획으로 발행될 수도 있습니다.[46] 테스트 계획은 경우에 따라 전반적인 테스트 접근 방식을 문서화하는 광범위한 "테스트 전략"의 일부가 될 수 있으며, 이는 그 자체로 마스터 테스트 계획이거나 별도의 아티팩트가 될 수도 있습니다.

추적성 매트릭스

이 단락들은 추적 가능성 매트릭스에서 발췌한 것입니다.[편집]
소프트웨어 개발에서 추적성 매트릭스([73]: 244 TM)는 일반적으로 표 형식의 문서로, 다대다 관계 비교를 사용하여 기준 문서 두 개를 연관시켜 관계의 완전성을 결정하는 데 사용됩니다.[73]: 3–22 높은 수준의 요구사항(이는 종종 마케팅 요구사항으로 구성됨)과 제품의 세부 요구사항을 높은 수준의 설계, 상세 설계, 테스트 계획 및 테스트 사례의 일치하는 부분에 사용하는 경우가 많습니다.

테스트 케이스

주요 기사: 테스트 케이스

테스트 케이스는 일반적으로 고유 식별자, 설계 사양의 요구 사항 참조, 전제 조건, 이벤트, 후속 조치(액션이라고도 함), 입력, 출력, 예상 결과 및 실제 결과로 구성됩니다. 임상적으로 정의된 테스트 케이스는 입력이며 예상되는 결과입니다.[74] 일반적으로 테스트 사례가 입력 시나리오와 예상되는 결과를 더 자세히 설명하지만, 이는 '조건 x 도출 결과는 y'와 다를 수 있습니다. 때로는 일련의 단계가 될 수 있지만, 경제적인 문제로 여러 테스트 사례에 대해 실행할 수 있는 별도의 테스트 절차에 단계가 포함되어 있는 경우가 많습니다. 그러나 예상 결과 또는 예상 결과 중 하나가 있습니다. 옵션 필드는 테스트 케이스 ID, 테스트 단계 또는 실행 번호 순서, 관련 요구 사항, 깊이, 테스트 범주, 작성자 및 테스트가 자동화되고 자동화되었는지 여부에 대한 확인란입니다. 테스트 사례가 클수록 필수 조건이나 단계 및 설명이 포함될 수도 있습니다. 테스트 케이스에는 실제 결과를 확인할 수 있는 장소도 포함되어 있어야 합니다. 이러한 단계는 워드 프로세서 문서, 스프레드시트, 데이터베이스 또는 기타 일반 리포지토리에 저장할 수 있습니다. 데이터베이스 시스템에서는 과거 테스트 결과, 결과를 생성한 사용자 및 해당 결과를 생성하기 위해 사용된 시스템 구성을 볼 수도 있습니다. 이러한 과거 결과는 일반적으로 별도의 테이블에 저장됩니다.

테스트 스크립트

테스트 스크립트는 사용자 작업을 복제하는 절차 또는 프로그래밍 코드입니다. 처음에 이 용어는 자동화된 회귀 테스트 도구에 의해 만들어진 작업의 산물에서 파생되었습니다. 테스트 케이스는 도구 또는 프로그램을 사용하여 테스트 스크립트를 만드는 기준이 됩니다.

테스트 스위트

이 섹션은 테스트 제품군에서 발췌한 내용입니다.[편집]
소프트웨어 개발에서 검증 스위트(Validation Suite)는 소프트웨어 프로그램이 특정 동작 집합을 가지고 있음을 보여주기 위해 테스트하는 데 사용되는 테스트 사례의 모음입니다.[75] 테스트 제품군에는 테스트 사례의 각 컬렉션에 대한 자세한 지침이나 목표와 테스트 중에 사용할 시스템 구성에 대한 정보가 포함되어 있는 경우가 많습니다. 테스트 사례 그룹에는 다음 테스트에 대한 전제 조건 상태 또는 단계 및 설명이 포함될 수도 있습니다.

테스트 고정장치 또는 테스트 데이터

주요 기사: 시험고정구

대부분의 경우 특정 기능의 동일한 기능을 테스트하기 위해 여러 개의 값 또는 데이터 세트가 사용됩니다. 모든 테스트 값과 변경 가능한 환경 구성 요소는 별도의 파일에 수집되어 테스트 데이터로 저장됩니다. 이 데이터를 고객에게 제공하고 제품 또는 프로젝트와 함께 제공하는 것도 유용합니다. 테스트 데이터를 생성하는 기술이 있습니다.

테스트 하니스

주요 기사: 테스트 하니스

소프트웨어, 도구, 데이터 입력 및 출력 샘플 및 구성을 모두 테스트 하니스라고 통칭합니다.

시운전

테스트 실행은 사용자가 실행 중인 테스트 사례 또는 테스트 제품군을 모아 예상 결과와 실제 결과를 비교하는 것입니다. 완료되면 보고서 또는 실행된 모든 테스트가 생성될 수 있습니다.

인증

추가 정보: 소프트웨어 테스트의 인증 §

소프트웨어 테스터 및 품질 보증 전문가의 전문적인 열망을 지원하기 위해 여러 인증 프로그램이 존재합니다. 몇몇 실무자들은 논란 부분에서 언급했듯이 테스트 분야가 인증 준비가 되어 있지 않다고 주장합니다.

논란

주요 소프트웨어 테스트 논란 중 일부는 다음과 같습니다.

민첩성과 전통성 비교
시험관은 불확실성과 지속적인 변화의 조건에서 작업하는 법을 배워야 합니까, 아니면 프로세스 "성숙"을 목표로 해야 합니까? 민첩성 테스트 운동은 2006년부터 상업계를 중심으로 인기를 얻고 있는 반면,[76][77] 정부 및 군[78] 소프트웨어 제공업체는 이 방법론뿐만 아니라 전통적인 테스트 마지막 모델(예: Waterpall 모델)도 사용합니다.[citation needed]
수동 테스트 대 자동 테스트
일부 저자는 테스트 자동화가 가치에 비해 너무 비싸서 적게 사용해야 한다고 생각합니다.[79] 그런 다음 테스트 자동화는 요구 사항을 캡처하고 구현하는 방법으로 고려할 수 있습니다. 일반적으로 시스템이 크고 복잡할수록 테스트 자동화의 ROI가 커집니다. 또한 도구 및 전문 지식에 대한 투자는 조직 내에서 적절한 수준의 지식 공유를 통해 여러 프로젝트에 걸쳐 상각될 수 있습니다.
ISO 29119 소프트웨어 테스트 표준의 존재는 정당한가요?
ISO 29119 표준에 대한 맥락 중심의 소프트웨어 테스트 학파의 입장에서 상당한 반대가 형성되었습니다. 국제 소프트웨어 테스트 협회(International Society for Software Testing)와 같은 전문 테스트 협회는 표준을 철회하려고 시도했습니다.[80][81]
일부 실무자는 테스트 분야가 인증 준비가 되지 않았다고 선언합니다.
[82] 현재 제공되는 어떤 인증도 실제로 지원자가 소프트웨어 테스트 능력을 보여줄 것을 요구하지 않습니다. 널리 인정되는 지식을 기반으로 한 인증은 없습니다. 자격증 자체는 개인의 생산성, 기술 또는 실무 지식을 측정할 수 없으며 테스트자로서의 역량 또는 전문성을 보장할 수 없습니다.[83]
결함 수정의 상대적인 비용을 보여주는 데 사용되는 연구
결함의 도입과 발견에 따른 상대적인 결함 수정 비용을 보여주기 위해 사용되는 연구의 적용 가능성에 대해서는 반대되는 견해가 있습니다. 예:

결함이 조기에 발견될수록 수리 비용이 저렴하다는 것이 일반적인 믿음입니다. 다음 표는 결함이 발견된 단계에 따라 결함을 수정하는 데 드는 비용을 보여줍니다.[84] 예를 들어, 요구사항의 문제가 릴리스 후에만 발견된 경우, 요구사항 검토를 통해 이미 발견된 경우보다 수리 비용이 10~100배 더 듭니다. 현대적인 지속적인 구축 관행과 클라우드 기반 서비스의 등장으로 시간이 지남에 따라 재구축 및 유지보수 비용이 절감될 수 있습니다.

하자보수비용 탐지된 시간
요구 사항들 건축 시공 시스템 테스트 발매후
소개시간 요구 사항들 1× 3× 5–10× 10× 10–100×
건축 – 1× 10× 15× 25–100×
시공 – – 1× 10× 10–25×

이 테이블을 외삽한 데이터가 부족합니다. 로랑 보사비트는 그의 분석에서 다음과 같이 말합니다.

"소규모 프로젝트" 곡선은 1학년 학생으로 구성된 두 팀에서만 나온 것으로 밝혀졌는데, 표본 크기가 너무 작아서 "일반적으로 작은 프로젝트"로 외삽하는 것은 전적으로 방어할 수 없습니다. GTE 연구는 대규모 프로젝트와 소규모 프로젝트 두 개에서 데이터가 나왔다고 말하는 것 외에는 데이터에 대해 설명하지 않습니다. Bell Labs "Safeguard" 프로젝트에 인용된 이 논문은 Boehm의 데이터 포인트가 시사하는 세분화된 데이터를 수집했다는 사실을 구체적으로 부인합니다. IBM 연구(Fagan의 논문)에는 Boehm의 그래프와 모순되는 것으로 보이는 주장이 포함되어 있으며, 그의 데이터 포인트와 명확하게 일치하는 수치 결과는 포함되어 있지 않습니다.

Boehm은 2010년에 "Making Software"를 작성할 때를 제외하고 TRW 데이터에 대한 논문도 인용하지 않으며, 1976년에 작성된 원래 기사를 인용했습니다. 봄이 인용하기에 적절한 시기에 TRW에서 수행된 대규모 연구가 있지만, 그 논문에는 봄의 주장을 뒷받침할 만한 종류의 데이터가 포함되어 있지 않습니다.[85]

관련 프로세스

소프트웨어 검증 및 검증

주요 기사: 검증 및 검증(소프트웨어) 및 소프트웨어 품질관리

소프트웨어 테스트는 검증 및 검증과 관련하여 사용됩니다.[86]

  • 확인: 소프트웨어를 제대로 구축했습니까? (즉, 요구 사항을 구현합니까?)
  • 유효성 검사: 올바른 소프트웨어를 구축했습니까? (즉, 성과물이 고객을 만족시키는지 여부)

검증과 검증이라는 용어는 업계에서 공통적으로 사용되며, 이 두 용어가 서로 모순되는 정의로 정의되는 것도 일반적입니다. IEEE 표준 소프트웨어 엔지니어링 용어집에 따르면 다음과 같습니다.[6]: 80–81

검증은 특정 개발 단계의 제품이 해당 단계 시작 시 부과된 조건을 충족하는지 여부를 결정하기 위해 시스템 또는 구성 요소를 평가하는 프로세스입니다.
검증은 시스템 또는 구성 요소가 지정된 요구 사항을 충족하는지 여부를 결정하기 위해 개발 프로세스 중 또는 종료 시에 평가하는 프로세스입니다.

그리고 ISO 9000 표준에 따르면:

검증은 명시된 요구사항이 충족되었음을 객관적인 증거 제공 및 검토를 통해 확인하는 것입니다.
검증은 특정한 용도 또는 용도에 대한 요건이 충족되었다는 객관적인 증거의 제공 및 심사를 통해 확인하는 것입니다.

이러한 모순은 요구사항과 지정된 요구사항의 개념을 사용하지만 다른 의미를 가지고 있기 때문에 발생합니다.

IEEE 표준의 경우, 유효성 검사의 정의에 언급된 지정된 요구 사항은 소프트웨어가 해결하고 충족해야 하는 이해 관계자의 문제, 필요 및 요구 사항입니다. 이러한 요구사항은 소프트웨어 요구사항 규격(SRS)에 문서화되어 있습니다. 그리고 검증의 정의에 언급된 제품은 소프트웨어 개발 프로세스의 모든 단계의 출력 인공물입니다. 이 제품들은 사실 건축설계사양, 상세설계사양 등의 사양입니다. SRS도 사양이지만 확인할 수 없습니다(적어도 여기에 사용된 의미에서는 그렇지 않으며 아래 이 주제에 대해 자세히 설명).

그러나 ISO 9000의 경우 지정된 요구 사항은 위에서 언급한 대로 확인해야 하는 사양 세트입니다. 앞서 설명한 바와 같이 사양은 다른 사양을 입력으로 받는 소프트웨어 개발 프로세스 단계의 산물입니다. 규격은 입력 규격을 올바르게 구현할 때 성공적으로 확인됩니다. SRS를 제외한 모든 사양은 첫 번째 사양이기 때문에 확인할 수 있습니다(단, 검증 가능). 예: 설계 사양은 SRS를 구현해야 하며, 시공 단계 아티팩트는 설계 사양을 구현해야 합니다.

그래서 이 단어들이 공통된 용어로 정의가 되면 명백한 모순은 사라지게 됩니다.

SRS와 소프트웨어 모두 유효성을 확인해야 합니다. SRS는 이해 관계자와 협의하여 정적으로 검증할 수 있습니다. 그럼에도 불구하고 소프트웨어 또는 모든 종류의 프로토타입(동적 테스트)의 일부 구현을 실행하고 해당 프로토타입으로부터 긍정적인 피드백을 얻으면 SRS가 올바르게 구성되었는지에 대한 확실성을 더욱 높일 수 있습니다. 반면에 소프트웨어는 최종적이고 실행 중인 제품(소스 코드를 포함한 아티팩트 및 문서가 아님)으로서 소프트웨어를 실행하고 이를 시도하도록 함으로써 이해 관계자와 함께 동적으로 검증해야 합니다.

일부에서는 SRS의 경우 입력이 이해 관계자의 말이므로 SRS 검증이 SRS 검증과 동일하다고 주장할 수 있습니다. 이렇게 생각하는 것은 더 많은 혼란을 초래할 뿐이므로 바람직하지 않습니다. 검증은 형식적이고 기술적인 입력 문서가 포함된 과정이라고 생각하는 것이 좋습니다.

소프트웨어 품질보증

소프트웨어 테스트는 소프트웨어 품질 보증(SQA) 프로세스의 일부로 간주될 수 있습니다.[4]: 347 SQA에서 소프트웨어 프로세스 전문가와 감사인은 문서, 코드 및 시스템과 같은 인공물이 아닌 소프트웨어 개발 프로세스에 관심을 가집니다. 이들은 소프트웨어 엔지니어링 프로세스 자체를 검사하고 변경하여 전달된 소프트웨어에 발생하는 결함 수, 즉 소위 결함률을 줄입니다. 허용 가능한 결함률을 구성하는 것은 소프트웨어의 특성에 따라 다릅니다. 비행 시뮬레이터 비디오 게임은 실제 비행기의 소프트웨어보다 훨씬 더 높은 결함 허용률을 가질 것입니다. SQA와 밀접한 연관성이 있지만 테스트 부서가 독립적으로 존재하는 경우가 많으며 일부 회사에는 SQA 기능이 없을 수 있습니다.[citation needed]

소프트웨어 테스트는 이해관계자에게 품질 관련 정보를 제공하기 위해 테스트 중인 소프트웨어를 조사하는 활동입니다. 이와 대조적으로 QA(품질 보증)는 결함이 고객에게 미치는 것을 방지하기 위한 정책 및 절차를 구현하는 것입니다.

참고 항목

참고문헌

  1. ^ Kaner, Cem (November 17, 2006). Exploratory Testing (PDF). Quality Assurance Institute Worldwide Annual Software Testing Conference. Orlando, FL. Retrieved November 22, 2014.
  2. ^ a b Pan, Jiantao (Spring 1999). "Software Testing" (coursework). Carnegie Mellon University. Retrieved November 21, 2017.
  3. ^ Leitner, Andreas; Ciupa, Ilinca; Oriol, Manuel; Meyer, Bertrand; Fiva, Arno (September 2007). Contract Driven Development = Test Driven Development – Writing Test Cases (PDF). ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007. Dubrovnik, Croatia. Retrieved December 8, 2017.
  4. ^ a b c d Kaner, Cem; Falk, Jack; Nguyen, Hung Quoc (1999). Testing Computer Software (2nd ed.). New York: John Wiley and Sons. ISBN 978-0-471-35846-6.
  5. ^ a b Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. ISBN 978-0-470-04212-0.
  6. ^ a b c IEEE Standard Glossary of Software Engineering Terminology, IEEE, 1990, doi:10.1109/IEEESTD.1990.101064, ISBN 978-1-55937-067-7
  7. ^ "Certified Tester Foundation Level Syllabus". International Software Testing Qualifications Board. March 31, 2011. Section 1.1.2. Archived from the original (pdf) on October 28, 2017. Retrieved December 15, 2017.
  8. ^ "Certified Tester Foundation Level Syllabus" (PDF). International Software Testing Qualifications Board. July 1, 2005. Principle 2, Section 1.3. Archived from the original (PDF) on December 17, 2008. Retrieved December 15, 2017.
  9. ^ Ramler, Rudolf; Kopetzky, Theodorich; Platz, Wolfgang (April 17, 2012). Combinatorial Test Design in the TOSCA Testsuite: Lessons Learned and Practical Implications. IEEE Fifth International Conference on Software Testing and Validation (ICST). Montreal, QC, Canada. doi:10.1109/ICST.2012.142.
  10. ^ "The Economic Impacts of Inadequate Infrastructure for Software Testing" (PDF). National Institute of Standards and Technology. May 2002. Retrieved December 19, 2017.
  11. ^ Sharma, Bharadwaj (April 2016). "Ardentia Technologies: Providing Cutting Edge Software Solutions and Comprehensive Testing Services". CIO Review (India ed.). Retrieved December 20, 2017.
  12. ^ Gelperin, David; Hetzel, Bill (June 1, 1988). "The growth of software testing". Communications of the ACM. 31 (6): 687–695. doi:10.1145/62959.62965. S2CID 14731341.
  13. ^ Gregory, Janet; Crispin, Lisa (2014). More Agile Testing. Addison-Wesley Professional. pp. 23–39. ISBN 978-0-13-374956-4.
  14. ^ a b c Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. ISBN 978-0-471-04328-7.
  15. ^ a b Graham, D.; Van Veenendaal, E.; Evans, I. (2008). Foundations of Software Testing. Cengage Learning. pp. 57–58. ISBN 978-1-84480-989-9.
  16. ^ a b c d Oberkampf, W.L.; Roy, C.J. (2010). Verification and Validation in Scientific Computing. Cambridge University Press. pp. 154–5. ISBN 978-1-139-49176-1.
  17. ^ Lee, D.; Netravali, A.N.; Sabnani, K.K.; Sugla, B.; John, A. (1997). "Passive testing and applications to network management". Proceedings 1997 International Conference on Network Protocols. IEEE Comput. Soc. pp. 113–122. doi:10.1109/icnp.1997.643699. ISBN 978-0-8186-8061-8. S2CID 42596126.
  18. ^ Cem Kaner, "Wayback Machine에서 보관된 탐색적 테스트 튜토리얼 2013-06-12", p.2
  19. ^ Cem Kaner, 탐색적 테스트 튜토리얼, Wayback Machine에서 아카이브된 2013-06-12, 페이지 36.
  20. ^ Lee, D.; Yannakakis, M. (1996). "Principles and methods of testing finite state machines-a survey". Proceedings of the IEEE. 84 (8): 1090–1123.
  21. ^ Petrenko, A.; Yevtushenko, N. (2011). "Adaptive testing of deterministic implementations specified by nondeterministic FSMs". In Testing Software and Systems: 23rd IFIP WG 6.1 International Conference, ICTSS 2011, Paris, France, November 7-10. Springer Berlin Heidelberg. pp. 162–178.
  22. ^ Petrenko, A.; Yevtushenko, N. (2014). "Adaptive testing of nondeterministic systems with FSM". In 2014 IEEE 15th International Symposium on High-Assurance Systems Engineering. IEEE. pp. 224–228.
  23. ^ a b c d Limaye, M.G. (2009). Software Testing. Tata McGraw-Hill Education. pp. 108–11. ISBN 978-0-07-013990-9.
  24. ^ a b c d Saleh, K.A. (2009). Software Engineering. J. Ross Publishing. pp. 224–41. ISBN 978-1-932159-94-3.
  25. ^ a b c Ammann, P.; Offutt, J. (2016). Introduction to Software Testing. Cambridge University Press. p. 26. ISBN 978-1-316-77312-3.
  26. ^ Everatt, G.D.; McLeod Jr., R. (2007). "Chapter 7: Functional Testing". Software Testing: Testing Across the Entire Software Development Life Cycle. John Wiley & Sons. pp. 99–121. ISBN 978-0-470-14634-7.
  27. ^ a b Cornett, Steve (c. 1996). "Code Coverage Analysis". Bullseye Testing Technology. Introduction. Retrieved November 21, 2017.
  28. ^ a b Black, R. (2011). Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional. John Wiley & Sons. pp. 44–6. ISBN 978-1-118-07938-6.
  29. ^ 간단한 예로 C 함수를 들 수 있습니다. int f(int x){return x*x-6*x+8;} 단 하나의 문장으로 구성됩니다. 규격에 대한 모든 검정 f(x)>=0 성공할 것입니다. 단, x=3 우연히 선택되었습니다.
  30. ^ Patton, Ron (2005). Software Testing (2nd ed.). Indianapolis: Sams Publishing. ISBN 978-0-672-32798-8.
  31. ^ Laycock, Gilbert T. (1993). The Theory and Practice of Specification Based Software Testing (PDF) (dissertation thesis). Department of Computer Science, University of Sheffield. Retrieved January 2, 2018.
  32. ^ Bach, James (June 1999). "Risk and Requirements-Based Testing" (PDF). Computer. 32 (6): 113–114. Retrieved August 19, 2008.
  33. ^ Savenkov, Roman (2008). How to Become a Software Tester. Roman Savenkov Consulting. p. 159. ISBN 978-0-615-23372-7.
  34. ^ Mathur, A.P. (2011). Foundations of Software Testing. Pearson Education India. p. 63. ISBN 978-81-317-5908-0.
  35. ^ a b Clapp, Judith A. (1995). Software Quality Control, Error Analysis, and Testing. William Andrew. p. 313. ISBN 978-0-8155-1363-6. Retrieved January 5, 2018.
  36. ^ Mathur, Aditya P. (2007). Foundations of Software Testing. Pearson Education India. p. 18. ISBN 978-81-317-1660-1.
  37. ^ Lönnberg, Jan (October 7, 2003). Visual testing of software (PDF) (MSc thesis). Helsinki University of Technology. Retrieved January 13, 2012.
  38. ^ Chima, Raspal. "Visual testing". TEST Magazine. Archived from the original on July 24, 2012. Retrieved January 13, 2012.
  39. ^ a b c Lewis, W.E. (2016). Software Testing and Continuous Quality Improvement (3rd ed.). CRC Press. pp. 68–73. ISBN 978-1-4398-3436-7.
  40. ^ a b Ransome, J.; Misra, A. (2013). Core Software Security: Security at the Source. CRC Press. pp. 140–3. ISBN 978-1-4665-6095-6.
  41. ^ "SOA Testing Tools for Black, White and Gray Box" (white paper). Crosscheck Networks. Archived from the original on October 1, 2018. Retrieved December 10, 2012.
  42. ^ Bourque, Pierre; Fairley, Richard E., eds. (2014). "Chapter 5". Guide to the Software Engineering Body of Knowledge. 3.0. IEEE Computer Society. ISBN 978-0-7695-5166-1. Retrieved January 2, 2018.
  43. ^ Bourque, P.; Fairley, R.D., eds. (2014). "Chapter 4: Software Testing" (PDF). SWEBOK v3.0: Guide to the Software Engineering Body of Knowledge. IEEE. pp. 4–1–4–17. ISBN 978-0-7695-5166-1. Archived from the original (PDF) on June 19, 2018. Retrieved July 13, 2018.
  44. ^ Dooley, J. (2011). Software Development and Professional Practice. APress. pp. 193–4. ISBN 978-1-4302-3801-0.
  45. ^ Wiegers, K. (2013). Creating a Software Engineering Culture. Addison-Wesley. pp. 211–2. ISBN 978-0-13-348929-3.
  46. ^ a b c Lewis, W.E. (2016). Software Testing and Continuous Quality Improvement (3rd ed.). CRC Press. pp. 92–6. ISBN 978-1-4398-3436-7.
  47. ^ Machado, P.; Vincenzi, A.; Maldonado, J.C. (2010). "Chapter 1: Software Testing: An Overview". In Borba, P.; Cavalcanti, A.; Sampaio, A.; Woodcook, J. (eds.). Testing Techniques in Software Engineering. Springer Science & Business Media. pp. 13–14. ISBN 978-3-642-14334-2.
  48. ^ Clapp, J.A.; Stanten, S.F.; Peng, W.W.; et al. (1995). Software Quality Control, Error Analysis, and Testing. Nova Data Corporation. p. 254. ISBN 978-0-8155-1363-6.
  49. ^ a b c "ISTQB CTFL Syllabus 2018" (PDF). ISTQB - International Software Testing Qualifications Board. Archived (PDF) from the original on March 24, 2022. Retrieved April 11, 2022.
  50. ^ Binder, Robert V. (1999). Testing Object-Oriented Systems: Objects, Patterns, and Tools. Addison-Wesley Professional. p. 45. ISBN 978-0-201-80938-1.
  51. ^ Beizer, Boris (1990). Software Testing Techniques (Second ed.). New York: Van Nostrand Reinhold. pp. 21, 430. ISBN 978-0-442-20672-7.
  52. ^ Woods, Anthony J. (June 5, 2015). "Operational Acceptance – an application of the ISO 29119 Software Testing standard" (Whitepaper). Capgemini Australia. Retrieved January 9, 2018.
  53. ^ Kaner, Cem; Bach, James; Pettichord, Bret (2001). Lessons Learned in Software Testing: A Context-Driven Approach. Wiley. pp. 31–43. ISBN 978-0-471-08112-8.
  54. ^ a b Myers, G. (2004). Sandler, C; Badgett, T; Thomas, M. (eds.). The Art of Software Testing (2 ed.). Wiley. ISBN 9780471469124.
  55. ^ Ammann, Paul; Offutt, Jeff (January 28, 2008). Introduction to Software Testing. Cambridge University Press. p. 215. ISBN 978-0-521-88038-1. Retrieved November 29, 2017.
  56. ^ "Standard Glossary of Terms used in Software Testing" (PDF). Version 3.1. International Software Testing Qualifications Board. Retrieved January 9, 2018.
  57. ^ O'Reilly, Tim (September 30, 2005). "What is Web 2.0". O'Reilly Media. Section 4. End of the Software Release Cycle. Retrieved January 11, 2018.
  58. ^ Auerbach, Adam (August 3, 2015). "Part of the Pipeline: Why Continuous Testing Is Essential". TechWell Insights. TechWell Corp. Retrieved January 12, 2018.
  59. ^ Philipp-Edmonds, Cameron (December 5, 2014). "The Relationship between Risk and Continuous Testing: An Interview with Wayne Ariola". Stickyminds. Retrieved January 16, 2018.
  60. ^ Ariola, Wayne; Dunlop, Cynthia (October 2015). DevOps: Are You Pushing Bugs to Clients Faster? (PDF). Pacific Northwest Software Quality Conference. Retrieved January 16, 2018.
  61. ^ Auerbach, Adam (October 2, 2014). "Shift Left and Put Quality First". TechWell Insights. TechWell Corp. Retrieved January 16, 2018.
  62. ^ "Section 4.38". ISO/IEC/IEEE 29119-1:2013 – Software and Systems Engineering – Software Testing – Part 1 – Concepts and Definitions. International Organization for Standardization. Retrieved January 17, 2018.
  63. ^ "Globalization Step-by-Step: The World-Ready Approach to Testing. Microsoft Developer Network". Microsoft Developer Network. Archived from the original on June 23, 2012. Retrieved January 13, 2012.
  64. ^ Claessen, Koen; Hughes, John (2000). "QuickCheck". Proceedings of the fifth ACM SIGPLAN international conference on Functional programming. Icfp '00. pp. 268–279. doi:10.1145/351240.351266. ISBN 978-1-58113-202-1. S2CID 5668071.{{cite book}}: CS1 메인트 : 일시 및 연도 (링크)
  65. ^ "Software Testing Lifecycle". etestinghub. Testing Phase in Software Testing. Retrieved January 13, 2012.
  66. ^ Dustin, Elfriede (2002). Effective Software Testing. Addison-Wesley Professional. p. 3. ISBN 978-0-201-79429-8.
  67. ^ Brown, Chris; Cobb, Gary; Culbertson, Robert (April 12, 2002). Introduction to Rapid Software Testing.
  68. ^ a b "What is Test Driven Development (TDD)?". Agile Alliance. December 5, 2015. Retrieved March 17, 2018.
  69. ^ "Test-Driven Development and Continuous Integration for Mobile Applications". msdn.microsoft.com. January 14, 2009. Retrieved March 17, 2018.
  70. ^ Joshi, Shrinivas; Orso, Alessandro (October 2007). "SCARPE: A Technique and Tool for Selective Capture and Replay of Program Executions". 2007 IEEE International Conference on Software Maintenance. pp. 234–243. doi:10.1109/ICSM.2007.4362636. ISBN 978-1-4244-1255-6. S2CID 17718313.
  71. ^ Steven, John; Chandra, Pravir; Fleck, Bob; Podgurski, Andy (September 2000). "jRapture: A Capture/Replay tool for observation-based testing". ACM SIGSOFT Software Engineering Notes. 25 (5): 158–167. doi:10.1145/347636.348993. ISSN 0163-5948.
  72. ^ Saieva, Anthony; Singh, Shirish; Kaiser, Gail (September 2020). "Ad hoc Test Generation Through Binary Rewriting". 2020 IEEE 20th International Working Conference on Source Code Analysis and Manipulation (SCAM). Adelaide, Australia: IEEE. pp. 115–126. doi:10.1109/SCAM51674.2020.00018. ISBN 978-1-7281-9248-2. S2CID 219618921.
  73. ^ a b Gotel, Orlena; Cleland-Huang, Jane; Hayes, Jane Huffman; Zisman, Andrea; Egyed, Alexander; Grünbacher, Paul; Dekhtyar, Alex; Antoniol, Giuliano; Maletic, Jonathan (January 1, 2012). Cleland-Huang, Jane; Gotel, Orlena; Zisman, Andrea (eds.). Software and Systems Traceability. Springer London. doi:10.1007/978-1-4471-2239-5_1. ISBN 9781447122388.
  74. ^ IEEE (1998). IEEE standard for software test documentation. New York: IEEE. ISBN 978-0-7381-1443-9.
  75. ^ Pinto, Leandro Sales; Sinha, Saurabh; Orso, Alessandro (November 11, 2012). "Understanding myths and realities of test-suite evolution". Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering. Association for Computing Machinery. pp. 1–11. doi:10.1145/2393596.2393634. ISBN 9781450316149. S2CID 9072512.
  76. ^ Strom, David (July 1, 2009). "We're All Part of the Story". Software Test & Performance Collaborative. Archived from the original on August 31, 2009.
  77. ^ Griffiths, M. (2005). "Teaching agile project management to the PMI". Agile Development Conference (ADC'05). ieee.org. pp. 318–322. doi:10.1109/ADC.2005.45. ISBN 978-0-7695-2487-0. S2CID 30322339.
  78. ^ Willison, John S. (April 2004). "Agile Software Development for an Agile Force". CrossTalk. STSC (April 2004). Archived from the original on October 29, 2005.
  79. ^ 마크 퓨스터, 도로시 그레이엄(Dorothy Graham): 소프트웨어 테스트 자동화(Software Test Automation)가 그 예입니다. 애디슨 웨슬리, 1999, ISBN 978-0-201-33140-0
  80. ^ "stop29119". commonsensetesting.org. Archived from the original on October 2, 2014.
  81. ^ Paul Krill (August 22, 2014). "Software testers balk at ISO 29119 standards proposal". InfoWorld.
  82. ^ Kaner, Cem (2001). "NSF grant proposal to 'lay a foundation for significant improvements in the quality of academic and commercial courses in software testing'" (PDF). Archived from the original (PDF) on November 27, 2009. Retrieved October 13, 2006.
  83. ^ Kaner, Cem (2003). Measuring the Effectiveness of Software Testers (PDF). STAR East. Archived from the original (PDF) on March 26, 2010. Retrieved January 18, 2018.
  84. ^ McConnell, Steve (2004). Code Complete (2nd ed.). Microsoft Press. p. 29. ISBN 978-0-7356-1967-8.
  85. ^ Bossavit, Laurent (November 20, 2013). "The cost of defects: an illustrated history". The Leprechauns of Software Engineering: How folklore turns into fact and what to do about it. leanpub.
  86. ^ Tran, Eushiuan (1999). "Verification/Validation/Certification" (coursework). Carnegie Mellon University. Retrieved August 13, 2008.

추가읽기

외부 링크

Wikimedia Commons에는 소프트웨어 테스트와 관련된 미디어가 있습니다.
Wikiversity에서는 소프트웨어 테스트 부서에서 소프트웨어 테스트에 대해 자세히 알아보고 다른 사람들에게 가르칠 수 있습니다.