Software Test Flashcards

Question 1

Q

소프트웨어 테스트 원리

Answer

A

⦿ SW 테스트의 정의 : SW 신뢰도 및 고객요구 만족도 향상을 위한 품질보증활동
⦿ 7가지 원리 (결완초집 살정오)
- 결함 존재만을 증명
- 완벽한 테스트 불가
- 개발 초기 테스트 시작
- 결함은 집중되어 존재
- 살충제 패러독스
- 정황 의존적
- 오류 부재의 궤변

Question 2

Q

소프트웨어 테스트 유형

Answer

A

정보획득 대상 : 화이트박스/블랙박스 테스트
실행여부 : 동적(화이트, 블랙), 정적(코드검사, 워크스루)
시각 : 검증, 확인
단계 : 단통시인설
목적 : 회안강성구

Question 3

Q

Verification

Answer

A

⦿ 활동대상 : 제품생산 활동(과정)
⦿ 목적 : 올바르게 생산하는가
⦿ 활동기간 : 각 단계별
⦿ 관점 : Internal (개발자)
⦿ 테스트 유형 : Inspection, Walkthrough

Question 4

Q

Validation

Answer

A

⦿ 활동대상 : 생산된 제품(결과)
⦿ 목적 : 제품이 올바른가
⦿ 활동기간 : 시작 및 종료 단계
⦿ 관점 : External (사용자)
⦿ 테스트 유형 : 단통시인설

Question 5

Q

단계별 테스트 유형

Answer

A

단위 테스트 : 개별 모듈 확인
통합 테스트 : 빅뱅, 상향식, 하향식, 샌드위치
시스템 테스트 : 기능, 비기능
인수 테스트 : 알파, 베타, 감마
설치 테스트 : 상호 연동 확인

Question 6

Q

단위 테스트

Answer

A

⦿ 정의 : 테스트 가능한 최소 단위 모듈을 기준으로 결함을 찾고, 기능을 검증하는 활동
⦿ 분야
- 인터페이스 : 입출력 매개변수
- 자료구조 : 자료형태
- 실행경로 : 조건, 루프
- 오류처리 : 오류 메시지
⦿ 절차 및 산출물
- 계획 : 단위 테스트 계획서
- 케이스 : Test Case/Oracle
- 수행 : 뮤테이션, 탐색적
- 보고 : 결과/수정 보고서

Question 7

Q

통합 테스트

Answer

A

⦿ 정의 : 최종 SW구성 시, 컴포넌트 및 인터페이스와 상호작용의 결함과 기능을 검증하는 활동
⦿ 유형
- 하향식 : Test Stub 이용
- 상향식 : Test Driver 이용
- 샌드위치 : 모듈 최소 단위 부터
- 빅뱅 : 전체 시스템 한번에

Question 8

Q

Test Driver

Answer

A

Bottom Up
하위 모듈 구동
Simulator
구현 어려움
초기 구조 파악 어려움

Question 9

Q

Test Stub

Answer

A

Top-Down
하위 모듈 대체
SetDebug
구현용이
테스트 비교적 어려움

Question 10

Q

시스템 테스트

Answer

A

⦿ 정의 : 사용자 요구사항 만족 여부를 기능 및 비기능 측면에서 테스트
⦿ 목적
- 요구사항 부합 여부 확인
- 가용성과 안전성 보장 여부 확인
- 중/장기적 운영위한 사전검증
⦿ 종류(회안강성구)
- 회복 : 자가 회복
- 안전 : 불법 SW 방지
- 강도 : 과부하
- 성능 : 응답시간, 처리량, 속도
- 구조 : 내부 논리적 복잡도

Question 11

Q

인수 테스트

Answer

A

⦿ 정의 : 기능/비기능 요구사항을 사용자가 직접 테스트, 개발 완료 증명
⦿ 목적 : 확신, 배포 가능성, 준수성(납기, 표준), 고객 피드백
⦿ 절차
- 준비 : 계획, 환경구축 (테스트 케이스/시나리오)
- 수행 : 테스트 수행, 오류 수정(테스트 수행 계획서)
- 평가 : 테스트 결과 요약, 검토, 승인 (테스트 결과 보고서)
- 시스템 모니터링 : 자원 사용량, 성능 보안 (시스템 테스트 보고서)
⦿ 주요 인수 기준
- 기능성, 성능
- 보안성, 안전성
- 인터페이스 품질
- 소프트웨어 품질

Question 12

Q

기능 테스팅

Answer

A

ISO 9126 : 기능성
목적 : 원하는 기능
특징 : 기능 만족 필수
사례 : 로그인, 권한, 조회
종속성 : 개발자 실력
기법 : 단위 테스트, 통합 테스트

Question 13

Q

비기능 테스팅

Answer

A

ISO 9126 : 신뢰성, 사용성, 효율성, 유지보수성, 이식성
목적 : 원하는 성능
특징 : 성능 만족 협의
사례 : 동접 100명 처리시 CPU 50%
종속성 : 솔루션, HW
기법 : 성능, 부하, 스트레스

Question 14

Q

확인 테스트 (Confirmation)

Answer

A

⦿ 정의 : 수정 활동이 성공적이었는지를 확인하기 위하여, 마지막으로 실행했을 때의 실패한 테스트 케이스를 다시 실 행하는 테스트. 재테스팅(Re-Testing)
⦿ 대상 : 결함이 발견된 후 수정된 소프트웨어
⦿ 목적 : 수정활동이 성공적이었는지를 확인하기 위함
⦿ 범위와 정도 : 실제 결함이 발견된 부분에 대해서만 테스팅, 수행 횟수는 리스크 분석 정보를 기반으로 결정
⦿ 적용 : 모든 테스트 레벨에서 수행가능
⦿ 방법 : 기존 실패한 테스트 케이스를 다시 실행

Question 15

Q

회귀 테스트 (Regression)

Answer

A

⦿ 정의 : 프로그램 수정으로 인해 숨어 있던 결함이 노출되지 않았는지, 또는 신규결함이 유입되지 않았는지 검증
⦿ 대상 : 변경된 소프트웨어 또는 관련이 있거나 전혀 관련이 없는 소프트웨어
⦿ 수행 : 소프트웨어 또는 실행환경이 변경되었을 때
⦿ 범위와 정도 : 이전에 정상동작했던 SW에서 결함을 발견하지 못해 야기될 수 있는 리스크에 바탕을 둠
⦿ 적용 : 모든 테스트 레벨에서 수행 가능
⦿ 방법 : 여러번 반복 수행되므로 자동화에 적합
⦿ 수행유형
- Retest All
- Selective Test
- Priority Test

Question 16

Q

리스크 기반 테스팅에서 Test 수준 적용 사례

Answer

A

STA(Severe) : Re-Testing 3회 / Full Regression Test
STTA(STrong) : Re-Testing 2회 / Full Regression Test
ITA(Intensive) : Re-Testing 1회 / Partial Regression Test
FTA(Fundamental) : Re-Testing 1회
장애로인한영향(왼쪽)
장애발생가능성(아래)

Question 17

Q

리뷰의 유형

Answer

A

비공식적 리뷰 : 페어 프로그래밍
기술적 리뷰 : 사전준비, 기술해결, 결함발견, 대안평가, 적합성 검토
워크쓰루 : 학습, 이해향상, 결함발견
인스팩션 : 훈련된 모더레이터, 사전준비, 결함발견, 개선활동수행

Question 18

