Two-Rabbits

사용자 정의함수(User-Defined Funtion)

사용자 정의함수는 절차형 SQL을 이용하여 사용자가 직접 정의하고 작성한 기능을 수행합니다. 수행이 종료되면 단일 결과 값을 반환합니다.

이제 사용자 정의함수의 구조에 대해서 이야기하겠습니다. 

첫번째로 이야기할 구조는 선언부(DECLARE)입니다. 선언부에서는 사용자 정의함수의 이름과 변수, 데이터 타입 등을 정의하는 부분입니다. 

CREATE FUNCTION GET_AGE(V_BIRTH_DATE IN CHAR(8))
IS

다음 코드는 CREATE FUNTION을 이용해 GET_AGE라는 사용자 함수를 정의합니다. 그 후  운영체제에서 파라미터를 입력받는 문자열 V_BIRTH_DATE을 정의합니다.

다음은 시작(BEGIN)과 종료부(END)입니다.

시작부와 종료부는 다수의 실행을 제어하는 기본 단위로 프로시저의 시작과 종료를 표현하고 있습니다. 반드시 시작부가 나오면 종료부로 마무리 지어야합니다.

BEGIN은 선언부의 뒤에 오며 선언부를 제외한 프로시저의 모든 구조들은 BEGIN과 END사이에 정의되어야합니다.  

BEGIN
V_CURRENT_YEAR CHAR(4);
V_BIRTH_YEAR CHAR(4);
V_AGE NUMBER;

-- 제어부, SQL, 예외부, 반환부가 BEGIN과 END사이에 들어간다.

END;

BEGIN문 뒤에 사용자 정의 함수에서 사용할 V_CURRENT_YEAR, V_BIRTH_YEAR, V_AGE 변수를 선언합니다.

세번째로 이야기 할 사용자 정의 함수의 구조는 제어부(CONTROL)입니다.

사용자 정의 함수에서는 조건문인 IF문, CASE문을 이용해 문장을 실행하게 됩니다.

네번째는 SQL로 데이터 조회 용도로만 사용하기 때문에 SELECT만 이용합니다.

SELECT TO_CHAR(SYSDATE, 'YYYY'), SUBSTR(V_BIRTH_DATE,1,4)
INTO V_CURRENT_YEAR, V_BIRTH_YEAR
FROM DUAL;

SET AGE = TO_NUMBER(V_CURRENT_YEAR) - TO_NUMBER(V_BIRTH_YEAR) + 1;

SQL에서는 SYSDATE로 현재 날짜를 조회를 합니다. 조회된 날짜의 연도 값만 파싱 후 변수 V_CURRENT_YEA에 입력합니다.

그 후 V_BIRTH_DATE에서 연도값만 자른 뒤 변수 V_BIRTH_DATE에 다시 입력하는 동작을 수행합니다.

마지막으로는 두 변수의 차이를 구해 1을 더해 나이를 구한 후 AGE에 입력하는 동작을 하는 SQL입니다.
 

다음으로 설명한 예외부 (EXCEPTION)는 BEGIN~END문 사이의 SQL문의 실행 중 예외 발생시 처리 방법을 정의하고 있습니다. 

마지막은 사용자 정의 함수만 가지고 있는 구조인 반환문(RETURN)입니다. 반환문에서는 하나의 값만 결과로 넘길 수 있습니다. 

RETURN AGE;

사용자 정의 함수의 최종 결과값으로 AGE라는 값을 넘겨주고 함수는 종료됩니다. 

정의된 사용자 함수를 이용하기 위해서는 다양한 방법으로 호출 가능합니다.

SELECT문을 이용한 방법은 다음과 같습니다. 

SELECT GET_AGE("20100525")

FROM DUAL;

SELECT문에서 "20100525"라는 값을 V_BIRTH_DATE에 넘겨주게 되면 SELECT의 결과로 AGE라는 사용자 함수의 결과를 반환받습니다.

다른 방법으로는 업데이트에서 사용하는 방법입니다.

UPDATE EMPLOYEE

SET AGE = GET_AGE(BIRTH_DATE)

