6. Tool support for testing(K2)
6.1 Types of test tool (K2)
6.1.1 테스팅 도구 분류 (Test tool classification) (K2)
테스팅의 여러가지 측면을 지원하는 많은 수의 도구가 있다. 이 요약서에서는 도구들이 지원하는 테스팅 액티비티에 따라서 도구들을 분류한다.
어떤 도구들은 하나의 액티비티를 지원한다. 다른 도구들은 하나 이상의 액티비티를 지원할 수 있다. 그러나 이런 도구들은 가장 관련있는 액티비티 아래로 분류된다. 일부의 상업적인 도구들은 오직 한가지 타입의 액티비티만을 지원한다. 다른 상업용 도구 벤더는 이러한 액티비티 모두 또는 많은 부분을 지원하는 도구 셋이나 슈트(suite)를 제공한다.
테스팅 도구는 반복적인 작업을 자동화함으로써 테스팅 액티비티의 효율성을 높일 수 있다. 예를 들어 테스팅 도구는 많은 수의 데이터 비교를 자동화 하거나 동작을 시뮬레이션함으로써 테스팅의 유연성 또한 높일수 있다.
일부의 테스팅 도구는 도구 그 자체가 테스트의 실제 결과에 영향을 미쳐서 테스트에 방해가 될 수 있다. 예를 들어, 여러가지 성능 도구를 가지고 어떻게 측정하느냐에 따라 실제 타이밍이 다르게 될 수 있거나, 어떤 커버리지 도구를 사용하는가에 따라 코드 커버리지의 다른 측정치를 얻을 수 있다. 이러한 방해되는 도구의 결과를 탐침 효과(probe effect)라 부른다.
일부 도구들은 개발자들에게 좀더 적절한 지원을 제공한다. (e.g 컴포넌트와 컴포넌트 통합 테스팅 동안에), 이러한 도구들은 아래의 분류에서 "D"로 표시될 것이다.
6.1.2 테스팅과 테스트의 관리를 위한 도구 지원 (K1)
모든 관리도구는 소프트웨어 개발 전 주기동안의 모든 테스트 액티비티들에 적용된다.
테스트 관리도구 (Test management tools)
테스트 관리 도구의 특성은 다음을 포함한다.
• 테스트의 관리와 수행된 액티비티에 대한 지원
• 테스트 실행 도구, 결함 추적 그리고 요구사항 관리도구와의 인터페이스한다.
• 독립적인 버전 컨트롤, 또는 외부 구성 관리 도구와의 인터페이스
• 테스트, 테스트 결과 그리고 요구사항 명세와 같은 소스 문서에 대한 부가사항에 대한 추적성 지원
• 테스트 결과의 로깅과 진행상황 보고 생성
• 테스트 객체에 대한 정보를 주기 위하여, 그리고 테스트 프로세스를 통제하고 향상시키기 위하여 테스트(e.g 실행된 테스트와 패스(pass)된 테스트)와 테스트 객체(e.g 발생한 부가사항)에 관련된 수량적인 분석(매트릭)
• 테스트 실행 도구, 결함 추적 그리고 요구사항 관리도구와의 인터페이스한다.
• 독립적인 버전 컨트롤, 또는 외부 구성 관리 도구와의 인터페이스
• 테스트, 테스트 결과 그리고 요구사항 명세와 같은 소스 문서에 대한 부가사항에 대한 추적성 지원
• 테스트 결과의 로깅과 진행상황 보고 생성
• 테스트 객체에 대한 정보를 주기 위하여, 그리고 테스트 프로세스를 통제하고 향상시키기 위하여 테스트(e.g 실행된 테스트와 패스(pass)된 테스트)와 테스트 객체(e.g 발생한 부가사항)에 관련된 수량적인 분석(매트릭)
요구사항 관리도구(Requirements management tools)
요구사항 관리도구는 요구사항 문장들을 저장하고, 일관성과 정의되지 않은(빠진) 요구사항을 체크하며, 요구사항을 우선순위화하고, 요구사항, 기능과/또는 특성에 대하여 개별적인 테스트들이 추적성을 갖는 것을 가능하게 한다. 추적성은 테스트 관리 프로세스 보고서에서 보고될 수 있다. 요구사항, 기능(functions)과/또는 특성(features)에 대한 테스트 셋의 커버리지 역시 보고되어야 한다.
부가사항 관리 도구 (Incident managment tools)
부가사항 관리도구는, 예를 들어 결함(defect), 실패(feature) 또는 인지된 문제들과 변칙사항과 같은, 부가사항 보고들을 저장하고 관리한다. 그리고 부가사항 보고관리를 지원하는 방법은 다음을 포함한다.
• 우선순위 정하는 것을 쉽게한다.
• 사람들에게 작업을 할당 (e.g 수정(fix) 또는 확정 테스트(confirmation test))
• 상태의 귀속성(attribution) (e.g 거부된 테스트, 준비된 테스트, 또는 다음 릴리즈에 언급된 테스트)
• 사람들에게 작업을 할당 (e.g 수정(fix) 또는 확정 테스트(confirmation test))
• 상태의 귀속성(attribution) (e.g 거부된 테스트, 준비된 테스트, 또는 다음 릴리즈에 언급된 테스트)
이러한 도구는 모든 시간에 걸쳐 모니터 되야하는 부가사항의 진행을 가능하게 하며, 때때로 통계적인 분석에 대한 지원을 제공하기도 한다. 그리고 부가사항에 대한 보고를 제공한다. 이것은 결함 추적 도구(defect tracking tools)로도 알려져 있다.
구성관리 도구 (Configuration management tools)
구성관리(CM) 도구는 엄격히 말하서 테스팅 도구가 아니다. 하지만 일반적으로 여러가지 버전들과 소프트웨어와 테스트의 구조를 추적하는데 필요하다.
구성관리 도구는
• 소프트웨어와 테스트웨어의 구성과 버전에 대한 정보를 저장한다.
• 테스트웨어(testware)와 소프트웨어 작업 산출물(software work product)과 산출 변형물(product variants) 사이에 추적성을 가능하게 한다.
• 하나 이상의 하드웨어/소프트웨어 환경에서 개발할 때 매우 유용하다. (e.g 여러가지 운영 체제 버전, 여러가지 라이브러리와 컴파일러, 여러가지 브라우저와 여러가지 컴퓨터에 대하여)
• 테스트웨어(testware)와 소프트웨어 작업 산출물(software work product)과 산출 변형물(product variants) 사이에 추적성을 가능하게 한다.
• 하나 이상의 하드웨어/소프트웨어 환경에서 개발할 때 매우 유용하다. (e.g 여러가지 운영 체제 버전, 여러가지 라이브러리와 컴파일러, 여러가지 브라우저와 여러가지 컴퓨터에 대하여)
6.1.3 정적 테스팅 지원 도구 (Tool support for static testing) (K1)
리뷰 프로세스 지원 도구(Review process support tools)
리뷰 프로세스 지원 도구는 리뷰 프로세스에 대한 정보의 저장, 리뷰 코멘트의 저장과 전달, 결함과 효과에 대한 보고, 리뷰하기 위한 규칙과/또는 체크리스트에 대한 참고사항 관리, 그리고 문서와 소스 코드 사이의 추적성의 자취를 보존한다. 리뷰 프로세스 지원도구는 지리학적으로 떨어져 있는 팀이 있다면 유용한 온라인 리뷰에 대한 지원 역시 제공할 수 있다.
정적 분석 도구(Static analysis tools)(D)
정적 분석 도구는 개발자, 테스터, 그리고 품질 보증 관련자가 동적 테스팅 전에 결함을 발견하는 것을 돕느다. 정적 분석 도구의 목적은 다음을 포함한다.
• 코딩 표준의 강제
• 구조와 의존성의 분석(e.g 링크된 웹 페이지)
• 코드 이해의 지원
• 구조와 의존성의 분석(e.g 링크된 웹 페이지)
• 코드 이해의 지원
정적 분석 도구는 코드로부터,예를 들어 계획이나 위험 분석에 대한 중요한 정보를 줄 수 있는, 특성(e.g complexity)을 계산할 수 있다.
모델링 도구(Modeling tools) (D)
모델링 도구는 소프트웨어의 모델을 검증하는 것을 가능하게 한다. 예를 들어, 데이터베이스 모델 확인기(checker)는 데이터베이스 모델내의 불일치성과 결함을 발견할 수 있다. 다른 모델링 도구는 정적 모델이나 객체 모델내의 결함을 발견할 수 있다. 이러한 도구는 때때로 모델에 기반한 일부의 테스트케이스를 생성하는 것을 지원한다. (아래의 테스트 디자인 도구를 보라)
정적 분석 도구와 모델링 도구의 주된 혜택은 개발 프로세스내에서 초기에 더 많은 결함을 발견하는 비용 효과이다. 그 결과로 개발 프로세스는 더 적은 재작업(rework)으로 인하여 가속화되고 향상될 수 있다.
6.1.4 테스트 명세 지원 도구 (Tool support for test specification) (K1)
테스트 디자인 도구 (Test design tools)
테스트 디자인 도구는 요구사항, 그래픽 사용자 인터페이스(GUI), 그리고 디자인 모델(상태, 데이터, 또는 객체), 또는 코드로 부터 실제 테스트나 테스트 입력을 생성한다. 이러한 타입의 도구는 예상되는 결과 역시 생성할 수 있다. (i.e 테스트 예상치를 이용할 수도 있다.) 상태나 객체 모델로부터 생성된 테스트들은 소프트웨어내의 모델의 구현을 검증하는데 유용하다. 이러한 것들은 도구가 생성하는 테스트들의 완전함 때문에 귀중한 시간을 절약할 수 있고 테스팅의 증가되는 완전함을 제공한다.
이러한 분류의 다른도구들은 때때로 테스트 스텁(stub)이나 테스트를 생성하는 테스트 프레임이라 불리우는, 구조화된 템플릿을 제공함으로써 테스트들의 생성을 지원하는 것을 도울수 있다. 따라서 테스트 디자인 프로세스의 속도를 높일 수 있다.
테스트 데이터 준비도구 (Test data preparation tools) (D)
테스트 데이터 준비도구는 테스트 실행동안에 사용되어야 하는 테스트 데이터를 설정하기 위하여 데이터베이스, 파일 혹은 데이터 전송을 조작한다. 이러한 도구의 혜택은 데이터 보호를 위하여 생생한 데이터를 익명으로 만들어진 테스트 환경에 전송되는 것을 보증한다는 것이다.
6.1.5 테스트 실행과 로깅 지원 도구 (Tool support for test execution and logging) (K1)
테스트 실행도구(Test execution tools)
테스트 실행 도구는 스크립팅 언어를 사용함으로써 지정된 입력과 예상되는 결과를 이용하여 자동이나 반자동으로 실행되어야 하는 테스트를 가능하게 한다. 예를 들어, 스크립트 언어는 제한된 노력을 가지고 비슷한 단계의 시스템의 여러 부분에 대한 다양한 데이터를 가지고 반복되는 테스트들을 조작하는 것을 가능하게 만든다. 일반적으로 이러한 도구들은 동적인 비교 특성과 각각의 실행된 테스트에 대한 테스트 로그를 제공하는 것을 포함한다.
테스트 실행도구는 반복 기록 도구(capture playback tools)로 참조될 때, 기록된 테스트들을 이용할 수 있다. 예를 들어, 탐색 테스팅(Exploratory testing) 동안에 입력을 추출하는 것과 스크립되지 않는 테스팅은 오류(failure)가 발생했을 때, 테스트를 재생성하고/하거나, 테스트를 문서화하기 위하여 유용해질 수 있다.
테스트 장비/단위 테스트 프레임워크 도구 (Test harness/unit test framework)(D)
테스트 장비는 테스팅 객체가 운영되어야 하는 환경을 시뮬레이션함으로써 컴포넌트 혹은 시스템의 일부분의 테스팅을 용이하게 할 수 있다. 이것은 실제 환경의 컴포넌트들이 아직 이용가능하지 않거나, 스텁과/이나 드라이버, 또는 단순히 예상가능하고 통제가능한 테스트하의 객체에 대하여 모든 결함이 있을 수 있는 환경을 제공하는 경우 모두에서 행하여 질 수 있다.
프레임워크는 테스트 되어야 하는 객체를 호출하고/하거나 그 객체에 대하여 피드백을 주는 것으로 코드, 객체, 메소드 또는 함수, 유닛 또는 실행 될 수 있는 컴포넌트의 일부에 대하여 생성될 수 있다. 이것은 실제의 결과 목표 대신에 객체로부터 결과를 얻기 위하여 스텁을 제공하고/하거나 테스트 객체에 대하여 입력을 제공하는 인위적인 수단을 제공하는 것으로 할 수 있다.
테스트 장비는 반드시 함께 테스트 되어야 하는 언어, 운영 시스템 또는 하드웨어와 같은 미들웨어의 실행 프레임워크를 제공하는데 사용 될 수 있다.
이것은 컴포넌트 테스트 레벨에 특별한 초점을 가지고 있는 경우, 단위 테스트 프레임웍크 도구라 불릴수 잇다. 이러한 도구의 타입은 만들어진 코드를 가지고 동시에 컴포넌트 테스트의 실행을 지원한다.
테스트 비교기 (Test comparators)
테스트 비교기는 파일, 데이터베이스 또는 테스트 결과들 사이의 차이점을 결정한다. 테스트 실행도구는 일반적으로 동적인 비교기를 포함한다. 그러나 실행 후의 비교는 분리된 비교도구에 의하여 행하여진다. 테스트 비교 도구는 테스트 오라클을 이용할 수도 있다. 특히 자동화 되었다면 말이다.
커버리지 측정도구(Coverage measurement tools) (D)
커버리지 측정 도구는 사용되는 측정 기법, 무엇이 측정되었는가와 코딩 언어에 의존하여 방해가 될 수도, 되지 않을 수도 있다. 코드 커버리지 도구는 실행된 코드 구조의 특정 타입의 퍼센티지를 측정한다. (e.g 문장, 브랜치, 또는 분기 그리고 모듈 또는 함수 호출). 이러한 도구는 테스트의 셋에 의하여 실행된 구조의 측정된 타입이 얼마나 완벽한지 보여준다.
보안도구(Security tools)
보안도구는 컴퓨터 바이러스와 서비스 공격의 거부에 대한 확인을 한다. 예를 들어, 방화벽은 엄격히 말해 테스팅 도구는 아니지만, 보안 테스팅을 위하여 사용할 수 있다. 다른 보안 도구는 시스템의 특정한 취약점을 찾음으로써 시스템에 부하를 준다.
6.1.6 성능과 모니터링 지원 도구 (K1)
동적 분석도구 (Dynamic analysis tools) (D)
동적 분석도구는 시간 종속성이나 메모리 부족과 같은 소프트웨어가 실행할 때만 발생하는 결함들을 발견한다. 이들은 일반적으로 컴포넌트 테스팅과 컴포넌트 통합 테스팅, 그리고 미들웨어를 테스팅 할 때 사용된다.
성능 테스팅/부하 테스팅/ 스트레스 테스팅 도구(Performance test/load testing
/stress testing tools)
성능 테스팅 도구는 다양하게 시뮬레이션 된 사용 조건 아래서 어떻게 시스템이 동작하는가를 모니터하고 보고한다. 이들은 응용 프로그램, 데이터베이스 또는 네트웍이나 서버와 같은 시스템 환경에 대한 부하를 시뮬레이션한다. 이러한 도구들은 부하나 압박과 같이 이것이 측정하는 성능 측면에 따라 명명되므로, 부하 테스팅 도구나 스트레스 테스팅 도구로도 알려져 있다. 이것들은 종종 파라미터에 의하여 통제되는 테스트의 반복적인 실행을 자동화하는 것에 기초한다.
모니터링 도구(Monitoring tools)
모니터링 도구는 엄격하게 말하면 테스팅 도구가 아니지만, 다른 수단에 의하여 이용가능하지 않은, 테스팅 목적을 위하여 사용될 수 있는 정보를 제공한다.
모니터링 도구는 계속적으로 특정 시스템 자원의 사용에 대하여 분석, 검증하고 보고한다. 그리고 가능한 서비스 문제에 대한 경고를 한다. 이들은 소프트웨어와 테스트웨어의 버전과 구축에 대한 정보를 저장하고, 추적성을 가능하게 한다.
6.1.7 특정 응용 프로그램 영역의 도구 지원 (Tool support for specific application areas)(K1)
위에서 구분된 도구 타입의 개별적인 예들은 특별한 종류의 어플리케이션 사용에 대한 특화가 될 수 있다. 예를 들어, 성능 테스팅 도구는 웹 기반의 응용 프로그램에 특화될 수 있다. 정적 분석 도구는 특정한 개발 플랫폼에 특화될 수 있다. 그리고 동적 분석도구는 테스팅 보안 측면에 대하여 특화된다.
상업적인 도구 슈트(suite)는 특정한 응용 프로그램 영역(e.g 임베디드 시스템)을 목표로 삼을 수 있다.
6.1.8 다른 도구를 사용한 도구 지원 (Tool support using other tools) (K1)
여기에서 리스트 된 테스팅 도구는 테스터들에 의하여 사용되는 유일한 도구 종류는 아니다. - 예를 들어, 테스터들도 스프레드 쉬트, SQL, 리소스 혹은 디버깅 도구(D)를 사용할 수도 있다.
==========================================================================
◆ SW 테스팅 도구
▪ 광의의 SW 테스팅 도구
- 상용 성능 테스트 자동화 도구 (일반적으로 고가)
- 테스트 관리 자동화 도구 (Defect Tracking 시스템 등)
- 테스트 지원 자동화 도구 (Analyzer, Windiff, Equalizer, Ghost)
- 테스트 방법론 및 문서 (체크 리스트, TC 작성 방법론 등)
- 상용 성능 테스트 자동화 도구 (일반적으로 고가)
- 테스트 관리 자동화 도구 (Defect Tracking 시스템 등)
- 테스트 지원 자동화 도구 (Analyzer, Windiff, Equalizer, Ghost)
- 테스트 방법론 및 문서 (체크 리스트, TC 작성 방법론 등)
▪ 협의의 SW 테스팅 도구
- 상용 성능 테스트 자동화 도구
- 테스트 관리 자동화 도구 (Defect Tracking 시스템 등)
- 상용 성능 테스트 자동화 도구
- 테스트 관리 자동화 도구 (Defect Tracking 시스템 등)
◆ SW 테스트 자동화 도구 관련 이슈
자동화 도구 사용의 장점
▪ 테스트 노력 절감 및 실수 감소 -> 반복되는 부분을 자동화시켜 리소스를 보다 위험도가 높은 부분의 테스팅에 집중하는 것을 가능하게 함
▪ 비용 효율적 유지보수 가능 -> 고객의 요구에 빠르게 응답
▪ 품질 향상 -> 고객 만족도 향상
자동화 도구 사용의 단점
▪ 고가이면서 유지 비용 (가상사용자, 업그레이드, 기술지원 등)도 높음
▪ 초기 환경 및 테스트 설정에 많은 시간과 노력 소요
▪ 테스트 스크립트 유지보수가 어려움
▪ 테스트 노력 절감 및 실수 감소 -> 반복되는 부분을 자동화시켜 리소스를 보다 위험도가 높은 부분의 테스팅에 집중하는 것을 가능하게 함
▪ 비용 효율적 유지보수 가능 -> 고객의 요구에 빠르게 응답
▪ 품질 향상 -> 고객 만족도 향상
자동화 도구 사용의 단점
▪ 고가이면서 유지 비용 (가상사용자, 업그레이드, 기술지원 등)도 높음
▪ 초기 환경 및 테스트 설정에 많은 시간과 노력 소요
▪ 테스트 스크립트 유지보수가 어려움
◆ SW 테스트 자동화 고려 사항
▪ 적절한 자동화 대상 프로젝트 선정
▪ 자동화를 테스트 전략과 계획에 포함
▪ 자동화 도구 선정에 신중
- 적합한 것을 찾기 어려움, 지원과 교육 고려
▪ 제품과 테스트 스팩을 Formal하게 변경하는 것에 대한 준비
▪ 자동화 테스트 지원 시설(도구) 개발 계획
- 자동화 도구의 적용범위의 한계로 직접 개발하는 부분 존재
▪ 테스팅을 다른 방식으로 진행하는 것 고려 (개발 계획 또는 도구 방식에 맞게)
- 자동화 테스트는 상세한 테스트 지침 필요
▪ 자동화 도구 및 자동하 테스팅 교육에 투자
▪ 자동화를 테스트 전략과 계획에 포함
▪ 자동화 도구 선정에 신중
- 적합한 것을 찾기 어려움, 지원과 교육 고려
▪ 제품과 테스트 스팩을 Formal하게 변경하는 것에 대한 준비
▪ 자동화 테스트 지원 시설(도구) 개발 계획
- 자동화 도구의 적용범위의 한계로 직접 개발하는 부분 존재
▪ 테스팅을 다른 방식으로 진행하는 것 고려 (개발 계획 또는 도구 방식에 맞게)
- 자동화 테스트는 상세한 테스트 지침 필요
▪ 자동화 도구 및 자동하 테스팅 교육에 투자
◆ 모델 기반 테스팅
▪ 요구사항(개발 관련 문서) -> 테스트 모델링(UML 등 이용) -> Animate ->
테스트 케이스 자동 생성 (스크립트 패턴, 맵핑) -> 테스트 스크립트 생성 -> 테스트 수행
테스트 케이스 자동 생성 (스크립트 패턴, 맵핑) -> 테스트 스크립트 생성 -> 테스트 수행
◆ 모델이란?
▪ 작은 오브젝트 : 다른 커다른 오브젝트를 대포함, 스케일링 가능
▪ 모델은 "간결" - 작고 간결하여 테스팅 관점에서 수동으로 테스트 설계하는 것보다 저럼하며, 일부(한가지 측면)만 테스팅 하기 이해 "부분적 모델" 이 가능하다.
▪ 모델은 "정확" - 기대 "행위"를 기술해야 하며, UML의 여러 다이어그램을 복합적으로 이용
▪ 모델은 "간결" - 작고 간결하여 테스팅 관점에서 수동으로 테스트 설계하는 것보다 저럼하며, 일부(한가지 측면)만 테스팅 하기 이해 "부분적 모델" 이 가능하다.
▪ 모델은 "정확" - 기대 "행위"를 기술해야 하며, UML의 여러 다이어그램을 복합적으로 이용
6.2 Effective use of tools:potential benefits and risks (K2)
6.2.1 테스팅에 대한 도구 지원의 잠재적인 혜택과 위험 (모든 도구에 대하여)
단순히 도구를 구입하거나 임대하는 것은 도구를 사용한 성공을 보증하지 않는다. 도구의 각 종류는 실질적이고 최종적인 혜택을 이루기 위한 추가적인 노력을 요구할 수 있다. 테스팅에 도구를 사용하는 것은 잠잭적인 혜택의 기회들 뿐 아니라. 위험 역시 가지고 있다.
도구를 사용하는 잠재적인 혜택은 다음을 포함한다.
• 반복적인 작업이 줄어든다. (e.g 회귀 테스티의 실행, 같은 테스트 데이터의 재입력, 그리고 코딩 표준에 대한 검사)
• 더 많은 일관성과 반복 가능성 (e.g 도구에 의하여 실행된 테스트, 요구사항으로부터 유도된 테스트들)
• 객관적인 평가(e.g 정적인 측정값, 커버리지와 시스템 행위)
• 테스트와 테스팅의 정보에 대한 쉬운 접근 (e.g 테스트 진행사항, 부대사건 비율과 성능에 대한 통계와 그래프)
• 더 많은 일관성과 반복 가능성 (e.g 도구에 의하여 실행된 테스트, 요구사항으로부터 유도된 테스트들)
• 객관적인 평가(e.g 정적인 측정값, 커버리지와 시스템 행위)
• 테스트와 테스팅의 정보에 대한 쉬운 접근 (e.g 테스트 진행사항, 부대사건 비율과 성능에 대한 통계와 그래프)
도구를 사용하는 위험은 다음을 포함한다.
• 도구에 대한 비현실적인 예상들 (쉬운 사용과 기능을 포함해서)
• 도구의 초기 소개에 대한 시간, 비용 그리고 노력에 대한 과소평가
• 도구로부터 의미있고 연속적인 혜택을 얻기 위해 필요한 노력과 시간의 과소평가(테스팅 프로세스에 대한 변경 요청과 사용되는 도구의 계속되는 향상 방법을 포함해서)
• 도구에 의하여 생성된 테스트 자산의 유지에 필요한 노력의 과소평가
• 도구에 대한 과도한 신뢰(테스트 디자인의 교체 혹은 수동 테스팅이 더 좋은 경우)
• 도구의 초기 소개에 대한 시간, 비용 그리고 노력에 대한 과소평가
• 도구로부터 의미있고 연속적인 혜택을 얻기 위해 필요한 노력과 시간의 과소평가(테스팅 프로세스에 대한 변경 요청과 사용되는 도구의 계속되는 향상 방법을 포함해서)
• 도구에 의하여 생성된 테스트 자산의 유지에 필요한 노력의 과소평가
• 도구에 대한 과도한 신뢰(테스트 디자인의 교체 혹은 수동 테스팅이 더 좋은 경우)
6.2.2 일부 도구 종류에 대한 특별한 고려사항들 (K1)
테스트 실행 도구 (Test execution tools)
테스트 실행 도구는 전기적으로 저장된 테스트를 구현하기 위하여 디자인된 스크립트를 재연한다. 이것은 때때로 중요한 혜택을 얻기 위해 많은 노력을 요구하는 도구의 종류이다.
수작업 테스터의 행위들을 기록함으로써 테스트를 추출하는 것은 매력적으로 보일수 있지만, 이러한 접근 방법은 많은 수의 테스트에게까지 규모가 확장되지 않는다. 추출된 스크립트는 각각 스크립트의 부분으로 특정 테이터와 액션을 선형적으로 표현한다. 이러한 종류의 스크립트는 예상되지 못한 이벤트가 일어날 때 불안정하게 될 수도 있다.
데이터 유도 방식(data-driven approach)은 테스트 입력(데이터)를 일반적으로 스프레드 쉬트로 분리한다. 그리고 테스트 데이터를 읽을 수 있는 더욱 일반적인 스크립트를 사용하고 여러가지 데이터를 가지고 동일한 테스트를 수행한다. 스크립트 언어에 익숙하지 않은 테스터들은 미리 정의된 스크립트에 대한 테스트 테이터를 입력 할 수 있다. 핵심어 유도 방식(keyworkd-driven approach)에서는 스프레드 쉬트는 처리해야 하는 액션을 설명하는 핵심어(실행어라 불린다.)와 테스트 데이터를 포함한다. 테스터들은(심지어 스크립트 언어에 친숙하지 않다고 하더라도) 핵심어를 이용하여 테스트를 정의할 수 있으며, 테스트 되어야 하는 응용 프로그램에 대하여 맞출 수 있다.
스크립팅 언어에 대한 기술적인 전문 지식은 (테스터나 전문가에 의한 테스트 자동화에 있어서 모두) 모든 접근 방법에 대하여 필요하다.
어떠한 스크립팅 기법이 사용되었던간에, 각각의 테스트에 대한 예상 결과는 나중의 비교를 위하여 저장되는 것이 필요하다.
성능 테스팅 도구
성능 테스팅 도구는 테스트를 디자인하고 결과를 해석하는 것을 돕기 위해 성능 테스팅에 전문적 기술을 가진 사람이 필요하다.
정적 분석 도구
소스 코드에 적용된 정적 분석 도구는 코딩 표준을 강제할 수 있지만, 기존 코드에 적용하게 된다면 많은 수의 메시지를 생성 할 수도 있다. 경고 메세지는 코드로 부터 실행 가능한 프로그램을 생성하는 것을 중단시키지 않지만, 이상적으로 처리된다면, 코드의 유지보수는 미래에도 더욱 쉬워질 것이다. 일부 메시지를 제외한 초기 필터를 가지고 하는 점차적인 구현은 효과적인 접근 방법이 될 수 있다.
테스트 관리 도구
테스트 관리 도구는 조직의 현재 필요한 가장 최적의 형식으로 정보를 생성하기 위하여 스프레드 쉬트나 다른 도구와 인터페이스하는 것이 필요하다. 보고서는 혜택을 제공하기 이하여 설계되고 모니터되는 것이 필요하다.
6.3 Introducing a tool into an organization
조직에 도구를 소개하는 것에 대한 주요한 원칙들은 다음을 포함한다.
• 도구에 의하여 향상된 테스트 프로세스에 대한 기회들에 대한 확인과 조직의 성숙도, 강점과 약점에 대한 평가
• 명확한 요구사항과 객관적인 특성에 대한 평가
• 요구 기능을 테스트하고 개발된 제품이 개발 목적을 만족시키는지를 결정하기 위한 개념의 증명
• 명확한 요구사항과 객관적인 특성에 대한 평가
• 요구 기능을 테스트하고 개발된 제품이 개발 목적을 만족시키는지를 결정하기 위한 개념의 증명
• 벤더의 평가 (트레이닝, 지원, 그리고 상업적인 측면을 포함한)
• 툴의 사용에 있어서 코칭(coaching)과 멘토링(mentoring)을 위한 내부적인 요구사항의 정의
• 툴의 사용에 있어서 코칭(coaching)과 멘토링(mentoring)을 위한 내부적인 요구사항의 정의
중요한 문제가 발견되고 파일럿 프로그램이 성공적이지 않다면, 이것의 영향(impacts)을 최소화 시키기 위해서 작은 규모의 파일럿 프로젝트를 수행함으로서 개념의 증명(proof-of-concept)가 행해질 수 있다.
파일롯 프로젝트는 다음의 목적을 가진다.
• 도구에 대하여 자세하게 배운다.
• 어떻게 도구가 기존의 프로세스와 습관에 맞추어질 수 있는지를 살펴보고, 어떻게 변경될 수 있는지를 알아본다.
• 도구를 사용, 관리, 저장, 그리고 유지하는 기준 방법을 결정하고, 테스트 한 것을 평가한다.
• 어떻게 도구가 기존의 프로세스와 습관에 맞추어질 수 있는지를 살펴보고, 어떻게 변경될 수 있는지를 알아본다.
• 도구를 사용, 관리, 저장, 그리고 유지하는 기준 방법을 결정하고, 테스트 한 것을 평가한다.
(e.g 파일이나 테스트들에 대한 명명 규칙을 정하고, 라이브러리 생성과 테스트 슈트의 모듈성(modularity)를 정의)
• 적당한 비용으로 혜택을 얻을 수 있는지 평가한다.
• 적당한 비용으로 혜택을 얻을 수 있는지 평가한다.
조직안에서 도구의 개발에 대한 성공 요소는 다음을 포함한다.
• 조직의 나머지 부분에 대하여 점차적으로 도구를 공개
• 도구의 사용에 적합하기 위한 프로세스의 적용과 향상
• 훈련의 제공과 새로운 사용자에 대한 코칭/멘토링
• 사용 가이드라인의 정의
• 도구의 사용으로부터 배운 교훈의 적응 방법
• 도구 사용과 혜택에 대한 메토링
• 도구의 사용에 적합하기 위한 프로세스의 적용과 향상
• 훈련의 제공과 새로운 사용자에 대한 코칭/멘토링
• 사용 가이드라인의 정의
• 도구의 사용으로부터 배운 교훈의 적응 방법
• 도구 사용과 혜택에 대한 메토링
==========================================================================
도구와 자동화의 주요 특성
1. 속도 - 자동화된 테스트는 수동으로 테스트를 실행하는 것보다 빠르다.
2. 효율성 - 테스트에 걸리는 시간을 줄여주고, 테스트 계획을 세우고 새로운 테스트를 생각한 시간을 더 많이 가질 수 있다.
3. 정확성과 정밀도 - 테스트 도구를 사용하면 같은 테스트를 여러번 수행하고 매번 완벽하게 결과를 확인할 수 있다.
4. 지속성 - 테스트 도구와 자동화는 지치거나 포기하지 않고 지시한 작업을 원하는 만큼 반복시킬 수 있다.
2. 효율성 - 테스트에 걸리는 시간을 줄여주고, 테스트 계획을 세우고 새로운 테스트를 생각한 시간을 더 많이 가질 수 있다.
3. 정확성과 정밀도 - 테스트 도구를 사용하면 같은 테스트를 여러번 수행하고 매번 완벽하게 결과를 확인할 수 있다.
4. 지속성 - 테스트 도구와 자동화는 지치거나 포기하지 않고 지시한 작업을 원하는 만큼 반복시킬 수 있다.
단, 테스트 도구를 사용하는 것이 언제나 해결책이 될 수 없다는 것을 알아야 한다.
반응형
'잘난놈되기' 카테고리의 다른 글
| "SD-128C Package" 구매 (0) | 2008.03.05 |
|---|---|
| 디그(Digg) + 팟캐스트(Podcast) = 영어 공부 (0) | 2008.01.04 |
| ISTQB Syllabus 2005 통합정리 (5. Test Management) (0) | 2007.10.31 |
| ISTQB Syllabus 2005 통합정리 (4. Test design techniques) (0) | 2007.10.25 |
| ISTQB Syllabus 2005 통합정리 (3. Review) (0) | 2007.10.22 |