Q

Inspection

Answer

A

(형주진계관회해)

형태 : 공식 (Formal)
주최자 : 프로젝트 팀
진행 : 진행자 (Moderator)
계획성 : 역할기반, 계획적
관심사 : 결함발견
회의록 : 기록자에 의한 공식 회의록 운영
해결책 : 논하지 않음

Question 19

Q

Walkthrough

Answer

A

형태 : 비공식 (Informal)
주최자 : 작성자 (코드, 문서)
진행 : 작성자 (Author)
계획성 : 비 계획적 미팅
관심사 : 결함발견 혹의 의견제안
회의록 : 작성자, 개발자의 메모성 기록
해결책 : 결함에 대해 의견 제안

Question 20

Q

성능 테스트

Answer

A

⦿ 개념
- 병목지점파악/튜닝
- 용량산정/시스템용량계획
⦿ 종류
1) 목적분류
- 단위 : 업무단위
- 복합 : 동시 사용자 및 가중치
- 임계 : 최대 성능
2) 방법분류
- 루프백 : 병목지점 도출
- 스파이크 : 트랜젝션 동시 실행
- 확장성 : 확장 계수 보장 여부
- 가용성 : HA, FT
⦿ 구성요소
- 조직 : 의뢰자, 관리자, 실행자, 인프라, 개발자
- 대상 : SW, 서버, 인프라
- 도구 : 자동화 도구, 부하 솔루션
- 스크립트 :  Shell, Batch
- 지표 : 전체/동시 사용자, 부하, 응답시간, 처리량
⦿ 절차
- 계획 : 목표성능, 테스트계획 수립
- 설계 : Workload 설계, TestCase 도출, Process 수립, Script 생성
- 실행 : 수행, 모니터링
- 보고 : 종합결과보고, 평가보고서 작성
⦿ 성능지표
1) CPU
- MIPS (Millions of Instructions Per Second)
- MFLOPS (Millions of Floating-Point Operations Per Second)
2) Network
- PPS (Packets Per Seconds)
- BPS (Bits Per Seconds)
3) HW Vendor
- TPMC (Transaction Per Minute Concurrent : 동접자 + 분당처리수)
4) Main Frame C/S
- TPS (Transaction Per Seconds)

Question 21

Q

Little’s Law

Answer

A

⦿ 정의 : 공간 내에 머무는 객체 수는 객체의 공간 유입량과 객체가 머무는 시간에 비례
⦿ 분석도 : TPS가 더 이상 증가하지 않고 완만하게 되는 시점이 그 시스템의 임계치
⦿ Little's Law를 적용한 분석방법
- 운영서버의 임계치 분석
- 튜닝 포인트 분석
- 향후의 성능 위험 요소 분석
- 튜닝의 향상 효과 분석
⦿ 성공적 테스트를 위한 고려사항
- 테스트 케이스 정의
- 테스트 계획 수립
- 테스트 조직 및 전문가 지원
- 제3자 테스트 수행

Question 22

Q

성능테스트 목표를 정하기 위한 Workload Metric

Answer

A

⦿ 정의 : 작업량(Workload)에 대한 정량적인 수치로써, 사용자 수에 따라 결정되는, 대상 시스템에 대한 성능 기준선(Baseline)
⦿ 평가 항목 및 지표
- 시간당 처리건수(TPH)
- 분당 최다 처리건수(TPM)
- 초당 최대 처리건수(TPS, 60초)
- 업무별 업무 가중치(비율%)
- 최대동시 사용자 수(명)
- 호출간격(초)

Question 23

Q

TPS (Transaction Per Second)

Answer

A

⦿ 정의 : 사용자의 요청(Request)에 대한 초당 처리된 트랜잭션의 건 수
⦿ 상관관계
- TPS-사용자 : 비례관계
- TPS-응답시간 : 반비례관계
⦿ TPS 계산방법
- Concurrent User = TPS * (Response Time + Think Time)
- TPS = Concurrent User / Request interval
- Active User = TPS * (Response Time)

Question 24

Q

성능 테스트 구성 용어

Answer

A

Named User(전체 사용자) = Concurrent User + 비접속자
Concurrent User(동시 사용자) = Active User + Inactive User
Response Time(응답 시간) = Round Trip Time + Queuing Time + Process Time
Think Time(사용대기 시간)
Request Interval = Response Time + Think Time

Question 25

Q

Loop Back Test

Answer

A

⦿ 정의 : 컴포넌트 성능시험
⦿ 방법 : 소스코드에 Loop Back 코드 삽입
⦿ 효과 : 아키텍처 측면 발전 방향 제시
⦿ 테스트 구성 : WEB-WAS-TP-DB 구성 시스템
⦿ 테스트 방법
- TP 호출하는 부분에 Loop Back Code 삽입
- WEB-WAS에 대한 성능 측정

Question 26

Q

Tier Test

Answer

A

⦿ 정의 : Tier에 직접 부하
⦿ 방법 : 각 Tier에 직접 부하
⦿ 효과 : Tier 별 성능 측정, 병목 지점 개선
⦿ 테스트 구성 : WEB-WAS-DB 구성 시스템
⦿ 테스트 방법
- WAS에 직접 부하 발생, DB에 직접 부하 발생
- WAS나 DB가 병목 구간 인지 확인

Question 27

Q

Spike Test

Answer

A

⦿ 정의 : 모든 사용자 일시 사용
⦿ 방법 : 정해진 시간에 대량 트랜잭션
⦿ 효과 : 시스템 리스소 변화량 검증 
⦿ 테스트 구성 : WEB-WAS-DB 구성 시스템
⦿ 테스트 방법
- 1,000명 사용자가 1분 이내 로그인 완료 여부
- 시스템 사용량은 95% 허용

Question 28

Q

테스트 도구

Answer

A

⦿ 테스트 자동화 도구의 분류 (SDLC)
1) 설계
- 명세기반 테스트 설계도구
- 코드기반 데트스 설계도구
- 테스트 관리 도구
2) 구현
- 정적분석 도구
- 리뷰 및 인스펙션 도구
- 커버리지 측정 도구
- 성능, 로드, 시뮬레이션 도구
- 테스트 수행도구
⦿ 테스트 자동화 지원도구 유형
1) 테스트 관리 지원도구
- 테스트 관리 도구
- 인시던트 관리 도구
- 요구사항 관리 도구
- 형상관리 도구
2) 테스트 설계 지원도구
- 테스트 설계 도구
3) 정적 테스팅 지원도구
- 정적 분석 도구
4) 동적 테스팅 지원도구
- 단위 테스트 도구
- 테스트 실행 도구
- 성능 테스트 도구
- 커머리지 측정 도구
- 동적 분석 도구
- 모니터링 도구
- 보안 도구

Question 29

Q

IEEE829

Answer

A

⦿ 테스트케이스 구성요소

식별자 : 추적성
테스트항목 : 테스트 대상
입력명세 : 입력값
출력명세 : 출력값
환경설정 : 테스트 베드
특수절차요구 : 프로세스
의존성기술 : 선/후관계

Question 30

Q

테스트 케이스 작성절차

Answer

A

(계자위요구방정타유)

테스트 계획 검토
자료 확보
위험평가 및 우선순위 지정
테스트 요구사항 정의
테스트 케이스 구조설계
테스트 방법 결정
테스트 케이스 정의
테스트 케이스 타당성 확인
테스트 케이스 유지보수

Question 31

Q

