1.0K 71 18

Đã đăng vào thg 12 2, 2015 12:51 SA 38 phút đọc

14.8K

Database Testing

Bài đăng này đã không được cập nhật trong 2 năm

Như chúng ta đã biết, Database chính là trái tim của một chương trình phần mềm. Để sản phẩm phần mềm của chúng ta chạy tốt thì trước tiên phải đảm bảo được chất lượng của Database theo các yêu cầu của hệ thống.

Vì vậy việc test Database là rất cần thiết và vô cùng quan trọng.

I. Database Testing là gì?

Database Testing là quá trình kiểm tra độ chính xác và tính toàn vẹn của cơ sở dữ liệu (CSDL). Đảm bảo rằng các dữ liệu là chính xác và duy nhất. Những lỗi sau đây của CSDL có thể gây ra một số vấn đề nghiêm trọng: deadlock, hỏng dữ liệu, hiệu suất kém, không thống nhất, vv...

Database Testing gồm hai loại:

Kiểm thử dữ liệu thực (Actual Data Testing): Là kiểm tra nội dung của dữ liệu có chính xác hay không. Ví dụ: yêu cầu đặt ra là một trang web phải không có các clip vi phạm thuần phong mỹ tục, clip bạo lực => Việc Testing cũng phải đảm bảo được điều đó (sau khi đưa trang web vào vận hành).
Kiểm thử ràng buộc dữ liệu (Database Integrity Testing): Là các hoạt động kiểm thử nhằm đảm bảo dữ liệu không bị hỏng, các schema dữ liệu là đúng đắn và các chức năng của các ứng dụng CSDL hoạt động đúng.

II. Vì sao cần phải thực hiện Database Testing ?

Thực hiện Database Testing giúp đảm bảo các vấn đề sau:

1.Đảm bảo tính thống nhất của dữ liệu (Data mapping)

・Là việc xác định dữ liệu của một bảng này tương ứng với dữ liệu nào trong bảng khác.

・Vấn đề này có ý nghĩa quan trọng trong các quá trình:

Di chuyển dữ liệu: Cần biết dữ liệu tương ứng với dữ liệu nào ở database mới để di chuyển chính xác.
Phân tích dữ liệu: Phân tích sự liên kết giữa các dữ liệu. Ví dụ: phân tích các thông tin cá nhân được mã hóa lưu trữ trong 4 số cuối của số Chứng minh thư nhân dân (data masking)
Hợp nhất các dữ liệu: Khi hợp nhất dữ liệu từ nhiều database khác nhau, cần biết dữ liệu nào tương ứng với dữ liệu nào để nhận dạng dữ liệu dư thừa và xóa đi (nếu cần thiết) Chi tiết tham khảo tại: https://en.wikipedia.org/wiki/Data_mapping

2.Đảm bảo các thuộc tính ACID (ACID properties)

Là việc đảm bảo các tính chất của CSDL bao gồm:

・Tính nguyên tố (Atomicity): Một giao dịch có nhiều thao tác khác biệt thì hoặc là toàn bộ các thao tác hoặc là không một thao tác nào được hoàn thành. Chẳng hạn việc chuyển tiền có thể thành công hay trục trặc vì nhiều lý do nhưng tính nguyên tố bảo đảm rằng một tài khoản sẽ không bị trừ tiền nếu như tài khoản kia chưa được cộng số tiền tương ứng. .

・Tính nhất quán (Consistency): Một giao dịch hoặc là sẽ tạo ra một trạng thái mới và hợp lệ cho dữ liệu, hoặc trong trường hợp có lỗi sẽ chuyển toàn bộ dữ liệu về trạng thái trước khi thực thi giao dịch.

・Tính độc lập (Isolation): Một giao dịch đang thực thi và chưa được xác nhận phải bảo đảm tách biệt khỏi các giao dịch khác.

・Tính bền vững (Durability): Dữ liệu được xác nhận sẽ được hệ thống lưu lại sao cho ngay cả trong trường hợp hỏng hóc hoặc có lỗi hệ thống, dữ liệu vẫn đảm bảo trong trạng thái chuẩn xác.

Ý nghĩa: Đảm bảo các tính chất ACID để tránh trường hợp dữ liệu tại các bước của một giao dịch không khớp, không liên kết với nhau dẫn đến tình trạng thất thoát hoặc sai dữ liệu.

