티스토리 뷰

ooad

Testing & Quality Assurance

dictee 2019. 5. 25. 13:24

※ tutorialspoint의 OOAD 요약 (https://www.tutorialspoints.com/object_oriented_analysis_design/)

 

코드 작성 후, 코드가 가질 수 있는 여러 에러들을 처리하도록 테스트는 필수이다. 

다른 중요 관점은, 프로그램이 목표를 만족하는지를 확인하는 것이다. 

1. Testing Object-Oriented Systems

SW 개발에서의 testing은 지속적은 활동이다. object oriented system에서 테스트는 unit test, subsystem test, system test의 3단계로 구분한다.

Unit Testing

개별 class에 대한 테스트. class attribute가 설계한대로 구현되었는지, method / interface는 error가 없는지 등을 확인한다. unit test는 해당 구조를 구현한 application 개발자에게 책임이 있다.

Subsystem Testing

특정 모듈 또는 subsystem에 관한 테스트이며, sussystem 리더에게 책임이 있다. subsystem 내의 association과 외부와의 interaction에 관한 테스트를 포함한다. subsystem의 새로운 버전 배포시 regression test 용도로 사용될 수 있다.

System Testing

전체 시스템에 대한 테스트이며, quality assurance 팀에게 책임이 있다. 해당 팀은 새로운 릴리즈를 위한 regression test에서도 system test를 종종 수행한다.

2. Object-Oriented Testing Techniques

Grey Box Testing

  • State model based testing: state coverage, state transition coverage, state transition path coverage

  • Use case based testing: 시나리오 기반 테스트

  • Class diagram based testing: class, derived class, association, aggregation에 대한 테스트

  • Sequence diagram based testing: sequence diagram의 message에서 표현하는 method 테스트

Techniques for Subsystem Testing

  • Thread based testing: subsystem 내의 use case를 확인하는데 필요한 모든 class를 통합 시험

  • Use based testing: 계층의 각 레벨의 모듈 내의 interface, service 테스트. 개별 class로부터 시작하여 작은 모듈, 그리고 더 큰 모듈, 마지막으로 subsystem까지 테스트

Categories of System Testing

  • Alpha testing: SW 개발 팀 내의 테스트

  • Beta testing: 일부 고객을 선택하여 진행하는 테스트

  • Acceptance testing: 고객에게 결과물 전달 여부를 결정하기 위한 테스트

3. Software Quality Assurance

Software Quality

우수한 SW는 정확히 해야 할 일을 하고 사용자가 정의한 요구 사양 만족도 측면에서 해석된다.

Quality Assurance

SW Product이 사용하기에 적합한 그 범위를 결정하는 methodlogy. SW 품질을 결정하는 주요 activity로는,

  • Auditing
  • Development of standards and guidelines
  • Production of reports
  • Review of quality system

Quality Factors

  • Correctness: SW 요구사양을 적절하게 만족하는지 여부 결정

  • Usability: SW 여러 사용자들 (초보자, 비기술자, 전문가 등) 가 사용할 수 있는지 결정

  • Portability: SW가 다른 HW 제품의 다른 플랫폼에서 동작할 수 있는지 결정

  • Maintainability: 에러 수정, 모듈 업데이트의 용이성 결정

  • Reusability: 모듈, class가 다른 SW 개발 시 재사용될 수 있는지 결정

4. Object-Oriented Metrics

크게 3가지 카테고리로 볼 수 있다: project metrics, product metrics, and process metrics.

Project Metrics

SW PM이 진행 중인 프로젝트의 상황과 성능을 평가할 수 있게 한다. 

  • Number of scenario scripts
  • Number of key classes
  • Number of support classes
  • Number of subsystems

Product Metrics

SW Product의 특성을 측정한다. 

  • Methods per Class: class의 복잡도를 결정한다. class 내의 모든 method가 동일한 복잡도를 갖는다고 할 경우, class가 더 많은 method를 갖는다면 복잡도가 더 증가하므로, 에러에 취약하다.

  • Inheritance Structure: 1개의 대형 상속 구조를 갖는 것보다는 여러개의 작은 상속 구조를 갖도록 하는 시스템이 더 잘 구조화될 수 있다. inheritence tree는 7 (± 2) 이상의 레벨 수를 갖지 않는 것을 권장하며, tree는 balance를 이뤄야 한다.

  • Coupling and Cohesion: 모듈은 낮은 결합도와 높은 응집도를 갖도록 설계되어야 하며, 이것은 더 좋은 reusability와 maintainability를 제공하게 된다.

  • Response for a Class: class instance에 의해 호출되는 method의 효율성 측정

Process Metrics

process가 어떻게 수행되는지 측정에 도움을 주는 metric. long term으로 수집되며, 이를 통해 SW 개선을 위한 지표로 사용된다. 

  • Number of KLOC (Kilo Lines of Code)
  • Defect removal efficiency
  • 테스트 중 발견한 평균 에러 갯수
  • KLOC 당 잠재 결함 수
댓글