수테크📱⌚️👀

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나 시스템을 다음 단계로 전달하는 데 있어 프로젝트 이해관계자들이 릴리즈 결정(출시)을 내릴 수 있도록 충분한 정보 제공 (맨날 유지보수할 수는 없자나...)

1. 자바스크립트란
   네이버, 구글과 같은 웹 페이지를 동적으로 만들기 위해 개발된 프로그래밍 언어
   
   
2. 라이브러리와 프레임워크의 차이는?
   1) 라이브러리 : 개발자가 특정 기능을 수행할 수 있도록 제공하는 도구 모음, 필요할 때 호출해서 사용할 수 있다. Numpy, Pandas 등이 있음
   2) 프레임워크 : 전체 애플리케이션 개발을 위한 기본 구조를 제공, 개발자가 그 틀 안에서 필요한 코드를 작성
   
   
3. 자바스크립트의 타입 분류?
   1) 원시 타입 자료형 : 프로그램이 실행되는 도중에 단 하나의 값만 가지는 SYMBOL형 : BigInt, 문자, boolean, null, undefined
   2) 비원시 타입 자료형 : 한 번에 여러 개의 값을 가지는 타입 : 객체, 함수, 배열
   
   
4. Infinity와 Nan에 대해서 설명?
   1) Infinity : 무한대를 나타내는 값으로, 어느 숫자든지 0으로 나누는 경우 반환되는 값이기도 하다
   2) NaN : 숫자가 아니라는 의미를 가지고 있고 문자열을 숫자로 나누는 것과 같이 부정확한 연산을 할 경우 반환되는 값같은 경우이다
   
   
5. null과 undefined의 차이에 대해서 설명?
   1) null : 오직 null 값만 포함하는 자료형으로 사용되고 존재하지 않거나 알 수 없는 값을 나타낼 때 사용
   2) undefined : 변수에 값이 할당되지 않은 상태일 때 자동으로 undefined 값이 할당됨!
   
   
6. === 연산자와 == 연산자의 차이점?
   1) === 연산자 : 두 값과 두 변수의 자료형까지 같은지를 비교하는 연산자
   2) == 연산자 : 두 값의 자료형은 비교하지 않고, 오직 값이 일치하는지를 비교하는 연산자
7. let과 var의 차이점 +const?
   1) let
   - 재할당 가능 여부 : 가능
   - 스코프 : 블록 스코프
   - 호이스팅 : 선언만 호이스팅되며 TDZ 적용
   - 초기화 필수 여부 : 선택
   - 추천 상황 : 값이 변경될 가능성이 있을 때
   
   2) var
   - 재할당 가능 여부 : 가능
   - 스코프 : 함수 스코프
   - 호이스팅 : 선언과 초기화 모두 호이스팅됨
   - 초기화 필수 여부 : 선택
   - 추천 상황 : 사용 비추천(오래된 방식)
   
   3) const
   - 재할당 가능 여부 : 불가능
   - 스코프 : 블록 스코프
   - 호이스팅 : 선언만 호이스팅되며 TDZ 적용
   - 초기화 필수 여부 : 선언 시 반드시 초기화 필요
   - 추천 상황 : 값이 변경되지 않아야 할 때
   
   
   
8. 호이스팅이란?
   아직 선언되지 않은 함수나 변수를 해당 스코프의 맨 위로 끌어올려서 사용하는 것처럼 보이게 하는 js의 동작 방식
   
   
9. 구조분해할당이란?
   배열 요소나 객체의 프로퍼티를 분해해서 그 값들을 각각의 변수에 할당하는 자바스크립트 표현식('...'기호를 사용)
   
   
