1장 에서는 Jenkins 자체에 testlink plugin 을 설치 하는 작업 까지 하였습니다.

2장에서는 해당 testlink plugin 을 통해서 현재 설치된 Jenkins 에 연동할 Target Testlink 를 설치 하는 작업과 간단한 실행순서 등을 보려고 합니다.

이미지는 생략하구

다시 

localhost:8888 ( 기존의 설정했던 포트번호 )

// ** 포트 번호 설정은 (Root 권한으로 하셔야 합니다.)

vi /etc/sysconfig/jenkins 로 들어가신후에 

JENKINS_PORT =" 요 부분   "  을 설정해주시면 됩니다.

ex: JENKINS_PORT="8888"

적용이 안될때는 다시 실행 하셔도 됩니다.

// ** 재시작  (Root 권한으로 하셔야 합니다.)

/etc/init.d/jenkins restart  

이제 메인 페이지 화면에서  

Jenkins 관리

시스템 설정 

TestLink  (Ctrl +F 로 찾아도 된다.)

찾고나면 옆에 추가 버튼이 있습니다.

추가 버튼을 누르게 되면 아래와 같은 화면이 나오게 됩니다. 하나씩 설명 하자면

보시면 Name과 Developer Key 에만 Mandatory Property (필수 속성) 이라고 되어있지만

사실은 URL도 필수 속성에 속합니다.

URL을 지정을 해둬야지 api 를 가져올수 있기 때문이죠.. 결론은 3개다 필수 속성입니다.

Name은 지정안하면 만들어주질 않기 때문에 

Name : 사용하는 TestLink 의 이름을 지정합니다 ( 실제 이름이 아닌 Jenkins 에서 사용할 이름)

예를 들어 testlink 를 2개 사용한다고 가정 하였을때 A는 테스트용 테스트링크고 B는 실제 사용 테스트링크 라고 하면 2개를 설치 후에

A의 Name은 - test testlink 

B의 Name은 - QA_Team_TestLink 식으로 이름을 지정해 놓아야  추후 빌드 할때 잘 골라서 사용할수 있습니다.

** 한글로 작성시에는

집사님(Jenkins) 께서 노하시기 때문에 영어로 작성을 하도록 합니다.

URL :  api 를 사용할수 있는 페이지 url을 지정 합니다.

// 보시게 되면 기본으로

http://localhost/testlink/lib/api/xmlrpc.php 라고 되어있는데

testlink 가 설치된 서버가 127.0.0.1 이라고가정할시에

http://127.0.0.1/testlink/lib/api/xmlrpc.php 라고 무턱대고 사용하면 연결이 되지않는다

** Port번호

http://127.0.0.1:8080/testlink/lib/api/xmlrpc.php 라고 무턱대고 사용하면 연결이 되지않는다

으로하여도 안될수가 있다. ! 왜냐면

testlink 버전 마다 xmlrpc.php 의 위치는 다르기 때문이다.

필자가 사용한 버전은 testlink - 1.9.16 버전이기 때문에 해당 버전에서 xmlrpc.php 의 위치는

http://ip주소:8080/testlink/lib/api/xmlrpc/v1/xmlrpc.php 위치한다. 위와 다른점은 

해당 부분이추가 되었다. 해당 블로그를 보다가 아 이제 Name부터 해볼까!

하고 작성하면 해당 에러가 뜰수 있다. (403) Jenkins의 로그인 Session 이끝났단 이야기 이니까 

그냥 다시 F5누르고 로그인 하시고 작업하시면 됩니다.

해당 403에러는 종종볼수 있습니다.

이제 남은 부분 개발자 도구 키 !

해당 키는 target Testlink 에서 생성하여서 받아 오셔야 합니다.

testlink 가 설치된 서버 혹은 주소로 접속 후 

해당 버튼을 누릅니다.

그리고 해당화면에서

해당 키를 생성하고 개인 API 접근 키 를 복사해서 Developer Key 에 입력 합니다.

Developer Key :

