[소프트웨어개발] 4. 애플리케이션 관리

염두리안 2023. 3. 6. 00:18

728x90

054. 애플리케이션 테스트 (★★☆)
055. 애플리케이션 테스트의 분류 (★★☆)
056. 테스트 기법에 따른 애플리케이션 테스트 (★★★)
057. 개발 단계에 따른 애플리케이션 테스트 (★★★)
058. 통합 테스트 (★★★)
059. 애플리케이션 테스트 프로세스 (★☆☆)
060. 테스트케이스/테스트시나리오/테스트오라클 (★★☆)
061. 테스트 자동화 도구 (★★☆)
062. 결함관리 (★★☆)
063. 애플리케이션 성능 분석 (★★☆)
064. 복잡도 (★★★)
065. 애플리케이션 성능 개선 (★★★)

054. 애플리케이션 테스트 (★★☆)

개념) 잠재되어 있는 결함 찾아내는 행위 / 요구사항 만족하는지 확인(사용자중심), 기능을 정확히 수행하는지 검증(개발자중심)
- 필요성) 오류 발견, 예방 / 신뢰도 향상 / 최소한의 시간, 노력 ~> 많은 결함 찾을 수 있음
SW 분류
- 상용 SW) 산업 범용 소프트웨어(시스템SW/미들웨어/응용SW) / 산업 특화 SW
- 서비스 제공 SW) 신규 개발 SW / 기능 개선 SW / 추가 개발 SW / 시스템 공합 SW
애플리케이션 테스트의 기본 원리) 잠재적 결함 줄일 수 있으나 SW에 결함이 없다고 증명 X ~> 완벽한 테스팅 불가능 / 테스트 ∝ (1/위험) / 작은 부분에서 시작, 점점 확대하며 진행 / 개발자와 상관 없는 팀에서 수행
- 파레토 법칙) 오류의 80%는 전체 모듈 20% 내에서 발견
- 특정 모듈 집중) 대부분의 결함이 소수의 특정 모듈에 집중해서 발생하는 결함
- 살충제 패러독스) 벌레에 내성 생겨 죽지 않는 현상... 동일 테스트 반복 시 더이상 결함이 발견되지 않음. 따라서 테스트 케이스 지속적으로 보완, 개선해야 함
- 오류-부재의 궤변) SW결함 모두 제거해도 사용자의 요구사항을 만족 못 시키면 해당 SW는 품질이 높다고 ㅁ라할 수 X

055. 애플리케이션 테스트의 분류 (★★☆)

프로그램 실행 여부에 따른 테스트
- 정적 테스트) 프로그램을 실행하지 않고 소스 코드 대상으로 분석하는 테스트 / SW 개발 초기에 결함 발견할 수 있어 SW 개발 비용 낮추는데 도움 / 워크스루, 인스펙션, 코드검사 등
- 동적 테스트) 프로그램을 실행해 오류 찾는 테스트... SW 개발의 모든 단계에서 테스트 수행 가능 / 블랙&화이트박스 테스트
테스트 기반에 따른 테스트
- 명세 기반 테스트) 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 테스트 / 동등 분할, 경계 값 분석 등
- 구조 기반 테스트) SW 내부 논리 흐름에 따라 테스트 케이스 작성, 확인 / 구문기반, 결정기반, 조건기반 등
- 경험 기반 테스트) 유사SW나 기술 등에 대한 테스터의 경험을 기반으로 수행... 명세 불충분하거나 테스트 시간에 제약 있을 경우 효과적 / 에러 추정의 체크리스트, 탐색적 테스팅
시각에 따른 테스트
- 검증 테스트) 개발자 시각에서 제품 생산 과정 테스트... 명세서대로 완성 됐는지
- 확인 테스트) 사용자 시각에서 생산된 제품의 결과를 테스트... 사용자가 요구한대로 제품 완성? 동작 잘 되는지
목적에 따른 테스트
- 회복 테스트) 일부러 실패하도록 한 후 올바르게 복구되는지
- 안전 테스트) 보호도구가 불법칩입으로부터 시스템을 보호할 수 있는지
- 강도 테스트) 과부하 시에도 SW가 정상적으로 실행되는지
- 성능 테스트) 실시간 성능, 전체적인 효율성 진단하는 테스트... SW 응답시간, 처리량 등 테스트
- 구조 테스트) SW 내부 논리적인 경로, 소스코드의 복잡도 등을 평가
- 회귀 테스트) SW 변경, 수정된 코드에서 새로운 결함이 없음을 확인
- 병행 테스트) 변경된 SW&기존 SW에 동일 데이터를 입력해 결과 비교

