노년코딩

2.1 소프트웨어 개발 모델

▶ 테스팅 vs. 소프트웨어 개발

 - 서로 밀접하게 연계

 - 개발 수명 주기에 기반하여 테스팅 접근법을 다르게 적용

2.1.1 V-모델(순차적 개발 모델)

▶ 개발 산출물(Work product)

 - 비즈니스 시나리오 또는 유즈 케이스, 요구사항 명세, 설계 문서나 코드 --> 테스트 베이시스(Basis)로 사용

▶ V-모델의 역할

 - 각각의 개발 단계에서 테스팅을 접근하는 방법을 개략적으로 이해하기 쉽게 모델화하여 보여주는 것.

 - V-모델을 통해 테스팅 기본 개념 이해

   >> 테스트 레벨의 의미 이해

   >> 개발 초기 단계에서 테스팅을 수행하다는 것의 의미

   >> 결함 예방 차원에서 테스팅이 의미하는 바 이해

   >> V & V (Verification(검증) and Validation(확인))의 의미 (검증과 확인 구분가능 해야 돼.)

▶ 테스트 레벨의 의미

 - 컴포넌트 / 단위 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅

   >> 테스트 레벨에 따라 테스트 전략, 테스트 기법, 테스트 수행 주체, 테스트 완료 기준 등이 달라짐.

   >> 테스트 레벨은 독립적.

▶ 개발 초기 단계에서 테스팅을 수행하다는 것의 의미

 - 개발 산출물을 리뷰 형태로 검토하면서 결함을 발견하는 정적 테스팅을 의미 (문서만으로 발견)

   >> 결정 테이블 테스팅, 상태전이 테스팅, 유즈 케이스 테스팅 등

 - 개발 초기의 테스팅을 통해서 후반부에서 발생할 비용을 줄임.

▶ 초기에 테스트 설계를 통해 결함을 사전에 예방 ★

2.1.2 반복적 - 검증적 개발 모델

▶ 반복적 & 점진적 개발 모델 

▶ 폭포수 개발 모델 VS. 반복적 & 점진적 개발 모델 

>> 폭포수 모델은 코딩단계까지 리스크가 남아잇기 때문에 거의 쓰지 않아.

>> 반복적 & 점진적 개발 모델이 안정성도 더 높음. -리스크를 처음부터 수정해기 때문.(그대신 초반에 더딤.)

2.1.3 개발 생명 주기 모델에서의 테스팅

▶ 성공적인 테스팅을 위한 조건

   >> 모든 개발 활동은 이에 상응하는 테스트 활동을 동반.

   >> 각 테스트 레벨은 그 레벨에 맞는 특정한 목적이 있음.

   >> 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되는 개발 활동 동안에 시작.

   >> 개발 생명주기 동안에 개발 산출물의 초안이 작성되면, 테스터는 이러한 문서를 리뷰하는 활동에 참가.

▶ 테스팅 레벨 조절

 - 테스팅은 프로젝트나 시스템 아키텍처의 성격에 따라 재조정하거나 합쳐질 수 있음.

2.2 테스트 레벨(Test Levels)

- 테스트 레벨의 일반적인 구분

   >> 단위, 통합, 시스템, 인수.

▶ 테스트 레벨에 따라 독립적으로 정의할 수 있는 사항

 - 테스트 레벨의 일반적인 목표(목적)

 - 테스트 케이스를 도출해 내는 데 참조되는 개발 산출물(베이시스)

 - 테스트 대상(테스트할 그 무엇)

 - 발견된 전형적인 결함과 장애

 - 테스트 하네스(드라이버/ 스텁) 필요 여부와 툴 지원의 필요성

 - 상세한 테스트 접근법

 - 테스트 수행 주체 또는 조직  

2.2.1 컴포넌트 테스팅

▶ 단위 테스트(Unit Test)

 - 테스트가 가능한 최소 단위로 나누어진 소프트웨어 모듈, 프로그램, 객체, 클래스 등에서 결함을 찾고 그 기능을 검증 ->대부분 개발자가 하는데 본인이 직접 코드 짠 경우 동료 개발자가 함. 

   >> 소프트웨어 각각의 단위를 다른 부분과 연계성을 고려하지 않고 격리해서 독립적으로 테스트 수행.

   >> 스텁, 드라이버, 시뮬레이터 사용.

 - 일반적으로 프로그램 소스코드를 대상 -- > 구조기반(화이트 박스)

 - 컴포넌트 테스트의 일반적인 목적

   >> 기본 경로 확인

   >> 모든 오류 처리 경로 확인

   >> 컴포넌트 내의 인터페이스 확인

   >> 로컬 데이터 확인, 데이터의 경계값 확인

2.2.2 통합 테스팅(Integration testing)

