ISTQB-CTFL Korean 無料問題集「ISTQB-Foundation Level Exam (ISTQB-CTFL Korean Version)」

（A）성능 테스트 도구가 제공하는 지원은 테스터가 부하 테스트를 실행하는 데 자주 활용됩니다.

（B）테스트 데이터 준비 도구가 제공하는 지원은 테스터가 자동화된 회귀 테스트 모음을 실행하는 데 자주 활용됩니다.

（C）버그 예측 도구가 제공하는 지원은 테스터가 발견한 버그를 추적하는 데 자주 사용됩니다.

（D）지속적인 통합 도구가 제공하는 지원은 테스터가 모델에서 테스트 케이스를 자동으로 생성하는 데 자주 활용됩니다.

（A）결정이 옳았습니다. 대부분의 버그는 동적 테스트 중에 식별하기가 더 쉽습니다.

（B）결정은 옳았습니다. 정적 테스트는 일반적으로 제품이 동적 테스트의 전체 주기를 거치도록 계획된 경우 중복됩니다.

（C）결정이 잘못되었습니다. 품질 보장은 동적 테스트를 수행한 후 정적 테스트를 수행해야 함을 명령합니다.

（D）결정이 잘못되었습니다. 정적 테스트는 개발 프로세스 초기에 결함을 발견하여 테스트 및 개발의 전체 비용을 줄일 수 있습니다.

（A）영향 분석에는 이전 SW 릴리스에서 오류를 감지한 테스트에 대해서만 회귀 테스트가 필요합니다.

（B）영향 분석은 수행해야 할 회귀 테스트의 양을 평가하는 데 사용됩니다.

（C）영향 분석과 회귀 테스트 사이에는 관계가 없습니다.

（D）영향 분석을 위해서는 새로 통합된 모든 프로그램 요소(새로운 기능)에 대한 회귀 테스트가 필요합니다.

（A）테스트 설계 사양

（B）프로젝트 계획

（C）요구사항 사양

（D）테스트 계획

（A）필요한 경우 최대 수의 결함을 포함하는 모듈의 개발 및 테스트를 담당하는 팀을 교체하고, 이것이 도움이 되지 않으면 더 많은 지식이 있는 사람으로 교체합니다.

（B）기존 회귀 테스트 모음이 적절한지 확인하고 필요한 경우 이를 확장하여 이전에 수정된 결함이 이후의 각 빌드에서 다시 테스트되도록 합니다.

（C）결함이 가장 많은 제품 모듈을 분석하고 이를 철저히 테스트하여 결함을 일회성 활동으로 수정합니다.

（D）기존 테스트 슈트를 자동화하여 각 테스트 실행에 소요되는 시간을 줄이고 사용 가능한 시간 내에 더 많은 테스트를 실행하여 결함이 발생할 가능성을 낮춥니다.

（A）오류

（B）실수

（C）오류

（D）실패

（A）검토의 목적과 범위가 정의되고, 검토할 작업 제품과 종료 기준도 정의됩니다.

（B）식별된 각 결함에 대해 별도의 결함 보고서가 생성되어 시정 조치를 추적할 수 있습니다.

（C）검토자들은 공동 회의에서 검토 중 발견된 이상을 분석하고 논의합니다.

（D）각 검토자는 개별 검토를 수행하여 이상점, 권장사항, 질문을 식별합니다.

（A）비기능적 테스트는 사용자 경험과 사용성에만 초점을 맞춥니다.

（B）수용 테스트 수준에서만 비기능 테스트를 수행합니다.

（C）시스템 테스트 수준부터 비기능 테스트를 수행합니다.

（D）비기능 테스트를 보안 테스트 및 성능 테스트로만 제한합니다.

（A）테스트 사분면을 사용하면 테스트 관리자는 잠재적인 제품 위험을 모든 이해 관계자에게 전달할 수 있습니다.

（B）테스트 사분면을 사용하면 테스트 관리자가 테스트 범위를 측정하고 모든 이해 관계자에게 전달할 수 있습니다.

（C）테스트 사분면을 사용하면 테스트 관리자가 모든 이해 관계자에게 테스트 유형을 구별하고 설명할 수 있습니다.

（D）테스트 관리자는 테스트 사분면을 사용하여 결함을 특정 유형의 테스트에 연결하여 결함의 우선순위를 지정할 수 있습니다.

