[테스트] 애플리케이션 테스트

 

 

개발된 응용 애플리케이션이나 시스템이 사용자가 요구하는 기능과 성능, 사용성, 안정성 등을 만족하는지 확인하고, 노출되지 않은 숨어있는 결함을 찾아내는 활동입니다.

 

오류 발견, 오류 예방, 품질 향상 관점에서 필요합니다.

관점	설명
오류 발견	잠재된 오류를 발견하고 수정하여 올바른 프로그램을 개발하기 위해 필요
오류 예방	프로그램 실행 전 동료검토, 워크스루, 인스펙션을 통해 오류를 사전에 발견하는 예방 차원의 필요
품질 향상	사용자의 요구사항 및 기대 수준을 만족하도록 반복적 테스트를 거쳐 제품의 신뢰도를 향상하는 품질 보증을 위해 필요

 

테스트 원리는 7가지가 있습니다.

1. 테스팅은 결함이 존재함을 밝히는 것
2. 완벽한 테스팅은 불가능
3. 개발 초기에 테스팅 시작
4. 결함에 집중
5. 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못함(살충제 패러독스)
6. 테스팅은 정황에 의존적
7. 요구사항을 충족시켜주지 못한다면, 결함이 없다고 해도 품질이 높다고 볼 수 없음(오류-부재의 궤번)

 
소프트웨어 테스트 산출물은 테스트 계획서, 테스트 케이스, 테스트 시나리오, 테스트 결과서가 있습니다.
실제론 없거나 대충 작성하는 경우가 많습니다.
그 경우가 되지 않도록 노력해야겠습니다.

1. 테스트 유형

1. 프로그램 실행 여부에 따른 분류

분류	설명	유형
정적 테스트	프로그램의 실행 없이 구조를 분석하여 논리성을 검증하는 테스트	동료 검토, 워크스루, 인스펙션
동적 테스트	프로그램 실행을 요구하는 테스트	화이트박스 테스트, 블랙박스 테스트

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

1. 화이트박스 테스트

• 내부 구조를 기반으로 문장검증, 경로검증을 수행합니다.
• 구조테스트라고도 하고 구문 커버리지, 결정 커버리지, 조건 커버리지, 조건/결정 커버리지, 변경 조건/결정 커버리지, 다중 조건 커버리지 테스트를 포함합니다.

유형	설명
제어구조 테스트	논리적 복잡도 측정 후 수행 경로들의 집합을 정의하는 테스트
루프 테스트	루프 구조에 국한해서 실시하는 테스트

2. 블랙박스 테스트

• 외부 사용자의 요구사항 명세를 보면서 수행하는 테스트(기능 테스트) 입니다.

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

3. 테스트 시각에 따른 분류

분류	설명
검증	- 소프트웨어 과정을 테스트 - 개발 규격과 요구를 충족시키는지 판단 - 개발자 혹은 시험자의 시각으로 소프트웨어가 명세화된 기능을 올바로 수행하는지 알아보는 과정
확인	- 소프트웨어 결과를 테스트 - 제대로 동작하는지 확인 - 최종 사용자 요구 또는 소프트웨어 요구에 적합하는지 판단 - 사용자의 시각으로 올바른 소프트웨어가 개발되었는지 입증

4. 테스트 목적에 따른 분류

분류	설명
회복 테스트	시스템에 고의로 실패를 유도하고 시스템의 정상적 복귀 여부를 테스트하는 기법
안전 테스트	불법적인 소프트웨어가 접근하여 시스템을 파괴하지 못하도록 소스 코드 내의 보안적인 결함을 미리 점검하는 테스트 기법
강도 테스트	시스템에 과다 정보량을 부과하여 과부하 시에도 시스템이 정상적으로 작동되는지를 검증하는 테스트 기법
성능 테스트	사용자의 이벤트에 시스템이 응답하는 시간, 특정 시간 내에 처리하는 업무량, 사용자 요구에 시스템이 반응하는 속도 등을 측정하는 테스트 기법
구조 테스트	시스템의 내부 논리 경로, 소스 코드의 복잡도를 평가하는 테스트 기법
회귀 테스트	오류를 제거하거나 수정한 시스템에서 오류 제거와 수정에 의해 새로이 유입된 오류가 없는지 확인하는 일종의 반복 테스트 기법
병행 테스트	변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트 기법

5. 테스트 종류에 따른 분류

분류	설명	유형
명세 기반 테스트	프로그램의 요구사항 명세서를 기반으로 테스트 케이스를 선정하여 테스트 하는 기법	- 동등 분할 - 경계값 분석 - 결정 테이블 - 상태전이 - 유스케이스 - 분류트리 - 페어와이즈 - 직교분할 테스트 (블랙박스 테스트)
구조 기반 테스트	소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트 기법	- 제어구조 테스트 - 루프 테스트 - 구문 기반 커버리지 - 결정 기반 커버리지 - 조건 기반 커버리지 - 조건/결정 기반 커버리지 - 변경조건/결정 기반 커버리지 - 다중조건 기반 커버리지 (화이트박스 테스트)
경험 기반 테스트	유사 소프트웨어나 유사 기술 평가에서 테스터의 경험을 토대로 한 직관과 기술 능력을 기반으로 수행하는 테스트 기법	- 탐색적 오류 측정 - 체크리스트 - 특성 테스트

