수테크📱⌚️👀

2.2 테스트 레벨(Test levels)

• 테스트 레벨에 따라 독립적으로 정의 할 수 있는 사항
  • 테스트 레벨의 일반적인 목표(목적)
  • 테스트 케이스를 도출해 내는데 참조되는 개발 산출물(베이시스)
  • 테스트 대상(테스트할 그 무엇)
  • 발견된 전형적인 결함과 장애
  • 테스트 하네스(드라이버/스텁) 필요 여부와 툴 지원의 필요성
  • 상세한 테스트 접근법
  • 테스트 수행 주체 또는 조직

• 
  테스트 레벨의 일반적인 구분
  • 단위(component or Unit)
    • 테스트가 가능한 최소 단위로 나누어진 소프트웨어 모듈, 프로그램, 객체, 클래스 등에서 결함을 찾고 그 기능을 검증 -> 개발자
      • 소프트웨어 각각의 단위를 다른 부분과 연계성을 고려하지 않고 격리해서 독립적으로 테스트 수행
      • 스텁, 드라이버, 시뮬레이터 사용
    • 일반적으로 프로그램 소스 코드를 대상 -> 구조기반(화이트 박스)
    • 컴포넌트 테스트의 일반적인 목적
      • 기본 경로 확인
      • 모든 오류 처리 경로 확인
      • 컴포넌트 내의 인터페이스 확인
      • 로컬 데이터 확인, 경계값 확인

• 통합(Integration)
  • 컴포넌트간에 인터페이스를 테스트하는 것은 물론 OS, 파일 시스템, 하드웨어 또는 시스템간 인터페이스와 같은 시스템의 각기다른 부분과 상호 연동하는 동작을 테스트
  • 컴포넌트 통합 테스트
  • 시스템 통합 테스트
  • 통합 테스팅은 기능적 특성은 물론 비기능적 특성(성능, 연결성등)을 테스팅 수행
  • 통합 테스팅 설계는 기능적 접근법, 구조적 접근법을 모두 사용
    • 통합 그 자체에만 집중하는 오류 주의!

• 시스템(System)
  • 개발 프로젝트 차원에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트 -> 리스크 최소화를 위해 실제 환경과 유사한 상태
  • 시스템 관려 고객의 요구사항이 완벽하게 실행되는지를 테스트
  • 테스트 베이시스(개발 산출물) 이용
    • 리스크 분석서, 요구사항 명세, 비즈니스 프로세스, 유즈 케이스, 기타 비즈니스 레벨의 시스템 동작 명세, OS 및 시스템 리소스와 상호작용 명세
  • 기능 및 비기능 요구사항 모두 검증
    • 기능적 테스트: 명세기반(블랙박스) 기법으로 수행 - 문서 기반
    • 비기능적 테스트: 기능적 외의 나머지 부분에 대한 요구사항 검증
  • 일반적으로 독립적인 테스트 팀이 수행 -> 검수 테스팅(출시)
• 인수(Acceptance)
  • 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 확신을 얻는 것 -> 결함 발견이 목적이 아님
  • 품질에 대한 확신
  • 시스템을 배포하거나 실제 사용할 준비가 되었는지 평가
  • 인수 테스팅 이후에 대규모 시스템 간의 통합 테스트 수행
    • 인수 테스팅이 반드시 최종 단계의 테스팅은 아님
  • 인수 테스팅은 프로젝트 전체 개발 과정에서 수행
    • 사용 SW 제품은 설치, 통합 하면서 테스팅
    • 컴포넌트의 사용성에 대해서는 컴포넌트 테스팅 동안 실행 가능
    • 새로운 기능 개선에 대해서는 시스템 테스팅 전에 실행 가능
  • 인수 테스팅 형태
    • 사용자 인수 테스팅(비즈니스 사용자가 확인)
    • 운영사의 테스팅: 백업/복원, 재난 복구, 사용자 관리, 유지보수 작업, 보안 취약성 점검
    • 계약 인수 테스팅과 규정 인수 테스팅: 맞춤식-개발 SW가 계약상의 인수 통과 조건/규정을 준수하는지 확인
    • 알파 테스팅과 베타(필드) 테스팅 -> 고객의 피드백
      • 알파 테스트: 개발 조직 내에서 고객에 의해 수행
        • 고객 사이트로 이동하기 전에 개발 완료 후 테스팅인 공장 인수 테스팅을 의미
      • 베타 테스트: 실제 환경에서 사용자 혹은 잠재 고객에 의해 수행
        • 고객 사이트로 이동한 후에 테스팅하는 사이트 인수 테스팅을 의미

