[실기] 소프트웨어공학(3/3)

 

최초 작성일: 2024-10-07

최종 작성일: 2024-10-07

목표 : 정처기 합격 및 CS 지식 쌓기

 

 

 

애플리케이션 테스트케이스 설계

1.    소프트웨어 테스트

(1)   개념 : 결함을 발견하기 위한 절차와 행위

(2)   필요성

오류 발견 관점

오류 예방 관점

품질 향상 관점

(3)   기본 원칙

테스팅은 결함을 찾아내는 활동

완벽한 테스팅은 불가능하다

테스팅은 개발 초기에 시작해야한다

테스팅 방법은 특정 상황에 의존적이다

결함 집중(defect clustering) : 파레토의 법칙 ( 결합의 80%는 20%의 핵심 모듈에서 발생)

살충제 패러독스 : 새로운 테스트 케이스 설계

오류-부재의 궤변 : 사용자의 요구사항을 충족하지 않으면 품질이 좋다고 할 수 없다

(4)   테스트 산출물

테스트 계획서

테스트 케이스

테스트 시나리오 – 테스트 케이를 엮은 것

테스트 결과서 – 잘했다 못했다

2.    테스트 오라클

(1)   개념

테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참값을 입력하여 비교하는 기법 및 활동

(2)   유형

참 오라클 : 모든 입력 값에 대해 결과를 생성하는 오라클

샘플링 오라클 : 제한된 입력 값들에 대해서만 결과 제공

휴리스틱 오라클 : 근사적인 (추정) 결과를 제공하는 오라클

일관성 검사 오라클  : 변경 전후로 테스트 결과의 일관성을 검증하는 오라클

3.    테스트 레벨 ( v)

단위 테스트 : 개발자, 정적 테스트(소스코드), 동적 테스트가 해당

통합 테스트 : 상향식(드라이버), 하향식(스텁) 테스트, 빅뱅 테스트, 백본 테스트(상향식+하향식)가 있음

시스템 테스트 : 기능 테스트, 비기능 테스트(안정성, 보안성, 효율성 등 품질 확인)

인수 테스트 : 알파 (개발자와 사용자가 같이 수행), 베타 테스트( 개발자 없이 사용자만)

4.    테스트 기법

(1)   프로그램 실행 여부

1)    정적 테스트

소스코드를 분석하여 문제점을 찾는 테스트 방식

종류

-코드검사: 코드의 오류를 검사

-워크스루: 개발자 검토 회의

-인스펙션: 검토 전문가들이 소스코드를 분석

2)    동적 테스트 : 소프트웨어를 실행하며 문제점을 찾는 테스트 방식

(2)   테스트 기법

1)    화이트 박스 테스트 : 소프트웨어의 내부 구조와 동작을 중점으로 검사하는 테스트

2)    화이트 박스 테스트 – 기법

문장 검증/선택(분기)검증/경로검증/조건검증

3)    기초 경로 검사 (basic path test) : McCabe가 제안한 것으로 대표적인 화이트 박스 테스트 기법

계산식 V(G) = Edge(선) -N(노드) +2

4)    블랙박스 테스트 : 프로그램의 사용자 요구사항 명세를 보면서 테스트

5)    블랙박스 테스트 – 기법

동등 분할 기법(Equivalence partitioning testing): 입력자료에 초점을 맞춘 테스트 (80~90 -> 85)

경계값 분석(Boundary Value Analysis) : 경계값을 테스트 케이스로 선정(80~90 -> 79, 91)

원인-효과 그래프 검사(Cause-Effect Graphing Testing) : 입력 데이터 간의 관계와 출력에 영향을 미치는 상황 분석

오류 예측 검사(error guessing): 과거의 경험이나 테스터의 감각으로 테스트하는 기법

비교 검사(comparison testing): 여러 버전의 프로그램에 동일한 자료를 제공

상태전이 검사(state transition testion): 상태를 변화시키는 이벤트와 입력값을 파악한다

(3)   테스트에 대한 시각

1)    검증(verification) : 소프트웨어의 개발 과정을 테스트

2)    확인(validation) : 완성된 소프트웨어의 결과를 테스트

(4)   테스트의 목적

회복 : 고의로 실패를 유도

안전: 보안적인 결함을 점검

강도(stress): 과부하 테스트

성능:응답하는 시간, 처리량, 반응속도등

구조: 소스코드의 복잡도를 평가

회귀(regression): 변경코드에 대해 새로운 결함 여부 평가

병행 : 변경된 시스템과 기존 시스템에 대한

a/b 테스트 : 기존 서비스 대비 효과 테스트