WHERE EMPOYEE_ID = '202020';

직원 테이블을 업데이트하기 위해서 직원번호가 202020인 직원의 나이를 사용자 정의함수를 통해 변경가능합니다. 

프로시저

프로시저(Procedue)는 절차형 SQL을 활용하여 기능을 수행하는 트랜젝션언어입니다. 즉, 프로시저를 호출하게되면 SQL작업을 포함하는 데이터 조작어를 수행하게 됩니다.  

프로시저의 구조에 대해서 이야기하겠습니다. 

선언부(DECLARE)에선 프로시저의 이름과 변수, 데이터 타입을 정의하는 부분입니다.

코드로 프로시저의 선언부에 대해서 자세하게 알아봅시다.

CREATE PROCEDURE SALES_CLOSING
  (V_CLOSING_DATE IN CHAR(8))
IS
  V_SALES_TOT_AMT NUMBER := 0;

다음 코드는 SALES_CLOSING이라는 프로시저를 정의하고 IN 뒤에는 파라미터로 V_CLOSING_DATE라는 8자리 문자열을 받도록 정의 하였습니다.

IS 뒤에는 프로시저 내에서 사용할 숫자형식의 변수인 V_SALES_TOT_AMT를 정의하였습니다.

시작부(BEGIN)와 종료부(END)는 다수의 실행을 제어하는 기본 단위로 프로시저의 시작과 종료를 표현하고 있습니다. 반드시 시작부가 나오면 종료부로 마무리 지어야합니다.

BEGIN은 선언부의 뒤에 오며 선언부를 제외한 프로시저의 모든 구조들은 BEGIN과 END사이에 정의되어야합니다.  

제어부(CONTROL)에서는 조건문 IF문과 CASE문, 반복문인 LOOP문, WHILE문, FOR LOOP문을 사용한 문장을 처리합니다. 

IF V_CLOSING_DATE < “20000101" THEN
  SET V_CLOSING_DATE = “20200101";
END IF;

다음은 파라미터 V_CLOSING_DATE가 문자열 "20000101"이면 “20200101"으로 값을 변경한다는 프로시저 내부의 조건문이 됩니다

SQL은 프로시저의 SQL은 SELECT, INSERT, DELETE, UPDATE과 같은 DML을 주로 사용되며 가끔 DDL도 사용됩니다. 

SELECT SUM(SALES_AMT)
INTO V_SALES_TOT_AMT
FROM SALES_LIST_T
WHERE SALES_DATE = V_CLOSING_DATE;

SALES_LIST_T라는 판매내역 테이블에서 다음 SQL문을 실행하고 결과 값을 V_SALES_TOT_AMT라는 변수로 전달합니다.

예외부(EXCEPTION)에 대해서 이야기 해보겠습니다. BEGIN END문 사이에서 SQL문의 실행이 될때 발생하는 예외에 대한 처리 방식을 정의하고 있는 부분입니다. 

EXCEPTION
  WHEN NO_DATA_FOUND THEN
  SET V_SALES_TOT_AMT = 0;
  INSERT INTO SALES CLOSED_T( SALES DATE, SALES TOT AMT) 
  VALUES ( V_CLOSING_DATE, V_SALES_TOT_AMT);

위의 코드에서는 만약 SQL의 조회 결과가 없을 경우 SQL의 결과로 NO_DATA_FOUND가 발생합니다. 그 결과 V_SALES_TOT_AMT은 0이 되며, INSERT 구문을 통해 마감된 값을 테이블에 삽입하는 동작을 실행합니다.

마지막으로 실행부 (TRANSACTION)는 프로시저에서 수행되는 DML을 DBMS 적용 여부를 COMMIT(적용), ROLLBACK(취소)를 통해 결정하는 부분입니다.

위에서 선언된 프로시저를 이용하려면 EXECUTE를 이용해 호출합니다.

EXECUTE SALES_CLOSING('20210506');

위의 호출문이 정상적으로 실행되면 V_CLOSING_DATE에 "20210506"이라는 8자리 문자열 값이 프로시저로 전달되며.

위에서 설명한 프로시저의 구조가 실행됩니다.

