시스템이 정해진 요구사항을 만족하는지 확인하고 주어진 표준 등을 준수하는지 검증하기 위해 테스트 수행

결과

(24년 7월 1일 추가)

6월 28일 아침 9시에 시험 결과가 공개됐다.

다행히도 합격했다. 네다섯문제 더 틀렸으면 불합격이었다.
보통의 자격증은 60점이 합격기준이라 항상 널널했는데, CSTS는 75점 이상이라 불안불안했다.

자격증을 공부하며 인상깊었던 것은 두 가지였다.

• 테스트는 궁극적으로 정상작동이 아니라 결함이 존재함을 보여주기 위해 수행하는 것이라는 사실
• 테스트를 설계할 때 단순히 기능요구사항 뿐 아니라 다양한 품질기준과 실제 프로그램의 순서도로부터 테스트케이스를 뽑아낼 수 있다는 것

학부에서 소프트웨어 공학을 배우지 못했는데, 어느정도 빈 부분을 메울 수 있었다.

정보처리기사 실기시험을 앞두고 있는데, 소프트트웨어 테스트 부분은 이제 걱정없다.

후기

(24년 6월 15일 추가)

2024년 6월 15일 서울 스페이스쉐어 삼성코엑스에서 봤다.
정말 어려웠다. 진짜 어려웠다.
분명 FL시험인데 AL출제범위에 있는 것 까지 나왔다.
헷갈리는 문제가 많았고, 말장난치는 듯한 문제가 많았다.

객관식은 참 답이 없었는데, 주관식은 밸런스를 맞추려는지 쉽게 나왔다.

몇 문제는 예제 문제가 그대로 나왔다. 다만 그 수가 그렇게 많지는 않았던듯.

왜 보냐

• 2024-상반기 자격증 겁나빨리많이따기 프로젝트의 일부
• 한 번도 똑바로 해본 적 없는 소프트웨어 테스트에 대해 깊게 이해하기
• 정보처리기사 실기 시험에 대비
• (전에 일할 때 만났던 TTA가 괜히 반가워서 흥미 생겼음)

테스트 개요

개요

테스트 목적

• 결함 검출, 제품 품질 개선
• 품질평가, 의사결정 지원
• 개발 프로세스 개선 지원

장애, 결함, 오류

• 소프트웨어 요구사항 : 기대, 약속된 소프트웨어의 동작 기준을 정의한 것
• 장애(Failure) : 소프트웨어가 요구사항과 다르게 동작하는 상황 (실행결과와 요구사항 사이에 관찰가능한 차이 있는 상황)
• 결함(Defect) : 장애를 유발할 수 있는 소프트웨어 내의 문제
  • 실제 코딩으로 구현하는 단계 뿐 아니라, 개발의 전과정에서 결함이 발생할 수 있음.
  • 빨리 발견해서 없앨 수록 결함해결 비용이 싸다. 아래의 순서.
    • 요구분석 - 설계 - 코딩 - 단위 테스팅 - 인수 테스팅 - 유지보수
• 오류(Error) : 결함이 생기게 한 개발자의 행위
  • 누락 : 요구명세에 있는거 빼먹음
  • 부정확한 구현 : 요구명세대로 구현은 했는데 좀 잘못했음.
  • 비관련 : 쓸데없는거 구현함

테스팅, 디버깅, 재테스팅

• 테스팅
  • 결함 발견을 위해 소프트웨어 실제 동작과 요구사항 사이의 차이를 확인
  • 장애발생 여부를 통해 결함의 유무를 간접적으로 판단함. 어떻게 고치는지 모르는 단계.
  • 결과 : 결함을 검출한 테스트 케이스, 테스트 환경
• 디버깅
  • 결함의 위치를 파악하고 제거
  • 결과 : 코드 수정
• 재테스팅
  • 결함이 진짜 제거됐는지 확인. 결함이 검출됐을 때의 테스트케이스로 수행.

테스트의 현실과 실제

프로그램 테스트는 결함이 있음을 보일 수는 있지만, 결함이 없음을 보일 수는 없다.

• 주어진 자원으로 가능한 효과적이고 효율적인 테스트 수행해야 함
  • 동적테스트의 한계를 고려한 테스트케이스 설계 : 동등 분할, 경곗값 분석, 조합테스트
  • 위험기반 테스트 적용

테스트 진화 과정

겔퍼린, 헤첼이 5레벨로 나누어 설명

