[정보처리기사] 7. 애플리케이션 테스트 관리

253. 애플리케이션 테스트

• 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차
• 고객의 요구사항을 만족시키는지 확인하는 절차, 기능을 정확히 수행하는 검증하는 절차가 있음

 

A - 254. 애플리케이션 테스트의 기본 원리

• 파레토 법칙 : 전체 코드의 20%의 해당하는 코드에서 전체 결함의 80%가 발견된다.
• 살충제 패러독스 : 동일한 테스트 케이스로 동일한 테스트 반복 시 더 이상 결함이 발견되지 않는다.
• 오류-부재의 궤변 : 결함이 없더라도 요구사항을 만족시키지 못하면 품질이 좋다고 볼 수 없다.

 

A - 255. 프로그램 실행 여부에 따른 테스트

• 정적 테스트
  • 프로그램을 실행하지 않고 명세서나 소스코드를 대상으로 분석하는 테스트
  • 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도, 남은 결함 등을 발견하기 위해 사용
  • 종류 : 워크스루, 인스펙션, 코드 검사 등
• 동적 테스트
  • 프로그램을 실행하여 오류를 찾는 테스트
  • 종류 : 블랙박스 테스트, 화이트 박스 테스트 

 

256. 테스트 기반에 따른 테스트 - 명세기반, 구조기반, 경험기반

• 명세 기반 테스트
  • 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트
  • 종류 : 동등 분할, 경계값 분석 등
• 구조 기반 테스트
  • 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트
  • 종류 : 구문 기반, 결정 기반, 조건 기반 등 
• 경험 기반 테스트
  • 테스터의 경험을 기반으로 수행하는 테스트로 시간이 없거나 명세가 불충분한 경우 경험 기반 테스트를 사용
  • 종류 : 에러 추정, 체크 리스트, 탐색적 테스팅 등

 

A - 257. 시각에 따른 테스트 - 검증 테스트, 확인 테스트

• 검증 테스트
  • 개발자의 시각에서 제품의 생산 과정을 테스트하는 것
• 확인 테스트
  • 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것

 

A - 258. 목적에 따른 테스트

• 회안강 성구회병
• 회복 테스트
  • 시스템에 결함을 주고, 올바르게 복구되는지 확인하는 테스트
• 안전 테스트
  • 불법적인 침입으로부터 시스템을 보호할 수 있는지 확인하는 테스트
• 강도 테스트
  • 과도한 정보량이나 빈도와 같은 트래픽을 부과하여 과부하 시에도 정상적으로 실행되는지 확인하는 테스트
• 성능 테스트
  • 전체적인 효율성(처리량, 응답시간, 경과시간, 자원 사용률 등)을 진단하는 테스트
• 구조 테스트
  • 논리적인 경로, 소스 코드의 복잡도 등을 평가하는 테스트
• 회귀 테스트
  • 변경/수정된 코드에 결함이 없는지 확인하는 테스트
• 병행 테스트
  • 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트

 

259. 화이트박스 테스트

• 모듈의 원시 코드를 오픈시킨 상태에서 원시코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법
• 모듈 안의 작동을 직접 관찰할 수 있다.

 

A - 260. 화이트박스 테스트의 종류 - 기초 경로 검사, 제어 구조 검사

• 기초 경로 검사 : 논리적 복잡성을 측정하게 해주는 테스트 기법으로 대표적인 화이트박스 테스트 기법
• 제어 구조 검사
  • 조건 검사 : 모듈 내의 논리적 조건을 검사하는 테스트
  • 루프 검사 : 반복 구조에 초점을 맞춰 실시하는 테스트
  • 데이터 흐름 검사 : 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트

 

A - 261. 화이트박스 테스트의 검증 기준 (중요)

• 문장 검증 기준
  • 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스를 설계
• 분기 검증 기준
  • 소스 코드의 모든 조건문에 대해 조건식의 결과가 True인 경우 / False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계
  • 결정 검증 기준이라고도 한다.
• 조건 검증 기준
  • 소스 코드의 조건문에 포함된 개별 조건식의 결과가 True인 경우/ False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계
• 분기/조건 기준
  • 분기 검증 기준과 조건 검증 기준을 모두 만족하는 설계로, 조건문이 True인 경우와 False인 경우에 따라 조건 검증 기준의 입력 데이터를 구분하는 테스트 케이스를 설계

 

A - 262. 블랙박스 테스트

• 소프트웨어가 수행한 특정 기능을 알기 위해 각 기능이 완전히 작동되는것을 입증하는 테스트
• 요구사항 명세를 보면서 테스트하며 구현된 기능을 테스트 한다.
• 소프트웨어 인터페이스를 통해 실시

 

A - 263. 블랙박스 테스트 종류 - 동경원오비

• 동치 분할 검사(Equivalence Partitioning Testing)
  • 타당한 자료와 타당하지 않은 자료를 균등하게 하여 테스트 케이스를 정하는 기법
  • 동등 분할 기법, 동치 클래스 분해라고도 함.
• 경계값 분석(Boundary Value Analysis)
  • 입력 조건의 중간값보다 경곗값에서 오류가 발생될 확률이 높다는 점을 기반하여 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법
