[2021 정보처리기사 실기] 13. 애플리케이션 테스트 관리

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

1) SW 테스트

: 개발된 응용 앱 등이 사용자 요구기능과 성능, 사용성, 안정성을 만족하는지, 노출되지 않은 숨은 결함을 찾아내는 활동.

필요성	설명
오류발견관점	잠재된 오류발견, 올바른 프로그램개발
오류예방관점	프로그램 실행 전 오류 사전 예방
품질향상관점	요구사항 및 기대수준만족위해 신뢰도 향상하는 품질보증 위해 필요.

- SW 테스트의 기본원칙

① SW 테스트 원리

원리	설명
결함존재를 밝힘	결함이 없다는 것을 증명할 수 는 없음. 결함을 줄이는 활동
완벽한 테스팅은 불가능
개발초기에 테스팅 시작	테스팅 결과를 단시간에 알 수 있고, 기간단축, 재작업 줄여 개발기간 단축 및 결함 예방. 후기에 하면 비용 커지는 요르돈의 법칙(눈덩이법칙) 적용됨.
결함집중	적은 수의 모듈에서 대다수의 결함이 발견됨. 파레토법칙(80대20): 오류의 80%는 전체모듈의 20%내에서발견
살충제 패러독스	반복적 테스트는 새로운 버그를 찾지 못함.
테스팅은 정황에 의존적	정황과 비즈니스 도메인에 따라 테스트 다르게 수행
오류-부재의 궤변	요구사항을 충족못하면 결함이 없다고해도 품질이 높다고 볼 수 없음

② SW 테스트 프로세스

순서	프로세스	설명
1	테스트계획	시스템파악, 정의 등
2	테스트분석및디자인	요구사항분석, 도구준비
3	테스트케이스 및 시나리오작성
4	테스트수행
5	테스트결과 평가 및 리포팅	정리, 리뷰, 결과평가

③ SW 테스트 산출물

테스트계획서

테스트베이시스: 분석,설계단계의 논리적인 CASE로 테스트 설계를 위한 기준이 되는 문서

테스트케이스: 테스트 위한 설계 산출물

테스트슈트: 테스트케이스를 실행환경에 따라 구분해놓은 테스트케이스집합. (시나리오가 포함되지 않은 단순한 테스트케이스들의 모임)

테스트시나리오

테스트스크립트(=테스트 스텝, 테스트절차서):테스트케이스의 실행순서를 작성한 문서.

테스트결과서

 

2) SW 테스트 유형

분류	설명	유형
정적테스트	테스트대상을 실행하지 않고 구조분석해 논리성 검증	리뷰, 정적분석
동적테스트	SW실행방식으로 테스트수행해결함검출	화이트박스테스트, 블랙박스테스트, 경험기반 테스트

-테스트기법에 따른 분류

① 화이트박스 테스트(=구조기반테스트, 코드기반테스트, 로직기반테스트, 글래스박스테스트): 프로그램 내부구조와 동작 검사하는 소프트웨어 테스트.

: 코드분석과 프로그램 구조지식을 바탕으로 모듈 내부를 테스트함.

: 산출물기능별로 제어구조에 따라 선택, 반복 등의 부분들을 수행함으로써 논리적 경로를 점검함.

유형	내용
구문(문장) 커버리지	모든명령문을 적어도 1번 수행.
결정(선택) 커버리지	전체 조건식이 적어도 1번은 참/거짓결과를 수행. 구문커버리지 포함
조건커버리지	개별조건식이 적어도 1번 참/거짓결과를 수행. 구문커버리지 포함
조건/결정 커버리지	전체조건식,개별조건식이 적어도 1번 참/거짓결과를 수행
변경 조건/결정 커버리지	개별조건식이 다른 식에 영향받지않고 전체조건식에 독립적으로 영향줌
다중 조건 커버리지	결정조건 내 모든 개별 조건식의 모든 가능한 조합을 100% 보장
기본 경로 커버리지(=경로 커버리지)	수행가능한 모든 경로를 테스트
제어흐름테스트	프로그램제어구조를 그래프형태로 나타내 내부로직을 테스트
데이터흐름테스트	제어흐름 그래프에 데이터 사용현황을 추가한 그래프를 통해 테스트