1. Debugging-oriented : 테스트와 디버깅 뚜렷한 차이 없음. 우연히 발견한 결함의 디버깅에 중점. 결함 탐색 노력 없음.
2. Demonstration-oriented : 시스템의 정상 작동을 증명하기 위한 테스트 케이스 설계. 결함을 찾기 위한 테스트케이스를 설게하지는 않음.
3. Destruction-oriented : 프로그램에 결함이 존재함을 보여주기 위한 테스트케이스 설계
4. Evaluation-oriented : 개발 전 단계에서 발생하는 결함을 발견하려고 함.
5. Prevention-oriented : 결함이 애초에 발생하지 않도록 사전 방지. 테스트가 용이하도록 시스템 설계. 테스트케이스 미리 설계. TDD.

테스트 원칙

• 프로그램 개발팀과 무관한 그룹이 수행해야 함
• 결함이 없을거라고 가정하면 안됨
• 타당하지 않고 예상치못한 경우에 대해서도 수행해야 함
• 어떤 부분에 결함이 남아있을 확률은 그 부분에서 이미 발견된 결함의 수에 비례.
  • 파레토 원칙 (결함의 80%는 20%의 모듈에서 발생)
• 테스트케이스 체계적으로 관리
• 각각의 테스트 결과 철저하게 점검

테스트와 품질 평가

ISO 25010에 따른 소프트웨어 품질 특성

• 기능 적합성 : 요구 기능 만족
• 성능 효율성 : 적절한 자원사용, 반응시간
• 호환성
• 사용성 : 쓰기 쉽냐?
• 신뢰성 : 규정된 조건, 기간 내에서 잘 동작
• 보안성 : 정보, 데이터 보호 능력
• 유지보수성
• 이식성

테스트 유형

• 기능 테스트 : 기능 요구사항에 중점
• 비기능 테스트 : 품질 요구사항에 중점
  • 각 품질 특성별로 각각의 테스트(=유형 테스트) 수행
• 피처에 중점을 둔 테스트 = 유형테스트

테스트와 품질 보증

포함관계

• 품질 보증
  • V&V (Verification & Validation)
    • 테스트

V&V (IEEE Std. 1012-2012)

• 정형방법 : 모델 체킹, 정확성 증명
• 테스팅 : 동적, 정적
• 분석 : 시뮬레이션, 평가

소프트웨어 품질보증

• 이해관계자 요구사항, 개발의 모든 것 포함

테스트 기본 용어

• 테스트 대상 : 테스트를 통해 결함을 검출하려는 대상 소프트웨어 (전체 또는 일부)
• 테스트 레벨 : 테스트 대상에 따라 수행되는 각각의 테스트
  • 컴포넌트 테스트 : 각각의 컴포넌트
  • 통합 테스트 : 전체 컴포넌트의 연결에 중점
  • 시스템 테스트 : 전체
• 피쳐 : 테스트 대상에 대해 테스트하고자 하는 특성 (측면, 관점)
  • 종류 : 기능피처, 비기능피처
  • 테스트 계획 수립할때 식별 --> 테스트 범위로 기술
  • 테스트 설계 활동을 통해 피처 구체화 -> 테스트 케이스, 절차 개발
• 테스트 설계 기법
  • 정적 테스트 : 실행하지 않고 테스트. 자동화도구 사용 가능(그러나 오검지 가능)
    • 특징 : 환경 필요 없음. 실행가능 소프트웨어 필요 없음. 소스코드만 필요.
    • 리뷰 : 개발단계별 산출물이 품질 목표에 부합하는지 점검, 결함 검출
    • 정적 분석 : 결함으로 판단되는 패턴이 소스코드에 있는지 분석
  • 동적 테스트 : 실행해서 테스트
    • 특징 : 환경필요. 실행가능 소프트웨어 필요.
    • 명세 기반 방법 : 내부 논리 참조 없이 요구명세로 테스트 케이스 개발. 전과정에 활용가능.
    • 구조 기반 방법 : 내부 논리를 기반으로 테스트 케이스 개발 (= 구조적 테스트, 화이트박스 테스트, 글래스박스 테스트)
    • 경험 기반 테스트 : 테스트케이스가 아닌, 경험과 직관을 활용해서 수행
      • 오류 추정
      • 탐색적 테스트
• 테스트케이스 : 입력, 예상결과, 입력제공방법, 결과 비교 방법
• 테스트 절차: 테스트를 준비, 실행, 결과 관찰, 기록하는 절차를 정의한 것
  • 테스트 스크립트 : 테스트 절차를 자동화도구가 해석하고 실행하는 언어로 작성한 것
