'분류 전체보기'에 해당되는 글 1478

  1. 2005.11.11 넌 좀 맞아야해~ 1
  2. 2005.11.11 단체 사진 1
  3. 2005.11.11 잔디가 좋아~ 1
  4. 2005.11.11 환경 사랑 1
  5. 2005.11.07 [리뷰 & 벤치마킹]CPU 4종-성능테스트
  6. 2005.11.07 성능 테스트
  7. 2005.11.07 TTA 성능 평가
  8. 2005.11.02 pc게임 품질평가 사례연구
  9. 2005.11.02 자바 애플리케이션 성능 튜닝 툴 자료
  10. 2005.11.02 S/W 성능 테스팅 - 이론
  11. 2005.11.02 SW 성능 테스팅 사례 I
  12. 2005.11.02 SW시험 용어집
  13. 2005.11.02 " A 프로젝트" BMT 테스트 후기
  14. 2005.11.02 테스트하는 마음 가짐
  15. 2005.11.02 테스트케이스의 설정기법
  16. 2005.11.02 Six Sigma 강의 자료
  17. 2005.11.02 소프트웨어 신뢰성 자료 #2
  18. 2005.11.02 소프트웨어 신뢰성 자료 #1
  19. 2005.11.02 소프트웨어 신뢰성 발표논문
  20. 2005.11.02 신뢰성 관련 사이트

넌 좀 맞아야해~



넌 좀 맞아야해~



촬영장 중에 죄수들을 가두는 감옥과

고문하고, 형벌을 가하던 기구들도 있습니다.



수진이가 응가를 해버려 엄마랑 수진이 보는 순간

이런 재밌는 연출을 하고 있었습니다.



몽둥이로 때리려하니 기겁을 하는군요

'사진으로 보는 일상 > 가족/친척' 카테고리의 다른 글

설날  (0) 2005.03.10
오래간만에 나간 외식  (1) 2004.12.17
무엇일까?  (0) 2004.06.19
토끼풀을 한웅큼 쥐고서  (0) 2004.06.19
풀밭 사이로  (0) 2004.06.19
호기심 - 올챙이가 어디 있지  (0) 2004.06.18
하늘 높이 하늘 높이 하늘 끝까지  (0) 2004.06.18
튼튼이 얼굴을 공개하다.  (1) 2004.02.18
즐거운 설날  (0) 2004.01.22
늦가을에 간 창경궁  (0) 2003.12.02

단체 사진



가끔씩 처가 식구들과 모여서 놀러 가지만

단체 사진 찍는 것 그리 많지 않습니다.

이만한 사람이 모여 찍는 건 결혼 사진 이후로 처음이지 않을까 싶습니다.



아이들 사진 찍는 것도 어려운데 단체 사진을 찍으니 더 힘듭니다.

한 놈이 웃으면 한 한 놈은 울거나 딴청 피우고

게다가 어떤 놈은 딴데 쳐다보고.



뒤에서 기다리는 사람들도 있어서 시간도 끌 수 없다보니

요렇게 아이들이 제각각인 사진이 나왔네요.



누구 아이들 찍는 좋은 묘수는 없는지





=-=-=-=-=-=-=-=-=-=



한 남자의 사랑 이야기



백년을 기약하면서 달콤한 연애를 하던 때
두 연인의 꿈은 너무나 희망에 부풀어있었습니다.

남자는 결혼을 위해 아파트를 준비하였고
여자는 새 아파트에 맞는 세간도 알아놓았습니다.

그렇게 희망이 부풀어 결혼준비를 하던 때
여자 아버지가 사업에 실패를 하여
회사의 문을 닫았습니다.

그 충격으로 여자의 아버지는 병원에 입원하게 되었습니다.
결혼을 한 달 앞둔 어느 날 남자는 여자의 손을 잡고
아픈 고백을 하는 것이었습니다.

자기가 보여 주었던 새 아파트는 사실은
자기의 것이 아니라는 것이었습니다.

여자도 사실 새 아파트에 가져갈 혼수품을
살 수 없는 형편이었기에
그 말에 그렇게 실망하지 않았습니다.

그들은 어렵게 단칸방에서 신혼산림을 차렸습니다.
그런데 남자의 월급이 결혼 전에 이야기하던
것과는 너무 작았습니다.

