1. C++ API 디자인
chapter 10. 테스트
Choong
아키텍트를 꿈꾸는 사람들
(http://cafe.naver.com/architect1)

2. 테스트?
• 요구사항에 의해 개발된 산출물이 요구사항과
부합하는지 여부를 검증하는 작업.
요구사항 –설계 – 구현 - 테스트

3. 테스트 코드가 필요한 이유
• 개발 시 발생 되는 문제로 인한 테스트 기간이 줄어듬.
• 기획의 변경
• 늘어나는 기능적인 문제점
• 예상치 못한 환경적 요인
• 결국 품질 저하.
• 개발자에게 자동화된 테스트 코드를 작성할 시간을 보장.

4. 자동화 테스트 프로세스 도입 이유(1)
• 자신감 향상
• API가 변경에 대한 자신감을 불러 일으킴.
• 복잡한 코드 변경 시 결과 예측.
• 하위 호환성에 대한 확신
• 이전버전의 워크플로와 기능들이 정상적으로 동작하는지
확인.
• 하위 호환성 여부 알림

5. 자동화 테스트 프로세스 도입 이유(2)
• 비용절감
• 모든 문제를 초기에 해결 가능.
• 릴리즈 후 버그를 해결하는 비용 (초기 10~25배)
• 유즈 케이스 정립
• 요구사항 기능이 언제 완성되었는지 확인 가능.
• 준수 보장

6. 자동화 테스트 프로세스 문제점
• 너무 많은 테스트 코드
• 테스트 케이스가 증가함에 따라 유지보수도 늘어남.
• 코드 수정 시 발생되는 테스트 코드 수정으로 오버헤드
발생.
..하지만 테스트 코드를 수정 하므로 하위호환성에 영
향을 미치는지 생각해볼 기회를 제공.

7. S/W 테스트 분류(1)
• 화이트 박스 테스트
• 소스코드 기준으로 테스트.
• 블랙 박스 테스트
• 구현보다는 API명세에 따라 테스트.
• 그레이 박스 테스트
• 화이트박스 + 블랙박스 (구현 로직에 기반)

8. S/W 테스트 분류(2)
테스트 케이스
1.ID/password 맞으면 로그인 성공
2.ID/password 틀리면 로그인 실패
테스트 시나리오
1.한글 ID는 로그인 경고 및 실패
2.특수문자 포함시 경고 및 실패
3.아이디가 없는 경우 경고
4.비빌번호에 특수문자가 없으면 실패
White box test Black box test

9. API 테스트
• API는 라이브러리 안에서 정의된 함수를 호출
하는 코드를 통해서 사용가능.
• 사용자 인터페이스를 제공하지 않음.
• 자동화된 테스트를 이용하여 빌드 시 테스트 프로
세스를 진행.
• 단위 테스트와 통합테스트의 집중.

10. 비기능적 테스트 요구사항(1)
• 테스트 수행
• 최소한의 성능과 메모리 사용에 관한 요구사항 만족 하는
지 테스트.
• 부하 테스트
• 과부하를 발생 시켜 처리 할 수 있는지 테스트.
• 확장성 테스트
• 복잡하고 방대한 양의 데이터를 처리 가능한지 테스트.

11. 비기능적 테스트 요구사항(2)
• 유지 테스트
• 실행시간을 지속 시켜 테스트
• 보안 테스트
• 민감한 정보의 대한 요구사항을 만족하는지 테스트.
• 동시성 테스트
• Multi thread 기능 테스트

12. 단위 테스트
• 메서드, 클래스를 작은 단위 별로 분리 하여 테스트.
• 테스트 대상이 되는 영역을 실행하기 위해 작성한
코드.
• true, false, return 값을 이용 하여 테스트.
• 화이트 박스 테스트에 속함.
• 코드에 대한 ‘신뢰’

13. 단위 테스트 예제

14. 외부자원에 의존적일 경우(1)
• 고정장치 구성(Fixture setup)
• 단위테스트 실행 하기 전에 초기화(setup())
• 테스트가 끝나면 구성환경 복귀(teardown())
• 동일한 구성함수들이 다양한 테스트 코드에 재사용
가능

15. 외부자원에 의존적일 경우(2)
• 스텁(stub), 목(mock) 객체
• 테스트에 필요한 의존적인 객체들은 stub이나
mock객체로 만들어 실체 객체 대신 사용.
• 외부자원에 연결 하지 않고 테스트 진행.
• stub객체를 생성하는데 지루함.
• 다른 단위테스트에서 재사용 불가.

16. 통합 테스트
• 함께 동작하는 컴포넌트간의 상호작용을 측정.
• 단위테스트로는 use case, 요구사항을 충족시키지 못
함.
• 클라이언트 관점에서 테스트 시나리오 작성.
• 블랙박스 테스트에 속함
• 개발자나 QA팀이 작업을 진행.

17. 성능 테스트
• 성능의 한계점을 정의해 테스트를 진행.
• 알 수 없는 속도 저하나 메모리 누수 문제를 피
하는데 도움.
• 성공과 실패를 경험적으로 판단.
• 부하 테스트도 여기에 속함.

18. 부하 테스트
• 수 많은 동시 접속 사용자의 요청을 처리.
• 사용자 환경에서 벌어지는 행동에 초점.
• 다량의 요청으로 과도한 정보 발생
• 자동화 측정 도구 필요
• http://graphs.mozilla.org

19. 좋은 테스트 코드의 특성(1)
• 빠르게(Fast)
• 단위 테스트는 1초 이내 결과 리턴.
• 안정적으로(Stable)
• 독립적이며 일관성.
• 쉽게 이식 가능하게(Portable)
• 다중 플랫폼을 지원한다면 테스트코드 역시 다양한
플랫폼을 지원.

20. 좋은 테스트 코드의 특성(2)
• 높은 수준의 코딩표준(High coding Standards)
• 코딩 표준 준수
• 테스트 내용 문서 기록
• 테스트 코드 리뷰
• 재연 가능한 오류(Reproducible failure)
• 문제는 쉽게 재연 가능 해야 한다.
• 문제를 찾기 쉽게 로그를 남기자.

21. 표준 QA 기법(1)
• Condition testing
• 조건문, 순환문 절 모두 테스트
• Code coverage
• 동치류(Equivalence classes)
• 같은 행동이 예상되는 테스트 입력 값
• 입력 값을 1~100까지 받는 경우, -1, 101 값도 추가 테스트
• 경계조건(Boundary conditions)
• N이라는 값 테스트 하는 경우 n+1, n-1 같이 근접하는 값 추가 테스
트.

22. 표준 QA 기법(2)
• Parameter testing
• 입력값에 의해 조건 분기 시 모든 조건 입력.
• 회귀 테스트(Regression testing)
• 하위 호환성이 가능한지 테스트
• getter/setter pairs
• Setter 값 입력 getter로 값 확인.

23. 표준 QA 기법(3)
• 리턴값 확인(return value assertion)
• 연산 순서(Operation order)
• 부정 테스트(Negative testing)
• 메모리 점유(memory ownership)
• NULL 입력 (NULL input)

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

25. QA 엔지니어 종류
• 소프트웨어 테스트 엔지니어 (STE,
Software Test Engineer)
• 테스트 소프트웨어 설계 엔지니어 (SDET,
Software Design Engineer in TEST)

26. 테스트 주도 개발(TDD)
• Test-Driven Development
• 기능을 구현 하기 전 테스트 코드를 먼저 작성.
• 테스트를 통과하기 위해 최소한의 코드를 작성
• 리팩토링, 코드가 간결해짐.
• 작은 단위로 변경사항을 점차 늘려감.

27. TDD 개발 사이클

28. TDD 예제

29. TDD 예제

30. TDD 예제

31. TDD 장점
• 하나의 코드를 구현 하기 전에 기능의 대해서
생각 해볼 수 있다.
• 사용자 입장에서 생각 해 볼 수 있다.
• 필요한 코드만 작성한다.

32. 실체 객체를 대신하는 테스트 객체
• Fake object
• 기능을 수행 하지만 간단한 코드로 구현된 객체
• Stub object
• 미리 준비된 응답을 리턴 하는 객체
• Mock object
• 미리 준비된 행동을 수행하는 객체

33. Private code test
• 멤버 함수. Public 한 method를 선언.
• 프렌드 함수를 사용하여 테스트
• 가급적 사용하지 않는 것이 좋다.

34. Public 멤버함수 예제
생략

35. Using Assertions
• assert 함수나 매크로를 호출하여 코드 검증
• 표현 값이 true이면 정상. (아무일 없음)
• 표현 값이 false인 경우 적절한 오류 와 실행
중단.

36. assert 예제
//NULL 인 경우 중단
//debug 빌드 시 assert 활성화

37. assert 사용시 주의사항
• 일반적인 오류 시 적절한 에러 처리.
• 그 외 프로그래밍 오류 시 assert 사용.

38. 국제화 지원
• 국제화 테스트는 주어진 지역이나 언어를 지원
하는지 확인.
• 날짜 형식, 화폐 단위 확인.

39. 테스트 하네스
• 자동화된 테스트를 쉽게 유지하고 실행 하며
결과 리포트를 제공
• CppUnit, Boost Test, Google Test,
TUT

40. 코드 커버리지(1)
• 테스트 코드 진행 상태
• 함수 커버리지, 라인 커버리지, 문장 커버리지, 기본
블록 커버리지, 결정 커버리지, 조건 커버리지
• Bullseye Coverage, Rational
PureCoverage, Intel Code-Coverage Tool,
Gcov

41. 코드 커버리지(2)

42. 버그 추적
• S/W 버그를 지속적으로 추적해서 정보를 데이터베
이스에 저장.
• 사용하기 어려움.
• 이슈 트래커와 다름.(?)
• http://www.bugzilla.org
• JIRA

43. 지속적인 빌드 시스템
• Tinderbox
• parabuild
• TeamCity
• Electric Cloud

44. 참조
• bcho.tistory.com
• http://blog.powerumc.kr