② 블랙박스 테스트 (=명세 테스트)

: 외부사용자의 요구사항 명세를 보며 수행하는 기능테스트

: SW 특징, 요구사항, 설계명세서에 초점 맞춰 테스트.

: 기능, 동작위주 테스트를 진행해 내부구조나 작동원리를 알지못해도 가능함.

유형	내용
동등분할테스트(=동치분할테스트, 균등분할테스트, 동치클래스분해테스트)	입력데이터의 영역을 유사한 도메인별로 유/무효값을 그룹핑해 대푯값 테스트 케이스를 도출하여 테스트함.
경곗값분석테스트(=한곗값테스트)	등가분할 후 경곗값에서 오류발생확률이 높기에 경곗값을 포함하여 테스트케이스 설계해 테스트. 최솟값 바로위, 최대치 바로 아래 등 입력값의 극한 한계를 트스트
결정테이블테스트	요구사항논리와 발생조건을 테이블로 나열해 조건,행위 모두 조합해 테스트
상태전이테스트	테스트 대상,상태 구분하고 이벤트에 의해 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 수행
유스케이스테스트	프로세스흐름을 기반으로 테스트케이스를 명세화하여 수행
분류트리테스트	트리구조로 분석해 테스트케이스설계해 테스트.
페어와이즈테스트	테스트데이터값들 간 최소 1번씩 조합. 모든 조합에 비해 상대적으로 적은 양의 테스트세트 구성 대부분 결함이 두 입력값의 상호작용에 기인함. 입력값이 많을수록 테스트케이스 도출 복잡도높음
원인-결과 그래프 테스트	그래프를 활용해 입력데이터간 관계 및 출력에 미치는 영향 분석해 효용성 높은 테스트케이스 선정해 테스트.
비교 테스트	여러버전의 프로그램에 같은 입력값 넣어 동일한 결과 데이터가 나오는지 비교해보는 테스트기법.

-테스트시각에 따른 분류

: 검증, 확인

-테스트목적에 따른 분류

분류	설명
회복테스트	고의로 실패유도 후 복귀테스트
안전테스트	보안적 결함 미리 점검
성능테스트	응답시간, 반응속도 -부하테스트:부하증가시키며 임계점을 찾는 테스트 -스트레스테스트:임계점 이상의 부하로 -스파이크테스트: 단기간 사용자몰릴 때 반응측정테스트 -내구성테스트: 장시간 부하가하여 반응테스트
구조테스트	논리경로, 소스코드 복잡도평가
회귀테스트	오류제거한 시스템에서 오류제거와 수정에 의해 새로 유입된오류는 없는지 확인.
병행테스트	변경된시스템과 기존시스템에 동일한 데이터 입력 후 결과비교

테스트 종류에 따른 분류

분류	설명
명세기반테스트(블랙박스 테스트)	-요구사항명세서 기반으로 테스트케이스 선정하여 테스트.
구조기반테스트(화이트박스 테스트)	-SW 내부 논리 흐름에 따라 테스트케이스를 작성하고 확인
경험기반테스트(블랙박스 테스트)	-유사SW, 기술 평가에서 테스터 경험 토대로한, 직관과 기술능력기반 테스트 ex) 탐색적, 오류추정, 체크리스트, 특성테스트

경험기반테스트

1) 탐색적 테스트: 테스트 스크립트, 테스트 케이스를 문서로 작성안하고 경험에바탕으로 탐색적으로 기능을 수행하며 테스트함. 구성요소: 테스트차터, 시간제한, 노트, 회고

2) 오류추정: 개발자 실수 추정, 결함검출. 동등분할, 경곗값분석 같은 명세기반 테스트방법과 함께 사용.

3) 체크리스트: 테스트내용 나열하여 하나씩 확인함.

4) 특성테스트: 국제표준인 ISO/IEC 9126 등 품질모델에 있는 품질특성을 염두로 경험적 테스트케이스 설계,테스트

 

