[Part 2] 소프트웨어 수명주기와 테스팅

- 용어 - 

인수 테스팅 - 시스템이 사용자의 필요 및 요구사항, 비즈니스 프로세스 측면에서 인수 조건을 만족하는지 확인하고 사용자, 고객, 기타 권한을 지닌 사람이 시스템의 인수 여부를 결정하기 위해 수행하는 공식 테스팅 

테스트 인프라 - 테스트 환경, 테스트 도구, 사무환경 및 절차로 구성된 테스트를 수행하는 데 필요한 조직 산출물

2.1 소프트웨어 개발 수명주기 모델

 

2.1.1 소프트웨어 개발과 소프트웨어 테스팅

 모든 소프트웨어 개발 수명주기 모델에 적용하기 좋은 테스팅의 특성

• 모든 개발 활동은 그에 사응하는 테스트 활동이 있다.
• 각 테스트 레벨은 그 레벨에 맞는 구체적인 목적을 가진다.
• 주어진 테스트 레벨에 맞는 테스트 분석과 설계는 상응하는 개발 활동이 이루어지고 있는 동안 시작해야 한다.
• 테스터가 요구사항과 설계의 정의와 개선을 위한 대화에 참여하고, 작업 산출물(ex 요구사항, 설계 등)의 초안이 나오는 즉시 리뷰에 참여한다.

어떤 소프트웨어 개발 수명주기 모델을 선택하더라도 테스팅을 초기에 시작하면 시간과 비용을 절약할 수 있다는 테스트 원리에 따라, 테스트 활동은 수명주기 초반에 시작해야 한다.        

이 실라버스에서 대표적인 소프트웨어 개발 수명주기 모델

• 순차적 개발 모델 - 개발 프로세스의 모든 단계는 이전 단계가 완료될 때 시작돼야 함. 폭포수 모델(순차적 - 요구사항 분석 , 설계, 코딩, 테스팅) ,V-모델 - 각 개발 단계에 테스트 레벨을 부여함. 각 테스트 레벨의 테스트 실행이 순차적으로 이루어져 있음.
• 반복적 개발 모델 - 기능 집합을 종종 고정된 기간의 일련의 주기 안에서 같이 명시, 설계, 구축, 테스트할 때 발생. 반복 주기에는 전체 프로젝트 범위에 대한 변경이나 기존 반복주기 동안 개발한 기능에 대한 수정 포함.
• 점진적 개발 모델 - 요구사항 정의, 시스템의 설계, 구축, 테스팅을 조각으로 나눠서 진행. 소프트웨어 기능은 점진적으로 늘어남.

반복적 개발 모델 대표적인 예

• 래셔널 통합 프로세스
• 스크럼
• 칸반
• 나선형

*2.2 테스트 레벨 *

 테스트 레벨이란 함께 분류되고 관리되는 테스트 활동의 집합을 지침.

 실라버스에서 다루고 있는 테스트 레벨이며 구체적인 목적/ 테스트 케이스를 도출하기 위해 참고하는 테스트 베이시스/ 테스트 대상/ 일반적인 결함과 장애/ 구체적인 접근법 -> 같은 특성을 기준으로 분류. 

• 컴포넌트 테스팅(유닛)
• 통합 테스팅
• 시스템 테스팅
• 인수 테스팅

2.2.1 컴포넌트 테스팅

컴포넌트 테스팅의 목적 - 개별적으로 테스트할 수 있는 컴포넌트에 초점 

• 리스크 완화
• 컴포넌트의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단
• 컴포넌트 품질 수준에 대한 자신감 획득
• 컴포넌트에 존재하는 결함 발견
• 다음 단계로의 결함 전이 방지

테스트 베이시스 -컴포넌트 테스팅의 테스트 베이시스로 사용할 수 있는 대표적인 작업 산출물 

• 상세 설계
• 코드
• 데이터 모델
• 컴포넌트 명세

테스트 대상 

• 컴포넌트, 단위, 모듈
• 코드 및 데이터 구조
• 클래스
• 데이터베이스 모듈

* 대표적인 결함과 장애

