데이터베이스 테스트-빠른 가이드

데이터베이스 테스트에는 데이터 유효성, 데이터 무결성 테스트, 데이터베이스와 관련된 성능 검사 및 데이터베이스의 절차, 트리거 및 기능 테스트가 포함됩니다.

예

사용자의 일상적인 트랜잭션 세부 정보를 캡처하고 세부 정보를 데이터베이스에 저장하는 애플리케이션을 고려하십시오. 데이터베이스 테스트 관점에서 다음과 같은 검사를 수행해야합니다.

• 애플리케이션의 트랜잭션 정보는 데이터베이스에 저장되어야하며 사용자에게 올바른 정보를 제공해야합니다.

• 정보가 데이터베이스에로드 될 때 손실되지 않아야합니다.

• 완료된 트랜잭션 만 저장해야하며 모든 불완전한 작업은 애플리케이션에서 중단해야합니다.

• 데이터베이스에 대한 액세스 권한이 유지되어야합니다. 사용자 정보에 대한 무단 또는 무단 액세스를 제공해서는 안됩니다.

데이터베이스 테스트를 수행해야하는 이유

데이터베이스 테스트가 수행되는 이유는 여러 가지가 있습니다. 백엔드 시스템은 데이터를 저장하고 다목적으로 액세스하므로 데이터베이스에서 데이터 무결성, 유효성 검사 및 데이터 일관성 검사를 수행해야합니다.

다음은 데이터베이스 테스트에 대한 몇 가지 일반적인 이유입니다.

• 데이터베이스 백엔드 호출의 복잡성을 완화하기 위해 개발자는 View 과 Stored 절차.

• 이들 Stored 절차 및 Views고객 세부 정보 (이름, 연락처 정보 등) 및 판매 데이터 삽입과 같은 중요한 작업이 포함됩니다. 이러한 작업은 여러 수준에서 테스트해야합니다.

• Black-box testing프런트 엔드에서 수행하는 것이 중요하지만 문제를 격리하기 어렵습니다. 백엔드 시스템에서 테스트하면 데이터의 견고성이 향상됩니다. 이것이 데이터베이스 테스트가 백엔드 시스템에서 수행되는 이유입니다.

• 데이터베이스에서 데이터는 여러 응용 프로그램에서 가져 오며 유해하거나 잘못된 데이터가 데이터베이스에 저장 될 가능성이 있습니다. 따라서 정기적으로 데이터베이스 구성 요소를 확인해야합니다. 또한 데이터 무결성과 일관성을 정기적으로 확인해야합니다.

데이터베이스 테스트 대 프런트 엔드 테스트

데이터베이스 테스트는 프런트 엔드 UI 테스트와 다릅니다. 다음 표는 주요 차이점을 강조합니다.

데이터베이스의 기능과 구조에 따라 DB 테스트는 세 가지 범주로 나눌 수 있습니다.

• Structural Database Testing − 테이블 및 열 테스트, 스키마 테스트, 저장 프로 시저 및 뷰 테스트, 트리거 확인 등을 다룹니다.

• Functional Testing− 사용자 관점에서 데이터베이스의 기능을 확인하는 작업입니다. 가장 일반적인 유형의 기능 테스트는 화이트 박스 및 블랙 박스 테스트입니다.

• Nonfunctional Testing − 여기에는 부하 테스트, 데이터베이스의 위험 테스트, 스트레스 테스트, 최소 시스템 요구 사항 및 데이터베이스 성능 처리가 포함됩니다.

구조적 데이터베이스 테스트

구조적 데이터베이스 테스트에는 최종 사용자에게 노출되지 않는 데이터베이스 구성 요소 확인이 포함됩니다. 여기에는 데이터를 저장하는 데 사용되며 최종 사용자가 변경하지 않는 저장소의 모든 구성 요소가 포함됩니다. SQL 저장 프로 시저 및 기타 개념에 대한 좋은 명령을 가진 데이터베이스 관리자는 일반적으로이 테스트를 수행합니다.

논의는 구조 테스트와 관련하여 테스트 된 일반적인 구성 요소입니다-

스키마 / 매핑 테스트

데이터베이스 개체 매핑을 사용하여 프런트 엔드 응용 프로그램의 개체를 확인하는 작업이 포함됩니다.

스키마 테스트에서-

• 최종 사용자 응용 프로그램 개체가 올바르게 매핑되지 않거나 데이터베이스 개체와 호환되지 않는 경우가 있습니다. 따라서 데이터베이스와 관련된 다양한 스키마 형식의 유효성 검사가 필요합니다.

• 테이블, 뷰, 열 등과 같이 데이터베이스에서 매핑되지 않은 개체를 찾아야합니다.

스키마에서 개체 매핑을 수행하는 데 사용할 수있는 다양한 도구가 시장에 있습니다.

Example − Microsoft SQL Server에서 테스터는 데이터베이스의 스키마를 확인하고 유효성을 검사하는 간단한 쿼리를 작성할 수 있습니다.

테스터가 테이블 구조를 변경하려는 경우 모든 stored 해당 테이블이있는 프로시 저는이 변경 사항과 호환됩니다.

저장 프로 시저 및보기 테스트

이 테스트에서 테스터는 저장 프로 시저 및 뷰의 수동 실행이 필요한 결과를 생성하는지 확인합니다.

테스터는-

• 필요한 트리거가 예상대로 실행되도록하는 경우.

• 개발 팀이 절차의 애플리케이션에 입력을 전달하여 모든 루프와 조건을 다룬 경우.

• 데이터베이스에 사용되지 않은 저장 프로 시저가있는 경우

• TRIM 작업은 데이터베이스의 필수 테이블에서 데이터를 가져올 때 제대로 적용됩니다.

• 테스트중인 애플리케이션의 요구 사항에 따라 스토어드 프로 시저 모듈의 전체 통합 유효성 검증.

• 예외 및 오류 처리 메커니즘을 따릅니다.

저장 프로 시저 테스트를 수행하는 데 사용되는 가장 일반적인 도구는 다음과 같습니다. LINQ, SP Test tool등

트리거 테스트

트리거 테스트에서 테스터는 다음 사항을 확인해야합니다.

• 트리거의 코딩 단계에서 코딩 규칙을 따르는 지 여부.