3) 정적 테스트

리뷰

: SW의 산출물에 존재하는 결함 검출, 플젝 진행상황 점검 활동. 사람이 직접 수행하는 수작업 중심의 방식.

유형	설명
관리리뷰	플젝 진행상황 검토 토대로 의사결정지원
기술리뷰	계획, 명세 준수하는지 검토. 변경사항 적절히 구현되었는지 평가
인스펙션(=동료검토)	저작자 외 다른 전문가가 검사해 문제식별하고 해결 찾음 (개발초기에 검사) -프로세스 1) 계획수립 2) 절차 및 작업물의 개요 설명 3) 준비, 작업물 검토 4) 검토 회의 5) 재작업 6) 후속작업 참가자: 주재자, 작성자, 낭독자, 기록자, 검토자
워크스루	검토자료를 회의 전에 배포해 사전검토 후 단시간 회의 진행하여 리뷰. 비형식적 검토방식. 결함검출뿐아니라 참가자교육, 지식공유.
감사	SW제품 및 프로세스가 규제, 표준, 절차 등을 준수하는지 독립적으로 평가.

정적분석

: IEEE1028-2008에서 정의함. 경영진준비, 리뷰계획, 리뷰절차개요설명, 작업물 개요설명, 개별 준비, 그룹검토, 재작업, 후속작업 순임.

: 자동화된 도구이용해 산출물 결함 검토, 복잡도 측정.

유형	설명
코딩표준	코딩표준 준수여부 검사. 도구 ex: LDRA, PRQA, Parasoft
복잡도 측정	-신뢰성있는 척도 사용해 프로그램 복잡도 측정 및 분석검사 McCabe의 순환복잡도의 복잡도 지표가 널리사용됨.
자료흐름분석	프로그램 자료흐름에 이상 존재 검사

 

4) 동적 테스트

화이트박스 테스트

-테스트 커버리지 개념

: 프로그램의 테스트 수행정도를 나타내는 값. 테스트 수행의 완벽성을 측정하는 도구.

: SW 테스트 범위를 측정하는 테스트품질측정 기준.

: 테스트의 신뢰성, 정확성 향상시키는 역할.

: 시스템 또는 컴포넌트에서 테스트가 수행된 정도

: 코드로 작성된 부분만 측정가능. 구현이 안되었거나, 명세서기능이 생략된 경우 결함발견 불가.

(1) 기능기반 커버리지: 테스트대상 앱의 전체 기능을 모수로 설정하고, 실제테스트가 수행된 기능의 수를 측정하는 방법. 100%달성을 목표로함.

(2) 라인 커버리지: 소스코드 라인 수를 측정

(3) 코드 커버리지: 코드 자체의 구문, 조건 등 측정. 일반적으로 테스트커버리지라고 하면 코드 커버리지를 일컬음.

 

-테스트 커버리지 구성

: 구문(문장), 결정, 조건, 결정포인트로 구성.

구문: 소스코드.

결정: 조건문에 대한 결정

조건식: 결정에 대한 각 조건식

결정포인트: 참과 거짓에 대한 분기 노드(if, while, for, switch)

 

①구문커버리지: 프로그램 내 모든 명령문을 적어도 1번 수행.

:구분커버리지% = 테스트케이스 집합에 의해 실행된 문장 수/(전체 실행가능한 프로그램문장수)*100

 

②결정커버리지: =선택 커버리지, 분기커버리지

결정커버리지%= 결정의결과수/전체프로그램결과수*100%

 

③ 조건 커버리지%= 테스트케이스집합에 의해 실행된 조건의 결과수/전체프로그램 조건의 결과수 * 100%

 

④ 조건/결정커버리지

: 조건커버리지와 결정커버리지를 최소한의 조합으로 달성하는 커버리지.

%= 테스트케이스집합에 의해 실행된 조건/결정의 결과수/(전체프로그램조건/결과의 결과수)*100%

 

⑤ 변경 조건/결정 커버리지

