Chất lượng dữ liệu trong các thử nghiệm hồi quy cơ sở dữ liệu quan hệ


9

Tôi đã làm việc trên một ứng dụng web Quản lý Bộ sưu tập Bảo tàng nguồn mở được sử dụng để theo dõi các bảo vật được gia nhập, tặng, cho mượn hoặc mua lại của bảo tàng.

Điều này liên quan đến việc thiết kế và tạo một cơ sở dữ liệu khá lớn (liên quan đến kinh nghiệm trước đây của tôi), nơi lưu trữ tất cả các loại thông tin khác nhau (thông tin xác thực, thay đổi thông tin vị trí, thông tin liên hệ cá nhân, hình ảnh, v.v.), cần phải linh hoạt và dễ dàng mở rộng .

Tôi chỉ hoàn thành bằng đại học và tôi không chuyên nghiệp khi thiết kế cơ sở dữ liệu và vì vậy tôi thực sự muốn tạo ra một bộ kiểm tra kỹ lưỡng để đảm bảo rằng những gì tôi có tại chỗ "hoạt động".

Tôi đã đọc về kiểm tra cơ sở dữ liệu và đã bắt gặp một vài bài viết đề cập đến Kiểm tra hồi quy liên quan đến cơ sở dữ liệu nhưng tôi không hiểu đầy đủ tất cả những gì liên quan đến điều này. Từ việc đọc bài viết này tại Dr.Dobbs tôi hiểu rằng một loại thử nghiệm mà tôi sẽ cần phải làm là xác nhận rằng logic trong cơ sở dữ liệu là chính xác. Vì vậy, tôi sẽ tạo các thử nghiệm chèn một số dữ liệu nhất định vào cơ sở dữ liệu và sau đó theo dõi nó bằng một truy vấn để đảm bảo rằng tôi lấy lại được dữ liệu chính xác từ cơ sở dữ liệu (đảm bảo rằng tất cả các kích hoạt hoặc chế độ xem phù hợp đang hoạt động).

Sự nhầm lẫn đi kèm với việc đề cập đến thử nghiệm cho "Chất lượng dữ liệu". Trong bài viết trên, tác giả đề cập rằng bạn muốn xác thực các mục sau bằng các bài kiểm tra:

  • Quy tắc giá trị miền cột
  • Quy tắc giá trị mặc định của cột
  • Quy tắc tồn tại giá trị
  • Quy tắc giá trị hàng
  • Quy tắc kích thước

Những loại thử nghiệm này sẽ liên quan và làm thế nào chúng sẽ được thực hiện? Ngoài ra đây là lần đầu tiên tôi viết một bộ kiểm tra cho cơ sở dữ liệu, có hướng dẫn tốt nào về cách bắt đầu / nơi bắt đầu hoặc bất kỳ quy trình nào tôi có thể làm theo để hướng dẫn phát triển thử nghiệm của mình không?

Câu trả lời:


3

Một câu trả lời đầy đủ cho câu hỏi này sẽ rất dài. Tôi sẽ cố gắng đề cập đến những điểm chính.

Để phân tách mối quan tâm, bạn có thể xem xét các thử nghiệm để:

A - Xác thực thiết kế cơ sở dữ liệu.

B - Xác thực rằng (các) chương trình đang tương tác chính xác với cơ sở dữ liệu.

Việc xác thực thiết kế cơ sở dữ liệu nên được thực hiện bởi người đã thiết kế cơ sở dữ liệu. Các nhà phát triển (trong khi thử nghiệm đơn vị) nên quan tâm nhiều hơn đến phần (B). Sự khác biệt chính mà tôi thấy giữa hai loại thử nghiệm là các công cụ được sử dụng. Đối với (A), bạn sẽ sử dụng một môi trường độc lập với mã dự án, trong khi trên (B) tất nhiên bạn sẽ sử dụng mã của dự án. Trong văn bản sau đây, tôi sẽ trộn cả hai.

Để trả lời các câu hỏi cụ thể của bạn:

Quy tắc giá trị miền cột

Mỗi cột có một kiểu dữ liệu liên quan. Mỗi cột phải được xác nhận theo các quy tắc kinh doanh để chứng minh rằng nó đại diện cho loại dữ liệu chính xác. Các vấn đề có thể phát sinh nếu loại dữ liệu cột không tương thích với các yêu cầu nghiệp vụ hoặc nếu mã sử dụng loại dữ liệu khác với cách xác định trong cơ sở dữ liệu.