• 잘못된 기능(설계 명세의 설명과 다름)
• 데이터 흐름 문제
• 잘못된 코드 및 논리

2.2.2 통합 테스팅

통합 테스팅의 목적 - 컴포넌트나 시스템 간의 상호작용에 초점을 맞춰서 진행한다.

• 리스크 완화
• 인터페이스의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단
• 인터페이스 품질 수준에 대한 자신감 획득
• 결함 발견
• 다음 단계로의 결함 전이 방지                                                                                                           

통합 테스팅 - 컴포넌트 통합 테스팅 , 시스템 통합 테스팅

• 컴포넌트 통합 테스팅 - 통합된 컴포넌트 간의 상호운용성과 인터페이스에 초점
• 시스템 통합 테스팅 - 시스템, 패키지, 마이로 서비스 간의 상호운용성과 인터페이스에 초점

테스트 베이시스

• 소프트웨어 및 시스템 설계
• 시퀀스 다이어그램
• 인터페이스 및 통신 프로토콜 명세
• 유스 케이스
• 컴포넌트나 시스템 레벨의 아키텍처
• 워크플로우
• 외부 인터페이스 정의서

테스트 대상

• 서브시스템
• 데이터베이스
• 인프라
• 인터페이스
• APls
• 마이크로 서비스

일반적인 결함과 장애

- 컴포넌트 통합 테스팅

• 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩
• 잘못된 인터페이스 콜 순서나 타이밍
• 인터페이스 불일치 
• 컴포넌트 간의 통신 장애
• 컴포넌트 간의 통신 실패 처리 누락 및 오류
• 컴포넌트 간 주고받는 데이터의 의미, 단위, 경계에 대한 잘못된 가정

- 시스템 통합 테스팅

• 시스템 간의 일관적이지 않은 메시지 구조
• 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩
• 인터페이스 불일치
• 시스템 간의 통신 장애
• 시스템 간의 통신  실패 처리 누락 및 오류
• 시스템 간 주고받은 데이터의 의미, 단위, 경계에 대한 잘못된 가정
• 필수 보안 규정 준수 실패

2.2.3 시스템 테스팅

시스템 테스팅 목적 - 전체 시스템 또는 제품 동작이나 능력에 관심을 가지며, 시스템이 수행할 엔드-투-엔드 작업과 그런 작업을 수행할 때 나타나는 비기능 동작을 고려하는 경우가 많음.

• 리스크 완화
• 시스템의 기능/비기능 동작이 설계 및 명시된 대로 이루어지는 검증
• 완성된 시스템이 기대한 대로 동작하는지 확인
• 전체 시스템 품질에 대한 자신감 획득
• 결함 발견
• 결함이 상위 테스트 레벨이나 생산 단계로의 전이 방지

테스트 베이시스

• 시스템 및 소프트웨어 요구사항 명세)(기능/비기능)
• 리스크 분석 보고서
• 유스케이스
• 에픽과 사용자 스토리
• 시스템 동작 모델
• 상태 다이어그램
• 시스템 및 사용자 메뉴얼

테스트 대상

• 애플리케이션
• 하드웨어/소프트웨어 시스템
• 운영 시스템
• 테스트 대상 시스템
• 시스템 설정과 설정 데이터

결함과 장애

• 잘못된 연산
• 시스템의 잘못되거나 예상치 못한 기능/비기능 동작
• 시스템 내 잘못된 제어 및 데이터 흐름
• 엔드-투-엔드 기능 작업 수행 실패
• 시스템 환경에서 시스템의 정상 동작 실패
• 시스템 및 사용자 메뉴얼대로의 시스템 동작 실패

2.2.4 인수 테스팅

인수 테스팅의 목적 - 시스템 테스팅과 마찬가지로 인수 테스팅도 전체 시스템 또는 제품의 동작이나 능력에 초점을 두고 진하는 경우 

• 전체 시스템의 품질에 대한 자신감 획득
• 완성된 시스템이 기대한 대로 동작하는지 확인
• 시스템의 기능/비기능 동작이 명세대로 동작하는지 검증

