[소프트웨어공학] 소프트웨어 테스팅 프로세스 여러 기법 및 모델 정리

소프트웨어 테스팅

목적 : 잘 수행되는지 확인 및 프로그램 사용 전 결함 발견
테스팅 방법 : 인위적인 데이터를 이용하여 프로그램 실행
점검 대상 : 오류, 이상, 또는 프로그램의 비기능적 속성에 관한 정보

소프트웨어 테스트 종류

검증 테스팅
- 시스템의 예상된 사용을 반영하는 테스트 케이스 집합 이용
- 시스템이 정확하게 수행되는 것을 기대
결함 테스팅
- 테스트 케이스는 결함을 드러낼 수 있도록 설계
- 소프트웨어의 동작이 부정확하거나, 명세에 따르지 않게 되는 입력 또는 입력 순서를 찾음
두 접근법 간의 명확한 경계는 없음

프로그램 테스팅의 입출력 모델 및 테스트 과정

시스템이 블랙박스로서 테스트되는 경우로 가정
결함 테스팅의 우선순위 집합 l_e에 속한 입력을 찾는 것
- 시스템에 있는 문제를 드러내기 때문
검증 테스팅 우선순위 → 정확한 입력으로 테스팅(집합 l_e)에 속하지 않는 입력)
- 시스템이 예상되는 정확한 출력을 생성하도록 함

프로그래밍 테스팅의 한계

테스팅이 다음의 내용을 보장하진 않는다
- 소프트웨어의 결함이 없다
- 모든 환경에서 명세대로 동작한다.
테스트하지 않은 항목에서 시스템에 있는 추가적인 문제 발견 가능
테스팅은 폭넓은 소프트웨어 검증 및 확인 프로세스의 일부
- 검증 : 제품을 올바르게 만들고 있는가?
- 확인 : 올바른 제품을 만들고 있는가?

검증과 확인 프로세스

소프트웨어 검증
- 소프트웨어가 명시된 기능적 및 비기능적 요구사항에 맞는지 점검하는 프로세스
소프트웨어 확인 - 좀 더 일반적인 프로세스
- 소프트웨어가 고객의 기대에 맞는지 보증하는 것
- 소프트웨어가 고객이 기대하는 것을 하는지 보증하는 것
이 두 프로세스는 요구사항을 활용 가능하게 되면 바로 시작하며 개발 프로세스의 모든 단계를 걸쳐서 계속됨
요구되는 확신의 수준은 다음의 사항에 의해 결정
- 시스템의 목적
- 사용자의 기대
- 시장 환경

인스펙션과 리뷰

시스템 요구사항, 설계 모델, 프로그램 소스 코드를 분석하고 검사
- 정적 확인 및 검증 기술 - 검증을 위해 실행시킬 필요 없음
대부분 시스템의 소스 코드에 집중
검증과 확인 프로세스에 포함

인스펙션과 테스팅

소프트웨어 인스펙션 장점

한 번의 인스펙션으로 시스템에 있는 여러 오류를 발견할 수 있음
- 인스펙션은 오류들 간의 상호 작용에 대해 염려할 필요 없음
추가 비용 없이 시스템의 불완전한 버전이 검사 될 수 있음
프로그램의 폭넓은 품질 속성을 검토할 수 있음
- 품질 속성 - 표준의 준수, 이식성, 유지보수성
- 비효율성, 부적절한 알고리즘, 서툰 프로그래밍 방식 등

소프트웨어 인스펙션 단점

소프트웨어 테스팅을 대체 불가능
다음 유형의 결함 발견하는 데는 부적합
- 프로그램의 다른 부분 간의 예상치 못한 상호작용
- 타이밍 문제
- 시스템 성능 문제
별도의 인스펙션 팀을 두는 것은 어렵고 비용이 많이 듦

소프트웨어 테스팅 프로세스 모델

전통적인 테스팅 프로세스

테스트 케이스
- 테스트에 대한 입력, 시스템으로부터 예상되는 출력의 명세, 무엇이 테스트되고 있는지에 대한 서술 포함
- 자동으로 생성 불가
테스트 데이터
- 시스템을 테스트하기 위해 고안된 입력
- 자동으로 생성될 수 있음