%= (테스트케이스집합에 의해 MC/DC를 만족하는 조건의 개수)/총조건의개수 * 100%

 

⑥ 다중 조건 커버리지

: 결정 조건 내 모든 개별 조건식의 모든 가능한 조합을 100% 보장하는 테스트 커버리지.

: 문장, 결정, 조건, 조건/결정커버리지를 모두 포용함.

%= (테스트 케이스 집합에 의해 실행된 각 결정 조건들의 조합수)/전체프로그램 결정조건들의 조합수 * 100%

 

⑦ 기본 경로 커버리지

: 맥케이브의 순환복잡도를 기반으로 커버리지를 계산

맥케이브 순환복잡도: 제어흐름의 복잡한 정보를 정략적으로 표시하는 기법. 해당 제어 흐름 그래프에서 선형적으로 독립적인 경로의 수.

맥케이브 순환복잡도 측정방법: 제어흐름에 의한 그래프를 통해 원시코드의 회전 수를 구해 복잡도계산.

%=테스트수행한기본경로비율/(식별한모든기본경로의수)*100%

 

⑧ 제어흐름 테스트

: 프로그램 제어구조를 충분히 커버하도록 경로를 선택하여 테스트케이스가 개발되고, 선택된 경로는 ‘테스팅 완전성’을 가늠하는 척도가 됨.

: 제어흐름그래프(G)는 노드집합, 에지집합으로 구성됨. 즉, G(N, E)임.

: 제어흐름 레벨에 따라 테스트 강도조절이 가능함.

 

블랙박스 테스트(명세기반 테스트)

: 전체 SW테스트 레벨(단위, 통합, 시스템, 인수)에서 적용 가능.

 

5) 테스트 케이스

:요구사항 준수하는지 확인하기 위해 개발된 입력값, 실행조건, 예상된 결과의 집합.

애플리케이션 테스트 시나리오 작성

1) 테스트 레벨

: 함께 편성되고 관리되는 테스트활동의 그룹

단위테스트: 단위모듈, 서브루틴. ex) 자료구조테스트, 실행경로테스트, 오류처리테스트, 인터페이스테스트

: 명세기반테스트(블랙박스)와 구조기반테스트(화이트박스)로 나누어짐.

통합테스트: 단위테스트를 통과한 모듈 사이 인터페이스, 통합된 컴포넌트간 상호작용 검증. ex) 빅뱅테스트, 샌드위치테스트, 상향식/하향식 테스트

: SW각 모듈간 일터페이스 관련 오류 및 결함 찾기.

시스템테스트: 통합된 단위시스템기능이 시스템에서 정상 수행되는지 검증. ex) 기능, 비기능요구사항테스트

인수테스트: 최종 계약상 요구사항 만족되었는지 확인. ex) 계약인수, 규정인수, 사용자인수, 운영상인수(백업/복원시스템, 정기점검 등), 알파/베타테스트

2) 테스트 시나리오

3) 테스트 환경 구축

 

애플리케이션 통합 테스트

애플리케이션 테스트 수행

1) 단위 테스트 (컴포넌트)

: 개별적 모듈(또는 컴포넌트) 테스트.

: 구현단계에서 각 모듈 구현한 후 수행.

: 개별적 모듈 테스트 수행하려면 모듈을 단독 실행할 수 있는 ‘테스트베드’ 환경이 필요.

목(Mock) 객체 생성 프레임워크

: 객체지향프로그램에서는 컴포넌트 테스트 수행 시 테스트되는 메서드는 다른 클래스의 객체에 의존함.--> 독립적 컴포넌트 테스트를 위해 ‘목 객체’가 필요.

목객체유형	설명
더미객체	테스트할 때 객체만 필요하고 기능은 노필요시. 정상작동은 수행하지 않고 예외수행.
테스트스텁	제어모듈이 호출하는 타모듈 기능을 단순수행. 더미객체에 단순기능 특정상태를 가정해 특정값 리턴하거나 메시지출력
테스트드라이버	테스트 대상 하위모듈을 호출하고, 파라미터 전달하고, 모듈테스트 수행후 결과를 도출
테스트스파이	테스트대상 클래스와 협력하는 클래스로 가는 출력을 검증하는데 사용
가짜객체	실제 협력클래스의 기능을 대체, 단순구현.

