'QC'에 해당되는 글 88

  1. 2005.11.18 통합사용자 기반의 결함추적시스템 논문
  2. 2005.11.18 SW 테스트 도구 (국내에서 사용되고 있는 툴 중심)
  3. 2005.11.18 소프트웨어 품질 보증(SQA) 자료
  4. 2005.11.17 해외 동향 및 CBD 성공사례 목 차 컴포넌트 관련 선진국 기술동향 해외 CBD
  5. 2005.11.17 MBASE에 의한 프로젝트 관리
  6. 2005.11.17 Model-Based Architecting and Software Engineering(MBASE)
  7. 2005.11.17 Setting up and Managing a Test Lab(PPT 번역)
  8. 2005.11.17 [ISTQB] Random Testing
  9. 2005.11.17 Test Process [PPT파일] 입니다.
  10. 2005.11.17 개발팀 테스팅과 테스트팀 테스팅
  11. 2005.11.17 TPI (Test Process Improvement) 개요
  12. 2005.11.17 TPI (Test Process Improvement) 테스트 성숙도 평가 도구-Excel 파일
  13. 2005.11.17 GUI Test Checklist
  14. 2005.11.17 테스트 케이스가 잘 작성되었는지 검토하는데 사용하는 체크리스트 1
  15. 2005.11.17 üũ
  16. 2005.11.17 품질 관리 (Quality Management)
  17. 2005.11.17 품질관리(QC) 7가지 도구
  18. 2005.11.07 [리뷰 & 벤치마킹]CPU 4종-성능테스트
  19. 2005.11.07 성능 테스트
  20. 2005.11.07 TTA 성능 평가

통합사용자 기반의 결함추적시스템 논문

통합사용자 기반의 결함추적시스템 논문

SW 테스트 도구 (국내에서 사용되고 있는 툴 중심)

 



SW 테스트 도구 (국내에서 사용되고 있는 툴 중심)


(가격은 일반적으로 사용자 수, 프로토콜 등에 따라 변동적입니다.)









































































































이름 (제작사)


용   도


비고


e‐TEST Suite (Empirix)


웹 어플리케이션 전문 기능 및 부하테스트 자동화 및 관리 도구 패키지


e‐Tester, e‐Load, e‐Manager,
e‐Reporter


e‐Tester (Empirix)


Web 어플리케이션의 기능 및 회귀 테스트 자동화 도구


 


e‐Load (Empirix)


가상 유저를 생성하여 웹 어플리케이션 및 시스템의 성능/부하 테스트


 


OneSight (Empirix)


웹 어플리케이션 성능 감시 모니터링 도구


 


WinRunner (Mercury Interactive)


Windows 어플리케이션의 기능테스트 자동화 도구


 


LoadRunner (Mercury Interactive)


가상 유저를 생성하여 시스템 성능/부하 테스트


 


Topaz (Mercury Interactive)


성능 모니터링 도구. 기능 테스트 및 성능 테스트를 거쳐 시스템이 Open된 이후, 실제 운영환경에서의 시스템 성능 모니터링.


 


TestDirector (Mercury Interactive)


Web‐based 테스트 케이스 관리 도구


 


QARun (Compuware)


Windows 어플리케이션의 기능테스트 자동화 도구


 


QALoad (Compuware)


가상 유저를 생성하여 시스템 성능/부하 테스트


 


Application Expert (Compuware)


시스템 성능 모니터링


 


QACenter (Compuware)


Capture and replay에 의한 기능 시험


 


QADirector (Compuware)


테스트 프로세스 관리


 


Performance (Test) Studio (IBM Rational)


가상 유저를 생성하여 시스템 성능/부하 테스트


 


Robot (IBM Rational)


Capture and replay에 의한 기능 시험


 


Silk Test (Segue)


Capture and replay에 의한 기능 시험


 


CodeScroll (슈어소프트텍)


소스코드 기반 테스팅 도구로써, 별도의 명세가 없더라도 테스팅을 수행할 수 있음. 테스팅의 모든 과정을 "자동화"하여 테스터의 도움이 없더라도 테스팅 수행이 가능.


사용자당 0.15억.


sales@suresofttech.com


이지트랙 (퍼슨넷)


개발과정에서의 버그 리포팅 및 관리, 출시전 베타 테스트 관리, 출시 후 사용 고객의 문의 사항 관리


 


RESORT for Java (소프트4소프트)


Java 언어를 이용하여 소프트웨어를 개발하거나 또는 개발된 기존의 Java 소프트웨어의 소스 코드 분석


042‐866‐6632


McCabe IQ  (McCabe)


소스 코드 분석. 사용자는 Source Code의 구조와 흐름, 복잡도를  살펴 볼 수 있음. 


02‐578‐3528


QAC/QAC++/QAJ (PRQA)


구문분석을 통한 코드 인스펙션 자동화 도구


02‐578‐3528


Insure ++ (Parasoft)


소스 코드 분석


 


Jtest (Parasoft)


소스 코드 분석


 


WebKing (Parasoft)


웹 품질 및 트래픽 분석


 





소프트웨어 품질 보증(SQA) 자료

소프트웨어 품질 보증(SQA) 자료

해외 동향 및 CBD 성공사례 목 차 컴포넌트 관련 선진국 기술동향 해외 CBD

첨부문서 참고


MBASE에 의한 프로젝트 관리

MBASE에 의한 프로젝트 관리 2000. 05. 18 중앙대학교 컴퓨터공학과


한글 DOC 파일



Model-Based Architecting and Software Engineering(MBASE)

