2.2 - Test Levels (테스트 레벨)

terms

Alpha testing, beta testing, component testing (also known as unit, module or program testing), driver, field testing, functional requirement, 
integration, integration testing, non-functional requirement, robustness testing, stub, system testing, test level, test-driven development, test environment, user acceptance testing  

Background

For each of the test levels, the following can be identified: their generic objectives, the work product(s) being referenced for deriving test cases(i.e. the test basis), the test object(i.e. what is being tested), typical defects and failures to be found, test harness requirements and tool support, and specific approaches and responsibilities.

2.2.1 Component Testing

Component testing searches for defect in, any verifies the functioning of, software (e.g. modules, programs, objects, classes, etc) that are separately testable. it may be done in isolation from the rest of the system. depending on the context of the development like cycle and the system. stubs, drivers and simulator may be used.

Component testing may include testing of functionality and specific non-functional characteristics, such as resource-behaviour (e.g. memory leaks) or robustness testing, as well as structural testing component, the software design or the data model.

Typically, component testing occurs with access to the code being tested and with the support of the development environment, such as a unit test framework or debugging tool, and, in practice usually involves the programmer who wrote the code Defects are typically  fixed as soon as they found, without formally recording incidents.

One approach to component testing is to prepare and automate test cases before coding. this is called a test-first approach or test-driven development. This approach is highly iterative is based on cycles of developing test cases, then building and integrating small pieces of code, and executing the component tests until they pass.

2.2.2 Integration testing

Integration tests interfaces between component. interactions with different parts of a system, such as the operation system, such as the operating system, file system, hardware, or interfaces between systems.

There may be more than one level of integration testing and it may be carried testing and it may be carried out on test objects of varying size. For example:

1. Component integration testing tests the interactions between software component and is done after component testing;

2. System integration testing tests the interaction between system and may be done after system testing. in this case, the developing organization may control only one side of the interface, so changes may be destabilizing. Business processes implemented as workflows may involve a series of system. Cross-platform issue may be significant.

the greater the scope of integration, the more difficult it becomes to isolate failure to a specific component or system, which may lead to increased risk.

systematic integration strategies may be based on the system architecture (such as top-down and bottom-up), functional tasks, transaction processing sequences, or some other aspect of the system or component. in order to reduce the risk of late defect discovery, integration should normally be incremental rather than "big bang"

Testing of specific non-functional characteristics (e.g. performance) may be included in integration testing.

At each stage of integration, testers concentrate solely on the integration itself. For example, if they are integrating module A with module B they are interested in testing the communication between the modules, not the functionality of either module. Both functional and structural approaches may be used.

Ideally, testers should understand the architecture and influence integration planning. If integration tests are planned before components or systems are built, they can be built in the order required for most efficient testing.

2.2.3  System testing 

system testing is concerned with the behaviour of a whole system/product as defined by the scope of a development or programme.

In system testing, the test environment should correspond to the final target or production environment as much as possible in order to minimize the risk of environment-specific failures not being found in testing.

System testing may include tests based on risks and/or on requirements specifications, business processes, use cases, or other high level descriptions of system behaviour, interactions with the operating system, and system resources.

system testing should investigate both functional and non-functional requirements of the system.

Requirements may exist as text and/or models. Testers also need to deal with incomplete or undocumented requirements. System testing of functional requirements starts by using the most appropriate specification-based (black-box) techniques for the aspect of the system to be tested. For example, a decision table may be created for combinations of effects described in business rules. Structure-based techniques (white-box) may then be used to assess the thoroughness of the testing with respect to a structural element, such as menu structure or web page navigation. (See Chapter 4.)

An independent test team often carries out system testing.

2.2.4  Acceptance testing

Acceptance testing is often the responsibility of the customers or users of a system; other stakeholders may be involved as well.

The goal in acceptance testing is to establish non-functional characteristics of the system. Finding defects is not the main focus in acceptance testing. Acceptance testing may assess the system's readiness for deployment and use, although it is not necessarily the final level of testing. For example, a large-scale system integration test may come after the acceptance test for a system.

Operational (acceptance) testing

The acceptance of the system by the system administrator, including 

- testing of backup/restore;

- disaster recovery;

- user management;

- maintenance tasks;

- periodic checks of security vulnerabilities.

Contract and regulation acceptance testing 

Contract acceptance testing is performed against a contract's acceptance criteria for producting custom-developed software. Acceptance criteria should be defined when the contract is agreed. Regulation acceptance testing is performed against any regulations that must be adhered to, such as governmental, legal or safety regulations.

Alpha and beta (or field) testing

Developers of market, or COTS, software often want to get feedback from potential or existing customers in their market before the software product is put up for sale commercially. Alpha testing is performed at the developing organization's site. Beta testing, or field testing, is performed by people at their own locations. Both are performed by potential customers, not the developers of the product.

Organizations may use other terms as well, such as factory acceptance testing and site acceptance testing for systems that are tested before and after being moved to a customer's site.

용어