2.1. 소프트웨어 개발 모델

• 테스팅 vs 소프트웨어 개발
  • 서로 밀접하게 연계
  • 개발 수명 주기에 기반하여 테스팅 접근법을 다르게 적용

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

• 개발 산출물 (Work product)
  • 비즈니스 시나리오 또는 유즈케이스, 요구사항 명세, 설계 문서나 코드 -> 테스트 베이시스(Basis)로 사용
• V-모델의 역할
  • 각각의 개발 단계에서 테스팅을 접근하는 방법을 개략적으로 이해하기 쉽게 모델화하여 보여주는 것
  • V-모델을 통해 테스팅 기본 개념 이해
    • 테스트 레벨의 의미
      • 컴포넌트 / 단위 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅
        • 테스트 레벨에 따라 테스트 전략, 테스트 기법,ㅌ ㅔ스트 수행 주체, 테스트 완료 기준 등이 달라짐
        • 테스트 레벨은 독립적
    • 개발 초기 단계에서 테스팅을 수행한다는 것의 의미
      • 개발 산출물을 리뷰 형태로 검토하면서 결함을 발견하는 정적 테스팅을 의미
        • 결정 테이블 테스팅, 상태전이 테스팅, 유즈케이스 테스팅 등
      • 개발 초기의 테스팅을 통해서 후반후에서 발생할 비용을 줄임
    • 초기에 테스트 설계를 통해 사전에 결함 예방 
    • V&V(Verification and Validation)의 의미
      
      • Verification(검증): 평가 대상이 기술된 요구사항을 만족하는지 검증(우리가 명세서 내용대로 시스템을 만들고 있는지)
      • Validartion(확인): 평가 대상이 사용자의 특정한 목적을 만족하는지를 확인(우리가 만드는 시스템이 고객이 원하는 시스템인지)

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

• 주기(Iteration)가 반복될수록 테스트 범위가 증가함
• 리그레션 테스팅이 점차 중요해짐(회귀 테스트)
• 테스트 자동화 필요성 증가
• 활용 가능한 적절한 테스트 접근법
  • 애자일 테스팅(Agile Testing)
  • 탐색적 테스팅(Exploratory Testing)

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

• 성공적인 테스팅을 위한 요건
  • 모든 개발 활동은 이에 상응하는 테스트 활동을 동반
  • 각 테스트 레벨은 그 레벨에 맞는 특정한 목적이 잇음
  • 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되는 개발 활동 동안에 시작
  • 개발 생명주기 동안에 개발 산출물의 초안이 작성되면, 테스터는 이러한 문서를 리뷰하는 활동에 참가
• 테스팅 레벨 조절
  • 테스팅은 프로젝트나 시스템 아키텍처의 성격에 따라 재조정하거나 합쳐질 수 있음

1.5 테스팅의 심리학

• 개발자와 테스팅 엔지니어 분리 -> 각자의 활동에 집중
• 테스팅 독립성(-> 단계가 오를 수록 독립성 높아짐)
  1. 테스트 대상 소프트웨어의 개발자각 설계한 테스트(독립성 낮아짐)
  2. 개발팀 내의 다른 인원이 설계한 테스트
  3. 다른 그룹의 독립적인 테스트 팀의 인원, 또는 테스트 전문가(사용성 또는 성능 테스트 전문가 등)가 설계한 테스트
  4. 다른 조직 또는 다른 회사의 인원이 설계한 테스트(외부적 조직에 의한 인증, 아웃소싱)
• 명확한 테스팅의 목표 설정은 테스팅을 성공적으로 수행하는데 있어 중요

• 테스팅 진행하는 동안 결함을 식별하는 과정
  • 작성자에 대한 비판으로 오해된 소지 존재
    • 호기심, 전문적인 비평, 비판적인 시선, 세밀한 것에 주목하는 태도, 개발자 또는 개발팀 동료와의 원활한 의사소통, 그리고 결함을 유추해 내는 경험을 필요
  • 오류나 결함, 장애가 긍정적인 방법으로 의사소통 된다면, 테스트와 개발자 간에 발생할 수 있는 감정 악화를 피할 수 있다
  • 테스터, 테스트 리더 사이: 좋은 대인 관계가 필요
  • 결함 정보: 결함 발견 -> 시간과 비용 절감 및 리스트 요소 줄임

