ISTQB CTFL 요점정리 6) Test 도구 1. 정적테스

2022.07.10 - [지방대 출신 초봉 4천받기/도움되는 자격증 (ISTQB CTFL)] - ISTQB CTFL 요점정리 5) Test의 유형과 관리

ISTQB CTFL 요점정리 5) Test의 유형과 관리

1. 정적 테스팅의 개요

  -. SW를 구동시키지 않고 결함을 발견하는 활동으로, 개발 산출물(사양서, 모델, 설계서, 소스코드, 형상 등)과 테스트 산출물(T/C, Test result, 테스트 환경, 스크립트 등)을 사람이 리뷰 하거나 툴을 이용해 분석하여 설계 산출물의 문제점, 소스코드의 잠재된 결함 발견, 대상 코드의 품질 정량성 측정(복잡도, 함수 콜 관계 등)하는 등 작업 산출물의 일관성과 내부 품질향상을 위해 사용된다. 안전 최우선 시스템(항공, 자동차, 의료 등)에서 매우 중요하게 다뤄지며, 다른 영역에서도 점차 일반화 되고 있다. 도구를 사용하기 때문에 별도의 T/C는 필요 없다.

  -. 작업 산출물 리뷰 프로세스 활동 순서 : 계획 → 리뷰 착수(Initiate Review_작업 산출물 및 체크리스트 등 자료 배포 후 리뷰 시작) → 개별 리뷰 (Individual Review_잠재결함, 권고사항, 질문기록) → 이슈 논의 및 분석 → 수정 및 보고

 

2. 정적 테스팅의 장점

  -. 코드가 완전히 나오기 전에도 가능하다, T/C를 만들 필요가 없다, 문제 원인을 바로 찾아 내기 때문에 디버깅 시간을 줄일 수 있다.(개발기간 단축 및 테스트 비용감소 효과를 볼 수 있지만, 테스트 인력이 부족할 때 사용하는 기법은 아니다. 테스트 인력이 부족한 경우라면 경험기반 기법, 탐색적 테스팅 등이 활용된다.)

 

3. 정적 테스팅의 유형

  1) Review : 사람이 개발 산출물을 매뉴얼 하게 진행 하여 장애 자체보다 장애 원인 발견이 목적이다. 요구사항명세서, 소스코드, T/C 등 개발과 관련된 전반적인 산출물이 리뷰 대상이 된다. 또한 리뷰를 위해 점검기준(체크리스트)이 필요하다.

    -. Walkthrough 특징 : 저자에 의해 진행 및 제어 된다. 시나리오, 예행연습(Dry runs), 동료그룹 검토 등이 진행 되며, 시간 및 인원수 등에 제한이 없고 상황에 따라 변경할 수 있기 대문에 사업자 리스크가 높은 영역과같이 고객과 의사소통 해야할 때 많이 사용된다. 학습, 시스템에 대한 이해 향상, 결함발견이 주 목적이다.

    -. Inspection 특징 : 저자가 아닌 훈련된 중재자(Moderator)에 의해 진행 및 제어 된다. 주로 동료 검사로 이루어지며 메트릭(Metric)을 수집하고, 체크리스트와 규칙을 기반으로 시작과 종료 조건이 있는 정식 프로세스이다. 미팅전 준비과정이 필요하며 인스펙션 리포트와 발견사항(인시던트)리스트가 산출물로 나온다. 정식적인 후속 처리 확인(follow-up)프로세스가 존재하며, 결함발견을 주요 목적으로 한다.

    -. 공식적 리뷰에는 관리자, 중재자, 검토자, 저자, 기록자 역할이 있다.

      ● 관리자 : 리뷰의 실행여부를 결정하고 프로젝트 일정에 리뷰시간을 할당하고 리뷰목적달성여부를 확인하고 승인다.

      ● 중재자 : 리뷰를 계획하고 미팅을 진행하고 후속조치 처리 여부 등을 추적하고 관리한다. 리뷰 중재자는 교육을 받는다.

      ● 검토자 : 해당분야의 기술적 또는 비즈니스적 배경을 갖춘 사람으로 필요한 준비를 거쳐 리뷰대상에서 인시던트를 발견하고 발견한 인시던트를 리뷰미팅에 공유하는 사람.

      ● 저자 : 리뷰 대상문서(산출물)의 작성자 또는 책임자.

      ● 기록자 : 리뷰 미팅에서 발견된 이슈, 미해결점 등을 기록하고 문서화 한다

  2) Analysis : 툴이 자동으로 결함을 찾아낸다.

    -. Syntax analysis 특징 : 코딩 룰과 같은 규칙이나 소스코드의 작성 스타일을 점검하는 방식의 툴 이다.

    -. Semantics analysis 특징 : 구문기반의 의미에 문제가 있는지를 점검하는 툴 이다.

 

4. 툴에 의한 정적 분석

  -. 주로 모델이나 소스코드 같이 정형화된 산출물 분석에 쓰인다. 구문 오류검출, 의미 오류검출, 소스코드 정보 제공 등에 활용된다. 왜냐하면 이 같은 것들은 사람이 직접 하는 것 보다 툴로 돌리는 게 효율적이기 때문이다.

  1) 구문 오류검출 : Coding 줄이나 Coding Style(띄어쓰기 구준 등)준수여부, 문법이나 기타 타입오류 등과 같은 오류.

  2) 의미 오류검출 : Overflow 나 런타임 에러 등과 같은 오류.

  3) 소스코드 정보 제공 : SW구조, 호출관계, 복잡도 정보 등 SW이해 및 설계 개선 지원을 위함.

  4) 정적 분석 도구를 통해 발견되는 결함 : 정의되지 않은 값으로 변수 참조, 모듈과 컴포넌트 간에 일관되지 않은 인터페이스, 사용되지 않는 변수, 사용되지 않는 코드, 코딩 표준 위반, 보안 취약성, 코드와 소프트웨어 모델의 구문 규칙 위반.

 

5. 정적 분석기법

  1) Dataflow Analysis : 변수의 사용 및 정의에 기반을 둔 검증. 즉, 정의된 변수를 사용하지 않고 다시 정의하거나, 정의 한 후 없애거나, 없앤걸 또 없애거나, 이미 없앤 거에 접근하려 한다는 등의 경우 문제가 될 수 있으므로 이를 검증하는 것.

Ex) Help 변수를 이용하여 Min, Max가 반대일 때 값의 교환하는 코드 예제로. 이 예제는 변수의 사용 및 정의의 잘못된 예를 보여준다.
  void exchange (int& min, int& max)
  {
    int help;
    if (min > max)
      {
        max = help;     //Undefined variable의 사용 (help는 정의된 거 없음)
        max = min;      // max에 2번 할당. 그로 인한 초기값 상실
        help = min;      // 사용되지 않은 값의 할당
      }
  }

  2) Controlflow Analysis : SW의 가능한 모든 경로의 분석. 즉, while 무한루프, 조건 부족으로 절대 들어가 지지 않는 기능 등을 flow에 따라 찾고 검증하는 것.

  3) 정적 분석의 한계 : 정적 분석의 정밀도는 False Positive/Negative가 얼마나 적게 발생하는가를 기준으로 한다. 즉, 사람이 만든 툴로 검사하는 거다 보니 정상 코드를 에러모드로 판단하거나(false Positive), 에러인 코드를 정상이라고 판단(false Negative)할 수 있는데 이게 적을 수록 정밀도가 높다고 본다.