구현
포트란 : 초창기 언어, 과학기술 계산용. 우주항공 분야에 사용
베이직 : 교육용 언어, 개발환경 시각적, 초보자가 익히기 쉬움
C : 명령형 언어, 모든 환경에서 사용 가능
C++ : C언어에 객체지향의 개념을 더한 언어
C# : 마이크로소프트가 .NET 플랫폼을 위해 만든 객체지향 언어. 유니티가 스크립트 언어로 채택하면서 게임 개발에도 널리 쓰임
자바 : 대형 전산실의 업무용 프로그램. 소스코드를 컴파일하면 플랫폼과 무관한 바이트코드가 만들어지고, 이 바이트코드를 플랫폼마다 따로 구현된 JVM(자바가상머신)이 해석해 실행한다. 플랫폼에 독립적인 것은 컴파일 결과물인 바이트코드이고, 플랫폼에 의존하는 부분은 JVM이 흡수한다
C 코딩 규칙
강의에서는 표준 코딩 규칙으로 다뤘다. 아래 규칙은 포인터 명명과 비트 필드, unsigned 접미사, 매크로 표기처럼 C 계열 언어를 전제로 한다.
- 변수명과 함수명은 31자 이내로 정한다
- 변수명과 함수명은 서로 다르게 짓는다
- 매크로명, 상수명 :
_와 대문자 - 변수명, 함수명 : 소문자로 시작 / 함수의 첫 번째 단어는 동사로(ex.
getData()) - 포인터명 : 참조하는 변수명 앞에 p를 붙인다(ex.
pname) - 소스파일 하나는 200줄 이내
- 한 줄의 길이 80자 이내
- 함수의 내용 70줄 이내
- 여는 중괄호
{는 문장의 끝, 닫는 중괄호}는 문장의 맨 앞 - 용도가 같은 변수는 한 줄에 작성
- 부호 없는 자료형은 끝에 u를 붙인다 → unsigned data type
- 비트 필드는 unsigned/signed int형으로만 선언한다
- 비트 필드 : 구조체 내에서 정수형 변수에 할당된 비트 수를 명시적으로 선언하는 방법
unsigned int count : 5;
- 8진수는 사용하지 않는다
- 값이 바뀌지 않는 값에는 const 변수를 사용한다
.(dot) 연산자와 단항 연산자(++,--)는 붙여 쓴다+ - * /는 공백을 넣는다- 삼항 연산자(
?:)는 맨 앞 수식을 괄호로 묶어준다(a > b) ? x : -x;
- switch문에서 빠져나오기 위해 break문을 한 번만 사용하고, 다 끝나면 default문에서 후속 처리한다
- goto문 사용 금지
테스트
IEEE의 정의 : 예상된 결과와 실제 결과가 어떤 차이를 보이는지 수동이나 자동으로 검사하고 평가하는 작업
소프트웨어 테스트 : 숨어있는 오류를 발견할 목적. 개발 과정에서 생성되는 문서나 프로그램에 있는 오류를 여러 기술을 이용해 검출하는 작업
테스트가 어려운 이유
- 완벽한 테스트 케이스를 도출하기 어렵다
- 실제 사용 환경을 구축하기 어렵다
테스트의 원리
- 개발 단계까지 함께 진행한다
- 개발자와 다른 별도의 팀에서 수행한다
- 파레토 원리 : 20%의 원인이 80%의 결과를 만든다. 오류도 일부 모듈에 집중되어 발생한다
- 살충제 패러독스 : 같은 테스트 케이스를 반복하면 더 이상 새로운 결함을 찾지 못한다(테스트 내성)
- 요르돈의 법칙 : 개발 초기에 테스팅하지 않으면 비용이 커진다
- 오류-부재의 궤변 : 요구사항을 충족시키지 못한다면, 결함이 없어도 품질이 높다고 볼 수 없다
오류 : 개발자에 의해 만들어지는 실수
결함 : 오류에 의해 프로그램이 완전치 못한 것. 주로 필요없는 정보나 필요한 정보가 없는 경우
→ 모든 결함이 반드시 실패를 유발하지는 않음
테스트 절차
SW와 전체 시스템 테스트는 계획 → 케이스 설계 → 실행 및 측정 → 결과 분석(수정 가능한지 불가능한지) → 오류 추적 및 수정 순서로 진행한다.
- 계획
- 업무 시스템별로 구분
- 요구분석명세서 기반으로 테스트할 목표를 정의. 우선순위 파악
- 설계
- 입력값으로 할 원시 데이터(sampling) 작성
- 문제에 적합한 테스트 기법 선정
- 실행 및 측정
- 테스트를 실시하고, 실행 결과를 문서화
- 환경 구축
- 계획 대비 결과를 비교·분석하고 보고서를 작성
- 결과 분석
- 결과값 VS 목표값(계획 단계) 비교
- 테스트 결과 보고서 작성 : 테스트 수행 결과, 사용된 방법, 평가, 권고사항 등
- 오류 추적 및 수정
- 오류 위치, 종류 확인. 제거 계획 수립
- 디버깅 도구 등을 이용해 오류를 수정
- 수정된 코드를 검토한 후 오류 수정 결과 보고서 작성
시각에 따른 테스트
- 검증 Verification 테스트 : 개발자의 시각으로 테스트. 설계서 대로 만들었는지 테스트
- 이전 단계 산출물이 현 단계의 산출물에 반영이 되었는지
- 요구분석명세서 내용이 설계서에 반영 → 설계서의 내용대로 코딩해야 함
- 불완전한 개발 결과를 가졌다는 한계점
- 확인 Validation 테스트 : 체크리스트, 요구사항대로 만들었는지 테스트
- 검증과 확인 둘 다 해야 강력한 테스트
- V & V (Verification and Validation) 검증 + 확인
사용목적에 따른 테스트
- 성능 테스트 : 요구사항 중에서 성능과 관련된 요구사항을 시스템이 얼마나 준수하는지
- 효율성, 부하에 대한 실행시간, 응답시간, 처리능력, 자원 사용량 등 체크+테스트
- 스트레스 테스트 : 비정상적이고 과도한 부하 상황에서 시스템이 잘 견디는지, 발생하는 오류는 어떤 것들인지 확인
- 보안 테스트 : 불법적인 침투를 잘 막아내는지 테스트 (ex. 화이트 해커)
- 안정성(내구성) 테스트 : 며칠 동안 부하를 주면서 안정적으로 돌아가는지 테스트 → 메모리 누수(메모리 반납하지 않음)
- 복원 가능성 테스트 : 고장나게 하고, 자동으로 복구가 잘 되는지 회복의 완벽성을 평가 ⇒ OS, DBMS, 통신용 소프트웨어의 안정성 테스트에 적용
정적 테스트
속성, 내부 살핌
코드를 실행하지 않고, 명세나 코드를 검토해 결함을 찾아냄
비공식 검토 : 개별검토, 동료검토 / 동료
공식 검토 : 검토회의, 소프트웨어 검사 / 동료 + 소프트웨어 기술 전문가
- 동료검토 : 2~3명. 명세서를 설명하고, 이해관계자들이 설명을 들으면서 결함을 발견
- 인스펙션
- 형식적 검토 기법
- 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아냄
- 워크스루
- 비형식적 검토기법
- 검토 자료를 회의 전에 배포해서 사전 검토한 후 짧은 시간동안 회의를 진행하는 형태
- CASE 도구
- 자동화된 요구사항 관리 도구를 이용해 요구사항의 추적성과 일관성을 검토
다음 두 기법은 검토 기법이 아니라 요구사항 도출 단계에서 쓰인다.
- 델파이 기법 : 전문가의 경험지식을 통한 문제 해결 및 미래 예측을 위한 방법
- 롤 플레잉 : 현실에서 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함
동적 테스트
구조 기반 테스트 : 프로그램 코드의 내부 구조를 테스트 설계의 기반으로 사용. 변수나 서브루틴 등
화이트박스 테스트
구문, 결정, 조건, 조건/결정, 변경 조건/결정, 다중 조건, 기본 경로, 제어 흐름, 데이터 흐름
- 구문 Statement 커버리지 : 모든 명령문을 적어도 한번 수행. (수행구문/전체구문) X 100%
- 결정, 선택, 분기 Decision 커버리지 : 결정 포인트 내의 전체 조건식이 적어도 한번은 참과 거짓의 결과가 되도록 수행
- 조건 Condition 커버리지 : 결정 포인트 내의 개별 조건식이 적어도 한번은 참과 거짓의 결과가 되도록 수행
- 조건/결정 커버리지 : 전체 조건식 + 개별 조건식 다 테스트
- 변경 조건/결정 커버리지 : 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함
- 다중 조건 Multiple 커버리지 : 모든 개별 조건식의 모든 가능한 조합을 100% 보장하는 커버리지
- 기본 경로 Base Path 커버리지 : 순환 복잡도만큼의 선형 독립 경로 집합을 테스트. 루프가 있으면 수행 가능한 경로가 무한히 많아질 수 있어 모든 경로를 테스트하지는 않는다
- 맥케이브 순환 복잡도 : 간선 수(화살표) - 노드 수(원) + 2 또는 그래프가 나누는 영역의 수(바깥 영역 포함)
위 그래프는 간선 9개, 노드 8개이므로 9 - 8 + 2 = 3이다. 영역은 안쪽의 R1·R2와 곡선 바깥의 R3를 합해 세 개이므로 두 방법의 결과가 같다.
- 제어 흐름 Control Flow 테스트 : 프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직 테스트
- 데이터 흐름 테스트 : 제어 흐름 그래프 + 사용현황 추가
명세 기반 테스트 : 내부 구조 보지 않고, 요구사항명세를 보면서 실행하는 테스트
블랙박스 테스트 - 동계원오비 / 동경결상 유분페 원비오
- 동등 분할 Equivalence Partitioning 테스트 : 입력 데이터의 영역을 유사한 도메인별로 유효값/무효값을 그룹핑하여 대푯값 테스트 케이스를 도출하여 테스트
- 경곗값 분석 Boundary Value Analysis 테스트 : 입력 범위의 경계에서 결함이 자주 발생하는 점을 이용하는 기법. 경곗값 자체와 그 양쪽 인접값(경곗값 -1, 경곗값, 경곗값 +1)을 고르는 3값 방식으로 정리한다
- 결정 테이블 Decision Table 테스트 : 요구사항의 논리와 발생조건을 테이블 형태로 나열하여, 조건과 행위를 모두 조합하여 테스트
- 첫 번째 조건은 주문이 유효한지, 두 번째 조건은 재고가 충분한지를 체크한다
| 구분 | 규칙 1 | 규칙 2 | 규칙 3 |
|---|---|---|---|
| 주문이 유효한가? | Y | Y | N |
| 재고가 충분한가? | Y | N | - |
| 주문 처리 | Y | N | N |
| 재고 주문 | N | Y | N |
| 오류 메시지 | N | N | Y |
- 상태 전이 State transition 테스트 : 이벤트에 의해 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 수행하는 테스트
- 유스케이스 Use Case 테스트 : 프로세스 흐름을 기반으로 테스트케이스를 명세화하여 수행하는 테스트
- 분류 트리 Classification Tree 테스트 : SW의 일부 또는 전체를 트리구조로 분석 및 표현하여 테스트 케이스 설계해 테스트
- 페어와이즈 Pairwise 테스트 : 테스트 데이터 값들 간에 최소한 한 번씩을 조합하는 방식
- 원인-결과 그래프 Cause-Effect Graphing 테스트 : 그래프를 활용해 입력 데이터 간의 관계 및 출력에 미치는 영향을 분석
- 비교 Comparison 테스트 : 여러 버전의 프로그램에 같은 입력값을 넣어 비교해 테스트
- 오류 예측 검사 : 경험, 감각
V모델 - 단통시인
단위테스트 : 프로그램의 기본 단위인 모듈을 테스트
- 정적테스트 : 소스코드 분석
- 동적테스트 : 실행시켜서 확인
- 구조기반 - 화이트박스
- 명세기반 - 블랙박스
통합테스트 : 모듈 통합 과정에서 오류 찾음
- 상향식 : 아래부터 위로, 클러스터 단위, 드라이버 가상의 모듈
- 하향식 : 위부터 아래로, 스텁 가상의 모듈, BFS, DFS
- 빅뱅 : 한번에 결합해 테스트
- 백본 : 핵심 골격이 되는 모듈을 먼저 통합해 뼈대를 만든 뒤, 주변 모듈을 단계적으로 붙여 나감. 뼈대의 위아래로 하향식과 상향식을 함께 사용한다
시스템테스트 : 시스템 작동하는지 테스트
- 기능 : 사용자 요구사항
- 비기능 : 성능, 보안, 신뢰성, 사용성 등이 있고 요구사항마다 적합한 기법을 골라 적용한다
- 성능 → 성능 테스트, 과부하 상황은 스트레스 테스트
- 보안 → 보안 테스트
- 신뢰성 → 안정성(내구성) 테스트, 복원 가능성 테스트
인수테스트 : 시스템 인수하기 전에 예상동작, 요구사항에 맞는지 테스트
- 알파 : 사용자 + 개발자
- 베타 : 사용자
회귀테스트 : 수정된 모듈이 기존코드에 영향을 미쳤는지 확인, 점진적으로 테스트