#실기 P2 애플리케이션 테스트 수행

Ch.1 애플리케이션 테스트 수행

01. 테스트

테스트

- 개발된 응용 어플리케이션 & 시스템의 사용자가 요구하는 기능과 성능, 사용성, 안전성 등을 확인하고 결함을 찾아내는 활동

- 소프트웨어 아키텍쳐 & 테스트 매니저 필요

 

소프트웨어 아키텍쳐

- 소프트웨어의 골격이 되는 기본구조

- 구성요소(Component)간의 관계를 표현하는 시스템 구조 또는 구조체

- 요구사항 → 분석 → 디자인 → 구현, 개발

 

테스트 매니저

- 단위테스트(Unit) → 통합테스트(Integration) → 시스템 테스트(System) → 인수 테스트(Acceptance)

 

테스트의 7가지 원칙

1. 테스트는 계획단계부터 실시  -(가능한 초기부터)

2. 테스트는 결함을 밝히는 활동  -(제거가 목적이 아님. 결함이 있음을 밝힐 수는 있지만 없다는 것을 밝힐 수는 없음.)

3. 완전한 테스트는 불가능

4. 테스트는 상황에 따라 다름  -(다양한 방법 필요)

5. 결함 집중을 고려해야 함  -(결함이 높은 곳에 자원이 집중되어 있다.(파레토 법칙))

6. 살충제 패러독스를 고려  -(동일한 테스트 반복으로 인한 내성현상)

7. 오류 부재의 궤변 고려  -(개발한 제품은 사용자의 요구사항과 일치하고 사용에 적합해야함)

 

 

02. 프로젝트 수행 단계에 따른 테스트의 분류

1. 단위 테스트 (Unit Testing)

- 컴포넌트component & 모듈module을 테스트

- 개발자에 의해 진행됨.

- 개발도구에서 지원하지 않아도 반드시 수행해야 함.

- 구조적 테스트, 기능성 테스트, 리소스 관련 테스트, 강건성 테스트 등 특정 비기능성 테스트 포함 수행됨.

- 컴포넌트 명세, 소프트웨어 상세 설계, 데이터 모델 명세 등을 이용해 테스트

- 방법

테스트 방법	설명	목적
구조 기반	화이트박스 테스트	제어흐름, 조건결정
명세 기반	사용자의 입력, 출력, 내부 이벤트 등을 확인 블랙박스 테스트	동등분할, 경계값 분석

 

화이트박스 테스트

- 개발자 관점 구조와 동작 기반의 테스트

- 종류 : 기초 경로 테스트/ 제어 흐름 테스트/ 조건 테스트/ 루프 테스트/ 데이터 흐름 테스트/ 분기 테스트

 

블랙박스 테스트

- 사용자 관점, 명세 기반의 테스트

- 종류 : 균등분할(동치분해)/ 한계값(경계값) 테스트/ 원인 효과 그래프 테스트/ 비교 테스트

 

명세 : 요구사항과 결과물의 일치

 

 

2. 통합 테스트 (Integration Testing)

- 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호작용 테스트

구분	빅뱅(Big Bang)	상향식(Bottom Up)	하향식(Top Down)
수행 방법	모든 모듈 동시 통합 후 수행	최하위 모듈부터 점진적으로 상위 모듈과 함께 수행	최상위 모듈부터  하위 모듈들을 통합하며 수행
더미 모듈	X	드라이버 필요	스텁 필요
장점	단시간 테스트 작은 시스템에 유리	장애위치 파악 쉬움 모듈 개발 시간 낭비가 없음	장애위치 파악 쉬움 이른 프로토타입 가능 중요 모듈의 선 테스트 가능 결함 조기 발견 가능
단점	장애위치 파악 어렵 모든 모듈 개발	이른 프로토타입 어려움 중요 모듈이 마지막으로 테스트 될 가능성 높음	많은 스텁 필요 하위 모듈들의 불충분한 테스트 수행 우려

드라이버 - 상향식 테스트 방식의 존재하지 않는 상위 모듈 간의 인터페이스 역할