• 테스트 환경 : 테스트를 실행하는 모든 환경 포함
  • (하드웨어, 운영체제, 시스템 소프트웽, 외부 연동 시스템, 응용 소프트웨어, 테스트 도구)
    

테스트 분류

테스트 레벨에 따라

• 분류
  • 컴포넌트(단위) 테스트
  • 통합 테스트
  • 시스템 테스트
  • 인수 테스트
• V모델
  • 필요 기대 - 인수 테스트
  • 요구 분석 - 시스템 테스트
  • 구조 설계 - 통합 테스트
  • 상세 설계 - 컴포넌트 테스트
  • --------구현

테스트 유형에 따라

ISO 25010 품질모델은 주특성, 부특성을 가짐.

• 기능적합성 : 완전성, 정확성, 타당성
• 사용성 : 타당성 식별력, 학습성, 운영 용이성, 사용자 오류 보호, ui미학, 접근성
• 성능 효율성 : Time behaviour, 자원 활용성, Capacity
• 호환성 : 공존성, 상호운영성
• 신뢰성 : 성숙성, 가용성, 장애허용성, 회복가능성
• 보안성 : 기밀성, 무결성, 부인방지, 책임성, 진본성
• 유지보수성 : 모듈성, 재사용성, 분석성, 변경용이성, 테스트 용이성
• 이식성 : 적응성, 설치 용이성, 대치 용이성

분류

• 기능 테스트 : 기능적합성을 평가.
  • 기능 요구사항 측면의 테스트
  • 모든 테스트 수준에서 수행
• 비기능 테스트 : 나머지 특성을 평가.
  • 품질 요구사항 측면의 테스트
  • 보통 시스템 테스트, 인수 테스트에서 수행

테스트 설계 기법에 따라

정적 테스트

• 리뷰 유형
  • 산출물의 결함 검출, 프로젝트 진행상황 점검. 전문가 그룹이 수행.
  • 절차 : 경영진 준비, 리뷰 계획, 리뷰 절차 개요 설명, 작업물 개요 설명, 개별 준비, 그룹 검토, 재작업, 후속 작업
  • 종류 : 관리 리뷰, 기술 리뷰, 인스펙션, 워크쓰루, 감사
• 정적 분석 유형
  • 소스코드의 구조적 속성을 이용, 자동화도구로 수행 가능
  • 종류 : 코딩 표준, 복잡도 측정, 자료 흐름 분석

동적 테스트

• 명세 기반 테스트 : 소스코드 없이 테스트케이스 결정
  • 동등 분할, 분류 트리 기법, 경곗값분석, 신택스 테스트, 조합 테스트, 상태 전이 테스트, 인과 그래핑, 결정표 테스트, 시나리오 테스트
• 구조 기반 테스트 : 소스코드 참고해서 테스트케이스 결정
  • 문장, 결정, 조건, 결정/조건, 다중 조건, 변경 조건/결정, 기본경로 테스트
• 경험 기반 테스트
  • 오류 추정
  • 탐색적 테스트

대표적인 테스트 수행 방법

리그레션 테스트

• 변경됐을 때 하는 테스트. 변경이 결함을 만들지 않았는가? 기존 요구사항을 충족하는가?
• 테스트 전략 : Retest-all, 선택적 리그레션 테스트, 테스트 최소화, 테스트 우선순위화

소프트웨어 생명주기 모델에 따른 테스트

• 소프트웨어 생명주기 : 개발 체계의 추상적 표현, 순차적/병렬적인 단계로 구성
• 순차적 생명주기 모델
  • 폭포수 모델, V-모델
• 진화적 개발 모델 : 핵심 부분 먼저 개발 -> 각 구성요소와 추가 요구사항 개발
• 애자일 개발 방법론 : TDD (테스트케이스 먼저 작성 -> 코드 작성), CI

위험 기반 테스트

• 피처 위험 분석을 통해 테스트 계획, 설계, 실행 등을 수행하는 것.
• 위험한거 먼저 대상에 추가하고, 가용자원에 따라 위험도 낮은건 제외

모델 기반 테스트

• 모델 : 테스트 대상에 대한 기대 동작을 기술(도식화)한 것
  • 자연어, 상태 전이도, UML다이어그램
• 모델기반테스트의 모델 : 많이 정형화되고 상세한 모델이어야 함. 모델을 바탕으로 모든 테스트 제반사항 결정
  • 정형적 표현법 사용 : 의사결정표, UML 상태 다이어그램, UML 액티비티 다이어그램