이렇게 설치까지 다 확인이 되었지만 Jenkins 에서 프로퍼티 끝에 보시면 아래와 같이 물음표 가 있습니다. 여기 물음표만 눌러서 진행하여도 웬만한 기능들 사용에는 많이 무리가 오진 않을것 같습니다.

눌르게되면 URL에 대해서 Usually it is http://host.port/testlink/lib/api/xmlrpc.php 라고 나옵니다.

예시를 하나 더 보여드리면

/var/lib/jenkins 에 대한 설명 도 나옵니다.  Jenkins 사용시에는 물음표부터 클릭해보면 알수 있습니다.

이번에는 testLink Installation 만 하였으며 다음에 빌드 에 대해서 작성 하겠습니다.

앞서 설정한대로 젠킨스의 설치가 끝났고 포트설정까지 되어있고 실행되어있는 상태 일시

ps aux | grep jenkins 라고 검색 하였을 시에

[tos@localhost _api_]$ ps aux | grep jenkins
jenkins   1772  0.1 16.3 4710916 612508 ?    
Ssl   1월15   3:07 /etc/alternatives/java -Dcom.sun.akuma.Daemon=daemonized -Djava.awt.headless=true 
-DJENKINS_HOME=/var/lib/jenkins -jar /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log
 --webroot=/var/cache/jenkins/war --daemon --httpPort=8888 --debug=5 --handlerCountMax=100 --handlerCountMaxIdle=20
[tos@localhost _api_]$

와 같이 동작중인 형태가 보여져야 현재 실행 됐다고 볼수 있다

이후 웹 브라우저를 킨후 (필자는 Chrome 63)

localhost:8888  로 접속 후 좌측 화면에 Jenkins 관리 버튼 을 누른다 

이후 나오는 창에서 플러그인 관리 클릭

누른후에 나오는 탭 중에서 "설치 가능" 탭을 눌러서 필요한 플러그인들을 설치 하여야 한다

여기서 설치 하여야 할 것들이 많이 나오기 때문에 Ctrl + F 로 직접 검색을 하여서 설치 하도록 한다.

testlink 연동을 위해서 설치 하여야할 플러그인

1. Testlink plugin (Current 3.12)

this plugin integrated, Jenkins and TestLink

2. Junit Plugin  // testLink exceution result , report etc use

3. JUnit Attachments Plugin (필자는 연동시에 사용하였지만 해당 플러그인은 필요 없어도 될것으로 보인다.)

젠킨스 tesltink 공식 매뉴얼

https://wiki.jenkins.io/display/JENKINS/TestLink+Plugin

해당 플러그인들을 좌측 check box에서 체크 한 후에 

맨 하단에서 "재시작 없이 설치하기 " 혹은 "지금 다운로드 하고 재시작 후 설치하기"

필자는 후자로 진행하였습니다. 큰 의미는 없습니다.

메인 페이지 -> Jenkins 관리 -> 시스템 설정 

에 들어가시게 되면

해당 부분이 보이실겁니다.  그렇다면 현재 Jenkins 에 testlink plugin , junit plugin 이 설치가 끝났습니다.

다음에는 해당 플러그인을 통해서 

Jenkins 자체에 target testlink 를 Install 하고 해당 테스트링크에 존재하는 테스트 계획 및 테스트 케이스를 찾아서 가져오는 작업 및 testlink-plugin 의 동작방식에 대해

작성하도록 하겠습니다.

젠킨스 젠킨스 IT 하는 사람들이라면 한번쯤 어디서든 들어봤을 법한 단어다

Jenkins(젠킨스),hudson(허드슨),git(깃),svn(에스브이엔) , 형상관리  

코드를 짜는 부분만이 개발자의 다라고 할수 없다.  물론 QA도 마찬가지다

테스트케이스를 만들고 결과 를 도출해내고 매번 같은 케이스를 수작업으로 확인하고 

Unit_Test를 작성한다고 하여도 매번 직접 확인하거나 매번 직접 실행하여야 하는 부분들이있다.

이런 경우에 테스트 중인 프로그램의 규모가 커지거나 하였을때는 어떻게 하겠는가 

