Byseul

1. 소프트웨어 설계1. UML 다이어그램 - 순차 다이어그램행위(Behavioral) 다이어그램객체 간의 동적 상호작용을 시간 개념을 중심으로 모델링일반적으로 다이어그램의 수직 방향이 시간의 흐름을 나타냄회귀 메시지(Self-Message), 제어블록(Statement block)등으로 구성시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호작용하는 과정을 액터, 객체, 메시지 등의 요소를 사용해 그림으로 표현한 것💡 순차 다이어그램의 구성요소구성요소내용액터 (Actor)시스템으로부터 서비스를 요청하는 외부요소 = 사람객체 (Object)메시지를 주고받는 주체생명선 (Lifeline)객체가 메모리에 존재하는 기간, 객체 아래쪽에 점선을 그어 표현실행상자 (Active Box)객체가 메시지를..

쉽고 효율적으로 테스트를 수행할 수 있도록 한 것휴먼 에러(Human Error)를 감소, 테스트의 정확성 유지, 테스트 품질 향상1. ⭐ 테스트 자동화 도구의 장점 / 단점1) 장점테스트 데이터 재입력, 재구성 같은 반복적인 작업을 자동화함으로써 인력 및 시간 단축다중 플랫폼 호환성, 소프트웨어 구성, 기본 테스트 등 향상된 테스트 품질 보장사용자 요구사항을 일관성 있게 검증테스트 결과에 대한 객관적인 평가 기준 제공테스트 결과를 그래프 등 다양한 표시 현태로 제공UI없는 서비스도 정밀 테스트 가능2) 단점도구의 사용 방법에 대한 교육 및 학습 필요프로세스 단계별로 적용하기 위한 시간, 비용, 노력이 필요비공개 상용 도구의 경우 고가의 추가 비용 필요2. 테스트 자동화 수행 시 고려사항재사용 및 측정이..

1. ⭐ 테스트 케이스 (Test Case)사용자 요구사항을 정확하게 준수했는지 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서명세 기반 테스트의 설계 산출물에 해당테스트 오류 방지, 인력, 시간 낭비 감소테스트 목표와 방법을 설정한 후 작성시스템 설계 단계에서 작성하는 것이 가장 이상적2. 테스트 케이스 작성 순서1) 테스트 계획 검토 및 자료 확보테스트 계획서를 재검토하여 테스트 대상 범위 및 접근 방법을 이해시스템 요구사항과 기능 명세서를 검토하고 테스트 대상 시스템의 정보 확보2) 위험 평가 및 우선순위 결정결함의 위험 정도에 따른 운선순위 결정어느 부분에 초점을 맞춰 테스트할지 결정3) 테스트 요구사항 정의사용자 요구사항이나 테스트 대상 재검토테스..

> 테스트 계획 → 테스트 분석 및 디자인 → 테스트 케이스 및 시나리오 작성 → 테스트 수행 → 테스트 결과 평가 및 리포팅 → 결함 추적 및 관리테스트 완료 후 산출 문서테스트 계획서테스트 케이스테스트 시나리오테스트 결과서1. 테스트 계획프로젝트 계획서, 요구 명세서 등을 기반으로 테스트 목표를 정의하고 테스트 대상 및 범위 결정시스템 구조 파악, 투입 조직 및 비용 산정, 테스트 시작 및 종료 조건 정의테스트 계획서 작성2. 테스트 분석 및 디자인테스트 목적과 원칙을 검토하고 사용자 요구사항을 분석리스크 분석 및 우선순위 결정테스트 데이터, 테스트 환경, 테스트 도구 등 준비3. 테스트 케이스 및 시나리오 작성테스트 케이스의 설계 기법에 따라 테스트 케이스 작성하고 검토 및 확인 후 테스트 시나리오..

단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법1) 비점진적 통합 방식단계적으로 통합하는 절차 없이 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트빅뱅 통합 테스트규모가 작은 소프트웨어에 유리 / 단시간 내에 테스트 가능전체 프로그램 대상으로 하기에 오류 발견 및 장애 위치 파악 및 수정 어려움2) 점진적 통합 방식모듈 단위로 단계적으로 통합하면서 테스트오류 수정이 용이, 인터페이스와 연관된 오류를 완전히 테스트할 가능성 높음하향식, 상향식, 혼합식1. 하향식 통합 테스트 (Top Down Integration Test)상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트깊이 우선 통합법, 넓이 우선 통합법테스트 초기부터 사용자에게 시스템 구조를 보여줌상위 모..