• 이점 : 대부분의 활동 자동화. 이른시점에 문제점, 결함 식별
• 단점 : 모델 구축 비용 비쌈

테스트 레벨에 따른 테스트 수행

레벨별 테스트 대상 수

• 컴포넌트 테스트 : 컴포넌트 개수
• 통합 테스트 : 아키텍처 설계도의 화살표 개수
• 시스템 테스트 : 1 (시스템 자체)

컴포넌트 테스트

개별 모듈(컴포넌트)의 테스트.
각 모듈 구현한 후에 수행 (TDD가 아닌 일반적인 경우)

테스트 환경 (테스트 베드)

• 모듈을 단독으로 실행할 수 있는 환경 필요
  • 호출되는, 호출하는 컴포넌트에 의존하지 않는 독립적인 방식으로 수행
• 주요 구성 요소 :
  • 모듈을 호출 : 테스트 드라이버
  • 모듈이 호출 : 테스트 스텁 (객체지향 프로그램인 경우 모의 객체로 대체)
  • 드라이버 -> 테스트 대상 모듈 -> 스텁

모의 객체

절차지향 방식 프로그램에서는 스텁을 사용할 수 있지만, 객체지향에서는 어려움
그래서 스텁 대신 모의 객체 사용.

• 분류 : Dummy, Test Stub, Test Spy, Fake Object

모의 객체를 수작업으로 만드는 대신 모의객체 생성 프레임워크 사용 가능 (e.g., mockito + junit)

@Mock
모의객체 선언
@InjectMocks
주입대상 선언 (모의객체를 참조하는 테스트 대상)
@Test
public void test이름(){
  1: fixture(setup)부분
  ..
  3: 테스트 기능 호출
  ..
  5: 결과확인 (verify)
}

FIRST 원칙

컴포넌트 테스트를 잘 수행하기 위한 5가지 원칙

• Fast : 실행시간 빨라야 함
• Isolated : 한 테스트가 다른 테스트에 의존하지 않아야 함
• Repeatable : 여러번 실행해도 같은 결과가 나와야 함
• Self-Validating : 사람의 개입 없이 테스트 통과 여부를 알 수 있어야 함. (자동화 권장)
• Timely : 제 때 수행해야 한다. (보통은 코드 작성시점, TDD하는 경우 코드 작성 직전)

통합 테스트

컴포넌트 통합 과정에서 수행. 컴포넌트간 상호 연동이 잘 되었는지 검사.
드라이버가 최상위 컴포넌트 호출. 스텁 없음.

두 가지 관점 (목적)

• 컴포넌트 연결의 정확성(상호작용)에만 초점 : 데이터가 누락없이 순서대로 잘 넘어가냐?
• 연결된 컴포넌트의 기능적 측면에 초점 : 연결된 컴포넌트의 정상 동작여부 모두 확인

통합 방법

빅뱅 방식 : 전체 컴포넌트를 한 번에 통합

• 장단점 : 그냥 하면돼서 좋음 / 오동작시 결함 위치를 찾기 어려움

점진적 방식 : 적은 수의 컴포넌트를 차례로 통합

• 장단점 : 결함 위치 찾기 쉬움 / 테스트 많이 해야됨 (드라이버 또는 스텁도 필요)
• 상향식 통합 : 클러스터(빌드)에 대한 드라이버 작성해서 테스트.
• 하향식 통합 : 상위모듈부터 만들고 하위 모듈은 스텁으로 대체. 새 모듈 추가시마다 리그레션 테스트.
• 샌드위치 통합 : 상향 하향 섞어서 함

시스템 테스트

통합테스트 완료 후 전체 시스템이 시스템 명세에 부합하는지 검증
기능 충족 여부, 비기능적 요구사항 모두 만족하는지 검증

인수 테스트

실제 사용자의 요구사항을 만족하는지 테스트
결함 검출이 아니라 고객이 시스템을 인수해도 되는지 평가하는 것.

• 유형 : 알파테스트, 베타테스트

유지보수 단계의 리스레션 테스트

유지보수활동에는 필연적으로 소프트웨어 수정 작업 수반 (기능보강 작업이 많아서)

• 결함 수정, 기능 보강, 적응, 예방 작업

새로운 버전에서 이전에 동작하던 기능이 정상적으로 동작하는지 확인 필요

리그레션 테스트 종류

