Luận văn thạc sĩ VNU UET kiểm định phần mềm theo tiếp cận hệ thống

TỔNG QUAN VỀ KIỂM ĐỊNH PHẦN MỀM

Giới thiệu chung về kiểm định phần mềm

Các quy trình và kỹ thuật kiểm định phần mềm là các vấn đề hiện nay đang đƣợc các nhà chuyên môn và quản lý quan tâm, nhằm đáp ứng cho nhu cầu ngày càng cao về kiểm định chất lƣợng của các ứng dụng công nghệ thông tin nói chung và cụ thể là các sản phẩm phần mềm trong các lĩnh vực cuộc sống

Kiểm định phần mềm là một phần quan trọng và quyết định của quá trình phát triển phần mềm trên chất lƣợng và độ tin cậy của sản phẩm chuyển giao Kiểm định không giới hạn để phát hiện lỗi trong phần mềm, mà sự tin cậy tăng lên trong các chức năng của chúng với sự đánh giá của các thuộc tính chức năng cũng nhƣ các thuộc tính khác [2]

Kiểm định phần mềm là một hoạt động kiểm tra năng lực, khả năng của phầm mềm bao gồm nhiều nhiệm vụ đòi hỏi khắt khe khác nhau: trước hết là nhiệm vụ xuất phát từ một bộ đầy đủ các trường hợp kiểm định thích hợp, theo một kỹ thuật kiểm định phần mềm đƣợc chọn lựa có lợi và có khả năng thực hiện đƣợc Tuy nhiên, sự lựa chọn hình thức kiểm định mới chỉ là một điểm bắt đầu mà còn nhiều nhiệm vụ quyết định khác thể hiện các mặt về chuyên môn kỹ thuật và các khái niệm phức tạp: chặng hạn khả năng để chọn lựa các kiểu kiểm định; sự quyết định các kết quả kiểm định có thể chấp nhận được hay không; nếu không thì đánh giá sự ảnh hưởng của sự cố lỗi chương trình và phát hiện nguyên nhân trực tiếp cũng như gián tiếp lỗi của chúng, phân tích các nguyên nhân cơ bản; đánh giá kiểm định là có khả năng và có thể dừng lại đƣợc, phụ thuộc lần lƣợt việc kiểm tra các tiêu chuẩn đánh giá hiệu lực của kiểm định

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 là phần mấu chốt của đảm bảo chất lƣợng phần mềm và biểu thị cho việc xét duyệt tối hậu về đặc tả, thiết kế và mã hóa

Theo nghĩa thông thường nhất, kiểm định phần mềm bao gồm việc "chạy thử" phần mềm hay một chức năng của phần mềm, xem nó chạy đúng nhƣ mong muốn hay không

Theo Glen Myers [15] thì kiểm định là một quá trình vận hành chương trình với ý định tìm ra các lỗi của phần mền Một (lần) kiểm định tốt là kiểm định có xác suất cao trong việc tìm ra một lỗi chƣa đƣợc phát hiện Một (lần) kiểm định thành công là một kiểm định làm lộ ra đƣợc ít nhất một lỗi còn chƣa đƣợc phát hiện.

Quy trình kiểm định phần mềm

Việc kiểm định phần mềm có thể thực hiện từng bước, sau mỗi chức năng hoặc module đƣợc phát triển, hoặc thực hiện sau cùng, khi phần mềm đã đƣợc phát triển 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ị

Vì đơn vị được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, sẽ không khó khăn gì trong việc tổ chức, kiểm tra, ghi nhận và phân tích kết quả kiểm tra Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể đơn vị đang kiểm tra Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho kiểm định đơn vị sẽ đƣợc đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm tra và sửa lỗi ở các mức kiểm tra sau đó

Kiểm định đơn vị thường do lập trình viên thực hiện Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm Thông thường, kiểm định đơn vị đòi hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình Mục đích của kiểm định đơn vị là bảo đảm thông tin được xử lý và xuất (khỏi đơn vị) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của đơn vị Điều này thường đòi hỏi tất cả các nhánh bên trong đơn vị đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi Một nhánh thường là một chuỗi các lệnh đƣợc thực thi trong một đơn vị, ví dụ: chuỗi các lệnh sau điều kiện if và nằm giữa then else là một nhánh Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm tra và quét hết đơn vị đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để thực hiện

