들어가며


'Import Export Tool for QC'(이하 IET)란 Quality Center 또는 TestDirector 와 같은 테스트 관리 도구에 작성된 데이터들을 보다 쉽고 편리하게 추출, 이동, 변경할 수 있는 유틸리티이다.


2010.07.07 현재 최신버전은 v1.8 로 업데이트



UT는 아래 테스트 관리 도구와의 연동을 지원한다.

Quality Center 9.0 (partial support for 9.2)
Quality Center 8.2
TestDirector 8.0


UT은 아래와 같은 세부 구성요소들을 포함하고 있다.

·      XML Reporting Utility Tool

·      SQL Reporting Utility Tool

·      Test Set Wizard

·      General Utilities

·      Copy Utility

·      Data Importer/Exporter

·      General TD/QC Reporting


'General Utilities'를 이용해 아래와 같은 많은 작업들을 손쉽게 처리할 수 있다.

General Reporting Utility

General reporting utility is a set of reports that you can take out from TestDirector or Quality Center. It will export data into Excel format and also into graphs.

Current Reports:

Grouping Grid Report

 

Cross Test Set

  • Test Case Results per Test Set (Excel export)
  • Cumulative Run Results for Test Case (Graph)

Category

  • Group By Test Case
  • Group By Run

Requirement Report

  • Tree Report

 

Test Case Report

  • Test Cases Not Covering Requirements
  • Detailed Test Case Report:

 and Detailed Test Case Report Sample

With this report you can also export Test Cases with Design Steps from Quality Center, see Test Cases with Design Steps Export Sample. This export includes also parameter values if Call to Test -feature is in use.

   

Test Performance Reports

  • Daily Test Performance

  • Weekly Test Performance

XML Reporting

  • XML Reporting will help you to export all your relevant data out from Quality Center or TestDirector into XML format for further analysis. You can then open this XML file for example in Excel.
  • To use this, you do not have to have any knowledge over database structure, you just select the fields you are interested and filters and it will output XML file using linked entities.

SQL Reporting

  • Using this it is possible to export all data from TestDirector or Quality Center project into XML or Excel format.
  • Includes also SQL syntax highlightning.
  • For using this utility you will need to know underlying database structure.



TCL 추출하기(클릭하면 이미지가 정상적으로 출력됩니다.)


1. General Reporting Utility 실행

서두에 언급했듯이 Trial Version이라 실행 직후 몇 초간의 대기시간이 주어진다.

잠시 기다린 후 우측의 'Try'를 선택하자.



2. 새 보고서 유형 선택


테스트 케이스를 추출할 것이므로 'Import New > By Test Set...'항목을 선택한다.



3. QC서버 로그인


테스트 셋 정보를 가져올 QC서버의 유효성과 권한 여부를 확인하기 위해 URL 과 ID/패스워드 입력 후 'Connect'를 선택하자.

서버 접속과 권한 확인이 성공하면, 아래의 도메인/프로젝트가 활성화 된다.

추출하고자 하는 테스트 셋이 위치한 도메인/프로젝트를 선택하고 'OK'를 선택한다.



4. 필드에 대한 필터 생성


각 필드에 지정된 필터항목들을 생성하기 위한 단계이다.

추출을 원하는 테스트 셋을 지정하고 'ok'를 선택한다.



5. 필터항목 선택


추출된 필터항목들이 나열되고 여기서 실제로 사용할 필터를 선택 후 'ok'를 누른다.

아래 스크린샷에 선택된 필드만 이용하여 예제를 생성할 것이다.



6. 데이터 파일 생성

최종산출물 작성에 필요한 실질적인 정보를 담고있는 데이터 파일의 경로 및 이름을 지정 후 저장한다.



7. 보고서 형식 선택


데이터 파일 저장이 완료되면 보고서 형식 선택화면이 출력된다.

아래 그림처럼 'Test Case Report'를 선택 후 'Next'를 선택한다.



8. 테스트 케이스 유형 선택


