TỔNG QUAN VỀ KIỂM ĐỊNH PHẦN MỀM
Khái niệm kiểm định phần mềm
Kiểm định phần mềm đóng vai trò quan trọng trong việc đảm bảo chất lượng sản phẩm, thể hiện sự đánh giá cuối cùng về đặc tả, thiết kế và mã nguồn.
Theo Glen Myers, kiểm định là quá trình thực hiện chương trình nhằm phát hiện lỗi phần mềm Một lần kiểm định hiệu quả có khả năng cao trong việc phát hiện lỗi chưa được biết đến Kiểm định thành công là khi nó phát hiện ít nhất một lỗi chưa được phát hiện trước đó.
Quy trình kiểm định phần mềm
Kiểm định phần mềm có thể được thực hiện theo từng bước sau khi phát triển mỗi chức năng hoặc module, hoặc cũng có thể thực hiện tổng thể sau khi phần mềm đã hoàn tất phát triển.
Quy trình kiểm định phần mềm có thể bao gồm các mức và bước kiểm tra cơ bản nhƣ sau:
Các mức độ cơ bản của kiểm tra phần mềm bao gồm nhiều đơn vị như hàm, thủ tục, lớp và phương thức Những đơn vị này có thể được kiểm tra một cách độc lập để đảm bảo chất lượng và hiệu suất của phần mềm.
Việc kiểm tra các đơn vị có kích thước nhỏ và chức năng đơn giản sẽ dễ dàng trong tổ chức, ghi nhận và phân tích kết quả Khi phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng trở nên đơn giản do chỉ cần tập trung vào đơn vị đang kiểm tra Một nguyên lý quan trọng là thời gian dành cho kiểm định ban đầu sẽ được bù đắp bằng việc tiết kiệm thời gian và chi phí cho các kiểm tra và sửa lỗi ở các mức tiếp theo.
Kiểm định đơn vị thường do lập trình viên thực hiện và cần được tiến hành sớm trong quá trình viết code, xuyên suốt chu kỳ phát triển phần mềm Để thực hiện kiểm định đơn vị hiệu quả, kiểm tra viên cần có kiến thức về thiết kế và mã nguồn của chương trình Mục tiêu chính là đảm bảo thông tin được xử lý và xuất ra là chính xác, tương ứng với dữ liệu đầu vào và chức năng của đơn vị Việc kiểm tra tất cả các nhánh bên trong đơn vị là cần thiết để phát hiện lỗi, trong đó một nhánh có thể là chuỗi lệnh thực thi sau điều kiện if Việc lựa chọn các nhánh để đơn giản hóa quy trình kiểm tra và quét toàn bộ đơn vị đòi hỏi kỹ thuật và đôi khi cần sử dụng thuật toán.
Kiểm định đơn vị yêu cầu chuẩn bị kỹ lưỡng các ca kiểm định và kịch bản trước khi thực hiện Các kịch bản này cần chỉ định rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong đợi Việc lưu trữ các ca kiểm định và kịch bản sẽ giúp tái sử dụng cho các lần kiểm định sau, nâng cao hiệu quả và tính nhất quán trong quá trình kiểm tra.
Kiểm định đơn vị có thể bao gồm các kỹ thuật kiểm định sau:
Kiểm định hộp đen (black box)
Kiểm định hộp trắng (white box)
Kiểm định tích hợp là quá trình kết hợp các thành phần của một ứng dụng và kiểm tra chúng như một ứng dụng hoàn chỉnh Khác với kiểm định đơn vị, chỉ kiểm tra các thành phần và đơn vị riêng lẻ, kiểm định tích hợp tập trung vào việc kiểm tra sự giao tiếp và tương tác giữa các thành phần đã được kết hợp.
Kiểm định tích hợp có 2 mục tiêu chính:
Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị
Tích hợp các đơn vị đơn lẻ thành các hệ thống nhỏ và cuối cùng là nguyên hệ thống hoàn chỉnh chuẩn bị cho kiểm tra ở mức hệ thống
Trong kiểm định đơn vị, lập trình viên nỗ lực phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của đơn vị Mặc dù có một số phép kiểm tra đơn giản về giao tiếp giữa đơn vị và các thành phần khác, nhưng giao tiếp thực sự chỉ được kiểm tra đầy đủ khi các đơn vị tích hợp và thực hiện kiểm định tích hợp.
Một chiến lược quan trọng trong kiểm định tích hợp là tiến hành tích hợp từng đơn vị một cách dần dần Mỗi đơn vị mới sẽ được thêm vào nhóm các đơn vị đã được tích hợp và kiểm định trước đó Việc này cho phép chúng ta chỉ cần kiểm tra sự giao tiếp của đơn vị mới với các đơn vị đã tích hợp, từ đó giảm thiểu số lượng kiểm tra cần thực hiện và giảm đáng kể khả năng xảy ra sai sót.
Có 4 loại kiểm tra trong kiểm định tích hợp:
1 Kiểm tra cấu trúc: Tương tự kiểm định hộp trắng (kiểm tra nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng), chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và nhánh bên trong
2 Kiểm tra chức năng: Tương tự kiểm định hộp đen (kiểm tra chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong), chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật
3 Kiểm tra hiệu năng: Kiểm tra việc vận hành của hệ thống
4 Kiểm tra khả năng chịu tải: Kiểm tra các giới hạn của hệ thống
Mục đích kiểm định hệ thống là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không
Kiểm định hệ thống bắt đầu khi tất cả các bộ phận phần mềm được tích hợp thành công và thường tốn nhiều thời gian, công sức Trong nhiều trường hợp, kiểm tra này yêu cầu thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt đối với các ứng dụng thời gian thực, hệ thống phân tán, hoặc hệ thống nhúng Tại mức độ hệ thống, người kiểm tra tìm kiếm lỗi nhưng tập trung vào đánh giá hiệu suất, độ tin cậy và các yêu cầu chất lượng khác Sự khác biệt chính giữa kiểm định tích hợp và kiểm định hệ thống là kiểm định hệ thống chú trọng vào hành vi và lỗi toàn hệ thống, trong khi kiểm định tích hợp tập trung vào sự giao tiếp giữa các đơn thể Thông thường, cần thực hiện kiểm định đơn vị và kiểm định tích hợp để đảm bảo mọi đơn vị và sự tương tác của chúng hoạt động chính xác trước khi tiến hành kiểm định hệ thống.
Kiểm định hệ thống đánh giá cả hành vi chức năng của phần mềm lẫn các yêu cầu chất lượng như độ tin cậy, tính tiện lợi, hiệu năng và bảo mật Mức kiểm tra này rất hiệu quả trong việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, như lỗi "tắc nghẽn" hoặc chiếm dụng bộ nhớ Sau khi hoàn tất kiểm định, phần mềm sẽ được đưa cho khách hàng hoặc người dùng cuối để kiểm tra và chấp nhận (Alpha/Beta Test) Quá trình này đòi hỏi nhiều công sức, thời gian và cần tính chính xác, khách quan, thường được thực hiện bởi một nhóm kiểm tra viên độc lập với nhóm phát triển dự án.
Bản thân kiểm định hệ thống lại gồm nhiều loại kiểm tra khác nhau, phổ biến nhất gồm:
Kiểm tra chức năng: bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế
Kiểm tra khả năng vận hành: bảo đảm tối ƣu việc phân bổ tài nguyên hệ thống
(ví dụ bộ nhớ) nhằm đạt các chỉ tiêu nhƣ thời gian xử lý hay đáp ứng câu truy vấn,
Kiểm tra khả năng chịu tải: bảo đảm hệ thống vận hành đúng dưới áp lực cao
Kiểm tra khả năng chịu tải là quá trình đánh giá hiệu suất hệ thống khi nhiều người truy xuất cùng lúc Tập trung vào các trạng thái tới hạn và các "điểm chết" giúp xác định giới hạn của hệ thống Ngoài ra, việc phân tích các tình huống bất thường cũng rất quan trọng để đảm bảo hệ thống hoạt động ổn định trong mọi điều kiện.
Kiểm tra khả năng bảo mật: bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống
Kiểm tra khả năng phục hồi là việc đảm bảo hệ thống có thể khôi phục trạng thái ổn định trước đó khi gặp phải tình huống mất tài nguyên hoặc dữ liệu Điều này đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến.
Hình 1.2 Các loại kiểm tra khác nhau trong Kiểm định hệ thống
Từ góc độ người dùng, việc thực hiện các kiểm tra là rất cần thiết để đảm bảo hệ thống hoạt động hiệu quả trong môi trường thực tế Không nhất thiết phải thực hiện tất cả các loại kiểm tra đã nêu; tùy thuộc vào yêu cầu và đặc điểm của từng hệ thống, cũng như khả năng và thời gian của dự án, trưởng dự án sẽ quyết định loại kiểm tra nào cần áp dụng trong kế hoạch.
CÁC KỸ THUẬT KIỂM ĐỊNH PHẦN MỀM
Kiểm định hộp trắng
2.1.1 Kiểm định hộp đen và kiểm định hộp trắng
Hộp đen và hộp trắng là hai phương pháp kiểm định phần mềm quan trọng, trong đó kiểm định hộp đen tập trung vào chức năng của phần mềm, còn kiểm định hộp trắng chú trọng vào cấu trúc bên trong của nó.
Kiểm định hộp đen là phương pháp tập trung vào việc kiểm tra các yêu cầu chức năng của ứng dụng phần mềm Quá trình này thực hiện kiểm tra toàn bộ các dải dữ liệu đầu vào và đầu ra để xác định tính chính xác của chúng Điều quan trọng là không cần quan tâm đến cách thức đạt được kết quả đầu ra hoặc các yếu tố bên trong "hộp" Kiểm định hộp đen xem hệ thống như một hộp đen thuần túy, vì vậy không yêu cầu hiểu biết về cấu trúc bên trong của nó.
Mặc dù kiểm định hộp đen có nhiều ưu điểm, nhưng nó vẫn chưa đủ để đáp ứng yêu cầu thực tế Các hệ thống trong đời sống thường có nhiều loại dữ liệu đầu vào khác nhau, dẫn đến sự gia tăng số lượng ca kiểm định Chẳng hạn, với một chương trình kiểm tra số dư tài khoản ngân hàng, chỉ cần khoảng 100 dòng lệnh để thực hiện các ca kiểm định tiêu biểu Tuy nhiên, đối với các hệ thống lớn như mô phỏng đào tạo phi công máy bay 747, việc kiểm tra chặt chẽ các thông số đầu vào và đầu ra chỉ dựa vào kỹ thuật kiểm định hộp đen là không khả thi.
Việc không xác định được các phần mã lệnh nào của chương trình đã được kiểm tra bằng kỹ thuật kiểm định hộp đen tạo ra rủi ro cho phần mềm Những đoạn mã lệnh chưa được thực hiện trong quá trình kiểm tra giống như một quả bom nổ chậm, có thể gây ra sự cố nghiêm trọng Điều này nhấn mạnh tầm quan trọng của việc kiểm tra toàn diện, vì những đoạn mã lệnh chưa được kiểm tra đồng nghĩa với việc chưa được đảm bảo chất lượng.
Một giải pháp hiệu quả cho vấn đề kiểm tra phần mềm là kết hợp kiểm tra hộp trắng với kiểm tra hộp đen Kiểm tra hộp trắng bao gồm các kiểm tra thiết kế, yêu cầu các dòng mã lệnh phải được thực thi ít nhất một lần và kiểm tra các chức năng riêng biệt Phương pháp này cho phép người kiểm tra xem xét chi tiết bên trong phần mềm, từ đó lựa chọn dữ liệu kiểm tra một cách hiệu quả hơn.
Kiểm định hộp trắng yêu cầu kiến thức sâu về cấu trúc và hoạt động bên trong của chương trình, trong khi kiểm định hộp đen chỉ dựa vào hiểu biết về các yêu cầu tổng quát của hệ thống.
2.1.2 Các nguyên tắc kiểm định hộp trắng
Kiểm định hộp trắng liên quan đến logic bên trong và cấu trúc của mã lệnh Nó còn đƣợc gọi là ClearBox Testing/OpenBox Testing/Structural Testing/ Glass Testing
Kiểm tra dựa trên kỹ thuật kiểm định hộp trắng yêu cầu sự kết hợp chặt chẽ giữa các yếu tố như câu lệnh, rẽ nhánh, đường đi, biểu thức và logic trong mã lệnh chương trình Để thực hiện kiểm định hiệu quả, kiểm tra viên cần có kiến thức vững về lập trình và cách thức hoạt động của mã lệnh Ngoài ra, kiểm định hộp trắng cũng đòi hỏi kiểm tra viên phải xem xét mã lệnh để phát hiện các phần tử, biểu thức hoặc đoạn mã hoạt động không chính xác.
Một số quy tắc cơ bản đối với kiểm định hộp trắng:
- Kiểm tra tất cả các đường đi độc lập ít nhất một lần
- Kiểm tra tất cả các quyết định logic (if-then-else) với giá trị TRUE/FALSE
- Kiểm tra tất cả các vòng lặp (for, while-do) tại các các giá trị biên, các giá trị bên trong biên
- Kiểm tra tính đúng đắn của tất các các cấu trúc dữ liệu nội tại trong chương trình
2.1.3 Ưu, nhược điểm của kiểm định hộp trắng
Các ƣu điểm của kiểm định hộp trắng:
Người kiểm tra có kiến thức sâu về cấu trúc nội bộ của chương trình, giúp họ dễ dàng xác định các tập dữ liệu đầu vào để thực hiện kiểm tra một cách hiệu quả.
Kiểm tra hộp trắng không chỉ tối ưu hóa mã lệnh của chương trình mà còn giúp loại bỏ những dòng mã thừa có thể ẩn chứa sai sót.
- Có thể phát hiện, loại bỏ những hiệu ứng phụ của các cấu trúc mã lệnh trong chương trình
Tuy vậy, kiểm định hộp trắng cũng tồn tại một số nhƣợc điểm:
Để đảm bảo chất lượng kiểm tra, các kiểm tra viên cần nắm vững cấu trúc chương trình và mã lệnh bên trong, điều này đòi hỏi kỹ năng chuyên môn cao hơn, dẫn đến việc tăng chi phí.
- Có thể bỏ sót các tham số kiểm tra thừa lại sau khi can thiệp vào mã lệnh của chương trình
Việc xem xét từng byte và bit trong chương trình để phát hiện các lỗi ẩn là gần như không thể, vì những lỗi này có thể gây ra sự cố trong quá trình hoạt động của chương trình.
Các chiến lƣợc kiểm tra của kiểm thử hộp trắng
2.2.1 Kiểm định đường cơ sở
Mục tiêu là tìm ra một tập cơ bản các con đường thực hiện độc lập đi qua các điểm trong chương trình ít nhất một lần
Cách thức thực hiện gồm các bước sau:
1 Từ một thiết kế hoặc một mã nguồn vẽ đồ thị dòng G tương ứng
2 Tính toán độ phức tạp chu trình V(G) của chương trình ứng với số con đường độc lập
3 Tìm tập cơ bản các con đường độc lập ứng với V(G) đã tìm
4 Thiết kế các ca kiểm định cho tập cơ bản trên
2.2.1.1 Đồ thị dòng Đồ thị dòng dùng để biểu diễn các dòng điều khiển trong chương trình và giúp xác định ra tập con đường cơ bản Đồ thị dòng (đồ thị chương trình) là một đồ thị mà:
Mỗi nút (hình tròn) biểu thị một vài câu lệnh thủ tục
Mỗi cạnh nối hai nút biểu diễn dòng điều khiển,
Chia mặt phẳng thành nhiều miền
Mỗi nút biểu thị sự phân nhánh hoặc hội nhập đƣợc gọi là nút vị từ
Hình 2.1 Các loại cấu trúc cơ bản
Hình 2.2 Ví dụ về đồ thị dòng
2.2.1.2 Tập các đường cơ bản Để đảm tất cả các câu lệnh trong chương trình đều được kiểm định ít nhất một lần, ta cần tìm được tất cả các đường độc lập trong các chu trình, tức là mỗi đường khác với các đường khác ít nhất một lệnh
Tập cơ bản các đường độc lập là tập:
Mọi cung của đồ thị dòng đều có mặt trong một đường của tập các con đường đó
Mỗi đường của tập đó đều chứa ít nhất một cung mà mọi đường khác của tập đó không có
Số lượng các đường của tập này cho ta số đo độ phức tạp chu trình của chương
Tập đường dẫn độc lập cho đồ thị lưu trình được minh họa trong hình 4 bao gồm bốn đường dẫn: Đường dẫn 1: 1-11, Đường dẫn 2: 1-2-3-4-5-10-1-11, Đường dẫn 3: 1-2-3-6-8-9-10-1-11, và Đường dẫn 4: 1-2-3-6-7-9-10-1-11 Mỗi đường dẫn mới đều tạo ra một cung mới Tuy nhiên, đường dẫn 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 không được coi là một đường dẫn độc lập vì nó chỉ là sự kết hợp của các đường dẫn đã được chỉ ra (đường dẫn 2 và 3) và không đi qua cung mới nào.
Các đường dẫn 1, 2, 3 và 4 trong hình 2.4b tạo thành một tập cơ sở Khi thiết kế các trường hợp kiểm thử cho những đường dẫn này, mọi lệnh trong chương trình sẽ được thực hiện ít nhất một lần, và mọi điều kiện sẽ được kiểm tra ở cả hai trạng thái đúng và sai Tuy nhiên, tập cơ sở không phải là duy nhất; có thể có nhiều tập cơ sở khác nhau được suy diễn cho việc thiết kế một thủ tục.
2.2.1.3 Độ phức tạp chu trình
Độ phức tạp của chu trình V(G) trong đồ thị G được xác định bởi số lượng đường độc lập trong tập cơ sở của chương trình, đây cũng là giới hạn trên cho số các kiểm định cần thực hiện.
V(G) = P + 1 Trong đó: E = số cung; N = số nút; P= số nút vị từ
Hình 2.3 Ví dụ về đồ thị dòng Công thức 1: V 1 (G) = E – N + 2 = 11 – 9 + 2 = 4
Công thức 2: V 2 (G) = R = 4 Công thức 3: Số nut vị từ P =3 Vì vậy V 3 (G) = P + 1 = 3 + 1 = 4 Nhƣ vậy, độ phức tạp chu trình của đồ thị trong hình 5 là:
Ví dụ: cho mã nguồn chương trình giải phương trình bậc 2 như sau
Begin Write('Nhap he so a,b,c');
Readln(a);Readln(b);Readln(c); delta:=sqr(b)-4*a*c;
If delta < 0 then Writeln('PTB2 vo nghiem') Else
End Else Begin X1:=-b-Sqrt(delta)/2*a;
(1) Phân tích, xác định yêu cầu mức độ kiểm định đường cơ sở
Phân tích mã nguồn nhằm xác định mức độ kiểm định của các đường cơ sở độc lập tuyến tính Mỗi đường sẽ được kiểm định thông qua kỹ thuật phân hoạch tương đương và phân tích giá trị biên.
(2) Vẽ lưu đồ, đồ thị luồng
Hình 2.4 Đồ thị dòng của phương trình bậc 2
Cách 1: V (G) =P+1 =3+1=4 (Với P số nút tân từ có trong đồ thị luồng G) Cách 2: V(G) = 4 (Số vùng của đồ thị G)
Cách 3: V (G) = E-N+2= 11-9+2 =4 (Với E là số cạnh, N là số nút)
(4)Xác định tập các đường cơ sở độc lập tuyến tính a=0 delta0 {a,b,c}={1,3,2} x1=-1, x2= -2 delta = thay cho >)
Sai biểu thức số học (ví dụ: j + k thay cho j - k)
Kiểm định điều kiện dựa trên các điều kiện để kiểm định, và bao gồm các kỹ thuật sau:
Hầu hết các phần mềm ứng dụng không thể thực hiện theo mô hình mã lệnh liên tục mà thường cần rẽ nhánh để thực hiện các chức năng lựa chọn Việc kiểm tra bao gồm việc chạy dữ liệu kiểm tra cho mỗi nhánh ít nhất một lần Kiểm tra theo dõi rẽ nhánh giúp xác nhận tính đúng đắn của tất cả các nhánh trong mã lệnh và đảm bảo rằng không có nhánh nào dẫn đến hành vi bất thường của ứng dụng.
Hình 2.5 Lưu đồ của một chương trình với các rẽ nhánh
Việc kiểm định tiến hành một cách đơn giản theo nguyên tắc sau:
Kiểm định từng điều kiện trong chương trình
Mục tiêu của kiểm định điều kiện không chỉ là phát hiện sai trong điều kiện đó mà còn là phát hiện các lỗi khác của chương trình
Kiểm định nhánh yêu cầu rằng đối với mỗi điều kiện kết hợp C, cả hai nhánh "true" và "false" của C, cũng như từng điều kiện đơn trong C, cần phải được kiểm tra ít nhất một lần.
Chiến lƣợc kiểm định theo miền đòi hỏi 3 hoặc 4 kiểm định cho một biểu thức quan hệ: Các trường hợp , =, = và
Ví dụ: Điều kiện (x > 5) Dẫn tới 3 kiểm định là: x = 5, x = 3 < 5, x = 8 > 5
Nếu biểu thức boolean có n biến thì cần tới 2 n kiểm định
Ví dụ: C = (b1 && b2) || (b3 && b4) sẽ cần 16 kiểm định tất cả
Nên n nhỏ thì thuận lợi, song nếu n lớn thì điều này là khó khả thi
Kiểm định theo miền với 2 n ca kiểm định là rất khó thực hiện trong trường hợp n lớn BRO là kỹ thuật làm giảm số ca kiểm định xuống [9]
BRO = kiểm định nhánh & toán tử quan hệ
BRO dùng “ràng buộc điều kiện cho điều kiện cần thử”
Trong điều kiện C cần thử nghiệm với n-1 điều kiện đơn, các ràng buộc của C bao gồm n điều kiện đơn, được biểu thị là (D1, D2,…, Dn), trong đó D i đại diện cho đặc tả ràng buộc đầu ra của từng điều kiện đơn tương ứng với C.
Ràng buộc D của điều kiện C được coi là được thực thi nếu trong quá trình thi hành, đầu ra của từng điều kiện đơn trong C đều đáp ứng các ràng buộc tương ứng.
Với một biến Boolean B, thì ràng buộc đầu ra của B là t (true) hoặc f (false)
Với một biểu thức quan hệ B thì ràng buộc đầu ra của B là: >, ,
Điều kiện C là hội của hai biến Boolean A và B = E, với các ràng buộc của C bao gồm các cặp (t, t), (t, f) và (f, t) Trong đó, giá trị t của (B = E) tương ứng với dấu "=" và giá trị f tương ứng với các dấu "" Tương tự, có thể áp dụng cho điều kiện của hai biến khác.
Boolean {(t, t), (t, f), (f, t)} ta có tập các ràng buộc của C phải gồm 4 phần tử: (t, =), (t,
Phủ của ràng buộc này bảo đảm đã phát hiện đƣợc sai biên Boolean hoặc toán tử quan hệ trong C
2.2.3 Kiểm định dòng dữ liệu
Kiểm định hộp đen
2.3.1 Các kỹ thuật kiểm định hộp đen
Kiểm định hộp đen là một kỹ thuật kiểm định phần mềm tập trung vào việc đánh giá hoạt động của hệ thống dựa trên dữ liệu đầu vào và đầu ra, mà không cần quan tâm đến cấu trúc bên trong Người kiểm định không có thông tin về cấu trúc chương trình và dựa vào sự đặc tả chức năng để kiểm tra tính thực thi của chúng Phương pháp này thường được gọi là kiểm định chức năng, cũng như kiểm định cách hoạt động hay kỹ thuật kiểm định hộp mờ đục Do đó, thiết kế kiểm định hộp đen và thiết kế kiểm định cách hoạt động có nhiều điểm tương đồng, dẫn đến việc phát triển kiểm định hộp đen là rất cần thiết.
Kiểm định hộp đen, như hình 2.9 minh họa, chỉ tập trung vào dữ liệu đầu vào và đầu ra của chương trình, mà không quan tâm đến cấu trúc bên trong của nó.
Hình 2.9 Một sự đặc tả đơn giản về kiểm định hộp đen
Kiểm định hộp đen dựa vào sự đặc tả và thiết kế chi tiết của hệ thống để xây dựng các giá trị đầu vào theo yêu cầu chức năng Mặc dù lý thuyết yêu cầu kiểm định tất cả các giá trị đầu vào trong miền giá trị để phát hiện lỗi, nhưng thực tế điều này không khả thi do chi phí và thời gian cao Do đó, việc xét các trường hợp kiểm định với số lượng tương đối ngẫu nhiên và đa dạng là điều chấp nhận được Tuy nhiên, điều này vẫn có thể dẫn đến nhiều hạn chế trong việc phát hiện lỗi, vì vậy cần có các giải pháp kỹ thuật phù hợp và quy trình kiểm tra hiệu quả nhằm phát hiện lỗi dữ liệu không đúng với đặc tả một cách tối ưu nhất với chi phí và thời gian tối thiểu.
Sau khi chuẩn bị các trường hợp kiểm định hợp lý, bước tiếp theo là xây dựng chương trình kiểm định để thực hiện kiểm tra các trường hợp đó Dữ liệu đầu ra dự kiến sẽ được so sánh với các kết quả của chương trình cần kiểm định, nhằm đánh giá tính chính xác và hiệu quả của quá trình kiểm định.
Hình 2.10 Mô tả đơn giản dữ liệu vào, ra của kiểm định hộp đen
Kiểm định hộp đen về cơ bản có ba phương pháp chính:
Việc kiểm thử toàn bộ các đầu vào của chương trình là không khả thi, do đó cần giới hạn kiểm thử trong một tập con của các trường hợp đầu vào Mục tiêu là lựa chọn một tập con tối ưu, tức là tập con có khả năng phát hiện hầu hết các lỗi một cách hiệu quả nhất.
Một tập con nhƣ vậy cần có hai tính chất:
Mỗi trường hợp kiểm thử nên gồm nhiều điều kiện đầu vào khác nhau có thể để giảm thiểu tổng số các trường hợp cần thiết
Phân hoạch các miền đầu vào của chương trình thành các lớp tương đương cho phép kiểm thử một giá trị đại diện trong mỗi lớp, với giả định rằng nó sẽ phát hiện lỗi tương tự như các giá trị khác trong cùng lớp Nếu một trường hợp kiểm thử trong lớp tương đương phát hiện lỗi, các trường hợp khác cũng sẽ phát hiện lỗi đó Ngược lại, nếu không có lỗi được phát hiện, thì các trường hợp khác trong lớp tương đương cũng sẽ không phát hiện lỗi, trừ khi có sự chồng chéo giữa các lớp tương đương.
Dữ liệu ra, biểu lộ các nhƣợc điểm
Dữ liệu vào nguyên do hoạt động bất thường
Phương pháp kỹ thuật hộp đen được xây dựng dựa trên hai vấn đề chính: phân hoạch tương đương và phát triển các điều kiện kiểm thử Vấn đề thứ nhất giúp xác định một tập cực tiểu các trường hợp kiểm thử, trong khi vấn đề thứ hai tập trung vào việc phát triển một tập các điều kiện cần được kiểm tra.
Thiết kế trường hợp kiểm thử bằng phương pháp phân hoạch tương đương bao gồm hai bước chính: đầu tiên, phân chia các miền đầu vào và đầu ra thành các lớp tương đương; sau đó, thiết kế các trường hợp kiểm thử đại diện cho từng lớp đó.
Xác định các lớp tương đương
“Phân hoạch tương đương” được định nghĩa theo lý thuyết tập hợp
Quan hệ trên hai tập A và B là một tập con của tích Đêcác A B, nghĩa là ab trong đó a A và b B
Quan hệ có thể đƣợc định nghĩa trên chính tập A, tức là khi B = A
Quan hệ trên tập A được định nghĩa là phản xạ nếu với mọi phần tử a thuộc A, thì a a Quan hệ được coi là đối xứng khi a b dẫn đến b a cho mọi a, b thuộc A Cuối cùng, quan hệ được gọi là bắc cầu nếu khi a b và b c thì sẽ có a c, áp dụng cho mọi a, b, c thuộc A.
Một quan hệ được gọi là quan hệ tương đương nếu nó có tính phản xạ, đối xứng và bắt cầu Ví dụ, quan hệ "=" trên tập số nguyên N là một quan hệ tương đương, trong khi quan hệ ">" trên cùng tập N lại không phải là quan hệ tương đương.
Một quan hệ tương đương phân hoạch tập hợp thành các lớp tương đương không bao nhau Chẳng hạn quan hệ =(a,b): a, b N, a+b là số chẵn có hai phân hoạch {0, 2, 4, …} và {1, 3, 5, …}
Các lớp tương đương được xác định bằng cách phân chia mỗi điều kiện đầu vào thành hai hoặc nhiều nhóm, với mục tiêu đại diện cho các trạng thái hợp lệ và không hợp lệ Điều kiện đầu vào có thể là giá trị số, miền giá trị, tập giá trị liên quan, hoặc điều kiện logic Để thực hiện quá trình này, bảng liệt kê các lớp tương đương được sử dụng như một công cụ hữu ích.
Bảng 2.1 - Bảng liệt kê các lớp tương đương Điều kiện vào/ra Các lớp tương đương hợp lệ Các lớp tương đương không hợp lệ
Các lớp tương đương có thể được định nghĩa theo các nguyên tắc sau:
1 Nếu điều kiện đầu vào xác định một khoảng giá trị, thì phân hoạch thành một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ Chẳng hạn, nếu đầu vào x nằm trong khoảng [0,100], lớp hợp lệ là 0