통합 테스트

통합 테스트(Integration Test)는 소프트웨어 각 모듈 간의 인터페이스 관련된 오류와 결함을 찾아 내기 위해서 사용되는 테스트 기법입니다. 

통합 테스트는 어떨게 통합이 되는지에 따라 두가지로 분류가 됩니다. 

첫번째 통합 테스트 기법은 하향식 통합(Top Down)입니다. 하향식 통합은 메인으로 부터 아래 방향으로 이동하며 깊이 우선 또는 너비우선 방식으로 하향식으로 통합됩니다.

이때 통합되는 모듈과 모든 하위 컴포넌트를 대신하기 위해 더미 모듈인 스텁(Stub)을 이용하여 하위 모듈의 반환 값을 전달하며 통합을 진행하게 됩니다.

두번째 통합 테스트 기법은 상향식 통합(Bottom Up)입니다. 상향식 통합은 최하위 레벨의 모듈이나 컴포넌트로 부터 시작해서 위쪽으로 이동해가며 구축을 통해 테스트를 진행하는 방식입니다.

이때 상향식 통합에서는 상위 모듈의 입력과 출력을 확인하기 위해 사용되는 더미 모듈인 드라이버(Driver)와 하위 모듈의 기능을 수행하는 클러스터(Cluster)를 이용해 통합을 진행합니다.

테스트 커버리지

테스트 커버리지(Test Coverage)는 주어진 테스트 케이스에 의해 수행되는 소프트웨어 테스트의 범위를 측정하는 기준이 됩니다.

또다른 테스트 커버리지의 역할로는 테스트의 정확성과 신뢰도를 향상시키는 역할도 하고 있습니다. 

테스트 커버리지는 3가지 기법으로 분류 됩니다.

- 기능 기반 커버리지: 기능 기반 커버리지는 테스트를 실행할 애플리케이션의 모든 기능을 두고 100% 달성을 목표한 뒤 실제 테스트가 수행된 기능의 수를 측정하는 방법입니다.

- 라인 커버리지: 라인 커버리지는 애플리케이션의 전체 소스 코드의 라인 수를 이용하여 시나리오가 수행한 소스 코드의 라인 수를 측정하는 방법입니다.

- 코드 커버리지: 코드 커버리지는 소스 코드의 구문과 조건 등 구조 코드가 얼마나 테스트 되었는지 측정하기 위해 사용됩니다.

코드 커버리지 유형

테스트 커버리지 중 구조 코드가 얼마나 테스트 되었는지 측정하는 코드 커버리지에 대해 더욱 자세하게 설명하겠습니다. 

첫번째로 구문 커버리지입니다. 구문 커버리지는 프로그램 내의 모든 명령문을 적어도 한 번 수행하는 커버리지입니다.

구문 커버리지의 다른 특징으로는 조건문의 결과와 상관없이 구문 실행 수로 계산이 됩니다.

두번째 테스트 커버리지는 결정 커버리지입니다. 프로그램 내에서 전체 결정문이 적어도 한 번은 참과 거짓 결과를 수행하는 커버리지입니다. 
예를 드러 if A and B라는 조건이 있다고 생각해봅시다. 이때 테스트 커버리지는 A와 B의 각 값의 결과가 아닌 전체 조건식인 A and B의 결과가 참과 거짓이 나오도록 실핼시키는 것을 말합니다.

세번째는 조건 커버리지입니다. 조건 커버리지는 결정 명령문 내에서 각 조건이 적어도 한 번 참과 거짓의 결과가 되도록 수행하는 커버리지 입니다.
결정 커버리지의 예와  같이 if A and B라는 조건이 있다고 봅시다. 이때는 A and B의 결과가 아닌 각 값의 결과를 확인 해야합니다. 즉, A의 결과로 참과 거짓이 나오고 B의 결과로도 참과 거짓이 되도록 수행시켜야합니다.

네번째는 조건/결정 커버리지입니다. 조건/결정 커버리지는 조건 커버리지와 결정 커버리지의 최소한의 조합으로 전체 조건식도 참과 거짓이 나와야 하며 개별 조건식도 참과 거짓이 나와야합니다.