개발 단계에서부터 테스트 수행하므로 단순히 코드 상의 오류뿐만 아니라 요구 분석의 오류, 설계 인터페이스 오류 등도 발견 가능단위 테스트 : 모듈 개발 시 모듈통합 테스트 : 여러 개 모듈 결합하여 시스템으로 완성시키는 과정시스템 테스트 : 설계된 소프트웨어가 시스템에서 정상적으로 수행되는지 확인인수 테스트 : 최종 소프트웨어를 사용자에게 인도하기 전1. 단위 테스트 (Unit Test)코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트인터페이스, 외부적 I/O, 자료 구조, 독립적 기초 경로, 오류 처리 경로, 경계 조건사용자 요구사항을 기반으로 기능성 테스트를 최우선으로 수행💡 단위 테스트로 발견 가능한 오류알고리즘 오류에 따른 원치 않는 결과탈출구가 없는 반복문틀린 계..

1. 화이트박스 테스트 (White Box Test)모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트설계된 절차에 초점프로시터 설계의 제어 구조를 사용하여 테스트 케이스 설계테스트 과정의 초기에 적용모듈 안의 작동을 직접 관찰원시 코드(모듈)의 모든 문장을 한 번 이상 실행함으로써 수행됨제어 구조에 따라 선택, 반복 등 분기점 부분들을 수행함으로써 논리적 경로를 제어2. ⭐ 화이트박스 테스트의 종류1) 기초 경로 검사 (Base Path Testing)대표적인 화이트박스 테스트 기법절차적 설계의 논리적 복잡성을 측정할 수 있게 함측정 결과는 실행 경로의 기초를 정의하는데 지침으로 사용됨2) 제어 구조 검사 (Control Structure Testing)조건 검사(Condit..

1. 프로그램 실행 여부에 따른 테스트 (프로그램 실행 여부)1) 정적 테스트프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트개발 초기에 결함을 발견할 수 있어 개발 비용을 낮춤워크스루, 인스펙션, 코드 검사2) 동적 테스트프로그램을 실행하여 오류를 찾는 테스트개발의 모든 단계에서 테스트 수행블랙박스 테스트, 화이트박스 테스트2. 테스트 기반 (Test Bases)에 따른 테스트 (무엇을 기반)1) 명세 기반 테스트사용자 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트동등 분할, 경계 값 분석2) 구조 기반 테스트소프트웨어 내부의 논리 흐름에 따라 테스트 케이스 작성하고 확인하는 테스트구문 기반, 결정 기반, 조건 기반3) 경험 기반 테스트유사..

개발한 애플리케이션이 고객의 요구를 만족시키는지 확인(Validation), 기능이 정상적으로 수행하는지 검증(Verification)Validation(확인) = 사용자 입장 = 고객의 요구에 맞게 구현되었는지 확인Verification(검증) = 개발자 입장 = 명세서에 맞게 만들어졌는지 점검1. ⭐ 애플리케이션 테스트의 필요성프로그램 실행 전 코드리뷰, 인스펙션 등을 통해 오류를 발견하여 예방반복적인 테스트를 통해 제품의 신뢰도 향상개발초기부터 테스트를 계획하고 시작하면 단순한 오류 발견뿐만 아니라 새로운 오류의 유입도 예방테스트를 효과적으로 수행하면 최소한의 시간과 노력으로 많은 결함을 찾음2. ⭐ 애플리케이션 테스트의 기본원리소프트웨어의 잠재적인 결함은 줄일 수 있지만 결함이 없다고 증명 X =..

소스 코드 파일들을 컴파일한 후 여러 개의 모듈을 묶어 실행 파일로 만드는 과정을 포함해 테스트 및 배포를 자동화하는 도구애자일 환경에서는 하나의 작업이 마무리될 때마다 모듈단위로 나눠서 코드들이 지속적으로 통합됨 = 지속적인 통합(Continuous Integration)Ant, Make, Maven, Gradle, Jenkins1. JenkinsJava 기반 오플소스 형태서블릿 컨테이너에서 실행되는 서버 기반 도구SVN, Git 등 대부분 형상관리 도구와 연동 가능친숙한 Web GUI 제공여러 대의 컴퓨터를 이용한 분산 빈도나 테스트 가능2. GradleGroovy 기반 오픈소스 형태안드로이드 앱 개발 환경에서 사용Java, C/C++, PythonDSL(Domain Specific Language)..