테스트 케이스의 요건

Answer

A

(정경반추적자자)

정확성
경제성
추적성
적합성
자립성
자정성

Question 32

Q

테스트 오라클

Answer

A

⦿ 정의 : 테스트 실행 결과가 올바른 결과인지를 판별할 수 있는 메커니즘
⦿ 특징 : 객관적 평가 제공, 제한된 검증, 수학적 기법
⦿ 유형
- 실제 오라클 : 모든 입력값 검증, 비용과다
- 샘플링 오라클 : 몇몇 입력값 검증, 특정값 만 검증
- 휴리스택 오라클: 샘플링 단점 극복
- 일관성 검사 오라클 : 수정전/수정후 실행 결과 비교

Question 33

Q

Test Harness

Answer

A

⦿ 개념 : 테스트를 지원하는 목적하에 생성된 코드와 데이터의 집합
⦿ 목적 : 테스트 프로세스의 자동화, 테스트 케이스의 실행, 테스트 결과 리포팅 작성
⦿ 구성요소
- Test Driver : Bottom Up 접근
- Test Stub; Top Down 접근
- Test Suites : 테스트 케이스의 집합
- Test Case : 자동화된 명세서
- Mock Object : 비슷한 기능의 가상 객체
⦿ 기대효과
- 생산성 증가
- 회귀 테스트 활용성 증가
- 품질 향상
- 어려운 조건속에 테스트 환경 제공

Question 34

Q

명세 기반 기법

Answer

A

⦿ 종류

동등분할 기법
경계값 분석
결정 테이블 테스팅
상태전이 테스팅
유스케이스 테스팅
분류트리 기법
페어와이즈 조합 테스팅
직교배열 테스팅

Question 35

Q

동등분할 기법

Answer

A

⦿ 정의 : 프로그램의 입력 도메인을 테스트케이스가 산출 될 수 있는 데이터의 클래스로 분류하는 방법
⦿ 예제
- x값이 0~100사이, 시험사례
- (x100)으로 분할
⦿ 특징
- 등가성 : 등가분할영역 확인
- 대표성 : 대표 입력값 적어도 한 개씩은 사용 보장
- 커버리지 : 특정 입력과 출력 커버리지 달성
- 재사용 : 다른 기법에서 입출력 데이터 사용가능
- 범용 : 모든 테스트 레벨에서 사용 가능

Question 36

Q

경계값분석 기법

Answer

A

⦿ 정의 : 일반적으로 많은 오류가 경계 값에서 발생하므로, 결함방지를 위해 경계값을 포함하는 테스트
⦿ 특징
- 경계값 : 최대/최소값
- 용이성 : 발견률 높고, 적용 쉬움
- 커버리지 : 동등분할의 확장
- 범용성 : 모든 테스트 레벨에 적용
⦿ 경계값 분석의 한계
- 동작에 대한 조합 테스트 부적합
- 입력 조합이 상호간에 독립적이라는 가정에서만 적합

Question 37

Q

결정 테이블 테스팅

Answer

A

⦿ 정의 : 조건과 행위의 모든 가능한 조합을 테스트하도록 설계하는 블랙박스 테스트 기법
⦿ 특징
- 조건과 행위 : 누락없는 테스트
- 복잡한 로직의 정의, 분석, 테스트에 효과적
- 모든 프로세스 수행 동작을 점검
- 구현 또는 명세의 잠재적 오류 발견
- 테스트 전략에 따른 조건 추가 제거가 용이
⦿ 구성요소
- 조건부(Condition) : 업무규칙 조건
- 행위부(Action) : 조건 조합 결과
⦿ 장점
- 논리적 모든 조합 생성 가능
- 효과적인 논리적 모순 발견
- 불완전한 요구사항의 결함 발견
⦿ 장점
- 작성에 많은 시간과 노력 필요
- 복잡한 시스템 적용시 논리적 실수 우려

Question 38

Q

상태전이 테스팅

Answer

A

⦿ 정의 : 시스템의 현재상황, 이전 이력의 변화에 따른 내용을 테스트
⦿ 특징
- 상태간 전이 표시
- 임베디드 소프트웨어 분야
⦿ 다이어그램
- 상태 : 이벤드 대기 모드 (원)
- 전이 : 다른 상태로 변경 (화살표)
- 이벤트 : 유발요인 (화살표 이름)
- 가드 : 이벤트 발생 조건 [조건/값]
- 액션 : 전이에 따른 동작 (화살표 이름/값 표시)
⦿ 설계방식
- 전형적인 상태
- 모든 상태
- 특정 상태 전이
- 불가능한 상태 전이
⦿ 목표
- 모델상의 결함 발견
- 구현상의 결함 발견

Question 39

Q

유스케이스 테스팅

Answer

A

⦿ 정의 : 유스케이스를 사용하는 Actor사이의 상호작용의 결함을 찾는 테스트 기법
⦿ 특징
- Use-case 검증
- 테스트 케이스 조기 작성
⦿ 흐름종류
- 기본흐름 : 반드시 발생하는 흐름
- 대체흐름 : 조건, 상황, 추가 흐름
⦿ 테스트 레벨에 따른 유스케이스 테스팅 방법
1) 컴포넌트 레벨
- 시나리오별 테스트 케이스
- 문장별 테스트 케이스
2) 시스템 레벨
- 활동기반 커버리지
- 전이기반 커버리지
- 경로기반 커버리지

Question 40

Q

분류 트리 기법

Answer

A

⦿ 정의 : 트리 구조로 분석 및 표현하고 이를 바탕으로 테스트 (블랙박스 형태, 명세가 없을 때에도 사용 가능, 비공식적 기법)
⦿ 특징
- 트리구조 시각화
- 중복누락 회피
- 복잡한 시스템 테스트 적합
- 초기 테스트 설계 활용
- 테스트 비용 추정 가능 : 트리 복잡도 근거
⦿ 테스트 케이스 생성 절차
1. 테스트 대상 분석
2. 분류 트리의 파라미터 결정
3. 각 파라미터의 세부 트리 구성
4. 각 파라미터 별 한 개 값 선택하고 해당 지점에 점으로 표시
5. ID 부여 및 기대결과 기술
6. 테스트 케이스 생성

Question 41

Q

페어와이즈 조합 테스팅

Answer

A

⦿ 정의 : 상대적으로 적은 양의 테스트 세트를 구성하여 결합을 찾고, 테스트에 대한 확신을 얻을 수 있는 테스트 방법

Question 42

Q

직교배열 테스팅

Answer

A

⦿ 정의 : 행뿐만 아니라 열까지 페어와이즈(서로 소)하게 테스트케이스를 구성하여 수행하는 테스트 기법
⦿ 특징
- 직교배열 기법 이용
- 모든 원소가 페어와이즈
- 비용 효율적

Question 43

Q

구조 기반 기법

Answer

A

