QA

Spies Spies는 Test Double 기법 중 하나로, 실제 객체의 메서드 호출을 추적하고 기록하는 데 사용된다. 목적 메서드 호출 여부, 횟수, 전달된 인자 등을 검증한다. 실제 구현을 변경하지 않고 메서드의 동작을 관찰한다. 코드의 상호작용을 분석하고 테스트한다. 장점 비침투적: 실제 객체의 동작을 변경하지 않고 관찰할 수 있다. 유연성: 다양한 정보를 수집하고 검증할 수 있다. 상세한 검증: 메서드 호출의 세부 사항을 정확히 확인할 수 있다. 단점 복잡성: 과도한 사용 시 테스트 코드가 복잡해질 수 있다. 오버스펙: 구현 세부사항에 너무 의존적인 테스트를 작성할 위험이 있다. 성능: 많은 spy를 사용할 경우 테스트 실행 속도가 느려질 수 있다. 예시 예시 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 from typing import Dict, Optional from datetime import datetime # 실제 데이터베이스 리포지토리 class UserRepository: def __init__(self, database_connection): self.db = database_connection def save(self, user_id: str, user_data: Dict): # 실제로는 데이터베이스에 SQL 쿼리를 실행할 것입니다 self.db.execute( "INSERT INTO users (id, data, created_at) VALUES (?, ?, ?)", [user_id, user_data, datetime.now()] ) def find_by_id(self, user_id: str) -> Optional[Dict]: # 실제로는 데이터베이스에서 조회할 것입니다 result = self.db.execute( "SELECT * FROM users WHERE id = ?", [user_id] ) return result.fetchone() # Fake 리포지토리 class FakeUserRepository: def __init__(self): # 데이터베이스 대신 딕셔너리를 사용 self.users: Dict[str, Dict] = {} def save(self, user_id: str, user_data: Dict): # 메모리에 직접 저장 self.users[user_id] = { 'data': user_data, 'created_at': datetime.now() } def find_by_id(self, user_id: str) -> Optional[Dict]: # 메모리에서 직접 조회 return self.users.get(user_id) # 사용자 서비스 class UserService: def __init__(self, user_repository): self.repository = user_repository def create_user(self, user_id: str, name: str, email: str): user_data = {'name': name, 'email': email} self.repository.save(user_id, user_data) def get_user(self, user_id: str): return self.repository.find_by_id(user_id) # 테스트 코드 def test_user_service(): # Fake 리포지토리 사용 fake_repository = FakeUserRepository() user_service = UserService(fake_repository) # 사용자 생성 테스트 user_service.create_user('user1', 'John Doe', 'john@example.com') # 사용자 조회 테스트 user = user_service.get_user('user1') assert user['data']['name'] == 'John Doe' assert user['data']['email'] == 'john@example.com' JavaScript 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 // 실제 외부 API 서비스 class WeatherService { async getTemperature(city) { // 실제로는 외부 API를 호출할 것입니다 const response = await fetch( `https://api.weather.com/${city}/temperature` ); return response.json(); } } // Fake 날씨 서비스 class FakeWeatherService { constructor() { // 미리 정의된 도시별 온도 데이터 this.temperatureData = { 'Seoul': { temperature: 25 }, 'New York': { temperature: 20 }, 'London': { temperature: 15 } }; } async getTemperature(city) { // 실제 API 호출 대신 저장된 데이터 반환 return Promise.resolve(this.temperatureData[city] || { temperature: 0 }); } } // 날씨 알림 서비스 class WeatherAlertService { constructor(weatherService) { this.weatherService = weatherService; } async shouldSendAlert(city) { const data = await this.weatherService.getTemperature(city); return data.temperature > 30; } } // 테스트 코드 describe('WeatherAlertService', () => { it('should not send alert for normal temperature', async () => { // Fake 날씨 서비스 사용 const fakeWeatherService = new FakeWeatherService(); const alertService = new WeatherAlertService(fakeWeatherService); const shouldAlert = await alertService.shouldSendAlert('Seoul'); expect(shouldAlert).toBe(false); }); }); 참고 및 출처

