달력

11

« 2019/11 »

  •  
  •  
  •  
  •  
  •  
  • 1
  • 2
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30



 

스텁(Stub)

·         실제 코드나 아직 준비되지 못한 코드를 임의로 동작하도록 하는 메커니즘

·         시스템이 너무 복잡하여 수정이 불가할 사용

·         통합 테스트와 같이 포괄적인 테스트를 수행 사용

·         별도로 외부 연동 시스템을 준비할 필요 없이 테스트 수행

 

 

 

 

 

클라이언트 기능와 서버 구성

기능이 가지로 구성되고, 개의 서버와 연동되는 프로그램입니다.

 

현재 상태가 모든 기능과 서버가 준비되어야만 지금 기능과 연동되는지 테스트가 가능한 경우인데 테스트나 데모가 필요

현재 상태가 기능 3 미완성이고, 서버와의 연결이 불가능한 환경인 경우인데 테스트나 데모가 필요

 

 


 

 

 

 

 

 

가상으로 연동 부분을 만들어 테스트

미구현 부분을 미구현된 부분과 연동이 필요한 부분을 가상으로 구성하여 테스트합니다.

 

스텁 1

미구현 기능 부분 대체하여 테스트

스텁 2

스텁 3

실제 서버를 연동하지 않고 대체하여 테스트

 


 




Posted by codedragon codedragon

댓글을 달아 주세요


 

 

테스트 아이템 식별 방법

·         테스트 대상 시스템 관련 비즈니스 위험을 식별합니다.

·         테스트 수행 중에 평가되어야 하는 위험을 기반으로 테스트 요소를 식별합니다.

·         심각도 위험도를 고려하여 테스트 요소를 분류합니다.

·         식별된 문서와 상세 항목들에 대해서 자세히 검토한 실제 테스트 케이스를 작성할 있는 수준의 아이템들을 식별해야 합니다.

·         먼저 선정된 요구사항에 대해서 우선순위를 정하는 것이 필요합니다. (어떠한 기능들이 있는가?, 어떻게 테스트될 것이냐?)

 

 

 

 

구분

설명

특정 모듈과 관련된 사항이 모듈별로 식별이 되지 않을 경우

·         비슷한 항목의 테스트 케이스들이 서로 떨어져서 작성되는 경우 발생

우선순위나 항목별로 정리를 하지 않을 경우

·         실제 테스트 아이템들을 정리할 매우 까다로울 있기 때문에 분류하여 수행

·         비슷한 항목끼리 모음(되도록 기능/동작/조건을 구분하는 것이 좋음)

·         모아진 항목에서 기본 동작과 조건이 추가된 복잡 동작을 적절히 나눔

 

 

 

 

[테스트아이템 식별 예시]

디지털 카메라 사양서 기준

L1

L2

L3

Test Item ID

Desc

Precondition

Action

Expected Result

Constraints

Note

1.1

1.1.1

카메라

1.1.1.

1

카메라

프리뷰

CAMER

A_1.1_0

001

·         카메라 메뉴에 진입하면 프리뷰

·         화면을 표시해야

·         카메라 전원 On 상태

·         카메라 프리뷰 메뉴로 진입

·         카메라 액정에 프리뷰 화면 표시

·         카메라 배터리 상태

·         카메라 온도 조건

 

1.

1

1.1.2

갤러

1.1.2.

1

갤러리

리스트

GALLER

Y_1.2_

0001

·         촬영된 사진 동영상을 표시해야

·         카메라 전원 On 상태

·         카메라에서 사진 동영상 촬영

·         갤러리 메뉴로 진입

·         촬영된 사진 동영상이 표시

·         카메라 메모리 상태

·         카메라로 촬영된 사진 동영상의 개수 조건

·         카메라 메모리가 없는 상태에서의 테스트 환경 구축

1.

1

1.1.3

설정

1.1.3.

1

설정

메뉴

리스트

SETTIN

G_1.3_

0001

·         설정 메뉴에 진입하면 카메라 설정 메뉴를 표시함

·         카메라 전원 On 상태

·         카메라 설정 메뉴로 진입

·         카메라 설정 메뉴 화면 표시

·         카메라 메모리 카드 삽입 상태

 

 

 










Posted by codedragon codedragon

댓글을 달아 주세요


 

 

의료장비 제어버그