⦿ 정의 : SW 시스템의 내부구조를 분석하여 테스트 수행하는 기법
⦿ 특징
- 테스트의 충분성 측정
- 명세기반기법 적용 후 사용
- 시스템 아키텍처 기반 수행
- 모든 테스트 레벨에서 수행 가능
⦿ 대상
- 컴포넌트 레벨 : 구문, 결정, 분기문, 코드
- 통합 레벨 : 콜트리
- 시스템 레벨 : 메뉴 구조, 비즈니스 프로세스, 웹페이지 구조
⦿ 유형
- 구문 : 실행된 구문이 몇 퍼센트인지 측정
- 결정 : 전체 조건식이 최소한 참 한번, 거짓 한번
- 조건 : 각 개별 조건식이 참 한번, 거짓 한번
- 조건/결정 : 전체 조건식의 결과가 참 한번, 거짓 한번. 각 개별조건식도 참 한번, 거짓 한번
- 변경 조건/결정 : 각 개별 조건식이 다른 개별 조건식에 무관하게 전체 조건식의 결과에 독립적으로 영향
- 다중 조건 : 모든 가능한 논리적 조합을 고려한 가장 강력한 논리적 수준의 100% 커버리지

Question 44

Q

경험 기반 기법

Answer

A

⦿ 정의 : 유사한 분야의 SW나 테스터의 과거 경함을 바탕으로 직감적으로 테스트하는 기법
⦿ 유형 (체탐오분)
- 체크리스트 기반 테스팅
- 탐색적 테스팅
- 오류추정
- 분류트리기법
⦿ 수행원리
- 제품 탐색 : 목적, 기능
- 테스트 설계 : 케이스 도출
- 테스트 실행 : 문제점 기록

Question 45

Q

탐색적 테스팅

Answer

A

⦿ 구성요소
- 테스트 차터 : 각 세션 임무
- 타임 박싱 : 각 세션 시간
- 테스트 노트 : 테스트 케이스
- 요약보고 : 간략보고
⦿ 설계와 수행
- 설계됨과 동시에 수행
- 기록은 옵션
⦿ 사용목적
- 대부분 비공식
- 테스트 실행 관리
⦿ 테스트케이스
- 계획, 설계, 실행 반복
⦿ 시간투자
- 문서, 검토 최소화
- 테스트 수행에 투자
⦿ 테스터 차이
- 테스터의 능력 활용 노력
⦿ 관계
- 테스트 설계자가 테스트
⦿ 방법
- 점진적, 주기적 테스팅

Question 46

Q

테스트게이스 기반 테스팅

Answer

A

⦿ 구성요소
- 계획서 : 인력, 일정, 환경
- 케이스 : 명세화 문서
- 시나리오 : 케이스 흐름
- 결과서 : 단위/통합 테스트
⦿ 설계와 수행
- 테스트 설계 후 기록
- 다른 테스터 수행 가능
⦿ 사용목적
- 문서화 기반 공식적 수행
- 테스트 설계 향상
⦿ 테스트케이스
- 실행 전 케이스 작성
⦿ 시간투자
- 문서작성, 검토에 많은 시간 소비
⦿ 테스터 차이
- 테스터 간의 차이 제거 노력
⦿ 관계
- 설계자와 테스터 다름
⦿ 방법
- 한번에 완벽한 테스팅

Question 47

Q

뮤테이션 테스트

Answer

A

⦿ 정의 : 정상 동작 프로그램에서 의도적으로 원시 부호(Source Code)를 변형(뮤턴트 삽입)을 하여, 동일한 입력 값으로 다른 결과를 출력시키는 Test Case를 선정하여, 테스트 케이스의 적합성 판단 및 신뢰성을 부여하는 기법 (테스트 케이스가 얼마나 잘 작성되어 있는지 평가)
⦿ 개념 : c=a+b; 라는 코드를 c=a-b; 로 수정 후 테스트 케이스를 돌려 실패한 테스트가 있는지 확인
⦿ 특징
- Test Case 선별
- 적합성 검증
⦿ 주요 연산자
1) 구조적 유형
- 상수 대치 : c -> c + 1
- 변수 대치 : A -> B
- 상수  변수
2) 객체지향적 유형
가. 상속성
- IHD(Inheritance Hiding variable Deletion)
- IOD(Inheritance Overriding Method Deletion)
- IOR(Inheritance) Overloading Method Rename
나. 다형성
- OMD (Overloading Method Deletion)
- PCD (Polymorphism Type Case Operator Deletion)
⦿ 뮤턴트 변환 연산자 : 속성, 서비스, 입력값, 출력값
⦿ 뮤테이션 테스팅의 유형
- Do Fewer : 샘플링
- Do Faster : 그루핑
- Do Smater : 분산
⦿ 수행시 고려사항
- 비버깅 병행검증
- 고가용성 적합
- 요구사항 검토

Question 48

Q

비버깅

Answer

A

⦿ 개념 : 의도적인 오류 코드를 삽입하고 테스트를 통해 잔존 오류를 도출하는 작업

⦿ 방법 : 기존 동작 로직을 변경하기 보다는 새로운 버그코드를 삽입

Question 49

Q

스모크 테스트

Answer

A

⦿ 정의 : 테스트 대상이나 제품의 빌드가 구축된 테스트 환경에서 테스트가 가능한지 여부를 판단하는 활동
⦿ 특징
- 테스트 환경을 테스트
- 제3자 테스트 팀 또는 개발팀 내의 테스트 팀이 수행
- 테스트 시나리오 없이 수행
- 디테일 한 테스트 수행 전 빌드의 정상적 health 체크를 위해 수행
⦿ 구성요소
- 메뉴얼 : HW, SW 메뉴얼
- 빌드 : Daily Build
- 테스터 : QA
- 분석정보 : 결함보고서
- 인프라 : 서버, 솔루션
⦿ 수행절차
- 사전준비 : 시스템구성도, 메뉴얼
- 빌드 : 프로그램, 패키지
- 수행 : 테스트 계획서
- 보고 : 테스트 결과서

Question 50

Q

Record & Replay 테스트

Answer

A

⦿ 개념 : 사용자의 입력과 외부 메시지로 구성되는 이벤트에 대해서 임베디드 소프트웨어가 정확히 대응하는 지를 테스트 하는 기법
⦿ 테스트 단계
가. Record
1) 기능 테스팅 캡쳐 시작
2) 이벤트 후킹
3) 이벤트 송신
4) 이벤트 저장
나. Replay
5) 기능 테스팅 재수행 시작
6) 이벤트 검색 및 변환
7) 이벤트 통신 전송
8) 이벤트 전달
9) 결과 전달

Question 51

Q

자료흐름 시험

Answer

A

⦿ 개념 : 프로그램 내에서 변수들이 값을 할당 받은 지점이나 사용된 지점에 따라 프로그램의 테스트 경로들을 선택하는 방법
⦿ 테스트 기준
- all-node : 모든 문장
- all-edge : 모든 결정, 분기
- all-defs : 변수
- all-p-use : 선언부
- all-c-use : 계산식
- all-c-use/some-p-use
- all-p-user/some-c-use
- all-uses : 모든 변수
- all-paths : 모든 경로

Question 52

Q

크라우드 소싱 테스트

Answer

A

⦿ 정의 : 광범위하게 분포된 다수의 사람들에게 사용하게 함으로써 피드백
⦿ 특징
- 크라우드소싱
- 페이-퍼-버그 모델
⦿ 프로세스
1) SW 테스트 의뢰
2) 의뢰 사전 분석
3) SW 테스트 실행
4) SW 테스팅 결과 분석
5) SW 테스팅 결과 보고

Question 53

Q

성능 검증 및 평가

Answer

A

성능 평가 기준 TPC와 SPEC
PoC
Pilot Test
BMT

Question 54

Q

PoC (Proof of Concept)

Answer

A

