| 2020 정보처리기사 (필기) | 2. 소프트웨어 개발 - 애플리케이션 테스트 관리

49. 애플리케이션 테스트

 

애플리케이션 테스트

애플리케이션에 잠재되어 있는 결함을 찾아내는 행위, 절차이다.

고객의 요구사항을 만족시키는지 확인(사용자 입장)하고, 기능을 정확히 수행하는지 검증(개발자 입장)한다.

 

소프트웨어의 분류

상용 소프트웨어

보통의 사용자들이 공통적으로 필요로 하는 기능을 제공하는 소프트웨어

> 산업 범용 소프트웨어 : 시스템 소프트웨어, 미들웨어, 응용 소프트웨어

> 산업 특화 소프트웨어 : 특정 분야에서 요구하는 기능만을 구현한 소프트웨어

서비스 제공 소프트웨어

특정 사용자가 필요로 하는 기능만을 구현해 제공하는 소프트웨어

> 신규 개발 소프트웨어 : 새로운 서비스를 제공하기 위해 개발된 소프트웨어

> 기능 개선 소프트웨어 : 기능을 개선하기 위해

> 추가 개발 소프트웨어 : 새로운 기능을 추가하기 위해

> 시스템 통합 소프트웨어 : 업무기능이나 데이터 등을 통합하여 개발된 소프트웨어

 

 

• 애플리케이션 테스트의 필요성

- 프로그램 실행 전에 오류를 발견하여 예방

- 제품의 신뢰도 향상

- 단순한 오류 뿐만 아니라 새로운 오류의 유입도 예방

- 최소한의 시간과 노력으로 많은 결함 발견 가능

 

 

• 애플리케이션 테스트의 기본 원리 

- 완벽한 소프트웨어 테스팅은 불가, 결함은 줄일 수는 있지만 결함이 없다고 증명할 수는 없음 

- 결함은 대부분 특정 모듈에 집중되어 있음

- 테스트 케이스를 지속적으로 보완 및 개선

- 정황에 따라 테스트를 다르게 수행

- 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없음

- 테스트와 위험은 반비례

- 테스트는 작은 부분에서 시작해 점점 확대해 진행

- 개발자와 관계없는 별도의 팀에서 테스트 수행

 

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

 

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

정적 테스트	- 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트 - 소프트웨어 개발 초기에 결함 발견 가능, 개발 비용 낮음 - 워크스루, 인스펙션, 코드검사 등
동적 테스트	- 프로그램을 실행하여 오류를 찾는 테스트 - 소프트웨어 개발의 모든 단계에서 테스트를 수행할 수 있음 - 블랙박스 테스트, 화이트박스 테스트

 

테스트 기반(Test Bases)에 따른 테스트

명세 기반 테스트	- 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트 - 동등 분할, 경계 값 분석 등
구조 기반 테스트	- 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트 - 구문 기반, 결정 기반, 조건 기반 등
경험 기반 테스트	- 유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 수행하는 테스트 - 사용자 요구사항에 대한 명세게 부족하거나 테스트 시간에 제약이 있는 경우 수행하면 효과적 - 에러 추정, 체크 리스트, 탐색적 테스팅

 

시각에 따른 테스트

검증(Verification) 테스트	개발자의 시각에서 제품의 생산 과정을 테스트하는 것, 제품이 명세서대로 완성 되었는지
확인(Validation) 테스트	사용자의 시각에서 생산된 제품의 결과를 테스트하는 것. 사용자가 요구한대로 완성되었는지

 

목적에 따른 테스트

회복(Recovery) 테스트	시스템에 여러 결함을 주어 실패하도록 한 후 올바르게 복구되는지 확인
안전(Security) 테스트	시스템에 설치된 시스템 보호 도구가 불법적인 칩입으로부터 시스템을 보호할 수 있는지 확인
강도(Stress) 테스트	시스템에 과도한 정보량이나 빈도 등을 부과해 과부하 시 소프트웨어가 정상적으로 실행되는지 확인
성능(Performance) 테스트	소프트웨어의 실시간 성능이나 전체적인 효율성을 진단, 응답시간, 처리량 등 테스트
구조(Structured) 테스트	소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가
회귀(Regression) 테스트	소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인
병행(Parallel) 테스트	변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력해 결과를 비교

 

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

 

화이트박스 테스트 (White Box Test)

모듈안의 내용을 볼 수 있어 내부의 논리적인 경로를 테스트하는 방식 (모듈 내부가 투명(화이트))

모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방식

- 구조 기반 테스트

