소프트웨어 테스트 전술

이 글은 고아로, 다른 어떤 기사도 그것에 연결되지 않는다.관련 기사에서 이 페이지에 대한 링크를 소개하고, 제안사항을 보려면 링크 찾기 도구를 사용해 보십시오.(2017년 3월)

다음에 대한 시리즈 일부
소프트웨어 개발
핵심 활동 과정 요구 사항들 디자인 건설 테스트 디버깅 배치 유지 관리
패러다임 및 모델 소프트웨어 엔지니어링 민첩한 클린룸 증분형 프로토타이핑 나선형 V 모델 폭포
방법론 및 프레임워크 Asd. 데브옵스 아빠 DSDM FDD IID 칸반 린 SD 레스 MDD MSF PSP RAD 럽 SAFe 스크럼 세마트 TSP 열어 보세요. UP XP
지원 분야 구성 관리 문서화 소프트웨어 품질 보증 프로젝트 관리 사용자 경험
연습 ATDD BDD CCO CI CD Ddd. PP SBE 스탠드업 TDD
도구들 컴파일러 디버거 프로파일러 GUI 디자이너 모델링. IDE 빌드 자동화 릴리스 자동화 코드로서의 인프라 테스트
지식의 표준 및 본문 바보크 CMMI IEEE 표준 ISO 9001 ISO/IEC 표준 PMBOK 스위복 ITIL IREB
용어집 인공지능 컴퓨터 공학 전기전자공학
윤곽선 소프트웨어 개발 개요
v t

이 글에서는 소프트웨어 테스트에 유용한 일련의 전술에 대해 논한다.소프트웨어 품질 보증에 대한 전술적 접근법(일반적으로 QA(Quality Assurance)로 더 널리 알려져 있음)과 시험 방법의 일반적 적용(일반적으로 "시험" 또는 "개발자 시험"으로 불림)의 포괄적인 목록으로 의도되었다.

설치시험

설치 테스트를 통해 시스템이 올바르게 설치되고 실제 고객의 하드웨어에서 작동하는지 확인하십시오.

박스 어프로치

소프트웨어 테스트 방법은 전통적으로 화이트-박스 테스트와 블랙박스 테스트로 나뉜다.이 두 가지 접근방식은 시험 엔지니어가 시험 사례를 설계할 때 취하는 관점을 설명하는 데 사용된다.

화이트 박스 테스트

화이트 박스 테스트(클리어 박스 테스트, 유리 박스 테스트, 투명 박스 테스트 및 소스 코드를 통해 구조 테스트라고도 함)는 최종 사용자에게 노출되는 기능과 반대로 프로그램의 내부 구조 또는 작동을 테스트한다.화이트박스 테스트에서는 시스템의 내부 관점뿐만 아니라 프로그래밍 기술도 테스트 케이스를 설계하는 데 사용된다.검사자는 코드를 통과하는 경로를 연습하기 위해 입력을 선택하고 적절한 출력을 결정한다.이는 회로 내 노드(예: 회로 내 테스트(ICT))와 유사하다.

화이트박스 테스트는 소프트웨어 테스트 프로세스의 유닛, 통합, 시스템 레벨에서 적용할 수 있지만, 대개 유닛 레벨에서 이루어진다.장치 내의 경로, 통합 중에 장치 사이의 경로 및 시스템 수준 테스트 중에 하위 시스템 사이의 경로를 테스트할 수 있다.이 시험 설계 방법은 많은 오류나 문제를 발견할 수 있지만, 규격의 구현되지 않은 부분이나 누락된 요건은 감지하지 못할 수 있다.

화이트 박스 테스트에 사용되는 기법은 다음과 같다.

• API 테스트 – 공용 및 개인 API를 사용한 응용프로그램 테스트(응용프로그램 인터페이스)
• 코드 적용 범위 – 코드 적용의 일부 기준을 충족하기 위한 테스트 생성(예: 테스트 설계자는 프로그램의 모든 문장이 한 번 이상 실행되도록 하는 테스트를 만들 수 있음)
• 고장 주입 방법 – 테스트 전략의 유효성을 측정하기 위해 고장을 의도적으로 도입
• 돌연변이 검사법
• 정적 시험 방법