⦿ 개념 : 제품, 기술, 정보 시스템 등이 조직의 특수 문제 해결을 신현할 수 있다는 증명 과정
⦿ 목적
- 신기술 적용 또는 신제품에 대한 사전 검증
- 도입 위험완화 및 사용자 반응 확인
⦿ 효과
- 기술 인프라 구조의 우발적 사고를 막기 위한 통제실무의 일종 
⦿ 대상
- 단일제품 및 솔루션 평가
⦿ 범위
- 아직 출시되지 않은 신제품
- 단일 제품 및 솔루션
⦿ 수행
- 기업내부 조직, 수요자 의뢰
⦿ 절차
1) 일정계획 수립
2) PoC요청 및 수행
3) 결과 분석 및 평가
4) 도입 및 생산 의사결정
⦿ 산출물
- 솔루션 및 제품설명서, 분석서
- PoC계획서, 결과서
- 제품 도입에 대한 타당성 분석

Question 55

Q

PT (Pilot Test)

Answer

A

⦿ 개념 : 프로그램을 실제로 운용하기 전에 오류 또는 부족한 점을 찾기 위하여, 실제 상황과 유사한 조건에서 시험 가동하는 행위
⦿ 목적
- 시스템을 부분적으로 사용하여 각 부분적 시스템이 어느 정도까지 견딜 수 있는지를 확인
⦿ 효과
- 서비스 수행 전 모의 시험을 통해 발생할 수 있는 여러 변수들을 미리 파악/대응
⦿ 대상
- 원시 프로그램이나 시험 프로그램
⦿ 범위
- 신규 개발된 시스템 및 서비스 수행
⦿ 수행
- 서비스 운영 조직, 수요자 의뢰 
⦿ 절차
1) 일정계획 수립
2) Pilot 테스트 수행
3) 결과 분석 및 평가
4) 서비스 런칭 의사결정
⦿ 산출물
- 서비스 시나리오
- 테스트 결과서

Question 56

Q

BMT (Benchmark Test)

Answer

A

⦿ 개념 : 실제와 같은 상황의 동일한 시험 환경에서 한 개 또는 여러 개의 대표적인 비교 대상과 비교 시험을 반복하여 성능을 평가
⦿ 목적
- 다양한 제품 중 요구하는 기능지원, 성능 수준과 가격을 비교하여 최적의 제품선택
⦿ 효과
- 유사한 제품 선택의 기준 제시
⦿ 대상
- 유사 기능을 제공하는 제품
⦿ 범위
- 도입분야의 솔루션, 하드웨어
- 도입 어플리케이션, 소프트웨어
⦿ 수행
- 제3의 기관수행, 수요자 의뢰
⦿ 절차
1) RFP발송 및 참여업체 제안접수
2) 평가항목 도출 및 평가방법선정
3) 시험환경 구성 및 수행
4) 성능결과 분석 및 평가
5) 최적의 제품 선정
⦿ 산출물
- BMT 계획서
- 성능평가 결과서
- 제품선정 결과서

Question 57

Q

PoC, Pilot, BMT 간 진행순서

Answer

A

1) PoC : 신기술 사전검증
2) BMT : 제품/기능군간 성능비교
3) Pilot : 선정 제품/기능의 문제점 및 개선안 피드백

Question 58

Q

TPC (Transaction Processing Performance Council)

Answer

A

⦿ 정의 : OLTP 시스템의 처리 성능을 측정하는 성능평가 기준의 표준규격을 제정하기 위해 결성된 비영리 성능 평가 기관
⦿ 특징
- 시스템의 성능 처리율과 단위 처리율당 비용을 이용
- 초당 트랜잭션 처리율(tps)과 분당트랜잭션 처리율(tpmC)
- NW를 포함한 HW성능과 OS를 포함하는 SW성능을 종합해서 평가
- 벤치마크 결과를 성능치와 가격대 성능비로 표시
⦿ 평가기준
- TPC-C : OLTP, tmpC
- TPC-E : DB성능, tmpE
- TCP-H : 복합환경, QphH

Question 59

Q

SPEC (Standard Performance Evaluation Corporation)

Answer

A

⦿ 정의 : 최신의 컴퓨터 시스템을 위한 표준 벤치마크를 만들기 위해 HP, SUN 등 여러 컴퓨터 회사가 자금 지원 결과로 만들어진 비영리 성능평가 기관
⦿ 특징
- 초반(1989년)에는 프로세스 성능에 초점(SPEC89)
- CPU, Graphics/Workstation, Java Client/Server 등 평가 기준 제시
⦿ 평가기준
- SPEC CPU2006 : CPU
- SPEC JBB2005 : JVM, CG
- SPEC power_ssj2008 : 전력
- SPEC web2009 : 웹성능
- SPEC SOA : MW, DB, HW 성능

Question 60

Q

ISO/IEC 29119

Answer

A

⦿ 정의 : SW 개발 생명주기 전 과정에 걸쳐 SW테스팅의 체계적인 프로세스, 원리 및 가이드를 지원하기 위한 테스팅 프로세스와 관련 산출물에 대한 국제표준
⦿ 필요성
- 소프트웨어 테스팅 체계 정립
- 테스팅과 품질에 대한 인식 개선
⦿ 구성요소 (용프문기키)
- 용어와 개요
- 테스팅 프로세스
- 테스팅 문서화
- 테스팅 기법
- 키워드 기반 테스팅

Question 61

Q

TMMI

Answer

A

⦿ 정의 : CMM에서는 다루지 못한 테스트 활동에 대한 프로세스 능력을 평가하기 위해 개발된 모델
⦿ 특징
- 테스트 프로세스에 대한 체계적 접근 방법을 제공
- 테스트 프로세스의 성숙도 수준을 확인, 개선, 결과 측정 수단 제공
⦿ 구조(레테목 하활 구획 관계사)
1) 레벨
1-1) 테스팅 능력
1-2) 성숙도 목표
1-2-1) 성숙도 하부목표
1-2-2) 활동/임무/책임
1-2-2-1) 구현과 조직화
1-2-2-2) 핵심관심
1-2-2-2-1) 관리자
1-2-2-2-2) 개발자
1-2-2-2-3) 사용자/클라이언트
⦿ 성숙도 단계 (초정통관최)
- 초기
- 정의
- 통합
- 관리/측정
- 최적화
⦿ 한계점
- 설명이나 지침 없음
- 경험많은 리더 필요
- 인적 관리 부족, 장비, 체계, 테스트 베드 등 시험기반 시설 영역 미고려
- 단계적 표현 사용으로 조직전체의 프로세스 수준만 나타냄, 개선이 필요한 프로세스 영역별 수준이 나타나지 않음
⦿ 활용방안
- 내부 평가팀 : 테스팅 역량 측정
- 상위 관리층 : 역량 향상 계획
- 개발팀 : 역량 향상
- 사용자, 고객 : 역할 인지

Question 62

Q

TPI (Test Process Improvement)

Answer

A

⦿ 정의 : 핵심영역을 20개로 나누고 각 핵심영역 별로 2~4레벨로 평가하는 테스트 심사 프레임워크
⦿ 특징
- 실용적 지식과 경함 바탕
- 프로세스 성숙도(핵심영역) 제공
- 서로 다른 관점으로 관찰
- 제어 가능한 개선 단계 정의
⦿ 모델의 구조
1) 20개 핵심영역 : 서로다른 관점
2) Levels : 초기, 통제, 능률, 최적
3) Checkpoints(157개) : 평가근거
4) 개선제안 : 상위단계 위한
⦿ Key Areas
- 계획 : 전략, 일정, 산정 계획
- 훈련 : 훈련, 의사소통
- 환경/도구 : 자동화, 환경
- 절차 : 평가, 보고, 관리
- 기법 : 결함관리, 척도명세