056. 테스트 기법에 따른 애플리케이션 테스트 (★★★)

화이트박스 테스트(White Box Test)) 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스 설계 / 테스트 과정 초기에 적용 / 모듈 안 작동 직접 관찰 / 모든 문장 한 번 이상 실행
화이트박스 테스트 종류
- 기초 경로 검사(Base Path Testing) : 대표적 / 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법... 결과는 실행 경로의 기초를 정하는 데 지침으로 사용
- 제어 구조 검사(Control Structure Testing) : 조건 검사(프로그램 모듈 내 있는 논리적 조건 테스트) / 루프 검사(반복 구조에 초점 맞춰 실시) / 데이터 흐름 검사(변수 정의, 사용 위치에 초점)
화이트박스 테스트 검증 기준
- 문장 검증 기준(Statement Coverage) : 소스 코드 모든 구문이 한 번 이상 수행되도록
- 분기 검증 기분(Branch Coverage) : 결정 검증 기준 / 모든 조건문에 대해 조건이 T, F인 경우가 한번 이상 수행되도록 테스트
- 조건 검증 기준(Condition) : 조건문에 포함된 개별 조건식 결과가 T, F인 경우가 한번 이상 수행되도록 테스트
- 분기/조건 기준 : 분기, 조건 검증 기준 모두 만족... 조건문이 T, F인 경우에 따라 조건 검증의 입력 데이터를 구분하는 테스트 케이스 설계
검증 기준 종류
- 기능 기반 커버리지) 실제 테스트가 수행된 기능 수 / 전체 기능 수
- 라인 커버리지) 테스트 시나리오가 수행한 코드 라인 수 / 전체 코드 수
- 코드 커버리지) 소스 코드의 구문, 분기, 조건 등의 구조가 얼마나 테스트 되었는지 측정
블랙박스 테스트(Black Box Test)) SW가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트(기능 테스트) / 프로그램 구조 고려 X... 테스트 케이스는 프로그램 or 모듈 요구, 명세를 기초로 결정 / SW 인터페이스에서 실시되는 테스트 / 누락기능, 인터페이스 오류, 자료구조&외부데이터 접근 오류, 행위&성능 오류, 초기화&종료 오류 등 발견하기 위해 사용
블랙박스 테스트 종류
- 동치 분할 검사(Equivalence Partitioning Testing, 동치 클래스 분해) : 입력 자료에 초점, 테스트 케이스 만들고 검사 / 프로그램 입력 조건에 타당한 입력 자료&타당치 않은 자료 개수 같게 해서 테스트 케이스 정하고, 해당 입력에 맞는 결과 출력 되는지 확인
- 경계값 분석(Boundary Value Analysis) : 입력 자료에만 치중한 동치 분할 기법 보완 / 입력 조건의 중간값보다 경계값에서 오류 발생 확률 높다는 점 이용 ~> 경계값을 테스트케이스로 선정
- 원인-효과 그래프 검사(Cause-Effect Graphing Testing) : 입력 데이터 간 관계, 출력에 영향을 미치는 상황을 체계적으로 분석 후 효용성 높은 테스트 케이스 선정해 검사
- 오류 예측 검사(Error Guessing) : 데이터 확인 검사/ 과거 경험, 확인자 감각으로 테스트... 다른 블박 테스트 기법으로 찾을 수 없는 오류 찾아내는 일련의 보충적 검사 기법
- 비교 검사(Comparison Testing) : 여러 버전의 프로그램에 동일 테스트 자료 제공 ~> 동일 결과 출력되는지 확인

057. 개발 단계에 따른 애플리케이션 테스트 (★★★)

개발 단계에 따른 애플리케이션 테스트) SW개발 단계에 따라 분류한 것을 테스트 레벨