단위 테스트 원칙

: 빠르게 수행, 다른 컴포넌트에 의존하지 않아야함.

2) 통합 테스트

: SW 각 모듈간 인터페이스 관련 오류/결함 찾아냄.

: 단위테스트가 끝난 모듈, 컴포넌트 단위 프로그램이 설계단계에서 제시한 앱과 동일한 구조와 기능으로 구현된것인지를 확인하는 테스트.

: 점증적방법(빅뱅방식: 모든 컴포넌트를 통합해 전체프로그램을 한번에 테스트), 비점증법방법으로 나뉨.

: 점증적방법은 상향식통합, 하향식통합방식으로 구분됨.

점증적방법

① 하향식 통합 방식 (스텁)

: 메인제어모듈(프로그램)로부터 아랫방향으로 제어경로따라 하향식으로 통합하며 테스트 진행. 깊이우선(DFS), 너비우선(BFS) 방식으로 통합됨.

② 상향식 통합 방식 (드라이버)

: 취하위레벨 모듈로부터 위쪽으로 경로이동하며 테스트.

③ 샌드위치 통합

: 상향식+하향식 결합방법. 하위프로젝트가 있는 대규모 통합테스트에서 사용하는 방식.

: 병렬테스트가 가능, 시간절약됨. 비용많이 소요됨.

: 상위레벨은 스텁, 하위레벨은 드라이버.

테스트방안	빅뱅	상향식	하향식	샌드위치
드라이버/스텁	드라이버/스텁없이 실제모듈로 테스트	테스트드라이버필요	테스트스텁 필요	테스트스텁, 드라이버 필요
장점	단시간 테스트 가능 작은시스템에 유리	장애위치 파악 쉬움 모든 모듈 개발시간 낭비 필요없음	장애위치 파악 쉬움 이른 프로토타입 가능 중요 모듈의 선 테스트 가능	병렬테스트 가능. 시간절약 대규모 통합테스트에 활용
단점	장애위치파악 어려움 모든모듈이 개발되어야가능	중요모듈들이 마지막 테스트 가능성 높음 이른 프로토타입 어려움	많은 스텁 필요 하위모듈의 불충분한 테스트 수행	비용많이 소요

3) 테스트 자동화 도구

: 스크립트 구현해서 테스트 시간 단축, 인력 투입 비용 최소화. (효율적)

장점: 자동화, 사용자요구기능의 일관성 검증 유리, 테스트결괏값에 대한 객관적 평가 기준 제공. 테스트 결과의 통계작업과 그래프 등 다양한 표시 형태 제공

단점: 도구 교육 및 학습 필요. 프로세스 단계별로 적용하기 위한 시간, 비용 ,노력 필요. 상용도구 고가, 유지관리 비용 높아 투자 필요.

종류

① 정적 분석 도구

: 만들어진 앱을 실행안하고 분석하는 도구.

: 소스코드 코딩표준 등 결함 발견위해 사용

: 소스코드에 대한 이해를 바탕으로 도구이용해 분석

② 테스트 실행 도구

: 작성된 스크립트를 실행. 데이터주도접근방식과 키워드주도접근방식으로 나뉨.

도구유형	설명
데이터주도접근방식	테스트 데이터를 스프레드시트에 저장. 다양한 데이터로 동일한 테스트케이스 반복실행가능. 스크립트언어 미숙해도 미리작성된 스크립트에 테스트데이터만 추가하여 쉽게 테스트가능
키워드주도접근방식	테스트수행동작 나타내는 키워드와 테스트 데이터를 스프레드시트에 저장. 키워드이용해 동작정의.

테스트 하네스

: 컴포넌트 및 모듈을 테스트하는 환경의 일부분. 테스트 지원위한 코드와 데이터.

