database testing complete guide why
실용적인 팁과 예제가 포함 된 데이터베이스 테스트에 대한 완전한 가이드 :
요즘 컴퓨터 응용 프로그램은 Android와 같은 기술과 많은 스마트 폰 응용 프로그램으로 인해 더 복잡합니다. 프런트 엔드가 복잡할수록 백 엔드가 더 복잡해집니다.
따라서 보안 및 품질 데이터베이스를 보장하기 위해 DB 테스트에 대해 배우고 데이터베이스를 효과적으로 검증 할 수있는 것이 더욱 중요합니다.
이 튜토리얼에서는 데이터 테스트에 대한 모든 것을 배우게 될 것입니다. 왜, 어떻게, 무엇을 테스트해야합니까?
데이터베이스는 소프트웨어 애플리케이션의 불가피한 부분 중 하나입니다.
웹, 데스크톱 또는 모바일, 클라이언트-서버, 피어-투-피어, 엔터프라이즈 또는 개인 비즈니스인지 여부는 중요하지 않습니다. 데이터베이스는 백엔드의 모든 곳에서 필요합니다.
마찬가지로, 의료, 금융, 임대, 소매, 우편 신청 또는 우주선 제어 여부에 관계없이 데이터베이스는 항상 무대 뒤에서 작동합니다.
애플리케이션의 복잡성이 증가함에 따라 더 강력하고 안전한 데이터베이스에 대한 필요성이 대두됩니다. 같은 방식으로 트랜잭션 빈도가 높은 애플리케이션 ( 예를 들어, 은행 또는 금융 응용 프로그램), 완전한 기능을 갖춘 DB 도구의 필요성이 결합됩니다.
요즘에는 기존 데이터베이스로는 처리 할 수없는 크고 복잡한 빅 데이터가 있습니다.
몇 가지가 있습니다 데이터베이스 도구 시장에서 구할 수 있습니다 예를 들어, MS-Access, MS SQL Server, SQL Server, Oracle, Oracle Financial, MySQL, PostgreSQL, DB2, Toad, Admirer 등 이러한 도구는 비용, 견고성, 기능 및 보안면에서 다양합니다. 이들 각각 장점과 단점이 있습니다.
학습 내용 :
데이터베이스를 테스트하는 이유
아래에서 DB의 다음 측면을 검증해야하는 이유를 살펴 보겠습니다.
# 1) 데이터 매핑
소프트웨어 시스템에서 데이터는 종종 UI (사용자 인터페이스)에서 백엔드 DB로 또는 그 반대로 이동합니다. 따라서 몇 가지주의해야 할 사항이 있습니다.
- UI / 프런트 엔드 양식의 필드가 DB 테이블의 해당 필드와 일관되게 매핑되는지 확인합니다. 일반적으로이 매핑 정보는 요구 사항 문서에 정의되어 있습니다.
- 애플리케이션의 프런트 엔드에서 특정 작업이 수행 될 때마다 해당하는 CRUD (생성, 검색, 업데이트 및 삭제) 작업이 백엔드에서 호출됩니다. 테스터는 올바른 작업이 호출되었는지 그리고 호출 된 작업 자체가 성공했는지 여부를 확인해야합니다.
# 2) ACID 속성 검증
원 자성, 일관성, 격리 및 내구성. DB가 수행하는 모든 트랜잭션은이 네 가지 속성을 준수해야합니다.
- 원 자성 트랜잭션이 실패하거나 통과 함을 의미합니다. 이는 트랜잭션의 한 부분이 실패하더라도 전체 트랜잭션이 실패했음을 의미합니다. 일반적으로이를 '전부 또는 전무'규칙이라고합니다.
- 일관성 : 트랜잭션은 항상 DB의 유효한 상태가됩니다.
- 격리 : 트랜잭션이 여러 개 있고 한꺼번에 실행되는 경우 DB의 결과 / 상태는 차례로 실행 된 것과 같아야합니다.
- 내구성 : 트랜잭션이 완료되고 커밋되면 정전이나 충돌과 같은 외부 요인이이를 변경할 수 없어야합니다.
추천 읽기 = >> MySQL 트랜잭션 튜토리얼
# 3) 데이터 무결성
모든 CRUD 작업 , 공유 데이터의 업데이트 된 최신 값 / 상태가 모든 양식과 화면에 표시되어야합니다. 한 화면에서 값을 업데이트하지 않고 다른 화면에 이전 값을 표시하면 안됩니다.
응용 프로그램이 실행 중일 때 최종 사용자는 주로 DB Tool이 제공하는 'CRUD'작업을 활용합니다. .
C : 생성 – 사용자가 새로운 트랜잭션을 '저장'하면 '만들기'작업이 수행됩니다.
R : 검색 – 사용자가 저장된 트랜잭션을‘검색’또는‘보기’하면‘검색’작업이 수행됩니다.
U : 업데이트 – 사용자가 기존 레코드를‘수정’또는‘수정’하면 DB의‘업데이트’작업이 수행됩니다.
D : 삭제 – 사용자가 시스템에서 임의의 레코드를 '삭제'하면 DB의 '삭제'작업이 수행됩니다.
최종 사용자가 수행하는 모든 데이터베이스 작업은 항상 위의 4 개 중 하나입니다.
따라서 데이터가 지속적으로 동일한 지 확인하는 것처럼 보이는 모든 위치에서 데이터를 확인하는 방식으로 DB 테스트 케이스를 고안하십시오.
# 4) 비즈니스 규칙 준수
데이터베이스의 복잡성은 관계형 제약, 트리거, 저장 프로 시저 등과 같은 더 복잡한 구성 요소를 의미합니다. 따라서 테스터는 이러한 복잡한 개체의 유효성을 검사하기 위해 적절한 SQL 쿼리를 만들어야합니다.
테스트 대상 (데이터베이스 테스트 검사 목록)
# 1) 거래
트랜잭션을 테스트 할 때 ACID 속성을 충족하는지 확인하는 것이 중요합니다.
다음은 일반적으로 사용되는 문장입니다.
- 거래 시작 거래 #
- 거래 종료 #
Rollback 문은 데이터베이스가 일관된 상태로 유지되도록합니다.
- 롤백 거래 #
이러한 명령문을 실행 한 후 Select를 사용하여 변경 사항이 반영되었는지 확인합니다.
- TABLENAME에서 * 선택
# 2) 데이터베이스 스키마
데이터베이스 스키마는 데이터가 DB 내에서 구성되는 방식에 대한 공식적인 정의에 지나지 않습니다. 테스트하려면 :
- 데이터베이스가 작동하는 요구 사항을 식별합니다. 샘플 요구 사항 :
- 다른 필드를 생성하기 전에 생성 할 기본 키입니다.
- 쉽게 검색하고 검색하려면 외래 키를 완전히 인덱싱해야합니다.
- 특정 문자로 시작하거나 끝나는 필드 이름.
- 특정 값을 삽입 할 수 있거나 삽입 할 수없는 제약 조건이있는 필드입니다.
- 관련성에 따라 다음 방법 중 하나를 사용하십시오.
- SQL 쿼리 DESC
스키마의 유효성을 검사합니다.
- 개별 필드의 이름과 해당 값을 확인하기위한 정규식
- SchemaCrawler와 같은 도구
# 3) 트리거
특정 테이블에서 특정 이벤트가 발생하면 코드 조각 (트리거)이 자동으로 실행되도록 지시 할 수 있습니다.
예를 들어, 새로운 학생이 학교에 합류했습니다. 학생은 수학과 과학의 두 수업을 듣고 있습니다. 학생이 '학생 테이블'에 추가됩니다. 트리거는 학생이 학생 테이블에 추가되면 해당 주제 테이블에 학생을 추가 할 수 있습니다.
일반적인 테스트 방법은 먼저 Trigger에 포함 된 SQL 쿼리를 독립적으로 실행하고 결과를 기록하는 것입니다. 트리거를 전체적으로 실행하여이 작업을 수행하십시오. 결과를 비교하십시오.
이들은 블랙 박스 및 화이트 박스 테스트 단계 모두에서 테스트됩니다.
소프트웨어 개발 수명주기 테스트 단계
- 화이트 박스 테스트 : 스텁 및 드라이버는 트리거가 호출되는 데이터를 삽입, 업데이트 또는 삭제하는 데 사용됩니다. 기본 아이디어는 프런트 엔드 (UI)와의 통합이 이루어지기 전에 DB 만 테스트하는 것입니다.
- 블랙 박스 테스트 :
에) UI 및 DB 이후 통합이 가능합니다. 트리거가 호출되는 방식으로 프런트 엔드에서 데이터를 삽입 / 삭제 / 업데이트 할 수 있습니다. 그런 다음 Select 문을 사용하여 DB 데이터를 검색하여 트리거가 의도 한 작업을 성공적으로 수행했는지 확인할 수 있습니다.
비) 이를 테스트하는 두 번째 방법은 트리거를 호출하는 데이터를 직접로드하고 의도 한대로 작동하는지 확인하는 것입니다.
# 4) 저장 프로 시저
저장 프로시 저는 사용자 정의 함수와 다소 유사합니다. 이는 Call Procedure / Execute Procedure 문에 의해 호출 될 수 있으며 출력은 일반적으로 결과 집합의 형식입니다.
이들은 RDBMS에 저장되며 응용 프로그램에서 사용할 수 있습니다.
또한 다음 기간 동안 테스트됩니다.
- 화이트 박스 테스트 : 스텁을 사용하여 저장 프로 시저를 호출 한 다음 예상 값에 대해 결과의 유효성을 검사합니다.
- 블랙 박스 테스트 : 응용 프로그램의 UI (프런트 엔드)에서 작업을 수행하고 저장 프로 시저의 실행과 그 결과를 확인합니다.
# 5) 필드 제약
기본값, 고유 값 및 외래 키 :
- 데이터베이스 개체 조건을 실행하는 프런트 엔드 작업을 수행합니다.
- SQL 쿼리로 결과를 검증합니다.
특정 필드의 기본값을 확인하는 것은 매우 간단합니다. 비즈니스 규칙 유효성 검사의 일부입니다. 수동으로 수행하거나 QTP와 같은 도구를 사용할 수 있습니다. 수동으로 프런트 엔드에서 필드의 기본값이 아닌 값을 추가하는 작업을 수행하고 오류가 발생하는지 확인할 수 있습니다.
다음은 샘플 VBScript 코드입니다.
Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match) 위 코드의 결과는 기본값이 존재하면 True이고 그렇지 않으면 False입니다.
고유 값을 확인하는 것은 기본값에 대해했던 방식과 똑같이 수행 할 수 있습니다. 이 규칙을 위반할 UI 값을 입력하고 오류가 표시되는지 확인하십시오.
자동화 VB 스크립트 코드는 다음과 같습니다.
Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match) 에 대한외래 키제약 조건 유효성 검사는 제약 조건을 위반하는 데이터를 직접 입력하고 응용 프로그램이이를 제한하는지 여부를 확인하는 데이터로드를 사용합니다. 백 엔드 데이터로드와 함께 제약 조건을 위반하는 방식으로 프런트 엔드 UI 작업을 수행하고 관련 오류가 표시되는지 확인합니다.
데이터 테스트 활동
데이터베이스 테스터는 다음 테스트 활동에 집중해야합니다.
# 1) 데이터 매핑 보장 :
데이터 매핑은 데이터베이스의 주요 측면 중 하나이며 모든 소프트웨어 테스터가 엄격하게 테스트해야합니다.
AUT와 해당 DB의 서로 다른 형식 또는 화면 간의 매핑이 정확할뿐만 아니라 설계 문서 (SRS / BRS) 또는 코드에 따라 일치하는지 확인하십시오. 기본적으로 모든 프런트 엔드 필드와 해당 백엔드 데이터베이스 필드 간의 매핑을 확인해야합니다.
모든 CRUD 작업에 대해 사용자가 애플리케이션의 GUI에서 '저장', '업데이트', '검색'또는 '삭제'를 클릭하면 각 테이블과 레코드가 업데이트되는지 확인합니다.
확인해야 할 사항 :
- 테이블 매핑, 열 매핑 및 데이터 형식 매핑.
- 조회 데이터 매핑.
- UI의 모든 사용자 작업에 대해 올바른 CRUD 작업이 호출됩니다.
- CRUD 작업이 성공했습니다.
# 2) 트랜잭션의 ACID 속성 확인 :
DB 트랜잭션의 ACID 속성은‘ 에 tomicity ',‘ 씨 지속성 ',‘ 나는 솔 레이션 '및‘ 디 urability '. 이 네 가지 속성에 대한 적절한 테스트는 데이터베이스 테스트 활동 중에 수행되어야합니다. 모든 단일 트랜잭션이 데이터베이스의 ACID 속성을 충족하는지 확인해야합니다.
아래 SQL 코드를 통해 간단한 예를 들어 보겠습니다.
CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));ACID 테스트 테이블에는 A와 B라는 두 개의 열이 있습니다. A와 B의 값 합계가 항상 100이어야한다는 무결성 제약 조건이 있습니다.
원 자성 테스트 이 테이블에서 수행 된 모든 트랜잭션이 모두 또는 전혀 없는지 확인합니다. 즉, 트랜잭션 단계가 실패하면 레코드가 업데이트되지 않습니다.
일관성 테스트 열 A 또는 B의 값이 업데이트 될 때마다 합계는 항상 100으로 유지됩니다. 합계가 100이 아닌 경우 A 또는 B에서 삽입 / 삭제 / 업데이트를 허용하지 않습니다.
격리 테스트 두 개의 트랜잭션이 동시에 발생하고 ACID 테스트 테이블의 데이터를 수정하려는 경우 이러한 트랙션이 격리되어 실행되도록합니다.
내구성 테스트 이 테이블에 대한 트랜잭션이 일단 커밋되면 정전, 충돌 또는 오류가 발생하더라도 트랜잭션이 그대로 유지되도록합니다.
이 영역에서는 응용 프로그램이 분산 데이터베이스를 사용하는 경우보다 엄격하고 철저하며 예리한 테스트가 필요합니다.
# 3) 데이터 무결성 보장
애플리케이션의 서로 다른 모듈 (예 : 화면 또는 양식)이 서로 다른 방식으로 동일한 데이터를 사용하고 데이터에 대한 모든 CRUD 작업을 수행한다는 점을 고려하십시오.
이 경우 최신 데이터 상태가 모든 곳에 반영되는지 확인하십시오. 시스템은 모든 양식 및 화면에 업데이트 된 최신 값 또는 이러한 공유 데이터의 상태를 표시해야합니다. 이를 데이터 무결성이라고합니다.
데이터베이스 데이터 무결성 검증을위한 테스트 사례 :
- 참조 테이블 레코드를 업데이트하기 위해 모든 트리거가 제자리에 있는지 확인하십시오.
- 각 테이블의 주요 열에 부정확하거나 잘못된 데이터가 있는지 확인하십시오.
- 테이블에 잘못된 데이터를 삽입하고 실패가 발생하는지 관찰하십시오.
- 부모를 삽입하기 전에 자식을 삽입하려고하면 어떻게되는지 확인하십시오 (기본 및 외래 키로 재생 해보십시오).
- 다른 테이블의 데이터에서 여전히 참조하는 레코드를 삭제하는 경우 오류가 발생하는지 테스트합니다.
- 복제 된 서버와 데이터베이스가 동기화되어 있는지 확인합니다.
# 4) 구현 된 비즈니스 규칙의 정확성 보장 :
오늘날 데이터베이스는 레코드 저장만을 의미하지 않습니다. 사실 데이터베이스는 DB 수준에서 비즈니스 로직을 구현하기 위해 개발자에게 충분한 지원을 제공하는 매우 강력한 도구로 발전했습니다.
강력한 기능의 몇 가지 간단한 예로는 '참조 무결성', 관계형 제약 조건, 트리거 및 저장 프로 시저가 있습니다.
따라서 개발자는 DB에서 제공하는 이러한 기능과 기타 많은 기능을 사용하여 DB 수준에서 비즈니스 로직을 구현합니다. 테스터는 구현 된 비즈니스 로직이 정확하고 정확하게 작동하는지 확인해야합니다.
위의 요점은 DB 테스팅의 가장 중요한 네 가지 'What To'를 설명합니다. 이제‘방법’부분으로 넘어가겠습니다.
데이터베이스 테스트 방법 (단계별 프로세스)
일반 테스트 프로세스 테스트 데이터베이스는 다른 응용 프로그램과 크게 다르지 않습니다.
다음은 핵심 단계입니다.
1 단계) 환경 준비
2 단계) 테스트 실행
3 단계) 테스트 결과 확인
4 단계) 예상 결과에 따라 검증
5 단계) 결과를 각 이해 관계자에게보고하십시오.
일반적으로 SQL 쿼리는 테스트를 개발하는 데 사용됩니다. 가장 일반적으로 사용되는 명령은 '선택'입니다.
어디에서 * 선택
Select 외에도 SQL에는 세 가지 중요한 명령 유형이 있습니다.
- DDL : 데이터 정의 언어
- DML : 데이터 조작 언어
- DCL : 데이터 제어 언어
가장 일반적으로 사용되는 문에 대한 구문을 살펴 보겠습니다.
데이터 정의 언어 CREATE, ALTER, RENAME, DROP 및 TRUNCATE를 사용하여 테이블 (및 인덱스)을 처리합니다.
데이터 조작 언어 레코드를 추가, 업데이트 및 삭제하는 명령문을 포함합니다.
데이터 제어 언어 : 사용자에게 데이터 조작 및 액세스 권한 부여를 처리합니다. Grant와 Revoke는 사용되는 두 가지 문입니다.
그랜트 구문 :
선택 / 업데이트 권한 부여
의 위에
에;취소 구문 :
취소 선택 / 업데이트
의 위에
에서;몇 가지 실용적인 팁
# 1) 직접 쿼리 작성 :
데이터베이스를 정확하게 테스트하려면 테스터는 SQL 및 DML (Data Manipulation Language) 문에 대해 잘 알고 있어야합니다. 테스터는 AUT의 내부 DB 구조도 알아야합니다.
더 나은 적용 범위를 위해 각 테이블에서 GUI와 데이터 검증을 결합 할 수 있습니다. SQL 서버를 사용하는 경우 쿼리 작성, 실행 및 결과 검색에 SQL 쿼리 분석기를 사용할 수 있습니다.
이것은 응용 프로그램의 복잡성이 중소 수준 일 때 데이터베이스를 테스트하는 가장 좋고 강력한 방법입니다.
애플리케이션이 매우 복잡한 경우 테스터가 필요한 모든 SQL 쿼리를 작성하는 것이 어렵거나 불가능할 수 있습니다. 복잡한 쿼리의 경우 개발자의 도움을받습니다. 이 방법은 테스트에 대한 자신감을 제공하고 SQL 기술을 향상시키기 때문에 항상 권장합니다.
# 2) 각 테이블의 데이터를 관찰하십시오.
CRUD 작업 결과를 사용하여 데이터 검증을 수행 할 수 있습니다. 데이터베이스 통합을 알고있는 경우 애플리케이션 UI를 사용하여 수동으로 수행 할 수 있습니다. 그러나 이것은 다른 데이터베이스 테이블에 방대한 데이터가있을 때 지루하고 성가신 작업이 될 수 있습니다.
수동 데이터 테스트의 경우 데이터베이스 테스터는 데이터베이스 테이블 구조에 대한 충분한 지식을 가지고 있어야합니다.
# 3) 개발자로부터 쿼리 받기 :
이것은 데이터베이스를 테스트하는 가장 간단한 방법입니다. GUI에서 CRUD 작업을 수행하고 개발자로부터 얻은 각 SQL 쿼리를 실행하여 그 영향을 확인합니다. SQL에 대한 지식이 필요하지 않으며 애플리케이션의 DB 구조에 대한 지식도 필요하지 않습니다.
그러나이 방법은 신중하게 사용해야합니다. 개발자가 제공 한 쿼리가 의미 상 잘못되었거나 사용자의 요구 사항을 올바르게 충족하지 못하면 어떻게됩니까? 이 프로세스는 단순히 데이터 유효성 검사에 실패합니다.
# 4) 데이터베이스 자동화 테스트 도구 사용 :
데이터 테스트 프로세스에 사용할 수있는 여러 도구가 있습니다. 필요에 따라 올바른 도구를 선택하고 최대한 활용해야합니다.
=> 확인해야 할 TOP DB 테스트 도구 목록은 다음과 같습니다.
결론
데이터베이스에서 테스트 할 이러한 모든 기능, 요소 및 프로세스로 인해 테스터가 주요 데이터베이스 개념에 기술적으로 능숙해야한다는 요구가 증가하고 있습니다. 데이터베이스 테스트가 새로운 병목 현상을 일으키고 많은 추가 비용이 든다는 부정적인 믿음에도 불구하고 이것은 상당한 관심과 요구를 받고있는 테스트 영역입니다.
추천 읽기 = >> 데이터베이스 보안 테스트 란?
이 튜토리얼이 그 이유에 초점을 맞추는 데 도움이 되었기를 바라며 데이터베이스 테스트에 대한 기본 세부 사항도 제공했으면합니다.
여러분의 피드백을 알려 주시고 DB 테스팅을하고 계시다면 개인적인 경험을 공유해주세요.
추천 도서
- JMeter를 사용한 데이터베이스 테스트
- 40 개 이상의 최고의 데이터베이스 테스트 도구-인기있는 데이터 테스트 솔루션
- XML에서 데이터베이스 테스트에 대한 간단한 접근 방식
- ETL 테스트 데이터웨어 하우스 테스트 자습서 (전체 가이드)
- 데이터 마이그레이션 테스트 자습서 : 완전한 가이드
- 복잡한 데이터 모델을 구축하기위한 10 가지 데이터베이스 설계 도구
- 예제가 포함 된 데이터웨어 하우스 테스트 자습서 | ETL 테스트 가이드
- Oracle 데이터베이스를 테스트하는 방법
^
- SQL 쿼리 DESC
