테스트수행사례 W통합보안솔루션

테스트 수행 사례

- W프로젝트

S.D.E.T ?

Software Development Engineer in Test

개발자에 Test맊 붙은 = 테스트 개발자?, 테발자?

이것맊 있으면 개발자를 의미합니다

개발자맊큼의 지식을 갖고 테스트 영역에서 일을 하는,

개발자가 그런 것처럼 개발팀 앆에서 일을 하는,

주로 애자일과 같은 홖경에서 필요로 하는,

SDET의 접근 젂략

- 고객/제품의 가치를 고민하며,

- 팀 앆에서,

- 개발 기갂 내내

- 팀 내부, 외부 이해관계자와

커뮤니케이션하며 브릿지 역할 수행

SDET

테스트 측면 엔지니어링 측면

- 개발단계에 쉽고 빠르게 홗용할 수 있는

테스트 자동화 접근

- 각 레벨 별 테스트 자동화 젂략 수립 및 리딩

단위 테스트

GUI 테스트

API, Component

테스트

매뉴얼테스트

RDMBS

DAO implementations

DAO interfaces

Service implementations

Service interfaces

Controller

REST API

웹 UI모바일 UI

GUI 테스트

단위 테스트

API 테스트

SDET 은 저희 개발팀이

고객이 원하는 제품을,

올바르게 맊들 수 있도록

거들겠습니다

젂하고 싶은 메시지 : “SDET은 거들 뿐”

테스트 수행 사례

- W프로젝트

대상 프로젝트 갂략 소개

사례 프로젝트는? WatzEye 3.0 프로젝트

“WatzEye”?우리의 자체 통합보앆 솔루션,

크게 3개 부분으로 구성

(1) CCS(Command Control System),

(2) VMS(Video Management System),

(3) GIS(geographic information systems)

“3.0”?기존 “1.0”, “2.0”에서 UX/UI적인 요소를 강화하기 위한 “3.0” 수행 프로젝트

개발 목표는?기존대비 직관적인 워크플로우 설계

CCS, VMS, GIS갂의 연동

사용자 친숙한 UI 재정의

사고처리 프로세스 SOP 관리

테스트 목표는?개발 목표에 따라 UX/UI, 연동 워크플로우에 대한 테스트 수행

2주

13개

정규직 7명(SDET 2명), 협력직 9명

약 6개월(2016.09.01~2017.02.28)

대상 프로젝트 갂략 소개

프로젝트 멤버

프로젝트 기갂

Sprint 주기

Sprint 개수

133개총 완료 스토리

315개총 결함

사용자 스토리 개수 기준번다운 차트

젂체 테스트 홗동

Business Value 측면

개발과 테스트의 목표 정의 서버 내부 테스트

Test Engineering 측면

사용자 스토리 AcceptanceCriteria(완료 조건) 정의/ 공유

Persona 정의와 유스케이스 도출

팀 내/외부 협업을 통한지속적인 피드백

통합 워크플로우 테스트 정의

클라이언트 테스트

기타 품질 홗동(with Jenkins)

HTTP API 테스트


- 비즈니스 요건 분석을 위해 WatzEye 관렦 사용자 그룹을 정의

- 추가적으로 각 그룹별 상세 유형과 특성을 도출

(1) 오퍼레이터 : 24시갂 교대근무 조의 팀원으로 실제 통합보안 관제 업무를 수행하는 사용자

(2) 감독자 : 교대 근무하는 각 조의 팀장으로 오퍼레이터를 감독하는 지침을 내리는 사용자

(3) 시스템 관리자 : 전체 시스템 정보 등을 관리하는 사용자


오퍼레이터

오퍼레이터에 대한

상세 페르소나 정의를 통해

테스트 요건 고민

※별첨. Persona란?

젂문성이떨어지는

게으른.불성실

야심 찬,맋은 기능을 원하는


감독자

감독자에 대한

상세 페르소나

열심히 하는

권위적인,남을 시키는


시스템관리자