단위테스트(Unit Test)) 코딩 직후 SW 설계의 최소 단위인 모듈이나 컴포넌트에 초점 맞춰 테스트 / 인터페이스, 외부적 I/O, 자료구조, 독립적 기초 경로, 오류 처리 경로, 경계 조건 등 검색 / 요구사항 기반으로 한 기능성 테스트를 최우서 수행 / 구조기반 많이 사용
- 구조 기반 테스트) 프로그램 내부 구조, 복잡도 검증하는 화이트박스 테스트 시행 / 제어흐름, 조건결정
- 명세 기반 테스트) 목적, 실행 코드 기반의 블랙박스 테스트 시행 / 동등 분할, 경계값 분석
- 발견 가능한 오류) 알고리즘 오류에 따른 원치않은 결과 / 무한루프 / 틀린 계산 수식에 의한 결과
통합 테스트(Integration Test)) 단위 테스트 완료된 모듈들 결합 ~> 하나의 시스템으로 완성시키는 과정에서 테스트
시스템 테스트) 개발된 SW가 해당 컴퓨터 시스템에서 완벽히 수행하는지 점검 / 실제 환경과 유사하게 / 기능적(블랙박스), 비기능적(화이트박스) 요구사항으로 구분해 테스트
인수 테스트(Acceptace Test)) 개발된 SW가 사용자 요구사항을 충족하는지 중점 / 사용자가 직접 테스트 / 문제 없음 인수 후 종료
- 사용자 인수 테스트) 사용자가 적절성 확인
- 운영상의 인수 테스트) 시스템관리자가 인수 시 수행하는 테스트... 백업&복원 시스템, 재난복구, 사용자관리, 정기점검 등 확인
- 계약 인수 테스트) 계약상 조건 준수하는지
- 규정 인수 테스트) 지침, 법규, 규정 등이 맞는지
- 알파 테스트) 개발자의 장소에서 사용자가 개발자 앞에서 테스트 / 통제된 환경에서 시행, 오류&사용상 문제점을 함께 확인하며 기록
- 베타 테스트) 선정된 최종 사용자가 여러 명의 사용자 앞에서 테스트(필드 테스트) / 개발자에 의해 제어되지 않은 상태에서 테스트 ~> 발견된 오류, 문제점 기록해 개발자한테 주기적 보고

058. 통합 테스트 (★★★)

통합된 테스트) 단위 테스트 완료된 모듈들 결합 ~> 하나의 시스템으로 완성시키는 과정에서 테스트
- 비점진적 통합 방식) 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트... 빅뱅 통합 테스트 방식 / 규모 작은 SW에 유리, 단시간에 테스트 가능 / 전체 대상 테스트 ~> 오류 발견, 장애 위치 파악, 수정 어렵
- 점진적 통합 방식) 모듈 단위로 단꼐적 통합, 테스트... 하향식/상향식/혼합식 / 오류 수정에 용이, 인터페이스와 연관된 오류를 완전히 테스트할 가능성 높음
하향식 통합 테스트(Top Down Integration Test) : 프로그램의 상위 모듈 → 하위 모듈 방향으로 통합하면서 테스트
- 주요 제어 모듈 기준으로 아래 단계로 이동하며 통합... 깊이(↓) 우선 통합법, 넓이(→) 우선 통합법 사용 / 테스트 초기부터 사용자에게 시스템 보여주기 ㄱㄴ / 상위 모듈에선 테스트 케이스 사용 어렵
- 절차
  1. 주요 제어 모듈은 작성된 프로그램 사용, 종속 모듈은 스텁으로 대체
  2. 통합법에 따라 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈로 교체
  3. 모듈이 통합될 때마다 테스트 실시
  4. 새로운 오류 발생하지 않음 보증을 위해 회귀 테스트(반복) 실시
상향식 통합 테스트(Bottom Up Integration Test) : 하위 모듈 → 상위 모듈 방향으로 통합하며 테스트
- 스텁 필요 없지만, 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터 필요
- 절차
  1. 하위 모듈을 클러스터로 결합
  2. 상위 모듈에서 데이터의 입/출력을 확인하기 위해 더미 모듈인 드라이버 작성
  3. 통합된 클러스터 단위로 테스트
  4. 테스트 완료 시 클러스터는 프로그램 구조 상위로 이동해 결합, 드라이버는 실제 모듈로 대체
