Tìm hiểu về Database(Data) Testing

Các hệ thống quản lý cơ sở dữ liệu quan hệ thường vẫn còn là nhiệm vụ quan trọng đối với dữ liệu mà được cập nhật bởi nhiều ứng dụng và có hàng ngàn, hàng triệu người dùng cuối tiềm năng sử dụng. Hơn thế nữa, họ thực thi chức năng quan trọng với nhiều loại phương pháp CSDL (database) (như stored procedures, stored functions, và/hoặc triggers) và các đối tượng CSDL. Một số quan điểm nói lên kiểm thử dữ liệu quan trọng là:

1. Ứng dụng lưu trữ thông tin giao dịch trong cơ sở dữ liệu ứng dụng và hiển thị chúng một cách chính xác cho người dùng.
2. Không có thông tin nào bị mất trong tiến trình xử lý.
3. Không có thông tin nào thực hiển một phần hoặc bị hủy bỏ bởi ứng dụng.
4. Không có người dùng nào không có quyền truy cập được phép truy cập vào thông tin người dùng. => Để đảm bảo cho các mục tiêu trên chúng ta cần phải sử dụng xác nhận dữ liệu và kiểm thử dữ liệu. Vậy như thế nào gọi là kiểm trử dữ liệu?

Kiểm thử cơ sở dữ liệu là đi vào kiểm tra biểu đồ, các bảng hay thực thi các câu lệnh như insert, update, delete,...của cơ sở dữ liệu được kiểm tra. Nó có thể liên quan đến việc tạo các truy vấn phức tạp để kiểm thử load/stress test và kiểm tra phản hổi của nó. Nó kiểm tra tính toàn vẹn và tính nhất quán của dữ liệu. Chúng ta sẽ đi vào tìm hiểu các mục chính sau:

• Sự khác biệt cơ bản giữa kiểm thử giao diện người dùng và dữ liệu.
• Các kiểu kiểm thử dữ liệu
• Schema testing
• Kiểm thử bảng, cột dữ liệu
• Stored procedure testing
• Trigger testing
• Database server validations
• Functional database testing
• Login and user security
• Load testing
• Stress testing

Có 3 kiểu kiểm thử dữ liệu đó là:

• Structural testing
• Functional testing
• Non-Functional testing

Cấu trúc kiểm thử dữ liệu bao gồm việc xác nhận tính hợp lệ của kho dữ liệu được sử dụng chủ yếu để lưu trữ dữ liệu và không cho người dùng cuối thao tác trực tiếp. Việc xác nhận sự hợp lệ của database server cũng là sự cân nhắc quan trọng trong các loại kiểm thử này.

Khía cạnh chính của Schema testing là đảm bảo rằng việc lậplược đồ giữa front end và back end là giống nhau. Do đó, chúng ta cũng có thể tham khảo schema testing như là mappong testing. Hãy thảo luận về một số checkpoints quan trọng trong schema testing.

• Xác nhận các định dạng schema khác nhau liên kết với cơ sở dữ liệu. Nhiều định dạng mapping của bảng có thể không tương ứng với định dạng mapping có trong giao diện người dùng của ứng dụng.
• Có nhu cầu xác minh trong trường hợp các bảng / khung nhìn / cột chưa được ghép nối.
• Cũng cần phải xác minh xem cơ sở dữ liệu không đồng nhất trong một môi trường có phù hợp với ứng dụng mapping tổng thể.

Chúng ta hãy cùng xem xét một số công cụ thú vị để xác nhận các lược đồ cơ sở dữ liệu.

• DBUnit được tích hợp với Ant rất phù hợp cho việc lập bản đồ thử nghiệm.
• SQL Server cho phép người kiểm tra có thể kiểm tra và truy vấn lược đồ của cơ sở dữ liệu bằng cách viết các câu truy vấn đơn giản và không thông qua mã code. Ví dụ: nếu các nhà phát triển muốn thay đổi cấu trúc bảng hoặc xóa nó, người kiểm tra sẽ muốn đảm bảo rằng tất cả các Srored Procedures và Views được sử dụng bảng tương thích với sự thay đổi đó. Một ví dụ khác có thể là nếu người kiểm tra muốn kiểm tra các thay đổi lược đồ giữa 2 cơ sở dữ liệu, họ có thể làm điều đó bằng cách sử dụng các câu truy vấn đơn giản.

Hãy nhìn vào những điều kiện để kiểm thử database và column

• Cho dù việc lập bản đồ các trường cơ sở dữ liệu và cột trong back end là tương thích với trong front end.
• Xác nhận độ dài và quy ước đặt tên của các trường trong cơ sở dữ liệu và các cột theo chuẩn yêu cầu.
• Xác nhận sự hiện diện của bất kỳ bảng / cột cơ sở dữ liệu không sử dụng / chưa được khai thác.
• Xác nhận tính tương thích của:
  • Kiểu dữ liệu
  • Độ dài trường của các cột cơ sở dữ liệu back end với các cột dữ liệu front end của ứng dụng.