그냥 꼴딱 밤을 샐것인가 ? 

너무 비효율적이다. IT하는사람이라면 컴퓨터를 노예 부리듯이 부릴 줄 아는것도 좋아보인다.

QA도 고도화된 개발자 만큼은 아니여도 어느정도 개발자 수준의 코드 퍼포먼스 정도는 낼줄알아야 한다. 젠킨스 든 git이든 개발자의 툴이다 아니다

QA도 사용하여야 할 툴이고 테스트가 진행될수록 프로그램이 커질수록 TestCase는 끝없이 방대해지며 이것들을 검증하는 스펙트럼은 QA의 역량에 따라 다르다 

높은 QA일수록 더 많은 스케일에 대한 테스트가 가능하다 이것들을 위해서 수동이 아닌 자동으로 되는 부분들에 대한 케이스를 CI를 통해서 통합하고 사용할수 있도록 하여야 한다.

자동화 테스트를 위한 젠킨스 사용은 필수이다

(다른 여러 방법이 있겠지만)

이것을 도와주기 위해서 오늘은 CI 툴인 Jenkins( 젠킨스) 에 대해서 조사한 내용과 설치 정도까지 할려고 한다. 

젠킨스 ?

흔히 검색하면 나오는 말이다. 지속적 통합 , CI 서버 CI ? (Continuous Integration) 라고 한다. 

대부분 개발자들은 개발된 코드를 지속적으로 통합하여 충돌 내용을 방지하기 위해서 사용한다고 한다.

최초에는 허드슨 프로젝트로 시작되었다. 

이로인해 어드민 페이지등은 허드슨과 매우 유사한 점이 많으며 허드슨 플러그인을 참고하여도 될정도이다.

공식 웹 사이트 : https://jenkins.io/ 

프로그래밍 언어 : Java 

최신 버전 : 금일자 기준으로 2017 년 8월 17일 자 버전인 (2.60.3)

 OS : Cross PlatForm

라이선스 : MIT 

종류 : 웹 어플리케이션

플러그인 :  400개 이상의 플러그인

(라이센스 관련 내용은 딸도 정리해서 올려놓았습니다.)

이외의 대표적인 젠킨스의 기능들

1. 저장소 통합 

2. 소스코드 체크아웃 이벤트 

3. 빌드 및 테스트 자동화

4. 테스트 보고서 생성

5. 실행결과 통보(이메일)

6. 산출물 저장

7. 배포

Install 

필자는 CentOS 계열을 사용하기 때문에 해당 젠킨스 설치도 CentOS 기준으로 6.0 7.0 으로 적도록 하겠습니다.

1. 설치 하기전 필수 사항 

JDK : 1.7 이상 ( 자바 프로그램이기 때문에 JDK 는 필수조건이다.)

2. 설치 (설치 방법은 홈페이지에서 파일을 받아도 되지만 CentOS에서는 명령어로 설치)

2-1 wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo

rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key

2-2 yum install jenkins

(설치가 끝납니다. ) 매우 간단

3. 기본 세팅 

3-1 이미 띄워놓은 여러 프로젝트들이 포트를 쓰고있어서 포트를 변경합니다.

기본 Default: 는 8080으로 되어있는데 해당 포트는 예약 포트이기 겹칠 확률이 있습니다.

3-2 vi /etc/sysconfig/jenkins

JENKINS_PORT  를 검색하면 찾을수있습니다. 

JENKINS_PORT="8888"  로 변경

etc

JENKINS_HOME = "var/lib/jenkins" 해당 사항은 알아 두어야 합니다. 

젠킨스에서 작업되는 워크스페이스 등에 대한 홈 위치 이기때문에 자주 접속하게 됩니다.

/etc/init.d/jenkins start  or /etc/init.d/jenkins restart 젠킨스 시작 및 재시작

// (루트 권한으로 시작 하여야합니다. sudo -s 혹은 su 

 4. 젠킨스 접속 

jenkins start 혹은 restart로 시작하였다면 웹 어플리케이션 답게 웹으로 접속하여야 합니다.