코드 커버리지 도구는 블랙박스 테스트를 포함하여 어떤 방법으로든 만들어진 테스트 세트의 완전성을 평가할 수 있다.이를 통해 소프트웨어 팀은 거의 테스트되지 않는 시스템의 일부를 검사할 수 있으며 가장 중요한 기능 포인트가 테스트되었는지 확인할 수 있다.^{[1][unreliable source?]}소프트웨어 메트릭으로서의 코드 적용 범위는 다음에 대한 백분율로 보고될 수 있다.

• 실행된 기능에 대해 보고하는 기능 범위
• 문장의 범위: 테스트를 완료하기 위해 실행된 줄 수를 보고함
• 특정 테스트의 True 및 False 분기가 모두 실행되었는지 여부를 보고하는 의사결정 범위

100% 명세서 적용범위는 (제어 흐름 측면에서) 모든 코드 경로 또는 분기가 한 번 이상 실행되도록 보장한다.이것은 정확한 기능성을 보장하는 데 도움이 되지만, 동일한 코드가 다른 입력을 올바르거나 잘못 처리할 수 있기 때문에 충분하지 않다.

블랙박스 테스트

블랙박스 테스트는 소프트웨어를 "블랙박스"로 취급하며, 소스 코드를 보지 않고 내부 구현을 전혀 모르는 상태에서 기능성을 검사한다.테스터들은 소프트웨어가 어떻게 해야 하는지에 대해서가 아니라 소프트웨어가 무엇을 해야 하는지에 대해서만 알고 있다.^[2]블랙박스 시험 방법에는 동등성 분할, 경계값 분석, 올페어 시험, 상태 전환표, 의사결정표 시험, 솜털 시험, 모델 기반 시험, 사용 사례 시험, 탐색 시험 및 규격 기반 시험이 포함된다.

규격 기반 시험은 해당 요건에 따라 소프트웨어의 기능성을 시험하는 것을 목적으로 한다.^[3]이 수준의 시험은 일반적으로 시험관에게 철저한 시험 사례를 제공해야 하며, 시험관은 주어진 입력에 대해 출력 값(또는 동작)이 시험 사례에 명시된 예상 값과 "있는" 값 또는 "아닌" 값인지 간단히 확인할 수 있다.시험 케이스는 규격과 요건, 즉 응용 프로그램이 해야 할 일을 중심으로 구축된다.그것은 시험 케이스를 도출하기 위해 사양, 요건 및 설계를 포함한 소프트웨어에 대한 외부 설명을 사용한다.이러한 테스트는 일반적으로 기능적이긴 하지만 기능적이거나 비기능적일 수 있다.

규격 기반 시험은 정확한 기능성을 보장하기 위해 필요할 수 있지만 복잡하거나 위험성이 높은 상황을 경계하기에는 불충분하다.^[4]

블랙박스 기법의 한 가지 장점은 프로그래밍 지식이 필요하지 않다는 것이다.프로그래머들이 어떤 편견을 가지고 있었든, 테스터는 아마도 다른 세트를 가지고 있고 다른 기능 영역을 강조할 수 있다.반면 블랙박스 테스트는 "손전등 없는 어두운 미로 속을 걷는 것 같다"^[5]는 평가를 받아왔다.소스 코드를 검사하지 않기 때문에 검사자가 하나의 테스트 케이스로 테스트했을 수 있는 것을 검사하기 위해 많은 테스트 케이스를 작성하거나 프로그램의 일부를 테스트하지 않은 경우가 있다.

이 테스트 방법은 유닛, 통합, 시스템 및 수락 등 모든 소프트웨어 테스트 레벨에 적용할 수 있다.일반적으로 상위 레벨에서 모든 시험을 구성하지는 않지만, 단위 시험을 지배할 수도 있다.

시각 테스트

시각적 테스트는 개발자가 요구하는 정보를 쉽게 찾을 수 있도록 데이터를 제시함으로써 소프트웨어 장애 시점에서 발생한 일을 검사할 수 있는 능력을 개발자에게 제공하는 것을 목적으로 한다.^[6][7]

시각적 테스트의 핵심에는 문제를 설명하는 것만이 아니라, 누군가에게 문제를 보여주는 것(또는 시험 실패)이 명확성과 이해를 크게 증가시킨다는 생각이 있다.따라서 시각 테스트는 전체 테스트 프로세스를 기록하여 테스트 시스템에서 발생하는 모든 것을 비디오 형식으로 캡처해야 한다.출력 영상은 사진 속 웹캠을 통한 실시간 테스터 입력과 마이크의 오디오 해설로 보완된다.

