dev + qa = hq sw dev + qa = hq sw

Q. 변이테스팅에 대해 틀린 것은? 더보기 A. 변이테스팅은 얼마나 많은 코드 구조가 커버됐는지 알 수 있다. (X) 변이 적절 점수는 테스트의 퀄리티를 보여준다. 점수가 높을수록, 테스크 케이스들의 퀄리티가 높다. (O) 변이는 변이로 인한 결과값과 오리지널 프로그램의 결과값의 구별할 수 있을 때 삭제된다.(O) Q. 변이테스팅에 대해 틀린 것은? 더보기 A. 변이 연산자는 변이가 컴파일 될 수 없도록 프로그램을 구문상변화(syntactic change)를 시킨다. (X) 변이테스팅에서 하나의 변이만 생설 할 수 있다. (X) 변이와 오리지널 프로그램은 구문상(syntactically)으로 다르다. (O) 변이 연산자는 구문상변화를 주지만, 결과변이(resulting mutant)는 구문상으로 맞아야하..

변이테스팅은, 테스트 세트의 적절함을 측정하는데 사용할 수 있는 하나의 방법이다. 솔루션 개발 - 테스트 케이스 생성 - 모두 통과 끝일까? 그 것만으로 충분하지 않다! 테스팅은 버그의 존재를 보는데 사용할 수 있지만, 버그가 존재하지 않다는 것을 증명하진 않는다. 적절함을 측정하려면 어떻게 해야할까? → 변이테스팅 변이테스팅에서는, 소프트웨어의 2번째 버전을 생성해야 한다. 에 변이(mutation)를 생성한다. 변이는 오리지널 버전과 이론적으로 똑같이 행동하지 않음 변이를 테스트한다. 테스트 실패 → 변이 발견! 많은 변이들을 생성하고, 각각의 변이들은 발견되고 종료된다. 좋은 테스트 케이스 = 테스트를 실행하고 모든 변이들이 발견됨 변이는 어떻게 만들까? 오리지널 버전의 한 줄에서 한 부분을 변경시..

Q. 구조 기반 기법은: 더보기 A. 화이트박스 테스팅이다. 구조 기반 기법은 코드의 내부 구조에 기반하여 테스트를 작성한다. Q. 구조 기반 기법에 대해 틀린 것은? 더보기 A. 테스팅의 목적은 버그가 없는 것을 확인하기 위해 100% 구조적 커버리지를 달성하는 것이다. (X) 대부분 상황에서, 구조적 커버리지가 100%를 되게 하는 것은 실행 불가능하다. (O) 구조적 테스팅은 화이트 박스 테스팅이다. (O) 구조적 커버리지 조건은 테스트의 적절함을 측정하기위해 코드의 구조를 사용한다. (O) 100% 커버리지는 방어적인(defensive) 프로그래밍으로 인해 불가능할 지도 모른다. 어떠한 구조적 커버리지 기준에서도 100% 커버리지를 달성하는 게 버그가 없다는 것이라고 확신하지 않는다.