• Cho dù các trường cơ sở dữ liệu cho phép người sử dụng cung cấp đầu vào mà người dùng mong muốn theo yêu cầu của tài liệu yêu cầu kinh doanh. Keys và indexes testing: Điều kiện quan trọng cho keys và indexes:
• Kiểm tra xem yêu cầu các ràng buộc đã được tạo ra trên các bảng yêu cầu
  • Primary Key
  • Foreign Key
• Kiểm tra xem mối quan hệ giữa các khóa ngoại có hợp lệ
• Kiểm tra xem kiểu dữ liệu của khoá chính và khoá ngoại có tương ứng giống với hai bảng.
• Kiểm tra xem size và length của fields và indexes được yêu cầu.
• Cho dù các yêu cầu:
  • Clustered indexes
  • Non clustered indexes đã từng được tạo ra trong các bảng yêu cầu theo yêu cầu nghiệp vụ.

Danh sách những điều quan trọng về tính hợp lệ cho stored procedures

• CHo dù nhóm phát triển đã chấp nhận yêu cầu:
  • Quy chuẩn conventions
  • Ngoại lệ và xử lý lỗi dành cho tất cả các stored procedures cho tât cả các modules cho ứng dụng đang kiểm thử.
• CHo dù đội phát triển đã bao phủ tất cả điều kiện/vòng lặp bằng cách áp dụng yêu cầu dữ liệu đầu vào cho bảng được yêu cầu cho ưngs dụng đang kiểm thử.
• CHo dù đội phát triển đã hoạt động đúng cách Trim bất cứ khi nào dữ liệu được lấy từ các bảng yêu cầu trong cơ sở dữ liệu.
• CHo dù thực hiện thủ công của Stored Procedure cung cấp cho người dùng cuối với kết quả được yêu cầu.
• Cho dù thực hiện thủ công của Stored Procedure đảm bảo các trường trong bảng được update như yêu cầu cho ứng dụng đang được kiểm thử.
• Cho dù việc thực hiện Stored Procedure cho phép ẩn các triggers được yêu cầu.
• Xác nhận các Stored Procedures không còn được sử dụng thì không hiển thị.
• Xác nhận điều kiện Allow Null có thể được thực hiển ở bất kỳ level database nào.
• Xác nhận thực tế là tất cả các Stored Procedures và Functions được thực thi thành công khi mà cơ sở dữ liệu đang được kiểm thử là rỗng.
• Xác nhận sự tích hợp tổng thể của các module stored procedure theo yêu cầu của ứng dụng đang được kiểm thử. Một vài công cụ hỗ trợ cho kiểm thử stored procedures là công cụ kiểm thử LINQ, SP

• Cho dù conventions coding được yêu cầu đã được tuân theo trong giai đoạn đang code của Triggers.
• Kiểm tra xe các trigger được thực thi cho các giao dịch DML tương ứng đã hoàn thành các điều kiện yêu cầu.
• Cho dù update trigger một cách chính xác khi chúng ta thực thi.
• Xác nhận các hàm update/insert/delete triggers được yêu cầu trong phạm vi ứng dụng đang được kiểm thử.

• Kiểm tra cấu hình database server theo yêu cầu của nghiệp vụ.
• Kiểm tra sự ủy quyền của người dùng được yêu cầu chỉ thực hiện những mức độ hành động mà ứng dụng yêu cầu.
• Kiểm tra xem database server có thể đáp ứng nhu cầu của số lượng tối đa cho phép các giao dịch người dùng như được xác định bởi các yêu cầu kỹ thuật yêu cầu nghiệp vụ.

Việc kiểm thử Functional cơ sở dữ liệu như được xác định bởi yêu cầu đặc điểm kỹ thuật cần đảm bảo hầu hết các giao dịch và hoạt động được thực hiện bởi người dùng cuối là phù hợp với yêu cầu kỹ thuật. Sau đây là các điều kiện cơ bản cần được xem xét để xác nhận cơ sở dữ liệu.

• Cho dù trường đó là bắt buộc khi nhập các giá trị null vào trường đó.
• Cho dù độ dài của mối trường là có kích thước phù hợp ?
• Cho dù tất cả các trường similar có cùng tên với bảng ?
• Cho dù bất kỳ trường computed thực thi trong cơ sở dữ liệu. Qúa trình này xác nhận tính hợp lệ của trường mapping từ quan điểm của người dùng cuối. Trong kịch bản cụ thể của người kiểm thử sẽ thực hiện một hoạt động ở mức cơ bản và tiếp theo sẽ điều hướng tới giao diện người dùng có liên quan để quan sát liệu việc kiểm tra có thích hợp được thực hiện hiện nay hay không? Các điều kiện ngược lại hoạt động đầu tiên được thực hiển bởi người kiểm tra giao diện người dùng và sau đó được xác nhận từ phía back end được coi là một hoạt động hợp lệ.

Một vài case kiểm thử quan trọng:

• Cho dù dữ liệu được tổ chức tốt về mặt logic
• Cho dù các dữ liệu được lưu trữ trong các bảng là chính xác và theo yêu cầu nghiệp vụ.
• Cho dù có bất kỳ dữ liệu không cần thiết nào trong ứng dụng đang được kiểm thử. ho dù dữ liệu đã được lưu trữ theo yêu cầu đối với dữ liệu đã được cập nhật từ giao diện người dùng.
• Cho dù các hoạt động TRIM thực hiện trên dữ liệu trước khi chèn dữ liệu vào cơ sở dữ liệu đang được kiểm thử.
• Cho dù các giao dịch đã được thực hiện theo yêu cầu nghiệp vụ yêu cầu kỹ thuật và cho dù kết quả là chính xác hay không.
• Cho dù dữ liệu đã được cam kết đúng cách nếu giao dịch đã được thực hiện thành công theo yêu cầu nghiệp vụ.
• Cho dù dữ liệu đã được sao lưu thành công hay không nếu giao dịch không được người dùng cuối thực hiện thành công.
• Cho dù dữ liệu đã được sao lưu được sao lưu ở điều kiện giao dịch chưa được thực hiện thành công hay không và nhiều cơ sở dữ liệu không đồng nhất đã tham gia vào giao dịch được đề cập.
• Cho dù tất cả các giao dịch đã được thực hiện bằng cách sử dụng các thủ tục thiết kế yêu cầu theo yêu cầu nghiệp vụ của hệ thống.

Việc xác nhận thông tin đăng nhập và bảo mật của người dùng cần phải tính đến những điều sau:

• Cho dù ứng dụng không cho phép người dùng tiếp tục thực thi trong ứng dụng trong trường hợp:
  • tên người dùng không hợp lệ nhưng mật khẩu hợp lệ
  • tên người dùng hợp lệ nhưng mật khẩu không hợp lệ.
  • tên người dùng không hợp lệ và mật khẩu không hợp lệ.
  • tên người dùng hợp lệ và mật khẩu hợp lệ.
• Cho dù người dùng chỉ được phép thực hiện những hoạt động cụ thể được xác định bởi các yêu cầu nghiệp vụ.
• Cho dù dữ liệu được bảo vệ khỏi truy cập trái phép
• Cho dù có vai trò người dùng khác nhau được tạo bằng các quyền khác nhau
• Cho dù tất cả người dùng đã yêu cầu cấp quyền truy cập vào Cơ sở dữ liệu được chỉ định theo yêu cầu của các đặc điểm nghiệp vụ.
• Kiểm tra dữ liệu nhạy cảm như mật khẩu, số thẻ tín dụng được mã hóa và không được lưu trữ dưới dạng văn bản thuần túy trong cơ sở dữ liệu. Đó là một thực tế tốt để đảm bảo tất cả các tài khoản phải có mật khẩu phức tạp và không dễ đoán.

Non-functional testing trong bối cảnh kiểm thử cơ sở dữ liệu có thể được phân loại thành các loại khác nhau theo yêu cầu nghiệp vụ. Nó có thể là: load testing, stress testing, security testing, usability testing và compatibility testing và còn một số loại khác nữa. Load testing nó cũng tương tự như stress testing nó có thể được nhóm lại theo phạm vi kiểm thử hiệu suất phục vụ hai mục đích cụ thể khi nói đến vai trò của kiểm thử non-functional.

Mục đích của load testing phải được clear và hiểu rõ tài liệu docs. Các loại cấu hình cần thiết để Kiểm thử Load :

• Các giao dịch người dùng được sử dụng thường xuyên nhất có thể ảnh hưởng đến hiệu suất của tất cả các giao dịch khác nếu chúng không hiệu quả.
• Ít nhất một giao dịch người dùng không chỉnh sửa phải được bao gồm trong bộ kiểm thử cuối cùng, do đó hiệu suất của các giao dịch đó có thể được phân biệt với các giao dịch phức tạp khác.
• Các giao dịch quan trọng hơn nhằm tạo thuận lợi cho các mục tiêu chính của hệ thống cần được đưa vào, vì theo định nghĩa, sự thất bại trong các giao dịch này đã ảnh hưởng lớn nhất.
• Cần phải có ít nhất một giao dịch có thể chỉnh sửa để có thể phân biệt được các giao dịch đó với các giao dịch khác.
• Việc quan sát thời gian đáp ứng tối ưu với số lượng lớn người dùng ảo cho tất cả các yêu cầu tương lai.
• Việc quan sát thời gian hiệu quả để tìm kiếm các bản ghi khác nhau. Công cụ kiểm thử load quan trọng là load runner, win runner và JMeter.

Stress testing còn được gọi là torturous testing vì nó nhấn mạnh ứng dụng đang được kiểm thử với khối lượng lớn công việc mà hệ thống không thành công. Điều này giúp xác định các lỗi của hệ thống. Một số công cụ kiểm thử stress quan trọng như là: loaod runner, win runner và JMeter.

Nguồn: https://www.guru99.com/data-testing.html