• Retest-all
• 선택적 리그레션 테스트
• 테스트 최소화 : 중복 테스트케이스 제거
• 테스트 우선 순위화
  • 우선순위 효과성 평가 척도 : APFD (Average Percentage of Faults Detected)
    • $1 - \frac{Tf1 + Tf2 + Tf3 + ... Tfm}{mn} + \frac{1}{2n} \times 100$ : 범위 0~100, 높을수록 좋다.

수행 절차

애플리케이션 변경
-> 컴포넌트/통합/시스템 테스트
-> 테스트 유지보수

품질 특성에 따른 테스트 수행

• 기능 적합성 테스트 : 기능 완전, 정확, 적절성.
• 성능 효율성 테스트
  • 요구사항 작성 어려움 --> 시스템 운영 프로파일 필요
  • 성능 테스트 방법 : 벤치마크, 부하 테스팅, 스트레스 테스팅, 스파이크 테스팅, 내구성 테스팅
  • 리틀의 법칙 : 목표 처리량에 요구되는 동시 사용자수 산정
    • Concurrent user = TPS * Request Interval = TPS * (Response Time + Think time)
    • Active user = TPS * Response Time
    • Inactive user = TPS * Think Time
• 호환성 테스트
  • 부특성 : 공존성, 상호운영성 (다른 프로그램이랑 같이 잘 쓸수있냐)
  • LISI 능력 모델 (격리, 불완전, 연결, 기능적, 도메인, 전군적)
• 사용성 테스트
  • KISTI 측정 항목 : 효과성, 효율성, 만족도
  • ISO25010 부특성 : 적합 인식성, 학습 용이성, 운영 용이성, 사용자 오류 방지성, 사용자 인터페이스 심미성, 접근성
  • 사용성 평가 방법 : 휴리스틱 평가, FGI, 인지적 워크쓰루, 설문
• 신뢰성 테스트
  • 부특성 : 성숙성, 가용성, 결함 허용성, 복구성
  • 신뢰성 정량화 : 가용성, MTTF(Mean Time To Failure)
  • 신뢰성 테스트 방법 : 통계적 테스트 (운영프로파일로 테스트 케이스 생성)
• 보안성 테스트
  • 부특성 : 기밀성, 무결성, 부인방지성, 책임성, 인증성
  • 보안성 검증 : 침입 테스트, 정적분석(CWE)
• 유지보수성 테스트
  • 부특성 : A-(모듈성, 분석성, 재사용성, 변경용이성) / B-(테스트 용이성)
  • 시스템 수정 이유 : 기능개선 및 추가, 변경된 환경 적응, 오류 수정, 예상치 못한 장애 예방
  • A의 테스트를 위해 검토하는 것 : 모듈화 정도, 모듈 결합/응집/복잡도
    • fan-in(얼마나 호출당하냐), fan-out(얼마나 호출하냐)
    • LCOM(클래스 내 메소드가 얼마나 연관돼있냐)
  • B의 테스트를 위해 검토하는 것 : 제어/분할/운영/이해 용이성, 관찰 가능성, 단순성, 안정성
• 이식성 테스트
  • 하드웨어, 소프트웨어 환경이 달라도 동등한 서비스를 제공하는지 여부 펴가
  • e.g., 전자정부 서비스 호환성 준수 지침
  • 크로스 브라우징 테스트 자동화 도구 : Selenium Grid, QTP, RFP

기타 테스트 수행

위험 기반 테스트

모든 케이스를 전부 다 테스트 할 수 없으니까 더 중요한것만 테스트 합시다.
근데 테스트 안한것들도 신경을 써줘야되니까, 대충 합의를 보자면
위험성을 평가해서 그 정도가 높은것들을 먼저 합시다. 위험도가 낮은건 일단 뺍시다.

위험 요소 식별

일단 요구사항 명세서, 품질 모델을 바탕으로 테스트가 필요한 모든 피처 나열
시스템 유형에 따라 강조되는 품질요소에 관련된 피처 식별
위험분석이 가능하도록 구체적으로 기술. (발생가능성, 심각성, 긴급성 부여)

위험도 산정

기술적 복잡성, 개발공정에서 제거 될 것 같은지 여부, 기능 사용 빈도 고려.
아래 세 가지를 조합해 종합적인 위험도 산정 가능.
각 항목에 3, 5가지 등급값 부여 (책에서는 1이 가장 위험, 5가 가장 안전)

• 발생가능성
• 심각성
• 긴급성

위험기반테스트 수행

