정보처리기사 오답 정리(15. 애플리케이션 테스트 관리)

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

소프트웨어 테스트는 오류 발견 관점, 오류 예방 관점, 품질 향상 관점에서 필요하다.

소프트웨어 테스트 원리

1. 살충제 패러독스

• 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못함
• 테스트 케이스의 정기적 리뷰와 개선 및 다른 시각에서의 접근 필요

2. 결함 집중(파레토 법칙)

• 적은 수의 모듈에서 대다수의 결함이 발견됨
• 소프트웨어 테스트에서의 오류의 80%는 전체 모듈의 20% 내에서 발견됨

3. 오류-부재의 궤변

• 요구 사항을 충족시켜주지 못한다면, 결함이 없다 해도 품질이 높다 할 수 없다.

프로그램 실행 여부에 따른 테스트 분류

1. 정적 테스트

• 테스트 대상을 실행하지 않고 구조를 분석하여 논리성을 검증하는 테스트
• 리뷰, 정적 분석이 해당
  • 리뷰의 유형에는 관리 리뷰, 기술 리뷰, 인스펙션, 워크스루, 감사 등이 있음

2. 동적 테스트

• 소프트웨어를 실행하는 방식으로 테스트를 수행하여 결함을 검출하는 테스트\
• 화이트박스 테스트, 블랙박스 테스트, 경험기반 테스트가 이에 해당

2. 테스트 기법에 따른 테스트 분류

1. 화이트박스 테스트

• 각 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트
• 코드 분석과 프로그램 구조에 대한 지식을 바탕으로 문제가 발생할 가능성이 있는 모듈 내부를 테스트
• 소스 코드의 모든 문장을 한 번 이상 수행함으로 진행됨
• 유형에는 구문 커버리지, 결정 커버리지, 조건 커버리지, 조건/결정 커버리지 등이 존재함

2. 블랙박스 테스트

• 프로그램 외부 사용자의 요구사항 명세를 보면서 수행하는 테스트이다.
• 소프트웨어의 특징, 요구사항, 설계 명세서 등에 초점을 맞춰 테스트가 이루어진다.
• 유형에는 동등분할 테스트, 경곗값 분석 테스트, 결정 테이블 테스트 등이 존재한다.
  • 동등분할 테스트 : 입력 데이터의 영역을 유사한 도메인별 유횻값/무효값을 그룹핑하여 대푯값 테스트 케이스로 테스트하는 방식
  • 경곗값 분석 테스트 : 경곗값 부분에서 오류 발생 확률이 높기에 이를 포함하여 테스트 케이스를 설계하는 방식
• 동작 위주의 테스트를 진행하기에 내부 구조나 작동 원리를 알지 못해도 가능함

테스트 오라클

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

1. 참(True) 오라클

• 모든 입력값에 대하여 기대하는 결과를 생성함으로 발생된 오류를 모두 검출할 수 있는 오라클

2. 샘플링(Sampling) 오라클

• 특정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공해주는 오라클

3. 휴리스틱(Heuristic) 오라클

• 샘플링 오라클을 개선한 형태. 특정 입력값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클

4. 일관성 검사(Consistent) 오라클

• 애플리케이션 변경이 있을 때, 수행 전과 후의 결괏값이 동일한지 확인하는 오라클

테스트 레벨

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

1. 단위 테스트

• 사용자 요구사항에 대한 단위 모듈, 서브루틴 등을 테스트하는 단계

2. 통합 테스트

• 단위 테스트를 통과한 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호작용을 검증하는 테스트 단계

3. 시스템 테스트

• 통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지를 검증하는 테스트단계

4. 인수 테스트

• 계약상의 요구사항이 만족되었는지 확인하기 위한 테스트 단계

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

단위 테스트

• 개별적인 모듈(또는 컴포넌트)을 테스트한다.
• 구현 단계에서 각 모듈을 구현 후 수행한다.
• 개별적인 모듈에 대해 컴포넌트 테스트를 수행하려면 모듈을 단독으로 실행할 수 있는 테스트 베드(Test Bed)라는 환경이 필요하다.

테스트 자동화 도구

• 테스트 도구를 활용하여 반복적인 테스트 작업을 스크립트 형태로 구현함으로 테스트 시간 단축과 인력 투입 비용을 최소화하는 한편, 쉽고 효율적인 테스트를 수행할 수 있는 방법
• 장점 : 테스트 데이터 재입력 작업의 자동화, 객관적 평가 기준 제공
• 단점 : 도구 사용 방법 학습 필요, 도구를 프로세스 단계별로 적용하기 위한 시간이 필요함, 추가 투가 비용 발생

테스트 자동화 도구 유형