노츠에 올려진 자료


Setting up and Managing a Test Lab(PPT 번역)

이 글은 sten.cyworld.com 에서 옮겨졌습니다.
작성자 : 신재문
작성일 : 2005.04.11 13:23:00


테스트 랩을 셋업하는데 고려해봐야 하는 내용을 담고 있습니다.
저자가 원래 작성한게 있었는데 그걸 다듬어서 2004년도에 발표했다고 말하고 있습니다.


"I spoke again at Eurostar 2004 in Cologne about setting up a test lab."


제가 번역한 것은 아쉽게도 별 다른 내용은 없겠지만, 2001년도 PDF 네요.


[ISTQB] Random Testing

첨부 참고


Test Process [PPT파일] 입니다.

야후 ISTQB뉴스그룹에서 얻은 자료인데, 혹 벌써 보신분도 많을수 있겠네요.

개발팀 테스팅과 테스트팀 테스팅

* 그림과 표가 들어가지 않아 퍼온글인데 제대로 올라가질 않네요...

요약설명 -
개발하고있는 소프트웨어를 개발자가 어떻게 테스트 하는 것이 효율적인지에 대해 한번쯤은 관심을 가져볼만 하다. 테스팅은 개발과 마찬가지로 체계적인 프로세스가 존재하며 계획과 검증된 기법 및 지식없이 진행할 경우 테스팅이 제대로 되지 않아 결과물의 품질이 낮거나 프로젝트 자체를 실패할 수 있다.

본 아티클에서는 개발자가 어떻게 테스트 해야할지에 대해 세부적으로 다루고 있지는 않지만 해당 아티클이 개발자가 테스트에 대해 진지하게 생각하게 하는 기회는 제공해 줄 것이며, 세부적인 내용은 시간을 두고 살펴보도록 한다.
 
본문 -

테스팅은 V-모델에서와 같이 개발팀에 의한 테스팅과 테스트팀에 의한 테스팅으로 구분되어질 수 있다. 통상적으로 테스트팀이 테스트를 모두 수행해야하고 개발팀은 개발에만 전념해야 한다고 생각할 수 있는데 실상은 그렇지가 않다. 개발 과정에서 테스트팀 또는 QA (Quality Assurance) 조직으로  단계로 넘어가기 전까지는 개발팀에서 테스팅을 해줘야 전체적인 테스팅이 효율적이된다. 개발팀에서 테스팅을 제대로 해주지 못하면 테스트팀에서 테스트해야하는 부담이 클뿐만 아니라 개발되는 소프트웨어나 시스템이 전반적으로 불안정할 위험이 매우 높다. 그뿐만 아니라 개발팀 전체에 개발하는 소프트웨어나 시스템에 대한 자신감 (Confidence)이 없어 개발팀의 사기가 저하될 가능성이 크다. 추가적으로 개발팀 테스트가 중요한 또다른 이유는 초기에 결함을 많이 찾아내면 수정하는 비용이 적게들어 최종적으로 프로젝트 비용을 크게 절감할 수 있기 때문이다. 한마디로 개발팀이 효과적이고 효율적인 테스트를 해주지 않으면 개발 프로젝트가 전체적으로 실패하거나 개발 과정 중 또는 개발 후 비용이 높아지게 된다.

 
                            개발팀 테스팅                              테스트팀 테스팅
 
테스팅 레벨            단위테스트, 통합테스트                  시스템테스트, 인수테스트
 
목적                      안정한 시스템을 개발하는 것          시스템이 요구사항을 충족시킨다는 확신 제공
 
특징                      테스트 프로세스가 상대적으로 단순  복잡한 테스트 라이프사이클 및 활동
 
이상적 테스트        위험 기반 테스팅 기법과 함께 위의 두가지 테스트 접근법을 잘 조합하여야 중요 결함을 발견 가능
 

개발팀에서 주로 관여하는 V-모델에서의 테스팅 레벨은 단위테스트와 통합테스트인데 위와 같은 이유로 효율적이고 효과적으로 테스트하는 것이 매우 중요하다. 개발팀은 안정한 시스템을 개발하기 위해 테스트하는 것이고 가능한 테스트 프로세스를 단순화하여 진행하며 단위테스트 보다는 통합테스트에 집중하는 것이 일반적으로 더 효율적이다.

반면, 테스트팀에서 관여하는 V-모델에서의 테스팅 레벨은 시스템테스트와 인수테스트이며 시스템이 요구사항을 충족시킨다는 확신을 갖기 위해 수행한다. 테스트 프로세스는 테스트팀의 참여자 규모와 소프트웨어/시스템 규모, 지원 기반 환경 (Infrastructure) 등에 따라 달라지나 개발팀 테스트 프로세스에 비해 상당히 복잡한 테스트 프로세스를 가지고 있다. 아래 그림에서 보는 바와 같이 5단계의 큰 프로세스 (절차)와 각 단계별 프로세스별로 세부적인 절차를 가지고 있다. 테스트팀의 규모, 프로젝트의 규모가 작아지면 프로세스를 단순화시킬 수는 있지만 큰 골격은 변하지 않는다. 반면 개발팀 테스트 프로세스는 5단계 중 준비단계와 완료단계를 보통 생략하거나 다른 단계에 포함시켜 크게 3단계정도의 프로세스를 따르며 세부적인 절차도 단순화시켜 효율성을 기한다.

