천객만래 [千客萬來] (It has an interminable succession of visitors)
  • 아래 내용들은 ISTQB FL 시험준비 & 테스팅공부를 위해 다음 출처의 자료들로 공부하며 정리한 것 입니다 *

  • 출처 : 개발자도 알아야할 소프트웨어 테스팅 실무 제3판

  • 출처 : 문제로 배우는 소프트웨어 테스팅 2

  • 출처 : Certified Tester Foundation Level Syllabus version 2011 Korean

[1] 소프트웨어 개발 모델

테스팅은 소프트웨어 개발활동과 독립적으로 존재하지않고 밀접하게 연계되어있으므로,

개발수명주기모델에 기반하여 테스트 접근법을 다르게 적용해야한다

  1. V-모델 (순차적 개발 모델)

※ 참고 : 폭포수모델

  • 폭포수 모델은 개발이 종료된 후 테스팅을 시작한다

  • 폭포의 물이 위에서 아래로 떨어지듯이 계획, 분석, 설계, 구현, 테스트, 유지보수의 각 단계가 하향식(top-down)으로 진행되며, 병행되거나 거슬러 반복되지 않는다. 각 단계가 끝날 때마다 확실히 매듭을 짓고 그 결과를 확인한 후에 다음 단계로 진행한다.

https://terms.naver.com/entry.nhn?docId=3532871&cid=58528&categoryId=58528&expCategoryId=58528

폭포수 모델의 개발 절차
폭포수 모델에서는 폭포의 물이 위에서 아래로 떨어지듯이 계획, 분석, 설계, 구현, 테스트, 유지보수의 각 단계가 하향식(top-down)으로 진행되며, 병행되거나 거슬러 반복되지 않는다. 각 단계가 끝날 때마다 확실히 매듭을 짓고 그 결과를 확인한 후에 다음 단계로 진행한다. 폭포수 모델을 적용한 개발 절차에서는 요구 사항 분석 단계가 끝나면 '요구 분석 명세서'라는 문서가 산출된다. 이 명세서를 기준으로 사용자에게 이상 유무를 확인받고 다음 단계인 설계 절차로 넘어간다. 이렇게 각 단계에서 생성되는 산출물에 대해 확인 절차를 거...

terms.naver.com

https://terms.naver.com/entry.nhn?docId=3532872&cid=58528&categoryId=58528&expCategoryId=58528

폭포수 모델의 장점과 단점
폭포수 모델은 각 단계마다 요구 분석 명세서, 설계 사양서, 코드 문서, 데이터베이스 매뉴얼, 사용자 매뉴얼, 운영 매뉴얼 등의 상세한 문서가 생성되는 문서 중심의 모델이라 할 수 있다. 또 각 단계가 명확히 구분되어 있다. 각 단계에서는 산출물이 만들어지고 이 산출물은 다음 단계의 입력 자료로 사용된다. 따라서 해당 단계의 오류를 수정하지 않고 다음 단계로 넘어가면 그 오류가 끝까지 남을 수 있으므로 초기 단계에서 오류를 해결하는 것이 매우 중요하다. 소프트웨어 개발에서 폭포수 모델을 사용했을 때의 장점은 다음과 같다. ■ 관리가...

terms.naver.com

[출처 : 네이버 지식백과 (쉽게 배우는 소프트웨어 공학, 2015. 11. 30., 한빛아카데미(주))]

<V-모델>

※V-모델 그림 참고 (p.49)

  • 폭포수 개발모델에 근간

  • 개발 단계에 대응하는 테스트레벨이 별도로 존재. 하지만, 일대일 대응은 아니다.

  • 각각의 개발단계에서 테스팅을 접근하는 방법을 간략히 모델화한 것

  • 개발단계와 테스팅활동이 어떻게 통합될수 있는지 설명한다.

  • 실제업무에 적용시에는 특성에 맞게 변형하여 사용한다.

  • 실업무에서 프로젝트,소프트웨어제품의 특성에 따라 v모델에서의 개발단계 및 테스트레벨을 더 많이 혹은 더 적게 구성할 수 있다.

(에) 컴포넌트 테스팅 이후에 컴포넌트통합테스팅이있을 수 있고, 시스템테스팅 이후에 시스템통합테스팅이 존재할 수 있다.

  • 소프트웨어 개발기간중의 '개발산출물(Work products)'은 하나이상의 테스트레벨에서 '테스트베이시스'가 된다.

(예) 일반적인 개발산출물 : CMMI, 소프트웨어 라이프 사이클 프로세스 참고. ??

  • 테스트분석가는 요구사항을 명세화하는 시점에 맞춰 테스트분석,설계를 시작한다

<V-모델을 통한 테스팅의 기본개념>

1) 테스트레벨 ​

  • V-모델에서 제시하는 테스트레벨

(1) 컴포넌트(단위) / 통합 - 하위레벨

(2) 시스템 / 인수 테스팅 - 상위레벨

  • 각 테스트레벨은 서로 독립적인 테스트 수명주기를 가진다. : 각각 다른 테스트전략,계획,기법,목적,수행주체,완료기준 등을 가진다.​

  • 각 테스트레벨은 서로 종속성을 지닌다. : 하나의 테스트레벨에서 다른 테스트레벨로 옮겨가기 위한 종료/시작조건을 갖춰야 한다.

2) 개발 초기 단계에서 테스팅을 수행

→ 정적 테스팅 (리뷰 등)

  • 개발 산출물을 리뷰(Review)형태로 검토하면서 결함을 발견

  • 개발이 시작됨과 동시에 진행한다

  • 테스터는 테스팅관점에서 테스트케이스를 만들면서 결함을 발견하여 리뷰에 기여한다.

  • 요구분석단계에서 테스트케이스를 작성해두면 인수테스팅시 많은 도움이 된다.

  • 정적테스팅 : 결정테이블테스팅, 상태전이 테스팅, 유즈케이스 테스팅 ※4장. 설계기법 참고

3) 결함 예방차원에서의 테스팅

  • 개발초기에 발견한 결함은 수정비용이 저렴

  • 개발초기에 테스트 베이시스가 되는 개발 산출물을 리뷰, 조기에 테스트를 설계하여, 결함을 사전에 예방

4) V&V (베리피케이션 & 벨리데이션)

  • 소프트웨어 개발 수명주기의 전(모든) 단계에서 수행가능

  • 정적테스팅(인스펙션과 같은 리뷰활동) 또는 동적테스팅 모두에서 검증가능

(1)베리피케이션(Verification)

: 개발 단계의 산출물이 그 단계의 '초기에 설정된 조건'을 만족하는지 여부를 검증하는 프로세스

  • 주어진 개발 단계의 제품이 그 단계에서 정의한 대로 조건을 만족하는지, 시스템이나 컴포넌트를 평가하는 프로세스.

  • ISO9000 : 명세된 요구사항이 충족됐는지를 조사에 의해서나 객관적증거제공으로 확인하는 것

  • 수명주기초기에 발생하는 중간산출물에 대해 베리피케이션을 실시하여, 처음에 정의한 대로 조건을 만족하는 시스템이나 컴포넌트가 구현됐는지 사전에 일부검토가 가능하다.

  • 이점 : 결함을 예방