（A）체크리스트 기반 테스트에는 사용자에게 중요한 사항과 소프트웨어가 실패하는 이유 및 방법에 대한 이해를 기반으로 하는 테스트 목록이 포함될 수 있습니다.

（B）체크리스트 기반 테스트는 사용성, 성능 및 보안 테스트를 포함한 비기능 테스트로 제한됩니다.

（C）체크리스트 기반 테스트는 인기가 있지만 일관성이 거의 없고 테스트 사례 개발에 대한 지침이 거의 없습니다.

（D）체크리스트 기반 테스트에는 테스트 조건의 자세한 목록에서 형식적인 테스트가 포함되어 있어 많은 반복성을 허용합니다.

（A）통합 테스트는 매우 중요한 테스트 수준이기 때문에 허용되지 않으며 i:를 무시하면 확실히 제품 품질이 좋지 않음을 의미합니다.

（B）조직이 테스트 수준을 변경할 수 없으므로 허용되지 않습니다. 이는 SDLC(소프트웨어 개발 수명 주기) 모델을 기반으로 선택되기 때문입니다.

（C）통합 테스트가 중요한 테스트 레벨 아크가 아니기 때문에 허용됩니다! 생략할 수 있습니다.

（D）테스트 대상 시스템의 컨텍스트에 따라 조직에서 남성 테스트 수준을 결정할 수 있으므로 허용됩니다.

（A）구성 관리 도구

（B）테스트 설계 도구

（C）모니터링 도구

（D）단위 테스트 프레임워크 도구

（A）진단 테스트를 실행하는 데 시간이 너무 많이 걸립니다.

（B）메모리 속도를 측정하는 진단 테스트가 실패했습니다.

（C）테스트 코드의 잘못된 구현으로 인해 진단 테스트가 실패했습니다.

（D）시스템 재설정 후 진단 테스트가 시작되지 않습니다.

（A）TDD 중에 생성된 자동화된 단위 테스트는 기술에 직접적으로 관련되므로 Q4 사분면에 분류됩니다.

（B）테스트 사분면의 번호가 높을수록 해당 사분면과 관련된 테스트의 중요성이 커집니다.

（C）탐색적 테스트는 Q3 사분면에 분류되며, 일반적으로 지속적인 통합 프로세스에 포함됩니다.

（D）BDD 및 ATDD 중에 생성된 자동화된 수용 테스트는 사분면 02에 분류됩니다.

（A）실패한 테스트이며 동일한 동작이 계속 발생하고 재현 가능한지 확인하기 위해 해당 테스트를 다시 실행하는 것을 목표로 합니다.

（B）결함이 수정되고 해당 테스트가 성공하면 해당 수정과 관련된 회귀 테스트를 실행할 수 있습니다.

（C）결함이 수정되고 다른 테스트 결과 해당 수정으로 인해 소프트웨어에 부작용이 발생하지 않는 것으로 확인됨

（D）테스트 결과에서 거짓 양성 결과가 없는지 확인하기 위한 자동화된 회귀 테스트 모음 실행

（A）모든 테스트는 자동화되어야 하며 모든 소프트웨어 변경 시 지속적인 통합 프로세스의 일부로 실행되어야 합니다.

（B）모든 테스트 수준에 대한 테스트 분석 및 설계는 코딩이 완료되고 모든 시스템 구성 요소를 테스트에 사용할 수 있게 되는 즉시 시작되어야 합니다.

（C）개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다.

（D）각 테스트 수준에는 소프트웨어 개발 라이프사이클 단계나 해당 테스트가 다루는 활동 유형과 일관성이 있는 고유한 테스트 목표가 있어야 합니다.

（A）테스트 케이스는 사용 사례의 시나리오를 실행하기 위해 화이트박스 테스트 기술을 사용하여 생성됩니다.

（B）사용성 등의 비기능적 요구사항을 기반으로 테스트 케이스를 도출합니다.

（C）테스트 사례는 기본, 예외, 대체 및 인간 사용자나 시스템과 관련된 오류 동작을 포함한 다양한 사용자 동작을 포괄하도록 설계되었습니다.

（D）테스트 케이스는 결함을 찾기 위해 사용자와 테스터 간의 쌍 테스트를 기반으로 파생됩니다.