개발팀에서 수행하는 단위테스트는 소프트웨어/하드웨어 각각의 단위(모듈, 컴포넌트)를 다른 부분과의 연계성을 고려치 않고 격리하여 테스트하는 것이고, 통합테스트는 단위 테스트를 통과한 개발 소프트웨어/하드웨어 컴포넌트(모듈)간 인터페이스 및 연동 기능 등을 구조적으로 접근하여 테스트 하는 방법이다. 단위테스트와 통합테스트는 주로 소스코드를 직접 다루면서 테스트를 진행하며, 제어 흐름 테스트 (Control flow test), 개선된 조건/결정 커버리지 테스트 (Modified condition/decision coverage) 또는 최소단위 비교 테스트 (Elementary comparison test), 자료흐름기반 테스트 (Data flow based test), 기본 경로 테스트, 도메인 테스트 (Domain test), 뮤테이션 테스트 (Mutation test), 상태전환 테스트 (State transition test) 기법 등을 이용한다. 이들 테스트 기법의 선정은 테스트 대상 소프트웨어의 특성과 테스트 요구사항, 개발 설계 문서 등의 테스트 베이스 (Test base)의 성격과 존재여부 등을 고려하여 결정한다. 각각의 테스트 기법에 대해서는 뒷부분에서 자세히 다루도록 한다.

테스트 팀에서 수행하는 시스템 테스트와 인수 테스트는 다음번 아티클에서 다룰 계획이다.

정리

    일반적으로 개발자는 본인이 개발한 또는 동료 개발자가 개발한 모듈을 모듈단위, 통합단위에서 테스트하게된다. 이러한 테스팅은 코딩만을 검토하고 동작하는 것만을 확인하는 것에 제한되지 않는다. 테스팅은 개발과 마찬가지로 체계적인 프로세스가 존재하며 계획과 검증된 기법 및 지식없이 진행할 경우 테스팅이 제대로 되지 않아 결과물의 품질이 낮거나 프로젝트 자체가 실패할 수 있다.

TPI (Test Process Improvement) 개요

TPI의 개념을 설명을 TPI를 만든 회사에서 정리해 놓은 파일 입니다.  TPI에 대해 처음 접하시는 분은 본 문서를 먼저 읽어보시는 것이 좋습니다.

TPI (Test Process Improvement)에 대한 관련 문서들이 아래에 있습니다.  참고하시기 바랍니다.

TPI (Test Process Improvement) 테스트 성숙도 평가 도구-Excel 파일

테스트 프로세스 스터디 자료 중의 하나로 TPI 를 실제 적용할때 도움되는 자료입니다. 누군가가 만들어서 올린 자료인데 자발적으로 몇번 업데이트되어 현재의 버전이 탄생했답니다

GUI Test Checklist

GUI를 테스트 하는데 고려해야할 세세한 항목들을 체계적으로 분류하여 상세하게 체크리스트화한 자료입니다. 현업에서 바로 사용할 수 있는 자료이며, 적용하시면서 customize하시면 좋은 성과를 볼 수 있으리라 생각합니다.

이번달 (5월) 23일 ~ 27일까지 5일간 Rex Black 테스팅 교육을 진행하실 Vipul Kocher 께서 강의할 내용 중 Practical한 자료 중의 하나입니다. Rex Black 직강의 실습을 더욱 상세하게 진행하는 것은 물론, 현업에서 바로 활용할 수 있는 템플릿을 제공하고 활용방법도 설명해 드린답니다.

테스트 케이스가 잘 작성되었는지 검토하는데 사용하는 체크리스트

Checklist for Reviewing testcases:

o Accurate - tests what the description says it will test.
o Economical - has only the steps needed for its purpose
o Repeatable, self standing - same results no matter who tests it.
o Appropriate - for both immediate and future testers
o Traceable - to a requirement
o Self cleaning - returns the test environment to clean state Structure and testability
o Has a name and number
o Has a stated purpose that includes what requirement is being tested
o Has a description of the method of testing
o Specifies setup information - environment, data, prerequisite tests, security access, login information,
o Has actions and expected results
o States if any proofs, such as reports or screen grabs, need to be saved
o Leaves the testing environment clean
o Uses active case language
o Does not exceed 15-20 steps
o Is in correct business scenario order with other tests
o Validates all types of input values

üũ

체크리스트 정리



  • 체크리스트는 시간이 지남에 따라 항목이 늘어남.
  • 체크리스트의 위력은 집중력에 있음.
  • 체크리스트가 너무 방대하면 집중력이 떨어짐.
  • 주기적으로 결함 데이터를 검토하여 결함을 발견하는데 별 도움이 안 되는 항목은 삭제해 나가야 함.
  • 삭제된 항목은 다른 항목을 검토할 때 참고할 수 있도록 별도의 항목을 만들어 관리.

체크리스트의 개별적인 관리



  • 어떤 엔지니어가 사용하는 방법이 효율적이라고 해서 다른 분야에서도 유용한 것은 아님.
  • 자신의 체크리스트는 스스로 작성하고 주기적으로 검토해야 함.
  • 코드검토 과정에서 결함을 계속 누락시키는 한 체크리스트를 개선할 수 있는 방법을 지속적으로 찾아야 함.
  • 이러한 개선은 시간이 걸린다는 것을 명심할 것.
  • 초기에는 결함을 발견해내는 능력이 각 검토 단계를 거치면서 향상되겠지만 능력향상이 점점 어렵게 됨.
  • 결함 데이터를 지속적으로 수집하고 분석하면서 어떻게 하면 결함 누락을 억제하고 누락된 결함들을 좀더 잘 찾아낼 수 있을지에 대해 생각해 보아야 함.
    점차 결함을 누락하게 되는 경우가 감소함에 따라 프로그램의 품질도 향상될 것임.