스텁 - 하향식 테스트 방식의 작성이 쉬운 시험용 모듈

 

 

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

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

- 성능 및 장애 테스트

- 전체 시스템의 동작과 관련

- 최종 사용자 환경과 유사하게 시스템 성능, 관련된 고객의 기능/비기능적인 요구사항 등이 완벽하게 수행되는지를 테스트

기능적 요구사항	요구사항 명세서, 비즈니스 절차, 유스케이스 등 -> 명세서 기반의 블랙박스 테스트
비기능적 요구사항	성능 테스트. 회복 테스트. 보안 테스트, 내부 시스템의 메뉴 구조 웹 페이지의 네비게이션 등 -> 구조적 요소에 대한 화이트박스 테스트

- 요구사항 명세서, 비즈니스 절차, 유스케이스, 리스크 분석 결과 등을 이용

 

유스케이스 - 시스템의 동작을 사용자의 입장에서 표현한 시나리오, 시스템 관련한 요구사항을 알아내는 과정

 

 

4. 인수 테스트 (Acceptance Testing)

- 최종 사용자, 이해관계자가 테스트 수행.

- 개발 제품의 운영 여부를 결정

사용자 인수 테스트	비즈니스 사용자가 시스템 사용의 적절성 여부 확인
운영상의 인수 테스트	시스템 사용자가 시스템 인수 시 수행 백업/복원 시스템, 재난 복구, 사용자 관리, 정기 점검 등을 확인
계약 인수 테스트	계약 상의 인수/검수 조건 준수 확인
규정 인수 테스트	정부 지침, 법규, 규정 등 규정에 맞게 개발했는지 확인
알파 테스트	개발하는 조직 내 잠재 고객이 테스트
베타 테스트	실제 환경에서 고객이 테스트

 

 

03. 테스트 케이스와 테스트 오라클

테스트 케이스

- 명세 기반 테스트의 설계 산출물

- 특정한 프로그램의 일부분 또는 경로에 따라 수행하거나, 특정한 요구사항을 준수하는지 확인하기 위해 설계

- 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서

 

- 테스트 케이스 작성 절차

계획 검토 및 참조 문서 수집

내부 검토 및 우선순위 결정

요구사항 정의

테스트 설계와 방법 결정

테스트 케이스 정의

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

테스트 수행

 

테스트 오라클

- 테스트 결과의 참, 거짓을 판단하기 위해

- 사전에 정의된 참 값을 입력하여 비교

- 유형

참 오라클	모든 입력값의 기대 결과 생성
샘플링 오라클	특정한 입력값들만 기대 결과 제공
휴리스틱(추정) 오라클	샘플링 오라클 개선 특정 입력값에 대해 올바른 결과 제공, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리
일관성 검사 오라클	어플리케이션 변경 시, 수행 전과 후의 결과값이 동일한지 확인

 

 

04. 테스트 자동화

테스트 자동화

- 사람이 하던 반복적 테스트 절차를 자동화 도구를 활용하여 테스트 하는 것.

- 준비, 구현, 수행, 분석 등을 스크립트 형태로 구현 → 휴먼에러 줄이기 가능

- 운영중인 시스템의 모니터링, UI가 없는 서비스의 경우에도 정밀한 테스트 가능

 

휴면에러 : 인간의 실수로 발생하는 에러

 

장점

1. 인력과 시간 최소화

2. 요구사항 정의, 성능 및 스트레스 테스트. 품질 측정 최적화

3. 향상된 테스트 품질 보장

 

단점

1. 테스트 도구 전문가 양성, 비용 多

2. 초기에 시간, 비용, 노력 추가 투자 필요

3. 비공개 상용 소프트웨어는 고가이며 인력과 교육에 대한 유지관리 비용이 높다

 

고려사항

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

2. 반복적인 빌드에서 스크립트 재사용성이 가능해야

3. 모든 수동 테스트 과정을 자동화 할 수는 없다. 용도에 맞는 적절한 도구 사용 필요

