13. 블랙박스 테스트2

경험 기반 테스트 정의

: 과거의 경험을 토대로 숙련된 테스터가 소프트웨어 제품의 품질을 검증하는 활동

: 과거 경험을 기반으로 적절한 전략과 계획을 수립하여 테스트한다.

 

경험기반 테스트 적용이 필요한 상황

* 요구사항 및 명세서가 부족한 경우

* 제품에 대한 정보가 부족한 경우

* 테스트 시간이 제한되는 경우

 

* 리스크가 낮은 소프트웨어 제품을 테스트할 경우에 경험기반 테스트로 가능하지만 리스크가 높은 제품의 경우 공식적인 테스트 방법과 병행이 필요하다.

 

경험기반 테스트 종류

- 탐색적 테스트

- 에러 추정 테스트

- 체크리스트 기반 테스트

- Ad Hoc 테스트

 

 

탐색적 테스트

: 체계적으로 테스트 설계와 실행은 동시에 하는것.

: 가치있는 테스트 결과를 가장 효과적으로 끊임 없이 얻기 위해 테스트 개개인의 자유의지와 책임감을 강조하는 소프트웨어 테스트의 한 방법.

: 직전의 테스트를 통해 얻은 통찰력을 다음 테스트에서 충분히 활용하면서 테스트 설계와 실행을 동시에 수행하는 활동.

: 비형식적 (체계적이지 않다는게 아님!)이고 창의적인 테스트로, 테스트 실행 결과를 기반으로 테스트 전략을 실시간으로 변경한다.

 

탐색적 테스트 주요개념

1) 테스트 차터

: 테스트 대상, 목적, 범위 등을 기록한 테스트 미션

: 무엇을 테스트해야 하는지, 어떻게 테스트해야 하는지, 어떤 문제를 찾아야 하는지 제시

 

2) 세션 노트

: 테스트 기록을 남기는 수단

: 테스트 수행기록 및 발견 특이사항, 수행시간 등을 기재

 

3) 타임 박싱

: 테스트의 집중력을 높이기 위해서 테스트 수행 시간을 지정

: 일반적으로 60~120분 정도로 세션을 진행

 

4) 회고

: 테스터의 경험과 지식을 공유

: 세션 종료 후 리뷰 진행

: 일반적으로 5분에서 10정도 진행

 

 

 

 

스크립트 테스트 vs 탐색적 테스트

 

스크립트 테스트 : 테스트 계획과 설계과정을 거친 후 테스트를 수행

탐색적 테스트 : 형식적인 테스트 계획이나 테스트 케이스 없이 테스트 결과에 다라 테스트 항목을 경험적으로 탐색하면서 테스트를 수행하는 방식.

 

탐색적 테스트 장점

- 경험 기반의 테스트를 체계적으로 적용

- 테스트 케이스 작성 시간을 줄여서 테스트 실행에 집중가능

- 적은 테스트 인력으로 많은 테스트 수행

- 명세가 거의 없고 시간이 부족한 경우 효과적/효율적으로 테스트 수행

- 테스터 또는 테스트 엔지니어의 역량 향상.

 

탐색적 테스트 단점

- 테스터의 성향에 따라서 서로 다른 결과를 도출

 

 

스크립트 테스트 vs 탐색적 테스트

 

구분	스크립트 테스트	탐색적 테스트
도메인 지식	테스트 설계과정을 통해 도메인 지식을 얻을 수 있다.	도메인지식이 충분하지 않은경우 테스트하기 어렵다. 도메인 지식이 부족할 경우 교육이 필요하므로 오버헤드가 필요하다.
시스템 복잡도	테스트 의존도를 고려해야 하는 복잡한 시스템의 경우 면밀하게 테스트 설계가 가능하다	테스트 의존도를 고려하지 않고 테스터의 능력에 의존한다.
문서화 정도	테스트에 관련된 문서가 요구된다	도메인 지식을 갖춘다는 가정하에 문서작성이 요구되지 않는다.
준비시간	많은 준비시간이 요구된다.	준비시간이 요구되지 않는다.
테스트 능력	테스트 설계를 위해 테스트 분석 능력이 요구된다.	탐색적 테스트를 할 수 있는 테스트 능력이 요구된다.
효율성	테스트 준비를 위한 투자가 필요하다	테스트 준비시간이 요구되지 않는다. 테스트에 더 많은 시간을 투입할 수 있다.
커버리지	완료된 테스트를 알 수 있어 테스트 커버리지 파악이 가능하다.	테스트로 커버리지를 알 수 없다.
재생산성	모든 과정을 쉽게 재생산할 수 있다	결함만 재생산할 수 있다.

 

