아꿈사.C++ api 디자인.20140315 a
1 like1,587 views
C++ API 가이드 chap.10 테스트 아꿈사 오후반 스터디 발표 자료
아꿈사.C++ api 디자인.20140315 a
- 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를 선언. • 프렌드 함수를 사용하여 테스트 • 가급적 사용하지 않는 것이 좋다.
- 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