공부하기!

-테스트 프로세스 

ㄴ 조직 테스트: 조직 테스트는 조직 전체에서 수행 될 모든 테스트 프로젝트의 공통적인 사항을 정의 하는데 초점을 둔다.    

ㄴ조직테스트 프로세스 

1. 조직 테스트 명세 개발 
2. 조직 테스트 명세 활용 모니터링 및 제어  
3. 조직 테스트 명세 갱신 

-위험관리 

1) 위험 분석 

ㄴ위험 요소 식별 

ㄴ 위험도 산정 

ㄴ위험 평가 

2) 위험 조치 시행 

ㄴ 회피(Avoidance), 완화(Mitigration), 위험 전가(Transfer), 위험 수용(Acceptance) 

3) 위험 모니터링 

-테스트 독립성 

테스트는 독립적으로 수행될수록 결함이 쉽게 발견된다. 

ㄴ기술적 독립성 

ㄴ관리적 독립성 

ㄴ재정적 독립성 

ㄴR(rigorous): 철저한 독립성, C(Conditional) 조건적 독립성, M(Minimized) 최소의 독립성.... 

-결함 생명 주기... 

Open 

Review 

Assigned 

Resolved 

Verified 

Duplicated 

Fixed 

Won't fix 

Deffered 

Reopen 

Closed 

결함 심각도!! 

minor, major, critical, ….   

결함 우선순위!! -> 위험도 높고 심각한 것 부터... 

-테스트 산출물 

1. 조직 테스트 정책 명세서 
2. 조직 테스트 전략 명세서 
3. 테스트 계획서 
4. 테스트 현황 보고서 
5. 테스트 종료 보고서 
6. 테스트 설계 보고서 
7. 테스트 케이스 보고서 
8. 테스트 절차 명세서 
9. 테스트 환경 요건 명세서 
10. 테스트 데이터 요건 명세서 
11. 테스트 환경 준비 보고서 
12. 테스트 데이터 준비 보고서 
13. 테스트 실행 로그 
14. 결함 보고서 
15. 결함 추적 보고서 

정적테스트: 프로그램 실행을 요구하지 않는 테스트를 정적테스트로 분류하며 리뷰라고 한다.  

ㄴ 관리 리뷰: 관리 리뷰의 목적은 진행 상황을 모니터하고 계획과 현재 일정 상태를 평가하여 필요하다면 자원, 일정이나 프로젝트 범위 등을 변경하는 것이다.     

ㄴ 기술 리뷰: 기술 리뷰의 대상에는 소프트웨어 요구/설계 명세, 테스트 문서, 유지보수 메뉴얼이나 설치 절차 등이 포함된다 

ㄴ 인스펙션: 인스펙션은 동료 검토라고 할 수 있다. 동료 검토란 비슷한 수준이나 역할을 가진 사람들이 코드 등을 포함한 소프트웨어 산출물을 검토하는 작업이다. 인스펙션은 가능한 한 개발 초기에 검사해야만 개발 초기 작업물에서 문제를 찾아낼 수 있다. 

ㄴ 워크쓰루: 워크쓰루는 인스펙션보다는 비형식적인 결함 검출 방법이다. 워크쓰루는 결함을 검출할 뿐만 아니라 참가자들의 교육이나 지식 공유를 위해 수행되기도 한다. 

ㄴ감사: 감사의 목적을 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지를 독립적으로 평가하는 것으로 규정하고 있다. 감사 참여자들은 대표 감사자, 감사자, 기록자, 게시자 등이 있다. 

-리뷰 프로세스 

1) 경영진 준비 

2) 리뷰 계획 

3) 리뷰 절차 개요 설명 

4) 작업물 개요 설명 

5) 개별 준비 

6) 그룹 검토 

7) 재작업 

8) 후속작업 

구조기반 테스트: 프로그램 제어 흐름이나 자료 흐름 정보를 이용하여 테스트 케이스를 설계하는 방법이다. 화이트 박스 또는 글래스 박스 테스트라고 한다. 

-제어 흐름 그래프 

-문장 테스트 

-결정 테스트 

-조건 테스트 

-결정/조건 테스트 

-다중 조건 테스트 

-변형된 조건/결정 테스트 (MCDC) 

-기본 경로 테스트 

명세 기반 테스트 

