별명

블랙박스 테스트, 펑션 테스트

 

정의

소프트웨어나 시스템의 테스트 수법 중 하나로서, 테스트 대상의 내부구조를 고려하지 않고 외부에서 본 기능이나 동작이 올바른지를 검증하는 수법의 테스트이다.

 

특징

- 입출력에만 착목하여 다양한 입력에 대해 상정한 대로 출력되는지 확인한다.

- 테스트 케이스의 작성에 내부의 처리흐름이나 프로그램 구조는 고려하지 않는다.

 

수법

단, 막무가내로 정한 입력값으로는 처리의 올바름을 확인할 수 없기 때문에 다음과 같은 수법을 사용한다.

- 사양상 같은 처리를 수행할 터인 값의 범위나 그룹을 구하여 각 범위의 대표치를 선택하여 테스트하는 동치분할

- 범위의 경계부근이 올바른 처리를 하는지 확인하는 「한계치분석(=경계치분석)」

 

출처 : e-words.jp/w/%E3%83%96%E3%83%A9%E3%83%83%E3%82%AF%E3%83%9C%E3%83%83%E3%82%AF%E3%82%B9%E3%83%86%E3%82%B9%E3%83%88.html

 

http://e-words.jp/w/%E3%83%96%E3%83%A9%E3%83%83%E3%82%AF%E3%83%9C%E3%83%83%E3%82%AF%E3%82%B9%E3%83%86%E3%82%B9%E3%83%88.html

 

e-words.jp

 

반응형

'■ 개발 공정 > 테스트' 카테고리의 다른 글

몽키 테스트(Monkey Test)  (0) 2020.10.16
테스트 자동화의 범위  (0) 2020.10.02
결합시험 사양서 작성 요령  (0) 2020.10.02
IT(Integration Test), 결합 시험이란?  (0) 2020.09.30

목적

개발자가 생각치 못한 에러를 찾아내는 것

 

개요

시험할 부분, 조작법의 상정이나 개발자의 의도에 대한 고려 없이

시험 실시자가 즉흥적으로 조작하는 시험 방법이다.

 

명칭의 유래

원숭이에게 시켜 보면 어떨까? 라는 생각

 

상세

일반적으로 테스트는 대상의 설계, 구조, 용도, 조작법을 고려한 순서나 변수를 미리 정한다.

하지만, 몽키 테스트는 확신으로 인한 시험 관점의 누수를 배제하기 때문에

개발자가 생각하지 못한 에러를 발견하기도 한다.

 

주의점

에러가 발생했을 때 상황을 재현하기 위해 조작한 순서의 기록, 관찰을 신중히 해야 한다.

 

몽키 테스트 방식

- 랜덤한 조작을 연속적으로 시험하는 방식

- 시험대상 사용 경험이 없는 유저에게 설명 없이 사용하게 하는 방식

- 개발측의 사람이 통상적이지 않은 조작을 굳이 수행하는 방식 ... ex) 버튼 연타

 

출처 : e-words.jp/w/%E3%83%A2%E3%83%B3%E3%82%AD%E3%83%BC%E3%83%86%E3%82%B9%E3%83%88.html

반응형

테스트를 자동화한다고 했을 때, 자동과 수동의 경계는 어떻게 될까?

한 칼럼에서 읽은 내용을 정리했다.

 

"테스트 자동화"라고 하면 일반적 인식으로는 PT의 기능 요건에 한정된다.

 

테스트는 공정에 따라, 종류에 따라 분류할 수 있다.

(1) 공정

- 개발자 담당 : PT(Program Test), IT(Integration Test), ST(System Test)

- 고객 담당 : 수입 테스트, OT(Operation Test), BT(Beta Test)


(2) 종류

- 기능 요건 : 기능 테스트

- 비기능 요건: 성능 테스트, 조작성 테스트, 보안 테스트

 

테스트 자동화 시, 필요한 상황 인식

1) 현 시스템은 어떤 단계의 테스트까지 진행할 필요가 있는가?

2) 그 중 어떤 테스트를 자동화 할 것인가?

3) 자동화 할 수 없는 부분은 어느 타이밍에 확인할 것인가?

 

테스트 툴 추천

1) Selenium Web Driver

- 화면 조작계 시험의 자동화 툴

- 간단한 스크립트를 작성하여 사용

- 화면 표시 내용과 기대치를 비교한 검증이 가능

 

