설계부터 테스트까지
Updated:
🔷 단위 테스트, 결합 테스트
-
함수나 프로시저, 메소드 등의 단위로 실시하느 ㄴ테스트를 단위 테스트라고 하며 상세설계에 대응한다
-
여러 프로그램을 결합하여 실시하는 테스트를 결합 테스트라고 하며 기본 설계에 대응한다
🔶 테스트는 문제를 빠르게 발견하기 위해 필요하다
🔶 작은 단위로 테스트 하다
🔶 여러 프로그램을 연결하여 테스트하다
🔷 시스템 테스트, 사용자 승인 테스트
-
개발이 전부 끝난 단계에서 개발자가 시행하는 시스템 전체 테스트를 시스템 테스르라고 한다
-
요전을 충족하고 있는지 발주한 쪽에서 확인하는 테스트를 사용자 승인 테스트라고 한다
🔶 시스템 전체로서의 동작을 확인한다
🔶 발주자 측에서 테스트 한다
🔷 블랙박스, 화이트박스 테스트, 커버리지
-
프로그램의 입출력에만 주목하는 테스트 방법을 블랙박스 테스트라고 하며, 정해진 테스트 케이스에 대해 올바른 결과를 얻을 수 있는지 확인한다
-
소스 코드의 내용을 보고, 명령이나 분기, 조건 등을 망라하는지 확인하는 테스트 방법으로 화이이트 박스 테스트가 있다
🔶 프로그램의 입출력에만 주목해서 테스트한다
🔶 소스 코드의 내뇬을 보고 테스트한다
🔷 동치 분할, 경계값 분석
-
그룹으로 분류한 중에서 대표적인 값을 선택하여 효율적으로 테스트하는 방법을 동치 분할이라고 한다
-
경계가 되는 값을 이용해 조건이 올바르게 구현되었는지 체크하는 바법을 경계값 분석이라고 한다
🔶 대표적인 값으로 테스트 한다
🔶 경계의 전후값으로 테스트 한다
🔷 버그, 디버그, 디버거, BTS
-
프로그램이 예상대로 동작하지 않는 것을 버그라고 한다
-
버그를 제거하거나 발견하는 작업을 디버그라고 하며, 디버그를 지원하는 소프트웨어를 디버거라고 한다
-
버그를 관리하는 소프트웨어로 BTS (Bug tracking system)가 있다
🔶 프로그램의 문제점을 찾아낸다
🔶 디버깅에 도움이 되는 도구
🔷 Inspection, 정적해석, 소프트웨어 매트릭스
-
문서나 소스 코드를 눈으로 체크하는 것을 inspection 이라고 하며, 문제의 조기 발견에 도움이 된다
-
정적 해석 툴을 사용함으로써 보수하기 어려운 코드를 방지한다
🔶 문제점의 유무를 눈으로 체크한다
🔶 소스 코드를 툴로 진단하다
🔷 Life-Cycle, DevOps
-
소프트웨어는 도입만 하면 끝이 아니라, 폐기 까지 고려해서 업무를 모델화하고 시스템화 계획을 세울 필요가 잇다
-
소프트웨어를 개발할 때는 개발과 운용을 따로 생각하는 게 아니라 협력 체제가 중요하다
🔶 업무를 모델화하여 시스템화 계획을 입안한다
🔶 개발과 운용의 협력체제
🔷 CI(Continuous Integration), CD(Continuous Delivery, Deployment)
-
CI 로 조기에 문제 발생을 방지하고 개발 효율을 높일 수 있다
-
CD 로 릴리즈의 속도를 높인다
🔶 자동으로 빌드하고 테스트한다
🔶 언제든지 릴리스 할 수 있는 상태를 유지한다
🔷 Refactoring
-
리펙토링해도 동작은 변하지 않으므로, 같은 입력에 대해서는 동일한 출력을 얻을 수 있다
-
리펙토링 지표로 소프트웨어 매트릭스를 사용할 수 있다
🔶 읽기 힘든 소스 코드가 만들어지는 이유
🔶 내용은 바꾸지 않고 정리하는 리펙토링
🔷 테스트 주도 개발, 테스트 우선, XP(Extreme Programing)
-
테스트 주도 개발에서는 테스트의 성공으로 재작업이 일어나지 않음을 확인하면서 작업이 진행되므로 버그가 적을 것으로 기대할 수 있다
-
XP 는 비지니스상의 요구가 변회해도 대처하기 쉬운 개발 기법이라고 할 수 있다
🔶 체크할 코드를 사전에 작성
🔶 변경을 받아들여 유연하게 대응하다
🔷 ER 다이어그램, DFD(Yourdon & DeMarco)
-
데이터베이스를 모델화하는 방법으로 주로 ER 다이어그램을 사용한다
-
데이터의 흐름을 표현하기 위해 주로 DFD 를 사용한다
🔶 데이터베이스 설계에 그림을 사용한다
🔶 데이터의 흐름을 시각화하다
ㄱㄷ
🔷 Class, Instance, Object
-
class 는 설계도이며, 사용하기 위해서는 instance 로서 실체화해야 한다
-
한 class 에서 여러개의 instance 를 생성하여, instance 별로 다른 데이터를 처리할 수 있다
🔶 객체 지향에서 사용하는 설계도
🔶 설계도에서 실체를 생성하다
🔷 상속, 서브 클래스, 다중상속
-
상속해서 서브 클래스를 만들면 슈퍼 클래스의 특성도 사용할 수 있다
-
마름모꼴 상속 문제로 프로그래밍 언어에 따라서는 다중 상속이 지원하지 않는다
🔶 기존 클래스를 재사용한다
🔶 상속해서 만드는 새로운 클래스
🔶 여러 클래스를 상속한다
🔷 Field, Method, Property
-
외부에서 필드에 직접 갑을 대입하지 않고, 메소드를 통해 필드에 저장함으로써 부적절한 값이 저장되는 것을 막을 수 있다
-
필드에 저장된 값을 읽어낼 때도 메소드를 사용함으로써 값을 가공해서 출력할 수 있다
🔶 Object가 가진 데이터와 조작
🔶 Object의 속성을 나타내는 말
🔷 캡슐화, 접근지정자
-
캡슐화하면 내부 데이터 구조를 변경해도 호출우너을 변경할 필요가 없어진다
-
클래스 내 필드에 직접 접근할 수 없도록 접근할 수 었는 범위를 접근지정자로 지정한다
🔶 내부 구조를 은폐한다
🔶 접근할 수 있는 범위를 지정한다
🔷 폴리모피즘, 인터페이스
-
폴리모피즘에 의해 다른 클래스에 있는 별개의 메소드를 동일한 이름으로 실행할 수 있다
-
인터페이스를 이용하면 변경에 강한 소프트웨어 개발에 도움이 된다
🔶 복수의 클래스에 같은 이름으로 메소드를 정의한다
🔶 메소드를 정의해 클래스 변경에 대응한다
🔷 AOP(어스팩트 지향 프로그래밍), DI(Dependency injection)
-
어스펙트 지향에 의해 원래 처리 목적과 다른 부분의 소스 코드를 분리함으로써 실현하고자 하는 처리 구현에 집중할 수 있다
-
취급하는 클래스의 인스턴스를 DI의 개념을 이용해 이용자에게 넘겨줌으로써, 사양 변경 등에서 수정 부담을 줄일 수 있다
🔶 본래 처리에 집중한다
🔶 테스트하기 쉽고 유연하게 대응할 수 있는 설계
🔷 생성자(Constructor), 소멸자
-
생성자와 소멸자는 인스턴스가 생성될 때와 소멸될 때 각각 자동으로 호출되므로, 프로그래머가 명시적으로 호출할 필요는 없다
-
인스턴스 내에서 사용하는 메모리 영역을 생성자로 확보하고, 소멸자로 해제하는 방법이 많이 사용된다
🔶 생성시에 반드시 호출되는 ‘생성자’
🔶 소멸될때 반드시 호출되는 ‘소멸자’
🔷
-
-
🔶
🔶
🔷
-
-
🔶
🔶
🔷
-
-
🔶
🔶
🔷
-
-
🔶
🔶
🔷
-
-
🔶
🔶
🔷
-
-
🔶
🔶
🔷
-
-
🔶
🔶
🔷
-
-
🔶
🔶
🔷
-
-
🔶
🔶
🔷
-
-
🔶
🔶
🔷
-
-
🔶
🔶
🔷
-
-
🔶
🔶
🔷
-
-
🔶
🔶
🔷
-
-
🔶
🔶
Reference
그림으로 배우는 프로그래밍 구조 - https://book.jacobko.info/#/book/8931465599
Leave a comment