블랙박스 테스트라고도 하는 명세 기반 테스트는 프로그램의 내부 논리 구조를 참조하지 않고 사용자의 요구사항이 기술된 명세나 설계 정보 등을 이용하여 테스트 케이스를 개발한다. 

-동등 분할 

-분류 트리 기법 

-경계값 분석 

-조합테스트 

-상태 전이 테스트 

-시나리오 테스트 

-Code-and-Fix: 테스팅 작업을 별도로 분리해 수행하지 않고 디버깅 작업의 한 부분으로 수행하는것 

ㄴ 바로 폐기 처분 되는 소프트웨어에 적합, 오랫동안 다양한 사용자들이 사용하는 시스템이거나 비교적 규모가 큰 시스템인 경우에는 부적합하다. 

- 순차적 개발 모델 

1) 폭포수 모델 

ㄴ 요구사항 → 요구사항 분석 → 구조 설계 → 상세설계 → 코딩 → 테스팅 →운영 

2)V-모델 

ㄴSDLC (Software Development Life Cycle) : 개발 관련 단계 

ㄴSTLC (Software Testing Life Cycle): 테스팅 관련 단계 

*폭포수 모델은 테스트를 하나의 개발단계로 보고, V-모델은 개발과 테스트를 동등하게 보고 명확하게 구분한다. 

*V-모델은 개발이 시작됨과 동시에 테스트 계획 및 설계에 필요한 활동이 시작 되며, 폭포수 모델은 코딩후에 테스트가 수행된다. 

-진화적 개발 모델 

ㄴ나선형 모델 

*나선형 모델은 매 단계에서 적당한 테스트가 이루어지므로 개발 과정에서 발생하는 많은 문제점을 해결 할 수 있는 기회를 제공한다. 소프트웨어 개발 프로세스의 한 주기 마다 많은 피드백을 받아 폭포수 모델처럼 개발 완료 후 심각한 결함이 발견될 확률이 적다.  

-애자일 개발 모델 

ㄴ사람 및 상호 의사 교환이 프로세스나 도구보다 우선한다.  

ㄴ 동작하는 소프트웨어가 포괄적인 문서보다 우선한다. 

ㄴ 고객과의 협력이 계약 협상보다 우선한다. 

ㄴ 변화에 반응하는 것이 계획을 다른 것보다 우선한다. 

-짝 프로그래밍: 개발자 두명이 짝을 이루어 한명이 코디을 한명이 코드를 검토하는 등의 작업을 수행한다.  

-테스트자동화: 테스트 자동화란 도구를 사용하여 테스트 프로세스의 일부 혹은 전부를 자동화하는 것을 의미한다. 

-테스트 도구 

ㄴ 테스트 설계 도구: 

1. 명세 기반 테스트 설계 도구: 요구사항 명세서를 바탕으로 테스트 케이스의 설계 및 생성을 지원하는 도구이다. (예:마이크로소프트에서 개발한 PICT 도구) 

1. 구조 기반 테스트 설계 도구: 코드를 입력으로 받아 테스트 케이스를 생성하는 도구이다. 

ㄴ 테스트 환경 구축 도구: 

*IaC(Infrastructure as Code) -> 인프라를 코드화 한다. 

ㄴ 테스트 실행 도구: Record & Playback (예: Katalon Studio) 

ㄴ 이슈 관리 도구:  Jira, Redmine, Mantis, TRac, Yona …etc 

-테스트 레벨 분류 

ㄴ 컴포넌트/단위 테스트: 각각의 컴포넌트를 테스트한다. 

ㄴ 통합 테스트: 컴포넌트 간의 인터페이스를 테스트한다. 

ㄴ 시스템 테스트: 전체 시스템이 목적을 만족시키는지 테스트한다. 

ㄴ 인수 테스트: 사용자의 요구사항을 만족하는지 확인한다. 

-테스트 설계 분류 

ㄴ 동적테스트: 명세 기반 테스트, 구조 기반 테스트, 경험 테스트 

ㄴ 정적 테스트: 리뷰, 정적 분석 

-테스트 유형 분류 

ㄴ 기능 테스트 

ㄴ 비기능 테스트 

-First 원칙 

ㄴ컴포넌트테스트를 위한 원칙 