상용 소프트웨어 시스템 테스팅의 3단계

개발 테스팅 (시스템 설계자와 프로그래머)
- 버그와 결함을 발견하기 위해 시스템 개발 중에 테스트
릴리스 테스팅 (별도의 테스팅 팀)
- 시스템의 완성된 버전을 사용자에게 릴리스 하기 전에 테스트
- 시스템이 이해 당사자들의 요구사항에 맞는지 점검
사용자 테스팅 (시스템의 사용자 또는 잠재적인 사용자들)
- 실제 사용 환경에서 시스템을 테스트
  - 소프트웨어 제품이 팔릴 수 있을지 결정하기 위해 테스트하는 경우
  - 인수 테스팅
    - 추가 개발 필요? 시스템 인수?
    - 고객이 공식적으로 시스템 테스트

소프트웨어 테스팅 프로세스

보통 수동 테스팅과 자동 테스팅을 섞어서 수행
수동 테스팅
- 테스터가 프로그램을 어떤 테스트 데이터를 가지고 실행시키고 그 결과를 예상하는 것과 비교
- 불일치하는 경우 불일치를 기록하고 프로그램 개발자에게 보고
자동 테스팅
- 테스트가 개발 중인 시스템이 테스트될 때마다 실행되는 프로그램으로 구성
- 프로그램이 예정된 대로 동작하는지 점검만 가능
- 다음의 경우 사용 불가능
  - 사물이 어떻게 보이는지에 의존하는 시스템
  - 프로그램이 예상치 못한 부작용이 없는지 테스트하는 경우

개발 테스팅

시스템을 개발하는 팀에 의해 수행되는 모든 테스팅 활동을 포함
소프트웨어를 개발한 프로그래머가 보통 테스터 역할을 수행
프로그래머/테스터 짝을 이용하기도 함
- 프로그래머와 연관된 테스터가 테스트를 개발하고 테스팅 프로세스를 도움
중대한 시스템의 경우 더욱 정형적인 프로세스를 사용
결함 테스팅 프로세스(목표 : 소프트웨어 버그를 발견하는 것)
- 디버깅과 중첩 - 코드의 문제를 찾아 그 문제를 고치기 위해 프로그램을 변경

세 단계의 개발 테스팅

단위 테스팅
- 객체나 메서드의 기능을 테스트
  - 개별 프로그램 단위 또는 객체 클래스가 테스트됨
컴포넌트 테스팅
- 컴포넌트 기능에 접근하는 컴포넌트 인터페이스를 테스트
  - 통합 컴포넌트 : 여러 개별 단위가 통합되어 생성된 결과물
시스템 테스팅
- 컴포넌트의 상호작용을 테스트
  - 시스템의 일부/전체 컴포넌트를 통합하여 시스템이 전체로서 테스트됨

단위 테스팅

프로그램 컴포넌트를 테스팅하는 프로세스
테스팅할 때 객체의 모든 기능이 포함되도록 테스트를 설계
이상적으로는 메서드를 따로 분리하여 테스트해야 하지만, 어떤 경우에는 테스트 순서가 필요
- 기상 관측소 예 - shutdown()을 테스트하기 위해 restart()를 실행해야 함

단위 테스팅의 어려움

일반화 또는 상속은 객체 클래스 테스팅을 더 복잡하게 함
상태모델을 이용할 수 있지만 비용 문제 발생
- 테스트되어야 하는 상태 전이 순서를 식별하고 이 순서대로 전이시키는 이벤트 순서를 정의
가능하다면 단위 테스팅을 자동화해야 함
- 테스트 자동화 프레임워크를 사용

단위 테스팅 및 테스트 자동화

단위 테스팅 프레임워크
- 특정 테스트 케이스 생성을 위하여 확장할 수 있는 범용 테스트 클래스를 제공
- 전체 테스트 모음은 대게 몇 초 안에 실행 가능 → 프로그램 변경시마다 테스트 가능
- 자동화된 테스트에는 세 부분이 있음
  - 설정 부분
    - 시스템을 테스트 케이스로 초기화
  - 호출 부분
    - 테스트될 객체나 메서드를 호출
  - 단언 부분
    - 호출 결과로 예상되는 결과와 비교, 단언이 참이면 테스트 성공, 아니면 실패