• 실행 된 트리거가 필수 조건을 충족하는지 확인하십시오.

• 트리거가 실행 된 후 데이터를 올바르게 업데이트하는지 여부.

• 업데이트 / 삽입 / 삭제의 유효성 검사는 테스트중인 애플리케이션의 기능을 트리거합니다.

테이블 및 컬럼 테스트

이 테스트에서 다루는 주요 영역은 다음과 같습니다.

• 데이터베이스의 데이터 유형을 프런트 엔드 애플리케이션의 필드 값에 대한 유효성 검사.

• 데이터베이스의 데이터 필드 길이를 애플리케이션의 데이터 유형 길이로 검증합니다.

• 응용 프로그램 필드 개체의 데이터베이스에 매핑되지 않은 테이블이나 열이 있는지 확인합니다.

• 데이터베이스 테이블 및 열의 명명 규칙은 비즈니스 요구 사항에 부합하는지 여부를 확인합니다.

• 데이터베이스의 키 및 인덱스 유효성 검사, 즉 테이블의 기본 및 외래 키는 요구 사항에 따라 정의됩니다.

• 기본 키와 해당 외래 키가 두 테이블에서 동일한 지 확인하십시오.

• 키의 Unique 및 NOT NULL 특성이 유지되는지 확인하십시오.

• 키와 인덱스의 길이와 데이터 유형은 요구 사항에 따라 유지됩니다.

데이터베이스 서버 확인

데이터베이스 서버 검사는 확인을 포함합니다-

• 데이터베이스 서버가 비즈니스 요구 사항에 따라 예상되는 트랜잭션 수를 처리 할 수 ​​있는지 여부.

• 데이터베이스 서버의 구성 세부 사항이 비즈니스 요구 사항을 충족하는 경우.

• 사용자 권한이 요구 사항에 따라 유지되는 경우.

기능 테스트

기능 테스트는 최종 사용자의 관점을 염두에두고 수행됩니다. 최종 사용자가 실행하는 필수 트랜잭션 및 작업이 비즈니스 사양을 충족하는지 여부.

블랙 박스 테스트

블랙 박스 테스트는 기능을 확인하기 위해 데이터베이스 통합을 확인하는 작업을 포함합니다. 테스트 케이스는 간단하며 함수에서 들어오는 데이터와 나가는 데이터를 확인하는 데 사용됩니다.

원인-효과 그래프 기법, 등가 분할 및 경계 값 분석과 같은 다양한 기법을 사용하여 데이터베이스의 기능을 테스트합니다.

이것의 advantages 다음과 같습니다-

• 매우 간단하며 개발 초기 단계에서 수행됩니다.
• 테스트 케이스 개발 비용은 화이트 박스 테스트에 비해 저렴합니다.

단점은 다음과 같습니다-

• 몇 가지 오류를 감지 할 수 없습니다.
• 얼마나 많은 프로그램을 테스트해야하는지 알 수 없습니다.

화이트 박스 테스트

White Box Testing은 데이터베이스의 내부 구조를 다루며 사양 세부 사항은 사용자에게 숨겨집니다. 여기에는 데이터베이스 리팩토링을 지원할 데이터베이스 트리거 및 논리적 뷰 테스트가 포함됩니다.

데이터베이스 기능, 트리거, 뷰, SQL 쿼리 등의 모듈 테스트를 수행합니다. 이러한 유형의 테스트는 데이터베이스 테이블, 데이터 모델, 데이터베이스 스키마 등의 유효성을 검사합니다. 참조 무결성 규칙을 확인합니다. 데이터베이스 일관성을 확인하기 위해 기본 테이블 값을 선택합니다.

화이트 박스 테스트를 수행하는 데 사용되는 가장 일반적인 기술은 조건 범위, 의사 결정 범위, 진술 범위 등입니다.

화이트 박스 테스트에서 코딩 오류를 감지 할 수 있으므로 데이터베이스의 내부 버그를 제거 할 수 있습니다. 화이트 박스 테스트의 한계는 SQL 문이 적용되지 않는다는 것입니다.

비 기능 테스트

비 기능적 테스트에는 부하 테스트, 스트레스 테스트, 비즈니스 사양을 충족하기위한 최소 시스템 요구 사항 확인, 위험 찾기 및 데이터베이스 성능 최적화가 포함됩니다.

부하 테스트

로드 테스트의 기본 목표는 실행중인 대부분의 트랜잭션이 데이터베이스 성능에 영향을 미치는지 확인하는 것입니다.

부하 테스트에서 테스터는 다음 사항을 확인합니다.

• 여러 원격 사용자에 대한 트랜잭션 실행에 대한 응답 시간입니다.
• 데이터베이스에서 특정 레코드를 가져 오는 데 걸린 시간입니다.

Examples of load testing in different testing types −

• 가장 많이 사용되는 트랜잭션을 반복적으로 실행하여 데이터베이스 시스템의 성능을 확인합니다.
• 인터넷에서 일련의 대용량 파일을 다운로드합니다.
• 컴퓨터 또는 서버에서 동시에 여러 응용 프로그램을 실행합니다.

스트레스 테스트

시스템 중단 점을 식별하기 위해 스트레스 테스트가 수행됩니다. 이 테스트에서는 시스템이 한 지점에서 실패하는 방식으로 애플리케이션이로드됩니다. 이 점을breakpoint 데이터베이스 시스템의.

데이터베이스 트랜잭션의 상태를 확인하려면 상당한 노력이 필요합니다. 시간 및 비용 기반 문제를 방지하려면 적절한 계획이 필요합니다.

가장 일반적으로 사용되는 스트레스 테스트 도구는 다음과 같습니다. LoadRunner 과 WinRunner.

우리가 example스트레스 테스트. CRM 응용 프로그램은 최대 50000 명의 동시 사용자를 수용 할 수 있습니다. 로드를 51000으로 늘리고 레코드 업데이트 또는 항목 추가와 같은 일부 트랜잭션을 수행한다고 가정하십시오. 트랜잭션을 수행하자마자 애플리케이션이 데이터베이스 시스템과 동기화 될 수 있습니다. 따라서 다음 테스트는 52000의 사용자 부하로 수행하는 것입니다. 때로는 스트레스 테스트라고도합니다.Fatigue Testing.

