10-2. 애플리케이션 통합 테스트

1-1. 요구사항 분석 https://minjh1126.tistory.com/44

1-2. 현행시스템 분석 https://minjh1126.tistory.com/45

1-3. 요구사항 확인 https://minjh1126.tistory.com/46

2-1. UI 요구사항 확인 https://minjh1126.tistory.com/47

2-2. UI 설계 https://minjh1126.tistory.com/48

3-1. 논리 데이터 저장소 확인 https://minjh1126.tistory.com/54

3-2. 물리데이터 저장소 설계 ~ 3.3 데이터베이스 기초 활용 https://minjh1126.tistory.com/57

4. 통합구현 https://minjh1126.tistory.com/58

5. 인터페이스 구현 https://minjh1126.tistory.com/59

6. 프로그래밍 언어 https://minjh1126.tistory.com/60

7-1. 데이터베이스 기본 https://minjh1126.tistory.com/49

7-2. 응용 SQL 작성하기 https://minjh1126.tistory.com/50

8-1. 개발환경 구축 https://minjh1126.tistory.com/51

8-2. 공통 모듈 구현 https://minjh1126.tistory.com/52

9-1. 소프트웨어 개발 보안 설계 https://minjh1126.tistory.com/53

9-2. 소프트웨어 보안 개발 구현 https://minjh1126.tistory.com/55

10-1. 애플리케이션 테스트 케이스 설계 https://minjh1126.tistory.com/56

 

2. 애플리케이션 통합 테스트

1. 애플리케이션 테스트 수행

1. 단위 테스트

• 단위 테스트: 개별적인 모듈 테스트. 모듈을 단독으로 실행할 수 있는 테스트 베드가 필요.
• 수행 도구
  • 테스트 드라이버: 상향식 테스트에서 사용되는 가상 상위 모듈. 필요 테스트를 인자를 통해 넘겨주고 완료 후 결과값을 받음.
  • 테스트 스텁: 하향식 테스트에서 사용되는 가상 하위 모듈. 필요한 조건만 가지고 임시로 제공됨.
• 원칙
  • 빠르게 수행되어야 하고 다른 컴포넌트에 의존해서는 안 됨.
  • 테스트를 몇 번 실행해도 같은 결과가 나와야하고, 사람의 개입 없이 테스트 결과를 알 수 있도록 작성해야함.

2. 통합 테스트

• 통합 테스트: 각 모듈 간 인터페이스 관련 오류 및 결함을 찾아내기 위한 테스트. 설계 단계에서 제시된 애플리케이션과 동일한 구조와 기능을 하는지 확인.
• 분류
  • 점증적 방식
    • 하향식 통합: 메인으로부터 내려가면서 테스트 진행. 깊이 우선 방식과 넓이 우선 방식이 있음.
      • 특징: 검사 초기에 시스템 구조가 파악되어 있어야 함. 스텁 사용. 깊이 우선, 넓이 우선 방식에 따라 차례대로 스텁이 하나씩 실제 모델로 교체되어 가는 시스템.
    • 상향식 통합: 최하위 모듈로부토 위쪽으로 올라가면서 테스트.
      • 특징: 하위 모듈들이 클러스터로 결합되고 상위 모듈인 드라이버 작성. 테스트가 완료되면 위쪽으로 결합되며 실제 모듈 등으로 교체.
    • 샌드위치 통합: 상향식 + 하향식 방법. 큰 규모의 통합 테스트에서 사용됨.
      • 특징: 병렬 테스트가 가능하고 시간 절약이 가능. 스텁과 드라이버의 필요성이 많이 강조되고 비용이 많이 소모됨.  
        • 비점증적(빅뱅) 방식: 모든 컴포넌트를 사전에 통합해 한꺼번에 테스트함. 

방안	빅뱅 테스트	상향식 테스트	하향식 테스트	샌드위치 테스트
방법	모듈 전체 통합 후 수행	하위 -> 상위	상위 -> 하위	하향식 + 상향식
드라이버/스텁	X	드라이버	스텁	드라이버, 스텁
장점	단시간, 작은 시스템	장애 위치 파악 쉬움 모든 모듈 개발 필요 X	장애 위치 파악 쉬움 이른 프로토타입 가능 중요 모듈 선 테스트 가능	병렬 테스트, 시간 절약 큰 규모의 통합 테스트
단점	장애 위치 파악 어려움 모든 모듈이 개발된 후	중요 모듈을 마지막에 테스트 이른 프로토타입 불가	많은 스텁 필요 하위 모듈 테스트 불충분	비용 많이 소모

 

3. 테스트 자동화 도구