- 테스트 과정의 초기에 적용

- 모듈 안의 작동을 직접 관찰

- 분기점 부분들을 수행함으로써 논리적 경로 제어

 

• 화이트박스 테스트의 종류

기초 경로 검사	- 대표적인 화이트박스 테스트 기법 - 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법
제어 구조 검사	- 조건 검사 (Condition Testing) : 프로그램 모듈 내에 있는 논리적 조건을 테스트  - 루프 검사 (Loop Testing) : 프로그램의 반복구조에 초점을 맞춰 테스트 - 데이터 흐름 검사 (Data Flow Testing) : 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트

 

• 화이트박스 테스트의 검증 기준

- 문장 검증 기준 (State Coverage) : 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스 설계

- 분기 검증 기준 (Branch Coverage) : 소스 코드의 모든 조건문이 한 번 이상 수행되도록 테스트 케이스 설계

- 조건 검증 기준 (Condition Coverage) : 소스 코드의 모든 조건문에 대해 조건이 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계

- 분기/조건 기준 : 소스 코드의 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계

 

• 검증 기준 (Coverage)의 종류

- 문장 검증 기준, 분기 검증 기준 등은 모두 코드 커버리지에 해당

- 기능 기반 커버리지 : 실제 테스트가 수행된 기능의 수 / 전체 기능 수

- 라인 커버리지 : 테스트 시나리오가 수행한 소스 코드의 라인 수 / 전체 소스 코드의 라인수 

- 코드 커버리지 : 소스 코드의 구문, 분기, 조건 등의 구조 코드 자체가 얼마나 테스트 되었는지를 측정하는 방법 

 

 

블랙박스 테스트 (Black Box Test)

소프트웨어의 각 기능이 완전히 작동되는 것을 입증하는 테스트, 기능 테스트라고도 함

- 사용자의 요구사항 명세서를 보면서 테스트, 주로 구현된 기능을 테스트

- 명세 기반 테스트, 경험 기반 테스트

- 테스트 과정의 후반부에 적용

 

• 블랙박스 테스트의 종류

동치 분할 검사 (동등 분할 기법)	입력 자료에 초점을 맞춰 테스트 케이스를 만들고 검사하는 방법
경계값 분석	입력 자료에만 치중한 동치 분할 기법을 보완하기 위한 기법
원인-효과 그래프 검사	입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 분석한 다음 효용성이 높은 테스트 케이스를 선정해 검사하는 기법
오류 예측 검사	과거의 경험이나 확인자의 감각으로 테스트하는 기법
비교 검사	여러 버전의 프로그램에 동일한 테스트 자료를 제공해 동일한 결과가 출력되는지 테스트하는 기법

 

52. 개발 단계에 따른 애플리케이션 테스트

 

개발 단계에 따른 애플리케이션 테스트

V-모델 : 애플리케이션 테스트와 소프트웨어 개발 단계를 연결해 표현한 것

 

1. 단위 테스트 (Unit Test)

코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트

- 화이트박스 테스트, 블랙박스 테스트 사용

- 주로 구조 기반 테스트 사용

 

 

2. 통합 테스트 (Integration Test)

단위 테스트가 완료된 모듈들을 결합 해 하나의 시스템으로 완성시키는 과정에서의 테스트

 

 

3. 시스템 테스트 (System Test)

개발된 소프트웨어가 해당 시스템에서 완벽하게 수행되는가를 테스트

- 기능적/비기능적 요구사항 각각을 만족하는지 테스트

 

 

4. 인수 테스트 (Acceptance Test)

개발한 소프트웨어가 사용자의 요구사항을 충족하는가를 사용자가 직접 테스트

 

• 인수 테스트의 종류

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

- 운영상의 인수 테스트 : 시스템 관리자가 백업/복원 시스템, 재난 복구, 사용자 권리 등 테스트

- 계약 인수 테스트 : 계약상의 인수/검수 조건을 준수하는지 여부 확인

- 규정 인수 테스트 : 규정에 맞게 개발되었는지 확인

- 알파 테스트 : 개발자 앞에서 사용자가 행하는 테스트 기법, 통제된 환경에서 검사

- 베타 테스트 : 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트 기법, 개발자에 의해 제어되지 않은 환경에서 검사

 

53. 통합 테스트

 

통합 테스트 (Integration Test)

단위 테스트 후 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법

 

• 비점진적 통합 방식

모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법

- 소규모 프로그램에 유리, 단시간 내 테스트 가능

- 오류 발견 및 장애 위치 파악 및 수정 어려움

