Nickoo's Blog

Cypress를 하다보면 아래와 같은 문구가 심심치 않게 나온다.

cypress cannot read property 'updatedata' of undefined

이 문제는 화면상의 element가 보이지 않아서 생기는 문제로 scrollTo로 해당 element가 보이도록 이동하면 해결 할 수 있다.

예 : 화면 상단으로 이동 cy.scrollTo(0,0) 

Mac에서 Cypress 설치방법

1. 터미널을 열고 npm install cypress --save-dev 입력 (만약 설치가 안되면 npm을 설치 해야함)

2. cypress 실행 

   > node_modules/.bin/cypress open

Continuous Integration 서버!! Jenkins를 설치해 보자!

하하... 회사가 미쿡이다 보니.. 안되는 영어로 어쩔 수 없이 메뉴얼을... 흑흑... 한쿡사람은 보지 말고 이거 보자!! 

Jenkins는 Continuous Integration를 Open-Source로 지원하고 있는 대표적인 CI Server이다. Java로 구축되었으며 약 1000개의 상의 플러그인들을 제공해 프로그래머들의 편의를 제공하고 있다.

여기서 잠깐 왜!!!! 우리는 CI를 서버를 사용해야 하는가? 솔직히... 한 두명이서 프로그램을 개발부터 배포 관리를 한다면 구지 CI서버를 설치할 필요는 없다. 왜? 혼자 하니까 자기 컴퓨터가 곧 테스트 서버이기 때문이다. 하지만, 그렇다 하더라도 실제 서버에 배포를 하는 작업은 언제나 까다롭다. 또한 팀별로 프로젝트를 한다면 통합 및 배포가 그만큼 더 어려워진다. 그!런!데! CI 서버 이놈이 우리를 대신해 테스트도 해주고, 리포트도 올려주고, 통합 빌드 및 배포까지 해준다니.... 구지 안쓰겠다고 마다할 필요가 없다.

그래서 이 포스트에서는 이놈을 어떻게 설치하고 셋업을 하는지 알아보도록 하자! 

우리의 목표는 위의 작업을 한!방!에! 자동으로 해주는 CI서버를 구축하는 것이다.

설치

솔직히 설치는 이렇게 설명하기 민망할 정도로 쉽다.

윈도우

http://Jenkins-ci.org 에 방문하여 자신에게 맞는 버전을 다운 받고, 보통의 프로그램 설치하듯 진행을 하면 설치는 완료 된다. Jekins를 설치하고 나면 로컬호스트(127.0.0.1:8080)의 기본포트는 8080으로 호스팅이 된다. 기본포트 8080을 바꾸고 싶다면 jenkins를 설치한 폴더(보통은 C:\Program Files (x86)\Jenkins)안에 Jenkins.xml을 열어

<arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=8080</arguments>

위의 빨간 부분을 원하는 포트로 바꾸면 된다.

