소프트웨어 공학 이론과 실제 13장 ~ 16장

C13 코딩

1. 프로그래밍 언어 유형

2. 좋은 코딩 기법

• 좋은 소프트웨어 코드의 6가지 공통점
• 쉽게 읽을 수 있다
• 주석이 잘 작성되어 있다
• 코드 구조가 간결하다
• 변경에 탄력적이다
• 활용을 위해 관리할 수 있어야 한다
• 제 기능을 해야 한다

• 좋은 코드 작성을 위한 규칙
• 최적화보다는 가독성이 우선이다
• 아키텍처를 우선 개발하라
• 테스트 커버리지를 고려하라
• 간단하고 단순하게 코딩하라
• 주석을 작성하되 보조적으로 사용하라
• 강한 결합과 느슨한 결합을 추구하라 → 구성 모듈간에 강하게, 서비스 간에 느슨하게
• 코드 리뷰가 항상 좋은 것은 아니다
• 그러나 사람을 칠칠맞기에 하는게 좋다고 생각
• 리팩토링은 작동하지 않는다
• 피곤하거나 컨디션이 좋지 않을 때는 코딩하지 마라
• 모든 것을 한 번에 작성하지 마라. 반복적으로 개발하라
• 가능하면 자동화 도구를 사용하라
• 취미를 가져라
• 여유 시간에 새로운 것을 배워라

3. 코딩 가이드라인

• MISRA-C 코딩 표준
• 2012 버전 기준 159개의 규칙 존재
• ex) Dir 1.1: 프로그램의 출력으로 정의된 행위는 모두 문서화하고 이해될 수 있어야 한다.

• 시큐어 코딩
• 구현 단계에서 해킹 등의 공격을 유발할 가능성이 있는 잠재적인 보안 취약점을 사전에 제거하여, 외부 공격으로부터 안전한 SW를 개발하기 위한 프로그래밍 기법
• 이를 위한 CERT C 코딩 표준등이 있다
• 각 규칙에 대하여 1~3의 심각성/발생 가능성/교정비용이 할당되어 있다.
• ex) 함수와 같은 매크로의 호출문의 내에서 전처리기를 사용하지 마라

4. 오픈 소스 기반 개발

• 오픈 소스 기반 개발 프로세스

• 오픈 소스 활용 시 주의 상황
• 라이선스 권한의 확인 검토
• MIT, BSD, Apache 써도 됨
• GPL 쓰지 말기…
• 오픈 소스 검증 체계 구축
• 지속적인 오픈 소스 관리
• 철저한 기술 검토
• 오픈 소스 변경 사항 기록

• 오픈 소스 활용 환경
• 검색 및 분석 도구: Solr, ElasticSearch, Lucene, Sphinx
• 개발 지원 도구: Git, Eclipse IDE, Apache NetBeans, Ruby on Rails, Bootstrap

C14 화이트박스 테스트

1. 테스트 개요

• V&V → Verification(검증)&Validation(검사)
• Verification: 이전 산출물과 현재 결과물이 동일한지
• Validation: 산출물이 사용자의 요구사항을 충족하는지

• SW V&V 활동
• 정적 활동: 리뷰, 코드 리딩, 프로그램 증명
• 동적 활동: 소프트웨어 테스트

소프트웨어 테스트

• SW 테스트: 입력 데이터 → SW 실행 → 의도된 결과와 실제 결과 비교

테스트 케이스와 테스트 오라클

• 테스트 케이스: 테스트를 수행하기 위한 입력 데이터

• 테스트 오라클: 실행 결과를 검증하기 위한 메커니즘 ← 테스트 케이스의 예상 결과를 만들어내기 어려울 때

테스트의 단계

• 단위 테스트: 모듈/함수 중심 테스트

• 통합 테스트: 모듈을 통합하며 수행하는 테스트. 모듈 간의 인터페이스 정확성이 주 관심 사항

• 시스템 테스트: 개발된 SW를 테스트

• 인수 테스트: 사용자 환경에서 개발된 SW를 테스트

• E2E 테스트: 시스템 같지만, regression/installation test다?

• 테스트 자동화 툴: sikulix

2. 코드 기반 테스트 케이스 생성 기법

• 화이트박스 테스트: 코드를 수행하지 않고, 구조만 고려하여 테스트 케이스를 생성하는 방법
• 구조적 테스트라고도 불림