ex) 빅뱅 통합 테스트 방식 

 

• 점진적 통합 방식

모듈 단위로 단계적으로 통합하면서 테스트하는 방법

- 하향식, 상향식, 혼합식 통합 방식이 있음

- 오류 수정 용이

 

 

• 하향식 통합 테스트

프로그램의 상위에서 하위 모듈 방향으로 통합하면서 테스트하는 기법

- 깊이 우선 통합법, 넓이 우선 통합법 사용

- 테스트 초기부터 사용자에게 시스템 구조 보여줄 수 있음

- 상위 모듈에서는 테스트 케이스를 사용하기 어려움

- 스텁(Stub) 사용 

스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구, 시험용 모듈

 

 

• 상향식 통합 테스트

프로그램의 하위에서 상위 모듈 방향으로 통합하면서 테스트하는 기법

- 클러스터(Cluster)와 드라이버 사용, 스텁 사용 안함

 

 

• 혼합식 통합 테스트

상향식, 하향식을 혼합해 테스트, 샌드위치식 통합 테스트라고도 함

 

 

• 회귀 테스팅(Regression Testing)

이미 테스트된 프로그램의 테스팅을 반복하는 것

통합테스트로 인해 변경과 오류가 있는지 다시 한번 확인하는 테스트

 

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

 

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

1. 테스트 계획

테스트 목표 정의, 테스트 대상 및 범위 결정

- 테스트 대상 시스템의 구조 파악

- 테스트의 조직 및 비용 산정

- 테스트 시작 및 종료 조건 정의

테스트 계획서 : 테스트 목적, 범위 등 테스트 수행을 계획한 문서

 

2. 테스트 분석 및 디자인

테스트의 목적과 원칙 검토, 사용자 요구사항 분석

- 테스트에 대한 리스크 분석, 우선순위 결정

- 테스트 데이터, 테스트 환경, 테스트 도구 등 준비

 

3. 테스트 케이스 및 시나리오 작성

- 테스트 용 스크립트 작성

테스트 케이스 : 사용자의 요구사항을 얼마나 준수하는지 확인하기 위한 입력값, 실행 조건, 기대 결과 등으로 만들어진 테스트 항목의 명세서

테스트 시나리오 : 여러 테스트 케이스의 동작 순서를 기술한 문서

 

4. 테스트 수행

테스트 환경 구축 후 테스트 수행

- 테스트 실행 결과 측정 및 기록

 

5. 테스트 결과 평가 및 리포팅

- 테스트 결과서 작성

테스트 결과서 : 테스트 결과를 비교 분석한 내용을 정리한 문서

 

6. 결함 추적 및 관리

- 결함 관리 프로세스 : 에러 발견 → 에러 등록 → 에러 분석 → 결함 확정 → 결함 할당 → 결함 조치 → 결함 조치 검토 및 승인

 

 

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

 

테스트 케이스

구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서

 

• 테스트 케이스 작성 순서

① 테스트 계획 검토 및 자료 확보

② 위험 평가 및 우선순위 결정

③ 테스트 요구사항 정의

④ 테스트 구조 설계 및 테스트 방법 결정

⑤ 테스트 케이스 정의

⑥ 테스트 케이스 타당성 확인 및 유지 보수

 

 

테스트 시나리오

테스트 케이스들을 적용하는 구체적인 절차를 명세한 문서

 

• 테스트 시나리오 작성 시 유의 사항

- 시스템별, 모듈별, 항목별 등과 같이 여러 개의 시나리오로 분리해 작성

- 사용자의 요구사항, 설계 문서 등을 토대로 작성

- 유스케이스 간 업무 흐름이 정상적인지 테스트

- 모듈 또는 프로그램 간의 연계가 정상 동작 하는지 테스트

 

 

테스트 오라클

테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입해 비교하는 기법 및 활동

 

• 테스트 오라클의 특징

- 제한된 검증 : 테스트 오라클은 모든 테스트 케이스에 적용할 수 없음

- 수학적 기법 : 테스트 오라클의 값을 수학적 기법을 이용해 구함

- 자동화 가능 : 테스트 대상 프로그램의 실행, 결과, 비교 커버리지 측정 등을 자동화

 

• 테스트 오라클의 종류

- 참 오라클 : 발생된 모든 오류 검출

- 샘플링 오라클 : 몇몇 입력 값들에 대해서만 기대하는 결과 제공하는 오라클

- 추정 오라클 : 샘플링 오라클을 개선한 오라클, 나머지 입력 값들은 추정으로 처리하는 오라클

