달력

12

« 2019/12 »

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


 

 

 

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

·         툴을 사용하지 않고 소프트웨어 개발을 하는 것이 불가능한 것은 아닙니다. 하지만 사람이 모두 관리할 경우 이슈가 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

댓글을 달아 주세요


 

 

 

화이트박스 기법(White-box testing)

·         화이트박스 검사 화이트박스 테스트

·         구조 시험

·         화이트박스 기법은 컴포넌트(단위) 또는 소프트웨어(시스템) 구조(코드) 중심으로 테스트 케이스를 도출하는 방법입니다.

·         컴포넌트(Component) 혹은 코드(Code) 같은 내부 구조 분석에 바탕을 두고 테스트 케이스를 도출하여 테스트하는 방법입니다.

·         프로그램 내의 경로를 수행하여 잠재적인 오류를 찾아냅니다.

 

 

http://bit.ly/2vmWA0c

https://en.wikipedia.org/wiki/White-box_testing

 


 

 


 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

 

블랙박스 기법(Black-box testing)

·         블랙박스 검사 블랙박스 테스트

·         명세 기반 기법

·         테스트 대상의 내부구조(코드) 참조하지 않고 테스트 베이시스(Test Basis), 그리고 개발자와 테스터, 사용자들의 경험을 바탕으로 기능적 혹은 비기능적 테스트 케이스를 도출하고 선택하는 방법입니다.

·         소프트웨어의 내부 구조를 직접 참조하지 않고 요구사항 명세서나 설계 문서를 기반으로 소프트웨어의 기능적 혹은 비기능적 요구 지시사항이 제대로 동작하는지 검증하는 방법입니다.

·         테스트 케이스를 체계적으로 도출하여 테스트합니다.

·         문서 기반 테스트입니다.

 

 

http://bit.ly/2Dt7bLx

https://en.wikipedia.org/wiki/Black-box_testing

 

 


 

 

 


 

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

스파게티 코드(Spaghetti code)

·         프로그램의 소스 코드가 복잡하게 얽힌 모습을 스파게티의 면발에 비유한 표현입니다.

·         스파게티 코드는 작동은 정상적으로 하지만, 사람이 코드를 읽으면서 코드의 작동을 파악하기는 어려운 코드를 의미합니다.

·         GOTO 문을 지나치게 많이 사용하거나, 프로그램을 구조적으로 만들지 않는 경우가 여기에 해당됩니다.

 

 

http://bit.ly/2VRWUzP

http://bit.ly/2vPYJEV

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

 

 


 



Posted by codedragon codedragon

댓글을 달아 주세요



 

 

화이트 박스 테스트 종류 (코드기반 시험)

구분

설명

Statement Coverage

·         모든 코드가 한번은 실행되게 입력합니다. (코드의 에러여부 파악)

Decision Coverage(branch test)

·         코드의 흐름에서 모든 진행을 테스트.

·         ex) if 구문이 2개라면 4개의 흐름(4 종류의 입력) 만들어야 합니다.

Condition Coverage

·         조건문이 있을 , 예를 들어 if 구문의 조건을 보고 조건에 맞는 input 안맞는 input 넣어서 유입되는지 테스트합니다.

·         if(조건상황들) 이라면 조건상황들이 true 조건과, false 조건을 찾아서 입력합니다.

Multiple Condition Coverage

·         조건문의 true false 모든 상황을 고려합니다.

·         조건이 if(A&B) 일때 4가지 입력이 발생(T,T T,F F,T F,F)합니다.

 

 

 

 



Posted by codedragon codedragon

댓글을 달아 주세요


 

 

 

블랙 박스 테스트 종류 (Input, Output 기반의 시험)

구분

설명

Syntax Testing

·         입력에 올바른 값과 올바르지 않는 값을 넣어서 테스트합니다.

Equivalent Partitioning

·         입력을 동등하게 쪼개고(예를 들어서 학점 프로그램이라면 0~70, 71~80, 81~90, 91~100으로 쪼갠다.), 영역의 대표값을 입력하는 테스트(45, 73, 87, 95 입력해서 각각 F, C, B, A 나와야 한다)합니다.

Boundary Testing

·         입력값의 경계를 테스트합니다.

·         ex) 학점 프로그램이라면 A B 경계인 89, 90, 91 입력해봅니다.

Decision Table

·         입력값의 종류를 결정합니다.

 

 



Posted by codedragon codedragon

댓글을 달아 주세요


 

 

QA(Quality Assurance)

·         품질 보증

·         IT 업계에서는 프로그램이 일정 수준의 품질을 가질  있도록 제품 출시 이전에 각종 테스트 검수 작업을 하는 업무를 말합니다.

·         QA 검수하는 프로그램의 품질 요소는 다양한데, 버그를 찾아내는 것부터 시작해, 위험요인이 만한 문제점들을 찾아내기도 하며, 수정된 사항이 제대로 적용되었는지의 여부도 QA 검수하게 됩니다.

·         만약 사내에 QA팀이 존재한다면 프로그램으로 인해 발생할 문제 위험성을 사전에 최소화할 있습니다.

·         하지만 QA팀이 따로 없거나 QA 프로세스를 거치지 않는다면 어떠한 프로그램이라도 출시 초기에 치명적인 버그가 있어 문제가 발생할 있습니다.

·         QA 업무는 프로그램 개발에 있어 중요한 위치를 차지하고 있습니다.

 

 

https://namu.wiki/w/QA

http://bit.ly/2UOHX0c

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

 

 

 

 

 

품질 관리 담당자 (QAO; Quality Assurance Officer)

·         품질 관리 담당자는 소프트웨어 개발을 하기 위한 단계 단계마다 품질을 보장하기 위한 활동들을 주도합니다.

·         주요 일정(마일스톤) 따라 예상되는 산출물들을 챙기고 직접 작성하기도 합니다. 여기서 산출물은 요구사항 명세서, 화면 설계서, 테스트 시나리오등과 같은 문서들을 의미합니다.

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

테스트 승인 불합격

테스트 승인 여부 결과 승인 시에는 해당 소프트웨어를 정식 배포하는 프로세스 진행합니다.

 

 

 

테스트 승인 여부 결과 불합격 프로세스

구분

설명

소프트웨어 개발팀

·         테스트 문제 보고서에 나온 모든 이슈에 대해서 소프트웨어 담당자를 선정합니다.

·         소프트웨어 담당자는 이슈를 분석하여 원인, 결과, 수정 여부를 확인합니다.

·         다음 테스트 일정을 확인하고 다음 테스트 전까지 테스트 의뢰에 필요한 모든 문서를 작성합니다.

검증팀

·         테스트 의뢰 시스템에 테스트 결과를 반영합니다.

·         소프트웨어 개발팀과 합의하에 다음 테스트 일정을 수립합니다.

·         개발자의 이슈 문의에 대한 지원 수행합니다.

 

 

 

[테스트 결과 문서 이해]


 


 


Posted by codedragon codedragon

댓글을 달아 주세요