테스트 드라이버, 테스트 스텁 차이점
- 드라이버) 테스트 대상의 하위 모듈을 호출하는 구조... 매개변수를 전달, 모듈 테스트 수행 후 결과 도출 / 상향식 테스트 / 존재하는 하위 모듈&존재않는 상위 모듈 간 인터페이스 역할 / 개별 완료 시 드라이버는 원래 모듈과 교체
- 스텁) 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구... 일시적으로 필요한 조건만 가지고 있는 시험용 모듈 / 하향식 테스트 / 일시적으로 필요한 조건만 가지고 임시로 제공되는 가짜 모듈 / 시험용 모듈... 일반적으로 드라이버보다 작성 쉬움
혼합식 통합 테스트) 하위 수준 - 상향식 통합 / 상위 수준 - 하향식 통합 ~> 최적의 테스트 지원... 샌드위치식 통합 테스트라고도 함
회귀 테스팅(Regression Testing) : 이미 테스트된 프로그램의 테스팅 반복... 통합 테스트로 변경된 모듈, 컴포넌트에 새로운 오류 있는지 확인 / 비용, 시간 문제로 기존 테스트 케이스 중 변경된 부분을 테스트할 수 있는 테스트 케이스만 선정해 수행
- 선정 방법) 모든 기능을 수행할 수 있는 대표적 테스트 케이스 선정 / 파급 효과가 높은 부분이 포함된 테스트 케이스 / 실제 수정이 발생한 모듈&컴포넌트에서 시행하는 테스트 케이스

059. 애플리케이션 테스트 프로세스 (★☆☆)

테스트 계획 → 테스트 분석/디자인 → 테스트 케이스/시나리오 작성 → 테스트 수행 → 테스트 결과 평가/리포팅 → 결함 추적 및 관리
- 테스트 계획) 테스트 목표 정의&테스트 대상, 범위 결정 / 구조 파악 / 조직, 비용 산정 / 시작&종료조건 설정
- 테스트 분석/디자인) 리스크 분석, 우선순위 결정 / 테스트 데이터, 환경, 도구 등 준비
- 테스트 케이스/시나리오 작성) 테스트용 스크립트 작성
- 나머지는 아래에서~

060. 테스트케이스/테스트시나리오/테스트오라클 (★★☆)

테스트 케이스(Test Case) : 구현된 SW가 요구사항을 정확히 준수했는지 확인하기 위한 테스트 항목 명세서 / 미리 설계시 테스트 오류 방지, 낭비 줄임 / 목표&방법 설정 후 작성 / 시스템 설계에서 작성하는 게 굿~
순서) 테스트 계획 검토 및 자료 확보 → 위험평가 및 우선순위 결정 → 테스트 요구사항 정의 → 테스트 구조 설계 및 테스트 방법 결정 → 테스트 케이스 정의 → 테스트 케이스 타당성 확인 및 유지보수
테스트 시나리오) 케이스 적용 순서에 따라 여러 개의 테스트 케이스들을 묶은 집합... 적용하는 구체적인 절차 명세한 문서 / 테스트 항목 빠짐없이 수행 가능
테스트 시나리오 작성 시 유의사항) 여러 개(시스템, 모듈, 항목별 등)의 시나리오로 분리해 작성 / 유스케이스 간 업무 흐름이 정상적인지 테스트 할 수 있도록 작성 / 연계가 정상적으로 동작하는지 테스트 할 수 있게 작성
테스트 오라클) 테스트 결과가 올바른지 판단하려고 사전에 정의된 참값을 대입해 비교하는 기법
- 제한된 검증 : 모든 테스트 케이스에 적용 X
- 수학적 기법 : 값을 수학적 기법을 이용해 구할 수 있음
- 자동화 기능 : 테스트 대상 프로그램의 실행, 결과비교, 커버리지 측정 등을 자동화할 수 있음
- 종류) 참 오라클 / 샘플링 오라클 / 추정 오라클 / 일관성 검사 오라클 등
종류
- 참(T) 오라클 : 모든 입력 값에 대해 기댓값(결과) 제공 ~> 발생된 모든 오류 검출 가능
- 샘플링 오라클 : 특정 값에 대해서만 기대값 제공
- 추정 오라클 : 특정 값에 대해 기대값 제공, 나머지는 추정으로 처리... 샘플링 개선
- 일관성 검사 오라클 : 앱 변경 있을 때, 테스트 케이스의 수행 전, 후 결과 값이 같은지 확인

