관계형 데이터베이스 회귀 테스트의 데이터 품질

박물관의 가입, 기부, 대출 또는 기타 획득 한 유물을 추적하는 데 사용되는 오픈 소스 Museum Collections Management 웹 응용 프로그램을 작업하고 있습니다.

여기에는 유연하고 쉽게 확장 할 수 있어야하는 모든 종류의 다양한 정보 (유물 정보, 위치 정보 변경, 개인 연락처 정보, 사진 등)를 저장하는 다소 큰 데이터베이스 (이전 경험과 관련하여)를 설계하고 작성하는 작업이 포함되었습니다. .

나는 단지 대학 학위를 마치고 데이터베이스 디자인에 관해서는 전문가가 아니기 때문에 실제로 "제자리에"있는 것을 보장하기 위해 철저한 테스트 스위트를 만들고 싶습니다.

데이터베이스 테스트에 대해 읽었으며 데이터베이스와 관련하여 회귀 테스트를 언급하는 몇 가지 기사를 보았지만이 모든 것이 무엇인지 완전히 이해하지 못했습니다. Dr.Dobbs 에서이 기사를 읽음으로써 필자가 수행해야 할 한 가지 테스트는 데이터베이스의 논리가 올바른지 확인하는 것입니다. 따라서 특정 데이터를 데이터베이스에 삽입하고 데이터베이스에서 올바른 데이터를 다시 가져 오는지 확인하기 위해 쿼리를 수행하는 테스트를 작성합니다 (모든 적절한 트리거 또는 뷰가 작동하는지 확인).

혼란은 "데이터 품질"에 대한 테스트에 대한 언급과 관련이 있습니다. 위의 기사에서 저자는 테스트를 통해 다음을 검증하고 싶다고 언급합니다.

• 열 도메인 값 규칙
• 열 기본값 규칙
• 가치 존재 규칙
• 행 값 규칙
• 크기 규칙

여기에는 어떤 유형의 테스트가 포함되며 어떻게 구현됩니까? 또한 데이터베이스를위한 테스트 스위트를 처음 작성하는 것입니다. 테스트 개발을 안내하기 위해 수행 할 수있는 방법 / 위치 또는 프로세스에 대한 좋은 지침이 있습니까?

이 질문에 대한 완전한 답변은 매우 길 것입니다. 나는 요점을 언급하려고 노력할 것이다.

우려를 분리하기 위해 다음과 같은 테스트를 살펴볼 수 있습니다.

A-데이터베이스 디자인을 검증하십시오.

B-프로그램이 데이터베이스와 올바르게 상호 작용하는지 확인하십시오.

데이터베이스 설계 검증은 데이터베이스를 설계 한 사람이 수행해야합니다. 개발자 (단위 테스트 중)는 (B) 부분에 더 관심을 가져야합니다. 두 가지 유형의 테스트간에 가장 큰 차이점은 사용 된 도구입니다. (A)의 경우 프로젝트 코드와 독립적 인 환경을 사용하고 (B)의 경우 물론 프로젝트 코드를 사용합니다. 다음 본문에서는 두 가지를 혼합합니다.

특정 질문에 대답하려면 다음을 수행하십시오.

열 도메인 값 규칙

각 열에는 관련 데이터 형식이 있습니다. 각 열은 올바른 데이터 유형을 나타내는 비즈니스 규칙에 따라 유효성을 검증해야합니다. 열 데이터 형식이 비즈니스 요구 사항과 호환되지 않거나 코드가 데이터베이스에 정의 된 방식과 다른 데이터 형식을 사용하는 경우 문제가 발생할 수 있습니다.

예를 들면 다음과 같습니다.

• 열이 small int로 정의 된 경우 텍스트를 저장할 수 없습니다. 이것은 누군가가 실제로 일부 데이터를 입력 할 때까지 눈에 띄지 않을 수 있으므로 열이 선택 사항 인 경우 특히 중요한 테스트입니다.

• 비즈니스에서 요구하는 열에 음수 값을 저장할 수 있습니까?

열 기본값 규칙

일부 컬럼은 DDL (Data Def. Language)의 기본값 스펙과 연관되며, 삽입 중 삽입이 값을 제공하지 않으면 데이터베이스가 기본값을 가정합니다. 값을 전달하지 않고 데이터베이스가 저장 한 결과 값을 관찰하여 테스트 할 수 있습니다. 이 테스트에는 Nullable 열 검사가 포함될 수도 있습니다. 고유 인덱스가 컬럼에 빌드되지 않으면 DDL에서 확인할 수 있으므로 테스트가 거의 필요하지 않습니다.

가치 존재 규칙

이 내용을 이해하면 데이터베이스에 삽입 또는 업데이트 된 데이터가 예상대로 표시되는지 확인합니다.

행 값 규칙

나는 이것이 정확히 무엇을 의미하는지 명확하지 않습니다.

크기 규칙

