'소프트웨어 테스트'에 해당되는 글 2건

  1. 2008.07.09 [펌]소프트웨어 테스터와 프로그래머의 화합(和合)의 법칙
  2. 2008.06.19 [펌]소프트웨어 테스트 개요

[펌]소프트웨어 테스터와 프로그래머의 화합(和合)의 법칙

ITWeb/스크랩 2008. 7. 9. 08:57
소프트웨어 테스터와 프로그래머.. 흠..
지금까지 개발을 해오면서 내가 만든 소프트웨어나 제품에 대해서 문제점을 지적해 주고 오류를 찾아 주는건 고맙다고 생각 한다.
하지만 오류와 문제점에 대한 지적만 할 뿐 그 과정에 대한 설명 없이 들이대는 분들을 종종 많이 보았다.
아래 글을 읽어 보면 알겠지만 모든 일에는 상호 존중과 이해를 기반하지 않고서는 서로 멱살 잡고 싸우기 일수가 아닐까 싶다.. (상호 존중과 이해 역시 담당자들의 실력이 뒷받침 되지 않는 다면 만들어 지지도 않겠지만.. )

배고픔 ㅡㅡ^

ref. http://www.ibm.com/developerworks/kr/library/dwclm/20080708/?ca=drs-kr

소프트웨어 테스터와 프로그래머의 화합(和合)의 법칙



이영석이영석 stone@sqe.co.kr

SOAP, 웹 서비스 등 XML 기반 기술과 BPM을 통한 프로세스 시스템 신봉자로 소프트웨어 품질에 대한 정통부 GS인증 업무를 수행하는 등 개발자 출신 QA라는 흔치 않은 경력을 가지고 있다. 현재 와이즈스톤(www.wisestone.kr) 대표이며, 소프트웨어 품질관리 교육 및 컨설팅 등을 하고 있다.

2008년 7월 8일



얼마 전 프로젝트 종료 후, 참여원들의 정보와 경험을 교환하는 클로징(closing) 회의 중 이런 얘기가 나왔다. "참여 프로그래머들이 같은 회사 사람들이니 다행이지, 서로 모르는 사이였다면 멱살잡고 싸웠을 겁니다." 모두 한참을 웃었다. 프로젝트에 참여한 프로그래머와 테스터 모두 크게 공감한다는 웃음이었다.

실제로 테스팅에 관한 많은 칼럼과 서적에서 빈번하게 언급되는 이슈가 '어떻게 서로 커뮤니케이션을 할 것인가'라는 의사소통에 관한 주제다. 그만큼 프로그래머와 테스터가 함께 참여하는 개발 프로젝트에서 의사소통 문제는 빈번하게 일어난다.

필자도 이전에 본 컬럼을 통해 이러한 문제에 대한 해결 방안의 하나로 BTS(Bug Tracking System) 같은 시스템 도입을 제안한 적이 있다. 서로 얼굴을 맞대고 문제를 논의하는 것보다는 시스템을 통해 감정을 배제한 의사소통이 효율적이라는 이유에서였다.

이번에는 평화로운(?) 의사소통을 위해 테스터와 프로그래머가 서로를 이해하는 데 도움이 될만한 '소프트웨어 테스팅 법칙 293가지'[1]라는 책에 소개된 몇 가지 재미있는 이야기를 소개하고자 한다.

테스터 관점의 이야기이지만, 프로그래머들도 자신들을 이해하고자 하는 테스터의 노력을 이해하고, 테스터의 눈으로 투영되는 자신들의 모습을 되돌아보는 기회가 되기를 바란다. 서로를 이해하고자 하는 노력과 그 결실인 화합이야말로, 성공적인 프로젝트의 가장 기본 전제이며 왕도(王道)이기 때문이다.


법칙 1. 프로그래머들의 사고방식을 이해하라

프로그래머들은 대부분 전문적이다
프로그래머는 자신이 개발해야 하는 모듈과 컴포넌트에 집중하며, 맡은 업무에 대해서는 적어도 팀 내 최고의 전문가라 할 수 있다.
테스터의 업무적 관점은 다르다. 테스터는 테스트할 시스템에 대해 다방면의 정보를 알고 있어야 하고, 각 모듈의 전체적인 조화에 집중한다.

