전체 글

1. 모듈 연계 개요 - 내부와 외부 모듈 또는 내부 모듈 간 데이터 교환을 위해 관계를 설정하는 것 - 종류 : 1. EAI(Enterprise Application Integration) - 기업 내 각종 애플리케이션 및 플랫폼 간의 정보 전달, 연계, 통합 등 상호 연동이 가능하게 해주는 솔루션 - 비즈니스 간 통합 및 연계성을 증대시켜 효율성 및 각 시스템 간의 확정성(Determinacy)을 높여 준다 유형 기능 point-to-point - 가장 기본적인 애플리케이션 통합 방식으로, 애플리케이션을 1:1로 연결한다 - 변경 및 재사용이 어렵다 hub & spoke - 단일 접점인 허브 시스템을 통해 데이터 저농하는 중앙 집중형 방식 - 확장 및 유지 보수가 용이 - 허브 장애 발생 시 시스템 ..

1. 모듈 간 공통 기능 및 데이터 인터페이스 개요 - 공통 기능은 모듈의 기능 중 공통적으로 제공되는 기능을 의미 - 데이터 인터페이스는 모듈 간 교환되는 데이터가 저장될 파라미터를 의미 - 이것들은 인터페이스 설계서에서 정의한 모듈의 기능을 기반으로 확인한다 - 모듈 간 공통 기능 및 데이터 인터페이스 확인 순서 1. 인터페이스 설계서를 통해 모듈별 기능을 확인한다 2. 외부 및 내부 모듈을 기반으로 공통적으로 제공되는 기능과 각 데이터의 인터페이스를 확인한다 2. 인터페이스 설계서 - 시스템 사이의 데이터 교환 및 처리를 위해 교환 데이터 및 관련 업무, 송수신 시스템 등에 대한 내용을 정의한 문서 - 일반적인 설계서와 정적/동적 모형 설계서로 구분 - 일반적인 인터페이스 설계서 : - 인터페이스 ..

1. 소스 코드 최적화 - 클린 코드 : 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 명료한 코드 - 나쁜 코드 : 로직이 복잡하고 이해하기 어려운 코드로, 스파게티 코드와 외계인 코드가 해당 - 스파게티 코드 : 로직이 서로 복잡하게 얽혀 있는 코드 - 외계인 코드 : 오래되거나 참고문서 또는 개발자가 없이 유지보수 작입이 어려운 코드 - 클린 코드 작성 원칙 가독성 - 누구든지 쉽게 읽을 수 있도록 작성 - 쉬운 용어, 들여쓰기 기능 등을 사용 단순성 - 코드를 간단하게 작성 - 한 번에 한 가지를 처리하도록 코드를 작성하고 클래스/메소드/함수 등을 최소 단위로 분리한다 의존성 배제 - 코드가 다른 모듈에 미치는 영향을 최소화한다 - 코드 변경 시 다른 부분에 영향이 없도록 작성 중복성 최소..

1. 복잡도 개요 - 시스템이나 시스템 구성 요소 또는 소프트웨어의 복잡한 정도를 나타낸다 - 시스템 / 소프트웨어를 어느 정도의 수준까지 테스트해야 하는지 또는 개발하는데 어느 정도의 자원이 소요되는 예측하는데 사용 - 복잡도가 높으면 장애 발생 확률이 높아짐 - 측정 방법 : LOC(Line Of Code), 순환 복잡도(Cyclomatic Complexity) 등 -> 소프트웨어의 개별적인 기능에 대해 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용해 비용 산정 2. 시간 복잡도 - 알고리즘의 실행 시간 - 실행시간은 하드웨어 성능이나 언어에 따라 달라지기 때문에 시간이 아닌 명령어 실행 횟수를 표기한다. 이를 점근 표기법이라 한다 - 점근 표기법의 종류 빅오 표..

1. 애플리케이션 성능 - 사용자가 요구한 기능을 최소한의 자원으로 최대한 많은 기능을 신속하게 처리하는 정도 - 성능 테스트 도구와 시스템 모니터링 도구로 분류 - 측정 지표 처리량(Throughput) 일정 시간 내에 애플리케이션이 처리하는 양 응답 시간(Response Time) 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간 경과 시간(Turn Around Time) 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간 자원 사용률(Resource Usage) 의뢰한 시간을 처리하는 동안 CPU, 메모리, 네트워크 등 사용량 2. 성능 테스트 도구 - 애플리케이션에 부하나 스트레스를 가하면서 성능 측정하는 도구 - 종류 : 도구명 도구 설명 지원 환경 JMeter HTTP, FTP 등 다..

1. 결함 정의 - 오류 발생, 작동 실패 등과 같이 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 것 - 사용자가 예상한 결과와 실행 결과 간의 차이, 업무 내용과의 불일치 등도 모두 결함에 해당 2. 결함 관리 프로세스 1. 결함 관리 계획 2. 결함 기록 - 테스터는 발견한 결함을 결함 관리 DB에 등록 3. 결함 검토 - 테스터, 프로그램 리더, 품질 관리 담당자 등은 등록된 결함을 검토하고 수정할 개발자에게 전달 4. 결함 수정 5. 결함 재확인 6. 결함 상태 추적 및 모니터링 활동 - 결함 유형, 발생률 등을 한눈에 볼 수 있는 대시보드/게시판 형태의 서비스를 제공 7. 최종 결함 분석 및 보고서 작성 3. 결함 상태 추적 - 결함 관리 측정 지표 1. 결함 분포 ..

1. 테스트 자동화 개념 - 사람이 반복적으로 하던 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용함 - 따라서 쉽고 효율적으로 테스트 수행 - 휴먼 에러를 줄이고 테스트 정확성을 유지, 테스트 품질 향상 2. 테스트 자동화 도구 장단점 장점 단점 - 테스트 데이터의 재입력, 재구성 같은 반복적인 작업 줄임 - 다중 플랫폼 호환성, 소프트웨어 구성, 기본 테스트 등 향상된 테스트 품질 보증 - 요구사항 등을 일관성 있게 검증 - 테스트 결과에 대한 객관적인 평가 기준 제공 - 테스트 결과를 그래프 등 다양한 형태 제공 - UI가 없는 서비스도 정밀 테스트 가능 - 자동화 도구 학습 필요 - 자동화 도구를 프로세스 단계별로 적용하기 위한 시간, 비용, 노력 발생 - 비공개 상용 도구의 경우 고가..

1. 테스트 케이스 - 요구사항을 준수했는지 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목 명세서 - 명세 기반 테스트의 설계 산출물에 해당한다 - 가장 이상적으로는 시스템 설계 시 작성해야 한다 2. 테스트 케이스 작성 순서 1. 테스트 계획 검토 및 자료 확보 2. 위험 평가 및 우선순위 결정 3. 테스트 요구사항 정의 4. 테스트 구조 설계 및 테스트 방법 결정 - 테스트 케이스의 형식과 분류 방법 결정 - 테스트 절차, 장비, 도구, 테스트 문서화 방법 결정 5. 테스트 케이스 정의 - 입력 값, 실행 조건, 예상 결과 기술 6. 테스트 케이스 타당성 확인 및 유지 보수 3. 테스트 시나리오 - 테스크 케이스를 적용하는 순서와 구체적인 절차를 명세 4. 테스트 ..