카테고리 없음
테스트 결과 분석
by 3604
2024. 9. 24.
1. 테스트 결과 분석
결과 종류
| 오류(Error) |
결함의 원인으로 일반적으로 사람에 의해 생성된 실수 |
| 결함(Defect), 결점(Fault), 버그(Bug) |
에러가 원인이되어 소프트웨어 제품에 포함 |
| 실패(Failure), 문제(Problem) |
소프트웨어 제품의 결함이 실행될 때 발생 |
2. 결함 관리
| 프로세스 |
- 오류 발견
- 오류 등록
- 오류 분석
- 결함 확정
- 결함 할당
- 결함 조치
- 결함 조치 검토 및 승인
|
| 도구 |
- 상용 결함 관리 도구
- QC(Quality Center)
- Clerar Quesst
- JIRA
- 오픈 소스 결함 관리 도구
|
3. 결함 추이 분석
유형
연계 테스트 및 검증
1. 연계 테스트
| 1단계: 단위 테스트 |
기능 동작/결함 여부 확인 |
| 2단계: 연계 테스트 |
데이터 흐름 및 처리 절차, 기능의 정상적 동작 확인 |
| 3단계: 통합 테스트 |
운용 애플리케이션 기능과의 통합 구조 흐름 확인 |
연계 테스트 구간 및 범위
| 단위 테스트 대상 및 내용 |
- 송수신 시스템의 연계 애플리케이션
- 기능 동작 여부 및 결함 여부 확인
- 데이터 추출, 코드 및 데이터 변환, 데이터 반영 여부 확인
|
| 연계 테스트 대상 및 내용 |
- 송신 시스템 연계 애플리케이션
- 연계 서버의 데이터 송수신
- 수신 시스템 연계 애플리케이션
- 데이터 흐름 및 처리 절차, 기능 정상적 동작 확인
|
| 통합 테스트 대상 및 내용 |
- 단위 테스트
- 연계 테스트송신 시스템에서 생성한 데이터가 중계 시스템 거쳐 수신 시스템으로 정상적 수신되는지 확인
|
**DB 연결 기술: 수신 시스템 WAS에서 송신 시스템 DB로 연결하는 DB 커넥션 풀(DB connection pool) 생성하고 연계 프로그램에서 해당 DB 커넥션 이용하는 방식
2. 연계 테스트 케이스 작성 및 명세화
단순 개별 데이터와 데이터 간의 연관 관계
| 단순 개별 데이터 |
- 개별 데이터 유효값 체크
- 유효값이 코드일 경우 코드 테이블에 등록된 값 체크
- 유효한 데이터 타입 체크
- 데이터 길이, 필수 입력 여부 체크
|
| 데이터 간 연관 관계 |
- 데이터 간 상관관계 체크
- 수신 시스템에서 운영 DB에 반영하는 연계 애플리케이션에 등록되어 있지 않은 데이터인지 체크
- 연계 애플리케이션에서 참조하는 테이블에 데이터 없는 경우 데이터 새롭게 등록하는 경우 체크
|
3. 연계 테스트 수행 및 검증
| 연계 테스트 환경 구축 |
- 설치 및 준비 사항
- 연계 서버
- 송, 수신용 어댑터
- 에이전트 설치
- 송수신 운영 데이터베이스
- 연계 데이터 추출 및 반영에 필요한 테이블
- 데이터와 송수신용 연계 애플리케이션
- 협의 사항
- 연계 테스트 일정/절차/방법/소요 시간/환경/환경 구축 기간
|
| 연계 테스트 수행 |
- 연계 애플리케이션 단위 테스트
- 연계 테스트 수행
|
| 연계 테스트 수행 결과 검증 |
- 운영 DB 테이블의 건수 카운트
- 실제 테이블이나 파일 열어 데이터 확인
- 파일 생성 위치와 파일 생성 여부/크기 확인
- 연계 서버 또는 엔진에서 제공하는 모니터링 화면의 내용 확인
- 시스템에서 기록하는 로그 확인
|
테스트 커버리지
1. 테스트 커버리지
| 개념 |
- 테스트 케이스에 의해 수행되는 s/w 테스트 범위 측정하는 테스트 품질 측정 기준
|
기능(Function)
기반 커버리지 |
- 애플리케이션 전체 기능을 모수로 설정하고 테스트
- 실제 테스트가 수행된 기능의 수 측정
- 100% 달성 목표
- UI 많은 시스템의 경우 화면 수 모수로 사용
|
라인(Line)
기반 커버리지 |
- 애플리케이션 전체 코드 라인 수를 모수로 테스트 시나리오가 수행한 코드의 라인 수 측정
- 단위 테스트에서는 라인 기반 커버리지를 척도로 삼기도 함
|
코드(Code)
기반 커버리지
|
- 애플리케이션 테스트 충분성 지표 중 하나로 코드 구문, 조건, 결정 등의 구조 코드 자체가 얼마나 테스트 되었는지 측정
- 프로그램 테스트 수행 정도를 나타내는 값으로 테스트 수행 완벽성 측정 도구
|
코드 커버리지 유형
| 구문(Statement) 커버리지 |
- 구문에 대한 단순 실행 여부 측정
- 프로그램 내의 모든 명령문 적어도 한 번 수행하는 커버리지 테스트
|
| 결정(Decision) 커버리지 |
|
| 조건(Condition) 커버리지 |
- 결정 포인트 내의 모든 개별 조건식 실행하여 측정
|
조건/결정(Condition/Decision)
커버리지 |
|
변경 조건/결정
(Modified Condition/Decision)
커버리지 |
|
다중 조건(Multiple Condition)
커버리지 |
- 결정 조건 내 모든 개별 조건식의 모든 경우의 수(100%) 실행하여 측정
|
분기 커버리지
(Branch coverage) |
- 각 분기 결정 포인트 내 전체 조건식이 적어도 한 번은 참/거짓 결과 수행
|
2. 테스트 결함 식별 및 관리
| 단계별 결함 유입 분류 |
- 기획 단계
- 요구사항 표준 미준수
- 요구사항 불명확/불완전/불일치
- 설계 단계
- 기획 단계 결함
- 설계 표준 미준수
- 기능 설계 불명확/불완전/불일치
- 코딩 단계
- 설계 단계 결함
- 코딩 표준 미준수
- 데이터/인터페이스 결함
- 테스트 부족
- 테스트 완료 기준 미 준수
- 테스트팀-개발팀 의사소통 부족
- 개발자 코딩 실수
|
| 결함 심각도 |
- 관리 항목
- 결함 내용/결함 ID, 결함 유형, 발견일, 심각도, 우선순위, 시정 조치 예정일, 수정 담당자, 재테스트 결과, 종료일
|
성능 분석 및 품질 평가
1. 성능 점검 개요
성능 측정 지표 처응경자
처리량
(Throughput) |
애플리케이션이 주어진 시간에 처리할 수 있는 트랜잭션 수
웹 애플리케이션의 경우 시간당 페이지 수로 표현 |
응답 시간
(Response Time) |
사용자 입력 끝난 후, 애플리케이션 응답 출력이 개시될 때까지의 시간
애플리케이션의 경우 메뉴 클릭 시 해당 메뉴가 나타나기까지 걸리는 시간 |
경과 시간
(Turnaround Time) |
애플리케이션에 사용자가 요구 입력한 시점부터 트랜잭션 처리 후 그 결과의 출력이 완료할 때까지 걸리는 시간 |
자원 사용률
(Resource Usage) |
애플리케이션이 트랜잭션 처리하는 동안 사용하는 CPU 사용량, 메모리 사용량, 네트워크 사용량 |
성능 분석 도구
- Performance/Load/Stress(성능/부하/스트레스) 점검 도구
- Monitoring(모니터링) 도구
2. 성능 저하 원인 분석
데이터 베이스 연결 및 쿼리 실행 시
발생되는 성능 저하 원인 |
- 데이터 베이스 잠금(lock)
- 불필요한 데이터베이스 패치(Fetch)
- 연결 누수(Leak)/부적절한 연결 ᄑᆍᆯ 크기(Pool Size)
- 불완전한 완료(Commit)
|
| 내부 로직으로 인한 성능 저하 원인 |
- 웹 애플리케이션의 인터넷 접속 불량
- 특정 파일 업로드, 다운로드로 인한 성능 저하
- 정상적으로 처리되지 않은 오류 처리로 인한 성능 저하
|
| 외부 호출로 인한 성능 저하 원인 |
|
잘못된 환경 설정이나 네트워크 문제로 인한
성능 저하 원인 |
- 환경 설정으로 인한 성능 저하
- 네트워크 장비로 인한 성능 저하
|
3. 테스트 관리 지원 도구의 분류
| 테스트 지원 도구 |
- 오픈 소스
- 결함 관리: Mantis, Bugzilla
- 테스트 케이스: testlink
- 형상, 버전 관리: CVS, SVN, Git, Bazaar
- 커뮤니케이션: MediaWiki, DokuWiki
- 통합 프로젝트 지원: Trac, nForge, Gorge
- 상용 소스
- 버그 추적: JIRA, TPMS, Test Director, Clear Quest
- 형상 관리: Visual Sourcesafe, IBM Ration Clear Case
- 커뮤니케이션 도구: Confiuence
|
| 정적 분석 지원 도구 |
- 오픈소스: pmd, Find Bug, checkstyle, cppcheck, Corbetura,
- Changeminer, jeniffer
- 상용소스: Coverity, IBM Rational Software, PolySpace
|
테스트 실행 및
로깅 지원 도구 |
- 오픈 소스
- 테스트 프레임 워크: Xunit, TestNG, Fit/FitNess, Jmock, Easymock, Googlemock
- IC(지속적 통합) 도구: CruiseControl, hudson, Jenkinson
- 빌드 자동화 도구: Ant, Maven, Make
- 실행 자동화 도구: STAF/STAX, Selenium
- 상용 소스
- 버그 추적 도구: WinRunner, Jtest, CodeScroll
|
| 성능 및 모니터링 지원 도구 |
- 오픈 소스: Jmeter, OpenSTA, Allmon, Eclipse, TPTP
- 상용 소스: E-Load, LoadRunner, Webload, Eobot
|
4. 소프트웨어 유지 보수
종류
- 하자보수(Corrective maintenance, 수리 보수)
- 기능 개선(Perfective maintenance, 완전 보수)
- 환경 적응(Adaptive maintenance, 적응 보수)
- 예비 조치(Preventive maintenance, 예방 보수)
Bed code
외계인 코드
(Alien Code) |
15년 전 이전에 개발된 소스 코드
개발 시 문서화하지 않았거나, 개발자 없거나 비구조적으로 작성하여 유지보수 어려운 프로그램 |
스파게티 코드
(spaghetti code) |
컴퓨터 프로그램 소스 코드가 복잡하게 얽힌 모습을 스파게티 면발에 비유
작동은 정상적으로 하나 사람이 코드를 읽으며 그 코드 작동을 파악하기 어려운 코드 |
| 알 수 없는 변수명 |
변수나 메서드에 대한 이름 정의 알 수 없는 코드 |
| 로직 중복 |
동일한 처리 로직이 중복되게 작성된 코드 |
유지보수 비용 측정 방법
소프트웨어 유지보수 부작용
| 코딩 |
- 부프로그램, 구문 레이블, 확인자, 논리 연산자 삭제/수정
- 파일 open하고 close하지 않을 경우
- 설계 수정 후 코드 변경하지 않은 경우
|
| 데이터 |
- 지역 상수 및 전역 상수 재정의
- 레코드 구조, 배열 크기 변경
- 플래그 변수, 포인트 변수, 매개 변수 수정
|
| 문서 |
|
5. 소프트웨어 품질 평가
품질 보증
(QA: Quality Assurance) |
- 어떤 항목이나 제품에 설정된 기술적인 요구사항과 일치하는지 적절하게 확인하는데 필요한 체계적/계회적 유형의 활동
|
품질 보증 활동
(SQA) |
- 소프트웨어 엔지니어가 실질적 기술 방법/측정 적용으로 정형화된 기술 검토(FTR)와 계획된 검사를 수행해 품질 설명, 품질 보증 수행
- 궁극적 목적은 소프트웨어 품질 향상
|
| 품질 목표 항목 |
- 정확성(Correctness): 요구사항 충족시키는 정도
- 신뢰성(Reliability): 주어진 시간동안 주어진 기능 오류없이 수행하는 정도
- 효율성(Efficiency)
- 무결성(Integrity): 허용하지 않은 사용이나 자료의 변경 제어하는 정도
- 유지보수 용이성(maintainability): 오류 쉽게 수정할 수 있는 정도
- 사용 용이성(Usability): 쉽게 사용할 수 있는 정도
- 검사 용이성(Testability): 테스트 통해 소프트웨어 결함을 얼마 쉽게 증명할수 있는가
- 이식성(Portability): 다양한 H/W 환경에서도 운용 가능하도록 쉽게 수정될 수 있는 정도
- 상호 운용성(Interoperability)
- 유연성(Flexibility)
- 재사용성(Reusability)
|
6. 소프트웨어 신뢰성 측정
Reference
https://book.naver.com/bookdb/book_detail.naver?bid=17134434