지식 제로부터 배우는 소프트웨어 테스트

저자는 타카하시 쥬이치이며, 소프트웨어 테스트와 관련하여 지식이 별로 없다보니 기초를 위해 잡은 책. 쉽게 재미있게 쓰여진 책인 듯하다. 글이 쓰여진 시기가 2013년이라 지금으로 부터 좀 오래전(IT쪽에서 보면)이라는게 아쉽기는 하지만 그래도 기초적인 지식을 쌓기에는 꾀 좋은 책인 듯하다. 이론적인 내용도 깊지 않지만 다루고 있고, 자신의 경험이나 실무와 관련하여서도 노하우를 알려주고 있다.   

   주요 내용 정리

모든 버그를 발견하는 것은 무리라고 생각하라 -Cem Kaner

프로그램 한 부분에 에러가 아직 있을 확률은 이미 그곳에서 발견한 에러 수에 비례한다. -G. J. Mayers

소프트웨어는 입력, 출력, 계산, 저장 이 네가지 동작에 대한 테스트만 하면 끝난다. - James Wittaker

80%의 버그는 20%의 컴포넌트에서 나오며 전체 중 50%의 컴포넌트에는 버그가 존재하지 않는다 -Boehm

화이트박스 테스트

프로그램의 논리 구조가 올바른지를 분석하는 테스트. 프로그램 내부 구조를 분석 및 테스트.

논리 구조의 올바름을 테스트하므로 소프퉤어의 사양이 틀려 발생하는 버그를 발견할 수 없음

제어 흐름 테스트

프로그램이 어떻게 움직이며 어떻게 제어 되어 실행되는가를 테스트. 

커버리지율(Coverage rate) 값을 얻고자 사용

스테이트먼트 커버리지, 브랜치 커버리지 테스트 등이 있음

스테이트먼트 커버리지

코드안의 명령문(스테이트먼트)를 적어도 한번은 실행

무척 약한 테스트 방법

브랜치 커버리지

분기 코드에 대해 각각의 반정 조건이 True, False 결과를 적어도 한 번씩 가질 수 있도록 테스트 케이스 작성

스테이트먼트 커버리지보다 강력

커버리지 테스트로 검출 할 수 없는 버그

- 프로그램 루프와 관련된 버그

- 요구사항 자체가 틀렸거나 기능이 준비되지 않은 버그

- 데이터와 관련된 버그

- 타이밍과 관련된 버그 (멀티 태스크나 인털럽트 관련 버그)

테스트 주도 개발 (Test Driven Development, TDD)

애자일 개발 스타일에서 주로 사용되는 것으로 짧은 사이클로 (Unit) 코딩 테스트를 수행, 리팩토링, 통합을 반복하며 개발해나가는 방식

TDD의 본직은 확실하게 품질을 보증한다기 보다는 신속하게 개발하여 변경에 내성을 기른다는 것

블랙박스 테스트

프로그램을 일종의 블랙박스로 보고 다양한 입력을 실행함으로써 소스 코드를 보지 않고 테스트를 수행하는 방법

등가분할(Equivalence Partitioning)

입력 영역을 '등가 클래스'라는 부분 집합으로 분할하고 그 부분 집합에서 선택한 입력값을 모두 같은 값이라고 보는 작업

경곗값 분석(Boundary Value Analysis)

테스트 값으로 유효 등과와 유효 등가의 사이값을 사용하는 방법. 서로 다른 처리가 수행되는 가장 가까운 두 곳을 테스트. 

디시전 테이블(Decision Table)

모든 입력 조합을 표로 만든 다음 이에 해당 입력에 대해 동작이나 출력을 표시하는 방법으로 복잡한 상태가 얽힌 기능 테스트에서 힘을 발휘

상태 전이 테스트

상태를 모델화하여 테스트를 수행하는 방법

상태수가 많으면 모델이 복잡해짐과 동시에 테스트 항목이 너무 늘어남

무작위 테스트(애드혹 테스트, 애드립 테스트)

닥치는 대로, 아무 것도 생각하지 않고 입력하거나 조작을 수행하는 방법

블랙박스 테스트 정리

우선 경계값 테스트 시행

만약 입력 영역이 두개 이상인 대화상자가 있다면 디시전 테이블 테스트를 수행

