소프트웨어 테스팅-퀵 가이드

테스팅이란 무엇입니까?

테스트는 지정된 요구 사항을 충족하는지 여부를 찾기위한 의도로 시스템 또는 구성 요소를 평가하는 프로세스입니다. 간단히 말해서 테스트는 실제 요구 사항과 상반되는 차이, 오류 또는 누락 된 요구 사항을 식별하기 위해 시스템을 실행하는 것입니다.

ANSI / IEEE 1059 표준에 따라 테스트는 다음과 같이 정의 할 수 있습니다.-소프트웨어 항목을 분석하여 기존 조건과 필수 조건 (즉, 결함 / 오류 / 버그) 간의 차이를 감지하고 소프트웨어 항목의 기능을 평가하는 프로세스입니다.

누가 테스트합니까?

프로세스 및 프로젝트의 관련 이해 관계자에 따라 다릅니다. IT 산업에서 대기업은 주어진 요구 사항의 맥락에서 개발 된 소프트웨어를 평가할 책임이있는 팀을 보유하고 있습니다. 또한 개발자는 테스트를 수행합니다.Unit Testing. 대부분의 경우 다음 전문가는 각자의 능력 내에서 시스템을 테스트하는 데 관여합니다.

소프트웨어 테스터
소프트웨어 개발자
프로젝트 리드 / 관리자
최종 사용자

소프트웨어 테스터, 소프트웨어 품질 보증 엔지니어, QA 분석가 등과 같은 경험과 지식을 기반으로 소프트웨어를 테스트하는 사람들을 회사마다 다르게 지정합니다.

주기 중에는 소프트웨어를 테스트 할 수 없습니다. 다음 두 섹션에서는 테스트를 시작해야하는시기와 SDLC 중에 종료 할시기를 설명합니다.

언제 테스트를 시작해야합니까?

테스트를 일찍 시작하면 재 작업에 드는 비용과 시간이 줄어들고 클라이언트에 제공되는 오류없는 소프트웨어를 생성 할 수 있습니다. 그러나 SDLC (Software Development Life Cycle)에서는 요구 사항 수집 단계에서 테스트를 시작하여 소프트웨어 배포까지 계속할 수 있습니다.

또한 사용중인 개발 모델에 따라 다릅니다. 예를 들어 Waterfall 모델에서 공식 테스트는 테스트 단계에서 수행됩니다. 그러나 증분 모델에서는 모든 증분 / 반복이 끝날 때마다 테스트가 수행되고 마지막에 전체 응용 프로그램이 테스트됩니다.

테스트는 SDLC의 모든 단계에서 다양한 형태로 수행됩니다.

요구 사항 수집 단계에서 요구 사항의 분석 및 검증도 테스트로 간주됩니다.
디자인을 개선하려는 의도로 디자인 단계에서 디자인을 검토하는 것도 테스트로 간주됩니다.
코드 완료시 개발자가 수행 한 테스트도 테스트로 분류됩니다.

언제 테스트를 중지해야합니까?

테스트는 끝이없는 프로세스이고 아무도 소프트웨어가 100 % 테스트되었다고 주장 할 수 없기 때문에 테스트를 중지 할시기를 결정하는 것은 어렵습니다. 테스트 프로세스를 중지하기 위해 다음 측면을 고려해야합니다.

마감일 테스트
테스트 케이스 실행 완료
특정 지점까지 기능 및 코드 커버리지 완료
버그 비율이 특정 수준 이하로 떨어지고 우선 순위가 높은 버그가 식별되지 않습니다.
경영 결정

확인 및 검증

이 두 용어는 서로 바꿔서 사용하는 대부분의 사람들에게 매우 혼란 스럽습니다. 다음 표는 확인과 검증의 차이점을 강조합니다.

Sr. 아니.	확인	확인
1	검증은 "당신이 제대로 구축하고 있습니까?"라는 우려를 해결합니다.	유효성 검사는 "올바른 것을 구축하고 있습니까?"라는 문제를 해결합니다.
2	소프트웨어 시스템이 모든 기능을 충족하는지 확인합니다.	기능이 의도 한 동작을 충족하는지 확인합니다.
삼	확인이 먼저 이루어지며 문서, 코드 등을 확인합니다.	검증은 검증 후에 이루어지며 주로 전체 제품을 점검합니다.
4	개발자가 수행합니다.	테스터가 수행했습니다.
5	여기에는 소프트웨어를 확인하기위한 검토, 연습 및 검사 수집이 포함되므로 정적 활동이 있습니다.	요구 사항에 대한 소프트웨어 실행을 포함하므로 동적 활동이 있습니다.
6	이는 객관적인 프로세스이며 소프트웨어를 확인하는 데 주관적인 결정이 필요하지 않습니다.	이는 주관적인 프로세스이며 소프트웨어가 얼마나 잘 작동하는지에 대한 주관적인 결정을 포함합니다.

다음은 소프트웨어 테스트에 대한 가장 일반적인 신화 중 일부입니다.

오해 1 : 테스트는 너무 비싸다

Reality− 소프트웨어 개발 중 테스트 비용을 적게 지불하거나 나중에 유지 관리 또는 수정 비용을 더 많이 지불한다는 말이 있습니다. 초기 테스트는 여러 측면에서 시간과 비용을 모두 절약하지만 테스트없이 비용을 줄이면 소프트웨어 응용 프로그램의 부적절한 설계로 인해 제품을 쓸모 없게 만들 수 있습니다.

오해 2 : 테스트는 시간 소모적이다

Reality− SDLC 단계 동안 테스트는 시간이 많이 걸리는 프로세스가 아닙니다. 그러나 적절한 테스트 중에 식별 된 오류를 진단하고 수정하는 것은 시간이 많이 걸리지 만 생산적인 작업입니다.

오해 3 : 완전히 개발 된 제품 만 테스트 됨

Reality− 의심 할 여지없이 테스트는 소스 코드에 따라 다르지만 요구 사항 검토 및 테스트 케이스 개발은 개발 된 코드와 독립적입니다. 그러나 개발 라이프 사이클 모델로서의 반복적 또는 점진적 접근 방식은 완전히 개발 된 소프트웨어에 대한 테스트의 종속성을 줄일 수 있습니다.

