'QC/품질관리'에 해당되는 글 69

  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.02 pc게임 품질평가 사례연구
  19. 2005.11.02 SW시험 용어집
  20. 2005.11.02 테스트하는 마음 가짐

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

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

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가지 도구

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

SW시험 용어집

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


 


- 영문 자료


테스트하는 마음 가짐

테스트하는 마음가짐(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