(2)벨리데이션(Validation)

: 개발 중 또는 개발단계 말에 명시된 사용자의 관점에서의 '요구사항'이 만족하는 지를 평가하는 프로세스

  1. 반복적-점증적 개발모델 (Iterative-incremental)

※ 모델 그림 참고 (p.53)

  • 개발주기(요구사항분석-시스템설계-구현 및 테스팅)가 짧게 연속적으로 '반복'하는 활동으로 이루어진다

  • 초기반복단계에서 리스크가 높은 모듈이나 주요 아키텍처에 해당하는 시스템 일부를 우선적으로 개발, 테스팅한다

  • 단위 테스트 프레임 워크 도구를 이용해 개발자가 테스트 주도 개발을 하는 것이 매우 중요하다.

(ex) 테스트 자동화 도구 도입을 통한 테스팅

  • 하나의 반복단계에서 생성한 산출물(프로그램,시스템)은 일반적으로 테스트레벨을 거치면서 검증된다.

  • 이전 반복단계에서 개발한 결과물은 현재의 반복에서 추가개발한 증분(증가된 부분)에 의해 규모가 커져 부분시스템(Partial system)을 형성한다.

  • 이때, 현재반복단계의 증분도 테스팅해야하지만, 부분시스템역시 리그레션여부의 확인목적으로 테스팅해야한다.

  • 리그레션테스팅 : 반복단계가 거듭될수록 중요해진다.

  • 베리피케이션, 벨리데이션 : 각 증분산출물(부분시스템)을 대상으로 수행될 수 있다.

< 장점 >

(1) 조기에 결함과 장애를 발견하고 제거가능하다. (개발리스크를 조기에 감소)

(2) 요구사항이 변경되었을 때 빠르게 반영가능하다.

< 반복적 개발모델에서의 테스팅 이슈 >

: 초기개발단계에서의 테스팅 및 테스트환경과 개발이 반복진행되면서, 테스팅 및 테스트환경이 변경된다.

  • 제한된 세트의 집중된 테스트에서, 광범위한 세트의 분산된 테스트로 확장

  • 테스트 대상 컴포넌트가 점차 증가

  • 단순한 테스트환경에서, 복잡한 테스트환경으로 변화

  • 시간이 지남에 따라 개별 유즈케이스 테스팅에서, 유스케이스간의 통합 테스팅으로 변화

< 주요 모델 > : 반복적으로 개발하는 모델들

  • 애자일 개발 모델 (민첩) (Agile) : XP(eXtreme Programming) , SCRUM 등

  • 래셔널 통합 프로세스 : RUP (Rational Unified Process)

  • 래피드 애플리케이션 개발 : RAD (Rapid Application Development)

  • 이해 관계자 중심의 소프트웨어 개발 (Outside-in Software Development)

  • 프로토타이핑 (Prototyping)

<애자일 테스팅 특징>

  • 테스트를 미리 설계하지 않을 수 있으며, 누구나 테스트에 적극참여가능 (사용자,테스터,개발자)

  • 결함을 최대한 빨리 발견가능 (요구사항을 개발과 동시에 발견가능)

  • 문서를 최소화한다

  • 테스트는 개발과 같이시작되거나 먼저시작되므로, 개발완료 = 테스트완료 이다.

  1. 개발 수명주기 모델 (Life Cycle)에서의 테스팅
  • 테스트 레벨은 프로젝트, 시스템아키텍쳐의 성격에 따라 재조정, 합쳐질 수 있다

(예) 상용(COTS : Commercial Off The Shelf)소프트웨어 제품을 시스템에통합할때

  • 구매자는 시스템레벨에서 통합테스팅 / 인수테스팅을 수행할 수 있다

  • 통합테스팅 : 인프라나 다른 시스템에 통합, 배포된 시스템에 통합

  • 인수테스팅 : 기능적 테스팅, 비기능적 테스팅, 사용자 테스팅, 운영 테스팅 등 수행

<성공적인 테스팅 요건>

  • 모든 개발 활동은 이에 상응하는 테스팅활동을 동반한다

  • 각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가지고 있다

  • 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되는 개발활동 동안에 시작​되어야 한다

  • 개발산출물 리뷰 : 개발 수명주기 동안에 개발 산출물의 초안이 작성되면, 테스터는 이러한 문서를 리뷰하는 활동에 참가해야 한다.

[2] 테스트 레벨(Test Levels)

< 각 테스트레벨 특징에 맞게 정의&식별되는 항목>

  • 일반적인 목표 : 목적

  • 테스트 케이스를 도출해내는데 참조되는 개발산출물 : 테스트베이시스

  • 테스트 대상 : 테스트할 그 무엇

  • 발견된 전형적 결함, 장애

  • 테스트 하네스 (드라이버,스텁), 툴 필요여부

  • 상세한 테스트 접근법

  • 테스트 수행주체, 조직

<화이트박스&블랙박스 테스팅>

  • 컴포넌트 테스팅 - 화이트박스

  • 시스템 테스팅 - 블랙박스

  1. 컴포넌트 테스팅(Component Testing) = 단위 테스팅(Unit Testing) = 모듈 테스팅 = 프로그램 테스팅

: 테스트가 가능한 최소단위로 나누어진 소프트웨어 (모듈,프로그램,객체,클래스 등) 내에서 결함을 찾고 그 기능을 검증하는 것

  • 개발 수명주기의 정황과 시스템에 의존적이면서도 시스템의 다른부분에서 격리하여 독립적으로 수행할 수 있다.

이떄, 스텁, 드라이버, 시뮬레이터가 사용될 수 있다.

  • 테스트케이스는 개발산출물에서 도출된다 : 컴포넌트명세, 소프트웨어상세설계, 데이터모델과 같은 개발산출물

  • 일반적으로 코드를 중심으로 수행하며, 개발환경의 지원을 필요로 한다 : 단위테스트프레임웍, 디버깅 툴과 같은 개발환경

  • 실무에서 개발자가 직접 테스트에 참여하여 결함을 바로수정하며, 기록과정은 일반적으로 생략한다.

그러나 프로세스관리,개선을 위해 결함에 대한 통계적 데이터가 필요한 경우는 인시던트(결함) 기록과정이 필요하다

  • 테스트 중심의 개발방법론 (Test-first approach / test driven development) : 코딩전 테스트케이스를 준비하고 자동화하는 방법이다. 반복적성향이 매우 강한 접근법으로 테스트케이스를 개발한 후 작은 규모의 코드를 작성, 통합하고 테스트가 통과할 떄까지 반복수행한다.

  • V모델에서 하위레벨 테스트에 속한다.

  • 테스팅

  • 주된 테스팅 방식 : 구조기반테스팅(화이트박스)

  • 구조적 : 분기커버리지등

  • 기능성

  • 비기능성 : 리소스 메모리유출 관련, 강건성 테스팅 등..

  • 수행주체

: 주로 개발자가 직접, 타개발자, 제3자 테스터

<목적>

  • 기본경로(Path)확인

  • 모든 오류처리경로(Error handling path) 확인

  • 컴포넌트 내의 인터페이스 확인

  • 로컬 데이터 확인, 경계값 확인