모형 객체를 사용한 단위 테스팅

모형 객체 : 사용되는 외부 객체와 같은 인터페이스를 가지며 그 기능을 모사
테스팅하는 객체가 구현되지 않은 객체들 또는 테스팅 프로세스에 시간이 많이 걸리게 하는 객체들에게
의존성을 가지는 경우에 사용
- 예 - 객체가 데이터베이스 호출을 하는 경우 사용 전 설정이 오래 걸릴 수 있음
비정상 동작이나 잘 일어나지 않은 이벤트를 모사하는 데 사용될 수 있음
- 시스템이 특정 시간에 행동을 하도록 예정되어 있는 경우

분할 테스팅 - 효과적인 테스트 케이스 선정 전략

공통 특성을 가지고 동일한 방식으로 처리되어야 하는 입력 그룹을 식별
각 그룹 안에서 테스트를 선정
입력 데이터와 출력들은 서로 다른 클래스들로 나뉠 수 있음
- 각각의 클래스들은 동등 분할 혹은 도메인이라고 불림
테스트 케이스는 각각의 분할로부터 선택되어 사용됨
- 테스트 케이스는 분할의 경계에 있는 케이스, 분할의 중간점에 가까운 케이스를 선정하는 것이 좋음

동등 분할

가이드라인을 활용한 테스팅 - 효과적인 테스트 케이스 선정 전략

테스팅 가이드라인
- 어떤 종류의 테스트 케이스가 오류 발견에 효과적인지에 관한 지식을 포함
시퀀스, 배열, 또는 리스트가 있는 프로그램 테스트 가이드라인
- 단 하나의 값만 가지는 시퀀스로 소프트웨어를 테스트
- 테스트마다 다양한 크기(0 포함)를 가지는 서로 다른 시퀀스를 사용
- 시퀀스의 첫 번째, 중간, 마지막 원소가 접근되도록 테스트를 유도
  - 분할 경계에 있는 문제를 드러나게 함

일반적인 테스팅 가이드라인

시스템에서 모든 오류메시지들이 생성되게 만드는 입력값들을 선택
버퍼 오버플로우가 일어나도록 입력을 설계
같은 입력 또는 입력 순서를 여러 번 반복
유효하지 않은 출력이 생성되도록 한다.
계산 결과가 너무 크거나 너무 작게 만든다.

컴포넌트 테스팅

소프트웨어 컴포넌트
- 상호 작용하는 여러 객체들로 이루어져 있음
- 객체들의 기능은 컴포넌트 인터페이스를 통해서 접근
복합 컴포넌트 테스팅의 목표
- 컴포넌트 인터페이스 또는 인터페이스가 명세에 따라 동작한다는 것을 보여줌
다양한 유형의 인터페이스 오류가 발생할 수 있음

인터페이스 테스팅

인터페이스 종류

매개변수 인터페이스
- 데이터의 참조 또는 어떤 경우 함수의 참조가 한 컴포넌트에서 다른 컴포넌트로 전달되는 인터페이스
- 객체의 메서드는 매개변수 인터페이스를 가짐
공유 메모리 인터페이스
- 메모리 블록이 컴포넌트 간에 공유되는 인터페이스
- 한 서브시스템이 데이터를 메모리에 기록하고 다른 서브시스템이 메모리에서 데이터를 읽어감
- 센서가 생성한 데이터를 다른 시스템 컴포넌트가 읽고 처리하는 임베디드 시스템에서 사용
프로시저 인터페이스
- 다른 컴포넌트에 의해 호출될 수 있는 프로시저들의 집합을 한 컴포넌트에 모아놓은 인터페이스
- 객체와 재사용 가능한 컴포넌트들은 이 형식의 인터페이스를 가짐
메시지 전달 인터페이스
- 한 컴포넌트가 다른 컴포넌트에 메시지를 전달하여 서비스를 요청하는 인터페이스
- 반환 메시지에는 서비스를 실행한 결과가 포함되어 있음
- 클라이언트-서버 시스템 같은 경우 이 형식의 인터페이스를 가짐

인터페이스 오류 및 종류