1. 정적 분석 도구(Static Analysis Tools)

• 만들어진 애플리케이션을 실행하지 않고 분석하는 도구
• 대부분의 경우 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함을 발견하기 위하여 사용
• 테스트를 수행하는 사람이 작성된 소스 코드에 대한 이해를 바탕으로 도구를 이용해서 분석하는 것

2. 테스트 실행 도구(Test Execution Tools)

• 테스트를 위해 작성된 스크립트를 실행하고, 작성된 스크립트를 각 스크립트마다 특정 데이터와 테스트 수행 방법을 포함함
• 데이터 주도 접근 방식과 키워드 주도 접근 방식이 존재함

3. 성능 테스트 두구(Performance Test Tools)

• 애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률에 대해 가상의 사용자를 생성하고 테스트를 수행함으로 성능 목표를 달성하였는지를 확인하는 도구

4. 테스트 통제 도구(Test Control Tools)

• 테스트 계획 및 관리를 위한 테스트 관리 도구, 테스트 수행에 필요한 데이터와 도구를 관리하는 형상 관리 도구, 테스트에서 발생한 결함에 대해 관리하거나 협업을 지원하기 위한 결함 추적/관리 도구 등이 존재

테스트 하네스(Test Harness)

• 애플리케이션 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로, 테스트를 지원하기 위한 코드와 데이터를 말하여, 단위 또는 모듈 테스트에 사용하기 위해 코드 개발자가 작성한다.

테스트 하네스 구성요소

1. Test Driver(테스트 드라이버) : 테스트 대상 하위 모듈 호출, 파라미터 전달, 모듈 테스트 수행 후의 결과 도출 등 상향식 테스트에 필요
2. Test Stub(테스트 스텁) : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구. 하향식 테스트에 필요
3. Test Suites(테스트 슈트) : 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합
4. Test Case(테스트 케이스) : 입력값, 실행조건, 기대결과 등의 집합
5. Test Script(테스트 스크립트) : 자동화된 테스트 실행 절차에 대한 명세
6. Mock Object(목 오브젝트) : 사용자의 행위를 조건부로 사전에 입력하면, 상황에 예정된 행위를 수행하는 객체

테스트 커버리지

• 주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준

테스트 커버리지 유형

1. 기능 기반 커버리지 : 앱의 전체 기능을 모수로 설정, 실제 테스트가 수행된 기능의 수를 측정하는 방법
2. 라인 커버리지 : 전체 소스 코드 라인 수를 모수로 테스트 시나리오가 수행한 소스 코드의 라인 수 측정
3. 코드 커버리지 : 소프트웨어 테스트 충분성 지표 중 하나. 소스 코드 구문, 조건, 결정 등의 구조 코드가 얼마나 테스트되었는지를 측정하는 방법. 일반적으로 테스트 커버리지라 하면 코드 커버리지를 말함

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

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

1. Throughput(처리량)

• 애플리케이션이 주어진 시간에 처리할 수 있는 트랜잭션의 수
• 웹 애플리케이션의 경우 시간당 페이지 수로 표현

2. Response Time(응답 시간)

• 사용자 입력이 끝난 후, 애플리케이션의 응답 출력이 개시될 때까지의 시간
• 애플리케이션의 경우 메뉴 클릭 시 해당 메뉴가 나타나기까지 걸리는 시간

3. Turnaround Time(반환 시간)

• 애플리케이션에 사용자가 요구를 입력한 시점부터 트랜잭션 처리 후, 그 결과의 출력이 완료될 때까지 걸리는 시간

4. Resource Usage(자원 사용률)

• 애플리케이션이 트랜잭션을 처리하는 동안 사용하는 CPU 사용량, 메모리 사용량, 네트워크 사용량

Bad Code(베드 코드)의 사례

1. Alien Code(외계인 코드)

• 아주 오래되거나 참고문서/개발자가 없어 유지보수 작업이 아주 어려운 코드

2. Spaghetti Code(스파게티 코드)

• 컴퓨터 프로그램의 소스 코드가 복잡하게 얽힌 모습을 스파게티 변발에 비유한 표현
• 작동은 정상적으로 하지만, 사람이 코드를 읽으면서 그 코드의 작동을 파악하기는 어려운 코드임

클린 코드의 작성 원칙으로는 가독성, 단순성, 의존성 최소, 중복성 제거, 추상화가 있음

Refactoring(리팩토링)

• 유지보수 생산성 향상을 목적으로 기능을 변경하지 않고, 복잡한 소스 코드를 수정, 보완하여 가용성 및 가독성을 높이는 기법

리팩토링의 목적에는 유지보수성 향상, 유연한 시스템, 생산성 향상, 품질향상이 있다.