그래도 여자는 신혼의 맛에 기쁘게 살았습니다.
여자의 아버지도 건강을 얻고 다시 사업을 시작하였습니다.
사업도 잘 되었습니다.

그런데 사람의 마음은 참 이상하지요!
친정 집이 어려울 때는 그저 있는 것에 감사하였는데
친정 집의 형편이 좋아지면서 자기의 모습이
왜 그리 초라해 지는지요!

결혼 전 아파트를 보여주고 그래도 경제적으로
어렵지 않게 해준다던 남자의 말이
모두 상처로 되살아났습니다.

그렇게 사랑스럽던 신랑이 그렇게 미워집니다.
결국 여자는 그 속상한 마음,
억울한 마음을 친정어머니께 말씀드렸습니다.

아픔을 이야기하는 여자의 볼에서 아픈 눈물이 흘러내리고,
이야기를 듣는 여자의 어머니의 눈에서도
눈물이 흘러내렸습니다.

이야기를 듣고 난 어머니, 딸에게 숨겨놓았던
비밀을 이야기해주었습니다.

사실은 김 서방이 아무 말하지 말라고 했는데
이제는 털어놓아야 겠구나.
"
여자의 어머니가 해준 말은 이런 내용이었습니다.

남자는 혼수용품을 해올 형편이
못되는 여자의 마음이 상할까보아
아파트를 팔아 여자의 아버지의 빚을 갚는데 보태었습니다.

그리고 남자의 매달 월급의 적지 않은 돈도
여자의 아버지의 병원 비로 썼던 것이었습니다.
이야기를 듣는 딸의 눈에서 눈물이 얼굴을 적십니다.

그 눈물은 조금전 어머니가 흘렸던 감동의 눈물이었습니다.
실망의 눈물이 감동의 눈물로 이렇게 쉽게도 바뀔 수가 있네요
.
오늘도 내 사랑하는 사람들에게
감동의 눈물을 흘리게 할 수는 없을까요!

신발을 돌려 놓아주는 작은 배려에서부터 말입니다.






좋은글 아침편지 중에서

'사진으로 보는 일상 > 여행' 카테고리의 다른 글

아빠도 함께  (1) 2005.11.11
바다 속으로 풍덩  (1) 2005.11.11
준비 운동  (1) 2005.11.11
절영 산책로  (1) 2005.11.11
진짜 같아요.  (1) 2005.11.11
서울 숲  (2) 2005.08.23
모래 가지고 놀아요.  (2) 2005.08.22
광안리  (1) 2005.08.21
물놀이  (1) 2005.08.21
용두산 공원  (1) 2005.08.21

잔디가 좋아~



입구에 대장금 출연진들의 손바닥이 보이네요.

이런 곳이 있다는 걸 가는날 처음 알았는데 도착해 보니

어떻게 알고 찾아 왔는지 많이들 오더군요.



특히 놀란게 우리 나라 사람뿐만 아니라 다른 나라 사람들이 많이 보인다는 점입니다.

우리나라 사람보다 외국인이 더 많아 보이더군요.

말을 들어보니 중국이나 대만, 일본 사람으로 보이는데

한꺼번에 우르르 몰려 다니는게 단체로 온 듯 합니다.

'사진으로 보는 일상 > 한솔이와수진이' 카테고리의 다른 글

한솔이의 표정  (1) 2005.11.11
놀이터에서  (1) 2005.11.11
수진이의 멋내기  (1) 2005.11.11
겁 많은 수진이  (1) 2005.11.11
어리광쟁이  (1) 2005.11.11
환경 사랑  (1) 2005.11.11
대장금 테마파크  (1) 2005.09.11
환경 사랑  (0) 2005.09.11
수락산 물놀이  (1) 2005.09.10
한솔이가 다쳐 응급실에 다녀오다.  (3) 2005.08.23

환경 사랑



한솔이가 어린이집에 다니면서 숙제를 가지고 오기 시작했다.

숙제라는 것이 아이 혼자 할 수 있는게 아니라

엄마랑, 아빠랑 함께 해야하는 것들이기 때문에

숙제가 나오면 덩달아 엄마, 아빠도 바빠진다.



요새 주제는 환경 보호다.

어떻게 하면 환경을 보호하는 것인지 알아보고 실천하는 것