인터페이스 오용
- 호출하는 컴포넌트가 다른 컴포넌트를 호출할 때 인터페이스를 잘못 사용
인터페이스 오해
- 호출하는 컴포넌트가 호출되는 컴포넌트의 동작에 대해서 잘못 가정하는 경우
타이밍 오류
- 데이터의 생산자와 소비자가 서로 다른 속도로 동작하고 오래된 정보에 접근하는 경우

인터페이스 테스팅을 위한 지침

테스트될 코드를 검사하여 각각의 외부 컴포넌트 호출을 식별
인터페이스를 통해 포인터가 전달될 때 항상 널 포인터 매개변수를 가지고 인터페이스를 테스트
프로시저 인터페이스를 통해 컴포넌트가 호출될 때 고의적으로 컴포넌트가 실패하게 하는 테스트 설계
메시지 전달 시스템에서 스트레스 테스팅 사용
공유 메모리를 통해 여러 컴포넌트가 상호작용 하는 경우, 컴포넌트들이 활성화되는 순서가 바뀌도록 설계

시스템 테스팅

개발 중의 시스템 테스팅
- 시스템의 버전을 생성하기 위해 컴포넌트들을 통합하고 통합된 시스템을 테스팅하는 것과 관련
다음을 검사
- 컴포넌트 호환, 상호작용하는지, 인터페이스를 통해 정확한 데이터를 전송하는지
컴포넌트 테스팅과의 차이
- 별도로 개발된 재사용 가능한 컴포넌트와 기성품 시스템이 통합되고 완전한 시스템이 테스트됨
- 다른 팀 구성원이나 하부팀에서 개발된 컴포넌트가 이 단계에서 통합
  - 시스템 테스팅은 개별적이기보다는 집단적인 프로세스

상호 작용 테스팅

시스템을 구성하는 컴포넌트들과 객체들 간의 상호 작용을 테스팅
유스케이스 기반 테스팅이 효과적인 접근법
- 상호작용에 초점을 맞추기 때문
- 여러 컴포넌트들이나 객체들은 보통 시스템의 각 유스케이스를 구현

기상 데이터 수집 시퀀스 다이어그램으로부터의 테스트 케이스

보고를 요청하는 입력은 연관된 응답이 있어야 하며, 요청에 대해서 궁극적으로 보고되어야 함
- 테스팅 중에는 보고가 제대로 구성되었는지 점검하기 위한 요약 데이터를 생성해야 함
WeatherStation에 보고하라는 입력 요청의 결과로 요약 보고가 생성됨

테스팅 정책

모든 가능한 프로그램 실행 순서를 테스트하는 철저한 테스팅은 불가능
테스팅 정책의 예시
- 메뉴를 통해 접근되는 모든 시스템 기능들이 테스트돼야 함
- 같은 메뉴를 통해 접근되는 기능들의 조합이 테스트되어야 함
- 사용자 입력이 제공되는 경우 모든 기능들은 올바른 입력 와 틀린 입력 둘 모드를 가지고 테스트되어야 함

테스트 주도개발(TDD)

테스팅과 코드 개발을 중첩시키는 프로그램 개발 접근법
증분을 위한 테스트와 함께 코드를 점증적으로 개발
- 개발된 코드가 그것을 위한 테스트를 모두 통과할 때까지 다음 증분 작업을 시작하지 않음
XP 애자일 개발 기법의 일부로 소개됨
- 애자일과 계획기반 프로세스 모두에 사용 가능

기본적인 TDD 프로세스

요구되는 기능의 증분을 식별하는 것으로 시작
- 작고 몇 줄의 코드로 구현 가능해야 함
이 기능을 위해 테스트를 만들고 자동화된 테스트를 구현
구현되어 있는 다른 모든 테스트들과 함께 그 테스트를 실행
해당 기능을 구현하고 테스트를 다시 실행
- 리팩토링 포함할 수 있음
모든 테스트가 성공적으로 실행되었으면 기능의 다음 부분 구현으로 이동

테스트 주도 개발의 특징