통념 4 : 완전한 테스트가 가능하다

Reality− 클라이언트 또는 테스터가 완전한 테스트가 가능하다고 생각할 때 문제가됩니다. 모든 경로가 팀에 의해 테스트되었을 수 있지만 완전한 테스트의 발생은 불가능합니다. 소프트웨어 개발 수명주기 동안 테스트 팀이나 클라이언트가 실행하지 않고 프로젝트가 배포 된 후 실행될 수있는 시나리오가있을 수 있습니다.

오해 5 : 테스트 된 소프트웨어는 버그가 없다

Reality − 이것은 클라이언트, 프로젝트 관리자 및 관리 팀이 믿는 매우 일반적인 통념입니다. 뛰어난 테스트 기술을 가진 테스터가 애플리케이션을 테스트 한 경우에도 소프트웨어 애플리케이션이 100 % 버그가 없다고 절대적으로 주장 할 수있는 사람은 없습니다. .

오해 6 : 누락 된 결함은 테스터로 인한 것

Reality− 테스트를 수행 한 후에도 애플리케이션에 남아있는 버그에 대해 테스터를 비난하는 것은 올바른 접근 방식이 아닙니다. 이 신화는 시간, 비용 및 요구 사항 변경 제약과 관련이 있습니다. 그러나 테스트 전략으로 인해 테스트 팀이 버그를 놓칠 수도 있습니다.

통념 7 : 테스터는 제품 품질에 대한 책임이 있습니다

Reality− 테스터 또는 테스트 팀만 제품 품질에 대한 책임을 져야한다는 것은 매우 일반적인 오해입니다. 테스터의 책임에는 이해 관계자가 버그를 식별하는 것이 포함되며 버그를 수정하거나 소프트웨어를 릴리스할지 여부는 자신의 결정입니다. 당시 소프트웨어를 출시하면 오류에 대한 책임을지기 때문에 테스터에게 더 많은 압력이 가해집니다.

오해 8 : 시간을 줄이기 위해 가능한 한 테스트 자동화를 사용해야합니다.

Reality− 예, 테스트 자동화가 테스트 시간을 줄이는 것은 사실이지만 소프트웨어 개발 중에는 언제든지 테스트 자동화를 시작할 수 없습니다. 테스트 자동화는 소프트웨어가 수동으로 테스트되고 어느 정도 안정적 일 때 시작되어야합니다. 또한 요구 사항이 계속 변경되면 테스트 자동화를 사용할 수 없습니다.

오해 9 : 누구나 소프트웨어 애플리케이션을 테스트 할 수있다

Reality− IT 업계 외부의 사람들은 누구나 소프트웨어를 테스트 할 수 있으며 테스트는 창의적인 일이 아니라고 생각하고 믿습니다. 그러나 테스터는 이것이 신화라는 것을 잘 알고 있습니다. 대안 시나리오를 생각하고 잠재적 인 버그를 탐색하려는 의도로 소프트웨어를 충돌시키려는 시도는 그것을 개발 한 사람에게는 불가능합니다.

오해 10 : 테스터의 유일한 임무는 버그를 찾는 것입니다

Reality− 소프트웨어에서 버그를 찾는 것은 테스터의 작업이지만 동시에 특정 소프트웨어의 도메인 전문가입니다. 개발자는 자신에게 할당 된 특정 구성 요소 또는 영역에 대해서만 책임이 있지만 테스터는 소프트웨어의 전반적인 작동, 종속성, 한 모듈이 다른 모듈에 미치는 영향을 이해합니다.

테스트, 품질 보증 및 품질 관리

대부분의 사람들은 품질 보증, 품질 관리 및 테스트 간의 차이점을 파악할 때 혼란스러워합니다. 서로 연관되어 있고 어느 정도까지는 동일한 활동으로 간주 될 수 있지만 구별되는 점이 있습니다. 다음 표에는 QA, QC 및 테스트를 구분하는 포인트가 나열되어 있습니다.

품질 보증	품질 관리	테스팅
QA에는 개발 된 소프트웨어 및 의도 된 요구 사항의 검증과 관련하여 프로세스, 절차 및 표준의 구현을 보장하는 활동이 포함됩니다.	여기에는 문서화 된 (또는 경우에 따라 아님) 요구 사항과 관련하여 개발 된 소프트웨어의 검증을 보장하는 활동이 포함됩니다.	여기에는 소프트웨어의 버그 / 오류 / 결함을 식별하는 활동이 포함됩니다.
시스템에서 실제 테스트를 수행하기보다는 프로세스 및 절차에 중점을 둡니다.	절차 및 프로세스 구현을 통해 버그 / 결함을 식별 할 목적으로 소프트웨어를 실행하여 실제 테스트에 중점을 둡니다.	실제 테스트에 중점을 둡니다.
프로세스 지향적 활동.	제품 지향적 활동.	제품 지향적 활동.
예방 활동.	수정 과정입니다.	예방 적 과정입니다.
STLC (Software Test Life Cycle)의 하위 집합입니다.	QC는 품질 보증의 하위 집합으로 간주 될 수 있습니다.	테스트는 품질 관리의 하위 집합입니다.

사정

Audit− 조직 또는 팀 내에서 실제 테스트 프로세스가 수행되는 방식을 결정하는 체계적인 프로세스입니다. 일반적으로 소프트웨어 테스트 중에 관련된 프로세스에 대한 독립적 인 검사입니다. IEEE에 따라 조직이 구현하고 따르는 문서화 된 프로세스에 대한 검토입니다. 감사 유형에는 법률 준수 감사, 내부 감사 및 시스템 감사가 포함됩니다.

Inspection− 오류 또는 격차를 식별하여 아티팩트에 대한 공식 또는 비공식 기술 검토를 포함하는 공식 기술입니다. IEEE94에 따라 검사는 소프트웨어 요구 사항, 설계 또는 코드를 작성자가 아닌 사람이나 그룹이 자세히 검사하여 결함, 개발 표준 위반 및 기타 문제를 감지하는 공식적인 평가 기술입니다.