Cũng nhƣ các mức kiểm tra khác, kiểm định đơn vị cũng đòi hỏi phải chuẩn bị trước các ca kiểm định hoặc kịch bản, trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra Các ca kiểm định và kịch bản này nên đƣợc giữ lại để tái sử dụng

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 kết hợp các thành phần của một ứng dụng và kiểm tra nhƣ một ứng dụng đã hoàn thành [15] Trong khi kiểm định đơn vị kiểm tra các thành phần và đơn vị riêng lẻ thì kiểm định tích hợp kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng

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 cố gắng 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ị Có một số phép kiểm tra đơn giản trên giao tiếp giữa đơn vị với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến đơn vị thật sự đƣợc kiểm tra đầy đủ khi các đơn vị tích hợp với nhau trong khi thực hiện kiểm định tích hợp

Một chiến lƣợc cần quan tâm trong kiểm định tích hợp là nên tích hợp dần từng đơn vị Một đơn vị tại một thời điểm đƣợc tích hợp vào một nhóm các đơn vị khác đã tích hợp trước đó và đã hoàn tất các đợt kiểm định tích hợp trước đó Lúc này, ta chỉ cần kiểm tra giao tiếp của đơn vị mới thêm vào với hệ thống các đơn vị đã tích hợp trước đó, điều này làm cho số lượng kiểm tra sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể

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 của phần mềm đã đƣợc tích hợp thành công Thông thường loại kiểm tra này tốn rất nhiều công sức và thời gian

Trong nhiều trường hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng Ở mức độ hệ thống, người kiểm tra cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lƣợng của toàn hệ thống Điểm khác nhau then chốt 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 các hành vi và lỗi trên toàn hệ thống, còn kiểm định tích hợp chú trọng sự giao tiếp giữa các đơn thể hoặc đối tƣợng khi chúng làm việc cùng nhau Thông thường ta phải thực hiện kiểm định đơn vị và kiểm định tích hợp để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện kiểm định hệ thống

Kiểm định hệ thống kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lƣợng nhƣ độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật

Mức kiểm tra này đặc biệt thích hợp cho 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, chẳng hạn các lỗi "tắc nghẽn" hoặc chiếm dụng bộ nhớ

Sau giai đoạn kiểm định hệ thống, phần mềm thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm tra để chấp nhận hoặc dùng thử (Alpha/Beta Test) Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, kiểm định hệ thống thường được thực hiện bởi một nhóm kiểm tra viên hoàn toà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

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à các phương pháp kiểm định phần mềm: kiểm định hộp đen (black-box, chức năng) và kiểm định hộp trắng (white-box , cấu trúc) [2]

Kiểm định hộp đen thường được hiểu theo nghĩa là tập trung vào kiểm tra các yêu cầu chức năng của ứng dụng phần mềm Phần mềm đƣợc thực thi đầy đủ đối với các dải dữ liệu đầu vào và tập dữ liệu đầu ra sẽ đƣợc xem xét xem có đúng đắn không

Cách thức để đạt đƣợc kết quả đầu ra này hay cái gì bên trong “hộp” thì không cần quan tâm đến Kiểm định hộp đen coi hệ thống nhƣ một hộp đen thuần túy, vì vậy nó không cần biết đến các cấu trúc bên trong

Mặc dù kiểm định hộp đen có nhiều ƣu điểm nhƣng bản thân nó thì chƣa đủ

Trước tiên, các hệ thống trong đời thường có rất nhiều loại dữ liệu đầu vào khác nhau, điều đó dẫn tới sự bùng nổ các ca kiểm định Ví dụ, đối với một chương trình kiểm tra số dƣ trong tài khoản ở Ngân hàng (check-balancing) là khoảng 100 dòng lệnh, ta có thể chạy một tập các ca kiểm định tiêu biểu, nhƣng đối với hệ thống lớn nhƣ hệ thống mô phỏng để đào tạo phi công lái máy bay 747 thì không thể kiểm tra chặt chẽ các thông số đầu vào/đầu ra dựa trên kỹ thuật kiểm định hộp đen

Thêm nữa là không thể biết được các phần mã lệnh nào của chương trình có thực hiện bằng kỹ thuật kiểm định hộp đen Các đoạn mã lệnh mà chƣa thực hiện trong quá trình kiểm tra đƣợc ví nhƣ một quả bom nổ chậm trong gói phần mềm Tất nhiên, những đoạn mã lệnh chƣa thực hiện nghĩa là chƣa đƣợc test

Một giải pháp cho vấn đề này là sử dụng kiểm tra hộp trắng bổ sung thêm cho kiểm tra hộp đen Chiến thuật kiểm tra hộp trắng bao gồm các kiểm tra thiết kế nhƣ các dòng mã lệnh phải đƣợc thực thi ít nhất một lần hoặc kiểm tra các chức năng một cách riêng biệt Kiểm định hộp trắng cho phép người kiểm tra xem xét bên trong, nó đặc biệt chú trọng các thông tin bên trong của phần mềm để chọn các dữ liệu kiểm tra một các hiệu quả

