Open API22 API 테스트 유형 * 소프트웨어 테스트 분류 항목 1. 화이트 박스 테스트 - 소스 코드를 기준으로 테스트가 개발되고 보통 프로그래밍 언어를 사용해서 테스트가 만들어짐 2. 블랙 박스 테스트 - 기능이 어떻게 구현되어 있는지 신경쓰지 않고 제품의 명세에 따라 테스트가 개발- API 명세에 따라 각각의 API 만을 테스트 하는 테스트 코드를 통해 진행 가능 3. 그레이 박스 테스트- 화이트 박스 테스트와 블랙 박스 테스트를 결합한 형태- 블랙 박스 테스트는 소프트웨어의 구체적인 구현 로직에 기반해서 진행 2017. 3. 29. 변경 근거와 관리 변경 용이성은 품질 속성 중 하나 기존 아키텍처와 기존 코드의 제약 안에서 작업을 한다 많은 프로그래머와 소프트웨어 설계자들은 결코 새로운 개발 작업을 할 기회를 얻지 못한다 새로운 기능을 수용하고, 새로운 환경에 순응하고, 버그를 수정 * 변경 카테고리 1. 지역 변경 : 하나의 요소를 변경함으로써 수행, 예를 들어, 가격 로직 모듈에 새로운 업무 규칙을 추가 2. 비지역 변경 : 여러 요소를 변경해야 하지만 해당 아키텍처적인 접근 방법은 그대로 둔다 예를 들어 가격 로직 모듈에 새로운 업무 규칙을 추가한 다음 이 새로운 업무 규칙에 필요한 새로운 필드를 데이터 베이스에 추가하고, 사용자 인터페이스에 규칙의 결과를 나타내게 한다 3. 아키텍처적 변경 : 요소가 서로 상호작용하는 근본적인 방식에 영향을 .. 2017. 3. 4. 시스템의 품질 속성 억제 또는 가능 * 시스템에 높은 성능이 필요하다면 요소의 시간 기반 행위와 공유 리소스 사용, 요소 간 커뮤니케이션 빈도와 크기를 관리하는데 주의 * 변경용이성이 중요하다면 시스템 변경이 소수의 요소에만 영향을 미치도록 요소에 책임을 배정하는데 주의(이상적으로 각 변경은 단 하나의 요소에만 영향을 미침) * 시스템이 고도로 안전해야 한다면 요소 간 커뮤니케이션을 관리하고 보호하며, 요소가 어떤 정보에 엑세스할 수 있는지 통제, 아키텍처에 특별한 요소를 도입 * 확장성이 시스템의 성공에 중요하다면 더 높은 기능을 제공하는 대체물을 도입할 수 있도록 리소스의 사용을 지역화, 리소스에 대한 가정과 한계를 하드 코딩 * 프로젝트가 시스템의 점증적인 서브집합을 인도할 필요가 있다면 컴포넌트 사용을 주의 깊게 관리 * 시스템의 .. 2017. 3. 4. 아키텍처가 중요한 이유 * 아키텍처가 중요한 이유 1. 아키텍처는 시스템의 주도적인 품질 속성을 억제하거나 가능 2. 아키텍처에 내린 결정은 시스템이 발전할 때 변경에 대한 근거를 제시하고 관리 3. 아키텍처 분석은 시스템의 품질을 초기에 예측 4. 문서화된 아키텍처는 이해 당사자 사이의 의사 소통을 향상 5. 아키텍처는 가장 초기의, 가장 기본적이며, 가장 변경하기 어려운 설계 결정의 운반체다 6. 아키텍처는 이어지는 구현에 대한 제약사항 집합을 정의한다 7. 아키텍처는 조직의 구조에 영향을 주거나 영향을 받는다 8. 아키텍처는 발전적인 프로토타이핑 기반을 제공할 수 있다 9. 아키텍처는 아키텍트와 프로젝트 관리자가 비용과 일정에 대한 근거를 설명할 수 있게 하는 주요 산출물 10. 아키텍처는 제품 라인의 핵심을 구성하는, .. 2017. 3. 4. Mediator 패턴 * 프로그램 복잡도 - 서로 완벽하게 관계를 가지면 N * (N - 1) 가지의 관계가 존재- 관계를 일일이 이해하는 것은 불가능- 각각 클래스들이 순환 참조 - 각각의 클래스나 객체 간의 커뮤니케이션을 특정 클래스나 객체가 중재해주는 형태로 변환- M : N의 복잡한 관계를 M : 1 의 관계로 간소화 시켜주는 방식 예제)- 커피 자판기 - 현재 상태를 표시하는 램프 - 종이컵과 원료 관리, 원료를 배합해서 커피를 만드는 믹서 - 동적을 받아들이고 관리하는 동전 박스 클래스 정의 - Lamp - Mixer - CoinBox - BillBox - 동작들을 수행하기 위해서는 각 클래스의 객체들이 서로 어떤 형태로든 커뮤니케이션을 가져야 하는 점 - 자동 판매기가 고장났을 경우 Mixer가 이를 감지 - 이.. 2017. 2. 27. Design Pattern 정리 Design Pattern 정리1. 디자인 패턴이 필요한 이유 - 특정 클래스에서 객체 생성- 객체를 생성할 때 클래스 이름을 명시하면 어떤 특정 인터페이스가 아닌 어떤 특정 구현에 종속- 이런 종속은 앞으로의 변화를 수용 못 함 - 객체를 직접 생성해서는 안됨(디자인 패턴 : Abstract factory, Factory method, Prototype) - 특정 연산에 대한 의존성- 특정한 연산을 사용하면, 요청을 만족하는 한 가지 방법에만 의존- 직접 코딩하는 방법을 피하면, 컴파일 시점과 런타임 모두를 만족, 요청 처리 방법을 쉽게 변경(디자인 패턴 : Chain of responsibility, Command) - 하드웨어와 소프트웨어 플랫폼에 대한 의존성- Windows, Unix, iOS, .. 2017. 2. 21. Prototype 패턴 * 객체 생성 방법 - 직접 클래스의 생성자를 호출해서 객체를 생성 - 객체 생성을 대행해주는 함수를 통해 객체를 생성 - 객체를 구성하는 부분 부분들을 먼저 생성한 후 이를 조합해서 객체를 생성 - 이미 생성된 객체를 복제해서 새로운 객체를 생성 * Prototype - switch와 같은 비교 문장을 없애면서도 생성할 객체의 자료형을 명확히 결정할 수 있는 방법 - 객체를 생성할 시점에 생성할 객체의 자료형을 정하는 형태 - 기존에 생성된 객체와는 무관하게 객체의 생성이 이루어짐 - 객체를 생성할 시점에 객체의 자료형을 별도로 정하지 않도록 해야 함 - 생성되는 객체의 자료형이 객체를 생성할 시점에 따로 정하지 않아도 이미 결정 - 기존의 객체를 복제해서 새로운 객체를 생성하면 새롭게 생성되는 객체는.. 2017. 2. 21. Decorator 패턴 - 특정 객체에 기능을 추가하거나 기능을 삭제하기 위해 클래스 내부 변경하거나 하위 클래스를 추가하는 방법 - 이 같은 클래스 차원의 접근 방법은 그 클래스에 속하는 모든 객체에게 영향을 미침 - 우리가 원하는 건 특정 객체에게만 기능을 추가하거나 삭제 - 적합한 해결책은 클래스 차원이 아니라 특정 객체에게만 기능을 추가하거나 삭제 - 객체 차원에서 동적으로 기능을 추가하거나 삭제 - 클래스를 변경시키지 않는 이상 객체 스스로 기능을 추가하거나 삭제할 수는 없다 - 따라서 객체 차원에서 기능을 추가하거나 삭제할 수 있는 유일한 방법 - 다른 객체를 이용해서 원래 객체를 꾸며주는 형태를 취하는 것 - 새로운 기능을 가진 객체가 원래 객체를 꾸며주면서 새로운 기능도 수행해주고 원래 객체가 가진 기능도 수행해.. 2017. 2. 21. Proxy 패턴 * Proxy 패턴 - 대리 객체를 통해 원래 객체의 작업을 수행하게 만드는 패턴 * 예제 - 웹으로 만화 서비스 제공- 이미지 파일로 서비스 제공- 서비스 요청에 따른 반응 시간 오래 걸림- 특정 시간대에 서비스 요청이 폭주 - 어떻게 하면 적은 자원을 사용하면서도 서비스 요청이 폭주하는 시간대에도 서비스 요청에 따른 반응 시간을 안정되고 빠르게 유지-어떻게 한정된 자원으로 안정되고 빠른 만화 서비스를 제공 - 이 문제를 해결하기 위해 먼저 서비스 요청이 어떤 단계의 작업을 거쳐 처리되는지 세분화- 각 단계에서 작업에 소요되는 시간 측정- 해야할 과제는 서비스 요청을 처리하는데 걸리는 전체적인 시간을 단축해서 서비스 요청이 폭주하더라도 서비스 요청 처리가 빠르게 이루어지도록 하는 것 - 이 경우 두 가.. 2017. 2. 9. Flyweight 패턴 * Flyweight 패턴 - Flyweight 객체 : 공유 가능한 정보를 별도의 객체를 정의해서 저장 관리시키는 객체- Intrinsic State : 공유가능한 정보는 Flyweight 객체의 내부에 저장, 관리- Extrinsic State : 공유 불가능한 정보 2017. 2. 9. Facade 패턴 (퍼사드 패턴) * 예제 - 어떤 검색 조건을 입력했을 때 해당 검색 조건을 만족하는 자료를 데이터베이스로부터 찾아주는 프로그램 - 입력한 검색 조건이 제대로 된 것인가?- 자료를 찾기 위해 데이터베이스 관리 시스템에 접속- 검색에 알맞은 SQL 문장 생성- 생성된 SQL 문장을 데이터베이스 관리 시스템에 전달- 그 결과를 받아와야 함- 그 결과를 기반으로 사용자에게 보여줄 최종 화면 생성 * 위의 예제는 데이터베이스로부터 자료를 검색하기 위한 클래스들이 이미 존재 - 사용자가 입력한 검색 조건이 적합한 것인지 검사해주기 위한 클래스- 검색 조건을 SQL 문장으로 생성해주기 위한 클래스- 데이터베이스 관리 시스템에 접속해서 SQL 문장의 실행을 요청하는 클래스- SQL 문장의 실행 결과를 저장하기 위한 클래스 - 이들은.. 2017. 2. 9. 상태 다이어그램 * 상태 다이어그램 - 클래스 내에서 한 상태에서 다른 상태로의 상태 이동을 유발하는 이벤트를 표시- 상태 및 이벤트의 네트워크- 클래스가 수신한 자극, 응답 및 조치를 캡처 - 각각의 상태는 하나 이상의 이벤트를 수신하며 이벤트를 수신할 때 클래스가 다음 상태로 상태 전이- 다음 상태는 이벤트에 따라 결정 - 상태 다이어그램을 모델링하면 시스템에서 중요 클래스의 동적 동작을 이해하는데 도움- 중요 클래스 : 중요 업무를 수행하는 클래스를 의미, 시스템 또는 비즈니스 이벤트에 따라 종종 상태를 변경 - 다양한 상태가 될 수 있으므로 예약 클래스의 상태 다이어 그램을 작성(임시 예약, 예약, 작성, 파기, 보류 등)- 클래스가 이러한 상태를 유지하는 기간과 클래스의 상태 변경을 유발하는 이벤트에 대해 이해.. 2017. 2. 9. 이전 1 2 다음