Chi tiết tham khảo tại: https://en.wikipedia.org/wiki/ACID

3.Đảm bảo tính toàn vẹn dữ liệu (Data Integrity)

・Là việc duy trì và đảm bảo tính chính xác và nhất quán của dữ liệu trên toàn bộ vòng đời của nó, và là một khía cạnh quan trọng đối với việc thiết kế, thực hiện và ứng dụng của bất kỳ hệ thống nào có thể lưu trữ, xử lý, hoặc lấy dữ liệu.

・Mục đích là đảm bảo dữ liệu được ghi lại một cách chính xác như mong muốn, nhằm ngăn chặn những thay đổi có chủ ý đến các thông tin.

Chi tiết tham khảo tại: https://en.wikipedia.org/wiki/Data_integrity

4.Đảm bảo tuân thủ quy tắc kinh doanh (Bussiness rule conformity)

・Có thể sử dụng quy tắc kinh doanh để cung cấp sự kiểm soát chính xác và nhất quán trong quá trình truy cập dữ liệu của ứng dụng của bạn.

・Quy tắc kinh doanh thường tập trung vào các vấn đề về kiểm soát truy cập (mỗi role của user được quy định có những quyền truy cập, hoạt động khác nhau...), tính toán kinh doanh (tính rate truy cập, tính % tham gia 1 khóa học...) và các chính sách của cơ quan tổ chức (trong trường hợp nào thì user bị khóa, bị xóa, bị cảnh cáo...).

Ví dụ: Đối với 1 web học trực tuyến:

Quy tắc kinh doanh về vấn đề kiểm soát truy cập.

Ví dụ: Thầy giáo được phép nhập vào và sửa đổi các thông tin của học sinh mà tham dự buổi học của họ, nhưng ko được thay đổi thông tin của các học sinh tham dự các buổi học khác.

Quy tắc kinh doanh về tính toán kinh doanh.

Ví dụ: Cách tính % tỉ lệ học sinh tham gia học, cách tính trung bình điểm đánh giá khóa học.

Một số quy tắc kinh doanh về các chính sách của tổ chức.

Ví dụ: Học sinh nào thì bị đình chỉ học (không tham gia thi 2 khóa).

Chi tiết tham khảo tại: https://msdn.microsoft.com/en-us/library/aa291582(v=vs.71).aspx

III. Các nội dung cần kiểm tra khi thực hiện Database Testing

A.Kiểm tra tính hợp lệ của cơ sở dữ liệu

1.Datatype: varchar, nvarchar, ntext:

1.1. Kiểm tra Maxlength

1.2. Phân biệt chữ hoa/chữ thường

1.3. Phân biệt 全角/半角 (full-size / half size)

1.4. Phân biệt ký tự unicode

1.5. Cho phép null hay không

1.6. Cho phép nhập ký tự đặc biệt hay không?

Một số ví dụ cụ thể

_1. Kiểm tra Maxlength: _

Giả sử DB setting giá trị cột Name là vachar (20)

Nhập 1~20 ký tự thì TRUE, nhập 0 và 21 ký tự thì FALSE

PP1: Check trên GUI

Mở màn hình giao diện, input các giá trị 0, từ 1~20, 21 ký tự vào trường cần check và Submit

=> Confirm kết quả xử lý thành công hay thất bại, có theo đúng nội dung mô tả trong spec không

=> Confirm kết quả lưu trữ trong database, nếu thất bại thì có bị lưu vào không, nếu thành công thì dữ liệu lưu trữ vào database có đúng với dữ liệu đã được input trên GUI không

Dùng lệnh SELECT để lấy ra bản ghi có string vừa input => view kết quả đã được lưu trữ vào trong DB có chính xác không

PP2: Dùng câu lệnh insert dữ liệu vào trong database. Thực hiện với import với dữ liệu 0, 1~20, 21 ký tự.

INSERT INTO Users (UserName) VALUES ('Abcdef Abcdef AbcdefH');

Kết quả: Nếu kết quả trả về khi Nhập 1~20 ký tự thành công. Nhập 0 hoặc 21 ký tự trở lên mà báo lỗi thì testcase PASS

2 . Phân biệt chữ hoa / chữ thường

PP1: Check trên GUI

Mở màn hình giao diện, input dữ liệu toàn chữ hoa, toàn chữ thường, hoặc có cả chữ hoa chữ thường vào trường cần check và save lại