데이터베이스 테스트를 수행하는 프로세스는 다른 응용 프로그램의 테스트와 유사합니다. DB 테스트는 다음과 같은 주요 프로세스로 설명 할 수 있습니다.

• 환경 설정
• 테스트 실행
• 테스트 결과 확인
• 예상 결과에 따라 검증
• 결과를 각 이해 관계자에게보고하십시오.

테스트 케이스를 개발하기 위해 다양한 SQL 문이 사용됩니다. DB 테스트를 수행하는 데 사용되는 가장 일반적인 SQL 문은 다음과 같습니다.Select성명서. 이 외에도 다양한 DDL, DML, DCL 문을 사용할 수 있습니다.

Example − 생성, 삽입, 선택, 업데이트 등

데이터베이스 테스트 단계

DB 테스트는 지루한 프로세스가 아니며 테스트 프로세스에 따라 데이터베이스 테스트 라이프 사이클의 다양한 단계를 포함합니다.

데이터베이스 테스트의 주요 단계는 다음과 같습니다.

• 초기 상태 확인
• 테스트 실행
• 예상 결과에 따른 결과 검증
• 결과 생성

First stageDB 테스팅에서 테스트 프로세스를 시작하기 전에 데이터베이스의 초기 상태를 확인하는 것입니다. 그런 다음 정의 된 테스트 케이스에 대해 데이터베이스 동작을 테스트합니다. 얻은 결과에 따라 테스트 케이스가 사용자 정의됩니다.

성공적인 데이터베이스 테스트를 위해 아래 제공된 워크 플로는 모든 단일 테스트에서 실행됩니다.

• Cleaning up the database − 데이터베이스에 테스트 가능한 데이터가 있으면 비워야합니다.

• Set up Fixture − 여기에는 데이터베이스에 데이터를 입력하고 데이터베이스의 현재 상태를 확인하는 작업이 포함됩니다.

• Perform test, verify results and generate results− 테스트가 실행되고 출력이 확인됩니다. 출력이 예상 결과와 같으면 다음 단계는 요구 사항에 따라 결과를 생성하는 것입니다. 그렇지 않으면 데이터베이스에서 버그를 찾기 위해 테스트가 반복됩니다.

이 장에서는 데이터베이스 테스트를 수행하는 데 사용되는 가장 일반적인 기술에 대해 설명합니다.

데이터베이스 스키마 테스트

앞서 언급했듯이 스키마의 각 개체를 테스트하는 작업이 포함됩니다.

데이터베이스 및 장치 확인

• 데이터베이스 이름 확인
• 데이터 장치, 로그 장치 및 덤프 장치 확인
• 각 데이터베이스에 충분한 공간이 할당되었는지 확인
• 데이터베이스 옵션 설정 확인

테이블, 열, 열 유형 규칙 확인

아래 항목을 확인하여 실제 설정과 적용된 설정의 차이점을 확인하십시오.

• 데이터베이스의 모든 테이블 이름

• 각 테이블의 열 이름

• 각 테이블의 열 유형

• NULL 값 확인 여부

• 기본값이 올바른 테이블 열에 바인딩되었는지 여부

• 테이블 이름 및 액세스 권한을 수정하기위한 규칙 정의

키 및 인덱스

각 테이블의 키와 인덱스 확인-

• 각 테이블의 기본 키

• 각 테이블의 외래 키

• 외래 키 열과 다른 테이블 인덱스의 열 사이의 데이터 형식 클러스터형 또는 비 클러스터형 고유 또는 고유하지 않음

저장 프로 시저 테스트

저장 프로 시저가 정의되어 있고 출력 결과가 비교되는지 확인하는 작업이 포함됩니다. 저장 프로 시저 테스트에서 다음 사항이 확인됩니다.

• 저장 프로 시저 이름

• 매개 변수 이름, 매개 변수 유형 등

• Output− 출력에 많은 레코드가 포함되어 있는지 여부. 0 행이 적용되거나 소수의 레코드 만 추출됩니다.

• 저장 프로 시저의 기능은 무엇이며 저장 프로 시저가 수행하지 않아야하는 작업은 무엇입니까?

• 저장 프로 시저가 올바른 데이터를 추출하는지 확인하기 위해 샘플 입력 쿼리를 전달합니다.

• Stored Procedure Parameters− 경계 데이터와 유효한 데이터로 저장 프로 시저를 호출합니다. 각 매개 변수를 한 번 무효화하고 프로 시저를 실행하십시오.

• Return values− 저장 프로 시저에서 반환 된 값을 확인합니다. 실패 할 경우 0이 아닌 값을 반환해야합니다.

• Error messages check− 저장 프로 시저가 실패하는 방식으로 변경하고 적어도 한 번 모든 오류 메시지를 생성합니다. 사전 정의 된 오류 메시지가없는 경우 예외 시나리오를 확인하십시오.

트리거 테스트

트리거 테스트에서 테스터는 다음 작업을 수행해야합니다.

• 트리거 이름이 올바른지 확인하십시오.
• 트리거가 특정 테이블 열에 대해 생성 된 경우 유효성을 검증하십시오.
• 트리거의 업데이트 유효성 검사.
• 유효한 데이터로 레코드를 업데이트하십시오.
• 잘못된 데이터로 레코드를 업데이트하고 모든 트리거 오류를 처리합니다.
• 다른 테이블의 행에서 여전히 참조되는 레코드를 업데이트합니다.
• 실패가 발생하면 트랜잭션을 롤백하십시오.
• 트리거가 트랜잭션을 롤백하지 않는 경우를 찾으십시오.

서버 설정 스크립트

두 가지 유형의 테스트를 수행해야합니다.

• 처음부터 데이터베이스 설정
• 기존 데이터베이스를 설정합니다.

SQL Server의 통합 테스트

통합 테스트는 구성 요소 테스트를 마친 후에 수행해야합니다.

• 저장 프로시 저는 충돌과 비 호환성을 찾기 위해 서로 다른 테이블의 레코드를 선택, 삽입, 업데이트 및 삭제하기 위해 집중적으로 호출해야합니다.

• 스키마와 트리거 간의 충돌.

• 저장 프로 시저와 스키마 간의 충돌

• 저장 프로 시저와 트리거 간의 충돌.

기능 테스트 방법

기능에 따라 데이터베이스를 모듈로 분할하여 기능 테스트를 수행 할 수 있습니다. 기능은 다음 두 가지 유형입니다-

• Type 1− 유형 1 테스트에서 프로젝트의 기능을 확인합니다. 각 주요 기능에 대해 해당 기능을 구현하고 기능 그룹에 넣을 책임이있는 스키마, 트리거 및 저장 프로 시저를 찾습니다. 그런 다음 각 그룹을 함께 테스트하십시오.

• Type 2− 유형 2 테스트에서 백엔드의 기능 그룹 경계가 명확하지 않습니다. 데이터 흐름을 확인하고 데이터를 확인할 수있는 위치를 확인할 수 있습니다. 프런트 엔드에서 시작하십시오.

다음 프로세스가 발생합니다-

• 서비스에 요청이 있거나 데이터를 저장할 때 일부 저장 프로 시저가 호출됩니다.

• 절차는 일부 테이블을 업데이트합니다.

• 이러한 저장 프로시 저는 테스트를 시작하는 장소가되고 해당 테이블은 테스트 결과를 확인하는 장소가됩니다.

스트레스 테스트

스트레스 테스트에는 주요 데이터베이스 기능 및 해당 저장 프로 시저 목록을 가져 오는 작업이 포함됩니다. 스트레스 테스트를 위해 아래에 주어진 단계를 따르십시오-

• 테스트 스크립트를 작성하여 이러한 기능을 시도하고 모든 기능은 전체주기에 한 번 이상 확인해야합니다.

• 특정 기간 동안 테스트 스크립트를 반복해서 수행하십시오.

• 로그 파일을 확인하여 교착 상태, 메모리 부족, 데이터 손상 등을 확인합니다.

벤치 마크 테스트

데이터베이스에 데이터 문제 나 버그가없는 경우 시스템 성능을 확인할 수 있습니다. 아래에 주어진 매개 변수를 확인하여 벤치 마크 테스트에서 시스템 성능 저하를 찾을 수 있습니다.

• 시스템 수준 성능
• 가장 많이 사용되는 기능 / 특징 식별
• 타이밍 – 기능을 수행하는 최대 시간, 최소 시간 및 평균 시간
• 액세스 볼륨

프런트 엔드를 통해 데이터베이스 테스트

백엔드 버그는 때때로 프론트 엔드 테스트를 수행하여 발견 할 수도 있습니다. 아래에 제공된 간단한 단계에 따라 프런트 엔드 테스트를 통해 버그를 감지 할 수 있습니다.

• 프런트 엔드에서 쿼리를 작성하고 검색을 실행합니다.

• 기존 레코드를 선택하고 일부 필드의 값을 변경 한 다음 레코드를 저장합니다. (UPDATE 문 또는 업데이트 저장 프로 시저 및 업데이트 트리거가 포함됩니다.)

• 프런트 엔드 창에 새 메뉴 항목을 삽입합니다. 정보를 입력하고 기록을 저장합니다. (INSERT 문 또는 삽입 저장 프로 시저 및 삭제 트리거가 포함됩니다.)

• 기존 레코드를 선택하고 DELETE 또는 REMOVE 버튼을 클릭 한 다음 삭제를 확인합니다. (DELETE 문 또는 삭제 저장 프로 시저 및 삭제 트리거가 포함됩니다.)

• 유효하지 않은 데이터로 이러한 테스트 케이스를 반복하고 데이터베이스가 어떻게 응답하는지 확인하십시오.

이 장에서는 다양한 테스트 방법과 관련하여 몇 가지 일반적인 데이터베이스 테스트 시나리오를 살펴 보겠습니다.

구조화 된 데이터베이스 테스트

구조적 데이터베이스 테스트와 관련된 일반적인 데이터베이스 시나리오는 다음과 같습니다.

• 데이터베이스 이름 확인, 데이터 장치, 로그 장치 및 덤프 장치 확인, 각 데이터베이스에 충분한 공간이 할당되었는지 확인하고 데이터베이스 옵션 설정을 확인합니다.

• 데이터베이스의 모든 테이블 이름, 각 테이블의 열 이름, 각 테이블의 열 유형, null 값 확인 여부. 각 테이블의 키 및 인덱스 확인 : 각 테이블의 기본 키, 각 테이블의 외래 키.

• 외래 키 열과 다른 테이블 인덱스의 열 사이의 데이터 유형 (클러스터형 또는 비 클러스터형 고유 또는 고유하지 않음).

기능적 데이터베이스 테스트

에 대한 일반적인 데이터베이스 테스트 시나리오 Functional Database Testing -

• 해당 기능을 구현하고이를 기능 그룹으로 만들고 각 그룹을 함께 테스트 할 수있는 스키마, 트리거 및 저장 프로 시저를 찾습니다.

• 데이터 흐름을 확인하고 데이터를 확인할 수있는 위치를 확인합니다. 프런트 엔드에서 시작하십시오.

비 기능적 데이터베이스 테스트

에 대한 일반적인 데이터베이스 테스트 시나리오 Non-Functional Database Testing -

• 주요 기능을 시도하기위한 테스트 스크립트를 작성하고 모든 기능은 전체주기에서 적어도 한 번 확인해야합니다.

• 특정 기간 동안 테스트 스크립트를 반복해서 수행하십시오.

• 로그 파일을 확인하여 교착 상태, 메모리 부족, 데이터 손상 등을 확인합니다.

• 프런트 엔드에서 쿼리를 작성하고 검색을 실행합니다. 기존 레코드를 선택하고 일부 필드의 값을 변경하고 레코드를 저장합니다. (UPDATE 문 또는 업데이트 저장 프로 시저, 업데이트 트리거가 포함됩니다.)

• 프런트 엔드 창에 새 메뉴 항목을 삽입합니다. 정보를 입력하고 기록을 저장하십시오. (INSERT 문 또는 삽입 저장 프로 시저, 삭제 트리거가 포함됩니다.)

• 기존 레코드를 선택하고 DELETE 또는 REMOVE 버튼을 클릭 한 다음 삭제를 확인합니다. (DELETE 문 또는 삭제 저장 프로 시저, 삭제 트리거가 포함됩니다.)

• 유효하지 않은 데이터로 이러한 테스트 케이스를 반복하고 데이터베이스가 어떻게 응답하는지 확인하십시오.

Schemas, tables, stored procedures, 및 Triggers데이터베이스의 핵심 개체입니다. 우리는 이미 이러한 데이터베이스 개체에 대한 DB 테스트 유형 및 테스트 시나리오를 공유했습니다.

스키마

데이터베이스 스키마는 데이터베이스 관리 시스템에서 지원하는 형식으로 데이터베이스 시스템의 구조를 정의합니다. 스키마는 데이터베이스가 구조화되는 방식을 나타냅니다 (관계형 데이터베이스의 경우 데이터베이스 테이블로 구성됨).

데이터베이스 스키마는 데이터베이스에 적용되는 무결성 제약 조건이라고하는 일련의 공식입니다. 이러한 무결성 제약 조건은 스키마 부분 간의 호환성을 보장합니다.

관계형 데이터베이스에서 스키마는 테이블, 필드, 뷰, 인덱스, 패키지, 프로 시저, 함수, 트리거, 유형, 구체화 된 뷰, 동의어, 데이터베이스 링크 및 기타 요소로 구성됩니다.

스키마는 일반적으로 데이터 사전에 저장됩니다. 스키마가 텍스트 데이터베이스 언어로 정의되어 있지만이 용어는 데이터베이스 구조의 그래픽 묘사를 나타내는 데 자주 사용됩니다. 즉, 스키마는 데이터베이스의 개체를 정의하는 데이터베이스의 구조입니다.

데이터웨어 하우스에서 사용되는 일반적인 유형의 스키마는 다음과 같습니다.

• 스타 스키마
• 눈송이 스키마
• Galaxy 스키마

데이터베이스의 테이블

관계형 데이터베이스에서 테이블은 정보를 행과 열로 구성하는 데 사용됩니다.

Example − 고객 테이블에는 고객 ID, 주소, 전화 번호 등과 같은 정보가 일련의 열로 포함됩니다.

각 데이터 조각은 테이블의 필드입니다. 열은 모든 고객의 전화 번호와 같은 단일 필드의 모든 항목으로 구성됩니다. 필드는 각 행을 구성하는 완전한 정보 세트 (예 : 특정 고객에 대한 정보 세트) 인 레코드로 구성됩니다.

저장 프로 시저

저장 프로시 저는 데이터베이스에 컴파일 된 형식으로 저장된 일련의 SQL 문이며 여러 프로그램이이를 공유 할 수 있습니다. 저장 프로 시저를 사용하면 데이터 무결성 유지, 데이터 제어 액세스 및 생산성 향상에 도움이 될 수 있습니다.

트리거

데이터베이스 트리거는 데이터베이스의 특정 테이블 또는 뷰에 대한 특정 이벤트에 대한 응답으로 실행되는 코드입니다. 트리거는 주로 데이터베이스에있는 정보의 무결성을 유지하는 데 사용됩니다.

데이터 무결성은 데이터베이스에서 중요합니다. 여기에는 삽입, 업데이트 및 삭제 전 데이터 유효성 검사가 포함됩니다. 참조 테이블 레코드의 유효성을 검사하려면 트리거가 있어야합니다.

데이터 무결성을 확인하려면 다음 작업을 수행해야합니다.

• 각 테이블의 주요 열을 확인하고 잘못된 데이터가 있는지 확인해야합니다. (이름 필드의 문자, 음수 백분율 등)

• 일치하지 않는 데이터를 찾아서 관련 테이블에 삽입하고 실패가 발생하는지 확인하십시오.

• 상위 데이터를 삽입하기 전에 하위 데이터를 삽입하십시오. 다른 테이블의 데이터에서 여전히 참조하는 레코드를 삭제 해보십시오.

• 테이블의 데이터가 업데이트되면 다른 관련 데이터도 업데이트되는지 확인합니다. 복제 된 서버 또는 데이터베이스가 동기화되고 일관된 정보를 포함하고 있는지 확인해야합니다.

데이터베이스의 데이터 매핑은 모든 테스터가 검증해야하는 핵심 개념 중 하나입니다. 일반적으로 테스터는 해당 백엔드 데이터베이스 필드와 사용자 인터페이스 프런트 엔드 필드 매핑을 확인해야합니다.

이 정보는 소프트웨어 요구 사항 사양 또는 비즈니스 요구 사항 사양 SRS / BRS 문서에 제공됩니다. 매핑이 제공되지 않는 경우 코딩 부분을 확인해야합니다.

프런트 엔드 애플리케이션에서 작업을 수행하면 해당 CRUD 작업이 호출되고 테스터는 호출 된 모든 작업이 성공했는지 확인해야합니다.

데이터 매핑의 주요 측면

다음은 데이터 매핑의 주요 측면입니다.

• UI / Front end 양식의 필드를 확인하고 해당 DB 테이블과 일관되게 매핑됩니다. 이 매핑 정보는 위에서 언급 한 요구 사항 문서에 정의되어 있습니다.

• 애플리케이션의 프런트 엔드에서 수행되는 모든 작업에 대해 해당 CRUD '생성, 검색, 업데이트 및 삭제'작업이 백 엔드에서 시작됩니다.

• 테스터는 올바른 조치가 호출되고 호출 된 조치 자체가 성공했는지 여부를 확인해야합니다.

데이터 매핑 테스트의 단계

다음은 데이터 매핑 테스트를 위해 따르는 단계입니다.

• Step 1 − 먼저 각 스크립트의 구문 오류를 확인하십시오.

• Step 2 − 다음은 테이블 매핑, 컬럼 매핑, 데이터 타입 매핑을 확인하는 것입니다.

• Step 3 − 조회 데이터 매핑을 확인합니다.

• Step 4 − 대상 테이블에 레코드가 없을 때 각 스크립트를 실행합니다.

• Step 5 − 대상 테이블에 레코드가 이미있을 때 각 스크립트를 실행합니다.

응답 시간이 길고 성능이 떨어지는 애플리케이션은 큰 문제를 일으킬 수 있습니다. 데이터베이스로드 테스트는 최종 사용자를 위해 데이터베이스 응용 프로그램을 배포하기 전에 성능 문제를 찾는 데 사용됩니다.

데이터베이스로드 테스트는 성능, 안정성 및 확장 성을 위해 데이터베이스 애플리케이션을 설계하는 데 도움이됩니다. 데이터베이스 애플리케이션의로드 테스트에는 다양한 사용자로드로 데이터베이스 애플리케이션의 성능 및 확장 성 테스트가 포함됩니다.

데이터베이스로드 테스트에는 대상 데이터베이스 애플리케이션에 대한 실제 사용자로드 시뮬레이션이 포함됩니다. 여러 사용자가 동시에 적중 할 때 데이터베이스 응용 프로그램의 작동 방식을 결정하는 데 도움이됩니다.

부하 테스트

로드 테스트의 기본 목표는 실행중인 대부분의 트랜잭션이 데이터베이스 성능에 영향을 미치는지 확인하는 것입니다. 부하 테스트에서 다음 측면을 확인해야합니다.

• 여러 원격 사용자에 대한 트랜잭션 실행에 대한 응답 시간을 확인해야합니다.

• 일반 트랜잭션의 경우 이러한 유형의 pf 트랜잭션에 대한 데이터베이스 성능을 확인하려면 편집 가능한 트랜잭션 하나를 포함해야합니다.

• 일반 트랜잭션의 경우 이러한 유형의 트랜잭션에 대한 데이터베이스 성능을 확인하려면 편집하지 않는 트랜잭션 하나를 포함해야합니다.

• 데이터베이스가 특정 레코드를 가져 오는 데 걸리는 시간을 확인해야합니다.

스트레스 테스트

시스템을 식별하기 위해 스트레스 테스트가 수행됩니다. breakpoint. 여기서 응용 프로그램은 시스템이 한 지점에서 실패하는 방식으로로드됩니다. 이 지점을 데이터베이스 시스템의 중단 점이라고합니다. 스트레스 테스트는 다음과 같이 알려져 있습니다.Fatigue Testing.

데이터베이스 트랜잭션의 상태를 확인하려면 상당한 노력이 필요합니다. 시간 및 비용 기반 문제를 방지하려면 적절한 계획이 필요합니다.

가장 일반적인 스트레스 테스트 도구는 다음과 같습니다. LoadRunner 과 WinRunner.

테스트 데이터를 생성하고 테스트 데이터를 관리하며 부하 테스트 및 회귀 테스트와 같은 데이터베이스 테스트를 수행하는 데 사용할 수있는 공급 업체에서 제공하는 다양한 도구가 있습니다.

사용되는 몇 가지 일반적인 도구가 아래에 나와 있습니다.

조직 성장에서 가장 중요한 부분은 데이터입니다. 시스템 장애가 발생한 경우 데이터를 복원해야합니다. 백업은 데이터베이스의 정확한 복사본으로, 데이터 손실시 데이터를 복원하는 데 도움이됩니다.

A / C 번호, 고객 이름, 신용 및 차변, 기간 등과 같은 고객 관련 데이터를 보유한 금융 회사를 생각해보십시오. 그러한 조직은 데이터 오류 발생시 그러한 중요한 정보를 잃어 버리는 압력에 어떻게 대처할까요?

이것이 디스크, 디스크 컨트롤러 등에 오류가 발생하는 경우 백업에 의존하여 데이터베이스로 복원 할 수 있도록 데이터를 백업하는 이유입니다.

데이터 백업 유형

사용할 수있는 백업에는 두 가지 유형이 있습니다.

• Physical Backups − 물리적 백업에는 Veritas Net Back, IBM Tivoli Manager 또는 OS 유틸리티를 사용하는 사용자 관리자 백업과 같은 타사 백업 도구를 사용한 백업이 포함됩니다.

• Logical Backups − 데이터베이스의 논리적 백업에는 테이블, 인덱스, 절차 등과 같은 논리적 개체의 백업이 포함됩니다.

Example − 데이터 백업을 수행하는 일반적인 도구 중 하나는 Oracle Recovery Manager (RMAN) 데이터베이스 백업을 수행하는 Oracle 유틸리티입니다.

RMAN 두 가지 구성 요소로 구성-

• Target database 백업이 필요합니다.

• RMAN 클라이언트는 데이터 백업을 수행하는 명령을 실행하는 데 사용됩니다.

BACKUP VALIDATE데이터베이스 파일의 유효한 백업을 만들 수 있는지 테스트하는 데 사용됩니다. 그것은 보장합니다-

• 데이터베이스의 물리적 또는 논리적 개체에 대한 백업이있는 경우.
• 귀중한 데이터를 정기적으로 백업하는 경우.
• 백업 도구가 조직의 백업 요구 사항을 충족하는 경우.

Database recovery testing데이터베이스가 복구되었는지 확인하는 데 사용됩니다. 복구 테스트를 사용하면 응용 프로그램이 제대로 실행되고 있는지 확인하고 복구 방법이 제대로 설정되지 않은 경우 손실되었을 귀중한 데이터를 검색 할 수 있습니다.

또한 몇 가지 중요한 프로세스가 원활하게 실행되고 있는지 확인하여 데이터 복구가 테스트 단계를 원활하게 통과하는지 확인합니다.

당신은 데이터베이스 복구를 위해 다음 검사를 수행 할 수 있습니다-

• 백업 소프트웨어의 모든 오류 또는 실수는 초기 단계에서 이러한 문제를 해결해야합니다.

• 응급 상황에서해야 할 일을 알 수 있도록 복구 테스트를 수행해야합니다.

• 효과적인 복구 전략을 계획 할 수 있도록 복구 테스트 요구 사항을 확인해야합니다.

• 문서를 복구 할 수있는 방법도 알아야합니다.

프로젝트의 초기 단계에서 복구 테스트를 실행해야합니다. 이를 통해 시스템에서 모든 유형의 오류를 제거하고 제거 할 수 있습니다. 다음은 테스트시 고려해야하는 몇 가지 중요한 사항의 목록입니다.

• 데이터베이스 시스템에서 변경 또는 수정이 발생하는 시간 범위입니다.

• 복구 계획을 수행 할 기간입니다.

• 데이터베이스 시스템에서 데이터의 민감도. 데이터가 더 중요할수록 소프트웨어를 더 정기적으로 테스트해야합니다.

