'QC'에 해당되는 글 88

  1. 2005.11.02 pc게임 품질평가 사례연구
  2. 2005.11.02 자바 애플리케이션 성능 튜닝 툴 자료
  3. 2005.11.02 S/W 성능 테스팅 - 이론
  4. 2005.11.02 SW 성능 테스팅 사례 I
  5. 2005.11.02 SW시험 용어집
  6. 2005.11.02 " A 프로젝트" BMT 테스트 후기
  7. 2005.11.02 테스트하는 마음 가짐
  8. 2005.11.02 테스트케이스의 설정기법
  9. 2005.11.02 Six Sigma 강의 자료
  10. 2005.11.02 소프트웨어 신뢰성 자료 #2
  11. 2005.11.02 소프트웨어 신뢰성 자료 #1
  12. 2005.11.02 소프트웨어 신뢰성 발표논문
  13. 2005.11.02 신뢰성 관련 사이트
  14. 2005.11.02 품질도구 - 시스템 및 소프트웨어편
  15. 2005.11.02 리눅스 신뢰성 테스트
  16. 2005.11.02 이용자 인터페이스 설계 원칙과 평가방법
  17. 2005.11.02 S/W 품질 시험 • 인증 제도 및 기술 동향
  18. 2005.11.02 소프트웨어 벤치마크 활성화 방안
  19. 2005.11.01 벤치마크 관련 사이트
  20. 2005.11.01 내게 맞는 업스캔컨버터 6종 비교분석

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/
- 지도교수: 권혁무

품질도구 - 시스템 및 소프트웨어편

품질혁신 활동을 신속하고 효과적으로 지원해 주는 Tool로서 품질 선진기업들이 이용하고 있는 Software들을 한 자리에 모았습니다.


종래 인해전술 방식의 품질개선 활동에서 이제는 똑똑한 Software를 잘 이용하는 것 - 6 Sigma 수준의 품질혁신이 결코 일본이나 구미 선진국만의 독점물이 아닐 것입니다.


DATA의 해석이나 통계적 품질관리를 위해 복잡한 계산식을 일일이 대입하거나 표계산 기능의 엑셀 프로그램과 같은 것으로 서툴게 그래프를 그리는 등의 후진성으로는 결코 그들을 따라 잡을 수 없습니다.


ISO QS-9000 시스템의 효율적인 운영, 품질 혁신 활동의 선진화!...... 그것은 SQC에서 부터 Taguchi method, 실험계획법, 다변량해석 등과 같은 고도의 품질도구 적용과 이를 간단히 처리해 주는 System Software의 활용일 것입니다.


 


자세한 내용은 첨부 문서 참고


리눅스 신뢰성 테스트






리눅스 신뢰성 테스트


Linux Technology Center의 리눅스 장기 신뢰성 평가

developerWorks














문서 옵션













이 페이지를 이메일로 보내기

이 페이지를 이메일로 보내기

JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.



난이도 : 초급


Li Ge, Staff Software Engineer, Linux Technology Center, IBM
Linda Scott, Senior Software Engineer, Linux Technology Center, IBM
Mark VanderWiele, Senior Technical Staff Member, Linux Technology Center, IBM


2003 년 12 월 01 일


리눅스 커널과 다른 핵심 OS 컴포넌트-라이브러리 및 장치 드라이버 부터 파일 시스템과 네트워킹 까지-의 테스트 결과와 분석을 정리했다. 모든 테스트들은 매우 극단적 조건 속에서 긴 시간동안 수행되었다. IBM Linux Technology Center는 세 달 간의 테스트를 끝내고 그 결과를 이 자리에서 나눈다.

IBM Linux Technology Center (LTC)는 1999년 8월에 설립되어 리눅스 개발 커뮤니티와 함께 활동했다. 약 200여명의 직원들이 하나의 오픈 소스 개발자 그룹을 형성하고 있다. 패치 부터 구조적 커널 변경에 이르기까지 코드를 기여하고 있다. 또한 IBM 내의 리눅스 관련 개발을 트래킹하고 있다.


LTC의 주요 관심 분야는, 리눅스 확장성, 신뢰성, 시스템 관리 등으로 이는 리눅스를 엔터프라이즈 급으로 향상시키는데 중요한 요소들이다.


LTC의 또 다른 핵심 미션은 상용 프로젝트가 테스트 되는 방식 대로 연구실에서도 전문적으로 리눅스를 테스트하는 것이다. LTC는 LTP Linux Test Project (LTP)에 기여하고 있다.










테스트 결과 요약



다음은 실행 시간 동안 수행한 테스트 및 관찰 결과에 기반한 요약이다:


  • 리눅스 커널과 기타 핵심 OS 컴포넌트(라이브러리, 장치 드라이버, 파일 시스템, 네트워킹, IPC, 메모리 관리)는 지속적으로 실행되고 치명적인 시스템 오류 없이 실행을 완료했다.
  • 모든 실행은 높은 성공률(95% 이상)을 보였는데 간헐적인 오류도 거의 없었다.
  • 리눅스 시스템 퍼포먼스는 장기 실행 중에도 낮아지지 않았다.
  • 리눅스 커널은 하드웨어 리소스(CPU,메모리, 디스크)를 사용하기 위해 적절히 조정되었다.
  • 리눅스 시스템은 전체 CPU 로드(99% 이상)와 높은 메모리 스트레스를 훌륭히 처리했다.
  • 리눅스 시스템은 오버로드된 환경을 정확히 핸들했다.


리눅스 커널과 기타 핵심 OS 컴포넌트들은 30일, 60일, 90일이 넘어도 신뢰성과 안정성을 유지한다. 또한 강력하고 엔터프라이즈용 으로도 손상이 없는 환경을 제공한다.


목표


리눅스 신뢰성 테스트의 목표는 LTP 테스트 슈트를 사용하여 오랜 기간 동안 리눅스 고객환경과 유사한 워크로드를 주어 리눅스의 안정성과 신뢰성을 측정하는 것이다. (참고자료). 여기에서 오류 규명은 주요 목표는 아니다.


테스트 환경 개요


여기에서는 LTP 테스트 슈트를 사용하여 30일과 60일 동안의 리눅스 신뢰성 측정 테스트에 대한 분석과 테스트 결과를 설명한다. 테스팅 커널로는 SuSE Linux Enterprise Server v8 (SLES 8)을 , 테스팅 하드웨어로는 IBM pSeries 서버가 사용되었다. 특별히 고안된 스트레스 테스트 시나리오에는 광범위한 커널 컴포넌트-네트워킹과 메모리 관리 같은 광범위한 커널 컴포넌트의 실행과 테스팅 시스템에 높은 스트레스의 워크로드를 만드는 것 등이 포함되어 있다. 리눅스 커널, TCP, NFS, I/O 테스트 컴포넌트들은 높은 스트레스 워크로드를 받게된다.

















위로



테스트



30일


30일 LTP 스트레스 실행 결과 (pSeries)


  • 머신: p650 LPAR
  • CPU: (2) Power4- 1.2 GHz
  • 커널: Linux 2.4.19-ull-ppc64-SMP (SLES 8 SP 1)
  • LTP version: 20030514
  • 99.00 percent Average CPU utilization (User: 48.65 percent, System: 50.35 percent)
  • 80.09 percent Average memory utilization (8GB)



  • SLES 8 PPC64 30일 스트레스 실행은 p650 LPAR에서 성공적으로 완료됨.
  • LTPstress는 테스트 툴이었다. 테스트 케이스는 병렬과 시퀀스 방식으로 실행되었다.
  • Kernel, TCP, NFS, I/O 테스트 컴포넌트들은 높은 스트레스 워크로드를 받았다.
  • 성공 비율: 97.88 percent
  • 주요한 시스템 오류 없음.

그림 1. 30일 LTP 스트레스 실행 결과
30-day LTP stress execution results for the pSeries


  • 머신: B80
  • CPU: (2) Power3- 375 MHz
  • 커널: Linux 2.4.19-ull-ppc64-SMP (SLES 8 SP 1)
  • LTP version: 20030514
  • 99.96 percent average CPU utilization (User: 75.02 percent, System: 24.94 percent)
  • 61.69 percent average memory utilization (8GB)
  • 3.86 percent average swap utilization (1GB)

관찰:


  • SLES 8 PPC64 60일 스트레스 실행은 pSeries B80에서 성공적으로 완료됨.
  • 테스트 툴: LTPstress. 테스트 케이스는 병렬과 시퀀스 방식으로 실행되었다.
  • Kernel, TCP, NFS, I/O 테스트 컴포넌트들은 높은 스트레스 워크로드를 받았다.
  • 성공 비율: 95.12 percent
  • 주요한 시스템 오류 없음.


그림 2. 60일 LTP 스트레스 실행 결과
60-day LTP stress execution results for the pSeries

하드웨어 및 소프트웨어 환경



표 1. 하드웨어 환경
























시스템 프로세서 메모리 디스크 스왑 파티션 네트워크
pSeries 650 (LPAR) Model 7038-6M2 2 - POWER4+(TM) 1.2GHz 8GB (8196MB) 36GB U320 IBM Ultrastar (다른 디스크도 있지만 사용되지 않음) 1GB Ethernet controller: AMD PCnet32
pSeries 630 Model 7026-B80 2 - POWER3(TM)+ 375 MHz 8GB (7906MB) 16GB 1GB Ethernet controller: AMD PCnet32

표 2. 소프트웨어 환경















컴포넌트 버전
Linux SuSE SLES 8 with Service Pack 1
Kernel 2.4.19-ul1-ppc64-SMP
LTP 20030514
















위로



방법


시스템 안정성 및 신뢰성은 지속적인 실행 시간과 시스템의 확실한 업로드로 측정된다.


xSeries와 pSeries 서버에서 기본적으로 30일 테스트가 수행되고 60일과 90일로 나아갔다. 초기 주안점은 커널, 네트워킹, I/O 테스팅이다.