▶ 통합 테스팅

 - 컴포넌트 간에 인터페이스를 테스트하는 것은 물론 OS, 파일 시스템, 하드웨어 또는 시스템 간 인터페이스와 같은 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트.

 - 컴포넌트 통합 테스트

 - 시스템 통합 테스트

 - 통합 테스팅은 기능적 특성은 물론 비기능적 특성(성능, 연결성 등)을 테스팅 수행.

 - 통합 테스팅 설계는 기능적 접근법, 구조적 접근법을 모두 사용.

   >> 통합 그 자체에만 집중하는 오류 주의!!!!

2.2.3 시스템 테스팅(System testing)

▶ 시스템 테스팅

 - 개발 프로젝트 차원에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트

-- > 리스크 최소화를 위해 실제 환경과 유사한 상태.

 - 시스템 관련 고객의 요구사항이 완벽하게 실행되는지를 테스트.

 - 테스트 베이시스(개발 산출물) 이용.

   >> 리스크 분석서, 요구사항 명세, 비즈니스 프로세스, 유즈 케이스, 기타 비즈니스 레벨의 시스템 동작 명세, os 및 시스템 리소스와 상호작용 명세.

 - 기능 및 비기능 요구사항 모두 검증

   >> 기능적 테스트 : 명세기반(블랙박스) 기법으로 수행 - 문서 기반 테스팅( 테스트 베이시스(개발 산출물) 이용).

   >> 비기능적 테스트 : 기능적 외의 나머지 부분에 대한 요구사항 검증.

 - 일반적으로 독립적인 테스트 팀이 수행 --> 검수 테스팅이라 함 (이후 출시)

2.2.4 인수 테스팅(Acceptance testing)

▶ 인수 테스팅

 - 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 확신을 얻는 것. --> 결함 발견이 목적이 아님. (시스템이 잘 돌아가는지 확인, 결함은 이전 테스팅에서 끝내야 돼)

 - 품질에 대한 확신.

 - 시스템을 베포 하거나 실제 사용할 준비가 되었는지 평가.

 - 인수 테스팅 이후에 대규모 시스템 간의 통합 테스트 수행.

   >> 인스테스팅이 반드시 최종 단계의 테스팅은 아님.

 - 인수 테스팅은 프로젝트 전 개발 과정에서 수행(프로젝트 진행하면서 계속 진행).

   >> 상용(COTS) SW제품은 설치, 통합하면서 테스팅.

   >> 컴포넌트의 사용성에 대해서는 컴포넌트 테스팅 동안 실행 가능.

   >> 새로운 기능 개선에 대해서는 시스템 테스팅 전에 실행 가능.

▶ 인수 테스팅 형태

 - 사용자 인스 테스팅(비즈니스 사용자가 확인)

 - 운영상의 테스팅

   >> 백업/복원, 재난 복구, 사용자 관리, 유지보수 작업, 보안 취약성 점검

 - 계약 인수 테스팅과 규정 인수 테스팅

   >> 맞춤식 - 개발 SW가 계약상의 인수 통과 조건/ 규정을 준수하는지 확인.

 - 알파 테스팅과 베타(필드) 테스팅 --> 고객의 피드백

(알파 테스트 : 회사의 다른 팀 테스트 / 베타 테스트: 외부 고객들이 테스트)

   >> 알파 테스트 : 개발 조직 내에서 고객에 의해 수행

      -고객 사이트로 이동하기 전에 개발 완료 후 테스팅인 공장 인수 테스팅을 의미

   >> 베타 테스트 : 실제 환경에서 사용자 혹은 잠재 고객에 의해 수행.

      - 고객 사이트로 이동한 후에 테스팅하는 사이트 인수 테스팅을 의미.

2.3 테스트 유형(Test types)

▶ 테스트 유형은 테스트 목적에 따라 구분

1. 소프트웨어가 수행하는 기능에 대한 테스팅.

2. 호환성, 신뢰성, 사용성과 같은 비기능적인 품질 특성 테스팅.

3. 소프트웨어나 시스템의 구조나 아키텍처에 대한 테스팅.

4. 변경 내용에 관련된 테스팅(확인 테스팅, 리그레션 테스팅)

- 기능적, 구조적 테스팅은 SW 모델 활용.

   >> 기능적 테스팅 --> 명세 기반 기법(블랙박스 테스팅) -프로세스 흐름 모델, 상태 전이 모델, 평문 언어 명세 이용.

   >> 구조적 테스팅 --> 구조기반 기법(화이트박스 테스팅 (개발능력 반드시 필요)) - 제어흐름 모델, 메뉴 구조 모델 이용.

2.3.1 기능 테스팅( Functional testing)

▶ 기능 테스팅

 -  문서화되어 있거나 테스터가 알고 있는 기능과 특징, 그리고 그것들과 특별한 시스템과의 상호 운용성을 수행하며 모든 테스트 레벨에서 수행 --> 시스템이 수행하는 무엇(what)을 의미.

 - 명세 기반 기법(블랙박스 테스팅)을 이용해서 테스트 조건과 테스트 케이스를 도출하고 소프트웨어의 외부적인 행동을 고려.