Question 63

Q

SW 유지보수

Answer

A

⦿ 정의 : 소프트웨어 SDLC를 연장하기 위해 인수, 설치 이후 행해지는 모든 소프트웨어 공학적 작업
⦿ 중요성 : 개발 이후 가장 활용이 활발한 시점, 개발대비 비용, 기간이 더 많이 소요
⦿ 유지보수의 종류
1) 목적 (수완적예)
- 수정 유지보수 (오류)
- 완전 유지보수 (기능향상)
- 적응 유지보수
- 예방 유지보수
2) 시기 (계응정지)
- 계약 유지보수
- 응급 유지보수
- 정기 유지보수
- 지연 유지보수
3) 대상
- 데이터, 프로그램, 문서화, 시스템
⦿ 유지보수 절차
1) 유지보수 준비
- 유지보수 계획서
- 유지보수 절차서
- 문제해결 절차서
2) 유지보수 영향분석
- 수정사항 요청서 (CSR)
- 수정사항 검증결과
- 유지보수 대안
3) 시스템 유지보수
- 시스템 시험 및 평가기준서
- 시험결과 보고서
4) 유지보수 검토 및 승인
- 유지보수 검토결과
- 유지보수 승인결과
5) 소프트웨어 이전
- 이전 계획서
- 이전 결과 보고서
- 운영검토 결과
6) 소프트웨어 폐기
- 폐기 계획서
- 폐기 결과 보고서
⦿ CSR 처리절차
1. CSR 처리기준 정의
2. CSR 요청
3. 사전검토
4. 변경영향 분석회의
5. 접수
⦿ 유지보수 향상기법
- 분석 : 문서표준, 코딩규약, 테스트계획, 사용자/운영자매뉴얼
- 설계 : 아키텍처 스타일, 디자인 패턴, 표준개발 가이드 이용
- 구현 : 모듈화, 캡슐화, 주석달기
- 이행 : 형상관리, CMDB 연계

Question 64

Q

Lehman의 소프트웨어 변화의 원리

Answer

A

⦿ 개념
⦿ 정의 : SW유지보수를 어렵게 만드는 SW변화의 특성을 이해함으로써, 유지보수, 변경관리, 형상관리, 품질통제 시 주요한 대응 원리로 활용
⦿ 법칙
- 계속되는 변경
- 증가하는 복잡도
- 대형 프로그램의 진화
- 조직의 안정성
- 익숙함의 유지
- 계속적인 성장
- 품질 저하
- 피드백 시스템

Answer 65

A

⦿ 개념
- 사업을 종료한 날부터 일정기간의 범위에서 발생한 하자에 대해 담보책임
- 요구사항 변경 및 환경의 변화에 따른 기능변경은 미포함
⦿ 수행근거
- 본래 구축사업의 하자담보책임
⦿ 비용 : 무상
⦿ 보수형태
- 수정보수
⦿ 기간
- 계약 완료 후 산출물의 정상적인 상태를 충족하지 못하는 결함을 보수하기 위한 기간을 규정

Answer 66

A

⦿ 개념
- 개발 완료 후 계속하여 수정, 보완하고 이러한 작업을 통하여 소프트웨어의 수명을 연장 시켜주는 작업
⦿ 비용 : 유상
⦿ 보수형태
- 수정보수, 적응보수, 완전보수
⦿ 기간
- 범위와 내용에 따라 별도의 계약

Answer 67

A

⦿ 정의 : 소프트웨어의 품질향상을 위해 원래 기능을 유지하면서 설계디자인을 개선하는 활동
⦿ 목적
- 디자인 개선
- 가독성 향상
- 버그 식별
- 개발속도 향상
⦿ 절차
- 단일 리팩토링
- 테스트
- 작동확인
- 변경 적용 또는 Undo
⦿ 종류
- Extract Method
- Inline Method
- Inline Temp
- Replace Temp with Query
- Introduce Explaning Variable
- Split Temporary Variable
- Remove Assignments to Parameters
- Substitute Algorithm
- Replace Magic Number with Symbolic Constant
- Decompose Conditional
- Consolidate Conditional Expression
- Consolidate Duplicate Conditional Fragments
- Remove Control Flag
- Replace Nested Conditional with Guard Clauses
- Rename Method
- Add Parameter
- Remove Parameter
- Parameterize Method
- Replace Parameter with Explicit Methods
- Replace Parameter with Methods

Answer 68

A