=> Confirm kết quả xử lý thành công hay thất bại

=> Confirm kết quả lưu trữ trong database (Dùng lệnh SELECT để lấy ra bản ghi có string vừa input => view kết quả đã được lưu trữ vào trong DB)

PP2: Check bằng câu Select hoặc insert để check kiểu dữ liệu được lưu trữ vào trong 1 trường trong DB

Ví dụ như khi thực hiện import một lượng dữ liệu lớn trực tiếp trong database hoặc trên GUI, sau đó cần confirm một trường nào đó chỉ tồn tại các ký tự hoa (hoặc ký tự thường) theo đúng quy định kiểu dữ liệu.

Ví dụ:

Check trong bảng employee, trường first_name_eng xem toàn bộ các dữ liệu đang được lưu trữ trong trường này có bị có dữ liệu nào không phải toàn bộ là ký tự hoa không

SELECT * from employee WHERE UPPER(first_name_eng) <> first_name_eng;

Check trong bảng employee, trường first_name_eng xem toàn bộ các dữ liệu đang được lưu trữ trong trường này có bị có dữ liệu nào không phải toàn bộ là ký tự thường không

SELECT * from employee WHERE LOWER(first_name_eng) <> first_name_eng;

<Đã sử dụng MySQL Workbench 6.1>

3 . Phân biệt 全角/半角 (full-size / half size)

PP1: Check trên GUI Mở màn hình giao diện, input dữ liệu

Toàn chữ full-size
Toàn chữ half-size
Dữ liệu có cả chữ full-size & half size

vào trường cần check và save lại

=> Confirm kết quả xử lý thành công hay thất bại

=> Confirm kết quả lưu trữ trong database (Dùng lệnh SELECT để lấy ra bản ghi có string vừa input => view kết quả đã được lưu trữ vào trong DB)

PP2: Check bằng câu Select hoặc insert trong database:

Không thể phân biệt được full-size với half-size trực tiếp trong Database nên không thể dùng query để check trong DB được.

4 . Phân biệt ký tự Unicode

PP1: Check trên GUI

Mở màn hình giao diện, input dữ liệu có ký tự unicode vào trường cần check và save lại

=> Confirm kết quả xử lý thành công hay thất bại trên GUI (các màn hình liên quan có hiển thị Unicode string này)

PP2: Dùng câu lệnh insert để xác định dữ liệu được import thành công hay không

1.Insert thành công => case này confirm được kiểu dữ liệu của field có support Unicode. (thiết kế DB đúng)

INSERT INTO Users (UserName, NickName) VALUES(N'Nguyễn Văn Hiệp', N'Lữ Gia')

Kết quả: Xác nhận Chuỗi Unicode được lưu đúng vào database.

2.Mở màn hình giao diện, input dữ liệu có ký tự unicode vào trường cần check và save lại

=> Confirm kết quả xử lý thành công hay thất bại trong Database bằng câu lệnh SELECT Nếu ký tự Unicode không bị vỡ font là OK. Ý nghĩa: Case này confirm được xử lý "Thêm mới" trong code là đúng.

5 . Cho phép null hay không

PP1: Check trên GUI Mở màn hình giao diện, input dữ liệu NULL vào các trường Require và save lại

=> Confirm kết quả xử lý thành công hay thất bại, có theo đúng nội dung mô tả trong spec không

PP2: Dùng câu lệnh insert để xác định dữ liệu được import thành công hay không

INSERT INTO Users (UserName, NickName) VALUES(NULL, 'Kumori')

Kết quả: Nếu FALSE thì chứng tỏ không thể nhập NULL vào trường UserName

Chúng ta có thể check xem giá trị NULL ở một trường nào đó bằng câu lệnh SELECT

SELECT * FROM tcount_tbl WHERE tutorial_count IS NULL;

hoặc

SELECT * from tcount_tbl WHERE tutorial_count IS NOT NULL;

2.Datatype: int, tinyint, float

2.1. Kiểm tra maxlength. Và đảm bảo các ký tự đều không bị cắt.

2.2. Kiểm tra giá trị max, min

2.3. Có cho phép nhập ký tự chữ hay không?

2.4. Cho phép nhập ký tự đặc biệt hay không?

2.5. Có cho phép nhập ký tự số 2 byte hay không?

2.6. Cho phép null hay không?

2.7. Không được phép nhập blank ở vị trí đầu tiên của field số.

