2. 소프트웨어 개발 수명주기와 테스팅

2.1.1 SW 개발과 테스팅(SW 개발 수명주기에서의 SW 개발 활동과 테스트 활동의 관계를 설명할 수 있다.)

---

모든 SW 개발 수명주기 모델에 적용하기 좋은 테스팅의 특성

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

 

SW 개발 수명주기 모델

	특징	종류
순차적 개발 모델	개발의 모든 단계는 이전 단계가 완료될 때 시작해야 한다. 완성된 기능 세트를 포함한 SW를 배포할 수 있지만 배포까지 많은 기간이 걸린다.	폭포수 모델: 요구사항 분석, 설계, 코딩, 테스팅이 순차적으로 이루어 진다. 테스팅은 개발 활동이 끝난 후 테스트가 이루어 진다. V-모델 : 각 개발 단계에 맞는 테스트 레벨을 부여하여 조기 테스팅을 구현
점진적 개발 모델	시스템의 설계, 구축, 테스팅을 조각으로 나눠서 진행
반복적 개발 모델	개발 주기를 반복적으로 하여 사용 가능한 SW를 며칠 만에 전달 가능	래셔널 통합 프로세스 : 각 반복 주기가 상당히 길고 기능 증분도 큼 스크럼 : 각 반복 주기가 짧고 기능 증분도 작음 칸반 : 반복 주기가 고정 or 고정x인 경우가 있음, 주기 완료 후 개선 사항 전달 나선형 : 실험적인 증분을 생성하여 개발 과정에서 수정하거나 폐기함

 

2.1.2 정황에 따른 SW개발 수명주기 모델(SW개발 수명주기 모델을 정황과 제품 특성에 따라 수정하는 이유 식별 가능)

---

SW 개발 생명주기 모델은 프로젝트의 정황과 제품 특성에 따라 선택하고 적용해야 함

ex) 안정 중심의 브레이크 제어 vs 속도 중심의 내부 sw

 

SW 개발 모델이 프로젝트 및 제품 특성의 맥락에 맞게 조정 되어야 하는 이유

• 시스템의 제품 리스크의 차이(복잡하거나 간단한 프로젝트)
• 많은 사업부가 프로젝트나 프로그램의 일부일 수 있다.(순차적 및 애자일의 조합)
• 제품의 짧은 출시 기간(테스트 레벨에서 테스트 유형의 통합 및 테스트 레벨 병합)

 

2.2 테스트 레벨(각 테스팅을 항목별로 구분, 비교 가능)

---

	컴포넌트 테스팅	통합 테스팅	시스템 테스팅	인수 테스팅
