(주간컴공) 제2과목 소프트웨어 개발 / 어플리케이션 테스트 관리

S1. 어플리케이션 테스트 분류

테스트의 필요성 : 오류를 예방하여 신뢰도 향상

1. 기본원리와 특징

  - 완벽한 테스트는 불가능

  - 상황에 맞게 테스트

  - 파레토법칙 : 20%의 원인이 80%의 결함을 가짐

  - 살충제 역설 : 같은 테스트를 반복하면 오류발견x

  - 오류부재의 궤변 : 사용자 요구사항 만족x

2. 시각(입장)

사용자 : 검증테스트 vs 개발자 : 확인테스트

3. 테스트 기반

  - 명세 기반 테스트 : 요구사항 명세서를 테스트 케이스(항목)으로 만들어서 테스트

  - 구조 기반 테스트 : SW내부 흐름에 따라 테스트 케이스르 만들어서 테스트

  - 경험 기반 테스트 : 비슷한 SW의 테스트 경험으로 테스트 케이스를 만들어서 테스트, 빠르나 정확도가 떨어짐

4. 실행여부

1) 정적테스트 : 개발초기, 비용감소

2) 동적테스트

  - 화이트박스 : 초기수행(논리적인 경로 테스트), 기초 경로테스팅(복잡성 테스트), 제어 구조 테스팅(조건, 반복, 흐름), 문장검증기준(모든 구문을 한번이상 수행했는가), 분기검증기준(모든 조건물을 한번이상 수행했는가), 조건검증기준(모든 조건문의 참, 거짓을 한번이상 수행했는가)

  - 블랙박스 : 개발 후반 수행(기능테스트), 동치분할(정상 및 비정상 인풋으로 결과 확인), 경계값 분석(입력조건의 경계값으로 테스트), 원인효과그래프(입출력 상황을 분석하여 높은 효율로 테스트), 오류예측검사(과거의 경험, 테스터의 감각으로 테스트(추가적)), 비교검사(동일한 테스트를 여러버전에 진행하여 결과 테스트)

5. 목적

  회복 : 복구가 잘 되는가 / 안전 : 보호가 잘 되는가 / 강도 : 과부하를 잘 견디는가 / 성능 : 빠른가 / 구조 : 단순명료한가 / 회귀 : 새코드(수정된 부분의 코드)가 문제가 없는가 / 병행 : 입출력문제가 없는가

 

S2. 개발 단계별 어플리케이션 테스트

주간컴공

1. 단위테스트 (모듈)

2. 통합테스트

비점진적 방식	한번에 통합, 단시간 테스트, 오류파악 및 수정이 어려움
점진적 방식	단계적 통합, 오류수정 용이	하향식 (상 -> 하)	깊이우선	시스템 구조 시각화 용이, 모듈통합시 회귀테스트 진행, 테스트시 종속 모듈은 stub 사용	stub : 상위모듈 테스트를 위한 기능만 가진 시험용 하위모듈
			너비우선
		상향식 (하 -> 상)	상위모듈이 없으므로 인터페이스 역할의 driver 이용, 테스트단위 cluster		driver : 아직 존재하지않는 상위모듈의 역할(인터페이스)을 하는 시험용 모듈 cluster : 드라이버에 적용될 하위모듈의 결합

3. 시스템 테스트 : 실제 사용환경과 유사하게 구성

  -  기능적 요구사항 : 블랙박스 테스트3. 시스템 테스트

  - 비기능적 요구사항 : 화이트박스 테스트

4. 인수테스트 : 사용자가 요구사항을 충족하는지 직접확인, 기능확인, 요구사항 확인

  - 알파테스트 : 개발환경에서 테스트, 사용자와 개발자가 함께

  - 베타테스트 : 일반 사용자들 환경에서 테스트

5. 테스트 프로세스 : 계획 -> 설계 -> 시나리오 -> 수행 -> 결과평가 -> 결함관리

 

S3. 테스트 자동화/성능분석

1. 테스트 자동화 : 휴먼에러 방지

  - 장점 : 자원(인력, 시간) 감소, 품질보장, 일관성(객관적 평가), 시각적 표현, UI없는 서비스도 테스트가능

  - 단점 : 교육 및 학습을 위한 자원(시간, 비용)이 필요함, 상용SW인 경우 추가 비용이 필요함

  1) 유형별 테스트 자동화 도구

2) 단계별 테스트 자동화 도구

2. 결함

1) 결함관리 프로세스

  결함 : 설계와 다른결과, 업무내용과 불일치, 사용자의 기대결과 만족x

  결함관리 DB(모니터링 서비스 제공) : 계획 -> 기록 -> 검토 -> 수정 -> 재확인 -> 보고서 작성

2) 결함 상태 추적

3) 결함의 분류와 심각도

ⓐ 분류

  - 시스템 결함 : 어플리케이션 및 DB의 작동 불능(지연)

  - 기능결함 : 프로세스와 기능의 결과가 기대결과와 불일치

  - GUI결함 : UI비일관성, 표시오류, 부정확한 메시지

  - 문서결함 : 문서, 메뉴얼의 불일치와 의사소통이 원활하지 않음

ⓑ 심각도 : high : 작동불능 / meduin : 흐름에 영향(ex.부정확한 기능) / low : 약간 불편(ex.오타)

3. 어플리케이션 성능 분석

처치량, 경과시간, 응답시간, 자원 사용률

1) 성능분석도구 : 실제 기대하는 성능과 비교했을 때 성능이 저하될 경우 그 원인을 분석하여 성능을 개선하기 위함

시스템에 부하(스트레스)를 줘서 성능을 측정(점검)하는 도구와 어플리케이션 실행중 자원사용량을 모니터링하여 분석과 진단을 하는 도구가 있음

2) 어플리케이션 성능 저하 원인 분석

clean code : 가독성, 의존성 배제, 단순성, 중복 최소화

bad code : 복잡함, 중복됨, 로직이 서로 얽혀있음