시각 테스트는 많은 이점을 제공한다.시험관이 문제를 기술하는 것만이 아니라 개발자에게 문제(그리고 그로 이어지는 사건)를 보여줄 수 있고, 많은 경우에 시험 실패를 재현할 필요성이 사라지기 때문에 통신의 질이 급격히 향상된다.개발자는 시험 실패에 대해 필요한 모든 증거를 가지고 대신 고장의 원인과 해결 방법에 초점을 맞출 수 있다.

시각적 테스트는 특히 소프트웨어 개발에서 민첩한 방법을 구현하는 환경에 적합하다. 민첩한 방법은 테스터와 개발자 간의 더 큰 커뮤니케이션과 소규모 팀 간의 협업이 필요하기 때문이다.^{[citation needed]}

즉석 시험과 탐구 시험은 소프트웨어 무결성을 확인하는 중요한 방법론인데, 중요한 버그를 빨리 찾을 수 있는 반면, 소프트웨어 무결성을 확인하는 데 있어서 더 적은 시간이 필요하기 때문이다.즉흥적이고 즉흥적인 방법으로 시험이 이루어지는 임시 시험에서, 버그를 발견하기 위해 취한 단계를 문서화하기 위해 시스템에서 발생하는 모든 것을 시각적으로 기록하는 시험 도구의 능력은 매우 중요해진다.^{[clarification needed][citation needed]}

시각적 시험은 개발 과정에 관여하는 많은 개인에 의해 사용될 수 있기 때문에 고객 수용과 사용적합성 시험에서 인정을 모으고 있다.^{[citation needed]}고객에게는 상세한 버그리포트와 피드백을 제공하는 것이 쉬워지고, 프로그램 이용자의 경우, 시각적 테스트가 사용자의 음성·이미지뿐 아니라 화면에 사용자 행동을 기록하여 개발자에게 소프트웨어 장애 시 완전한 그림을 제공할 수 있다.

회색 상자 테스트

그레이박스 테스트(미국식 철자: 그레이박스 테스트)는 사용자 또는 블랙박스 수준에서 테스트를 실행하는 동안 테스트 설계 목적으로 내부 데이터 구조 및 알고리즘에 대한 지식을 보유하는 것을 포함한다.테스터가 소프트웨어의 소스 코드에 완전히 액세스할 필요는 없다.^[2]입력 데이터를 조작하고 출력을 포맷하는 것은 그레이 박스로서의 요건을 갖추지 못한다. 입력과 출력이 명백히 우리가 테스트 중인 시스템을 호출하는 "블랙 박스" 밖에 있기 때문이다.이러한 구별은 시험을 위해 인터페이스만 노출되는 두 개의 서로 다른 개발자가 작성한 코드 모듈 간 통합 시험을 수행할 때 특히 중요하다.

그러나 데이터베이스나 로그 파일과 같은 백엔드 데이터 저장소를 수정해야 하는 테스트는 사용자가 정상적인 프로덕션 작업에서 데이터 저장소를 변경할 수 없기 때문에 그레이 박스로 간주된다.^{[citation needed]}회색 상자 시험에는 예를 들어 경계 값이나 오류 메시지를 결정하는 역 엔지니어링도 포함될 수 있다.

검사자는 소프트웨어의 작동 원리에 대한 기본 개념을 파악하여 외부에서 소프트웨어를 테스트하는 동안 보다 정보에 입각한 테스트를 선택한다.일반적으로 회색 상자 테스터는 데이터베이스 시딩과 같은 활동으로 분리된 시험 환경을 설정할 수 있다.검사자는 데이터베이스에 대해 SQL 문을 실행하고 쿼리를 실행하는 등의 특정 작업을 수행한 후 테스트 대상 제품의 상태를 관찰하여 예상되는 변경 사항이 반영되었는지 확인할 수 있다.회색 상자 시험은 제한된 정보에 기초하여 지능적인 테스트 시나리오를 구현한다.이는 특히 데이터 유형 처리, 예외 처리 등에 적용된다.^[8]

자동화된 테스트

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

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

자동화된 테스트 도구

프로그램 테스트와 고장 감지는 테스트 도구와 디버거에 의해 크게 도움이 될 수 있다.테스트/디버그 도구에는 다음과 같은 기능이 포함된다.

• 프로그램 모니터, 다음을 포함한 프로그램 코드의 전체 또는 부분 모니터링 허용:
  • 전체 지침 수준 모니터링 및 추적 기능을 허용하는 명령 집합 시뮬레이터
  • 하이퍼바이저, 다음을 포함한 프로그램 코드 실행을 완전히 제어할 수 있는 기능:
  • 프로그램 애니메이션, 소스 레벨 또는 기계 코드에서 단계별 실행 및 조건부 중단점 허용
  • 코드 범위 보고서
• 포맷된 덤프 또는 심볼 디버깅, 오류 시 또는 선택한 지점에서 프로그램 변수를 검사할 수 있는 도구
• 자동화된 기능 GUI(Graphical User Interface) 테스트 도구를 사용하여 GUI를 통한 시스템 레벨 테스트를 반복한다.
• 벤치마크, 런타임 성능 비교 가능
• 핫 스팟 및 리소스 사용을 강조할 수 있는 성능 분석(또는 프로파일링 도구)

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

자동화된 테스트에 적용되는 애플리케이션 계층 추상화

일반적으로 인정된 4가지 수준의 시험이 있다: 단위 시험, 통합 시험, 구성요소 인터페이스 시험, 시스템 시험.테스트는 소프트웨어 개발 프로세스에서 추가되는 위치 또는 테스트의 특수성 수준에 따라 자주 그룹화된다.SWEBOK 가이드에 의해 정의된 개발 프로세스 중 주요 수준은 특정 프로세스 모델을 암시하지 않고 테스트 대상으로 구별되는 단위, 통합 및 시스템 테스트다.^[9]다른 시험 수준은 시험 목적에 따라 분류된다.^[9]

고객 입장에서 보면 낮은 수준의 테스트(LLT)와 높은 수준의 테스트(HLT) 두 가지가 있다.LLT는 소프트웨어 응용 프로그램 또는 제품의 다른 레벨 구성요소에 대한 시험 그룹이다.HLT는 전체 소프트웨어 응용 프로그램 또는 제품에 대한 테스트 그룹이다.^{[citation needed]}

단위시험

단위 시험이란 일반적으로 기능 수준에서 코드의 특정 섹션의 기능을 검증하는 시험을 말한다.객체 지향 환경에서 이것은 대개 클래스 레벨이며 최소 단위 테스트에는 시공자와 파괴자가 포함된다.^[10]

이러한 유형의 테스트는 특정 기능이 예상대로 작동하는지 확인하기 위해 개발자가 코드(화이트 박스 스타일)로 작업할 때 작성하는 것이 보통이다.한 함수는 코드의 코너 케이스 또는 다른 분기를 잡기 위해 다중 테스트를 수행할 수 있다.단위 시험만으로는 소프트웨어의 기능을 확인할 수 없고, 오히려 소프트웨어의 구성 블록이 서로 독립적으로 작동하는지 확인하는 데 사용된다.

단위 시험은 소프트웨어 개발 위험, 시간 및 비용을 줄이기 위해 광범위한 결함 방지 및 탐지 전략의 동시 적용을 수반하는 소프트웨어 개발 프로세스다.소프트웨어 개발자 또는 엔지니어가 소프트웨어 개발 라이프사이클의 건설 단계에서 수행한다.전통적인 QA의 초점을 대체하기 보다는, 그것은 그것을 증가시킨다.단위 테스트는 코드가 QA로 승격되기 전에 시공 오류를 제거하는 것을 목표로 한다. 이 전략은 전체 개발 및 QA 프로세스의 효율성뿐만 아니라 결과 소프트웨어의 품질을 향상시키기 위한 것이다.

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

통합 테스트

통합 시험은 소프트웨어 설계에 대한 구성요소 사이의 인터페이스를 검증하려는 모든 유형의 소프트웨어 시험이다.소프트웨어 구성요소는 반복적인 방법으로 통합되거나 모두 통합될 수 있다("빅뱅").일반적으로 전자는 인터페이스 문제를 더 빠르고 고정할 수 있기 때문에 더 나은 관행으로 간주된다.

통합 시험은 인터페이스의 결함과 통합 구성요소(모듈) 간의 상호작용을 노출하기 위해 작동한다.점진적으로 더 큰 그룹의 시험 소프트웨어 구성 요소들은 구조 설계의 요소들에 해당하는 것으로 통합되고 소프트웨어가 시스템으로서 작동할 때까지 시험된다.^[11]

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