품질 관리 (Quality Management)






6.   품질 관리 (Quality Management)


 


 



6.1   정의


    Project 품질관리는 Project의 요구사항을 만족시키기 위하여 필요한 Process를 포함한다. 이는 품질체계내에서 품질기획(QP), 품질관    리(QC), 품질보증(QA), 품질개선(QI)이라는 도구를 가지고 품질정책, 품질목표, 책임과 이행 등을 실행하기 위한 전반적인 모든 관리기    능과 관련된 행위를 포함하는 것이다.



6.2   품질 관리 Process


    ◇ 품질계획 (Quality Planning)


    ◇ 품질보증 (Quality Assurance)


    ◇ 품질관리 (Quality Control)


6.3   품질 계획 (Quality Planning)


    ◇ 품질방침, 범위명세서, 제품설명서 등을 위하여 Project에 적용되는 품질표준을 확인하고 품질표준의 만족 방법을 결정하는 Process


    ◇ 비용수익 분석 (Cost/Benifit Analysis) 기법


    ◇ Quality Management Plan


    ◇ 검사항목 및 기준치, Check List



6.4   품질 보증 (Quality Assurance)


    ◇ 품질보증계획, 품질관리측정결과등을 이용하여 Project가 관련된 품질표준을 만족하고 있다는 신뢰를 제공할 수 있도록 품질체계내        에서 행해지는 계획적이며 체계적인 모든 활동


    ◇ Quality Audit 기법


    ◇ Quality Improvement(품질개선)



6.5   품질 관리(Quality Control)


    ◇ 작업결과물, 체크리스트, 품질경영계획등을 이용하여 Project의 결과가 품질표준에 부합하도록하며, 또한 불만족한 결과를 제거하는         방법을 찾아내기 위하여 구체적인 Project 결과물을 모니터링하는 Process


    ◇ Control Chart, Pareto Diagram, 통계적 Sampling


    ◇ 합부판정(Acceptance Decision)


    ◇ 공정 조정(Process Adjustment)

품질관리(QC) 7가지 도구

품질관리(QC) 7가지 도구

[리뷰 & 벤치마킹]CPU 4종-성능테스트