데이터베이스 백업 및 복구 테스트의 일반적인 단계

데이터베이스 복구 테스트에서는 실제 환경에서 테스트를 실행하여 비즈니스 환경에서 재해 및 기타 예기치 않은 이벤트 발생시 시스템 또는 데이터를 실제로 복구 할 수 있는지 확인해야합니다.

다음은 데이터베이스 복구 테스트에서 수행되는 일반적인 작업입니다.

• 데이터베이스 시스템 테스트
• SQL 파일 테스트
• 부분 파일 테스트
• 데이터 백업 테스트
• 백업 도구 테스트
• 로그 백업 테스트

데이터베이스 보안 테스트는 보안 메커니즘의 허점을 찾고 데이터베이스 시스템의 취약성 또는 약점을 찾기 위해 수행됩니다.

데이터베이스 보안 테스트의 주요 목표는 시스템의 취약성을 찾아 내고 잠재적 인 침입자로부터 데이터와 리소스를 보호하는지 여부를 확인하는 것입니다. 보안 테스트는 정기적으로 수행 될 때 잠재적 인 취약성을 효과적으로 식별하는 방법을 정의합니다.

다음은 데이터베이스 보안 테스트를 수행하는 주요 목표입니다.

• Authentication
• Authorization
• Confidentiality
• Availability
• Integrity
• Resilience

데이터베이스 시스템의 위협 유형

SQL 주입

이는 악성 SQL 문이 데이터베이스 시스템에 삽입되고 데이터베이스 시스템에서 중요한 정보를 얻기 위해 실행되는 데이터베이스 시스템에서 가장 일반적인 유형의 공격입니다. 이 공격은 사용자 응용 프로그램 구현의 허점을 이용합니다. 이를 방지하려면 사용자 입력 필드를 신중하게 처리해야합니다.

데이터베이스의 권한 상승

이 공격에서 사용자는 이미 데이터베이스 시스템에 일부 액세스 권한이 있으며 데이터베이스 시스템에서 일부 무단 활동을 수행 할 수 있도록이 액세스 권한을 더 높은 수준으로 올리려고합니다.

서비스 거부

이러한 유형의 공격에서 공격자는 합법적 인 사용자가 데이터베이스 시스템 또는 응용 프로그램 리소스를 사용할 수 없도록 만듭니다. 응용 프로그램은 응용 프로그램, 때로는 전체 시스템을 사용할 수 없게 만드는 방식으로 공격을받을 수도 있습니다.

데이터에 대한 무단 액세스

또 다른 유형의 공격은 애플리케이션 또는 데이터베이스 시스템 내의 데이터에 대한 무단 액세스를 확보하는 것입니다. 무단 액세스에는 다음이 포함됩니다.

• 사용자 기반 애플리케이션을 통한 데이터 무단 액세스
• 타인의 접근을 감시하여 무단 접근
• 재사용 가능한 클라이언트 인증 정보에 대한 무단 액세스

신원 스푸핑

ID 스푸핑에서 해커는 사용자 또는 장치의 자격 증명을 사용하여 네트워크 호스트에 대한 공격을 시작하고 데이터를 도용하거나 데이터베이스 시스템에 대한 액세스 제어를 우회합니다. 이 공격을 방지하려면 IT 인프라 및 네트워크 수준의 완화가 필요합니다.

데이터 조작

데이터 조작 공격에서 해커는 데이터를 변경하여 이점을 얻거나 데이터베이스 소유자의 이미지를 손상시킵니다.

데이터베이스 보안 테스트 기술

침투 테스트

침투 테스트는 보안 허점을 찾아 잠재적으로 컴퓨터 시스템, 기능 및 데이터에 대한 액세스 권한을 얻으려는 의도로 컴퓨터 시스템에 대한 공격입니다.

위험 찾기

위험 찾기는 손실 유형 및 취약성 발생 가능성과 관련된 위험을 평가하고 결정하는 프로세스입니다. 이는 다양한 인터뷰, 토론 및 분석을 통해 조직 내에서 결정됩니다.

SQL 주입 테스트

애플리케이션 필드에서 사용자 입력을 확인하는 작업이 포함됩니다. 예를 들어 ','또는 ';'과 같은 특수 문자를 입력합니다. 사용자 응용 프로그램의 모든 텍스트 상자에 허용되지 않아야합니다. 데이터베이스 오류가 발생하면 일부 쿼리에 사용자 입력이 삽입되어 응용 프로그램에서 실행됨을 의미합니다. 이 경우 애플리케이션은 SQL 인젝션에 취약합니다.

이러한 공격은 공격자가 서버 데이터베이스의 중요한 정보에 액세스 할 수 있으므로 데이터에 큰 위협이됩니다. 웹 애플리케이션에 대한 SQL 삽입 진입 점을 확인하려면 일부 사용자 입력을 받아 데이터베이스에서 직접 MySQL 쿼리가 실행되는 코드베이스에서 코드를 찾습니다.

대괄호, 쉼표 및 인용 부호에 대해 SQL 주입 테스트를 수행 할 수 있습니다.

암호 크래킹

이것은 데이터베이스 시스템 테스트를 수행하는 동안 가장 중요한 검사입니다. 중요한 정보에 액세스하기 위해 해커는 암호 해독 도구를 사용하거나 일반적인 사용자 이름 / 암호를 추측 할 수 있습니다. 이러한 일반적인 암호는 인터넷에서 쉽게 사용할 수 있으며 암호 크래킹 도구도 자유롭게 존재합니다.

따라서 테스트시 비밀번호 정책이 시스템에서 유지되고 있는지 확인해야합니다. 은행 및 금융 응용 프로그램의 경우 모든 중요 정보 데이터베이스 시스템에 엄격한 암호 정책을 설정해야합니다.

데이터베이스 시스템의 보안 감사

보안 감사는 필요한 표준을 준수하는지 여부를 결정하기 위해 정기적으로 회사의 보안 정책을 평가하는 프로세스입니다. 비즈니스 요구 사항에 따라 다양한 보안 표준을 따라 보안 정책을 정의한 다음 해당 표준에 대해 설정된 정책을 평가할 수 있습니다.