구성요소 인터페이스 시험의 관행을 사용하여 다양한 장치 또는 서브시스템 구성 요소 간에 전달된 데이터의 취급 상태를 점검할 수 있다.^[12][13]전달되는 데이터는 "메시지 패킷"으로 간주할 수 있으며, 한 장치에서 생성되는 데이터에 대해 범위나 데이터 유형을 확인하여 다른 장치로 전달되기 전에 유효성을 시험할 수 있다.인터페이스 테스트의 한 가지 방법은 전달되는 데이터 항목의 로그 파일을 별도로 유지하는 것이며, 종종 수일 또는 수주일 동안 단위 간에 전달된 수천 건의 데이터를 분석할 수 있도록 타임스탬프가 기록된다.다른 인터페이스 변수가 정상 값으로 전달되는 동안 일부 극한 데이터 값의 처리를 확인하는 것이 테스트에 포함될 수 있다.^[12]인터페이스의 비정상적인 데이터 값은 다음 장치에서 예상치 못한 성능을 설명하는 데 도움이 될 수 있다.구성요소 인터페이스 테스트는 블랙박스 테스트의 변형이며,^[13] 서브시스템 구성요소의 관련 작용 이상의 데이터 값에 초점을 맞춘다.

시스템 테스트

시스템 테스트는 시스템이 요구 사항을 충족하는지 확인하기 위해 완전히 통합된 시스템을 테스트한다.^[14]예를 들어 시스템 테스트에는 로그온 인터페이스 테스트, 항목 생성 및 편집, 결과 보내기 또는 인쇄, 항목의 요약 처리 또는 삭제(또는 보관)가 차례로 포함된 다음 로그오프할 수 있다.

운영 인수 테스트

운영 수용은 품질 관리 시스템의 일부로서 제품, 서비스 또는 시스템의 운영 준비(사전 출시)를 수행하는 데 사용된다.OAT는 소프트웨어 개발 및 소프트웨어 유지보수 프로젝트에 주로 사용되는 비기능 소프트웨어 시험의 일반적인 유형이다.이러한 유형의 테스트는 지원되거나 생산 환경의 일부가 되는 시스템의 운영 준비 상태에 초점을 맞춘다.따라서 운영 준비 상태 테스트(ORT) 또는 운영 준비 상태 및 보장(OR&A) 테스트라고도 한다.OAT 내의 기능 시험은 시스템의 비기능적 측면을 검증하는 데 필요한 시험으로 제한된다.

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

호환성 테스트

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

매연 및 건전성 테스트

건전성 테스트는 추가 테스트를 진행하는 것이 합리적인지 여부를 결정한다.

스모크 테스트는 소프트웨어를 작동하기 위한 최소한의 시도로 구성되며, 소프트웨어 작동에 전혀 방해가 되는 기본적인 문제가 없는지 여부를 판단하도록 설계된다.그러한 시험은 빌드 검증 시험으로 사용될 수 있다.

회귀 검정

회귀 테스트는 주요 코드 변경이 발생한 후 결함을 찾는 데 초점을 맞춘다.구체적으로는 돌아온 오래된 버그를 포함하여 기능이 저하되거나 상실된 소프트웨어 퇴행을 밝혀내려고 한다.이러한 퇴행은 이전에 올바르게 작동하던 소프트웨어 기능이 의도한 대로 작동을 멈출 때마다 발생한다.일반적으로 퇴행은 소프트웨어의 새로 개발된 부분이 기존의 코드와 충돌할 때 프로그램 변경의 의도하지 않은 결과로 발생한다.회귀 테스트의 일반적인 방법에는 이전 테스트 사례 집합을 다시 실행하고 이전에 고정된 고장이 다시 나타났는지 확인하는 것이 포함된다.시험의 깊이는 릴리스 프로세스의 단계와 추가된 기능의 위험에 따라 달라진다.이러한 변경사항은 릴리스에 늦게 추가되거나 위험하다고 간주되는 변경에 대해 완전하거나 매우 얕을 수 있으며, 변경 내용이 릴리스 초기에 있거나 위험이 낮다고 간주되는 경우 각 기능에 대한 양성 테스트로 구성된다.회귀 테스트는 일반적으로 이전 소프트웨어 기능에 대한 수많은 세부 사항을 확인하기 때문에 상용 소프트웨어 개발에서 가장 큰 테스트 작업이며, 심지어 새로운 소프트웨어도 이전 테스트 케이스를 사용하여 새 설계의 부품을 테스트하여 이전 기능을 여전히 지원할 수 있도록 할 수 있다.^[16]

