[정보처리기사 요약] 2과목 소프트웨어 개발 – 4장 애플리케이션 테스트 관리

2022 시나공 정보처리기사 필기 참고하여 요약한 내용입니다. 2과목 소프트웨어 개발의 4장 애플리케이션 테스트 관리에서 중요한 내용들을 중심으로 정리했습니다. 요약인 만큼 내용이 부족할 수 있을 수 있으니 참고해주세요.

4장 애플리케이션 테스트 관리

53. 애플리케이션 테스트 : 애플리케이션의 결함을 찾아내는 행위나 절차,

고객의 요구사항을 만족시키는지 확인, 기능을 정확히 수행하는지 검증

1) 필요성 : 실행 전에 오류를 발견하여 예, 신뢰도 향상, 최소한의 시간과 노력으로 많은 결함 찾을 수 있음

2) 기본 원리 : 완벽한 테스팅은 불가능, 파레토 법칙(20%의 코드에서 전체 80%의 오류가 발견됨)
살충제 패러독스
정황에 따라 다르게 테스트
오류-부재의 궤변(결함이 없어도 요구사항을 만족시키지 못하면 품질이 높다할 수 없음)
테스트와 위험은 반비례, 개발과 관계없는 별도의 팀에서 수행

54. 애플리케이션 테스트의 분류

1) 프로그램 실행 여부에 따른 테스트

– 정적 테스트 : 실행하지 않고 코드를 대상으로 분석 (ex. 워크스루, 인스펙션, 코드검사)

– 동적 테스트 : 실행하여 오류를 찾는 테스트 (ex. 블랙박스 테스트, 화이트박스 테스트)

2) 테스트 기반에 따른 테스트

– 명세 기반 : 요구사항에 빠짐없이 테스트 케이스로 만들어 구현

– 구조 기반 : 논리 흐름에 따라 테스트 케이스 작성

– 경험 기반 : 유사 소프트웨어에 대한 테스터 경험 기반으로 수행

3) 시각에 따른 테스트

– 검증(Verification) 테스트 : 개발자의 시각에서 생산 과정을 테스트, 명세서대로 완성됐는지

– 확인(Validation) 테스트 : 사용자의 시각에서 제품의 결과를 테스트, 요구한대로 완성됐는지, 정상적으로 동작하는지

4) 목적에 따른 테스트

– 회복 : 결함을 주어 실패하도록 한 후 복구되는지 확인

– 안전 : 불법적인 침입으로부터 보호할 수 있는지 확인

– 강도 : 과부하 시에 정상적으로 실행되는지 확인

– 성능 : 실시간 성능이나 효율성 진단, 응답시간, 처리량 테스트

– 구조 : 논리적 경로, 복잡도 평가

– 회귀 : 변경된 코드에서 결함이 없음을 확인

– 병행 : 변경된 소프트웨어가 기존 소프트웨어에서 같은 데이터를 입력한 후 결과를 비교

55. 테스트 기법에 따른 애플리케이션 테스트

1) 화이트박스 테스트 : 원시 코드를 오픈시킨 상태에서 논리적인 경로를 테스트, 절차에 초점을 둔 구조적 테스트, 초기에 진행,

모든 문장을 한 번 이상 실행

– 종류

* 기초 경로 검사(Base Path) : 대표적인 화이트박스 테스트 기법, 절차적 설계의 논리적 복잡성 측정,

결과는 실행 경로의 기초를 정의

* 제어 구조 검사(Control Structure) : 논리적 조건을 테스트(조건 검사), 반복 구조에 초점(루프 검사),

변수 정의와 사용의 위치에 초점(데이터 흐름 검사)

– 검증 기준 : 테스트 케이스가 얼마나 적정한지 판단하는 기준

* 문장 검증 : 모든 구문이 한 번 이상 수행 되도록

* 분기 검증 : 결정 검증 기준, 모든 조건문에 조건이 True일 때와 False일 때가 한 번 이상 수행되도록