인수 테스팅 - 사용자 인수 테스팅/ 운영 인수 테스팅/ 계약 및 규제 인수 테스팅/ 알파 및 베타 테스팅

 

사용자 인수 테스팅 - 일반적으로 실제 또는 시뮬레이션된 운영 환경에서 예정된 사용자가 사용하기에 얼마나 적합한지 확인하는데 관심을 둔다.

 

운영 인수 테스팅 - 운영자 또는 시스템 관리 직원에 의해 수행되는 시스템 인수 테스팅(시뮬레이션된) 생산 환경에서 이루어지는 경우가 많다. 가장 중요한 목적은 운영자 또는 시스템 관리자가 비록 예외적이고 어려운 조건에서라도 운영 환경에서 사용자를 위해 시스템을 정상적으로 유지할 수 있다는 자신감을 얻는 것이다. 테스트는 운영 측면에 집중돼 있으며, 다음을 포함할 수 있다.

• 백업 및 복원 테스팅
• 설치, 삭제, 업그레이드
• 긴급 복구
• 사용자 관리
• 유지보수 작업
• 데이터 로딩 및 이관 작업
• 보안 취약점 확인
• 성능 테스팅

계약 및 규제 인수 테스팅 - 주문 개발 소프트웨어의 생산을 위한 계약서에 명시된 인수 조건을 가지고 수행. 인수 조건은 모든 계약 당사자가 계약에 동의할 때 정의. 계약 인수 테스팅은 사용자나 독립적인 테스터가 수행하는 경우가 많음.

규제 인수 테스팅은 정보, 법적, 안전 규제 등과 같이 준수해야 하는 모든 규제를 가지고 수행. 규제 인수 테스팅은 사용자나 독립적인 테스터가 수행하는 경우가 많음. 규제 기관이 결과에 대한 실사나 감사를 진행하기도 한다.

계약 및 규제 인수 테스팅의 가장 중요한 목적은 계약이나 규제 준수에 대한 자신감 획득.

 

알파 및 베타 테스팅 - 소프트웨어 제품을 시장에 출시하기 전에 기존 혹은 신규 사용자, 고객, 운영자 등으로부터 피드백을 받기 원하는 사용 소프트웨어 개발자가 사용하는 경우가 많다. 

알파 테스팅 - 개발 조직의 현장에서 개발팀이 아닌 신규 혹은 기존 고객이나 운영자, 독립적 테스트팀이 수행.

베타 테스팅 - 신규 혹은 기존 고객이나 운영자가 자신의 환경에서 수행.

목적 - 신규 혹은 기존 고객이나 운영자가 시스템을 일반적인 조건과 운영환경에서 사용해 자신의 목적을 최소한의 어려움, 비용, 리스크 등으로 완수할 수 있다는 자신감을 획득. 또 다른 목적은 시스템을 사용할 조건 및 환경과 관련된 결함의 발견일 수 있음.

 

테스트 베이시스

• 비지니스 프로세스
• 사용자 또는 비즈니스 요구사항
• 규제, 법적 계약, 표준
• 유스케이스 및 사용자 스토리
• 시스템 요구사항
• 시스템 또는 사용자 문서
• 설치 절차
• 리스크 분석 보고서

일반적인 테스트 대상

• 테스트 대상 시스템
• 시스템 설정과 설정 데이터
• 완전히 통합된 시스템의 비지니스 프로세스
• 복원 시스템이나 비즈니스 연속성 및 긴급 복구 테스팅을 위한 핫 사이트
• 운영 및 유지보수 프로세스
• 양식
• 보고서
• 기존 및 전환된 생산 데이터

일반적인 결함과 장애

• 비즈니스나 사용자 요구사항을 충족하지 못하는 시스템 워크플로우
• 잘못 구현된 비즈니스 규칙
• 계약 혹은 규제 요구사항을 충족하지 못하는 시스템
• 보안 취약성, 많은 부하가 걸렸을 떄 성능 효율성 저하, 지원 대상 플랫폼상에서의 잘못된 운영 등과 같은 비기능 장애

2.3 테스트 유형

