깍돌이

국내에서 QA는 그냥 테스트하는 조직이며 개발자 서포팅 느낌이지

절대 "주"가 될수없다고 생각 한다. 

그래서 그런가 QA로 들어왔던 사람들은 QA에서만 주구장창있거나 경력을 살리지못하고 다른일을 하던가 이다.

하지만 잘못된 생각이다. 분명히 QA도 이 위치에서 조금만더 테스트에 대한 생각과 고민을 한다면 개발자 못지 않는 

스킬 셋을 가질 수 있으며 이걸 나는 너무 늦게 깨달았지만 지금이라도 깨달았기 때문에 박터지게? 공부중이다.

하지만 QA는 컴파일러 언어 보다는 스크립트 언어가 조금 더 비중을 차지하는건 사실이다. 

scp를 이용하여서 파일을 받아 온다 .치면

sudo scp -r test@192.168.1.11:~/Test/Tmp 에서 받아오는데 이 이후에

password :입력과

DNS어쩌구 머시기 yes를 해주어야 한다. 

이 부분을 매번 테스트할때마다 받아오기도 귀찮고 그냥 ./scp.sh 하면안될까 싶어서 찾아보니 expect 로 한댄다.

그래서 expect 가설치 되어있는지 확인을 하여야 하기 때문에

터미널에서 그냥 expect 라고 입력시 not found 뜨면 설치를 해주어야 한다. 

저는 Unix시스템에서 작업을 하기 때문에 Unix기준으로 보면

pkg search expect 해당 커널 버전에 따라서 이렇게 나오게 됩니다. 

순수 expect 입력시 not found command가 뜬다면 pkg install expect 로 설치를 해주세요 

repository 가 없다면

expect  http://www.nist.gov/el/msid/expect.cfm

tcl   http://tcl.sourceforge.net/ 에서 설치를 해주셔야 합니다.

repository 없이는 tcl까지 설치 하여야 합니다.

기본적인 루틴

spwan (지정된 어플리케이션을 실행)

send (명령 실행)

expect -re(기대 값 설정)

interact (스크립트 종료)

#!/bin/sh 으로 실행하게되면 not found가 뜰수가 있는데

sh 혹은 bash 쉘에 expect 를 넣어 서사용하는방식이

expect << EOL 을 넣어 주면 사용할수 있다.

아주 간단한것부터 시작ㅇ르 해본다.

test라는 계정으로 접속하여 192.168.1.11 서버에 /home/Test/Temp 라는 폴더를 /home/Test/Tmp 라는 폴더(현재서버)로 가져올려고 한다.

scp명령자체에 sudo를 걸어서 가져올려고 한다. 그럴시에 PassWord입력이 2개가 뜨게 된다.

그렇기 때문에 대략적인 스크립트를 적어 본다면 

#!/bin/sh/

expect << EOL

spawn sudo scp -r test@192.168.1.11:~/Test/Temp /home/Test/Tmp

expect "Password*" // 처음 나타난 메시지중에 Password로 시작하는 메시지를 기대한다.

sleep 0.5                // 0.5초 쉬고 

send "1234\r"        // 1234를 입력하고 캐리지 리턴 (\r)엔터 입력 

expect "Password*"    // 두번째 나타난 메시지 중에 Password로 시작하는 메시지를 기대한다.

sleep 0.5                //0.5초 쉬고 

send "1234\r"        //1234 입력 후 엔터 

interact

로 나타날수 있다.

해당 스크립트는 쓸모가 없다. (쓸수도 없고...)

2탄으로 다시 작성하도록 하겠습니다.

내가 쓰는 vim 셋팅

/home/계정/.vimrc 생성후 입력 

syntax on        " 문법 하이라이트 킴"

set number            " line 표시를 해줍니다.

set shiftwidth=4      " shift를 4칸으로 ( >, >>, <, << 등의 명령어)

set tabstop=4         " tab을 4칸으로

set ignorecase      " 검색시 대소문자 구별하지않음

set hlsearch         " 검색시 하이라이트(색상 강조)

set expandtab       " tab 대신 띄어쓰기로

set background=dark  " 검정배경을 사용할 때, (이 색상에 맞춰 문법 하이라이트 색상이 달라집니다.)

set nocompatible   " 방향키로 이동가능

set encoding=utf8