제어 흐름 그래프

• 코드의 실행-종료 까지의 제어 흐름을 플로우 차트로 표현한 것

경로 기반 테스트 케이스 생성

• 테스트는 제어 흐름 그래프에서 준비 데이터가 모든 제어 흐름을 거쳐가는지 고려해야 한다
• → 커버리지

• 문장 커버리지(Statement Coverage)
• 모든 문장을 한 번씩 거쳐 가야한다는 조건을 만족하게 Path를 선택하는 것
• 1 → 2 → 3 → 4 → 5 → 2 → 6

• 분기 커버리지(Branch Coverage)
• 모든 분기를 적어도 한번씩 거쳐 가도록 Path를 선정하는 것
• if문 기준 모든 참/거짓, for/while에서는 적어도 한번 루프의 내부가 실행되게
• 1 → 2 → 3 → 4 → 5 → 2 → 6
• 1 → 2 → 3 → 5→ 2 → 6

• 데이터 흐름 커버리지(Data Flow Coverage)



• All-Defs: 선언된 모든 변수를 적어도 한 번 사용하는 경로까지 테스트
• 변수 i에 대해 1 → 2 또는 4 → 5
• 변수 A에 대해 4 → 5 → 2
• All-Uses: 선언된 하나의 변수를 사용하는 모든 지점까지 테스트
• All-DU: 선언된 모든 변수를 사용하는 모든 지점까지 커버

• 조건 커버리지(Condition Coverage)
• 조건문에 대하여 모든 가능한 결과가 적어도 한 번씩 나타날 수 있도록

• 다수 조건 분기 커버리지(MC/DC Coverage)
• 조건 커버리지와 분기 커버리지를 동시에 만족하는 테스트 케이스를 생성하기 위한 방법
• 결론은 MC/DC를 봐야한다는 것

3. 오류 기반 테스트

• 뮤턴트 커버리지
• 원본 코드에 결함을 주입하여 뮤턴트 코드를 만든다
• 이때 테스트 케이스가 실패하면 테스트 케이스가 꼼꼼하게 짜여졌다고 볼 수 있다

4. 동적 심볼릭 테스트

• 콘콜릭 테스트

기호 실행

콘콜릭 실행

C15 블랙박스 테스트

1. 블랙박스 테스트 개요

• 블랙박스 테스트: 소스 코드에 대한 정보 없이 요구사항 명세만 이용하여 테스트 케이스를 생성하는 기법
• 기능적 테스트라고도 부른다

2. 기능 기반 테스트 케이스 생성 기법

동치 분할 기법

• 유효 동치 클래스: 프로그램이 정상적으로 처리할 것으로 기대되는 유효한 입력값들의 집합

• 무효 동치 클래스: 프로그램이 오류를 반환할 것으로 예상되는 유효하지 않은 입력값들의 집합

• ex) 0~100 사이의 점수를 입력받아 학점을 부여하는 프로그램 → 50 하나, 110 하나를 입력으로 주기

경계치 커버리지 분석

• [-1.0, +1.0] → -1.1, -1.0, 1.0, 1.1

• 1 ~ 100 → 0, 1, 100, 101

• A ~ F → A, F

특수치 커버리지 분석

원인 결과 커버리지 분석

• 의사결정 테이블
• ~

• 원인-결과 그래프
• ~

블랙박스 테스트 케이스 생성 예제

3. 시나리오 기반 테스트

테스트 시나리오 생성 방법

테스트 시나리오 생성 예제

아웃라인 방법에 의한 테스트 케이스 생성

유즈 케이스 방법에 의한 테스트 케이스 생성

4. 테스트 단계

단위 테스트

통합 테스트

시스템 테스트

인수 테스트

회귀 테스트

카오스 테스트

혼돈 테스트란 무엇인가? - Dev Proxy

이 문서에서는 비정상 상황 테스트의 개념과 보다 탄력적인 앱을 빌드하는 데 어떻게 도움이 되는지 설명합니다.

https://learn.microsoft.com/ko-kr/microsoft-cloud/dev/dev-proxy/concepts/what-is-chaos-testing

• 테스트 드라이버: caller → postman 같은거, JUnit, pytest 같은 것

• 테스트 stub: mock api 같은 거

• 테스트 하네스 개념 찾아보기