테스트 유형 - 특정 테스트 목적을 위해 소프트웨어 시스템이나 시스템의 일부 특정 속성을 테스트하는 활동의 집합

• 완전성, 정확성, 적합성 등과 같은 기능 품질 특성 평가
• 신뢰성, 성능 효율성, 보안성, 호환성, 사용성 등과 같은 비기능 품질 특성 평가
• 컴넌트나 시스템의 아키텍처 및 구조가 정확하고 완전하며 명시된 것과 일치하는지 평가
• 수정의 효과 평가. 예를 들어, 결함이 수정됐는지 확인(확인테스팅)하고 소프트웨어나 환경의 변화로 인해 동작에 의도하지 않은 변화가 없는지(리그레션 테스팅) 평가 

2.3.1 기능 테스팅 - 시스템이 수행해야 하는 기능을 평가하기 위한 테스트를 포함. 기능이란 시스템이 해야 하는 그 "무엇"을 애기

기능 테스팅이 얼마나 철저하게 수행 됐는지 기능 커버리지를 통해 측정할  수 있다. 기능 커버리지란 어떤 기능이 테스트에 의해 어느정도 실행됐는지를 말하며, 커버되고 있는 요소 유형에 대한 백분율로 표기.

 

2,3,2 비기능 테스팅 - 시스템의 비기능 테스팅은 사용성, 성능 효율성 또는 보안성과 같은 시스템 특성을 평가. 비기능 테스팅이란 시스템이 "얼마나 잘" 동장 하는지에 대한 테스팅을 말함. 기능 테스팅 처럼 모든 테스트 레벨에서 수행 가능. 비기능 테스팅은 조기에 할수록 좋음.

 

2.3.3 화이트박스 테스팅 - 시스템의 내부 구조나 구현을 기반으로 테스트를 도출. 내부 구조로는 코드, 아키텍처, 워크플로우, 시스템 내 데이터 플로우 등이 있음.

화이트박스 테스팅이 얼마나 철저하게 이루어졌는지 구조 커버리지를 통해 측정.

구조 커버리지란 특정 구조 요소가 테스트에 의해 어느 정도 실행됐는지를 말하며, 커버되고 있는 요소 유형에 대한 백분율로 표기.

 

2.3.4 변경 관련 테스팅 - 결함을 수정하고자 했든 또는 기능을 추가하거나 개선하기 위해서 했든 시스템이 변경되면, 해당 변경이 결함을 제대로 수정했는지, 기능을 올바르게 구현했는지 또 예상하지 못한 부작용이 발생하지 않았는지 확인하기 위한 테스팅을 수행할 필요가 있음.

• 확인 테스팅 : 결함이 수정된 후 이 결함으로 인해 불합격됐던 모든 테스트 케이스를 새로운 소프트웨어 버전에서 재실행할 수 있음. 확인 테스팅의 목적은 원래 제대로 결함을 제대로 수정했는지 확인하는 것이다.
• 리그레션 테스팅 - 코드의 특정 부분에 대한 변경이 무언가를 수정하기 위해서거나 또는 다른 목적이든 관계없이 이런 변경은 의도치 않게 코드의 다른 부분에 영향을 줄 수 있다. 리그레션 테스팅은 이런 의도하지 않은 부작용을 발견하기 위한 테스트를 수행.

확인 테스팅과 리그레션 테스팅은 모든 테스트 레벨에서 수행 가능

 

2.4 유지보수 테스팅 - 소프트웨어와 시스템이 생산 환경으로 배포되고 나면 유지보수가 필요. 배포된 소프트웨어와 시스템에 대한 다양한 변경은 거의 필연적으로 발생.

2.4.1 유지보수가 필요한 상황 - 유지보수의 계기

• 개선을 위한 변경 , 계획된 확장(릴리스기반), 수정 혹은 긴급 변경, 운영 환경 변경, 상용 소프트웨어 업그레이드, 결함 및 취약성을 위한 패치 등.
• 이관을 위한 변경, 하나의 플랫폼에서 다른 플랫폼으로 이관할때 다른 ㅇ어플의 데이터를 위한 데이터 전환 테스트 등.

 

-참조 실라버스