메뉴

ISTQB 기초 수준 시험 샘플 종이 – III

  • 메인
  • 다른
  • ISTQB 기초 수준 시험 샘플 종이 – III

istqb foundation level exam sample paper iii

문제를 제거하기 위해 도구를 사용해보십시오

C ++ 병합 정렬 코드

1. 소프트웨어 테스트 활동이 시작되어야합니다.

ㅏ. 코드가 작성 되 자마자
비. 디자인 단계에서
씨. 요구 사항이 공식적으로 문서화되었을 때
디. 개발 라이프 사이클에서 가능한 한 빨리

ISTQB 기초 레벨 시험 샘플 종이-3

2. 사용자가 발견 한 결함의 원인은 다음과 같습니다.

ㅏ. 저품질 소프트웨어
비. 불량한 소프트웨어 및 불량한 테스트
씨. 불행
디. 테스트를위한 시간 부족

3. 소프트웨어를 출시하기 전에 테스트하는 주된 이유는 무엇입니까?

ㅏ. 출시 후 시스템이 작동 함을 보여주기 위해
비. 소프트웨어가 출시하기에 충분한 품질인지 결정
씨. 출시 전에 가능한 한 많은 버그를 찾으려면
디. 릴리스에 대한 위험 기반 결정에 대한 정보 제공

4. 다음 중 사실이 아닌 것은 무엇입니까?

ㅏ. 성능 테스트는 전체 시스템을 테스트하는 동안뿐만 아니라 단위 테스트 중에 수행 할 수 있습니다.
비. 합격 테스트에 반드시 회귀 테스트가 포함되는 것은 아닙니다.
씨. 검증 활동에는 테스터 (검토, 검사 등)가 포함되어서는 안됩니다.
디. 테스트 환경은 가능한 프로덕션 환경과 유사해야합니다.

5. 발견 된 결함을 개발자에게보고 할 때 테스터는 다음과 같아야합니다.

ㅏ. 정중하고 건설적이며 도움이되는
비. 버그가 수정되어야한다면“기능”이 아니라고 주장
씨. 비판에 반응하는 방식에 민감한 외교적
디. 무엇보다도

6. 테스트는 어떤 순서로 실행해야합니까?

ㅏ. 가장 중요한 테스트부터
비. 가장 어려운 테스트를 먼저 (고정에 최대 시간을 허용)
씨. 가장 쉬운 테스트부터 (초기 신뢰를주기 위해)
디. 그들이 생각하는 순서

7. 개발 수명주기 후반에 오류가 발견 될수록 수정하는 데 더 많은 비용이 듭니다. 왜?

ㅏ. 문서가 형편 없기 때문에 소프트웨어가 무엇을하는지 알아내는 데 시간이 더 걸립니다.
비. 임금이 오르고있다
씨. 결함은 더 많은 문서, 코드, 테스트 등에 내장되었습니다.
디. 해당 사항 없음

8. 사실이 아닌 블랙 박스 테스터

ㅏ. 기능 사양 또는 요구 사항 문서를 이해할 수 있어야합니다.
비. 소스 코드를 이해할 수 있어야합니다.
씨. 결점을 찾는 동기가 높음
디. 시스템의 약점을 찾기 위해 창의적입니다.

9. 테스트 설계 기법은

ㅏ. 테스트 케이스 선택 프로세스
비. 예상 출력을 결정하는 프로세스
씨. 소프트웨어의 품질을 측정하는 방법
디. 수행해야 할 작업을 테스트 계획에서 측정하는 방법

10. 테스트웨어 (테스트 케이스, 테스트 데이터 셋)

ㅏ. 요구 사항, 디자인 및 코드와 같은 구성 관리가 필요합니다.
비. 소프트웨어의 새 버전마다 새로 구성되어야합니다.
씨. 소프트웨어가 생산 또는 사용으로 출시 될 때까지만 필요합니다.
디. 릴리스의 일부를 구성하지 않으므로 문서화하고 주석을 달 필요가 없습니다.
소프트웨어 시스템

11. 사고 로깅 시스템

유일한 기록 결함
b는 제한된 가치입니다
c는 모든 사고가 포함 된 경우 테스트 중에 프로젝트 정보의 귀중한 소스입니다.
디. 테스트 팀만 사용해야합니다.

12. 더 나은 개발 방법으로 소프트웨어의 품질을 높이면 다음과 같은 방법으로 테스트 (테스트 단계)에 필요한 시간에 영향을 미칩니다.

ㅏ. 테스트 시간 단축
비. 변경 없음
씨. 테스트 시간 증가
디. 말할 수 없다

13. 커버리지 측정

ㅏ. 테스트와 관련이 없습니다
비. 테스트 완전성의 부분적인 척도
씨. 모든 소프트웨어에 대해 지점 적용 범위가 필수 여야합니다
디. 시스템 테스트가 아닌 단위 또는 모듈 테스트에만 적용 할 수 있습니다.

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

