TỔNG QUAN VỀ KIỂM ĐỊNH PHẦN MỀM
Giới thiệu chung về kiểm định phần mềm
Quy trình và kỹ thuật kiểm định phần mềm đang thu hút sự chú ý của các chuyên gia và nhà quản lý, nhằm đáp ứng nhu cầu ngày càng cao về chất lượng ứng dụng công nghệ thông tin, đặc biệt là trong lĩnh vực phát triển sản phẩm phần mềm phục vụ cho cuộc sống.
Kiểm định phần mềm đóng vai trò quan trọng trong quy trình phát triển phần mềm, ảnh hưởng trực tiếp đến chất lượng và độ tin cậy của sản phẩm Không chỉ dừng lại ở việc phát hiện lỗi, kiểm định còn nâng cao sự tin cậy thông qua việc đánh giá các chức năng và thuộc tính khác của phần mềm.
Kiểm định phần mềm là quá trình đánh giá năng lực và khả năng của phần mềm thông qua nhiều nhiệm vụ phức tạp Đầu tiên, cần xây dựng một bộ các trường hợp kiểm định đầy đủ và lựa chọn kỹ thuật kiểm định phù hợp Tuy nhiên, việc chọn hình thức kiểm định chỉ là bước khởi đầu; còn nhiều yếu tố quyết định khác liên quan đến chuyên môn kỹ thuật và các khái niệm phức tạp Các quyết định này bao gồm việc xác định kiểu kiểm định, đánh giá tính chấp nhận được của kết quả kiểm định, và nếu không chấp nhận được, cần phân tích nguyên nhân lỗi và tác động của chúng Cuối cùng, việc đánh giá khả năng kiểm định và quyết định dừng hay tiếp tục kiểm tra dựa vào các tiêu chuẩn hiệu lực là rất quan trọng.
Trong luận văn này các thuật ngữ kiểm định, kiểm tra và kiểm thử đƣợc sử dụng với cùng một ý nghĩa.
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 đối với các đặc tả, thiết kế và mã nguồn của phần mềm.
Kiểm định phần mềm thường được hiểu là quá trình "chạy thử" phần mềm hoặc một chức năng cụ thể của nó để xác định xem chúng hoạt động đúng như mong đợi hay không.
Theo Glen Myers, kiểm định phần mềm là quá trình chạy chương trình nhằm phát hiện lỗi 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 nhận diệ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 mỗi chức năng hoặc module phát triển, hoặc tiến hành tổng thể khi phần mềm đã hoàn tất.
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:
Hình 1.1 Các mức độ cơ bản của kiểm tra phần mềm
1.3.1 Kiểm định đơn vị Để có thể hiểu rõ về kiểm định đơn vị, khái niệm trước tiên ta cần làm rõ: thế nào là một đơn vị phần mềm [2] Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm tra đƣợc Theo định nghĩa này, các hàm, thủ tục, lớp, hoặc các phương thức đều có thể được xem là đơn vị
Việc kiểm tra các đơn vị nhỏ với chức năng đơn giản giúp dễ dàng tổ chức, ghi nhận và phân tích kết quả Khi phát hiện lỗi, xác định nguyên nhân và khắc phục sẽ thuận lợi hơn do chỉ cần khoanh vùng trong đơn vị đang kiểm tra Nguyên lý thực tiễn cho thấy, thời gian dành cho kiểm định ban đầu sẽ được bù đắp bằng việc tiết kiệm đáng kể thời gian và chi phí cho các kiểm tra và sửa lỗi sau này.
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 giai đoạn viết code cũng như xuyên suốt chu kỳ phát triển phần mềm Quá trình này yêu cầu kiểm tra viên phải 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 của kiểm định đơn vị là đảm bảo thông tin được xử lý và xuất ra là chính xác, tương quan với dữ liệu đầu vào và chức năng của đơn vị Để đạt được điều này, tất cả các nhánh bên trong đơn vị cần được kiểm tra nhằm phát hiện các lỗi tiềm ẩn Một nhánh có thể được hiểu là chuỗi lệnh được thực thi trong một đơn vị, chẳng hạn như các lệnh sau điều kiện if trong khối then else Việc lựa chọn các nhánh để đơn giản hóa quy trình kiểm tra đòi hỏi kỹ thuật và đôi khi cần sử dụng thuật toán để thực hiện hiệu quả.
Kiểm định đơn vị yêu cầu chuẩn bị kỹ lưỡng trước mỗi ca kiểm định, bao gồm việc xác đị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 này là cần thiết để tái sử dụng trong tương lai.
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 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 cho giao tiếp giữa đơn vị và các thành phần khác, nhưng việc kiểm tra giao tiếp thực sự chỉ được thực hiện đầy đủ khi các đơn vị được tích hợp và kiểm định trong quá trình 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à tích hợp từng đơn vị một cách dần dần Mỗi đơn vị sẽ được thêm vào một nhóm các đơn vị đã hoàn tất 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 hệ thống các đơn vị đã tích hợp, từ đó giảm thiểu số lượng kiểm tra 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 và công sức Việc kiểm tra này có thể 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 bố hoặc hệ thống nhúng Người kiểm tra tìm kiếm lỗi ở mức độ hệ thống, tập trung vào đánh giá hiệu suất, thao tác, độ 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 đến 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ể khi làm việc cùng nhau Để đảm bảo mọi đơn vị và sự tương tác giữa chúng hoạt động chính xác, cần thực hiện kiểm định đơn vị và kiểm định tích hợp 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 và 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 Phương pháp 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, bao gồm các vấn đề như "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 thường đượ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, vì vậy kiểm định hệ thống 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à một quy trình quan trọng, tập trung vào việc đánh giá các trạng thái tới hạn, xác định các "điểm chết" và phân tích các tình huống bất thường khi nhiều người truy xuất dữ liệu cùng lúc.
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à bước quan trọng để đảm bảo hệ thống có thể khôi phục trạng thái ổn định trước đó khi gặp tình huống mất tài nguyên hoặc dữ liệu Điều này đặc biệt cần thiết đố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, các loại kiểm tra hệ thống là rất cần thiết để đảm bảo khả năng hoạt động trong môi trường thực tế Tuy nhiên, không nhất thiết phải thực hiện tất cả các loại kiểm tra 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 mà không xem xét cấu trúc bên trong, trong khi kiểm định hộp trắng lại phân tích cấu trúc và mã nguồn của phần mềm.
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 phần mềm, trong đó phần mềm được thực thi với các dải dữ liệu đầu vào và đầu ra để xác định tính chính xác Phương pháp này không quan tâm đến cách thức đạt được kết quả đầu ra hay các yếu tố bên trong "hộp", mà chỉ xem xét hệ thống như một hộp đen thuần túy, không cần biết đến cấu trúc bên trong.
Mặc dù kiểm định hộp đen mang lại nhiều ưu điểm, nhưng nó vẫn chưa đủ để đảm bảo chất lượng hệ thống Các hệ thống thực tế thường có nhiều loại dữ liệu đầu vào khác nhau, dẫn đến sự bùng nổ trong 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, có thể thực hiện một tập các ca kiểm định tiêu biểu với khoảng 100 dòng lệnh Tuy nhiên, đối với các hệ thống lớn như mô phỏng đào tạo phi công lái 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.
Không thể xác định được các phần mã lệnh nào trong chương trình đã được kiểm tra bằng kỹ thuật kiểm định hộp đen 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 trong gói phần mềm, vì chúng chưa được kiểm tra và có thể gây ra sự cố trong tương lai.
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ế, chẳng hạn như đảm bảo rằng tất cả các dòng mã lệnh được thực thi ít nhất một lần và kiểm tra các chức năng một cách độc lập Phương pháp này cho phép người kiểm tra tiếp cận bên trong phần mềm, tập trung vào các thông tin nội tại để lựa chọn dữ liệu kiểm tra một cách hiệu quả.
Kiểm định hộp trắng yêu cầu hiểu biết sâu sắc về cấu trúc nội bộ của chương trình, trong khi kiểm định hộp đen chỉ cần nắm rõ 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 kiểm tra viên phải nắm rõ 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 Để thực hiện kiểm định hiệu quả, kiểm tra viên cần có kiến thức về lập trình và hiểu cách thức hoạt động của mã lệnh Họ cũng phải xem xét mã lệnh để xác định 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 phù hợp để thực hiện kiểm tra một cách hiệu quả.
Kiểm tra hộp trắng mang lại lợi ích trong việc tối ưu hóa mã lệnh của chương trình, đồng thời loại bỏ các 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í cho quy trình kiểm tra.
- 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 giấu gần như là không khả thi, 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 hoạ trong hình 4 là: Đườ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 Đường dẫn 4: 1-2-3-6-7-9-10-1-11
Mỗi đường dẫn mới tạo ra một cung mới, nhưng đường dẫn 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 không được coi là độc lập Đây chỉ là sự kết hợp của các đường dẫn đã chỉ ra (đường dẫn 2 và 3) và không đi qua cung nào mới.
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ở cho việc kiểm thử Khi thiết kế các trường hợp kiểm thử dựa trên tập cơ sở 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 mặt đúng và sai Tuy nhiên, cần lưu ý rằng tập cơ sở không phải là duy nhất; trên thực tế, có thể có nhiều tập cơ sở khác nhau được suy diễn để thiết kế một thủ tục kiểm thử.
2.2.1.3 Độ phức tạp chu trình
Số lượng đường độc lập trong tập cơ sở của chương trình xác định giới hạn tối đa cho số kiểm định cần thực hiện, được gọi là độ phức tạp của chu trình Độ phức tạp chu trình V(G) của đồ thị G có thể được tính bằng nhiều phương pháp khác nhau.
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: V1(G) = E – N + 2 = 11 – 9 + 2 = 4
Công thức 3: Số nut vị từ P =3 Vì vậy V3(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
Readln(a);Readln(b);Readln(c); delta:=sqr(b)-4*a*c;
(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 tập 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ể viết 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 các 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 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 định í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à
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, để thử nghiệm 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 ký hiệu là (D1, D2, …, Dn) Mỗi Di đại diện cho một đặc tả ràng buộc đầu ra tương ứng của điều kiện đơn trong C.
Ràng buộc D của điều kiện C được coi là được thi hành nếu trong quá trình thi hành, đầu ra của mỗi đ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 là các cặp (t, t), (t, f) và (f, t) Trong đó, (B = E) có giá trị t tương ứng với dấu "=" và giá trị f tương ứng với các dấu "" Tương tự, điều kiện này cũng áp dụng cho 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
Phương pháp kiểm định dòng dữ liệu giúp xác định và sử dụng các biến trong chương trình, đồng thời định vị các đường tương ứng Nhiều chiến lược kiểm định dòng dữ liệu đã được phát triển và so sánh để nâng cao hiệu quả trong quá trình kiểm tra.
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 thông qua 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, mà chỉ dựa vào đặc tả chức năng để kiểm tra tính thực thi Phương pháp này thường được gọi là kiểm định chức năng, kiểm định cách hoạt động, hoặc kiểm định hộp mờ đục Thiết kế kiểm định hộp đen và 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 quy trình thiết kế kiểm định hộp đen.
Kiểm định hộp đen, như hình 2.9 minh họa, tập trung vào dữ liệu đầu vào và đầu ra của chương trình mà không chú ý đế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 đặc tả hệ thống và thiết kế chi tiết để xây dựng các giá trị đầu vào cho các yêu cầu chức năng của chương trình Mặc dù lý thuyết yêu cầu kiểm định tất cả giá trị đầu vào trong miền giá trị để phát hiện lỗi, thực tế cho thấy điều này không khả thi do chi phí và thời gian cao Thay vào đó, việc lựa chọn ngẫu nhiên và đa dạng một số lượng hợp lý các trường hợp kiểm định là chấp nhận được Tuy nhiên, phương pháp này vẫn có hạn chế trong việc phát hiện lỗi, do đó cần 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ả 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 một cách 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 với kết quả dữ liệu dự kiến Cuối cùng, cần so sánh các kết quả của chương trình kiểm định với đặc tả để đánh giá tính chính xác của kết quả 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ử tất cả 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 cao nhất để phát hiện hầu hết các lỗi trong chương trình.
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 giúp kiểm thử hiệu quả hơn Việc kiểm thử một giá trị đại diện trong mỗi lớp có thể coi là tương đương với việc kiểm thử bất kỳ giá trị nào trong cùng lớp, mặc dù không đảm bảo hoàn toàn Nếu một trường hợp kiểm thử trong lớp tương đương phát hiện lỗi, thì tất cả các trường hợp khác trong lớp đó cũng sẽ phát hiện lỗi tương tự Ngược lại, nếu không phát hiện lỗi, 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
Hai vấn đề nêu trên hình thành phương pháp kỹ thuật hộp đen, được gọi là phân hoạch tương đương Vấn đề thứ hai nhằm phát triển một tập hợp các điều kiện cần được kiểm thử Trong khi đó, vấn đề thứ nhất giúp xây dựng một tập hợp tối thiểu các trường hợp kiểm thử để bao phủ các điều kiện này.
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 đã được xác định.
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 gọi là phản xạ nếu aa với aA
Quan hệ trên tập A gọi là đối xứng nếu ab ba với a, bA
Quan hệ trên tập A gọi là bắc cầu nếu ab và bc ac với a,b,c A
Quan hệ tương đương là một quan hệ có tính phản xạ, đối xứng và bắt cầu Ví dụ, quan hệ "=" trên tập hợp số nguyên N là một quan hệ tương đương, trong khi quan hệ ">" trên cùng tập hợp N 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 điều kiện đầu vào thành nhiều nhóm, mỗi nhóm biểu diễn một tập hợp các trạng thái hợp lệ hoặc 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 để tổ chức và phân loại các điều kiện đầu vào một cách hiệu quả.
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