프로그래머는 시스템에 적용된 자신의 논리에 집중한다
프로그래머는 자신이 만든 모듈과 다른 프로그래머가 만든 모듈의 연관성에 대해 이해하고 있다. 또한 발생할 수 있는 오류 처리에 대한 방안도 준비한다. 이러한 이유로 테스터가 오류를 보고할 때 프로그래머들은 종종 그러한 오류가 발생한다는 사실을 믿지 못하고 의심한다. 그러므로 테스터는 프로그래머가 코딩 시 기획했던 데이터 처리의 논리를 염두에 두고 철저하게 증거를 수집해 결함을 찾아야 한다.

프로그래밍은 복잡한 행위다
얽히고설킨 복잡한 구조의 프로그래밍 작업은 집중이 필요로 한 일이다. 이러한 업무 중에 다른 신경 쓰이는 일이 생기는 상황이 유쾌하지는 않을 것이다. 테스터에게는 이러한 프로그래밍 업무에 대한 이해가 필요하다(물론 테스팅이라는 업무 역시 장시간 집중이 필요한 업무라는 것을 프로그래머도 알아야 할 것이다).

프로그래머는 종종 어려운 상황을 감수한다
프로그래머들은 잦은 요구사항 변화에 따른 코드 변경 요구, 버그에 대한 수정 요구 등 작업 집중에 방해되는 환경 속에서 업무를 수행한다.

많은 프로그래머들은 일상적인 반복 업무를 싫어하며, 주어진 반복 업무를 도구나 스크립트를 작성하여 자동화한다
이러한 업무 성향으로 인해 프로그래머들은 테스터들의 매뉴얼한 반복 작업을 비효율적이고 최적화되지 못한 작업으로 이해하기도 한다. 만약 작은 코드 개발에 참여해 프로그래머가 되어 볼 수 있는 기회를 갖는다면, 개발자들을 이해하는 데 좋은 경험이 될 것이다.



위로


법칙 2. 프로그래머와 신뢰를 쌓아라

테스트할 프로그램을 작성하는 프로그래머와 불필요한 적대 관계를 만들 이유가 없다. 프로그래머들과 함께 개발 계획, 요구사항 분석, 초기 프로토타입 등을 공유할 수 있다면 개발자들을 이해하는 데 도움이 될 것이다.

또한 테스터는 프로그래머들이 자신이 이미 아는 내용에 대해 듣고 싶어하는 것이 아니라는 것을 알아야 한다. 가령 예를 들어 개발 초기에 아직 작성하지 않은 오류 처리 방안이나 개발해야 하는 기능에 대해 듣고자 하는 것이 아니라는 것이다. 이러한 부분은 프로그래머가 몰라서 안 되어 있는 것이 아니라 아직 작업을 하지 않은 것뿐이다. 프로그래머가 각 상황에 따라 무엇을 듣고자 하는지에 대한 이해 역시 중요하다.


법칙 3. 서비스를 제공하라

다음 몇 가지 서비스를 제공하는 것으로 둘 사이의 신뢰에 큰 도움이 될 것이다.

  • 서드파티 컴포넌트를 테스트하라. 테스트 결과를 공유함으로써 프로그래머들은 제품에 해당 컴포넌트를 사용할 것인지 여부를 결정할 수 있으며, 또한 어떻게 사용해야 하는지에 대한 정보를 얻을 수 있다.
  • 프로그래머가 스스로 테스트할 수 있는 테스트 환경을 지원하라.
  • 자신이 개발한 모듈을 테스트하기 위해 프로그래머가 부여 받은 테스트 지원 요구사항에 대해 검토하라. 프로그래머들은 애매모호한 요구사항 때문에 난처한 상황에 처하는 경우가 많으므로 테스터가 도와준다면 기뻐할 것이다.

테스팅 업무는 서비스를 제공하는 성향의 업무이므로 테스터가 프로그래머가 필요로 하는 업무에 대해 적극적으로 서비스를 제공한다면 둘 간의 관계는 대립이 아닌 화합의 관계가 될 것이다.


법칙 4. 성실하고 능력을 갖춰야 존중을 받는다

테스터는 고객의 대변자다. 즉 테스터의 궁극적인 업무는 사용자가 겪을 문제점을 보고하는 일이다. 하지만 아무리 좋은 의도를 담은 행동이라도 잘못된 부분을 지적하는 결함에 대한 보고는 유쾌하다고 하기 어렵다. 훌륭한 보고를 위해 다음과 같은 사항을 고려해야 한다.