• 테스터의 역할
  • 다툼보다는 협력으로 시작 -> 공통적인 목표를 모든 사람에게 
  • 소프트웨어를 개발한 사람에게 비평을 배게하고 중립적이고 사실에 근거한 제품의 결함만 전달하려고 노력한다
  • 다른 인원이 어떻게 느끼는지, 왜 그렇게 반응하는지 이해하도록 노력한다
  • 상호간에 의사소통 했던 것을 상대방이 정확하게 이해했는지 확인한다

1.6. 소프트웨어 테스팅을 제약하는 요소

• 최근 SW
  • 전통적인 컴퓨팅 영역 탈피
    • 가전, 무선단말기, 산업기기, 휴대폰, 자동차(ECU) 분야
  • SW 개발 프로세스 품질의 중요성과 함께 SW 결함을 사전에 진단하고 정상 동작여부를 시험하는 테스팅의 중요성 부각
    • 전채 개발비의 40% ~ 60% 이상의 테스팅 비용 (개발 << 테스팅 비용)
    • 하지만 기존 개발자들은 테스팅에 소극적 -> 하위레벨 테스트 부족
  • 품질에 대한 인식 높아져 기대 수준 높아짐 -> 리스크 관리 필요
    • 체계적인 테스팅을 위해서는 테스트의 우선순위 중요
• 테스트에 대한 문제점
  • 테스터가 테스팅에 대해 너무 단편적으로 알고 있는 것은 체계적인 테스팅을 제약하는 요인
    • 개념과 연관성 이해
    • 리스크 기반 테스팅 접근법 / 테스트 기법 / 테스트 커버리지
    • 이론을 실무에 적용하는 노력 필요
  • 의사결정권자와 매니저의 테스팅에 대한 인식 부족
    • 임시방편
    • 테스트 자동화 도구의 중장기적 계획 or 테스트 프로세스 정립 필요
  • 테스팅을 투자가 아닌 불필요한 비용으로 인식
    • 테스팅은 개발보다 더 확실한 ROI(Return On Investment) 활동

1.7. 테스팅 분야의 매력

• 테스팅 분야의 전문가
  • 체계적인 지식 체계를 갖는 전문 분야
    • 기존적인 컨셉과 테스트 전략, 계획, 설계 기법, 테스트 케이스 작성, 결함 관리, 지원도구, 정적 테스트 기법, 비기능성 테스팅, 테스트 프로세스 관리, 기반 설비 및 환경, 메트릭과 리포팅 등의 분야 포함
  • 테스팅 분야는 넓고 다양함
    • 자동화 도구에 대한 전문적 기술
    • 보안성 테스트, 신뢰성 테스팅 분야 전문가
    • 테스팅 컨셉, 기법 및 관리 방법을 소프트웨어 종류별 최적화하여 적용
  • 테스팅 필요성 급증
  • 테스팅 분야에서 연령 제한(X), 경험 중시

1.8. 테스트 전문가

• 테스트 전문가에 대한 수요
  • 계속적으로 증가 -> 소비자의 품질에 대한 마인드와 기대수준 올라감
  • 전문 인력 수급 어려움
    • 협력사 파견인력 지원
    • 테스팅 전문회사에 아웃소싱
    • 고급인력이 부족한 경우엔 테스트 컨설턴트 활용
  • 능력 있는 테스트 전문가
    • 기술능력 - 소프트웨어 공학 이해, 테스트 수행 능력
    • 개인 능력 - 커뮤니케이션, 분석력, 문서화, 결함 유추
    • 습성 - 충분한 이해와 도구 사용, 표준화 노력
    • 사고방식과 태도 - 주인의식, 열정, 적극, 긍정, 호기심, 비판적인 시선 

1.4. 테스트 프로세스의 기초

• 테스트 프로세스
  • 테스팅 관련 활동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 테스팅의 구성 요소를 엮어주는 역할
    • 테스트 베이시스 -> 계획 단계부터 필요 설계 시 반드시 요구
    • 테스트 조직 -> 계획 단계부터 필요, 실행 단계에서 다수 인력 필요
    • 테스트 전략
    • 테스트 기법 -> 분석 및 설계 단계에서 필요
    • 테스트 대상 -> sw는 가장 이른 시기 준비, 늦어도 실행 단계엔 필수
    • 테스트 기반 설비 및 환경 -> 실행 단계 전에 구축
  • 체계적으로 발견한 결함과 관련 정보를 바탕으로 정량적(수치적)으로 개발 프로젝트에 조언(분석한 리스크)을 제공

1.4.1. 태스트 계회과 제어(통제)

