2.3 Test Types (테스트 유형)

Terms

Black-box testing, code coverage, functional testing, interoperability testing, load testing, maintainability testing, performance testing, portability testing, reliability testing, security testing, specification-based testing, stress testing, structural testing, usability testing, white-box testing

Background

a group of test activities can be aimed at verifying the software system (or a part of a system) based on a specific reason or target for testing.

 

a test type is focused on a particular test objective, which could be the testing of a function to be performed by the software; a non-functional quality characteristic, such as reliability or usability, the structure or architecture of the software or system; or related to changes, i.e confirming that defects have been fixed (confirmation testing) and looking for unintended changes (regression testing).

 

A model of the software may be developed and/or used in structural and functional testing, for example, in functional testing a process flow model, a state transition model or a plain language specification; and for structural testing a control flow model or menu structure model. 

 

2.3.1 Testing of function (functional testing)

The functions that a system, subsystem or component are to perform may be described in work products such as a requirements specification, use cases, or a functional specification, or they may be undocumented. The functions are "what" the system does.

 

Functional tests are based on functions and features (described in documents or understood by the testers) and their interoperability with specific systems, and may be performed at all test levels (e.g. tests for component may be based on a component specification).  

 

Specification-based techniques may be used to drive test conditions and test cases from the functionality of the software or system. (See Chapter 4.) Functional testing considers the external behaviour of the software (black-box testing).

 

A type of functional testing, security testing, investigates the functions (e.g. a firewall) relating to detection of threats, such as viruses, from malicious outsiders. Another type of functional testing, interoperability testing, evaluates the capability of the software product to interact with one or more specified components or system.

 

2.3.2 Testing of non-functional software characteristics (non-functional testing)

Non-functional testing includes, but is not limited to, performance testing, load testing, stress testing, usability testing, maintainability testing, reliability testing and portability testing, it is the testing of "how" the system works.

 

Non-functional testing may be performed at all test levels. The term non-functional testing describes the tests required to measure characteristics of systems and software that can be quantified on a varying scale, such as response times for performance testing, these tests can be referenced to a quality model such as the one defined in 'software engineering - software product quality' (ISO 9126).

2.3.3 Testing of software structure/architecture (structural testing)

Structural (white-box) testing may be performed at all test levels. Structural techniques are best used after specification-based techniques, in order to measure the thoroughness of testing through assessment of coverage of a type of structure.

 

Coverage is the extent that a structure has been exercised by a test suite, expressed as a percentage of the items being covered. if coverage is not 100%, then more tests may be designed to test those items that were missed and, therefore, increase coverage. Coverage techniques are covered in Chapter 4.

 

At all test levels, but especially in component testing component integration testing, tools can be used to measure the code coverage of element, such as statements or decisions. Structural testing may be based on the architecture of the system, such as a calling hierarchy.

 

2.3.4 Testing related to changes (confirmation testing (retesting) and regression testing)

after a defect is detected and fixed, the software should be retested to confirm that the original defect has been successfully removed. This is called confirmation. Debugging (defect fixing) is a development activity, not a testing activity.

 

Regression testing is the repeated testing of an already tested programs, after modification, to discover any defects introduced or uncovered as a result of the changes(s). these defects may be eigher in the software being tested, or in another related or unrelated software component. It is performed when the software, or its enviroment, is chagned, The extent of regression testing is based on the risk of not finding defects in software that was working previously.

 

Tests should be repeatable if they are to be used for confirmation testing and to assist regression testing.

 

Regression testing may be performed at all test level, and applies to functional, non-functional and structural testing. Regression test suites are run many times and generally evolve slowly, so regression testing is a strong candidate for automation.

 

 

 

용어

블랙 박스 테스팅, 코드 커버리지, 기능 테스팅, 상호 운용 테스팅, 로드 테스팅, 유지보수 테스트, 성능 테스팅, 휴대성 테스트팅 신뢰성 테스팅, 보안 테스팅,

명세 기반 테스팅, 스트레스 테스팅, 구조 테스팅, 사용성 테스팅, 화이트 박스 테스팅

 

배경 

