Software Test Flashcards

Question

Loop Back Test

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

(정경반추적자자) - 정확성 - 경제성 - 추적성 - 적합성 - 자립성 - 자정성

Answer 8

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

Answer 9

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

Answer 10

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

Answer 11

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

Answer 12

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

Answer 13

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

Answer 14

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

Answer 15

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

Answer 16

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

Answer 17

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

Answer 18

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

Answer 19

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

Answer 20

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

Answer 21

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

Answer 22

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

Answer 23

``` ⦿ 정의 : 정상 동작 프로그램에서 의도적으로 원시 부호(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 : 분산 ⦿ 수행시 고려사항 - 비버깅 병행검증 - 고가용성 적합 - 요구사항 검토 ```

Answer 24

⦿ 개념 : 의도적인 오류 코드를 삽입하고 테스트를 통해 잔존 오류를 도출하는 작업 | ⦿ 방법 : 기존 동작 로직을 변경하기 보다는 새로운 버그코드를 삽입

Answer 25

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

Answer 26

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

Answer 27

``` ⦿ 개념 : 프로그램 내에서 변수들이 값을 할당 받은 지점이나 사용된 지점에 따라 프로그램의 테스트 경로들을 선택하는 방법 ⦿ 테스트 기준 - 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 : 모든 경로 ```

Answer 28

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

Answer 29

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

Answer 30

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

Answer 31

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

Answer 32

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

Answer 33

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

Answer 34

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

Answer 35

``` ⦿ 정의 : 최신의 컴퓨터 시스템을 위한 표준 벤치마크를 만들기 위해 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 성능 ```

Answer 36

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

Answer 37

``` ⦿ 정의 : 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) 사용자/클라이언트 ⦿ 성숙도 단계 (초정통관최) - 초기 - 정의 - 통합 - 관리/측정 - 최적화 ⦿ 한계점 - 설명이나 지침 없음 - 경험많은 리더 필요 - 인적 관리 부족, 장비, 체계, 테스트 베드 등 시험기반 시설 영역 미고려 - 단계적 표현 사용으로 조직전체의 프로세스 수준만 나타냄, 개선이 필요한 프로세스 영역별 수준이 나타나지 않음 ⦿ 활용방안 - 내부 평가팀 : 테스팅 역량 측정 - 상위 관리층 : 역량 향상 계획 - 개발팀 : 역량 향상 - 사용자, 고객 : 역할 인지 ```

Answer 38

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

Answer 39

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

Answer 40

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

Answer 41

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

Answer 42

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

Answer 43

``` ⦿ 정의 : 소프트웨어의 품질향상을 위해 원래 기능을 유지하면서 설계디자인을 개선하는 활동 ⦿ 목적 - 디자인 개선 - 가독성 향상 - 버그 식별 - 개발속도 향상 ⦿ 절차 - 단일 리팩토링 - 테스트 - 작동확인 - 변경 적용 또는 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 44

``` ⦿ 정의 - 그룹으로 함께 묶을 수 있는 코드조각이 있으면, 코드의 목적이 잘 드러나도록 메소드의 이름을 지어 별도의 메소드로 뽑아낸다 ⦿ 수정전 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 45

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

Answer 46

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

Answer 47

``` ⦿ 정의 : 어떤 수식의 결과값을 저장하기 위해서 임시변수를 사용하고 있다면, 수식을 뽑아내서 메소드로 만들고, 임시변수를 참조하는 곳을 찾아 모두 메소드 호출로 바꾼다, 새로 만든 메소드는 다른 메소드에서도 사용될 수 있다 ⦿ 수정전 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 48

⦿ 정의 : 복잡한 수식이 있는 경우에는, 수식의 결과나 또는 수식의 일부에 자신의 목적을 잘 설명하는 이름으로 된 임시변수를 사용하라 ⦿ 수정전 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 && isIEBrowser && wasInitialized( ) && wasResized) { //작업... } ```

Answer 49

``` ⦿ 정의 : 루프안에 있는 변수나 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 50

``` ⦿ 정의 : 파라미터에 값을 대입하는 코드가 있으면, 대신 임시변수를 사용하도록 하라 ⦿ 수정전 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 51

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

Answer 52

⦿ 정의 : 특별한 의미를 가지는 숫자 리터럴이 있으면, 상수를 만들고, 의미를 잘 나타내도록 이름을 지은 다음, 숫자를 상수로 바꾸어라 ⦿ 수정전 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 53

⦿ 정의 : 복잡한 조건문(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 54

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

Answer 55

``` ⦿ 정의 : 동일한 코드 조각이 조건문의 모든 분기 안에 있는 경우, 동일한 코드를 조건문 밖으로 옮겨라. ⦿ 수정전 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 56

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

Answer 57

``` ⦿ 정의 : 메소드가 정상적인 실행경로를 불명확하게 하는 조건 동작을 가지고 있는 경우, 모든 특별한 경우에 대해서 보호절(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 58

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

Answer 59

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

Answer 60

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

Answer 61

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

Answer 62

``` ⦿ 정의 : 파라미터의 값에 따라서 다른 코드를 실행하는 메소드가 있다면, 각각의 파라미터 값에 대한 별도의 메소드를 만들어라 ⦿ 수정전 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 63

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

Answer 64

``` ⦿ 정의 : 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 65

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

Answer 66

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

Answer 67

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

Answer 68

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

Answer 69

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

Answer 70

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

Answer 71

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

Answer 72

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

Answer 73

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

Answer 74

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

Answer 75

``` ⦿ 개념 - 비정상적인 데이터를 무작위로 애플리케이션에 입력하여 에러를 유도하는 테스트 - 문제 발생 전에 보안취약점을 발견하여 대응하기 위한 방안으로 부각됨 - 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가 계속 발생할 경우 보안 취약점으로 분류 ```