각 열은 DDL에서 정의 된 방식에 따라 데이터베이스의 크기를 갖습니다. 요구 사항에 맞는 값 (GUI에서 입력하거나 계산 결과로 생성됨)이 열에 올바르게 저장되도록해야합니다. 예를 들어 Small Integer 데이터 형식을 사용하면 50 억의 값을 저장할 수 없습니다. 또한 VARCHAR2 (30)로 정의 된 이름에는 40자를 사용할 수 없으므로, 특히 열이 데이터 집계에 사용될 때 비즈니스 규칙이 매우 명확해야합니다. 그러한 상황에서 발생하는 상황을 테스트하려고합니다.

시작 방법 / 장소에 대한 지침

이를 수행하는 한 가지 방법은 테스트 계획을 세우는 것입니다. 요구 사항 문서 및 사용 사례와 같은 올바른 버전의 사양과 소프트웨어를 사용하고 싶습니다. 또한 단위 테스트 (있는 경우)에서 수행 한 테스트로 테스트 테스트를 조정해야합니다. 다시 수행 할 필요가없는 중복 테스트가있을 수 있습니다. 필요한 경우 특정 테스트를 반복 할 수 있도록 테스트하기 전에 데이터베이스 사본을 작성하려고합니다. DBA가 이에 도움이 될 수 있습니다. 또한이 테스트를 어떻게 문서화하고 테스트 범위를 검증하는지 팀과 확인해야합니다. 데이터베이스를 논리적 부분으로 나누고 각 논리적 부분의 테스트를 개별적으로 시작할 수 있습니다. 테스트 프로세스는 데이터베이스의 DDL을 연구하고 비즈니스에서 요구하는대로 컬럼이 올바르게 정의되었는지 검증하여 시작할 수 있습니다. 대부분의 테스트를 수행하기 위해 다른 도구가 아닌 응용 프로그램의 소프트웨어를 사용해야합니다. 예를 들어 다음과 같이 질문하십시오.

• 열이 정의 된 유형이어야합니까 (Name을 Int로 만들 때 아무런 의미가 없습니다).

• 비즈니스 요구 사항과 크기가 호환됩니까?

• 비즈니스 요구 사항의 모든 열이 데이터베이스에 있습니까?

• null 열은 실제로 선택 사항입니까?

• 기타

다음으로, 테스트 케이스를 설계하여 위의 테스트를 수행 할 수 있습니다. GUI를 사용하여 대부분의 테스트를 수행 할 수 있습니다.

언급하지 않은 다른 중요한 데이터베이스 테스트가 있습니다. 그들은 다음을 처리합니다.

1-기본 키가 비즈니스 관점에서 실제로 고유한지 테스트합니다.

2-PK 이외의 고유 인덱스가 비즈니스 관점에서 실제로 고유한지 테스트합니다.

3-외래 키 제약 조건 테스트가 작동합니다.

4-행이 삭제 될 때 발생하는 상황 및 관련 행에 미치는 영향 테스트

5-CHEKC, 트리거 (있는 경우)와 같은 특수 데이터베이스 구성에 관한 기타 테스트

6-올바른 테이블 정규화 및 정규화 된 열이 올바른 값을 보유합니다.

위의 전체 목록은 아니지만 시작해야합니다.

나는 당신이 이것에 잘못 접근하고 있다고 생각합니다.

내가 아는 모든 데이터베이스는 데이터를 테이블에 삽입하기 전에 확인합니다. 각 열의 정의에 대해 데이터의 유효성을 검사합니다. SMALLINT (3) 열에 80 자 문자열을 입력 할 수 없습니다. 데이터베이스가 해당 시도에 실패하고 오류가 있음을 알려줍니다. 데이터를 삽입 한 후 검색하여 직접 테스트 할 필요는 없습니다.

데이터베이스에 보내기 전에 데이터에 대한 유효성 검사 / 필터링 규칙이 필요 합니다.

• 데이터가 각 열에 허용되는 유형 및 범위에 맞는지 확인하고 원하지 않는 내용을 필터링
• 오류를 피하기 위해 올바르게 이스케이프 처리 (공용 인터페이스가있는 경우 가능한 SQL 삽입)

이러한 유효성 검사 / 필터링 규칙은 실제 응용 프로그램의 데이터에서 실행되어야합니다. 그런 다음 정확하고 잘못된 데이터를 제공하여 테스트에 따라 유효성 검사를 통과 또는 실패하는지 테스트하여 테스트가 올바른지 확인하도록 설정할 수 있습니다.

데이터베이스 디자인이 진행되는 한, 테스트를 통해 실제로이를 검증 할 수는 없습니다. 많은 디자인이 이상적이지 않더라도 작동 할 수 있기 때문에 (그리고 다른 사람들 간의 이상적인 변화에 대한 정의) 가능합니다. 적절한 데이터베이스 디자인은 자동화 된 테스트가 아니라 경험과 지식으로 제공됩니다.