static testing dynamic testing difference between these two important testing techniques
안드로이드에 APK 파일이 저장된 위치
테스트는 확인 및 검증 . 우리 모두는 테스트를 완료하는 데 2V가 필요하다는 것을 알고 있습니다.
오늘의 기사에서 우리는 정적 테스트 . 확인이라고도합니다. 우리는 그것에 대해 모든 것을 배우고 특별히 강조 할 것입니다. 동적 테스트 종종 최대의 관심을 받고 그것을 자세히 설명하는 수많은 기사가 있습니다.
그러나 정적 테스트에 대한 논의는 대응하는 동적 테스트의 의미에 대한 설명 없이는 완료되지 않습니다. 동적 테스트는 유효성 검사이고 다른 'V'입니다.
동적 테스트는 실제 시스템으로 작업하는 경우입니다 (일부 아티팩트 또는 시스템), 입력을 제공하고, 출력을 수신하고, 출력을 예상 된 동작과 비교합니다. 오류를 찾기 위해 시스템을 직접 사용합니다.
이 과정에서 우리는 테스트에 대한 다음 두 가지 일반적인 오해가 어떻게 사실이 아닌지 이해할 것입니다.
- 테스트는 끝에 오는 활동입니다.
- 테스터에 의해서만 수행되며 나머지는 할 일이 없습니다.
에 대한 빠른 참조부터 시작하겠습니다. V- 모델 :
- 에 왼쪽 방향 V-model의 경우 QA 팀에서 수행하지 않는 활동이 있습니다.
- 에 오른편 , 일부는 개발자 팀, 일부는 테스터, 일부는 사용자가 관리합니다.
시작하겠습니다. 요구 사항 수집 . 비즈니스 분석가 및 기타 상위 수준의 관리자가 수행합니다.이 단계의 출력 문서는 비즈니스 요구 사항 문서 인 BRD입니다.
다음 단계는 시스템 디자인 . 시스템 설계는 비즈니스 요구 사항이 FRD (기능 요구 사항 문서)에서 기능 요구 사항으로 변환되는 단계입니다.
번역이 진행되면 Dev 팀 (이 단계의 주요 행위자)은 BRD 문서를 한 페이지 씩, 한 줄씩 검토 할 것입니다. 주요 목표는 번역을 위해 비즈니스 요구 사항을 소비하는 것이지만 BRD 문서는 차례로 검토되고 있습니다.
예: 이것이 보안이 큰 은행 사이트의 BRD라고 가정 해보십시오. BRD에는 온라인 뱅킹 사이트에서 계정을 만드는 다양한 사용자의 암호 규칙에 대해 설명하는 섹션이 있습니다. 규칙 중 하나는 다음과 같습니다. 사용자는 다른 계정에 사용하는 비밀번호를 사용할 수 없습니다.
이것은 할 수 없습니다. 사이트는 사용자가 로그인 자격 증명을 설정하는 방법을 제안 할 수 있지만 방법이 없기 때문에 이러한 제한이 적용될 수 있습니다. 따라서이 요구 사항은 실행 가능하지 않습니다. 즉, 소프트웨어를 통해 달성 할 수 없습니다.
이제이 예를 기반으로 다음 사항을 고려해 보겠습니다.
- 이 요구 사항이 구축 가능하지 않아서 테스트 할 수 없다는 (즉, 실행 가능하지 않음) 어떻게 결정됩니까? 은행 사이트가 있고 로그인 및 비밀번호를 설정 한 다음 이것이 불가능하다는 것을 알고 있습니까? 아니요, 우리는 BRD에 대한 검토와 물론 몇 가지 일반적인 비즈니스 감각을 기반으로합니다.
- 이 요구 사항을 테스트하고 있습니까? 물론이지만 순수하게 이론적, 개념적 의미를 기반으로하지만 실제 AUT (Application under Test)가 아닙니다.
- 이 테스트의 물리적 형태는 무엇입니까? -BRD에 대한 간단한 읽기 또는 공식 검토 또는 비즈니스 요구 사항에 대한보다 공식적인 타당성 분석.
오해로 돌아가서 :
- 누가 BRD에 대한이 검토를 수행합니까? – 대부분 제품 생성을 담당하는 개발 팀 및 기타 기술 팀입니다. 테스터가 아닙니다.
- 이 검토는 제품 생성이 끝날 때 진행됩니까? 아니요, 프로젝트 개발 초기 단계입니다. 따라서 끝이 아닙니다.
정적 테스트 기법 :
요약하면 정적 테스트는 다음 방법을 따르는 소프트웨어 테스트의 검증 부분입니다.
- 문서 검토
- 연습
- 검사
- 타당성 분석 또는 소프트웨어가 올바른지 여부를 결정하기위한 다른 형태의 분석
- 코드 검토
CSTE CBOK를 인용하려면 '검증은'올바른 시스템을 구축 했습니까? '라는 질문에 답합니다. 유효성 검사에서는 '우리가 시스템을 제대로 구축 했습니까?'라고 말합니다.
다음은 V- 모델의 왼쪽에서 발생하는 모든 정적 테스트 활동입니다.
| SDLC 단계 | 산출 | 확인 | 배우 |
|---|---|---|---|
| 비즈니스 요구 사항 수집 | BRD (비즈니스 요구 사항 문서) | 범위 문서 (있는 경우) | |
| 시스템 요구 사항 설계 | FRD (기능 요구서) | BRD 검토 / 확인 | 개발, 기술 팀 |
| 기술 요구 사항 설계 | TDD (기술 설계 문서) | FRD 검토 / 검증 | 개발, 기술 팀 |
| 디자인 (코드) | 암호 | TDD를 검토 / 확인합니다. 완전성, 형식 등을 위해 개발 팀의 코드 검토 | 개발, 기술 팀 |
노트 : 이 정보는 단계가 다소 유사 할 것이므로 개발 방법론을 따르는 프로젝트에 대해 추정 할 수 있습니다.
V 모델의 오른쪽에는 유효성 검사가 있습니다.
동적 테스트 기법 :
단위, 통합, 시스템 및 UAT 단계는 모두 개발의 다양한 단계에서 AUT에서 수행 할 테스트를 만드는 것입니다. 테스트가 다양한 종류의 요구 사항을 검증하는 것을 목표로하지만 모두 동일한 테스트입니다.
따라서 AUT에서 실행해야하는 테스트가 있고 그 출력이 테스트 결과 (성공 여부)를 결정하는 데 필요한 모든 형태의 테스트는 유효성 검사입니다.
직장에서 어려운 상황에 대처
이제 V 모델의 오른쪽 (RHS)에 검증이 전혀 없다는 것을 일반화해도 괜찮습니까? 내 대답은 아니오 야.
RHS의 각 단계에서 생성 된 모든 테스트는 테스트 생성 / 종료 단계에서 여러 번 검토됩니다. 테스트 문서 검토의 자세한 프로세스는 https://www.softwaretestinghelp.com/test-documentation-reviews/
RHS에서 :
- 테스트 및 코드는 개발자가 단위 / 통합 테스트 단계에서 검토합니다.
- 시스템 테스트는 문서화 중에 동료 검토를 거치고 완료되면 개발 팀과 비즈니스 분석가의 검토를 거칩니다.
- UAT 테스트는 UAT가 시작되기 전에 QA 팀과 사용자가 검토합니다.
결론
결론적으로 정적 테스트는 비즈니스 요구 사항 검토, 기능적 요구 사항 검토, 설계 검토, 코드 연습 및 테스트 문서 검토의 형태를 취하는 중요한 테스트 기술입니다. 테스터들만하는 것이 아니라 지속적인 활동입니다.
유효성 검사, 동적 테스트 부분은 더 실습이며 제품 자체에서 발생하며 아티팩트 나 제품 표현이 아닙니다. 테스트 케이스 / 조건 식별, 커버리지 고려 사항, 실행 및 결함보고의 훨씬 공식적인 프로세스는 모두 동적 테스트 방법을 표시합니다.
저자 정보 : 이 기사는 STH 팀원 Swati S가 작성했습니다.
정적 및 동적 테스트 주제에 대한 의견, 질문 및 경험을 공유하십시오.