알파 테스팅, 베타 테스팅, 컴포넌트 테스팅 (유닛, 모듈 또는 프로그램 테스팅), 드라이버, 필드 테스팅, 기능 요구사항, 통합, 통합 테스팅, 비기능 요구 사항, 강건성 테스트,

시스템 테스팅, 테스트 레벨, 테스트 주도 개발, 테스트 환경, 인수 테스팅

배경

각각의 테스트 레벨에 대해 다음의 내용이 독립적으로 식별될 수 있다. 일반적인 목펴(목적), 테스트 케이스를 도출해 내는데 참조되는 개발 중간 산출물(테스트 베이시스), 테스트 대상(테스트 되어진 무엇), 발견된 전형적인 결함과 장애, 테스트 하네스(드라이버) 필요 여부와 툴 지원의 필요성, 특정한 테스트 접근법과 담당 책임(테스팅 주체 또는 조직)

2.2.1 컴포넌트 테스팅 또는 단위 테스팅

컴포넌트 테스팅은 테스트 가능한(최소) 단위로 분리된 테스트 소프트웨어(모듈 ,프로그램, 객체, 클래스 등) 내에서 결함을 찾고 그 기능을 검증하는 것이다. 컴포넌트 테스팅은 개발 생명주기와 시스템에 의존적이면서 시스템의 다른 부분에서 격리되어 독립적으로 수행할 수 있다. 이때, 스텁과 드라이버, 시뮬레이터가 사용될 수 있다.

컴포넌트 테스팅은 구조적인 테스팅 (분기 커버리지 등)은 물론 기능성 테스트와 리소스 관련(메모리 유출 등) 테스팅 또는 강건성 테스팅과 같은 특정 비기능성 테스트를 포함한다. 테스트 케이스는 컴포넌트 명세, 소프트웨어 상세 설계 또는 데이터 모델 명세와 같은 개발 중간 산출물에서 도출된다.

일반적으로 컴포넌트 테스팅은 코드를 중심으로 수행하며, 단위 테스트 프레임 워크 또는 디버깅 툴 같은 개발 환경의 지원을 필요로 하여, 실무에서는 코드를 작성한 프로그래머가 테스트에 참여한다. 일반적으로 결점은 발견될 때마다 수정되며, 정규적인 결함 기록 과정은 생략하는 것이 일반적이다.

컴포넌트 테스팅 접근법 중의 한 가지는 코딩 전에 테스트 케이스를 준비하고 자동화하는 것이고, 이것이 테스트 중심의 개발 방법론(Test-first approach 또는 test-driven development)이다. 이 접근법은 대단히 반복적이며, 테스트 케이스를 개발한 후 작은 규모의 코드를 작성하여 통합하고, 이것이 테스트를 통과할 때까지 컴포넌트 테스트를 실행하는 주기에 기반하고 있다.

2.2.2 통합 테스트

통합 테스팅은 컴포넌트 간의 인터페이스를 테스트 하는 것은 물론, OS, 파일 시스템, 하드웨어 또는 시스템 간 인터페이스와 같은 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트한다. 

통합 테스팅은 하나 이상의 테스트 레벨이 있을 수 있으며, 다양한 크기의 대상에 대해 수행될 수 있다. 예를 들면,

1. 컴포넌트 통합 테스팅은 소프트웨어 컴포넌트 사이의 상호작용을 테스트하며, 컴포넌트 테스팅 이후에 수행된다.

2. 시스템 통합 테스팅은 시스템 사이의 상호 작용을 테스트 하며, 시스템 테스팅 이후에 수행된다. 이 경우에 개발 조직은 인터페이스의 한 면만을 제어하게 되어 변경 사항은 시스템 전체 차원에서의 불안정을 유발할 수 있다.

통합하는 범위가 크면 클수록 장애가 특정 컴포넌트나 시스템에서 기인한 것으로 격리하는 것이 더 어려워 지고, 이는 개발의 리스크(Risk)를 증가시킨다.

상향식, 하향식, 백본 통합과 같은 체계적인 통합 전략은 시스템 아키텍쳐, 기능적인 작업, 트랜잭션 처리 순서, 시스템 또는 컴포넌트의 다른 측면 등에 따라 다양화 할 수 있다. 뒤늦은 결점 발견으로 발생할 수 있는 리스크를 줄이기 위해, 일반적으로 통합은 '빅뱅(Big Bang)' 보다는 '순차적(incremental)'이어야 한다.

통합 테스팅은 기능적 특성은 물론 특정한 비기능적 특성(예, 성능)을 테스트 하는 것을 포함해야 한다.

테스터는 통합의 각 단계에서 통합 그 자체에만 집중한다. 예를 들어, 모듈 A와  B를 통합한다면, 모듈간의 통신하는 기능에 집중하여 테스트하고, 개별 모듈의 기능성에는 관심을 두지 않는다. 통합 테스팅을 기능적이고 구조직인 접근법을 모두 사용할 수 있다.

이상적으로 테스터가 아키텍쳐에 대한 이해를 바탕으로 통합 테스팅 계획에 관여해야 한다. 통합 테스트가 컴포넌트 또는 시스템이 만들어지기 전에 계획된다면, 통합 테스트는 가장 효율적인 테스팅을 수행할 수 있도록 고안될 수 있다.