구성요소: 테스트드라이버, 테스트스텁, 테스트 슈트(테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합), 테스트케이스(입력값, 실행조건, 기대 결과 등의 집합), 테스트 스크립트, 목 오브젝트

애플리케이션 테스트 결과 분석

1) 테스트 결과 분석

① SW 결함

에러/오류: 결함의 원인. 사람에 의한 실수

결함/결점/버그: SW 제품에 포함된 결함. 제거안하면 SW 제품 실패, 문제발생

실패/문제: SW 제품에 포함된 결함이 실행될 때 발생하는 현상.

② 테스트 완료 조건

: 단위/통합/시스템/인수테스트 등 각 단계별 테스트를 언제 어떤 상황에서 종료할것인지 결정하는 기준.

③ 테스트 리포팅

: 테스트결과정리: 테스트 결과까지 모두 포함된 문서작성

: 테스트요약문서: SW 품질상태 포함한 문서 작성

: 품질상태: 결함 중요도 등 품질상태

: 테스트 결과서: 결함과 관련된사항 중점적 기록

: 테스트 실행절자 및 평가: 결과에 대한 평가 수행.

2) 결함 관리: 7개의 활동

결함분석 방법

1) 구체화: 결함원인 찾기위해 결함발생시킨 입력값, 테스트절차, 테스트환경 명확히 파악

2) 고립화: 어떤요소가 결함발생영향을 미치는지 분석

3) 일반화: 결함발생영햐주는 요소를 최대한 일반화시킴

 

결함 생명주기 및 추적 관리 활동

1) 결함 생명주기

결함 생명주기별 결함상태	설명
결함등록(Open)	구체화, 고립화, 일반화한 결함으로서 보고된 상태 결함보고서에 기록되어 결함추적의 대상이 된 상태
결함검토(Reviewed)	Open된 결함의 처리방안 검토상태 결함은 위험성을바탕으로 수정되거나 다음릴리스에서 수정되거나 무시될 수 있음
결함할당(Assigned)	결함수정할 개발자 결정.
결함수정(Resolved)	결함 수정 해결처리상태
결함확인(Verified)	결함처리 합당 검증 완료상태
결함종료(Closed)	정확한수정 판단 후 완료상태
결함재등록(Reopen)	잘 수정되지 않아 재수정요구
결함조치보류(Deferred)	Open된 결함을 바로 수정안하고 다음 릴리스에서 해결하기로 연기함. 적절한시점에 Reopen됨.

결함처리유형	설명
Fixed	요청된 결함 수정완료처리
Duplicated	기존 다른결함과 중복됨
Won’t Fix	수정필요할정도로 중요하거나 긴급하지 않아서 수정하지않음
Invalid	테스트케이스에 문제가 있음

2) 결함 추적 관리 활동

단계	착수기준	입력물	산출물	종료조건
단위 테스트	없음	- 테스트활동 로그 결함관리대장	-결함관리대장 -테스트활동로그 -테스트결과보고서	심각도 상위 수준의 결함 해결 여부 확인
통합 테스트	-설계문서 결함발견 -통합테스트 평가완료
시스템 테스트	-요구사항 명세서 결함발견 -시스템테스트평가완료
운영 테스트	-요구사항 명세서 결함발견 -운영 테스트 평가 완료

3) 결함 추이 분석

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

 

결함 추이 분석 유형

1) 결함분포분석: 결함수를 측정해 결함의분포 분석

2) 결함추세분석: 시간흐름따른 결합 수 측정해 추세분석

3) 결함 에이징분석: 결함 상태의 지속시간 측정하여 분석

 

애플리케이션 개선 조치사항 작성

1) 테스트 커버리지

2) 결함의 식별 및 관리

결함분류	설명 세부유형
시스템 결함	비정상적 종료, 중단 응답시간지연 DB에러 등 앱환경, DB에러
기능결함	요구사항 미반영, 불일치, 부정확한 비즈니스 프로세스, 스크리브 에러, 타시스템연동시 오류, 설계, 업무시나리오 단계의 결함
GUL 결함	UI비일관성, 부정확한 커서/메시지 등 화면설계결함
문서 결함	의사소통과 기록 원활하지않은 문제 온/오프라인 매뉴얼 불일치 등

 