<테스트 베이시스>

  • 컴포넌트 요구사항

  • 상세설계 / 프로그램 상세 설명서

  • 코드

<테스트 대상>

  • 컴포넌트

  • 프로그램

  • 데이터변환, 마이그레이션 프로그램

  • 데이터베이스 모듈

  1. 통합 테스팅 (Intergration Testing)

: 컴포넌트간의 인터페이스를 테스트하는 것

: 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트 하는 것 (OS,파일,시스템,하드웨어,시스템간 인터페이스)

  • 단위간의 결합과 인터페이스를 중점적으로 검증한다.

  • 개별모듈의 내부 기능성에는 관심을 두지 않는다.

  • 컴포넌트테스팅은 개별모듈의 기능에 관심을 두지만, 통합테스트는 두개 모듈사이의 커뮤니케이션에 관심을 둔다.

  • ??? 통합의 각 단계에서 테스터는 통합 그 자체에만 집중(실라버스) / 통합그자체에만 집중하는 오류를 범하지 말아야 한다(책)

  • 이상적으로는 테스터가 이키텍처에 대한 이해를 바탕으로 통합테스팅계획에 관여해야한다.

  • 컴포넌트 또는 시스템이 만들어지기 전에 통합테스트를 계획한다면, 테스팅을 가장 효율적으로 수행할 수 있도록 컴포넌트 개발순서를 계획할 수도 있다.

  • V모델에서 하위레벨 테스트에

  • 테스팅

  • 기능적 / 비기능적(성능,연결성) 특성을 테스팅해야한다

  • 테스팅설계 : 기능적 / 구조적 접근법 모두 사용하여, 통합 그 자체만 집중하는 오류를 범하지 말아야 한다.

  • 수행주체

: 테스터

  • 하나이상의 테스트 레벨이 있을 수 있으며, 다양한 크기의 테스트 대상에 대해 수행될 수 있다.

1) 컴포넌트 통합 테스팅 : 소프트웨어 컴포넌트 사이의 상호작용을 테스트하며 컴포넌트 테스팅 이후에 수행된다

2) 시스템 통합 테스팅 : 서로 '다른 시스템간' 또는 하드웨어, 소프트웨어간 상호작용을 테스트하며, 시스템 테스팅 이후에 수행된다.

  • 타 시스템과의 연동 테스트

  • 개발조직은 한쪽 시스템에 국한되어 제어 권한을 갖고, 이는 리스크로 간주됨 : 변경발생시 시스템전체차원에서 불안정유발

  • 비즈니스 프로세스가 시스템간의 업무흐름을 가지고 있는 경우, 시스템간 교차점에서 중대한 문제를 야기가능

  • 통합하는 범위가 크면 클수록 장애,결함의 위치를 찾아 격리하기가 어렵다. → 개발리스크/문제해결(Troubleshooting)시간 증가

  • 통합하는 범위가 클수록, 특정 컴포넌트나 시스템에서기인하므로.

(ex) 빅뱅 접근법 : 점진적 통합방식에 비해 결함발견이 늦어져 리스크로 작용할 확률이 높다

  • 따라서, 결함을 쉽게 격리하고 조기발견하기위해서 순차적, 체계적인 통합전략(Incremental approach)을 사용해야 한다

  • 빅뱅전략 x / 상향식, 하향식, 백본 o

  • 시스템 통합 전략은 시스템아키텍처 (상향식/하향식), 기능적테스트, 트랜잭션 처리순서, 시스템 또는 컴포넌트의 다른 측면등에 기반을 둘 수 있다

< 통합 테스트 레벨의 통합 접근법>

※표 참고 (P.56)

1) 백본(Backbone) : 가장 중요,리스크가 높은 모듈로 초기통합형성

  • 장점 : 결함 격리 쉬움 / 리스크가 높은 결함을 초기에 발견

  • 단점 : 시간이 오래 걸림

  • 드라이버/스텁 : 필요에 따라 만들어 사용

2) 빅뱅(Big bang) : 모든 테스트 모듈을 동시에 통합

  • 장점 : 단시간 테스트

  • 단점 : 결함 격리 어려움

  • 드라이버/스텁 : 없다. 실제모듈로 테스트

3) 상향식(Bottom up) : 가장 하부모듈부터 통합해가면서

  • 장점 : 결함 격리 쉬움 / 하위모듈을 충분히 테스트

  • 단점 : 수정이 어려운 중요결함을 상부구조에서 발견가능 / 비즈니스 로직반영이 어려움

  • 드라이버/스텁 : 테스트 드라이버가 필요

4) 하향식(Top down) : 가장 상부모듈부터 통합해가면서

  • 장점 : 결함 격리 쉬움 / 설계쌍의 결함을 빨리 발견

  • 단점 : 수정이 어려운 중요결함을 하부에서 발견가능 (ex)디자인결함을 가진 db

  • 드라이버/스텁 : 테스트스텁이 필요

<테스트 베이시스>

  • 소프트웨어와 시스템 설계

  • 아키텍쳐

  • 워크플로우(Workflows)

  • 유즈케이스

<테스트대상>

  • 서브 시스템

  • 데이터베이스 구축

  • 기반환경

  • 인터페이스

  • 시스템 구성과 구성 데이터

  1. 시스템 테스팅 (System Testing)

: 개발 프로젝트 차원(범위)에서 정의된 '전체 시스템 또는 제품의 동작'(시스템 성능)에 대해 테스트 하는 것

  • 테스팅 범위 : 해당 테스트레벨의 마스터/레벨테스트 계획에 명확하게 정의되어 있어야 한다.

  • 단위 및 통합테스트가 완료돼 기능상 문제가 없는 상태에서 수행할 수 있다.

  • 실제 최종 사용환경 또는 이와 유사한 환경에서 수행해야한다. : 환경특성장애(Environment-specific failure)리스크를 최소화하기 위해서

  • 전체 기능상의 결함발견, 비기능적 품질 특성확인을 목적으로 한다

  • 테스트엔지니어는 불완전, 문서형태를 갖추지못한 요구사항을기반으로 테스트하는 경우도 고려해야한다.

  • 시스템 성능(시스템,제품의 동작)과 관련된 고객의 요구사항이 성공적으로 수행되었는지를 확인한다.

  • V모델에서 상위레벨 테스트에 속한다

  • 완료조건 : 오픈돼있는(처리되지않은) 심각한 결함이 없음 / 모든 기능,비기능테스트아이템을 테스트함

  • 테스팅

  • 기능 요구사항 / 비기능 요구사항 / 데이터 품질특성 등을 모두 검증해야한다

[ 기능적]

  • 주된 테스팅 방식 : 명세기반테스팅(블랙박스)

(예) 결정테이블 기법 : 비즈니스 룰에 표현된 결과들의 조합을 테스트하기 위해 사용

[비기능적(구조적)]

  • 구조기반기법 : 메뉴구조나 웹페이지 내비게이션같은 구조적(비기능적)요소에 결함문제가 없는지 평가

  • 기능적 품질특성 외 나머지부분 검증을 수행

(예) 성능테스트, 가용성테스트, 보안성 테스트

  • 수행주체