문제점을 명확하게 보고하라
불필요한 과정과 정보는 생략하고, 버그가 발생되는 운영 절차와 버그에 대한 현상만을 명확하게 기술해야 한다. 프로그래머가 이해하기 쉽고, 버그 발생 과정을 따라 해보기 쉽게 보고해야 한다. 프로그래머가 간결하고 명확한 보고서를 통해 시간을 아낄 수 있다면, 테스터의 시간도 소중하게 생각할 것이다.

제품에서 실제로 수행한 동작을 판단 기준으로 삼는다
프로그래머는 누구보다도 더 프로그램 내부를 잘 안다. 그러니 테스터는 직접 봤던 것에 대해서만 이야기하면 된다. 어떤 점이 문제를 일으켰는지에 대한 추측으로 시간을 낭비할 필요가 없다.

나쁜 소식은 직접 전달하라
프로그래머가 문제 상황을 인식하고 대처할 시간을 준 다음, 상급자에게 보고하라. 또한 이 문제를 상급자에게 보고할 것이라는 것을 개발자에게 이야기해 주어야 한다.

모르는 것을 아는 체 하지 말라
어설픈 추측이 문제 해결을 방해하는 장애물이 될 수 있다.

버그 리포트를 과대 포장하지 않는다
버그 보고는 사실 그대로를 정확하게 전달해야 한다. 발견한 버그를 과대 포장하지도, 과소 평가하지도 말아야 한다. 또 중요한 버그를 찾았다고 그것을 뽐내도 안 된다. 테스터와 프로그래머가 한배를 탄 운명 공동체라는 것을 명심해야 한다.



위로


법칙 5. 사람이 아닌 작업에 집중하라

버그를 발견하면 '버그'를 보고하라. 프로그래머 아무개가 잘못했다는 식으로 보고해서는 안 된다. 문제가 있는 프로그래머를 보고하는 것이 자신의 업무라고 생각한다면, 모든 프로그래머는 여러분과 정보를 공유하지 않을 것이고, 여러분을 피하려고 할 것이다. 이렇게 된다면 신뢰는 깨진다. 테스터의 업무는 잘못하는 프로그래머를 찾는 것이 아니라, 버그를 찾는 것이다.


법칙 6. 프로그래머들은 자신의 일에 대해 이야기하는 것을 좋아한다. 궁금한 점이 있으면 직접 물어보라

프로그래머와 이야기를 통해 정보를 얻기가 어렵다고 말하는 테스터가 많다. 하지만 프로그래머들이 다루는 설계 문서를 이해하고 그것에 관해 이야기를 시작해보자. 가능하면 코드도 살펴보자. 프로그래머 관점에서 이해하고 그 용어를 가지고 개발자들의 화법으로 이야기하고자 한다면 프로그래머들이 얼마나 자기 일에 대해 이야기하기를 좋아하는지 알게 될 것이다.

이런 대화는 시스템을 구축하는 사람들의 마음속에 있는 전제조건을 알아내는 데 도움이 된다. 또한 시스템을 오동작하게 하는 방식을 찾아낼 수 있다. 테스터가 C++나 자바 등 개발 언어를 알고 있다면 좀 더 도움이 될 것이다. 프로그램이 멀티스레드로 동작한다면 스레드가 어떤 것인지 이해하는 것은 중요한 일이다.

어떻게 하면 제품에서 오류가 발생하도록 할 수 있는지에 대해 고민하는 것이 테스터의 업무라 생각할 수 있다. 그러나 팀의 일원으로 지금 만들고 있는 제품의 진정한 가치를 이해해야 한다.


법칙 7. 프로그래머는 테스트를 도와주고 싶어한다

대부분의 프로그래머는 자기가 작성한 프로그램을 테스트하고 싶어한다. 개발자들은 프로그램을 작성하는 중에 자신이 실수했을 수도 있다는 사실을 인정하며, 이러한 실수를 발견해 주기를 기대하고 있다.

테스터는 프로그래머에게 테스트를 쉽게 해주는 테스트 용이성(testability)을 요구하지만 쉽게 목적을 이루지 못한다. 테스트 용이성 확보를 위한 요청에는 다음 핵심 사항이 있어야 한다.

  1. 프로그래머의 언어로 이야기하라.
  2. 빨리 요청하라.
  3. 현실적이어야 한다.