2.8. Không được phép nhập blank ở vị trí cuối cùng của field số.

2.9. Kiểm tra lỗi chia cho 0

2.10. Kiểm tra giá trị 0 cho tất cả các tính toán

2.11. Kiểm tra giá trị trong giới hạn max,min

2.12. Kiểm tra giá trị = giá trị max, min

2.13. Kiểm tra giá trị vượt giới hạn giá trị max, min

Một số ví dụ cụ thể

2.2 Kiểm tra giá trị max, min

Tình huống: để kiểm tra dữ liệu được insert vào một trường nào đó của bảng có thỏa mãn điều kiện giá trị lớn nhất hoặc giá trị bé nhất cho phép không.

Ví dụ: trường tuổi chỉ cho phép tuổi từ 19 -> 45

⇒ Cách test:

Nhập các value sau trên GUI:

< 19 tuổi
19 -45 tuổi -> 45 tuổi

Submit vào Database. Kiểm tra value đã được insert vào trong Database. => Kết quả:

Các value từ 19 -45 được insert vào Database thành công
Các value <19, >45 không được insert vào trong Database.

2.3 . Có cho phép nhập ký tự chữ hay không?

PP1: Check trên GUI:

Nhập vào trường cần check

Toàn bộ là ký tự chữ
Có cả chữ, cả số
Toàn ký tự số

=> Confirm kết quả insert thành công hay thất bại,

=> Confirm dữ liệu được insert vào database có đầy đủ và chính xác không

PP2: Check bằng câu Select hoặc insert trong database:

Dùng lệnh INSERT để insert một bản ghi, có trường cần check có dữ liệu

Toàn bộ là ký tự chữ
Có cả chữ, cả số
Toàn ký tự số

=> Confirm kết quả insert thành công hay thất bại

Nếu khi thực hiện insert 1. và 2. thành công thì chứng tỏ vẫn bị nhập dữ liệu có ký tự chữ vào trong database

3.Datatype: datetime

3.1. Kiểm tra maxlength

3.2. Kiểm tra ngày hợp lệ

3.3. Có cho phép nhập chữ hay không?

3.4. Có cho phép nhập ký tự đặc biệt hay không?

3.5. Có cho phép nhập ký tự số 2 byte hay không?

3.6. Kiểm tra format theo kiểu nào?

3.7. Kiểm tra đối với trường hợp năm nhuần có được tính đúng không?

3.8. Kiểm tra giá trị 00 và 13 đối với tháng

3.9. Kiểm tra giá trị 00 và 32 đối với ngày

3.10. Kiểm tra giá trị 28 , 29, 30 -Feb có được tính đúng không?

4.Datatype: bit

4.1. Chỉ được phép nhập 0 hoặc 1

4.2. Có cho phép null hay không?

4.3. Kiểm tra nhập ký tự số 2 byte 0 hoặc 1

5.Upload file (Thực hiện upload file có các định dạng, size, tên file khác nhau… như dưới đây. Sau khi đã thực hiện upload file thì kiểm tra kết quả đã lưu vào trong database):

5.1. File có định dạng đúng với spec: file tạo từ phần mềm gốc, file tạo từ convert mp3 -> avi, word -> html, file đổi extention

5.2. File có định dạng không đúng với spec, file sai định dạng, file không có định dạng

5.3. File có size đúng với spec: size thường, size min max

5.4. File có size không đúng với spec: file vượt quá giới hạn cho phép, file 0 byte

5.5. File có tên đúng với spec: độ dài, tên ký tự đặc biệt, tiếng Anh, tiếng Nhật

5.6. File có tên không đúng với spec: độ dài vượt quá giới hạn cho phép, tên sai chuẩn

5.7. File mà đang được lưu trữ ở các nguồn khác nhau: trên local/online/share file/sub folder/ folder name đặc biệt...

5.8. File có các quyền access khác nhau: write, read, view

5.9. Thực hiện upload với nhiều file, upload với folder: tồn tại cả file chuẩn theo spec và file không chuẩn theo spec

5.10. Thực hiện upload file có dung lượng lớn và trong khi đang xử lý upload thì thực hiện cancel upload

5.11. Thực hiện thao tác upload trên các môi trường khác nhau: Windows, ubuntu, MAC v.v

B. Kiểm tra tính toàn vẹn của cơ sở dữ liệu