: 주로 독립적인 테스트 팀이 진행 (하지만 개발팀도 수행가능)

< 테스트 베이시스(개발산출물) >

  • 리스크 분석서(리포트)

  • 요구사항 명세 : 시스템 및 소프트웨어

  • 기능 명세

  • 비지니스 프로세스

  • 유즈 케이스

  • 기타 비지니스 레벨의 시스템 동작 명세

  • OS 및 시스템 리소스와의 상호작용 명세

<테스트대상>

  • 시스템, 사용자메뉴얼, 운영메뉴얼

  • 시스템구성, 구성데이터

  1. 인수 테스팅 (Acceptance Testing)

: 시스템이 인수조건을 만족시키는지, 사용자나 고객이 시스템을 인수할지 결정할 수 있도록

사용자의 필요, 요구, 비지니스 프로세스를 고려해 수행하는 테스팅이다.

  • 요구분석단계에서 테스트케이스를 작성해두면 인수테스팅시 많은 도움이 된다.

  • 테스트 베이시스가 확보되는 개발 초기단계(요구사항정의단계)에서 시작한다

  • 최종 단계의 테스팅이라고 보기 어렵다

(예) 대규모의 시스템 통합 테스트를 개별시스템에 대한 인수테스트 이후에 실행할 수도 있다.

  • V모델에서 상위레벨 테스트에 속한다

< 목적 >

: 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 '확신'을 얻는 것.

  • 결함을 찾는 것은 주된 관심사가 아니다.

  • 사업적 리스크(Business Risk)에 집중해 테스트한다

  • 프로젝트 전(모든) 개발 과정에서 수행할 수 있다.

  • 상용(COTS)소프트웨어 제품은 설치, 통합되면 - 인수테스팅을 수행할 수 있다

  • 프로그램 유지보수성에 대한 인수테스팅은 - 컴포넌트테스트 실행전에 수행할 수 있다

  • 컴포넌트의 사용성에 대한 인수테스팅은 - 컴포넌트테스팅 동안에 수행할 수 있다

  • 새로운 기능상의 개선에 대한 인수 테스팅은 - 시스템 테스팅전에 수행할 수 있다

  • 수행주체

: 시스템을 사용하는 고객이나 사용자가 전담하여 수행하는게 대부분 / 다른관련자도 참여가능

<인수 테스팅의 전형적인 형태>

1) 사용자 인수 테스팅

  • 일반적으로 비즈니스 사용자가 시스템 사용의 적절성을 확인한다

2) 운영상의 인수 테스팅

  • 시스템관리자에 의한 테스트활동이다.

  • 테스트항목

  • 백업/복원테스팅

  • 재난 복구

  • 사용자 관리

  • 유지보수 작업

  • 보안취약성에 대한 정기점검

  • 데이터로드, 마이그레이션 작업

3) 계약 / 규정 인수테스팅

  • 계약 인수테스팅 : 맞춤식개발(Custom-developed) 소프트웨어가 계약상의 인수통과조건을 준수하는지확인하는 테스팅으로, 인수자가 계약에 동의할 때 인수통과된다

  • 규정 인수테스팅 : 정부지침, 법률, 안정규정 등 준수해야 하는 규정에 맞게 개발되었는지 확인하는 테스팅

4) 알파 / 베타(필드) 테스팅

  • 상용소프트웨어개발자는 종종 소프트웨어가 상업적으로 판매되기 전에 목표시장의 기존 고객이나 잠재고객으로 피드백을 받고 싶어한다.

(1) 알파테스팅 = 공장 인수 테스팅(Factory acceptance testing)

  • 개발 조직 내에서 고객에 의해 수행된다

  • 고객사의 사이트로 이동하기 전에 개발완료후 테스팅

(2) 베타(필드)테스팅 = 사이트 인수 테스팅(Site acceptance testing)

  • 실제 환경에서 사용자, 잠재고객에 의해 수행된다

  • 고객사이트로 이동한 후에 테스팅

<테스트 베이시스>

  • 리스크 분석 리포트

  • 사용자 요구사항 : 테스트케이스구성을 위한 베이시스

  • 시스템 요구사항

  • 유즈케이스

  • 비지니스 프로세스

<테스트 대상>

  • 완전히 통합된 시스템의 비즈니스 프로세스

  • 운영 및 유지보수 프로세스

  • 사용자 절차

  • 양식

  • 보고서

  • 구성 데이터

<검수 테스팅>

  • 실무에서는 시스템테스팅 - 인수테스팅사이에 출시여부를 결정하기위한 검수테스팅이 존재하는 경우가 있다

  • 품질평가형태로 이루어진다

<개발과정 테스팅>

  • 소프트웨어의 결함을 찾고 수정하기 위해 가능한 많은 장애의 원인을 발생시킨다

<SW 품질평가 테스팅>

  • 신뢰성, 가용성 같은 시스템의 특성을 평가한다

[3] 테스트 유형 (Test types)

  • 테스팅하는 목적 및 품질특성을 염두에 두고, 소프트웨어 시스템(시스템일부)을 검증하는 일련의 테스트활동을 말한다.

  • 테스트의 구체적인 이유, 대상에 따라 특정테스트 활동 묶음을 소프트웨어 시스템(또는 시스템의일부)을 확인하기 위해 실행할 수 있다.

<테스트유형은 다음의 테스트목적에 중점을 둔다>

  • 소프트웨어가 수행하는 기능에 대한 테스팅

  • 비기능적인 품질 특성 테스팅 : 호환성, 신뢰성, 사용성과 같은

  • 소프트웨어나 시스템의 구조나 아키텍쳐에 대한 테스팅

  • 변경내용에 대한 테스팅 : 확인테스팅 / 리그레션 테스팅

<테스트 용이성 (Testability)>

  • 테스터는 품질속성 중 제품요구사항을 리뷰할 때(테스트 전에/개발(코딩) 전에), 제품에 대한 테스트용이성을 먼저 평가해야 한다.

  1. 기능 테스팅 (Functional Testing)

: 시스템이 수행하는 그 '무엇' = 기능

  • [블랙박스]테스팅

  • 모든 테스트 레벨에서 수행가능

  • 블랙박스 테스팅 : 명세기반기법을 이용해 소프트웨어, 시스템기능에서 테스트조건,테스트케이스를 도출하고 소프트웨어의 외부적인 행동을 고려한다.

  • 프로세스 흐름 모델, 상태 전이 모델, 평문 언어 명세 등을 이용가능

  • 실행되어야하는 (서브)시스템,컴포넌트의 기능은 개발산출물(요구사항명세, 유즈케이스, 기능적명세)에 기술되어 있거나, 문서화되지 않을 수 있다.

  • 기능테스팅은 문서화되어있거나 테스터가 알고 있는 기능과 특징, 그것들과 특별한 시스템과의 상호운용성을 고려하여 수행한다.

(예) 컴포넌트 테스트 레벨에서의 기능테스팅 - 컴포넌트 명세를 기반으로함

<품질특성 : 기능성>

  • 품질부특성 : 적합성,정확성, 준수성, 상호운용성, 보안성 [적.정.보.상.준]

1) 보안성 테스팅 (Security Testing)

