Byseul

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)..

1. 공유 폴더 방식버전 관리 자료가 로컬 컴퓨터의 공유 폴더에 저장되어 관리되는 방식약속된 공유 폴더에 매일 복사로컬로 복사 후 컴파일하여 이상유무 확인파일 오류 확인되면, 등록한 개발자에게 수정 의뢰파일의 변경 사항을 DB에 기록하여 관리SCCS, RCS, PVCS, QVCSRCS (Revision Control System) : 소스 파일 동시 수정 방지, 다른 방향으로 진행된 개발 결과를 합치거나 변경 내용 추적 가능2. 클라이언트/서버 방식서버에 저장되어 관리되는 방식로컬로 복사하여 작업한 후 변경된 내용을 서버에 반영모든 버전관리는 서버에서 수행하나의 파일을 서로 다른 개발자가 작업할 경우 경고 메시지 출력서버 문제시, 복수되지 전까지 협업 및 버전관리 작업은 중단CVS, SVN, CVSNT,..

1. 소프트웨어 패키징의 형상관리형상관리 (SCM; Software Configuration Management)소프트웨어 개발과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동변경원인 제어개발 전 단계에 적용 / 유지보수 단계에서도 수행개발 비용 감소, 방해요인 최소화되도록 보증하는 것이 목적프로젝트 계획, 분석서, 설계서, 프로그램, 소스코드, 테스트 케이스 등 포함가시성과 추적성 보장함으로써 소프트웨어의 생산성과 품직을 높일 수 있음Git, CVS, Subversion2. 형상관리의 중요성지속적인 변경 사항을 체계적으로 추적하고 통제무절제한 변경 방지버그나 수정사항 추적진행 정도 확인하기 위한 기준배포본 효율적으로 관리여러 명의 개발자가 동시 개발 가능3. 형상관리 기능형상 식별 :..

사용자가 소프트웨어를 사용하면서 필요한 제반 사항이 모두 포함되도록 작성되어야 함배포 후 발생될 수 있는 오류에 대한 패치나 기능에 대한 업그레이드를 위해 매뉴얼 버전 관리개별적으로 동작이 가능한 컴포넌트 단위로 매뉴얼 작성컴포넌트 명세서, 컴포넌트 구현 설계서 기준으로 작성1. 서문문서 이력, 사용자 매뉴얼의 주석, 기록 보관을 위해 필요한 내용 기술2. 기본사항소프트웨어 개요, 소프트웨어 사용환경, 소프트웨어 관리, 모델/버전별 특징, 기능/인터페이스 특징, 소프트웨어 구동환경3. 사용자 매뉴얼 작성 방법사용자가 사용방법을 이해하기 쉽도록 상황별로 누락없이 캠처하여 순서대로 상세히 설명사용자 화면, 주요 기능 분류, 응용 프로그램 및 설정, 장치 연동, Network 환경, Profile 안내, 고객..

사용자를 기준으로 설치과정에 대한 모든 내용이 순서대로 빠짐없이 수록되어야 함설치과정에서 표시될 수 있는 오류메시지 및 예외 상황에 관한 내용을 별도로 분류하여 설명1. 서문문서이력, 설치 매뉴얼의 주석, 설치 도구의 구성, 설치 환경 체크항목2. 기본사항소프트웨어 개요, 설치 관련 파일, 설치 아이콘, 프로그램 삭제, 관련 추가 정보3. 설치 매뉴얼 작성 방법설치과정을 이해하기 쉽도록 설치 화면을 누락없이 캡처하고 순서대로 상세히 설명설치화면, 설치 이상 메시지, 설치 완료 및 결과, FAQ, 설치 시 점검사항, Network 환경 및 보안, 고객지원방법, 준수 정보 및 제한 보증4. 설치 매뉴얼 작성 순서> 기능 식별 → UI분류 → 설치파일 / 백업파일 확인 → Uninstall 절차 확인 → 이상..

불법 복제 및 배포 등을 막기위한 기술적인 방법저작권자가 의도한 용도로만 사용되도록 디지털 콘텐츠의 생성, 유통, 이용까지의 전 과정에 걸쳐 사용되는 디지털 콘텐츠 관리 및 보호 기술원본 콘텐츠가 아날로그인 경우 디지털로 변환 후 패키저에 의해 DRM 패키징을 수행크기가 작은 경우, 사용자가 콘텐츠를 요청하는 시점에서 실시간 패키징 수행크기가 큰 경우, 미리 패키징을 수행한 후 배포암호화된 저작권자의 전자서명이 포함되고 저작권자가 설정한 라이선스 정보가 클리어링 하우스(Clearing House)에 등록됨사용자는 클리어링 하우스에 등록된 라이선스 정보를 통해 사용자 인증과 콘텐츠 사용권한 소유 여부를 확인받아야 함종량제 방식의 경우, 클리어링 하우스를 통해 서비스의 사용량을 측정하여 이용한 만큼의 요금 ..

고객과 공유하기 위한 문서테스트 결과 및 개발 준수 여부 확인 가능전체 기능, 서비스 내용, 개선 사항 공유체계적인 버전관리개선 사항을 적용한 추가 배포시 제공최종 승인을 받은 문서1. 릴리즈 노트 초기 버전 작성 시 고려사항정확하고 완전한 정보기반으로 개발팀에서 직접 현재 시제로 작성이력이 정확하게 관리되어 변경, 개선된 항목에 대한 이력 정보 작성2. 릴리즈 노트 추가 버전 작성 시 고려사항베타 버전 출시, 긴급한 버그 수정, 업그레이드 등 기능 향상, 사용자 요청 등 특수한 상황이 발생한 경우 작성버그 번호를 포함한 모든 수정내용을 작성업그레이드 경우, 릴리즈 버전 출시 후 릴리즈 노트 작성요구사항 추가 및 수정된 경우, 기능 향상과는 다른 별도의 릴리즈 버전 출시 후 릴리즈 노트 작성3. 릴리즈 ..