상태가 변하는 소프트웨어라면 상태전이 테스트를 수행

탐색적 테스트(Exploratory Testing)

소프트웨어 기능을 배워가면서 테스트 설계와 테스트 실행을 동시에 수행하는 방법으로, 우선 테스터가 테스트와 관련하여 학습을 하고 테스트를 설계, 테스트 실행, 테스트 결과 보고의 순으로 활동. 좀더 자세하게는 아래와 같음 

1. 대상 소프트웨어의 목적을 명확히 한다. 
2. 기능을 목록화 한다. 
3. 약한 기능이나 조작을 목록화 한다.
4. 각 기능을 테스트하고 버그를 기록한다
5. 계속 테스트를 진행한다.

탐색적 테스트 정리

탐색적 테스트가 테스트 케이스 기반의 테스트보다 낮은 효율을 보인다는 데이터는 존재하지 않는다. 탐색적 테스트는 테스트 담당자가 충분한 소프트웨어 기반의 지식과 함께 테스트 지식이 있을 때에 비로소 뛰어난 힘을 발휘한다. 탐색적 테스트 + 기술을 갖춘 테스트 담당자의 최강 조합이라면 짧은 시간에 최대의 결과를 낼 수 있다. 

비기능 요구(품질 특성) 테스트

테스트에서 중요한 특성은 보안성(Security), 신뢰성(Reliability), 효율성(Efficiency)이 가장 중요하다고 생각. 그리고 그럭저럭 테스트할 수 있거나 기능을 기반으로한 블랙박스 테스트를 수행하다보면 해결 될 때가 많음

비기능 요구 테스트에서는 각각의 비기능 요구에 대해 접근 방법이 모두 다름

성능 테스트

소프트웨어를 설계하거나 기획하는 단계에서 설정된 소프트웨어 성능이 기대한 대로 나오는가 확인하는 테스트

성능의 정의는 명확하게, 요구 정의대로만 테스트 케이스를 작성해서는 안됨, 성능 테스트는 미루지 말 것. 

성능 테스트 5단계

1. 아키텍처 검증

2. 성능 벤치마크

3. 성능 회귀 테스트

4. 성능 튜닝, 억셉턴스 테스트

5. 24x7 성능 모니터링

보안 테스트

종래의 소프트웨어 테스트란 개발자가 제대로 프로그래밍을 하지 못했던 소프트웨어의 장애를 미리 방지하는 방법론이기 때문에, 악의적인 공격을 일으키는 문제를 발현하는 것은 지금까지도 소프트웨어 테스트 범주에는 포함되지 않고 있다. 

보안 문제는 '구조의 취약점을 이용해 그 프로그램의 제어권을 빼앗기거나 불능이 되게함', '데이터의 취약점을 이용해 데이터를 조작'이라는 두 부류로 크게 나뉨. 

보안 테스트 분야는 아직 테스트 방법이 발달하지 못했으므로 무작위 테스트에 주로 의존

신뢰성 테스트

소프트웨어의 신뢰성을 측정하려면 신뢰도 성장 곡선 같은 것을 그려야만 한다. 이대 메트릭으로는 전통적으로 MTBF(Mean Time Between Failure)를 이용한다. 

테스트 계획 작성 방법

IEEE 829 테스트 템플릿을 바탕으로 항목을 추가하거나 필요 없는 항목을 삭제해서 사용

