깍돌이

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

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

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

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

티스 토리 사용 도중

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

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 이라는 파일이 생기는데 이파일은 원래 터미널 제어를 받았을떄 나타나는 로그들을 포함하고있다.

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

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