스모크 테스트 : 테스트 환경에 대한 테스트

(5)   테스트 종류

1)    명세 기반 : 명세서 보고 해서 시간이 많이 걸림

2)    구조 기반 : 소스 코드를 보고 해서 시간이 많이 걸림

3)    경험 기반 테스트 : 경험이 많은 테스트가 진행

 

테스트 커버리지

(1)   개념 : 테스트를 얼마나 수행했는지 측정하는 기준

(2)   유형

1)    기능 기반 : 기능을 모수로 설정

2)    라인 기반 : 전체 소스 코드의 라인 수를 모수

3)    코드  : 소스 코드의 구문, 조건, 결정 등을 측정

4)    코드 커버리지

①     구문 커버리지 : 구문에 대해 한번 이상 수행

②     조건 커버리지 : 개별 조건식에 대해 수행

③     결정 커버리지 : 결정 포인트 내의 모든 분기문에 대해 수행

④     조건/결정 커버리지 : 결정 포인트 T/F, 개별 조건식 T/F(true/false)

⑤     변경 조건/ 결정 커버리지 : 모든 결정 포인트 내의 개별 조건식은 적어도 한번 t/f

⑥     다중 조건 커버리지 : 가능한 조합을 100% 보장

결함 관리 도구(게시판)

(1)   개념 및 중요성 : 테스트 수행 후 발생한 결함을 추적하고 관리할 수 있게 해주는 도구

(2)   프로세스: 에러 발견 -> 에러 등록 -> 에러 분석 -> 결함 확정 -> 결함 할당 -> 결함 조치 -> 결함 조치 검토 및 승인

(3)   결함 추이 분석

1)    결함 추이 분석 : 테스트 완료 후 발견된 결함의 결함 관리 측정 지표의 속성값들을 분석하고, 향후 애플리케이션의 어떤 모듈 또는 컴포넌트에서 결함이 발생할지를 추정하는 작업

2)    측정 지표

결함 분포 : 결함의 분포를 분석

결함 추세 : 테스트 진행 시간의 흐름에 따른 추세를 분석

결함 에이징 : 결함 상태의 지속 시간을 측정

(4)   결함 관리 항목

테스트 자동화 도구

(1)   개념 : 테스트를 효과적으로 수행하기 위해 스크립트(설명서)나 도구를 활용하여 반복적인 테스트 작업을 자동화하는 방법

(2)   유형

1)    정적 분석 도구 : 애플리케이션을 실행하지 않고 분석/ 종류 : PMD, SONARQUBE, Cppcheck, checkstyle 등

2)    테스트 실행 도구 : 사전에 작성된 테스트 스크립트나 시나리오를 실행하는 도구

3)    성능 테스트 도구 : 시스템의 성능, 부하, 스트레스 테스트를 위한 도구/ 종류: JMeter 등

4)    테스트 통제 도구 : 테스트의 전체 프로세스를 관리하는 도구

5)    테스트 장치(test harnett)-구성요소

테스트 드라이버 : 상향식 테스트에 필요

테스트 스텁 : 하향식 테스트에 필요

테스트 슈트 : 테스트 케이스의 집합

테스트 케이스 : 입력 값, 실행 조건, 기대 결과 등의 집합 (하나의 기능단위)

테스트 스크립트 : 자동화된 테스트 실행 절차(설명서)

목 오브젝트 : 조건부로 상황에 예정된 행위를 수행하는 객체(단순한 생각만 하는 것, 미완성)

 

통합 테스트

(1)   통합 테스트의 개념 : 소프트웨어 각 모듈간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 테스트 기법

(2)   분류 : 점증적 방식(하나씩) – 상향식(드라이버), 하향식(스텁) 통합 테스트/ 비 점증적 방식- 빅뱅 테스트

애플리케이션 성능 저하 원인

(1)   데이터 베이스 관련 성능 저하

-데이터베이스 락

-불필요한 패치(DB Fetch)

-연결 누수 (connection leak)

(2)   내부 로직으로 인한 성능 저하 원인

-파일 관련 오류

-코드 오류

(3)   외부 호출로 인한 성능 저하

 

애플리케이션 성능 분석

(1)   성능 분석 지표

처리량, 응답시간, 경과 시간(반환시간, turnaround time, 사과를 가져다 주는 것) 자원 사용률

(2)   성능 분석 도구

Jmeter, LoadUI 등

(3)   모니터링 도구

Scouter,NMon,Zabbix,Jeniffer

 

 

정형기술검토회의 (FTR, Formal Technical Review)