시스템 관리자에 대한

상세 페르소나

글로벌 툴 경험,IT맊 아는

현장 가기 싫어하는,일일이 설명하기 싫어하는


각 액터별 유스케이스 초안 도출

을 통해 제품에 대한 이해 시도











HTTP API 테스트

사용자 스토리 Acceptance Criteria(완료 조건) 정의/ 공유

Title: Customer withdraws cash(고객이 현금을 인출한다)NarrativeAs a customer(고객으로써)I want to withdraw cash from ATM(나는 현금인출기에서 현금을인출하기를 원한다)So that I don’t have to wait in line at the bank(그래서, 은행에서 줄을 서지 않아도될 수 있도록)

Given the account is in credit,and the card is valid,and the dispenser contains cash

(계좌 및 카드가 정상이고 인출기내부에 현금이 있는 상황에서)

When the customer requests cash(고객이 현금 인출을 요청하면)

Then ensure the account is debited,and ensure cash is dispensed,and ensure the card is returned

(계좌에서 돆이 차감되어야 하고, 현금과 카드가 배출되어야 한다)

대표적인 예사용자 스토리 종료기준

1..n

※ Acceptance Criteria (인수기준, 완료조건): “사용자 스토리가 완료되었다”를 정의할 수 있는 기준 정의: AC를 통해 사용자 스토리를 더 명확히 정의하고, AC를 통해 이해관계자(PO, 개발,테스트, 고객) 갂의 이해 정도를 공유할 수 있다

AC 리뷰를 통한 요건 상세 분석

분석자,UX

개발자

SDET

1) 사용자는 CCTV 영상에 대해 정지, 재시작, 중지 시킬 수있습니다

4)아, 그렇다면 마우스 컨텍스트 메뉴 표시라면 왼쪽 어떤메뉴에서 선택했을 때 표시되나요?

2) 기능은 마우스 컨텍스트 메뉴에 있는 건가요? 아니면 상단 툴바인가요?

3) 한 개 CCTV가 여러 번 중복재생될 수 있는데 그럼, 여러 개가 일시에 정지되나요?

Acceptance Criteria의 단계별 홗용

분석 단계- 기획(분석) 단계에서는 제품의 기능을 모든 이해관계자가 같이 논의

하면서 정의하고 문제의 정의와 해결법을 논의

개발 단계

딜리버리 단계

- 상세 정의가 개발을 가이드하며,

- 각 AC 별 자동화 구축은 개발과 병렬로 짂행되며 젂체 팀원이 자동

화 구현에 같이 동참하고,마지막에 자동화된 테스트가 통과되면서 개발

완료를 정의할 수 있음

- 이 스펙과 자동화는 그대로 데모가 되고,

- 처음에 정의한 스펙이 그대로 제품에 반영되었음을 확인할 수 있음

상세 정의된 AC상세 정의된 AC

분석자,UX

개발자 SDET 운영











HTTP API 테스트

팀 내에서의 협업 워크플로우

스프린트 앆에서 개발과 협업

목 금 월 화 수목 금 월 화 수

HTTP API 테스트

Sprint #N

Sprint #N+1Sprint #N-1

1st week 2nd week

테스트 스크립트작성 및 수행, 결함보고

사용자스토리파악

&AC정의

클라이언트/서버개발 및 단위 테스트

브랜치Merge

및확인

결함조치확인 테스트

결함조치및

재확인

짝테스트(같이, 매뉴얼)

개발

SDET

D-3 개발완료

대상정의

SP#N-1GUI 테스트 스크립트

리팩토링

SP#N+1AC 검토/보완

결과 확인,코드 리뷰,결함 보고

외부 공유용실행 바이너리

내부 공유용실행 바이너리

짝 테스트

짝 테스트

- 정해짂 시갂(30분)동안 개발자와 SDET이 같이 앉아서 테스트를 수행

- 같이 테스트를 짂행하면서 개발자는 테스트를, SDET는 제품을 상세 습득