2.2.3 시스템 테스팅

시스템 테스팅은 개발 프로젝트 차원(범위)에서 정의된 전체 시스템/제품의 동작과 관련이 있다. 

시스템 테스팅의 테스트 환경은 테스팅으로 발견하지 못하여 발생할 수 있는 "환경 제한적 장애 (Environment-specific failure)" 관련 리스크를 최소화하기 위해서 가능한 실제 최종 사용 환경과 유사해야 한다.

시스템 테스팅 수행은 리스크 분석서, 요구사항 명세, 비지니스 프로세스, 유즈케이스, 기타 비지니스 레벨의 시스템 동작 명세, OS 및 시스템 리소스와의 상호작용을 포함할 수 있다.

시스템 테스팅은 기능적 / 비기능적 시스템의 요구 사항을 모두 포함해야 한다. 여기서 요구사항은 텍스트나 모델의 형태로 존재하는 경우가 많다. 테스트 엔지니어는 불완전하거나 문서 형태를 갖추지 못한 요구 사항을 기반으로 테스트하게 되는 경우도 고려해야 한다. 기능적인 요구 사항의 시스템 테스팅은 테스트 대상의 특성에 가장 적절한 명세기반(블랙박스) 기법을 사용한다. 예를 들어, 비지니스 룰에 표현 된 결과들의 조합을 테스트하기 위해 결정 테이블(Decision table) 기법을 사용할 수 있다. 그런 다음, 메뉴 구조나 웹 페이지 네비게이션과 같은 구조적인(비기능적인) 요소에 대한 테스팅이 얼마나 완벽하게 수행되었는지 평가하기 위해 구조 기반 기법(화이트 박스)을 사용할 수 있다. (챕터 4 참고)

시스템 테스팅은 독립적인 테스트 팀이 수행하는 경우가 대부분이다.

2.2.4 인수 테스팅

인수 테스팅은 시스템을 사용하는 고객이나 사용자가 전담하여 수행하는 경우가 대부분인데, 다른 관련자들도 참여할 수 있다.

인수 테스팅의 목적은 시스템이나 시스템의 일부 또는 특정한 비기능적 특성에 대해 '확신(Confidence)'를 얻는 것이다. 결함을 찾는 것은 인수 테스팅의 주된 관심사가 아니다.

인수 테스팅은 시스템을 배포하거나 실제 사용할만한 준비가 되었는지에 대해 평가한다. 그러나 인수 테스팅이 반드시 최종 단계의 테스팅이라고 보기는 어렵다. 예를 들어, 대규모의 통합 테스트를 시스템에 대한 인수 테스트 이후에 실행할 수 있다.

인수 테스팅은 하나의 테스트 레벨 이상에서 수행 될 수 있다. 예를 들면,

- 상용(COTS) 소프트 웨어 제품은 설치되거나 통합되면 인수 테스트할 수 있다.

- 컴포넌트의 사용성에 대한 인수 테스팅은 컴포넌트 테스팅 동안에 수행할 수 있다.

- 새로운 기능상의 개선에 대한 인수 테스팅은 시스템 테스팅 전에 이루어질 수 있다.

인수 테스팅의 전형적인 형태는 다음과 같닫.

사용자 인수 테스팅 

일반적으로 비지니스 사용자가 시스템 사용의 적절성을 확인한다.

운영상의(인수) 테스팅

시스템 관리자에 의한 시스템의 인수 시 수행하는 테스트 활동으로 테스트 하는 항목은 다음과 같다.

- 백업 / 복원 테스팅

- 재난 복구 

- 사용자 관리 

- 유지보수 작업

- 보안 취약성에 대한 정기적인 점검

계약 인수 테스팅과 규정 인수 테스팅 

맞춤식-개발 (Custom-development) 소프트웨어가 계약상의 인수 통과 조건을 준수하는지 확인하는 테스팅이다. 인수 통과 조건은 게약이 성립 되었을 때 정의되어야 한다.

규정 인수 테스팅은 정부 지침, 법률 또는 안전 규정 등 준수해야 하는 규정에 맞게 개발 되었는지 확인하는 테스팅이다.

알파 테스팅과 베타(또는 필드) 테스팅

시장에서 판매하는 또는 상용(COTS) 소프트웨어 개발자는 종종 소프트웨어가 상업적으로 판매되기 전에 목표 시장의 기존 고객이나 잠재적인 고객으로부터 피드백을 받고 싶어한다. 알파 테스팅은 개발하는 조직 내에서 잠재적인 고객에 의해 수행된다. 반면 베타 테스팅이나 필드 테스팅은 실제 업무 현장에 있는 인원(사용자, 잠재적인 고객)에 의해서 수행된다. 

고객사의 사이트로 이동하기 전에 개발 완료 후 테스팅 하는 소위 '공장 인수 테스팅(Factory acceptance testing)'은 알파 테스팅과 같은 의미이고, 

고객 사이트로 이동한 후에 테스팅 하는 '사이트 인수 테스팅(Site acceptance testing)'은 베타 테스팅과 같은 용어이다.