Ví dụ:

  • Nếu cột được định nghĩa là int nhỏ, bạn sẽ không thể lưu trữ văn bản trong đó. Đây là một thử nghiệm quan trọng đặc biệt khi các cột là tùy chọn, vì nó có thể không được chú ý cho đến khi ai đó thực sự nhập một số dữ liệu trong đó.

  • Bạn có thể lưu trữ một giá trị âm trong một cột nơi doanh nghiệp yêu cầu điều đó xảy ra không?

Quy tắc giá trị mặc định của cột

Một số cột được liên kết với một đặc tả giá trị mặc định trong DDL (Ngôn ngữ xác định dữ liệu) trong đó nếu trong quá trình chèn, phần chèn không cung cấp giá trị, cơ sở dữ liệu sẽ giả sử giá trị mặc định. Điều này có thể được kiểm tra bằng cách không chuyển giá trị và quan sát giá trị kết quả mà cơ sở dữ liệu lưu trữ. Thử nghiệm này cũng có thể bao gồm kiểm tra các cột Nullable. Điều này hiếm khi yêu cầu kiểm tra vì nó có thể được xác minh từ DDL trừ khi một chỉ mục duy nhất được xây dựng trên cột.

Quy tắc tồn tại giá trị

Theo tôi hiểu điều này, bạn xác minh rằng dữ liệu được chèn hoặc cập nhật hiển thị như mong đợi trong cơ sở dữ liệu.

Quy tắc giá trị hàng

Tôi không rõ chính xác điều này có nghĩa là gì.

Quy tắc kích thước

Mỗi cột có kích thước trong cơ sở dữ liệu dựa trên cách xác định trong DDL. bạn muốn đảm bảo rằng bất kỳ giá trị nào phù hợp với yêu cầu (GUI dạng đã nhập hoặc dẫn đến đầu ra của một tính toán) sẽ được lưu trữ chính xác trong cột. Ví dụ, loại dữ liệu Số nguyên nhỏ không cho phép bạn lưu trữ giá trị 5 tỷ. Ngoài ra, tên được xác định là VARCHAR2 (30) sẽ không chứa 40 ký tự, vì vậy các quy tắc kinh doanh phải rất rõ ràng ở đây, đặc biệt khi cột được sử dụng để tổng hợp dữ liệu. Bạn muốn kiểm tra những gì xảy ra trong những tình huống như vậy.

hướng dẫn về cách / nơi bắt đầu

Một cách để làm điều này là đưa ra một kế hoạch thử nghiệm. Bạn muốn đảm bảo rằng bạn đang sử dụng phiên bản chính xác của thông số kỹ thuật (như tài liệu yêu cầu và Trường hợp sử dụng) và của phần mềm. Bạn cũng cần phối hợp các bài kiểm tra với các bài kiểm tra được thực hiện bởi Kiểm thử đơn vị (nếu có). Bạn có thể tìm thấy các bài kiểm tra trùng lặp mà bạn không cần phải thực hiện lại. Bạn muốn lấy một bản sao của cơ sở dữ liệu trước khi thử nghiệm để bạn có thể lặp lại một thử nghiệm cụ thể nếu bạn cần. DBA có thể giúp bạn với điều này. Bạn cũng cần kiểm tra với nhóm của mình cách họ ghi lại các bài kiểm tra và xác minh phạm vi kiểm tra với họ. Bạn có thể chia cơ sở dữ liệu của mình thành các phần logic và bắt đầu kiểm tra từng phần logic riêng biệt. Quá trình thử nghiệm có thể bắt đầu bằng cách nghiên cứu DDL của cơ sở dữ liệu và xác minh rằng các cột được xác định chính xác theo yêu cầu của doanh nghiệp. Bạn nên sử dụng phần mềm của ứng dụng chứ không phải bất kỳ công cụ nào khác để thực hiện phần lớn các bài kiểm tra. Ví dụ câu hỏi như sau:

  • Là cột được cho là thuộc loại đã xác định (không có điểm nào trong việc đặt tên là Int).

  • Là kích thước tương thích với các yêu cầu kinh doanh?

  • Có phải tất cả các cột trong yêu cầu kinh doanh được tìm thấy trong cơ sở dữ liệu?

  • Các cột null thực sự là tùy chọn?

  • Vân vân.