같은 동일 PC에서 하신다면 localhost:8888 

// 위에 8888로 설정하였기 때문에 혹시 안된다면 8080으로 해보셔도 되고 재시작을 해보시고 8888로 하시면 됩니다. 위에서 설정만 하고 말았다면 적용이 안되어있을수 있음 

5. Unlock Jenkins 

위의 4번에서 제킨스를 접속하게 되면

 Unlock Jenkins 라고 나오게 된다. 해당 부분에서

car /var/lib/jenkins/secrets/initialAdminPassword 하게되면 나오는 키를 입력해주면 된다.

6. Customize Jenkins

 Install suggested plugins 설치 ( 기본 설치 이므로 원하지 않는다면 선택 하지 않아도 된다.)

7 어드민 계정 생성

id: test

pw: test_QA

// 해당 admin 계정으로만 jenkins의 플러그인  + 쉘 스크립트 작성 등에 대한 설정이 가능하니 유의해서 만들기 바람 

OLTP DB -> 99%의 DB가 OLTP DB일 거다

T는 트랜잭션을 뜻하며 update가 되는 DB를 뜻한다.

OLAP DB (올랩) -> insert 만 되는 DB로서

통계청 등에서 많이 사용된다.

예전에는 각각의 DB engine이 많이 달랐지만 지금 현재는 Engine이 같다고 볼 수 있다.

SQL도 이전에서는 다른점이 있었지만 이제는 전부 같다 OLAP DB에서는 추가된 SQL 이 있긴함

하나 DB -> 인메모리 DB

알티베이스 -> read Only OLAP DB (insert만 되고 업데이트가 안된다고는 하지만 update가 되긴 함)

OLTP DB는 Row Manager

OLAP 는 Column Manager

------------------------------------------------------------------------------------------------------

C랑 C++은 완전 다른 개념이며 같다고 볼수 없다.

C++ : 컴파일러 언어 JAVA : 인터프린터 언어 (중간언어가 있음)

script : 중간 언어가 없어 직접 인터프린터 라고 한다.

C++ : 컴파일에러

JAVA : VM(인터프린터) -> JVM

이런 형식이기에 둘의 성능은 비교가 될수 있다.

JAVA 는 GC(가비지 컬렉터가 존재)

C++ : GC가 없음 

JAVA: GC가 있음

JAVA에서는 메모리릭이 날 확률이 매우 적고 VM이 있기 때문에 성능이 많이 저하 되지만 프로그램이 죽을일이 매우 적음

또한 메모리 릭 또한 나타나지 않음

치명적 약점 : -> 성능

시스템소프트웨어에서는 자바 로 개발을 할수가 없음

C++ : 컴파일 언어 이면서 객체지향을 지원하는 언어 C보단 속도가 느리지만 성능면에서 뒤쳐지지않음 많이 뒤쳐져봐야 1~%

에러 처리가 매우 좋음 , 객체지향, 성능 희생이 거의없음

-> C로 개발하는거보다 C++의 개발 이유 

 C++은 C의 Super set 이라고볼수 있다.( 유지보수도 C에 비해서 매우 쉬운 편)

리눅스 커널은 C로 되어있어 유지보수가 매우 어렵다 

SQL언어는 인터 프린터 언어이다.

JavaScript는 예외적으로 위의 스크립트의 특징도 자바의 특징도 가지고있지 않다. 

최근 제품들은 전부 C++로 개발이 되어지고 있다.

node.js는 최고의 기술이다.

NODE는 단어 자체가 고유 명사이며 js는 자바스크립트를 뜻한다.

node.js의 event driven 방식의 코드 설계는 정말 최고다 

의존성으로 인한 에러 코드를 찾기 위한 수고가 덜어진다. (유지보수에도 용이)

최근에 개발되는 제품들은 Event Driven 의 구조를 가지고 있으며 C++로 개발이 되어진다.

children 과 childNodes 를 비슷해보이지만 결과값이 다르다

var child_array2 = window.document.getElementById("layout");

var nodes = child_array2.childNodes;

console.log(nodes);

nodes = child_array2.children;

     console.log(nodes);

