nhn 테스트고도화 팀 - NTS

mongoDB : jmeter 2.11

hadoop : 플러그인 추가

plugin 구조로 되어 있어 확장 가능 —> 가장 좋음

tomcat 7, 8에서 websocket 프로토콜 지원 가능

http recording이 가능

브라우저의 프록시 서버 설정을 통해서

ui 테스트 가능

jenkins와 jmeter 연동이 가능?

성능테스트자동화

jenkins 와 grinder 연동 가능?

응답시간을 서버 time과 network time으로 나눌수있다

latency time —> 첫번째 버퍼가 왔을때 

나머지 두번째 부터 마지막 까지 왔을때를 네트워크 타입

소프트웨어 품질 

크게 2가지 : Functional (소프트웨어가 무슨 what 동작을 하느냐) / nonFunctional (어떻게 how 동작을 하느냐)

non functional : 코드 품질 관리로 가능

품질 관리 하면 생각나는 것은 : 가장 많이 하는것은 코드리뷰 

코드 품질 관리는 개발자 부터 시작하는것이 맞다 

현재 코드리뷰의 목적을 잘 달성하고 있는가? 

코드리뷰는 바로바로 해야 하는데.. 현실에서는 쉽지 않다

이유는 리뷰할 시간이 없다  리뷰하는 사람이 해주겠지라고 생각함

잘 돌아가면 그냥 릴리즈해

왜 이렇게 제대로 되지 않는가? 

눈에 보이지 않는 코드 품질을 보여줘야 한다.

그럼 실제로 눈으로 보이지 않는 코드를 그럼 관리해보자 그리고 품질을 높혀보자

그 툴로 대표적으로 sonarqube가 있는데…

기존의 정적분석 도구는 시간에 따른 버그의 추이 여러 프로젝트의 결과의 비교를 보여주지 못한다. 단발성으로만 결과를 보여주는데 이것은 플랫폼 즉, 결과 관리, 추적, 비교 등등이 가능하기때문에 플랫폼이라고 부를수있다. 

소나큐브는 프로파일을 통해서 일관된 품질 관리 가능

기준에 만족하지 못하면 그에대한 노티 및 다시 개발을 요청 등이 가능 : Quality gate

개발 언어의 장벽을 많이 해결해줌

소나큐브가 코드 품질을 관리하는 기준으로 7가지가 있다

이런 요소들을 각 소스파일이나 프로젝트에 퀄리티 프로파일이라는 룰 셋을 만들어서 적용할수있다.

쿼트 gate를 통해서 품질 관리 종료등을 관리할수있다.

find bug 등의 결과와 같은 결과를 얻을수있음 (같은 소스로 구현됨)

플러그인을 통한 기능 확장 가능

metrics : 품질결과를 수치적으로 관리

developer tools : 플러그인을 개발할수있는

gevernance

languages : 한국어는 없음

localization : 

visualization / reportin :  품질 결과 시각화

developer’s seven deadly sins: 7가지 실수 항목에 맵핑시켜서 관리

1. 적절하지 않은 아키텍처ㅗ아 설계 

코드 복잡도를 계산하는 매트릭스중 하나 : cyclometric complicity

2. 중복코드 관리 

3. 단위테스트 : tdd 개념 테스트 코드를 먼저 만들어야 한다…는 생각에서 관리

4. 코드 복잡도 관리 : 

5.  잠재적인 발생 가능성 있는 버그 : 코딩 룰 

드릴 다운 피처 : 파일 단위단위에 대한 검증 가능 

공수산정 : 코드 품질을 상향시키는데 걸리는 공수 계싼가능 커스터마이징 가능

6. 널리 알려진 코딩 표준 : 25 개 정도의 툴과 연동이 가능

7. 주석 관리 : public class에 대한 주석 관리

코드 품질의 위의 7가지 항목으로 봐야 한다. 

더 집중화된 품질을 관리하기 위해서는 

품질 프로파일

한줄 하줄이 코딩 룰 —> 각 프로젝트에 맞게 잘 조합해서 사용가능 

프로파일이라고 하는 룰 셋을 만듬

threadhold 값을 가지고 통화했는지 종료 여부 판단가능

현재 좋은 상태로 가는지 나쁜상태로 가는지 확인가능 : 트렌드 정보를 통해

지금부터는 소나큐브를 실제로 돌려보자

ci로 사용되는 jenkins 와 어떻게 통합되는지

먼저 소스 

jenkins를 통해서 코드 빌드시 소나를 통해 코드 리뷰

빌드시작 —> 단위테스트 후 빌드시 소나큐브를 부름 —> 빌드 하면서 바로 코드 품질 확인 —>   그 결과는 소나 서버에 떨어짐 —> 정적분석이 완료되면 빌드 성공

코드 프로파일 = 룰 

심각도도 조정가능 

설명 및 해당 룰을 위반하지 않게 하려면 어떻게 코드를 작성해야 하는지 가이드

플러그인 센터를 통해서 플러그인 관리 추가 가능

중점 : 지속적인 통합환경 활용 /  drill-dow 

상용도구와 오픈소스 도구 