• 테스트 계획과 제어
  • 주요 활동
    • 테스트 목적/목표 및 대상 연구
    • 테스트 전략 개발
    • 테스트 완료 조건의 결정
    • 테스트를 추정
    • 테스트 조직 구성
    • 테스트 계획 활동
    • 테스트 관리 및 제어
    • 리포팅

• 테스트 제어
  • 계획 대비 실제 진행 상황을 비교하는 지속적인 활동
  • 계획과의 차이 확인-> 지속적 모니터링
  • 제어 작업
    • 테스트 결과에 대한 측정과 분석
    • 테스트 진척사항, 완료조건의 모니터링과 문서화
    • 테스트 계획과의 차이 교정
    • 테스팅의 진행과 변경에 대한 의사 결정 활동
    • 테스팅 계획은 테스팅의 제어와 모니터링 활동으로부터 받은 피드백을 반영

1.4.2. 테스트 분석과 설계

• 테스트 분석과 설계
  • 일반적이고 추상적인 테스팅 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환하는 활동(어떤 상황에는 어떤 경우가 나와야한다 케이스 만들기~)
  • 주요 작업
    • 테스트 베이시스 리뷰(가장 기초 문서-요구사항 명세서, 설계 계획서 등)
    • 테스트 상화 / 테스트 케이스 / 필요한 테스트 데이터 식별
    • 테스트 케이스 설계와 우선순위 선정
    • 테스트 기법 할당
    • 테스트 용이성 평가
    • 테스트 환경 구축(실제 환경과 동일)
    • 필요한 도구 식별

1.4.3. 테스트 구현과 실행

• 테스트 구현과  실행
  • 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시저 또는 테스트 스크립트를 명세화
  • 테스트에 필요한 환경이 구축되어야 함
  • 주요 작업
    • 테스트 케이스 개발, 구현과 우선순위 설정
    • 자동화 테스트 스크립트 작성
    • 테스트 하네스(harnesses) 준비(환경) - 나중에~
    • 효율적인 테스트 실행을 위해 테스트 수트(테스트 케이스 묶음) 생성
    • 선행 테스트
    • 테스팅 실행(결과 기록 - 식별과 버전 관리)
    • 기대 결과와 비교 -> 예상 결과와 실제 결과 간의 차이에서 오는 불일치를 인시던트(incidents) 또는 결함으로 보고 -> 불일치 원인 파악
  • 예상과 실제의 불일치
    • 테스트 케이스 결함
    • 테스트 정황 결함
    • 어플리케이션 결함
  • 불일치를 조치한 결과를 확인하기 위한 테스트 활동 반복
    • 수정이 되었는지 테스트 실행 -> 확인(confirmation) 테스틩
    • 수정으로 새로운 버그가 발생하지 않았는지 테스트 실행 -> 회귀 테스팅(regression testing)
  • 결함의 유형
    • 기획 시 유입된 결함 - 요구사항의 표준 미준수, 테스트 불가능 등
    • 설계 시 유입된 결함 - 설계의 표준 미준수, 테스트 불가능 등
    • 코딩 시 유입된 결합 - 코드의 표준 미준수 등
    • 테스트 부족으로 유입된 결함
    • 마무리 부족
    • 팀간 의사소통 부족
    • 코딩 실수
  • 결함 심각도에 따른 결함 유형 (명시적으로 보여서 좋은듯~ 우리회사도 이거인거 같어)
    • 치명적 결함, 매우 심각, 심각, 보통, 경미 (-> 4단계)
    • 치명적 결함, 주요 결함, 일반 결함, 사소한 결함, 개선 사항(-> 5단계)
  • 결함 유형으로 부적절한 경우
    • Major, Minor, Trifle(Minor를 결함의 심각도가 낮은 것으로 인식 가능)
    • A, B, C(어느 것이 결함이 높은 것인지 알 수 없음)
  • 결함의 우선순위 표현
    • 즉시 해결, 주의 요망, 대기, 낮은 순위

1.4.4. 테스트 완료 조건과 리포팅

• 테스트 완료 조건의 평가
  • 초기 목표 대바 완료조건의 달성 여부 확인(-> 95% 만족 시)
  • 테스트 레벨에 따라 다 수행 함
  • 완료 조건 작업
    • 테스트 실행 결과인 테스트 로그가 테스트 계획에 명시된 완료 조건을 만족하는지 확인
    • 추가 테스트 필요 여부 및 명세화된 테스트 완료 조건 변경 여부
    • 이해관계자들에게 배포할 테스트 요약 보고서 작성