사진을 보면 childNodes는 25개의 결과 가 나오지만  children 은 12개의 결과 가 나옵니다.

childNodes는  줄바꿈을 개수로 세는 경우가 있어서 해당과 같이 나옵니다.

자세한건 없고 되도록  children 을 쓰려고합니다.

restapi 서버를 node.js로 구성 하는 경우에 꼭 필요한 경우라고 생각 합니다.

최근에 파일 관련 데이터 를 crud하기 위한 rest api 서버를 간단하게 제작 해보니

body-parser 라는 모듈이 필요하게 되어서 사용하게 되었습니다.

해당 모듈은

npm install body-parser 로 설치 할수 있으며 request body 를 json 으로 변환해 주는 모듈입니다.

작성중..

NPM(Node Package Manager) 에 대해서는 이제 어떤건지 대략적으로 알수 있을 것 같습니다.

이제부터는 NPM 에서 사용하였던 모듈들에 대해서 리스트를 작성 하도록 할려고 합니다.

이번에는 2번째 모듈인  cors (Cross Origin Resource Sharing)  모듈에 대해서 간단하게 보려고 합니다.

왜 두번째로 cors를 하였냐면 가장 맨 처음에 부딪치는 이슈이기 때문입니다. 

122.118.155.163:3000 으로 node서버를 진행시

122.118.155.163 에서 node 실행 인데 3000 port로 Listen 중 이며

122.118.155.163:8888 에서 웹서버가 디플로이 (Deploy) 된 상태 에서 클라이언트가 

122.118.155.163 으로 ajax 요청을 보내게되면 크로스 도메인 이슈가 나타나게 된다.

웹서버(웹프로젝트)는 8888에 떠있지만 실제로 요청을 받는 API 서버는 3000 포트에서 받고 있기 때문이다. 

해당 크로스 도메인에 대해서는 따로 찾아 보시길 바라고 해당 의 경우에는 

3000으로 Listen 중인 이 서버가 같은 IP를 사용하고 있지라도 CORS 문제로 인해서 restapi 를 사용할수가 없게 된다. - 보안 상의 이유로 안된다고 하는데 해당 사항에 대해서는 찾아서 이 글에 수정 하도록 하겠습니다.

XMLHttpRequest cannot load http://xx.xx.xx.xx/xxx. Request header field Content-Type is not allowed by Access-Control-Allow-Headers. 

출처: http://blog.opid.kr/430 [opid's document]

해당 에러 메시지 가 나타났을 경우에 CORS 이슈가 나타났다고 할수 있습니다.

** IE에서 간혹 cors를 설정 하였는데도 불구하고 SEC7118 XMLHttpRequest CORS 라는 에러를 내 뿜는

경우가 있는데 해당은 IE 11 버그입니다. (Windows 10 으로 가서 실행시는 나타나지 않는)

CORS이슈가있으면 response, request가 되지 않습니다. 

이에 대해서 여러가지 방법이 있는데 

1. ajax의 dataType을 jsonp 로 바꾸는 법 

2. 헤더의 크로스 도메인 을 허가하는 방법 

  -> PHP  header("Access-Control-Allow-Origin: *");

  -> JSP  <% response.addHeader("Access-Control-Allow-Origin","*"); %>

cors를 활성화 해준다고 되어있습니다. 여러 기능도 포함하여서

설치

-> npm 모듈이기 때문에 npm 으로 설치 합니다. 해당 설명도 진행할수록 생략 하도록 하겠습니다.

npm install cors

사용

npm cors 페이지 참조 

1. 모든 도메인 요청 활성화(모든 작업 CORS 허용 테스트용)

// 익스프레스 모듈 require 및 app 설정 (해당 방식은 express 에서 사용하도록 한 규약? 같은 방식)

var express = require('express')

var app =express();

// install cors 로 설치 하였기 때문에 cors 모듈 require

var cors = require('cors')

// cors () 사용  // 모든 도메인에 대한 Request 활성화  -> 좋지 않은 방식 

app.use(cors());

사용

2. 싱글 라우트에 대한 도메인 활성화(특정 작업에 대해서만 CORS허용)

// 익스프레스 사용

var express = require('express');

var app = express();

// cors 사용

var cors = require('cors');

// ***********  products/:id 에 대한 url 라우팅시에만  cors 를 허용 

app.get('/products/:id', cors(), function(req,res,next) {

res.json({msg:'This is CORS-enabled for a single Route'});

})

사용

3. CORS Config settings(setting 값을 수정하여서 CORS 허용 IP지정)

var express = require('express');

var app = expresS();

var corsOptions = {

origin :'http://example.com',

optionsSuccessStatus:200; // IE 11이나 여러 스마트 TV들에 대한 확인 

};

app.get('/products/:id',cors(corsOptions),function(req,res,next){

res.json({msg:' This is CORS-enabled for only example.com.'});

});

사용

4. CORS w/ Dynamic Origin  동적으로 읽어서 사용 

whitelist 배열을 push 로 추가하여서 실시간으로 허용 및 제거 가능 

// 앞 부분 생략

var whitelist = ['http://example1.com','http://example2.com']

var corsOptions = {

origin: function(origin,callback)    {

if(whitelist.indexOf(origin) !==-1){

callback (null,true);

} else{

callback (new Error('Not allowed by CORS'))

}

}

}

app.get('/products/:id', cors(corsOptions),function(req,res,next){

res.json({msg: 'This is CORS-enabled for a whitelisted domain.'})

});

5. ETC CORS pre-Flight  CORS 비동기 사용 , CORS 제거 등에 대한 내용은

www.npmjs.com 에 cors 검색 후 확인 하시면 될것 같습니다.

git을 설치하기 전의 나의 OS 부터 확인

uname

 Linux  // OS 이름 

uname -r

3.10.0-327.el7.x86_64 // 커널 정보

cat /etc/*release  // OS 정보 확인 

CentOS Linux release 7.2.1511 (Core)

NAME="CentOS Linux"

VERSION="7 (Core)"

ID="centos"

ID_LIKE="rhel fedora"

VERSION_ID="7"

PRETTY_NAME="CentOS Linux 7 (Core)"

ANSI_COLOR="0;31"

CPE_NAME="cpe:/o:centos:centos:7"

HOME_URL="https://www.centos.org/"

BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"

CENTOS_MANTISBT_PROJECT_VERSION="7"

REDHAT_SUPPORT_PRODUCT="centos"

REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.2.1511 (Core)

CentOS Linux release 7.2.1511 (Core)

getconf LONG_BIT  // 비트 확인 

64

var round_i = 5555.55555555; 

console.log(round_i.toFixed(5));

 결과 : ->   5555.55556

오늘의 끄적끄적

1. CSS 

display : inline, dispaly : block 속성

block - 한줄에 나열하지 않고 그 자체를 한줄로 표현  (자연 스러운 줄 넘김이 가능 )<p> 태그

-> margin,width,height 속성이 정의 가능 

 ( 기본적으로 width 가 100%)

inline 줄을 바꾸지 않고 다른요소와 하께 한 행에 위치하려는 성향 <a> 태그

-> margin-top,margin-bottom 속성을 정의해도 적용 X  

상하 여백은 line-height 속성에 의해 발생 

width 와 height 속성이 적용되지 않음 

-> inline 너비와 높이는 태그가품고 있는 내부 요소의 부피에 맞춰집니다.

최소한의 간격을 유지하기 위해서 연속으로 사용된 경우는 5px의 내부 margin 이 자동 발생

(웹 브라우저의 기본 설정 때문)

inline-block 

margin-top,margin-bottm 정의 가능 상하 여백을 margin , line-height 를 모두 제어가능

width 와 height 정의 가능

기본적으로는 태그가 품고있는 내부 요소에 의해 부피가 맞춰짐

inline-block 끼리 사용시에는 최소한의 간격을 유지하기 위해서 좌, 우 약 5px 가량의 외부 여백이 발생

margin-left margin-right 를 사용시에 여기에 추가로 여백을 줄수 있음