달력

10

« 2020/10 »

  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

 

 

소프트웨어 품질

·         정의된 요구사항과 일치하는가를 확인하는데 필요한 전반적인 계획과 체계적인 작업을 말합니다.

·         개발 초기에 소프트웨어 특성과 요구사항을 파악하여 품질 목표를 설정하고 개발단계에서 정형 기술 검토를 통해 품질 목표의 충족 여부를 체크하고 테스트 과정을 거치게 됩니다. 프트웨어 품질 보증 활동 최종 결과물의 테스트나 확인을 통해서 수행되는 것이 아닌 개발 단계에서 적용됩니다.

·         소프트웨어 결함을 발견하고 제거하는 일이 소프트웨어 품질 보증을 위해서 중요한 작업이지만 이보다 중요한 것은 사전에 결함이 발생하지 않도록 예방하는 것입니다.

·         요구사항을 바탕으로 소프트웨어 아키텍처를 디자인할 때도 적절한 아키텍처를 선택하여 전체적인 개발에 문제가 발생하지 않도록 해야 하며 일정과 비용 문제도 고려합니다.

 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

 

SQUARE(ISO25000)

소프트웨어 통합 모델 표준인 SQUARE(ISO25000) 구성도(Diagram)


 

 

https://ko.wikipedia.org/wiki/ISO_25000

https://iso25000.com/index.php/en/iso-25000-standards

http://bit.ly/2rYBRlG

 


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

상태 전이 테스팅(State Transition Testing)  (0) 2020.02.03
소프트웨어 품질  (0) 2020.02.03
SQUARE(ISO25000)  (0) 2020.02.03
테스트 도구의 장단점  (0) 2020.02.03
2.Summary - 2.애플리케이션 결합 조치하기  (0) 2020.01.28
회고 프랙티스(Retrospective)  (0) 2020.01.27
Posted by codedragon codedragon

댓글을 달아 주세요


 

 

 

테스트 도구의 장단점

·         테스트 도구의 장점

·         테스트 도구의 단점

 

 

 

 

테스트 도구의 장점

·         테스트 데이터의 재입력과 재구성 같은 반복 작업의 자동화를 통하여 테스트 인력과 시간을 최소화해줍니다.

·         빌드확인, 회귀, 다중 플랫폼 호환성, 소프트웨어 구성, 기본 테스트 등의 향상된 테스트 품질을 보장합니다.

·         정적인 측정값 객관적인 평가 기준을 제공합니다.

·         향상된 요구사항 정의, 성능 스트레스 테스트, 품질 측정을 최적화해 줍니다.(요구사항의 일관성)

·         성능에 대한 통계와 그래프 테스트 정보에 대한 쉬운 접근을 제공합니다.

 

 

 

 

 

테스트 도구의 단점

·         도입 테스트 도구 전문가를 양성 또는 고용이 필요합니다.

·         초기에 프로세스 적용, 도구 사용에 대한 시간, 비용, 노력에 대한 추가 투자가 필요합니다.

·         비공개 상용 소프트웨어의 경우 고가이며, 인력과 교육에 대한 유지관리 비용이 높습니다.

 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

 

결함 심각도별 분류

구분

설명

결함 심각도 분류 사례

·         치명적, 매우 심각, 심각, 보통, 경미

·         치명적 결함, 주요 결함, 일반 결함, 사소한 결함, 개선 사항

부적절한 결함 심각도 분류 사례

·         Major, Minor, Trifle

·         A, B, C

결함 심각도 관리

·         프로젝트 조직 차원에서 합의된, 단계를 구분하기 위한 구체적이고 명확한 기준과 용어를 사용해야 결함 리포팅의 신뢰성 저하, 불필요한 논쟁 유발, 시간 낭비 낭비되는 요소를 막을 있습니다.

https://codedragon.tistory.com/5401

 

 

 

 

 

테스트의 목적

·         업무 흐름별 경로의 적절성 업무 처리 여부 확인

·         애플리케이션 간의 연계 연동 확인

·         기능과 비기능의 적합성 사용 편의성 확인

·         비정상적인 결과 발생부분의 확인 해결

·         업무간 시스템 연동으로 상호작용의 지원과 실행 여부 확인

 

 

 

 

 

 

결함 관리 측정 지표

결함 관리 다음 측정 지표를 추적해야 한다.

·         심각도 범주당 미해결 결함

·         심각도 범주당 기간 수정된 결함

·         발견된 결함 전체수

·         리스크 레벨별 잔존 결함의 심각도 수준 결함 (리스크가 높은 부분 중심)

·         누적 결함

 

https://codedragon.tistory.com/5401

 

 

 

 

 

 

결함관리 프로세스

프로세스

설명

결함관리 계획

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

결함 기록

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

결함 검토

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

결함 수정

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

결함 재확인

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

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

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

최종 결함 분석 보고서 작성

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

 

https://codedragon.tistory.com/9967

 

 

 

 

 

테스트 마감활동의 발생 시기

·         소프트웨어 시스템이 출시되어 테스트 프로젝트가 완료되었을

·         테스트 프로젝트가 취소되었을

·         계획된 모든 마일스톤이 달성되었을

·         유지보수 활동 추가 개발되거나 업데이트된 부분이 출시 완료되었을

 

https://codedragon.tistory.com/9996

 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

회고 프랙티스(Retrospective)

·         일정기간 동안 프로젝트를 수행한 팀이 프로세스를 개선하고 추후 동일한 문제점을 반복하지 않기 위해 실시합니다.

·         과거를 돌아보며 새로운 깨닫는 활동입니다.(온고이지신;溫故而知新)

·         회고는 팀이 스스로 학습하고 개선 나갈 있도록 하는 장치입니다.

·         회고 프랙티스는 애자일 프랙티스 가장 먼저 도입하는 것을 추전합니다.

·         회고는 팀의 단점을 찾기보다, 강점을 찾아 극대화하는 것을 목표로 합니다.

 

 

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

크리덴셜(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

댓글을 달아 주세요