Database Testing Tutorial - Hướng dẫn kiểm thử Cơ sở dữ liệu
Bài đăng này đã không được cập nhật trong 3 năm
Đối với bất kỳ một ứng dụng nào thì Giao diện (Graphical User Interface - GUI) chính là thành phần giao tiếp với người dùng. Chính vì thế, nó luôn được chú trọng nhất bởi các nhà quản lý cũng như đội ngũ phát triển.
Nhưng bên cạnh đó, để đảm bảo mọi thông tin "giao tiếp" ấy là hoàn toàn chính xác, thì Cơ sở dữ liệu (Database) lại là một yếu tố quyết định, là trái tim của ứng dụng.
Hãy cùng xét đến ví dụ một người dùng sử dụng một ứng dụng ngân hàng và thực hiện các giap dịch trên đó. Từ quan điểm của kiếm thử database, có những điểm quan trọng sau đây cần phải xác minh:
- Ứng dụng lưu trữ và hiển thị thông tin chính xác
- Không có thông tin bị mất mát trong quá trình xử lý
- Không lưu trữ các thông tin giao dịch chưa hoàn thành hoặc bị bỏ qua
- Không thể truy cập thông tin của các người dùng khác
Để đảm bảo các mục tiêu trên, chúng ta phải sử dụng phương pháp xác thực dữ liệu hoặc kiểm thử dữ liệu.
Trong hướng dẫn này, chúng ta sẽ tìm hiểu về các nội dung sau:
- Sự khác biệt giữa kiểm thử giao diện (GUI) và cơ sở dữ liệu
- Các loại kiểm thử cơ sở dữ liệu
- Kiểm thử sơ đồ (Schema)
- Kiểm thử bảng và cột
- Kiểm thử thủ tục (Stored Procedures)
- Kiểm thử Trigger
- Xác thực máy chủ cơ sở dữ liệu
- Kiểm thử chức năng của cơ sở dữ liệu
- Đăng nhập và bảo mật người dùng
- Kiểm thử phi chức năng
1. Những khác biệt cơ bản giữa kiểm thử giao diện và cơ sở dữ liệu
|**User-Interface testing**|**Data testing**|
|Test giao diện hay còn gọi là test front-end|Test back-end hay còn gọi là test data|
|Chủ yếu thực hiện với những item tương tác trực tiếp với người dùng như form, biểu đồ, các menu hoặc các báo cáo v.v… (được tạo bằng C#, VB, VB.net, VC++, Delphi hoặc các công cụ thiết kế giao diện…)|Chủ yếu thực hiện với những item mà người dùng không nhìn thấy được trực tiếp trên app. Chúng bao gồm các xử lý và lưu trữ bên trong như là Assembly, DBMS, Oracle, SQL Server, MYSQ|
|Đối tượng:
- Các textbox
- Dropdown list
- Calendar
- Button
- Di chuyển sang trang mới
- Hiển thị hình ảnh
- Nhìn và cảm nhận tổng thể đối với ứng dụng|Đối tượng:
- Sơ đồ
- Bảng
- Cột
- Khóa và chỉ số
- Thủ tục
- Triggers
- Xác thực máy chủ cơ sở dữ liệu
- Kiểm tra trùng lặp dữ liệu|
|Yêu cầu tester phải hiểu biết đầy đủ về các yêu cầu nghiệp vụ cũng như việc sử dụng các công cụ phát triển, framework kiểm thử tự động|Tester để có thể thực hiện việc kiểm thử back-end cần phải có một nền tảng và kiến thức về database và ngôn ngữ truy vấn|
2. Các loại kiểm thử Cơ sở dữ liệu
Có 3 loại kiểm thử Cơ sở dữ liệu:
- Kiểm thử cấu trúc (Structural)
- Kiểm thử chức năng (Functional)
- Kiểm thử phi chức năng (Non-functional)
2.1. Kiểm thử cấu trúc (Structural)
Việc kiểm thử cấu trúc database bao gồm việc kiểm tra tất cả các phần tử bên trong kho lưu trữ dữ liệu được sử dụng chủ yếu cho việc lưu trữ data mà không cho phép người dùng cuối thao tác trực tiếp. Các truy vấn SQL chính là chìa khóa cho sự thành công của giai đoạn này.
Kiểm tra sơ đồ (Schemas)
Mục tiêu chính của việc kiểm tra sơ đồ là để đảm bảo sự các sơ đồ được ánh xạ giữa front-end và back-end là như nhau. Do đó, chúng ta cũng có thể tham chiếu kiểm thử sơ đồ như kiểm thử ánh xạ (maping testing).
Những điểm quan trọng trong việc kiểm tra sơ đồ:
- Kiểm tra các kiểu dữ liệu của sơ đồ liên kết với cơ sơ dữ liệu. Nhiều khi, việc mapping định dạng của table có thể không tương thích với việc mapping định dạng trên giao diện người dùng của ứng dụng.
- Cần thiết kiểm tra các trường hợp: table, view, column không trùng khớp lẫn nhau.
- Ngoài ra, cũng cần thiết phải check các trường hợp dị biến của data (các trường hợp thay đổi hay data khác thường) trong môi trường tổng thể của ứng dụng.
Một số công cụ hữu ích cho kiểm thử sơ đồ:
DBUnit được tích hợp với Ant rất thích hợp để kiểm thử sơ đồ. SQL Server cho phép tester có thể test và truy vấn các sơ đồ trong cơ sở dữ liệu của database bằng cách viết những câu query đơn giản mà không cần thông qua code.
Ví dụ:
-
Nếu một lập trình viên muốn thay đổi cấu trúc của table hoặc xóa nó, tester nên kiểm tra toàn bộ các thủ tục và các View mà sử dụng trong bảng tương thích với các thay đổi.
-
Ví dụ khác là tester muốn kiểm tra sơ đồ thay đổi giữa 2 cơ sở dữ liệu, họ có thể thực hiện việc đó bằng cách sử dụng những câu query đơn giản.
Kiểm tra Bảng và Cột trong cơ sở dữ liệu
Các loại kiểm thử khác nhau cho cột và cơ sở dữ liệu:
- Check sự mapping giữa các trường (field) và cột của cơ sở dữ liệu ở back-end và front-end.
- Kiểm tra độ dài và qui ước đặt tên của các trường và cột trong database đã đúng yêu cầu hay chưa.
- Kiểm tra sự hiện diện của bất kỳ cột/bảng trong cơ sở dữ liệu chưa được sử dụng/ánh xạ.
- Kiểm tra sự tương thích giữa kiểu dữ liệu và độ dài của các cột trong cơ sở dữ liệu và khi hiển thị trên ứng dụng.
- Các trường trong cơ sở dữ liệu có cho phép người dùng cung cấp dữ liệu đầu vào mong muốn như trong tài liệu yêu cầu cụ thể hay không.
Kiểm tra khóa và chỉ số:
Những yếu tố quan trọng trong kiểm thử khóa và chỉ số bao gồm:
- Kiểm tra khóa chính và khóa ngoại cần thiết được có tạo trong các bảng yêu cầu hay không.
- Kiểm tra các tham chiếu của khóa ngoại có hợp lệ hay không.
- Kiểm tra kiểu dữ liệu của khóa chính và khóa ngoại tương ứng có giống nhau giữa hai bảng hay không.
- Kiểm tra các khóa và index có tuân thủ các quy ước đặt tên hay không.
- Kiểm tra kích thước và độ dài của các trường và index.
- Kiểm tra xem clustered index và non-clustered index có được tạo trên các bảng như được yêu cầu hay không.
Kiểm tra thủ tục (Stored procedures)
Những nội dung quan trong nhất đối với kiểm tra thủ tục bao gồm:
- Dev team đã đáp ứng đúng yêu cầu hay chưa? Coding theo đúng qui ước tiêu chuẩn? Xử lý các ngoại lệ và lỗi cho tất cả các thủ tục, mo-đun của toàn bộ ứng dụng đang được test.
- Dev team đã đảm bảo cho các điều kiện/vòng lặp bằng cách áp dụng các dữ liệu đầu vào cần thiết cho ứng dụng đang được test hay chưa
- Dev team đã thực hiện đúng việc TRIM dữ liệu bất cứ khi nào lấy data từ các bản cần thiết trong database hay chưa.
- Kết quả của việc thực hiện chạy bằng tay các thủ tục có đúng với yêu cầu hay không
- Việc thực hiện chạy bằng tay các thủ tục có đảm bảo các trường trong bảng được update theo đúng yêu cầu của ứng dụng hay không
- Việc thực hiện các thủ tục bằng cách gọi thông qua trigger có đúng hay không
- Kiểm tra xem có các thủ tục nào không được sử dụng không
- Kiểm tra việc có phép điều kiện Null hay không trong cơ sở dữ liệu hay không
- Kiểm tra xem thực tế tất cả các thủ tục và chức năng có chạy đúng khi cơ sở dữ liệu là trống hay không
- Kiểm tra tổng quát sự tích hợp của các mo-đun trong thủ tục có đang work đúng hay không
Một số tool dùng để kiểm thử thủ tục là LINQ, SP test tool, ...
Kiểm tra Trigger
- Kiểm tra xem việc mã hóa các trigger đã đúng theo qui ước tiêu chuẩn hay chưa
- Kiểm tra xem các Trigger thực hiện cho các giao dịch DML tương ứng đã thõa mãn các điều kiện cần thiết chưa
- Kiểm tra xem các trigger cập nhật dữ liệu chính xác hay chưa.
- Kiểm tra các Update/Insert/Delete trigger được yêu cầu có chạy trong ứng dụng hay không.
Xác thực máy chủ cơ sở dữ liệu
- Kiểm tra cấu hình của máy chủ cơ sở dữ liệu đã đúng với tài liệu đặc tả yêu cầu chưa
- Kiểm tra việc xác thực người dùng được thực hiện khi có các yêu cầu từ phía ứng dụng
- Kiểm tra xem các máy chủ cơ sở dữ liệu có thể phục vụ được cho nhu cầu số lượng giao dịch tối đa theo tài liệu đặc tả nghiệp vụ hay không
2.2. Kiểm thử chức năng của cơ sở dữ liệu (Functional)
Kiểm thử chức năng của cơ sở dữ liệu để đảm bảo tất cả 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 của ứng dụng.
Dưới đây là các điều kiện cơ bản cần được kiểm tra khi thực hiện kiểm thử cơ sở dữ liệu:
- Những trường có giá trị là bắt buộc nhưng lại cho phép null hay không
- Độ dài của mỗi trường có hải là kích thước đầy đủ hay không
- Những trường tương tự nhau có tên giống nhau ở các bảng không
- Có bất kỳ các trường được tính toán (computed fields) nào xuất hiện trong cơ sở dữ liệu hay không
Việc xử lý cụ thể này là kiểm tra các trường được ánh xạ từ quan điểm của người dùng cuối. Trong các trường hợp cụ thể, tester sẽ thực hiện hoạt động ở cấp cơ sở dữ liệu và sau đó sẽ chuyển hướng đến giao diện người dùng có liên quan để quan sát và kiểm tra xem trường được kiểm chứng có được hiển thị ra hay không.
Ngược lại, đầu tiên tester sẽ thực hiện kiểm tra hiển thị ở giao diện người dùng, sau đó sẽ thực hiện kiểm chứng ở cơ sở dữ liệu, đây cũng là một lựa chọn hợp lệ.
Kiểm tra tính nhất quán và toàn vẹn dữ liệu
Các nội dụng quan trọng cần kiểm tra bao gồm:
- Dữ liệu có được tổ chức hợp lý hay không
- Dữ liệu được lưu trong các bảng có chính xác và đúng yêu cầu hay không
- Các dữ liệu không cần thiết có xuất hiện trong ứng dụng hay không
- Dữ liệu đã được lưu trữ có giống với các dữ liệu được cập nhật trên giao diện người dùng hay không
- Thao tác TRIM có được thực hiện trên dữ liệu trước khi trèn vào cơ sở dữ liệu hay không
- Các giao dịch được thực hiện đúng theo các yêu cầu được tả và kết quả có chính xác hay không
- Dữ liệu có chính xác nếu giao dịch được chạy thành công đúng như yêu cầu hay không
- Dữ liệu có được phục hồi lại thành công nếu giao dịch của người dùng cuối thất bại hay không
- Dữ liệu có được phục hồi lại toàn bộ trong điều kiện giao dịch không được chạy thành công và nhiều cơ sở dữ liệu không đồng nhất được gọi trong một giao dịch hay không.
- Giao dịch có được chạy bằng cách sử dụng các thủ tục được chỉ định như trong yêu cầu đặc tả hay không.
Đăng nhập và bảo mật người dùng
Kiểm thử đăng nhập và bảo mật người dùng cần lưu ý đến những điểm sau đây:
- Kiểm tra xem ứng dụng có ngăn cản người dùng thực hiên thêm các thao tác trong các trường hợp sau hay không:
- Username không hợp lệ nhưng mật khẩu hợp lệ
- Username hợp lệ nhưng mật khẩu không hợp lệ
- Cả username và mật khẩu không hợp lệ
- Cả username và mật khẩu hợp lệ
- Kiểm tra xem người dùng có được quy định chỉ thực hiện một số thao tác cụ thể được chỉ định trong yêu cầu đặc tả hay không.
- Kiểm tra xem dữ liệu có được bảo vệ khi có một truy cập trái phép hay không.
- Kiểm tra xem các user có các quyền khác nhau khi được phân quyền khác nhau hay không.
- Kiểm tra xem tất cả các user có thể truy cập ở các cấp độ khác nhau trên cơ sở dữ liệu như được chỉ định trong yêu cầu đặc tả.
- Kiểm tra các dữ liệu nhậy cảm như mật khẩu, số tài khoản có được mã hóa và không được lưu dưới dạng văn bản thô hay không. Sẽ tốt hơn nếu đảm bảo tất cả các tài khoản có mật khẩu phức tạp và khó đoán.
2.3. Non-functional testing
Kiểm thử phi chức năng trong kiểm thử cơ sở dữ liệu có thể được chia thành rất nhiều loại dựa trên yêu cầu đặc tả. Nó có thể là kiểm thử về tải (load testing), kiểm thử sự quá tải (stress testing), kiểm thử tính bảo mật (security testing), kiểm thử tính ổn định (usability testing) và kiểm thử tính tương thích (compatibility testing). Load testing và stress testing có thể được nhóm vào loại kiểm thử về hiệu năng (performance testing) để phục vụ hai mục đích khác nhau khi nói đến vai trò của kiểm thử phi chức năng.
Định lượng rủi ro: Định lượng của rủi ro giúp các bên liên quan xác định được yêu cầu về thời gian đáp ứng của hệ thống trên các mức độ phụ tải yêu cầu. Đây là nhiệm vụ đầu tiên của bất kỳ công việc đảm bảo chất lượng nào. Chúng ta cần phải lưu ý load testing không làm giảm các rủi ro trực tiếp, nhưng thông qua quá trình xác định và định lượng rủi ro, sẽ có những biện pháp để khắc phục và phòng tránh các rủi ro.
Cấu hình tối thiểu của hệ thống: Sự hiểu biết mà chúng ta có được thông qua việc kiểm thử thực tế, cấu hình tối thiểu của hệ thống sẽ cho phép hệ thống đáp ứng được các hiệu suất như được yêu cầu bởi các bên liên quan. Ngoài phần cứng và phần mềm, các chi phí liên quan đến quyền sở hữu cũng có thể giảm thiểu. Các yêu cầu cụ thể có tể được phân loại nhằm tối ưu hóa chi phí.
All rights reserved
