오늘 저녁은 냉면이다. 나는 얼음 팩을 끌어 안고 있다. 덥다. 이토록 더울 수 있다는 게 그저 신기할 따름의 체감 온도 33도이다. 집에는 에어컨이 설치되어 있지만 우리집은 에어컨을 그렇게 좋아하지 않는다. 나이가 들면서 달라진 점이 있다면 더위를 잘 느끼고, 땀이 잘 난다는 것. 물론 다른 사람들 기준이 아닌 지극히 나의 기준에서 그렇다. 어렸을 때는 이렇게까지 더위를 느끼지 않았던 것 같은데, 이렇게 까지 땀도 나지 않았던 것 같은데 무엇이 문제가 되었으면 지금의 상황이 되었을까 고민을 해본다. 나는 추위를 잘탄다. 추위를 잘 타면 더위는 넘어가야 이상적인게 아닌가 싶다가도 무엇이 그 기준을 정하느냐를 생각해봤을 때에 그렇게 집착할 것이 아닐 것 같다는 생각을 하게 된다. 어렸을 때는 더위를 잘 느끼지 못했다. 그때는 더위와 추위가 공평했다. 한쪽이 강하면 한쪽은 작아졌으니까. 그런데 지금은 왜 두가지의 느낌을 어느 하나 부족하지 않게 공평하게 대하고 있는 걸까. 그렇게 공평하고 싶다면 차라리 둘다 느끼지 못하는 쪽은 택할 수 없었던 것일까 한탄을 하게 된다.
1. 결함 발견과 격리(때로는 예방까지) 2. 결함 발견 메커니즘을 가지고 있다. 3. 제품의 자신감 제공 4. 결함 예방과 조화를 이루어야 함 5. 품질과 리스크에 대한 통찰 제공(결함을 많이 잡으면 리스크 낮아짐) 6. 테스팅은 수명주기와 프로세스를 갖는 프로젝트 7. "테스트"는 실제 수행하는 하나하나의 실체이다.
▶ 테스트를 하는 목적 프로그램의 동작(기능)과 성능, 안정성이 사용자의 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 방법.
테스팅의 목적
▶ 주요 이유 - 잔존 결함 발견 >> 잔존 결함이 있는 채로 출시했다가 후에 발견하면 유지보수 비용이 많이 들어! 그전에 찾아내야 됨. - 개발 시스템 / sw자신감 부여 >> 품질 수준에 대한 자신감 획득과 정보 제공 - 결함을 미연에 방지 - 명세를 충족 확인 >> 소비자의 요구사항에 만족하는지를 확인한다! - 사용자 및 비즈니스의 요구 충족 확인 - 비즈니스 리스크를 감소시키는 정보 제공(발견된 결함 기반의 수치 데이터 제공) >> 리스크는 큰 것부터(시간이 많지 않아. 출시시키고 나중에 잡을 수 있는 작은 것들보단 큰 것부터!)
▶ 기타 이유 - 개발 프로세스 점검, 이슈 제거 - 논리적 설계의 구현 검증 - 시스템 / sw가 적절히 동작함을 확인
▶ 테스팅의 목적은 테스트의 상황이나 관점에 따라 달라질 수 있다.
무슨 말인가 하면, 개발과정 : 소프트웨어의 결함을 찾아내고 수정하기 위해서 가능한 많은 장애의 원인을 발생시킴. >> 많은 결함을 발견하기 위해! 인수과정 : 예상된 대로 시스템이 동작하는지 확인하고, 요구사항에 맞는지 확신을 얻는 과정. >> 말 그대로 사야 되니까 제대로 동작하는지 확인을 해야지! 품질 평가 : 특정시간에 시스템을 출시하는 것의 리스크를 개발 프로젝트 관련자에게 전달. >> 개발 시간은 항상 정해져 있으니까. 유지 보수 : 변경사항을 추가적으로 개발하는 중에 새로운 결함이 유입되었는지 확인하는 테스팅 과정 포함. 운영 : 신뢰성 또는 가용성과 같은 시스템의 특성을 평가.
테스팅의 목적
옛날 방식의 테스트 개념은 소프트웨어의 정상 작동 여부 확인이 목적.
현재 테스팅 개념은 사용자의 기대수준과 요구사항에 맞게 구현되고 동작하는지 확인하는 것이 목적. (버그는 없는지)
▶ 최종 목표 : 결함 데이터를 근간으로 소프트웨어의 리스크 정보를 정략적 수치화하여 의사 결정권자에게 전달.
1.1.1 SW 시스템 관점에서 테스팅의 필요성
▶ SW 관점에서 테스팅(SW테스팅이 왜 필요할까?)
- 비즈니스 애플리케이션에서 소비자 제품에 이르기까지 폭넓게 생활의 많은 부분 사용 >> 비중은 계속 증가.
- 금전적인 손실, 시간낭비, 비즈니스의 이미지 손상(== 제품 잘못됐다고 하면 사용자는 그 제품을 더 이상 쓰지 않음), 그리고 부상이나 사망에 이르기까지 다양한 심각성
- 테스팅은 소프트웨어 시스템의 문제를 최소화하기 위해 필요.
▶ 소프트웨어 결함 - 세 가지 구분해야 돼!오류, 결함, 장애!
- 오류(error) : 인간의 행위, 실수 (== 사람이 실수하는 것)
>> 코드 작성, 소프트웨어나 시스템 또는 문서 작성 시 결함을 만드는 오류.
- 결함(defect) - 요구된 기능의 부정확한 처리를 말하며 이것으로 인해 고장 또는 장애를 발생시키는 원인이 됨(장애가 발생할 수 있는 원인)
>> 시간적인 압박, 복잡한 코드, 기반환경의 복잡성, 기술이나 시스템의 변경, 수많은 시스템 상호 간의 연동.
>> 결함은 장애의 원인(환경, 기술이나 시스템의 변경, 요구된 기능의 부정확한 처리)
>> But,모든 결함이 장애를 발생시키는 것은 아니다.★★
- 장애(failure) : 코드에 존재하는 결함의 실행 또는 환경적 조건에 의해 부정확하게 처리되는 것을 의미함.
>> 결함 + 환경적인(방사, 전자기장, 물리적 오염 등) 조건.
소프트웨어의 결함을 발생시키는 2가지 원인
1. 인간의 소스코드 실수 - 인간의 실수 또는 시스템 코드에 결함을 야기시켰을 때. 2. 주변환경에 의한 결함 - 전자파, 자석, 공해, 자연현상 등과 같은 주변 환경의 영향으로 소프트웨어 또는 시스템이 사용하는 하드웨어 영향을 주 오류
소프트웨어 결함의 원인 문제가 나오면 대부분 결함이 정답이래!! 기억하고 가래!!
1.1.2 테스팅이란 무엇인가??
▶ 테스팅
- 응용 프로그램 또는 시스템의 동작과 성능, 안정성이 사용자가 요구하는 수준을 만족하는 지 확인하기 위해 결함을 발견하는 메커니즘
>> 정상 동작 여부 확인.
>> 사용자의 기대 수준과 요구사항에 맞게 구현되고 동작하는지 확인. == 벨리데이션
>> 개발 프로젝트의 리스크 정보를 정량적 수치로 의사결정권자에게 전달.
- 초기 개발 산출물 -> 리뷰.(초기엔 코드가 없어서 리뷰를 해. 리뷰는 정적분석이라고도 하는데 코드없이 테스팅하는것을 말함. / 동적 분석이라는 것도 있는데 얜 코드를 실질적으로 돌려보는걸 말해)
- 테스트 케이스 작성 과정(결함 예방 활동)
- 다양한 테스팅 활동. (단통시인)
1.1.3 SW 개발, 유지보수, 운영 시 테스팅의 역할
▶ 테스팅
- 개발 초기의 요구사항 분석 단계부터 리뷰와 정적분석을 통해 정적으로 시작
>> 각각의 개발 단계에 대응하는 테스트 레벨별(단위, 통합, 시스템, 인수) 테스팅
- 컴포넌트, 통합 테스팅은 개발 조직 중심으로 수행
- 시스템이 갖춰진 이후의 테스팅은 독립적인 테스트 조직 중심
- 테스트 레벨에 따른 테스트
>> 소프트웨어 품질을 높이고, 결함 발생 가능성을 최소화하는 게 목적.
- 유지보수 활동으로 변경 및 단종되거나 환경이 변경
>> 변경된 환경에 대해 운영 테스팅(리그레이션 테스팅)
>> 변경으로 인한 결함과 장애를 예방
- 계약상 요구조건 및 산업에 특화된 표준 만족
1.1.4 테스팅과 품질
▶ 품질 특성 및 향상
- ISO /IEC 9126 소프트웨어 제품 품질
>> 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 높아야 돼!!
(외울 때! 기사신효이성 - 기사가 신효를 지키려고 이성을 붙잡는다. )
- 품질 향상
>> 테스팅 결함을 찾아내고, 발견된 결함을 수정한다.
- 품질 보증
>> 이전 프로젝트를 통해 많은 테스트 경험과 정보 확보
>> 발견되니 결함의 근본 원인 이해를 통해 프로세스 개선
>> 결함의 재발 방지
- 개발 표준이나 교육 훈련 그리고 결함 분석
1.1.5 테스팅, 얼마나 해야 충분한가?
▶ 적절한 테스팅 정도
- 리스크 수준을 고려
- 프로젝트 제약 사항
>> 기술적인 내용, 비즈니스, 제품, 프로젝트 리스크, 시간, 비용
- 테스팅은 테스트된 sw나 시스템을 다음 단계로 전달하는 데 있어 프로젝트 이해 관계자들이 릴리즈 결정을 내릴 수 있도록 충분한 정보를 제공
- 적절한 릴리즈를 결정해야 한다.(다른 회사보다 먼저 출시해야 하며 안전한지 정보를 제공할 수 있을 만큼 테스팅이 진행되어야 한다.)
커버리지
1. 커버리지를 높이면 결함이 줄어들어 품질이 높아짐. 2. 리스크를 반영해 커버리지를 높이면 테스트의 완성도가 높아짐. 3. 커버리지는 어떤 커버리지인지 명시해 주지 않으면 의미가 없음. 4. 테스트 케이스의 수를 늘린다고 커버리지가 높을 수 있는 것은 아님!!!! ★
* 테스트 모니터링과 제어:관리자 역할(감시자 역할)로 계획, 분석, 설계, 구현, 실행, 완료단계까지 다 들어가.
* 테스트 스위트 / Test Suite : 테스트케이스들을 하나로 묶은 것.테스트스크립트 세트.
* 테스트 하네스 / Test Harness : 자동화된 테스트 지원 도구, 다양한 환경에서 프로그램 단위를 작동시키고 그 작동과 출력을 모니터하기 위해 사용되는 소프트웨어와테스트데이터의 집합. >> 테스트하기 위한 환경이라 알아두면 돼.
*** 테스트 모니터링과 제어는 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행 까지 테스트 모니터링과 제어는 계속 되어야 해!!! 한 단계에서 필요한게 아니야. 테스트 계획단계에서 테스트 모니터링과 제어가 시작하는거 X.
테스트 프로세스의 기초 (빨간 글씨들은 다 외운다 생각해야돼!!)
테스트 계획과 제어
- 테스트 목적/ 목표 설정 및 대상 연구 - 테스트 종료 조건 - 테스트 관리 및 제어 - 테스트 전략 개발 - 테스트 추정 - 모니터링(리포팅) - 리스크 분석 - 조직 구성 - 리포팅 계획/ 설계 - 전략 수립 - 테스트 계획 - 진행 리포팅
외워라 : 테스트 종료조건은 테스트 계획과 제어의 산출물!
테스트 분석과 설계
- 테스트 베이시스 검토 - 테스트 환경 구축에 필요한 기반시설 및 도구 식별 - 테스트 용이성 평가 - 테스트 베이시스와 테스트 케이스의 추적성 설명할 수 있게 만들어져야돼 - 테스트 컨디션/ 요구사항/ 데이터 식별 -논리적(hight level) 테스트 케이스 설계 및 우선 순위 선정
외워라 : 테스트 베이시스 검토(글로 작성하는 것)는 테스트 분석과 설계에서 들어가는 거야!
테스트 구현과 실행
- 테스트 케이스 최종 구현과 우선 순위 선정 - 테스트 프로시저 생성 및 우선 순위 선정 - 테스트 베이시스와 테스트 케이스의 추적성 확인 및 업데이트 - 데스트 데이터 생성 - (재)테스트 실행(결과 및 이슈 기록) - 테스트 스위트 생성 - 기대 결과와 비교 - 테스트 환경의 올바른 구축 확인
종료 조건의 평가 레포팅
- 종료 조건의 달성 여부 평가 - 최종 테스트 보고서 작성
테스트 종료의 조건
- 산출물 확인 데스트웨어 보관 - 테스트프로세스 평가(진단)
▶ 테스트 프로세스
- 테스팅 관련 활동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 테스팅의 구성요소를 엮어 주는 역할.
>> 테스트 베이시스 : 계획단계 부터 필요. 설계시 반드시 요구 -> 문서화를 해야 한다.
>> 테스트 조직: 계획단계 부터 필요, 실행 단계에서 다수 인력 필요
>> 테스트 전략
>> 테스트 기법 : 분석 및 설계 단계에서 필요.
>> 테스트 대상 : SW는 가장 이른 시기 준비, 늦어도 실행 단계에서는 필수.
>> 테스트 기반 설비 및 환경 : 실행 단계 전에 구축.
- 체계적으로 발견한 결함과 관련 정보를 바탕으로 정량적(수치적)으로 개발 프로젝트에 조언(분석한 리스크) 제공.
테스트 계획과 제어(통제)
▶ 테스트 제어 - 계획 대비 실제 진행 상황을 비교하는 지속적인 활동 - 계획과의 차이 확인 >> 지속적인 모니터링 - 제어 작업 >> 테스트 결과에 대한 측정과 분석 >> 테스트 진척 사항, 완료조건의 모니터링과 문서화 >> 테스트 계획과의 차이 교정 >> 테스팅의 진행과 변경에 대한 의사 결정 활동 >> 테스팅 계획은 테스팅의 제어와 모니터링 활동으로부터 받은 피드백을 반영
▶ 테스트 계획과 제어 - 주요 활동 >> 테스트 목적/ 목표 및 대상 연구 >> 테스트 전략 개발 >> 테스트 완료 조건의 결정(80~90%) >> 테스트를 추정 >> 테스트 조직 구성 >> 테스트 계획 활동 >> 테스트 관리 및 제어 >> 리포팅
테스트 프로세스
▶ 1-1. 테스트 계획 - 테스트 계획은 테스팅의 미션과목표를 정의하고 이를 만족시키기 위한 테스트 활동들을 수립하는 과정. - 테스트 계획은모니터링 및 통제 활동의 피드백에 따라 조치를 할 수 있도록 수립되어야 한다.
★★★계획 단계에서 해야하는 일★★★ >> 1.테스트를 위한 자원 파악(인적 자원, 테스트 환경, PC사양 등). >> 2. 테스트 정책 및 테스트 전략 수립. >> 3. 테스트 분석 및 설계업무 일정 관리. >> 4. 테스트의 적용, 실행, 평가에 대한일정 관리. >> 5.완료 조건 결정.
▶ 1-2. 테스트 제어 - 테스트 통제는 실제 진행 상황과 계획을 비교하고 보고 하는 활동. - 여기에는 프로젝트의 미션과 목표를 위해 조치가 이루어질 수 있음. - 이를 위해 프로젝트의 진행이 지속적으로모니터링 되어야 할 것.
★ ★ ★제어 단계에서 해야 하는 일★ ★ ★ >> 1. 결과 측정 및 분석. >> 2. 모니터링 및 문서화의 진행, 테스트 범위, 종결 기준. >> 3. 결과 반영(수정, 변경 등) 활동. >> 4. 의사 결정
- 테스트 계획과 제어 단계는 테스트 분석과 설계, 테스트 구현과 실행, 종료 조건의 평가 레포팅의 모든 단계를 모니터링 해줘야돼.
▶ 2. 테스트 분석과 설계 - 테스트 계획에서 제시된 목표를 테스트 케이스로 반영.
>> 일반적이고 추상적인 테스팅 목적을실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환하는 활동.
★ ★ ★분석과 설계단계에서 해야하는 일 ★ ★ ★ >> 1. 테스트 베이시스 리뷰(가장 기초 문서, 요구사항 명세서, 설계 계획서, 디자인 등).*테스트 베이시스 :요구사항 등 테스트 케이스의 토대. >> 2.테스트 대상 아이템 또는 명세, 구조 분석을 통해 테스트 상황을 식별하고 우선순위 선정. >> 3.테스트 케이스 설계와 우선 순위 선정. >> 4. 비공식적인 기법으로 테스트 케이스 추가 도출 및 보완 >> 5. 테스트 상황과 테스트 케이스에 필요한 테스트 데이터 식별. >> 6.테스트 환경 구축에 대한 디자인과 요구되는 기반 시설 및 도구 식별.(완전한 구축이 아니라 어떠한 환경에서 할지 정하는 것)
▶ 3. 테스트 구현 및 실행 (테스트 프로시저, 테스트 스크립트 키워드 나오면 테스트 구현 및 실행!) - 효과적/ 효율적 테스트를 위해 테스트 케이스를 조합하고, 테스트 프로시저(==모듈시스템이 있으면 정하는 순서)/ 테스트 스크립트를 작성.(자동화)
- 테스트 환경이 구축되어 있어야 한다.(환경 완성돼있어야 됨.)
★ ★ ★ 구현 및 실행 단계에서 해야하는 일 ★ ★ ★ >> 1. 테스트 데이터 생성. >> 2. 효과적인 테스트를 위해 테스트 프로시저 생성. >> 3. *테스트 하네스 준비. >> 4. 테스트 환경이 제대로 설정되었는지 확인. >> 5. 계획된 절차에 따라 테스트 케이스를 직접 또는 툴을 사용하여 수행. >> 6. 테스트 실행 결과를 기록하고 테스트 수행 대상 및 소프트웨어 버전을 기록.
>> 7. 예상 결과와 실제결과를 비교.
>> 8. 불일치하는 결과가 나오는 원인을 기록.
>> 9. 각각의 불일치에 대한 반복적인 활동.
++ 주요 작업(위의 해야하는 일과 같은데 같이 읽어보고 공부해. 아마 비슷할꺼. 키워드 위주로 봐봐.)
- 테스트 케이스 개발, 구현과 우선 순위 설정
- 자동화 테스트 스크립트 작성
- 테스트 하네스 준비
- 효율적인 테스트 실행을 위해 테스트 수트(테스트 케이스 묶음) 생성
- 테스팅 실행(겨로가 기록 -식별과 버전 관리)
- 기대 결과와 비교 -> 예상 결과와 실제 결과 간의 차이에서 오는 불일치를 인시던트 또는 결함으로 보고 -> 불일치 원인 파악(원인을 파악하는건 테스터가 하는 일, 원인을 찾아서 수정하고 제거하는 건 개발자가 하는 일.)
- 예상과 실제의 불일치로 테스트 케이스 결함, 테스트 정황 결함, 어플리케이션 결함이 있을 수 있다.
- 불일치를 조치한 결과를 확인하기 위한 테스트 활동 반복
>> 수정이 되었는지 테스트 실행 -> 확인 테스팅(Confirmation Testing).
>> 수정으로 새로운 버그가 발생하지 않았는지 전체를 테스트 실행 -> 회귀 테스팅(Regerssion Testing).
- 결함의 유형
>> 기획시 유입된 결함 : 요구사항의 표준 미준수, 테스트 불가능 등.
>> 설계시 유입된 결함: 설계의 표준 미준수, 테스트 불가능 등.
>> 코딩 시 유입된 결함: 코드의 표준 미준주 등.
*테스트 하네스 :
- 테스트 드라이버 + 테스트 스텁.
- 드라이버 : 상향식 테스트, 하위 모듈에서 상위 모듈로의 테스트를 진행
- 스텁 : 하향식 테스트, 상위 모듈에서 하위 모듈로의 테스트를 진행.
▶4-1. 완료 조건의 평가와 리포팅 - 테스트 수행 결과를 목적과 비교하여 평가.
★ ★ ★완료 조건의 평가와 리포팅단계에서 해야하는 일 ★ ★ ★ >> 1. 테스트 계획에 정의된 완료 기준에 따라 테스트 로그 확인. (로그가 나온다? 무조건 완료 조건.) >> 2. 추가 테스트가 필요한지에 대한 평가를 하거나 완료 기준을 변경. >> 3. 이해 관계자들을 위한 테스트 요약 보고 작성.
- 리포팅 내용으로 뭐가 있냐. -> 리포팅에 표현되는 내용.
>> 발견된 결함과 미해결 결함의 추이 및 우선순위.
>> 테스트 진척도. (테스트 어느 정도 진행됐는지.)
>> 리스크 및 메트릭으로 실증된 조언.
*메트릭 : 메트릭이란 지연, 오류 비율에서 사용자 가입까지 시간에 따른 모든 환경 변화를 추적할 수 있는 숫자 값.
>> 테스트 환경의 가용성.
>> 테스트 커버리지, 결함 발견 효과성/ 효율성, 품질 평가 결과, 결함 상태별 결함수.
>> 소프트웨어 사이즈 대비 결함 수 등.
▶ 4-2. 테스트 마감 조건과 리포팅
- 모든 테스트 활동에서 경험, 테스트 도구, 사실, 통계를 종합하기 위해 데이터를 수집하고 완료.
★ ★ ★테스트 마감 조건과 리포팅 단계에서 해야하는 일 ★ ★ ★ >> 1. 계획된 산출물이 산출되었는지에 대한 확인, 개별 요소에 대한 보고완료, 또는 아직 수행 중인 활동의 변경에 기록에 대한 이슈제기.
>> 2. 시스템 인수와 관련된 문서 확인. >> 3. 유지보수 조직에 테스트 도구 인계. >> 4. 사후 관리 및 테스트 성숙도 향상 수준 분석.
++
▶ 테스트 마감 활동
- 산출물 확인, 테스트 웨어(산출물) 보관(-> 다음 프로젝트를 위해)
- 테스트 프로세스 평가 심사.
- 주요활동
>> 테스트 결과 마감(예정된 산출물, 인시던트 레포트 종료, 해결되지 않은 요구사항에 대한 처리, 시스템 인수에 대한 문서화 등)
>> 테스트웨어, 테스트 환경, 테스트 기반 설비를 차후에 사용위해 마감, 보관.
>> 테스트 웨어를 유지보수 조직에 이관
>> 테스트 프로세스 심사 및 개선 사항
>> 이후 릴리즈나 프로젝트, 테스트 성숙도의 개선에 지침이 될 수 있도록 테스트 프로젝트를 통해 얻은 교훈을 분석
효과적 / 효율적의 차이(시험엔 안나와도 알아는 둬볼까.)
효과적(Effective)
- 계획되었거나 원했던 테스트 결과 산출. - 효과적 테스터는 테스팅 노력으로부터 어떤 결과를 도출 할 것인지 결정함.
- 결함을 발견하기 위한 활동. - 테스트는 공정상(한 제품이 완성되기까지 거쳐야되는 단)의 결함을 발견할 수 있다. - 시스템이 정지되는 결함과 정지가 되지 않는 결함이 모두 포함된다.
디버깅
- 결함의 원인을 찾고 코드를 수정하는 개발 활동. - 디버깅 후 테스터에 의해 확인 테스팅을 수행하여 결함이 제대로 고쳐졌는지 확인 필요. - 개발자가 수행.
테스팅의 특성 ★
▶ 완벽한 테스팅은 불가능하다. - 한 프로그램 내의 내부 조건이 무수히 많을 수 있다. - 입력이 가질 수 있는 모든 값의 조합이 무수히 많다. - 이벤트 발생 순서에 대한 조합도 무수히 많다. ▶ ★★★테스트는 결함이 없음을 보이려는 것이 아니다. ★★★ - 테스팅은 결함이 존재함을 밝히는 활동. ▶ 본인이 만든 프로그램의 결함을 발견하기는 쉽지 않다, ▶ 현실적인 테스팅의 목적. - 주어진 리소스(시간, 인력 등)로 리스크가 높은 시스템 부분의 결함을 발견할 확률을 극대화 >> 리스크의 최소화.
테스팅의 일반적 원리 7가지
1. 테스팅은 결함이 존재함을 밝히는 활동이다. - 잠재적으로는 존재하는 결함 줄임. >> But, 결함이 없다고는 증명할 수 없다. 2. 완벽한 테스팅은 불가능하다. - 리스크가 높은 것부터 해결해 나가야 함.(중요도 순서) >> 한 프로그램 내에 내부 조건이 너무 많음. >> 입력이 가질 수 있는 모든 값의 조합이 무수히 많다. >> 이벤트발생시 발생 순서에 대해 조합도 무수히 많다. >> 리스크에 따라 테스트 강도 높게 수행 -> 실제 완벽하게 수행하는 것은 불가능하다. 3. 개발 초기에 테스팅 시작한다. >> 개발의 시작과 동시에테스트를 계획하고 전략적으로 접근. >> 요구사항 분석서와 설계서 등의 개발 산출물 분석후 테스트 케이스 도출. 4. 결함은 집중되어 있다. - 특정 모듈에 집중되어 있음. (넓게 퍼져있지 않음.) >> 결함이 집중돼있는 곳을 잡아야 돼. >> 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보임. >>결함의 집중은 운영상의 장애를 초래함. (운영상의 장애 ex : 복잡한 구조의 모듈, 다른 모듈과 다량의 상호작용을 하는 모듈, 개발 난이도가 높거나 최신 기술을 사용한 모듈, 크기가 큰 모듈, 경험이 미흡한 팀에서 개발한 모듈, 새롭게 개발한 모듈) 5. 살충제 패러독스. - 면역력이 생기는 거 >> 테스트 케이스를 늘 똑같은 걸 사용하면 버그 찾기 쉽지 않음. >> 주기적으로 업데이트된 테스트 케이스 필요. >> 동일한 테스트 케이스로 동일한 테스트를 반복하면 결함을 찾기 어려워진다. >> 더 많은 결함을 찾기 위해서는 테스트 케이스를 정기적으로 리뷰하고 개선해야 함. 6. 테스팅은 정황에 의존적이다. >> 테스트는 정황과 도메인(대상 영역)에 따라 다르게 수행되어야 함.(똑같은 테스트 케이스를 쓰는 게 X) >> 모든 테스트에 적용되어야 하는 것 : 테스트 프로젝트 기획, 표준적인 기법 적용, 독립적인 테스트 환경, 효율적/ 효과적 테스트 팀 조직, 정식 리포팅 등. 7. 오류 - 부재의 궤변. - 개발된 소프트웨어를 사용자가 원하는 데로 만들지 않으면(요구사항 충족 ㄴㄴ, 요구 수준 만족 ㄴㄴ) 결함을 수정해도 필요(또는 의미)가 없음.
테스팅에 대한 오해
1. 테스트는 완벽하게 수행될 수 있다. >> X 2. 아무나 테스트를 수행할 수 있다. >> X 3. 테스트는 그리 어려운 작업이 아니다. >> X 4.SW나 시스템이 잘 실행됨을 보여주는 것이다 >> X >> 결함이 있다는 것을 보여주는 것. 결함을 잡고 리스크를 낮춘다!! 실행이 잘되는 걸 보여주는 건 개발자의 역할! 5. 테스트는 개발 이후의 작업이다. >> X 개발 초기의 작업. 6. 개발 일정에 따라 테스트는 생략 될 수 있다. >> X 7. 시간, 인력이 부족해서 테스팅을 제대로 못한다. >> X 말도 안 되는 내용.
테스트 프로세스와 산출물
계획 / 통제(제어) - 조직 구성 테스트 베이시스(기초문서- 엑셀파일) 필요. ▼ 분석 및 설계 - 테스트 기법 필요, 테스트 베이시스 필수, 테스트 설비 및 환경 구축. ▼ 구현과 실행 - 테스트하는 거. ▼ 완료 조건의 평가와 리포팅 - 테스트 커버리지 90퍼센트 했으니까 그만 끝내자. 마감 보고서 쓰기(리포팅). ▼ 테스트 마감활동 - 결함 보고서 쓰기.
오류(에러) : 사람의 실수에 의한 에러, 원인은 사람. 결함 : == 결점(Defect), 버그(bug), 에러에 의해 발생하는 것, 에러가 실제로 코드에 구현(내재화) 된 것. 장애 : 결함을 가진 SW 실행하면 발생(눈에 보이게)하는 것, 눈에 보여지는 것.
★ 모든 결함이 장애로 가지는 않는다. ★ 결함이 있어도 정상적으로 실행될 수 있다.
소프트웨어 결함의 원인
소프트웨어 결함 : - 인간의 실수 : 사람의 실수는 소프트웨어 또는 시스템 코드에 결함을 야기시킬 수 있다. - 주변환경에 의한 결함: 전자파, 자석, 공해, 자연현상 등과 같은 주변 환경의 영향으로 소프트웨어 또는 시스템이 사용하는 하드웨어에 영향을 주어 오류를 발생시킬 수 있다.(ex. 컴퓨터 속에 먼지나 벌레가 들어가서 전원이 제대로 안 켜지는 경우)
ISTQB 답) 결함은 소프트웨어에서만 문제를 야기시킨다 >> X, 결함은 소프트웨어와 하드웨어에서 모두 다 문제를 야기시킬 수 있다. >> O
소프트웨어의 개발, 유지보수, 운영과 테스팅
▶ 소프트웨어 개발 과정에서의 테스팅은? - 개발 초기부터 정적 분석(코드 문을 보면서 테스팅하는 것 >>정적분석은 리뷰랑 연계됨)을 통해 시작한다. - 개발 단계에 대응하는 테스트 레벨에 따라 테스팅을 실행한다. - 테스트 조직의 독립성 문제.
▶ 운영 테스팅 - 기존 운영 시스템의 변경/ 단종/ 환경 변화 등으로 변경된 시스템에 대한 테스팅.
테스팅과 품질
▶ 소프트웨어 품질 특성 : 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성
▶ 테스팅 : 기능 테스팅, 비기능 테스팅
어느 정도의 테스팅이 적절한가? ▶ 테스팅의 제약 사항 - 테스팅을 많이 할수록 좋겠지만, 현실적으로는 제약이 있다. - 대표적인 4가지 제약 사항 :일정, 비용, 조직의 성숙도, 테스터의 역량. ▶ 적절한 테스팅의 정도는? - 리스크 수준을 고려(리스크 큰 것부터 제거) - 기술적인 내용, 비즈니스, 제품 리스크, 프로젝트 리스크, 시간, 비용 등을 고려.
소프트웨어 테스팅의 목적 1
옛날 방식의 테스트 개념 :
소프트웨어의 정상 작동 여부 확인
현재의 테스트 개념 :
사용자의 기대수준과 요구사항에 맞게 구현되고 동작하는 지 확인
>> 결함 데이터를 근간으로 소프트웨어의 리스크 정보를 정량적 수치화하여 의사결정권자에게 전달
소프트웨어 테스팅의 목적 2
▶ 주요 이유 - 잔존 결함을 발견 - 개발 시스템/ SW 자신감 부여 - 결함을 미연에 방지 - 명세를 충족 확인 >>엑셀 파일 문서(테스트 베이시스 == 요구사항문서) - 사용자 및 비즈니스의 요구 충족 확인 (사용자가 원한 거 충족 됐는지 확인) - 비즈니스 리스크를 감소시키는 정보 제공 (발견된 결함 기반의 수치 데이터 제공)
▶ 기타 이유 - 개발 프로세스 점검 - 논리적 설계의 구현 검증 - 시스템/ SW가 적절히 동작함을 확인
소프트웨어 테스팅의 목적 3
테스팅의 목적은 테스트의 상황이나 관점에 따라 달라질 수 있다. 1. 개발 과정: 소프트웨어의 결함을 찾아내고 수정하기 위해서 가능한 많은 장애의 원인을 발생시킴. 2. 인수 과정: 사용자에게 예상된 대로 시스템이 동작하는지 확인하고, 요구사항에 맞는지 확신을 얻는 과정. 3. 품질 평가: 특정 시간에 시스템을 출시하는 것의 리스크를 개발 프로젝트 관련자에게 전달. 4. 유지 보수: 변경사항을 추가적으로 개발하는 중에 새로운 결함이 유입되었는지 확인하는 테스팅 과정 포함. 5. 운영 과정 : 신뢰성 또는 가용성과 같은 시스템의 특성을 평가. 테스팅은 문서의 리뷰와 함께 정적 분석에 의한 테스트 포함한다.
피벗 테이블을 사용함으로 합계함수나 평균함수를 사용하지 않고 끌어다 쓰기만으로 함수를 대체할 수 있는 동영상을 보았다.
그래서 공부해 보는 피벗 테이블.
피벗 테이블
피벗 테이블로 확인 하고자 하는 데이터 영역 선택 > 삽입 > 테이블 > 피벗 테이블 클릭 > 새 워크시트 선택 후 확인.
일단 피벗 테이블을 만들고자 하는 데이터를 선택해서 피벗테이블을 만들어 준다.
피벗 테이블 필드에 만들고자 했던 데이터의 셀들이 필드로 선택할 수 있게 만들어졌다. - 필터 : 특정 값에 대한 데이터만 보고 싶을 때. - 행 : 데이터를 보고 싶은 기준. - 값 : 기준에 맞추어 보고 싶은 값.
피벗 테이블을 만들면 위 처럼 화면이 나옴.
값 영역에서는 합계나 평균을 구할 수 있으니 값 필드 설정을 통해 필요한 유형을 선택해 준다.
합계 데이터였던 값을 평균으로 바꿔 사용한 결과 값 - 연령대에 따른 평균 키와 몸무게 값
원하는 데로 행과 값에 필드를 선택해서 넣어준다.
< 피벗 테이블을 만들 수 없다고 오류가 뜨는 경우 확인해 봐야 되는 것. > 1. 표의 첫 번째 줄에 행 내용이 비어있을 경우 - 필드 이름이 잘못되어 있다는 오류로 필드명이 누락되었을 경우 나옴. >> 빈 내용 확인 후 넣어주면 됨. 2. 표의 첫번째 줄의 행이 두줄로 작성되어 있는 경우 - 필드가 쪼개질 수는 없어서 오류가 뜸.
< 데이터가 변경되었을 경우 > - 데이터가 바뀌거나 변경되면변경된 데이터를 사용한 피벗 테이블에 가서 마우스 오른쪽 버튼 클릭 후 새로고침버튼 눌러줘야수정한 내용 업데이트됨. - 새로운 데이터는 아래 방향으로 누적되게 하고, 새로운 필드는 오른쪽 방향으로 추가를 하는 습관을 들여 피벗 테이블 만들 때 문제가 없게 하는 게 포인트!
피벗 테이블을 꾸며 줄 수 있는 기능이 있음. 자동 디자인 기능. : 메뉴 > 디자인 또는 메뉴 > 피벗 테이블
1. 기획(하나로 모으기 위해 VLOOKUP함수사용) 2. 가공(숫자/ 텍스트/ 날짜 시간을 입맛에 맞게 3. 집계(집계 함수, SUMIF, COUNTIF함수와 피벗 테이블)
1. VLOOKUP함수
서로 다른 테이블에서 특정 키값을 기준으로 내가 원하는 값을 불러와서 적어주고 싶다면 VLOOKUP 함수!
형식 : =VLOOKUP(조회하려는 항목, 찾고자 하는 위치, 반환할 값이 포함된 범위의 열 번호, 근사값 또는 정확히 일치)
엑셀은 범위가 상대참조를 기본으로 동작. 절대 참조로 걸어주는 방법은 F4클릭(숫자 앞에 $를 넣어 고정해 줄 수 있음)
그렇게 해봤는데 오류가 남.
찾을 이름을 입력하고 찾고자 하는 위치를 절대 참조로 달아두고 열번호 넣고 정확히 일치로 찾기 위해 false를 넣어 해봤는데 #Ref! 오류라니... 뭐가 문제일까.
왜 오류 나는지 아는 사람.
왜 오류 나는지 알았다. 당연히 I열만 범위에 넣어 줬으니 답이 없지. J열까지 넣어 줘야 제대로 된 값이 나옴.
이런 말같지도 않은 상황도 다 제대로 알지 못한 상태에서 해서 그런 거라 생각하면서 다시 집중하자.
왜 오류 나는지 아는 사람 등장.
찾고자 하는 위치에 불러오고 싶은 테이블만 존재한다면 열과 열로 범위를 정해줘도 된다 함. 이런 상황이면 이 방법이 오류가 더 안 날 것 같음.
찾고자 하는 위치에 테이블만 있다면 열대 열로 맞추어도 됨.
분할해줘야 되는 데이터를 위해
=LEFT(분할 값, 왼쪽에서 몇 글자까지 가져올지), =RIGHT(분할 값, 오른쪽에서 몇 글자까지 가져올지)
이렇게 잘라주면 값들이 텍스트로 변경되기 때문에 숫자로 인식시켜 주기 위해 *1을 해준다.
이걸 하던 중에 뭔가 몸무게가 3자리 수일 수도 있고 c#에서 Split 함수가 생각나서 엑셀에서도 있는지 찾아봤더니 있다!
TEXTSPLIT 함수 사용 버전
여기서도 숫자를 텍스트로 만들었기 때문에 =VALUE()를 사용해 숫자로 값 변경. ex > =VALUE(TEXTSPLIT(F13,"/"))
근데 이 함수를 쓰면 자동으로 나누어져서 바로 옆칸에 들어가짐. 옆에 셀은 다른 함수를 쓸 수가 없다. 아마 매개변수로 이것도 선택해 줄 수 있을 듯했지만 찾아보니 나눈 문자열을 가로로 분리할지 세로로 분리할 지만 나온다.
그래서 찾아본 TEXTSPLIT함수의 매개변수들.
TEXTSPLIT 함수
형태 : =TEXTSPLIT(텍스트, 열 구분 문자, 행 구분 문자, 공백 무시, 일치 모드, 에러 표시 문자) 열구분 문자와 행 구분 문자로 열로 나눌지 행으로 나눌지 선택됨. 공백 무시에 TRUE를 쓸 경우 공백 무시, FALSE일 경우 공백 그대로 유지, 당연히 생략하면 FALSE로 인식. 일치 모드에 0 또는 FALSE 구분 문자 대소문자 구분, 1 또는 TRUE면 대소문자 구분 X 에러 표시 문자는 에러가 발생할 상황에 표시될 문자를 지정.
SUMIF 함수, COUNTIF 함수
SUMIF함수 형태 : =SUMIF(주어진 조건을 찾을 영역(범위), 선택한 영역에서 찾을 조건(값), 위의 영역에서 조건에 맞는 셀에서 실제로 더할 값의 영역) COUNTIF함수 형태 : =COUNTIF(범위, 선택한 범위에서 찾을 값)
키 합계 =SUMIF(주어진 조건을 찾을 영역(범위), 선택한 영역에서 찾을 조건(값), 위의 영역에서 조건에 맞는 셀에서 실제로 더할 값의 영역)
인원 수 계산 COUNTIF함수 형태 : =COUNTIF(범위, 선택한 범위에서 찾을 값)
using System;
using System.Collections.Generic;
using System.Linq;
public class Solution {
private int StringChangeInt(string str)
{
string[] strSplit = str.Split(':');
return int.Parse(strSplit[0]) * 60 + int.Parse(strSplit[1]);
}
public int solution(string[,] book_time) {
int answer = 0;
int[] keyArr = new int[book_time.GetLength(0)];
List<(int, int)> list = new List<(int, int)>();
List<int> roomCheck = new List<int>();
for (int i = 0; i < book_time.GetLength(0); i++)
{
list.Add((StringChangeInt(book_time[i, 0]), StringChangeInt(book_time[i, 1])));
}
var sortlist = list.OrderBy(o => o.Item1);
foreach((int inRoom, int outRoom) room in sortlist)
{
int num = roomCheck.FindIndex(n => n <= room.inRoom - 10);
if (num == -1)
{
roomCheck.Add(room.Item2);
}
else
{
roomCheck[num] = room.Item2;
}
}
answer = roomCheck.Count;
return answer;
}
}