테스팅하는 특정한 이유나 타깃을 염두에 두고, 소프트웨어 시스템(또는 시스템의 일부분)을 확인하는 목적을 달성하기 위해, 그룹의 테스트 활동이 관여될 수 있다. 테스트 유형은 다음과 같은 특정한 테스트 목적에 중점을 둔다. 소프트웨어가 수행하는 기능에 대한 테스팅; 신뢰성, 사용성과 같은 비기능적인 비기능 품질 특성 테스팅; 소프트웨어나 시스템의 구조나 아키텍쳐에 대한 테스팅; 변경 내용에 관련된 테스팅. (예를 들어, 결함에 대한 수정이 이루어졌는지에 대한 확인 테스팅(Confirmation testing)과 의도하지 않은 변경을 찾는 리그레션 테스팅(Regresstion testing)

 

기능적 그리고 구조적 테스팅(Functional and structual testing)은 소프트웨어의 모델을 이용하거나 필요한 경우 이를 생성해 낼 수 있다. 예를 들어, 기능적 테스팅은 프로세스 흐름 모델(Process flow model), 상태 전이 모델 (state transtion model)이나 평문 언어 명세(Plain language specification) 등을 이용하여 테스팅할 수 있고, 구조적 테스팅은 제어 흐름 모델(Control flow model)이나 메뉴 구조 모델(Menu structure model)등을 이용하여 테스팅 할 수 있다.

 

2.3.1 기능 테스팅

실행되어야 하는(서브)시스템 또는 컴포넌트의 기능은 요구 사항 명세, 유즈케이스 또는 기능적인 명세와 같은 개발 중간산출물(Work products)에 기술되어 있거나, 문서화되지 않을 수 있다. 여기서 기능은 시스템이 수해아는 그 "무엇"을 의미한다.

 

기능 테스팅은 문서화되어 있거나 테스터가 알고 있는 기능과 특징, 그리고 그것들과 특별한 시스템과의 상호운용성을 고려하여 수행하며 모든 테스트 레벨(Test level)에서 수행될 수 있다. (예를 들어, 컴포넌트 기능 테스트는 컴포넌트 명세를 기반으로 한다.)

 

명세 기반 기법(Specification-based technique)를 이용해 소프트웨어나 시스템의 기능성에서 테스트 조건(Test condiftion)과 테스트 케이스를 도출한다. (4장 참고).

기능적인 테스팅은 소프트웨어의 외부적인 행동을 고려한다. (블랙 박스 테스팅).

 

기능 테스팅의 한가지 형태인 보안성 테스팅(Security testing)은 악의적인 코드(바이러스 등) 와 같은 외부로부터의 위협을 감지해 내는 것과 관련이 있는 기능(방화벽)을 확인한다. 기능 테스팅의 또 다른 형태로, 상호운용성 테스팅(interoperability)은 하나 또는 여러 개의 명시된 컴포넌트나 시스템이 서로 상호작용하는 소프트웨어 제품의 능력을 평가하는 것이다.

 

2.3.2 비 기능 테스팅

비 기능 테스팅은 성능 테스팅, 부하 테스팅, 스트레스 테스팅, 사용성 테스팅, 유지보수 테스팅, 신뢰성 테스팅, 이식성 테스팅을 포함한다.

이는 시스템이 "어떻게" 동작하는지를 뜻한다.

 

비 기능 테스팅은 모든 테스트 레벨에서 수행될 수 있다. 비기능 테스팅이라는 용어는 성능 테스팅에서의 응답시간과 같이 다양한 척도 또는 스케일(Scale)로 정량화 가능한 소프트웨어나 시스템의 특성(Characteristics)을 측정하는 테스트를 의미한다. 이러한 테스트는 '소프트웨어 공학 - 소프트웨어 제품 품질(Software Engineering - Software Product Quality)' (ISO/IEC9126)에서 정의된 것과 같은 품질 모델을 참고할 수 있다.

 

2.3.3 구조적 테스팅

구조적인 (화이트 박스) 테스팅은 모든 테스트 레벨에서 수행될 수 있다. 구조적인 테스트 기법은 특정 유형의 구조 커버리지를 평가하여 테스팅은 보장성 또는 충분함 (Thoroughness)을 측정하는 것이므로 이를 위해서는 명세 기반 기법을 적용한 다음에 사용할 때 가장 좋은 결과를 보여준다.

 

커버리지는 시스템 또는 소프트웨어의 구조가 테스트 스위트에 의해 테스트된 정도를 말하며, 구조 종류에 대해 커버된 퍼센트(Percentage)로 표시한다. 만일 커버리지가 100%가 아니라면, 누락된 아이템을 테스트하기 위해 더 많은 테스트를 설계하여 커버리지를 높일 수 있다. 커버리지 관련 기법은 4장에서 다룬다.

 

모든 테스트 레벨에서, 특히 컴포넌트 테스팅과 컴포넌트 통합 테스팅 레벨에서(자동화) 도구(tools)는 선언(Statements)과 결정(Decision)과 같은 커버리지 요소를 측정하는 용도로 사용될 수 있다. 구조적인 테스팅은 코드 레벨뿐만 아니라 호출 체계(구조, Hierarchy)와 같은 시스템 아키텍쳐에 기반을 두고 수행될 수 있다.

 

또한, 구조적인 테스트 접근법은 시스템 통합 또는 인수 테스팅의 테스트 레벨(예, 비지니스 모델이나 메뉴 구조)에 적용할 수 있어 모든 테스트 레벨에서 수행될 수 있다.

 

2.3.4 확인(재)/리그레션 

결함이 발견되고 수정된 후에 소프트웨어는 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트 되어야 한다. 이것을 확인 테스팅이라 부른다. 여기서 결함을 수정하는 디버깅(Debugging)은 개발 활동이며 테스팅 활동으로 보지 않는다.

 

리그레션 테스팅(Regression tesing)은 이미 테스트된 프로그램의 테스팅을 반복하는 것으로, 결함 수정 이후 변경의 결과로 도입되었거나 발견되지 않았던 또 다른 결함을 발견하는 것이다. 이러한 결함은 테스트 중인 소프트웨어에 존재할수도 있고, 다른 관련이 있거나 전혀 관련이 없는 소프트웨어 컴포넌트에 있을 수 있다. 리그레션 테스팅은 소프트웨어 또는 그 환경이 변경되면 수행한다. 리그레션 테스팅을 수행하는 범위와 정도는 이전에 동작했던 소프트웨어에서 결함을 발견하지 못해 야기될 수 있는 리스크에 바탕으 둔다.

테스트가 확인 테스팅으로 쓰이거나 리그레션 테스팅을 보조한다면 그 테스트는 반복적인 성향을 갖게 된다.

리그레션 테스팅은 모든 테스트 레벨에서 수행될 수 있으며, 기능, 비기능 그리고 구조적 테스팅에 적용할 수 있다. 리그레션 테스트 스위트는 여러번 반복 수행되며 대개는 서서히 변화하기 때문에 리그레션 테스팅은 자동화에 적합한 후보이다.