◆테스트 환경

 테스트 시스템은 크게 3가지를 준비했다. 펜티엄4 익스트림 에디션(펜티엄4 EE) 프로세서는 기존 875P 메인보드에서 인식가능하기 때문에 펜티엄4 3.2GHz 시스템과 동일한 구성으로 성능을 테스트했다. 애슬론64 프로세서와 애슬론64 FX-51 프로세서는 소켓 형식과 메모리 지원 스펙이 다르기 때문에 각각 별도의 시스템으로 구성해 테스트를 진행했다.



 1. 시스템 성능 측정(산드라 2004)

 용량은 작지만 다양한 방법으로 시스템 성능을 측정하는 산드라 2004 프로그램으로 CPU와 메모리 성능을 측정해 보았다. 먼저 CPU 성능을 측정해 보면 전반적으로 펜티엄4 시스템들이 앞선 성능을 보이고 있음을 알 수 있다.

 가장 앞선 성능을 제시하는 시스템은 펜티엄4 EE로 기존의 펜티엄4 3.2GHz 모델에 비해 큰 성능 향상은 없지만 전반적으로 가장 빠른 성능을 보여주었다. 그 다음으로는 펜티엄4 3.2GHz, 애슬론64 FX-51, 애슬론64 3200+가 뒤를 이었다.





 이 테스트에서 전반적으로 인텔 펜티엄4 솔루션이 우위를 보이는 까닭은 프로그램 안에 제공되는 테스트 항목 자체가 CPU 동작클럭에 민감하게 반응하기 때문이다. AMD의 애슬론(64·FX·XP 포함) 솔루션의 경우 클럭 자체는 낮지만 실제 애플리케이션을 통한 데이터 연산능력은 상당히 높기 때문에 동종의 플랫폼과 비교할 시에는 산술적인 연산능력 비교수치로써 적절한 가치를 가지게 된다고 말할 수 있지만, 인텔 시스템과 같이 동작 클럭이 높은 이종의 플랫폼과 비교할 시에는 형평성이 다소 변질되는 특성을 가진다.

 메모리 대역폭 측면에선 애슬론64 FX-51 시스템의 성능이 크게 돋보인다. 듀얼채널 메모리 인터페이스 지원이라는 장점은 인텔 875P 솔루션 역시 제공하는 특징이지만 인텔 솔루션과는 다르게 애슬론64 FX-51은 CPU 자체에 메모리 컨트롤러를 내장하고 있기 때문에 기존의 노스브릿지를 통한 CPU 메모리간 데이터 전송보다 빠른 데이터 전송 효율을 보장한다.

 CPU와 메모리가 직접 연결돼 상호 데이터 교환을 수행할 수 있는 점은 애슬론64 3200+ 시스템 역시 마찬가지라고 말할 수 있지만 애슬론64 3200+ CPU는 싱글채널 메모리 버스만을 지원하기 때문에 듀얼채널 메모리 버스를 지원하는 애슬론64 FX-51·인텔 875P 솔루션과는 다소 거리가 있는 제한된 대역폭만을 가지게 된다.



 2. 프로그램 수행 능력(MCC윈스톤 2003 1.0)

 다양한 애플리케이션(주로 2D 기반)을 통해 시스템 성능을 측정하는 MCC윈스톤 2003 버전으로 일반적인 프로그램 수행능력을 측정해 보았다. 테스트 결과는 전반적으로 애슬론64 계열이 앞선 성능을 제시하는 것으로 나타났다.

 다만 인텔 솔루션의 결과값에는 한가지 고려해야 할 요소가 있는데 그것은 다름아닌 하이퍼스레딩 기능이다. 이 기능은 현재 인텔 펜티엄4 CPU 에서만 지원되는 강력한 가상 프로세서 구현 기능으로 이를 지원하는 메인보드와 운용체제를 사용할 시에 CPU 분할 연산의 효율성을 극대화시킬 수 있는 매력적인 기능이라고 말할 수 있다.

 캡처 사진에서 볼 수 있듯이 하이퍼스레딩 기능을 켠 상태에선 시스템 상에 두개의 CPU가 장착된 것으로 인식된다. 이러한 환경에선 윈도XP 같은 멀티태스킹 지원 운용체계에서 다수의 응용프로그램을 수행하더라도 두개의 논리적 프로세서가 각 프로그램에 효율적으로 CPU 연산능력을 분배하기 때문에 전체적인 시스템 반응속도가 느려지지 않는 부드러운 체감속도를 제공하게 되는 것이다.

 MCC윈스톤 2003 역시 특별한 설정 없이도 이러한 하이퍼스레딩 기능의 효과를 보게 되는데 테스트 결과값에 나와 있듯이 이 기능을 켰을 경우에는 다수의 프로그램을 통해 시스템 성능을 측정했음에도 불구하고 전체적으로 58%의 CPU 점유율만을 보였음을 알 수 있다. 말하자면 벤치마크 테스트 이외에도 여타 프로그램 구동을 위해 48%에 해당하는 CPU 연산능력을 여분으로 준비해 두고 있었다는 이야기인 것이다.

 애슬론64 FX-51 시스템의 경우 인텔의 하이퍼스레딩 기능 같은 가상 프로세서 구현기능은 제공되지 않기 때문에 전반적으로 높은 CPU 점유율을 보여주는 대신 상당히 빠른 성능을 제공한다. 테스트 결과에서도 이는 쉽게 입증됐다. 애슬론64 FX-51은 펜티엄4 EE의 성능을 앞서고 있으며 애슬론64 3200+은 펜티엄4 3.2GHz 시스템의 성능을 앞서고 있다.

 다만 하이퍼스레딩 기능을 사용하지 않게 되면 펜티엄4 시스템도 상당히 우수한 퍼포먼스를 제공하게 되는 것이 사실이다. 하이퍼스레딩 기능을 사용하지 않을 경우에는 애슬론64 FX-51과 같이 높은 CPU 점유율을 보여주지만 절대적인 성능에서만큼은 애슬론64 FX-51을 앞서는 강력한 성능을 보여주고 있다. 애슬론64 FX-51 솔루션이 64비트 플랫폼 지원이라는 미래지향적인 장점을 가지고 있다면 펜티엄4 시스템은 멀티태스킹 구현환경에 최적화된 솔루션이라는 현실적인 효율성의 측면을 강조하는 셈이다.



 3. 비디오 인코딩 성능 테스트(TMPGEnc 2.521)

 ▲AVI에서 MPEG1으로 변환시 소요된 시간. 짧을수록 좋다. (단위:초)

 ※ 인코딩 소스:PC 게임 ‘헐크’ CF 동영상(640×480픽셀, AVI 포맷, 143MB, 4분 49초)

 ※ 설치된 코덱:통합 코덱팩 7.01



 동영상 변환에 자주 활용되는 TMPGEnc로 비디오 인코딩 성능을 체크해 보았다. 테스트 결과 전반적으로 펜티엄4 솔루션의 우위가 확인됐으며 애슬론64 FX-51 솔루션은 약간 느린 성능을 보였다.

 비디오 인코딩 성능에서 펜티엄4 솔루션이 우수한 성능을 발휘하는 이유는 역시 최적화된 iSSE2 명령어 세트와 하이퍼스레딩 기능의 지원 때문이라고 말할 수 있다. 애슬론64 FX-51 역시 iSSE2 기능을 지원하기는 하지만 iSSE2는 근본적으로 인텔이 개발한 멀티미디어 성능향상 명령어 세트기 때문에 효율성 측면에서 인텔 펜티엄4 아키텍처 위에서 보다 빠르게 동작하는 특성을 가질 수 밖에 없다.

 하이퍼스레딩 기능 역시 비디오 인코딩 성능을 향상시키는 주요한 원인이다. 하나의 물리적인 프로세서를 두개의 논리적인 프로세서로 인식시켜 양방향으로 인코딩 명령을 수행할 수 있기 때문에 단일 프로세서로 인식되는 애슬론64 FX-51 시스템보다는 빠른 성능을 제공한다. AMD 솔루션의 성능 역시 나쁜 편은 아니지만 비디오 인코딩 분야는 아직까지는 인텔 솔루션의 입김이 강하게 작용하는 분야라 할 수 있다.



 4. 3D 가속 성능 테스트(UT2003)

 화려한 그래픽과 높은 정밀도의 물리역학 엔진으로 유명한 UT2003 버전으로 다이렉트X 8 환경에서의 3D 가속성능을 체크해 보았다. 테스트는 크게 두가지 방식으로 진행했는데 단순한 맵 자체의 랜더링 능력을 테스트하는 플라이바이 테스트와 보츠가 포함된 전투 화면을 렌더링함으로써 실제 사용자가 체감할 수 있는 프레임과 유사한 결과값을 제시해 주는 보트매치가 그것이다.

 먼저 플라이바이 테스트의 경우에는 800×600 해상도에서는 애슬론64 FX-51 시스템이 약간 앞선 성능을 보였지만 그 이상의 해상도에선 펜티엄4 솔루션이 조금씩 앞선 성능을 나타냈다. 플라이바이 테스트의 경우 앞서 이야기한 바 있듯이 단순한 맵 자체의 렌더링 성능만을 측정하는 것이기 때문에 사용자가 실제 게임을 하면서 체감할 수 있는 프레임과는 상당한 거리가 있는 것이 사실이다.

 보트매치 테스트는 다수의 보츠 케릭터가 화면에 나타나고 이들 캐릭터들이 움직일 때 화면에 표시되는 물리적인 움직임과 무기를 사용할 때 나타나는 광원효과 처리 등의 연산이 내부적으로 이뤄지기 때문에 실제 게임을 할때와 유사한 결과값을 도출해 낼 수 있다.

 결국 중점적으로 참고해야 할 결과값은 보트매치 테스트 결과라 할 것인데 이 부분에선 애슬론64 FX-51 시스템이 전반적으로 펜티엄4 시스템을 앞선 성능을 나타냈다. 인상적인 것은 애슬론64 3200+ 시스템 테스트 결과로써 800×600·1024×768 해상도 등에서 펜티엄4 EE의 성능을 능가하고 있다. 현재 출시된 32비트 응용 프로그램들은 상당수가 인텔 펜티엄4 CPU 에 최적화돼 있지만 애플리케이션 내부에서 이뤄지는 연산의 특성에 따라 애슬론64 FX-51 솔루션이 앞선 성능을 보이는 분야도 있음을 증명하는 결과라 할 것이다.



 5. 3D 가속성능 테스트(3D마크03)

 다이렉트X 9 지원 벤치마크 툴로 유명한 3D마크03 버전으로 3D 가속성능 테스트를 수행해 보았다. 결과는 우열을 가리기가 힘들게 나타났다. 800×600·1280×1024 해상도에서는 전반적으로 펜티엄4 솔루션이 앞선 성능을 보였지만 1024×768 해상도에서는 상당히 큰 폭으로 애슬론64 FX-51 솔루션이 앞선 성능을 나타냈다.

 다소 혼동되는 결과라 말할 수 있겠지만 3D마크03 항목중 하나인 CPU 테스트 항목의 결과값을 살펴보면 승자는 자연스럽게 밝혀진다. 3D마크03 CPU 테스트의 경우 그래픽카드의 3D 가속성능은 배제한 채 CPU 자체의 능력만으로 3D 그래픽 화면을 랜더링하는 테스트를 수행하는데 이 테스트에서는 애슬론64 FX-51 CPU가 펜티엄4 CPU보다도 앞선 성능을 보이는 프로세서라고 프로그램 자체적으로 판단하고 있는 것이다.

 CPU 자체의 연산능력은 높은데 왜 최종적인 3D 가속성능에서는 다른 결과가 나타나는 것일까. 여러가지 설명이 가능하겠지만 가장 확실한 이유는 역시 드라이버의 최적화 수준이 다르기 때문일 것이다. 펜티엄4 CPU 의 경우 출시된지 꽤 오랜시간이 지났기 때문에 디토네이터XP v45.23 드라이버와의 궁합이 최상이지만 애슬론64 FX-51 프로세서는 공개된지 얼마되지 않았고 디토네이터 XP v45.23 드라이버는 AMD64 솔루션이 출시되기 이전에 공개된 버전이기 때문에 새로운 프로세서에 대한 본격적인 드라이버 최적화 작업은 아직 시작되지 않은 단계라고 말할 수 있다.

 특히 엔비디아의 경우 그래픽 코어 개발과 함께 애슬론64 FX 솔루션을 위한 엔포스3 칩세트를 제조·공급하는 업체라는 점을 잊어서는 곤란하다. 현재 엔비디아는 인텔 컨트롤러 칩세트 시장에는 진출하지 않았기 때문에 엔포스3 칩세트 판매량 증진을 위해 통합 칩세트 드라이버와 디토네이터XP 그래픽 드라이버를 애슬론64 FX 시스템에서 최상의 성능을 발휘할 수 있도록 튜닝할 명분이 충분하게 존재한다. 이는 향후 인텔 펜티엄4 솔루션을 견제할 수 있는 잠재적인 무기로 성장할 가능성이 있다. 현재 단계에서는 펜티엄4 솔루션의 입지가 강하다고 말할 수 있겠지만 차후에는 충분히 변동될 수 있다는 것을 의미하는 것이다.



 6. 3D 가속성능 테스트(퀘이크3)

 오픈GL 가속 성능은 어떠한지 살펴보자. 출시된 지 꽤 오래 지났지만 공신력 있는 벤치마크 결과를 산출하기로 유명한 퀘이크3 게임으로 프레임 테스트를 수행했다. 어느정도는 예측 가능한 결과였지만 펜티엄4 솔루션이 전반적으로 앞선 성능을 나타냈다.

 그렇다면 맵 자체의 품질을 올렸을 때는 어떤 결과가 나타날까. 고품질의 반사효과로 유명한 nv15.pk3 맵을 사용해 프레임을 측정해 보았는데 역시 전반적으로 펜티엄4 솔루션들이 앞선 성능을 보였다. 애슬론64 FX-51 프로세서의 발표로 AMD는 물론 일부 하이엔드 사용자들 역시 새로운 플랫폼에 대한 기대로 시끌벅적한 것은 사실이지만 기존 32비트 애플리케이션 환경에서의 펜티엄4 솔루션의 성능은 이제 완숙한 경지에 도달해 있음을 보여주는 결과라 할 것이다.



 7. 뷰포트 가속능력 테스트(스펙뷰perf 7.1)

 뷰포트 가속능력 테스트 프로그램으로 전문성을 인정받고 있는 스펙뷰(SPECview)pref 7.1 버전으로 오픈GL 가속성능을 테스트 해보았다. 한가지 항목에선 애슬론64 FX-51 시스템이 빠른 성능을 제공하고 있지만 여타 항목에선 전반적으로 펜티엄4 솔루션보다 낮은 성능을 보이고 있어 드라이버 및 애플리케이션의 최적화가 충분히 진행된 펜티엄4 솔루션의 안정된 성능은 무시할 수 없는 장점임을 다시 한번 확인시켜 주었다.