테스터의 요청이 어느 모듈의 어떤 인터페이스를 원하는지 구체적이라면 프로그래머는 훨씬 쉽게 테스터의 요청을 이해할 것이다. 또한 프로젝트 초기에 테스팅에 관한 요청이라면 개발 일정에 그러한 요구사항을 고려하여 일정을 계획할 수 있어 프로그래머의 업무 진행에 대한 부담이 줄어든다(빠듯한 개발 일정 중간에 테스팅을 위한 지원 요청은 프로그래머에게 정말 감당하기 힘든 스트레스가 된다). 테스트 지원을 위한 코드 추가가 제품을 만들기 위한 프로그래밍보다 부담이 된다면 그러한 요구 또한 옳지 못하다.

많은 테스터들이 프로그래머가 항상 핑계를 댄다고 말한다. '테스트를 위해 포함되는 그 코드가 소프트웨어 보안에 문제를 일으킬 것 같아요', '성능 저해 요인이 될 것입니다' 그러나 이러한 이야기는 오히려 개발자들이 테스트를 위한 코드에 관심이 많다는 의미일 수 있다.

테스터는 프로그래머로 하여금 테스터를 도와주는 것이 궁극적으로 자신에게 도움이 된다는 사실을 인식시키는 것이 무엇보다 중요하다!



위로


후기

대다수의 프로그래머들에게 테스터를 존중하는 마음이 부족한 것이 사실이다. 테스터들을 자신들의 생산품인 프로그램의 '옥의 티'와 같은 흠을 찾아내 닦아주는 흡사 도우미(maid) 정도로 생각한다.

그렇다면 테스터는 이러한 인식을 가진 프로그래머에 대해 어떤 생각을 가지겠는가. 사람 마음은 인지상정(人之常情)이라 똑같지 않을까? 자신을 존중하지 않는 상대에게 좋은 감정을 갖기는 어려울 것이다. 어쩌면 테스터들 눈에는 결점 가득한 프로그램을 만든 프로그래머가 그 코드처럼 결점투성이의 부족한 사람으로 보일 수도 있을 것이다.

원론적인 결론이지만 서로 업무를 존중하고, 개인적인 친분을 위해 노력하는 것이 원만한 상호 관계를 유지하는 방법이라 할 수 있을 것이다. 성서에도 있지 않은가. 사람이 목숨을 유지하기 위해서는 눈, 코, 입, 손, 발 중 하나만 있어서 되는 것이 아니라, 중요한 것은 모두의 화합이라고.



위로


[1] Cem Kaner, James Bach, Bret Pettichord, 소프트웨어 테스팅 법칙 293가지(LESSON LEARNED IN SOFTWARE TESTING: A CONTEXT-DRIVEN APPROACH), 정보문화사, 2004


:

[펌]소프트웨어 테스트 개요

ITWeb/스크랩 2008. 6. 19. 15:47

ref. http://blog.naver.com/sesangsari/20050249197

소프트웨어
테스트 개요

정의

  • 테스트는 프로그램이나 시스템이 자신이 해야 되는 일을 수행하는 믿음을 주는 과정이다. [Hetzel 73]
  • 컴퓨터 소프트웨어를 실행하여 그 결과가 올바른지 판단하는 과정이다. [Glass 79]
  • 에러를 발견한 목적으로 프로그램을 실행하는 과정이다. [Myers 79]
  • 프로그램 테스트는 오류가 존재함을 보일 수는 있지만, 오류가 없음을 보일 수는 없다 [Dijkstra 72]
  • 테스트소프트웨어 품질을 측정하고 개선하기 위한 테스트웨어를 공학화하여 사용하고 유지하기 위한 또 다른 아이프사이클 프로세스이다. [Crag and Jaskiel 02]