・Là đảm bảo tính chính xác và nhất quán của dữ liệu được lưu trữ trong quá trình thao tác (insert, update, delete)

・Trong DB việc kiểm tra toàn vẹn của dữ liệu sẽ thông qua 2 đối tượng quản lý Constraint và Trigger

Hai đối tượng này được liên kết trực tiếp vào bảng dữ liệu.

1. Constraint

1.1. Kiểm tra tính duy nhất của dữ liệu

-Là loại ràng buộc cho phép kiểm tra tính duy nhất của dữ liệu trong bảng, tránh trường hợp người dùng nhập dữ liệu trùng với dữ liệu đã có trong bảng dữ liệu.

Để kiểm tra tính duy nhất đó có các loại ràng buộc PRIMARY KEY và UNIQUE KEY CONSTRAINT

1.1.1. PRIMARY KEY:

・Là khóa chính của bảng và là định danh duy nhất của mỗi bản ghi.

・Để tạo thành khóa chính thì cột (các cột) phải thỏa mãn 2 điều kiện: Không NULL và mỗi giá trị phải là duy nhất trong toàn bảng.

3 cách khai báo khóa chính:

CREATE TABLE name.table( Col_1 INT NOT NULL PRIMARY KEY, Col_2 VARCHAR(50) )

Hoặc

CREATE TABLE name.table( Col_1 INT NOT NULL, Col_2 VARCHAR(50), CONSTRAINT PK_Table PRIMARY KEY (Col_1, Col_2) )

Hoặc tạo bảng trước sau đó add thêm khóa chính:

ALTER TABLE name_table ADD CONSTRAINT PK_Table PRIMARY KEY (Col_1, Col_2)

1.1.2. UNIQUE KEY CONSTRAINT

Cho phép kiểm tra tính duy nhất của các cột không tham gia làm khóa chính

Có thể tạo nhiều ràng buộc duy nhất trên cùng 1 bảng

Cho phép nhập các giá trị NULL.

Cú pháp:

AFTER TABLE name_table ADD CONSTRAINT UC_nametable(col_1, col_2)

1.2. Kiểm tra tồn tại dữ liệu

・Còn được gọi là ràng buộc khóa ngoại (foreign key).

・Khóa ngoại là 1 trường hoặc nhiều trường dùng để tạo liên kết dữ liệu giữa 2 bảng.

・Một ràng buộc khóa ngoại phải đảm bảo rằng: chỉ có dữ liệu đã tồn tại trong khóa chính của bảng cha (bảng chứa Primary key) mới được nhập vào khóa ngoại.

・Một bảng có thể có nhiều khóa ngoại

Cú pháp:

CONSTRAINT ten_khoa_ngoai FOREIGN KEY(danh_sach_cot_khoa_ngoai) REFERENCES ten_bang_tham_chieu(danh_sach_cot_tham_chieu)

1.3. Kiểm tra miền giá trị

・Cho phép bạn kiểm tra miền giá trị dữ liệu của các cột trong bảng

・Điều này giúp ngăn cản việc người dùng nhập 1 dữ liệu vượt ra khỏi phạm vi quy ước

Cú pháp:

CONSTRAINT ten_constraint CHECK (dieu_kien)

2. Trigger

2.1. Định nghĩa

・Là 1 đối tượng của cơ sở dữ liệu bao gồm các lệnh SQL kết hợp với nhau.

・Trigger phải được gắn liền với 1 bảng, và tự động thực thi khi có các thao tác: INSERT, UPDATE, DELETE làm thay đổi dữ liệu của bảng.

・Tác dụng:

+Trigger có thể tự kích hoạt khi có sự thay đổi dữ liệu của bảng, nên có thể viết trigger để thực hiện các tác vụ ngầm, do đó giúp tăng hiệu năng của cơ sở dữ liệu.

+Qua Trigger ta có thể viết các thiết lập ngăn chặn và hủy bỏ các thao tác làm thay đổi dữ liệu không hợp lý trong cơ sở dữ liệu.

+Các thay đổi dữ liệu đối với cập nhật (Update), Thêm mới (Insert) sẽ lưu ra một bảng là Inserted, Đối với thao tác Xóa (Delete) sẽ tạo ra 1 bảng là deleted, các bảng này chỉ tồn tại trong thời gian trigger đó thực thi.

2.2. Cách viết Trigger

Khi viết Trigger phải chỉ rõ là được thực hiện trên bảng nào, và những hành động nào xảy ra.