2) Apache JMeter

- 부하 시험용 툴

 

3) OWASP ZAP

- 보안 테스트 툴

 

참고 : qiita.com/gevanni/items/ff9a27936a1a6df28b9a

반응형

1. 목적

결합시험 사양서를 어떻게 작성해야 하는지 이해하자.

 

2. WHAT

결합시험 사양서 작성법에 대해 이해한다.

 

3. WHY

올바른 관점으로 결합시험을 수행하기 위해서이다.

 

4. HOW

  4.1. 결합시험이란?

  - 복수의 모듈을 조합 시, 정상 동작 하는지를 확인한다.

  - 확인 관점

    1) 모듈간 인터페이스를 확인

    2) 모듈 전체 조합 후 동작을 확인

 

  4.2. 결합시험의 종류

    4.2.1. 인터페이스 테스트

    인터페이스 규격, 연계 종류, 연계 방법 등 요건에 맞게 테스트 한다.

    - 모듈 간 연계를 위해 규격화된 정보를 확인한다.  ex) 매개변수 갯수, 타입 / 형식 / 문자코드, 개행코드

    - 연계 방법에는 파일 연계, API 연계가 있으므로 요건에 맞게 테스트한다.

    - 요건에 따라 시스템 내부, 시스템 간, 외부 시스템과의 연계를 테스트한다.

    4.2.2. 업무 시나리오 테스트

    4.2.3. 예외처리 테스트

    4.2.4. 부하 테스트

    - 대량의 Access나 DB내 대량의 데이터에 대한 CRUD를 대상으로 한다.

    - 관점은 다음 두 가지가 있다.

      1) 처리가 제 시간 내에 이루어 지는가?

      2) 시스템을 계속 가동할 수 있는가?

    4.2.5. 보안 테스트

 

  4.3. 결합시험 시나리오를 작성하는 Point

    4.3.1. 업무 종류, 업무 흐름을 의식한다.

    - 업무를 고려하면 기능간 연계를 확인하기 쉽다.

    - 단점으로는 정상계 기능만 의식하기 쉽다.

    4.3.2. 업무상, 시스템상의 이레귤러를 고려한다.

    - 이레귤러의 고려는 시스템의 품질을 좌우한다.

    - 업무상의 이레귤러를 고려한다.

    ex) 계좌 잔액이 부족하기 때문에 결제 승인을 거부한다.

    - 시스템상의 이레귤러를 고려한다.

    ex) Access량이 많아서 서버가 다운되었을 때의 예외처리

 

  4.4. 요약

    1) 시험관점 설정

    2) 업무 흐름, 이레귤러를 의식한 시험항목 작성

 

참고 : kabblog.net/417/

 

結局、結合テストは何をすればいい?結合テスト仕様書作成の観点 | wecoplus

上司や先輩から「結合テスト仕様書つくっといて〜」と言われて困ったことがある人は多いのではないでしょうか? SEとしての経験が豊富でも、また結合テストを実施したことがあっても、�

kabblog.net

반응형

개요

단체 시험이 끝난 복수의 모듈을 결합하여 동작시킨다.

 

목표

모듈 간 인터페이스에 관한 버그를 검출하는 것이다.

 

목적

사양대로 동작함을 증명하여 성과물의 품질을 보증한다.

 

장단점

단체 시험의 약점인 결합부의 확인이 가능하지만,

버그의 원인 특정이 어렵다는 단점이 있다.

 

관점

1. 기능 요건

  1.1. 정상 패턴 확인

  1.2. 이레귤러 패턴 확인

2. 비기능 요건

  2.1. 성능 확인

  2.2. 조작성 확인

  2.3. 보안 확인

 

대표적 수법

1. TopDown

가짜 하위 모듈인 '스터브(Stub)'를 이용하여, 상위 모듈의 인터페이스를 확인한다.

 

2. BottomUp

가짜 상위 모듈인 '드라이버(Driver)'를 이용하여, 하위 모듈의 인터페이스를 확인한다.

반응형

'■ 개발 공정 > 테스트' 카테고리의 다른 글

FT(Function Test), 기능 시험이란?  (0) 2020.11.04
몽키 테스트(Monkey Test)  (0) 2020.10.16
테스트 자동화의 범위  (0) 2020.10.02
결합시험 사양서 작성 요령  (0) 2020.10.02

+ Recent posts