---

2. 테스트 오라클

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

유형	설명
참 오라클	모든 입력값에 대하여 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클
샘플링 오라클	특정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공해주는 오라클
휴리스틱 오라클	샘플링 오라클을 개선한 오라클로 특정 입력값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클
일관성 검사 오라클	애플리케이션 변경이 있을 때 수행 전과 후의 결괏값이 동일한지 확인하는 오라클

---

3. 테스트 레벨

종류	설명	기법
단위 테스트	사용자 요구사항에 대한 단위, 모듈, 서브루틴 등을 테스트하는 단계	- 인터페이스 테스트 - 자료구조 테슽 - 실행 경로 테스트 - 오류 처리 테스트
통합 테스트	단위 테스트를 통과한 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호작용을 검증하는 테스트 단계	- 빅뱅 테스트 - 상향식/하향식 테스트
시스템 테스트	통합된 단위 시스템 기능이 시스템에서 정상적으로 수행되는지를 검증하는 테스트 단계	- 기능/비기능 요구사항 테스트
인수 테스트	계약상의 요구사항이 만족되었는지 확인하기 위한 테스트 단계	- 알파/베타 테스트

---

4. 테스트 시나리오

테스트 수행을 위한 여러 테스트 케이스의 집합입니다.
테스트 케이스의 동작 순서를 작성한 문서이며 테스트를 위한 절차를 명세한 문서입니다.

테스트 수행 절차를 미리 정하였기 때문에 설계 단계에서 중요시되던 요구사항이나 대안 흐름과 같은 테스트 항목을 빠짐없이 테스트합니다.

---

5. 테스트 커버리지

소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준이며 테스트의 정확성과 신뢰성을 향상시키는 역할을 합니다.

1. 테스트 커버리지 유형

유형	설명
기능 기반 커버리지	테스트 대상 애플리케이션의 전체 기능을 모수로 설정하고 실제 테스트가 수행된 기능의 수를 측정하는 방법
라인 커버리지	애플리케이션 전체 소스 코드의 라인 수를 모수로 테스트 시나리오가 수행한 소스 코드의 라인 수를 측정하는 방법 (단위 테스트에서는 라인커버리지를 척도로 삼습니다.)
코드 커버리지	소프트웨어 테스트 충분성 지표 중 하나로 소스 코드의 구문, 조건, 결정 등의 구조 코드 자체가 얼마나 테스트되었는지를 측정하는 방법

2. 코드 커버리지 유형

※ 화이트박스 테스트에 적혀있는 "구문 커버리지, 결정 커버리지, 조건 커버리지, 조건/결정 커버리지, 변경 조건/결정 커버리지, 다중 조건 커버리지" 의 내용입니다.

유형	설명
구문 커버리지	- 프로그램 내의 모든 명령문을 적어도 한번은 수행하는 커버리지 - 조건문 결과와 관계 없이 구문 실행 개수로 계산
결정 커버리지	- 프로그램 내의 전체 결정문이 적어도 한번은 참과 거짓의 결과를 수행하는 커버리지
조건 커버리지	- 결정 명령문 내의 각 조건이 적어도 한번은 참과 거짓의 결과가 되도록 수행하는 커버리지
조건/결정 커버리지	- 전체 조건식뿐만 아니라 개별 조건식도 참 한번, 거짓 한번 결과가 되도록 수행하는 커버리지
변경 조건/결정 커버리지	- 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상시킨 커버리지
다중 조건 커버리지	- 결정 조건 내 모든 개발 조건식의 모든 가능한 조합을 100%보장하는 커버리지

---

6. 결함

애플리케이션에 발생한 결함이 어떤 영향을 끼치며 그 결함이 얼마나 치명적인지 나태내는 척도가 있습니다.

분류	설명	예시
치명적 결함	기능이나 제품의 테스트를 완전히 방해하거나 못하게 하는 결함	데이터 손실, 시스템 충돌
주요 결함	기능이 기대와 많이 다르게 동작하거나 그 기능이 해야하는 것을 못하는 결함	기능 장애
보통 결함	제품이나 프로그램이 특정 기준을 충족하지 못하거나 전체에 영향을 주지 않는 일부 기능이 부자연스러운 결함	사소한 기능 오작동
경미한 결함	사용상의 불편함을 유발하는 결함	표준 위반, UI 잘림
단순 결함	사소한 버그라고 하며, 기능에는 영향이 없지만 수정되어야 하는 결함	미관상 좋지 않음

발생한 결함이 얼마나 빠르게 처리되어야 하는지를 결정하는 척도인 결함 우선순위에 대한 내용입니다.