다음은 변경 조건/결정 커버리지입니다.  변경 조건/결정 커버리지는 개별 조건식이 다른 조건식에 영향 받도록 구성해 전체 조건식에 독립적으로 영향을 주도록 변형시킨 커버리지입니다.

마지막 테스트 커버리지는 다중 조건 커버리지입니다. 다중 조건 커버리지는 결정 조건 내에서 모든 개발 조건식의 모든 가능성 있는 조합을 보장하는 커버리지입니다.

소프트웨어 테스트

애플리케리션에서 사용자가 요구하는 기능과 성능, 사용성 등이 만족하는지를 확인 하고 결함을 찾는 활동을 소프트웨어 테스트라 합니다.

소프트웨어 테스트의 관점은 오류를 어떻게 발견하는지 언제 발견하는지에 따라 여러 관점으로 나눠집니다.

- 오류 발견 관점: 오류 발견 관점은 프로그램에 잠재되 있는 오류를 발견하고 수정하기 위해 필요합니다.

- 오류 예방 관점: 프로그램을 실행 전에 동료 검토나 워크스루, 인스펙션 기법을 이용해 오류를 사전에 예방 하는 기법입니다.

- 품질 향상 관점: 사용자의 요구사항에 맞춰 반복적인 테스트를 거쳐 제품의 신뢰도를 향상시키는 기법을 품질 향상 관점이 있습니다. 

즉, 위에서 설명한 각 관점을 모두 숙지하고 신경써서 오류가 없는 애플리케이션을 서비스 하는게 목적입니다. 

소프트웨어 테스트 원리

소프트웨어 테스트는 다양한 원리가 존재합니다. 

테스팅은 결함 존재를 밝힌다는 원리는 결함이 존재하는 것을 프로그래머는 테스팅을 통해 밝혀 결함을 줄이는 활동을 하게 됩니다. 

완벽한 테스팅이 불가능한 것은 너무도 완벽한 테스팅을 하면 결국 사용한 시간과 자원 대비 낭비라는 이야기입니다.  

개발초기에 테스팅을 시작해야한다는 것은 초기부터 테스트 설계를 시작하게 되면 빠른 결과를 얻을 수 있고 테스팅에 소모 되는 시간과 재작업이 줄어들어 서비스 개발에 있어 개발기간과 결함을 줄이게 됩니다.

결함집중은 80대 20의 법칙이라고도 불립니다. 20%적은 수의 모듈에서 80% 이상의 대부분의 오류가 발견된다는 소프트웨어 테스트 법칙입니다.

살충제 패러독스는 동일한 테스트 케이스로 반복적으로 오류검사를 시행하게 된다면 새로운 버그를 놓치게 된다는 법칙입니다. 

테스트는 정황에 의존적은 소프트웨어의 성격이 달라지면 그 성격에 맞춰 테스트를 다르게 수행해야됩니다.

오류-부재의 궤변은 만약 결함도 없는 완벽한 소프트웨어를 만들어 낸다해도 요구사항을 만족시킬수 없다면 그것은 높은 품질은 소프트웨어는 아닐 것입니다. 

다양한 소프트웨어 테스트의 원리에 대해서 알아봤는데 특히 결함집중(80대20의 법칙), 살충제 패러독스, 오류-부재의 궤변 등은 시험에서 내기 좋은 문제임으로 반드시 암기하시고 넘어가야합니다.

소프트웨어 테스트 유형

소프트웨어 테스트는 프로그램 실행 여부에따라서 나뉘거나 테스트에 사용되는 기법에 따라서도 나뉘게 됩니다. 

실행여부에 따라서 나눠진 테스트 기법의 유형에 대해서 알아보겠습니다.

- 정적 테스트: 정적 테스트는 동료 검토나 워크스루, 인스펙션과 같이 프로그램의 실행없이도 구조를 분석하고 논리성을 검증하는 방식입니다.

- 동적 테스트: 동적 테스트는 직접 프로그램을 실행해 소프트웨어를 테스트하는 방식으로 화이트박스 테스트와 블랙박스 테스트가 여기에 속합니다.