설치를 다했다면 로컬호스트:변경한포트 (http://127.0.0.1:8086)로 접속해 보자. 

리눅스

아래와 같이 Jenkins를 다운 받고

wget -P /yourDesireDirectory http://mirrors.jenkis-ci.org/war-stable/latest/jenkis.war

아래와 같이 인스톨을 하자!

java -jar /DownloadedDirectory/Jenkins.war

마찬가지로 8080을 사용하고 있다면  "/etc/systemconfig/Jenkins"를 열어 아래부분을 원하는 포트로 변경하자.

## Type:        integer(0:65535)
## Default:     8080
## ServiceRestart: jenkins
#
# Port Jenkins is listening on.
# Set to -1 to disable
#
JENKINS_PORT="8086"

설치를 다했다면 마찬가지로 자신의 젠킨스에 접속해보자. ( http://127.0.0.1:8086 )
 

기본 설정

자 설치한 젠킨스에 접속을 해보니, 모든 권한을 가지고 있다. 물론 내부적으로 몇명만 사용하는 경우라면 상관이 없겠지만, 만약 모르는 누군가가 들어와서 어렵게 만들어 놓은 작업들이 망쳐 놓은다면 큰 낭패를 볼 것이다. 그래서 일단 손님들로 부터 사용권한을 빼앗도록 하자.

젠킨스 왼쪽 메뉴의 "Manage Jenkins" 클릭하고, 가운데 "Configure Global Securiy" 페이지로 들어가자!

위의 그림은 이미 설정을 바꿔 놓은 화면이지만, 실제로는 "Anyone can do anything"이라는 무시무시한 설정으로 되어 있다. 여기서 잠깐 선택 내용들을 살펴보도록 하자. 

Security Realm은 어떤 데이터 베이스를 사용자 데이터 베이스로 사용할 지 선택하는 부분이다.

   Delegate to servlet container. 사용자를 git, sebversion, whoAmI 혹은 다른 곳에서 가져와 사용하고 싶을때 선택한다. 

   Github Authentication Plugin. 사용자를 GitHub에서 인증 받아 사용할 때 선택 한다 (플러그인을 설치해야 사용가능)

   Jenkins' own user database 사용자를 젠킨스에서 직접 만들어 사용할 때 선택한다. (본 포스트에서는 이것을 사용)

   LDAP 윈도우 서버의 엑티브 디렉토리에서 설정한 사용자를 가져와 사용할 때 선택한다.

인증 부분은 그냥 읽어도 알 수 있는 내용들이기 때문에 설명은 생략하도록 하겠다.

이제 빨리 손님에게서 권한을 빼앗고, 로그인한 유저들에게도 필요한 권한만 주도록 만들어보자.

위에서 설명한 것 같이 "Jenkins' own user databse"를 선택하고 "Logged-in users can do anything"을 선택하자. 왜냐하면 현재 본인도 등록이 되어있지 않기 때문에 다른 것을 선택하면 자신도 접속을 못해 젠킨스를 다시 깔아야하는 불상사를 초래할 수 도 있기 때문이다. Save를 누르면 이제 본인에게도 (손님) 권한이 사라진 것을 확인할 수 있다. 그럼 "sign up"을 눌러 사용자를 만든다. 사용자를 만들면 다시 모든 권한이 부여된 것을 볼 수 있다. 그럼 이제 로그인 한 사용자들에게 알맞는 권한을 부여하고 자신에게는 모든 권한을 갖는 어드민 권한으로 만들어보자.

아까와 마찬가지로 "Manage Jenkins"안에 "Configure Global Security"에 들어가서 Authorization에서 "Matrix-based security"를 선택하자.(위의 그림 참조) User/group to add 텍스트박스에 본인의 아이디를 넣고 "Add"를 클릭한다. 여기서

잠깐!!!!! 절대 엔터키를 누르지 말자!! 습관적으로 우리는 입력후 엔터를 치는데, 본 페이지에서 엔터를 누르면 젠킨스는 페이지 세이브를 실행시키고, 아무 권한도 없는 본인은 앞으로 젠킨스 설정에 들어갈 수 없다... 그리고 젠킨스를 다시 설치해야하는 상황이 벌어진다. 본인을 넣었으면 위의 그림과 같이 자신에게는 모든 권한을 부여하고..(오른쪽 엑스표 옆에 아이콘이 전체선택/해제 아이콘) Anonymous(손님)에게는 읽기 권한만 주자. 그리고 세이브를 하면 이제 본인은 어드민 계정이 되고 다른 사용자들에게 필요한 권한을 줄 수 있다.

가장 처음에 언급한 것과 같이 젠킨스는 약 1000정도의 플러그인을 제공하고 있다. 그래서 다 설치할 수는 없고 자신에게 필요한 플러그인들을 선택해서 설치해야 한다. 플러그인들을 살펴보면 크게 빌드관련, 테스트 관련, 그리고 리포트 관련 플러그인들로 나눌 수 있다. 나도 많은 플러그인 들을 설치해보지는 않았으나, 유용한 플러그인들 몇가지를 적도록 하겠다.

Ant Plugin (Apache Ant Builder)

Git Client Plugin, GIT plugin (Integrates Git)

GitHub API Plugin, Github Authentication Plugin, GitHub plugin, GitHub pull request builder plugin (Using Github)

Marven Project Plugin

MSBuild Plugin

MSTestRunner plugin

NAnt Plugin

NUnit plugin

Post-Build Script Plug-in

Team Foundation Server Plug-in

그외 중복 코드를 체크하는 Duplicate Code Scanner Plug-in 코드 복잡도를 체크하는 NSIQ Collector plugin등은 매우 유용하게 사용된다. 이외에도 시간이 있다면 플러그인들을 살펴보고 자신에게 알맞는 플러그인들을 설치해보는 것도 좋다.

플러그인 설치는 "Manage Jenkins"안에 "Plugin Manager"에서 찾고 설치할 수 있다.

그럼 마지막으로 젠킨스 설정에 대해서 알아보도록 하자. Manage Jenkins 안에 Configure System을 누르면 아래 그림과 같은 페이지가 나타난다.

젠킨스 설정은 조금만 보면 알겠지만, 사실 사용할 프로그램의 위치를 맵핑해주는 것이 다다. 그런데 그말을 바꿔 말한다면 필요한 프로그램이 젠킨스 서버에 설치가 되어 있어야 한다는 말이다.(뭐 빌드를 하려면 당연한 이야기이지만..) 예를 들어보자면 Visual Studio 프로젝트를 빌드하고 테스트를 하려면 위의 설정 부분에서 MSBuilde.exe파일과 MSTest.exe파일의 위치를 멥핑해주면 된다. 모든 설명은 아래 그림으로 대처하겠다.

이상으로 젠킨스 설치와 설정에 관련된 포스트를 마치도록 하고, 다음에는 실질적으로 Auto-Build와 Auto-Deploy에 관한 Job을 만드는 과정에 대해 알아보도록 하자.

출처 : http://rakisis.tistory.com/8

정적 테스트(Static Test)

개발된 프로그램을 돌려보지 않고, 명세서나 코드만을 보고 테스트를 하는 방법이다. 말그대로 정적인 테스트이다.

정적테스트안에서 화이트 박스 / 블랙 박스 테스트로 나눌 수 있다.

정적 화이트박스 테스트(Static WhiteBox Test)

프로그램을 실행하지 않고 소프트웨어의 설계, 코드나 구조 등에서 상세하게 버그를 찾을 수 있는 방법이다.

테스트하는 방법으로는 동료검토(Peer Reviews), 워크스루(Walk throughs), 검사(Inspections) 등이 있다.

이 테스트를 하기 위해서 일반적으로 데이터 참조오류, 데이터 선언 오류, 연산 오류, 비교 오류, 제어흐름 오류, 파라미터 오류, 입출력 오류 등과 같은 코드 검토 체크리스트를 사전에 정해놓고 검사한다.

정적 블랙박스 테스트(Static BlakBox Test)

프로그램의 소스코드를 파악할 수도 없고, 실행시키지도 않는 상태에서 수행하는 검사이다. 따라서 프로그램 명세서에 대한 테스트가 이에 해당한다.

제품 개발의 방향을 잡아주는 개발 명세서의 완결성, 정확성, 정밀성, 일관성, 연관성, 실행 가능성, 코드와의 무관성, 테스트가능성 등을 판단하는 작업이다.

기획팀에서 만든 프로젝트 기획문서를 보고 리뷰를 하면서 개선사항, 문제가 될만한 부분들, 구현가능성, Validation 체크 등에 대한 사항들을 기획팀에 많이 피드백을 준다

동적 테스트(Dynamic Test)

정적테스트와 달리 개발된 프로그램을 돌려보면서 테스트를 하는 방법이다.  직접 실행하면서 개발이 잘 되었는지, 특정한 상황에 대해 오류가 발생하지는 않는지 검사를 한다.

동적 화이트박스 테스트(Dynamic Whitebox Test)

쉽게 말하면 , 프로그램을 돌리면서 소스코드를 확인하는 방법이다.

코드의 역할과 작동 방법을 관찰하여 테스트에서 배재할 대상이나, 중점적으로 보아야 할 영역, 테스트 접근 방법등을 결정한다.

코드의 근본적인 구조를 관찰하고 이를 사요하여 테스트를 설계하고 수행한다는 측면에서 구조적 테스팅(Structual Test)이라고도 불린다.

소프트웨어를 제어하면서 직접 테스트를 진행한다.

동적 화이트 박스 vs 디버깅

가만히 살펴보면 디버깅과 동적 화이트박스 테스트가 뭐가 다른지 혼란스러울 수 있다.

동적 화이트 박스 테스트의 목표는 버그 발견.

디버그의 목표는 발견된 버그에 대한 수정.

하지만 버그가 발생하는 곳, 원인을 분리하려는 영역에서는 중복된다고 볼 수 있다.

동적 블랙박스 테스트(Dynamic BlackBox Test)

동적 화이트박스 테스트가 소스코드를 분석하며 프로그램을 돌리는 방식이였다면, 블랙박스 테스트는 소스코드의 구조는 배제한체 그저 프로그램을 실행하며, 사용자의 입장에서 테스트를 진행하는 방식으로 볼 수 있다.

실제 수행하며 테스트하는 의미로 동작 테스트(Behavioral test)라고도 한다.

테스트 케이스를 설계하고 이에 따라 테스트를 수행해보면서 문제점을 발견한다.

여러가지 상황에 대해 프로그램이 정상적으로 동작하는지, 오류처리는 제대로 되는지에 대한 테스트를 수행하는데,

당연히 이 세상에 존재하는 모든 입력값이나 상황들을 조합해서 테스트를 할 수 없기 때문에 상황에 따라 ‘적당한’  테스트 케이스를 설계하는것이 필수적이다.

그 기법으로는 동등분할(Equivalence partitioning), 경계값 분석(Boundary condition),  실패를 위한 상태 테스트(반복, 스트레스, 부하) 등이 있다.

Regression testing ( 리그레션 테스트 )

- 회귀테스트 라고 함

- 테스트의 중복을 피하기 위하여 테스트 재사용

- 유지보수 단계의 테스트

- 반복 수행됨며 대개는 서서히 변경되기 때문에 자동화 대상으로 고려 가능

- 두자기 의미

  > 오류를 발견하여 고치고 다시 원래 문제를 일으켰던 것을 테스트 확인.

     수정이 예상대로 되었는지 확인

     수정된 것이 반복 테스트

  > 수정된 부분이 다른 부분에 영향을 주어 예상하지 않은

     오류를 발생시키지 않는지 확인

     수정 후 프로그램의 통합이 제대로 이루어졌는지 확인

테스트를 계획, 설계, 실행하는 테스트 프로세스 동안 생성된 산출물. 테스트웨어는 테스팅에 사용되는 문서, 스크립트, 입력값, 예상 결과, 시작과 마무리 절차, 파일, 데이터베이스, 환경, 그리고 모든 추가적인 소프트웨어 또는 유틸리티를 포함한다. [Fewster and Graham 따름]

* Artifacts produced during the test process required to plan, design, and execute tests, such as documentation, scripts, inputs, expected results, set-up and clear-up procedures, files, databases, environment, and any additional software or utilities used in testing. [After Fewster and Graham]

1.4 테스트 프로세스의 기초(Fundamental test process)

테스팅의 가장 명백한 부분은 테스트를 실행하는 것이다. 그러나 효과적이고 효율적인 테스팅이 되기 위해서는 테스트를 계획하고, 테스트 케이스를 설계하고, 실행을 준비하고 상태를 평가하는데 보내는 시간 역시 포함되어야 한다.

기본적인 테스트 프로세스는 다음의 주된 활동들(activities)로 구성된다.

 - 계획과 통제 (Planning and Control)
 - 분석과 설계 (Analysis and Design)
 - 구현과 실행 ( Implementation and Execution)
 - 종료 기준의 평가와 보고 (Evaluating exit criteria and Reporting)
 - 테스트 마감 활동들 (Test closure activities)

논리적으로는 순차적이지만, 프로세스내의 활동들은 중첩되거나 동시에 진행될 수 있다.

1.4.1 테스트 계획과 제어/통제(Test planning and Control)

테스트 계획 수립은 테스팅의 목표와 임무(Mission)를 달성하기 위해 목표와 임무를 면밀히 확인하는 활동이고, 테스팅의 목표 달성을 위해 필요한 활동 내역을 정의하는 것이다.

테스트 계획이란 테스트 임무를 확인하고, 테스트 목적과 어떻게 테스트 할것인지를 정의하는 행위이다.

Test planning is the activity of verifying the mission of testing, defining the objectives of testing and the specification of test activities in order to meet the objectives and mission.

테스트 제어(Control)는 실제 진행상황과 계획을 비교하고, 계획의 오차를 포함한 진행 상태를 보고하는 계속 진행되는 활동이다. 테스트 제어는 프로젝트의 임무와 목표를 만족시키기 위하여 필요한 활동들(actions)을 포함한다. 테스팅을 통제하기 위해서는, 프로젝트 전체에 걸쳐 모니터링 되어야 한다. 테스트 계획은 모니터링과 통제 활동으로 부터 피드백(feedback)을 받는다.

Test control is the ongoing activity of comparing actual progress against the plan, and reporting the statues, including deviations from the plan. It involves tasking actions necessary to meet the mission and objectives of the project. In order to control testing, it should be monitored throughout the project. Test planning takes into account the feedback from monitoring and control activities.

테스트 계획(Test Planning)은 다음의 주요 작업들(tasks)을 포함한다.

 - 테스팅의 범위와 위험을 결정하고, 테스팅의 목표를 정한다. 

 - Determining the scope and risks, and identifying the objectives of testing.

 - 테스트 방법을 정한다.(기법, 테스트 항목, 적용 범위, 테스팅에 포함되는 팀들간의 정의와 조정, 테스트웨어)
 - Determining the test approach (techniques, test items, coverage, identifying and interfacing the teams involved in testing, testware).

 - 요구되는 테스트 자원을 정의한다. (e.g 인력, 테스트 환경, PC등)
 - Determining the required test resources (e.g. people, test environment, PCs).

 - 테스트 정책과/또는 테스트 전략을 결정한다.
 - Implementing the test policy and/or the test strategy.

 - 테스트 분석과 설계 작업을 계획한다. 
 - Scheduling test analysis and design tasks.

 - 테스트 구현과 실행 그리고 평가를 계획한다.
 - Scheduling test implementation, execution and evaluation.

 - 종료 기준을 결정한다.

 - Determining the exit criteria.

테스트 제어(Control)는 다음의 주요한 작업들을 포함한다.

 - 결과의 측정과 분석

 - measuring and analyzing result.

 - 프로세스, 테스트 적용범위(test coverage), 그리고 종료 기준(exit criteria)의 모니터링과 문서화

 - monitoring and decumenting progress, test coverage and exit criteria.

 - 올바른 동작의 초기화

 - initiation of corrective actions.

 - 의사결정

 - making decisions.

1.4.2 테스트 분석과 설계(Test analysis and design)

테스트 분석과 설계는 일반적이고 추상적인 테스팅 목적을 실제적이고 구체적인 테스트 상황(Test conditions)과 설계(Design)로 변환하는 활동이다.

Test analysis and design is the activity where general testing objectives are transformed into tangible test conditions and test design.

테스트 분석과 설계는 다음의 주요한 작업을 포함한다.

 - 테스트 관련 기본사항을 검토한다.(요구사항, 아키텍쳐, 디자인, 인터페이스)
 - Reviewing the test basis (such as requirements, architecture, design, interfaces)

 - 테스트 조건 또는 테스트 요구사항과 테스트 항목, 명세, 동작과 구조에 분석을 기초로 필요한 테스트 데이터를 정의한다.
 - Identifying test conditions or test requirements and required test data based on analysis of test items, the specification, behavior and structure.

 - 테스트들(tests)을 설계한다.
 - Designing the tests.

 - 시스템과 요구사항의 테스트 가능성을 평가한다.

 - Evaluation testability of the requirements and system.

 - 테스트 환경을 설정하고, 테스트에 요구되는 기반 구조와 도구를 정의한다.

 - Designing the test environment set-up and identifying any required infrastructure and tools.

1.4.3 테스트 구현과 실행(Test implementation and execution)

테스트 구현과 실행은 테스트 상황을 테스트 케이스나 테스트웨어로 변환하는 활동이다. 이때에는 테스트 실행에 필요한 테스트 환경이 구축되어 있어야 한다.

Test implementation and execution is the activity where test conditions are transformed into test cases and testware, and the environment is set up.

테스트 구현과 실행은 다음의 주요한 작업을 포함한다.

 - 테스트 케이스의 개발과 우선 순위화, 테스트 데이터의 생성, 테스트 절차(test procedures)의 작성, 그리고 테스트 장치의

    준비와 자동화된 테스트 스크립트 작성
- Developing and prioritizing test cases, creating test data, writing test procedures and, optionally, preparing test harnesses and writing automated test scripts.

 - 효과적인 테스트 실행을 위한 테스트 케이스들로 부터의 테스트 슈트(test suite) 작성
 - Creating test suites from the test cases for efficient test execution.

 - 테스트 환경이 올바르게 설정되었는지의 검증
 - Verifying that the setst environment has been set up correctly.

 - 계획된 순서에 따라 수동이나 테스트 실행 도구에 의한 테스트 케이스의 실행
 - Executing test cases either manually or by using test execution tools, according to the planned sequence.

 - 테스트 실행의 결과 로깅과 테스트웨어, 그리고 테스트 도구, 테스트 중인 소프트웨어의 버전과 특성(identities)들을 기록
 - Logging the outcome of test execution and recording the identities and versions of the software under test, test tools and testware.

 - 실제 테스트 결과와 예상 테스트 결과의 비교
 - Comparing actual results with expected results.

 - 실제 테스트와 예상 테스트 결과 사이의 불일치(discrepancies)를 보고하고, 그 원인을 찾기 위하여  분석한다.

   (e.g 코드, 특정 테스트 데이터, 테스트 문서안의 결점이나 실행된 테스트 방법 내의 잘못)
 - Reporting discrepancies as incidents and analyzing them in order to establish their cause.

   (e.g a defect in the code, in specified test data, in the test document, or a mistake in the way the test was executed)

 - 각각의 불일치에 대하여 취해진 행위의 결과와 같은  테스트 활동을 반복한다. 예를 들어, 이전에 실패한 테스트의 재실행(re-execution)은 잘못을 수정한 것을 확인하기 위한 것이다. (확인 테스트-confirmation test) 정정된 테스트의 실행과/또는 다른 테스트들의 수행은 소프트웨어의 변경되지 않은 부분에는 아직 결점이 나타나지 않았다는 것과 결점을 고친 것이 다른 결점들을 커버 하였다는 것을 확신하기 위해서 진행된다.(회귀테스팅-regression testing)

1.4.4 테스트 완료 조건과 리포팅(Evaluating exit criteria and reporting)

"완료 조건 평가"는 초기에 정의된 테스트 목표에 비해 어느 정도 실제 테스트가 실행되었는지를 평가하는 활동이다. 테스트 목표를 달성하였다면 테스트가 완료된다. 그렇지 않다면 추가적인 테스트를 통해 테스트 목표를 달성할 것인지, 아니면 목표를 변경하여(필요시 추가적인 테스트를 실행한 후) 테스트를 완료할 것인지를 결정하여야 한다. 해당 활동은 각 테스트 레벨(Test Level - 컴포넌트, 통합, 시스템, 인수 테스팅)마다 수행되는 것이 원칙이다.

종료 기준을 평가하는 것은 다음의 주요한 작업을 포함한다.

 - 테스팅 계획에 정의된 종료 기준에 비교하여 테스트 로그들(logs)을 확인한다.
 - 더 많은 테스트가 필요한지, 정의된 종료 기준이 변경되어져야 하는지를 평가한다.
 - 이해당사자를 위한 테스트 요약 보고서를 작성한다.

1.4.5 테스트 마감 활동(Test Closure activities)

테스트 마감은 완료된 테스트 활동에서 데이터를 수집하여, 테스트에서 발견된 사실과 수치는 물론 테스팅 경험과 테스트웨어를 종합하고 축적하는 활동이다. 테스팅이 얼마나 체계적으로 수행되었는지 평가하고 향후 테스팅을 개선하기 위해 업계 모범 사례(Best practices)를 모델로 테스트 프로세스를 심사(평가)하는 것 또한 테스트 마감 활동의 중요한 부분이다.

테스트 마감 활동은 소프트웨어 시스템이 출시되어 테스트 프로젝트가 완료 되었을 때(또는 취소되었을 때), 계획된 모든 마일스톤이 달성되었을 때, 또는 유지보수 활동 중 추가 개발되거나 업데이트된 부분이 출시 완료되었을 때 발생한다.

Test closure activities collect data from completed test activities to consolidate experience, testware, facts and numbers. From example, when a software system is released, a test project is completed (or cancelled), a milestone has been achieved, or a maintenance release has been completed.

테스트 종료 액티비티는 다음의 주요한 작업을 가진다.

 - 부가적인 사건의 종료 보고서와 오픈된(opened) 상태로 남아 있는 부분에 대하여 일어나는 변경 기록들, 그리고 시스템의

    승인에 대한 문서와 같은 계획된 소프트웨어 구성요소들이 전달(deliverables)되었는가 확인한다. 
 - 테스트웨어, 테스트 환경 그리고 테스트 기반 구조를 정리하고 최종적으로 승인한다. 
 - 유지보수 조직에 테스트웨어를 이양한다.
 - 다음 프로젝트와 릴리즈 그리고 테스트 성숙도의 향상을 위하여 경험으로 배운  사항(lessons learned)을 분석한다.

소프트웨어 업계에서는 일단 제작되어 다른 사람에게 전달되는 소프트웨어 제품 구성요소를 deliverable이라 한다.

초기 구상 단계부터 대중에게 출시되기까지 소프트웨어 제품을 만드는 데 사용되는 과정을 소프트웨어 수명주기 모델이라고 한며 가장 많이 사용되는 모델은 다음의 4가지 모델이다.

 - 빅뱅 (Big-bang) 모델
 - 코딩- 수정(Code-and-Fix) 모델
 - 폭포(Waterfall) 모델
 - 나선형(Spiral) 모델   

Test Plan (테스트 계획)

  Purpose
    - Test의 개요를 정의한다.
    - 테스트 전략 및 테스트 수행의 개요를 정의한다.

  Goal of the Test
    - Test의 최종 목표를 정의한다.

  Scope of the Test
    - 테스트 대상 기능과 비 대상 기능을 정의한다. 해당 기능들은 업무요구 사항 및 기술 요구 사항에 정의되어 있어야 한다.

Test Estimation (테스트 견적)

  예측 방법 
    - 과거 프로젝트나 유사 프로젝트의 매트릭을 근거로 테스트 업무량(effort) 예측
    - 전문가나 테스크의 주체에 의한 예측

  테스팅 업무량에 영향을 주는 요소들
    - 제품의 특성 : 테스트 베이스의 품질, 제품 사이즈, 문제 도메인의 복잡성, 신뢰성 및 보안성 요구수준, 문서화 요구수준
    - 개발 프로세스 특성 : 조직의 안정성, 사용한 틀, 테스트 프로세스, 관여자들의 스킬 수준, 시간 압박 정도
    - 테스팅 결과물 : 결함 수와 요구되는 재작업량

Test approaches (테스트 접근)

  분석적 접근법 (Analytical approachs) : Risk-based testing
  모델 기반 접근법(Model-based approaches) : Stochastic testing(reliability growth model, operational profiles)
  Methodical approaches : Failure based(error guessing, fault-attacks), check-list based, quality characteristic based
  Process - or standard-compliant approaches
  Dynamic and heuristic approaches
  Consultative approaches (by expert advice)
  Regression-averse approaches (reuse of existing test materials and automation)

Test Strategies and factors

  테스트 전략은 무엇을 어떻게 테스트하고 어느 정도의 깊이/커버리지로 할 것인지를 결정하는 것으로

  리스크 기반 테스트 전략이 대표적이다.

  테스트 전략의 결정 요소로는 Product technology, product criticality, product complexity, component selection 등이 있다.

Risk - 시간과 자원의 한계를 고려

  Defect -> Failure -> Risk   (*Error - relate to human)
  Defect : Failure 원인 (a specific cause of failure) (Related to product)
  Failure : 의도된 기능을 수행하지 못한것 (relate to events)
  Risk : failure 때문에 주어진 기간에 발생하는 비용 Risk = failure 가능성

           Damage Chance of Failure = frequency of use

           chance of fault

Exhaustive 테스팅 전략

  모든 가능한 경우를 테스팅
  생명 관련 소프트웨어 -> Exhaustive 테스팅 & 안전분석 필요
  안전 분석을 위한 Safety manager와 엔지니어가 있어야 함

Test Environment

  테스트가 수행될 물리적 환경, H/W 환경을 정의한다.
  테스트가 수행될 S/W 환경을 정의한다.

[참고] 소프트웨어 수명 주기 모델

빅뱅 모델 (Big-Bang Model)

우주의 생성을 설명하는 이론 중 하나가 빅뱅이론이다. 수 십억년전 우주는 무한한 에너지로 인한 한 번의 거대한 폭팔로 인해 생성되었다는 것이 이 이론이다. 소프트웨어 개발에서의 빅뱅 모델도 같은 이론을 따른다. 많은 양의 물질(사람과 자본)이 한데 모여 종종 매우 격렬하게 많은 양의 에너지가 소모되고 그 결과 완벽한 소프트웨어 제품이 탄생하거나 혹은 그 반대가 된다.

빅뱅이론의 장점은 간단함이다. 계획, 일정 또는 형식적인 개발 과정이 포함된다면 이 이론의 매력은 반감된다. 모든 노력은 소프트웨어를 개발하고 코드를 작성하는데 사용되어야 한다. 이 방법은 제품의 요구사항이 분명하지 않고 최종 출시 날짜가 변동 가능할 경우에 이상적이다. 고객의 요구사항이 유동적이이어야 한다는 점 역시 중요하다. 마지막 순간까지 어떤 제품이 나올지 모르기 때문이다. 대부분의 빅뱅 모델에서는 형식적인 테스팅이 아예 없거나 거의 이루어지지 않는다. 테스팅 과정이 있는 경우에는 제품이 출시되기전 아주 잠깐 동안만 이루어진다.

코딩-수정 모델 (Coding-Fix Model)

코드-수정 모델은 프로젝트팀이 특별히 다른 모델을 사용하려는 노력을 기울이지 않는 한 대개 기본적으로 안주하게 되는 모델이다. 적어도 이 모델에서는 제품의 요구 사항이 무엇인지에 대한 생각을 필요로 한다는 점에서, 절차상으로는 빅뱅 모델보다 한 단계 위에 위치한다. 이 접근 방법을 사용하는 팀은 대개 그들이 원하는 바에 대한 대략적인 아이디어만 가지고 간단한 설계 작업을 하고 코딩, 테스팅, 버그 수정의 단계를 끊임없이 반복한다.

이 모델의 경우 계획과 문서화하는 단계가 거의 없기 때문에 프로젝트 팀은 즉시 결과를 보여줄 수 있다. 이러한 이유로 코딩-수정 모델은 프로토타입, 데모 등 빠른 시간 내에 제작하고 제작이 끝나면 금방 버리도록 계획된 작은 규모의 프로젝트에 매우 적합하다. 하지만 코딩-수정 모델은 규모가 크고 잘 알려진 많은 소프트웨어 제품에 사용되고 있다. 빅뱅 모델과 같이 코딩-수정 모델에서도 테스팅 작업이 특별히 요구되지 않지만 코딩 작업과 수정 작업 사이에 매우 중요한 역할을 담당한다.

폭포수 모델 (Waterfall Model)

이 모델에서 중요한 세가지 사실은
  
1. 어떤 제품을 만들 것인가를 명확히 해 두는 것이 매우 중요하다. 개발 및 코딩은 제품에 있어 하나의 단계에 지나지 않음을 명심해야 한다.
2. 단계는 분리되어 있고 겹치는 일이 없다.
3. 이전 단계로 되돌아 갈 수 없다. 한 단계에 발을 들여 놓은 다음에는 해당 단계에 대한 작업을 완전히 마무리 지은 후 다음 단계로 이동해야 한다.

나선형 모델 (Spiral Model)

나선형 모델의 기본 아이디어는 처음 시작 단계에서는 모든 세부 사항을 정의 할 수 없다는 것에서 출발한다. 중요한 기능을 정의하여 시도해보고 고객의 의견을 수렴한 후 다음 단계로 이동한다. 나선형 모델은 다음의 단계를 반복한다.

1. 목표, 대안, 장해 요인 결정
2. 위험 요인 확인 및 분석
3. 대안 평가
4. 현재 단계 개발 및 테스트
5. 다음 단계 계획
6. 다음 단계에 대한 접근 방법 결정

이 모델은 이상향이 아니다.

Interative and Incremental Developement & Approach

점진적으로 효과적인 결과물(해결책)을 산출하기 위해 일련의 활동(Requirement -> Analysis -> Design -> Implmentation -> System Test)을 반복적으로 적용하는 개발 스타일

 - Interative (반복적인) : 핵심적인 개발 활동을 "리스크(우선순위)"에 따라 반복적/발전적으로 적용하여 결과물/해결책 도출
 - Incremental (점차적으로 증가하는) : 반복 사이클을 통해 개발이 진행됨에 따라 "문제"에 대한 이해를 높여, 해결능력을 향상시킨다.

Waterfall VS  Interative

 - Waterfall은 결과물로 수행전까지 문서만 존재하지만 Iterative는 각 Iteration 별 실제 개발 결과물이 존재한다.
 - Waterfall은 Risk를 프로젝트 중간이후의 코딩 단계까지 가지고 가지만  Iterative는 Risk를 개발 앞단에서 처리
 - Waterfall은 개발 프로젝트 예측이 어렵지만 Iterative는 개발 프로젝트 예측이 용이하다. 

출처 :  2005년 ISTQB 시나버스 ||  http://akiss.egloos.com/2634612

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

출처 : http://www.softwaretestinghelp.com/types-of-software-testing/