기말고사 01. 마지막 과제

 * 블랙박스 테스트
기능 테스트를 말하는 것

소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서
소프트웨어의 동작을 검사하는 방법

테스트 케이스는 프로그램이나 모듈의
요구나 명세를 기초로 결정
제품에 대한 요구사항과 결과물이 일치하는지 확인

프로그램 내부 구조를 고려하지 x
코드를 몰라도 됨

입력과 출력을 알아야 함

가능한 모든 기능을 전부 테스트하는 것이 좋다

사용자의 요구사항 명세를 보면서 테스트하는 것
구현된 기능을 테스트
소프트웨어 인터페이스에서 실시된다

 블랙박스 테스트의 종류
 1. 동치 분할 검사
 2. 경계값 분석
 3. 원인-효과 그래프 검사
 4. 오류 예측 검사
 5. 비교 검사

 동치 분할 검사
 1. 입력 자료에 초점을 맞춰
테스트 케이스를 만들고 검사
 2. 동등 분할 기법이라고도 한다
 3. 입력 자료에만 치중

 경계값 분석
 1. 입력 자료에만 치중한 동치 분할 기법을 보완
 2. 조건의 중간값보다 경계값에서 오류가 발생할 확율이 더 높기 때문에
 3. 입력 조건의 경계값을 테스트 케이스로 선정하여 검사

 원인-효과 그래프 검사
효용성이 높은 테스트 케이스를 선정하여 검사

 오류 예측 검사
 1. 경험이나 감각으로 테스트
 2. 다른 블랙 박스 테스트 기법으로는 찾아낼 수 없는
오류를 찾아내는 보충적 검사 기법
 3. 데이터 확인 검사라고도 한다

 비교 검사
여러 버전의 프로그램에 동일한 테스트 자료를 제공해서
동일한 결과가 출력하는지 테스트


 * Q1 답

 케이스 1
옳은 입력

 케이스 2
옳지 않은 입력
날짜가 이상
ex) 2000년 6월 35일

 케이스 3
옳지 않은 입력
미래의 날짜 입력
ex) 3024년 6월 4일 


 * 블랙 테스트와 화이트 테스트

 블랙 박스 테스트
인풋과 아웃풋만이 있음
내부 구조는 신경쓰지 x

 화이트 박스 테스트
코드 실행이 기준
내부 절차가 중요


 * EI Error Index
소프트웨어 품질 관리에서 
결함의 심각도와 발생 빈도를 고려하여
소프트웨어의 오류 상태를 평가하는 지표

 공식은
EI = 시그마(i x PI(i)) / PS

 i
오류의 심각도 수준
숫자가 클수록 심각도가 크다
보통은 1, 2, 3으로 표현

 PI(i)
특정 심각도 수준 i에 해당하는 오류 수
각 심각도 수준에 대해 발생한 오류의 개수를 의미

 PS
전체 소프트웨어의 크기
일반적으로 코드 라인 수, 기능 점수, 기타 소프트웨어의 크기를 나타내는 척도이다

주어진 소프트웨어의 오류 지수를 계산하기 위해
각 심각도 수준(i)에 해당하는 오류 수(PIi)를 수준(i)으로 가중치하여 합산한 후
이를 전체 소프트웨어의 크기(PS)로 나누어 산출하는 것

EI는 소프트웨어의 오류 상태를 나타내는 지표


* 주관식 1번 정답
test case 1
input : 2000/01/01
output : 25살
옳은 입력.

 test case 2
input : 3024/01/01
output : 0세
아직 오지 않은 날짜를 입력.

 test case 3
input : abcd/ef/gh
output : error
입력 형식의 오류. 숫자가 아닌 영문을 입력.


* 주관식 2번 정답
블랙 박스 테스트는 인풋과 아웃풋만이 있는 테스트이다. 즉 프로그램의 내부 구조는 신경쓰지 않는다. 그러나 화이트 박스 테스트는 코드 실행이 기준이다. 따라서 화이트 박스 테스트에서는 내부 절차가 중요하다.
 이러한 특징으로 인해 블랙 박스 테스트에서는 발견되지 않지만 화이트 박스 테스트에서만 발견되는 오류는 오버플로우 문제가 있다. 결과물은 옳게 나오지만 시스템 내부에서는 보안 관련 취약점 문제가 있을 수도 있다.
 또한 무한 루프 문제도 있다. 조건이 명확하지 않으면 결과물이 나와 프로그램은 계속 실행될 수도 있다.
 즉, 단발성인 테스트의 결과는 잘 나올 수 있지만 프로그램 내부에 문제가 남아 있는 경우가 블랙 박스 테스트에서는 문제점을 찾을 수 있지만 화이트 박스 테스트에서는 문제점을 찾을 수 있는 유형이다. 논리 오류, 제어 흐름 오류, 변수 또는 데이터 유형 오류가 그 예시가 될 수 있다.