• 리포팅에 표현되는 내용
  • 발견된 결함과 미해결된 결함의 추이 및 우선순위 (얼마나 높은 우선순위에 있는 결함이 얼마나 줄어들었는지)
  • 테스트 진척도
  • 리스크 및 매트릭으로 실증된 조건
    • 테스트 환경의 가용성(다음에 사용 가능한지)
      • 테스트 커버리지
      • 결함 발견 효율성/효과성
      • 품질 평가 결과
      • 결함상태별 결함수
      • 소프트웨어 사이즈 대비 결함수
      • 요구사항별 테스트 일수
      • 해결되지 않은 결함과 영향 및 오래 수정되지 않은 결함

1.4.5. 테스트 마감 활동

• 테스트 마감 활동
  • 산출물 확인, 테스트웨어(산출물) 보관(-> 다음 프로젝트를 위해)
  • 테스트 프로세스 평가 심사
  • 주요 활동
    • 테스트 결과 마감(예정된 산출물, 인시턴트 레포트 종료, 해결되지 않은 요구사항에 대한 처리, 시스템 인수에 대한 문서화 등)
    • 테스트웨어, 테스트 롼경, 테스트 기반설비를 차후에 사용위해 마감, 보관
    • 테스트웨어를 유지보수 조직에 이관
    • 테스트 프로세스 심사 및 개선 사항
    • 이후 릴리즈나 프로젝트, 테스트 성숙도의 개선에 지침이 될 수 있도록 테스트 프로젝트를 통해 얻은 교훈을 분석

1.3. 테스팅의 일반적인 원리

• 원리 1. 테스팅은 결함이 존재함을 밝히는 것 (Testing shows presence of defects)
  • 잠재적으로 존재하는 결함 줄임
  • But, 결함이 없다고 증명할 수는 없음
• 원리 2. 완벽한 테스팅 (Exhaustive testing)은 불가능 (Exhaustive testing is impossible)
  • 한 프로그램 내에 내부 조건이 많음
  • 입력이 가질 수 있는 모든 값의 조합이 무수히 많음
  • 이벤트 발생시 발생 순서에 대한 조합도 무수히 많음
  • 리스크에 따라 테스트 강도 높게 수행 -> 실제 완벽은 불가
• 원리 3. 개발 초기에 테스팅 시작 (Early testing)
  • 개발의 시작과 동시에 테스트를 계획하고 전략적으로 접근
  • 요구사항 분석서와 설계서 등의 개발 산출물 분석 후 테스트 케이스 도출
  • 다 만들고 테스트 결과가 엉망이 나오면 유지보수 비용이 장난 아니겠쥐~
• 원리 4. 결함 집중 (Defect clustering)
  • 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보임
  • 결함의 집중은 운영상의 장애를 초래
    • 복잡한 구조의 모듈
    • 다른 모듈과 다량의 상호작용을 하는 모듈 (자꾸 호출하다 보면 결함 나오기 쉬움)
    • 개발 난이도가 높거나 최신 기술을 사용한 모듈
    • 크기가 큰 모듈
    • 경험이 미흡한 팀에서 개발한 모듈
    • 새롭게 개발한 모듈
• 원리 5. 살충제 패러독스 (Pesticide paradox)
  • 동일한 테스트 케이스로 동일한 테스트를 반복하면 결함으로 찾기 어려워짐
  • 더 많은 결함을 찾기 위해서는 테스트 케이스를 정기적으로 리뷰하고 개선
• 원리 6. 테스팅은 정황(Context)에 의존적 (Testing is context dependent)
  • 테스팅은 정황(context)과 도메인에 따라 다르게 진행
  • 모든 테스트에 적용되어야 하는 것
    • 테스트 프로젝트 기획
    • 표준적인 기법적용
    • 독립적인 테스트 환경
    • 효율적/효과적 테스트 팀 조직
    • 정식 리포팅 등
• 원리 7. 오류-부재의 궤변 (Absence-of-errors fallacy)
  • 개발된 소프트웨어가 사용자 요구수준을 만족하지 않는다면 버그를 수정하는 것은 의미가 없음

1.2 테스팅이란 무엇인가?

• 테스팅
  • 응용 프로그램 또는 시스템의 동작과 성능, 안정성이 사용자가 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 메커니즘
    • 정상 동작 여부 확인
    • 사용자의 기대 수준과 요구사항에 맞게 구현되고 동작하는지 확인
    • 개발 프로젝트의 리스크 정보를 정량적 수치로 의사결정권자에게 전달
  • 초기 개발 산출물 -> 리뷰
  • 테스트 케이스 작성 과정(결함 예방 활동)
  • 다양한 테스팅 활동

• 테스팅의 일반적인 목적
  • 남아있는 결함 발견
  • 명세 충족 확인
  • 사용자 및 비즈니스의 요구 충족
  • 결함 예방
  • 품질 수준에 대한 자신감 획득과 정보 제공
  • 비즈니스 리스크를 감소시키는 정보에 근간한 조언 제공
  • 개발 프로세스 점검, 이슈 제기
  • 논리적 설계의 구현 검증
  • 시스템과 소프트웨어가 적절히 동작함을 확인

• 관점에 따른 테스팅의 목적
  • 개발 과정 - 결함을 찾고 수정하기 위해 가능한 많은 장애 상황 재연
  • 인수 테스팅 - 예상대로 시스템이 동작하는지 확인, 요구사항 확인
  • 소프트웨어 품질 - 출시하는 것의 리스크를 관련자에게 전달
  • 유지보수 테스팅 - 변경에 대해 새로운 결함의 유입을 확인(반복 테스트)
  • 운영 테스팅 - 신뢰성 또는 가용성 같은 시스템 특성을 평가
  • 테스팅은 문서의 리뷰와 함께 정적 분석에 의한 테스트 포함

1.1. 테스팅이란 무엇인가?

1.1.1 SW 시스템 관점에서 테스팅의 필요성

• SW 관점에서 테스팅
  • 비즈니스 어플리케이션에서 소비자 제품에 이르기까지 폭넓게 생활의 많은 부분에 사용 -> 비중은 계속 증가
  • 금전적인 손실, 시간 낭비, 비즈니스의 이미지 손상, 그리고 부상이나 사망에 이르기까지 다양하고 심각
  • 테스팅은 소프트웨어 시스템의 문제를 최소화하기 위해 필요

1.1.2 소프트웨어 결함의 원인

• 소프트웨어 결함
  • 오류(error) - 인간의 행위, 실수
    • 코드 작성, 소프트웨어나 시스템 또는 문서 작성시 결함을 만드는 오류
  • 결함(defect) - 요구된 기능의 부정확한 처리를 말하며 이것으로 인해 고장 또는 장애를 발생시키는 원인이 됨
    • 시간적인 압박, 복잡한 코드, 기반환경의 복잡성, 기술이나 시스템의 변경, 수많은 시스템 상호간의 연동
    • 결함은 장애의 원인
    • But, 모든 결함이 장애를 발생시키는 것은 아님
  • 장애(failure) - 코드에 존재하는 결함의 실행 또는 환경적 조건에 의해 부정확하게 처리되는 것을 의미함
    • 결함 + 환경적인(방사, 전자기장, 물리적 오염 등) 조건

1.1.3 SW 개발, 유지보수, 운영 시 테스팅의 역할

• 테스팅
  • 개발 초기의 요구사항 분석 단계부터 리뷰와 정적분석(문서 정도로 생각)을 통해 정적으로 시작 -> 각각의 개발단계에 대응하는 테스트 레벨별
  • 컴포넌트, 통합 테스팅은 개발 조직 중심으로 수행
  • 시스템이 갖춰진 이후의 테스팅은 독립적인 테스트 조직 중심
  • 테스트 레벨에 따른 테스트
    • 소프트웨어 품질을 높이고, 결함 발생 가능성을 최소화
  • 유지보수 활동으로 변경 및 단종되거나 가능성을 최소화
    • 변경된 환경에 대해 운영 테스팅(리그레션 테스팅)
    • 변경으로 인한 결함과 장애를 예방
  • 계약상 요구조건 및 산업에 특화된 표준 만족

1.1.4 테스팅과 품질

• 품질 특성 및 향상
  • ISO/IEC 9126 소프트웨어 제품 품질
    • 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성
  • 품질 향상 -> 테스팅이 결함을 찾아내고, 발견된 결함 수정
  • 품질 보증(Quality Assurance)
    
    • 이전 프로젝트를 통해 많은 테스트 경험과 정보 확보
    • 발견된 결함의 근본 원인 이해를 통해 프로세스 개선
    • 결함의 재발 방지
  • 개발 표준이나 교육 훈력 그리고 결함 분석

1.1.5 테스팅, 얼마나 해야 충분한가?

• 적절한 테스팅 정도
  • 리스크 수준을 고려
  • 프로젝트 제약 사항
    • 기술적인 내용
    • 비즈니스
    • 제품
    • 프로젝트 리스크
    • 시간
    • 비용
  • 테스팅은 테스트된 SW나 시스템을 다음 단계로 전달하는 데 있어 프로젝트 이해관계자들이 릴리즈 결정(출시)을 내릴 수 있도록 충분한 정보 제공 (맨날 유지보수할 수는 없자나...)