• 원인-효과 그래프 검사(Cause-Effect Graphing Testing)
  • 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는기법
• 오류 예측 검사(Error Guessing)
  • 과거의 경험이나 확인자의 감각으로 테스트하는 기법
• 비교 검사(Comparison Testing)
  • 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법

 

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

• 개발 : 요구사항 -> 분석 -> 설계 -> 구현
• 테스트 : 단위 -> 통합 -> 시스템 -> 인수 테스트
• V 모델

 

A - 265. 단위 테스트

• 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트하는 것
• 인터페이스, 외부적I/O, 자료구조, 독립적 기초경로, 오류 처리경로, 경계 조건 등을 검사
• 사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선으로 한다
• 구조기반 테스트와 명세 기반 테스트로 나뉘지만 주로 구조기반 테스트를 시행

 

A - 266. 통합 테스트

• 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트
• 비점진적 통합 방식 : 통합 절차 없이 프로그램 전체를 테스트하는 방법
  • 종류 : 빅뱅 통합 테스트 방식
• 점진적 통합 방식 : 모듈 단위로 단계적으로 통합하면서 시행하는 테스트방법
  • 종류 : 하향식 통합 테스트, 상향식 통합 테스트, 혼합식 통합 테스트

 

267. 시스템 테스트

• 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는지 점검하는 테스트
• 기능적 요구사항과 비기능적 요구사항을 구분하여 각각을 만족하는지 테스트

 

B - 268. 인수 테스트

• 사용자의 요구사항을 충족하는지에 중점을 두고 테스틀하는 것
• 알파 테스트 : 개발자의 장소에서 사용자가 행하는 테스트, 통제된 환경에서 행해짐.
• 베타 테스트 : 실업무를 가지고 사용자가 직접 테스트

 

A - 269. 하향식 통합 테스트

• 상위 모듈 -> 하위 모듈 방향으로 통합하면서 테스트 하는 기법
• 1) 주요 제어 모듈의 종속 모듈들은 스텁으로 대체
• 2) BFS, DFS 등의 통합 방식에 따라 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈로 교체
• 3) 모듈이 통합될 때마다 테스트를 실시
• 4) 새로운 오류가 발생하지 않음을 보증하기 위해 회귀 테스트를 실시

스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구. 일시적으로 필요한 조건만을 가지고 있는 시험용 모듈

 

 

270. 상향식 통합 테스트

• 하위 모듈 -> 상위 모듈 방향으로 통합하면서 테스트하는 기법
• 1) 하위 모듈들을 클러스터로 결합
• 2) 상위 모듈에서 데이터의 입출력을 확인하기 위해 더미 모듈인 드라이버를 작성

테스트 드라이버 : 테스트 대상의 하위모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구

 

 

271. 혼합식 통합 테스트

• 하위 수준에서는 상향식, 상위 수준에서는 하향식 통합을 사용하여 최적의 테스트를 지원하는 방식
• 샌드위치식 통합 테스트 방법이라고도 함.

 

272. 회귀 테스트

• 통합 테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인하는 테스트

 

273. 테스트 케이스

• 사용자의 요구사항을 정확히 준수했는지 확인하기 위해 설계된 입력값, 실행조건, 기대결과 등으로 구성된 명세서
• 미리 설계하면 테스트 오류 방지, 테스트 수행에 필요한 인력, 시간 등의 자원낭비를 줄일 수 있음.

 

274. 테스트 시나리오

• 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스를 묶은 집합
• 구체적인 절차를 명세
• 절차, 사전 조건, 입력데이터 등이 설정되어 있음.

 

B - 275. 테스트 오라클

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

 

A - 276. 테스트 오라클의 종류

• 참 오라클 : 모든 테스트 케이스의 입력값에 대해 기대하는 결과를 제공하는 오라클
• 샘플링 오라클 : 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공하는 오라클
• 추정 오라클 : 특정한 몇몇 테스트 케이스의 입력 값들에 대해서 기대하는 결과를 제공하고, 나머지 입력 값들에 대해서는 추정으로 처리하는 오라클
• 일관성 검사 오라클 : 애플리케이션에 변경이 있을때, 테스트 케이스의 수행 전과 후의 결과값이 동일한지 확인하는 오라클

 

B - 277. 테스트 자동화 도구

• 정적 분석 도구
  • 프로그램을 실행하지 않고 분석하는 도구
  • 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도를 발견하기 위해 사용
• 테스트 실행 도구
  • 스크립트 언어를 사용하여 자동으로 테스트를 실행하는 도구
• 성능 테스트 도구
  • 애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률 등에 대한 성능 목표 달성 여부를 확인하는 도구

• 테스트 통제 도구
  • 테스트를 계획하고 관리하고, 결함 관리하는 도구
• 테스트 하네스 도구
  • 실행 환경을 시뮬레이션하여 테스트 되도록 도와주는 도구
  • 테스트 하네스 : 컴포넌트 / 모듈을 테스트하는 환경의 일부분으로, 테스트를 지원하기 위해 생성된 코드와 데이터를 의미

 