테스트 툴
Linux Test Project (LTP; 참고자료)는 SGI, IBM, OSDL, Bull, Wipro Technologies와의 합동 프로젝트이다. 리눅스의 신뢰성, 강도, 안정성을 테스트 하는 오픈 소스 커뮤니티에 테스트 슈트를 제공하는 것이 목표이다. Linux Test Project는 리눅스 커널과 관련 기능들을 테스트 하기 위한 툴 컬렉션이다. 커널 테스팅의 자동화를 실현시켜 리눅스 커널을 향상시키는 것이 목적이다.


현재 LTP 슈트에는 2000개의 테스트 케이스가 있다. 대부분 syscall, 메모리, IPC, I/O,파일시스템, 네트워킹 같은 커널 인터페이스를 다루고 있다. 테스트 슈트는 업데이트 되고 월간 배포되며 다양한 아키텍쳐에서 실행된다.

















위로



테스트 전략


24 시간 "초기 테스트"와 "스트레스 테스트" 단계가 있다


초기 테스트를 통과하는 것은 엔트리 요구사항 같다. 초기 테스트는 하드웨어와 OS에서 LTP 테스트 슈트의 24 시간동안의 성공적인 실행이 이루어져야 한다. 드라이버 스크립트인 runalltests.sh는 커널을 확인하는데 사용된다. 이 스크립트는 순서대로 패키지 테스트를 실행한다. 병렬로 동시에 실행되는 여러 인스턴스들을 시작하는 옵션도 가지고 있다. 이 스크립트는 디폴트 실행이다:


  • 파일시스템 스트레스 테스트
  • 디스크 I/O 테스트
  • 메모리 관리 스트레스 테스트
  • IPC 스트레스 테스트
  • 스케줄러 테스트
  • 명령어 함수 확인 테스트
  • 시스템 호출 함수 확인 테스트


스트레스 테스트는 시스템 사용도가 높을 때 제품의 강도를 확인하는 것이다. runalltests.sh 외에 ltpstress.sh 라고 하는 테스트 시나리오는 광범위한 커널 컴포넌트들을 메모리 관리 및 네트워킹과 병행하여 실행하고 테스팅 시스템에 높은 스트레스 워크로드를 만들도록 특별히 고안되었다. ltpstress.sh는 LTP 테스트 슈트의 일부이다. 이 스크립트는 비슷한 테스트 케이스들을 병렬로 실행하며 다른 테스트 케이스들은 순차로 실행한다. 이 스크립트도 디폴트로 실행된다:


  • NFS 스트레스 테스트
  • 메모리 관리 스트레스 테스트
  • 파일시스템 스트레스 테스트
  • Math (floating point) 테스트
  • pthread 스트레스 테스트
  • 디스크 I/O 테스트
  • IPC (pipeio, semaphore) 테스트
  • 시스템 호출 함수 확인 테스트
  • 네트워킹 스트레스 테스트

















위로



시스템 감시


변경된 top 유틸리티는 시스템 감 시 툴로 사용되었다. top은 실시간으로 프로세서 액티비티를 계속 관찰한다. 향상된 top 유틸리티는 추가 기능이 있는데 top 결과의 스냅샷을 파일에 저장할 수 있고 결과 파일의 평균을 요약 할 수 있다.


우리의 테스트에서 시스템 사용에 대한 스냅샷(또는 top 아웃풋 파일)은 10초 마다 찍히며 결과 파일에 저장된다. 게다가 시스템 사용과 LTP 테스트 아웃풋 파일은 매일 또는 주 마다 찍힌다. 이 기능은 cron 잡과 스크립트에 의해 제어되었다.


테스트 전
선택된 모든 테스팅 시스템은 가능한 한 서로 비슷하게 설정되었다. 여분의 하드웨어는 잠재적인 하드웨어 오류를 줄이기 위해 제거되었다. 최소한의 보안 옵션이 이미지 설치 동안 선택되었다. 최소 2GB의 디스크 공간이 top 데이터 파일과 LTP 로그 파일을 저장하도록 보유되었다.


테스팅 중간
테스트 중에는 시스템은 방해받지 않았다. 테스트가 실행되는지 확인하기 위한 임시 액세스는 허용했다. ps 명령어 사용, top 데이터 체크, LTP 로그 데이터 확인 등이 그것이다.


테스팅 후
테스트가 완료되면 시스템 감시 툴인 top은 갑자기 멈춘다. 모든 top 데이터 파일들은 저장되고 분석을 위한 데이터를 제공하는 프로세스가 시작된다.

















위로



참고자료


















위로



필자소개










Li Ge: Staff Software Engineer in the IBM Linux Technology Center.











Linda Scott: Senior Software Engineer, IBM development lab.











Mark VanderWiele: Senior Technical Staff Member & Architect, IBM Linux Technology Center.

이용자 인터페이스 설계 원칙과 평가방법

첨부 문서 참고

S/W 품질 시험 &#8226; 인증 제도 및 기술 동향

소프트웨어 벤치마크 활성화 방안

소프트웨어 벤치마크 활성화 방안 PDF 파일

벤치마크 관련 사이트

내게 맞는 업스캔컨버터 6종 비교분석

첨부 문서 참고