4. 도구환경설정과 도구 습득 기간을 고려하여 프로젝트의 지연 방지

5. 프로젝트 초기에 테스트 엔지니어의 적절한 투입 시기와 계획 수립 필요

 

테스트 도구의 평가 방법 및 요소

테스트 활동	테스트 도구	내용
테스트 계획	요구사항 관리	고객 요구사항 정의 및 변경 사항 관리
테스트 분석/설계	테스트 케이스 생성	테스트 기법에 따른 테스트 데이터 및 케이스 작성
	커버리지 분석	테스트 완료 범위의 척도
테스트 수행	테스트 자동화	기능 테스트 등 테스트 도구를 활용하여 자동화를 통한 테스트 효율성 제고
	정적 분석	코딩표준, 런타임 오류 검증
	동적 분석	대상 시스템 시뮬레이션을 통한 오류검출
	성능 테스트	가상 사용자를 인위적으로 생성해 시스템 처리 능력 측정
	모니터링	시스템 자원(CPU, Memory)의 상태 확인 및 분석 지원 도구
테스트 통제	형상 관리	테스트 수행에 필요한 다양한 도구 및 데이터 관리
	테스트 관리	전반적인 테스트 계획 및 활동에 대한 관리
	결함 추적/관리	테스트에서 발생한 결함 관리 및 협업 지원

 

 

 

 

Ch.2 애플리케이션 결함 조치

01. 결함 관리

결함

- 프로그램과 명세서 간의 차이, 업무내용의 불일치

- 기대결과와 실제 관찰 결과 간의 차이

- 사용자가 기대하는 타당한 기대치를 시스템이 만족시키지 못할 때 변경이 필요한 모든 것

 

결함관리 프로세스

결함 관리 계획

결함 기록

결함 검토

결함 수정

결함 재확인

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

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

 

결함의 상태 및 추적

결함 등록 (Open)	결함 검토 (Reveiwed)	결함 할당 (Assigned)	결함 수정 (Resolved)	결함종료 (Closed)
		결함 조치 보류 (Deferred)	재오픈 준비해 결함등록
		결함 해제 (Clarified)	결함 종료 (Closed)

• 결함 등록 : 아직 분석되지 않은 상태
• 결함 검토 : 등록된 결함을 담당 모듈 개발자, 테스터, 프로그램 리더, 품질관리 담당자와 검토
• 결함 할당 : 결함의 영향 분석 및 수정을 위해 개발자와 문제 해결 담당자에게 할당된 상태
• 결함 수정 : 개발자에 의해 결함 수정 완료된 상태
• 결함 조치 보류 : 수정이 필요하지만 현재 수정이 불가능해서 연기된 상태. 우선순위, 일정 등을 고려해 재오픈 준비상태
• 결함 해제 : 다시 검토한 결과 결함이 아니라고 판명된 경우
• 결함 종료 : 발견된 결함이 해결되고 종료승인을 한 상태

 

결함 분류

1) 시스템 결함

- 애플리케이션 환경과 테이터베이스 처리에서 발생하는 결함

1. 비정상적인 종료/중단
2. 응답시간 지연
3. 데이터베이스 에러

2) 기능 결함

- 기획, 설계, 업무 시나리오 단계에서 발생된 결함

1. 요구사항 미반영/불일치
2. 부정확한 비즈니스 프로세스  -기능자체는 수행되나 내부 프로세스 로직의 문제로 부정확한 결과를 내는 경우
3. 스크립트 에러
4. 타 시스템 연동 시 오류

3) GUI 결함

- 사용자 화면 설계에서 발생된 결함

1. 응용 프로그램의 UI 비일관성
2. 부정확한 커서/메세지
3. 데이터 타입의 표시 오류

4) 문서 결함

- 기획자, 사용자, 개발자 간의 의사소통과 기록이 원활하지 않는 경우에 발생하는 결함

- 사용자의 온/오프라인 매뉴얼 불일치, 요구사항 분석서와 기능 요구사항의 불일치로 인한 불완전한 상태의 문서로 발생한 결함

 