ㅏ. 테스트 시간이 다되었을 때.
비. 계획된 모든 테스트가 실행되었을 때
씨. 테스트 완료 기준이 충족되었을 때
디. 테스트 실행으로 결함이 발견되지 않은 경우

15. 다음 중 사실 인 것은 무엇입니까?

ㅏ. 컴포넌트 테스트는 블랙 박스, 시스템 테스트는 화이트 박스 여야합니다.
비. 테스트에서 많은 버그를 발견하면 소프트웨어의 품질에 대해 확신이 없어야합니다.
씨. 버그가 적을수록 테스트 결과가 더 좋았습니다.
디. 더 많은 테스트를 실행할수록 더 많은 버그를 찾을 수 있습니다.

16. 사용할 테스트 기술을 결정하는 데 중요한 기준은 무엇입니까?

ㅏ. 특정 기술을 얼마나 잘 아는가
비. 시험의 목적
씨. 기술이 애플리케이션 테스트에 얼마나 적합한 지
디. 기술을 지원하는 도구가 있는지 여부

17. 아래의 의사 코드가 프로그래밍 언어 인 경우 100 % 문 범위를 달성하려면 몇 개의 테스트가 필요합니까?

1. x = 3이면
2. Display_messageX;
3. y = 2이면
4. Display_messageY;
5. 기타
6. Display_messageZ;
7. 기타
8. Display_messageZ;

에. 하나
비. 두
씨. 삼
디. 4

18. 질문 17과 동일한 코드 예제를 사용하여 100 % 분기 / 의사 결정 범위를 달성하려면 몇 개의 테스트가 필요합니까?

에. 하나
비. 두
씨. 삼
디. 4

19 다음 중 비 기능 테스트 유형이 아닌 것은 무엇입니까?

ㅏ. 상태 전환
비. 유용성
씨. 공연
디. 보안

20. 다음 중 메모리 누수를 감지하는 데 사용하는 도구는 무엇입니까?

ㅏ. 상태 분석
비. 커버리지 분석
씨. 동적 분석
디. 메모리 분석

21. 다음 중 테스트와 관련된 표준이 아닌 것은 무엇입니까?

ㅏ. IEEE829
비. IEEE610
씨. BS7925-1
디. BS7925-2

22. 다음 중 구성 요소 테스트 표준은 무엇입니까?

ㅏ. IEEE 829
비. IEEE 610
씨. BS7925-1
디. BS7925-2

23 다음 중 참인 것은 무엇입니까?

ㅏ. 프로그램 사양의 오류는 수정하는 데 가장 많은 비용이 듭니다.
비. 코드의 오류는 수정하는 데 가장 비용이 많이 듭니다.
씨. 요구 사항의 결함은 수정하는 데 가장 많은 비용이 듭니다.
디. 설계상의 결함은 수정하는 데 가장 많은 비용이 듭니다.

24. 다음 중 통합 전략이 아닌 것은 무엇입니까?

ㅏ. 디자인 기반
비. 빅뱅
씨. 상향식
디. 위에서 아래로

25. 다음 중 블랙 박스 설계 기법은 무엇입니까?

ㅏ. 성명 테스트
비. 등가 분할
씨. 오류 추측
디. 유용성 테스트

26. 순환계 복잡성이 높은 프로그램은 거의 다음과 같습니다.

소프트웨어 테스트를위한 테스트 계획을 만드는 방법

ㅏ. 큰
비. 작은
씨. 쓰기 어려움
디. 테스트하기 어려움

27. 다음 중 정적 테스트는 무엇입니까?

ㅏ. 코드 검사
비. 커버리지 분석
씨. 유용성 평가
디. 설치 테스트

28. 다음 중 이상한 것은 무엇입니까?

ㅏ. 흰색 상자
비. 유리 상자
씨. 구조적
디. 기능의

29. 프로그램은 다음과 같이 숫자 필드의 유효성을 검사합니다.

10보다 작은 값은 거부되고 10에서 21 사이의 값은 허용되며 22보다 크거나 같은 값은 거부됩니다.

다음 입력 값 중 모든 등가 파티션을 포함하는 것은 무엇입니까?

에. 10,11,21
비. 3.20.21
씨. 3,10,22
디. 10,21,22

30. 질문 29와 동일한 사양을 사용하여 다음 중 MOST 경계 값을 다루는 것은 무엇입니까?

에. 9,10,11,22
비. 9,10,21,22
씨. 10,11,21,22
디. 10,11,20,21

위의 모든 질문에 대한 답변 :

질문 답변
1. d
2. b
3. d
4. c
5. d
6. a
7. c
8. b
9.
10. ~
11. c
12.
13. b
14. c
15. b
16. b
17. c
18. c
19. ~
20. c
21. b
22. d
23. c
24.
25. b
26. d
27. a
28. d
29. c
30. b

아래 링크에서이 샘플 문서를 PDF 형식으로 다운로드 할 수도 있습니다.
ISTQB 질문 용지 3

추천 도서

^