테스트

이 글은 아래 글을 한국어로 정리한 것이다. https://medium.com/swlh/usual-production-patterns-applied-to-integration-tests-50a941f0b04a Basics: build, operate, check 모든 통합테스트는 build, operate, check 단계를 가진다. build: 테스트 시나리오를 준비하는 단계. 일반적으로 데이터에비스에 데이터를 추가한다. operate: 테스트할 API나 객체의 메서드를 호출한다. check: 실행한 API나 메서드의 결과가 예상한대로 동작했는지 확인한다. build 단계: 데이터 추가 build 단계에 테스트 시나리오를 위해 데이터베이스에 데이터를 추가해야된다. 데이터를 추가하는 방법으로는 3가지가 있다. 테스트 중인 시스템의 API 호출 순수 SQL 사용 Repository Layer 사용 테스트 중인 시스템의 API 호출 이는 안티패턴이 될 수 있다....

최근 수업 시간을 통해 단위 테스트나 통합 테스트 같은 코드 동작 테스트만 있는게 아니라 부하 테스트, 성능 테스트도 필요하다는 사실을 알게되었다. 이외에도 어떤 테스트가 있고 우리는 개발에 어떤 테스트가 필요한지 알아보도록한다. 테스트 접근법 테스트를 하기 위해서는 3가지의 접근법이 있다고한다. 화이트 박스 테스트 애플리케이션 내부의 코드를 기반으로 테스트를 진행한다. 모든 코드 라인을 거쳐 변수에 의도한 값이 저장되어 있는지, 의도한대로 분기문을 거치는지 등의 개발자가 이해할 수 있는 수준의 테스트 코드를 작성한다. 화이트 박스 테스트의 경우 불필요한 코드를 제거하는 등의 최적화를 할 수 있는 장점이 있다....

구현과 테스트 소프트웨어 생명 주기 (SDLC)와 테스트 V-Diagram Requirement Analysis: 의뢰자로부터 요구 사항을 받아 분석 System Design: 소프트웨어 명세 작성. 시스템 구성, 메뉴 구조, 데이터 구조 등. Architecture Design: 모듈 목록, 각 모듈의 기능, 인터페이스 관계, 의존 관계, 데이터베이스 테이블 등 설계. Module Design: 프로그래머가 직접 코딩을 할 수 있도록 유닛 또는 모듈 단위로 설계. 테스트 unit test 테스트가 가능한 최소 단위로 나누어진 모듈, 프로그램, 객체, 클래스 내에서 결함을 찾고 그 기능을 검증하는 것임 시스템의 다른 부분에서 격리하여 독립적으로 수행 됨 코드를 작성한 프로그래머가 주도함 코드를 중심으로 수행함 integration test 모듈간 인터페이스를 테스트 함 각기 다른 모듈과 상호 연동하는 동작을 테스트 함 기능적 특성과 특정한 비기능적 특성을 테스트 함 기능성: 조향 비기능성: 성능, 부하, 스트레스 등 system test 전체 시스템 또는 제품의 동작에 대해 테스트함 가능한 범위에서 실제 최종 사용 환경 또는 유사한 환경에서 수행함 환경 특성 장애 리스크를 최소화 하기 위해서 기능 및 비기능 요구 사항을 모두 검증함 독립적인 테스트 팀이 주도함(QA 팀 등) acceptance test 시스템이 실제 사용할만한 준비가 되어있는지에 대해 평가함 결함을 찾는 것이 주된 관심사가 아님 사용자가 불편함이 없는지 확인하는 것이 주 목적 시스템을 사용하는 사용자가 전담하여 수행함 알파/베타 테스트 알파 테스트: 사내 이해당사자들에게 테스트 베타 테스트: 사외 대상자들에게 테스트 FIRST: 좋은 단위 테스트는 무엇인가?...

응답 관련 평균 응답 시간: 사용자가 요청보내고 응답의 마지막 바이트를 받을 때까지 걸리는 평균적인 시간을 말한다. 실제 사용자 경험을 가장 잘 나타내는 수치다. 최대 응답 시간: 응답 시간 중에 가장 긴 경우를 말한다. 응답에 이상 현상을 식별할 때 사용한다. Error rate: (문제가 발생하는 요청 수)/(전체 요청 수)를 의미한다. 사용자 경험을 개선하려면 Error rate를 줄여야된다. 처리량 관련 동시 사용자(Concurrent users): 특정 시점에 활성 상태인 Virtual User의 수를 말한다. 시스템이 수용할 수 있는 유저의 수를 정할 때 사용할 수 있다....