Kiểm định hộp trắng đòi hỏi phải có các am hiểu bên trong chương trình, trong khi đó kiểm định hộp đen chỉ dựa trên hiểu biết về các yêu cầu hệ thống nói chung

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

Các bài kiểm tra dựa trên kỹ thuật kiểm định hộp trắng kết hợp chặt chẽ các yếu tố bao gồm các câu lệnh, các rẽ nhánh, đường đi, biểu thức và logic bên trong của mã lệnh chương trình Để thực hiện kiểm định, kiểm tra viên phải quan tâm, làm việc với mã lệnh và do đó cần am hiểu, có kiến thức về lập trình và cách thức hoạt động bên trong của mã lệnh Kiểm định hộp trắng cũng yêu cầu kiểm tra viên xem xét trong mã lệnh và tìm ra phần tử/biểu thức/đoạn mã nào 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:

- Vì người kiểm tra am hiểu về cấu trúc bên trong của chương trình, do đó rất dễ để tìm ra các tập dữ liệu đầu vào để kiểm tra chương trình một cách hiệu quả

- Một ƣu điểm nữa là kiểm tra hộp trắng giúp cho việc tối ƣu các mã lệnh của chương trình Nó cũng giúp loại bỏ các dòng mã lệnh thừa mà có thể tiềm ẩn những 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:

- Do yêu cầu phải nắm rõ cấu trúc chương trình và mã lệnh bên trong, các kiểm tra viên cần có kỹ năng cao hơn dẫn tới 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

- Gần như không thể xem xét tất cả đến byte/bit của chương trình để tìm các lỗi ẩn giấu mà có thể làm chương trình xảy ra lỗi khi hoạt động.

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 đưa ra một cung mới Đường dẫn 1-2-3-4-5-10-1-2-3-6-8-9- 10-1-11 không được xem là một đường dẫn độc lập vì nó chỉ là một tổ hợp các đường dẫn đã được chỉ ra (đường dẫn 2 và 3) và nó sẽ không đi qua một cung mới nào

Các đường dẫn 1, 2, 3 và 4 tạo thành một tập cơ sở trong hình 2.4b Nếu các trường hợp kiểm thử được thiết kế để thực hiện những đường dẫn này (một tập cơ sở) thì mọi lệnh trong chương trình sẽ đảm bảo được thực hiện ít nhất một lần và mọi điều kiện sẽ đƣợc thực hiện cả hai mặt đúng (true) và mặt sai (false) Tuy nhiên, tập cơ sở không phải là duy nhất Trong thực tế, một số các tập cơ sở khác nhau có thể đƣợc suy diễn cho việc thiết kế một thủ tục đƣợc đƣa ra

2.2.1.3 Độ phức tạp chu trình

Số các đường độc lập trong tập cơ sở của chương trình là giới hạn trên của số các kiểm định cần phải tiến hành 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 tính theo các cách sau:

 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: V1(G) = E – N + 2 = 11 – 9 + 2 = 4

Công thức 2: V2(G) = R = 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

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ở

Yêu cầu phân tích mã nguồn, xác định mức độ kiểm định tập các đường cơ sở độc lập tuyến tính Mỗi đường sẽ được tiến hành kiểm định bằng 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 nhƣ không phần mềm ứng dụng nào có thể viết theo mô hình mã lệnh tiếp diễn liên tục, mà thường tại một số điểm chúng cần phải rẽ nhánh để thực hiện một chức năng lựa chọn nào đó Việc kiểm tra bao gồm chạy các dữ liệu kiểm tra 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 tất cả các rẽ nhánh trong mã lệnh và khẳng định không có nhánh nào dẫn tới hành xử 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: với mỗi điều kiện kết hợp C, thì các nhánh “true” và “false” của C và mỗi một điều kiện đơn trong C 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à 

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ử”

 Giả sử trong điều kiện C cần thử có n-1 điều kiện đơn, các ràng buộc của C (có n điều kiện đơn) là (D1, D 2 ,…, Dn), trong đó Di là một đặc tả ràng buộc đầu ra của điều kiện đơn tương ứng của C

 Ta nói rằng ràng buộc D của điều kiện C là đƣợc phủ bởi một thi hành của C nếu nhƣ trong quá trình thi hành đó, đầu ra (“outcome”) của mỗi điều kiện đơn trong C thoả mãn 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à: >, ,