(1)   개념 : 소프트웨어 품질 보증 활동/ 소프트웨어 개발 산출물, 오류 발견을 목적으로 한다

(2)   검토 지침

제작자가 아닌 제품의 검토에만 집중한다

문제 영역을 명확히 표현한다

제기된 모든 문제를 바로 해결하고자 하지 않는다

검토자들은 사전에 작성한 메모들을 공유한다

논쟁이나 반박을 제한한다

의제를 정하고 그 범위를 유지한다

참가자의 수를 제한하고, 사전 준비를 철저히 하도록 강요한다

자원과 시간 일정을 할당한다

모든 검토자에게 의미 있는 교육을 행한다

검토의 과정과 결과를 재검토 한다

 

소스 코드 품질 분석 -> 리팩토링(기능은 그대로 소스코드만 수정)

(1)   동료 검토(peer review) : 2~3명의 개발자가 참여하는 리뷰 프로세스

(2)   Work through : 계획된 개발자 검토 회의

(3)   Inspection : 공식적 검사 회의/ 계획 -> 사전 교육 -> 준비 -> 인스펙션 회의 -> 수정 -> 후속 조치

소스코드 품질 분석 도구

(1)   분류

1)    정적 분석 도구 : 프로그램 실행 없이 소프트웨어 코드를 분석

2)    동적 분석 도구 : 프로그램을 실행하여 코드의 메모리 누수나 스레드 결함 등을 발견

애플리케이션 성능 개선하기

(1)   코드 최적화의 개념

(2)   코드 스멜

소스코드에서 발견할 수 있는 잠재적인 문제점

코드 스멜 관련 용어

-      스파게티 코드 : 난잡한 코드

-      외계인 코드 : 오래되어 유지보수가 어려운 코드

(3)   리팩토링 : 외부 동작 변경 없이 내부 구조를 개선하는 방법

(4)   클린 코드

1)    개념 : 의존성 최소화, 명확한 가독성과 목적성을 가진 코드

2)    원칙 : 가독성/ 단순성/의존성 배제/ 중복성 최소화/ 추상화

소프트웨어 유지보수

(1)   개념 : 개발 완료 이후부터 폐기될때까지 지속적으로 수행되는 작업

(2)   구분

1)    수정 보수 : 오류 수정

2)    적응 보수 : 환경 변화

3)    향상 보수 : 기능 추가

4)    예방 보수 : 잠재적인 오류 대비

(3)   용어

1)    레거시 시스템

2)    외계인 코드 : 오래되서 유지보수 어려움

3)    스파게티 코드 : 복잡하게 얽힌 프로그래밍 소스코드

4)    코드 스멜 : 소스코드 내에 존재하는 잠재적인 문제

 

제품 품질 국제 표준

1)    개념 : 소프트웨어 개발 공정 각 단계에서 산출되는 제품이 사용자 요구를 만족하는 지 검증하기 위한 국제 표준

2)    소프트웨어 품질 관련 국제 표준

1)    ISO/IEC 9126의 소프트웨어(기신사효유이)

기능성(Functionality)

신뢰성(Reliability)

사용성(Usability)

효율성(Efficiency)

유지보수성

이식성(Portability) : 다른 시스템으로 이식

2)    ISO/IEC 14598 평가 특성 – 9126하면서

반복성: 동일 평가자가 동일 제품 테스트

재현성 : 다른 평가자가 동일 제품 테스트

공정성 : 평가의 편향 없음

객관성 : 평가자의 주관성에 영향 받지 않는 평가

3)    ISO/IEC 12119 구성요소

제품 설명서/사용자 문서/ 실행 프로그램

4)    ISO/IEC 25000 – 9126 + 14598

프로세스 품질 국제 표준 (이거 만드는 회사가 잘 돌아가는 지)

(1)   개념 : 소프트웨어 개발 프로세스 및 관련 업체의 프로세스 관리 능력을 평가하고 개선하는 데 사용된다

(2)   국제 프로세스 품질 표준

1)    ISO/IEC 12207 구성

기본 생명 주기 프로세스 : 개발하는 절차 ( 획득, 공급, 개발, 운영, 유지보수)

지원 생명 주기 프로세스 : 기본 생명 주기 진행하면서 지원 ( 문서화, 형상 관리, 품질보증, 검증, 확인)

조직 생명 주기 프로세스 : 관리, 기반 구조, 개선, 교육 훈련

2)    15504(SPICE) – 유럽

ISO에서 표준으로 지정된 프로세스 수행능력 평가 표준 프레임 워크