• 테스트 계획 문서 번호(Test plan identifier) - 테스트 계획은 항상 업데이트되어야 하므로 버전 번호도 붙인다. 
• 참고 자료 (References) - 테스트 계획과 관련된 문서 열거, 예를들어 프로젝트 계획, 요구사항 문서, UI 사항 문서
• 소개 글 (Introduction) - 테스트 아이템, 테스트해야하는 기능에 대한 요약, 왜 이 테스트 계획을 작성해야 하는가? 이후 테스트는 어떤 방향성으로 작업할 것인가, 어떤 품질의 제품을 만들어 내고 싶은가에 대하여 입력
• 테스트 아이템 (Test items) - 테스트할 소프트웨어 버전, 어떤 매체에서 테스트 되는가, 어떤 하드웨어에 의존하는가
• 테스트 해야하는 기능 (Features to be tested) - 테스트할 기능을 목록으로 작성
• 테스트 할 필요가 없는 기능 (Features not to be tested) - 관리자의 승인을 꼭 받아야 하는 항목
• 접근 방법 (Approach) - 어떤 접급 방법으로 테스트 할것인지. 예를 들어 "모든 테스트 케이스는 커버리지 도구로 모니터하고 브랜치 커버리지로 90%이상을 실현"
• 테스트 아이템의 합격/불합격 판정 기준 (Item pass/fail criteria)
• 중지 기준과 재개 요건 (Suspension criteria and resumption requirements)
• 테스트 성과물 (Test deliverables)
• 테스팅 태스크 (Testing tasks)
• 실행 환경 (Environmental needs)
• 책임 범위 (Responsibilities)
• 인원 계획, 훈련 계획 (staffing and training needs)
• 일정 (Schedule) - IBM의 조사에 따르면 소프트웨어 코드 1000줄안에 약 60개의 버그가 있다고 함. 
• 위험과 대책 (Risks and contingencies) - 복잡도, 신규성, 변경, 상위 의존성, 등 소프트웨어 테스트 등의 위험 요인이 있으므로 이에 대한 대책을 마련하는 것도 필요
• 승인 (Approvals)
• 종료 기준 (필자 추가) - 중요도가 '높음'의 버그가 남아있지 않을 것, 모든 테스트 케이스의 98%를 통과했을 것, 48시간 이내에 중요도 '높음'버그가 발견되지 않을 것

테스트 케이스 작성 방법

IEEE 829-2008 에는 테스트 케이스의 작성 방법에 대한 정의가 있음 

언제, 누가 해도 똑같은 결과를 얻을 수 있도록 써야 한다. 

테스트 케이스 관리 도구를 사용하면 입력이나 관리를 빠르게 할 수 있음. 오픈 소스 테스트 케이스 관리 도구 도입도 좋다고 생각

테스트 케이스 로그 기록

• 날짜:테스트 실행 날짜
• 테스트 결과: 테스트가 성공인지 실패인지
• 실시자: 누가 테스트 실행?
• 빌드번호: 어느 빌드로 테스트 실행
• 환경 : 어떤 컴퓨터로 실행? 어떤 OS?

최초로 테스트 케이스를 실행할 때는 중요 기능 테스트부터 실행해야 한다. 이렇게 함으로써 중요한 기능이 동작하지 않아 다른 기능을 테스트할 수 없는 사태를 막을 수 있다. 

품질을 눈에 보이기 위한 매트릭 선택

• 중요도가 높은 버그의 발견수 
• 버그 수정에 드는 시간
• 모듈당 버그 수 
• 코드 복잡도(McCabe의 규칙 이용)

   저자의 생각

버그 발생 상태를 보면서 버그가 많이 나오는 부분에 대해 브랜치 커버리지를 실행해는 것도 나쁘지 않음(브랜치 커버리지보다 강력한 커버리지 방법도 있음)

프로그램에서 '경계'라 불리는 곳은 항상 버그가 숨어있으므로 경곗값 부근은 상세히 테스트할 필요가 있다.

테스트 엔지니어에게 충분한 기술이 없거나 시간이 부족한 경우 좋은 데이터와 나쁜 데이터를 입력하도록 한다. 

좋은 데이터 

- 사용자가 자주 사용 할 듯한 데이터

- 프로그래머가 허용하는 최소 데이터

- 프로그래머가 허용하는 최대 데이터

- 0^25(혹은 나쁜 데이터로)

나쁜 데이터

- 아주 작은수 (-999999999, 0.000000001등)

- 아주 큰수 (9999999999, 10999999999 등)

- 긴 데이터

- 무효 데이터

아무리 테스트 케이스를 잘 작성한다고 해도 테스트 케이스 실행을 통해 발견하는 버그는 50%이하인 것 같다. 차라리 테스트 케이스를 일일이 사전에 작성하는 것보다 소프트웨어를 테스트하면서 생각하여 시행하는 것이 더 낫다. 

테스트 자동화 도구를 이용한 테스트는 추천하지 않음. 사는 것보다 자신이 만드는 편이 싸게 먹힘. 

주로 특정 컴포넌트에서 버그가 몰려 있는 경우가 많으므로 모듈별  버그 발견 수 데이터를 확인하여 해당 모듈에 대하여 다양한 테스트를 수행