공식 검사 회의에는 계획, 개요 준비, 검사 회의, 재 작업 및 후속 조치와 같은 프로세스가 포함될 수 있습니다.

테스트 및 디버깅

Testing− 수정하지 않고 소프트웨어의 버그 / 오류 / 결함을 식별하는 것이 포함됩니다. 일반적으로 품질 보증 배경이있는 전문가가 버그 식별에 관여합니다. 테스트는 테스트 단계에서 수행됩니다.

Debugging− 문제 / 버그를 식별, 격리 및 수정하는 작업이 포함됩니다. 소프트웨어를 코딩하는 개발자는 코드에서 오류가 발생하면 디버깅을 수행합니다. 디버깅은 화이트 박스 테스트 또는 단위 테스트의 일부입니다. 디버깅은 단위 테스트를 수행하는 동안 개발 단계에서 수행하거나보고 된 버그를 수정하는 동안 단계에서 수행 할 수 있습니다.

전 세계의 많은 조직이 소프트웨어의 품질 요구 사항을 개선하기 위해 다양한 표준을 개발하고 구현합니다. 이 장에서는 품질 보증 및 테스트와 관련하여 널리 사용되는 몇 가지 표준에 대해 간략하게 설명합니다.

ISO / IEC 9126

이 표준은 소프트웨어 응용 프로그램의 품질을 결정하기 위해 다음과 같은 측면을 다룹니다.

품질 모델
외부 측정 항목
내부 측정 항목
사용중인 품질 메트릭

이 표준은 다음과 같은 소프트웨어에 대한 품질 속성 집합을 제공합니다.

Functionality
Reliability
Usability
Efficiency
Maintainability
Portability

위에서 언급 한 품질 속성은 표준을 자세히 연구 할 때 연구 할 수있는 하위 요소로 더 세분화됩니다.

ISO / IEC 9241-11

이 표준의 Part 11은 특정 사용자가 특정 사용 컨텍스트에서 효과 성, 효율성 및 만족도와 함께 특정 목표를 달성하기 위해 제품을 사용할 수있는 범위를 다룹니다.

이 표준은 유용성 구성 요소와 이들 간의 관계를 설명하는 프레임 워크를 제안했습니다. 이 표준에서는 사용자 성능과 만족도 측면에서 유용성을 고려합니다. ISO 9241-11에 따르면 사용성은 사용 컨텍스트에 따라 다르며 사용성 수준은 컨텍스트가 변경됨에 따라 변경됩니다.

ISO / IEC 25000 : 2005

ISO / IEC 25000 : 2005는 일반적으로 소프트웨어 품질 요구 사항 및 평가 (SQuaRE)에 대한 지침을 제공하는 표준으로 알려져 있습니다. 이 표준은 소프트웨어 품질 요구 사항 및 평가와 관련된 프로세스를 구성하고 향상시키는 데 도움이됩니다. 실제로 ISO-25000은 ISO-9126과 ISO-14598의 두 가지 오래된 ISO 표준을 대체합니다.

SQuaRE -와 같은 하위 부분으로 나뉩니다.

ISO 2500n-품질 관리 부서
ISO 2501n-품질 모델 부문
ISO 2502n-품질 측정 부서
ISO 2503n-품질 요구 사항 부서
ISO 2504n-품질 평가 부서

SQuaRE의 주요 내용은-

용어 및 정의
참조 모델
일반 가이드
개별 부문 가이드
요구 엔지니어링 관련 표준 (즉, 사양, 계획, 측정 및 평가 프로세스)

ISO / IEC 12119

이 표준은 클라이언트에 제공되는 소프트웨어 패키지를 다룹니다. 고객의 생산 과정에 초점을 맞추거나 다루지 않습니다. 주요 내용은 다음 항목과 관련이 있습니다.

소프트웨어 패키지에 대한 요구 사항 세트.
지정된 요구 사항에 대해 제공된 소프트웨어 패키지를 테스트하기위한 지침.

여러 가지 잡다한

QA 및 테스트 프로세스와 관련된 다른 표준 중 일부는 다음과 같습니다.

Sr. 아니요	표준 및 설명
1	IEEE 829 소프트웨어 테스트의 여러 단계에서 사용되는 문서 형식에 대한 표준입니다.
2	IEEE 1061 품질 요구 사항을 설정하고, 프로세스 및 소프트웨어 품질 메트릭의 제품을 식별, 구현, 분석 및 검증하는 방법론입니다.
삼	IEEE 1059 소프트웨어 검증 및 검증 계획 가이드.
4	IEEE 1008 단위 테스트를위한 표준입니다.
5	IEEE 1012 소프트웨어 검증 및 검증을위한 표준입니다.
6	IEEE 1028 소프트웨어 검사를위한 표준.
7	IEEE 1044 소프트웨어 이상 분류를위한 표준입니다.
8	IEEE 1044-1 소프트웨어 이상 분류를위한 가이드입니다.
9	IEEE 830 시스템 요구 사항 사양을 개발하기위한 가이드입니다.
10	IEEE 730 소프트웨어 품질 보증 계획의 표준입니다.
11	IEEE 1061 소프트웨어 품질 메트릭 및 방법론의 표준입니다.
12	IEEE 12207 소프트웨어 수명주기 프로세스 및 수명주기 데이터에 대한 표준입니다.
13	BS 7925-1 소프트웨어 테스트에 사용되는 용어의 어휘.
14	BS 7925-2 소프트웨어 구성 요소 테스트를위한 표준입니다.

이 섹션에서는 SDLC 중에 소프트웨어를 테스트하는 데 사용할 수있는 다양한 유형의 테스트를 설명합니다.

수동 테스트

수동 테스트에는 자동화 된 도구 나 스크립트를 사용하지 않고 소프트웨어를 수동으로 테스트하는 것이 포함됩니다. 이 유형에서 테스터는 최종 사용자의 역할을 맡고 소프트웨어를 테스트하여 예기치 않은 동작이나 버그를 식별합니다. 단위 테스트, 통합 테스트, 시스템 테스트 및 사용자 승인 테스트와 같은 수동 테스트에는 여러 단계가 있습니다.

테스터는 테스트 계획, 테스트 케이스 또는 테스트 시나리오를 사용하여 소프트웨어를 테스트하여 테스트의 완전성을 보장합니다. 수동 테스트에는 테스터가 소프트웨어를 탐색하여 오류를 식별하는 탐색 테스트도 포함됩니다.

자동화 테스트

테스트 자동화라고도하는 자동화 테스트는 테스터가 스크립트를 작성하고 다른 소프트웨어를 사용하여 제품을 테스트하는 것입니다. 이 프로세스에는 수동 프로세스의 자동화가 포함됩니다. 자동화 테스트는 수동으로 빠르게 반복적으로 수행 된 테스트 시나리오를 다시 실행하는 데 사용됩니다.

회귀 테스트 외에도 자동화 테스트는 부하, 성능 및 스트레스 관점에서 애플리케이션을 테스트하는데도 사용됩니다. 수동 테스트에 비해 테스트 범위를 늘리고 정확도를 높이며 시간과 비용을 절약합니다.

무엇을 자동화해야합니까?

소프트웨어의 모든 것을 자동화하는 것은 불가능합니다. 사용자가 로그인 양식이나 등록 양식과 같은 거래를 할 수있는 영역, 많은 사용자가 동시에 소프트웨어에 액세스 할 수있는 영역은 자동화되어야합니다.

또한 수동 프로세스를 자동화하여 모든 GUI 항목, 데이터베이스와의 연결, 필드 유효성 검사 등을 효율적으로 테스트 할 수 있습니다.

언제 자동화해야합니까?

테스트 자동화는 소프트웨어의 다음 측면을 고려하여 사용해야합니다.

크고 중요한 프로젝트
동일한 영역을 자주 테스트해야하는 프로젝트
자주 변경되지 않는 요구 사항
많은 가상 사용자가로드 및 성능을 위해 애플리케이션에 액세스
수동 테스트와 관련하여 안정적인 소프트웨어
시간의 가용성

자동화하는 방법?

자동화는 VB 스크립팅 및 자동화 된 소프트웨어 응용 프로그램과 같은 지원 컴퓨터 언어를 사용하여 수행됩니다. 자동화 스크립트를 작성하는 데 사용할 수있는 많은 도구가 있습니다. 도구를 언급하기 전에 테스트 프로세스를 자동화하는 데 사용할 수있는 프로세스를 식별 해 보겠습니다.

자동화를위한 소프트웨어 내 영역 식별
테스트 자동화를위한 적절한 도구 선택
테스트 스크립트 작성
테스트 슈트 개발
스크립트 실행
결과 보고서 작성
잠재적 인 버그 또는 성능 문제 식별

소프트웨어 테스트 도구

다음 도구는 자동화 테스트에 사용할 수 있습니다.

HP 빠른 테스트 전문가
Selenium
IBM Rational 기능 테스터
SilkTest
TestComplete
어디서나 테스트
WinRunner
LoadRunner
Visual Studio 테스트 전문가
WATIR

소프트웨어 테스트에 사용할 수있는 다양한 방법이 있습니다. 이 장에서는 사용 가능한 방법에 대해 간략하게 설명합니다.

블랙 박스 테스트

응용 프로그램의 내부 작동에 대한 지식없이 테스트하는 기술을 블랙 박스 테스트라고합니다. 테스터는 시스템 아키텍처를 알지 못하며 소스 코드에 액세스 할 수 없습니다. 일반적으로 블랙 박스 테스트를 수행하는 동안 테스터는 입력을 제공하고 입력이 어디서 어떻게 작동하는지 알지 못해도 출력을 검사하여 시스템의 사용자 인터페이스와 상호 작용합니다.

다음 표에는 블랙 박스 테스트의 장점과 단점이 나열되어 있습니다.

장점	단점
큰 코드 세그먼트에 적합하고 효율적입니다.	선택한 수의 테스트 시나리오 만 실제로 수행되므로 제한된 범위입니다.
코드 액세스가 필요하지 않습니다.	테스터가 응용 프로그램에 대한 지식이 제한적이라는 사실 때문에 비효율적 인 테스트.
시각적으로 정의 된 역할을 통해 사용자 관점과 개발자 관점을 명확하게 구분합니다.	테스터가 특정 코드 세그먼트 또는 오류가 발생하기 쉬운 영역을 대상으로 할 수 없기 때문에 맹목적 범위.
적당히 숙련 된 다수의 테스터가 구현, 프로그래밍 언어 또는 운영 체제에 대한 지식 없이도 애플리케이션을 테스트 할 수 있습니다.	테스트 케이스는 설계하기가 어렵습니다.

화이트 박스 테스트

화이트 박스 테스트는 내부 논리와 코드 구조에 대한 자세한 조사입니다. 화이트 박스 테스트는glass testing 또는 open-box testing. 수행하기 위해white-box 응용 프로그램에서 테스트하려면 테스터는 코드의 내부 작업을 알아야합니다.

테스터는 소스 코드 내부를 살펴보고 부적절하게 작동하는 코드 단위 / 청크를 찾아야합니다.

다음 표는 화이트 박스 테스트의 장단점을 나열합니다.

장점	단점
테스터가 소스 코드에 대한 지식을 가지고 있으므로 애플리케이션을 효과적으로 테스트하는 데 도움이 될 수있는 데이터 유형을 쉽게 찾을 수 있습니다.	화이트 박스 테스트를 수행하려면 숙련 된 테스터가 필요하기 때문에 비용이 증가합니다.
코드 최적화에 도움이됩니다.	때로는 많은 경로가 테스트되지 않은 상태로 이동하므로 문제를 일으킬 수있는 숨겨진 오류를 찾기 위해 구석 구석을 조사하는 것이 불가능합니다.
숨겨진 결함을 가져올 수있는 추가 코드 줄을 제거 할 수 있습니다.	코드 분석기 및 디버깅 도구와 같은 특수 도구가 필요하기 때문에 화이트 박스 테스트를 유지하기가 어렵습니다.
코드에 대한 테스터의 지식으로 인해 테스트 시나리오 작성 중에 최대 범위에 도달합니다.

회색 상자 테스트

그레이 박스 테스트는 애플리케이션의 내부 작업에 대한 제한된 지식을 가지고 애플리케이션을 테스트하는 기술입니다. 소프트웨어 테스트에서 더 많이 알수록 응용 프로그램을 테스트하는 동안 많은 비중을 차지하는 것이 좋습니다.

시스템의 도메인을 마스터하면 테스터는 항상 제한된 도메인 지식을 가진 사람보다 우위를 차지할 수 있습니다. 테스터가 애플리케이션의 사용자 인터페이스 만 테스트하는 블랙 박스 테스트와 달리; 회색 상자 테스트에서 테스터는 설계 문서와 데이터베이스에 액세스 할 수 있습니다. 이 지식이 있으면 테스터는 테스트 계획을 세우면서 더 나은 테스트 데이터와 테스트 시나리오를 준비 할 수 있습니다.

장점	단점
가능한 경우 블랙 박스 및 화이트 박스 테스트의 결합 된 이점을 제공합니다.	소스 코드에 대한 액세스를 사용할 수 없기 때문에 코드 및 테스트 범위를 검토하는 기능이 제한됩니다.
그레이 박스 테스터는 소스 코드에 의존하지 않습니다. 대신 인터페이스 정의 및 기능 사양에 의존합니다.	소프트웨어 설계자가 이미 테스트 케이스를 실행 한 경우 테스트가 중복 될 수 있습니다.
사용 가능한 제한된 정보를 기반으로 회색 상자 테스터는 특히 통신 프로토콜 및 데이터 유형 처리와 관련된 우수한 테스트 시나리오를 설계 할 수 있습니다.	가능한 모든 입력 스트림을 테스트하는 것은 비합리적인 시간이 걸리기 때문에 비현실적입니다. 따라서 많은 프로그램 경로가 테스트되지 않습니다.
테스트는 디자이너가 아닌 사용자의 관점에서 수행됩니다.

테스트 방법 비교

다음 표에는 블랙 박스 테스트, 그레이 박스 테스트 및 화이트 박스 테스트를 구분하는 포인트가 나열되어 있습니다.

블랙 박스 테스트	회색 상자 테스트	화이트 박스 테스트
애플리케이션의 내부 작동을 알 필요는 없습니다.	테스터는 애플리케이션의 내부 작동에 대한 지식이 제한적입니다.	테스터는 애플리케이션의 내부 작업에 대한 완전한 지식을 가지고 있습니다.
폐쇄 형 테스트, 데이터 기반 테스트 또는 기능 테스트라고도합니다.	테스터는 응용 프로그램 내부에 대한 지식이 제한되어 있으므로 반투명 테스트라고도합니다.	클리어 박스 테스트, 구조 테스트 또는 코드 기반 테스트라고도합니다.
최종 사용자와 테스터 및 개발자가 수행합니다.	최종 사용자와 테스터 및 개발자가 수행합니다.	일반적으로 테스터와 개발자가 수행합니다.
테스트는 외부 기대치를 기반으로합니다.-애플리케이션의 내부 동작을 알 수 없습니다.	테스트는 고급 데이터베이스 다이어그램과 데이터 흐름 다이어그램을 기반으로 수행됩니다.	내부 작업은 완전히 알려져 있으며 테스터는 그에 따라 테스트 데이터를 설계 할 수 있습니다.
철저하고 시간 소모가 가장 적습니다.	부분적으로 시간이 많이 걸리고 철저합니다.	가장 철저하고 시간이 많이 걸리는 테스트 유형입니다.
알고리즘 테스트에는 적합하지 않습니다.	알고리즘 테스트에는 적합하지 않습니다.	알고리즘 테스트에 적합합니다.
시행 착오 방법으로 만 수행 할 수 있습니다.	알려진 경우 데이터 도메인 및 내부 경계를 테스트 할 수 있습니다.	데이터 도메인과 내부 경계를 더 잘 테스트 할 수 있습니다.

테스트 과정에는 다양한 수준이 있습니다. 이 장에서는 이러한 수준에 대한 간략한 설명이 제공됩니다.

테스트 수준에는 소프트웨어 테스트를 수행하는 동안 사용할 수있는 다양한 방법이 포함됩니다. 소프트웨어 테스트의 주요 수준은 다음과 같습니다.

기능 테스트
비 기능 테스트

기능 테스트

이것은 테스트 할 소프트웨어의 사양을 기반으로하는 블랙 박스 테스트 유형입니다. 입력을 제공하여 애플리케이션을 테스트 한 다음 의도 한 기능을 준수해야하는 결과를 검사합니다. 소프트웨어의 기능 테스트는 시스템이 지정된 요구 사항을 준수하는지 평가하기 위해 완전한 통합 시스템에서 수행됩니다.

응용 프로그램의 기능을 테스트하는 동안 관련된 다섯 단계가 있습니다.

단계	기술
나는	의도 된 응용 프로그램이 수행 할 기능을 결정합니다.
II	애플리케이션 사양에 따라 테스트 데이터를 생성합니다.
III	테스트 데이터 및 애플리케이션 사양을 기반으로 한 출력입니다.
IV	테스트 시나리오 작성 및 테스트 케이스 실행.
V	실행 된 테스트 케이스를 기반으로 실제 결과와 예상 결과를 비교합니다.

효과적인 테스트 관행은 모든 조직의 테스트 정책에 적용된 위의 단계를 볼 수 있으므로 조직이 소프트웨어 품질과 관련하여 가장 엄격한 표준을 유지하는지 확인합니다.

단위 테스트

이러한 유형의 테스트는 테스트 케이스를 공식적으로 실행하기 위해 테스트 팀에 설정이 전달되기 전에 개발자가 수행합니다. 단위 테스트는 각 개발자가 소스 코드 할당 영역의 개별 단위에 대해 수행합니다. 개발자는 품질 보증 팀의 테스트 데이터와 다른 테스트 데이터를 사용합니다.

단위 테스트의 목표는 프로그램의 각 부분을 분리하고 개별 부분이 요구 사항 및 기능 측면에서 올바른지 보여주는 것입니다.

단위 테스트의 한계

테스트는 애플리케이션의 모든 버그를 포착 할 수 없습니다. 모든 소프트웨어 응용 프로그램에서 모든 실행 경로를 평가하는 것은 불가능합니다. 단위 테스트의 경우도 마찬가지입니다.

개발자가 소스 코드를 확인하는 데 사용할 수있는 시나리오 및 테스트 데이터의 수에는 제한이 있습니다. 모든 옵션을 다 사용한 후에는 단위 테스트를 중지하고 코드 세그먼트를 다른 단위와 병합 할 수밖에 없습니다.

통합 테스트

통합 테스트는 제대로 작동하는지 확인하기 위해 응용 프로그램의 결합 된 부분을 테스트하는 것으로 정의됩니다. 통합 테스트는 상향식 통합 테스트와 하향식 통합 테스트의 두 가지 방법으로 수행 할 수 있습니다.

Sr. 아니.	통합 테스트 방법
1	Bottom-up integration 이 테스트는 단위 테스트로 시작하여 모듈 또는 빌드라고하는 점진적으로 더 높은 수준의 단위 조합 테스트가 이어집니다.
2	Top-down integration 이 테스트에서는 가장 높은 수준의 모듈이 먼저 테스트되고 점진적으로 더 낮은 수준의 모듈이 이후에 테스트됩니다.

포괄적 인 소프트웨어 개발 환경에서는 일반적으로 상향식 테스트를 먼저 수행 한 다음 하향식 테스트를 수행합니다. 이 프로세스는 실제 상황을 모방하도록 설계된 시나리오에서 전체 애플리케이션에 대한 여러 테스트로 마무리됩니다.

시스템 테스트

시스템 테스트는 시스템 전체를 테스트합니다. 모든 구성 요소가 통합되면 지정된 품질 표준을 충족하는지 확인하기 위해 애플리케이션 전체를 엄격하게 테스트합니다. 이러한 유형의 테스트는 전문 테스트 팀에서 수행합니다.

시스템 테스트는 다음과 같은 이유로 중요합니다.

시스템 테스트는 애플리케이션이 전체적으로 테스트되는 소프트웨어 개발 라이프 사이클의 첫 번째 단계입니다.
응용 프로그램은 기능 및 기술 사양을 충족하는지 확인하기 위해 철저히 테스트됩니다.
응용 프로그램은 응용 프로그램이 배포 될 프로덕션 환경과 매우 가까운 환경에서 테스트됩니다.
시스템 테스트를 통해 비즈니스 요구 사항과 애플리케이션 아키텍처를 모두 테스트, 확인 및 검증 할 수 있습니다.

회귀 테스트

소프트웨어 응용 프로그램이 변경 될 때마다 응용 프로그램 내의 다른 영역이이 변경의 영향을 받았을 가능성이 높습니다. 회귀 테스트는 수정 된 버그로 인해 다른 기능이나 비즈니스 규칙 위반이 발생하지 않았는지 확인하기 위해 수행됩니다. 회귀 테스트의 목적은 버그 수정과 같은 변경으로 인해 애플리케이션에서 다른 오류가 발견되지 않도록하는 것입니다.

회귀 테스트는 다음과 같은 이유로 중요합니다.

변경된 애플리케이션을 테스트해야 할 때 테스트의 간격을 최소화합니다.
새로운 변경 사항을 테스트하여 변경 사항이 응용 프로그램의 다른 영역에 영향을주지 않았는지 확인합니다.
애플리케이션에서 회귀 테스트를 수행 할 때 위험을 완화합니다.
타임 라인을 훼손하지 않고 테스트 범위가 증가합니다.
제품 마케팅 속도를 높입니다.

수락 테스트

이것은 응용 프로그램이 의도 한 사양을 충족하고 고객의 요구 사항을 충족하는지 여부를 측정하는 품질 보증 팀에서 수행하므로 가장 중요한 유형의 테스트입니다. QA 팀은 애플리케이션을 테스트하는 데 사용되는 사전 작성된 시나리오 및 테스트 케이스 세트를 갖게됩니다.

응용 프로그램에 대한 더 많은 아이디어가 공유되고 그 정확도와 프로젝트가 시작된 이유를 측정하기 위해 더 많은 테스트를 수행 할 수 있습니다. 수락 테스트는 단순한 철자 오류, 외관상의 오류 또는 인터페이스 차이를 지적 할뿐만 아니라 시스템 충돌 또는 애플리케이션의 주요 오류를 유발하는 애플리케이션의 버그를 지적하기위한 것입니다.

애플리케이션에 대한 승인 테스트를 수행함으로써 테스트 팀은 애플리케이션이 프로덕션에서 수행되는 방식을 줄입니다. 시스템 수락을위한 법적 및 계약 적 요구 사항도 있습니다.

알파 테스트

이 테스트는 테스트의 첫 번째 단계이며 팀 (개발자 및 QA 팀)간에 수행됩니다. 함께 결합 된 단위 테스트, 통합 테스트 및 시스템 테스트를 알파 테스트라고합니다. 이 단계에서 애플리케이션에서 다음과 같은 측면이 테스트됩니다.

맞춤법 오류
끊어진 링크
흐린 방향
애플리케이션은로드 시간과 지연 문제를 테스트하기 위해 사양이 가장 낮은 컴퓨터에서 테스트됩니다.

베타 테스트

이 테스트는 알파 테스트가 성공적으로 수행 된 후에 수행됩니다. 베타 테스트에서는 의도 된 대상의 샘플이 애플리케이션을 테스트합니다. 베타 테스트는pre-release testing. 소프트웨어의 베타 테스트 버전은 부분적으로는 프로그램에 "실제"테스트를 제공하고 부분적으로는 다음 릴리스의 미리보기를 제공하기 위해 웹의 광범위한 청중에게 이상적으로 배포됩니다. 이 단계에서 청중은 다음을 테스트합니다.

사용자는 응용 프로그램을 설치하고 실행하고 프로젝트 팀에 피드백을 보냅니다.
오타, 혼란스러운 응용 프로그램 흐름, 심지어 충돌까지 발생합니다.
피드백을 받으면 프로젝트 팀은 실제 사용자에게 소프트웨어를 출시하기 전에 문제를 해결할 수 있습니다.
실제 사용자 문제를 해결하기 위해 수정하는 문제가 많을수록 애플리케이션의 품질이 높아집니다.
일반 대중에게 출시 할 때 더 높은 품질의 애플리케이션을 보유하면 고객 만족도가 높아집니다.

비 기능 테스트

이 섹션은 비 기능적 속성에서 애플리케이션 테스트를 기반으로합니다. 비 기능적 테스트에는 본질적으로 작동하지 않지만 성능, 보안, 사용자 인터페이스 등과 같이 중요한 요구 사항에서 소프트웨어를 테스트하는 것이 포함됩니다.

중요하고 일반적으로 사용되는 비 기능 테스트 유형 중 일부는 아래에서 설명합니다.

성능 시험

소프트웨어에서 버그를 찾는 것보다 병목 현상이나 성능 문제를 식별하는 데 주로 사용됩니다. 소프트웨어 성능 저하에 기여하는 여러 원인이 있습니다.

네트워크 지연
클라이언트 측 처리
데이터베이스 트랜잭션 처리
서버 간 부하 분산
데이터 렌더링

성능 테스트는 다음 측면에서 중요하고 필수 테스트 유형 중 하나로 간주됩니다.

속도 (예 : 응답 시간, 데이터 렌더링 및 액세스)
Capacity
Stability
Scalability

성능 테스트는 정 성적 또는 정량적 일 수 있으며 다음과 같은 여러 하위 유형으로 나눌 수 있습니다. Load testing 과 Stress testing.

부하 테스트

큰 입력 데이터에 액세스하고 조작하는 소프트웨어 측면에서 최대 부하를 적용하여 소프트웨어의 동작을 테스트하는 프로세스입니다. 정상 및 최대 부하 조건에서 모두 수행 할 수 있습니다. 이 유형의 테스트는 소프트웨어의 최대 용량과 사용량이 많을 때의 동작을 식별합니다.

대부분의 경우 Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test 등과 같은 자동화 된 도구를 사용하여로드 테스트를 수행합니다.

가상 사용자 (VUsers)는 자동화 된 테스트 도구에 정의되고 스크립트가 실행되어 소프트웨어의 부하 테스트를 확인합니다. 사용자 수는 요구 사항에 따라 동시에 또는 점진적으로 늘리거나 줄일 수 있습니다.

스트레스 테스트

스트레스 테스트에는 비정상적인 조건에서 소프트웨어의 동작을 테스트하는 것이 포함됩니다. 예를 들어 일부 리소스를 제거하거나 실제 부하 제한을 초과하는 부하를 적용하는 것이 포함될 수 있습니다.

스트레스 테스트의 목적은 시스템에 부하를 적용하고 중단 점을 식별하기 위해 소프트웨어에서 사용하는 리소스를 인수하여 소프트웨어를 테스트하는 것입니다. 이 테스트는 다음과 같은 다양한 시나리오를 테스트하여 수행 할 수 있습니다.

네트워크 포트를 임의로 종료 또는 다시 시작
데이터베이스 켜기 또는 끄기
CPU, 메모리, 서버 등과 같은 리소스를 소비하는 다양한 프로세스 실행

사용성 테스트

사용성 테스트는 블랙 박스 기술이며 사용 및 운영을 통해 사용자를 관찰하여 소프트웨어의 오류 및 개선 사항을 식별하는 데 사용됩니다.

Nielsen에 따르면 사용성은 사용 효율성, 학습 가능성, 기억력, 오류 / 안전성, 만족도의 5 가지 요소로 정의 할 수 있습니다. 그에 따르면 제품의 사용성이 좋을 것이고 위의 요소를 가지고 있다면 시스템을 사용할 수있을 것이라고한다.

Nigel Bevan과 Macleod는 사용성이 컴퓨터 시스템과의 상호 작용의 결과로 측정 할 수있는 품질 요구 사항이라고 생각했습니다. 이 요구 사항은 충족 될 수 있으며 최종 사용자는 적절한 리소스를 사용하여 의도 한 목표를 효과적으로 달성하면 만족할 것입니다.

2000 년 Molich는 사용자 친화적 인 시스템은 배우기 쉽고 기억하기 쉽고 사용하기 쉽고 사용하기 만족스럽고 이해하기 쉬운 다섯 가지 목표를 충족해야한다고 말했습니다.

사용성에 대한 다양한 정의 외에도 ISO-9126, ISO-9241-11, ISO-13407 및 IEEE std와 같은 속성 및 하위 속성의 형태로 사용성을 정의하는 몇 가지 표준 및 품질 모델과 방법이 있습니다. 610.12 등

UI 대 사용성 테스트

UI 테스트에는 소프트웨어의 그래픽 사용자 인터페이스 테스트가 포함됩니다. UI 테스트는 GUI가 요구 사항에 따라 작동하는지 확인하고 색상, 정렬, 크기 및 기타 속성 측면에서 테스트됩니다.

반면 사용성 테스트는 쉽게 처리 할 수있는 우수하고 사용자 친화적 인 GUI를 보장합니다. UI 테스트는 사용성 테스트의 하위 부분으로 간주 될 수 있습니다.

보안 테스트

보안 테스트에는 보안 및 취약성 관점에서 결함과 차이를 식별하기 위해 소프트웨어 테스트가 포함됩니다. 다음은 보안 테스트가 보장해야하는 주요 측면입니다.