* 주관식 3(A)번 정답
EI는 소프트웨어의 오류 상태를 나타내는 지표이다. 특히 위험 수준을 구분한 후 각 위험 수준에 해당하는 오류가 발생하는 빈도를 체크한다. 각 수준과 빈도를 곱한 후, 나온 결과들을 모두 더한 후에, 총 프로그램 크기로 나누는 것이 EI이다.
 공식 EI = Σ(i * PI(i)) / PS에서 i는 오류가 심각한 수준을 의미한다. PI(i)는 각 오류 수준 i가 발생한 빈도 수를 의미한다. PS는 전체 소프트웨어 크기로 일반적으로 코드 라인 수를 의미한다.


* 주관식 3(B) 정답
 PI는 위상 지수로 특정 단계 i에서 발견된 총 결함 수를 의미한다. PI를 구하면서 프로그램의 각 단계에서 발견된 결함을 추적하고 계산할 수 있다.
 공식 PI = D(i)/ ΣD(j)에서 PI(i)는 단계 i에서의 위상 지수를 의미한다. D(i)는 단계 i에서 발견된 결함 수를 의미한다. ΣD(j)는 j=1부터 현재 단계인 n까지 누적된 결함 수를 의미한다.
 PI를 통해서 어느 단계해서 결함이 많이 발생되었는지 파악할 수 있다.


* 주관식 4(A) 정답
 FP는 기능 점수 측정값으로 기능 점수 분석을 사용자 관점에서 소프트웨어 개발을 측정하기 위한 표준화된 방법이다.
 공식 FP = Count_Total [0.65+0.01 sum(Fi)], i=1 ~ 14에서 Count Total은 식별된 모든 사용자 기능의 총 개수로 입력, 출력, 조회 등이 있다. 복잡도에 따라 가중치가 있다. Fi는 일반 시스템 특성으로 소프트웨어의 복잡성에 영향을 미치는 요소이다. 각 Fi는 영향력에 따라 0~5 사이의 값이 있다. sum(Fi)는 이러한 14가지 시스템 특성의 점수를 더한 것이다. [0.65+0.01 sum(Fi)]는 값 조정 계수로 시스템의 복잡성에 따라 조정하지 못한 기능 포인트를 조정하는 데 사용한다. 0.65는 기본 값 조정 상수이고 0.01은 가중치 상수를 의미한다.


* 주관식 4(B) 정답
장점 : FP 평가는 일단 표준화된 방법이라는 장점이 있다. 또한 사용자 관점에서 기능을 측정하므로 비전문가 관계자가 더 쉽게 이해를 할 수 있다는 장점이 있다. 따라서 사용자의 요구를 보다 쉽게 반영할 수 있다. 그리고 FP 평가는 프로그래밍 언어, 방법론, 기술과 독립적이므로 다양한 프로젝트에서 일관된 방식으로 소프트웨어 평가가 가능하다.

단점 : FP 평가는 분류 가중치가 주관적이라는 단점이 있다. 따라서 평가자 양성이 중요하며 이에 따른 비용과 시간이 요구된다. 그리고 FP 평가는 다른 방법에 비해 복잡하다는 단점도 존재한다.


* 주관식 5 정답
 Use Case Model과 Object Model, Dynamic Model 각 모델들이 서로 일관되게 유지되어야 시스템의 정확성과 신뢰성을 확보할 수 있다.
 Use Case Model에서 언급된 객체는 Object Model에서 정의되어 있어야 한다. 또한 Use case Model에서 정의된 함수는 Object Model의 함수와 일치해야 한다.
 Use Case Model과 Dynamic Model의 경우 Use Case Model에서의 시나리오와 Dynamic Model의 시퀀스 다이어그램이 일치해야 한다. 즉, Use Case Model의 사용자 동작 흐름이 Dynamic Model에서 정확하게 반영되어야 한다. 또한 Use Case Model에서 정의된 주요 사건은 Dynamic Model에서 상태 전이로 표현되어야 한다.
 Object Model과 Dynamic Model 사이에서 Dynamic Model의 시퀀스 다이어그램에서의 객체 간의 메시지 교환이 Object Model에서 정의된 객체, 메서드와 일치해야 한다. 또한 Dynamic Model의 상태 변화가 Object Model의 속성과 일치해야 한다.
 이러한 일관성을 만족시키면 시스템이 정확하게 정의되고 시스템 동작 이해에 도움이 된다.