결함 심각도별 분류

1) 치명적 결함: 기능, 제품의 테스트를 완전방해하거나 못하게하는 결함. (데이터손실, 시스템 충돌)

2) 주요결함: 기능이 다르게 동작하거나 못함(기능장애)

3) 보통결함: 기준충족못함. 일부기능 부자연(사소한 기능 오작동)

4) 경미한 결함: 사용상의 불편함유발(표준위반, UI잘림)

5) 단순결함: 버그. 기능에 영향없으나 수정되어야함(미관상 좋지 않음)

 

결함 우선순위(얼마나 빠르게 처리해야하는가)

1) 결정적: 24시간안에 즉시 수정. 전체기능 동작안함.

2) 높음:결함에 의해 다른 기능을 사용할 수 없음

3) 보통: 실패시 에러메시지 출력이안됨

4) 낮음: 작은 기능

 

애플리케이션 성능 개선

1) 애플리케이션 성능 측정 지표

처리량: 주어진 시간에 처리가능한 트랜잭션 수. 웹앱의 경우 시간당 페이지 수로 표현

응답시간: 응답출력 시간

경과시간: 사용자요구 입력시점부터 트랜잭션 처리 후 그결과 출력이 완료될때까지 걸리는 시간

자원사용률: 트랜잭션 처리동안 cpu/메모리/넽웤사용량

 

2) 유형별 성능 분석 도구

성능/부하/스트레스 점검도구

도구	설명
JMeter	HTTP, FTP, LDAP 등 다양한 프로토콜 지원하는 안정성, 확장성, 부하, 기능 테스트 도구
LoadUI	UI 통해 HTTP, JDBC 등 서버 모니터링 지원
OpenSTA	HTTP, HTTPS 지원하는 부하테스트 및 생산풍 모니터링도구

모니터링도구:

도구	설명
Scouter	단일 뷰 통합/실시간 모니터링. 튜닝에 최적화된 인프라 통합 모니터링도구
zabbix	웹기반 서버, 서비스, 앱 모니터링도구

3) 애플리케이션 성능저하원인 - 데이터베이스

1) DB Lock: 대량 데이터조회, 과도한 업데이트, 인덱스 생성시 발생하는 현상 등. Lock해제까지 대기/타임아웃.

2) 불필요한 DB Fetch: 실제필요한 데이터보다 대량 데이터 요청이 들어옴, 결과세트에서 마지막위치로 커서를 옮기는 작업이 빈번함

3) 연결누수: DB연결과 관련한 JDBC객체를 종료하지 않음

4) 부적절한 커넥션풀크기: 넘 작거나 크게설정

5) 커밋관련: 트랜잭션이 커밋되지 않고 커넥션풀에 반환될 때, 코딩에러로 불필요커밋이 자주발생할 때.

 

4) 애플리케이션 성능저하원인 – 내부 로직

1) 웹앱의 인터넷 접속불량

2) 특정 파일의 업로드, 다운로드

3) 비정상적 오류 처리

5) 애플리케이션 성능저하원인 – 외부호출(http,소켓통신)

6) 애플리케이션 성능저하원인 – 잘못된환경, 넽웤문제

 

환경설정으로 인한 성능저하:

스레드풀, 힙 메모리 크기를 넘 작게 설정하면 힙메모리풀 발생으로 성능 저하가능성 조냊

넽웤 장비로 인한 성능저하: 라우터, L4 스위치 등 넽웤 장비간 데이터 전송 실패/지연에 따른 데이터 손실 발생 시 성능저하, 자애발생 가능성 존재

 

애플리케이션 성능 개선

1) 소스코드 최적화

:읽기 쉽고 변경 및 추가가 쉬운 클린코드를 작성하는 것.

배드 코드

: 타개발자가 로직을 이해하기 어렵게 작성된 코드