- 짝 테스트 후 SDET은 더 상세 테스트를, 개발자는 바로 결함 수정

팀 내/외부 커뮤니케이션, 협업

실제 구현된 제품을 확인하고 최초 정의한 내용과 검증 수행

요건이 명확하지 않은 경우 팀 내부, 외부 이해관계자와 확인

분석자개발자

SDET

저는 이거 어떻게 맊들어 달라는 건지 잘 모르겠어요…

UX

사업부

어? 내가 얘기하는건 그게 아닌데…

제가 알기로는 이렇게 하는게맞아요.

아~ 저희가 의도한 건… 그게 아니라











HTTP API 테스트


개발 중갂부터 최종 통합워크플로우 테스트 정의 및 공유

더 많은 이해관계자와 공유하기 위해 워크플로우를 도식화


각 워크플로우에 대한 상세 시나리오 작성 및 테스트 수행


워크플로우 테스트에 필요한 데이터 정의 및 생성











HTTP API 테스트

테스트 레벨별 접근

CCS 서버 내부 테스트(Controller 테스트 등)

서버단 HTTP 테스트

클라이언트GUI 테스트

. 대상 : 로직을 담은 일반 자바 클래스에대한 Junit 테스트. 주수행자 : 개발자. 관리여부 : 개발자 판단으로 필요에 따라(테스트 커버리지 참고)

. 대상 : 스프링프레임워크 상의 Component 대상

. 주수행자 : 개발자

. 검토자 : SDET

. 관리여부 : 대상 도출 후 작성 여부 확인(테스트 커버리지 참고)

. 대상 : CCS, VMS, GIS 등 변경될 수 있는 서버에대한 HTTP 요청 테스트. 주수행자 : SDET. 관리여부 : 대상 도출 후 별도 계획에 따라 수행

. 대상 : CCS 클라이언트 (VMS, GIS 클라이언트) GUI 대상. 주수행자 : SDET. 관리여부 : 사용자스토리별 테스트 정의

애자일 테스트 자동화 피라미드 기반의 테스트 자동화 접근

각 테스트 대상에 대한 테스트 수행 방안 정의, 샘플 코드 제공 및 수행

서버 내부 테스트

목적 : 서버 개발과 동시에 쉽게, 빠르게 검증(디버그)하기 위한 Junit 코드 작성

대상 : 싞규 개발 기능(기존 기능 제외)

주수행자 : 서버 개발자

TestUtil

테스트에 사용되는유틸리티 메소드

TestException

테스트 상황에 따른Exception 정의

TestConstants

테스트에 사용되는상수값 정의

MockWebApplicationContextTestCase

setUpClass{~JNDI설정~}

AbstractTransactionalJUnit4SpringContextTests

스프링이 제공하는테스트 유틸




가DataOperationTest

:: select가withRequiredParamsOnly:: select가withAllParams…


AABizOperationTest

:: selectUserInfoTest_Normal:: selectUserInfoTest_Invalid…

서버 내부 테스트

개발 IDE에서 바로 테스트를 수행하고 수행 결과와 테스트 커버리지 확인이 가능











HTTP API 테스트

HTTP API 테스트의 필요성

Watz Eye 2.0Server

Watz Eye 3.0Server

Watz Eye 4.0Server

Watz Eye 3.0C# Client

Watz Eye 2.0C# Client

Watz Eye 4.0Client

서버, 클라이언트가 서로 이질적으로 구성되고, HTTP API를 통해 인터랙션 됨

각 버전 갂 서버, 클라이언트의 속 앋맹이는 변경될 수 있지만 API 레벨에서는

일관성이 필요

HTTP Request: {url}/XXBiz, Parameter: ..,.,,.,,.,,

HTTP Response:: 200, SUCCESS, Response body is~~

과거 현재 미래

HTTP API 테스트의 구성

SecuDBUtil

DB에 직접 쿼리수행기능 제공

TestException

테스트 상황에 따른Exception 정의

MasterTestData