새우깡을 사주었는데 먹고 나서 버려버린다.

평소엔 휴지통에 잘 버리더니 오늘은 왠일인지 그냥 바닥에 버린다.

휴지통에 버리라고 한 후

휴지통으로 뛰어가는 한솔이를 보고 생각난게 있어  연출 샷.

휴지 줍는 걸 다시 찍으니 약간은 쑥스러운가 보다.

'사진으로 보는 일상 > 한솔이와수진이' 카테고리의 다른 글

놀이터에서  (1) 2005.11.11
수진이의 멋내기  (1) 2005.11.11
겁 많은 수진이  (1) 2005.11.11
어리광쟁이  (1) 2005.11.11
잔디가 좋아~  (1) 2005.11.11
대장금 테마파크  (1) 2005.09.11
환경 사랑  (0) 2005.09.11
수락산 물놀이  (1) 2005.09.10
한솔이가 다쳐 응급실에 다녀오다.  (3) 2005.08.23
울리기 대장 한솔이  (1) 2005.08.23

[리뷰 & 벤치마킹]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 성능 평가 자료

pc게임 품질평가 사례연구

한국정보과학회 소프트웨어공학연구회 주최로 진행된,
5회 KCSE(한국 소프트웨어공학 학술대회)에 발표했던 논문입니다.
아직은 여러 면에서 부족한 내용이 많이 있지만,
권원일 클럽짱님의 강압에 의해 게재합니다.
관심있는 분들의 많은 조언바랍니다.

첨부파일이 2M가 넘어서 압축하여 올립니다.

'QC > 품질관리' 카테고리의 다른 글

GUI Test Checklist  (0) 2005.11.17
테스트 케이스가 잘 작성되었는지 검토하는데 사용하는 체크리스트  (1) 2005.11.17
üũ  (0) 2005.11.17
품질 관리 (Quality Management)  (0) 2005.11.17
품질관리(QC) 7가지 도구  (0) 2005.11.17
SW시험 용어집  (0) 2005.11.02
테스트하는 마음 가짐  (0) 2005.11.02
테스트케이스의 설정기법  (0) 2005.11.02
Six Sigma 강의 자료  (0) 2005.11.02
소프트웨어 신뢰성 자료 #2  (0) 2005.11.02

자바 애플리케이션 성능 튜닝 툴 자료

볼랜드에서 받은 메일에 있는 자료입니다.
게시판 성격에 맞는지도 모르겠고,....
볼랜드 코리아와 저는 아무 관계도 없답니다... ^^
----------------------------------------------------------------
볼랜드의 자바 성능 튜닝 툴인 OST 설명 자료
  ※ OST의 주요 기능
        -. 자바 어플리케이션의 통합 테스트시 문제점 발견
        -. 각 단계별 (JSP, EJB, JDBC, etc)성능 측정
        -. 문제 발생시 문제 발생 코드 영역 표시
        -. 리포팅
        -. etc....

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

[리뷰 & 벤치마킹]CPU 4종-성능테스트  (0) 2005.11.07
성능 테스트  (0) 2005.11.07
TTA 성능 평가  (0) 2005.11.07
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

S/W 성능 테스팅 - 이론

이론 자료

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