• Fast  
• Isolated 
• Repeatable 
• Self-Validating 
• Timely 

-빅뱅 방식: 통합 대상 컴포넌트가 많은 경우, 전체 컴포넌트를 한번에 통합하여 테스트 하는 방식을 빅뱅 방식이라고 부르는다 

-점진적 통합: 적은 수의 컴포넌트를 차례로 통합하는 방식이다. 

ㄴ하향식: 상위→하위 컴포넌트로 점진적 통합 

ㄴ상향식: 하위→상위 컴포넌트로 점진적 통합 

ㄴ샌드위치: 상향식 + 하향식 방식 

-시스템/ 소프트웨어 품질 특성 

• 기능 적합성 

ㄴ 기능 완전성 

ㄴ 기능 정확성 

ㄴ 기능 적절성 

• 성능 효율성 

ㄴ 시간 반응성 

ㄴ 자원 효율성 

ㄴ 수용성 

• 호환성 

ㄴ 공존성 

ㄴ 상호운용성 

• 사용성 

ㄴ 적합인식성 

ㄴ 학습 용이성 

ㄴ 운영 용이성 

ㄴ 사용자 오류 방지성 

ㄴ 사용자 인터페이스 심미성 

ㄴ 접근성 

• 신뢰성 

ㄴ 성숙성 

ㄴ 가용성 

ㄴ 결함 허구성 

ㄴ 복구성 

• 보안성 

ㄴ 기밀성 

ㄴ 무결성 

ㄴ 부인 방지성 

ㄴ 책임성 

ㄴ 인증성 

• 유지보수성 

ㄴ 모듈성 

ㄴ 재사용성 

ㄴ 분석성 

ㄴ 변경 용이성 

ㄴ 테스트 용이성 

• 이식성 

ㄴ 적응성 

ㄴ 설치 용이성 

ㄴ 대체 용이성 

-위험기반 테스트 

ㄴ위험 요소 식별 

ㄴ 위험도 산정 

ㄴ 위험 기반 테스트 수행 

-테스트 계획 

1. 테스트 레벨/유형 결정 
2. 테스트 대상 선정 
3. 테스트 범위 설정 
4. 테스트 전략 
5. 테스트 설계/구현 및 테스트 환경 
6. 테스트 실행 및 결함 보고 
7. 테스트 모니터링/ 제어 및 테스트 종료

- 테스팅: 테스팅은 소프트웨어의 실제 동작과 요구사항의 차이를 확인한다. 

- 디버깅: 디버깅은 테스팅을 통하여 결함의 존재를 확인 한 후에 수행되며, 결함의 위치를 파악하고. 이를 제거하는 것을 목적으로 한다. 

- 재테스팅: 개발자가 결함을 제거하기 위해 코드를 수정한 후, 결함이 제거 되었는지 초기에 결함을 검출한 테스트케이스로 확인 하는 테스팅. 

- 리그레션 테스트: 유지보수 단계에서 소프트웨어가 수정 된 후에 변경이 올바르게 되었는지 검사하기 위하여 리그레션 테스트를 수행한다. 

- 테스트의 목적 

• 결함의 검출과 제품 품질 개선 
• 품질 평가와 의사 결정 지원 
• 개발 프로세스 지원 

- 완벽한 테스트는 불가능하다. (너무나 많은 경우의수….) 

- 테스트 대상: 테스트 대상은 테스트를 통해 결함을 검출하려는 대상 소프트웨어를 뜻한다. 

- 피처:  피처는 테스트 대상의 특성 중에서 테스트하고자 하는 측면/관점을 뜻한다. 

- 테스트 케이스: 입력과 예상 결과를 묶어서 일반적으로 테스트 케이스라고 부른다. 

- 테스트 환경: 테스트 대상을 실행 하는 모든 환경으로 하드웨어, 운영체제를 포함한 시스템 소프트웨어, 외부 연동 시스템, 공존하는 소프트웨어, 테스트 도구 등을 포함한다 

- 오류, 결함, 장애의 개념 

오류: 결함이 생기게 한 개발자의 행위 

결함: 소프트웨어 내에 장애를 유발할 수 있는 문제 

ㄴ 결함의 유형: 누락, 부정확한 구현, 비관련 

장애: 소프트웨어가 요구사항과 다르게 동작하는 것