사용 목적에 따른 테스트 테스트는 목적에 따라 다음과 같이 분류할 수 있다. 성능 테스트 - 성능 테스트는 소프트웨어의 효율성을 진단하는 테스트이다. 즉 사용자의 요구사항 중에서 성능과 관련된 요구사항을 시스템이 얼마나 준수하는지 테스트한다. 또 통합 시스템의 전후 관계에서 소프트웨어 실행 시간을 테스트한다. 일반적으로 예상된 부하에 대한 실행시간, 응답시간, 처리능력 등을 체크하고 자원 사용량 등을 테스트한다. 부하 테스트는 가상 사용자의 수를 늘려 가면서 부하의 양을 점차적으로 늘려 가는데, 이때 초당 처리 능력(TPS)과 요청당 응답 기간(KT)의 변화 추이를 측정한다. 스트레스 테스트 - 스트레스 테스트는 평소보다 많은 비정상적인 값, 양, 빈도, 부피 등으로 부하를 발생시켜 부하가 최고치인 상황..
전공/소프트웨어공학
시각에 따른 테스트 공장에서 제품을 생산할 때는 각 공정 단계에서 필요한 텟트를 거치고 통과해야 다음 단계로 넘어간다. 이렇게 여러 단계를 거쳐 최종 생산된 제품도 시장에 내보내기 전에 마지막으로 검수하는 과정을 거쳐 이상이 없어야 출하한다. 소프트웨어도 각 단계에서는 개발자의 시각으로 테스트 하고 완선된 제품은 사용자의 시각으로 테스트 하는데, 이를 각각 확인(verification)테스트와 검증(validation)테스트라 한다. 확인(verification) 테스트 사용자가 1부터 10까지 곱하는 프로그램을 주문했는데, 개발자가 착각해 1부터 10까지 더하는 프로그램을 개발했다고 하자, 확인 테스트를 수행하면 1부터 10까지 더하는 계산과정이 정확하고, 결과가 맞는지ㅏㄴ 체크한다. 결과가 정확히 5..
1. 시각에 따른 테스트 1.1 확인 테스트 1.2 검증 테스트 2. 사용 목적에 따른 테스트 2.1 성능테스트 2.2 스트레스 테스트 2.3 보안 테스트 2.4 안정성 테스트 2.5 복원 가능성 테스트 3. 프로그램 실행 여부에 따른 테스트 3.1 정적 테스트 3.1.1 비정형 방법 3.1.2 정형 방법 3.2 동적 테스트 3.2.1 명세기반 테스트(블랙박스 테스트) 3.2.2 구현기반 테스트(화이트 박스 테스트) 4. 소프트웨어 개발 단계에 따른 테스트 4.1 단위 테스트 4.2 통합 테스트 4.3 시스템 테스트 4.4 인수 테스트 4.5 회귀 테스트
소프트웨어 테스트란? 소포트웨어 테스트는 '소프트웨어 내에 존재하지만 드러나지 않고 숨어 있는 오류를 발견할 목적으로 개발 과정에서 생성되는 문서나 프로그램에 있는 오류를 여러 기술을 이용해 검출하는 작업'이라고 할수있다. 소프트웨어 테스트의 목표 소프트웨어 테스트이 목표는 작게 보면 ' 원시 코드 속에 남아 있는 오류를 발견하는 것' 이다. 또 '결함이 생기지 않도록 예방하는 것'이다. 그러나 큰 의미에서 보면 '개발된 소프트웨어가 고객의 요구를 만족하는지 확인해 주는 것' 이다. 즉 개발자와 고객에게 사용하기에 충분한 소프트웨어임을 보여주는 것이다. 그러러면 실행된 프로그램의 결과가 명세서의 내용과 일치함을 보여야 한다. 결과적으로 테스트의 목표는 '개발된 소프트웨어에 신뢰성을 높여주는 것' 이라 할..
행위 패턴(Behavioral Patterns) 옵저버 패턴(Observer) 객체들 사이에 1 : N 의 의존관계를 정의하여 어떤 객체의 상태가 변할 때, 의존관계에 있는 모든 객체들이 통지받고 자동으로 갱신될 수 있게 만드는 패턴입니다. 상태가 변할 때 의존자들에게 알리고, 자동 업데이트하는 패턴 상태 패턴(State) 객체의 내부 상태가 변경될 때 행동을 변경하도록 허락합니다. 객체는 자신의 클래스가 변경되는 것처럼 보이게 됩니다. 객체 내부 상태에 따라서 행위를 변경하는 패턴 스트레이트지 패턴(Strategy) 동일 계열의 알고리즘들을 정의하고, 각각 캡슐화하며 이들을 상호교환 가능하도록 만드는 것입니다. 알고리즘을 사용하는 사용자로부터 독립적으로 알고리즘이 변경될 수 있도록 하는 패턴입니다. 다..
구조 패턴(Structural Patterns) 적응자 패턴(Adapter or Wrapper) 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴으로, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 해주는 패턴입니다. 인터페이스로 인해 함께 사용하지 못하는 클래스를 함께 사용하도록 하는 패턴 브리지 패턴(Bridge) 구현부에 추상층을 분리하여 각자 독립적으로 변형할 수 있도록 하는 패턴입니다. 추상과 구현을 분리하여 결합도를 낮춘 패턴 컴포지트 패턴(Composite) 객체들의 관계를 트리 구조롤 구성하여 부분-전체 계층을 표현하는 패턴으로, 사용자가 단일/복합객체 모두 동일하게 다루도록 하는 패턴입니다. 개별 객체와 복합 객체를 클라이언트에서 동..
생성(Creational) 패턴 싱클톤 패턴(Singleton) 클래스의 인스턴스가 하나임을 보장하고 접근할 수 있는 전역적인 접근점을 제공하는 패턴으로, 디자인패턴의 가장 많이 알려진 패턴입니다. 유일한 하나의 인스턴스를 보장하도록 하는 패턴 추상팩토리 패턴(Abstract Factory) 구체적인 클래스를 지정하지 않고 관련성이 있거나, 독립적인 객체들을 생성하기 위한 인터페이스를 제공하는 패턴입니다. 생성군들을 하나로 모아놓고 팩토리 중에서 선택하게 하는 패턴 빌더 패턴(Builder) 복합 개체의 생성과정과 표현과정을 분리시켜 동일한 생성과정에서 다양한 표현을 생성할 수 있는 패턴입니다. 생산단계를 캡슐화 하여 구축 공정을 동일하게 이용하도록 하는 패턴 팩토리 메서드 패턴(Factory Metho..
생성(Creational) 패턴 객체 생성에 관련된 패턴 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다. 종류 구조(Structural) 패턴 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴 예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 패턴 종류 행위(Behavioral) 패턴 객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴 한 객체가 혼자 수행할 수 없는 작업을 여러개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는 것에 중점을 둔다. 종류
