10. 정적 테스팅 개요

​
​

10-1. 정적 테스팅 개요

​

• 정적테스팅

  • 소프트웨어 테스트 방법

    • 동적 테스트

      • 프로그램 실행 O

    • 정적 테스트

      • 프로그램 실행 X

​
​

---

11. 리뷰

​

11-1. 리뷰 개요

​

• 정적테스트 (= 리뷰)

  • IEEE 1028-2008

  • 여러 전문가가 모여 프로그램을 검토하여 결함을 검출하는 방법

    • 관리 리뷰

    • 기술 리뷰

    • 인스펙션

    • 워크스루

    • 감사

    • 공식 검토

​
​

---

11-2. 관리 리뷰

​

• 진행 상황을 모니터하고 계획과 현재 일정 상태 평가가 필요한 경우
  자원, 일정이나 프로젝트 범위 등을 변경

  • 적절히 변경되었는지 확인 필요

• 설치 계획, 백업 및 회복 계획, 안정성 계획, 재난 계획, 비상 대책 계획, 진행 보고서, 테스트 결과

• 의사 결정자에게 전달되고 리뷰 목적이 달성되었는지 판단

​
​

---

11-3. 기술 리뷰

​

• 유능한 인력으로 구성된 팀이
  프로젝트의 기술적 상태를 확인하는 증거로
  작업물을 리뷰한 후 관리자에게 제공

  • 의도된 사용에 적합한지 평가

  • 계획, 법규, 표준이나 명세를 충실히 지키는지 평가

  • 변경 사항이 적절하게 구현되었는지를 평가

  • 변경 명세에 식별된 영역에만 해당 변경이 영향을 미치는지 평가

  • 여러 대안을 추천하거나 대안검토

  • 대표 엔지니어가 주재하며 경우에 따라 관리자가 해결해야 한다면 참가

​
​

---

11-4. 인스펙션

​

• 인스펙션

  • 가장 형식화된 대표적인 리뷰 방식

  • 가능한 한 개발 초기에 검사해야만 개발 초기 작업물에서 문제 검출 가능

  • 결과적으로 품질에 투입되는 비용이 감소하며 개발 기간 단축 효과

  • 코딩 전까지 일반적인 개발보다 소요 인력이 더 많이 필요

  • 초기비용 증가 BUT 개발 단계의 재작업과 투입 인력 감소

  • = 동료검토(Peer review)
    - 동료 검토 : 비슷한 수준이나 역할을 가진 사람들이 코드 등을 포함한 SW 검토하는 작업
    ​
    ​

• 인스펙션 참가자의 역할
  ​

  • 중재자(Inspection leader/Moderator)
    리더
    참가자들 선정 , 계획
    전문적으로 훈련된 퍼실리데이터(Facilitator)가 담당

    • 퍼실리데이터
      검토 회의 또는 워크숍과 같이 여러 사람이 일정한 목적을 가지고 함께 작업을 수행할 때,
      효과적으로 목적을 달성하도록 작업 과정을 설계하고 참여를 유도하여 질 높은 결과물이 나오도록 도움을 주는 사람
      ​

  • 작성자(Author)
    회의에 필요한 자료를 제출
    자료 내용에 관한 설명
    질문에 대답
    ​

  • 낭독자(Reader)
    작업물에 대한 자신의 이해 및 해석을 바탕으로 작업물에 대해
    회의 참가자들에게 인스펙션 회의를 이끄는 역할
    ​

  • 기록자(Recorder)
    회의에서 논쟁, 모든 질문 및 답변 등을 기록
    ​

  • 검토자(Inspector)
    결함을 찾아내고 전달받은 자료를 충분히 검토
    ​
    ​

• 인스펙션 과정
  ​

  1. 리뷰 계획

     • 중재자가 리뷰 목적 파악 후 리뷰팀 구성

  2. 인스펙션 절차 개요 설명

     • 중재자가 참가자들의 역할 할당

  3. 인스펙션 작업물에 대한 개요 설명

     • 작성자가 검토자들에게 검토할 작업물에 대해서 설명

  4. 준비

     • 실제 리뷰 회의 전에 인스펙션팀 구성원은 작업물을 검토

  5. 검토 회의

     • 체크리스트를 사용하여 작업물에 대한 개별 검토 완료 => 단체 회의

  6. 재작업

     • 검출된 문제 목록이 작성자에게 전달되면 실제 작업물에서 문제를 해결하는 작업을 수행

  7. 후속작업

     • 중재자나 중재자에게서 위임받은 사람이 발견된 모든 문제에 대해서 확인

​
​

---

11-5. 워크스루

​

• 비형식적인 결함 검출 방법

• 참가자들의 교육이나 지식 공유 목적으로도 수행

• 작업물을 돌아다니면서 작업물에 대한 설명을 진행하고
  검출된 결함에 대한 권고 및 조치 사항들을 기록

• 재작업 및 후속 단계에서 작성자는 모든 조치 사항들이 종결되었음을 확인
  ​
  ​

---

11-6. 감사(Audit)

​

• 제품 및 프로세스 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지 평가

• 대표 감사자, 감사자, 기록자 or 개시자

• 대표 감사자가 감사를 주도하며 인터뷰나 문서들을 점검함으로써 법규나 표준 등에 부합되는지 증거를 수집

• 제공자, 소비자, FDA와 같은 제3기관에서 필요에 따라 요구
  ​
  ​

---

11-X. 공식 검토(Formal Review)

​

• 매우 체계적이고 엄격한 리뷰