***  일반 + 신유형

oracle에서 빈문자열은 null로 저장 / sql server에서는 빈문자열 그대로 저장되어 

4번은 null이 아니자나... 그래서 조회가 안됩니다...

논리 연산자 우선순위 : NOT > AND > OR

null 은 포함하지 않고 계산하면

1. (20 + 0) / 2 = 10

2. (20 + null (x)) / 1  = 20

3. (20 + null (x)) / 1  = 20

NVL(대상데이터 , NULL일때 데이터)

값이 null 인 경우, 2번째 지정값을 출력하고 그렇지 않으면 대상데이터를 출력한다.

SELECT TOP(3) WITH TIES 팀명, 승리건수   // TOP(3) 만 적는다면 그냥 3개만 출력
	FROM 팀별 성적
    ORDER BY 승리건수 DESC;

=> 3번째 행과 동일한 값을 가진 추가 행이 있다면 이 행들도 포함(SQL Server에서 사용)

SELECT 팀명. 승리건수
	FROM 팀별성적
    WHERE ROWNM <= 3
    ORDER BY 승리건수 DESC;

=> 3번째 행과 동일한 값을 가지 추가행이 있더라도 포함 x (Oracle에서 사용)

=> Oracle에서서 TOP(3) WITH TIES와 유사한 기능을 구현하려면 DENSE_RANK()의 윈도우 함수를 사용할 수 있다

RANK()와 DENSE_RANK()의 차이....

EmployeeIDNameSalary

RANK() 사용 예시

SELECT *
FROM (
    SELECT e.*, RANK() OVER (ORDER BY Salary DESC) AS rnk
    FROM Employees e
)
WHERE rnk <= 3;

EmployeeIDNameSalaryrnk

RANK() 함수는 Salary가 같은 Bob과 Carol에게 동일한 2순위를 부여하고, 다음 순위인 3을 건너뛰고 4를 Dave에게 부여

DENSE_RANK() 사용 예시

SELECT *
FROM (
    SELECT e.*, DENSE_RANK() OVER (ORDER BY Salary DESC) AS rnk
    FROM Employees e
)
WHERE rnk <= 3;

EmployeeIDNameSalaryrnk

DENSE_RANK() 함수는 Salary가 같은 Bob과 Carol에게 동일한 2순위를 부여하고, 다음 순위를 3으로 부여하여 연속성을 유지합니다.

• RANK(): 동일한 값을 가진 행들이 있으면 순위에 공백이 생깁니다.
• DENSE_RANK(): 동일한 값을 가진 행들이 있더라도 순위에 공백이 생기지 않고 연속적으로 부여됩니다.

oracle은 수정후에 create하면 자동으로 저장된다

헷갈리기 쉬운 문제...

ROWNUM 을 정렬 전에 쓰면 아무 의미 없다....

정답은 3번

' \d+', 'xxx', 1, 2 => 문자를 xxx로 바꾸는데 처음부터 시작해서 2번째 위치꺼를 REPLACE 바꿔라

*** 노랭이 모르는거

TCL :  논리적인 작업의 단위를 묶어 DML에 의해 조작된 결과를 작업 단위(Transaction) 별로 제어하는 명령어인 Commit, Rollback, Savepoint 등이 여기에 해당하며, 일부에서는 DCL로 분류하기도 한다

UNIQUE는 NULL 입력이 가능하다!!! PK는 불가능함 ㅋㅋㅋ

****  노랭이 정리

데이터 모델링

1. 개념적 데이터 모델링 : 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링 진행, 전사적 데이터 모델링, EA 수립시 많이 이용

2. 논리적 데이터 모델링 : 시스템으로 구축하고자 하는 업무에 대해 Key 속성, 관계 등을 정확하게 표현, 재사용성이 높음

3. 물리적 데이터 모델링 : 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계 

데이터 모델링을 하는 주요한 이유

1. 업무정보를 구성하는 기초가 되는 정보들에 대해 일정한 표기법에 의해 표현함으로써 정보시스템 구축의 대상이 되는 업무 내용을 정확하게 분석하기 위해서

2. 분석된 모델을 가지고 실제 데이터베이스를 생성하여 개발 및 데이터 관리에 사용하기 위해서

