달력

1

« 2020/1 »

  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  


 

 

크리덴셜(Credential)

·         ID, PW 같은 로그인 정보 개인 신상과 관련해 암호화한 정보까지 폭넓게 의미합니다.

·         크리덴셜은 사용자가 본인을 증명하는 수단으로서의 의미를 가집니다.

 

 

 

 

 

크리덴셜 스터핑(Credential stuffing)

·         공격자가 이미 확보한 크리덴셜(Credential) 다른 계정들에 마구 집어 넣는(stuffing) 방식으로 사용자 정보를 침해하고 공격하는 것을 가리킵니다.

·         웹사이트에서 훔친 로그인 정보를 다른 웹사이트에 무차별 대입(brute-force)하는 자동화 시스템입니다.

·         하나의 계정 정보가 다른 계정 정보와도 일치할 것을 노린 공격 프로세스입니다.

·         사용자가 동일한 크리덴셜을 다중의 웹사이트에서 사용한다는 사실을 파악하여 계정 탈취를 쉽게 자동화할 있고 추후 많은 계정을 공격하는 데도 활용되어집니다.

·         만약 어떤 사람이 동일한 비밀번호를 여러 계정에서 함께 사용하고 있거나 예전에 사용했던 비밀번호를 다시 사용하고 있다면, 언제 어디서 유출됐을지 모를 크리덴셜을 통해 공격자가 여러 계정에 사람의 비밀번호를 대입해 공격하다면 공격에 성공할 가능성이 매우 높아지게 됩니다.

 

 

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

https://www.owasp.org/index.php/Credential_stuffing

 

 

 


 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

 

 

결함 리포트

결함 관리를 위해 결함 발생 결함 관리시 스템에 결함을 등록하되 아래 항목들을 필수로 포함합니다.

·         결함 내용

·         테스트 케이스 식별 번호

·         결함 유형

·         발견일

·         심각도

·         우선순위(결함 수정의 우선순위)

·         시정 조치 예정일

·         수정 담당자

·         테스트 결과

·         종료일

 

https://codedragon.tistory.com/5401

 

 

 

 

 

 

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

 

·         단위 테스트

·         통합 테스트

·         시스템 테스트

·         인수 테스트

 

 

https://codedragon.tistory.com/9984

https://codedragon.tistory.com/8937

https://codedragon.tistory.com/9914

https://codedragon.tistory.com/9943

https://codedragon.tistory.com/9113

 

 

 

 

 

 

 

형상관리 용어 - Git

https://codedragon.tistory.com/4763

 

 

 

 

 

 

 

결함 분석(Defect Analysis) 관련 용어 설명

https://codedragon.tistory.com/6178

 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

 

 

 

테스트 도구의 장단점

https://codedragon.tistory.com/9856

 

 

 

 

 

 

 

 

 

소프트웨어 품질 평가의 모델 SQUARE(ISO25000) 구성  Diagram

 

 


 

https://codedragon.tistory.com/9876

https://codedragon.tistory.com/9895

https://codedragon.tistory.com/9060

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

상태 전이 테스팅의 설계 절차

단계

절차

1

상태-이벤트 테이블 구성

2

전이 트리 구성

3

반응(Legal or Valid)테스트 케이스 구성

4

무반응(Illegal or Invalid)테스트 케이스 구성

5

가드 또는 조건 테스트 케이스 구성

6

테스트 프로시저 구성

 

https://codedragon.tistory.com/9738

https://codedragon.tistory.com/9838

 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

 

테스팅의 일반적인 원리

원리

설명

테스팅은 결함이 존재함을 밝히는 활동입니다.

·         결험이 발견되지 않는다해도 결함이 없다는 것은 증명할 없습니다.

완벽한 테스팅 불가능합니다.

·         리스크 분석과 결정된 우선순위에 테스팅을 집중해야 합니다.

·         모든 가능성을 테스트하는 것은 불가능합니다. (자원 한계, 무한한 조건/조합이 존재)

테스팅은 개발 초기 시작합니다.

·         개발 시작과 동시에 테스트를 계획, 전략적으로 접근해야 합니다.

결함 집중(Defect Clustering)

·         대다수의 결함들은 적은 수의 모듈에서 대다수의 결함이 발견됩니다.

살충제 패러독스(Pesticide Paradox)

·         동일한 테스트를 반복적으로 수행하면 버그를 찾기 힘듭니다.

·         동일한 테스트케이스로 반복 수행할 경우 새오운 결합을 찾을 없으므로 정기적인 테스트케이스 리뷰와 개선 필요합니다.

테스팅은 정황(Context) 의존적입니다.

·         정황과, 분야에 따라 다르게 테스트를 진행합니다.

·         효율적, 효과적 테스트 조직과 독립적 테스트 환경이 필요합니다.

오류-부재의 궤변(Absence of Errors Fallacy)

·         사용자 요구사항에 맞지 않는다면 결함을 찾고 수정하는 것은 무의미합니다. , 요구사항을 충족하지 못하면 결함을 모두 발견했다고(오류가 없더라도) 해도 품질이 높다고 없습니다.

 

https://codedragon.tistory.com/6531

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

등가 분할(Equivalence Partitioning)

·         등기 분할

·         입력값/출력값 영역(Input/Output Space) 유한 개의 상호 독립적인 집합(Mutual Disjoint Subset)으로 나누어 수학적인 등가 집합을 만든 , 등가 집합의 원소 대푯값을 선택하여 테스트 케이스를 도출하는 방법입니다.

·         동등 분할 클래스는 유효한 입력 데이터뿐 아니라 유효하지 않은 입력 데이터(입력되지 말아야 ) 포함할 있습니다.