• 테스트 자동화 도구: 테스트 작업을 스크립트로 구현해 시간 단축, 인력 최소화, 테스트를 쉽고 효율적이게 가능
• 유형
  • 정적 분석 도구: 실행시키지 않고 테스트. 코딩 표준, 스타일, 복잡도 등 탐색. 코드에 대한 이해가 바탕이 되어야 함.
  • 테스트 실행 도구: 테스트를 위해 작성된 스크립트를 실행함. 스크립트에는 특정 데이터와 테스트 수행 방법이 포함되어 있음.
    • 데이터 주도 접근 방식: 테스트 데이터를 스프레드 시트에 저장. 다양한 테스트 데이터를 이용해 반복 실행이 가능하고, 스크립트 언어에 익숙하지 않아도 데이터만 추가해서 사용 가능.
    • 키워드 접근 주도 방식: 수행할 동작을 나타내는 키워드와 테스트 데이터를 스프레드 시트에 저장. 키워드로 수행 동작을 정의할 수 있고 특성에 맞춰 테일러링 수행 가능.
  • 성능 테스트 도구: 처리량, 응답 시간, 경과 시간, 자원 사용률에 대해 가상의 사용자를 생성하고 테스트 해 성능 목표 달성 여부 확인.
  • 테스트 통제 도구: 테스트 계획 및 관리, 테스트 데이터를 관리하는 형상 관리, 결함 관리, 협업 지원을 위한 도구 등이 있음.
• 테스트 하네스: 테스트 환경의 일부분으로, 테스트를 지원하기 위한 코드나 데이터. 단위 테스트에 사용하기 위해 작성.
  • 구성 요소
    • 테스트 드라이버: 하위 모듈을 호출하는 등 상향식 테스트에 필요.
    • 테스트 스텁: 타 모듈의 기능을 수행하는 도구로 하향식 테스트에 필요.
    • 테스트 슈트: 테스트 대상 컴포넌트나 모듈, 시스템에 다용되는 테스트 케이스의 집합.
    • 테스트 케이스: 입력값, 실행 조건, 기대 결과 등의 집합.
    • 테스트 시나리오: 테스트 되어야할 기능 및 특징, 테스트 필요 상황을 작성한 문서. 하나의 단일 테스트 시나리오가 여러 테스트 케이스 포함 가능.
    • 테스트 스크립트: 자동화된 테스트 실행 절차에 대한 명세.
    • 목 오브젝트: 사용자의 행위를 조건으로 입력해두면, 그 상황에서 예정된 행위를 수행.

 

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

1. 테스트 결과 분석

• 결함
  • 오류: 결함의 원인으로 사람(개발자, 분석가 등)에 의한 실수.
  • 결점: 개발 활동에 있어서 시스템의 고장을 일으키고 오류가 있을 때 발생.
  • 버그: 프로그램 오류로 인해 예상치 못한 결과 발생.
  • 고장/문제: 소프트웨어 제품에 포함된 결함이 실행될 때 발생.

2. 결함 관리

• 결함 관리: 테스트 수행 후 발생한 결함의 재발 방지와 유사 결함 발견 시 처리 시간 단축을 위한 결함 추적 및 관리 활동.
• 결함 관리 프로세스 활동: 결함 관리 계획 - 결함 기록(결합 DB에 저장) - 결함 검토(등록된 결함의 내용 검토 및 전달) - 결함 수정 - 결함 재확인 - 결합 상태 추적 및 모니터링(대시보드나 게시판 형태의 서비스 제공) - 최종 결함 분석 및 보고서 작성
• 결함 생명주기
  • 결함 등록(Open): 결함을 분석 후 구체화, 고립화, 일반화한 결함으로서 보고됨. 결함 보고서에 기록되어 추척의 대상이 됨.
  • 결함 검토(Reviewed): 등록된 결함 처리 방안 검토. 위험성(발생 가능성, 심각성, 긴급성)을 바탕으로 이번에 수정되거나 릴리스에서 수정되거나 무시될 수 있음.
  • 결함 할당(Assigned): 수정할 개발자가 결정되고 결함 해결이 요구됨.
  • 결함 수정(Resolved): 결함 해결 완료.
  • 결함 확인(Verified): 결함 처리가 합당하고 정확한지 검증이 완료됨.
  • 결함 종료(Closed): 정확한 수정이 이뤄졌다고 판단되어 종료.
  • 결함 재등록(Reopen): 정확하게 수정되지 않아 수정 재요청.
  • 결함 조치 보류(Deferred): 등록된 결함을 바로 수정하지 않고 다음 릴리스로 미룸. 적절한 시점에 다시 Reopen욀 수 있음.

 

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

1. 테스트 커버리지

• 테스트 커버리지: 주어진 테스트 케이스에 의해 수행되는 테스트 범위를 측정하는 테스트 품질 측정 기준.
• 유형
  • 기능 기반 커버리지: 테스트 대상 애플리케이션 기능을 모수로 설정하고 실제 테스트가 수행된 기능의 수를 측정. 100% 달성을 목표로 하고, UI가 맣은 시스템의 경우에는 화면을 모수로 사용.
  • 라인 커버리지: 코드 라인 수를 모수로 수행한 소스 코드 라인 수 측정. 단위 테스트에서는 라인 커버리지를 척도로 삼음.
  • 코드 커버리지: 충분성 지표 중 하나로 소스 코드 구문, 조건, 결정 등의 구조 코드 자체가 얼마나 테스트 되었는지 측정. 테스트 커버리지라고 하면 대체로 코드 커버리지.