: 악의적인 코드(바이러스등)와 같은 외부로부터의 위협을 감지해내는 것과 관련이 있는 기능(방화벽)을 확인하는 테스팅

  • 보안정책확인

  • 시스템으로 침투하는 보호되지 않는 진입점(트랩도어) 파악

  • 가용성, 무결성, 기밀성, 부인방지 등의 보안관련 평가

2) 상호운용성 테스팅(Interoperability)

: 하나 또는 여러개의 명시된 컴포넌트나 시스템이 서로 상호작용하는 소프트웨어 제품의 능력을 평가하는 테스팅

  1. 비기능 테스팅 (Non-Functional Testing) = 소프트웨어 제품 특성 테스팅(Testing of software product characteristics)

: 시스템이 '어떻게' 동작하는가를 테스팅

  • [블랙박스]테스팅

  • 성능, 부하, 스트레스, 사용성, 유지보수성, 신뢰성, 이동성 테스팅을 포함하는 개념이다.

  • 모든 테스트 레벨에서 수행가능

  • (성능테스팅에서의 응답시간과 같이) 다양한 척도,비율(Scale)로 정량화가능한 소프트웨어, 시스템의 특성을 측정하는 테스트이다.

  • 외부로 표출되는 소프트웨어의 습성을 확인할 목적으로 실행된다.

  • 블랙박스 테스트 설계기법을 활용한다

<부하 테스팅(Load Testing)>

실제 환경을 가정하고 일반적으로 요구사항에서 제시하는 부하의 최대치를 발생시켜 시스템이 안정적으로 작동하는 지를 확인하는 테스트.

<비기능성>

  • 품질특성 : 신뢰성, 사용성, 효율성, 유지보수성, 이식성 [유.효.이.신.사]

  1. 구조적 테스팅 (Structural Testing)

: 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보장성, 충분함(Thoroughness)을 측정하는 테스팅

  • [화이트박스]테스팅

  • 제어 흐름 모델, 메뉴구조 모델 등을 이용가능

  • 구조기반(화이트 박스) 테스팅 : 코드커버리지 높임

  • 모든 테스트 레벨에서 수행가능 : 시스템, 시스템 통합, 인수 테스팅

(예) 비즈니스 모델이나 메뉴구조도 활용하여 구조적 테스트 설계를 통해 수행이 가능하다.

  • 명세기반기법을 적용한 다음에 사용할 떄 가장 좋은 결과를 보여준다.

  • 컴포넌트 테스팅/컴포넌트 통합 테스팅 레벨에서 프로그램 코드 커버리지를 높이는 용도로 사용한다.

((자동화)도구사용하여 선언,구문(Statements) 혹은 결정문(Decisions)과 같은 커버리지 요소를 측정)

  • 코드레벨뿐만아니라, 호출 체계/구조(Hierarchy)와 같은 시스템의 아키텍처에 기반을 두고 수행가능하다.

<커버리지>

: 시스템, 소프트웨어 구조가 테스트수트에 의해 테스트된 정도

  • 만일 커버리지가 100%가 아니라면, 누락된 아이템을 테스트하기위해 더많은 테스트를 설계하여 커버리지를 높일 수 있다

  1. 확인 테스팅 (Confirmation Testing) = 재 테스팅 (Re Testing)

: 결함이 발견되고 수정된 후에 소프트웨어는 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트하는 것

  • 디버깅(결함의 원인을 찾거나 수정하는 활동)은 개발활동이며, 테스팅활동이 아니다.

  1. 리그레션 테스팅 (Regression Testing) = 회귀 테스팅

: 결합수정 이후 변경의 결과로 새롭게 만들어지거나, 이전 결함으로 인해 발견되지 않았던 또다른 결함을 발견하기 위해

  • 이미 테스트된 프로그램의 테스팅을 반복하는 것. 퇴행(Regression)여부를 확인하는 테스팅

  • 모든 테스트 레벨에서 수행가능

  • 기능, 비기능, 구조적 테스팅에 적용할 수 있다

  • 반복수행되므로 '자동화'대상으로 고려가능 : 리그레션 테스트 수트는 여러번 반복수행되며 대개는 서서히 변경되므로

  • 테스트 대상 : 변경된 소프트웨어뿐만아니라 환경이 변경되어도 수행되어야 한다.

  • 결함은 테스트중인 소프트웨어에 존재할 수 있고, 관련이 없는 다른 소프트웨어 컴포넌트에도 있을 수 있다.

  • 테스트 범위/정도 : 리스크에 바탕을 둔다

  • 위험성이 높으면 리그레션 테스팅을 넓은범위로, 보다 상세하고 철저하게 수행 (Intensive and higher-depth)

  • 테스트가 확인테스팅으로 쓰이거나, 리그레션 테스팅을 보조한다면 그 테스트는 반복적인 성향을 갖는다.

  • 결함 마스킹은 리그레션 테스팅으로 찾을 수 있다.

<결함 마스킹(Fault Masking)>

: 어떤 이유로 결함이 가려져서 해당 결함을 발견할 수 없는 상태

​- 결함이 있는 프로그램 부분이 실행되지 않았거나, 다른 결함이나 장애로 해당 결함이 드러나지 않는 등 여러 이유로 결함이 존재하지만 발견되지 않을 수 있다.

[4] 유지보수 테스팅 (Maintenance Testing)

: 소프트웨어 또는 시스템이 변경, 단종, 마이그레이션될 때, 이미 운영되고 있는 시스템에서 수행하는 테스팅

  • 개발과정에서 변경작업이 일어나는 경우, 새로운 결함이 유입됐는지 확인한다.

  • 모든 테스트 유형 / 모든 테스트 레벨에서 수행가능​

  • 명세(Specifications)가 매우 오래되었거나 없다면 명세서를 근간으로 수행하기는 어렵다

  • 사전에 출시계획을 세우는 것이 유지보수 테스팅의 성공여부에 중대한 영향을 미친다.

  • 테스트 대상 : 변경된 부분에 대한 테스팅 이외에도 변경되지 않은 시스템 요소에 대한 방대한 리그레션 테스팅도 고려해야한다​

  • 테스트 범위/정도 : 변경사항의 리스크 및 크기, 기존시스템의 크기

  • 영향도 분석(Impact analysis) : 변경으로 인해 기존시스템이 어떻게 영향을 받는지 결정하는 것

  • 얼마나 많은 리그레션 테스팅을 수행할지 결정하는 데 이용한다

1) 변경(Modification)

  • 출시(릴리즈)기반으로 계획된 개선활동에 의한 변경, 요구사항 변경에 의한 수정과 긴급변경, 환경의 변경 등

  • 계획된 OS 또는 DB 업그레이드 / 계획된 상용소프트웨어 업그레이드 / OS의 새로 드러난 취약점 패치

2) 마이그레이션 = 변환

  • 한 플랫폼에서 다른 플랫폼으로 옮기는 작업

  • 변경되는 소프트웨어에 대한 운영테스트 + 새로운 환경에서의 운영테스트 필요

  • 운영되고 있는 시스템에서 다른 응용프로그램의 데이터가 마이그레이션될때도 필요