Ví dụ xét điều kiện C là hội của hai biến Boolean: A và B = E Khi đó các ràng buộc của C là các cặp (t, t), (t, f) và (f, t); với (B = E) có giá trị t tương ứng với “=“, và giá trị f tương ứng với “” Xét tương tự trên đối với điều kiện hai biến

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 chỉ quan tâm cách hoạt động của hệ thống dựa trên các dữ liệu vào và dữ liệu ra mà không quan tâm cấu trúc bên trong của hệ thống Người kiểm định không có thông tin về cấu trúc chương trình

Theo phương pháp này người kiểm định hệ thống dựa trên sự đặc tả các chức năng để tiến hành kiểm định tính thực thi của chúng có đúng với đặc tả không Với lý do này kiểm định hộp đen đƣợc xét bằng kiểm định chức năng Kỹ thuật kiểm định này cũng đƣợc gọi là kiểm định cách hoạt động hay kỹ thuật kiểm định hộp mờ đục hoặc hộp đóng hoàn toàn Nhƣ vậy kiểm định hộp đen là một kiểm định cách hoạt động và theo đó việc thiết kế kiểm định cách hoạt động không khác là bao nhiêu từ thiết kế kiểm định hộp đen và đây là lý do để ta đƣa ra việc thiết kế xây dựng kiểm định hộp đen

Hình 2.9 dưới đây cho thấy kiểm định hộp đen không quan tâm đến cấu trúc bên trong của chương trình mà chỉ quan tâm đến dữ liệu vào (input) và dữ liệu ra (output)

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 về cơ bản là dựa vào sự đặc tả của hệ thống, các thiết kế chi tiết để xây dựng các giá trị đầu vào theo tất cả các yêu cầu chức năng của chương trình hay còn gọi là thiết kế các trường hợp kiểm định theo đặc tả Xét về mặt lý thuyết để tìm hết tất cả các lỗi trong chương trình cần kiểm định thì chúng ta phải kiểm định tất cả các giá trị đầu vào trong miền giá trị Nhƣng trong thực tế điều này không thể thực hiện được bởi vì chi phí quá cao và tốn nhiều thời gian Việc xét các trường hợp kiểm định với một số lượng tương đối theo ngẫu nhiên và đa dạng các giá trị dữ liệu vào là điều có thể "Chấp nhận" Tuy nhiên, theo đó vẫn sẽ gặp phải nhiều hạn chế trong việc phát hiện lỗi, vấn đề đặt ra cần phải có các giải pháp kỹ thuật thích hợp và thực hiện theo một quy trình nào đó nhằm kiểm tra phát hiện một cách tốt nhất các lỗi dữ liệu ra không đúng với đặc tả hay các lỗi dị thường với chi phí và thời gian tiêu tốn ít nhất có thể cho phép

Sau khi chuẩn bị các trường hợp kiểm định một cách hợp lý, công việc tiếp theo là xây dựng chương trình kiểm định để tiến hành kiểm định cho các trường hợp với dự kiến kết quả dữ liệu ra, cuối cùng là so sánh các kết quả của chương trình cần kiểm định với đặc tả để đánh giá 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 thể Vì thế, khi kiểm thử chương trình nên giới hạn một tập con tất cả các trường hợp đầu vào có thể có Tất nhiên, người ta mong muốn lựa chọn một tập con đúng (tức là, một tập con có xác suất cao nhất phát hiện hầu hết các lỗi)

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 một chương trình thành một số xác định các lớp tương đương, sao cho có thể giả định hợp lý rằng việc kiểm thử một giá trị đại diện của mỗi lớp là tương đương với việc kiểm thử một giá trị bất kỳ trong cùng lớp đó (tuy điều này không đảm bảo tuyệt đối) Có nghĩa là, nếu một trường hợp kiểm thử trong một lớp tương đương phát hiện ra một lỗi, thì tất cả các trường hợp khác trong lớp tương đương sẽ phát hiện ra cùng một lỗi đó

Ngược lại, nếu một trường hợp kiểm thử không phát hiện ra một lỗi, thì không có trường hợp nào khác trong lớp tương đương đó phát hiện ra lỗi (trừ khi một tập con của lớp tương đương nằm trong một lớp tương đương khác, vì các lớp tương đương có thể gối lên nhau)

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 đề xem xét ở trên tạo thành một phương pháp của kỹ thuật hộp đen và gọi là phân hoạch tương đương Vấn đề thứ hai được sử dụng để phát triển một tập các điều kiện cần quan tâm phải đƣợc kiểm thử Vấn đề thứ nhất đƣợc sử dụng để phát triển một tập cực tiểu các trường hợp kiểm thử phủ các điều kiện trên