결함 심각도가 높아도 우선순위가 반드시 높은 것은 아니며, 애플리케이션이 특성에 따라 우선순위가 결정될 수 있습니다.

우선순위	설명
결정적	- 24시간 안에 즉시 수정 - 이슈가 발생하면 일반적으로 전체 기능이 동작하지 않고, 어떤 테스트도 더이상 진행할 수 없음
높음	- 중요한 결함이 수정되는 동안 이 우선순위의 결함은 종료 기준에 대한 테스트 활동을 하기 위해 수정되어야 하는 다음 후보가 됨 - 일반적으로 결함으로 인해 다른 기능을 사용할 수 없을 때 이 우선순위로 분류
보통	- 실패가 발생했을 때 올바른 에러 메시지가 출력되지 않는 것과 같은 에러가 이 우선순위로 분류될 수 있음
낮음	- 디자인에서 일부 강화하거나 사용자 경험을 향상시키기 위한 작은 기능 구현에 대한 요청이 이 우선순위로 분류

---

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

지표	설명
처리량	- 애플리케이션이 주어진 시간에 처리할 수 있는 트랜잭션의 수
응답시간	- 사용자의 입력이 끝난 후 애플리케이션의 응답 출력이 개시될 때까지의 시간
경과시간	- 애플리케이션에 사용자가 요구를 입력한 시점부터 트랜잭션을 처리 후 그 결괄의 출력이 완료될 때까지 걸리는 시간
자원사용률	- 애플리케이션이 트랜잭션을 처리하는 동안 사용하는 CPU, 메모리, 네트워크 사용량

---

8. 성능 분석 도구

1. 유형별 성능 분석 도구

성능 분석 도구는 애플리케이션의 성능을 점검하는 도구와 시스템 자원 사용량을 모니터링하는 도구로 분류할 수 있습니다.

구분	설명
성능/부하/스트레스 점검 도구	- 애플리케이션의 성능 점검을 위해 가상의 사용자를 점검 도구 상에서 인위적으로 생성한 뒤 시스템의 부하나 스트레스를 통해 성능 측정 지표인 처리량, 응답시간, 경과시간 등을 점검하기 위한 도구
모니터링 도구	- 애플리케이션 실행 시 자원 사용량을 확인하고 분석 가능한 도구 - 성능 모니터링, 성능 저하 원인 분석, 시스템 부하량 분석, 장애 진단, 사용자 분석, 용량 산정 등의 기능을 제공하며, 시스템의 안정적 운영을 지원하는 도구

2. 성능 분석 도구 유형

1. 성능 테스트 도구

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

2. 시스템 모니터링 도구

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

---

9. 소스 코드 최적화

1. 나쁜 코드(Bad Code)

• 다른 개발자가 로직을 이해하기 어렵게 작성된 코드
• 처리 로직의 제어가 정제되지 않고 서로 얽혀 있는 스파게티 코드
• 함수, 클래스, 컴포넌트의 이름들이 명확한 의미를 갖지 못하거나 실제 작동과 불일치(의미없는 이름)
• 클래스와 컴포넌트 간에 데이터와 컨트롤 흐름이 네트워크로 복잡하게 연결(높은 결합도)
• 아키텍처가 더 이상 구별되지 않고 여러 솔루션으로 이루어져 아키텍처상 변형들로 인해 시스템 풀질이 떨어짐(아키텍처 침식)
• 동일한 처리 로직이 중복되게 작성된 코드
• 비즈니스 기능을 수행하지 못하는 많은 컴포넌트들이 존재(오염)
• 현재 코드와 문서가 일치하지 않고 수정과 변경을 위한 도메인 지식은 크게 증가하지만 개발자의 지식부족 초래(문서부족)
• ... 등

2. 클린 코드(Clean Code)

• 잘 작성되 가독성이 높고, 단순하며, 의존성을 줄이고 중복을 최소화하여 깔끔하게 잘 정리된 코드
• 중복 코드 제거로 애플리케이션 설계가 개선될 수 있음
• 가독성이 높으므로 애플리케이션의 기능에 대해 쉽게 이해할 수 있음
• 버그를 찾기 쉬워지며 프로그래밍 속도가 빨라짐
• 의미 있는 이름
• 간결하고 명확한 주석
• 함수는 가급적으로 작게 만들고 if, while 문ㅇ 안의 내용은 한 줄로 처리되도록 작성(작은 함수)
• 조건, 루프, 흐름을 통제하는 선언문이 코드에 있으면 코드가 읽기 어려움(읽기 쉬운 제어 프름)
• 오류코드의 반환보다 예외처리를 활용(오류 처리)
• 등

3. 소스 코드 최적화 기법

• 애플리케이션 개발 프레임워크 코딩 표준을 설정하고 인터페이스 클래스를 이용하여 느슨한 결함 코드를 구현
• 인터페이스를 통해 추상화된 자료 구조를 구현하여 의존성을 최소화