Beizer 소프트웨어 테스트 진화 과정

  • Level 1 (debugging-oriented) - 이 레벨에서는 테스트와 디버깅의 차이가 뚜렷하게 보이지 않는다. 즉, 우연히 발견된 오류를 수정하는 디버깅에 중점을 두며 프로그램의 오류를 착기 위한 별도의 노력을 기울이지 않는다.
  • Level 2 (demonstration-oriented) - 프로그램이 올바르게 동작한다는 사실을 입증하기 위해 테스트를 수행한다.
  • Level 3 (destruction-oriented) - 프로그램에 오류가 존재함을 보여주기 위해 테스트를 수행한다.
  • Level 4 (evaluation-oriented) - Level3의 테스트가 실제 프로그램 코드에 있는 오류를 발견하는 것에 초점을 맞추었다면, Level4에서는 소프트웨어 개발 전 단계에 발생하는 오류를 발견하는 개념으로 확장
  • Level 5 (prevention-oriented) - 프로그램의 오류를 사전에 발견하는 것이 아니라 오류가 발생하지 않도록 사전에 방지하자는 개념으로, 프로그램을 개발할 때 처음부터 테스트가 용이하도록 시스템을 설계/ 테스트 용이성을 고려한 프로그램 설계

소프트웨어 오류 원인 및 분포

  • 요구사항의 잘못된 정의 -
  • 고객과 개발자간의 잘못된 의사 소통이나 부재
  • 고의적인 요구사항 미 준수
  • 설계 오류
  • 코딩 오류
  • 문서나 코딩 표준에 따르지 않는 경우
  • 미흡한 테스트 프로세스
  • 요구사항(56%), 설계(27%), 코드(10%), 기타(7%)

테스트 오라클

  • 테스트 실행 결과가 올바른 결과인지를 판별할 수 있는 매커니즘을 일컬음.
  • 테스트 오라클의 분류
    1. 참 오라클 (true oracle) - 모든 입력값들에 대해 원하는 결과들을 생성하여 발생된 오류를 놓치지 않고 검출할 수 있는 오라클을 말함. ex) sin을 계산하는 프로그램을 검사하기위해, 다른 알고리즘을 사용하여 직접 계산
    2. 샘플링 오라클 (sampling oracle) - 특정 몇몇 입력 값들에 대해서만 원하는 결과를 제공해 주는 오라클. ex) sin 함수 테스트 시 0, 90, 180, 270, 360도에 대해서만 결과를 제공함.
    3. 휴리스틱 오라클 (heuristic oracle) - 샘플링 오라클의 단점을 개선하기 위해 특정 몇몇 입력 값들에 대해서는 샘플링 오라클의 경우처럼 올바른 결과를 제공하고, 나머지 입력 값들에 대해서는 휴리스틱으로 처리하는 오라클 ex) sin함수 테스트시 0, 90, 180, 270, 360도에 대해서 올바른 결과를 확인하고, 나머지는 x의 값이 증감에 따라 sin(x)가 증감함을 비교하여 실행결과가 올바른지 판단
    4. 일관성 검사 오라클 (consistent oracle) - 대부분의 상업용 테스트 도구에서 지원하는 테스트 오라클 형태로써, 리그레션 테스트에서의 테스트 오라클은 수정되기 전의 프로그램의 실행 결과와 수정된 후의 테스트 실행 결과를 비교하는 역할을 담당하며, 이는 자동화할 수 있다.

소프트웨어 테스트 전략

소프트웨어 테스트 분류

