[실기]Ⅶ.애플리케이션 테스트 관리★★

핵심개념정리

no	개념	설명
1	소프트웨어 테스트	개발된 응용 애플리케이션이나 시스템이 사용자가 요구하는 기능과 성능, 사용성, 안정성 등을 만족하는지 확인하고 노출되지 않은 SW결함을 찾아내는 활동
2	화이트박스 테스트	프로그램 내부로직을 기반으로 문장검증, 경로검증을 하는 테스트(구조 테스트)
3	블랙박스 테스트	외부 사용자의 요구사항 명세를 보며 수행하는 테스트(기능,명세 테스트)
4	테스트 케이스	특정 요구사항에 부합하는지 확인하기 위해 개발된 입력값, 수행조건, 예상된 결과의 집합
5	테스트 오라클	테스트 결과가 참/거짓인지 판단하기 위해 사전에 정의된 참 값을 입력하여 비교하는 기법
6	테스트 레벨	함께 편성되고 관리되는 테스트활동의 그룹, 책임과 연관, 서로 독립적
7	테스트 시나리오	테스트 수행을 위한 여러 테스트 케이스의 집합, 동작 순서 기술 문서, 절차 명세 문서
8	통합 테스트	sw 각 모듈 간 인터페이스 관련 오류, 결함을 찾기 위한 체계적인 테스트 기법
9	테스트 자동화 도구	테스트 도구를 활용하여 반복적인 테스트 작업을 스크립트 형태로 구현하여 시간과 인력 투입 감소
10	테스트 하네스	app 컴포넌트 및 모듈을 테스트하는 환경의 일부분, 테스트를 지원하기 위한 코드와 데이터
11	클린코드	가독성이 높고, 단순, 의존성이 낮고, 중복 최소화
12	배드코드	오염, 문서 부족, 의미 없는 이름, 높은 결합도, 아키텍처 침식
13	트랜잭션(Transaction)	데이터베이스에 변경이 발생할 때 실행되는 모든 작업의 최소단위로, 모든 과정이 올바르게 처리되지 않으면 Rollback해줌(데이터 무결성)

 

 

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

1. 소프트웨어 테스트
   1) 원리
       - 결함이 존재함 
       - 완벽한 테스팅은 불가능
       - 개발 초기에 테스팅 시작
       - 결함 집중 '파레토의 법칙': 적은 수의 모듈에서 대다수의결함, 20%에서 80%의 오류
       - 살충제 파라독스(20년 1회 기출) : 동일한 케이스에서 반복적인 테스트는 새로운 버그를 찾지 못함
       - 테스팅은 정황에 의존적 : 정황과 도메인에 맞게 테스트를 다르게 수행
       - 오류-부재의 궤변 : 요구사항을 충족하지 못하면 결함이 없더라도 품질이 높다고 볼 수 없음
       - Brooks법칙: 지연되는 프로젝트에 인력을 더 투입하면 오히려 더 늦어진다. 

   2) 기법

      ▶︎ 화이트박스 테스트(구조기반테스트)

             - 제어구조 테스트: SW의 논리적 복잡도 축정 후 수행경로들의 집합을 정의
             - 루프 테스트: 프로그램의 루프 구조에 국한해서 실시

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

동등 분할 테스트	유사한 도메인별로 유효값/무효값을 그룹핑하여 대표값 테스트 케이스를 도출하여 테스트하는 기법
경계값 분석 테스트	경계값에서 오류발생 확률이 높기 때문에 경계값을 포함하여 테스트 케이스를 설꼐하는 기법
결정 테이블 테스트	요구사항의 논리와 발생조건을 테이블 형태로 나열하여, 조건과 행위를 모두 조합하여 테스트
상태전이 테스트	테스트 대상/시스템이나 객체의 상태를 구분하고, 이벤트에 의해 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 수행하는 테스트 기법
유스케이스 테스트	시스템이 실제 사용되는 유스케이스로 모델링 되어 있을 때, 프로세스 흐름을 기반으로 테스트 케이스를 명세화하여 수행
분류트리 테스트	SW의 일부 또는 전체를 트리 구조로 분석/표현하여 설계
페어와이즈 테스트	Test data 값들 간에 최소한 한 번씩 조합하는 방식, 커버해야 할 기능적 범위를 모든 조합에 비해 상대적으로 적은 양의 테스트 세트를 구성하기 위한 기법

        ▶︎ 경험 기반 테스트
            : 이전 테스터가 다루었던 유사 APP, 기술에서의 경험, 직관, 테스터의 기술능력으로부터 테스트 케이트 추출
             (탐색적 테스팅, 오류 추정, 체크리스트 기반 테스팅)

▷ 검증검사기법
     - 동치분할검사: 입력자료에 초점을 맞춰 케이스를 만들고 검사
     - 알파테스트: 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트
     - 베타테스트: 선정된 최종 사용자가 여러명의 사용자 앞에서 행하는 테스트 기법
     - 형상검사: 구성요소, 목록, 유지보수를 위한 모든 사항이 표현되었는가를 검사

   3) 목적