- 일관성 검사 오라클 : 애플리케이션 변경 시, 테스트 케이스의 수행 전과 후의 결과 값 비교

 

 

56. 테스트 자동화 도구

 

테스트 자동화

사람이 하던 반복적인 테스트 절차를 테스트 자동화 도구를 사용해 자동화 하여 휴먼 에러를 줄이고 테스트의 정확성 유지, 테스트 품질 향상

 

 

• 테스트 자동화 도구의 장단점

장점	- 인력 및 시간 감소 - 향상된 테스트 품질 보장 - 사용자 요구사항 등을 일관성 있게 검증 가능 - 테스트 결과에 대한 객관적인 평가 기준 제공 - 테스트 결과를 그래프 등 다양한 표시 형태로 제공 - UI가 없는 서비스도 정밀 테스트 가능
단점	- 비공개 상용 도구의 경우 고가의 추가 비용 필요 - 자동화 도구를 프로세스 단계별로 적용하기 위한 시간, 비용, 노력 필요 - 테스트 자동화 도구의 사용 방법에 대한 교육 및 학습 필요

• 테스트 자동화 수행 시 고려사항

- 재사용 및 측정이 불가능한 테스트 프로그램은 제외

- 용도에 맞는 적절한 도구를 선택 사용

- 자동화 도구의 환경설정, 습득 기간을 고려해 프로젝트 일정 계획

- 반드시 프로젝트 초기에 테스트 엔지니어의 투입 시기 계획

 

 

• 테스트 자동화 도구의 유형

1. 정적 분석 도구 : 프로그램을 실행하지 않고 분석하는 도구
2. 테스트 실행 도구 : 스크립트 언어를 사용해 테스트 실행하는 방법
   1. 데이터 주도 접근 방식 : 스프레드시트에 테스트 데이터를 저장하고, 이를 읽어 실행하는 방식
   2. 키워드 주도 접근 방식 : 스프레드시트에 테스트를 수행할 동작을 나타내는 키워드와 테스트 데이이터를 저장해 실행하는 방식
3. 성능 테스트 도구 : 처리량, 응답시간, 자원 사용률 등을 적용한 가상의 사용자를 만들어 테스트를 수행
4. 테스트 통제 도구 : 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구
5. 테스트 하네스 도구 : 테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈 테스트

 

테스트 하네스

애플리케이션의 컴포넌트 및 모듈을 테스트하는 환경의 일부분

테스트 드라이버	테스트 대상의 하위 모듈을 호출, 파라미터 전달, 모듈 테스트 수행 후의 결과를 도출하는 도구
테스트 스텁	일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈
테스트 슈트	테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합
테스트 스크립트	자동화된 테스트 실행 절차에 대한 명세서
목 오브젝트	사전에 사용자의 행위를 조건부로 입력해 두면, 그 상황에 맞는 예정된 행위 수행하는 객체

 

 

57. 결함 관리

 

결함 (Fault)

오류 발생, 작동 실패 등과 같이 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것을 의미

 

• 결함 관리 프로세스

① 결함 관리 계획

② 결함 기록

③ 결함 검토

④ 결함 수정

⑤ 결함 재확인

⑥ 결함 상태 추적 및 모니터링 활동

⑦ 최종 결함 분석 및 보고서 작성

 

• 결함 상태 추적

테스트에서 발견된 결함은 지속적으로 상태 변화 추적 및 관리

- 결함 관리 측정 지표 

> 결함 분포 : 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정

> 결함 추세 : 테스트 진행 시간에 따른 결함 수의 추이 분석

> 결함 에이징 : 특정 결함 상태로 지속되는 시간 측정

 

• 결함 추적 순서

① 결함 등록

② 결함 검토

③ 결함 할당

④ 결함 수정

⑤ 결함 조치 보류

⑥ 결함 종류

⑦ 결함 해제

 

• 결함 분류

- 시스템 결함, 기능 결함, GUI 결함, 문서 결함

 

• 결함 심각도

결함 심각도를 우선순위에 따라 분류 : Hight, Medium, Low

 

• 결함 우선순위

발견된 결함 처리에 대한 신속성을 나타내는 척도, 결함의 중요도와 심각도에 따라 설정

- 심각도가 높다고 반드시 우선순위가 높은 것은 아님

- 결함 우선순위 : 결정적, 높음, 보통, 낮음 또는 즉시 해결, 주의 요망, 대기, 개선권고 

 

• 결함 관리 도구

- Mantis, Trac, Redmine, Bugzilla 등