Static final ADMIN_ID=“administrator”Static final FA_CODE=“FA”Static final USED_CCTV_SEQNO=“125”…

HTTPTestCase

MAPKEY_BIZPROCESSID…:getRequestURL(~)…



AAPITest

:: ATest_필수입력수행:: Atest_선택값포함수행…

HTTPUnit을 활용하여 HTTP Request를 생성하고 Response를 확인하는 테스트 작성

테스트 클래스, 메소드 상에 JavaDoc 주석으로 호출 정보를 같이 작성하여 문서화 작업

API 호출 정보: 설명, input,output

테스트 수행 정보: 설명, input, 수행결과

HTTPTestUtil

테스트에 필요한 유틸리티

…

JavaDoc Java Test Code

HTTP API 테스트 실행

개발 프로젝트와 별도 프로젝트로 테스트 프로젝트 구성

상수로 정해짂 IP 정보(예:개발 WAS)로 HTTP Reqeust 요청 후 결과 검증











HTTP API 테스트

클라이언트 GUI 테스트 자동화

Challenge & Risk

. 개발과 동시에 GUI 테스트 자동화를 구축(스크립팅)할 수 있을까?

. 변경이 심한 GUI에 대해 변경을 잘 반영할 수 있을까?

. C#, WPF UI에 대한 GUI 테스트 자동화는 어떻게 구현할 수 있을까?

- 발췌: 테스트 자동화 회고 -

(1) 개발과 동시에 해보니 UI가 결정되지 않거나, 이후 변경되기로 결정되는(?)

상황이 비일비재

(2) WPF기반에 커스터 UI 콤포넌트를 많이 쓰다보니 변경이 되면 처음부터 재작업해야

하는 경우가 대부분

(3) CodedUI라는 툴을 발굴하여 해결, Best Practice는 더 해 봐야…

(4) GUI 테스트 자동화의 우선순위가 제일 낮고, 개발 완료가 더디다 보니 제일 뒷전이…


GUI 테스트 툴 선정

항목Windows

Automation APICoded UI White Sikuli autoit

설명UI Automation Library, low

-level library

Visual Studio 엔터프라이즈에내장된 UI Automation 기능,

based on the low-level UI Aut

omation library

based on the low-level U

I Automation library,

(https://github.com/TestStack/White)

이미지 인식 기반의범용 GUI 테스트 툴

윈도우 기반 프로그램의오브젝트 인식 기반 GUI 매크로 툴 – WPF 인식이앆 되어 대상 제외

비용 오픈소스(무료)

Visual Studio 2015 Enterpris

e 버전에 포함(기존 VS Ultimate or Premiu

m 에 포함)

Free

(TestStack-Thoughtsworks

)오픈소스(무료) 오픈소스(무료)

대상 WPF WPF, MFC, 웹 등등 WPF applications only anything 윈도우 기반 프로그램

방식라이브러리이고 이 라이브러리를 활용해서 코드전체를 다짜야 함

Record 방식 지원블랙박스 형태로 접근

UI Automation library

를 사용하여 스크립트 작성

이미지 인식 기반으로automates anything you

see on the screen

윈도우 오브젝트 인식 방식

스크립트언어

C# C# whatever.NET language Python

Jenkins

연계-

Jenkins 플러그인인 MSTest

를활용하여 테스트 수행 가능

좌동커맨드 라인 명령어 등으로연계

BDD툴연계

-

.NET 기반의 SpecFlow 연계가가능하기는 함

커맨드라인 레벨에서robot framework과 연계 가능하다고 함

강점라이브러리로무료 사용 가능

해외 레퍼런스 다수 있음MicroSoft가 보장하는 상용툴

무료, 특정 기술이 의존적이지 않고 거의 대부분의 동작 자동화 가능,

위치에 관계없이 이미지만 같으면 인식 가능

약점실제 API 수준으로코딩 작업 필요

유료BDD 연계를 위해서는Wrapper를 이용해서 모듈화해서 호출해야 하는 것으로 보임

이미지 인식을 위해 수행 PC의 해상도 통일이필요,

이미지 변경 시 민식 안됨BDD 연계가 취약

https://github.com/TestStack/White

https://github.com/TestStack/White


GUI 레벨에서 동작을 Record하고,

스크립트로 생성한 후 Play하는 방식의 툴

기록 <> 일시정지

기록된 단계 표시

콘트롤 조사 및 어설션 추가

코드생성

COMMON폴더: 공통 파일

Tests 폴더: 테스트 코드

UIMaps 폴더: 화면별 UIMap 코드

샘플 테스트 프로젝트

1)Record

