[- Disclaimer -]
아래 내용은 정보보안 공부 목적으로 작성된 것이나, 이를 토대로 허가되지 않은 대상에 실습을 진행할 경우 해킹 시도로 간주하여 법적 처벌을 받을 수 있음을 알려 드립니다.
Verification
✦ 개발 과정 간 명세서 기준 검증
✧ 개발자 기준 Test: 단위 Test, 통합 Test, 시스템 Test
Validation
✦ 완재품을 가져다 검증
✧ 사용자 기준 Test: 인수 Test
Application Test 필요성
✦ 프로그램 실행 전 Error를 발견하여 예방
✦ 사용자 요구 사항, 기대 수준 등을 만족하는지 반복 Test하므로 제품 신뢰도 향상
✦ 개발 초기부터 Test하면 단순 Error 뿐 아니라 새 Error 유입도 예방 가능
✦ Test 효과적 수행 시 최소 시간 및 노력으로 많은 결함 발견 가능
Application Test 기본 원리
✦ 잠재적 결함을 줄이는거지 원천 봉쇄는 아니므로 완벽한 Test란 없다.
✦ Pareto Principle 법칙에 따라 Test로 발견된 80%의 Error는 20%의 Module에서 발견되므로 “특정 Module 집중”으로 효율적인 Error 찾기
✧ 개발자 특성이나 Application 기능적 특징에 의해 특정 Module에 결함 집중 됨
✧ Pareto Principle (=파레토 법칙): 상위 20% 사람들이 전체 부의 80% 소유
✧ 특정 Module 집중 (=결합 집중, Detect Clustering): 대부분의 결함이 소수의 특정 Module에 집중되어 발생
✦ 동일 Test Case를 반복하면 Pesticide Paradox 현상이 발생하므로 Test Case의 지속 보완 필요
✧ Pesticide Paradox (=살충제 패러독스): 벌레에게 살충제 계속 뿌리면 내성 생겨서 별 효과 못 보는 거
✧ Test 많이 할 수록 위험이 적어져 Test와 위험은 반비례 관계
✦ S/W 특징, Test 환경, Tester 역량 등 정황에 따라 Test 결과가 달라지므로 정황에 따라 Test를 상이하게 수행
✦ Absence of Errors Fallacy (=오류-부재의 궤변)
✧ 나오는 S/W 결함 다 제거해도 사용자 요구 사항 비만족 시 S/W 품질은 높다고 할 수 없음
✦ Test는 작은 부분에서부터 큰 부분으로 확대해가며 진행
✦ Test는 개발자와 관계없는 별도 팀에서 수행
Application Test 분류 - 프로그램 실행 여부
✦ 정적 Test
✧ 명세서, Source Code로 프로그램 비실행 Test
✧ Ex) Walk Through, Inspection, Code 검사 등
✦ 동적 Test
✧ 프로그램 실행 Test
✧ Ex) Blackbox Test, Whitebox Test
Application Test 분류 - Test 기반
✦ 명세 기반 Test
✧ 요구 사항 누락 없는 Test Case 구현 여부
✧ Ex) 동등 분할, 경계 값 분석 등
✦ 구조 기반 Test
✧ S/W Logic와 맞물리는 Test Case 구현 여부
✧ Ex) 구문 기반, 결정 기반, 조건 기반
✦ 경험 기반 Test
✧ 유사 S/W나 기술 등에 대한 Tester 경험
✧ 요구 사항 명세 불충분 및 Test 시간 제약 시 효과적
✧ Ex) Error 추정, Check List, 탐색적 Testing
Application Test 분류 - Tester 시각
✧ Validation, Verification
Application Test 분류 - 목적
✦ 회복, 안전, 강도, 성능, 구조, 회귀, 병행 Test
기능 기반 Coverage
✦ 실제 Test가 수행된 기능 수 /(나누기) 전체 기능 수
Line Coverage
✦ Test 시나리오가 수행한 Source Code의 Line 수 /(나누기) 전체 Source Code Line 수
Code Coverage
✦ Sorce Code 구문 분기, 조건 등 주고 Code 자체가 얼마나 Test되었는지 Module 내부의 논리적인 구조를 Cover하도록 측정하는 방법
Whitebox Test
✦ Code Coverage에 해당
✦ Base Path Testing (=기초 경로 검사)
✧ 대표적 Whitebox Testing 기법
✧ Test Case 설계자가 절차적 설계의 논리적 복잡성 측정 > 실행 경로 기초 정의 및 지침으로 사용
✦ Control Structure Testing (=제어 구조 검사)
✧ Condition Testing (=조건 검사), Loop Testing (=루프 검사), Data Flow Testing (=데이터 흐름 검사)
✦ 검증 기준
✧ Statement Coverage (=문장 검증 기준): Source Coe의 모든 구문이 1회 이상 수행되도록 설계
✦ Branch Coverage (=분기 검증 기준, Decision Coverage (=결정 검증 기준)): 개별식 미포함 모든 조건 대상 True와 False가 1회 이상 수행되도록 설계
✧ 조건은 언제나 T or F
✦ Condition Coverage (=조건 검증 기준)
✧ 개별식 포함 모든 조건 대상 True와 False가 1회 이상 수행되도록 설계
✦ Branch/Condition Coverage (=분기/조건 기준)
✧ 분기 검증 기준과 조건 검증 기준을 만족하는 설계
✧ True or False에 따라 조건 검증 기준의 입력 Data 구분
Blackbox Test
✦ 기능 작동 여부를 입증하는 기능 Test
✦ 요구 사항 명세를 보면서 Test
✦ 주로 구현된 기능을 Test
✦ S/W Interface에서 Test
✦ 누락 기능, Interface 오류, 자료 구조 및 외부 DB 접근에 따른 Error, 행위나 성능 Error, 초기화 및 종료 Error 등을 발견하기 위함
✦ Test 과정 후반부에 적용 됨
Blackbox Test 종류 - Equivalence Partitioning Testing (=동치 분할 검사, 동치 클래스 분해, 동등 분할 기법)
✦ 타당한 입력과 비타당한 입력 수를 균등하게 분배해 Test Case를 정하고 입력 자료에 맞는 결과 출력 여부 확인
✧ Ex) 성적 입력 프로그램에 성적들 입력하여 예상 결과 값과 실제 결과 값의 일치 여부 확인
Blackbox Test 종류 - Boundary Value Analysis (=경계 값 분석)
✦ 입력 자료에만 치중한 동치 분할 기법 보완
✧ 입력 자료보다 경계 값 Error 발생률이 더 높다는 점 이용하여 입력 조건의 경계 값을 Test Case로 선정 후 검사
✧ Ex) 성적에 -1도 넣어보고 101도 넣어보고, 0도 넣어보고 100도 넣어보고 해서 예상 오류와 실제 오류 간 일치 여부 확인
Blackbox Test 종류 - Cause-Effect Graphing Testing (=원인-효과 그래프 검사)
✦ 입력 Data 간 관계와 출력에 영향을 미치는 상황을 체계적으로 분석 후 효용성 높은 Test Case 선정하여 검사
Blackbox Test 종류 - Error Guessing (=오류 예측 검사, 데이터 확인 검사)
✦ 과거 경험이나 확인자의 감각으로 Test
✧ 다른 Blackbox Test 기법으로는 찾아낼 수 없는 Error를 발견하는 일련의 보충적 검사 기법
Blackbox Test 종류 - Comparsion Testing (=비교 검사)
✦ 여러 Version의 프로그램에 동일 Test 자료 제공 후 동일 결과 출력 여부 확인
Application Test Level
✦ 개발 단계에서부터 Test를 수행하므로 단순 Code 상의 오류 외 요구 분석 오류, 설게 interface 오류 등 발견 가능
✦ V-Model
✧ S/W 개발 단게와 Application Test를 연결하여 표현한 Model
요구 사항 인수 테스트
분석 시스템 테스트
설계 통합 테스트
구현 단위 테스트
Plain Text
복사
Application Test Process
✦ 사용자 요구 사항 반영 여부, 결함 여부 등 Test하는 절차 순서
Application Test Process - Test 계획
✦ Project 계획서, 요구 사항 명세서 기반 Test 목표 정의 및 대상, 범위 결정 후 Test 계획서를 작성하여 Test 대상 시스템 구조 파악, 투입 조직 및 비용 산정, Test 시작 및 종료 조건 정의
✦ Test 시작 조건
✧ Test 계획, 일정, 환경 구축, 사용자 요구 사항에 대한 Test 명세서, 투입 조직 및 참여 인력 역할과 책임 등
✧ 조건 비만족 시에도 Test 시작 가능
✦ Test 종료 조건
✧ Test 정상 완료, 기간 만료, 비용 모두 소진 등 상이하게 지정 가능
Application Test Process - Test 분석 및 디자인
✦ Test 목적 및 원칙 검토 후 사용자 요구 사항 분석, Test 시 Lisk 분석 및 우선 순위 결정, Test Data와 환경과 Tool 준비
✦ Test Data 종류: 실제 Data, 인위로 만든 가상 Data
Application Test Process - Test Case 및 시나리오 작성
✦ Test Case 설계 기법에 따라 Test Case 작성 및 검토 확인 후 Test 시나리오 작성 > Test Script 작성
Application Test Process - Test 수행
✦ Test 환경 구축 후 Test 수행 후 실행 결과 측정 후 기록
Application Test Process - Test 결과 평가 및 Reporting
✦ Test 결과 비교 분석 후 Test 결과서 작성
✧ 결함 내용, 결함 재현 순서 등 결함 중적적 기술
✧ Test 종료 시 Test 실행 절차 리뷰 및 결과에 대한 평가 수행 후 실행 최적화하여 다음 Test에 적용
Application Test Process - 결함 추적 및 관리
✦ Test 수행 후 결함 발생 위치, 종류 등 추적 관리
✧ 결함 발견 시 처리 시간 단축 및 재발 방지 가능