동적테스트 기법에 속해있는 따른 화이트 박스 테스트와 블랙박스 테스트는 테스트의 기법에 차이가 있습니다.

화이트 박스 테스트는 구조테스트라고도 불리며 프로그램 내부의 로직과 구조를 투명하게 보며 수행되는 테스트 기법입니다.

화이트 박스 테스트도 어떤 방식을 이용하는지에 따라 두가지로 분류됩니다.

소프트웨어의 논리적 복잡도를 측정을 통한 수행 경로의 집합을 정의하는 제어구조 테스트와 프로그램의 루프를 이용해 실시되는 루프테스트로 나눠지게 됩니다.

화이트박스 테스트는 구문 커버리지와 결정 커버리지, 조건 커버리지, 조건/결정 커버리지 등을 포함하고 있습니다.

다음은 블랙박스 테스트에 대해서 알아보겠습니다. 블랙박스 테스트는 기능 테스트로도 불리며 외부 사용자의 요구사항 명세를 확인을 통해 수행되는 기법입니다.

블랙박스 테스트의 유형은 어떻게 도출하는지에 따라 총 7가지로 분류됩니다.

- 동등 분할 테스트: 동등 분할 테스트는 입력 데이터의 영역이 유사한 도메인으로 유효 값과 무효 값을 그룹핑합니다. 그 사이에서 대표 값을 도출하는 테스트 기법입니다.
예를 들어서 0<X<100인 X가 있습니다. 동등분할 테스트를 이용하면 X=10, X=-100, X=1000을 대표 값으로 지정해 테스트합니다.

- 경계 값 분석 테스트: 경계 값 분석 테스트는 등가 분할한 뒤 경계 값 부분에서 오류가 발생할 가능성이 높다는 원리를 이용한 테스트입니다. 그래서 경계 값을 포함한 테스트 케이스들을 설계하여 테스트하게 됩니다.
위와 같은 예를 들어보겠습니다. X가 0<X<100일 경우 X=0, X=1, X=99, X=100을 테스트하면 경계 값 부분을 테스트 가능합니다.

- 결정 테이블 테스트: 결정 테이블 테스트는 요구사항을 논리와 발생조건을 테이블 형태로 나열한 뒤 조건과 행위를 모두 조합 해 테스트하는 기법입니다.

- 상태전이 테스트: 상태전이 테스트는 테스트 대상이나 시스템, 객체 등의 상태 구분합니다. 그 후 이벤트가 오면 다른 상태로 전이 되는 경우의 수를 찾는 테스트 기법입니다.

- 유즈케이스 테스트: 유즈케이스의 경우 실제 자주 사용되는 테스트 기법입니다. 시스템이 모델링 되어 있으면 프로세스를 기반으로하여 테스트 케이스를 명세화 수행을 하게됩니다.

- 분류 트리 테스트: 분류 트리테스트는 소프트웨어의 일부 또는 전체를 트리 구조로 표현 후 분석을 통해 테스트 케이스를 설계하는 기법입니다.

- 페어와이즈 테스트: 페어와이즈 테스트는 테스트할 데이터 값을 최소 한번씩 조합하게되면 커버하게 될 기능적 범위가 모든 조합에 비해 상대적으로 적어지게 됩니다. 이를 테스트 셋으로 구성해 사용하는 기법을 이야기합니다.

마지막으로 알아볼 내용은 테스트 종류에 따른 분류입니다.

첫번째로 이야기할 테스트는 명세 기반 테스트라고도 불리는 블랙박스 테스트입니다. 프로그램의 요구사항 명세서를 기반으로 테스트 케이스를 선정합니다.

두번째 테스트는 구조 기반 테스트라 불리는 화이트박스 테스트입니다. 소프트웨어 내부 논리 흐름을 따라 테스트 케이스를 선정하는 기법입니다.

마지막으로는 경험기반 테스트입니다. 경험기반 테스트는 유사 소프트웨어나 테스터의 경험을 토대로 수행하는 테스트 기법을 이야기합니다.