4) Play

2)Generate

3)Modulize&RefactoringAssertion

GUI 테스트 자동화 동영상 데모

데모 시나리오 갂략 소개

[ 동영상 1 ]

1) WatzEye CCS 로그인(“administrator”)

2) 앋람 발생 (테스트용 임의 HTTP Request 수행)

3) 해당 앋람을 오퍼레이터(“operator”)에게 처리지시

[ 동영상 2 ]

4) WatzEye CCS 로그인(“operator”)

5) 할당 받은 앋람을 접수(Acknowledge)

6) 해당 앋람 대응(Response탭 이동)

7) 정해짂 대응 절차(SOP)에 따라

(1) 각 절차 Complete 처리 후 내용 입력

(2) Add Task

(3) 최종 완료 처리

8) 목록 조회











HTTP API 테스트

Jenkins 기반의 개발 빌드/테스트 자동화

[ 서버 ] [ 클라이언트 ]

CONV_BP 개발빌드소스 Repo :

빌드파일: build_convbp.xml

SECU_PLTFM 개발빌드소스 Repo : 빌드파일: build_secupltfm.xml

SERVER 테스트빌드파일: build_secupltfm.xml>>test

SERVER pmd빌드파일: pmd_secupltfm.xml

HTTP API 테스트소스 Repo: 빌드파일: mvn -verify

클라이언트 소스 빌드소스Repo: 빌드: MSBuild.exe WatzEyeCCS.sln/t:Rebuild /p:Configuration=Release

GUI 테스트 수행MSBuild.exe WatzEyeVMSTest.csproj/t:Rebuild /p:Configuration=DebugMSTest/testcontainer:VMSBasicWorkflow.orderedtest

개발빌드

서버테스트

코드인스펙션

HTTP API 스펙문서생성소스 Repo: 빌드파일: mvn -doc

HTTP API 테스트

C#빌드

클라이언트GUI 테스트


SERVER 테스트빌드파일: build_secupltfm.xml>>test

서버테스트

※ 기존 레거시 코드에 대해서는 테스트 코드 미작성※ 현재 개발 WAS와의 port 충돌로 disable 상태


SERVER pmd빌드파일: pmd_secupltfm.xml

코드인스펙션

※ 위반 건수가 엄청나게 많고기존 레거시 코드에 대한 부분이어서 별도 가이드는 미수행


HTTP API 테스트

빌드파일: mvn -verify

HTTP API 스펙문서생성

빌드파일: mvn -doc

개발 빌드 / 테스트 자동화 이슈 히스토리

API 테스트 결함



클라이어트 빌드 실패

GUI 테스트 결함

클라이어트 빌드 실패



수행 회고

1) SDET 인력 갂 테스트 자동화 회고

영역 A B

GUI 테스트자동화

. WPF, C#에서 GUI 테스트 자동화(CodedUI 툴)를 경험할수 있었고, 툴 가이드 문서도 유용했다. GUI 테스트 자동화가 SDET업무에서 우선순위가 낮았고, UI 확정도 늦고, 변경도 심해서 개발 과정에는 거의 수행하지 못했다.. WPF에 더해 커스텀 UI를 많이 쓰면서 레코딩된 스크립트가 쓰레기였다.

. 관심있었던 GUI 테스트 자동화를 경험할 수 있었다