- 세션기반 테스트

: 각 세션별 집중해야 할 미션을 수립하고 테스트

: 각 세션을 진행하면서 ,무엇을 탐험했고, 어떤 정보를 찾았는지 자세하게 메모

: 세션 마지막에는 다른 사람들에게 전달해야하는 정보를 정리. (발견한 버그와 질문, 다음 세션에서 탐험해야할 영역 등)

 

 

 

차터(Charter)

 

- 구성

(1) 목표 : 어느곳을 탐험해야 하는가? 

=> 어떤 기능이나 요구사항일 수도 있고 관련된 특정 모듈일 수도 있다.

(2) 자원 : 어떤 자원을 가지고 갈 것인가?

=> 도구, 데이터, 새로운 기술 등

(3) 정보 : 어떤 종류의 정보를 찾고 싶은가?

=> 보안, 성능, 신뢰성, 가용성, 사용성 등

 

- 차터 양식

✅ 내가 필요한 정보를 찾기 위해서

✅ 사용 가능한 자원을 가지고

✅ 목표가 되는 곳으로 탐험을 떠나자!

 

- 차터 예시

✅ 보안상 취약한 부분을 찾기 위해서

✅ java script와 SQL Injection 공격을 가지고

✅ 입력 필드로 탐험을 떠나자!

 

- 차터 작성 방법

=> 미션에 대한 문장

    * 목적에 부합해야 하고,

    * 작업에 집중하고,

    * 이행 여부를 확인하며

    * 테스트 범위를 기술해야 한다.

=> 작성 방법

    * 간결하고 요점에 맞게

    * 포함 사항과 제외 사항 기술

    * 제약사항을 기술

 

ex) 적절한 차터 예시 1

✅ 사용자가 접근 권한이 있는 콘텐츠에 접근 할 수 있는지를 찾기 위해

✅ 그럴싸하게 위장된 웹주소와 POST 요청 파라미터를 가지고

✅ 로그인을 필요로 하는 웹페이지로 탐험을 떠나자!

 

ex) 적절한 차터 예시 2

✅ 개인 정보 보호 규정을 위반하는 시나리오를 찾기 위해서

✅ 개인정보 보호 설정 기능을 가지고

✅ 메시지 기능으로 탐험을 떠나자.

 

ex) 적절하지 않은 차터 예시 1

❌ 프로파일 수정 기능이

❌ 작은 따옴표를 가지는 이름을 제대로 처리하는지를 찾기 위해서 O'Melly라는 이름을 가지고

❌ 이름수정으로 탐험을 떠나자

=> 세션은 1~2시간으로 주어지는데 이렇게 너무 구체적이면 TC 몇 개 분량밖에 안됨

ex) 적절하지 않은 차터 예시 2

❌ 보안이 취약한 모든 부분을 찾기 위해서

❌ 사용가능한 모든 해킹 프로그램을 가지고

❌ 시스템 보안으로 탐험을 떠나자

=> 세션이 1~2시간으로 주어지는데 너무 차터가 광범위해서 테스트하기 어렵다.

 

- 차터가 필요한 영역

1) 고장모드

: "어떻게 하면 시스템을 망가뜨릴 수 있을까?"

ex) 유효하지 않는 값, 환경(메모리, 대역폭 등), 스트레스 부하 등

 

2) 창의적인 아이디어

: "만약 이렇게 하면 어떻게 동작할까?"

ex) 고정관념 버리기, 매우큰 데이터 사용, 예상치 않은 상호작용 테스트

 

3) 환경

: "이 제품이 어떤 환경에서 사용할까?"

ex) HW, SW, 상호 의존적인 소프트웨어, OS, browser

 

4) 품질특성

: "이 제품은 어떤 품질특성을 지원해야 하나?"

ex) 성능, 처리율, 가용성, 사용성, 유지보수성, ...성