• given when then
• given: 상태만 줘야한다
• when: 트리거링만 해야한다
• then 결과를 봐야한다

• api 멱등성등도 체크해야한다

• 그래서 그냥 gwt 해서 api가 정상작동한다~ 하고 끝나면 안된다

• 즉 test 코드를 짜는건 좋다 ~

C16 소프트웨어 개발 적용 기술

1. 형상 관리

• 형상 관리
• 변경의 기준이 되는 항목을 식별하고 정의
• 정의된 항목에 대하여 변경과 배포를 통제
• 변경 요청 및 항목의 변경에 대하여 기록-관리
• 개발 항목에 대한 완전성, 일관성, 정확성 보장

• 형상 관리 절차
• 형상 식별
• 형상 통제
• 상태 보고
• 형상 감사

2. 코드 리팩토링

• 리팩토링: 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법

3. 관점지향 프로그래밍

• AOP(Aspect-oriented programming)

• 모든 프로그래밍 패러다임은 관심사의 분리를 통해 문제 영역을 독립적인 모듈로 분해될 수 있어야 하는데, OOP를 적용해도 분리될 수 없는 부분이 존재 → AOP의 시작

• 기존 OOP의 문제점
• 중복되는 코드
• 지저분한 코드: 횡단 관심 코드들이 핵심 코드 사이에 끼어있어 가독성이 떨어짐
• 생산성 저하: 횡단 관심을 구현한 코드를 작성하기에 생산성이 저하
• 재활용성 저하: OOP에서도 모듈화되지 않는 부분이 존재
• 변화의 어려움

• 조인 포인트: 횡단 관심 모듈의 기능이 삽입되어 동작할 수 있는 특정 위치
• ex) 메서드가 호출되는 부분, 리턴되는 시점, 예외 처리가 필요한 시점, 인스턴스 생성 시점

• 포인트 컷: 어떤 클래스의 어느 조인 포인트를 사용할 것인지 결정하는 선택 기능

• 어드바이스: 각 조인 포인트에 삽입되어 동작하는 코드

• 위빙: 포인트 컷에 의해 결정된 조인 포인트에 어드바이스를 삽입하는 과정

• 에스팩트(Aspect): 포인트 컷과 어드바이스를 합친 것. 기본 작업 단위로, 객체지향의 클래스와 비슷한 역할을 수행

package com.example.aop.aspect;

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;
import org.springframework.stereotype.Component;

/**
 * Aspect: 포인트컷과 어드바이스를 합친 모듈.
 * 이 클래스는 로그를 남기는 부가 기능을 담당합니다.
 * @Aspect: 이 클래스가 Aspect임을 나타냅니다.
 * @Component: Spring이 이 Aspect를 Bean으로 관리하도록 합니다.
 */
@Aspect
@Component
public class LoggingAspect {

    /**
     * Pointcut: 어드바이스를 적용할 위치(Join Point)를 선별하는 기능.
     * 'com.example.aop.service' 패키지 아래의 모든 클래스의 모든 메서드 실행을 대상으로 지정합니다.
     */
    @Pointcut("execution(* com.example.aop.service.*.*(..))")
    private void serviceLayerExecution() {}

    /**
     * Advice: 실제 실행될 부가 기능 로직.
     * @Before: 타겟 메서드가 실행되기 '전'에 이 어드바이스를 실행합니다.
     * "serviceLayerExecution()" 포인트컷에 의해 선택된 모든 조인 포인트에 이 어드바이스가 적용됩니다.
     *
     * @param joinPoint: 현재 실행되는 조인 포인트(메서드)에 대한 정보를 담고 있습니다.
     */
    @Before("serviceLayerExecution()")
    public void logBefore(JoinPoint joinPoint) {
        // 현재 실행되는 메서드의 이름을 가져와 출력합니다.
        String methodName = joinPoint.getSignature().getName();
        System.out.println("====== [AOP 로그] " + methodName + " 메서드 실행 전 ======");
    }
}

4. 탐색기반 소프트웨어 공학

• 방대한 데이터로부터 최적의 솔루션을 찾는 방법

• SW 공학에서는 많은 문제가 최적화 문제로 연결됨

• 문제 구조를 가정하지 않는 메타 휴리스틱 검색 기술을 사용하여 최적에 가깝거나, 충분히 좋은 솔루션을 찾고자 하는 것