061. 테스트 자동화 도구 (★★☆)

테스트를 자동화 할 수 있도록 도와주는 도구
- 장) 반복작업 자동화 ~> 비용 절감 / 다중 플랫폼 호환성, SW구성, 기본 테스트 등 품질 보장 / 요구사항 일관성 있게 검증 / 객관적 평가 기준 / 다양한 표시 형태 제공(그래프처럼) / UI없이 정밀테스트 가능
- 단) 교육, 학습 필요 / 단계별로 적용하기 위한 시간, 비용, 노력 필요 / 비공개 상용 도구는 비쌈
고려사항) 재사용, 측정 불가능한건 제외 / 모든 과정 자동화 도구는 X... 용도에 맞게 / 자도오하 도구 환경 설정 등등을 고려해 엔지니어, 프로젝트 일정 계획
유형
- 정적 분석 도구) 프로그램 실행 않고 분석... 코딩 표준, 코딩 스타일, 복잡도, 남은 결함 등 발견하기 위해 사용 / 테스트를 수행하는 사람이 작성 코드 이해해야 분석 가능
- 테스트 케이스 생성 도구) 자료 프름도 / 기능 테스트 / 입력 도메인 분석(원시 코드 내부 참조X) / 랜덤 테스트
- 테스트 실행 도구) 스크립트 언어 사용해 테스트 실행하는 방법... 테스트 데이터, 테스트 수행방법 등이 포함된 스크립트 작성 후 실행 / 데이터 주도 접근 방식 / 키워드 주도 접근 방식
- 성능 테스트 도구) 앱의 처리량, 응답/경과 시간, 자원 사용 등을 인위적으로 적용한 가상의 사용자들을 만들어 테스트 수행
- 테스트 통제 도구) 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구 / 형상 관리도구, 결함추적 관리 도구 등
- 테스트 하네스) 앱의 컴포넌트, 모듈을 테스트하는 환경의 일부분... 테스트 지원위해 생성된 코드, 데이터 의미
테스트 하네스 구성요소
- 테스트 드라이버 : 테스트 대상의 하위 모듈 호출, 매개변수 전달, 모듈 테스트 수행 후 결과 도출하는 도구
- 테스트 스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구... 일시적으로 필요 조건만 가지고 있는 테스트용 모듈
- 테스트 슈트 : 컴포넌트, 모듈, 시스템에 사용되는 테스트 케이스 집합
- 테스트 케이스 : 요구사항 준수했는지 확인하기 위해 만들어진 테스트 항목 명세서
- 테스트 스크립트 : 자동화된 테스트 실행 절차에 대한 명세서
- 목 오브젝트 : 사전에 사용자의 행위를 조건부로 입력 ~> 상황에 맞는 예정된 행위 수행하는 객체
자동화도구
- 테스트 계획) 요구사항 관리
- 테스트 분석/설계) 테스트 케이스 생성
- 테스트 수행) 테스트 자동화/정적 분석/동적 분석/성능 테스트/모니터링
- 테스트 관리) 커버리지 분석/형상관리/결함 추적, 관리

062. 결함관리 (★★☆)

결함 정의) SW가 개발자가 설계한 것과 다르게 동작, 겨로가 발생하는 것
프로세스) 결함 관리 계획 → 결함 기록(DB에 기록) → 결함 검토(검토&개발자전달) → 결함 수정 → 결함 재확인 → 최종 결함 분석 및 보고서 작성
결함 상태 추적) 결함은 지속적으로 상태 변화 추적, 관리
- 측정 지표) 결함 분포 / 결함 추세 / 결함 에이징
결함 추적 순서) 결함 등록 → 결함 검토 → 결함 할당 → 결함 수정 → 결함 조치 보류 → 결함 종료 → 결함 해제
결함 분류) 시스템 / 기능 / GUI / 문서
결함 심각도) High(프로세스 진행X) / Medium(시스템 흐름에 영향) / Low(흐름에 영향X)
결함 우선순위) 결정적 / 높음 / 보통 / 낮음 // 즉시 해결 / 주의 요망 / 대기 / 권고 등
결함 관리 도구) Manis / Trac / Redmine / Bugzilla