'QC > 성능평가' 카테고리의 다른 글

성능 테스트  (0) 2005.11.07
TTA 성능 평가  (0) 2005.11.07
자바 애플리케이션 성능 튜닝 툴 자료  (0) 2005.11.02
S/W 성능 테스팅 - 이론  (0) 2005.11.02
SW 성능 테스팅 사례 I  (0) 2005.11.02
" A 프로젝트" BMT 테스트 후기  (0) 2005.11.02
벤치마크 관련 사이트  (0) 2005.11.01
내게 맞는 업스캔컨버터 6종 비교분석  (0) 2005.11.01
컴퓨터 성능 평가  (0) 2005.11.01
Windows XP의 성능  (0) 2005.10.31

성능 테스트





Visual Studio .NET으로 분산 응용 프로그램 디자인  


성능 테스트




특정 성능 요구 사항을 파악한 후에는 응용 프로그램이 이러한 요구 사항을 만족하는지 확인하는 테스트를 시작할 수 있습니다. 성능 테스트는 응용 프로그램이 안정적으로 작동하고 있으며 견고하다는 사실을 전제로 합니다. 이에 따라, 테스트 중에는 가능한 한 변수를 없애는 것이 중요합니다. 예를 들어, 코드의 버그는 성능 문제가 나타나도록 할 수도 있고 감출 수도 있습니다. 서로 다른 성능 테스트에 대한 결과를 비교하기 위해서는 응용 프로그램이 제대로 작동해야 합니다. 특히, 조정 과정을 거치면서 구성 요소의 구현이 수정된 경우에는 해당 응용 프로그램의 성능을 반드시 다시 테스트해야 합니다. 응용 프로그램에 대한 성능 테스트를 수행하기 전에 해당 응용 프로그램의 기능 테스트가 선행되어야 합니다. 응용 프로그램 자체의 변경 사항 외에도 하드웨어, 네트워크 소통량, 소프트웨어 구성, 시스템 서비스 등에서 예상치 못한 변수가 발생할 수 있습니다. 응용 프로그램에 대한 변수를 제어하는 일은 매우 중요합니다.