278. 테스트 하네스의 구성 요소

• 테스트 드라이버 : 하위 모듈을 호출하고, 파라미터를 전달하고, 수행 후의 결과를 도출하는 도구
• 테스트 스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구, 일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈
• 테스트 슈트 : 시스템에 사용되는 테스트 케이스의 집합
• 테스트 케이스 : 사용자의 요구사항을 정확히 준수했는지 확인하기 위한 입력 값, 실행 조건, 기대 결과 등으로 만들어진 명세
• 테스트 스크립트 : 자동화된 테스트 실행절차에 대한 명세
• 목 오브젝트 : 사용자의 행위를 조건부로 설정해두면, 그 상황에 맞는 예정된 행위를 수행하는 객체

 

B - 279. 결함

• 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 것
• 사용자가 예상한 결과와 실행 결과 간의 차이나 업무 내용과의 불일치 또한 결함에 해당

 

280.결함 상태 추적

• 발견된 결함에 대해 지속적으로 상태변화를 추적하고 관리해야 하는데, 관리 측정 지표에는 3가지가 있다.
• 결함 분포 : "결함 수" 측정
• 결함 추세 : "시간에 따른 결함 수의 추이" 분석
• 결함 에이징 : 결함 "지속시간" 측정

 

281. 결함 분류

• 시스템 결함 : 애플리케이션 환경이나 데이터베이스 처리에서 발생된 결함
• 기능 결함 : 애플리케이션의 기획, 설계, 업무 시나리오등의 단계에서 유입된 결함
• GUI 결함 : 화면설계에서 발생된 결함
• 문서 결함 : 의사소통이 원활하지 않아 발생한 결함

 

282. 결함 심각도/우선순위

• 결함 심각도: 심각한 정도
  • High, Medium, Low, Critical, Major, Minor, Simple로 구분
• 결함 우선순위 : 처리의 우선순위
  • High, Medium, Low, Ciritical, 즉시해결, 주의요망, 대기, 개선 권고 등으로 구분

 

A - 283. 애플리케이션 성능 측정 지표

• 처리량, 응답 시간, 경과 시간, 자원 사용률
  • 처리량 : 일정 시간내에 처리하는 일의 양
  • 응답 시간 : 요청을 전달한 시간으로부터 응답이 도착하는데 걸리는 시간
  • 경과 시간 : 작업을 의뢰한 시간으로부터 처리가 완료될때까지 걸리는 시간
  • 자원 사용률 : CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률

 

284. 성능 테스트 도구

• JMeter : HTTP, FTP 지원
• LoadUI : HTTP, JDBC 지원
• OpenSTA : HTTP, HTTPS 지원

 

285. 시스템 모니터링 도구

• 시스테 자원의 사용량을 확인하고 분석하는 도구
• Scouter : 인프라 통합 모니터링 도구, 애플리케이션의 성능을 모니터링/통제
• Zabbix : 웹기반 서버, 서비스, 애플리케이션 등의 모니터링 도구

 

286. 복잡도 / 시간복잡도

• 복잡도
  • 시스템, 시스템 구성요소, 소프트웨어의 복잡한 정도
• 시간 복잡도
  • 알고리즘  수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화 한 것
  • 빅 오 표기법 : 실행시간이 최악일 때 표기하는 방법

 

B - 287. 빅오표기법

• O(1) : 입력값에 관계없이 한 단계만 거침
• O(log2^n) : 이진트리, 이진 검색
• O(n) : 입력값(n)과 1:1의 관계를 가짐 / for문
• O(nlog2^n) : 힙정렬, 2-way 병합정렬
• O(n^2) : 삽입정렬, 퀵정렬, 버블정렬, 선택정렬, 쉘 정렬 등
• O(2^n) : 피보나치 수열

 

B - 288. 순환 복잡도

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

 

B - 289. 소스 코드 최적화

• 클린 코드 : 누구나 쉽게 이해하고 수정 추가할 수 있는 단순,명료한 코드
• 나쁜 코드 : 로직이 복잡하고 이해하기 어려운 코드
  • 스파게티 코드 : 로직이 서로 복잡하게 얽혀있는 코드
  • 외계인 코드 : 오래되어 개발자가 없어 유지보수 작업이 어려운 코드

 

B - 290. 클린코드 작성원칙

• 단순성 : 코드를 간단하게 작성. 한번에 한가지 일을 처리하도록.
• 가독성 : 읽기 쉽게 작성. 들여쓰기나 네이밍
• 의존성 : 다른 모듈에 미치는 영향을 최소화
• 중복성 최소화 : 코드의 중복을 최소화
• 추상화 : 상위 클래스에서는 간략하게 특성을. 하위 클래스에서 구현을.

 

A - 291. 소스코드 품질 분석 도구

• 정적 분석 도구 : 작성한 코드를 실행하지 않고 코딩 표준이나, 코딩 스타일 , 결함을 확인하는 코드 분석도구
  • ex) pmd, cppCheck, checkstyle, sonarQube, cobertura 등 ( 펨책책소코 )
• 동적 분석 도구 : 작성한 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구
  • ex) Avalanche, Valgrind 등