▶ 보안성 테스팅

 - 악의적인 코드(바이러스 등)와 같은 외부로부터의 위협을 감지해 내는 것과 관련이 있는 기능을 확인.

   >> 보안 정책 확인, 트랩도어(진입점) 파악, 보안 관련 평가(가용성, 무결성, 기밀성, 부인 방지 등).

2.3.2 비기능 테스팅

▶ 소프트웨어 제품 특성 테스팅

 - 어떻게(How) 동작하는 가를 테스팅

   >> 성능 테스팅, 부하 테스팅, 스트레스 테스팅, 사용성 테스팅, 유지보수성 테스팅, 신뢰성 테스팅 그리고 이동성 테스팅 등을 포함한 개념.

 - 전문적 지식인과 도구 필요.

 - 모든 테스트 레벨에서 수행.

 - 다양한 척도 또는 비율로 정량화 가능한 SW품질 특성 측정. - 무조건 수치로 표현되야 돼

 - 소프트웨어 품질 모델 참조(ISO/IEC 9126)

   >> 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성(6가지 척도) 이라는 품질 특성으로 분류.

2.3.3 구조적 테스팅(Structural testing)

▶ 구조 테스팅

 - 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보장성 또는 충분함을 측정하는 것이 목적인 테스트 유형.

 - 커버리지

   >> 시스템 또는 SW구조가 테스트 스위트(test suite)에 의해 테스트된 정도.

   >> 테스팅의 충분함을 측정(100%로 표시 --> 추가 테스트 설계)

 - 모든 테스트 레벨에서 수행 가능

   >> 구조적 테스트 기법(화이트 박스 테스트)

   >> 시스템 아키텍처에 기반을 두고 수행

   >> 비즈니스 모델이나 메뉴 구조(인수 or 시스템 테스트 레벨)

2.3.4 확인/ 리그레션 테스팅

▶ 확인(confirmation/re- testing) 테스팅

 - 결함이 발견되고 수정된 후에 SW는 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트하는 경우.

   >> 결함을 수정하기 위한 디버깅은 테스팅이 아닌 개발 활동.

▶ 리그레션(regression) 테스팅

 - 이미 테스트된 프로그램의 테스팅을 반복.

 - 결함 수정 이후 변경의 결과로 새롭게 만들어지거나 이전 결함으로 인해 발견되지 않았던 다른 결함을 발견.

 - SW 또는 환경이 변경되면 실시.

 - 모든 테스트 레벨에서 수행.

 - 리그레션 테스팅 -- > 반복적인 성향 -- > 자동화 대상.

2.4 유지보수 테스팅

▶ 유지보수 테스팅

 - 이미 운영되고 있는 시스템에서 수행되며, SW나 시스템이 변경, 단종되었거나 마이그레이션 될 때 발생.

 - 변경에 대한 유지 보수 테스팅.

   >> 계획된 개선을 위한 변경, 수정에 의한 변경과 환경의 변경.

   >> 계획된 OS, DB 업그레이드, OS의 새로 드러난 취약점 패치.

 - 마이그레이션에 대한 유지보수 테스팅.

   >> 변경된 SW에 대한 운영 테스트 + 새로운 환경에서의 운영 테스트

 - 변경된 것 + 변경되지 않은 시스템 요소(영향도 분석 후)에 대한 방대한 리그레션 테스팅 고려.

 - 범위는 변경 범위 및 기존 시스템의 리스크와 크기 고려.  

(참고)

테스트 정책

▶ 소프트웨어 테스팅에 대한 조직의 철학을 정의한 문서

▶ 테스팅 관련 최상위 레벨 문서(일반적으로 간단한 형태)

 - 테스팅 정의

 - 테스팅 미션 및 목적

 - 테스팅 조직의 핵심 역할

 - 고객 만족을 위한 테스팅 관점과 시각

 - 테스트 프로세스 개선

소프트웨어 테스트 윤리강령

▶ 공공성 우선 : 공공의 이익을 위해

▶ 고객과 고용주의 이익 고려 : 고객, 고용주, 공공의 이익 고려

▶ 전문성 있는 결과물 : 표준화된 전문적 산출물

▶ 판단의 독립성 : 판단에 무결성과 독립성 보장

▶ 윤리적 관리 : 윤리적으로 테스팅을 관리해야 함

▶ 직업 의식 : 공공의 이익에 부합하도록 무결성과 신뢰 제공

▶ 동료 의식 : 동료를 공정하게 대하고 개발자와 협력을 촉진

▶ 자기 조직 : 전문성을 확보하고 윤리적 사고로 활동을 함   

테스터 사명

▶ 책임감 : 고객의 입장에서 대변하고 적극적으로 리스크 관리를 함

▶ 태도 : 끊임없는 호기심과 열정으로 창의적이고 혁신적인 테스팅을 위해 노력함

▶ 프로의식 : 테스팅을 사랑하고 자긍심을 갖고 끊임없는 학습으로 전문성을 확보함

▶ 커뮤니케이션 : 개발자는 완성도가 높은 제품을 함께 만들어가는 동반자로 누구에게나 배우려는 열린 마음 지향