Thiết kế trường hợp kiểm thử bằng phân hoạch tương đương được xử lý theo hai bước: phân hoạch các miền đầu vào/ra thành các lớp tương đương, và thiết kế các trường hợp kiểm thử đại diện cho mỗi 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à ab 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 aa với aA Quan hệ  trên tập A gọi là đối xứng nếu ab  ba với a, bA Quan hệ  trên tập A gọi là bắc cầu nếu ab và bc  ac với a,b,c  A

Một quan hệ có tính phản xạ, đối xứng và bắt cầu gọi là quan hệ tương đương

Chẳng hạn quan hệ “=” trên tập N (số nguyên) là quan hệ tương đương nhưng quan hệ “>” trên tập N thì không phải

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, …}

Như vậy, các lớp tương đương được nhận dạng bằng cách lấy mỗi điều kiện đầu vào (thông thường là một câu lệnh hoặc một cụm từ trong đặc tả) và phân hoạch nó thành hai hoặc nhiều nhóm Các lớp tương đương biểu diễn một tập các trạng thái hợp lệ hoặc không hợp lệ cho điều kiện đầu vào Điều kiện đầu vào là giá trị số xác định, hoặc miền giá trị, tập giá trị có liên quan, hoặc điều kiện logic Để làm điều này, chúng ta sử dụng bảng liệt kê các lớp tương đương

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 0) và một dãy N số nguyên gọi là các phần tử của dãy

+ K là phần tử bất kỳ của dãy

+ Chương trình P sắp xếp dãy theo thứ tự tăng dần và xuất ra dãy đã sắp xếp

P đƣợc xem là đúng với đặc tả S nếu và chỉ nếu: với mỗi đầu vào hợp lệ, đầu ra của P tương ứng với đặc tả của S

Có nhiều phương pháp sắp xếp khác nhau đã được nghiên cứu và phát triển Mỗi phương pháp có ưu và nhược điểm riêng về độ phức tạp tính toán và thời gian thực hiện Vì vậy, để lấy ví dụ tốt cho việc kiểm thử về khả năng thực hiện, chúng ta chọn hai nhóm thuật toán sau để thực hiện kiểm thử hộp đen và so sánh kết quả thực hiện Độ phức tạp O(n 2 ): Insertion Sort, Selection Sort, Shell Sort, Bubble Sort Độ phức tạp O(n log n): Heap Sort, Quick Sort, Merge Sort

Việc kiểm thử đơn vị trên các mođun của các thuật toán này sử dụng các phương pháp kiểm thử hộp trắng (phương pháp đường dẫn cơ sở) Và để minh hoạ cho qui trình kiểm thử tích hợp chúng ta thử lấy module MergeSort để thiết kế bộ kiểm thử

Phát sinh các trường hợp kiểm thử Chiến lƣợc kiểm thử

Việc kiểm thử thuật toán sắp xếp đƣợc thực hiện theo nhiều mức khác nhau:

Mức cao: bao gồm việc kiểm thử chức năng, kiểm thử khả năng thực hiện (thời gian, khả năng tối đa,…)

Mức thấp: bao gồm việc kiểm thử đơn vị và kiểm thử khi tích hợp các thành phần

Với việc kiểm thử ở mức cao cho các thuật toán sắp xếp, chúng ta sẽ thiết kế các trường hợp kiểm thử nhằm kiểm tra khả năng tối đa (số phần tử tối đa của dãy) và hiệu quả của thuật toán (thời gian thực hiện, … của mỗi thuật toán trên các bộ dữ liệu vào khác nhau) Ở mức kiểm thử này, chúng ta không can thiệp vào cấu trúc mã bên trong của thuật toán, mà chỉ dựa vào đặc tả thuật toán để phát sinh dữ liệu kiểm thử Vì vậy, ở mức này chúng ta sẽ sử dụng các phương pháp hộp đen (trình bày trong chương 2) để sinh dữ liệu đầu vào và kiểm tra các kết quả đầu ra theo đặc tả của thuật toán Ở mức thấp, để thực hiện kiểm thử cho các thuật toán cần thiết kế các trường hợp kiểm thử với mục đích tìm lỗi của mã lệnh Vì vậy, chúng ta cần thâm nhập vào mã lệnh của thuật toán và áp dụng các phương pháp hộp trắng (chẳng hạn phương pháp đường dẫn cơ sở) để phát sinh các trường hợp kiểm thử, và xây dựng bộ dữ liệu kiểm thử tương ứng