063. 애플리케이션 성능 분석 (★★☆)

애플리케이션 성능) 사용자가 요구한 기능을 연비 좋게 처리하는 정도
- 측정 지표) 처리량(Throughput) / 응답시간(Response Time) / 경과 시간(Turn Aroud Time) / 자원 사용률(Resource Usage)
성능 테스트 도구) JMeter / LoadUI / OpenSTA
시스템 모니터링 도구) 자원 사용량 확인, 분석하는 도구... Scouter, Zabbix
성능 저하 원인 분석) DB 과부하 / 타임아웃 / 커넥션 풀 너무 크거나 작음 등등등 대충 느낌으로 가는겨~~^^

064. 복잡도 (★★★)

시스템 복잡도 높으면 장애 발생할 수 있음... 미리 제거할 필요 O / LOC(Line of code), 순환 복잡도 등
시간 복잡도) 소소익선
- 점근 표기법) 명령어 실행 횟수 표기 / 빅오 표기법(실행시간이 최악일 떄 표기... 실횡횟수<표기수치) / 세타표기법(평균일 때... 평균적 수치 표기) / 오메가 표기법(최상일 때... 실행횟수는 표기수치보다 작을 수 없음)
빅오 표기법
- O(1) : 문제 해결에 하나의 단계만 거침 / 스택 삽입, 삭제
- O(logv2 n) : 필요 단계가 입력값(n) or 조건에 의해 감소 / 이진트리, 이진 검색
- O(n) : 단계, 입력값 관계가 1:1 / for문
- O(nlogv2 n) : 단계가 저거만큼 실행 / 힙정렬, 2-way 합병 정렬
- O(n^2) : 제곱만큼 수행 / 삽입 정렬, 쉘 정렬, 선택 정렬, 버블 정렬, 퀵 정렬
- O(2^n) : 2의 n제곱만큼 수행 / 피보나치 수열
순환 복잡도 : 한 프로그램의 논리적인 복잡도를 측정하기 위한 SW 척도 / 맥케이브 순환도(멕케이브 복잡도 메트릭) 이라고도 함 / 제어 흐름도 이론에 기초
- 계산된 값은 프로그램의 독립적인 경로 수 정의, 모든 경로가 한 번 이상 수행되엇음을 보장하기 위해 행해지는 테스트 횟수의 상한선 제공
- 순환 복잡도 = E(화살표수) - N(노드수) + 2

065. 애플리케이션 성능 개선 (★★★)

소스코드 최적화) 클린코드 작성
- 나쁜 코드) 스파게티 코드(얽혀있음) / 외계인 코드(오래되거나 참고문서 없어서 유지보수 어려운거)
- 클린 코드) fuxxing good code
  - 작성원칙) 가독성 / 단순성 / 의존성 배제 / 중복성 최소화 / 추성화
소스 코드 최적화 유형
- 클래스 분할 배치 : 하나의 클래스는 역할 하나만 수행하도록
- 느슨한 결합 : 인터페이스 클래스 이용 ~> 추상화된 자료 구조, 메소드 구현해 의존성 최소화
- 코딩 형식 준수 / 좋은 이름 사용 / 적절한 주석문 사용
소스 코드 품질 분석 도구
- 정적 분석 도구) 실행X, 코딩 스타일&표준&결함 확인 / 비교적 개발 초기의 결함 찾을 때 사용, 완료시점에선 품질 검증 차원 / 비정상적인 패턴 찾기 / 동적에서 발견하기 어려운 결함 찾아냄 / 소스코드에서 코딩의 복잡도, 모델 의존성, 불일치성 분석 / pmd, cppcheck, SonarQube, chechstyle, ccm, cobertura
- 동적 분석 도구) 실행 ~> 코드에 존재하는 메모리 누수, 스레드 결함 등 분석 / Avalanche, Valgrind 등

728x90