OOAD-테스트 및 품질 보증

프로그램 코드가 작성되면 테스트를 거쳐 모든 오류를 감지하고 처리해야합니다. 테스트 목적으로 여러 체계가 사용됩니다.

또 다른 중요한 측면은 프로그램이 목적에 부합하는지 여부를 확인하는 프로그램의 목적 적합성입니다. 적합성은 소프트웨어 품질을 정의합니다.

객체 지향 시스템 테스트

테스트는 소프트웨어 개발 중 지속적인 활동입니다. 객체 지향 시스템에서 테스트는 단위 테스트, 하위 시스템 테스트 및 시스템 테스트의 세 가지 수준을 포함합니다.

단위 테스트

단위 테스트에서는 개별 클래스가 테스트됩니다. 클래스 속성이 디자인에 따라 구현되었는지 여부와 메서드 및 인터페이스에 오류가 없는지 여부가 표시됩니다. 단위 테스트는 구조를 구현하는 애플리케이션 엔지니어의 책임입니다.

하위 시스템 테스트

여기에는 특정 모듈 또는 하위 시스템 테스트가 포함되며 하위 시스템 책임자의 책임입니다. 여기에는 하위 시스템 내부의 연관성 및 하위 시스템과 외부의 상호 작용 테스트가 포함됩니다. 하위 시스템 테스트는 새로 출시 된 각 하위 시스템 버전에 대한 회귀 테스트로 사용할 수 있습니다.

시스템 테스트

시스템 테스트에는 전체 시스템 테스트가 포함되며 품질 보증 팀의 책임입니다. 팀은 새 릴리스를 조립할 때 종종 시스템 테스트를 회귀 테스트로 사용합니다.

객체 지향 테스트 기법

그레이 박스 테스트

객체 지향 프로그램을 테스트하기 위해 디자인 할 수있는 다양한 유형의 테스트 케이스를 그레이 박스 테스트 케이스라고합니다. 회색 상자 테스트의 중요한 유형 중 일부는 다음과 같습니다.

State model based testing − 여기에는 상태 커버리지, 상태 전환 커버리지 및 상태 전환 경로 커버리지가 포함됩니다.
Use case based testing − 각 사용 사례의 각 시나리오가 테스트됩니다.
Class diagram based testing − 각 클래스, 파생 클래스, 연관 및 집계가 테스트됩니다.
Sequence diagram based testing − 시퀀스 다이어그램의 메시지에있는 방법이 테스트됩니다.

하위 시스템 테스트를위한 기술

서브 시스템 테스트의 두 가지 주요 접근 방식은 다음과 같습니다.

Thread based testing − 서브 시스템에서 단일 사용 사례를 실현하는 데 필요한 모든 클래스가 통합되고 테스트됩니다.
Use based testing− 각 계층 구조 수준에서 모듈의 인터페이스와 서비스가 테스트됩니다. 테스트는 개별 클래스에서 클래스로 구성된 작은 모듈, 점진적으로 더 큰 모듈, 마지막으로 모든 주요 하위 시스템으로 시작됩니다.

시스템 테스트 범주

Alpha testing − 이것은 소프트웨어를 개발하는 조직 내의 테스트 팀에 의해 수행됩니다.
Beta testing − 이는 일부 협력 고객 그룹에 의해 수행됩니다.
Acceptance testing − 이는 인도 물을 수락하기 전에 고객이 수행합니다.

소프트웨어 품질 보증

소프트웨어 품질

Schulmeyer와 McManus는 소프트웨어 품질을 "전체 소프트웨어 제품 사용에 대한 적합성"으로 정의했습니다. 양질의 소프트웨어는해야 할 일을 정확히 수행하며 사용자가 정한 요구 사항 사양의 만족도 측면에서 해석됩니다.

품질 보증

소프트웨어 품질 보증은 소프트웨어 제품이 사용하기에 적합한 정도를 결정하는 방법론입니다. 소프트웨어 품질을 결정하기 위해 포함 된 활동은 다음과 같습니다.

Auditing
표준 및 지침 개발
보고서 작성
품질 시스템 검토

품질 요인

Correctness − 정확성은 소프트웨어 요구 사항이 적절하게 충족되는지 여부를 결정합니다.
Usability − 사용성은 다른 범주의 사용자 (초보자, 비 기술자 및 전문가)가 소프트웨어를 사용할 수 있는지 여부를 결정합니다.
Portability − 이식성은 소프트웨어가 다른 하드웨어 장치가있는 다른 플랫폼에서 작동 할 수 있는지 여부를 결정합니다.
Maintainability − 유지 보수성은 오류를 수정하고 모듈을 업데이트 할 수있는 용이성을 결정합니다.
Reusability − 재사용 성은 모듈과 클래스를 다른 소프트웨어 제품 개발에 재사용 할 수 있는지 여부를 결정합니다.

객체 지향 메트릭

지표는 크게 프로젝트 지표, 제품 지표 및 프로세스 지표의 세 가지 범주로 분류 할 수 있습니다.

프로젝트 지표

프로젝트 메트릭을 사용하면 소프트웨어 프로젝트 관리자가 진행중인 프로젝트의 상태와 성과를 평가할 수 있습니다. 다음 메트릭은 객체 지향 소프트웨어 프로젝트에 적합합니다.

시나리오 스크립트 수
키 클래스 수
지원 클래스 수
서브 시스템 수

제품 지표

제품 메트릭은 개발 된 소프트웨어 제품의 특성을 측정합니다. 객체 지향 시스템에 적합한 제품 메트릭은 다음과 같습니다.

Methods per Class− 클래스의 복잡성을 결정합니다. 클래스의 모든 메서드가 똑같이 복잡하다고 가정하면 메서드가 더 많은 클래스가 더 복잡하므로 오류에 더 취약합니다.
Inheritance Structure− 여러 개의 작은 상속 격자가있는 시스템은 하나의 큰 상속 격자가있는 시스템보다 더 잘 구조화됩니다. 일반적으로 상속 트리의 수준은 7 (± 2) 개를 넘지 않아야하며 트리는 균형을 이루어야합니다.
Coupling and Cohesion − 결합이 낮고 응집력이 높은 모듈은 재사용 성과 유지 보수성이 더 높기 때문에 더 나은 설계로 간주됩니다.
Response for a Class − 클래스의 인스턴스가 호출하는 메서드의 효율성을 측정합니다.

프로세스 메트릭

프로세스 메트릭은 프로세스가 수행되는 방식을 측정하는 데 도움이됩니다. 오랜 기간 동안 모든 프로젝트에서 수집됩니다. 장기적인 소프트웨어 프로세스 개선을위한 지표로 사용됩니다. 일부 프로세스 메트릭은 다음과 같습니다.

KLOC 수 (Kilo Lines of Code)
결함 제거 효율
테스트 중 감지 된 평균 실패 수
KLOC 당 잠재 결함 수