* 조건 검증 : 조건문에 포함된 개별 조건식의 결과가 True일 때와 False일 때가 한 번 이상 수행되도록

* 분기/조건 기준 : 분기 검증과 조건 검증을 모두 만족하는 설계

2) 블랙박스 테스트 : 모든 기능이 완전히 작동되는 것을 입증, 기능 테스트, 명세서를 보면서 테스트, 구현된 기능 테스트, 후반부

– 종류

* 동치 분할 검사(Equivalence Partitioning) : 입력 자료에 초점, 타당한 입력 자료와 타당하지 않은 입력 자료

* 경계값 분석(Boundary Value Analysis) : 동치 분할 검사 보완, 입력 조건의 경계값을 테스트 케이스로 선정

* 원인 – 효과 그래프 검사 : 입력과 출력에 영향을 미치는 상황을 분석

* 오류 예측 검사(Error Guessing) : 보충적 검사 기법, 데이터 확인 검사

* 비교 검사: 여러 버전의 프로그램과 같은 테스트 케이스를 적용하여 동일한 결과가 출력되는지

56. 개발 단계에 따른 애플리케이션 테스트 : V-모델(애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현한 것)

1) 단위 테스트(Unit Test) : 모듈이나 컴포넌트에 초점을 맞춰 테스트, 기능성 테스트, 주로 구조 기반 테스트

– 발견 가능한 오류 : 알고리즘 오류, 무한 루프, 틀린 계산 수식

– 테스트 방법 : 구조 기반 테스트(화이트박스), 명세 기반 테스트(블랙박스)

2) 통합 테스트(Integration Test) : 모듈을 결합하는 과정에서의 테스트, 상호 작용 오류 검사

3) 시스템 테스트(System Test) : 실제 사용 환경과 유사한 환경에서 테스트

– 테스트 방법 : 기능적 요구사항(블랙박스), 비기능적 요구사항(화이트박스)

4) 인수 테스트(Acceptance Test) : 요구사항을 충족하는지에 초점, 사용자가 직접 테스트

– 테스트 방법

* 사용자 인수 : 사용자가 시스템 사용의 적절성 여부 확인

* 운영상의 인수 : 시스템 관리자가 인수 시 수행

* 계약 인수 : 계약상의 인수 조건 준수 여부

* 규정 인수 : 정부 지침, 법규 등 규정에 맞게 개발되었는지

* 알파 테스트 : 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트, 통제된 환경에서 테스트,

문제점을 개발자와 사용자가 함께 확인

* 베타 테스트 : 필드 테스팅, 개발자 없이 사용자가 행하는 테스트, 문제점은 주기적으로 보고

57. 통합 테스트 : 모듈을 통합하는 과정에서 발행하는 오류를 찾아내는 테스트 기법 (ex. 비점진적 통합 방식, 점진적 통합방식)

1) 하향식 통합 테스트 : 상위 모듈에서 하위 모듈로 통합하면서 테스트, 깊이 우선 통합법, 넓이 우선 통합법,

테스트 초기부터 사용자에게 시스템 구조를 보여줄 수 있음, 스텁 사용, 마지막에 회귀 테스트 실시

2) 상향식 통합 테스트 : 하위 모듈에서 상위 모듈로 통합하면서 테스트, 클러스터 필요, 드라이버 작성

** 테스트 드라이버와 테스트 스텁 차이

드라이버 : 상위 모듈이 없는 경우, 상향식 테스트, 인터페이스 역할

스텁 : 하위 모듈이 없는 경우, 하향식 테스트, 가짜 모듈 역할, 시험용 모듈, 드라이버보다 작성 쉬움

3) 혼합식 통합 테스트 : 샌드위치식 통합 테스트

4) 회귀 테스팅 : 이미 테스트된 프로그램의 테스팅을 반복하는 것

58. 애플리케이션 테스트 프로세스

59. 테스트 케이스/테스트 시나리오/테스트 오라클

1) 테스트 케이스 : 명세 기반 테스트의 설계 산출물, 테스트 오류 방지, 시스템 설계 시 작성

