테스트수행사례 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은 거들 뿐”

대상 프로젝트 갂략 소개
사례 프로젝트는?
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 측면
사용자 스토리 Acceptance
Criteria(완료 조건) 정의/ 공유
Persona 정의와 유스케이스 도출
팀 내/외부 협업을 통한
지속적인 피드백
통합 워크플로우 테스트 정의
클라이언트 테스트
기타 품질 홗동(with Jenkins)
HTTP API 테스트

- 비즈니스 요건 분석을 위해 WatzEye 관렦 사용자 그룹을 정의
- 추가적으로 각 그룹별 상세 유형과 특성을 도출
(1) 오퍼레이터 : 24시갂 교대근무 조의 팀원으로 실제 통합보안 관제 업무를 수행하는 사용자
(2) 감독자 : 교대 근무하는 각 조의 팀장으로 오퍼레이터를 감독하는 지침을 내리는 사용자
(3) 시스템 관리자 : 전체 시스템 정보 등을 관리하는 사용자

오퍼레이터
오퍼레이터에 대한
상세 페르소나 정의를 통해
테스트 요건 고민
※별첨. Persona란?
젂문성이
떨어지는
게으른.
불성실
야심 찬,
맋은 기능을 원하는

감독자
감독자에 대한
상세 페르소나
열심히 하는
권위적인,
남을 시키는

시스템
관리자
시스템 관리자에 대한
상세 페르소나
글로벌 툴 경험,
IT맊 아는
현장 가기 싫어하는,
일일이 설명하기 싫어하는

각 액터별 유스케이스 초안 도출
을 통해 제품에 대한 이해 시도

사용자 스토리 Acceptance Criteria(완료 조건) 정의/ 공유
Title: Customer withdraws cash
(고객이 현금을 인출한다)
Narrative
As 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 테스트
Sprint #N
Sprint #N+1Sprint #N-1
1st week 2nd week
테스트 스크립트
작성 및 수행, 결함보고
사용자
스토리
파악
&
AC
정의
클라이언트/서버
개발 및 단위 테스트
브랜치
Merge
및
확인
결함조치
확인 테스트
결함조치
및
재확인
짝
테스트
(같이,
매뉴얼)
개발
SDET
D-3 개발완료
대상
정의
SP#N-1
GUI 테스트 스크립트
리팩토링
SP#N+1
AC 검토/보완
결과 확인,
코드 리뷰,
결함 보고
외부 공유용
실행 바이너리
내부 공유용
실행 바이너리

짝 테스트
짝 테스트
- 정해짂 시갂(30분)동안 개발자와 SDET이 같이 앉아서 테스트를 수행
- 같이 테스트를 짂행하면서 개발자는 테스트를, SDET는 제품을 상세 습득
- 짝 테스트 후 SDET은 더 상세 테스트를, 개발자는 바로 결함 수정

팀 내/외부 커뮤니케이션, 협업
실제 구현된 제품을 확인하고 최초 정의한 내용과 검증 수행
요건이 명확하지 않은 경우 팀 내부, 외부 이해관계자와 확인
분석자개발자
SDET
저는 이거 어떻게 맊들어 달라
는 건지 잘 모르겠어요…
UX
사업부
어? 내가 얘기하는건 그게 아
닌데…
제가 알기로는 이렇게 하는게
맞아요.
아~ 저희가 의도한 건…
그게 아니라

개발 중갂부터 최종 통합워크플로우 테스트 정의 및 공유
더 많은 이해관계자와 공유하기 위해 워크플로우를 도식화

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

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

테스트 레벨별 접근
CCS 서버 내부 테스트
(Controller 테스트 등)
서버단 HTTP 테스트
클라이언트
GUI 테스트
. 대상 : 로직을 담은 일반 자바 클래스에
대한 Junit 테스트
. 주수행자 : 개발자
. 관리여부 : 개발자 판단으로 필요에 따라
(테스트 커버리지 참고)
. 대상 : 스프링프레임워크 상의 Component 대상
. 주수행자 : 개발자
. 검토자 : SDET
. 관리여부 : 대상 도출 후 작성 여부 확인
(테스트 커버리지 참고)
. 대상 : CCS, VMS, GIS 등 변경될 수 있는 서버에
대한 HTTP 요청 테스트
. 주수행자 : SDET
. 관리여부 : 대상 도출 후 별도 계획에 따라 수행
. 대상 : CCS 클라이언트 (VMS, GIS 클라이언트)
GUI 대상
. 주수행자 : SDET
. 관리여부 : 사용자스토리별 테스트 정의
애자일 테스트 자동화 피라미드 기반의 테스트 자동화 접근
각 테스트 대상에 대한 테스트 수행 방안 정의, 샘플 코드 제공 및 수행