• 문서화된 절차

• 규칙대로 이행

• 명확하게 정의된 역할과 책임이 존재

• 결함을 조기에 발견하고 수정하는 목표
  ​

• 공식 검토 방법

  • 요구사항 검토 (SRR)

    • Software Requirement Review
    • 요구사항 명세서를 완전하게 검증하는 것이 목표
    • 모든 이해관계자가 요구사항에 동의하고
      요구사항이 프로젝트 목표와 일치하는지 확인

  • 예비 설계 검토 (PDR)

    • Preliminary Design Review
    • 주요 설계가 요구사항을 만족하는지 확인
    • 주요 설계 결정, 아키텍처, 인터페이스를 검토
    • 리스크 평가와 초기 비용 및 일정 예측이 포함될 수 있음.

  • 상세 설계 검토 (CDR)

    • Critical Design Review
    • 상세 설계가 모든 요구사항을 충족하고 구현 가능하며
      테스트 가능하도록 충분히 상세한지 확인
    • 모듈 설계, 데이터 구조, 알고리즘, 인터페이스 검토

  • 테스트 준비 검토 (TRR)

    • Test Readiness Review
    • 소프트웨어가 테스트 단계로 넘어갈 준비가 되었는지 확인
    • 테스트 계획, 테스트 케이스, 테스트 환경 검토
    • 주요 결함이 수정되었고,
      테스트 수행에 필요한 자원이 준비되었는지 확인

​
​

---

12. 정적 분석

​

12-1. 정적 분석 개요

​

• **자동화된 도구의 지원을 받아 정적 테스트를 수행하는 것
  • 사람이 수작업으로 직접 수행
    => 리뷰 (관리리뷰/기술리뷰/인스펙션/워크스루/감사/공식검토)

• 구조적 분석

  • 코딩 표준
  • 복잡도 분석
    • CRC

• 데이터 흐름 분석

  • 심볼릭 실행
  • 자료 흐름 분석
    • 자료 흐름 패턴
      • 변수 정의(define) : d
      • 변수 참조(use) : u
      • 변수 무효화(kill) : k

​

• 심볼릭 실행

  • 주어진 경로가 실행 가능한지 검사

  • 실행 불가능한 경로 검출

  • 프로그램 테스트 데이터 자동 생성

​

• 자료 흐름 패턴

  • EX). 결함 유형

    • 초기화하지 않고 사용한 변수
    • 선언 후 사용하지 않은 함수
    • 선언 후 사용하지 않은 변수

  • 심각한 오류

    • ku : kill-use

  • 잠재적 오류

    • dd : define-define - 두번 정의
    • kk : kill-kill
    • ~u : 정의되지 않고 처음 사용
    • ~k : 처음으로 무효화
    • dk : define-kill
    • d~ : 제일 나중에 정의

  • 정상

    • ~d : 처음으로 정의됨
    • ud : 자료 사용 후 정의
    • du : define-use
    • uu : use-use
    • uk : use-kill
    • kd : kill-define
    • u~ : 제일 나중에 참조
    • k~ : 제일 나중에 무효화

​
​

---

12-2. 코딩 표준

​

• 개발자가 프로그램을 작성할 때 지켜야 하는 규약

• 한 프로그램을 여러 개발자가 협력하여 작성하더라도
  프로그램 모든 부분이 동일한 개발자가 코딩한 것처럼 일관성 유지

  • 가독성이 좋고, 이해하기 쉬우므로 유지 보수가 용이
    ​

• 코딩스타일

  • 

  • 새로운 블록은 공백 두 칸의 들여 쓰기로 시작
    블록이 끝나면 이전 들여쓰기 수준으로 리턴

  • 메서드 이름은 카멜 표기 방식(Camel Case)을 따르고 동사나 동사구를 사용

    • 카멜 표기 방식 : 각 단어의 첫 글자를 대문자로 적되, 맨 앞에 오는 글자는 소문자로 표기

  • 변수 이름은 명사를 사용
    의미 있도록 작성되어야 하며 사용 의도를 드러내야함.

    • undefined behavior이 발생할 수 있는 경우

      • 초기화되지 않은 변수 사용

      • 배열의 범위를 넘어서는 인덱스 사용

      • 0으로 나눗셈

  • 시중에 판매되는 몇몇 정적 분석 도구로 MISRA-C 코딩 규칙 검사 가능

    • LDRA, PRQA, Parasoft
    • Suresoftetch (국내)

​
​

---

12-3. 복잡도 분석

​

프로그램 복잡도 통제를 위해
신뢰할 수 있는 척도를 사용하여 복잡도 측정

• 복잡도가 높은 프로그램 => 신뢰성, 테스트 비용, 유지보수성이 안좋음
  ​
  ​
• 순환 복잡도(Cyclomatic complexity)
  가장 널리 사용
  주어진 제어 흐름 그래프에서 선형적으로 독립적인 기본 경로(Basic path)라 불리는 프로그램 경로의 개수
  ​
  • 노드와 간선으로 구하는 공식
    • E – N + 2
      E는 간선들의 개수, N은 노드들의 개수
      
      ​
  • 닫힌 영역의 개수로 구하는 공식
    • 닫힌 영역의 개수 + 1
    • 분기 노드들의 개수 + 1
      
      ​
  • 추가적으로 알아야 할 규칙
    • 분기문을 만나면 + 1
      • If, while, for, &&, ||를 만나면 +1
      • Switch 문의 각 case에 +1
    ​
  • 순환 복잡도와 신뢰성과의 관계