Coding Backup

4.1 개요

3.5 리그레션 테스트 유지보수 단계에서 소프트웨어 수정 하는 이유결함 수정 작업: 소프트웨어를 사용하는 도중 발견된 결함을 수정 / 21%기능 보강 작업: 기능을 추가하거나 성능을 개선 / 50%적응 작업: 새로운 운영환경에 적응시기위위한 유지보수 / 25%예방 작업: 더 나은 유지보수를 위한 유지보수 / 4%유지보수 활동에는 소프트웨어 수정이 수반되기 때문에 변경 작업 후 결함이 있는지 확인 = 리그레션 테스트개발 단계에서 사용한 테스트 케이스 사용하여 수정 전후 차이를 비교동일한지, 동일하지 않다면 의도한 것인지 확인시간 및 비용이 한정적이기 때문에 테스트 케이스의 규모를 잘 고려해야 함 Retest-All 기존에 개발된 모든 테스트 케이스를 사용하는 방식복잡한 테스트 절차를 요구하지 않지만 많은 ..

3.4 시스템 테스트 및 인수 테스트시스템 테스트통합 테스트가 완료된 후에 전체 시스템이 시스템 명세에 따라 개발되었는지 검증하기 위해 수행하는 테스트시스템의 기능 측면 + 비기능적 측면 모두 만족하는지 검증 인수 테스트시스템 테스트 완료 후 실제 사용자의 요구사항을 만족하는지 확인하기 위한 테스트결함 검출이 아니라 시스템을 인수해도 되는지 고객의 입장에서 평가테스트 케이스는 사용자 또는 소프트웨어 구입자가 제시할 수도 있고 시스템 테스트 때 사용했던 것을 재사용할 수 있음개발자가 수행한 테스트로 발견되지 않는 결함이 발견될 수 있음알파 테스트: 선택된 사용자가 개발자 환경에서 통제된 상태로 진행베타 테스트: 일정 수의 사용자에게 사용하게 하며, 보통 개발자는 참가하지 않음

3.3 통합 테스트개요점진적 통합3.3.1 개요통합 테스트는 컴포넌트 간의 상호 연동이 제대로 수행되는지 검사컴포넌트 테스트에서 문제가 없더라도 통합한 후에 결함이 발생할 수도 있음통합 테스트를 수행할 때는 각 테스트 별로 통합 대상이 되는 컴포넌트를 먼저 결정 상호작용 관점컴포넌트 간 연결의 정확성에만 초점을 두는 관점 컴포넌트 간의 데이터 전송과 수신에만 초점을 둠입력 로그와 출력 로그의 값을 비교하는 방식으로 적합성 확인 가능로그 생성이 어려울 경우에는 핑거 프린트를 사용해 데이터의 변경 여부만을 판단하기도 함컴포넌트 간의 연결 자체에서 오작동이 발생할 가능성이 클 경우 먼저 수행 기능적인 측면 관점컴포넌트 1과 컴포넌트 2 전체가 테스트 대상이라고 볼 수 있음컴포넌트 간의 통신에 문제가 있을 가..

3.2 컴포넌트 테스트개요모의 객체 생성 프레임워크FIRST 원칙3.2.1 개요컴포넌트(단위) 테스트개별적인 모듈(또는 컴포넌트) 테스트각 모듈을 구현한 후 수행컴포넌트를 독립적인 방식으로 테스트 수행➡️ 단독으로 실행할 수 있는 환경 필요 - 테스트 베드➡️테스트 환경의 주요 구성 요소 - 테스트 드라이버, 테스트 스텁 컴포넌트0, 1, 2 은 연결되어 있지만 각각의 컴포넌트는 단독으로 실행하여 테스트 진행따라서 컴포넌트 0 테스트를 한 후, 컴포넌트 1을 호출하는 것이 아닌 컴포넌트 1의 스텁을 호출하게 됨마찬가지로 컴포넌트 1도 컴포넌트 0의 호출이 필요한 게 아니라 드라이버 1이 호출하여 테스트 진행함 3.2.2 모의 객체 생성 프레임워크테스트 되는 메소드가 다른 클래스의 객체에 의존할 수 있음..