라벨이 테스트 개요인 게시물 표시

단위 테스트의 희망편, 절망편과 성공적인 단위 테스트를 위한 지침

단위 테스트 : 희망편, 절망편 단위 테스트의 목표는 소프트웨어 프로젝트의 지속 가능한 성장이다. 단위 테스트의 적용 여부는 논쟁거리가 아니며 늘 적용해야한다. 그러나, 모든 테스트 스위트가 프로젝트에 좋은 결과만 가져오는 것은 아니다. 희망편 테스트를 포함한 프로젝트는 초반에 작업 속도가 테스트가 없는 프로젝트보다 느리지만 시스템이 복잡해질 수록 소프트웨어 엔트로피 에서 이득을 본다. 소프트웨어 엔트로피는 시스템 내 무질서도를 말하는데, 테스트가 없는 프로젝트에서 소프트웨어 엔트로피는 저품질의 코드 형태로 나타나고 코드베이스를 신뢰할 수 없을 지경이 되면 그 소프트웨어는 안정적이라고 보기 어렵다. 코드베이스를 지속적으로 검증하는 테스트를 통해 회귀 현상(코드 수정 후 나타나는 버그)에 대한 안전망 역할을 하는 보험을 얻었다. 보험을 얻었으니 프로젝트 후반에도 개발 속도를 유지하며 소프트웨어를 확장할 수 있다. 부수 효과로 더 나은 설계 를 얻을 수도 있다. 예를 들어,  코드가 서로 충분히 분리되어있지 않은 강결합(tight-coupling)의 저품질 코드를 단위 테스트를 쉽게 하기 위해 리팩토링 하는 케이스가 있다. -> 그러나 낮은 결합도라고해서 프로젝트의 코드 품질이 좋다는 보장은 없다. 절망편 테스트가 포함된 프로젝트와 없는 프로젝트에 대한 차이는 얘기했으니 잘못된 테스트가 포함된 프로젝트에 대해서 얘기한다. 프로젝트 내에서 잘못된 테스트 스위트가 지속되면  테스트를 해도 원하는 결과를 얻지 못하는 경우와 상황을 악화시키는 경우가 발생한다. 테스트가 잘못 작성된 프로젝트는 결국 침체 단계 에 빠진다. 테스트 개수는 상당히 많지만 테스트 자체가 유지보수 되지 않고 버그를 유발한다면 잘못된 경고 가 발생하고 회귀 오류에 도움이 되지 않는 결과 를 보여준다. 테스트는 프로젝트에 도움이 돼야하는데 의미 없는 테스트만 양산한다면 , 소프트웨어의 잠재적인 버그에 노출되는 부분을 넓히는 것 에 불과하다. 고품질 테스트에만 집중해야하며, 고...

V&V 대 품질 보증

포함관계 테스트 < V&V < 품질 보증 V&V = Verification and Validation Verification 검증 개발 과정에서 수행한 활동의 적합성 검사 EX ) 추적성 검사 Validation확인 결과물의 적합성을 검사 개발 단계별 V&V IEEE Std. 2012-2012 IEEE Standard for System and Software Verification and Validation 은 개발 단계별 V&V를 제시한다. EX ) 요구사항분석 단계에서의 V&V 요구사항평가 인터페이스 분석 추적성 분석 심각성 분석 V&V 활동 분류 ISO/IEC/IEEE 29119-1가 제시하는 V&V 활동 분류 정형 방법 모델 체킹 정확성 증명 테스팅 동적 테스팅 정적 테스팅 V&V 분석 시뮬레이션 평가 품질 보증 테스팅, V&V보다 큰 활동 범위를 가진다. 규칙-규제-법규 등을 포함한 이해관계자의 요구사항을 바탕으로 프로세스-시스템/소포트웨어개발에 대한 모든 것을 포함.

테스트와 품질 평가

SW테스트와 SW품질의 관계 소프트웨어의 품질을 평가할 때 테스트를 활용할 수 있다. ISO25010 소프트웨어 품질 유형의 8가지 특성-하위 품질 특성을 분류함 기능 적합성 성능 효율성 호환성 사용성 신뢰성 보안성 유지보수성 이식성 각기 다른 품질 특성이 있기 때문에 각 품질 특성별로 다른 유형의 테스트를 수행한다. 유형 테스트 성능 - 성능 테스트 보안 - 보안 테스트 신뢰 - 신뢰성 테스트 등 ... 기능 테스트 대 비기능 테스트 기능 테스트 Functional Test 기능 요구사항에 중점을 둔 테스트 비기능 테스트 Non-functional Test 품질 요구사항에 중점을 둔 테스트