Confidentiality
Integrity
Authentication
Availability
Authorization
Non-repudiation
소프트웨어는 알려 지거나 알려지지 않은 취약점으로부터 안전합니다.
소프트웨어 데이터는 안전합니다.
소프트웨어는 모든 보안 규정을 따릅니다.
입력 확인 및 유효성 검사
SQL 삽입 공격
주입 결함
세션 관리 문제
교차 사이트 스크립팅 공격
버퍼 오버 플로우 취약점
디렉터리 탐색 공격

이식성 테스트

이식성 테스트에는 재사용 가능성을 확인하고 다른 소프트웨어에서도 이동할 수있는 소프트웨어 테스트가 포함됩니다. 다음은 이식성 테스트에 사용할 수있는 전략입니다.

한 컴퓨터에서 다른 컴퓨터로 설치된 소프트웨어 전송.
다른 플랫폼에서 소프트웨어를 실행하기 위해 실행 파일 (.exe)을 빌드합니다.

이식성 테스트는 시스템 테스트의 하위 부분 중 하나로 간주 될 수 있습니다.이 테스트 유형에는 다양한 환경에서의 사용과 관련하여 소프트웨어의 전체 테스트가 포함되기 때문입니다. 컴퓨터 하드웨어, 운영 체제 및 브라우저는 이식성 테스트의 주요 초점입니다. 이식성 테스트의 일부 전제 조건은 다음과 같습니다.

소프트웨어는 이식성 요구 사항을 염두에두고 설계 및 코딩되어야합니다.
관련 구성 요소에 대해 단위 테스트가 수행되었습니다.
통합 테스트가 수행되었습니다.
테스트 환경이 설정되었습니다.

테스트 문서에는 소프트웨어 테스트 전이나 테스트 중에 개발해야하는 아티팩트 문서가 포함됩니다.

소프트웨어 테스트에 대한 문서는 필요한 테스트 노력, 테스트 범위, 요구 사항 추적 / 추적 등을 추정하는 데 도움이됩니다.이 섹션에서는 다음과 같은 소프트웨어 테스트와 관련하여 일반적으로 사용되는 문서화 된 아티팩트 중 일부를 설명합니다.

테스트 계획
테스트 시나리오
테스트 케이스
추적 성 매트릭스

테스트 계획

테스트 계획은 응용 프로그램을 테스트하는 데 사용할 전략, 사용할 리소스, 테스트를 수행 할 테스트 환경, 테스트의 한계 및 테스트 활동 일정을 설명합니다. 일반적으로 품질 보증 팀장은 테스트 계획 작성을 담당합니다.

테스트 계획에는 다음이 포함됩니다.

테스트 계획 문서 소개
응용 프로그램을 테스트하는 동안 가정
애플리케이션 테스트에 포함 된 테스트 케이스 목록
테스트 할 기능 목록
소프트웨어를 테스트하는 동안 사용할 접근 방식
테스트해야하는 결과물 목록
애플리케이션 테스트를 위해 할당 된 리소스
테스트 프로세스 중 관련된 모든 위험
달성해야 할 작업 및 마일스톤 일정

테스트 시나리오

애플리케이션에서 테스트 할 영역을 알려주는 한 줄 문입니다. 테스트 시나리오는 모든 프로세스 흐름이 처음부터 끝까지 테스트되는지 확인하는 데 사용됩니다. 애플리케이션의 특정 영역은 애플리케이션의 규모와 복잡성에 따라 하나의 테스트 시나리오에서 수백 개의 시나리오까지 가질 수 있습니다.

'테스트 시나리오'와 '테스트 케이스'라는 용어는 같은 의미로 사용되지만 테스트 시나리오에는 여러 단계가있는 반면 테스트 사례에는 단일 단계가 있습니다. 이 관점에서 볼 때 테스트 시나리오는 테스트 사례이지만 여러 테스트 사례와 실행해야하는 순서가 포함됩니다. 이 외에도 각 테스트는 이전 테스트의 출력에 따라 다릅니다.

테스트 케이스

테스트 케이스에는 테스트 작업을 수행하는 동안 사용할 수있는 일련의 단계, 조건 및 입력이 포함됩니다. 이 활동의 주요 목적은 소프트웨어의 기능 및 기타 측면에서 소프트웨어가 통과 또는 실패하는지 확인하는 것입니다. 기능, 부정, 오류, 논리적 테스트 케이스, 물리적 테스트 케이스, UI 테스트 케이스 등과 같은 많은 유형의 테스트 케이스가 있습니다.

또한 소프트웨어의 테스트 범위를 추적하기 위해 테스트 케이스가 작성됩니다. 일반적으로 테스트 케이스 작성 중에 사용할 수있는 형식적인 템플릿은 없습니다. 그러나 다음 구성 요소는 항상 사용할 수 있으며 모든 테스트 케이스에 포함됩니다.

테스트 케이스 ID
제품 모듈
제품 버전
개정 내역
Purpose
Assumptions
Pre-conditions
Steps
예상되는 결과
실제 결과
Post-conditions

단일 테스트 시나리오에서 많은 테스트 사례가 파생 될 수 있습니다. 또한, 때때로 테스트 스위트로 통칭되는 단일 소프트웨어에 대해 여러 테스트 케이스가 작성됩니다.

추적 성 매트릭스

추적 성 매트릭스 (요구 사항 추적 성 매트릭스-RTM이라고도 함)는 소프트웨어 개발 수명주기 동안 요구 사항을 추적하는 데 사용되는 표입니다. 순방향 추적 (예 : 요구 사항에서 설계 또는 코딩으로) 또는 역방향 (예 : 코딩에서 요구 사항으로)에 사용할 수 있습니다. RTM에 대한 사용자 정의 템플릿이 많이 있습니다.

RTM 문서의 각 요구 사항은 관련 테스트 사례와 연결되어 있으므로 언급 된 요구 사항에 따라 테스트를 수행 할 수 있습니다. 또한 버그 ID도 포함되어 관련 요구 사항 및 테스트 사례와 연결됩니다. 이 매트릭스의 주요 목표는 다음과 같습니다.