블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

Bazel 빌드툴


Tensorflow Serving을 살펴보다보니, Serving Server는 C++기반에 gRPC 인터페이스 기반이라는 것을 알았는데,

빌드 환경이 bazel이라는 것을 사용한다. 그래서 Bazel이 무엇인가 찾아봤는데. 쉽게 말하면 빌드 툴이다





위키에 설명이 가장 잘나와 있는데, 구글에서 만든 빌드 시스템으로, 구글의 경우 큰 소스코드를 빌드하기 때문에, 이를 위해서 만들어진 빌드 시스템을 오픈소스화 한것으로, 분산 빌드등을 제공하고 빠른 성능을 제공한다.


쉽게 말해서 make,ant,gradle,maven과 같은 빌드 시스템으로 보면 된다.

Java,C,C++,Python,Object C등의 언어를 지원한다.


https://en.wikipedia.org/wiki/Bazel_(software)

In software developmentBazel is an open source tool that allows for the automation of building and testing of software.[2] The company Google uses the build tool Blaze internally[3] and released and open-sourced part of the Blaze tool as Bazel, named as an anagram of Blaze.[4] Bazel was first released in March 2015 and achieved beta status by September 2015.[5]

Similar to build tools like MakeApache Ant, or Apache Maven,[2][4] Bazel builds software applications from source code using a set of rules. Rules and macros are created in the Skylark language, a subset of Python.[4] There are built-in rules for building software written in the programming languages of JavaCC++PythonObjective-C and Bourne shell scripts.[4][5] Bazel can produce software application packages suitable for deployment for the Android and iOS operating systems.[6]

In designing Bazel, emphasis has been placed on build speed, correctness, and reproducibility.[2][4] The tools uses parallelization to speed up parts of the build process.[4] It includes a Bazel Query language that can be used to analyze build dependencies in complex build graphs.[4]


아무래도 개발 환경 설정이 쉽지 않은 만큼, Bazel C++ 빌드 환경이 패키징된 도커 환경을 알아보는것이 더 좋겠다.

TestLink를 이용한 Test Case 관리

조대협 (http://bcho.tistory.com)


테스트 케이스가 어떻게 요구 사항에 맵핑이 되는지, 테스트 케이스의 시나리오는 어떻게 되고 요구 되는 결과 (Expected Result)는 어떻게 되는지, 테스트 결과는 어떻게 되는지, 그리고 Version 별 릴리즈에 따른 테스트 계획과 결과는 어떻게 되는지를 관리할 수 있는 도구가 필요하다.

 대부분 테스트 엔지니어나 개발팀들이 위의 테스트 도구 자체에는 관심이 많은 것 처럼 보이지만, 정작 테스트 프로세스나 테스트 케이스 전체를 관리하기 위한 관리도구에는 그다지 집중하지 않는 것 처럼 보인다. 테스트 케이스 자체를 구현하는 것도 중요하지만, 전체 시스템에 대해 어떻게 테스트를 하고, 테스트에 대한 내용을 어떻게 관리할 것인가도 상당히 중요한 일이라고 본다.

그렇다고 거창하고 복잡한 프로세스가 필요하다는 이야기가 아니라 최소한의 테스트 조직에서 테스트 케이스에 대한 관리를 할 수 있는 툴이 필요하다는 것이다.

조금 쉽게 설명하면 테스트 케이스를 액셀로 만들어서 그 액셀 문서를 여러 사람이 나눠서 테스트를 진행하고 결과를 기입하던 절차를 자동화 했다고 생각하면 된다.

Test Link

오픈소스 도구중에서 널리 사용되고, Learning Curve가 낮은 도구중의 하나가 TestLink 라는 도구이다. http://testlink.org/

먼저 TestLink에서 사용되는 개념에 대해서 먼저 알아보자



Test Project

테스트 프로젝트는 테스트를 수행하는 프로젝트 자체를 이야기 한다. 블로그 서비스를 만들었을때 블로그 서비스 프로젝트”; 와 같은 단일 테스트 프로젝트로도 만들 수 있고, 내지는 블로그 서비스 모바일 클라이언트 테스트”, “블로그 서비스 웹 서비스 테스트와 같이 하나의 서비스에 대해서도 특성에 따라서 여러가지 프로젝트로 분할해서 테스트를 진행할 수 있다. 분할의 기준은 자유롭지만, 테스트 팀 단위로 분할 하는 것이 관리에 용이하다. (클라이언트 테스트 팀, 웹 테스트 팀 또는 미국 테스트 팀, 한국 테스트팀 등)

Test Specification

Test Spec은 테스트를 진행하고자 하는 테스트 케이스들의 집합이다.

Test Spec Test Suite, Test Case로 나뉘어져 있는데, Test Suite은 대분류, Teste Suite의 소분류의 테스트 케이스라고 보면 된다.

흥미로운 점중의 하나는 TestLink에서는 이 Test Case에 대한 버전 관리가 가능하다는 것이다. 예를 들어, “로그인이라는 Test Case, 예전에는 Facebook 계정을 이용한 로그인만을 테스트하는 케이스였는데, 향후에, 케이스가 추가 되서, Google 계정 로그인도 지원한다면, Test Case의 버전을 새로운 버전으로 정의할 수 있다.

Test Plan

테스트 플랜은 실제 진행하는 테스트를 의미한다. Test Project내에서, 테스트 대상 시스템의 특정 버전을 테스트 하기 위해서 Test Spec내의 Test Suite/Case를 모아 놓은 것을 Test Plan이라고 한다. Test Spec이 전체 테스트 케이스의 집합이라면, Test Plan에서는 실제로 이번에 테스트 할 Test Suite/Case들을 모아 놓은 subset이다. Test Plan Test Case를 맵핑할때, 실제 어느 Test Engineer가 테스트를 진행할지 Test Engineer assign할 수 있다.

Test Execution

Test Plan을 세웠으면, 실제로 각 Test Engineer가 자기에게 할당된 테스트를 수행하고, 테스트 결과 Pass/Fail 여부를 체크한다. 만약에 실패한 케이스일 경우에는 재 테스트를 하는데, 그 간 Minor Release가 되었을 경우에는 Minor Release 버전으로 테스트를 다시 해서 Pass 여부를 결정한다.

Test Report

마지막으로, 테스트 결과를 리포팅한다. 테스트 실패,성공 여부, 주요 Test Category (TestSuite)별 성공 실패 여부등을 리포팅 한다.

Test Link 사용 예제

그러면 이 흐름에 따라서 Test Link에서 실제로 어떻게 Test를 수행하는지를 알아보자. 먼저 TestLink를 인스톨하고

1.     Test Project 생성

먼저 Create New Project에서 테스트 프로젝트를 생성한다.

프로젝트 명과, 테스트 케이스에 적용할 prefix를 정의한다.



몇가지 옵션들이 있는데, TestLink BugZilla,Mantis,JIRA와 같은 버그 트랙킹 도구와 연동이 가능하다. “Issue Track Integration”을 선택하면, 버그 트랙킹도구를 연결할 수 있다. (별도의 Configuration이 필요하다.)

          • Ÿ   - Enable Requirement Feature : Requirement TestLink에 정의해서, Requirement à Test Case까지의 추적성을 부여할 수 있다.

          • Ÿ   - Enable Testing Priority : Test Case에 가중치를 부여할 수 있다.

          • Ÿ   - Enable Test Automation : 수동으로 테스트 하는 것이 아니라, Test Case SOAP UI Selenium과 같은 다른 테스트 도구를 연동하도록 설정할 수 있다. 

자 이제 테스트 프로젝트가 위의 그림처럼 생성되었다.


2.     Test Spec 작성

상단 메뉴에서 “Test Specification” 이라는 곳으로 들어가면 Test Suite/Case를 정의할 수 있다. 해당 메뉴로 들어가면 Test Suite/Case를 넣을 수 있는 화면이 나온다. 여기서 좌측 아래에 있는 트리를 선택한 후 오른쪽 버튼을 눌러서 Test Suite을 생성한다. Test Suite 이름과 간단하게, Test Suite에 대한 내용을 “Detail” 부분에 기술한다. 본인의 경우에는 이 Test Suite Scrum Epic 1:1 맵핑을 시키고, Epic에 있는 Description을 그대로 사용한다.

Test Suite Test Case의 집합으로, Test Case에 대한 대분류 정도로 생각하면 되고, 생성된 Test Suite들은 아래 그림과 같이 폴더 형태로 생성된다.


다음으로, 생성된 TestSuite (폴더)에서 오른쪽 버튼을 눌러서 Test Case를 생성한다.



Test Case는 개개별 테스트 시나리오로, 먼저 Summary 부분에 어떤 내용을 테스트 하는지 기술 하고, PreCondition을 입력한다. 예를 들어 Facebook 계정을 이용해서 로그인하는 시나리오를 테스트 한다면, Precondition사용자는 Facebook 계정을 가지고 있어야 한다.” 로 정의할 수 있다.

다음으로 구체적인 테스트 절차를 입력한다.

Step을 입력하는 버튼을 누르면, 아래와 같이 Step을 입력할 수 있는 부분이 나온다. 쉽게 이야기해서 테스트 절차가 된다. 각 단계별로 필요한 Action“Step actions”에 적어놓고, 우측에는 “Expected results”에 정상적으로 Action을 수행했을때 기대되는 결과를 기록한다.


위와 같이 Step by Step으로 action을 정의할 수 도 있지만 굳이 필요하지 않다면,아래 그립과 같이 하나의 action안에 전체 Step을 기술할 수 도 있다.



여기 까지 진행하면, Test Project Test 시나리오를 담은 Test Specification이 모두 완성되었다.


3.     Test Plan 작성

이제 실제로 테스트를 진행하기 위해서 Test Plan을 작성해보자. Home 메뉴에서 Test Plan Management를 선택한후에, 아래와 같이 Test Plan을 생성한다.



4.     Build Version 생성

다음으로 Test Plan내에서 사용할 Build Version을 정의한다.



처음에는 1.0과 같은 Major 버전을 정의하고, 개발팀에서 Minor 버전을 Release할때 마다 1.1, 1.2 식으로 Minor Version도 같이 생성한다. 그리고 각 버전에는 아래 그림과 같이 Release date를 선택해놓으면 관리하기가 편리하다.



5.     Test Suite/Case Test Plan Assign

이제 Test Plan Test Specification에 정의된 Test Case들을 맵핑해보자 메인화면에서 Test Plan Contents 라는 메뉴에서 “Add Remove Test Cases”를 선택한다.

아래와 같이 Test Case를 선택할 수 있는 창이 나오는데, 좌측 아래에서 Test Case를 골라서, 우측 상단에서 처럼 Test Engineer Test Taget Version을 선택한 후에, “Add Selected”를 선택하여, 테스트 케이스를 Test Engineer에게 할당한다.



이제 테스트 수행을 위한 준비가 다 되었다. 개별 Test Engineer에게 상세한 Test Scenario들이 모두 배정 되었다.


6.     Test Execution

이제 테스트를 수행하는데, Test Engineer들은 할당된 Test Spec Step action에 따라서 테스트를 수행하고, 성공/실패 여부를 아래 그림과 같이 선택한다.


위의 그림은 테스트가 성공했을때의 케이스이다. 만약에 Test가 실패하면, Failed라고 나타나는데, 이때 BUG management의 벌레 모양 버튼을 누르면 아래와 같이 버그 트랙킹 시스템에 등록된 버그 번호를 입력할 수 있다.



이렇게 버그 번호를 입력하면, Relevant bugs에 해당 버그에 대한 링크가 생성되고, 이 링크를 누르면, 해당 버그 트랙킹 시스템으로 이동한다. Relvant bugs 항목을 보면 이 Bug의 현재 처리 상태가 나온다. 위의 그림에서는 “Testing” 상태로 나타나는데, 이 상태는 버그 트랙킹 시스템의 상태를 그대로 출력해준다. Open이나 In Progress 처럼 개발자가 버그 수정을 하다가 수정이 끝나서 위의 그림처럼 “Testing”상태로 상태를 바꿔 놓으면, Test Engineer가 버그가 수정되었음을 인지하고, 버그 트랙킹 시스템에서 수정 결과와 버전을 확인한 후에, 그 버전(Minor 버전)을 선택하여 다시 Test를 수행한후 Pass/Fail 여부를 결정한다.

이 과정에서 TestLink와 버그 트랙킹 시스템간의 프로세스 연계가 중요하다.

테스트가 실패한 경우, Test engineer가 버그 트랙킹 시스템에 Bug를 등록해야 하고, Bug가 수정되면 개발자가 해당 Bug를 다시 Test Engineer에게 assign한후에, Test Engineer가 테스트를 확인하면, 버그 트랙킹 시스템에서 해당 Bug Close 처리하도록 하는 것이 권장되는 프로세스 이다.

Test Execution 시에, 1.0에서 발견된 버그라도 수정이 1.2 버전에서 수정되었다면, Test Execution에서 테스트 수행전에 “Build to Execute” 리스트박스에서 수정된 버전을 선택해서 테스트를 진행해줘야 한다.


7.     Reporting

테스트가 종료되었으면, 상단 메뉴의 “Test Reports”에서, 여러 형태의 테스트 리포트를 생성할 수 있다.



위의 그림은 Test Suite 별로 성공/실패 율과 전체 Test Case 수를 리포팅해주는 화면이다.

Test Link 향상된 기능

이외에도 Test Link는 앞에서 잠깐 언급한 바와 같이 Selenium,SOAPUI와 같은 테스트 도구 뿐만 아니라, JUnit과 같은 다양한 테스트 프레임웍 연동은 물론이거니와, Jenkins까지 같이 연계가 가능해진다.

기존에 테스트 도구만을 사용했을 때는 전체 테스트 현황이나 History, 상세한 테스트 케이스 특히 JUnit과 같은 코드가 아니라, Human readable한 형태로 테스트 케이스를 관리할 수 있게 해주며, 요구 사항에서 부터 Test Case 및 결과에 까지의 추적성을 보장해주기 때문에 매우 편리한 도구이다. Learning Curve도 상당히 낮은 도구이기 때문에 반드시 사용해보기를 권장한다.

그리고 누가 강조하지만, 도구는 도구일뿐이다. 어떻게 테스트팀의 구조를 잘 세팅하고, 프로세스를 잘 정의하느냐가 가장 중요한 항목이다.

'ALM > Test Automation' 카테고리의 다른 글

TestLink를 이용한 Test Case 관리 자동화  (2) 2013.12.31
Selenium Test Suite 수행  (0) 2013.12.29
Selenium WebDriver와 RC 차이  (0) 2013.12.24
Selenium 테스트 메모  (0) 2013.12.24
테스트 팀의 조직 구조  (1) 2012.08.21
JUnit Max  (1) 2009.05.06


MS 클라우드 아키텍쳐는 대충 파악했고, 요즘 KT나 기타등등 회사들이 오픈소스기반의 클라우드를 검토하는 일이 많은지라 오픈 소스 클라우드를 하나씩 뽀게기 하고 있는데, 오늘 첫번째는 유칼립스...
검색을 해봐도 한글자료가 그나마 잡히는 게 유칼립스다. 아마 그만큼 쉬워서가 아닐까 싶은데.

일단 주목할만한 특징을 몇개 적어보면
Amazon EC2,EBS,S3와 API 호환성을 가지고 있다.
그외에 DB 서비스등은 제공하지 않지만 어짜피 DB야 IaaS에 잘 올리고, NoSQL로 서비스 만들면 되니까는 구축에는 큰 문제 없을 듯
기본적으로 Hypervisor는 Xen,KVM 지원하고 근래에 VMWare를 지원한다. Hyper-V는 지원하지 않는다.
Guest OS로는 대부분의 Linux를 지원하고 2.0 버전부터는 Windows Server 2003과 2008을 지원한다.

인스톨만하면 Amazon like한 클라우드 서비스를 바로 쓸 수 있는 것이 장점인데,
Admin 메뉴얼 훝어보니 Private Cloud향으로 개발된 것 같다. Multi tanent에 대한 지원 기능이 좀 약한 것 같고 특히 Orchestration 기능이 없어서 Flexibility는 좀 떨어질 듯 하다. (cf. Microsoft Opalis 같은 일종의 클라우드형 BPM? )

대충 구조는 이렇게 생기셨고



컴포넌트는 아래와 같다.
  • CLC (Cloud Controller) - 전체 클라우드를 관리하는 관리 시스템
  • Walrus (Store persistance data like S3) - 아마존 S3와 같은 대용량 파일 저장 시스템
  • CC (Cluster Controller) - 클러스터 단위에 대한 컨트럴러
  • SC (Storage Controller like Amazon EBS)- SAN (NFS,ISCSI, etc 지원) - Amazon EBS와 같은 Local Storage
  • NC (Node Controler - per server) - 각 서버에 배포되는 컨트럴러
구조는 잘 잡힌거 같은데, 클러스터 개념은 다시 파악할 필요가 있는 것 같고, 만약에 클러스터가 동적으로 생성이 가능하다면 Tenant 단위로 클러스터를 맵핑 시켜주는 것이 좋을 듯.

네트워크 모델은 DHCP 기반의 네트웍, Static IP도 지원하고 기본적으로 VLAN도 지원한다. 어느 정도 구색은 갖춘듯 싶고.
Storage 부분은 문서상에는 NFS,iSCSI,etc 지원이라고 나오는데, FC/HBA 기반의 SAN을 지원하는지는 확실하지 않다. (아마 하겠지만 구성은 쉽지 않은 듯)

Supported SAN은 DELL과 NetApp 장비를 지원하는데
Eucalyptus EE with SAN support has these additional prerequisites:
• Configured SAN device(s). Eucalyptus currently supports these SAN devices:
• Dell EqualLogic (PS4000 series, PS6000 series). For more information on Dell EqualLogic SANs, see www.dell.com.
• NetApp (FAS2000 series, FAS6000 series)

역시 NetApp은 요즘 어디가나 잘 끼는 듯. :)
한글로 유칼립스 소개한 문서는
http://www.ibm.com/developerworks/kr/library/os-cloud-virtual1/
http://www.linxus.co.kr/main/view_post.asp?post_seq_no=50015

기업내의 중소규모 Private Cloud 구성에는 꽤나 쓸만할거 같다.



IaaS 구축용
- Hypervisor : XenServer, Oracle XenServer가 가격 대비 Support 가능
- Cloud Management : Cloud stack (cloud.com)
- Software ISCSI : Nexentar (고속 IO에는 적합하지 않음)

PaaS 구축용
- Storage : OpenStack
- Column DB : Cassandra
- Simple DB : MySQL or VoltDB

Hadoop은 아니라고 보고

진짜 별게 다 나온다.
오픈 소스가 많이 발전하고,
이제 J2EE 급의 각종 오픈소스 프레임웍들이 나오더니..
이런것에 대한 통합과 정리의 필요성을 생각하고 있었는데.
실제로 Spring의 경우는 오픈소스들의 컨테이너와 같은 역할을 하면서 수많은 커넥터 들을 만들어 내고 있었다.
그런데 왠걸? SourceForge에서 EJSOA로 Enterprise용 Java Open Source 아키텍쳐를 내 놓았다.

사용자 삽입 이미지

얼마나 실용적일까는 두고봐야할 일이지만, 상용 J2EE 벤더 입장에서는 그리 반갑지 않은 오픈소스가 아닐까 싶다. 이대로 가다가는 상용벤더들은 Middleware보다는 솔루션과 컨설팅등에 집중해야 하지 않을까?
다음은 EJOSA 관련 자료들에 대한 링크
http://blog.naver.com/comsnake?Redirect=Log&logNo=80005937833
http://blog.naver.com/comsnake?Redirect=Log&logNo=80005937833

'IT 이야기 > 트렌드' 카테고리의 다른 글

자바 기술 트렌드 분석 - 2. OR Mapping  (1) 2009.04.30
자바 기술 트렌드 분석 - 1. MVC  (1) 2009.04.30
구글  (0) 2007.11.21
요즘 개발의 트렌드  (0) 2007.09.04
EJOSA (Enterprise Java Open Source Architecture)  (0) 2007.08.27
기술 기술..  (0) 2007.07.25