정적 테스트 대 동적 테스트

정적 테스트 테스트 대상을 실행하지 않고 테스트 수행. 리뷰 개발 단계별 산출물이 품질 목표에 부합하는지 점검, 검토. 산출물에 존재하는 결함 검출이 목적 정적 분석 결함으로 판단할 수 있는 특정한 패턴이 소스 코드에 있는지 분석. 장점 - 경제성 : 실행환경을 필요로 하지 않고 설계 수준에서 결함을 검출하고 해결하기 때문. - 도메인별 자동화 도구를 활용한 대규모 소스 코드 분석    프로그래밍 개발표준인 MISRA C, MISRA C++, JSF AV C++ 등은    자동차, 항공기같은 안전이 중요시되는 소프트웨어 개발에 필수로 요구됨 단점 - 결함이 아닌 문제를 결함으로 보고하는 False positive의 단점이 있음 - False positive의 비율이 높아지면 도구의 테스트 결과를 신뢰하지 않는 부작용 발생 동적 테스트 테스트 대상을 실행하여 결함 검출. 명세 기반 프로그램의 구조, 내부 논리를 참고하지 않고 테스트 케이스를 개발. 대신 사용자의 요구 명세, 설계 정보를 이용하여 개발한다. 컴포넌트-통합-시스템-인수 테스트 등 전 과정에 걸쳐 사용될 수 있음. 구조 기반 프로그램의 제어 흐름이나 자료 흐름 정보를 이용하여 테스트 케이스 설계. 프로그램 내부 구조 정보를 기반으로 테스트 케이스를 설계하므로 화이트박스 테스트 라고도 한다. 경험 기반 테스트 케이스 설계 바탕으로 테스트를 수행하는 대신 도메인에서 테스터의 경험, 기존 테스트 산출 결과, 직관을 활용하여 수행. 대표적으로 오류 추정 탐색적 테스트 가 있다. 장점 소스코드 없어도 수행이 가능하다. 코드 분석으로 확인하기 어려운 요구사항을 확인할 수 있다. (-초 이내에 이벤트가 발생해야한다 와 같은 제약이 있는 경우) 단점 소프트웨어를 실행하기 위한 환경이 요구된다. 그 환경은 외부 시스템과 연계가 필요한 환경일 수도 있다.

테스팅, 디버깅, 재테스팅

테스팅 결함 존재가 있는지 확신할 수 없는 상태에서 요구사항과 소프트웨어의 실제 동작의 차이를 확인한다. 예상 결과와 다른 결과를 보일 때, 결함이 존재한다고 추측함. 테스팅의 결과 산출물 결함을 검출한 (테스트 케이스-테스트 환경) 소프트웨어의 어느 모듈에서 발생했는지 이를 해결하기 위한 방법은 관여하지 않는다. 디버깅 결함 존재를 확인 후 결함 위치를 파악하고 제거하는 과정. 재테스팅 결함 제거를 위한 코드 수정 후, 실제로 제거됐는지 다시 테스트. 초기 결함을 검출한 테스트 케이스 로 다시 테스트

테스트 원칙

The Art of Software Testing에서 말하는 테스트 원칙 테스트는 반드시 프로그램을 개발한 프로그래머나 팀과는 무관한 그룹이 수행할 것. 사람의 심리상 자신이 작성한 프로그램에 대해서는 방어적 경향을 띄기 때문. 결함이 발견되지 않으리라는 가정하에 테스트 계획을 수립하면 안 된다. 테스트는 결함을 발견하려는 의도로 프로그램을 실행하는 과정이기 때문. 프로그램의 어떤 부분에 결함이 남아있을 확률은 그 부분에서 이미 발견된 결함의 수에 비례한다. 프로그램의 결함의 80%는 20%의 모듈에서 발생한다. 테스트 케이스를 체계적으로 관리할 것. 프로그램이 어떤 이유로 수정되었다면 기존의 기능이 영향을 받았는지 다지 테스트해야한다. 이를 위한 새 테스트 케이스를 만드려면 많은 작업량이 필요하므로 기존에 만들었던 테스트 케이스를 재사용하여 테스트하는 것이 바람직함. 각각의 테스트 결과를 철저하게 점검할 것. 출처 The Art of Software Testing

이 블로그의 인기 게시물

실무진 면접 경험으로 정리하는 백엔드 (1) : 에듀 테크 기업 면접

노마드코더 개발자북클럽 Clean code TIL 6 : 6장. 객체와 자료구조

백엔드 개발자가 Djnago fullstack 사이드 프로젝트를하며 ( html, css, vanillaJS 그리고 JS프레임워크 )