Kiểm thử cơ sở dữ liệu bao gồm kiểm thử dữ liệu hiện tại và tính toàn vẹn của cơ sở dữ liệu, nhằm đảm bảo dữ liệu không bị hỏng và các sơ đồ cơ sở dữ liệu là đúng đắn, cũng nhƣ kiểm thử chức năng của các ứng dụng cơ sở dữ liệu (ví dụ các thành phần Transact-SQL). Script SQL thƣờng đƣợc sử dụng để kiểm thử cơ sở dữ liệu. Không phải tất cả các cơ sở dữ liệu đều là cơ sở dữ liệu SQL, nhƣng hầu hết đều hỗ trợ SQL, cũng nhƣ hầu hết đều là các ứng dụng Web.
Kiểm thử có thể đƣợc áp dụng tại nhiều điểm của tƣơng tác. Hình 14.10 chỉ ra hỏng hóc có thể xuất hiện tại nhiều điểm của tƣơng tác. Các script hay chƣơng trình
Khoa Công Nghệ Thông Tin Đại Học Công Nghệ - Đại Học Quốc Gia Hà Nội
Học viên: Nguyễn Thị Ngọc Hƣơng
phía trình khách, các script hay chƣơng trình phía trình chủ, các dịch vụ truy cập cơ sở dữ liệu, các thủ tục lƣu trữ, các trigger và dữ liệu đƣợc lƣu trữ trong các bảng cơ sở dữ liệu. Nhƣ thế, kiểm thử có thể và nên đƣợc áp dụng tại nhiều điểm của tƣơng tác. Mặc dù các script phía trình khách và trình chủ là độc lập với các thủ tục lƣu trữ và dữ liệu, các script hay chƣơng trình tƣơng tác với các thủ tục lƣu trữ đóng vai trò quan trọng. Chúng đƣợc sử dụng để hợp lý hóa và xử lý lỗi dữ liệu vào ra[8]
Hình 3.22 Các điểm tƣơng tác
3.5.1. Các phƣơng pháp kiểm thử hộp trắng
Kiểm tra mã nguồn (Code walk-through):Kiểm tra mã nguồn là một phƣơng
pháp hiệu quả để xác định lỗi ở mức mã nguồn. Phƣơng pháp này không chỉ sử dụng cho kiểm thử cơ sở dữ liệu. Nó đã đƣợc sử dụng cho nhiều ngôn ngữ lập trình. Đó là một tiến trình thẩm định ngang hàng mà trong đó tác giả mã nguồn hƣớng dẫn các lập trình viên khác xem xét toàn bộ mà nguồn từng dòng một. Những ngƣời đọc mã nguồn đƣợc khuyến khích chỉ ra những gì không hiệu quả, dƣ thừa, không phù hợp, hay mã nguồn không tốt mà họ thấy. Mục đích của ngƣời đọc mã nguồn là xem xét một cách cẩn thận mã nguồn cần đƣợc thẩm định và xác định càng nhiều lỗi càng tốt. Kiểm tra mã nguồn hữu hiệu khi phƣơng pháp kiểm thử hộp đen không thể áp dụng đối với các thủ tục lƣu trữ ở mức kiểm thử đơn vị và khi việc gỡ rối chƣơng trình không thể xác định đƣợc các lỗi lô-gíc trong chƣơng trình.[8]
Thực thi các lệnh SQL mỗi lần một lệnh:Có thể kiểm thử các thủ tục lƣu trữ
bằng cách thực thi các lệnh SQL mỗi lệnh một lần so với kết quả đã biết. Kết quả sau đó sẽ đƣợc hợp thức hóa bởi kết quả đặc tả. Phƣơng pháp này tƣơng tự nhƣ kiểm thử đơn vị. Lợi ích chính của phƣơng pháp này là lỗi khi đƣợc phát hiện, chỉ cần sự phân tích đơn giản để sửa lỗi. Nhƣợc điểm là phƣơng pháp này rất nhàm chán và chi phí nhân công cao.
Thực thi các thủ tục lưu trữ mỗi lần một thủ tục:Các thủ tục lƣu trữ thƣờng
nhận các tham số vào và chứa các lô-gíc điều khiển. Đôi khi, chúng gọi các thủ tục khác hoặc hàm ở bên ngoài. Nhƣ thế, những sự phụ thuộc tham số vào và lô-gíc điều khiển cần phải đƣợc xem xét khi kiểm thử thủ tục lƣu trữ. Phƣơng pháp kiểm thử này tƣơng tự nhƣ kiểm thử các hàm. Đối với mỗi thủ tục lƣu trữ, phân tích kiểu dữ liệu và
Khoa Công Nghệ Thông Tin Đại Học Công Nghệ - Đại Học Quốc Gia Hà Nội
Học viên: Nguyễn Thị Ngọc Hƣơng
ràng buộc của mỗi tham số vào: giá trị trạng thái trả về đƣợc định nghĩa bởi ngƣời dùng và mã nguồn lô-gíc điều khiển trong thủ tục lƣu trữ. Để kiểm thử một thủ tục lƣu trữ, hãy gọi nó với không bản ghi nào cả và với một số rất lớn các bản ghi. Kiểm thử một cơ sở dữ liệu với chỉ một ít bản ghi hoàn toàn khác với khi cơ sở dữ liệu đƣợc nạp đầy với các dữ liệu thực.
Thiết kế các ca kiểm thử bao gồm cả các kiểu dữ liệu hợp lệ và không hợp lệ. Hơn nữa, áp dụng kiểm thử lớp tƣơng đƣơng và điều kiện giới hạn biên khi thiết kế các tham số vào.
Kiểm thử trigger: Kiểm thử viên cần phải xác định tất cả các trigger nhƣ một
phần của ứng dụng. Sau đó, chúng ta phân tích và phân loại các điều kiện mà trigger sẽ đƣợc thực thi. Kiểm thử viên phải hiểu công việc mỗi trigger thực hiện. Các kiểm thử viên phải viết và thực thi các lệnh SQL hoặc thủ tục lƣu trữ để tạo ra các điều kiện và hợp thức hóa kết quả đƣợc đặc tả.
Giao diện bên ngoài: Phân tích các ca kiểm thử của phƣơng pháp này tƣơng tự
các phƣơng pháp kiểm thử hộp trắng, hộp đen. Tuy nhiên, thay vì thực thi mỗi thủ tục lƣu trữ, các thủ tục lƣu trữ đƣợc gọi từ các chức năng của ứng dụng bên ngoài. Các ứng dụng Web cung cấp cho ngƣời dùng một giao diện trình duyệt qua đó họ có thể truy cập và xử lý các bản ghi dữ liệu. Các lệnh SQL đƣợc gửi đến cơ sở dữ liệu thƣờng đƣợc xây dựng bởi chèn các dữ liệu cung cấp bởi ngƣời dùng vào trong các trƣờng của lệnh SQL. Trừ khi dữ liệu đến từ trình duyệt Web đƣợc kiểm tra trƣớc khi gửi đến cơ sở dữ liệu, một lệnh SQL hay một thủ tục lƣu trữ có thể tạo ra kết quả không mong đợi do lỗi dữ liệu.
3.5.2. Các phƣơng pháp kiểm thử hộp đen
Thiết kế ca kiểm thử:Sử dụng phƣơng pháp kiểm thử hộp đen truyền thống,
các ca kiểm thử đƣợc thực thi phía trình khách. Các đầu vào đƣợc nhập vào trên trang Web, và dữ liệu đƣợc gửi đến cơ sở dữ liệu ở bên trong qua giao diện trình duyệt Web. Kết quả đƣợc gửi trả lại trình duyệt, sau đó đƣợc kiểm tra so với giá trị mong đơi. Phƣơng pháp này cũng có những hạn chế sau:
Đôi khi kết quả đƣợc gửi đến trình duyệt sau khi thực thi ca kiểm thử không nhất thiết chỉ ra rằng dữ liệu đƣợc ghi một cách đúng đắn vào một bản ghi trong bảng.
Khi kết quả lỗi đƣợc gửi trả lại trình duyệt sau khi thực thi ca kiểm thử, nó chƣa chắc đã phải là lỗi của cơ sở dữ liệu. Các phân tích sâu hơn nữa sẽ đƣợc yêu cầu để xác định chính xác nguyên nhân lỗi.
Khoa Công Nghệ Thông Tin Đại Học Công Nghệ - Đại Học Quốc Gia Hà Nội
Học viên: Nguyễn Thị Ngọc Hƣơng
Kiểm thử lô-gíc giao dịch: Các hành động cơ bản là những công việc cần đƣợc
thực hiện nhƣ là một hành động đơn. Nếu bất kỳ một trong các hành động này không thể thực hiện đƣợc, giao dịch cần phải không thực hiện các cập nhật khác.
Kiểm thử vấn đề cạnh tranh: Nhiều vấn đề cạnh tranh có thể tồn tại. Một khóa
chết (deadlock) tồn tại khi hai hay nhiều ngƣời dùng khóa cùng các bản ghi.
Kiểm thử với một cơ sở dữ liệu sạch: Script cài đặt thƣờng chứa các lệnh SQL
đƣợc sử dụng để tạo cơ sở dữ liệu, tạo bảng, phƣơng thức xem, cài đặt thủ tục lƣu trữ, và nhập dữ liệu ban đầu vào các bản ghi. Phụ thuộc vào độ phức tạp của sơ đồ dữ liệu và ứng dụng, script có thể dài hoặc ngắn. Trong tiến trình phát triển , thông thƣờng script này hay thay đổi để đáp ứng các yêu cầu cài đặt cụ thể. Kiểm thử lặp lại tiến trình cài đặt trên các cơ sở dữ liệu hoàn toàn sạch sẽ đƣợc yêu cầu nhằm đảm bảo rằng không có hiệu ứng phụ đƣợc tạo ra bởi sự thay đổi