결함 심각도

-전체 시스템에 결함이 미치는 영향을 레벨별로 나타냄

High  -시스템 중단/다운 → 진행X

Medium  -시스템 흐름에 영향

Low  -시스템 흐름에 영향X, 상황에 맞지 않는 용도와 화면구성

 

 

02. 결함 조치

1. 소프트웨어 테스트 기법

1) 단위 테스트 기법

- 컴포넌트나 모듈 내의 결함을 찾고 기능을 검증하기 위한 테스트

 

xunit

- 다양한 코드 중심의 테스트 프레임 워크.

- 소프트웨어의 함수, 클래스 등 서로 다른 구성 단위를 검사

- JAVA(Junit), C++(Cppunit), .NET(Nunit)

 

Mock 테스트

- 특정 기능 또는 모듈에 대한 응답 결과를 미리 정의해 높고 테스트

Dummy	객체의 전달에만 사용. 실제 사용X, 주로 매개 변수 목록을 채우는데 사용
Fake	실제로 동작하도록 구현. (바른 구현을 위해 실제환경과는 다르게 구현할 수 있음)
Stubs	미리 준비한 응답만 제공. 그 외의 상황에서는 정상적 작동X
Mocks	스펙을 통해 정의된 응답을 받고 다른 응답을 받을 경우에는 예외를 발생하도록 구현 응답에 대한 확인 수행

 

2) 통합 테스트 기법

- 전체 시스템이 통합 완료 될 때까지 단위 시스템 간의 연계성 및 기능 요구사항들을 확인

- 소프트웨어와 소프트웨어 구성요소 간의 상호작용 테스트

테스트 구현 : 테스트 상황과 방법을 구체화 시켜 테스트 케이스를 도출하고 작성하는 것

테스트 설계 방법 : 테스트 상황과 방법을 구체화 시키기 위한 수단 및 도구

 

설계 방법

보다 작은 케이스	동등 클래스
보다 많은 버그 찾기	경계 테스트 동등 클래스 중 대표 클래스를 뽑을 때 가장자리, 즉 경계값을 뽑는 경우

 

3) 시스템 테스트 기법

- 시스템 테스트 업무의 진행 전체를 총괄할 수 있도록 절차 및 각 프로세스 별 세부 업무를 알아야 하고 결과에 대한 분석 및 해결방안을 제시할 수 있어야 함

- 부하 및 성능 테스트, 장애 복구 테스트, 보안 테스트

 

4) 인수 테스트 기법

- 최종 사용자가 요구한 기능이 제대로 반영되었는지, 인수 조건에 만족하는지를 테스트하는 기법

- 실제 운영 환경에서 시행

- 고객이 주도

 

 

2. 결함 관리의 이해

에러(Error)

- 소프트웨어 개발, 유지보수 수행 중에 발생한 부정확한 결과

- 개발자의 오타, 개발 명세서의 잘못된 이해, 서브루틴 기능 오해

 

오류(Fault)

- 프로그램 코드 상에 존재하는 것. 코드 누락.

- 비정상적인 프로그램과 정상적인 프로그램의 버전 간의 차이로 발생

 

실패(Failure)

- 장애

- 비정상적인 프로그램과 정상적인 프로그램의 실행 결과 차이.

- 결함의 결과

 

결함(Defect)

- 버그, 에러, 오류, 실패, 프로그램 실행 문제점, 프로그램 개선 사항 등 전체 포괄

 

* 결함의 판단 기준 : 기능명세서

테스터의 시각에서 이해하기 어려운 기능, 사용이 까다로운 기능, 비정상적으로 느린 기능도 결함에 포함.

 

 

3. 테스트 격언