_C. Kiểm tra hiệu năng (performance) _

1. Vì sao cần phải thực hiện kiểm tra hiệu năng:

Do khi thực hiện query để lấy dữ liệu thì sẽ phải lấy dữ liệu từ nhiều bảng khác nhau (điều kiện join) với nhiều điều kiện lọc giới hạn phạm vi dữ liệu sẽ được trích xuất ra (điều kiện where) nên hay xảy ra vấn đề là tốc độ trả về kết quả hiển thị trên màn hình mất nhiều thời gian, hoặc không hiển thị được kết quả trên màn hình do timeout.

==> Vì vậy cần phải thực hiện kiểm tra performance, so sánh tốc độ xử lý thực tế với tốc độ kỳ vọng chênh lệch như thế nào để có hướng cải thiện tốc độ.

2. Các trường hợp cần phải kiểm tra performance:

・Thao tác với màn hình search

・Thực hiện view list danh sách ( hàng trăm records, phân trang nhiều)

・Thực hiện insert hoặc update 1 lượng dữ liệu lớn (xử lý batch)

**3.Cách thực hiện: **

・Cần định rõ mục tiêu performance tính đến việc load và thời gian trả kết quả về: định nghĩa rõ đối với load 1 lượng data nhất định nào đó thì thời gian trả về chấp nhận được là bao nhiêu?

・Cần định rõ resource vì các máy có cấu hình khác nhau thì tốc độ response cũng khác nhau. Chúng ta nên dựng máy ảo với cấu hình mong muốn để thực hiện test

・Thực hiện load testing:

có thể sử dụng tool để test như SQL Server load generator (http://blog.sqlauthority.com/2012/06/07/sql-server-load-generator-free-tool-from-codeplex/)
Hoặc run các câu lệnh SQL trực tiếp trong Database, lấy giá trị thời gian thực hiện thực tế mà SQL trả về. Sau đó so sánh với thời gian mà spec mong đợi.

=> Trong trường hợp thời gian trả về quá lâu so với thời gian kỳ vọng (slow query) thì tiến hành report bug cho bên DEV để DEV điều tra, ví dụ như check lại câu query có hợp lý không, cần cải tiến tốc độ như thế nào?

D. Kiểm tra thủ tục (Stored Procedure)

**1. Định nghĩa **

Thủ tục là một đối tượng trong cơ sở dữ liệu bao gồm một tập nhiều câu lệnh SQL được nhóm lại với nhau.

2. Cấu trúc:

・Các cấu trúc điều khiển (IF, WHILE, FOR) có thể được sử dụng trong thủ tục.

・Bên trong thủ tục lưu trữ có thể sử dụng các biến như trong ngôn ngữ lập trình nhằm lưu giữ các giá trị tính toán được, các giá trị được truy xuất được từ cơ sở dữ liệu.

・Một tập các câu lệnh SQL được kết hợp lại với nhau thành một khối lệnh bên trong một thủ tục. Một thủ tục có thể nhận các tham số truyền vào cũng như có thể trả về các giá trị thông qua các tham số (như trong các ngôn ngữ lập trình). Khi một thủ tục lưu trữ đã được định nghĩa, nó có thể được gọi thông qua tên thủ tục, nhận các tham số truyền vào, thực thi các câu lệnh SQL bên trong thủ tục và có thể trả về các giá trị sau khi thực hiện xong.

3.Chức năng

・Đơn giản hoá các thao tác trên cơ sở dữ liệu nhờ vào khả năng module hoá các thao tác này.

・Thủ tục lưu trữ được phân tích, tối ưu khi tạo ra nên việc thực thi chúng nhanh hơn nhiều so với việc phải thực hiện một tập rời rạc các câu lệnh SQL tương đương theo cách thông thường.

・Thủ tục lưu trữ cho phép chúng ta thực hiện cùng một yêu cầu bằng một câu lệnh đơn giản thay vì phải sử dụng nhiều dòng lệnh SQL. Điều này sẽ làm giảm thiểu sự lưu thông trên mạng.

・Thay vì cấp phát quyền trực tiếp cho người sử dụng trên các câu lệnh SQL và trên các đối tượng cơ sở dữ liệu, ta có thể cấp phát quyền cho người sử dụng thông qua các thủ tục lưu trữ, nhờ đó tăng khả năng bảo mật đối với hệ thống.

4.Cú pháp

CREATE PROCEDURE [stroge_name] [tham_so] AS [Truy_van_SQL]

IV. Phương pháp kiểm thử trong Database Testing

1. Kiểm thử hộp trắng (white-box testing)

Phương pháp này thường do DEV thực hiện trong quá trình review code và UT. Có các đặc điểm:

・Dựa trên sự phân tích mã để xây dựng các phép thử theo các tiêu chuẩn bao phủ.

・Cho phép kiểm tra tất cả câu lệnh và điều kiện tồn tại bên trong

Các phương pháp kiểm thử hộp trắng :

_1.1. Kiểm tra mã nguồn (Code walk-though) : _

・Là một phương pháp hữu hiệu khi kiểm thử hộp đen không thể áp dụng ở mức kiểm thử đơn vị

・Mục đích là tìm ra những gì không hiệu quả, dư thừa, không phù hợp của mã nguồn

・Phương pháp này hoạt động tốt khi chỉ dùng cho một số ít thành viên và không kéo dài quá một vài giờ .

1.2. Thực hiện tuần tự các câu lệnh SQL

・Thực hiện trong Unit Test

・Có thể kiểm thử các store procedure bằng cách thực thi các câu lệnh SQL mỗi lệnh một lần so với kết quả đã biết

・Lợi ích chính là khi lỗi được phát hiện, chỉ cần sự phân tích đơn giản để sửa lỗi

1.3.Thực hiện test lần lượt các store procedure

・Tương tự kiểm thử các functions

・Đối với mỗi store procedure , phân tích kiểu dữ liệu và ràng buộc của mỗi tham số vào

・Thực hiện bằng cách gọi store procedure với số ít bản ghi và với một số lượng lớn bản ghi

・Thực thi store procedure bằng cách truyền tham số đầu vào khác nhau. So sánh kết quả đầu ra với kết quả mong đợi

1.4. Kiểm thử Trigger

・Cần xác định các trigger như là một phần của ứng dụng

・Mục tiêu kiểm thử là xác định các Store procedures có đạt được mục tiêu thiết kế , các lệnh có được thực thi đúng đắn...

2. Kiểm thử hộp đen (black-box testing)

Phương pháp này sẽ do QA thực hiện.

Black-box testing là nghiên cứu xem phần mềm như là một “hộp đen”, phương pháp test dựa trên đầu vào và đầu ra của chương trình để test mà không quan tâm tới source code bên trong của hệ thống được xây dựng như thế nào.

Trong Database Testing: Thiết kế TestCase theo phương pháp truyền thống: trước khi viết testcase chúng ta phải xác định viết cho từng item trên mỗi form hay viết cho toàn bộ chức năng.

Thực hiện test lần lượt theo các bước:

Chuẩn bị môi trường: Setting để vào được database
Run test: Thực hiện các lệnh thao tác với đối tượng cần check trong database
Check kết quả thực hiện
Đối chiếu với kết quả mong muốn
Báo cáo kết quả cho các bên liên quan tương ứng

Thiết kế các trường hợp kiểm thử:

・Tạo tất cả các trường hợp kiểm thử gây ra tất cả các lỗi có thể xảy ra dựa vào những hiểu biết về SQL

・Kiểm tra sự tương tác giữa SQL và các thành phần

・Nắm bắt được cách sử dụng công cụ dữ liệu để thực thi câu lệnh SQL và store procedure

Kiểm thử các giao dịch logic:

・Kiểm thử các trường hợp có thể xảy ra đối với tất cả các giao dịch

・Nếu bất kỳ một sự cập nhật của giao dịch không thành công thì các cập nhật khác của giao dịch đó cũng phải được hủy bỏ

Kiểm thử vấn đề về truy cập đồng thời：

・Một cơ sở dữ liệu có thể xử lý nhiều giao dịch trong cùng một thời điểm

＋Mỗi giao dịch cần giữ khóa của dữ liệu để đảm bảo tính toàn vẹn

＋Khả năng xảy ra tình trạng Deadlock

V. Các lỗi thường phát sinh trong Database Testing

Trong khi thực hiện Database Testing, có thể tập trung vào một số điểm thường xảy ra lỗi như sau:

・Các tập lệnh, các chương trình chạy tại máy khách (Client)

・Các tập lệnh, các chương trình chạy tại máy chủ (Server)

・Các dịch vụ truy cập CSDL, kết nối CSDL

・Các dữ liệu được lưu trữ,…

=> Việc kiểm tra có thể và nên được áp dụng tại các điểm này.

Có hai lớp lỗi phổ biến của Database Testing là: Lỗi toàn vẹn dữ liệu & Lỗi đầu ra

1. Lỗi toàn vẹn dữ liệu

_Góc độ kỹ thuật: _

Lỗi về toàn vẹn dữ liệu là lỗi bất kì gây ra các kết quả sai lệch được lưu trữ.

Ví dụ: Thiếu dữ liệu của một bản ghi, hoặc thiếu dữ liệu của 1 trường nào đó trong bản ghi.

Góc độ người dùng:

Lỗi toàn vẹn dữ liệu nghĩa là có thể có dữ liệu bị mất hoặc không chính xác hoặc đã lỗi thời vì nó không được cập nhật đúng cách.

Ví dụ: Nhập toàn bộ thông tin cho một form Thêm mới

Xử lý mong muốn: Thông tin thêm mới phải được hiển thị ở phần Danh sách

Kết quả thực tế: Sau khi nhập thông tin xong, bản ghi mới đó không được lưu vào trong CSDL hoặc lưu không đầy đủ các thông tin đã đăng ký=> Trên form: Thêm mới xong người dùng không nhìn thấy kết quả hiển thị hoặc hiển thị sai với giá trị nhập vào

2. Lỗi đầu ra

_Góc độ kỹ thuật: _

Lỗi đầu ra được gây ra bởi một số lỗi trong việc truy vấn dữ liệu, thực hiện các lệnh thao tác xử lý và phục hồi dữ liệu, mặc dù dữ liệu nguồn là chính xác.

Ví dụ: Kết nối cơ sở dữ liệu thất bại, Bộ nhớ không đủ để lưu trữ thêm data nên quá trình Thêm mới thất bại (và chỉ hiện ra thông báo: "Không thể thêm mới" giống như khi thêm mới 1 trường thông tin nào đó sai), ...

Góc độ người dùng:

Các dấu hiệu nhìn thấy trong lỗi đầu ra có thể tương tự như lỗi toàn vẹn dữ liệu. Chỉ khi dựa vào phân tích các yếu tố kỹ thuật bên trong hệ thống mới phân biệt được giữa hai loại lỗi này. => thách thức đối với kiểm chứng hộp đen.

Kết luận: Sai sót trong các hoạt động CSDL sẽ dẫn đến lỗi toàn vẹn dữ liệu, lỗi đầu ra hoặc cả hai

Một số lỗi phổ biến trong các hoạt động CSDL.

・Thất bại trong việc tạo CSDL:

+Tạo bảng sai (sai tên, kiểu từng trường, max length, ràng buộc các bảng, trường khóa...)

+Khởi tạo sai giá trị mặc định (khi thêm mới/cập nhật 1 bản ghi, gán giá trị mặc định sai với yêu cầu...)

+Sai thủ tục lưu trữ (thủ tục thực hiện việc Select/Insert/Update/Delete... bị sai, không thực hiện đúng theo yêu cầu)

・Kết nối CSDL bị thất bại (mất mạng, server bị mã hóa, bộ nhớ không đủ để nhận xử lý...)

・Sai sót trong các lệnh thao tác với CSDL: Xử lý sai dấu phẩy, dấu nháy đơn, sai kiểu dữ liệu, sai chính tả....

Tài liệu tham khảo

Kết luận

Database testing không phải là chủ đề mới, ít nhiều mỗi tester đều đã thực hiện test liên quan đến database testing.

Yêu cầu để thực hiện được Database Testing là Tester cần có kiến thức kỹ thuật tốt về các concept quan trọng của CSDL. Ở mức độ đơn giản nhất là kiểm tra tính hợp lệ của CSDL thì tester cũng cần có kiến thức cơ bản về Database cũng như biết cách sử dụng các câu lệnh CRUD của SQL.

Bài viết này cung cấp thêm các thông tin chi tiết, giúp các bạn hiểu hơn về việc tại sao lại cần thực hiện Database Testing, cách thực hiện như thế nào và cần lưu ý những gì khi test Database.

Chúng tôi hy vọng sẽ giúp các bạn áp dụng được các phương pháp test kiểm tra tính hợp lệ, ràng buộc dữ liệu... vào dự án của mình một cách hiệu quả.