달력

8

« 2020/8 »

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


 

 

경계값 분석(Boundary Value Analysis)

·         동등 분할의 경계에서 결함이 발견될 확률이 높기 때문에 결함을 예방하기 위해 경계값까지 포함하여 테스트하는 기법입니다.

·         분할 영역의 최대값과 최소값은 영역의 경곗값이 됩니다.

입력 조건의 중간 보다는 경계 값에 오류(Error) 발생할 확률 경험적으로 높다는 점을 감안하여 경계 값을 포함하여 테스트 케이스를 설계하는 방법입니다.

 

 

 

 

경계값 분석 특징

·         등기 분할(Equivalence Partitioning) 변형입니다.

·         입력 값의 경계 부분에서 많은 오류가 발생합니다.

·         개발자가 비교 연산자(Comparison Operators) 사용에서 실수할 여지가 많습니다.

·         일반적으로 해당 경계 , 경계보다 작은 , 경계보다 선정합니다.

o    N, N-1, N+1 for the 상위 경계

o    N, N-1, N+1 for the 하위 경계

 

 

 

 

 

등기 분할(Equivalence Partitioning)과의 차이점

등기 그룹(Equivalence Class) 내의 임의 값을 선택하는 대신 그룹(Class) 경계 값이 선택되도록 합니다.

 

 

 



Posted by codedragon codedragon

댓글을 달아 주세요



 

 

TDD 개발 절차

구분

단계

1

테스트 추가

2

테스트 수행(새로운 테스트 실패되도록)

3

코드 작성

4

테스트 수행(모든 테스트 성공할 때까지)

5

코드 리팩토링

6

반복

 

 

 


 

 

Step1 : 테스트 추가

·         추가되는 기능에 대해 구현에 앞서 테스트 케이스를 작성합니다.

·         테스트 케이스로 작성되는 기능은 유닛 테스트 정도의 작은 기능으로 구현합니다.

·         테스트 케이스를 작성하는 개발자는 기능에 대한 상세 요구사항을 파악해야 합니다.

·         테스트 케이스 작성은 JUnit 같은 유닛 테스트 활용합니다.

 

 

 

 

Step2 : 테스트 수행(새로운 테스트 실패되도록)

·         추가한 테스트 케이스를 포함하여 유닛 테스트를 수행합니다.

·         새롭게 추가된 테스트 케이스의 결과는 실패(Fail) 떨어집니다. 새롭게 추가된 테스트 케이스에 대한 코드는 구현되지 않았기 때문에 실패(Fail)하는 것이 당연합니다.

·         추가된 테스트 케이스만 실패하여 개발자에게 구현 테스트에 대한 확신을 있습니다.

 

 

 

 

 

 

Step3 : 코드 작성

·         테스트 케이스 실패 원인이 코드를 작성하는 단계입니다.

·         테스트 케이스 이외의 코드 작성은 금지합니다.

·         테스트 케이스의 결과가 성공(Pass) 수준의 코드로 작성하는 것이 목표입닏.

 

 

 

 

 

 

 

Step4 : 테스트 수행(모든 테스트 성공할 때까지)

·         테스트 케이스를 다시 한번 수행하는 단계입니다.

·         추가된 테스트 케이스 모든 테스트 케이스를 통과(Pass)하는 것이 목표입니다.

·         모두 통과 개발자는 구현사항이 요구사항을 만족한다는 것에 확신할 있습니다.

·         새롭게 추가한 코드가 부작용을 일으키지 않았다는 것을 확인할 있습니다.

·         테스트 케이스가 통과(Pass)하지 않는 경우 추가된 코드에 문제 있음로 수정이 필요하며 수정 단계를 다시 수행합니다.

 

 

 

 

  

Step5 : 코드 리팩토링

·         테스트 주도 개발 프로세스 수행시 정기적 코드에 대한 리팩토링 수행이 필요합니다.

·         신규기능 추가에 의한 코드 규모 확대, 중복 코드 제거, 구조 개선, 식별자의 의미가 명확하게 나타나도록 변경 등의 작업을 수행합니다.

·         리팩토링 후에 지속적으로 테스트 케이스를 실행합니다.

·         모든 테스트 케이스 통과(Pass) 리팩토링이 기존 기능을 변형시키지 않았음을 확인할 있습니다.

 

 

 

 

 

Step6 : 반복

·         요구사항의 새로운 기능 추가 구현시 1번째 단계(테스트 추가)부터 반복하여 수행합니다.

·         단계의 수행은 간결하게 유지합니다.

·         기능을 작은 단위로 쪼개서 수시로 반영합니다.

·         테스트 주도 개발 절차에 의해 반복적으로 수행합니다.



 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

Banana code(바나나 코드)

·         Banana 철자에서 'an' 반복해서 쓰는 데서 유래되었습니다.

·         무한 루프(infinite loop) 도는 코드를 의미합니다.

 


 

 

무한 루프(무한반복; infinite loop; Endless loop)

https://codedragon.tistory.com/1081

 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

추정 프랙티스 조감도

각기 서로 다른 사용자 스토리에 따라 상대적으로 다른 사용자 스토리를 가지고 있어서 사용자 스토리의 규모를 이해 있습니다.


 

http://bit.ly/2vrt4Xe

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

소프트웨어 보안약점 진단가이드


 

 

 

https://bit.ly/2Wny1fY


 

 

 

 

직접 다운로드

붙임5_소프트웨어_보안약점_가이드.z01

붙임5_소프트웨어_보안약점_가이드.z02

붙임5_소프트웨어_보안약점_가이드.z03

붙임5_소프트웨어_보안약점_가이드.z04

붙임5_소프트웨어_보안약점_가이드.z05

붙임5_소프트웨어_보안약점_가이드.z06

붙임5_소프트웨어_보안약점_가이드.z07

붙임5_소프트웨어_보안약점_가이드.z08

붙임5_소프트웨어_보안약점_가이드.z09

붙임5_소프트웨어_보안약점_가이드.z10

붙임5_소프트웨어_보안약점_가이드.z11

붙임5_소프트웨어_보안약점_가이드.z12

붙임5_소프트웨어_보안약점_가이드.z13

붙임5_소프트웨어_보안약점_가이드.zip

 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

 

페어 프로그래밍(Pair programming)

·         프로그래밍 동료 프로그래밍  프로그래밍

·         사람이 하나의 컴퓨터와 키보드를 공유하면서 일하는 기법입니다.

·         프로그래머가 컴퓨터에서 함께 일하면서 코딩과 코드 리뷰를 동시에 수행하게 됩니다.

·         상호간에 코드 리뷰를 함으로써 보다 좋은 품질을 얻을 있습니다.

 

 

구분

역할

드라이버

(driver)

·         진행자

·         코드를 작성하는 사람

·         키보드를 소유하고 작업을 진행하는 사람

·         질문과 제안하는 역할

내비게이터

(naviagator)

·         관찰자

·         pointer observer

·         코드를 함께 리뷰하는 사람(code review)

·         훈수를 두거나 그림/방향을 그리는 사람

·         목표와 방향을 점검하며 드라이버의 작업을 검토하고 리트하는 사람

·         작업의 방향을 제시하는 역할

 

 

http://bit.ly/2XOJR2M

http://bit.ly/2IWL2Je

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

 

 

 


http://bit.ly/2ZEZwTW

 







Posted by codedragon codedragon

댓글을 달아 주세요


 

 

 

결정/조건 커버리지(Decision/Condition Coverage)

·         변형 조건/결정 커버리지

·         조건/결정 커버리지(Condition/Decision Coverage)

·         변형 조건/결정 커버리지(MC/DC) 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상시킨 것으로 결정 커버리지, 조건 커버리지보다 강력하다.

·         조건문 내에 존재하는 조건들의 (True) 거짓(False) 모두를 커버하고 연산식(Boolean Expression) · 거짓이 적어도 이상 실행되는 것을 기준으로 하는 커버리지입니다.

·         조건 커버리지에 부합되는 값이 결정 커버리지나 구문 커버리지의 각각을 만족시키지는 못합니다.

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

결함관리 프로세스

결함관리 프로세스는 7개의 활동으로 구성됩니다. 

 

프로세스

설명

결함관리 계획

결함관리 계획은 전체 프로세스에서 결함관리에 대한 일정, 인력, 업무 프로세스를 확보하여 계획을 수립하는 것을 말합니다.

결함 기록

테스터는 발견된 결함에 대한 정보를 결함관리 DB 기록합니다.

결함 검토

등록된 결함에 있어서 주요 내용을 검토하고, 결함을 수정할 개발자에게 전달합니다.

결함 수정

개발자는 할당된 결함의 프로그램을 수정합니다.

결함 재확인

테스터는 개발자가 수정한 내용을 확인하고 다시 테스트를 수행합니다.

결함 상태 추적 모니터링 활동

결함관리 팀장은 결함관리 데이터베이스를 이용하여 대시보드 또는 게시판 형태의 서비스를 제공합니다.

최종 결함 분석 보고서 작성

발견된 결함에 대한 내용과 이해관계자들의 의견이 반영된 보고서를 작성하고 결함관리를 종료합니다.

 

 


Posted by codedragon codedragon

댓글을 달아 주세요

 

 

시스템 테스트(System Test)

·         소프트웨어의 전체 시스템에 대한 테스트 수행합니다.

·         기능, 성능, 메모리, 요구사항 만족 여부 전반적인 테스트 진행합니다.

·         출시 전에 기능 완성도 성능을 검증하는 마지막 단계의 테스트합니다.

·         독립적인 테스트 테스트를 진행합니다.

 

 

 

시스템 테스트 항목

·         모든 요구사항의 정확한 실행여부

·         사용성, 이식성, 신뢰성, 유지보수성 비기능적인 요구사항

·         하드웨어, 소프트웨어, 운영자의 유저 인터페이스 측면의 요구사항

·         데이터나 다른 리소스의 과부하 상태에서의 내구성

·         매뉴얼(사용자, 관리자) 적절성

 

 

 

 

 

시스템 테스트 종류

구분

테스트 기법

구조적(Structural) 테스트 기법

·         스트레스(Stress) 테스트

·         회복(Recovery) 테스트

·         준거성(Compliance) 테스트

·         보안(Security) 테스트

기능적(Functional) 테스트 기법

·         요구사항(Requirement) 테스트

·         회귀(Regression) 테스트

 

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

프로젝트 수행 단계에 따른 테스트의 접근 방법

 

·         단위 테스트

·         통합 테스트

·         시스템 테스트

·         인수 테스트

 

 


'Security > SecureCoding' 카테고리의 다른 글

결함관리 프로세스  (0) 2020.03.09
시스템 테스트(System Test)  (0) 2020.03.09
프로젝트 수행 단계에 따른 테스트의 접근 방법  (0) 2020.03.09
스프린트 계획 미팅  (0) 2020.03.06
V-model(V 모델)  (0) 2020.03.01
SQL Injection 공격  (0) 2020.02.23
Posted by codedragon codedragon

댓글을 달아 주세요