1. 소프트웨어를 완벽하게 테스트 하는 것은 불가능
2. 소프트웨어 테스트는 위험을 수반하는 훈련
3. 테스트 작업으로 결함이 존재하지 않는다는 사실을 입증할 수 없다.  -단지 결함이 있다는 사실만 보여줄 수 있음, 테스트 결과 결함이 발견되지 않았더라도 결함이 없음을 의미하는 것이 아님.
4. 발견한 모든 결함을 수정할 수는 없다.
5. 발견한 결함이 많을수록 남아있는 결함 수도 많다.

 

 

03. 결함 조치 관리

1. 프로그램 코드 검토 기법

코드 인스펙션(Code Inspection) = 코드 검사. 결함 파악 및 제거 목적

 

워크스루 : 코드의 품질 평가, 개선 목적으로 수행되는 검토 기법

 

소프트웨어 인스펙션(SW Inspection)

- 코드 인스펙션 + 설계 및 설계 산출물

- QA가 주관, 담당하여 실시.

- But, 아키텍트가 각 단계에서 원활한 업무 수행을 위해 지원해야 함.

- 아키텍트는 코드 인스펙션의 프로세스 전반과 각 단계별 수행 업무 등을 전체적으로 이해할 필요가 있다.

- 아키텍트는 Overview, Rework가 잘 수행될 수 있도록 지원하는 것이 중요

• 자동 코드 인스펙션을 위한 환경 지원, 계획 수립 지원 활동
• 체크리스트 정합성 검토 지원 활동
• 인스펙션 결과 리뷰 참석
• 발견된 결함을 수정하기 위한 개발자 리딩 지원 활동

자동 코드 인스펙션 : 전체 개발된 프로그램을 대상으로 수행

수동 코드 인스펙션 : 자동코드 인스펙션 코드 중 에러가 많은 경우, 업무 중 복잡한 처리 로직 有, 처음 투입되는 개발자의 산출물

 

인스펙션의 효과: 테스트 전 결함 발견에 따른 이익을 수행 팀원들이 인식하는 것이 가장 크다

 

코드 인스펙션 프로세스

구분	수행 단계	주요 내용
자동 수행	1. 범위 계획 (Caplacity Plan)	인스펙션의 범위와 범위 선정 기준 결정
	2. 시작 (Overview)	자동 인스펙션 수행
준비단계	3. 준비 (Preparation)	계획서 작성, 체크리스트 작성, 계획 공지, 대상 산출물 준비
이행 단계	4. 인스펙션 회의	사전 검토 실시, 미팅 실시
시정 조치	5. 재작업 (Rework)	개발 원작자가 직접 작업
	6. 후속 처리 (floow-up)	결과서 작성 및 보고

 

코드 인스펙션 테스크별 수행 내용

구분	작업	수행내용	산출물
자동 수행	1. 자동 인스펙션 수행	전수 검사, Quailty Metric, 결함 분석	코드 인스펙션 결과
준비 단계	2. 계획서 작성	일정 및 관련자, 대상 산출물 및 준비물 정의	인스펙션 계획서
	3. 체크리스트 작성	표준 체크리스트를 테일러링하여 인스펙션 체크리스트 작성	인스펙션 체크리스트
	4. 계획 공지	메일이나 공지를 통해 관련자에게 사전 공지
	5. 대상 산출물 준비	산출물 작성자가 인스펙션 시 필요한 자료를 준비
이행 단계	6. 착수 회의 실시	진행자는 참여자에게 검토 주안점, 방법, 역할 등을 교육 작업자는 대상 산출물 및 참조 자료에 대한 개요 소개
	7. 사전 검토 실시	산출물, 체크리스트, 사전 검토서 양식 배포 참여자별로 자료를 개별 검토하여 발견된 부적합 사항 기록	인스펙션 결과서
	8. 미팅 실시	사전 검토에서 발견된 부적합 사항 검증 미팅에서 발견된 부적합 사항 추가 기재 부적합 사항 목록 정리 또는 조치 계획 수립	인스펙션 결과서
	9. 결과 정리	진행자는 최종 확정된 결함 내용을 인스펙션 결과서에 정리한 후 작성자에게 배포