합격시험

합격 시험은 다음 두 가지 중 하나를 의미할 수 있다.

1. 매연 테스트는 주요 테스트 프로세스에 새로운 빌드를 도입하기 전에, 즉 통합 또는 회귀 전에 합격 테스트로 사용된다.
2. 고객이 자체 하드웨어의 실험실 환경에서 수행하는 합격 시험을 UAT(사용자 합격 시험)라고 한다.인수 시험은 개발의 두 단계 사이의 인계 프로세스의 일부로 수행될 수 있다.^{[citation needed]}

알파 검사

알파 테스트는 개발자 사이트에서 잠재적 사용자/고객 또는 독립된 테스트 팀에 의해 시뮬레이션되거나 실제 운영 테스트된다.알파 테스팅은 소프트웨어가 베타 테스팅으로 가기 전에 내부 인수 테스팅의 한 형태로 기성 소프트웨어에 채택되는 경우가 많다.^[17]

베타 테스트

베타 테스트는 알파 테스트 후에 수행되며 외부 사용자 인수 테스트의 한 형태로 간주될 수 있다.베타 버전으로 알려진 소프트웨어의 버전은 베타 테스터로 알려진 프로그래밍 팀 외부의 제한된 청중에게 공개된다.소프트웨어는 추가 테스트를 통해 제품에 결함이나 버그가 거의 없음을 확인할 수 있도록 그룹에게 공개된다.베타 버전은 공개 대중에게 제공되어 피드백 필드를 최대 미래 사용자 수로 증가시키고 가치를 더 일찍, 장기 또는 심지어 무한정 기간 동안(연속 베타) 제공할 수 있다.^{[citation needed]}

기능 테스트와 비기능 테스트

기능시험이란 코드의 특정 작용이나 기능을 검증하는 활동을 말한다.일부 개발 방법론은 사용 사례나 사용자 사례에서 작동하지만, 이것들은 일반적으로 코드 요구사항 문서에서 발견된다.기능 테스트는 "사용자가 이것을 할 수 있는가" 또는 "이 특정 기능이 작동하고 있는가"라는 질문에 답하는 경향이 있다.

비기능 테스트란 확장성이나 기타 성능, 특정 제약조건에 따른 행동, 보안 등 특정 기능이나 사용자 조치와 관련이 없을 수 있는 소프트웨어의 측면을 말한다.테스트는 한계점, 즉 확장성 또는 성능의 극한값이 불안정한 실행으로 이어지는 지점을 결정한다.비기능적 요건은 특히 사용자의 적합성 관점에서 제품의 품질을 반영하는 요건이 되는 경향이 있다.

연속 테스트

지속적인 테스트는 소프트웨어 출시 후보자와 관련된 비즈니스 위험에 대한 즉각적인 피드백을 얻기 위해 소프트웨어 전송 파이프라인의 일부로 자동화된 테스트를 실행하는 과정이다.^[18][19]지속적인 테스트는 기능 요구사항과 비기능 요구사항 모두의 검증을 포함한다. 즉, 테스트의 범위는 상향 요구사항이나 사용자 사례의 검증에서 비즈니스 목표를 중첩하는 것과 관련된 시스템 요구사항의 평가까지 이른다.^[20][21][22]

파괴검사

파괴 테스트는 소프트웨어 또는 하위 시스템에 장애를 일으키려고 시도한다.유효하지 않거나 예상치 못한 입력을 받아도 소프트웨어가 제대로 기능하는지 검증하여 입력 검증 및 오류 관리 루틴의 견고성을 확립한다.^{[citation needed]}소프트웨어 결함 주입은 솜털 형태의 고장 시험의 예다.다양한 상용 비기능 시험 도구는 소프트웨어 결함 주입 페이지에서 연결된다. 파괴 시험을 수행하는 수많은 오픈 소스 및 무료 소프트웨어 도구도 있다.

소프트웨어 성능 테스트

성능 시험은 일반적으로 시스템 또는 하위 시스템이 특정 작업 부하에서 응답성과 안정성 측면에서 어떻게 수행되는지 결정하기 위해 실행된다.또한 확장성, 신뢰성 및 자원 사용과 같은 시스템의 다른 품질 속성을 조사, 측정, 검증 또는 검증하는 역할을 할 수 있다.

