조치 우선순위 결정
소프트웨어 테스트 기법
1. 단위 테스트 기법
(1) JUnit을 활용한 테스트
Java 환경이라면 대부분 JUnit이라는 단위 테스트프레임워크를 통해 단위 테스트를 할 수 있어야 한다
| 단계 | 수행 내용 |
| 1 | junit.framework.TestCase의 서브 클래스 타입의 테스터 클래스를 생성한다. |
| 2 | 생성자를 작성한다. |
| 3 | setUp, tearDown 메소드를 오버라이드한다. |
| 4 | 일반적으로 Junit 테스트에서는 Fixture의 메소드를 테스트하게 되는데, 이때 Fixtur e의 테스트할 메소드에 매핑이 되는 메소드를 작성한다. |
| 5 | TestRunner 클래스의 static 메소드인 run 메소드를 호출한다 |
(2) Mock 테스트
(가) 단위 테스트 시 Mock 개체를 사용하여 테스트하는 기법을 말하며, 특정 기능 또는 모듈에 대한 응답 결과를 미리 정의해
놓고 테스트한다.
(나) 테스트 전용 객체를 테스트 더블(Test Double)이라 부르며, 이는 테스트를 위해 실제 객체를 대신해서 사용되는 용어다.
| 테스트 유형 | 테스트 시나리오 | 측정 결과 기준 |
| 웹 서버 장애 | - 동작 중인 웹 서버 10대 중 1대의 웹 서버 프로세스를 강제로 Kill한다. | 서비스 지속적 유지 |
| 웹 애플리케이션 장애 | - 동작 중인 WAS서버의 인스턴스 8개 중 실행 중인 인스턴스 한 개를 멈춘다. - 현재 접속 중인 사용자의 수행 인스턴스여야 한다. |
자동 세션 및, 서비스 유지 |
| 데이터베이스 장애 | - HA(High Availability) Fail-over, Fail-back 시 rerouting 동작 여부를 테스트한다. - Active한 Primary 서버의 DB서비스를 강제로 Kill한다. |
10초 내 서비스 복구 |
(3) 보안 테스트
보안 테스트는 별도의 보안 전문가에 의해 애플리케이션 전반에 걸쳐 검증 받는 것이 바람직하다.
보안성 검증은 애플리케이션의 기능적 요구사항과는 별도로 해킹이나 침 투에 대비할 수 있는 최신 기술 트렌드가 반영된
검증이 필요하며, 보안 검증이 완료 되면 결과를 바탕으로 취약점 분석을 한 후 개선 방안을 수립하고
반드시 이를 시스 템에 반영하도록 계획을 수립해야 한다.
4. 인수 테스트 기법
최종 사용자가 요구한 기능이 제대로 반영되었는지, 이수 조건에 만족하는지를 테스트하는 기법이다.
결함관리의 이해
1. 결함 관련 용어
(1) 에러(Error) 소프트웨어 개발 또는 유지 보수 수행 중에 발생한 부정확한 결과로, 개발자의 실수로 발생한 오타,
개발 명세서의 잘못된 이해, 서브루틴의 기능 오해 등이 있다.
(2) 오류(Fault) 프로그램 코드 상에 존재하는 것으로 비정상적인 프로그램과 정상적인 프로그램 버전 간의 차이로 인하여
발생되며, 잘못된 연산자가 사용된 경우에 프로그램이 서브루틴으 로부터의 에러 리턴을 점검하는 코드가 누락된 것을
말한다.
(3) 실패(Failure) 정상적인 프로그램과 비정상적인 프로그램의 실행 결과의 차이를 의미하며,
프로그램 실행 중에 프로그램의 실제 실행 결과를 개발 명세서에 정의된 예상 결과와 비교함으 로써 발견한다.
(4) 결함(Defect) 버그, 에러, 오류, 실패, 프로그램 실행에 대한 문제점, 프로그램 개선 사항 등의 전체 를 포괄하는 용어이다.
2. 결함의 판단 기준
기능 명세서를 기준으로 다음 5가지 규칙 중 하나 이상에 해당하는 경우를 결하이라 볼 수 있다.
(1) 기능 명세서에 가능하다고 명시된 동작을 수행하지 않는 경우
(2) 기능 명세서에 불가능하다고 명시된 동작을 수행하는 경우
(3) 기능 명세서에 명시되어 있지 않은 동작을 수행하는 경우
(4) 기능 명세서에 명시되어 있지 않지만 수행해야 할 동작을 수행하지 않는 경우
(5) 테스터의 시각에서 볼 때 문제가 있다고 판단되는 경우
테스트 격언(Testing Axioms)
1. 소프트웨어를 완벽하게 테스트하는 것은 불가능하다.
(1) 가능한 입력의 수가 너무 많다.
(2) 가능한 출력의 수가 너무 많다.
(3) 소프트웨어 명세서가 주관적이다.
(4) 소프트웨어 결함도 주관적이다.
2. 소프트웨어 테스트는 위험을 수반하는 훈련이다.
(1) 가능한 모든 테스트 시나리오와 테스트 케이스를 테스트하지 않을 경우 위험을 감 수하기로 했다는 뜻과 같다.
(2) 테스터는 무엇이 중요하고 무엇이 중요하지 않은지 현명한 판단을 하여야 한다.
3. 테스트 작업으로 결함이 존재하지 않는다는 사실을 입증할 수 없다.
(1) 테스트를 통해 소프트웨어에 결함이 없다는 것을 보장할 수는 없으며,
단지 테스트 결과로 결함이 있다는 사실만을 보여줄 수 있다.
(2) 테스트 결과 결함이 발견되지 않았다 하더라도 이는 결함이 없음을 의미하는 것은 아니다.
4. 아래와 같은 사유로 인하여 발견한 모든 결함을 수정할 수는 없다.
(1) 쫓기는 작업 일정
(2) 외부적인 요인(테스트 환경 미비, 사용자 환경 자체 장애, 법률 또는 규정 변경 등) 으로 결함이 아님에도
결함으로 판단되는 경우
(3) 각각의 프로그램 간에 서로 결합도가 높은 경우의 고치기 위험한 결함
(4) 현실에서 거의 발생할 가능성이 없는 경우(자연재해)의 고칠 가치가 없는 결함
5. 발견한 결함이 많을수록 남아 있는 결함의 수도 많다.
소프트웨어 테스터의 역할과 능력
1. 소프트웨어 테스터의 역할
(1) 결함을 발견하는 것이다.
(2) 결함을 가능한 한 빨리 발견하는 것이다.
(3) 가능한 한 결함을 빨리 발견하여 결함이 수정 보완되었는지 확인하는 것이다.
2. 소프트웨어 테스터의 능력
(1) 탐구심과 문제 해결력을 갖추어야 한다.
(2) 때로는 창의력을 발휘하여 결함을 찾기 위해 새로운 접근법도 사용해야 한다.
(3) 완벽함을 추구하지만, 가능한 한도 내에서 적당한 수준의 완벽성을 추구한다.
(4) 테스터는 항상 나쁜 소식을 전하는 사람이다.
개발자에게 그들의 작품에 결함이 있 다고 말하려면 재치와 능숙함, 그리고 설득력이 필요하다.
결함 조치 관리
프로그램 코드 검토 기법
1. 소프트웨어 인스펙션(Software Inspection)의 개요
(1) 코드 인스펙션(Code Inspection) 외에도 설계 및 설계 산출물까지 포괄하여 소프트웨 어 인스펙션으로 부르기도 한다.
(2) 코드 인스펙션은 매우 효과적인 테스트 방법으로서 어떠한 다른 테스트 방법으로 대체할 수 없다.
이는 상당한 시간이 필요한 작업이며, 통계에 따르면 인스펙션을 적절히 잘 수행하기만 하면 포함된 에러의 90%까지
찾아낼 수 있다.
(3) 코드 인스펙션, 워크스루와 같이 몇 시간 동안 수행되는 단위 미팅과는 구별되어야 한다.
적절한 코드 인스펙션은 여러 날이 필요하고 도구의 도움이 있어야 한다.
(4) 적절한 인스펙션은 소프트웨어 개발의 전체 수명 주기에 걸친 리소스 절감과 그에 따른 비용 감소 그리고 산출물의 품질을
향상시키는 것으로 나타난다.
(5) 인스펙션을 해야 하는 비즈니스적인 이유는 아래와 같다.
(가) 결함을 빨리 찾을수록 수정(fix) 비용이 적게 든다.
(나) 인스펙션의 데이터를 통해 업무에 집중할 수 있다.
(다) 인스펙션을 함으로써 교차 교육(Cross-training)을 돕는다.
(라) 제품의 "re-engineering”이 가능한 영역을 식별하도록 돕는다.
(마) 소프트웨어를 개발하고 유지하는 데 적은 비용이 든다.
(바) 스케줄에 긍정적인 효과를 준다.
(사) 품질을 향상시킨다.
2. 인스펙션 중점 항목
프로젝트에서 소프트웨어 인스펙션 업무는 품질보증(QA)이 주관하여 담당 또는 부서에서 실시하나, 아키텍트가 각 단계에서 원활한 업무 수행을 위해 지원을 하여야 한다. 소프트 웨어 인스펙션 중 특히 코드 인스펙션과 관련하여, 아키텍트는 코드 인스펙션의 프로세스 51 전반과 각 단계별 수행 업무 등을 전체적으로 이해할 필요가 있다. 아래와 같이 검토 절차에서 아키텍트는 Overview와 Rework가 잘 수행될 수 있도록 지원 하는 것이 중요하다.
(1) 자동 코드 인스펙션을 위한 환경 지원, 계획 수립 지원 활동
(2) 체크리스트 정합성 검토 지원 활동
(3) 인스펙션 결과 리뷰 참석
(4) 발견된 결함을 수정하기 위한 개발자 리딩 지원 활동
3. 코드 인스펙션의 프로세스와 수행 내용
(1) 코드 인스펙션 프로세스
| 구분 | 수행 단계 | 주요 내용 |
| 자동 수행 | 1. 범위 계획 (Capacity Plan) |
얼마만큼 인스펙션할 것인가? 인스펙션의 범위와 범위 선정 기준을 결정함. |
| 2. 시작 (Overview) | 자동 인스펙션 수행 | |
| 준비 단계 | 3. 준비 (Preparation) | 계획서 작성, 체크리스트 작성, 계획 공지, 대상 산출물 준비 |
| 4. 인스펙션 회의 (Inspection Meeting) |
사전 검토 실시, 미팅 실시 | |
| 시정 조치 | 5. 재작업 (Rework) | 개발 원작자가 직접 작업함. |
| 6. 후속처리 (Follow-up) |
결과 분석서 작성 및 보고 |
(2) 코드 인스펙션 태스크별 수행 내용
| 구분 | 태스크 | 수행 내용 | 산출물 |
| 자동수행 | 1. 자동 인스펙션 수행 | - 전수 검사, Quality Metric, 결함 분석 | 코드 인스펙션 결과 |
| 준비단계 | 2. 계획서 작성 | - 일정 및 관련자, 대상 산출물 및 준비물 정의 | 인스펙션 계획서 |
| 3. 체크리스트 작성 | - 표준 체크리스트를 테일러링하여 인스펙션 체크리스트 작성 | 인스펙션 체크리스트 | |
| 4. 계획 공지 | - 메일이나 공지를 통해 관련자에게 사전 공지 | ||
| 5. 대상 산출물 준비 | - 산출물 작성자가 인스펙션 시 필요한 자료를 준비 | ||
| 이행단계 | 6. 착수 회의 실시 | - 진행자는 참여자에게 검토 주안점, 검토 방법, 역할 등을 교육 - 작성자는 대상 산출물 및 참조 자료에 대한 개요 소개 |
|
| 7. 사전 검토 실시 | - 산출물, 체크리스트, 사전검토서 양식 배포 - 참여자별로 자료를 개별 검토하여 발견된 부적합 사항 기록 |
인스펙션 결과서 | |
| 8. 미팅 실시 | - 사전 검토에서 발견한 부적합 사항 검증 - 미팅에서 발견된 부적합 사항 추가 기재 - 부적합 사항 목록 정리 또는 조치 계획 수립 |
인스펙션 결과서 | |
| 9. 결과 정리 | - 진행자는 최종 확정된 결함 내용을 인스펙션 결과서에 정리한 후 작성자에게 배포 | ||
| 시정조치 | 10. 보완 작업 실시 | - 작성자는 각 결함에 대한 보완 작업을 실시 | |
| 11. 시정 조치 결과 확인 | - 진행자는 보완 완료 여부를 확인 (필요 시 재검토 실시) | ||
| 12. 결과 보고 | - 진행자는 결과서를 작성하여 관련자에게 보고 | 인스펙션 결과서 |
(3) 코드 인스펙션 테스크별 수행 내용
(가) 자동 코드 인스펙션
전체 개발된 프로그램을 대상으로 자동 인스펙션을 수행한다.
(나) 수동 코드 인스펙션
1) 자동 코드 인스펙션 코드 중 에러가 많은 경우
2) 업무 중에 복잡한 처리 로직이 있는 경우
3) 처음 투입되는 개발자의 산출물
(4) 코드 인스펙션 수행 시 고려사항
일반적으로 인스펙션의 목적은 개발 가이드에 따른 표준 준수성을 파악하기 위함에 있으므로
기능적으로 이상이 없는 소스 코드를 대상으로 검증한다펙션에
4. 인스펙션과 워크스루의 차이점
인스펙션은 워크스루와 달리 체크리스트를 기반으로 검토하며 발견된 모든 결함을 제거해 야 한다는 특징이 있다. 완성도가 기준 이상일 때 수행함으로써 모든 결함을 없애는 데 주요 목적이 있다.
형상 관리 및 구성 요소
1. 소프트웨어 형상 관리의 정의
(1) 소프트웨어 프로세스의 모든 출력물 정보
(2) 컴퓨터 프로그램, 컴퓨터 프로그램 설명 문서, 데이터 등
(3) 소프트웨어 프로세스 전반에 걸쳐 소프트웨어 형상의 변경 요인에 대해 소프트웨어 형상을 보호하는 활동
| 소프트웨어 형상 관리 | 소프트웨어 지원 |
| 소프트웨어 엔지니어링 프로젝트 개시에서 소프트웨어 소멸 시점까지의 활동 | 소프트웨어가 고객에게 인도되고 운영되는 시 점에 발생하는 소프트웨어 엔지니어링 활동 |
2. 기준선과 소프트웨어 형상 항목
(1) 기준선 (Baseline)
변경을 통제하게 도와주는 기준선은 정식으로 검토 및 합의된 명세서나 제품 개발의 바탕으로서,
정식의 변경 통제 절차를 통해서만 변경 가능.
(2) 소프트웨어 형상 항목 (SCI. Software Configuration Item)
소프트웨어 형상과 개발 도구의 합성이다.
| 개발 단계 | 기준선(Baseline) | 소프트웨어 형상 항목 |
| 계획 | 사용자 요구사항 | 시스템 명세서, 개발계획서, 구성관리계획서, 품질평가계획서, 개발표준 및 절차 매뉴얼 |
| 요구 분석 | 사용자 요구 기능이 하위 시스템 간에 어떻게 분배되는가 여부 | 자료흐름도, 자료사전, 자료흐름도 명세서 |
| 설계 | 개발 전 설계 명세 | 입출력명세서, 화면설계서, 초기 사용자 매뉴얼, 초기 시스템 매뉴얼, 자료 구조도, 시스템 구조도 |
| 구현 | 시험 계획서 | 원시코드, 목적코드, 실행코드, 단위시험 보고서 |
| 시스템 통합 및 시험 | 제품 | 통합시험 보고서, 기능/성능/과부하 시험 보고서, 인증시험 보고서 |
| 설치 및 운영 | 운영 | 목적/실행코드, 운영자 매뉴얼, 사용자 매뉴얼 |
3. 형상 관리의 주요 활동
(1) 형상 관리 기능
형상 관리의 주요 기능은 형상을 식별하고 관리하는 데 있다
| 단계 | 설명 |
| 형상 식별 | 형상 관리 대상을 구분하고 관리 목록 번호 부여 |
| 버전 관리 | 진화 그래프 등을 통해 SCI의 버전 부여/갱신 |
| 변경 통제 | SCI에 대한 접근 및 동기화 제어 |
| 형상 감사 | SCI 무결성을 평가하여 공식적으로 승인 |
| 상태 보고 | 개발자와 유지 보수자에게 변경 사항을 공지 |
(2) 형상 식별
소프트웨어 형상 항목에 대해 식별하고 고유한 이름을 부여하는 활동
| 식별자 항목 | 내용 |
| 이름(name) | 객체 명 |
| 서술(description) | SCI 타입, 프로젝트 식별자, 버전 정보 |
| 자원(list of resource) | 제공/처리/참조/요구되는 객체 |
| 실현(realization) | 기본 객체인 경우 : 단위 텍스트에 대한 포인터 실현(realization) |
(3) 버전 관리
형상 관리 활동 중 버전 관리는 여러 버전의 형상 객체를 관리하기 위한 절차와 도구, 그리고 형상 항목의 여러 버전을
표현하는 기능을 구성할 수 있다.
4. 변경 통제에 대한 업무별 활동
변경 통제에 대한 업무별 주요 활동은 변경 요청에 대하여 프로세스에 어떠한 영향이 있는 지 확인하는 과정으로,
검토와 승인이 완료된 후 결함 변경을 수행한다.
2024.12.06 - [일학습 병행 SW개발_L3 훈련과정] - [NCS 모듈] 애플리케이션 테스트 수행 - 애플리케이션 테스트 수행하기(1)
[NCS 모듈] 애플리케이션 테스트 수행 - 애플리케이션 테스트 수행하기(1)
테스트 수행 테스트 개요테스트 과정에 필요한 역할은 소프트웨어 아키텍트와 테스트 매니저이다. 소프트웨어 생명 주기는 요구사항, 분석, 디자인, 구현 또는 개발 순으로 진행되며, 프로젝
faring.tistory.com
*NCS 모듈 참조
'일학습 병행 SW개발_L3 훈련과정' 카테고리의 다른 글
| [NCS 모듈] 애플리케이션 배포-애플리케이션 소스 검증(2) (7) | 2024.12.09 |
|---|---|
| [NCS 모듈] 애플리케이션 배포 - 애플리케이션 배포환경 구성하기(1) (9) | 2024.12.09 |
| [NCS 모듈] 애플리케이션 테스트 수행 - 애플리케이션 테스트 수행하기(1) (9) | 2024.12.06 |
| [NCS 모듈] UI테스트 - 테스트 결과 보고하기(3) (6) | 2024.12.05 |
| [NCS 모듈] UI 테스트 - 사용성 테스트 수행하기(2) (10) | 2024.12.05 |