성능 측정


성능 테스트 정의


기준 성능 결정


스트레스 테스트


성능 문제 해결


성능 측정


성능을 정확하게 조정하려면 각 테스트 결과에 대해 정확하면서도 완전한 기록을 유지해야 합니다. 기록해야 하는 사항은 다음과 같습니다.


  • 정확한 시스템 구성, 특히 이전 테스트 환경에서 변경된 사항
  • 원시 데이터 및 성능 모니터링 도구에서 측정된 결과

이러한 기록 사항은 응용 프로그램이 성능 목표를 만족하는지를 나타낼 뿐만 아니라, 향후 발생할 수 있는 성능 문제를 파악하는 데 도움이 됩니다.


각 테스트 과정 중에 정확히 동일한 성능 테스트 항목을 실행해야 합니다. 그렇지 않을 경우, 서로 다른 결과가 나타난 이유가 테스트 환경의 변경으로 인한 것인지, 응용 프로그램의 변경으로 인한 것인지를 파악할 수가 없습니다. 성능 테스트의 설정을 가능한 한 자동화할 경우 운영자의 차이로 인한 변수를 제거하는 데 도움이 됩니다.


테스트가 시작될 때까지 응용 프로그램이 실행된 시간과 같이 사소한 요소도 성능 테스트의 결과에 영향을 줄 수 있습니다. 차가운 자동차 엔진이 뜨거운 엔진과 다른 성능을 나타내는 것과 같이, 장기 실행 응용 프로그램은 메모리 단편화 등으로 인해 새롭게 실행된 응용 프로그램과는 다른 성능 결과를 보여줄 수 있습니다.


성능 테스트 정의


성능 테스트 중에 성능 목표에 지정된 측정 항목에 대한 값을 측정하고 기록하십시오. 일고 시간, 트랜잭션 혼합 등과 같은 모든 성능 측정 항목을 만족해야 합니다. 이러한 제약 조건 내에서 테스트는 가능한 한 현실적인 상황을 반영해야 합니다. 예를 들어, 많은 클라이언트가 동시에 액세스를 시도할 때 응용 프로그램이 어떤 성능을 나타내는지 테스트합니다. 다중 스레드 테스트 응용 프로그램은 재현할 수 있는 방식으로 여러 클라이언트를 시뮬레이션할 수 있습니다. 여기에서 각 스레드는 하나의 클라이언트를 나타냅니다. 응용 프로그램이 데이터베이스에 액세스할 경우, 데이터베이스는 현실성 있는 개수의 레코드를 포함하고 있어야 하고 테스트는 데이터 입력에 대해 임의의(하지만 유효한) 값을 사용해야 합니다. 테스트 데이터베이스가 너무 작을 경우 데이터베이스 서버의 캐싱 효과에 대한 테스트 결과는 현실성이 없게 됩니다. 데이터가 비현실적인 방식으로 입력 또는 액세스될 경우에도 결과는 현실성이 없을 것입니다. 예를 들어, 새로운 데이터가 기본 키에 대해 알파벳 순서대로 생성될 가능성은 없습니다.