3) 단종

  • 데이터를 마이그레이션하는 테스팅 포함

  • 데이터 저장관련 테스팅 : 데이터의 보유기간이 필요할경우

  • 유지보수테스팅 vs 유지보수성테스팅 비교하기! - 다른개념이다

< (비교) 유지보수성 테스팅(Maintainability Testing)>

: 소프트웨어 및 시스템이 변경을 고려해 얼마나 잘 개발했는지 밝히는 테스팅

  • 유지보수성이 낮은 시스템은 작은 변경에도 취약하다 ( 코드의 많은 부분을 수정하는 등 재작업,리소스 투입이 많음)
    [출처] Part2. 소프트웨어 수명주기와 테스팅|작성자 Eugene
Posted by SB패밀리

댓글을 달아 주세요

소프트웨어 개발주기

확인(Verification) - 제품을 올바르게 개발하고 있는가? Need

소프트웨어 개발 주기에서 주어진 단계에서의 생산품이 이전 단계에서 수립된 요구들을 수행하는가를 결정하는 과정.

프로그램 정확도의 형식 증명.

항목들, 프로세스들, 서비스들, 또는 문서들이 명시된 요구들을 따르는지 재검토하고 조사하며 시험, 검사, 감사 및 문서화하는 행위.

검증에는 주기 검증과 형식 검증의 두 가지 형태가 있다. 주기 검증은 개발 주기의 특정 단계에서 제작된 생산 제품이 그 이전 단계에서 설정한 규격들을 어느 정도 충족시키는지를 결정하는 과정이다. 형식 검증은 원시 부호가 규격에 맞게 작성되었는지를 수학적으로 엄격하게 증명하는 것이다

보증,검증(Validation) - 올바른 제품을 개발하고 있는가? Procedure

소프트웨어에 대한 요구 조건에 응하고 있는 것을 확인하기 위해 소프트웨어 개발공정의 마지막에 소프트웨어를 평가하는 공정.

소프트웨어개발과정의 최종 단계로써, 소프트웨어가 요구된 바와 합치되는지를 평가하는 일.

소프트웨어 타당성 검사(Software Validation)

 

 

 

Posted by SB패밀리

댓글을 달아 주세요

1. 자바스크립트에서  ==., ===

 

==는 loose equality할때 사용한다. 또한 ==은 형변환을 수행한다.

형변환 후에 오직 두개의 값 비교만 수행한다는 의미이다.

(Type coercion means that two values are compared only after attempting to convert them into a common type.)

 

=== strict equality 할때 사용한다.

타입(type)과 값(value) 모두 비교했을때 같아야 한다.

 

 

Falsy Value Comparison(거짓값 비교)

 

거짓값은 false, 0, "", null, undefined, NaN으로 총 6가지이다.

1. false — boolean false

2. 0 — number zero

3. “” — empty string

4. null

5. undefined

6. NaN — Not A Number

Posted by SB패밀리

댓글을 달아 주세요

전세계 mybatis와 hibernate 점유율

동아시아를 제외하고 대부분 나라에서는 Hibernate를 압도적으로 많이 사용하고 있으며, Hibernate를 배우게 되면 Mybatis보다 코드가 더 간결하며, 더 객체 지향적이고 생산성이 매우 높다는 것을 장점으로 생각하게 됩니다.

Posted by SB패밀리

댓글을 달아 주세요

Having problems with a ticket being submitted multiple times?

This article will show you how to disable the Submit button after it has been click and change the text label to Submitting, please wait...
 

  1. Make a backup copy of your existing index.php file.
     

  2. Open file index.php in a plain text editor, such as Notepad.
     

  3. Inside index.php find the first two occurrences of this code:

    <input type="submit"
     

  4. After this code add:

    onclick="this.disabled=true;this.value='Sending, please wait...';this.form.submit();"

    Remember, do this twice - the first two times you find code in step 3.

    The final code should look like this:

    <input type="submit" onclick="this.disabled=true;this.value='Sending, please wait...';this.form.submit();" 
     

  5. Save changes, upload the index.php file to your server and test it.
     

That's it! Now, when your visitors click the "Submit" button when submitting a ticket, the button will be be disabled with the Sending, please wait message until the post is complete.

Posted by SB패밀리

댓글을 달아 주세요

검증(Validation)

올바른 제품을 만들고 있는가? WHAT

QIP(Quality Inspection Plan)

품질시험계획서(제품명세서)

기자재 제작업체가 기기제작에 착수하기 전에 검사품명, 제작공정별 검사  항목,     적용규격, 검사예정일, 검사장소 등을 명시하여 검사를 효과적으로 수행하기 위하여 제작업체가 작성하여 발주자가의 승인을 받으며 시험 및 검사가 공장에서 이루어지는 공장 QIP와 발전소 또는 건설현장에서 이루어지는현장 QIP로 구분됩니다.

   - 검사방법은 “R, W, H” 가 있으며, 자세하게 설명하면 다음과 같습니다.

   R(Review Point) : 공정 중 시험환경, 절차 및 판정기준 등의 시험요건과 규격 및 성능이 계약규격에 만족되는지를 확인하기 위하여 점검하는 행위입니다.

   W(Witness Point) : 공정 중 검사자의 입회를 받도록 결정한 시점으로,입회검사가 불가능할 경우 다음 공정으로 진행시킬 수 있으나, 반드시 입회불가 통보를 받은 후에 진행하여야 합니다.

   H(Hold Point) : 공정 중 검사자에 의한 검사 또는 입회를 필요로 하는 중요단계로서 검사에 합격하지 않고는 다음 공정으로 진행하지 못하도록 결정한 검사점을 말합니다.

 

확인(Verification)

올바르게 제품을 만들고 있는가?  HOW

ITP(Inspection Test Plan)

검사및시험계획서(시험절차서)

공정 중 실시하는 검사항목에 대한 적용범위, 적용기준 및 표준, 시험 및 검사 항목, 항목별 시험검사 절차, 판정기준 등 시험 및 검사수행에 필요한 내용을 상세히 기술한 서류를 말합니다

 

 

품질관련 필수용어 필수용어 참조

Posted by SB패밀리

댓글을 달아 주세요

클라우드 선두업체 아마존, 블록체인 개발서비스 정식 출시 

https://news.v.daum.net/v/20190502173046670
#AWS #AMB #아마존 #AMAZON

 

클라우드 선두업체 아마존, 블록체인 개발서비스 정식 출시

(서울=뉴스1) 이수호 기자 = 전세계 1위 클라우드업체 아마존(AWS)이 기업용 블록체인 개발서비스 '아마존 매니지드 블록체인'을 정식 출시했다. 2일 아마존은 자사 홈페이지를 통해 아마존 매니지드 블록체인 서비스의 정식 버전을 공개하고 고객사 모집(미국 동부 대상)에 나선다고 밝혔다. 다만 한국 서비스 시기는 공개하지 않았다. 아마존 매니지드 블

news.v.daum.net

 

Posted by SB패밀리

댓글을 달아 주세요

2019년 4월 인터넷에서 가장 인기 있는 프로그래밍 언어 순위는?

Top programming language ?

인터넷에서 인기있는 tag나 검색어를 바탕으로 한 것이라서 100% 신뢰라기 보다는 참고용.