: 처리 로직의 제어가 정제되징낳고 서로 얽혀 있는 스파게티 코드, 변수나 메서드에 대한 이름 정의를 알 수 없는 코드, 동일 처리 로직이 중복되게 작성된 코드.

(1) 외계인 코드

: 오래되거나 참고문서, 개발자 없어 유지보수작업 어려움

(2) 스파게티 코드

: 소스코드가 복잡히 얽힘. 정상작동이나, 사람이 작동을 파악하기는 어려움

(3) 알 수 없는 변수명

: 변수, 메서드 명 정의를 알 수 없음

(4) 로직 중복

: 동일한 처리 로직이 중복되게 작성된 코드

 

배드 코드 유형

(1) 오염: 비즈니스 기능 수행못하는 많은 컴포넌트 존재

(2) 문서부족: 코드와 문서 불일치. 지식부족초래

(3) 의미없는이름: 함수,클래스,컴포넌트명이 불명확한의미

(4) 높은결합도: 클래스,컴포넌트간 데이터와 컨트롤 흐름이 넽웤으로 복잡하게 연결

(5) 아키텍처 침식: 아키텍처가 더 이상 구별되지 않고 여러 솔루션으로 이루어져서 아키텍처상 변형들로 인해 시스템 품질이 떨어짐.

 

클린 코드

: 가독성높고 단순하며 의존성줄이고, 중복최소화, 깔끔

: 설계 개선되며, 버그찾기쉬워지고 프밍속도가 빨라짐.

 

클린 코드의 작성 원칙

1) 가독성: 들여쓰기사용

2) 단순성: 1번에 1처리만 수행. 최소단위로 분리

3) 의존성최소: 영향도 최소화.

4) 중복성제거: 중복코드제거

5) 추상화: 추상화구현.

 

2) 소스 코드 품질 분석

: 소스코드 코딩스타일, 표준, 코드복잡도 등에 존재하는 결함발견

 

1) 정적분석도구

(1) pmd : 자바 및 타언어 소스코드 버그, 데드코드 분석

(2) cppcheck: C/C++ 코드 메모리누수, 오버플로우 분석

(3) SonarQube: 소스코드 품질 통합 프랫폼, 플러그인확장가능

(4) checkstyle: 자바코드 코딩표준검사도구

(5) ccm: 다양한 언어의 코드복잡도 분석도구, 리눅스, 맥환경 CLI 형태 지원

(6) cobertura: jcoverage 기반 테스트커버리지 측정도구

 

2) 동적분석도구

(1) Avalanche: Valgrind 프레임워크 및 STP 기반 SW 에러 및 취약점 동적 분석 도구

(2) Valgrind: 자동화된 메모리 및 스레드결함 발견분석도구

 

3) 애플리케이션 성능 개선 방안

 

소스코드 최적화 기법 적용

: 앱 개발 프레임워크의 코딩 표준을 정하고, 인터페이스 클래스를 이용해 느슨한결합 코드를 구현함.

: 인터페이스를 통해 추상화된 자료구조를 구현해 의존성을 최소화함.

 

아키텍처 조정을 통한 성능개선

: 객체 생성, 사용을 분리해 의존성최소화하기위해 패곹리 메서드 패턴을 이용해 성능 개선.

 

프로그램 호출순서 조정 적용

: 호출함수 먼저코딩, 호출되는 함수 나중에 배치. 유사성 높은 함수나 코드끼리 가깝게 배치

 

소스코드 품질분석 도구 활용

① 메모리사용 최소화: String은 StringBuffer로 사용, 루프 내 불필요한 메서드 호출이 반복되지 않게함.

② 입출력 발생 최소화: 문자일어올 때 버퍼사용

③ System.out.println() 사용 제외: 대기시간발생됨. Log4j 로거 사용해 성능 개선.

 

리팩토링 통한 성능 개선

: 기능변경안하고, 복잡한 소스코드 수정, 보완해 가용성 및 가독성을 높임

목적: 유지보수성 향상, 유연한시스템, 생산성/품질향상

 

애플리케이션 성능현황 관리

: 성능현황판(Q-Board) 사용해 성능테스트 단계 기록.