5개 등급값을 갖는 3개의 위험도 평가 항목
-> 5^3 = 125. --> 1(가장위험) ~ 125(가장안전) 범위 가능

1~125 사이를 네 개의 구간으로 나누고, 각 구간별로 적절한 대응.

• 고강도 테스트
• 균형적 테스트
• 부가적 테스트
• 결함 보고

위험기반 테스트 계획

• 테스트 레벨, 유형 결정
• 테스트 대상 선정
• 테스트 범위 설정
• 테스트 전략
  • 고려사항 : 테스트 설계 기법, 테스트 완료 기준, 재테스팅(혹은 리그레션 테스팅)
• 테스트 설계/구현 및 테스트 환경
  • : 피처 구체화, 테스트 전략 구체화, 우선순위 결정, 테스트 환경 요건 및 구축, 테스트 데이터 요건 및 준비
• 테스트 실행 및 결함 보고
  • : 테스트 절차 선택, 결함 기록, 결함 추적
• 테스트 모니터링/제어 및 테스트 종료
  • : 테스트 모니터링 및 테스트 활동 제어, 테스트 종료 보고

생명주기모델에 따른 수행

순차적 개발 모델

• 폭포수 모델
  • 개발 중심 모델
  • 개발자에게 익숙한 요구사항, 요구사항 변경이 빈번하지 않은 경우 적합
  • 결함 있으면 수정비용 매우비쌈. 테스트를 개발 극후반의 한 스텝으로 취급
  • 요구사항, 요구사항 분석, 구조 설계, 상세 설계, 코딩, 테스팅, 운영
• V모델
  • V&V : Verification(검증:명세 만족?), Validation(확인:요구사항 만족?)
  • 테스트를 개발과 동등하게 취급한 모델 (개발과 동시에 테스트 설계)
  • 왼쪽의 개발 관련 단계 (SDLC), 코딩, 오른쪽의 테스트 관련 단계 (STLC)

진화적 개발 모델

이터레이션과 점진적 개발 원칙에 바탕
요구사항 불명확한 경우 적용

이터레이션마다 테스트 수행

• 나선형 모델
  • 초기 요구사항 설정
  • (재)설계, 프로토타입, 테스트 및 고객평가 반복

애자일 개발 보델

애자일 선언의 가치를 추구하기 위해 IDD를 따름
소프트웨어 개발 주기를 여러 개 이터레이션으로 구분
각 이터레이션 = 하나의 소규모 프로젝트나 마찬가지

최종 이터레이션의 산출물 = 릴리즈

애자일의 중요한 실천 규칙 : TDD, CI

대표적인 애자일 방법 : XP(eXtreme Programming)
페어 프로그래밍 : xp의 실현 방안

테스트 자동화

반복업무 감소. 일관성 있고빠른 테스트 수행.
자동화 없이 효과적으로 할 수 없는 테스트 있음 (성능, 부하, 스트레스 테스트)
수동 테스트가 더 효과적일 수도 있음

SEARCH 모델

Setup, Execution, Anylysis, Report, Clean up, Help
각 단계 자동화 -> 효율 높임, 휴먼에러 예방 -> 전문적이고 일관성 있는 테스트 가능

ISO/IEC/IEEE 29119

테스트 프로세스 분류

• 조직 테스트 프로세스
• 테스트 관리 프로세스
• 동적 테스트 프로세스
  • 테스트 설계 및 구현
  • 환경 구축 및 관리
  • 실행
  • 결함 보고

테스트 자동화 도구

동적 테스트 프로세스 각 단계의 도구

• 설계 도구 : 테스트 케이스 생성
  • 명세 기반 테스트 설계 도구 : 명세서
  • 구조 기반 테스트 설계 도구 : 코드
• 테스트 환경 구축 도구
  • IaC (Infra as Code) : e.g., Docker
• 테스트 실행 도구
  • 테스트케이스를 스크립트로 변환하여 실행
  • Record & Playback 방식. (e.g., Katalon Studio)
  • 테스트 실행 프레임워크
    • 선형 : 순차적으로 스크립트 실행
    • 모듈 기반 : 스크립트 모듈화
    • 데이터 주도 : 스크립트와 데이터 분리
    • 키워드 주도 : 테스트와 애플리케이션 결합도 줄임
• 이슈 관리 도구 (버그 추적 도구)
  • 결함 생명 주기 : 신규, 진행, 해결, 완료 상태
  • Redmine, Jira, Mantis, Trac, Yona