개발 단계별 분류별

  • 단위테스트 : 구현 단계에서 각 모듈이 구현된 후에 단위 테스트를 수행, 모듈이 단독적으로 실핼할 수 있는 환경 필요
  • 통합테스트 : 단위 테스트가 완료된 모듈 간의 인터페이스 상호작용이 올바르게 되는지를 테스트함으로써 (1) 개별적인 모듈에 대한 테스트가 불충분하게 수행됨을 보완 (2) 제한된 상황만을 고려한 테스트 스텁 때문에 실제 모듈과 통합하는 과정에서 오류가 발생을 확인 (3) 전역 변수 등으로 인해 모듈간의 예기치 못한 상호 작용 때문에 발생하는 부작용(side effect) 인한 오류 발생 부분을 확인 가능하다.
    1. 빅뱅테스트
    2. 점진적 테스트
      1. 하향식 통합 : 가장 상위 모듈을 테스트하기 위해 하위 모듈들을 테스트 스텁들로 대치한 후에 테스트를 수행하는 방식임. 설계상의 오류를 빨리 발견할 수 있다는 장점이 있는 반면에, 많은 수의 테스트 스텁이 필요하기 때분에 비용이 많이 소요될 수 있다. 블랙박스 테스트만 사용하는 경우 하위 모듈이 충분하게 테스트되지 않을 가능성 있음.
      2. 상향식 통합 : 하위 모듈을 먼저 테스트하고 상위에 있는 모듈들을 통합하는 방식임. 하위에 있는 모듈들을 충분하게 테스트할 수 있고, 테스트 스텁 비용이 들지 않는 장점이 있는 반면 설계 오류를 조기에 발견하는 못하는 단점이 있다.
      3. 샌드위치 통합 : 하향식+상향식의 통합하는 방법
  • 시스템 테스트 : 전체 시스템에 대한 초기의 목적을 만족시키는가를 테스트로 통합 테스트가 완료된 후에 완전한 시스템에 대해 시스템 명세에 따라 개발되었는지를 검증하기 위해 수행하는 테스트임. 단위 테스트나 통합 테스트는 기능이 올바르게 수행되는지를 검증하는 것에 중점을 두지만, 시스템 테스트는 시스템의 기능 측면에서뿐만 아니라 신뢰성, 견고성, 성능, 안정성과 같은 비기능적 요구사항을 시스템이 만족하는 지도 검증함.
  • 인수테스트 : 사용자의 요구 사항을 만족하는 가를 확인, 사용자 입장에서 실제 사용자 환경에서 테스트, 시스템테스트에서 사용한 테스트 케이스들을 이용할 수 있음
    1. 알파 테스트 : 사용자에 의해 테스트가 수행되지만 개발자 환경에서 통제된 상태로 수행
    2. 베타 테스트 : 소프트웨어를 일정 수의 사용자들에게 사용하고 피드백을 받는다. 보통 베타 테스트에서는 개발자가 참여하지 않음.
  • 리그레션 테스트 ; 유지보수 단계에서 변경이 제대로 이루어지는 지를 테스트
    1. 오류 수정 작업 (corrective maintenance) - 21%
    2. 기능 보강 작업 (perfective maintenance) - 50%
    3. 적응 작업 (adaptive maintenance) - 25%
    4. 예방 작업 (preventive maintenance) - 4%

  • 테스트드라이버 역할
    1. 테스트 케이스가 저장되어 있는 파일이나 DB로부터 하나의 테스트 케이스를 읽는다.
    2. 읽은 테스트 케이스를 입력 인자로 사용하여 테스트 대상이 되는 모듈을 호출한다.
    3. 모듈의 실행 결과를 저장하고 다음 테스트 케이스를 읽는다. 경우에 따라서는 테스트 드라이버가 테스트 오라클 역할을 수행할 수 있다. (즉 실행결과가 원하는 결과인지를 판별하여 프로그램에 오류가 검출되었는지를 판별하는 기능을 수행)
    4. 2-3과정을 더 이상 실행할 테스트 케이스가 없을때까지 반복하여 수행

  • 테스트 스텁 : 호출되는 모듈의 완전한 기능에 의존되지 않는 경우에는 단순히 호출되는 모듈명과 인자들을 출력할 수 있는 형태, 인자 값들과 관계 없이 특정 싱핼 겨로가를 미리 파일에 전달해서 이를 전달할 수 있다.
  • 모의 객체
    1. 객체 지향 프로그램에서 단위 테스트를 수행할 때 테스트되는 메소드가 다른 클래스 객체에 의존
    2. 독립적인 단위 테스트를 위해서는 절차 지향적 프로그램밍에서 스텁과 같은 개념을 사용하는 것이 필요하며 일정의 스텁의 객체 지향 버전임
    3. 수작업으로 만들거나, 모의 객체 라이브러리(ex: easymock / http://www.easymock.org )를 이용

테스트케이스 생성별

  • 블랙박스 테스트 : 명세를 기반으로 테스트 케이스 작성
    1. 동등분할 클래스
    2. 경계값 분석
    3. 결정 테이블 기반 테스트
    4. 도메인 테스트
    5. Pairwise 테스트
    6. 상태 전이 테스트
    7. Cause-effect graph
  • 화이트박스 테스트 : 프로그램 코드 정보 (제어 및 자료흐름)을 바탕으로 테스트 케이스 작성
    1. 제어흐름 기반 테스트
    2. 자료흐름 기반 테스트
    3. 결함 기반 테스트

테스트 목적별

  • 침입(penetration) 테스트 - 시스템의 보안을 테스트
  • 견고성(robustness) 테스트 - 시스템이 비정상적인 운영환경하에서 얼마나 동작이 원활하게 이루어 지는지를 시험
    1. 네거티브 테스트 : 시스템이 기대하지 않는 입력들을 테스트 데이터로 사용
  • 성능 테스트
  • 스트레스 테스트 및 볼륨 테스트
  • 신뢰성(reliability) 테스트 - 시스템이 어느 기간 동안에 요구되는 서비스를 제공하는 능력을 측정, 통계적 테스트(statistical testing)방법을 사용함.
    1. 가용성(availability) : 시스템이 주어진 기간 동안 서비스를 실제로 제공할 수 있는지 나타내는 속성 (ex : 가용성이 0.995 : 시스템은 1,000시간 단위 동안 995시간 단위 동안 서비스를 제공)
    2. MTTF(mean time to failfure) : 시스템이 운영된 후 오류가 발생할 때까지의 평균 동작 시간 (ex : MTTF가 100 : 100시간 단위마다 1개의 오류가 발생할 수 있다는 것을 의미 )

테스트 대상별

  • 컴파일러 테스트
  • 임베디드 시스템 소프트웨어
  • 운영 체제
  • 웹시스템
  • 컴포넌트 테스트

소프트웨어 테스트 Rule

소프트웨어 테스트 원칙

  1. 테스트는 반드시 프로그램을 개발한 프로그래머나 팀과는 무관한 그룹에 의해서 수행되어야 한다.
  2. 테스트 작업을 가장 능력이 뛰어난 사람에 할당하라.
  3. 오류가 발견되지 않을 것이란 가정하에서 테스트 계획을 수립해서는 안된다.
  4. 타당한 경우뿐만 아니라 타당하지 않고 예상하지 못한 경우들에 대해서도 테스트를 수행하라.
  5. 프로그램의 어떵 부분에 오류가 남아있을 확률은 이미 발견된 오류의 수에 직접적으로 비례한다. (Pareto원칙)
  6. 테스트 케이스를 체계적으로 관리하라
  7. 각각의 테스트 결과를 철저하게 검증하라

테스트기법의 Cam. Kaner 분류

  • 테스트 기법을 구분하는 5가지 요인
  1. Tester : 누가 테스트를 수행하는가?
    • 사용자 테스트, 알파, 베타, 전문가, 짝 테스트
  2. 범위 : 어떤 측면을 테스트 하는가?
    • 함수, 기능 또는 통합 함수, 메뉴, 도메인, 동등 클래스, 경계값, 입력 필드, 논리, 상태, 경로, 요구사항, …
  3. 잠재적 문제(risk based) : 찾고 있는 문제의 형식은?
    • 실패에 대한 예측 비용 관점에서 우선 순위 부여
    • 오류 비용 가능성이 클수록 초기에 주의 깊게 테스트
  4. 행위 : 어떤 테스트를 수행하는가?
    • 회귀, 스크립트 기반, 시나리오, 설치, 부하, 성능…
  5. 평가 : 테스트를 통과했는지 어떻게 알 수 있을까?
    • 자가검증데이터, 저장된 결과와 비교, 다른 공인문서와 비교, 일관성
  • 생각하는 방식에 따라 기법이 분류된다.

Joel Test

  • SW팀 평가 테스트 방법 ( Joen on Software )
  1. 소스코드 관리 시스템을 사용하고 있습니까?
  2. 한번에 빌드를 만들어 낼 수 있습니까?
  3. 일일 빌드를 하고 있습니까?
  4. 버그 추적 시스템을 운영하고 있습니까?
  5. 코드를 새로 작성하기 전에 버그를 수정합니까?
  6. 일정을 업데이트하고 있습니까?
  7. 명세서를 작성하고 있습니까?
  8. 조용한 작업 환경에서 일하고 있습니까?
  9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
  10. 테스터를 별도로 두고 있습니까?
  11. 프로그래머 채용 인터뷰때 코딩 테스트를 합니까?
  12. 무작위 사용편의성 테스트를 수행하고 있습니까?

Test Paradigm Shift

  • 테스트 단계 활동 –> 모든 단계 활동
  • 정상 수행 확인 –> 오류(Error) 발견
  • 단위 테스트 중심 –> 시스템 테스트 중심

Effective Test

  • How to make testing more effective (by Boris Beizer)
  1. Know which test techniques work best
  2. Automate retesting and test management
  3. Minimize test design labor
  4. Know when to stop testing

Test CheckList

  1. Configuration/설치 테스팅
    1. HW 및 SW가 정확히 설치되었는가?
    2. 모든 파일과 연결(connection)이 생성되었는가?
    3. 모든 적절한 데이터 파일이 load되었는가?
    4. System defaults가 적절히 구성되었는가?
    5. 다른 시스템과의 인터페이스 및 주변 기기가 잘 작동하는가?
  2. 호환성 및 상호운영성 테스팅
    1. 호환성: 실제 환경에서 운영할 때 기존의 시스템에 대해 오동작이 없는가?
    2. 상호운영성 : 실제 환경에서 대상 시스템을 운영할 때 다른시스템과 성공적으로 연동 하는가?
  3. 문서 및 도움말 테스팅
    1. 문서 검토, 상호 참조 등을 활용하여 작성해야 함, 신규 또는 익숙하지 않은 사용자의 경우 필수적임.
  4. 장애회복(Fault recovery) 테스팅
    1. 에러 또는 예외 상황 발생 후 정상 상태로 회복되어 성공적으로 운영될 수 있는가?
    2. 적절한 백업데이터가 유지되는가?
    3. 백업데이터가 안정한 장소에 저장되는가?
    4. 회복 절차가 문서화되어 있는가?
    5. 회복 전담요원이 할당되고 훈련되었는가?
    6. 회복 도구가 개발되고 가용한가?
  5. 성능 테스팅: 자동화 도구를 활용하는 경우가 많음.
    1. 어떤 측면을 주로 테스트할 것인가?
    2. 성능 요구사항은 무엇인가?
    3. 시스템 사용시 어떻게 변화되는가?
    4. 어떻게 시험하는가?
  6. 자동화된 테스팅
    1. Test automation tools 활용 재사용 가능한 테스트 생성 및 예상결과외 실제 결과를 기록으로 남김)
    2. 적용분야 : 기능 테스팅, 성능/볼률/스트레스 테스팅, 특히 regression testing시 유용함
  7. Intrusive 테스팅
    1. 테스트 결과를 테스터가 볼 수 없을 때 프로그램 일부를 수정하여 테스트
    2. 수정된 시스템은 원상 복귀하여야하며, 엄격한 change control 및 형상관리가 요구됨
  8. Thread 테스팅
    1. Business 기능을 처음부터 끝까지 테스트 함 (사용자 혹은 운영자가 시스템을 사용하는 것과 같은 방식)
  9. ETC
    1. Security 테스팅 - 요구되는 수준의 보안을 구현하였는지 테스트함 (비밀보장,가용성,데이터및 SW무결성을 점검)
    2. Stress 테스팅 - Peak Load일 때 정확하게 작동하는지 점검
    3. Usability 테스팅 - User-based surveys등 수행
    4. Volume 테스팅 - 데이터의 양이 많을 때 정확하게 작동하는지 점검
    5. Compliance 테스팅 - 표준 및 절차에 따라 개발되었는지 점검

Testability

  • 제어용이성 (controllability) 프로그램의 실행을 제어하기 용이하도록 설계. 제어 용이성이 높아지면 테스트를 자동화할 수 있는 부분이 많아지고 최적화 할 수 있다.
  • 관찰가능성 (observability) - 프로그램의 내부 상태가 현재 어떤 상태인지를 쉽게 파악할 수 있는 기능을 갖추도록 설계
  • 단순성 (simplicity) - 가능한 시스템 구조 등을 단순하게 설계하면 더 효율적으로 테스트를 수행할 수 있다.
  • 분할용이성 (decomposability) - 테스트할 대상 영역을 제어함으로써 문제가 발생된 곳을 고릅시켜 독립적으로 모듈에 대한 테스트를 수행할 수 있도록 설계
  • 운영용이성 (operability) - 프로그램이 결함이 발생하여도 테스트 작업을 계속할 수 있도록 설계
  • 안정성 (stability) - 테스트 동안에 소프트웨어에 대한 변경이 자주 발생되지 않도록 설계
  • 이해용이성 (understandability) - 소프트웨어 설계 정보가 잘 조직화되어 쉽게 접근 가능하도록 하여 소프트웨어를 더욱 잘 이해할 수 있도록 설계
: