무료 온라인 액세스 ISQI.CTFL_Syll_4.0.v2024-08-05.q39 모의 시험 (Page 2)

CTFL_Syll_4.0 문제 1

다양한 소프트웨어 개발 프로젝트에서 식별된 위험의 다음 예를 고려하십시오.
[나]. 웹 사이트의 일반 텍스트와 큰 텍스트 모두에 대한 대비 색상 비율이 해당 접근성 지침을 준수하지 않아 많은 사용자가 페이지의 내용을 읽기 어렵게 만듭니다.
[II]. 개발 공급업체가 소프트웨어 시스템을 제때에 제공하지 못하여 시스템 시스템 개발 프로젝트의 일부로 계획된 시스템 통합 테스트 활동이 크게 지연되었습니다.
[III]. 테스트 팀의 사람들은 효과적인 회귀 테스트 스위트의 생성을 허용하지 않는 테스트 자동화 전략에 필요한 테스트 수준에서 테스트를 자동화할 수 있는 충분한 기술이 없습니다.
[IV]. 웹 애플리케이션에서 신뢰할 수 없는 소스의 데이터는 적절한 입력 유효성 검사를 거치지 않으므로 애플리케이션이 여러 보안 공격에 취약해집니다. 다음 중 올바른 설명은 무엇입니까?

A. [I] 및 [III]은 제품 위험입니다. [II] 및 [IV]는 프로젝트 위험입니다.

B. [I] 및 [IV]는 제품 위험입니다. [II]와 [III]은 프로젝트 위험입니다.

C. [II], [III] 및 [IV]는 제품 위험입니다. [I]는 프로젝트 위험입니다

D. [IV]는 제품 위험입니다. [나]. [II]와 [III]은 프로젝트 위험입니다.

CTFL_Syll_4.0 문제 2

새로운 웹 앱은 풍부한 사용자 경험을 제공하는 것을 목표로 합니다. 기능 테스터로서 귀하는 몇 가지 기능 테스트를 실행하여 앱을 출시하기 전에 해당 앱이 요구 사항 사양 내에서 지원되는 장치로 나열되어 있는 여러 모바일 장치에서 올바르게 작동하는지 확인했습니다. 이러한 테스트는 애플리케이션과 상호 작용하는 유일한 사용자인 안정적이고 격리된 테스트 환경에서 수행되었습니다. 모든 테스트를 통과했지만 일부 테스트에서 다음 문제가 관찰되었습니다. 일부 모바일 장치에서만 이미지가 포함된 두 웹 페이지의 응답 시간이 매우 느렸습니다.
주어진 정보에만 기초하여, 다음 권장 사항 중 어느 것을 따르시겠습니까?

A. 문제를 관찰한 테스트를 실행하여 어떤 장치에 대한 자세한 정보를 제공하는 결함 보고서를 열어야 합니다.

B. 이 문제는 기능이 아닌 성능 효율성과 관련이 있습니다. 따라서 기능 테스터로서 모든 기능 테스트가 통과되었으므로 결함 보고서를 공개해서는 안 됩니다.

C. 문제가 관찰된 장치의 하드웨어 장비 불량으로 인해 문제가 발생할 가능성이 높으므로 결함 보고서를 열지 마십시오.

D. 결함 보고서를 열지 말고 문제를 관찰한 장치가 더 이상 지원되지 않아 요구 사항 사양에서 제거되어야 함을 테스트 관리자에게 알려서는 안 됩니다.

정답: A

설명
기능 테스터는 문제를 관찰한 테스트를 실행하여 어떤 장치에 대한 자세한 정보를 제공하는 결함 보고서를 열어야 합니다. 결함 보고서는 테스트 중에 발견된 결함의 발생, 성격 및 상태를 기록하고 추가 조사 및 해결을 위한 정보를 제공하는 문서입니다.
결함 보고서에는 결함 요약, 결함 설명, 결함 심각도, 결함 우선순위, 결함 상태, 결함 출처, 결함 카테고리, 결함 재현 단계, 결함 스크린샷, 결함 첨부 파일, 등등. 결함 보고서를 여는 것은 수행된 테스트 유형이나 수준에 관계없이 소프트웨어 시스템에서 결함을 발견한 테스터에게 좋은 습관입니다. 다른 옵션은 권장되지 않습니다. 그 이유는 다음과 같습니다.
이 문제는 기능이 아닌 성능 효율성과 관련되어 있지만 그렇다고 해서 기능 테스터로서 모든 기능 테스트를 통과했기 때문에 결함 보고서를 공개해서는 안 된다는 의미는 아닙니다. 성능 효율성은 응답 시간, 리소스 활용도, 처리량 등과 같은 명시된 조건에서 소프트웨어 시스템이 기능을 얼마나 잘 수행하는지를 측정하는 품질 특성입니다.
성능 효율성은 특히 다양한 장치와 네트워크에서 실행되는 웹 애플리케이션의 경우 사용자 경험의 중요한 측면입니다. 기능 테스트를 통과하여 소프트웨어 시스템이 기능 요구 사항을 충족하더라도 일부 장치에서 관찰되는 성능 문제는 여전히 소프트웨어 시스템의 사용자 만족도, 유용성, 안정성 및 보안에 영향을 미칠 수 있습니다.
따라서 기능 테스터로서 귀하는 성능 문제를 결함으로 보고하고 개발자나 성능 테스터가 이를 조사하고 해결하는 데 도움이 되도록 가능한 한 많은 정보를 제공할 책임이 있습니다.

CTFL_Syll_4.0 문제 3

Agile 프로젝트 반복의 일부로 수행된 2시간 동안의 중단 없는 테스트 세션에서는 테스터가 웹 애플리케이션의 특정 사용성 문제에 집중할 수 있도록 경험적 체크리스트가 사용되었습니다.
해당 세션 동안 테스터의 경험을 통해 생성된 비스크립트 테스트는 다음 테스트 사분면 중 어느 것에 속합니까?

A. 1분기

B. 2분기

C. 3분기

D. 4분기

정답: C

설명
2시간 동안의 테스트 세션 동안 테스터의 경험을 통해 생성된 비스크립트 테스트는 테스트 사분면 Q3에 속합니다. 테스트 사분면은 테스트 목표(테스트가 팀 지원 또는 제품 비평에 중점을 두는지 여부)와 테스트 기준(테스트가 기술 또는 비즈니스를 기반으로 하는지 여부)이라는 두 가지 차원을 기반으로 테스트 유형을 분류합니다. 테스트 사분면은 Q1, Q2, Q3 및 Q4로 표시되어 있으며 각 사분면은 단위 테스트, 승인 테스트, 유용성 테스트 또는 성능 테스트와 같은 다양한 테스트 관점을 나타냅니다. 테스트 사분면 Q3은 탐구 테스트, 사용성 테스트, 사용자 수용 테스트, 알파 테스트, 베타 테스트 등과 같이 비즈니스 관점에서 제품을 비판하는 목적을 가진 테스트 유형에 해당합니다. 주어진 시나리오는 테스터의 경험, 직관 및 웹 애플리케이션 학습을 기반으로 하며 사용자 인터페이스, 사용자 만족도, 사용자 만족도와 같은 몇 가지 특정 사용성 문제에 중점을 두기 때문에 탐색적 테스트 및 사용성 테스트의 예입니다. 피드백 등. 다음과 같은 이유로 다른 옵션이 올바르지 않습니다.
테스트 사분면 Q1은 단위 테스트, 구성 요소 테스트, 통합 테스트, 시스템 테스트 등과 같이 기술 관점에서 팀을 지원하는 목적을 가진 테스트 유형에 해당합니다. 이러한 테스트 유형은 일반적으로 다음을 수행하는 개발자 또는 테스터가 수행합니다. 소프트웨어 시스템의 소스 코드, 디자인, 아키텍처 또는 구성에 대한 액세스를 제공하며 다양한 통합 수준에서 소프트웨어 시스템의 기능, 품질 및 신뢰성을 검증하는 것을 목표로 합니다.
테스트 사분면 Q2는 기능 테스트, 승인 테스트, 스토리 테스트, 시나리오 테스트 등과 같이 비즈니스 관점에서 팀을 지원하는 목적을 가진 테스트 유형에 해당합니다. 이러한 테스트 유형은 일반적으로 다음을 수행하는 테스터 또는 고객이 수행합니다. 소프트웨어 시스템의 요구사항, 사양, 사용자 스토리 또는 비즈니스 프로세스에 대한 액세스를 제공하며 소프트웨어 시스템이 사용자와 이해관계자의 기대와 요구를 충족하는지 검증하는 것을 목표로 합니다.
테스트 사분면 Q4는 성능 테스트, 보안 테스트, 신뢰성 테스트, 호환성 테스트 등과 같이 기술 관점에서 제품을 비판하는 목적을 가진 테스트 유형에 해당합니다. 이러한 테스트 유형은 일반적으로 다음과 같은 자격을 갖춘 테스터 또는 전문가가 수행합니다. 소프트웨어 시스템의 도구, 지표, 표준 또는 벤치마크에 액세스하고 효율성, 보안, 신뢰성 또는 호환성과 같은 소프트웨어 시스템의 비기능적 측면을 평가하는 것을 목표로 합니다. 다양한 조건이나 환경에서 소프트웨어 시스템.
참고 자료: ISTQB CTFL(Certified Tester Foundation Level) v4.0 소스 및 문서:
ISTQB 인증 테스터 기초 레벨 강의 계획서 v4.0, 1.3.1장, 소프트웨어 개발 수명 주기 테스트 ISTQB 테스트 용어집 v4.0, 테스트 사분면, 탐색적 테스트, 유용성 테스트, 단위 테스트, 구성 요소 테스트, 통합 테스트, 시스템 테스트, 기능 테스트, 승인 테스트, 스토리 테스트, 시나리오 테스트, 성능 테스트, 보안 테스트, 신뢰성 테스트, 호환성 테스트

CTFL_Syll_4.0 문제 4

프로그램의 구성 요소 테스트 중에 100% 결정 적용 범위가 달성되면 다음 적용 범위 기준 중 100%도 보장되는 것은 무엇입니까?

A. 100% 오래된 전환 적용 범위

B. 100% 동등 클래스 적용 범위

C. 경계값 범위 100%

D. 100% 설명 적용 범위

정답: D

명령문 범위는 테스트 스위트1에 의해 실행되는 소스 코드의 실행 가능한 명령문의 비율을 측정하는 구조적 범위 측정법입니다. 결정 적용 범위는 테스트 도구 모음1에서 실행되는 소스 코드의 결정 결과(예: 분기 또는 조건)의 비율을 측정하는 또 다른 구조적 적용 범위 측정항목입니다. 의사결정 범위는 각 결정의 가능한 모든 결과를 테스트해야 하는 반면, 명령문 범위는 모든 명령문이 최소한 한 번 실행되어야 하기 때문에 명령문 범위보다 더 강력한 측정 기준입니다2. 따라서 테스트 스위트가 100% 결정 적용 범위를 달성하면 모든 분기 또는 조건의 모든 명령문이 실행되어야 하므로 100% 명령문 적용 범위를 달성한다는 의미이기도 합니다. 그러나 그 반대는 사실이 아닙니다. 100% 문 적용 범위는 100% 결정 적용 범위를 보장하지 않습니다. 왜냐하면 일부 분기나 조건에는 테스트 스위트에서 테스트되지 않은 여러 결과가 있을 수 있기 때문입니다2. 예를 들어 다음 의사코드를 고려해보세요.
if (x > 0) then print("양수") else print("비양수") end if
x = 1 및 x = -1로 이 코드를 실행하는 테스트 스위트는 두 print 문이 모두 실행되기 때문에 100% 문 적용 범위를 달성합니다. 그러나 x > 0 조건은 참과 거짓이라는 두 가지 결과로만 테스트되었기 때문에 100% 결정 적용 범위를 달성할 수는 없습니다. 세 번째 가능한 결과인 x = 0은 테스트 스위트에서 테스트되지 않았습니다. 따라서 테스트 스위트는 조건이나 분기의 잠재적인 버그나 오류를 놓칠 수 있습니다.
오래된 전환 적용 범위, 동등 클래스 적용 범위, 경계 값 적용 범위와 같은 다른 옵션은 100% 결정 적용 범위를 달성해도 100%가 보장되지 않습니다. 오래된 전환 커버리지는 테스트 스위트3에 의해 실행되는 상태 머신의 상태 간 전환 비율을 측정하는 구조적 커버리지 측정항목입니다. 등가 클래스 적용 범위는 테스트 도구 모음4에서 테스트되는 입력 또는 출력 값의 등가 클래스(또는 파티션) 비율을 측정하는 기능 적용 범위 메트릭입니다. 경계 값 적용 범위는 테스트 스위트4에서 테스트하는 입력 또는 출력 범위의 경계 값(또는 극값)의 백분율을 측정하는 또 다른 기능 적용 범위 측정항목입니다. 이러한 측정항목은 동작, 기능, 사양 등 테스트 중인 시스템의 다양한 측면을 기반으로 하기 때문에 의사결정 범위와는 별개입니다. 따라서 100% 의사결정 범위를 달성한다고 해서 이러한 지표 중 어느 것도 100% 달성한다는 의미는 아니며 그 반대도 마찬가지입니다. 참조 = ISTQB® 인증 테스터 기초 레벨 강의 계획서 v4.0, 소프트웨어 테스팅의 테스트 적용 범위 - Guru99, 구조적 적용 범위 측정법 - MATLAB & Simulink - MathWorks India, 소프트웨어 테스팅의 테스트 설계 적용 범위 - GeeksforGeeks.

CTFL_Syll_4.0 문제 5

테스트에서 실행된 코드 줄을 추적하여 효율성을 측정하는 테스트 유형은 무엇입니까?

A. 승인 테스트

B. 구조 테스트

C. 통합 테스트

D. 탐색적 테스트

정답: B

구조 테스트는 테스트에서 실행된 코드 줄을 추적하여 효율성을 측정하는 테스트 유형입니다. 화이트박스 테스트 또는 글래스박스 테스트라고도 하는 구조적 테스트는 소프트웨어의 내부 구조, 설계 또는 구현을 기반으로 합니다. 구조 테스트의 목적은 코드 경로, 분기, 명령문, 조건 또는 데이터 흐름을 실행하여 소프트웨어가 성능, 보안, 안정성 또는 유지 관리 가능성과 같은 지정된 품질 속성을 충족하는지 확인하는 것입니다. 구조적 테스트는 기능 적용 범위, 라인 적용 범위, 분기 적용 범위 또는 명령문 적용 범위와 같은 다양한 적용 범위 측정항목을 사용하여 테스트된 코드의 양을 확인하고 테스트되지 않았거나 도달할 수 없는 코드 부분을 식별합니다. 구조 테스트는 단위 테스트, 통합 테스트, 시스템 테스트 또는 승인 테스트와 같은 모든 테스트 수준에 적용될 수 있지만 테스터가 소스 코드에 액세스할 수 있는 하위 수준에서 더 일반적으로 사용됩니다.
다른 옵션은 테스트에서 실행된 코드 줄을 추적하여 효율성을 측정하는 테스트 유형이 아니기 때문에 올바르지 않습니다. 승인 테스트는 소프트웨어가 승인 기준과 사용자 요구 사항을 충족하는지 확인하는 테스트 유형입니다. 승인 테스트는 일반적으로 소프트웨어의 소스 코드나 기술 세부 사항에 액세스할 수 없는 최종 사용자나 고객이 수행합니다. 승인 테스트는 내부 구조나 구현보다는 소프트웨어의 기능, 유용성 또는 적합성에 더 관심이 있습니다. 통합 테스트는 소프트웨어 구성 요소 또는 하위 시스템이 예상대로 함께 작동하는지 확인하는 테스트 유형입니다. 통합 테스트는 일반적으로 구조적 및 기능적 테스트 기술을 모두 사용하여 구성 요소나 하위 시스템 간의 인터페이스, 상호 작용 또는 종속성을 확인할 수 있는 개발자 또는 테스터에 의해 수행됩니다. 통합 테스트는 개별 코드 라인보다는 소프트웨어의 통합 논리, 데이터 흐름 또는 통신에 더 관심이 있습니다. 탐색적 테스트는 동시 학습, 테스트 설계 및 테스트 실행을 포함하는 테스트 유형입니다. 탐색적 테스트는 일반적으로 창의성, 직관 또는 경험을 사용하여 소프트웨어를 탐색하고 결함, 위험 또는 개선 기회를 발견하는 테스터에 의해 수행됩니다. 탐색적 테스트는 내부 구조나 구현보다는 소프트웨어의 동작, 품질 또는 가치에 더 관심이 있습니다. 참조 = ISTQB CTFL(Certified Tester Foundation Level) v4.0 강의 계획서, 4장: 테스트 기술, 섹션 4.3: 구조 테스트 기술, 페이지 51-54; 1장: 테스트의 기초, 섹션 1.4: 소프트웨어 개발 수명주기 전반에 걸친 테스트, 11-13페이지; 3장: 정적 테스트, 섹션 3.4: 탐색적 테스트, 페이지 40-41.