2) 테스트 시나리오 : 순서에 따라 여러 개의 테스트 케이스를 묶은 집합, 구체적인 절차를 명세,

여러 개의 시나리오로 분리하여 작성

3) 테스트 오라클 : 참 값을 대입하여 비교하는 기법, 예상 결과를 계산하거나 확인

– 특징 : 제한된 검증, 수학적 기법, 자동화 기능

– 종류 : 참 오라클, 샘플링 오라클, 추정 오라클, 일관성 검사 오라클

60. 테스트 자동화 도구

1) 테스트 자동화 : 휴먼 에러를 줄임, 테스트 정확성 유지, 테스트 품질 향상

2) 테스트 자동화 도구의 유형

– 정적 분석 도구 : 소스 코드로 분석

– 테스트 케이스 생성 도구 : 자료 흐름도, 기능 테스트, 입력 도메인 분석, 랜덤 테스트

– 테스트 실행 도구 : 데이터 주도 접근 방식, 키워드 주도 접근 방식

– 성능 테스트 도구 : 성능의 목표 달성 여부 확인

– 테스트 통제 도구 : 형상관리 도구, 결함 추적/관리 도구

– 테스트 하네스 도구 : 테스트 환경의 일부분

61. 결함 관리

1) 결함(Fault) : 소프트웨어가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것

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

1) 애플리케이션 성능 : 최소한의 자원으로 최대한 많은 기능을 신속하게 처리하는 정도

– 측정 지표 : 처리량(Throughput), 응답 시간(Response Time), 경과 시간( Turn Around Time),

자원 사용률(Resource Usage)

63. 복잡도 : 소프트웨어의 복잡한 정도, 높으면 장애 발생 가능

1) 시간 복잡도 : 프로세스 수행하는 연산 횟수를 수치화한 것, 낮을수록 실행 시간이 짧음,

명령어의 실행 횟수 표기(점근 표기법)

– 점근 표기법 종류 : 빅오 표기법, 세타 표기법, 오메가 표기법

* 빅오 표기법 : 알고리즘의 실행시간이 최악일 때를 표기, 성능 예측 용이

O(1) : 입력값에 관계 없이 한 개의 단계만

O(log2n) : 단계가 입력값 또는 조건에 의해 감소

O(n) : 단계가 입력값과 1:1의 관계 (for 문)

O(nlog2n) : 단계가 입력값의 n(log2n)번만큼 수행 (힙 정렬, 합병 정렬)

O(n^2) : 단계가 입력값의 제곱만큼 수행 (삽입 정렬, 쉘 정렬, 선택 정렬, 버블 정렬, 퀵 정렬)

O(2^n) : 단계가 2의 입력값 제곱만큼 수행 (피보나치 수열)

2) 순환 복잡도(Cyclomatic Complexity) : 논리적인 복잡도를 측정하기위한 소프트웨어의 척도,

순환 복잡도는 제어 흐름도의 영역 수와 일치

V(G) = E – N + 2 (E:화살표 수, N:노드 수)

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

1) 소스 코드 최적화 : 나쁜 코드는 배제, 클립코드로 작성

– 클린 코드 : 잘 작성된 코드, 가독성, 단순성, 의존성 배제, 중복성 최소화, 추상화

– 나쁜 코드 : 로직이 복잡하게 얽혀있는 코드(스파게티 코드), 개발자가 없어 유지보수 작업이 어려운 코드(외계인 코드)

2) 소스 코드 최적화 유형 : 클래스 분할 배치, 느슨한 결합, 코딩 형식 준수, 좋은 이름 사용, 적절한 주석문 사용

3) 소스 코드 품질 분석 도구

– 정적 분석 도구 : 소스 실행시키지 않고 분석, 비정삭정인 패턴을 찾을 수 있음, 개발 초기의 결함 발견에 사용

(ex: pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura 등)

– 동적 분석 도구 : 코드를 실행하여 메모리 누수, 스레드 결함 등 분석

(ex: Avalanche, Valgrind 등)