C++ API 디자인 chapter 10. 테스트

Choong 아키텍트를 꿈꾸는 사람들

(http://cafe.naver.com/architect1)

테스트?

• 요구사항에 의해 개발된 산출물이 요구사항과 부합하는지 여부를 검증하는 작업.

요구사항 –설계 – 구현 - 테스트

테스트 코드가 필요한 이유 • 개발 시 발생 되는 문제로 인한 테스트 기간이 줄어듬.

• 기획의 변경

• 늘어나는 기능적인 문제점

• 예상치 못한 환경적 요인

• 결국 품질 저하.

• 개발자에게 자동화된 테스트 코드를 작성할 시간을 보장.

자동화 테스트 프로세스 도입 이유(1) • 자신감 향상 • API가 변경에 대한 자신감을 불러 일으킴. • 복잡한 코드 변경 시 결과 예측.

• 하위 호환성에 대한 확신 • 이전버전의 워크플로와 기능들이 정상적으로 동작하는지 확인.

• 하위 호환성 여부 알림

자동화 테스트 프로세스 도입 이유(2) • 비용절감 • 모든 문제를 초기에 해결 가능.

• 릴리즈 후 버그를 해결하는 비용 (초기 10~25배)

• 유즈 케이스 정립 • 요구사항 기능이 언제 완성되었는지 확인 가능.

• 준수 보장

자동화 테스트 프로세스 문제점 • 너무 많은 테스트 코드 • 테스트 케이스가 증가함에 따라 유지보수도 늘어남. • 코드 수정 시 발생되는 테스트 코드 수정으로 오버헤드 발생.

..하지만 테스트 코드를 수정 하므로 하위호환성에 영향을 미치는지 생각해볼 기회를 제공.

S/W 테스트 분류(1) • 화이트 박스 테스트 • 소스코드 기준으로 테스트.

• 블랙 박스 테스트 • 구현보다는 API명세에 따라 테스트.

• 그레이 박스 테스트 • 화이트박스 + 블랙박스 (구현 로직에 기반)

S/W 테스트 분류(2)

테스트 케이스 1.ID/password 맞으면 로그인 성공 2.ID/password 틀리면 로그인 실패

테스트 시나리오 1.한글 ID는 로그인 경고 및 실패 2.특수문자 포함시 경고 및 실패 3.아이디가 없는 경우 경고 4.비빌번호에 특수문자가 없으면 실패

White box test Black box test

API 테스트 • API는 라이브러리 안에서 정의된 함수를 호출 하는 코드를 통해서 사용가능.

• 사용자 인터페이스를 제공하지 않음.

• 자동화된 테스트를 이용하여 빌드 시 테스트 프로세스를 진행.

• 단위 테스트와 통합테스트의 집중.

비기능적 테스트 요구사항(1) • 테스트 수행

• 최소한의 성능과 메모리 사용에 관한 요구사항 만족 하는지 테스트.

• 부하 테스트 • 과부하를 발생 시켜 처리 할 수 있는지 테스트.

• 확장성 테스트 • 복잡하고 방대한 양의 데이터를 처리 가능한지 테스트.

비기능적 테스트 요구사항(2) • 유지 테스트 • 실행시간을 지속 시켜 테스트

• 보안 테스트 • 민감한 정보의 대한 요구사항을 만족하는지 테스트.

• 동시성 테스트 • Multi thread 기능 테스트

단위 테스트 • 메서드, 클래스를 작은 단위 별로 분리 하여 테스트.

• 테스트 대상이 되는 영역을 실행하기 위해 작성한 코드.

• true, false, return 값을 이용 하여 테스트.

• 화이트 박스 테스트에 속함.

• 코드에 대한 ‘신뢰’

단위 테스트 예제

외부자원에 의존적일 경우(1)

• 고정장치 구성(Fixture setup)

•단위테스트 실행 하기 전에 초기화(setup())

•테스트가 끝나면 구성환경 복귀(teardown())

• 동일한 구성함수들이 다양한 테스트 코드에 재사용가능

외부자원에 의존적일 경우(2) • 스텁(stub), 목(mock) 객체 •테스트에 필요한 의존적인 객체들은 stub이나 mock객체로 만들어 실체 객체 대신 사용.

•외부자원에 연결 하지 않고 테스트 진행.

• stub객체를 생성하는데 지루함.

•다른 단위테스트에서 재사용 불가.

통합 테스트 • 함께 동작하는 컴포넌트간의 상호작용을 측정.

• 단위테스트로는 use case, 요구사항을 충족시키지 못함.

• 클라이언트 관점에서 테스트 시나리오 작성.

• 블랙박스 테스트에 속함

• 개발자나 QA팀이 작업을 진행.

성능 테스트

• 성능의 한계점을 정의해 테스트를 진행.

• 알 수 없는 속도 저하나 메모리 누수 문제를 피하는데 도움.

• 성공과 실패를 경험적으로 판단.

• 부하 테스트도 여기에 속함.

부하 테스트

• 수 많은 동시 접속 사용자의 요청을 처리.

• 사용자 환경에서 벌어지는 행동에 초점.

• 다량의 요청으로 과도한 정보 발생

•자동화 측정 도구 필요

• http://graphs.mozilla.org

좋은 테스트 코드의 특성(1) • 빠르게(Fast) • 단위 테스트는 1초 이내 결과 리턴.

• 안정적으로(Stable) • 독립적이며 일관성.

• 쉽게 이식 가능하게(Portable) •다중 플랫폼을 지원한다면 테스트코드 역시 다양한 플랫폼을 지원.

좋은 테스트 코드의 특성(2) • 높은 수준의 코딩표준(High coding Standards) • 코딩 표준 준수 •테스트 내용 문서 기록 •테스트 코드 리뷰

• 재연 가능한 오류(Reproducible failure) • 문제는 쉽게 재연 가능 해야 한다. • 문제를 찾기 쉽게 로그를 남기자.

표준 QA 기법(1) • Condition testing

• 조건문, 순환문 절 모두 테스트 • Code coverage

• 동치류(Equivalence classes) • 같은 행동이 예상되는 테스트 입력 값 • 입력 값을 1~100까지 받는 경우, -1, 101 값도 추가 테스트

• 경계조건(Boundary conditions) • N이라는 값 테스트 하는 경우 n+1, n-1 같이 근접하는 값 추가 테스트.

표준 QA 기법(2) • Parameter testing • 입력값에 의해 조건 분기 시 모든 조건 입력.

• 회귀 테스트(Regression testing) • 하위 호환성이 가능한지 테스트

• getter/setter pairs • Setter 값 입력 getter로 값 확인.

표준 QA 기법(3)

• 리턴값 확인(return value assertion)

•연산 순서(Operation order)

• 부정 테스트(Negative testing)

•메모리 점유(memory ownership)

• NULL 입력 (NULL input)

테스트의 선택과 집중 • API의 주요기능을 테스트 • 여러 기능과 관련 있는 기능을 테스트 • 리스크가 높은 코드에 집중 • 빈약하게 정의된 설계에 집중 • 고성능, 보안이 염려되는 기능에 집중 • 클라이언트에게 나쁜 영향을 미칠 수 는 기능에 집중. • 먼저 완료 가능한 기능을 테스트

QA 엔지니어 종류

• 소프트웨어 테스트 엔지니어 (STE, Software Test Engineer)

•테스트 소프트웨어 설계 엔지니어 (SDET, Software Design Engineer in TEST)

테스트 주도 개발(TDD)

• Test-Driven Development

• 기능을 구현 하기 전 테스트 코드를 먼저 작성.

•테스트를 통과하기 위해 최소한의 코드를 작성

• 리팩토링, 코드가 간결해짐.

• 작은 단위로 변경사항을 점차 늘려감.

TDD 개발 사이클

TDD 예제

TDD 예제

TDD 예제

TDD 장점

• 하나의 코드를 구현 하기 전에 기능의 대해서 생각 해볼 수 있다.

• 사용자 입장에서 생각 해 볼 수 있다.

• 필요한 코드만 작성한다.

실체 객체를 대신하는 테스트 객체

• Fake object • 기능을 수행 하지만 간단한 코드로 구현된 객체

• Stub object • 미리 준비된 응답을 리턴 하는 객체

• Mock object • 미리 준비된 행동을 수행하는 객체

Private code test

•멤버 함수. Public 한 method를 선언.

• 프렌드 함수를 사용하여 테스트

• 가급적 사용하지 않는 것이 좋다.

Public 멤버함수 예제

생략

Using Assertions

• assert 함수나 매크로를 호출하여 코드 검증

• 표현 값이 true이면 정상. (아무일 없음)

• 표현 값이 false인 경우 적절한 오류 와 실행 중단.

assert 예제

//NULL 인 경우 중단

//debug 빌드 시 assert 활성화

assert 사용시 주의사항

• 일반적인 오류 시 적절한 에러 처리.

• 그 외 프로그래밍 오류 시 assert 사용.

국제화 지원

• 국제화 테스트는 주어진 지역이나 언어를 지원하는지 확인.

• 날짜 형식, 화폐 단위 확인.

테스트 하네스

• 자동화된 테스트를 쉽게 유지하고 실행 하며 결과 리포트를 제공

• CppUnit, Boost Test, Google Test, TUT

코드 커버리지(1) • 테스트 코드 진행 상태

• 함수 커버리지, 라인 커버리지, 문장 커버리지, 기본블록 커버리지, 결정 커버리지, 조건 커버리지

• Bullseye Coverage, Rational PureCoverage, Intel Code-Coverage Tool, Gcov

코드 커버리지(2)

버그 추적 • S/W 버그를 지속적으로 추적해서 정보를 데이터베이스에 저장.

• 사용하기 어려움.

• 이슈 트래커와 다름.(?)

• http://www.bugzilla.org

• JIRA

지속적인 빌드 시스템

• Tinderbox

• parabuild

• TeamCity

• Electric Cloud

참조

• bcho.tistory.com

• http://blog.powerumc.kr