'Detailed Test Case Report'와 'Use Filtering'을 체크하고 'Next'를 선택한다.



9. 보고서에 사용할 필드 선택

테스트 케이스 양식에 포함되어야 할 필드만 체크 후 'Finish'를 선택한다.



10. 테스트 케이스 필드 순서 지정

테스트케이스의 각 필드들의 순서(상위항목이 왼쪽부터 정렬됨)를 지정 후 'Finish'를 선택한다.



11. 테스트 케이스 저장 경로 및 파일 이름 지정

엑셀로 저장될 파일 경로와 이름을 지정 후 '저장'을 선택한다.




12. 완성된 테스트 케이스 확인

생성된 파일을 조회하면 다음과 같이 잘 정리된 TCL이 완성된다.(클릭하면 정상적으로 출력됩니다.)


'IT와 생활' 카테고리의 다른 글

KVM-over-IP 구매 가이드  (0) 2010.11.10
라리탄 Dominion KX2 KVM 사용자 가이드  (0) 2010.11.09
국가 코드와 언어 코드  (0) 2010.06.29
[성능] 사용자의 개념과 이해  (0) 2010.06.09
Google TV 에 대한 정보들  (0) 2010.05.24

WRITTEN BY
하이런

,

 본 게시물의 목적달성을 위해 우리에게 insignificant(하찮은), minor(중요하지 않은), significant(의미있는), major(중대한) 그리고 critical(치명적인) 의 5가지 결함 등급이 주어졌다고 가정하자.
우리가 프로젝트의 한 단계를 종료하고 다음 단계로 접어들 때, 우리는 테스트 매니저에 의해 설정되는 기준을 인지할 필요가 있으며 이것이 꼭 수반되어야 한다. 보통 한 단계의 종료 기준이 다음 단계를 위한 시작기준이 된다. 예를 들면 대규모의 통합 테스트에서 테스트 매니저는 그 자신만의 시작기준을 정의할 것이며 기본적으로 이것이 이전단계에 대한 종료기준이 되는 것이다. 이는 제품의 출시 시점에서 이상적인 수단이 된다.

내가 강조하고 싶은 것은 두 가지 핵심 요소이다. 출시 시점에 남아있는 결함이 하나도 없을 것이라고 말하는 테스트 매니저는 마치공상의 세계에서 살고 있는 것과 같다. 이것은 평생 테스트 할 수 있기를 바라고, 완벽한 코드를 출시하고자 하는 테스트 매니저이다. 이는 현실적으로 불가능한 일이다. 비즈니스의 현실은 프로젝트를 착수하고, 사업 요구사항을 만족시키며, 첫번째 예시에서 프로젝트를 정당화하기 위해 사용된 비즈니스 혜택들을 제공하기 위해 어느 정도의 리스크는 수용될 수 있는 것이다. 