. CodedUI 툴이 사용하기에 제약사항(콘트롤이 안잡히는 등)이 많았다. 미리 자동화할 부분에 대해 개발자와 협의가 되지않아(오토메이션아이디 설정과 같은) 시갂 소모가 컸다(코드 분석 및 직접 설정)

HTTP API테스트

- 단기갂에 수행했음에도 개발 기갂 디버그용, 서버 정상동작 확인용으로 잘 활용했다- 쉽게 실행하고 결과를 확인할 수 있었다- 전체 API에 대해서는 수행하지 않았다 (insert, update, delete 기능들, SOP쪽 기능들)- 그때그때 싞규 API가 추가되다 보니 테스트 수행이 약갂씩 늦었다

-

서버 테스트자동화

- 별도 WAS 를 띄울 필요 없이 확인 가능했다- 초기 Pilot 코드(Service 대상) 대싞 Controller 대상 테스트로 변경해서 테스트 커버 범위를 넓혔다- 스프링 설정 파일 로딩이 너무 무거워서 테스트할 때마다 로딩 시갂이 너무 길었다- 스프링 설정 부분이 일반 프로젝트에 비해 너무 복잡하고 이해가 안 되는 부분이 있어 많이 헤맸다- 프로젝트 말미에 테스트 코드 유지 공수가 커서 버려졌다

-

(좋았던 점)(나빴던 점)

수행 회고

2) 클라이언트 개발자 회고(좋았던 점)(나빴던 점)

구분 가 업무 나 업무

AC 정의 및사젂 리뷰,

(A)AC리뷰를 통해서 개발 젂에 무엇을 할지 2중으로 자세히 체크해서 좋았다.(B) 나는 AC회의를 참석 앆 해서 시갂 젃이 맋이됐다-업무 리더가 다시 정리해서 공유해 줬다

(가)개발 젂에 AC를 통해서 공유하고 의사소통할 수 있었다(마) AC 회의를 참석할 수 있어서 좋았다. 적힌 내용 외에도 궁금한 내용을 다이렉트로 묻고 확인했다

(A)업무리더로 AC리뷰를 하기는 했는데 나중에 보니 놓친게 있거나 원래 의도가 잘 젂달 앆 된 부분이 있었다

(가)AC공유가 스프린트 첫째날이 아니어서 좀 늦었다

짝 테스트

(A) 짝테스트를 하고 싶었는데 맋이 못했다 (마) 테스트하는 사람맊큼 다른 이해관계자들도 제품이나 개발 상황에 대해 깊게 봐줬으면 좋겠다(사)짝 테스트를 맋이 못했다

테스트 수행,결함관리(MyTask)

(A) 테스트를 통해서 내가 체크 앆 했던 부분도 체크 됨(C) 테스트 잘 찍어서 해주어서 도움이 맋이 되었다

(가)업무 역할자 별로 서로 말이 잘 통해서 좋았다(마)테스트 수행 시 SDET이 다른 역할자갂 조율이 좋았다. 노련미가 돋보였다

(A) UI감수 내용과 겹치는 결함이 너무 맋았다/ SDET이 빌드를 해서 개발자의 일을 덜어줬으면 좋겠다(B) MyTask 사용법을 잘 모르겠다. 젂체 프로세스도 잘 파악 못함. (C) UI감수와 겹치는 결함이 맋았다SDET이 UX와 먼저 검토 후 짂행했으면 좋겠다

(마) 지나고 난 다음에 기능 변경이 맋기도 했고, 프로젝트 말미에 다른 기술을 검토하는 과정에서 되던 기능이 앆 되어 앆타까웠다(사) MyTask 에 Resolve 넘기는 시점과 바이너리 넘기는 시점이 앆 맞았는데, 이에 대해 SDET이 사젂 설명없이 퇴짜를 놓아 서운했다(사젂 교육 때 설명 앆 해 줬음)

감사합니다

테스트수행사례 W통합보안솔루션

Software

Transcript of 테스트수행사례 W통합보안솔루션