개념	테스트가 가능한 최소 단위로 나누어진 SW 내에서 결함을 찾고 기능을 검증	컴포넌트간의 인터페이스를 테스트 하는 것은 물론 os, 파일시스템 등 다른 부분과 상호 연동하는 동작 테스트	개발 프로젝트 범위에서 정의 된 전체 시스템 또는 제품의 동작에 대해 테스트 하는 것	시스템을 사용하는 고객, 사용자가 전달하여 테스팅을 구현하는 테스트. 관계자의 참여도 가능
목적	리스크 완화 기능, 비기능 동작이 설계, 명세와 일치 판단 품질 수준에 대한 자신감 획득 결함 발견 다음 단계로 결함 전이 방지	리스크 완화 기능, 비기능 동작이 설계, 명세와 일치 판단 품질 수준에 대한 자신감 획득 결함 발견 다음 단계로 결함 전이 방지	리스크 완화 기능, 비기능 동작이 설계, 명세와 일치 판단 품질 수준에 대한 자신감 획득 결함 발견 다음 단계로 결함 전이 방지 시스템이 기대한 대로 동작하는지 확인	품질 수준에 대한 자신감 획득 기능, 비기능 동작이 설계, 명세와 일치 판단 완성된 시스템이 기대한 대로 동작 확인
테스트 베이시스	상세 설계 코드(객체, 클래스) 데이터 모델 컴포넌트 명세	소프트웨어 및 시스템 설계 시퀀스 다이어그램 인터페이스 및 통신 프로토콜 명세 유스케이스 컴포넌트나 시스템 레벨의 아키텍처 워크플로우 외부 인터페이스 정의서	시스템, 소프트웨어 요구사항 명세 (기능/비기능) 리스크 분석 보고서 유스케이스 에픽(epic)과 사용자 스토리 시스템 동작 모델 상태 다이어그램 시스템 및 사용자 매뉴얼	비즈니스 프로세스 사용자 또는 비즈니스 요구사항 규제, 법적 계약, 표준 유스케이스 및 사용자 스토리 시스템 요구사항 시스템, 사용자문서 설치 절차 리스크 분석 보고서 백업 및 복원 절차 긴급 복구 절차 비기능 요구사항 운영 문서 배포 및 설치 지침 성능 목표
대상	컴포넌트, 단위, 모듈 코드 및 데이터 구조 클래스 데이터베이스 모듈	서브시스템 데이터베이스 인프라 인터페이스 APIs 마이크로서비스	애플리케이션 하드웨어/소프트웨어 시스템 운영 시스템 테스트 대상 시스템 시스템 설정과 설정 데이터	테스트 대상 시스템 시스템 설정과 설정 데이터 완전히 통합된 시스템의 비즈니스 프로세스 복원 시스템, 비즈니스 연속성, 복구 테스팅 목적 사이트 운영 및 유지보수 프로세스 양식 보고서 기존 및 전환된 생산 데이터
결함과 장애	잘못된 기능 데이터 흐름 문제 잘못된 코드 및 논리	잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩 잘못된 인터페이스 콜 순서나 타이밍 인터페이스 불일치 컴포넌트 간의 통신 장애 컴포넌트 간의 통신 실패처리 누락 및 오류 컴포넌트 간 주고 받는 데이터의 의미, 단위, 경계에 대한 잘못된 가정	잘못된 연산 시스템의 잘못되거나 예상치 못한 기능/비기능 동작 시스템 내 잘못된 제어 및 데이터 흐름 엔드-투-엔드 기능 작업 수행 실패 시스템 환경에서 시스템의 정상 동작 실패 시스템 및 사용자 매뉴얼대로의 시스템 동작 실패	비즈니스나 사용자 요구사항을 충족하지 못하는 시스템 워크플로우 잘못 구현된 비즈니스 규칙 계약 혹은 규제 요구사항을 충족하지 못하는 시스템 보안 취약성, 많은 부하가 걸렸을 때 성능 효율성 저하, 지원 대상 플랫폼상에서의 잘못된 운영 등과 같은 비기능 장애
접근법과 책임	주로 개발자가 수행 애자일 개발에서는 자동화된 컴포넌트 테스트 케이스를 먼저 작성	주로 개발자가 책임 모듈의 통합에 집중함 통합하는 범위가 넓으면 격리가 어려워 개발 리스크와 문제 해결 시간의 증대 야기	시스템 테스팅은 일반적으로 명세에 과도하게 의존하는 독립적인 테스터가 수행 기능과 비기능 모두의 측면에서 전반적인 시스템의 엔드-투-엔드 동작에 관심을 가진다. 테스터가 일찍 참여하여 결함 발견 효과 증대	주로 고객, 비즈니스 사용자, 제품 소유자, 시스템 운영자가 담당하며, 기타 관계자가 참여 사용자 인수 테스팅 : 자신감 획득, 사용자가 사용하기 얼마나 적합한지 확인 운영 인수 테스팅 : 운영자 또는 시스템 관리 직원에 의해 수행되는 시스템 인수 테스팅 계약, 규제 테스팅: 주문 개발 소프트웨어의 생산을 위한 계약서에 명시된 인수 조건 수행 알파, 베타 테스팅: 제품을 시장에 출시하기 전 사용자, 고객, 운영자 등으로부터 피드백을 받기 원하는 상용 소프트웨어 개발자가 사용하는 경우

 

2.3장

---

	2.3.1 기능 테스팅	2.3.2 비기능 테스팅	2.3.3 화이트박스 테스팅	2.3.4 변경 관리 테스팅