가장 일반적인 보안 표준의 예는 ISO 27001, BS15999 등입니다.

데이터베이스 보안 테스트 도구

OS 및 애플리케이션 검사를 테스트하는 데 사용할 수있는 다양한 시스템 테스트 도구가 출시되어 있습니다. 가장 일반적인 도구 중 일부는 아래에서 설명합니다.

Zed 공격 프록시

웹 애플리케이션의 취약점을 찾기위한 침투 테스트 도구입니다. 광범위한 보안 경험을 가진 사람들이 사용하도록 설계되었으므로 침투 테스트를 처음 사용하는 개발자 및 기능 테스터에게 이상적입니다. Windows, Linux, Mac OS에서 일반적으로 사용됩니다.

파로스

쿠키 및 양식 필드를 포함하여 서버와 클라이언트 간의 모든 HTTP 및 HTTPS 데이터는 이러한 스캐너를 사용하여 가로 채고 수정할 수 있습니다. 크로스 플랫폼, Java JRE / JDK 1.4.2 이상에서 사용됩니다.

사회 엔지니어 툴킷

오픈 소스 도구이며 시스템 요소가 아닌 인간 요소가 공격을받습니다. 공격 코드가 포함 된 이메일, 자바 애플릿 등을 보낼 수 있습니다. Linux, Apple Mac OS X 및 Microsoft Windows에 권장됩니다.

가다랑어

이 도구는 사이트에서 취약점을 검색하는 데 사용됩니다. 도구에서 생성 된 보고서는 전문 웹 애플리케이션 보안 평가의 기초 역할을합니다. Linux, FreeBSD, MacOS X 및 Windows에서 선호됩니다.

Vega

웹 애플리케이션에서 SQL 주입, 교차 사이트 스크립팅 (XSS) 및 기타 취약성의 인스턴스를 찾는 데 사용되는 오픈 소스, 다중 플랫폼 웹 보안 도구입니다. Java, Linux 및 Windows에 선호됩니다.

와피 티

Wapiti는 웹 애플리케이션의 웹 페이지를 스캔하고 데이터를 삽입 할 수있는 스크립트와 양식을 확인하는 오픈 소스 및 웹 기반 도구입니다. Python으로 빌드되었으며 파일 처리 오류, 데이터베이스, XSS, LDAP 및 CRLF 삽입, 명령 실행 감지를 감지 할 수 있습니다.

웹 풍뎅이

Java로 작성되었으며 HTTP / HTTPS 프로토콜을 통해 통신하는 애플리케이션을 분석하는 데 사용됩니다. 이 도구는 주로 직접 코드를 작성할 수있는 개발자를 위해 설계되었습니다. 이 도구는 OS에 종속되지 않습니다.

데이터베이스 테스트를 성공적으로 수행하려면 테스터는 기술 및 기능 요구 사항과 같은 모든 소스에서 요구 사항을 수집해야합니다. 몇 가지 요구 사항이 높은 수준에있을 가능성이 있으므로 이러한 요구 사항을 작은 부분으로 나눌 필요가 있습니다. 데이터베이스 테스트는 복잡한 작업이며 테스터는이 테스트를 수행하는 동안 많은 문제에 직면합니다. 가장 일반적인 데이터베이스 테스트 문제는 다음과 같습니다.

테스트 범위가 너무 큽니다.

테스터는 데이터베이스 테스트에서 테스트 항목을 식별해야합니다. 그렇지 않으면 테스트 할 항목과 테스트하지 않을 항목을 명확하게 이해하지 못할 수 있습니다. 따라서 요구 사항이 명확하다면 데이터베이스에서 중요하지 않은 개체를 테스트하는 데 많은 시간을 낭비 할 수 있습니다.

테스트 할 개체 목록이있는 경우 다음은 테스트를 설계하고 각 테스트 항목에 대한 테스트를 실행하는 데 필요한 노력을 추정하는 것입니다. 설계 및 데이터 크기에 따라 일부 데이터베이스 테스트를 실행하는 데 시간이 오래 걸릴 수 있습니다.

데이터베이스 크기가 너무 크면 테스트해야 할 개체와 제외 할 개체를 찾는 것이 큰 도전이됩니다.

축소 된 테스트 데이터베이스

일반적으로 테스터에게는 테스트 할 개발 데이터베이스 사본이 제공됩니다. 해당 데이터베이스에는 응용 프로그램을 실행하기에 충분한 데이터가 거의 없습니다. 따라서 개발, 스테이징 및 프로덕션 데이터베이스 시스템을 테스트 할 필요가 있습니다.

데이터베이스 구조 변경

이것은 DB 테스트의 일반적인 과제 중 하나입니다. 때로는 테스트를 설계하거나 실행하고 데이터베이스 구조가 변경된 경우가 있습니다. 이는 테스트 중에 데이터베이스에 대한 변경 사항을 알고 있어야합니다.

데이터베이스 구조가 변경되면 변경의 영향을 분석하고 테스트를 수정해야합니다. 또한 여러 사용자가 테스트 데이터베이스를 사용하는 경우 테스트 결과에 대해 확신 할 수 없으므로 테스트 데이터베이스가 테스트 목적으로 만 사용되는지 확인해야합니다.

DB 테스트의 또 다른 문제는 동시에 여러 테스트를 실행한다는 것입니다. 최소한 성능 테스트를 위해 한 번에 하나의 테스트를 실행해야합니다. 데이터베이스가 여러 작업을 수행하고 성능이 낮게보고되는 것을 원하지 않습니다.

복잡한 테스트 계획

데이터베이스 구조는 일반적으로 복잡하고 막대한 데이터가 있으므로 불완전하거나 동일한 테스트를 반복적으로 실행할 가능성이 있습니다. 따라서 테스트 계획을 작성하고 그에 따라 진행하고 정기적으로 진행 상황을 확인해야합니다.

SQL에 대한 좋은 이해

데이터베이스를 테스트하려면 SQL 쿼리와 필요한 데이터베이스 관리 도구에 대한 충분한 지식이 있어야합니다.

db_connect(query1 DRIVER {drivername};SERVER server_name;UID uidname;
   PWD password;DBQ database_name );

db_excecute_query (write the required query that is to execute); Specify the appropriate condition

db_disconnect(query);