그래서 다음 질문은 리스크의 수준과 수용될 수 있는 것이 무엇인가이다. 이는 프로젝트의 특성에 따라 좌우될 것이다. 안전과 밀접하게 연관된 어플리케이션을 포함하는 것은 소규모 비즈니스에서 두 사람에 의해 사용되는 것 보다는 훨씬 더 높은 수준의 품질 요구사항을 가질 것이다. 일반대중이나 많은 고객들에게 노출되는 것 역시 내부적으로만 사용되는 것 보다 훨씬 더 높은 품질을 보장할 필요가 있을 것이다. 테스트 매니저의 능력은 어플리케이션의 사용 목적을 평가하는 것이며 허용할 수 있는 결함의 수준을 정의하는 것이다. 시작, 종료기준을 언급한 문서(http://tcl-india.blogspot.com/2008/06/entry-and-exit-criteria.html)에서 이전에 정의한 것처럼 프로젝트 후반에 지원을 보장하기 위해 프로젝트 매니저가 그런 단계들이 실행될 수 있도록 해야한다.

지금 당장 우리는 수용될 수 있는 결함들을 살펴봐야 한다. 일반적인 오해는 치명적인 결함이 우선순위나 심각성이 '0' 인 수준을 확인하는 것이지만, 사소한 결함의 수준에 대한 제한이란 존재하지 않는다. 이는 현실에서 그대로 드러난다. 하나의 사소한 결함이 출시를 가로막지는 않지만, 다수의 사소한 결함들이 어플리케이션의 출시를 허락하지 않을 수 있다.

나는 우리가 일단 결함의 심각성에 집중하기를 제안한다. 우리는 다수의 insignificant 가 하나의 minor 와 같고, 다수의 minor 가 하나의 significant 와 같다는 식으로 비례적으로 이해할 필요가 있다. 이는 어플리케이션의 용도에 따라 바뀔 수 있다. 그래서 각기 다른 어플리케이션 유형에 대한 몇가지 제안을 제시한다.

안전과 밀접한 어플리케이션
Proportions: 1 Critical = 2 Severe : 1 Severe = 3 Significant : 1 Significant = 5 Minor : 1 Minor = 10 Insignificant
Final Exit Criteria: 0 Critical : 0 Severe : 0 Significant : 5 Minor : 10 Insignificant


일반적인 상용 어플리케이션
Proportions: 1 Critical = 3 Severe : 1 Severe = 5 Significant : 1 Significant = 10 Minor : 1 Minor = 20 Insignificant
Final Exit Criteria: 0 Critical : 0 Severe : 3 Significant : 10 Minor : 20 Insignificant


내부적인 용도로 사용되는 어플리케이션 (20 + Users)
Proportions: 1 Critical = 4 Severe : 1 Severe = 7 Significant : 1 Significant = 15 Minor : 1 Minor = 50 Insignificant
Final Exit Criteria: 0 Critical : 1 Severe : 5 Significant : 10 Minor : 40 Insignificant


내부적인 용도로 사용되는 어플리케이션 (0 to 20 Users)
Proportions: 1 Critical = 5 Severe : 1 Severe = 10 Significant : 1 Significant = 20 Minor : 1 Minor = 100 Insignificant
Final Exit Criteria: 0 Critical : 2 Severe : 5 Significant : 10 Minor : 50 Insignificant


WRITTEN BY
하이런

,
소프트웨어 테스팅에서 빌드 인수 테스트라고도 알려진 빌드 검증 테스트는 빌드가 테스트팀으로 전달되기 전에 그 빌드가 테스트 가능한지를 검증하기 위해 제품의 새로운 매 빌드에 대해 수행하는 일련의 테스트들이다. 빌드 인수 테스트는 보통 어플리케이션 소프트웨어의 주요 기능을 시험해보는 소규모 테스트 셋이다. BVT를 통과하지 못한 빌드는 거부되고 테스트는 이전의 빌드(인수 테스트를 통과한 최소 하나의 빌드가 제공된)로 계속 진행한다.

BVT는 빌드에 심각한 문제가 있는지 개발자가 즉시 알 수 있도록 하기 때문에 중요하며, 불안정한 빌드를 테스트 하는 것을 방지함으로써 테스트 팀의 시간 낭비와 좌절을 줄여준다.


WRITTEN BY
하이런

,

S/W 벤치마크테스트 평가모델 개발 이슈

*한국정보통신기술협회 시험인증연구소 S/W시험인증 센터

The Development Issue of S/W Benchmark Test

Evaluation Model

 

-요약-

국내 벤치마크테스트는 일반적으로 각 제품의 기능별 성능별 비교분석을 통해 제품의 장단점을 파악하는 것이 주된 목적이었다 기존 벤치마크테스트의 산출물은 시험 항목별 결과와 비교 분석 결과이다. 최근에는 동종 제품들 중에서 특정 목적에 가장 적합한 제품을 선택하기 위한 수단으로 벤치마크테스트 결과가 사용되기도 한다. 이러한 특수한 목적의 벤치마크테스트는 기존 산출물 이외에 특정 목적에 가장 적합한 제품이 무엇인지 판단할 수 있는 순위표가 추가된다. 최근의 새로운 요구사항을 반영하기 위해서는 새로운 S/W 벤치마크 테스트 평가모델이 필요하다. 본 논문에서는 기존의 벤치마크테스트와 구분되는 소비자의 새로운 요구를 만족시킬 수 있는 S/W 벤치마크테스트 평가모델 개발 이슈에 대해 연구하고 있다.

 

1. 서론

 

국내 S/W 산업이 점차 성숙해감에 따라 유사한 제품의 개발이 많아지고 점점 군을 형성해 가고 있는 추세이다. 다양한 동종 제품의 개발로 인해 사용자는 자신의 사용 목적에 보다 적합한 제품을 선택할 수 있게 되었다. 그러나 많은 동종제품 가운데 사용자 자신이 다양한 제품을 직접 사용해보지 않고 용도에 맞는 최적의 제품을 선택하는 것은 쉬운 일이 아니다. 이때 객관적이고 공정한 S/W 벤치마크테스트 결과를 확보할 수 있다면 보다 쉽게 좋은 제품을 선택할 수 있을 것이다.

 

구매자 입장에서 벤치마크테스트는 객관적인 테스트 결과를 통해 각 제품의 장단점을 올바로 파악할 수 있게 하여 구매 목적에 보다 근접한 제품을 선택하는데 유용한 지침이 될 수 있다. 반면 개발사 입장에서 벤치마크테스트는 동종 제품들 간의 객관적인 비교평가를 통해 각 제품의 강점을 파악하고 취약점 보완 및 개선방안을 제시할 수 있으므로 품질향상에 큰 도움을 줄 수 있다.

 

또 다른 목적의 벤치마크테스트는 유사 제품들간의 기능 및 성능의 우선순위를 결정하는데 목적을 둘 수도 있다. 일례로 공공기관 및 대규모 조직에서 도입할 제품을 선정하고자 할 때 중립의 위치에 있는 전문 기관에 제품의 우선순위를 결정하기 위한 벤치마크 테스트를 의뢰하는 경우도 최근 들어 많은 수요가 발생하고 있다.

 

기존의 비교 분석을 위한 벤치마크 테스트는 산출물로 각 평가 요소별 평가 값과 비교 분석서를 산출하지만 요구에 의한 우선순위를 결정하는 벤치마크테스트는 부가적으로 목적 평가 기준에 기반한 제품별 우선순위를 산출하게 된다. 이러한 순위 산출을 위한 벤치 마크 테스트는 무엇보다 기본 목적이 명확해야 하며 이러한 벤치마크테스트는 시험에 응하는 제품을 대부분 수용할 수 있어야 한다.

비교분석을 위한 벤치마크테스트는 시험제품을 선정함에 있어 LINUX OS들에 대한 벤치마크테스트, 백신 S/W들 간의 벤치마크테스트 등과 같이 동종의 국한된 S/W를 대상으로 시험을 진행하는 반면, 순위를 결정하는 벤치마크 테스트는 벤치마크테스트의 목적에 부합하는 어떠한 제품도 시험에 응할 수 있다.

이러한 소비자의 새로운 요구사항을 반영하기 위해서는 기존의 벤치마크테스트 평가모델과 구별되는 특수 요소가 반영된 새로운 S/W 벤치마크테스트 평가모델의 개발이 절실히 필요하다.

 

본 연구에서는 이러한 요구사항을 만족시킬 수 있는 벤치마크테스트 평가모델 개발 및 프로세스에 대해 연구하고 있으며 향후 산업계에서 벤치마크테스트 수행 시 지침으로 활용할 수 있도록 하고자 한다.

 

2. 프로세스 정의

 

효율적인 벤치마크테스트 수행을 위해서는 벤치마크테스트 프로세스 정의가 선행되어야 한다. 그림은 일반적인 벤치마크테스트 수행을 위한 프로세스를 단계, 활동, 작업으로 구분하여 도식화 한 것이다.

 

2.1 벤치마크테스트 프로세스

 

2.1.1 요구분석 단계

시험 대상 항목과 벤치마크테스트 항목 리스트를 도출하기 위해 대상 S/W에 대한 철저한 분석을 실시한다. 분석 이후 항목 도출 시에는 벤치마크테스트에 참여하는 제품의 업체 개발자 및 담당자들과의 미팅을 통해 도출 항목에 대해 합의하고 실제 벤치마크테스트 가능 여부를 검증하기 위해 프로토 타입 단계를 포함하여 설계단계에 앞서 준비해야 할 조건을 파악한다.

 

2.1.2 계획단계

요구분석 단계에서 도출한 결과물들을 토대로 일정 및 자원 투입 계획을 구체적으로 산정한다.

 

 


[
그림 1] S/W 벤치마크테스트 프로세스

 

별도의 교육이 필요한 경우 교육 계획을 수립하며 전문가 그룹을 구성하도록 한다. 시험환경 구축을 위한 환경설정과 시험도구 및 S/W 선정도 계획단계에서 이루어진다.

 

2.1.3 설계 단계

계획 수립 이후 도메인별 전문가 그룹을 구성하여 시험 대상 주요 항목 및 부가항목을 선정한다. 벤치마크테스트 항목 확정 이후 항목별 측정기준 및 공식을 도출하여 매트릭을 작성하고, 벤치마크 테스트에 참여하는 업체들과 항목에 대한 합의를 진행한 후 벤치마크테스트 평가모델을 완성한다.

 

2.1.4 실행 단계

개발된 평가모델의 각 항목 별 벤치마크테스트를 수행한다. 비교 대상 제품별로 동일한 조건에서 시험을 실시하고 시험 결과가 도출되면 결과에 대한 문제점을 정밀 검토 후 필요한 경우 보완 시험을 수행하고 결과를 정리한다.

 

2.1.5 마감 단계

벤치마크테스트의 절차 방법 및 비교분석 결과를 정리 검토하고 결과에 대한 고객 의견을 조사한다. 최종적으로 벤치마크테스트 과정 및 결과를 저장한다.


 

[ 1] 유형별 벤치마크테스트 프로세스

 

단계

활동

비교분석 벤치마크테스트 작업

순위도출 벤치마크테스트 작업

요구분석

S/W분석 및 업체상담

1. 대상 S/W 분석(프로그램, 매뉴얼, 기타 관련자료)

2. 시험 대상항목 및 벤치마크테스트 항목 리스트 도출

3. 해당 업체들과 상담

(벤치마크테스트 항목 등)

4. 항목별 시험 절차 및 방법 정의

5. 투입공수 및 수수료 산정

1. 대상 S/W 분석(프로그램, 매뉴얼, 기타 관련자료)

2. 시험 대상항목 및 벤치마크테스트 항목 리스트 도출

3. 벤치마크테스트 의뢰기관과 상담(벤치마크테스트 의뢰기관이 요구하는 항목 및 일반적인 벤치마크테스트 항목 등)

4. 항목별 시험 절차 및 방법정의

5. 투입공수 및 수수료 산정

계획

일정 및 자원 투입 방안

1. 인력 및 자원 투입 계획

2. 일정 계획

3. 교육 계획

4. 전문가 그룹 구성(Optioanl)

1. 인력 및 자원 투입 계획

2. 일정 계획

3. 교육 계획

4. 전문가 그룹 구성(Optioanl)

시험 환경 구축 방안

1. 시험 환경 설정

2. 시험 도구 및 S/W 선정

1. 시험 환경 설정

2. 시험 도구 및 S/W 선정

설계

벤치마크테스트 항목 도출

1. 전문가 그룹 운영(optional)

2. 벤치마크 항목 확정

3. 매트릭 작성(항목별 측정기준 및 공식 도출)

4. 해당 업체들과 합의

1. 전문가 그룹 운영

2. 벤치마크 항목 확정

3. 항목별 가중치 부여

4. 항목별 배점 부여

5. 과락 항목 선정

6. 매트릭 작성(항목별 측정기준 및 공식 도출)

7. 전문가 그룹 및 의뢰기관과 합의

항목별 벤치마크테스트 방법 개발

1. 벤치마크테스트 절차 개발

2. 벤치마크테스트 방법(시나리오, 스크립트, 테스트케이스 등) 개발

1. 벤치마크테스트 절차 개발

2. 벤치마크테스트 방법(시나리오, 스크립트, 테스트케이스 등) 개발

시험환경 구축

1. 시험 환경 구축

2. 시험 도구 및 S/W 설치

1. 시험 환경 구축

2. 시험 도구 및 S/W 설치

실행

벤치마크테스트 수행

1. 벤치마크테스트 항목별 시험 진행

1. 벤치마크테스트 항목별 시험 진행

검토

1. 문제점 정리/협의

2. 보완 시험

3. 결과 정리

1. 문제점 정리/협의

2. 보완 시험

3. 결과 정리

보고서 작성

벤치마크 절차, 방법 및 비교분석 결과 정리

벤치마크 절차, 방법 및 비교분석 결과 정리

마감

검토

벤치마크 결과 검토

벤치마크 결과 검토

 

2.2 순위도출 형 프로세스 고려사항

[1]은 비교분석 형 벤치마크테스트와 순위도출 형의 벤치마크테스트의 프로세스를 비교한 도표이다. 도표에서 나타나듯이 일반적인 비교분석형 벤치마크테스트와 순위도출 형 벤치마크테스트는 동일한 프로세스를 준수하지만 각 단계별로 약간의 차이를 갖는다.

 

2.2.1 요구분석 단계

비교분석 형에서 벤치마크테스트 항목 협의 주체는 벤치마크테스트에 응하는 업체 벤치마크테스트 수행기관 전문가집단이다. 항목을 도출하고 확정하는 단계에서 특정 제품 또는 특정 기능에 편중되지 않도록 모든 참여 업체들과 협의 조율 과정이 수반된다.

반면 순위도출 형에서의 항목 협의 주체는 벤치마크테스트 의뢰기관, 벤치마크테스트 수행기관 전문가집단이다. 벤치마크테스트에 응하는 업체는 협의 주체 대상에 포함될 수 없다. 항목을 도출하고 확정하는 단계에서 의뢰 기관이 요구사항을 정확히 파악하고 전문가 집단 및 수행기관과의 협의 조율 과정이 수반된다.

 

2.2.2 설계 단계

설계단계의 최종 산출물은 벤치마크테스트 평가 모델이다. 최종 확정된 평가 항목들은 요구분석 단계와 마찬가지로 각각 참여 업체들과의 합의(비교분석형), 의뢰 기관과의 합의(순위도출형)를 필요로 한다.

[1] 의 순위도출형 설계단계의 작업 영역을 살펴보면 평가모델 개발시 부가적으로 고려해야 할 사항으로 항목별 가중치 항목별 배점 과락 항목에 대해 언급되어 있다. 벤치마크테스트 목적에 따라 평가모델 개발 요소가 크게 달라짐을 알 수 있으며, 각 사항의 내용에 대해서는 3장에서 다루고 있다.

 

2.2.3 마감 단계

벤치마크테스트 수행 종료 후 마감단계에서는 각각 벤치마크테스트 항목 별 비교 분석 결과와 순위 표(순위도출형)를 산출하게 된다 결과에 대한 공표는 전자의 경우 각 참여업체들에게 공개되고 일반에 공표 여부는 또 다른 프로세스를 거쳐 공표 여부가 결정되게 된다. 하지만 후자의 경우 벤치마크테스트의 결과가 의뢰 기관에만 공개되며 참여업체 및 일반에 공개하지 않는다.

 

3. 평가모델 개발 이슈

 

3.1 가중치 부여

 

가중치는 시험 대상 제품의 평가항목 중요도에 따라 차등적으로 부여해야 하며 벤치마크테스트 의뢰기관, 벤치마크테스트 수행기관, 전문위원 3자의 충분한 의견 수렴을 거친 후 결정되어야 한다.

세부항목을 기준으로 벤치마크테스트 항목의 중요도를 2단계(필수항목, 부가항목)로 구분하여 가중치를 부여하는 방법, 3단계(필수항목, 중요항목, 부가항목)로 구분하는 방법 또는 더욱 세밀하게 구분하여 가중치를 부여할 수 도 있다. 하지만 통상적으로 2단계 또는 3단계 구분이 일반적인 가중치 부여 방법으로 사용되고 있다.

 

항목의 중요도를 3단계로 구분할 경우 평가모델이 간결하고 명확해 지는 반면 정밀도는 보다 세밀한 구분방법 보다 덜하게 된다. 반면 3단계로 구분할 경우 보다 정밀한 평가가 가능하지만 제품의 순위에 변동을 줄 만큼의 차이를 발생시키는 일은 드물다. 선정하기 위한 벤치마크 테스트에서는 제품을 도입하려는 벤치마크테스트 의뢰기관에서 중요하게 여기는 필수항목에 통상 50%이상의 배점을 할당하기 때문에 더욱 그러하다.

 

[2] [3] TTA에서 기 수행한 순위선정을 위한 벤치마크테스트 사례 중 일부 데이터이며, 가중치 단계와 항목 수를 나타내고 있다. 해당 벤치마크테스트에서는 총 40개의 세부항목에 대해 2단계 가중치를 4:1 비율로 부여하여 적용하였다.

 

[2] 2단계 가중치 및 항목 수

 

 

기능성

사용성

효율성

이식성

합계

필수항목

16

5

3

5

29

부가항목

5

2

2

2

11

합계

21

7

5

7

40

 

 [3] 3단계 가중치 및 항목 수

 

 

기능성

사용성

효율성

이식성

합계

필수항목

13

3

3

3

22

중요항목

5

2

1

2

10

부가항목

3

2

1

2

8

합계

21

7

5

7

40

 

 

3.2 배점 기준

 

3.2.1 하향식 및 상향식 배점 부여

품질특성, 분류, 평가항목, 세부항목, 시험항목, 테스트케이스의 6단계의 레벨로 구성된 평가모델을 예로 들면 품질특성별로 큰 점수를 부여한 후 하향식으로 점수를 배분하는 Top-Down 방식과 테스트케이스마다 작은 점수를 부여하여 상향식으로 점수를 합산하는 Bottom-Up 방식이 존재한다. 언급한 두 가지 방식이 SW 벤치마크테스트의 일반적인 배점방식이다. 상기 가중치 부여 결과를 그대로 점수화하여 다음 하위 레벨에 배점하는 경우가 Top-Down 방식에 해당할 수 있다. 이렇게 Top-Down 방식을 적용할 경우 최하위레벨의 테스트케이스들 간의 형평성이 결여될 수 있는 문제점이 발생한다. 이러한 문제점은 Bottom-Up 방식의 장점을 반영함으로써 어느 정도 해소할 수 있다.

Bottom-Up 방식을 적용할 경우에는 가중치 부여 시 구분했던 필수항목, 중요항목, 부가항목들 각각에 대해서는 항목 내부에서 동일한 배점을 적용해야 한다. 이렇게 함으로써 Top-Down 방식을적용함으로써 발생하는 형평성 결여 문제점을 일부 해소할 수 있다.

 

3.2.2 기능구현여부와 기능구현 정확성

순위를 선정하는 벤치마크테스트는 기존 벤치마크테스트보다 다양한 제품들이 벤치마크테스트에 참여한다. 이때 기능 평가 항목이 모든 제품을 수용하기는 현실적으로 불가능하다. 어떠한 항목에 대해 해당 제품의 모호한 구현은 Pass/Fail을 판단하는데 어려움이 있다.

따라서 명확한 기준을 마련하기 위해 기능성에 속한 벤치마크테스트 항목은 실제 해당 기능

이 구현되어 있는지를 시험하는 기능구현과 구현된 기능이 의도한대로 정상 동작 하는지

여부를 시험하는 정확성으로 구분하여 배점한다.

이렇게 구분된 배점을 통해 모호하게 구현된 기능에 대해 부분점수를 부여할 수 있으며 부분 점수의 적용을 통해 벤치마크테스트를 수행하면서 발생할 수도 있는 오 측정의 역효과를 부분적으로 감소시킬 수 있다.

 

3.3 과락 항목 설정

 

구매를 위한 우선순위 도출을 목적으로 하는 벤치마크테스트 수행 시 대상 제품은 시험수행

기관 또는 의뢰기관에서 선정하는 것이 아니라 신청에 의해 접수된 제품을 대상으로 벤치마

크테스트를 수행하게 된다. 이러한 경우 목적에 부합하지 않는 제품들도 벤치마크테스트에 신청하는 경우도 있다.

과락 항목의 범위는 벤치마크테스트 의뢰자가 반드시 구현되어야 하며 정상적인 동작을 보장해야 한다고 여기는 항목과 간단한 예로 제품은 정상적으로 설치 가능해야한다와 같은 시험 진행을 위한 필수 기본 항목으로 구성한다.

과락 항목 채택 여부는 실질적으로 벤치마크테스트 의뢰자와 협의 하에 채택하여야 하며, 이러한 과락 항목에 대해서는 모집공고 시 명확하게 공시하여야만 한다.

 

과락 항목에 대한 모집공고를 명확하게 공시하여도 해당 요구사항을 만족하지 못하는 제품들이 실제 벤치마크테스트에 응하는 사례가 다수 존재하며 현재까지 TTA에서 수행한 순위선정을 위한 벤치마크테스트 참여 업체 중 37.5% 가량이 해당 케이스로써 실격한 전례를 보인다. 일반적으로 과락 항목은 배점을 부여하지 않으며 Pass/Fail 형태의 특수 항목으로 분류한다.

  

4. 결론 및 향후 연구

 

본 논문에서는 각 제품의 기능별 성능별 비교분석을 통해 제품의 장단점을 파악하는 것을 목적으로 하는 기존의 벤치마크테스트 외에 최근 수요가 늘고 있는 순위 도출을 목적으로 하는 벤치마크테스트에 대해 연구하고 각 단계별로 주요 점검 요소를 도표로 정리하여 나타내었으며, 세부적으로 상이한 요소에 대해서 자세한 설명을 통해 해당 벤치마크테스트 프로세스 및 평가 모델 개발과 관련한 지침을 제시하였다.

향후 보다 다양한 가중치 부여 방법 개발에 관한 연구와 보다 공정한 배점기준에 관한 연구를 지속적으로 진행하여 평가모델에 반영하여야 하며, 이러한 연구를 통해 벤치마크테스트 목적에 부합하는 적합한 평가모델 개발이 가능할 것이라 예상된다.

 


[
참고문헌]

[1] Benchmark handbook, http://www.benchmarkresoruces.com/handbook, 2004

[2] 소프트웨어 벤치마크테스트(BMT) 현황, 김재웅, 신석규, 20053, 정보처리학회지

[3] S/W 벤치마킹 테스트 및 품질 표시제 시행 방안에 관한 연구 보고서, 한국정보통신기술협회(TTA), 2002

[4] S/W분야별 벤치마킹 테스트 모델 개발 및 시범서비스에 관한 연구 보고서, 한국정보통신기술협회(TTA), 2002

[5] 벤치마킹 테스트 보고서, 한국정보통신기술협회(TTA), 2004

[6] 소프트웨어 품질 벤치마킹을 위한 평가기술에 관한 연구, 한국정보통신기술협회(TTA), 2001


'IT와 생활' 카테고리의 다른 글

[QA] Pairwise Testing(페어와이즈 테스팅)  (0) 2009.01.19
MS SQL 서버 버전 확인하기  (0) 2009.01.06
entry criteria vs exit criteria  (0) 2008.11.06
Severity Vs Priority  (0) 2008.11.03
Entry and Exit Criteria  (0) 2008.11.03

WRITTEN BY
하이런

,