정의	사용자가 조작할 수 있는 모든 기능 관련 테스트. 즉, 시스템이 무엇을 할 수 있는가	사용자가 조작할 수 없는 내부 신뢰성, 성능, 기타 SQA 관점의 평가, 이식성. 즉, 시스템이 얼마나 잘 동작 하는가	시스템의 내부 구조(코드, 아키텍처, 워크플로우, 데이터 플로우)나 구현을 기반으로 테스트를 도출하는 기법	시스템 변경(결함 수정, 기능 추가, 개선)시 해당 변경이 결함을 제대로 수정했는지, 기능을 올바르게 구현했는지 또 예상하지 못한 부작용이 발생하지 않았는지 확인하기 위한 테스팅
특징	모든 테스트 레벨에서 수행할 수 있고, 수행해야 한다. 소프트웨어 동작을 보기 때문에 컴포넌트나 시스템의 기능에 대한 테스트 컨디션과 테스트 케이스 도출을 위해 블랙박스 기법을 활용	모든 테스트 레벨에서 수행할 수 있고, 수행해야 한다. 가능한 초반에 수행하는 것이 좋다. 비기능 결함을 늦게 발견하게 되면 프로젝트의 성공에 큰 위협 블랙박스 기법은 비기능 테스팅을 위한 테스트 컨디션과 테스트 케이스를 도출하는 데 사용할 수 있다.	모든 테스트 레벨에서 수행할 수 있고, 수행해야 한다.	확인 테스팅 : 전에 찾은 결함이 수정되었는지 확인하는 테스팅 리그레션 테스팅 : 의도하지 않은 부작용을 발견하기 위한 테스트를 수행. 수정에 의해 시스템의 다른 부분에 영향이 없는지 확인하는 테스팅
2.3.5 테스트 유형과 테스트 레벨	컴포넌트 테스팅: 컴포넌트가 복잡한 이자 계산을 어떻게 해야 하는지를 테스트 설계 컴포넌트 통합 테스팅: 사용자 인터페이스에서 포착하는 계정 정보가 어떻게 전달되는지를 테스트 설계 시스템 테스팅: 계좌 소유주가 어떻게 자신의 예금 통장에 신용 한도를 부여할 수 있는지를 테스트 설계 시스템 통합 테스팅: 시스템이 외부 마이크로서비스를 사용해서 계좌 소유주의 신용 점수를 확인하는 방법으로 테스트 설계 인수 테스팅: 은행이 신용 한도를 승인하거나 거절하는 방법을 기반으로 테스트 설계	컴포넌트 테스팅: 복잡한 전체 이자 계산을 수행하기 필요한 CPU 사이클 횟수를 평가하기 위해 성능 테스트 설계 컴포넌트 통합 테스팅: 사용자 인터페이스에서 비즈니스 로직으로 전달되는 데이터로 인한 버퍼 오버플로우 취약성을 위한 보안 테스트 설계 시스템 테스팅: 보이는 화면이 모든 지원 대상 브라우저와 모바일 기기에서 제대로 동작하는지 확인하기 위한 이식성 테스트 설계 시스템 통합 테스팅: 신용 점수 마이크로서비스가 응답하지 않을 때 시스템의 강건성을 평가하기 위한 신뢰성 테스트 설계 인수 테스팅: 은행 신용 처리 인터페이스에 장애인의 접근성을 평가하는 사용성 테스트 설계	컴포넌트 테스팅: 금융 계산을 수행하는 모든 컴포넌트에 대한 완벽한 구문 및 결정 커버리지 달성하기 위한 테스트 설계 컴포넌트 통합 테스팅: 브라우저 인터페이스의 각 화면이 다음 화면과 비즈니스 로직을 기반으로 데이터를 어떻게 전달하는지 확인하기 위한 테스트 설계 시스템 테스팅: 신용 한도 신청 도중 순차적으로 거치게 되는 웹페이지를 커버하기 위한 테스트 설계 시스템 통합 테스팅: 신용 점수 마이크로서비스로 보내는 모든 조회 유형을 실행하기 위한 테스트 설계 인수 테스팅: 은행 간 이체에서 지원하는 모든 금융 데이터 파일 구조와 값 범위를 커버하기 위한 테스트 설계	컴포넌트 테스팅: 각 컴포넌트를 위한 자동 리그레션 테스트가 구축되고 지속적인 통합 프레임워크에 포함 컴포넌트 통합 테스팅:인터페이스 관련 결함 수정이 코드 저장소에 체크인됐을 때 해당 수정을 확인하기 위한 테스트 설계 시스템 테스팅: 특정 워크플로우에 속하는 화면 중 하나만 변경되더라도 해당 워크플로우에 대한 모든 테스트 실행 시스템 통합 테스팅: 신용 점수 마이크로서비스의 지속적인 개발 일환으로 해당 마이크로서비스와 상호작용하는 애플리케이션에 대한 테스트를 매일 재실행 인수 테스팅: 인수 테스팅에서 발견된 결함이 수정되면 기존에 불합격했던 모든 테스트를 재실행

 

2.4.1 유지 보수가 필요한 상황(유지보수 테스팅이 필요한 상황을 요약할 수 있다)

---

유지보수의 계기

• 개선을 위한 변경
• 계획된 확장
• 수정 혹은 긴급 변경(핫픽스)
• 운영 환경 변경(예: DB 업그레이드)
• SW 업그레이드
• 결함 및 취약성을 위한 패치

이관을 위한 변경

• 플랫폼 이전
• 신규 환경에 대한 운영 테스트
• 다른 애플리케이션의 데이터를 위한 데이터 전환 테스트

보관을 위한 변경

• 데이터 이관이나 장시간의 데이터 유지가 필요하면 보관처리에 대한 테스팅
• 차후 복원/회수 절차에 대한 테스팅

 

2.4.2 유지보수를 위한 영향도 분석(유지보수 테스팅에서 영향도 분석의 역할을 기술할 수 있다)

---

영향도 분석은 유지보수 릴리스에 포함된 변경을 평가해서, 의도한 결과뿐만 아니라 변경으로 인해 발생할 수 있는 예견된 부작용을 식별하고, 변경의 영향을 받는 시스템 영역을 식별하기 위해 실시한다.

 

다음과 같은 상황에서는 영향도 분석이 어려울 수 있다:

• 명세(예: 비즈니스 요구사항, 사용자 스토리, 아키텍처)가 오래 됐거나 없는 경우
• 테스트 케이스가 문서화되어 있지 않거나 너무 오래된 경우
• 테스트와 테스트 베이시스 간 양방향 추적성이 유지되지 않은 경우
• 도구 활용이 적거나 없는 경우
• 연관된 인원이 도메인이나 시스템 지식을 가지고 있지 않은 경우
• 소프트웨어의 개발 중 유지보수성에 충분히 신경을 쓰지 못한 경우