Fauls positive/ nagative

정적분석 프로세스의 어려움 

—> 개잘자의 능력을 판단하는 문화는 피해야 함

—> 사람이 항상 개입해야 한다.

누가 : 자동화 툴이 

언제 : 업무시간 또는 업무시간 외에

어디서 : 어디서든

무엇을 : 반복되는 테스트 케이스에 대해서 

왜 : 효율화를 위해 (시간, 인력) 

어떻게 : 자동화 툴이 알아서 

무엇을 얻을수 있을까?

모바일 환경에서...테스트 자동화의 필요성 --> ???

  --> 누가 언제 어디서 왜 

그렇다면 어떻게 우리가 업무 효율성을 높일수있을까 

모바일 환경에서 테스트 자동화에 대해서 

시현 또는 그림을 통해 전체 자동화 테스트 Flow를 전달한다.

이것을 도와주는 솔루션으로 Appium이 있음 (이외에도 ....가 있음)

 이때 어려운 용어들이 나타남

      - webdriver

      - selenium

      - webdriver json wire protocol

      - Uiautomator

     일단 이런것은 차차 알아가면 될것이고 이 발표에서는 각각의 개념은 넘어가겠음

appium이란 무엇인가 --> 테스트 환경을 그림으로 표현하여 Appium의 기능을 한눈에 전달

전체 동작 방식을 그림으로 표현

이것을 사용하기 위해서 우리가 해야할일

  - 테스트 환경 만들기 --> 이것이 제일 어려우며 오래 걸림 (follow를 해준것임) --> 교육 시간 마련 

  - Java에 대한 언어 익숙해지기 ---> 스크립트 작성을 위한 교육시간 마련 

    --> xpath에 대해서 익숙해지기? xpath를 꼭 사용해야 하나

  - 모바일 장비에 대한 기술적 개념 익히기 

샘플 앱을 사용하여 보여줌

이후 계획

  - 중요 앱에 대해서 확장할 계획

  - 효율적인 스크립트 작성을 위해 API를 제공할 것임

    - 공용스크립트 (로그인 등) 생성

  - 스크립트를 유지 보수 with git or svn

  - CI 연동

  - 화면 캡처 및 리포트

  - 원격관리, 다수모바일 지원

테스트 자동화의 가장 큰 난관

- 스크립트 작성에 걸리는 시간

- 스크립트에 대한 잦은 유지보수

- 자동화 툴에서 지원되지 않는 역영은 테스트에서 제외

- 스크립트의 유통기한이 짧다

  --> 잘 돌아가다가 예외 경우 잘 안돌아가는 경우가 있음 

       스크립트를 만들면서 계속 수정이 필요할수있음 그래서 안정화 단계가 필요함 

스크립트 작성 방법

1. class 매칭 방법 

2. Text  매칭 방법 --> xpath를 알아야 함

3. HTML 태크 방법 x

(나중에) 스크립트 작성 도구 생성  

테스트 케이스(TC) --> 자동화 스크립트로 자동으로 transfomation

액션(동사), 대상(목적어)

이미지 클릭은 어떻게? --> tolerance값을 사용해서 색을 통해 이미지를 찾음 --> 후보군이 많이 나옴 --> ㅇ  

guitar는 모바일에서 어떻게 테스트를 수행하는가

Emulator (AVD) 를 컨트롤

VNC 를 통해서 (원격기능) 

VNC 서버를 모바일 장비에 설치

코드 커버리지는 소프트웨어 테스트 시 사용되는 측정 기준 중의 하나

소스코드가 테스트된 정도를 의미함

당연히, 소스코드 내부를 들여다 봐야 하므로, 화이트박스 테스트에 속한다.

코드 커버리지 기준은 다음과 같이 7개 기준이 있다

특정 테스트케이스를 어느기준을 적용하여 테스트하느냐에 따라 커버리지 비율이 틀려지게 된다.

Function coverage : 소프트웨어 내에 정의된 Function이 호출되는 정도

Statement coverage : 소프트웨어 내에 정의된 Statement 가 호출되는 정도

Decision coverage : 소프트웨어 내에 정의된 조건문이 참/거짓 모두 수행되는 정도

Condition coverage (or Predicate coverage) : 소프트웨어 내에 기술된 조건문에서 사용되는 개별 조건이 참/거짓  모두 수행되는 정도

Modified Condition / Decision Coverage (MC/DC) : 소프트웨어 내에 기술된 조건문에 참/거짓이 되기 위한 조건들의 가능한 조합 모두가 수행되는 정도

Path coverage

Entry / Exit coverage

문제는 어느 기준을 적용하여 코드 커버리지분석을 하느냐 인데,

이는 해당 소프트웨어의 중요성 및 수행비용에 따라 결정됨

당연히, 더 상세한 커버리지 분석을 위해서는 더 많은 테스트케이스가 필요하게 되며

이는 비용과 직결되게 된다.

따라서 어느 수준까지 커버리지 분석을 수행할지는 프로젝트 별로 비용 및 중요성을 판단하여 조기에 결정하여 수행하면 된다.