set fileencodings=utf-8,euc-kr,cp949    " 파일인코딩 형식 지정

set bs=indent,eol,start    " backspace 키 사용 가능

set history=1000    " 명령어에 대한 히스토리를 1000개까지

set ruler              " 상태표시줄에 커서의 위치 표시

set nobackup      " 백업파일을 만들지 않음

set title               " 제목을 표시

set showmatch    " 매칭되는 괄호를 보여줌

set nowrap         " 자동 줄바꿈 하지 않음

set wmnu           " tab 자동완성시 가능한 목록을 보여줌

syntax on        " 문법 하이라이트 킴"

// 출처가 어딘지 기억이 안난다.... 

// 이제 부터 직접 추가 

2016-06-24

set encoding=utf8  (한글 깨지는 부분)

set fileencodings=cp949       

두줄 추가 (cp949 추가시에 , 앞에 띄어쓰기 하면 에러 발생 붙이길

********

2016-06-27

해당 alias 설정은 /etc/csh.cshrc   alias vi     vim

2016-10-06

set ai                    " auto indent

set si                    " smart indent

set cindent            " c style indent 

제거 쓸데없음 

scp 서버간 파일 복사 에 사용되는 명령어 이며 보안성이 (ftp, sftp 등에 비해 뛰어나다) - 이에 대해서는 따로 정리

기본 사용법에 대해서만 설명한다

첫번째는 내가 갖고 있는 파일을 보낼때 

scp [option][file_location] [send_account]@IPAddress:/location

현재 서버인 192.168.0.0.1 /home/User/ 에 있는    

temp.txt 파일을 111.123.5.12(계정은 test) 에 /home/user/ports 에 보낸다고 하면

scp /home/user/temp.txt test@111.123.5.12:/home/user/ports 

반대로 서버에서 가져오는 방법도 있다.

192.168.1.11 서버에 있는 /home/Test/temp/memo.txt 파일을 가져온다고 할시에는

scp [account]@IPAddress:[download_location] [current_location]

scp test@192.168.1.11:/home/Test/temp/memo.txt .

마지막 memo.txt 띠고 . 의 의미는 현재 위치(pwd)로 라는 뜻이 된다. 절대 경로로 /home/test라고 주어도 된다.

*** 만약에 ssh 기본 포트인 22번 포트가 아닐 경우에는

scp -P 하고 포트번호를 써 주어야 한다.

scp -P 8080 test@192.168.1.11:~/temp

*** 가져오거나 보내는 파일이 폴더일 경우에는 -r 옵션을 추가한다. (mv나 cp에서 사용하는 -r의 옵션과 동일하다 하위 폴더 모두 복사 이동)

scp - r test@192.168.1.11:~/Test/temp /home/Test/temp

요약

"재주는 곰이 넘고 돈은 왕서방이 받는다"

대한민국에서는 똑똑하고 착한 사람은 매우 "계산적"인 사람을 칭하는 것 같다.

"어둠의 내려 갈 곳을 잃어 "

"희미해진 기억 들 이젠 잊으려고 해 "

"난 다시 꿈 꿔 하늘을 걸어서 "

회사 - 집 - 회사 - 집 - 회사 - 집 

티스 토리 사용 도중

핵 빡치는게 옆에 매번 카테고리를 열어서 쓰는 거였는데

html /css 수정들어가서

html 소스에서

category 찾아서 </div>  앞에 해당 스크립트를 작성한다. ㅎ.ㅎ

<script language="JavaScript">try{expandTree();}catch(e){}</script>

// 출처 : ilooksogood.tistory.com/2

블랙 박스 테스팅(Black box testing) – 시스템의 내부 설계(Internal system design)는 이 테스팅 유형에서 고려할 대상이 아니다. 테스트는 요구사항(Requirement) 및 기능성(Functionality)에 기반해서 이루어진다.

화이트 박스 테스팅(White box testing) – 이 테스팅은 애플리케이션의 코드 내부의 로직(Logic)에 대한 지식을 기반으로 수행된다. 글래스 박스(유리상자 혹은 투명상자) 테스팅으로도 알려져 있다. 이 유형의 테스팅을 수행하기 위해서는 내부적으로 소프트웨어와 코드가 어떻게 동작하는지를 알고 있어야만 한다. 화이트 박스 테스트는 코드 구문(Statements), 분기(Branches), 경로(Paths), 조건(Conditions) 커버리지 등으로 분류할 수 있다.

유닛 테스팅(Unit testing) – 각각의 소프트웨어 컴포넌트나 모듈 대상 테스팅을 의미한다. 일반적으로 테스터가 아니라 프로그래머에 의해 수행되며, 이를 수행하기 위해서는 프로그램 내부에서 수행되는 코드와 프로그램 설계에 대해 매우 해박한 지식을 가지고 있어야 한다. 테스트 드라이브 모듈(Test drive modules)이나 테스트 하네스(Test harnesses) 개발이 필요할 수도 있다.

점진적인 통합 테스팅(Incremental integration testing) – 바텀업(Bottom up) 방식의 테스팅. 예를 들어, 애플리케이션에 새로운 기능이 추가되는 것에 대해 지속적으로 이어지는 테스팅과 같은 것이다. 애플리케이션의 기능성과 모듈은 이미 각각 충분히 테스트 되어있는 상태여야 한다. 프로그래머 혹은 테스터에 의해 수행된다.

통합 테스팅(Integration testing) – 통합 이후에 결합된 기능들을 검증하기 위한 통합 모듈 테스팅. 여기서 모듈은 일반적으로 코드 모듈, 개별 애플리케이션, 네트워크 상의 클라이언트와 서버 애플리케이션 등이 될 수 있다. 이 유형의 테스팅은 특히 클라이언트/서버 및 분산 환경 시스템에 적절하다.

기능 테스팅(Functional testing) – 이 유형의 테스팅은 내부적인 부분을 무시하고 결과값이 요구사항대로 나왔는지, 혹은 그렇지 않은지에 초점을 맞춘다. 블랙박스 타입의 테스팅이 애플리케이션의 기능 요구사항 검증에 적합하다.  

시스템 테스팅(System testing) – 각각의 요구사항에 대해 전체 시스템이 테스트된다. 전체 요구사항 명세에 기반한 블랙 박스 타입의 테스팅으로 모든 조합 가능한 시스템의 부분들을 커버한다.

엔드-투-엔드 테스팅(End-to-end testing) – 시스템 테스팅과 유사하며, 데이터베이스와 네트워크 커뮤니케이션의 사용, 혹은 다른 종류의 하드웨어, 애플리케이션, 혹은 시스템에 대한 상호 작용과 같은 실제 사용자 환경을 모방한 환경에서 사용되는 모든 애플리케이션에 대한 테스팅을 포함한다.

새너티 테스팅(Sanity testing) – 새로운 소프트웨어 버전이 주요 테스팅 업무를 수행하기에 충분히 적합한가를 판단하기 위해 수행하는 테스트. 만약 애플리케이션에서 사용 초기에 크래시(Crash)가 발생한다면, 시스템은 더 이상의 테스팅을 수행할 정도로 충분히 안정적이라고 말할 수 없으며, 빌드 혹은 애플리케이션은 이 부분을 수정해야 한다.

리그레션 테스팅(Regression testing) – 애플리케이션의 모든 모듈 및 기능에 대한 수정 사항을 테스팅 하는 것. 리그레션 테스팅에서 모든 시스템을 커버하는 것은 무척 어려운 일이므로 일반적으로 이러한 유형의 테스팅에는 자동화 테스팅이 사용된다.

인수 테스팅(Acceptance testing) – 일반적으로 이 유형의 테스팅은 시스템이 고객이 명세한 요구사항을 충족했는지를 검증하기 위해 사용된다. 사용자 혹은 고객이 애플리케이션을 인수(Accept)할 것인지를 결정하기 위해 수행한다.

부하 테스팅(Load testing) – 어느 지점에서부터 시스템의 반응 시간이 지연되거나(Degrades), 혹은 반응이 실패하는지를 알아보기 위해 부하의 범위 안에서 웹 사이트를 테스트 하는 것과 같은, 부하가 걸리는 상황 하에서 시스템의 동작을 검사하기 위해 수행하는 일종의 퍼포먼스 테스트.

스트레스 테스팅(Stress testing) – 명세에서 허용된 것 이상의 스트레스를 가해서 어떻게 그리고 언제 시스템에서 장애가 발생하는지를 체크하기 위한 테스트. 저장 용량을 초과하는 데이터를 저장하거나, 복잡한 데이터베이스 쿼리를 입력하거나, 시스템에 지속적으로 입력값을 입력하거나 혹은 데이터베이스에 부하를 거는 것과 같은 심각한 부하를 주는 테스트를 수행한다.

퍼포먼스 테스팅(Performance testing) – ‘스트레스’ 혹은 ‘부하’ 테스팅과 종종 혼용되어 사용되는 단어. 시스템이 퍼포먼스 요구사항을 충족하는지 검증하는 행위이다. 이를 위해 각기 다른 퍼포먼스와 부하 툴을 사용한다.

사용성 테스팅(Usability testing) – 사용자 친화적(User-friendliness)인지를 점검하는 것. 애플리케이션의 플로우와 신규 사용자들이 쉽게 애플리케이션을 이해할 수 있는지, 사용자가 원하는 어떤 시점에서도 적합한 도움말이 제공되는지 등이 테스트된다.

설치/삭제 테스팅(Install/uninstall testing) – 각기 다른 하드웨어와 소프트웨어 환경 및 다른 OS 하에서 전체, 부분, 혹은 업그레이드 설치/삭제 프로세스를 테스트한다.

회복 테스팅(Recovery testing) – 크래쉬, 하드웨어 장애 혹은 다른 심각한 문제들로부터 시스템이 어떻게 복구되는지를 테스트 하는 것

보안 테스팅(Security testing) – 해킹이 시스템을 뚫고 들어갈 수 있는지를 검증하는 것. 인가 받지 않은 내부 혹은 외부의 액세스로부터 시스템이 어떻게 스스로를 방어하는지에 대해 테스트한다. 외부 공격으로부터 시스템, 데이터베이스가 안전한지를 체크한다.

호환성 테스팅(Compatibility testing) – 특정한 하드웨어/소프트웨어/OS/네트워크 환경 및 각기 다른 조합 하에서 소프트웨어가 어떻게 동작하는지를 테스트한다.

비교 테스팅(Comparison testing) – 앞서 출시된 제품 혹은 유사한 제품과 비교해 제품의 장단점을 비교함

알파 테스팅(Alpha testing) – 이 유형의 테스팅을 위해 사내에서 가상 유저 환경이 조성될 수 있다. 개발의 마지막 부분에서 이 테스트가 수행된다. 이 테스팅의 결과로 사소한 디자인 변경 등이 이루어 질 수 있다.

베타 테스팅(Beta testing) – 일반적으로 엔드 유저에 의해 완료되는 테스팅. 상용화를 위한 애플리케이션 릴리즈 이전의 최종 테스팅이다.

출처 - http://angel927.tistory.com/77

유닉스에서 기본적인 내부 자동화는 그냥 코딩질하면되지만 (

GUI 자동화는 막상 까다로운점이 있다.

다른 방식들이 야 여러가지가 있겠지만 1분만에 생각해본 방법으로는

프로그램 구현 프로세스가

어플리케이션 실행 -> 테스트 할 프로그램 실행 -> 이미지 매칭하여 특정 동작 후 매칭결과 어플리케이션에 표시 혹은 .txt에 추가 

그냥 /home/my/app/test 라는 프로그램이 실행되어야 한다면

코드 첫줄에 만약에 system("/home/my/app/test") 로 실행해버리면 터미널 제어가 걸려서 test프로그램이 꺼지지 않는 한 

다음 로직으로 진행이 되지 않는다.

그렇기 때문에 C 코드상에 (터미널에서도 써도상관없다. system 이 터미널에서 쓰는 명령을 C코드상에 연결시켜주는거라)

system("nohup sh -- ./exec.sh &"); nohup 을 사용한다.

nohup 에 대한 자료는 따로 검색하시길 혹은 Unix Shell 에 따로 정리 하도록 함 

이런식으로 실행되면 C++ 코드는 정상적으로 실행이 되며 중간에 한번 터미널 제어를 받지 않는 형식의 스크립트 실행이 가능 하다. nohup.out 이라는 파일이 생기는데 이파일은 원래 터미널 제어를 받았을떄 나타나는 로그들을 포함하고있다.

" 나는 니가 무슨생각을 하는지 모른다.

하지만 나는 니가 옳은 판단을 할거라는 걸 안다. "