회복 테스트	고의로 실패를 유도하고 시스템의 정상적 복귀여부를 테스트
안전 테스트	소스 코드 내에 보안적 결함을 미리 만들어서 테스트
강도 테스트	과다 정보량을 부과하여 과부하 시에도 정상적으로 작동되는지 검증
성능 테스트	응답 시간, 특정 시간 내 처리 업무량, 반응 속도 등 측정
구조 테스트	시스템의 내부 논리 경로, 소스 코드의 복잡도 평가
회귀 테스트	오류제거, 수정에 의해 새로 유입된 오류가 없는지 반복 테스트
병행 테스트	변경된 시스템과 기존 시스템에 동일한 데이터를 입력하여 결과를 비교

   4) 테스트 오라클 종류
       - 참 오라클: 발생된 오류 모두 검출
       - 샘플링 오라클: 특정한 몇 개의 입력 값에 대해서만 기대 결과 제공
       - 휴리스틱(Heuristic) 오라클: 샘플링 개선 형태, 나머지 값들에 대해서는 추정으로 처리
       - 일관성 검사 오라클: APP 변경이 있을 때 수행 전-후의 결과 값이 동일한지 확인

 

2. 테스트 시나리오 작성
   1) 테스트 레벨 종류

 

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

1. 통합 테스트
   ▶︎ 분류

점증적인 방법	상향식	하위 모듈 기능을 수행하는 클러스터로 결합, 드라이버 작성(더미모듈)
	하향식	‘깊이-우선’, ‘너비-우선’방식으로 통합, 스텁 개발(더미모듈)
비점증적인 방법	빅뱅 방식	모든 모듈을 동시에 통합한 후 수행 드라이버/스텁 X, 단시간 테스트 가능/ 작은 시스템에 유리

2. 테스트 자동화 도구 유형: 정적분석도구/ 테스트 실행도구/ 성능 테스트 도구/ 테스트 통제 도구
3. 테스트 하네스
: 테스트 드라이버(상향식), 테스트 스텁(하향식), 슈트(케이스 집합), 케이스, 스크립트(실행 절차 명세), 목 오브젝트(조건부 행위 실행) 

 

 

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

▶︎ 어플리케이션 성능 측정 지표(20년 1회 기출): 처리량/ 응답시간/ 경과시간/ 자원사용률
▶︎ 유형별 성능 분석 도구: 성능/부하/스트레스 점검도구 - 모니터링 도구
▶︎ 성능 분석 도구 유형
   - 성능 테스트 도구

도구	설명	지원환경
JMeter	HTTP, FTP, LDAP 등 다양한 프로토콜을 지원하는 안전성, 확장성, 부하, 기능 테스트 도구	크로스 플랫폼
LoadUI	UI를 통해 HTTP, JDBC 등 주로 웹 서비스를 대상으로 서버 모니터링을 지원하는 부하테스트	크로스 플랫폼
OpenSTA	HTTP, HTTPS 지원하는 부하 테스트 및 생산품 모니터링 도구	윈도우즈

   - 시스템 모니터링 도구

도구	설명	지원환경
Scouter	단일 뷰 통합/실시간 모니터링, 튜닝에 최적화된 인프라 통합 모니터링 도구	크로스 플랫폼
Zabbix	웹기반 서버, 서비스, 어플리케이션 모니터링 도구	크로스 플랫폼

▶︎ 데이터베이스 관련 성능 저하 원인

DB Lock	대량의 데이터 조회, 과도한 업데이트, 인덱스 생성 시 발생하는 현상
DB Fetch(불필요한 DB 패치)	실제 필요한 데이터보다 많은 대량의 데이터 요청이 들어올 경우 응답 시간 저하 현상 발생
Connection Leak(연결 누수)	DB연결과 관련한 JDBC객체를 사용 후 종료하지 않을 경우 발생
Connection Pool Size (부적절한 커넥션 풀 크기)	너무 작거나 크게 설정한 경우 성능 저하 발생 가능성 존재
확정(Commit) 관련	트랜잭션이 확정되지 않고 커넥션 풀에 반환될 때 성능 저하 가능성 존재

▶︎ 소스코드 품질분석 도구 유형  20년 2회 기출 

정적 분석 도구	작성된 소스 코드를 실행시키지 않고, 코드 자체만으로 코딩 표준 준수 여부, 코등 스타일 적정 여부, 잔존 결함 발견여부를 확인 하는 분석(도구)
동적 분석 도구	어플리케이션을 실행하여 코드에 존재하는 메모리 누수 현황을 발견하고, 발생한 스레드의 결함 등을 분석(도구)

▶︎ 트랜잭션 특성 4가지(ACID) 20년 1회 기출
    - Atomicity 원자성 : 트랜잭션 연산은 데이터베이스에 모두 반영되든지 아니면 전혀 반영되지 않아야 한다.
    - Consistency 일관성 : 트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 변환한다.
    - Isolation 격리성 : 트랜잭션 실행 중 생성하는 연산의 중간 결과를 다른 트랜잭션이 접근 불가하다.
    - Durability 영속성: 성공적으로 완료된 트랜잭션의 결과는시스템이 고장나더라도 영구적으로 반영되어야 한다.

 

 

 

▶︎ 빌드 자동화 도구
   : 제품 sw 실행파일 생성을 자동화하기 위해 저장소에  있는 소스를 자동으로 읽어서 빌드한 후 테스트-검사하여 실행파일을 만드는 도구
   ▷ 대표적 빌드 자동화 도구: Jenkins(젠킨스)
      - 자바 기반 오픈 소스로 가장 많이 활용, 지속적인 통합관리 가능
      - 서블릿 컨테이너 서버 기반으로 구동, CVS/SVN/Git 등 다양한 버전관리 도구 지원
   ▷ 안드로이드 공식 자동화 도구: Gradle(그래들)
      - Groovy를 이용한 빌드 자동화 시스템, 안드로이드 스튜디오의 공식 빌드 시스템
      - 자바, C++C, 파이썬 등 언어 지원