10. spread와 rest
    1) spread
    - 특정 배열의 요소나 객체의 프로퍼티 값을 펼치는 역할을 한다
    - 동일한 코드를 여러 번 작성해야 하는 과정에서 코드를 더욱 간단하게 작성할 수 있다
    - 순서에 상관없이 여러 번 반복해서 사용할 수 있다
    
    2) rest
    - 특정 부분을 하나의 배열이나 객체로 묶는 역할을 하는 문법
    - 객체에서 rest는 구조 분해 할당과 함께 사용되며, 원하는 값들을 꺼내고 나머지 값을 별도로 묶어서 할당할 수 있다
    - rest 문법은 spread와는 다르게 순서에 상관없이 여러번 작성할 수 없고, 항상 맨 마지막에 작성해야 하기 때문에 주의해서 작성해야 한다
    
    
11. promise 객체란?
    - js에서 특정 작업을 비동기로 처리할 때 사용하는 객체
    - 프로미스 객체는 객체 생성 시 인수로 excutor라는 실행 함수를 전달하고, 실행 함수에는 매개변수로 resolve와 reject라는 콜백함수를 전달한다 
    - 프로미스 객체가 생성됨과 동시에 excutor가 실행되고, excutor에서 원하는 작업이 처리된다
    - 프로미스 객체의 excutor는 작업 처리의 성고 여부에 따라 성공했을 경우 resolve, 실패했을 경우 reject가 호출된다
    
    
12. async & await란?
    1) async
    - "비동기 작업을 약속(Promise)하는 함수"를 표시하는 간판 같은 역할입니다.
    - 간판(async)을 보면 "이 함수는 나중에 결과를 줄 거야"라고 알 수 있습니다.
    - 함수에 async를 붙이면 자동으로 Promise를 반환합니다.
    - 비동기 작업을 포함하고 있는 프로미스 객체를 반환하는 함수에 작성하는 키워드이기때문에, async를 작성하면 코드를 더 직관적으로 해석할 수 있다
    
    2) await
    - async 함수 안에서만 사용할 수 있는 키워드로, 비동기 작업(Promise)이 끝날 때까지 기다렸다가 그 결과를 반환합니다.
    - await는 마치 식당에서 음식이 나올 때까지 기다리는 손님과 같은데, 손님은 음식을 기다리지만, 음식이 나올 때까지 다른 사람과 대화를 할 수도 있음(비동기 작업)
    
    
13. JSON이란?
    - 데이터를 텍스트 형식으로 저장하고 교환하기 위해 사용하는 가볍고 읽기 쉬운 데이터 포맷
    - 웹 애플리케이션에서 클라이언트와 서버 간 데이터를 주고받을 때 사용
    - JSON은 JavaScript 문법을 기반으로 하지만, Python, Java, C++, PHP 등 거의 모든 프로그래밍 언어에서 사용 가능
    - 키-값 쌍으로 데이터를 표현
    
    
14. DOM이란?
    - 자바스크립트는 DOM을 통해 웹 페이지 요소에 접근할 수 있다
    - DOM을 사용하면 HTML 문서를 동적으로 수정, 추가, 삭제하고 사용자와 상호작용할 수 있습니다.
    - 주요 객체: document, Node, 요소 노드 등
    - 주요 메서드: getElementById, querySelector, createElement, appendChild 등
    - DOM은 웹 페이지를 트리 구조로 표현하며, JavaScript를 통해 동적으로 조작할 수 있는 인터페이스입니다.
    
    
15. 로컬 스토리지란?
    - 웹 브라우저의 데이터를 저장할 수 있는 저장소와 같은 기능
    - 로컬 스토리지를 사용하면 사용자가 브라우저를 종료하더라도 기존에 웹 페이지 내에서 저장한 데이터를 계속 유지할 수 있다
    - 로컬 스토리지는 텍스트 데이터만 저장할 수 있기 때문에 객체 혹은 배열 형태의 데이터를 로컬 스토리지에 저장하려면 데이터를 문자열로 변환해야 한다
    - JSON 객체에는 특정 문자열을 자바스크립트 객체로 변환하는 JSON.parse(), 특정 객체를 JSON 형태로 변환하는 JSON.stringify() 메서드가 있다