Assembly language, Object-C, MATLAB의 약진이 돋보인다. Groovy 가 가장 많은 상승을...

reference : TIOBE index

Posted by SB패밀리

댓글을 달아 주세요

Conditional operators

You have already seen the conditional operator is, however CoffeeScript offers a range of operators to match those present in JavaScript.

COFFEESCRIPT vs JAVASCRIPT

COFFEESCRIPT JAVASCRIPT
is ===
isnt !==
not !
and &&
or ||
true, yes, off true
false, no, off false

Now you can successfully use if, else and unless with conditional operators to create a basic program! In the next part we will explore functions and their unique syntax.

Posted by SB패밀리

댓글을 달아 주세요

git 계정 변경

IT - 개발 2019.04.01 09:37

git 계정 변경

    1. 방법 $ git config --global user.name "이름"
    2. 방법 $ git config --global user.email "이메일"

git 로컬 계정 변경

  1. 방법 $ git config --local user.name "이름"
  2. 방법 $ git config --local user.email "이메일"

'IT - 개발' 카테고리의 다른 글

2019년 4월 개발언어 순위?  (0) 2019.05.01
COFFEESCRIPT vs JAVASCRIPT - 조건식 오퍼레이터  (0) 2019.04.10
git 계정 변경  (0) 2019.04.01
commit messages in Git, Redmine Sync  (0) 2019.04.01
Adobe CS3 문제  (0) 2019.02.10
AWS와 함께 하는 클라우드 컴퓨팅  (0) 2019.02.02
Posted by SB패밀리

댓글을 달아 주세요

 

 

Referencing issues in commit messages

When fetched from the repositories, commit messages are scanned for referenced or fixed issue IDs.
These options lets you define keywords that can be used in commit message to reference or fix issues automatically, and the status to apply to fixed issues.

Default keywords are:

  • for referencing issues: refs, references, IssueID
  • for fixing issues: fixes, closes

There's no default status defined for fixed issue. You'll have to specify it if you want to enable auto closure of issues.
If you want to reference issues without using keywords, enter a single star: * in the Referencing keywords (Administration/Repository) setting. In this case, any issue ID found in the message will be linked to the changeset.

Example of a working commit message using default keywords:

This commit refs #1, #2 and fixes #3

This message would reference issues 1 and 2 and automatically fix issue 3.
After a keyword issue IDs can be separated with a space, a comma or &.

The keywords are caseinsensitive and at least one blankspace or colon is needed between the keyword and the first hash to produce 
a match. More examples that will produce the same result as the example above:

This commit refs:#1, #2 and fixes #3 This commit Refs #1, #2 and fixes #3 This commit REFS: #1, #2 and fixes #3

Enable time logging

Allows time logging directly from commit messages. This only makes sense if you activated the "Time tracking" module in said project. In this case, you can add special words in your commit message to indicate the time you spent on an issue.

The basic syntax for doing that is : @<time>, where time consists in a number of hours or minutes.

Here's a list of many valid commit messages that would work if you want to say you spent N hours on issue 1234:

Implement feature #1234 @2 Implement feature #1234 @2h Implement feature #1234 @2hours Implement feature #1234 @15m Implement feature #1234 @15min Implement feature #1234 @3h15 Implement feature #1234 @3h15m Implement feature #1234 @3:15 Implement feature #1234 @3.25 Implement feature #1234 @3.25h Implement feature #1234 @3,25 Implement feature #1234 @3,25h

Activity for logged time

This is the type of activity that should be used when detecting there's a log time in a commit message (see above).

 

 

 

http://www.redmine.org/projects/redmine/wiki/RedmineSettings#Referencing-issues-in-commit-messages

Posted by SB패밀리

댓글을 달아 주세요

Adobe CS3 문제

IT - 개발 2019.02.10 09:56

Adobe CS3 불청객



'IT - 개발' 카테고리의 다른 글

git 계정 변경  (0) 2019.04.01
commit messages in Git, Redmine Sync  (0) 2019.04.01
Adobe CS3 문제  (0) 2019.02.10
AWS와 함께 하는 클라우드 컴퓨팅  (0) 2019.02.02
AWS가 제안하는 서버리스 아키텍처  (0) 2019.01.24
Rad Studio 라이센스 종류  (0) 2019.01.10
Posted by SB패밀리

댓글을 달아 주세요

Amazon


AWS와 함께 하는 클라우드 컴퓨팅 - 홍민우 AWS 매니저



https://www.slideshare.net/awskorea/aws-aws-90606807



'IT - 개발' 카테고리의 다른 글

commit messages in Git, Redmine Sync  (0) 2019.04.01
Adobe CS3 문제  (0) 2019.02.10
AWS와 함께 하는 클라우드 컴퓨팅  (0) 2019.02.02
AWS가 제안하는 서버리스 아키텍처  (0) 2019.01.24
Rad Studio 라이센스 종류  (0) 2019.01.10
RAD Studio 버전  (0) 2019.01.10
Posted by SB패밀리

댓글을 달아 주세요

AWS가 제안하는 서버리스 아키텍처





출처: 판교 개발자 데이 – Aws가 제안하는 서버리스 아키텍처 – 김필중

Posted by SB패밀리

댓글을 달아 주세요

RAD Studio에는 여러 라이센스 옵션이 있습니다.

  • 지명 사용자 라이센스 : 특정 개인에게 사용 권한을 부여 라이센스. 소프트웨어는 여러 대의 컴퓨터에 설치하여 사용할 수 있지만 동시에 사용할 수는 1 만입니다. 지명 사용자 라이센스를 여러 사용자가 공유하거나 양도 할 수 없습니다. 지명 사용자 라이센스를 사용하려면, EDN 계정 (E 메일 주소가 필요)를 작성해야합니다.
  • 네트워크 지명 (Network Named) 또는 네트워크 동시 (Network Concurrent) 라이센스 : 라이센스 서버 (Embarcadero License Server)에 의해 관리되는 라이센스. 네트워크 지명 사용자 라이센스는 조직의 사용자에게 할당하여 사용할 수 있습니다. 네트워크 동시 라이센스는 구입 한 라이센스 수 분의 조직의 불특정 다수가 동시에 사용할 수있는 라이센스입니다. 어떤 라이센스도 조직 내에 구축 된 라이센스 서버에 연결하는 네트워크 환경이 필요합니다.
  • Flexera FlexNet에 의해 관리되는 네트워크 라이센스 (일반 판매는하고 있지 않으므로 자세한 내용은 문의 바랍니다)
  • 아카데믹 라이센스 - 학생 개인의 학습을위한, 아카데믹 볼륨 라이선스 - 학교 교실 수업 교육을위한




RAD Studio 10.2 Tokyo는 다음 이전 버전의 라이센스를 사용할 수 있습니다.

  • Delphi 10.1 Berlin, Delphi 10 Seattle, Delphi XE8, Delphi XE7, Delphi XE6, Delphi XE5, Delphi XE4, Delphi XE3, Delphi XE2, Delphi XE, Delphi 2010 Delphi 2009, Delphi 2007, Delphi 7
  • C ++ Builder 10.1 Berlin, C ++ Builder 10 Seattle, C ++ Builder XE8, C ++ Builder XE7, C ++ Builder XE6, C ++ Builder XE5, C ++ Builder XE4, C ++ Builder XE3, C ++ Builder XE2, C ++ Builder XE, C ++ Builder 2010, C ++ Builder 2009, C ++ Builder 2007, C ++ Builder 6
  • HTML5 Builder XE3, RadPHP XE2, RadPHP XE