⦿ 정의
- 그룹으로 함께 묶을 수 있는 코드조각이 있으면, 코드의 목적이 잘 드러나도록 메소드의 이름을 지어 별도의 메소드로 뽑아낸다
⦿ 수정전
void printOwing(double amount) {
   printBanner( );
   //상세정보표시
   System.out.println("name:" + _name);
   System.out.println("amount:" + amount);
⦿ 수정후
void printOwing(double amount) {
   printBanner( );
   printDetail(amount);
}

void printDetail(double amount) {
   System.out.println("name:" + _name);
   System.out.println("amount:" + amount);
}

Answer 69

A

⦿ 정의 : 메소드 몸체가 메소드의 이름 만큼이나 명확할 때는, 호출하는 곳에 메소드의 몸체를 넣고 메소드를 삭제하라
⦿ 수정전
int getRating( ) {
return (moreThanFiveLateDeliveries( )) ? 2 : 1;
}

boolean moreThanFilveLateDeliveries( ) {
   return _numberOfLateDeliveries > 5;
}
⦿ 수정후
int getRating( ) {
   return ( _numberOfLateDeliveries > 5) ? 2 : 1;
}

Answer 70

A

⦿ 정의 : 간단한 수식의 결과값을 가지는 임시변수가 있고, 그 임시변수가 다른 리팩토링을 하는데 방해가 된다면, 이 임시 변수를 참조하는 부분을 모두 원래의 수식으로 바꿔라
⦿ 수정전
double basePrice = anOrder.basePrice( );
return (basePrice > 1000);
⦿ 수정후
return (anOrder.basePrice( ) > 1000);

Answer 71

A

⦿ 정의 : 어떤 수식의 결과값을 저장하기 위해서 임시변수를 사용하고 있다면, 수식을 뽑아내서 메소드로 만들고, 임시변수를 참조하는 곳을 찾아 모두 메소드 호출로 바꾼다, 새로 만든 메소드는 다른 메소드에서도 사용될 수 있다
⦿ 수정전
double basePrice = _quantity * _itemPrice;
if (basePrice > 1000)
   return basePrice * 0.95;
else
   return baseprice * 0.98;
⦿ 수정후
if (basePrice( ) > 1000)
   return basePrice( ) * 0.95;
else
   return baseprice( ) * 0.98;

double basePrice( ) {
   return _quantity * _itemPrice;
}

Answer 72

A

⦿ 정의 : 복잡한 수식이 있는 경우에는, 수식의 결과나 또는 수식의 일부에 자신의 목적을 잘 설명하는 이름으로 된 임시변수를 사용하라
⦿ 수정전
if ((platform.toUpperCase( ).indexOf(“MAC”) > -1) &&
(browser.toUpperCase( ).indexOf(“IE”) > -1) &&
wasInitialized( ) && resized >0)
{
//작업…
}
⦿ 수정후
final boolean isMacOS = platform.toUpperCase( ).indexOf(“MAC”) > -1;
final boolean isIEBrowser = browser.toUpperCase( ).indexOf(“IE”) > -1;
final boolean wasResized = 0;

if (isMacOS &amp;&amp; isIEBrowser &amp;&amp; wasInitialized( ) &amp;&amp; wasResized) {
   //작업...
}

Answer 73

A

⦿ 정의 : 루프안에 있는 변수나 Collecting Temporary Variable도 아닌 임수변수에 값을 여러 번 대입 하는 경우에는, 각각의 대입에 대해서 따로따로 임시변수를 만들어라
⦿ 수정전
double temp = 2 * ( _height + _width);
System.out.println(temp);
temp = _height + _width;
System.out.println(temp);
⦿ 수정후
final double perimeter = 2 * ( _height + _width);
System.out.println(perimeter);
final double area = _height + _width;
System.out.println(area);

Answer 74

A

⦿ 정의 : 파라미터에 값을 대입하는 코드가 있으면, 대신 임시변수를 사용하도록 하라
⦿ 수정전
int discount( int inputVal, int quantity, int yearToDate) {
   if( inputVal > 50) inputVal -= 2;
   //~~~~~
}
⦿ 수정후
int discount( int inputVal, int quantity, int yearToDate) {
   int result = inputVal;
   if( inputVal > 50) result -= 2;
   //~~~~
}

Answer 75

A

⦿ 정의 : 알고리즘을 보다 명확한 것으로 바꾸고 싶을 때는 메소드의 몸체를 새로운 알고리즘으로 바꾼다
⦿ 수정전
String foundPerson(String[ ] people) {
for( int i=0; i

Answer 76

A

⦿ 정의 : 특별한 의미를 가지는 숫자 리터럴이 있으면, 상수를 만들고, 의미를 잘 나타내도록 이름을 지은 다음, 숫자를 상수로 바꾸어라
⦿ 수정전
double potentialEnergy ( double mass, double height ) {
return mass * 9.81 * hegith;
}
⦿ 수정후
double potentialEnergy ( double mass, double height ) {
return mass * GRAVITATIONAL_CONSTANT * hegith;
}
static final double GRAVITATIONAL_CONSTANT = 9.81;

Answer 77

A

⦿ 정의 : 복잡한 조건문(if-then-else)이 있는 경우, 조건, then부분, 그리고 else부분에서 메소드를 추출하라.
⦿ 수정전
if ( data.before (SUMMER_START) || data.after (SUMMER_END) )
charge = quantity * winterRate + winterServiceCharge;
else charge = quantity * _summerRate;
⦿ 수정후
if (notSummer(date))
charge = winterCharge(quantity);
else charge = summerCharge(quantity);

Answer 78

A

⦿ 정의 : 같은 결과를 초래하는 일련의 조건 테스트가 있는 경우, 그것을 하나의 조건 식으로 결합하여 뽑아내라
⦿ 수정전
double disabilityAmount( ) {
   if ( _seniority  12) return 0;
   if ( _isPartTime) return 0;
   // disability amout계산
⦿ 수정후
double disabilityAmount( ) {
   if ( isNotEligibleForDisability( )) return 0;
   // disability amout계산

Answer 79

A

⦿ 정의 : 동일한 코드 조각이 조건문의 모든 분기 안에 있는 경우, 동일한 코드를 조건문 밖으로 옮겨라.
⦿ 수정전
if ( isSpecialDeal( ) ) {
   total = price * 0.95;
   send( );
} else {
   total = price * 0.98;
   send( );
}
⦿ 수정후
if ( isSpecialDeal( ) ) {
   total = price * 0.95;
} else {
   total = price * 0.98;
}
send( );

Answer 80

A

⦿ 정의 : 일련의 boolean식에서 컨트롤 플래그 역할을 하는 변수가 있는 경우, break 또는 return을 대신 사용하라
⦿ 수정전
void checkSecurity(String[ ] people) {
   boolean found = false;
   for( int i=0; i

Answer 81

A

⦿ 정의 : 메소드가 정상적인 실행경로를 불명확하게 하는 조건 동작을 가지고 있는 경우, 모든 특별한 경우에 대해서 보호절(guard clause)을 사용하라
⦿ 수정전
double getPayAmount( ) {
   double result;
   if ( _isDead ) result = deadAmount( );
   else {
      if ( _isSeparated ) result = separatedAmount( );
      else {
         if ( _isRetired) result = retiredAmount( );
            else result = normalPayAmount( );
       }
   }
   return result;
}
⦿ 수정후
double getPayAmount( ) {
   if ( _isDead ) return deadAmount( );
   if ( _isSeparated ) return separatedAmount( );
   if ( _isRetired ) return retiredAmount( );
   return normalPayAmount( );
}

Answer 82

A

⦿ 정의 : 메소드의 이름이 그 목적을 드러내지 못하고 있다면 메소드의 이름을 바꿔라
⦿ 수정전
public String getTelephoneNumber( ) {
return (“(“ + _officeAreaCode + “)” + _ officeNumber);
}
⦿ 수정후
public String getOfficeTelephoneNumber( ) {
return (“(“ + _officeAreaCode + “)” + _ officeNumber);
}

Answer 83

A

⦿ 정의 : 어떤 메소드가 그 메소드를 호출하는 부분으로부터 더 많은 정보를 필요로 한다면, 이 정보를 넘길 수 있는 파라미터를 추가하라

Answer 84

A

⦿ 정의 : 파라미터가 메소드 몸체에서 더 이상 사용되지 않는다면, 그 파라미터를 제거하라.

Answer 85

A

⦿ 정의 : 몇몇 메소드가 메소드 몸체에 다른 값을 포함하고 있는 것을 제외하고는 비슷한 일을 하고 있으면, 다른 값을 파라미터로 넘겨 받는 하나의 메소드를 만들어라.
⦿ 수정전
void tenPercentRaise( ) {
   salary *= 1.1;
}
void fivePercentRaise( ) {
   salary *= 1.05;
}
⦿ 수정후
void raise( double factor ) {
   salary *= (1 + factor);
}

Answer 86

A

⦿ 정의 : 파라미터의 값에 따라서 다른 코드를 실행하는 메소드가 있다면, 각각의 파라미터 값에 대한 별도의 메소드를 만들어라
⦿ 수정전
void setValue( String name, int value) {
   if ( name.equals("height") ) _height = value;
   if ( name.equals("width") ) _width = value;
}
⦿ 수정후
void setHeight( int arg ) {
   _height = arg;
}
void setWidth( int arg ) {
   _width = arg;
}

Answer 87

A

⦿ 정의 : 메소드를 호출한 다음, 결과를 다른 메소드에 대한 파라미터로 넘기고 있다. 수신자(파라미터를 넘겨 받는 메소드) 또한 이 메소드를 호출 할 수 있다면, 그 파라미터를 제거하고 수신자가 그 메소드를 호출 하도록 하라.
⦿ 수정전
int basePrice = _quantity * _itemPrice;
discountLevel = getDiscountLevel( );
double finalPrice = discountedPrice( basePrice, discountedLevel );
⦿ 수정후
int basePrice = _quantity * _itemPrice;
double finalPrice = discountedPrice( basePrice );

Answer 88

A

⦿ 정의 : SW품질속성을 저해하는 리팩토링이 필요한 코드의 패턴 혹은 코드의 일부분
⦿ 유형
- Duplicated Cod : 중복된 코드
- Long Method : 너무 긴 메소드
- Large Class : 거대한 클래스
- Long Parameter List : 너무 많은 인수
- Divergent Change : 변경의 발산
- Shotgun Surgery : 변경의 분산
- Feature Envy : 속성 조작의 부적절한 관계
- Data Clump : 데이터 덩어리
- Primitive Obsession : 기본 데이터형의 집착
- switch 문 : 다수의 switch, if문
- Parallel Inheritance Hierarchies : 평형 상속 구조
- Lazy Class : 게으름뱅이 클래스
- Speculative Generality : 추측성 일반화
- Temporary Field : 일시적 속성
- Message Chains : 메시지의 연쇄
- Middle man : 중개자
- Inappropriate Intimacy : 부적절한 관계, is-a 가 아니면서 상속 사용
- Alternative Classes with Different Interface : 클래스의 인터페이스 불일치
- Incomplete Library Class : 미숙한 클래스 라이브러리
- Data Class : 데이터 클래스
- Refused Bequest : 상속 거부
- Comments : 코멘트

Answer 89

A

Multi-purpose column : 다목적 컬럼
Multi-purpose table : 다목적 엔티티
Redundant data : 중복 데이터
Tables with many columns : 너무 많은 컬럼
Tables with many rows : 너무 많은 데이터
Smart columns : 다기능 목적 컬럼
Fear to change : 변화에 소극적

Answer 90

A

구조 리팩토링 : 테이블 구조 변경
데이터 품질 리팩토링 : 값의 일관성 사용성 개선
참조 무결성 리팩토링 : 제약조건 추가
아키텍처 리팩토링 : 외부 프로그램 상호작용 개선
기능 리팩토링 : 프로시저, 트리거 개선 변경
변환 : 새로운 요소 추가

Answer 91

A

⦿ 정의 : 기 개발된 SW를 분석하고 재구조화하는 과정을 거친 후 검증된 컴포넌트를 재사용하여 SW위기 극복 및 생산성을 향상시키는 기법
⦿ 목표
- SW위기 극복
- SW개발 생산성 향상
- 유지보수 비용절감
- SW변경 요구 신속대처
⦿ 개념
- Reverse Engineering : 역공학
- Reengineering : 재공학
- Reuse : 재사용

Answer 92

A

⦿ 정의 : 물리적 수준의 소프트웨어 정보를 논리적인 소프트웨어 정보의 서술로 추출하는 프로세스
⦿ 유형
- 논리 역공학 : 코드 -> 추출 -> 설계
- 자료 역공학 : 데이터 전이, 이전
⦿ 프로세스
1) Dirty Source Code
2) Restructure Code
3) Clean Source Code
4) Extract Abstractions (Processing, Interface, Database)
5) Initial Specification
6 Refine &amp; Simplify
7) Final Specification

Answer 93

A

⦿ 정의 : 유지보수, 생산성, 품질향상을 위해 역공학을 통해 분석한 시스템을 최적화 설계로 다시 구성하는 프로세스 (역공학 + Change + 순공학)
⦿ 프로세스
1) 원시코드로 부터 정보 추출
2) 역 공학
3) 시스템의 향상과 검증
4) 순공학
5) 설계와 최적화
6) 원시코드의 생성
⦿ 적용기법
- 재구조화
- 재모듈화
- 의미론적 정보추출