=> 데이터 모델링 이라는 것은 단지 데이터베이스만을 구축하기 위한 용도로 쓰이는 것이 아니라 데이터모델링 자체로서 업무를 설명하고 분석하는 부분에서도 매우 중요한 의미를 가짐

데이터 모델링 유의점 : 중복, 비유연성, 비일관성

데이터베이스 스키마 구조 3단계

- 외부 스키마 : 사용자가 보는 데이터베이스의 부분적 뷰를 정의

- 개념 스키마 : 통합 관점의 스키마 구조를 표현한 것으로 데이터 모델링은 통합관점의 뷰를 가지고 있는 개념 스키마를 만들어가는 과정임.

- 내부 스키마 : 데이터의 물리적 저장 구조를 정의

ERD 작성 순서

1. 엔터티를 그린다

2. 엔터티를 적절하게 배치한다

3. 엔터티 간 관계를 설정한다

4. 관계명을 기술한다

5, 관계의 참여도를 기술한다

6. 관계의 필수여부를 기술한다

엔터티의 특징

1.반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다

2. 유일한 식별자에 의해 식별이 가능해야 한다

3. 영속적으로 존재하는 (두개 이상의)인스턴스의 집합이어야 한다

4. 엔터티는 업무 프로세스에 의해 이용되어야 한다

5. 엔터티는 반드시 속성이 있어야 한다

6. 엔터티는 다른 엔터티와 최소 한 개 이상의 관계야 있어야 한다 

기본엔터티(키엔터티) 

- 원래 존재하는 정보로서 다른 엔터티와의 관계에 의해 생성되지 않고 독립적으로 생성이 가능하고 자신은 타 엔터티의 부모의 역할을 하게 된다

- 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가지게 된다

- 예를 들어 사원, 부서, 고객...

-  vs) 중심엔터티(메인엔터티) : 데이터 모델에서 다른 여러 엔터티와 관계를 맺는 중심적인 역할을 하는 엔터티로 여러 엔터티와의 관계를 맺고 관계를 통해 데이터를 연결한다

속성(Attribute) 

: 업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위

=> 업무상 관리가 가능한 최소의 의미 단위(엔터티의 한 분야)

속성의 특성에 따른 분류

- 기본속성 :  엔터티가 본질적으로 가지고 있는 속성('고객' 엔터티의  '이름', '주소', '전화번호')

- 설계 속성 : 데이터베이스 설계를 위해 추가된 속성('주문' 엔터티의 '주문번호', '고객ID')

- 파생 속성 : 다른 속성 값에서 계산되거나 유도되는 속성, 조회할 때 빠른 성능을 내도록 함('주문' 엔터티의 총금액)

 속성의 도메인

:  각 속성은 가질 수 있는 값의 범위가 있는데 이를 속성의 도메인이라하며, 엔터티 내에서 속성에 대한 데이터타입과 크기 그리고 제약사항을 저장하는 것

두개의 엔터티 사이에 체크해야 할 사항

1. 두 개의  엔터티 사이에 관심있는 연관규칙이 존재하는가?

2. 두 개읜 엔터티 사이에 정보의 조합이 발생하는가?

3. 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?

4. 업무기술서, 장표에 관계연결을 가능하게 하는 동사가 있는가?

주식별자를 저장할 때 고려해야 할 사항

- 주식별자에 의해 엔터티내에 모든 인스턴스들이 유일하게 구분되어야 한다(유일성)

- 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다(최소성)

- 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다(불변성)

- 주식별자가 지정이 되면 반드시 값이 들어와야 한다(존재성)                                                                                                                                                                                                                                                                              

식별자의 종류

- 엔터티 내에서 대표성을 가지는가에 따라 주식별자와 보조식별자로 구분

- 엔터티 내에서 스스로 생성되었는지 여부에 따라 내부식별자와 외부식별자로 구분

- 단일 속성으로 식별이 되는가에 따라 단일식별자와 복합 식별자로 구분

- 원래 업무적으로 의미가 있던 식별자 속성을 대체하여 일련번호와 같이 새롭게 만든 식별자를 구분하기 위해 본질식별자와 인조식별자로 구분

성능 데이터 모델링 수행 절차에 대한 설명..

1. 데이터모델링을 할 때 정규화를 정확하게 수행

2. 데이터베이스 용량산정을 수행

3. 데이터베이스에 발생되는 트랜잭션의 유형을 파악

4. 용량과 트랜잭션 유형에 따라 반정규화를 수행

5. 이력모델의 조정, PK/FK 조정, 슈퍼 타입/서브타입 조정 등을 수행

6. 성능관점에서 데이터모델을 검증