1985 종양 제거를 위한 방사선 치료기인 Therac 25라는 제품의 제어 코드에 있었던 버그 때문에 6건의 사고가 발생해서 3명이 죽고 다른 3명은 심각한 방사능 후유장애에 시달려야 했습니다. 2017년에도 장비결함으로 방사능에 누출되는 사고가 발생했습니다.


http://bit.ly/2XRWIRI

 

X-ray 모드는 강한 방사선을 사용하기 때문에 이를 균일하고 안전하게 사용할 있도록 턴테이블이라고 하는 장치를 환자와 방사선 발사기 사이에 위치시켜 안전하도록 제어해주어야 합니다. 텐테이블은 Electron 모드로 동작할 때는 필요하지 않아 필요하지 않으므로 X-Ray모드일 때는 턴테이블을 움직여 주어야 하는 제어 필요하며 여기에 해당하는 컴퓨터 소프트웨어 버그(Killer bug) 존재했습니다.

 


http://bit.ly/2VH8qRC

 

https://en.wikipedia.org/wiki/Therac-25

 

 

 

 

참고자료 다운로드

10.Sync.pdf

 

or

http://www.ittc.ku.edu/~heechul/courses/eecs678/F16/slides/10.Sync.pdf

 



Posted by codedragon codedragon

댓글을 달아 주세요


 

 

 

릴리즈 계획 프랙티스 적용

아래의 상황들에서 릴리즈 계획 프랙티스를 적용할 있습니다.

·         전체 업무 규모 산정 어려울

·         조직이 해야 하는 할일의 목록과 범위 명확하지 않을

·         계획 수립시 각자의 의견이 대립

·         이해관계가 얽혀 있어 각자 계획을 수립하기 어려운 경우

·         계획 수립시 각자의 의견이 골고루 반영되도록 하고 싶을

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

 

스프린트(Sprint)

·         반복적인 개발 주기

·         계획한 일을 수행하는 한정된 기간(Time box) 의미합니다.

·         개발팀은 스프린트(Sprint) 동안 프로젝트를 수행합니다.

·         보통 달력기준 1~4 단위의 반복 개발기간 가지며 이터레이션(Iteration)이라고도 합니다.

·         회사에서 정하는 이터레이션이 개발 주기가 됩니다. 계획 회의 부터 제품 리뷰가 진행 되는 날짜 까지의 기간이 1스프린트 입니다.

 



Posted by codedragon codedragon

댓글을 달아 주세요


 

 

테스트 전략 수립 및 선정 시 고려할 사항

 

구분

고려사항

리스크(Risk)

·         프로젝트 성공에 매우 중요합니다.

·         새로운 기능이 추가된 소프트웨어인 경우 사전에 리스크 파악하여 분석적(Analytical) 전략을 수립하는 것이 유리합니다.

·         일정상 기능 구현 완료가 늦어질 것으로 예상되는 기능 또는

·         성능 이슈가 발생할 것으로 예상되는 기능인 경우 사전에 리스크 파악하여  즉흥적(Dynamic) 전략을 선택하는 것이 유리합니다.

능력(Skills)

·         테스터의 능력 숙련도가 중요한 요소입니다.

·         숙련도가 높지 않은 조직의 경우 표준 테스트 전략을 따라 테스트를 진행하는 것이 유리합니다.

목적(Objective)

·         요구사항 비지니스적인 목표가 전략 수립에 영향을 미치는 경우가 많음

·         고객이 안정적인 소프트웨어를 요구하는 경우 회귀(Regression) 테스트를 많이 진행하는 전략을 수립하는 것이 유리합니다.

제품(Product)

·         제품에 따라 요구사항 명세서가 상세하게 작성되어 있는 경우 요구사항 명세서 기반으로 테스트를 진행하는 것이 유리합니다.

테스트의 효율 극대화

·         현업에서 개발 전략에 많은 시간을 할애하지 않는 경우가 많습니다. 전략에 충분한 시간을 투입해야 합니다.

기타

·         어떤 테스트 기법을 사용해야 하는가?

·         얼마나 많은 시간 동안 테스트해야 하는가?

·         우리가 활용할 있는 자원은 얼마나 있는가?

·         해당 프로젝트의 위험 요소나 중요도는 얼마인가?

·         제품 품질을 기대 수준은 어느 정도인가?

·         자동화 테스트 필요한가? 그렇다면 어떠한 툴을 사용?

·         전문성 확보를 위해 아웃소싱이 필요한가?

 

 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

다중 조건 커버리지(Multiple Condition Coverage)

·         복수 조건 커버리지