수준	단계	설명
0	불안정 단계	미구현 또는 목표 미달성
1	수행 단계	프로세스 수행 및 목적 달성
2	관리 단계	프로세스 수행 계획 및 관리
3	확립 단계	표준 프로세스의 사용
4	예측 단계	프로세스의 정량적 이해 및 통제
5	최적화 단계	프로세스의 지속적인 개선

3)    CMM : 소프트웨어 개발 업체들의 업무능력 평가 기준을 세우기 위한 평가 모형 -미국

CMM 성숙도 5 단계

수준	단계	설명
1	초기 단계	성과를 예측할 수 없는 상태
2	반복 단계	성공적인 프로젝트의 반복
3	정의 단계	프로세스의 기초가 정립되어 발전
4	관리 단계	정량적 프로세스 관리
5	최적화 단계	질적/양적 지속적 개선

4)    CMMi : 기존 CMM에 프로젝트 관리, 프로큐어먼트, 시스템 엔지니어링 등의 요소를 추가한다

수준	단계	설명
1	초기 단계	프로세스를 갖고 있지 않는 조직
2	관리 단계	기본적인 프로세스 가짐
3	정의 단계	표준 프로세스를 보유
4	정량적 관리 단계	프로세스들을 정량적으로 관리
5	최적화 단계	질적/양적 지속적 개선

 

서비스 관리 국제 표준

(1)   개념 : 고객에게 IT 서비스를 제공하고 관리하기 위한 통합된 관리체계를 적용하여 고객에게 적절한 통제, 개선된 효과성 및 개선의 기회를 제공한다

(2)   종류 : ISO/IEC 20000

애플리케이션 패키징

(1)   개념 : 개발 완료된 소프트웨어를 사용자에게 전달하지 위한 형태로 패키징 하는 과정

(2)   특징

개발자가 아닌 최종 사용자 중심으로 진행된다

신규 및 변경된 소스를 식별, 모듈화하여 패키징 한다

버전 관리 및 릴리스 노트(뭐가 바뀌었는지)를 통해 지속적으로 관리한다

다양한 사용자 환경에서의 호환성을 고려하여 패키징 한다

(3)   패키징 수행 순서

기능 식별 -> 모듈화 -> 빌드 진행(컴파일) -> 사용자 환경 분석 -> 패키징 적용 시험 -> 패키징 변경 개선

애플리케이션 배포 도구

(1)   개념 : 최종 사용자에게 소프트웨어를 전달하는 전체 과정

(2)   고려사항 : 반드시 내부 콘텐츠에 대한 암호화 및 보안을 고려/ 추가로 다양한 이기종 연동을 고려

(3)   CI/CD

1)    CI :지속적인 통합

2)    CD : 지속적인 서비스 제공 혹은 지속적인 배포

릴리즈 노트

(1)   개념 : 소프트웨어 제품과 함께 배포되는 문서

(2)   작성 항목 : Header, 개요, 목적, 이슈 요약, 재현항목, 수정/개선 내용, 사용자 영향도

DRM(Digital Rights Management)

(1)   개념 : 디지털 콘텐츠의 불법 사용을 제한하고, 승인된 사용자에게만 콘텐츠 사용을 허용하는 기술

(2)   구성 및 흐름

구성	설명
콘텐츠 제공자	콘텐츠를 제공하는 저작권자
콘텐츠 분배자	암호화된 콘텐츠를 제공
패키저	콘텐츠를 메타 데이터로 묶는 기능
보안 컨테이너	안전한 유통을 위한 전자적 보안 장치
DRM 컨트롤러	콘텐츠의 이용권한을 통제
클리어링 하우스	키 관리 및 라이선스 발급 관리

(3)   DRM 사용 규칙 제어 기술

1)    콘텐츠 식별 체계 : 디지털 콘텐츠에 고유 식별 번호를 부여하여 관리(DOI, URI를 이용)

2)    메타 데이터 : 콘텐츠에 관한 구조화된 데이터

3)    권리 표현 기술(해당 하는 콘텐츠에 대해 어떤 권리 요구 가능?) : 콘텐츠에 대한 규칙을 설정(XrML) / render(이용) Transport(교환) derivative(변환)

(4)   저작권 보호 기술

1)    암호화 기술 : 특정 키를 가진 사용자만이 콘텐츠를 이용

2)    위변조 방지(Temper-proofing) : 콘텐츠에 무단 조작 시 감지하고 오류 동작을 유발

3)    워터 마킹 : 콘텐츠에 저작권 정보를 은닉/ 워터 마킹(불법복제방지, 이거 내꺼다), 핑거프린팅(불법 유통 방지, 이거 내꺼다 근데 너가 샀네)