일반적으로, 테스트 환경에서는 트랜잭션 혼합, 일고 시간, 클라이언트 수 등과 같이 사용자별로 다를 수 있는 입력 매개 변수를 고려해야 합니다. 하지만, 테스트 환경 자체에서는 현실적인 데이터를 만드는 규칙을 지정할 수 있습니다.


응용 프로그램을 실행하기 위한 테스트 환경을 만든 후, 테스트 실행 시 동일하게 적용해야 할 모든 조건을 문서로 작성해 두어야 합니다. 이러한 조건은 최소한이라도 테스트 환경 실행에 필요한 입력 매개 변수를 포함해야 합니다. 또한, 테스트 실행에 대한 데이터베이스 설정 방법도 문서로 작성해야 합니다. 데이터베이스가 이전 테스트로 인해 변경된 사항을 포함하지 않도록 지침을 지정해야 합니다. 테스트에 사용된 컴퓨터 구성도 지정합니다. 이 설정은 프로덕션 환경과 더욱 가까우므로 응용 프로그램과 다른 별도의 컴퓨터에서 테스트 환경을 실행하십시오.


기준 성능 결정


성능 목표를 정의하고 성능 테스트를 개발한 후에는 테스트를 한 번 실행하여 기준을 설정합니다. 테스트 환경이 실제 프로덕션 환경과 가까울수록 배포 후 응용 프로그램이 안정적으로 작동할 확률이 높아집니다. 따라서, 처음부터 현실적인 테스트 환경을 만드는 것이 중요합니다.


운이 좋으면 기준 성능이 성능 목표를 만족할 수도 있으며 이 경우 응용 프로그램을 조정하지 않아도 됩니다. 이에 반해, 대부분의 경우 기준 성능은 만족스럽지 못합니다. 하지만, 초기 테스트 환경 및 기준 결과를 문서화할 경우 이에 따라 조정 작업을 쉽게 수행할 수 있습니다.


스트레스 테스트


특별한 형태의 성능 테스트인 스트레스 테스트는 다른 엔지니어링 분야의 파괴 테스트와 유사합니다. 스트레스 테스트의 목표는 응용 프로그램의 성능 저하를 넘어 리소스의 포화 사용 또는 오류 발생으로 인해 응용 프로그램을 더 이상 사용할 수 없을 때까지 프로세스 로드를 늘리는 것입니다. 스트레스 테스트는 응용 프로그램이 배포될 때까지는 쉽게 발견할 수 없는 사소한 버그들을 찾아내는 데 도움이 됩니다. 이러한 버그는 대개 잘못된 디자인으로 인해 생긴 것이므로 스트레스 테스트는 각 응용 프로그램 영역의 초기 개발 단계에서 시작해야 합니다. 이러한 미묘한 버그를 수정할 때에는 이러한 버그를 무시했을 때 응용 프로그램의 다른 곳에서 발생할 수 있는 관련 버그를 수정하는 것보다는 소스 자체를 수정하는 것이 좋습니다.


성능 문제 해결


성능 문제의 원인에는 하나 이상의 요인이 있을 수 있습니다. 따라서, 좋지 않은 성능에 대한 해결책을 찾는 것은 과학 실험을 하는 것과 매우 유사합니다. 과학 실험에서는 일반적으로 관찰, 가설, 예측, 테스트, 제어 및 이론으로 이루어지는 6단계의 과정을 따릅니다. 이론은 실험 과정에 의해 축적된 최적의 증명 정보로 뒷받침되는 가설로 구성됩니다. 이와 동일한 프로세스를 수행하여 성능 문제를 해결할 수 있습니다.


ASP 응용 프로그램에서 기대 이하의 성능이 나타난 경우 ASPProcessorThreadMax 메타베이스 속성이 너무 낮게 설정되었다고 가정합니다. 이것은 ASP Requests Queued 성능 카운터가 위, 아래로 이동하고 프로세서가 50% 이하에서 실행되고 있는 경우일 수 있습니다. 따라서, ASPProcessorThreadMax 메타베이스 속성의 값을 늘리면 성능이 향상될 것으로 예측할 수 있습니다.


이제 활성 스레드 설정을 제어할 수 있게 되었습니다. 눈에 띄는 성능 변화가 있을 때까지 한 번에 하나의 설정만 변경합니다. ASPProcessorThreadMax 메타베이스 속성을 조정한 후 기대 이상의 만족할 만한 성능이 나타난 경우, 현재의 모든 변수(예: 필요한 총 메모리 양, 실행되고 있는 응용 프로그램 수, 업그레이드된 소프트웨어) 하에서는 특정 속성 설정이 최상의 서버 성능을 제공한다는 이론을 세울 수 있습니다. 그렇다면, 변수의 변경이 이후의 실험 대상이 됩니다.


참고 항목


성능 | 응용 프로그램, 서버 및 보안 이벤트 기록 | 성능 임계값 모니터링 | 빌드, 디버그 및 테스트 | Performance and Scalability Testing | Understanding Performance Testing

TTA 성능 평가

TTA 성능 평가 자료