[정처기 실기] 「1」 | 소프트웨어 구축 - (1.5) 애플리케이션 테스트 관리

[정처기 실기] 「1」 | 소프트웨어 구축 - (1.5) 애플리케이션 테스트 관리

> 「1」 소프트웨어 구축

「2」 데이터베이스 구축

「3」 운영체제

「4」 네트워크

「5」 정보보안

「6」 신기술 용어

 

1. 소프트웨어 공학 개념

2. 프로젝트 계획 / 분석

3. 소프트웨어 설계

4. 화면 설계

5. 서버 프로그램 구현

6. 인터페이스 구현

7. 객체지향 구현

> 8. 애플리케이션 테스트 관리

9. 소프트웨어 유지보수

10. 제품 소프트웨어 패키징

8. 애플리케이션 테스트 관리

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

소프트웨어 테스트

○ 결함(Fault)을 발견하기 위한 절차와 행위

○ 소프트웨어 테스트의 필요성 : 오류 발견 관점, 오류 예방 관점, 품질 향상 관점

○ 소프트웨어 테스트의 기본 원칙

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

  - 완벽한 테스팅은 불가능

  - 테스팅은 개발 초기에 시작해야 함

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

  - 결함 집중(Defect Clustering) : 파레토의 법칙(20% 모듈에서 전체 결함 80%) 

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

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

  - Brooks의 법칙 : 지연되는 프로젝트에 인력 추가 투입 시 더 지연

○ 테스트 산출물 : 테스트 계획서, 테스트 케이스, 테스트 시나리오, 테스트 결과서

 

테스트 오라클

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

○ 테스트 오라클의 유형

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

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

  - 휴리스틱 오라클 : 추정 결과를 제공하는 오라클

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

○ 테스트 시나리오 : 테스트 케이스 적용, 동작 순서에 따라 테스트 케이스를 묶은 집합

 

테스트 레벨

○ 단위 테스트 > 통합 테스트 > 시스템 테스트 > 인수 테스트

 

소프트웨어 테스트 기법

○ 프로그램 실행 여부

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

    : 동료검토

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

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

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

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

○ 테스트 기법

  - 화이트박스 테스트 : 소프트웨어의 내부 구조와 동작을 중점으로 검사하는 테스트 , 비기능적 테스트

    : 문장 검증, 선택(분기) 검증, 경로 검증

    : 기초 경로 검사(Basic Path Test) - McCabe가 제안, V(G) = E - N + 2

    : 제어 구조 검사(Control Structure Testing) - 조건 검사, 루프 검사, 자료 흐름 검사(변수 정의, 변수 사용 위치)

  - 블랙박스 테스트 : 프로그램의 사용자 요구사항 명세를 보며 테스트

    : 동등 분할 기법(Equivalence Partitioning Testing) - 입력 자료에 초점을 맞춰 테스트, 기능적 테스

    : 경계값 분석(Boundary Value Analysis) - 경계값을 테스트 케이스로 선정

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

    : 오류 예측 검사(Error Guessing) - 과거의 경험이나 테스터의 감각으로 테스트

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

    : 상태전이 검사(State Transistion Testion) - 상태를 변화시키는 이벤트와 입력값을 파악

○ 테스트에 대한 시각

  - 검증(Verification) : 개발자의 시각, 소프트웨어 개발 과정을 테스트 (단위, 통합, 시스템 테스트)

  - 확인(Validation) : 사용자의 시각, 완성된 소프트웨어의 결과를 테스트 (알파, 베타 테스트)

○ 테스트 목적

  - 회복(Recovery) : 고의로 실패를 유도

  - 안전(Security) : 보완적인 결함을 점검

  - 강도(Stress) : 과부화 테스트

  - 성능(Performance) : 응답하는 시간, 처리량, 반응속도

  - 구조(Structure) : 소스코드의 복잡도를 평가

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

  - 병행(Parallel) : 변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 비교

  - A / B 테스트 : 기존 서비스 대비 효과 테스트

  - 스모크 테스트(Smoke) : 테스트 환경의 테스트

○ 테스트 종류

  - 명세 기반 테스트 : 동등 분할, 경계값 분석 (블랙박스)

  - 구조 기반 테스트 : 구문 기반, 결정 기반, 조건 기반 (화이트박스)

  - 경험 기반 테스트 : 에러 추정, 체크리스트, 탐색적 테스팅

 

테스트 커버리지

○ 테스트를 얼마나 수행했는지 측정하는 기준

○ 테스트 커버리지 유형

  - 기능 기반 커버리지 : 기능을 모수로 설정

  - 라인 커버리지 : 전체 소스 코드의 Line 수를 모수로 설정

  - 코드 커버리지 : 소스 코드의 구문, 조건, 결정 측정 | if(결정 포인트[개별 조건식 && 개별 조건식])

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

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

    : 결정(분기) 커버리지 - 결정 포인트에 대해 수행

    : 조건 / 결정 커버리지 - 결정 포인트 T / F, 개별 조건식 T / F

    : 변경 조건 / 결정 커버리지 - 모든 결정 포인트 내 개별 조건식은 적어도 한 번 T / F

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

 

애플리케이션 통합 테스트

결함관리 도구

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

○ 결함관리 프로세스

  > 에러 발견

  > 에러 등록

  > 에러 분석

  > 결함 확정

  > 결함 할당

  > 결함 조치

  > 결함 조치 검토 / 승인