자동화된 테스팅 환경이 필수적
- 아주 작은 증분의 코드가 개발되기 때문
- 테스트를 실행시키고 테스트 대상 시스템을 호출하는 별도의 프로그램으로 테스트가 내장되어야 함
프로그래머가 코드의 일부가 실제로 무엇을 하는 것인지에 대한 생각을 분명히 하는 것을 도움

테스트 주도 개발의 장점

코드 커버리지
- 원칙적으로 작성된 모든 코드의 일부는 적어도 하나의 연관된 테스트가 있어야 함
회귀 테스팅
- 프로그램이 개발될 때 테스트 스위트가 점증적으로 개발됨
단순화된 디버깅
- 테스트가 실패했을 때 문제를 찾기 위한 디버깅 도구를 사용할 필요 없음
시스템 문서화
- 테스트 자체가 코드가 무엇을 하는지 설명하는 문서의 형태로 동작
  - 테스트를 읽는 것은 코드를 이해하기 쉽게 함

회귀 테스팅

시스템에 변경이 가해진 후 성공적으로 실행되었던 테스트 집합들을 실행시키는 것
- 변경이 새로운 버그를 초래하지 않았고 새로운 코드가 기존 코드와 의도대로 상호작용하는지 검사
자동화된 테스팅은 회귀 테스팅의 비용을 극적으로 감소시킴
- 기존 테스트들이 빠르고 값싸게 재실행될 수 있음
- 시스템에 변경을 가한 후 기능을 더 추가하기 전에 기존의 모든 테스트가 성공적으로 수행돼야 함

릴리스 테스팅

개발팀 외부에서 사용하기로 의도된 시스템의 특정 릴리스를 테스팅하는 프로세스
- 보통은 고객과 사용자를 위한 것
- 복잡한 프로젝트에서는 릴리스가 관련된 시스템을 개발하는 다른 팀을 위한 것일 수도
시스템 테스팅과의 중요한 차이점
- 시스템 개발팀이 릴리스 테스팅의 책임을 지면 안됨
- 릴리스 테스팅은 시스템이 요구사항에 맞고 시스템의 고객에게 사용되기에 충분히 괜찮다는 것을
  보장하기 위한 확인 점검 프로세스
  - 시스템 테스팅은 버그 발견에 집중
시스템이 사용하기에 괜찮다는 것을 시스템의 공급자에게 확신시키는 것
테스트가 시스템 명세로부터 유도되는 블랙박스 테스팅 프로세스
- 시스템은 행동이 시스템의 입력과 연관된 출력을 조사하는 것만으로도 결정될 수 있는 블랙박스 취급

요구사항 기반 테스팅

좋은 요구공학의 일반적인 원칙 → 요구사항은 테스트 가능해야 함
검증 테스팅의 성격이 강함

시나리오 테스팅

시나리오를 만들어 시스템의 테스트 케이스를 개발하는 데 사용하는 릴리스 테스팅 접근법
시나리오 또는 사용자 스토리들은 요구공학 프로세스의 일부
- 시나리오 테스팅에 재사용할 수 있음
시나리오 테스팅은 이해당사자들에게 동기를 주어야 함

MentCare 시스템의 사용자 스토리

정신건강 관리 업무를 담당하는 간호사 A가 있다. 그의 역할 중 하나는 환자 가정을 방문하여 치료가 효과적인지, 약물치료의 부작용은 겪지 않는지 점검하는 것이다.
가정 방문일에 A는 Mencare 시스템에 로그인하여 당일의 가정 방문 일정과 방문할 환자의 요약 정보를 출력한다.
A의 PC에 방문 예정인 환자들의 기록을 다운로드하도록 요청하고 PC에 저장될 기록을 암호화할 키를 입력하도록 요구한다.
A가 방문할 환자 중 하나는 우울증 약으로 치료를 받고 있는 B이다.
B는 약물치료가 도움이 된다고 느끼지만 밤에 깨어있게 되는 부작용 있다고 믿는다.
A는 B의 기록을 찾고 암호를 풀기 위해 키를 입력하도록 요구받는다.
A는 처방된 약물을 점검하고 부작용에 대해 질의한다.
불면증은 알려준 부작용이므로 B의 문제를 기록하고 약물치료를 변경할 수 있게 병원에 방문할 것을 권한다.
B가 동의하고 A는 병원으로 돌아가서 진료 예약을 잡기 위해 B에게 전화해야 한다는 내용을 입력한다. B의 진료를 끝내고 기록을 다시 암호화한다.
진료 후, A는 병원으로 돌아가 방문했던 환자들의 기록을 데이터베이스에 업로드한다.
시스템은 A가 추적 정보를 위해 연락해야 하거나, 병원 예약을 잡아야 하는 환자들의 통화 목록을 생성한다.