Stubs Stubbing은 테스트에서 사용되는 기법으로, 실제 객체나 아직 구현되지 않은 코드를 대신하여 미리 정의된 응답을 제공하는 메커니즘 목적 의존성 격리: 실제 구현체로부터 테스트 대상을 분리하여 독립적인 테스트를 가능하게 합니다. 특정 시나리오 테스트: 다양한 상황에 대한 테스트를 용이하게 합니다. 미구현 코드 대체: 아직 개발되지 않은 부분을 임시로 대체할 수 있습니다. 테스트 속도 향상: 실제 리소스 접근 없이 빠른 테스트가 가능합니다. 특징 미리 정의된 응답(canned answer)을 제공합니다. 실제 코드의 동작을 단순화하여 모사합니다. 주로 상태 테스팅에 중점을 둡니다. 메서드 호출의 결과만 정의하며, 호출 여부는 검증하지 않습니다. 사용 사례 구현되지 않은 함수나 외부 라이브러리 함수를 사용할 때 복잡한 로직을 단순화하여 테스트하고자 할 때 특정 조건에서의 예외 상황을 테스트할 때 외부 의존성(예: 데이터베이스, 네트워크 요청)을 가진 코드를 테스트할 때 예시 Python 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 from unittest.mock import Mock, patch import pytest from datetime import datetime # 테스트할 실제 클래스 class PaymentService: def __init__(self, payment_gateway): self.payment_gateway = payment_gateway def process_payment(self, amount): if amount <= 0: raise ValueError("Amount must be positive") response = self.payment_gateway.charge(amount) if response['status'] == 'success': return True return False # 외부 결제 게이트웨이 클래스 (실제로는 외부 서비스) class PaymentGateway: def charge(self, amount): # 실제로는 외부 API를 호출하는 복잡한 로직 pass # Stub 예시 class PaymentGatewayStub: def charge(self, amount): # 항상 성공 응답을 반환하는 단순한 구현 return {'status': 'success', 'timestamp': datetime.now()} # 테스트 코드 def test_payment_service_with_stub(): # Stub 사용 gateway_stub = PaymentGatewayStub() payment_service = PaymentService(gateway_stub) assert payment_service.process_payment(100) == True Javascript 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 // Jest를 사용한 테스트 예시 const { jest } = require('@jest/globals'); // 테스트할 실제 클래스 class UserService { constructor(database) { this.database = database; } async getUserById(id) { const user = await this.database.findUser(id); if (!user) { throw new Error('User not found'); } return user; } async updateUserEmail(id, newEmail) { const user = await this.database.findUser(id); if (!user) { throw new Error('User not found'); } user.email = newEmail; await this.database.updateUser(id, user); return user; } } // Stub 예시 class DatabaseStub { constructor() { this.users = new Map([ [1, { id: 1, name: 'John Doe', email: 'john@example.com' }], [2, { id: 2, name: 'Jane Doe', email: 'jane@example.com' }] ]); } async findUser(id) { return this.users.get(id); } async updateUser(id, userData) { this.users.set(id, userData); return userData; } } // 테스트 코드 describe('UserService', () => { // Stub을 사용한 테스트 describe('with stub', () => { const dbStub = new DatabaseStub(); const userService = new UserService(dbStub); test('should return user when exists', async () => { const user = await userService.getUserById(1); expect(user.name).toBe('John Doe'); }); test('should throw error when user not found', async () => { await expect(userService.getUserById(999)) .rejects .toThrow('User not found'); }); }); }); 참고 및 출처

보안 취약점 스캔 (Security Vulnerability Scanning) 시스템의 모든 진입점과 약점을 체계적으로 검사하는 과정이다. 주로 자동화된 도구를 사용하여 알려진 취약점 패턴을 검사하고, 잠재적인 보안 위험을 식별합니다. 주요 목적 잠재적인 보안 취약점 식별 데이터 유출 및 사이버 공격 위험 감소 규정 준수 요구사항 충족 전반적인 보안 태세 강화 작동 방식 대상 식별: 스캔할 시스템, 네트워크, 애플리케이션을 정의 스캔 실행: 자동화된 도구를 사용하여 취약점 검색 데이터 수집 및 분석: 발견된 취약점에 대한 정보 수집 및 분석 보고서 생성: 식별된 취약점과 심각도 수준을 포함한 상세 보고서 작성 결과 평가 및 조치: 우선순위에 따라 취약점 해결 방안 수립 주요 스캔 유형 네트워크 취약점 스캔: 방화벽, 라우터 등 네트워크 인프라의 취약점 검사 웹 애플리케이션 취약점 스캔: SQL 인젝션, XSS 등 웹 관련 취약점 탐지 데이터베이스 취약점 스캔: 데이터베이스 시스템의 보안 취약점 평가 호스트 취약점 스캔: 개별 서버나 워크스테이션의 OS 수준 취약점 검사 장점 조기 취약점 발견으로 비용 절감 자동화를 통한 효율적인 보안 관리 규정 준수 입증 용이 지속적인 보안 상태 모니터링 가능 주의사항 거짓 양성(false positive) 결과 발생 가능성 모든 취약점을 발견할 수 없음 스캔 자체가 시스템에 부하를 줄 수 있음 참고 및 출처