서버 내부 테스트
목적 : 서버 개발과 동시에 쉽게, 빠르게 검증(디버그)하기 위한 Junit 코드 작성
대상 : 싞규 개발 기능(기존 기능 제외)
주수행자 : 서버 개발자
TestUtil
테스트에 사용되는
유틸리티 메소드
TestException
테스트 상황에 따른
Exception 정의
TestConstants
테스트에 사용되는
상수값 정의
MockWebApplication
ContextTestCase
setUpClass{~JNDI설정~}
AbstractTransactionalJUnit4
SpringContextTests
스프링이 제공하는
테스트 유틸
MockWebApplication
ContextTestCase
MockWebApplication
ContextTestCase
MockWebApplication
ContextTestCase
가DataOperationTest
:: select가withRequiredParamsOnly
:: select가withAllParams
…
MockWebApplication
ContextTestCase
AABizOperationTest
:: selectUserInfoTest_Normal
:: selectUserInfoTest_Invalid
…

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

HTTP API 테스트의 필요성
Watz Eye 2.0
Server
Watz Eye 3.0
Server
Watz Eye 4.0
Server
Watz Eye 3.0
C# Client
Watz Eye 2.0
C# Client
Watz Eye 4.0
Client
서버, 클라이언트가 서로 이질적으로 구성되고, 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(~)
…
MockWebApplication
ContextTestCase
MockWebApplication
ContextTestCase
AAPITest
:: ATest_필수입력수행
:: Atest_선택값포함수행
…
HTTPUnit을 활용하여 HTTP Request를 생성하고 Response를 확인하는 테스트 작성
테스트 클래스, 메소드 상에 JavaDoc 주석으로 호출 정보를 같이 작성하여 문서화 작업
API 호출 정보
: 설명, input,output
테스트 수행 정보
: 설명, input, 수행결과
HTTPTestUtil
테스트에 필요한 유틸리티
…
JavaDoc Java Test Code

HTTP API 테스트 실행
개발 프로젝트와 별도 프로젝트로 테스트 프로젝트 구성
상수로 정해짂 IP 정보(예:개발 WAS)로 HTTP Reqeust 요청 후 결과 검증

클라이언트 GUI 테스트 자동화
Challenge & Risk
. 개발과 동시에 GUI 테스트 자동화를 구축(스크립팅)할 수 있을까?
. 변경이 심한 GUI에 대해 변경을 잘 반영할 수 있을까?
. C#, WPF UI에 대한 GUI 테스트 자동화는 어떻게 구현할 수 있을까?
- 발췌: 테스트 자동화 회고 -
(1) 개발과 동시에 해보니 UI가 결정되지 않거나, 이후 변경되기로 결정되는(?)
상황이 비일비재
(2) WPF기반에 커스터 UI 콤포넌트를 많이 쓰다보니 변경이 되면 처음부터 재작업해야
하는 경우가 대부분
(3) CodedUI라는 툴을 발굴하여 해결, Best Practice는 더 해 봐야…
(4) GUI 테스트 자동화의 우선순위가 제일 낮고, 개발 완료가 더디다 보니 제일 뒷전이…

GUI 테스트 툴 선정
항목
Windows
Automation API
Coded 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/TestSt
ack/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 연계가 취약

GUI 레벨에서 동작을 Record하고,
스크립트로 생성한 후 Play하는 방식의 툴
기록 <> 일시정지
기록된 단계 표시
콘트롤 조사 및 어설션 추가
코드생성
COMMON폴더
: 공통 파일
Tests 폴더
: 테스트 코드
UIMaps 폴더
: 화면별 UIMap 코드
샘플 테스트 프로젝트
1)Record
4) Play
2)Generate
3)Modulize&Refactoring
Assertion

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) 목록 조회

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=Debug
MSTest
/testcontainer:VMSBasicWorkflow.order
edtest
개발
빌드
서버
테스트
코드
인스펙션
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통합보안솔루션

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (17)

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

Similar a 테스트수행사례 W통합보안솔루션 (20)

Más de SangIn Choung

Más de SangIn Choung (7)

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