시나리오에 기반한 기능 테스트

시나리오 기반하여 여러 기능의 테스트 가능
- 시스템 로그온에 의한 인증
- 특정 환자 기록을 노트북 PC에 다운로드와 업로드
- 가정 방문 일정
- 모바일 장치에서 환자 기록의 암호화와 복호화
- 기록 검색과 수정
- 부작용 정보를 유지하는 약물 데이터베이스 연결
- 전화 안내 시스템
시나리오 기반 접근법을 사용할 때 보통 같은 시나리오 안에서 여러 요구사항을 테스팅함

성능 테스팅

성능과 신뢰성과 같은 창발성에 의한 테스트
시스템이 의도된 부하를 처리할 수 있는지 확인하기 위해 설계되어야 함
다음의 두 가지 사항과 연관
- 시스템이 요구사항을 만족하는지 보여주는 것
- 시스템에 있는 문제와 결함을 발견하는 것
성능 요구사항 테스트를 위하여 운영 프로파일을 구성하여 할 수 있음
- 운영 프로파일 - 시스템이 처리할 작업의 실제 구성이 반영된 테스트들의 결합

스트레스 테스팅

시스템의 한계에 가까운 테스트를 설계하는 것
- 결함 발견의 효과적인 방법
- 실제 한계를 넘어서는 요청을 생성하여 시스템에 스트레스를 주는 것
두 가지 측면에서 도움
- 시스템의 장애 행동 테스트
- 시스템이 최대 부하가 걸렸을 때만 보이는 결함이 드러나게 함
네트워크를 기반으로 하는 분산 시스템과 특별히 관련
- 분산 시스템은 심한 부하가 있을 때 심각한 성능저하를 보임
- 스트레스 테스팅은 성능 저하가 언제 시작되는지 알 수 있게 해 줌

사용자 테스팅(고객 테스팅)

사용자나 고객이 입력을 제공하고 시스템 테스팅에 관한 의견을 내는 테스팅 프로세스의 한 단계
사용자 테스팅 세 가지 유형
- 알파 테스팅
  - 선택된 그룹의 소프트웨어 사용자들
    - 개발팀과 밀접하게 작업하여 소프트웨어의 초기 릴리스를 테스트
- 베타 테스팅
  - 소프트웨어의 릴리스를 더 큰 그룹의 사용자들에게 제공
    - 사용자들이 실험해 볼 수 있게 하고 발견한 문제를 시스템 개발자에게 알림
- 인수 테스팅
  - 고객이 시스템을 테스트
    - 시스템 개발자로부터 시스템을 인수하고 고객 환경에 배치해도 되는지를 결정하기 위함

알파 테스팅

소프트웨어나 앱 개발할 때 주로 사용
- 새로운 시스템 기능에 대한 정보를 빨리 얻기 위해 알파 테스팅 참여를 원할수도 있음
맞춤 소프트웨어 개발할 때도 사용 가능
애자일 개발 기법은 개발 프로세스에 사용자 참여를 주장

베타 테스팅

시스템의 초기 또는 완성되지 않은 릴리스를 평가하기 위한 목적
소프트웨어와 운영 환경 특성 간 상호 작용 문제를 발견하기 위해 사용
마케팅의 한 형태로 활용되기도 함

인수 테스팅

맞춤 시스템 개발의 고유한 부분
- 고객 자신의 데이터를 이용하여 시스템 테스트
- 시스템 개발자로부터 시스템 인수 결정

인수 테스팅 프로세스의 여섯 단계

인수 기준 정의
- 인수 기준은 시스템 계약의 일부가 되어야 하며 고객과 개발자에 의해 승인되어야 함
- 현실적으로 프로세스 초기에 기준을 정의하는 것이 어려울 수 있음
  - 상세한 요구사항 X, 개발 프로세스 중 확실히 변경될 것