Tiếp theo, bạn có thể thiết kế các trường hợp thử nghiệm để kiểm tra ở trên. Bạn có thể sử dụng GUI để thực hiện hầu hết các bài kiểm tra.

Có những bài kiểm tra cơ sở dữ liệu quan trọng khác mà bạn chưa đề cập. Những người đối phó với:

1 - Kiểm tra các khóa chính thực sự độc đáo từ góc độ kinh doanh.

2 - Kiểm tra các chỉ mục duy nhất (trừ PK) thực sự độc đáo theo quan điểm kinh doanh.

3 - Kiểm tra các ràng buộc khóa ngoài.

4 - Kiểm tra những gì xảy ra khi một hàng bị xóa và ảnh hưởng của nó đến các hàng liên quan.

5 - Các thử nghiệm khác liên quan đến các cấu trúc cơ sở dữ liệu đặc biệt như CHEKC, Triggers nếu chúng tồn tại.

6 - Chuẩn hóa bảng đúng và các cột được chuẩn hóa giữ các giá trị đúng.

Trên đây không phải là một danh sách đầy đủ nhưng nó sẽ giúp bạn bắt đầu.


Cảm ơn bạn đã chi tiết trong câu trả lời của bạn và đề xuất của bạn để phát triển thử nghiệm có vẻ như là một nơi tốt để bắt đầu. Cảm ơn bạn đã giúp đỡ.
Kristen D.

KristenD. @Songo Tôi đánh giá cao phản hồi.
NoChance

1

Tôi nghĩ rằng bạn đang tiếp cận điều này sai cách.

Bất kỳ cơ sở dữ liệu nào tôi biết đều xác minh dữ liệu trước khi chèn nó vào các bảng - nó xác nhận dữ liệu theo định nghĩa của từng cột. Bạn không thể nhập chuỗi 80 ký tự vào cột SMALLINT (3) - cơ sở dữ liệu sẽ thất bại trong lần thử đó và cho bạn biết bạn đã mắc lỗi. Bạn không cần phải tự kiểm tra bằng cách chèn dữ liệu và sau đó truy xuất dữ liệu.

Những gì bạn muốn có là xác thực / quy tắc lọc trên dữ liệu trước khi nó được gửi đến cơ sở dữ liệu.

  • Đảm bảo dữ liệu phù hợp với các loại và phạm vi được chấp nhận cho từng cột và lọc nội dung không mong muốn
  • Đảm bảo thoát đúng cách để tránh lỗi (và có thể tiêm SQL nếu bạn có giao diện chung)

Các quy tắc xác thực / lọc sẽ chạy trên dữ liệu trong ứng dụng thực tế của bạn. Sau đó, bạn có thể thiết lập các kiểm tra để đảm bảo rằng chúng là chính xác, bằng cách cung cấp cho nó dữ liệu chính xác và không chính xác để đảm bảo rằng nó vượt qua hoặc không xác nhận hợp lệ.

Theo như thiết kế cơ sở dữ liệu, bạn thực sự không thể xác minh nó bằng các thử nghiệm - vì nhiều thiết kế sẽ hoạt động ngay cả khi chúng không lý tưởng (và định nghĩa về thay đổi lý tưởng giữa những người khác nhau). Thiết kế cơ sở dữ liệu phù hợp đi kèm với kinh nghiệm và kiến ​​thức, không phải với các bài kiểm tra tự động.


Tôi thấy bạn đến từ đâu và tôi hoàn toàn có ý định tạo và kiểm tra các bộ lọc xác thực dữ liệu trước khi nó truy cập vào cơ sở dữ liệu, nhưng trong câu hỏi này, ý định chính của tôi là thử xác minh thiết kế cơ sở dữ liệu (càng nhiều càng tốt trước đây sử dụng nó) và cũng xác minh rằng những gì thực sự đang hoạt động như dự định (ví dụ: đảm bảo các ràng buộc khóa ngoại không bị phá vỡ như @EmmadKareem đã đề cập trong câu trả lời của anh ấy. Cảm ơn bạn đã đưa ra xác thực dữ liệu mặc dù nó rất hợp một phần của bất kỳ ứng dụng nào sử dụng cơ sở dữ liệu.
Kristen D.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.