테스트 도구 선정

• 프로세스 : 요구사항 정의, 도구 조사, 도구 평가, 파일럿 프로젝트 ,도구 선정 ,도구 구입
• 테스트 피라미드
  • 유지보수 비용, 실행 속도 : UI 테스트 > 통합(API)테스트 > 컴포넌트 테스트
  • ROI : UI테스트 < 통합(API)테스트 < 컴포넌트 테스트

정적 테스트

리뷰

수작업임.

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

• 리뷰 대상 : 프로그램과 모든 산출물
• 왜함? : 리뷰에서 결함 나오면 나중에 다만들고 제거하는 것 보다 비용이 작다.
• 프로세스 : 경영진 준비, 리뷰 계획, 리뷰 절차 개요 설명, 작업물 개요 설명, 개별 준비, 그룹 검토, 재작업, 후속작업

관리 리뷰

목적 : 진행상황 모니터, 현재 상태 평가해서 필요하면 자원, 일정 변경.
주요 대상 : 프로젝트 진행상황 파악할 수 있는 문서

기술 리뷰

• 목적 : 프로젝트의 기술적 상태를 확인
• 의도된 사용에 적합? 계획/법규/표준/명세 지킴? 변경사항 적절하게 반영함? 대안 추천
• 주요 대상 : 보통 개발 문서

인스펙션

가장 형식화됨. 동료검토. (피어리뷰)
비슷한 수준/역할의 사람에게 코드 등 산출물 검토 맡김. 가능한 초기에 검사해야함.
-> 인스펙션 지원 문서 개선 활용

• 인스펙션 참가자 : 주재자(퍼실리테이터), 작성자, 낭독자, 기록자, 검토자
• 과정 : 리뷰 계획, 절차 개요 설명, 작업물 개요 설명, 준비, 검토회의, 재작업, 후속작업

워크쓰루

결함검출, 참가자 교육, 지식공유 목적

작업물을 따라 돌아다니면서 작업물 설명 진행. 검출된 결함에 대한 권고(조치) 사항 기록.
재작업, 후속단계를 통해 모든 조치사항이 해결됐는지 확인해야함.

감사

소프트웨어가 규정, 가이드라인, 계획, 절차, 표준을 잘 지키는지 독립적으로 평가하는 것.
비준수사항 사례 식별->교정활동 요구 보고서 산출

제공자, 소비자, 제3기관에서 요구

• 역할 : 대표 감사자, 감사자, 기록자, 개시자, 피감사조직 대표.

정적 분석

도구로 자동 정적 테스트

코딩 표준(지침) 부합

지가 좋아하는 스타일로 코드 싸지 말고 컨벤션 잘 맞춰서 짭시다. 정신건강에도 좋아요.

• 중괄호 위치에 따른 코딩 스타일 : BSD, K&R, GNU
• 메소드 카멜케이스. 동사(구).
• 변수이름 카멜케이스. 명사. 사용의도 드러내야 함.

// BSD
if () 
{
}

// K&R
if (){
}

// GNU
if ()
  {
  }

코딩 가이드라인 MISRA-C 대표적

• C언어 코딩 가이드라인 : 임베디드 시스템에서 안전, 이식성, 신뢰성 목표
• undefinded behavior : 를 예방하는 내용이 포함돼있음.
  • e.g., 초기화되지 않은 변수 사용, 배열 범위 넘는 인덱스로 배열 참조, 0나눗셈

코드 복잡도 계산 (복잡도 분석)

복잡도가 높은 프로그램 : 신뢰성, 테스트비용, 유지보수성 나쁨.

순환복잡도 : 제어흐름 그래프에서 기본경로의 개수.

• 공식 = E - N + 2
  • = 간선개수 - 노드 개수 + 2
  • = 닫힌 영역의 개수 + 1
  • = 분기 노드들의 개수 + 1
• RIAC의 기준 : 10이하 acceptable, 30 quistionable, 50 cannot be tested, 75 bad fix

자료 흐름 분석

자료 흐름에 이상이 있는지 분석

• d : defined
• k : killed
• u : used
• ~x : 모든 선행행위가 x와 관련 없음
• x~ : 모든 후행 행위가 x와 관련 없음

동적 테스트 : 구조 기반 테스트

제어 흐름 그래프

• 구성 : 기본 블록(노드) + 제어 흐름(간선)
  • 시작노드 : 입력간선 없는 노드
  • 종료노드 : 출력간선 없는 노드

구조기반테스트 이해