2. 결함 식별 및 관리

• 분류(심각도)
  • 치명적 결함: 테스트를 완전히 방해하거나 못하게 함 - 데이터 손실, 시스템 충돌
  • 주요 결함: 기능이 기대와 많이 다르게 동작하거나 기능을 못함 -기능 장애
  • 보통 결함: 특정 기준을 충족하지 못하거나 전체에 영향을 주지 않는 일부 기능이 부자연스러움 - 사소한 기능 오작동
  • 경미한 결함: 불편함 유발 - 표준 위반, UI 잘림
  • 단순 결함: 사소한 버그, 기능에 영향이 없지만 수정되어야 함 - 미관상 이슈

 

 

3. 애플리케이션 성능 분석

1. 애플리케이션 성능 분석

1. 개요

• 성능 측정 지표
  • 처리량: 주어진 시간 동안의 처리 가능한 트랜잭션 수. 웹 애플리케이션에서는 시간 당 페이지 수.
  • 응답 시간: 사용자 입력이 끝난 후 응답 출력 개시까지의 시간. 
  • 경과 시간: 요구를 입력한 순간부터 결과의 출력이 완료될 때까지의 시간.
  • 자원 사용률: 트랜잭션을 처리하는 동안의 CPU 사용량, 네트워크 사용량.
• 성능 분석 도구
  • 점검 도구(성능/부하/스트레스): 사용자를 임의로 생성하고 시스템에 부하나 스트레스를 줘 처리량, 응답 시간, 경과 시간 등 점검.
  • 모니터링 도구: 자원 사용량을 확인하고 분석. 성능 모니터링 및 저하 원인 분석, 시스템 부하량 분석, 장애 진단, 사용자 분석, 용량 산정 등의 기능을 제공해 안정적 운영을 지원.

 

2. 애플리케이션 성능 개선

1. 코드 최적화

• 코드 종류
  • 배드 코드: 다른 개발자가 로직을 이해하기 어렵게 작성. 
    • 사례 
      • 외계인 코드: 아주 오래됐거나 참고문서, 개발자가 없어 유지보수가 어려움.
      • 스파게티 모드: 소스 코드가 복잡하게 얽혀있어 작동을 잘 하지만 코드를 읽었을 때 파악하기는 어려움.
      • 알 수 없는 변수명: 변수나 메서드의 이름 정의를 알 수 없음.
      • 로직 중복: 동일한 처리 로직.
    • 유형
      • 오염: 기능을 수행하지 못하는 많은 컴포넌트가 존재.
      • 문서 부족: 현재 코드와 문서가 일치하지 않고 수정과 변경을 위한 도메인 지식이 크게 증가하지만 개발자의 지식 부족.
      • 의미 없는 이름: 이름에 명확한 의미가 없거나 실제 작동과 불일치.
      • 높은 결합도: 컴포넌트들 간의 흐름이 복잡하게 연결됨.
      • 아키텍처 침식: 아치텍처가 더이상 구별되지 않고 여러 솔루션으로 이뤄져 시스템 품질 하락.
  • 클린 코드: 가독성이 높고 단순하고 의존성이 적고 중복이 최소화된 코드.
    • 원칙: 가독성, 단순성, 의존성 최소, 중복성 제거, 추상화.
    • 최적화 기법: 의미 있는 이름, 간결하고 명확한 주석, 보기 좋은 배치, 작은 함수, 읽기 쉬운 제어 흐름, 오류 처리, 클래스 분할 배치, 느슨한 결합 기법, 코등 형식 기법 적용

2. 소스 코드 품질 분석

• 도구 유형
  • 정적 분석 도구(실행X)
    • pmd: 자바 및 다른 언어 소스 코드 버그, 데드코드 분석.
    • cppcheck: C/C++의 메모리 누수, 오버플로우 등 분석.
    • SonarQube: 소스코드 품질 통합 플랫폼. 플러그인 확장 가능.
    • checkstyle: 자바 코드에 대한 코딩 표준 검사 도구.
    • ccm: 다양한 언어의 코드 복잡도 분석. 리눅스, 맥 환경의 CLI 형태 지원.
    • cobertura: jcoverage 기반의 테스트 커버리지 측정 도구.
  • 동적 분석 도구(실행O)
    • Avlanche: Valgrind 프레임워크 및 STP 기반 소프트웨어 에러 및 취약점 동적 분석.
    • Valgrind: 자동화된 메모리 및 스레드 결함 발견 분석 도구.

3. 성능 개선 방안

• 성능 개선 방안: 소스 코드 최적화, 아키텍처 조정을 통한 성능 개선, 프로그램 호출 순서 조정 적용.
• 소스 코드 춤질 도구 활용: 메모리 사용 최소화, 입출력 발생 최소화, System.out.println() 사용 제외.
• 리팩토링
  • 리팩토링: 유지보수 생산성 향상을 목적으로 기능을 변경하지 않고 복잡한 소스 코드를 수정 및 보완. 내부적인 구조, 관계 등을 단순화.
    • 목적: 유지보수성 향상, 유연한 시스템, 생산성 향상, 품질 향상.