○ 결함 추이 분석

  - 결함 추이 분석

    : 테스트 완료 후 발견된 결함의 결함관리 측정지표의 속성값을 분석하고, 향후 결함이 발생할지 추정하는 작업

  - 결함관리 측정 지표 

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

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

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

  - 결함관리 항목

    : 결함 내용, 결함 ID, 결함 유형, 발견일, 심각도, 우선순위, 시정 조치 예정일, 수정 담당자, 재테스트 결과, 종료일

 

테스트 자동화 도구

○ 테스트를 효과적으로 수행하기 위해 스크립트나 도구를 활용하여 반복적인 테스트 작업을 자동화하는 방법

○ 테스트 자동화 도구 유형

  - 정적 분석 도구(Static Analysis Tools) : 애플리케이션을 실행하지 않고 분석하는 방법

    : Pmd, SonarQube, Cppcheck, Checkstyle

  - 테스트 실행 도구(Test Execution Tools) :  사전에 작성된 테스트 스크립터나 시나리오를 실행하는 도구

  - 성능 테스트 도구(Performance Test Tools) : 시스템의 성능, 부하, 스트레스 테스트를 위한 도구

    : JMeter, LoadRunner

○ 테스트 통제 도구(Test Control Tools) : 테스트의 전체 프로세스를 관리하는 도구

○ 테스트 장치(Test Harness) 구성요소

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

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

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

  - 테스트 케이스 : 입력 값, 실행 조건, 기대 결과 집합

  - 테스트 스크립트 : 자동화된 테스트 실행 절차

  - 목 오브젝트 : 조건부로 상황에 예정된 행위를 수행하는 객체

 

단위 테스트

○ 구조 기반테스트 진행, 기능성 테스트 최우선

 

통합 테스트

○ 소프트웨어 각 모듈 간 인터페이스 관련 오류 / 결함을 찾아내기 위한 테스트 기법

○ 통합 테스트 수행 방법의 분류

통합 테스트
점증적 방식		비 점증적 방식
상향식 통합 테스트	하향식 통합 테스트	빅뱅 테스트

 

애플리케이션 성능 개선

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

○ 데이터베이스 관련 성능 저하

  - 데이터베이스 락(DB Lock)

  - 불필요한 패치(DB Fetch)

  - 연결 누수(Connection Leack)

○ 내부 로직으로 인한 성능 저하 원인

  - 파일 관련 오류

  - 코드 오류

○ 외부 호출로 인한 성능 저하

 

애플리케이션 성능 분석

○ 애플리케이션 성능 분석 지표

  - 처리량(Throughput)

  - 응답 시간(Response Time)

  - 경과 시간(Turn Around Time)

  - 자원 사용률(Resource Usage)

○ 성능 분석 도구

  - JMeter : 다양한 프로토콜(HTTP, FTP)을 지원하는 부하 테스트 도구

  - LoadUI : 웹 서비스의 로드 테스트에 사용

  - OpenSTA : HTTP, HTTPS 프로토콜에 대한 부하 테스트

○ 모니터링 도구

  - Scouter : 단일 뷰를 통한 통합 / 실시간 모니터링

  - NMon : 리눅스 서버 자원에 대한 모니터링

  - Zabbix : 웹 기반의 서버, 서비스, 애플리케이션 모니터링 도구

  - Jeniffer : 트랜잭션의 양, 처리 시간, 응답 시간, 자원 활용률 모니터링

 

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

○ 소프트웨어 품질 보증 활동, 소프트웨어 개발 산출물 / 오류 발견을 목적으로 함

○ 검토 지침

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

  - 문제 영역을 명확히 표현

  - 제기된 모든 문제를 바로 해결 X

  - 사전에 작성한 메모를 공유

  - 논쟁, 반박을 제한

  - 의제 정하고, 그 범위를 유지

  - 참가자 수를 제한, 사전 준비 강요

  - 자원과 시간 일정을 할당

  - 모든 검토자에게 의미 있는 교육 행함

  - 검토의 과정과 결과를 재검토

 

소스코드 품질 분석

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

○ 워크스루(Walkthrough) : 계획된 개발자 검토 회의

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

=> 한 후에, 리팩토링 수행

○ 검증 체크리스트

  - 기능성(Functional)

  - 완전성(Completencess)

  - 일관성(Consistency)

  - 명확성(Unambiguity)

  - 검증 가능성(Verifiability)

  - 추적 가능성(Traceability)

  - 변경 용이성(Easily Changeable)

 

소스코드 품질 분석 도구

○ 코딩 중 발생할 수 있는 다양한 문제를 해결하기 위해 사용하는 도구

○ 소스코드 품질 분석 도구 분류

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

    : PMD, checkstyle, SonarQube, cppcheck, ccm, cobertura

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

    : Avalanche, Valgrind

 

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

○ 코드 최적화 : 알고리즘 개선, 병목 현상 제거, 실행 시간 단축, 메모리 사용 최소화

○ 코드 스멜(Code Smell) : 소스 코드에서 발견할 수 있는 잠재적인 문제점

  - 스파게트 코드(Spaghetti Code) : 난잡한 코드

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

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

○ 클린코드

  - 의존성 최소화, 명확한 가독성과 목적성을 가진 코드

  - 클린코드 작성 원칙 : 가독성, 단순성, 의존성 배제, 중복성 최소화, 추상화

 

 

 

 

 

 

 

출처 | 흥달쌤