이상적인 테스트 : 모든 경로 한 번씩 실행
-> 그러나 그럴 수 없다. 경로가 너무많아.

일부 경로만 테스트.
일부 경로만 선정하는기준 필요.

테스트 수행 방법

경로 선정 기준에 따라 분류함.

문장 테스트

프로그램의 모든 실행가능한 문장(블록)을 최소한 한 번은 실행.

1. 모든 실행가능한 기본블록 지나가는 경로 집합 식별
2. 경로집합에 있는 각 프로그램 경로에 대해, 입력데이터와 기대 출력 식별.

문장 커버리지(%) = 100 X 테스트 케이스 집합에 의해 실행된 문장의 수 / 전체 실행 가능한 문장의 수

결정 테스트

모든 결정문(조건문, 스위치)의 결과가 참, 거짓 각각을 최소한 한 번 실행.

결정 커버리지 = (실행된 결정문 결과 수) / 전체 프로그램 결정문 결과 수

조건 테스트

조건 : AND OR 없는 식
결정 : 조건이 AND OR로 결합된 것

모든 조건이 참 거짓 각각 되는 경우를 최소 한 번씩 실행

조건 커버리지 = 실행된 개별 조건 결과수 / 전체 프로그램 개별 조건 결과 수

결정/조건 테스트

결정테스트, 조건테스트를 모두 만족하는 테스트

결정/조건 커버리지 = 실행된 결정문과 개별 조건 결과수 / 전체 프로그램 결정문과 개별 조건 결과수

다중 조건 테스트

기본 조건들이 가질 수 있는 모든 가능한 조합 한 번씩 검증.

다중 조건 커버리지 = 실행된 조건들의 조합 수 / 전체 프로그램 개별 조건들의 조합 수

• true, false와 false, true는 같음. 조합이니까.
• 그래서 2개 조건의 전체 조합 수는 8개가 아닌 6개

동적 테스트 : 명세 기반 테스트

내부 논리 구조 참고 없이, 명세, 설게정보를 이용해 테스트 케이스 개발
명세정보 알고있으면 적용대상에 제한 없음. 컴포넌트/통합/시스템/인수 테스트 전 과정 가능.

동등 분할

소프트웨어 테스트 근간
테스트케이스 개수 줄이면서 효과적인 테스트 수행

입력 또는 출력 영역을 동등클래스로 분할.
각 클래스에서 하나의 값을 선택 -> 테스트케이스로 이용
-> 테스트 결과 올바르게 동작하면 -> 클래스의 나머지 값에 대해서도 올바르게 동작할것.

주의
동등클래스들의 합집합 = 입력영역 그 자체
동등클래스들은 서로 공통값 없어야 함.

클래스 조합 방법

• one-to-one 동등 분할
• 최소화 동등 분할

경곗값 분석

입력 영역 경계 근처에 있는 값들을 이용하여 테스트 케이스 설계

입력, 출력 영역을 여러 클래스로 분할. (동등분할)
클리스의 경계, 경계 근처에 있는 값들 사용.

• 2-value BVA
• 3-value BVA

조합 테스팅

동등분할, BVA로 분할된걸 조합해서 테스트 케이스 구성

개개의 입력인자 분할 과정 = 인터페이스 기반 IDM

테스트케이스 조합 방법

• each choide : 클래스 각 값 한번씩은 사용
• 페어와이즈 : 두 클래스 간 모든조합
• all combinations : 모든조합
• base choice : (보통) 정상동작하는 케이스 하나 놓고. 한 인자값씩 변경해가면서 테스트케이스 만들기.

결정표 테스팅

결정표(조건/행위 - 규칙)로 테스트케이스설계

상태전이 테스팅

시스템을 상태전이도(STD : State Transition Diagram)로 모델링

• 시스템 외부에서 들어오는 이벤트에 의해 시스템 상태가 어떻게 전이, 반응하는가를 나타내는 명세수단.
• 상태전이도, 전이트리로 테스트케이스 선정.

상태전이테스트 방식

• 상태 테스트 : 모든 상태 최소 한 번씩 방문
• 단일 전이 테스트 : 모든 유효한 전이 최소 한 번씩 방문
• all transitions 테스트 : 모든 전이 최소 한 번씩 방문 (유효하지 않은 전이도 방문)
• 다중 전이 테스트 : STD의 n+1개 전이 시퀀스들을 최소 한 번씩 방문

테스트 프로세스

https://snnchallenge.tistory.com/384