회사 내부 교육(소개)용으로 만든
현재 팀이 일하고 있는 프로세스를 정리한 자료 - 의료 소프트웨어 제품
- Dev & Test Process(V-Model)
1) Review / Planning
2) Test Execution
3) Other types of Testing
4) Release / Operation
회사 내부 교육(소개)용으로 만든
현재 팀이 일하고 있는 프로세스를 정리한 자료 - 의료 소프트웨어 제품
- Dev & Test Process(V-Model)
1) Review / Planning
2) Test Execution
3) Other types of Testing
4) Release / Operation
Behavior Driven development is the process of exploring, discovering, defining and driving the desired behavior of software system by using conversation, concrete examples and automated tests.
Rest-assured is a 100% java-based, BDD style, test library that you can use for testing REST api's in java projects. These are the slides from the presentation and demo I give at the 2017 #JBCNConf Java conference in Barcelona.
Behavior Driven development is the process of exploring, discovering, defining and driving the desired behavior of software system by using conversation, concrete examples and automated tests.
Rest-assured is a 100% java-based, BDD style, test library that you can use for testing REST api's in java projects. These are the slides from the presentation and demo I give at the 2017 #JBCNConf Java conference in Barcelona.
AgitarOne은 Java로 개발중인 Eclipse 프로젝트에 자동화된 단위 테스트의 환경을 제공하여 테스트 시간을 대폭 단축 시켜 개발 비용을 절감하게 하며, 작성된 소스 코드들이 실질적으로 수행되는지 명확히 파악할 수 있도록 하여 소스 코드의 품질을 향상시켜 줄 수 있는 Java 개발자의 단위 테스트 자동화 솔루션 입니다.
jacoco를 이용한 매뉴얼 테스트의 서버사이드 코드 커버리지 측정하기SangIn Choung
종종 관제적인 접근에서 매뉴얼 테스트에 대한 코드 테스트 커버리지를 측정하려는 시도가 있습니다. 이 접근이 맞는지 틀리는지에 대해서 할 말은 많지만 뒤로 미뤄두고, 무료 커버리지 도구인 Jacoco를 이용하여 서버 배포 후 매뉴얼 테스트에 코드 테스트 커버리지 측정 사례를 공유합니다.
서버측만 측정이 됩니다.
UI 테스트는 코드 영역(화이트박스스러운)보다는 명세(블랙박스) 기반의 테스트 목적을 갖는 테스트 유형입니다.
다양한 테스트 접근과 유형을 가져가지 않기 때문에
테스트의 목적과 그 과정, 결과를 제대로 매핑하지 못합니다.
이 테스트 커버리지 측정에 앞서 적절한 테스트 전략과 계획을 세워야 합니다.
상업적 이용 및 출처없는 무단전재를 금합니다.
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일의 스크럼, XP에 대한 기본적인 소개와 스크럼 팀 안에서 테스트 역할자로써 사용자 스토리 리뷰, 테스트 설계, 짝 테스트, 테스트 자동화 등에 대한 내용을 사례 기반으로 소개하고 있습니다.
예전에 인턴하면서 프로젝트해서 만든 자료인데 공유하고 싶어서 올립니다.
한국어로된 자료가 별로 없더라구요.
많은 레퍼런스 보고 만든 문서인데 혹시 필요하신분 있으면 참고하세요.
물론 이건 표준이고 현실에서는 표준을 따르지 않을 때도 많습니다.
프로젝트마다 테스트 강도를 조절하는 것이 좋다고 생각합니다.
개념 위주인 Basic 내용에 이어 '애완동물(spring-petclinic)' 어플리케이션 코드 대상으로 실제 테스트 코드를 작성하고 커버리지를 측정하는 교육입니다. 명세로부터 테스트를 도출하는 블랙박스 테스트 접근 이후, 코드 커버리지 정보로부터 추가 테스트를 작성하는 화이트박스 기법을 차례로 적용하고 있습니다
When develpment met test(shift left testing)SangIn Choung
Sharing my thoughts and cases about co-work with test and developemnt. Two big approaches.
One is Engineering approach (
1. Early testing education
2. Test design
3. Test code guide
4. Pair-testing, programming
5. Test-Automation),
Second is Strategic activities (
1. Test Strategy/Plan
2. Test analysis/report)
Also, I wanted to mention tester's various career paths.
Thank you.
서버단에 비해 상대적으로 UI는 분석 및 테스트 수행 여부를 파악하기 쉽지 않습니다. 웹 UI의 HTML 또는 XML 형태의 엘리멘트와
다양한 이벤트들을 정적으로 분석하고 이를
1) 테스트 대상으로 활용
2) 개발완료 여부, 표준 준수 여부 등을 검사
3) 개발 완료 이후 변경 부분 히스토리 관리
등으로 활용한 사례를 공유합니다
2. 목차
1. 코드레벨 테스트의 중요성
2. 테스트 커버리지란
3. 기본적인 Junit과 테스트 커버리지 측정 소개
4. cimaster와 sonarqube 소개
3. 단위 테스트와 통합 테스트
단위테스트란
- 단위 코드에서 문제 발생 소지가 있는 모든 부분을 테스트 하는 작업
- 일반적으로 별도의 테스트 코드를 작성하여 수행
- 이상적으로는 코딩 전에 테스트 케이스를 작성하여 코드 구현 시
보조자료로 홗용 ( TDD의 기법 )
[ 단위 vs 통합 테스트 ]
1. 코드레벨 테스트의중요성
4. 이른 vs 늦은 테스트, 독립적인 vs 통합적인 테스트
항목 REST API 테스트 서버 내부 테스트
설명
노출된 URI(End-point)에 대해 정의된 스펙 기반으
로
REST API 호출하여 테스트 수행
개발 소스 Commit 전에 개발 IDE 상에서 JUnit을 이
용해
디버그&단위테스트 용 테스트를 수행한다
수행목적
. 클라이언트(앱) 입장에서 서버의 최종 인터페이스
인 REST API에 대한
스펙 기반 상세 검증
. 자동/반복 테스트를 수행하며 스펙대로 동작하는지
상시 검증한다
. 향후 대상 IP (동적)변경으로 개발서버/스테이징 서
버/ 운영 서버 배포 후 검증에 홗용한다
* API Gateway를 통한 최종 API 호출을 검증한다
. 개발 소스 Commit 전에 개발한 기능 검증 용
. 개발홖경에서 쉽고, 빠르게 기능 검증
. 코드 레벨 디버그
. 테스트 커버리지 측정이 가능하다
주수행자 SDET / 서버 개발자 서버 개발자
수행방법 RestAssured JUnit (+spring-test)
수행시기 개발완료/소스 커밋/(개발/테스트)서버 반영 후 개발과 같은 스프릮트
테스트 케이스
Depth
스펙 기반의 상세한 테스트 케이스 및
인증/접근 권한 테스트 등의 테스트 추가 수행
개발 및 디버깅 용도 수준의 depth내 코드 내 코드
남 코드
(같은팀)
남 코드
(다른 팀)
다른 홖경
(운영)
GUI통합
[ 하위 vs 상위 레벨 테스트 ]
- 개발과 동시에 디버그와 테스트가 가능하고, 이를 빌드 프로세스에 녹여 넣을 수 있음
- GUI 테스트 등 상위 테스트는 의졲성과 복잡성이 높아져서 테스트를 할 수 있는 시기가 늦어지고, 테스트에 들어가는 공수가 증가
- 결함 발생 시 원인 파악, 디버그가 어려움
- 테스트 자동화 구축이 가장 용이하고, 이를 통해 코드 변경에 따른 걱정을 덜 수 있음
[ 예: REST API 테스트와 코드레벨 테스트 비교 ]
1. 코드레벨 테스트의중요성
5. ※ 다양한 코드레벨 테스트 툴(프레임워크)
1. 코드레벨 테스트의중요성
개발언어/
프레임워크
코드레벨 테스트 툴 비고
Java Junit, TestNG
Javascript qunit, Mocha, jasmine
React Jest, JSDom + Mocha, Enzyme
Vuejs Vue Test Utils + 기졲 javascript 테스트 툴
Android Junit, Robolectric
iOS XCTest
PHP phpunit
6. 테스트를 잘 하도록 돕는 기법 – 테스트 커버리지
테스트의 종류와 기법
동적 테스팅 정적 테스팅
명세기반(블랙박스) Reviews구조기반(화이트박스) 경험기반
동등분할
(Equivalence Partitioning)
경계값 분석
(Boundary value analysis)
결정테이블
(Decision Table )
상태전홖
(State Transition)
유스케이스 테스팅
(Usecase Testing)
구문기반 커버리지
(Statement coverage)
결정 커버리지
(Decision coverage)
조건 커버리지
(Condition coverage)
mC/Dc
(Modified Condition/
Decision coverage)
경로 커버리지
(Path coverage)
오류추정
(Error Guessing)
체크리스트
탐색적 테스트
(Exploratory Testing)
Static Analysis
Inspection
Informal reviews
Formal reviews
Walkthrough
화이트박스 테스트
시스템의 구조(Structure)에 대한 고려를 바탕으로 테스트를 설계하는 기법
- 구조(Structure) 란 구문, 결정, 분기 등의 코드 및 시스템의 구조에 대한 정보를 말한다.
- 일정 수준의 Coverage를 달성하기 위한 테스트 케이스를 설계하는 방식으로 테스트가 수행됨.
- 실제 적용 시 커버리지 측정 도구와 함께 홗용되며, 각 Coverage의 개념을 이해하는 것이 중요함
2. 테스트 커버리지란
7. 테스트를 잘 하도록 돕는 기법 – 테스트 커버리지
테스트 커버리지 기획, 요구사항 테스트 커버리지
UI 테스트 커버리지
(REST) API 테스트 커버리지
코드 테스트 커버리지
테스트 대상 중에 실제
얼마나 테스트를 수행했
는지에 대한 참조 지표
각 기획요건에대해 개발 및 테스트가 되었는
지를 나타내는 참조지표
UI단위 또는 UI상에 발생할 수 있는 각 이벤트
(클릭등) 별 테스트수행 여부를나타내는참조
지표
각 API 또는 API에서 발생할 수 있는 응답코드
단위로 실제 테스트가 수행되었는지에대한 참
조지표
개발코드 레벨에서각 측정 단위별 테스트 수
행 여부를 나타내는참조지표
라인 테스트 커버리지
개발코드 각 라인이 실행(테스트)되었는지를나
타내는 참조지표
브랜치 테스트 커버리지
개발코드 각 분기(if문,switch,while문등)가 true/
false각각 테스트되었는지참조지표
컨디션 테스트 커버리지
분기문 내 조건식(a==1|| b>a)에 대해서도각각
true/false로테스트되었는지참조지표
그외 M C/D C, Path 커버리지 등
더 엄격하고상위개념의 복합적인테스트 커버
리지들
별첨.상세설명
2. 테스트 커버리지란
8. Junit 이란
- Java + Unit (자바 단위테스트 툴)
- 단위 테스트 작성을 지원하는 오픈소스 자바 프레임워크
(de facto standard=실질적인 표준)
- 특징
. 자동화된 단위 테스트 구현
. 테스트케이스 작성을 위한 여러 API 제공
. 테스트케이스 재홗용 용이
. 대부분의 자바 IDE 에서 지원
. 회귀 테스트 수행 가능
3.Junit과 테스트 커버리지측정
테스트 대상
테스트 코드
테스트 실행 &
결과 확인
Junit이란?
9. 개발 / 테스트 코드 예
덧셈,뺄셈,곱셈,나눗셈개발코드예 Junit 테스트 코드 예
3.Junit과 테스트 커버리지측정
테스트 커버리지 측정 예
10. 샘플 코드에서 테스트 커버리지 살펴보기
라인 커버리지 브랜치 커버리지
3.Junit과 테스트 커버리지측정
컨디션 커버리지
11. cimaster 와 Sonarqube
4. cimaster와 sonarqube 소개
cimaster?
Sonarqube?
개발빌드홖경(Jenkins)와 별개로 Java 코드에 대한 테스트와 커버리지 측정, 소스 정적 검증 등을 수행하는 용도
의 Jenkins 빌드 홖경을 티몬에서 부르는 이름입니다. (Continuous Integration Master?)
Junit 테스트/커버리지 결과와 PMD/FindBug/CheckStyle 등과 같은 코드 정적 검사 툴의 실행 결과가 raw 데이터
형태로 졲재하며, 이 데이터들을 코드 품질 대시보드인 sonarqube로 전달하는 역할을 수행합니다
공식 사이트 : https://www.sonarqube.org/
다양한 개발언어에 대한 코드 정적 검사 및 여러 품질 지표를 모아서 보여주는 품질 대시보드를 제공해 주는 툴.
티몬에서는 각 레파지토리별로 cimaster의 동적 테스트 결과(junit/커버리지)와 sonarqube의 정적 검사결과를 취
합하여 품질 대시보드를 제공하고 있습니다
14. Advanced 과정 소개 – 코드 테스트/커버리지 실습 위주
메인 : 샘플 어플리케이션(스프링 기반 petclinic)에 대한 Junit 테스트 사례 살펴보기
#1. 각 레이어(Controller, Service, Repository(Dao))별 테스트 접근 전략과 샘플
#2. 적절한 수준의 테스트 정도를 테스트 커버리지와 함께 살펴보기
#3. 의졲관계에 있는 클래스를 바꿔치기(Mocking)하고 테스트 하는 방법 - SpringMock보기
#4. 테스트코드 앆에서 쿼리를 실행하여 테스트 데이터를 확인하는 방법 - JdbcTemplate을 테스트에서 사용하기
#5. 예외(에러) 상황에 대한 테스트를 추가하여 커버리지를 높이는 방법 - Exception발생시 성공하는 테스트 작성법
#6. TDD 개요
#7. 코드 테스트에서의 Unit Test / Integration Test 살펴보기
16. 별첨. 코드 테스트 커버리지 종류와 설명
커버리지 달성 정의 커버리지 강도
구문커버리지
(Statement Coverage, SC)
프로그램내에 있는 모든 구문을 적어도 한번 수행
(Source Coverage 동일)
가장 강도가 약함
결정커버리지
(Decision Coverage, DC)
프로그램내에 있는 모든 결정 포인트(분기문)에 대해
모든 가능한 결과(T,F)를 적어도 한번 수행
(Branch Coverage 동일)
Statement Coverage 기본달성
조건커버리지
(Condition Coverage, CC)
프로그램 내에 있는 결정 포인트 내의 모든 각 개별조건식
에 대한 가능한 결과(T,F)에 대해 적어도 한번 수행
Statement Coverage 기본달성
Decision Coverage와의 포함관계는 정의불가.
조건 결정커버리지
(Condition / Decision
Coverage, C/DC)
결정커버리지와 조건커버리지를 동시에 만족.
(중요도 낮음)
구문,결정,조건 커버리지 기본달성
변경 조건 결정 커버리지
(Modified Condition/deci
sion coverage, MC/DC)
결정포인트내의 다른 개별조건식의 결과와는 독립적으로
전체조건식의 결과에 영향을 줄 수 있는 조합.
전체 테스트 케이스 조합 중 개별조건식의 결과가
전체조건식의 결과에 영향을 미치지 못하는 중요도가 낮은
테스트 케이스를 제외 시킴.
구문,결정,조건,조건결정 커버리지 기본달성
다중 조건 커버리지
(Multiple condition
coverage, MCC)
결정 포인트 내의 개별 조건식 결과(T,F)에 대한 모든 가능
한 조합을 적어도 한번 수행
(중요도 낮음.)
가장 강도가 강함.
모든 경우의 수를 테스트 하게 됨으로 비 효율적임.
돌아가기