·         연산식(Boolean Expression) 간의 마스크(Mask) 현상을 해결하기 위하여 조건문 내에 존재하는 논리 연산자를 고려한 모든 조합을 실행하는 것을 기준으로 하는 커버리지입니다.

·         조건문 간의 조합은 고려되지 않으나, 조건(Condition) 모든 가능한 조합이 나오도록 합니다.

 

 

 

 

마스크(Mask) 현상

어떤 조건이 다른 조건들의 판단 결과에 상관없이 미리 판단하는 것입니다.

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

 

소프트웨어 테스트 툴의 필요성

·         툴을 사용하지 않고 소프트웨어 개발을 하는 것이 불가능한 것은 아닙니다. 하지만 사람이 모두 관리할 경우 이슈가 100개정도 넘어가는 순간부터 복잡해져 이슈에 대한 상태 파악을 쉽게 정리 불가능해 줍니다.

·         유관 부서도 많고 테스트 케이스나 버그 수준도 상당히 복잡하여 관리해줄 툴을 적절히 사용하는 것이 중요합니다. 그래서 없이 개발을 한다는 것은 비효율적이고 상식에 맞지 않습니다.

 

 

 

소프트웨어 테스트 툴은 종류가 다양할 뿐만 아니라, 테스트 절차마다 차이가 있습니다.

구분

차이

테스트 운영

진행 상황 리스크를 쉽게 파악할 있도록 보조하는 기능에 중점을 두고 있습니다.

형상 관리

버전 생성, 수정 사항 반영 크와 같은 기능을 주로 제공합니다.

 

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

플래닝포커(Planning poker)

·         스크럼 포커(Scrum poker)

·         추정을 위한 합의 기반 기술(consensus-based technique)

·         사용자 스토리의 규모를 추정하는 방식입니다.

·         소프트웨어 개발에 있어서 개발 목표를 위한 공수 산정이나 상대적 규모산정 사용됩니다.

·         플래닝 포커에서 그룹의 구성원들은 공수 산정 시에 입으로 크게 말하는 대신에 숫자로된 카드를 테이블에 엎어놓는 방식으로 놀이처럼 진행합니다. 카드들을 확인 하면서 해당 공수들이 논의됩니다.

·         숫자를 숨기는 이런 방식은 구성원들의 편향적인 고정관념을 피할수 있게 해줍니다. 누군가 처음 숫자를 크게 말하면서 다음 사람들의 공수 산정에 영향을 미칠 있는것 처럼 말입니다.

 

http://bit.ly/2ULvWsm

https://en.wikipedia.org/wiki/Planning_poker

 

 


 

 




Posted by codedragon codedragon

댓글을 달아 주세요



 

 

블랙박스 vs 화이트박스

·         블랙박스/화이트박스 기법을 비교한 내용입니다.

·         블랙박스 테스트와 화이트박스 테스트를 병행하는 것이 바람직합니다.

 

구분

블랙박스 기법

화이트박스 기법

처리

·         프로그램의 외부 명세 근거

·         (프로그램 기능 명세서)

·         프로그램의 내부 명세 근거

·         (원시 프로그램 리스트)

기준

·         What

·         무엇을 수행하는가?

·         시스템이 무엇을 수행하는지 테스트

·         시스템의 결과 동작에서 버그 식별

·         How

·         어떻게 처리되는가?

·         시스템이 어떻게 동작하는지 테스트

·         기능 또는 인터페이스 상의 내부 버그 식별

검사

·         기능 검사

·         구조 검사

시점

·         검사단계 후반부에서 수행

·         검사단계 전반부에서 수행

구조

·         제어구조 무시 (정보 영역 초점)

·         정보영역보다 제어구조 중시

검사 종류

·         동등 분할

·         경계값 분할

·         원인-결과 그래프 기법

·         비교 검사

·         기초 경로 검사

·         조건 검사

·         데이터 흐름 검사

·         루프 검사

특징

·         요구사항 명세서에 명시되어

·         있지 않은 기능은 테스트가 불가능

·         요구사항 명세서가 불완전한 경우, 블랙박스 테스트로 모든 기능 검증 불가능

·         너무 많은 수의 경로를 고려

·         모든 경로를 실행하고도 오류를 발견하지 못하는 경우 발생할 있음

·         경로가 존재하는 경우에만 테스트 가능

 

https://codedragon.tistory.com/8807

https://codedragon.tistory.com/8985

 

 


Posted by codedragon codedragon

댓글을 달아 주세요