Posted by SB패밀리

댓글을 달아 주세요

RAD Studio 버전

IT - 개발 2019.01.10 14:44

RAD Studio에는 Professional, Enterprise Architect의 3 가지 버전이 있습니다. 

각 에디션의 차이, 기능 자세한 내용은 RAD Studio 제품 버전 및기능 목록 을 참조하십시오.



Posted by SB패밀리

댓글을 달아 주세요

2018년 1월, 12월 프로그래밍 언어 인기도 순위


네덜란드 티오베(TIOBE) 회사가 매달 검색엔진 통계를 이용하여 발표하는 개발언어 인기도 순위


2018년12월



2018년 1월


1년 전 / 1개월 전 정보이지만 대략 트렌드 파악이 간다.

2019년 1월은 어떨지 조만간 확인하도록 하고

C#은 6위, DELPHI는 11위 정도를 유지하고 있구나.


https://www.tiobe.com/tiobe-index/

Posted by SB패밀리

댓글을 달아 주세요

[JAVA] JetBrains IntelliJ IDEA 학생 무료 인증


인텔리J IDEA를 설치해서 공부하려고 하시는 분

학생 계정이 있다면 다음 학생무료인증 가이드를 참고하세요.

전 학생 계정 인증 완료.


학생무료인증 가이드 클릭

Posted by SB패밀리

댓글을 달아 주세요

문자 인식

IT - 개발 2018.12.18 22:55

문자 인식

  1. 개요
    • 문자의 개념
    • 필기 도구와 사람의 필기 운동의 물리적인 작용에 의해 구체적인 형태로 기록되어, 그것을 읽는 사람에게 정보를 전하는 것.

    • 문자 인식
    • 문자를 인식하여 하나의 개념에 대응시키는 작용

    • 문자인식의 대상

    • 문자 인식
      온라인 문자 인식오프라인 문자인식
      제약된 필기자유로운 필기인쇄체필기체
        특수활자체단일
      활자체
      다중
      활자체
      제약된 필기체자유로운 필기체
        바코드자기 잉크문자 

    • 문자 인식의 과정

    • 입력
      패턴
      -->전처리-->특징
      추출
      -->분류-->후처리-->인식결과 
      출력

  2. 문자 인식의 어려움
    • 질적인 문제
    • 인식 대상이 단일 활자체의 인쇄체 문자에서 다양한 활자체의 인쇄체 문자, 제약이 가해진 필기체 문자, 더 나아가 무제약 필기체 문자로 바뀜에 따라 증가.

    • 양적인 문제
    • 인식 대상이 숫자(10종)에서 영문자(52종), 한글(11,172종), 더 나아가 한자(약 50,000여 종)로 바뀜에 따라 증가.

  3. 온라인 문자 인식과 오프라인 문자 인식
    • 온라인 문자 인식
      • 사용자가 필기하는 동안에 인식기가 필기 문자를 인식하는 것.
      • 장점 : 획수, 획순, 각 획에 대한 필기 방향과 각 획 내에서의 필기 속도 등 필기의 시간적, 공간적인 동적 정보를 얻을 수 있다. (인식률이 높다.)
      • 단점 : 온라인 데이터(문자)를 사용자가 필기하는 순간에만 얻을 수 있고, 문자 입력을 위해 특수한 장치인 전자 펜(또는 스타일러스)과 태블릿(또는 디지타이저)을 사용해야 한다.

    • 오프라인 문자 인식
      • 이미 작성된 인쇄체 문자 혹은 필기체 문자를 인식하는 것.
      • 장점 : 글을 쓴 이후에는 언제라도 데이터를 얻을 수 있다.
      • 단점 : 동적 정보를 얻을 수 없다. (인식률이 낮다.)
  4. 문자 인식의 응용 분야
  5. 우편물 자동 분류를 위한 우편 번호 인식, 산업 현장에서의 제품 검사나 분류, 문서 인식, 도면 인식, 팩시밀리를 통해 전달받은 영상에서의 문자 인식, 워드 프로세서 OCR, 금융 기간에서의 전표 또는 수표의 자동 입력 등 여러 분야에 걸쳐 실용화되어 실생활에 효과적으로 사용.



자료출처 : 배경환


Posted by SB패밀리

댓글을 달아 주세요

API, 라이브러리, SDK, 프레임워크, 플랫폼


 용 어

 개 념

API

 Application Program Interface로 인터페이스를 의미하며, 서로 다른 목적으로 개발된 software의 특정 기능을 호출하기 위해서 software나 library 기능을 사용할 수 있도록 기능 호출을 하도록 하는 것이다.

대표적인 예로 MS runtime API, java API, google API, facebook API 등이 있다.

SDK

 Android SDK, iOS SDK, Windows SDK, 특정 제품의 SDK 등의 서비스를 제공하기 위한 것이며, 모두 대상이 되는 운영체제나 서비스 기반이 있다.

Library 

필요한 특정 모듈을 호출하여 사용하는 개념이다. 

대표적인 예로 Rad Studio 컨포넌트 라이브러리 등이 있다. 

Framework 

 프레임워크는 소프트웨어를 개발할 때 사용할 수 있는 인터페이스 기반 패키지로 말할 수 있다. 인터페이스란 개발의 basement가 되는 구조와 코드/알고리즘/암호화/데이터베이스 연동 방식의 집합체라고 할 수 있다.

대표적인 프레임워크는 마이크로소프트 사의 MFC, 닷넷(.NET) 프레임워크와 자바의 스프링, 전자정부, 앵귤라 프레임워크, TMSSoftware TMS Package 등이 있다.

 Platform

 특정 장치나 시스템, 서비스 등에서 이를 구성하는 기반이 되는 하드웨어나 소프트웨어 환경, 더 크게는 틀이나 골결을 지칭한다. 또, 서드파티에 의해 개발된 것이 사용자들에 의해 사용/유통될 수 있는 환경/기술 등을 의미한다.

대표적인 플랫폼으로는 Windows, MacOS, Linux와 같은 운영체제, 모바일 안드로이드나 iOS, 엠바카데로 사의 파이어몽키(FireMonkey), 인터넷 포털 서비스의 소셜네트워크 서비스 또는 카카오톡, 라인 등이 있다.

 Docker

 


컴포넌트란 인터페이스를 기본적으로 구현하고 응용 프로그램간의 개체 공유를 가능하게 하는 독립적인 기능을 수행하는 소프트웨어 모듈이다.

컴포넌트(Component, VCL)는 CBD(Component based Development) 개발방법론. 

기업들은 쇼핑바구니, 사용자 인증, 검색엔진, 카탈로그 등 상업적으로 이용 가능한 컴포넌트를 결합하여 그들의 전자상거래 응용프로그램을 개발하는 컴포넌트 기반 개발을 사용한다.



Posted by SB패밀리

댓글을 달아 주세요