팀 프로젝트에 성능 테스트를 진행해보기 앞서 성능 테스트의 기본 지식을 학습할 필요가 있어서 글을 작성하게 되었다. 성능 테스트? 부하 테스트? 스트레스 테스트? 성능 테스트, 부하 테스트, 스트레스 테스트. 이름만 들어서는 전부 같은 같은 말로 보였다. 하지만 실제로 표현하는 사례들을 보니 어느 정도 차이가 있었다. 성능 테스트 성능 테스트는 소프트웨어와 인프라의 속도를 테스트한다. 메모리 사용량, 네트워크 대역폭 및 처리량, 응답 시간, CPU 사용률 등의 기준을 두고 측정할 수 있다. 시스템 내에 통신 과정의 병목을 찾아내기 위해서 진행 한다....

테스트하고자 하는 객체가 다른 객체에 의존하고 있으면 그것은 단위 테스트가 아닌가? Sociable Unit Test와 Integeration Test는 궁극적으로 테스트의 목표가 다르다. Integration Test는 2개이상의 모듈이 있을 때, 각 모듈의 정확성보다는 제대로 협력하는지를 테스트한다. 따라서 Integration Test는 모든 경우를 모두 테스트할 필요는 없다. Sociable Unit Test는 모든 경우의 수에 제대로 동작하는지 테스트를 한다. 종속되는 대상을 이미 테스트하고 있다면, 굳이 독립적인 테스트를 만들 필요가 없다. 이미 종속되는 테스트를 완료했으며, 만약 너가 TDD를 하고있다면 테스트를 실패하는 원인을 찾기 어렵다는 점도 없을 것이다....

설치 https://k6.io/docs/getting-started/installation/ 위 링크를 참고하면 내가 원하는 환경의 설치 방법을 확인할 수 있다. 나 같은 경우는 도커 환경에서 성능 테스트를 진행할 예정이라 아래와 같은 명령어를 입력했다. $ docker pull loadimpact/k6 실행 하기 K6의 테스트 작성은 매우 간단했다. JavaScript 파일을 하나 만들어두고 아래와 같이 function 안에 시나리오를 작성하면 된다. import http from 'k6/http'; import { sleep } from 'k6'; export default function () { http.get('https://test.k6.io'); sleep(1); } 도커에서 실행해야되므로 아래와 같이 실행했다....

시작 하기 Gatling의 시작 방법은 단순하다. 링크에서 압축 파일을 받아서 풀면된다. 주로 유저 시나리오 코드를 user-files/simulations 경로에 넣어두고 bin/gatling.sh 를 통해 실행시키면 된다. 시나리오 작성 하기 시나리오 코드를 작성하고 싶은데 엄청 간단한 툴이 있었다. Gatling에서 Recorder라는 애플리케이션을 제공해주는데 이를 이용하면 아래 두 가지가 가능하다. 브라우저 작업을 추적해 시나리오 코드 작성 HAL 파일을 통해 시나리오 코드 작성 나 같은경우 1번 방법을 사용하면 HTTPS의 웹사이트는 추적이 불가능 한 경우가 있어서 2번 방법을 사용했다....

목표 BDD가 무엇인지 이해한다. BDD의 장점을 이해한다. BDD의 활용 예(Mockito)를 알아본다. BDD란 정의 TDD 중 하나로, TDD를 진행할 때 테스트와 관련된 용어들을 비즈니스 용어로 사용하도록 하는 기법 만들어진 배경 BDD 개념을 처음 고안한 Daniel Terhorst-North의 블로그: https://dannorth.net/introducing-bdd/ 기존에 TDD를 진행할 때, 테스트 코드의 모든 영역에 test라는 단어가 들어갔다. class: CustomerLookUpTest method: testFindsCustomerById(), TestFailsForDuplicateCustomers() 테스트 코드를 문서처럼 사용하기 위해 test라는 단어를 제거하고, 비즈니스 도메인의 용어를 사용하는 문장을 작성하도록 변경했다. class: CustomerLookUp method: findsCustomerById(), failsForDuplicateCustomers() 이 기법을 사용하다보니 아래와 같은 관습을 갖기 시작했다....