Answer 94

A

⦿ 정의 : 이미 개발되어 그 기능, 성능 및 품질을 인정 받았던 소프트웨어의 전체 또는 일부분을 다시 사용
⦿ 효과
- 신뢰성, 확장성, 생산성, 사용성, 유지보수성, 적응성 향상
⦿ 활용기법
- Copy : 복사
- Pre-Processing : include
- Library : Library Link
- Package : 정적
- Object : 동적
- Generic : 다형성
- Object-Oriented : 상속, 다형성
- Component : 표준 조립

Answer 95

A

⦿ 정의 : SW 생명주기 전체 과정에서 만들어지는 각 단계별 산출물을 체계적으로 관리하여 SW품질 보증활동을 향상시키는 기법
⦿ 필요성
- 가시성 확보, 무결성 보장, 병렬 개발 가능, 표준준소
⦿ 기법 (계식통감기)
- 계획 수립
- 형상 식별
- 형상 통제
- 형상 감사
- 형상 기록
⦿ 구성요소(기형물버통)
- 기준선
- 형상항목
- 형상물
- 형상버전
- 형상통제위원회
⦿ 기준선 (기분설시제운)
- 계획 : 기능적 기준선
- 분석 : 분배적 기준선
- 설계 : 설계 기준선
- 구현 : 시험 기준선
- 시험 : 제품 기준선
- 운영 : 운영 기준선

Answer 96

A

⦿ 정의 : 모든 변경이 효율적이고 표준화된 방법과 절차가 사용되는 것을 보장하는 관리기법
⦿ 절차
- 변경 요청
- 변경 결정
- 단순 변경
- CAB/CCB 개최
- 긴급변경
- 일반변경
⦿ 고려사항
- 형상물 Ownership 명확화
- 비즈니스 연속성 IT 연속성 고려
- 시간척도 계산
- 변경 위험 사전 인지
- 복귀 전략
- 의사결정 증거문서

Answer 97

A

⦿ 정의 : 고객의 기대를 이해하고, 변경사항을 배포하고 설치하기 위한 관리활동
⦿ 절차
1) 개발환경
- 배포 정책 수립
- 배포 계획 수립
- SW설계/개발
2) 통제된 테스트 환경
- 릴리즈 구축 및 구성
- 릴리즈 목적 부합성 검사
- 정상 버전 인수
3) 운영환경
- 롤 아웃 계획 수립
- 의사소통 준비 및 훈력
- 배포 및 설치

Answer 98

A

⦿ 정의 : SW개발 시 코드와 라이브러리, 관련문서 등의 시간의 변화에 따른 변경을 관리하는 활동
⦿ 유형
1) 저장소유형
- 로컬 버전관리 : RCS
- 중앙 집중 버전관리 : CVS, SVN
- 분산형 버전관리 : Git, Mercurial
2) 공개유형
- 오픈소스 : CVS, SVN
- 상용소스 : PVCS, Clear Case

Answer 99

A

⦿ 개념
- 비정상적인 데이터를 무작위로 애플리케이션에 입력하여 에러를 유도하는 테스트
- 문제 발생 전에 보안취약점을 발견하여 대응하기 위한 방안으로 부각됨
- System Crash, DDoS 공격 조건들, 성능조차, 기타 보안취약점 발견 가능
⦿ 취약점 및 테스트 방법
1) Valid Case Fuzz Test
- 정상입력데이터 입력
- Fuzzer 와 DUT간 정상 응답 확인 목적
2) Invalid Case Skip Testing
- 비정상입력데이터 입력
- DUT가 비정상 입력을 처리 하지 못할 경우 그냥 Skip하고 다음 테스트 케이스 수행
3) Invalid Case Fail Testing
- 비정상입력데이터 입력
- DUT가 처리하지 못할 경우, 정상입력데이터를 통해 DUT응답 확인
- 응답을 수선하면 단순 Fail,
응답이 없을 경우 Crash 판정
- Fail, Crash가 계속 발생할 경우 보안 취약점으로 분류

Brainscape's Knowledge GenomeTM

Software Test Flashcards

Brainscape's Knowledge Genome^TM