성능 프로파일링 (Performance Profiling) 성능 프로파일링(Performance Profiling)은 소프트웨어의 실행 동작을 분석하여 성능을 측정하고 개선하는 기술이다. 성능 프로파일링은 소프트웨어 개발 과정에서 중요한 품질 관리 활동으로, 초기 단계부터 지속적으로 수행하여 효율적이고 최적화된 소프트웨어를 개발하는 데 도움을 준다. 정의와 목적 성능 프로파일링은 소프트웨어의 실행 시 동작과 리소스 사용을 분석하는 과정이다. 주요 목적은 다음과 같다: 코드의 병목 지점 식별 리소스 사용량 분석 (CPU 시간, 메모리 사용 등) 실행 시간이 긴 함수나 코드 섹션 파악 성능 최적화를 위한 개선 지점 도출 프로파일링 단계 계획: 분석 대상과 목표 설정 데이터 수집: 실행 중 성능 데이터 수집 분석: 수집된 데이터 분석 및 병목 지점 식별 최적화: 분석 결과를 바탕으로 코드 개선 검증: 개선 효과 확인 주요 프로파일링 유형 CPU 프로파일링: 함수별 CPU 사용 시간 측정 메모리 프로파일링: 메모리 할당 및 해제 패턴 분석 I/O 프로파일링: 디스크, 네트워크 등 I/O 작업 분석 장점 코드 품질 향상 소프트웨어 효율성 증대 리소스 할당 최적화 사용자 경험 개선 확장성 향상 도구 다양한 성능 프로파일링 도구가 있으며, 대표적인 것들은 다음과 같다: ...

데스크 체크(Desk Check) 데스크 체크는 코드를 작성한 개발자가 자신의 “책상에서” 수행하는 자체 검토 활동이다. 이는 마치 작가가 원고의 초안을 검토하는 것과 유사하다. 개발자는 자신이 작성한 코드를 한 줄씩 꼼꼼히 읽어가며 논리적 오류나 잠재적 문제를 찾아낸다. 데스크 체크의 실제 적용 예시: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 // 데스크 체크 과정의 예시 public class PaymentProcessor { public boolean processPayment(double amount, String cardNumber) { // 데스크 체크 포인트 1: 입력값 검증 // - amount가 음수인 경우는 없는지? // - cardNumber가 null이거나 빈 문자열은 아닌지? if (amount <= 0 || cardNumber == null || cardNumber.isEmpty()) { return false; } // 데스크 체크 포인트 2: 카드 번호 형식 검증 // - 숫자로만 구성되어 있는지? // - 길이가 올바른지? if (!validateCardNumber(cardNumber)) { return false; } // 데스크 체크 포인트 3: 결제 처리 로직 // - 예외 처리가 적절한지? // - 트랜잭션 처리가 정확한지? try { return executePayment(amount, cardNumber); } catch (PaymentException e) { logError("Payment failed", e); return false; } } } 데스크 체크 수행 방법 체계적 검토 프로세스 개발자는 다음과 같은 순서로 코드를 검토한다: 코드 구조 검토 논리적 흐름 확인 예외 상황 고려 성능 관련 검토 코드 스타일 확인 체크리스트 활용 효과적인 데스크 체크를 위한 체크리스트 예시: 기본적인 검증 사항들 null 참조 가능성 검사 경계 조건 검사 리소스 관리 확인 보안 관련 검토 문서화 적절성 확인 데스크 체크의 장점과 효과 즉각적인 문제 발견 개발자가 코드를 작성한 직후에 검토함으로써 문제를 빠르게 발견할 수 있다: ...