[리뷰 & 벤치마킹]CPU 4종-성능테스트  (0) 2005.11.07
성능 테스트  (0) 2005.11.07
TTA 성능 평가  (0) 2005.11.07
자바 애플리케이션 성능 튜닝 툴 자료  (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

SW 성능 테스팅 사례 I

[컨퍼런스 발표자료] SW 성능 테스팅 사례 1

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

[리뷰 & 벤치마킹]CPU 4종-성능테스트  (0) 2005.11.07
성능 테스트  (0) 2005.11.07
TTA 성능 평가  (0) 2005.11.07
자바 애플리케이션 성능 튜닝 툴 자료  (0) 2005.11.02
S/W 성능 테스팅 - 이론  (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

SW시험 용어집

힘들여 모르는 것 마다 하나씩 용어를 올릴 필요가 없었나 봅니다.
이미 다른 기관에서 용어를 잘 정리해 두었네요...
프린트해서 가지고 계시면 많은 도움이 되지 않을까 생각합니다.


 


- 영문 자료


" A 프로젝트" BMT 테스트 후기

이 글은 sten.cyworld.com 에서 옮겨졌습니다.
작성자 :  최민식 
작성일 : 2002.11.15 17:09:00

안녕하세요 최근에 1주일 동안 다녀온 BMT 테스트 후에 얻은 팁이라고 할까요
하여튼 짤막한 기술적인 부분을 다루려고 합니다. 보안상 프로젝트의 이름은 A라고 하겠습니다.

BMT의 대상이 되는 것은 여러가지가 있었지만 특별히 "성능테스트 부분"에 대한 얘기만을 다루겠습니다.

1. TOOL
툴은 loadrunner를 사용하더군요.
300 유저늘 생성해도 실제 메모리는 100M 내외가 쓰입니다.
512M RAM 노트북에서 300 유저를 생성해도 무리가 없는 것으로 보아 많은 메모리를 요구하는 다늘 성능 테스트 제품과 비교 되었습니다.
툴 사용자의 말로는 다른 부하 측정 제품들의 경우 데이터의 70% 정도밖에는 신뢰하지 못하지만 loadrunner는 90 % 정도 신뢰가 되고 일단은 가볍게 노트북으로도 300유저를 생성할 수 있어 좋답니다.(프로그램에 따라 300유저를 생성하지 못할 수도 있습니다.)
라이센스는 부하생성 할 때마다 1유저당 3달러정도를 내야 합니다.(24시간 기준)

2. 명령어(script 와 sar)
일단 예를 들어 설명 하겠습니다.
예) script sample.log
sar -u 5 10000
유닉스의 경우 시스템을 상태를 실시간으로 볼수 있는 여러가지 명령어가 존재 합니다. Target에 방대한 양의 데이터를 동시에 입력하거나 처리할 때 실시간으로 CPU의 상태를 볼 수 있는 명령어가 sar 입니다.
하지만 sar의 명령에 앞서서 script를 이용하면 sar에서 출력된 시스템의 상태를 기록할 수 있습니다.

우선 script sample.log를 하면은 화면에 출력되는 것들을 sample.log에 차곡 차곡 쌓습니다.
그 이후 sar 에 -u 옵션을 주면 CPU의 상태를, 5는 5초 단위로 10000은 10000번을 찍으라고 하면 5초마다 5초에 대한 평균을 내어 sample.log파일에 적게 되겠죠
Ctrl+C를 누르면 sar -u 5 10000을 멈추게 되고
Ctrl+D를 누르면 열려져 있던 sample.log를 닫으면서 script가 종료 됩니다.
마지막으로 sample.log 파일을 엑셀로 읽으면 멋진 통계표로 만들기가 쉽습니다.
유닉스 성능 테스트에 이용하면 편리합니다.

실제 sar를 man 페이지를 이용하여 보면 여러가지 옵션이 있습니다.
관심 있으신 분은 직접 읽어 보시는 것도 좋을 듯 싶네요
위의 내용은 제가 본것과 들은 것을 중심으로 적었기 때문에 증거 자료는 물론 없읍니다. 하지만 틀린 내용에 대한 리플은 환영 합니다.
좋은 하루 되세요

----------------------------
[RE]  정도균

안녕하세요. 바산네트워크(주) 정도균입니다.

TTA시험센터에서는 일반적으로 Loadrunner를 사용하시는 건지 궁금하네요 ?
아직 전 loadrunner를 접하지 못해서.. 또 고가의 제품들이고

저 같은 경우, 이전에 비슷한 성능테스트를 수행한 경험이 있는데요
R사의 제품을 가지고 했었답니다.

그런데 300유저인데 노트북1대로 했었다면, 자세한건 몰라도 월등한거 같네요..
써보고 싶긴 한데.. 아궁. 시간이...
저희같은 경우 1,200명정도를 생성했는데.. . 총 4대가 소요되었습니다.
(제 기억으론 조금 빵빵한 데스크탑 1대로 300명정도는 가능하긴 하더군요)
(데스크탑 3대 : Virtual User Creation , 1대 : Control System)

가상유저가 점점 많아질수록, 원하는 사향이 기하급수적으로 뛰더군요. 콘트롤 시스템도 사양의 매우 중요하구요

그런데 궁금한점이 측정데이터의 신뢰성이 90%정도라고 하셨는데. 어떤식으로. 신뢰성에 대한 판정을 내리시는지요 ? 저희같은 경우는 무식하게도 Client PC의 Response Time을 다 점검했었거든요. 물론, Script의 Pass/fail하고요. loadrunner도 그런식으로 되는건가요 ?

나오는 데이터의 수준도 궁금하구요. Rational 같은 경우는 거의 효율성에 대한 메트릭 값만 달랑 나와서 보기 힘들더군요, 거의 대부분의 Raw Data이고 그걸 통계화시키는 방법도 없는거 같구요 제가 잘몰라서 그러는지 몰라도......

------------------------------------------------
[RE] 최민식

이번 테스트는 직접 하지 못하고 테스트하는 것을 감독하는 수준이어서
원하시는 답을 드리기는 어렵고
제가 본것은 fail/pass 부분인데 원인을 알 수 없는 fail이 가끔 발생하는데
loadrunner일 경우 그 빈도가 적다는 사실을 적어 놓은 것이고요
제가 알기로 유닉스에서 별도의 클라이언트를 설치하지 않고 RPC를 이용하여
알 수 있는 수준이 정해져 있는 것으로 알고 있습니다. 정확히 그 RPC의 이름은 모르는 사항입니다.
아마도 데이터의 깊이는 타사와 비슷하지 않을 까요?
제대로 된 대답이 아니라 죄송 합니다.

'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
벤치마크 관련 사이트  (0) 2005.11.01
내게 맞는 업스캔컨버터 6종 비교분석  (0) 2005.11.01
컴퓨터 성능 평가  (0) 2005.11.01
Windows XP의 성능  (0) 2005.10.31
7,200RPM 80GB HDD 4種 完全分析  (0) 2005.10.28

테스트하는 마음 가짐

테스트하는 마음가짐(2005.6.27일 게재)에서는 주제가 "테스트의 원칙"이었는바, 여기서는
그 후속으로 "디버그의 원칙(오류위치의 발견, 오류의 수정)" 과 "오류의 분석"에 대해 게재
합니다. 자료출처와 게재의도는 앞서의 것과 같습니다.
테스트의 미경험자는 상상하기 어렵겠지만, 경험자인 경우는 적어도 한번쯤은 공감하는 부분이
기억되리라 생각합니다. 또, 오류분석에 대해서는 어느정도 대처하고 있을까요? 7월 22일


'QC > 품질관리' 카테고리의 다른 글

üũ  (0) 2005.11.17
품질 관리 (Quality Management)  (0) 2005.11.17
품질관리(QC) 7가지 도구  (0) 2005.11.17
pc게임 품질평가 사례연구  (0) 2005.11.02
SW시험 용어집  (0) 2005.11.02
테스트케이스의 설정기법  (0) 2005.11.02
Six Sigma 강의 자료  (0) 2005.11.02
소프트웨어 신뢰성 자료 #2  (0) 2005.11.02
소프트웨어 신뢰성 자료 #1  (0) 2005.11.02
소프트웨어 신뢰성 발표논문  (0) 2005.11.02

테스트케이스의 설정기법

프로그래머 초심자용 교재입니다.
오래전의 것이라 망설렸는데 Certified Tester F-Level Syllabus 4.에
몇가지가 있어, 이해에 참조가 될 것 같습니다.
기업에서는 이런 교육을 대학의 관련전공학과에서의 이수를
바라고 있습니다.

죄송합니다.
"test-tec-tr.hwp" 파일내용중 원전 저자명의 착오를 정정합니다.
G.M.Myers->G.J.Myers 6월 13일

'QC > 품질관리' 카테고리의 다른 글

품질 관리 (Quality Management)  (0) 2005.11.17
품질관리(QC) 7가지 도구  (0) 2005.11.17
pc게임 품질평가 사례연구  (0) 2005.11.02
SW시험 용어집  (0) 2005.11.02
테스트하는 마음 가짐  (0) 2005.11.02
Six Sigma 강의 자료  (0) 2005.11.02
소프트웨어 신뢰성 자료 #2  (0) 2005.11.02
소프트웨어 신뢰성 자료 #1  (0) 2005.11.02
소프트웨어 신뢰성 발표논문  (0) 2005.11.02
신뢰성 관련 사이트  (0) 2005.11.02

Six Sigma 강의 자료

소프트웨어 신뢰성 자료 #2

소프트웨어 신뢰성 자료 #2


 


SW Models.zip (65 kb) 은 실습 자료


 


그냥 Mathematica 화일을 올리겠습니다.

이 것을 보시거나 실행하려면

www.wolfram.com에 가셔서 "MathReader"라는

프로그램을 다운 받으시면 됩니다.

혹 주위에서 프로그램을 구할 수 있으면

직접 실행할 수도 있구요.



'QC > 품질관리' 카테고리의 다른 글

pc게임 품질평가 사례연구  (0) 2005.11.02
SW시험 용어집  (0) 2005.11.02
테스트하는 마음 가짐  (0) 2005.11.02
테스트케이스의 설정기법  (0) 2005.11.02
Six Sigma 강의 자료  (0) 2005.11.02
소프트웨어 신뢰성 자료 #1  (0) 2005.11.02
소프트웨어 신뢰성 발표논문  (0) 2005.11.02
신뢰성 관련 사이트  (0) 2005.11.02
품질도구 - 시스템 및 소프트웨어편  (0) 2005.11.02
리눅스 신뢰성 테스트  (0) 2005.11.02

소프트웨어 신뢰성 자료 #1

신뢰성 관련 자료 1



소프트웨어 신뢰성 발표논문

2003년 8월 26일 서울대학교 신공학관에서 열린
<군사과학기술학회 종합학술대회>에 발표한 논문입니다.

참고하시기 바랍니다.


장주수

신뢰성 관련 사이트





















































































































































국내 관련 사이트
<대학교>
아주대학교 품질 및 신뢰성 설계 실험실
서울대학교 신뢰성공학 연구실
창원대학교 품질 및 신뢰성공학 센터
신뢰성분석연구센터
   
  < 연구소 및 기관 >
  산업기술시험원 신뢰성팀
  전자부품연구원
  한국전자통신연구소
   대우중공업(주) 중앙연구소 신뢰성평가센터
   
  < 기 업 >
  모아소프트
  한국능률협회 신뢰성기술 컨설팅
  RAM 기술연구회
  한국신뢰성 기술서비스
   윈텍(WIN-TEK)
   
국외 관련 사이트
  < 대 학 교 >
    Centre for Software Reliability at City University
    FAA Center for Aviation Systems Reliability
    Quality Reliability Engineering Center Prospectus
    Reliability Information Center
    SRE Information Center
 
< 정부기관 및 연구소 >
     American National Standards Institute(ANSI)
     International Electrotechnical Commission(IEC)
     International Organization for Standardization(ISO)
     NASA Standard EEE Parts List (MIL-STD-975)
     NASA Reliability Preferred Practices for Design and Test
     NASA Reliability Program Practices, Overview
     Reliability Analysis Center(RAC)
     Safety, Reliability & Quality Resources
     Sandia National Lab. - Center for System Reliabilit y
     Welcome To Goverment-lndustry Data Exchange Program(GIDEP)
 
< 기 업 >
      BQR Reliability Engineering Ltd
      Center for Software Engineering
      ISOGRAPH
      Office of Systems Safety and Mission Assurance
      Reliability Magazine

< 학 회 >
       American Society for Quality(ASQ)
       American Society for Testing and Materiala(ASTM)
       International Reliability Physics Symposium(IRPS)
       Reliability Related Professional Societies
       Society of Maintenance & Reliability Professionals
       Society of Reliability Engineering
       The Institute of Electrical and Electronics Engineers(IEEE)

 


 


품질관련 연구실(국내)


한국과학기술원 응용통계연구실
- http://ie1.kaist.ac.kr/~stat/baseframe/first_ko.html
- 지도교수: 배도선

한국과학기술원 품질설계연구실
- http://ie1.kaist.ac.kr/~dfqlab/
- 지도교수: 염봉진

포항공대 품질공학연구실
- http://kayak.postech.ac.kr/
- 지도교수: 김광재

포항공대 확률통계분석연구실
- http://ie.postech.ac.kr/pasta/index.htm
- 지도교수: 전치혁

전북대 품질 및 신뢰성 연구실
- http://ise.chonbuk.ac.kr/~sixsigma/
- 지도교수: 홍성훈

부경대 품질시스템연구실
- http://ie1.pknu.ac.kr/qsystem/
- 지도교수: 권혁무