·         입력 데이터의 도메인(Domain) 유사한 특징을 가진 그룹(Class)으로 분류하여 그룹(Class)에서 대표 테스트 케이스를 도출하는 방법입니다.

·         동일한 입력에 대해서는 항상 동일한 결과를 가져오도록 그룹(Class) 구분합니다.

·         유효한 입력 조건을 대표하는 유효한 그룹(Valid Class) 외의 다른 경우를 대표하는 유효하지 않은 그룹(Invalid Class)으로 구분하는 것이 일반적입니다.

 

 

 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

아리안 5 폭발 사고

·         1996 아리안 5 로켓이 발사된 40 만에 폭발하는 사고가 있었습니다. 폭발 사고는 64비트로 표현된 실수 값을 16비트 정수로 변환하는 과정에서 16비트 보다 수가 입력되어 Overflow 발생하여 일어난 것이었습니다. 폭발로 인해 3 7000 달러의 손실이 발생하였습니다. 만약 로켓을 발사하기 전에 소프트웨어 테스트 면밀하게 진행하였다면 사고를 방지할 있었을 것입니다.

 

·         소프트웨어의 결함을 사전에 검출하지 못할 경우 엄청난 결과를 초래할 있으며, 소프트웨어의 개발 못지 않게 소프트웨어 테스트 중요하다는 것을 잊지 말아야합니다.

 

http://bit.ly/2vj8Vms

http://bit.ly/2DuyoxL

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

 


 

 

 

 

차세대 로켓 아리안 5 프랑스에서 발사했으나 폭파돼 - MBC NEWS

1m 30s

http://bit.ly/2Pp8Vu8


 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

 

사용자 스토리 프랙티스

·         개발해야 대상 제품이나 서비스의 기능을 정의하는 방식입니다.

·         사용자입장에서 비즈니스적인 가치를 정의하는 것에 초점을 두고 요구사항을 정의하는 프랙티스입니다.

·         사용자 스토리 프랙티스 고객팀 작성자 또는 담당자 함께 작성합니다.

 

구분

역할

고객팀

사용자 스토리의 초안을 제시

작성자 똔느 담당자

가급적 업무를 아는 사람(기획자) 고객과 함께 있는 자리에서 질문하며 작성합니다.

 

 

 

 



Posted by codedragon codedragon

댓글을 달아 주세요



 

 

인스펙션(Inspection) 절차

 


 

단계

설명

계획

(Planning)

·         인스펙션 대상 산출물 선정

·         중재자 구성

·         중재자는 사전에 인스펙션 대상 산출물 팀원에게 배포합니다.

·         팀원은 배포된 산출물을 사전에 숙지하기 위한 계획을 세워야 합니다.

·         인스펙션 날짜, 시간 장소를 사전에 공지합니다.

개관

(Overview)

·         팀원이 인스펙션 자료들을 이해하고 분석할 있게 하는 것이 목적입니다.

·         팀원이 산출물을 보다 쉽게 이해하도록 하여 인스펙션의 효과를 극대화합니다.

·         선택적 단계

·         팀원들의 산출물에 대한 이해도가 높을 경우 생략 가능합니다.

준비

(Preparation)

·         검사 회의에 참여하기 준비 단계

·         개별적으로 작업 산출물과 관련 자료들을 철저하게 공부하고 이해해야 합니다.

·         체크리스트 활용하여 검토해야 주요 항목 숙지해야 합니다.

·         팀원은 각자 준비하는 얼마만큼의 시간을 사용하였는지, 결점이라고 생각되는 것들을 기록해야 합니다.

·         중재자는 인스펙션 시간을 산정합니다.

검토 회의

(Meeting)

·         인스펙터들이 작업 산출물을 함께 검토하는 회의입니다.

·         실제 인스펙션이 이루어 지는 단계

·         중재자는 회의 시작하기 , 모든 인스펙터들이 충분히 준비되었는지 확실히 해야합니다.

·         개발자가 산출물 내용을 풀어 설명하는 동안, 다른 모든 사람들은 오류를 찾기 위해 인스펙션을 수행합니다.

·         보통 개발자가 읽으면서 에러를 스스로 찾는 경우가 많습니다.

·         오류가 발생했는지, 어떻게 수정할지 논의해서는 됩니다.

·         오로지 산출물을 정밀히 조사하는 작업에만 집중해야 합니다.

·         오류 검출 과정에 개발자에 대한 비판으로 가지 않도록 주의해야 합니다.

·         시간 기록과 함께 찾아진 모든 오류는 분류 기록해야 합니다.

·         코드 인스펙션

·         1~2시간 사이가 적당하며 너무 경우 효율성이 저하될 있습니다.

재작업

(Rework)

·         개발자는 검사 회의 모든 발견된 오류를 수정합니다.

·         오류의 개수에 따라 중재자가 재검사 진행이 가능합니다.

·         재작업시 계획단계로 돌아가서 수행합니다.

추적

(Follow-up)

·         수정한 결과는 중재자가 체크합니다.

·         중재자의 판단에 따라 결과가 좋은 경우 인스펙션을 공식적 완료합니다.

·         산출물은 형상관리 체제에 따라 관리합니다.

 

 



Posted by codedragon codedragon

댓글을 달아 주세요


 

 

 

프레임워크(Mock framework)

·         객체를 활용한 테스트는 직접 개발자가 객체를 만들어야 합니다.

·         객체를 만드는 것은 시간 · 노력이 필요합니다.

·         이미 만들어져 있는 프레임워크를 활용하여 쉽게 객체 활용이 가능합니다.

·         해당 라이브러리만 세팅하면 쉽게 객체를 활용 가능

 

 

 

대표적인  프레임워크

·         EasyMock

·         Jmock

·         Mockcpp

·         Googlemock

 


Posted by codedragon codedragon

댓글을 달아 주세요