인수 테스팅 계획 수립
- 인수 테스팅을 위한 자원, 시간, 예산을 결정하고 테스트 일정을 수집하는 것과 관련
인수 테스트 계획
- 요구사항의 필요한 적용 범위와 시스템 기능들의 테스트 순서를 다루어야 함
- 테스팅 프로세스에서의 리스크를 정의하고 리스크 완화에 관해 논의
인수 테스트 유도
- 시스템을 인수할 수 있는지 여부를 점검하도록 테스트가 설계되어야 함
  - 시스템의 기능적, 비기능적 특성을 모두 테스트하는 것이 목표
인수 테스트 실행
- 합의된 인수 테스트가 시스템에서 실행
- 사용자 테스팅 환경이 별도로 만들어져야 할 수 있음
- 이 프로세스를 자동화하는 것은 어려움
  - 최종 사용자와 시스템 간 상호작용을 테스팅하는 것이 포함될 수 있기 때문
테스트 결과 타협
- 인수 테스팅이 완료되고 시스템이 인도됨
시스템 거부/인수
- 개발자와 고객이 시스템이 인수되어야 할지 여부를 결정
- 시스템이 사용하기에 충분하지 않은 경우
  - 추가 개발 요구, 개발이 완료되면 인수 테스트를 반복

인수 테스팅 프로세스

계약과 관련된 문제라고 생각할 수 있음
계약 외의 문제와 연관되기도 함
- 고객이 가능한 바로 소프트웨어를 사용하기를 원할 수도
- 고객이 문제점과 관련 없이 소프트웨어를 인수하기를 원할 수도

애자일 기법에서의 인수 테스팅 프로세스

별도의 인수 테스팅 활동이 없을 수 있음
- 최종 사용자는 개발팀의 일부
- 사용자 스토리 관점에서의 테스트가 인수 테스트와 동일
개발팀에 속하지 않은 최종 사용자 집단 필요
- 인수 테스팅으로써, 평소 업무의 일부인 것처럼 시스템을 사용해야 함
시스템은 애자일 기법으로 개발하지만 별도의 인수 테스팅 필요

저작자표시 변경금지

소프트웨어 테스팅

소프트웨어 테스트 종류

프로그램 테스팅의 입출력 모델 및 테스트 과정

프로그래밍 테스팅의 한계

검증과 확인 프로세스

인스펙션과 리뷰

인스펙션과 테스팅

소프트웨어 인스펙션 장점

소프트웨어 인스펙션 단점

소프트웨어 테스팅 프로세스 모델

전통적인 테스팅 프로세스

상용 소프트웨어 시스템 테스팅의 3단계

소프트웨어 테스팅 프로세스

개발 테스팅

세 단계의 개발 테스팅

단위 테스팅

단위 테스팅의 어려움

단위 테스팅 및 테스트 자동화

모형 객체를 사용한 단위 테스팅

분할 테스팅 - 효과적인 테스트 케이스 선정 전략

동등 분할

가이드라인을 활용한 테스팅 - 효과적인 테스트 케이스 선정 전략

일반적인 테스팅 가이드라인

컴포넌트 테스팅

인터페이스 테스팅

인터페이스 종류

인터페이스 오류 및 종류

인터페이스 테스팅을 위한 지침

시스템 테스팅

상호 작용 테스팅

기상 데이터 수집 시퀀스 다이어그램으로부터의 테스트 케이스

테스팅 정책

테스트 주도개발(TDD)

기본적인 TDD 프로세스

테스트 주도 개발의 특징

테스트 주도 개발의 장점

회귀 테스팅

릴리스 테스팅

요구사항 기반 테스팅

시나리오 테스팅

MentCare 시스템의 사용자 스토리

시나리오에 기반한 기능 테스트

성능 테스팅

스트레스 테스팅

사용자 테스팅(고객 테스팅)

알파 테스팅

베타 테스팅

인수 테스팅

인수 테스팅 프로세스의 여섯 단계

인수 테스팅 프로세스

애자일 기법에서의 인수 테스팅 프로세스

검색 태그

티스토리툴바