구조 기반 기법은 화이트박스 테스팅 기법 중 하나 블랙박스 테스팅 코드나 내부 구조에 대한 지식없이 소프트웨어가 원하고 예상하는대로 작동하는지 테스트하는 방법 화이트박스 테스팅 코드, 내부 구조를 기반으로 테스트하는 방법 예. 코드 리뷰/검사, 페어 프로그래밍 코드 커버리지 모든 코드가 잘 실행되는지, if문의 true/false가 최소 한번씩은 실행되는지와 같은 컨셉 위주로 테스트 가능한 시나리오들을 모두 테스트하는 것은 가능하지도 or 실용적이지 않기 때문에 구조 기반 테스팅은 중요하다 → 주어진 시간내에 더 많은 테스트를 실행하는 것과 적절하게 사용되기 위해 충분한 테스트를 실행하지 않는 것을 고려하여, 타협해야한다. 절충하기 위해서는, 코드 커버리지 기준이 필요하다. 코드 커버리지 기준 - 구문(..

Q. Validation과 Verification의 차이점은: 더보기 A. Validation은 올바른 제품을 만들고 있는지를 확인하고, Verification은 제품을 올바르게 만들고 있는지 확인한다. V-모델에서, Validation은 사용자 필요조건 단계에서 계획되고, Verification은 사용자 스펙(specification) 단계에서 계획된다. Q. V-모델에 따르면, 시스템은 verification 단계를 지났다라는 것은 무슨 의미인가? 더보기 A. 시스템은 유닛 테스팅부터 verification 테스팅의 테스트들을 다 통과했으며, 이제 validation 테스팅을 위해 준비됐다. 시스템은 사용자로부터 행해지는 validation 테스팅을 위해 준비되었다. Q. V-모델에 따르면, 유효한(..

Validation 사용자의 만족에 따라 소프트웨어가 실행되는지 확인 사용자의 니즈를 충족시키는지 확인 "올바른 제품을 만들고 있는가?"에 대한 대답 니즈에 맞춘 설계 검증 명시된 요구사항들을 만족하는지 여부를 확인하기 위해 개발 단계 말 또는 중간에 구성요소나 시스템을 평가하는 프로세스 (IEEE/ANSI) 컴퓨터 기반 테스팅 - 실제적으로 소프트웨어를 실행 예. 하위 레벨 테스팅 (단위 테스팅, 통합 테스팅), 상위 레벨 테스팅 (사용성 테스팅, 기능 테스팅, 시스템 테스팅, 인수 테스팅) 동적 테스트 Verfication 소프트웨어가 명세와 일치하며 그에 따라 실행하는지 확인 "제품을 올바르게 만들고 있는가?"에 대한 대답 스펙, 설계에 맞춘 구현과정 검증 개발 단계의 산출물이 그 단계의 초기에 설..

Q. V 모델은: 더보기 A. 소프트웨어 개발에 있어서 다른 단계들을 적절한 테스팅 과정과 짝을 이루는 소프트웨어 개발 방법론이다. 테스팅 프레임워크는 프로그램의 각 부분에 테스트 케이스들이 정의되는 프로그램이다. 테스트 케이스들을 실행하면, 생성된 결과값이 예상된 결과값과 일치하는지 자동적으로 체크한다. Q. 시스템 디자인을 테스트하는 것은? 더보기 A. 모듈 테스팅 모듈 테스팅은 시스템의 디자인을 테스트한다. 모듈 설계(또는 디테일 설계)와 짝을 이룬다. Q. 시스템 설계서을 테스트하는 것은? 더보기 A. 검증(Verification) 테스팅 Verification 테스팅에서 시스템이 시스템의 설계서(시스템이 어떻게 사용자의 필요조건들을 맞출지에 대한 이해)를 잘 따라가고 있는지 확인한다.

V-모델 소프트웨어 개발의 주요 단계들(비즈니스 요구사항 명세화에서 배포까지)과 상응하는 테스트 레벨(인수 테스팅에서 유닛 테스팅까지) 사이의 일대일 대응 관계를 설명하는 순차적 개발 수명주기 모델. 폭포수 모델의 확장형. 요구사항(Requirements) 설계 사용자가 요구사항을 정의. 사용자의 언어로 작성된다. ↓ 검증(Validation) 요구사항과 솔루션이 일치하는지 확인하기 위해 사용되는 테스트들로 이루어진 한 세트. 인수 테스트(acceptance tests)라고도 한다. 인수 테스팅(acceptance testing): 시스템이 사용자의 필요 및 요구사항 및 비즈니스 프로세스 측면에서의 인수 조건을 만족하는지 확인하고 사용자, 고객, 기타 권한을 지닌 사람이 시스템의 인수 여부를 결정하기 위..