워크스루(Walkthrough) 워크스루는 마치 박물관 가이드가 관람객들을 안내하듯이, 코드 작성자가 리뷰어들을 코드를 통해 “안내"하는 과정이다. 이 과정에서 코드의 의도, 구현 방식, 그리고 잠재적인 문제점들을 함께 발견하고 논의할 수 있다. 워크스루 세션의 실제 예시: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 // 워크스루 세션 중 코드 설명 예시 public class OrderProcessor { // 발표자: "주문 처리 시스템의 핵심 클래스입니다. // 주문의 유효성 검사부터 결제, 배송 처리까지 담당합니다." private final PaymentService paymentService; private final InventoryService inventoryService; private final ShippingService shippingService; public OrderResult processOrder(Order order) { // 발표자: "먼저 주문의 유효성을 검사합니다. // 여기서 중요한 것은 재고 확인입니다." if (!validateOrder(order)) { throw new InvalidOrderException("Invalid order"); } // 발표자: "재고가 확인되면 결제를 진행합니다. // 결제는 트랜잭션으로 처리됩니다." PaymentResult payment = paymentService.processPayment(order); // 리뷰어 질문: "결제 실패 시 재고는 어떻게 처리되나요?" // 발표자: "좋은 지적입니다. 결제 실패 시 재고를 원복하는 // 로직을 추가해야 할 것 같네요." if (payment.isSuccessful()) { // 발표자: "결제가 성공하면 배송 처리를 시작합니다." return createShippingOrder(order, payment); } return OrderResult.failure("Payment failed"); } } 워크스루의 주요 특징과 장점 상호작용적 학습 참가자들은 실시간으로 질문하고 토론할 수 있다: ...

코드 리뷰 (Code Review) 코드 리뷰는 개발자가 작성한 코드를 다른 개발자들이 검토하고 피드백을 제공하는 과정이다. 이는 마치 작가들이 서로의 글을 읽고 조언을 주고받는 것과 유사하다. 주된 목적은 코드의 품질을 향상시키고 팀 내의 지식 공유를 촉진하는 것이다. 코드 리뷰의 실제 적용 예시: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 // 리뷰가 필요한 코드 예시 public class UserService { public void createUser(String username, String password) { // 데이터베이스에 직접 저장 database.execute( "INSERT INTO users (username, password) VALUES ('" + username + "', '" + password + "')" ); } } // 리뷰어의 피드백 후 개선된 코드 public class UserService { /** * 새로운 사용자를 생성하고 저장합니다. * @param username 사용자 이름 * @param password 비밀번호 * @throws ValidationException 유효하지 않은 입력값 */ public void createUser(String username, String password) { // 입력값 검증 validateInput(username, password); // 비밀번호 해싱 String hashedPassword = passwordHasher.hash(password); // 준비된 구문을 사용하여 SQL 인젝션 방지 userRepository.save(new User(username, hashedPassword)); } } 주요 특징 품질 보증: 코드 리뷰는 버그를 찾아내고, 코드 품질을 향상시키며, 보안 취약점을 발견하는 데 도움을 준다. 여러 눈이 검토하므로 한 사람이 놓칠 수 있는 문제점들을 더 쉽게 발견할 수 있다. 지식 공유: 팀 멤버들이 서로의 코드를 검토하면서 자연스럽게 지식을 공유하고 학습할 수 있다. 주니어 개발자는 시니어의 피드백을 통해 성장할 수 있고, 시니어 개발자도 새로운 관점을 얻을 수 있다. 일관성 유지: 팀의 코딩 표준과 모범 사례를 준수하는지 확인함으로써, 전체 코드베이스의 일관성을 유지할 수 있다. 코드 리뷰 프로세스의 주요 단계 리뷰 준비 개발자는 리뷰를 위해 코드를 준비할 때 다음 사항들을 고려한다: ...