부하 시험은 대량의 데이터든 다수의 사용자든 시스템이 특정 부하에서 계속 작동할 수 있다는 시험과 주로 관련이 있다.이를 일반적으로 소프트웨어 확장성이라고 한다.비기능 활동으로 수행되는 경우 관련 하중 시험 활동을 내구성 시험이라고 한다.볼륨 테스트는 특정 구성 요소(예: 파일 또는 데이터베이스)의 크기가 급격하게 증가할 때에도 소프트웨어 기능을 테스트하는 방법이다.스트레스 테스트는 예기치 않거나 드문 작업 부하에서 안정성을 테스트하는 방법이다.안정성 시험(흔히 부하 또는 내구성 시험이라고 함)은 소프트웨어가 허용 가능한 기간 또는 그 이상에서 지속적으로 잘 기능할 수 있는지 여부를 점검한다.

성능시험의 구체적인 목표가 무엇인지에 대해서는 거의 합의가 이루어지지 않고 있다.부하 테스트, 성능 테스트, 확장성 테스트 및 볼륨 테스트라는 용어는 종종 서로 바꾸어 사용된다.

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

사용적합성 시험

사용적합성 시험은 사용자 인터페이스가 사용하기 쉽고 이해하기 쉬운지 확인하는 것이다.그것은 주로 응용 프로그램의 사용과 관련이 있다.

내게 필요한 옵션 테스트

접근성 시험은 다음과 같은 표준 준수를 포함할 수 있다.

• 1990년 미국 장애인법
• 제508조 1973년 회생법 개정
• W3C(World Wide Web Consortium)의 Web Accessibility Initiative(Web Accessibility Initiative)

보안 테스트

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

국제표준화기구(ISO)는 이를 "시험항목, 관련 데이터 및 정보가 보호되는 정도를 평가하여 허가받지 않은 사람이나 시스템이 이를 사용, 읽거나 수정할 수 없고, 인가된 사람이나 시스템이 이에 대한 접근을 거부하지 않도록 하기 위해 실시하는 시험 유형"^[23]으로 정의한다.

국제화 및 국산화 테스트

소프트웨어의 국제화 및 국산화 일반적 능력은 가성분화를 통해 실제 번역 없이 자동으로 테스트할 수 있다.새로운 언어로 번역되거나 새로운 문화(다른 통화나 시간대 등)에 적응한 후에도 애플리케이션이 여전히 작동하는지 검증한다.^[24]

인간 언어에 대한 실제 번역도 시험해야 한다.가능한 지역화 실패는 다음과 같다.

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

개발시험

"개발시험"은 소프트웨어 개발 리스크, 시간, 비용을 줄이기 위해 광범위한 결함 예방과 검출 전략을 동시에 적용하는 것을 수반하는 소프트웨어 개발 프로세스다.소프트웨어 개발자 또는 엔지니어가 소프트웨어 개발 라이프사이클의 건설 단계에서 수행한다.전통적인 QA의 초점을 대체하기 보다는, 그것은 그것을 증가시킨다.개발 테스트는 코드가 QA로 승격되기 전에 시공 오류를 제거하는 것을 목표로 한다. 이 전략은 결과 소프트웨어의 품질뿐만 아니라 전체 개발 및 QA 프로세스의 효율성을 높이기 위한 것이다.

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

A/B 테스트

A/B 테스트는 기본적으로 두 가지 출력을 비교하는 것으로, 일반적으로 한 변수만 변경된 경우, 테스트 실행, 한 가지 변경, 다시 실행, 결과 비교.이것은 더 작은 규모의 상황에서 더 유용하지만, 어떤 프로그램이라도 세밀하게 조정할 때 매우 유용하다.보다 복잡한 프로젝트에서는 다변량 테스트를 수행할 수 있다.

동시 테스트

동시 시험에서는 응력 시험이나 솜털 시험과는 반대로 정상 입력과 정상 작동 조건에서 연속적으로 실행하면서 성능에 초점을 맞춘다.메모리 누수는 물론 기본적인 결함도 이 방법으로 찾기 쉽다.

적합성 시험 또는 형식 시험

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

참조

외부 링크

Wikimedia Commons는 소프트웨어 테스트와 관련된 미디어를 가지고 있다.

• Curlie의 소프트웨어 테스트 도구 및 제품