시정 조치	10. 보완 작업 실시	작성자는 각 결함에 대한 보완 작업 실시
	11. 시정 조치 결과 확인	진행자는 보완 완료 여부 확인(필요시 재검토)
	12. 결과 보고	진행자는 결과서를 작성하여 관련자에게 보고	인스펙션 결과서

 

인스펙션과 워크스루의 차이점

구분	인스펙션	워크스루
목적	결함 파악 및 제거	산출물 평가 및 개선
수행조건	완성도가 기준 이상 일 때	팀이나 관리자가 필요할 때
결함 수정 여부	모든 결함 제거	저자 결정
변경 사항 검증	진행자가 재작업 결과 확인	저자 결정
검토자 인원	3-6명	2-7명
참여자	동료	기술 전문가 및 동료
검토 인도자	교육받은 진행자	저자(직접 주도)
검토 준비 여부	체크리스트를 이용한 검토	일반적으로 준비하지 않음
검토 분량	상대적 적음	상대적 적음
검토 속도	상대적 느림	빠름
발표자	산출물에 의존도가 높은 사람(Reader)	저자
지표 수집 여부	모든 검토자들이 기록	X
보고서	결함 리스트 및 측정 지표	워크스루 보고서
데이터 측정 여부	필수	권장사항
체크리스트 사용 여부	O	X

 

2. 형상 관리 및 구성요소

소프트웨어 형상 관리

- 소프트웨어 엔지니어링 프로젝트 개시에서 소멸시점까지의 활동

- 소프트웨어 프로세스의 모든 출력물 정보, 컴퓨터 프로그램, 컴퓨터 프로그램 설명 문서, 데이터 등 소프트웨어 프로세스 전반에 걸쳐 소프트웨어 형상의 변경 요인에 대해 소프트웨어 형상을 보호하는 활동

 

소프트웨어 지원

- 소프트웨어가 고객에게 인도되고 운영하는 시점에 발생하는 소프트웨어 엔지니어링 활동

 

기준선(Baseline)

- 변경 통제 도와줌

- 정식의 변경 통제 절차를 통해서만 변경 가능

 

소프트웨어 형상 관리 항목 (SCI ; Software Configuration Item)

개발 단계	기준선(Baseline)	소프트웨어 형상 항목(SCI)
계획	사용자 요구사항	시스템 명세서, 개발 계획서, 구성 관리 계획서, 품질 평가 계획서, 개발 표준 및 절차 메뉴얼
요구분석	사용자 요구 기능이 하위 시스템 간에 어떻게 분배되는가 여부	자료 흐름도, 자료 사전, 자료 흐름도 명세서
설계	개발 전 설계 명세	입출력 명세서, 화면 설계서, 초기 사용자 매뉴얼, 초기 시스템 매뉴얼, 자료 구조도, 시스템 구조도
구현	시험 계획서	원시코드, 목적코드, 실행코드, 단위시험 보고서
시스템 통합 및 시험	제품	통합 시험 보고서, 기능/성능/과부하 시험 보고서, 인증 시험 보고서
설치 및 운영	운영	목적/실행코드, 운영자 매뉴얼, 사용자 매뉴얼

 

형상 관리의 주요 활동

형상 식별	형상 관리 대상 구분, 관리목록번호 부여
버전 관리	SCI의 버전 부여/갱신
변경 통제	SCI에 대한 접근 및 동기화 제어
형상 감사	SCI 무결성을 평가하여 공식적으로 승인
상태 보고	개발자와 유지 보수자에게 변경 사항을 공지

 

형상 관리 도구

- 소프트웨어 변경 과정 및 처리 상태를 기록/보고하고 소프트웨어의 안전성을 높이는 데에 지원하는 도구

CSV (Concurrent Verwion System)	가장 오래됨 단순 명령 구조. 텍스트 기반 코드만 지원
SVN (Subversion)	가장 대중화 다양한 GUI 존재. 압축을 통해 서버 공간 절약 가능
Git	리눅스 커널 개발을 위해 만든 형상 관리 시스템 분산형 방식(스스로 저장공간 필요)