패스 어라운드(Pass Around) 패스 어라운드는 마치 책을 여러 사람이 돌려가며 읽는 것처럼, 코드를 여러 개발자들이 순차적으로 검토하는 방식이다. 각 리뷰어는 자신의 전문 분야나 관점에서 코드를 검토하고 피드백을 제공한다. 예를 들어, 한 개발자는 성능 관점에서, 다른 개발자는 보안 관점에서 같은 코드를 검토할 수 있다. 실제 패스 어라운드 프로세스의 예시: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 // 첫 번째 리뷰어 (성능 전문가)의 검토 public class DataProcessor { public List<Result> processData(List<Data> dataList) { // 성능 관련 코멘트: // "대용량 데이터 처리 시 메모리 문제가 발생할 수 있습니다. // 스트림을 사용하여 처리하는 것이 좋겠습니다." return dataList.stream() .filter(Data::isValid) .map(this::transform) .collect(Collectors.toList()); } } // 두 번째 리뷰어 (보안 전문가)의 검토 후 수정된 버전 public class DataProcessor { public List<Result> processData(List<Data> dataList) { // 보안 관련 코멘트: // "입력 데이터의 유효성 검증이 필요합니다. // 또한 처리 과정에서의 로깅이 필요합니다." if (dataList == null) { throw new IllegalArgumentException("Data list cannot be null"); } logger.info("Starting data processing for {} items", dataList.size()); return dataList.stream() .filter(this::validateData) .map(this::transform) .collect(Collectors.toList()); } } // 세 번째 리뷰어 (테스트 전문가)의 검토 후 추가된 테스트 코드 @Test public class DataProcessorTest { // 테스트 관련 코멘트: // "경계 조건과 예외 상황에 대한 테스트가 필요합니다." @Test void testProcessDataWithNullInput() { assertThrows(IllegalArgumentException.class, () -> processor.processData(null)); } @Test void testProcessDataWithEmptyList() { assertTrue(processor.processData(Collections.emptyList()).isEmpty()); } } 프로세스 코드 작성자가 리뷰 대상 코드를 공유 참여자들이 개별적으로 코드 검토 각자의 의견을 메일이나 시스템에 기록 코드 작성자가 피드백을 수집하고 필요한 수정 진행 패스 어라운드의 장점과 효과 다양한 관점에서의 검토 여러 전문가의 시각으로 코드를 검토할 수 있다: ...

감사(Audit) 독립적인 검토자들이 소프트웨어 산출물과 프로세스를 체계적으로 검사하고 평가하는 공식적인 검토 과정이다. 이는 마치 회계 감사와 유사하게, 객관적인 기준에 따라 철저하게 검증하는 과정이다. 외부 또는 독립적인 감사자에 의해 수행되며, 주로 규정 준수와 품질 표준 충족 여부를 확인하는 데 중점을 둔다. Audit의 주요 특징 공식성과 체계성 Audit은 가장 공식적인 검토 형태. 모든 과정이 문서화되며, 정해진 절차와 체크리스트에 따라 진행된다. 예를 들어: 1 2 3 4 5 6 7 8 Audit 계획서 1. 검토 범위: 사용자 인증 모듈 전체 2. 검토 일정: 2024.01.15 - 2024.01.19 3. 참여자 역할: - 주검토자: 김철수 (보안팀) - 부검토자: 이영희 (품질관리팀) - 기술지원: 박지민 (개발팀) 4. 검토 기준: ISO/IEC 27001 보안 표준 독립성 Audit을 수행하는 검토자들은 해당 프로젝트나 코드 개발에 직접 참여하지 않은 독립적인 인원들로 구성된다. 이는 객관적인 평가를 보장하기 위함이다. ...

페어 프로그래밍(Pair Programming) 페어 프로그래밍에서는 두 명의 개발자가 서로 다른 역할을 맡는다. ‘드라이버(Driver)‘는 실제로 코드를 작성하는 사람이고, ‘네비게이터(Navigator)‘는 코드를 검토하고 방향을 제시하는 사람이다. 이 두 역할은 주기적으로 교대한다. 실제 페어 프로그래밍 예시: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 // 페어 프로그래밍 세션 예시 // Driver가 코드를 작성하고, Navigator가 실시간으로 리뷰와 제안을 합니다 // Navigator: "사용자 등록 기능을 구현해볼까요? 먼저 입력값 검증부터 시작하는게 좋겠어요." // Driver: "네, 동의합니다. 사용자 이름과 이메일 유효성을 체크하는 메서드부터 작성할게요." public class UserRegistration { public boolean registerUser(String username, String email) { // Navigator: "null 체크도 필요할 것 같네요." // Driver: "네, 좋은 지적입니다. 추가하겠습니다." if (username == null || email == null) { return false; } // Navigator: "이메일 형식 검증도 필요할 것 같아요." // Driver: "이메일 정규식을 사용해서 검증하면 좋겠네요." if (!validateEmailFormat(email)) { return false; } // Navigator: "사용자 이름 길이 제한도 있어야 할 것 같아요." // Driver: "네, 최소 3자, 최대 20자로 제한하겠습니다." if (username.length() < 3 || username.length() > 20) { return false; } // 실제 등록 로직 구현… return saveUser(username, email); } } 페어 프로그래밍의 주요 이점 실시간 코드 리뷰 두 명이 함께 작업하면서 즉각적인 피드백이 가능하다: ...