Kiểm định phần mềm theo tiếp cận hệ thống

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ườn

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Đoàn Văn Trung

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CễNG NGHỆ

Đoàn Văn Trung

Kiểm định phần mềm theo tiếp cận hệ thống

Ngành : Cụng nghệ thụng tin

Mó ngành: 1.01.10

Luận văn thạc sỹ

Người hướng dẫn khoa học:

PGS TSKH Nguyễn Xuõn Huy

Hà Nội - 2007

CHƯƠNG 1 TỔNG QUAN VỀ KIỂM ĐỊNH PHẦN MỀM

1.1 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

1.2 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

1.3 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:

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)

 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

Đ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

(ví dụ nhiều người truy xuất cùng lúc) Kiểm tra khả năng chịu tải tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thường,

 Kiểm tra cấu hình

 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: bảo đảm hệ thống có khả năng khôi phục trạng

thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặ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

Nhìn từ quan điểm người dùng, các kiểm tra trên rất quan trọng: bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực Lưu ý không nhất thiết phải thực hiện tất cả các loại kiểm tra nêu trên Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, trưởng dự án sẽ quyết định áp dụng những loại kiểm tra nào

1.3.4 Kiểm định chấp nhận

Thông thường, sau giai đoạn kiểm định hệ thống là kiểm định chấp nhận, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện) [1] Mục đích của kiểm định chấp nhận là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng)

Kiểm định chấp nhận có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm tra của kiểm định hệ thống và kiểm định chấp nhận gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt

Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng, thông thường sẽ thông qua hai loại kiểm tra gọi là Alpha Test và Beta Test Với Alpha Test, người sử dụng (tiềm năng) kiểm tra phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa Với Beta Test, phần mềm sẽ được gửi tới cho người sử dụng (tiềm năng) để kiểm tra ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa

Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì kết quả kiểm định chấp nhận sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm tra trước đó Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng Ví dụ, đôi khi một phần mềm xuất sắc vượt qua các phép kiểm tra về chức năng thực hiện bởi nhóm thực hiện dự án, nhưng khách hàng khi kiểm tra sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng, v.v

Gắn liền với giai đoạn kiểm định chấp nhận thường là một nhóm những dịch vụ

và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng, v.v Mọi tài liệu đi kèm phải được cập nhật và kiểm tra chặt chẽ

CHƯƠNG 2 CÁC KỸ THUẬT KIỂM ĐỊNH PHẦN MỀM

2.1 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 [13]

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

2.2 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 đường dẫn độc lập cho đồ thị lưu trình được minh hoạ trong hình 4 là:

1-2-3-4-5-10-1-2-3-6-8-9-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

Hình 2.3 Ví dụ về đồ thị dòng Công thức 1: V1(G) = E – N + 2 = 11 – 9 + 2 = 4

(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 (3) Xác định V(G)

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)

PTB2

vo nghiem

PTB2 invalid

R4

invalid'

2.2.1.4 Ma trận kiểm định

Ma trân kiểm định là một ma trận vuông có kích thước bằng số các nút trong đồ thị dòng:

 Mỗi dòng/cột ứng với tên một nút

 Mỗi ô: là tên một cung nối nút dòng đến nút cột

Nhân liên tiếp k ma trận này được ma trận chỉ các con đường k cung từ nút dòng tới nút cột

Các ma trận kiểm định được sử dụng như một dữ liệu có cấu trúc để kiểm tra các đường cơ bản

Để ma trận kiểm định - một công cụ mạnh trong việc đánh giá cấu trúc điều khiển chương trình khi kiểm định, ta thêm trọng số cho các cung của ma trận kiểm định như sau:

 Xác suất cung đó được tiến hành

 Thời gian xử lý của quá trình đi qua cung đó

 Bộ nhớ đòi hỏi của quá trình đi qua cung đó

 Nguồn lực đòi hỏi của quá trình đi qua cung đó

2.2.2 Kiểm định điều kiện

Điều kiện có thể là một trong các dạng sau:

 Điều kiện đơn: là một biến boolean hoặc một biểu thức quan hệ , có thể có toán

tử phủ định đứng đầu

 Biểu thức quan hệ: là một biểu thức boolean chỉ một quan hệ giữa hai biểu thức

số học và quan hệ với nhau bởi các quan hệ so sánh (<, <=, >, >=, = =, !=)

 Điều kiện kết hợp: là điều kiện cấu thành từ hơn một điều kiện đơn nhờ các toán

tử boolean: hoặc, và, phủ định (OR, AND, NOT)

Các kiểu sai trong điều kiện kiểm định có thể là:

 Sai biến boolean (ví dụ: sử dụng sai biến)

 Sai toán tử boolean (ví dụ: AND thay cho OR)

 Sai số hạng trong biểu thức toán tử boolean

 Sai toán tử quan hệ (ví dụ: >= 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ì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

2.2.2.2 Kiểm định theo miề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 2n

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

2.2.2.3 Kiểm định BRO

Kiểm định theo miền với 2n

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, D2,…, 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à: >, <, =,  (lớn hơn, nhỏ hơn, bằng hoặc khác)

Xét điều kiện C là kết hợp của hai biến Boolean A và B (C = A Π B) Khi đó

ràng buộc đầu ra của C là một cặp giá trị t hoặc f

Ví dụ, xét điều kiện (C = A AND B) Chiến lược kiểm định BRO đòi hỏi rằng tập ba ràng buộc {(t, t), (t, f), (f, t)} đều được phủ bởi các thi hành của C, còn {f, f} là thừa Biểu thức logic C không đúng khi “ít nhất một đối sai” (hoặc A hoặc B sai), do vậy trong 3 cặp trên có ít nhất một cặp làm C sai

Xét điều kiện đơn C : (B = E) Khi đó ràng buộc của C là một trong ba : < , > ,

=

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 “<“ hoặc “>” 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,

<), (t, >) và (f, =)

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 tuyển chọn các đường của chương trình tương ứng với việc định vị các xác định biến và sử dụng biến trong chương trình Đã

có một số chiến lược kiểm định dòng dữ liệu và so sánh chúng

Giả sử rằng mỗi câu lệnh của chương trình được gán với số câu lệnh duy nhất

và mỗi hàm không được cải biên các tham số của nó và các biến toàn cục

Với mỗi câu lệnh S ta định nghĩa:

 DEF(S) = {X | câu lệnh S chứa định nghĩa của X}: tập các biến được định nghĩa trong S

 USE(S) = {X | câu lệnh S chứa một sử dụng X}: tập các biến được sử dụng trong S

 Nếu S là câu lệnh if hoặc câu lệnh lặp thì DEF của nó là rỗng (đối với ngôn ngữ

Pascal), còn USE của nó là được xác định dựa theo điều kiện trong S

Giả thiết: định nghĩa biến X ở câu lệnh S vẫn còn sống tại câu lệnh S’ nếu có

một con đường từ S tới S’ mà trên con đường đó không chứa một định nghĩa nào khác của X

Một chuỗi khai báo - sử dụng (DU) của biến X là có dạng [X, S, S’] trong đó S, S’ là các số hiệu lệnh, X có trong tập DEF(S) và tập USE(S’), và khai báo của X trong câu lệnh S trú trong lệnh S’

Chiến lược kiểm định dòng dữ liệu đòi hỏi rằng mọi DU đều phải được phủ ít nhất một lần

Kiểm định DU không bảo đảm phủ tất cả các nhánh của chương trình, tuy nhiên một nhánh không được phủ bởi DU kiểm định là rất hiếm

Kiểm định dòng dữ liệu là hữu ích để chọn các đường của chương trình có chứa

lồng các câu lệnh rẽ nhánh if hoặc vòng lặp (for, while, do-while)

2.2.4 Kiểm định vòng lặp

Có bốn loại vòng lặp cần xem xét như sau:

 Vòng lặp đơn (Simple Loop)

 Vòng lặp lồng (Nested Loop)

 Vòng lặp nối tiếp (Concatenated Loop)

 Vòng lặp phi cấu trúc (Unstructured Loop)

1 Bắt đầu từ vòng lặp trong cùng Thiết lập các vòng lặp khác giá trị nhỏ nhất

2 Thực hiện các kiểm tra vòng lặp đơn (giá trị 1, m, n-1, n) đối với vòng lặp trong cùng trong khi vẫn giữ các giá trị vòng lặp bên ngoài là nhỏ nhất

3 Xét tiếp vòng lặp bên ngoài, thực hiện kiểm tra với các giá trị vòng lặp ngoài nó nhận giá trị nhỏ nhất, vòng lặp bên trong thì nhận giá trị thông thường m nào

Hình 2.8 Vòng lặp phi cấu trúc

2.3 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:

2.3.1.1 Phân hoạch tương đương

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 <= x <= 100, các lớp không hợp lệ là x < 0 và x > 100

2 Nếu điều kiện đầu vào yêu cầu một giá trị xác định, phân hoạch thành một lớp

tương đương hợp lệ và hai lớp tương đương không hợp lệ Chẳng hạn, nếu đầu vào x=5, thì lớp hợp lệ là x= 5, các lớp không hợp lệ là x <5 và x >5

3 Nếu điều kiện đầu vào xác định một phần tử của tập hợp, 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 thuộc tập các giá trị tháng trong năm, Months = {“Jan”, …,

“Dec”}, thì lớp tương đương hợp lệ là x Months và lớp tương đương không hợp lệ là xMonths

4 Nếu điều kiện đầu vào là Boolean, 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ệ tương ứng với hai trạng thái true

1 Gán một giá trị duy nhất cho mỗi lớp tương đương

2 Đến khi tất cả các lớp tương đương hợp lệ được phủ bởi các trường hợp kiểm

thử thì viết một trường hợp kiểm thử mới phủ nhiều nhất có thể các lớp

tương đương hợp lệ chưa được phủ

3 Đến khi tất cả các lớp tương đương không hợp lệ được phủ bởi các trường hợp kiểm thử thì hãy viết các trường hợp kiểm thử mới sao cho mỗi trường

hợp kiểm thử mới chỉ phủ duy nhất một lớp tương đương không hợp lệ chưa

được phủ

Các trường hợp không hợp lệ được phủ bởi các trường hợp kiểm thử riêng biệt

do việc kiểm tra đầu vào có lỗi này sẽ bị che hoặc bỏ sót việc kiểm tra đầu vào có lỗi khác

Ví dụ: Phát sinh các lớp tương đương hợp lệ và không hợp lệ cho đặc tả sau:

Dữ liệu thu được từ xử lý các thông tin của các sinh viên để tạo các bản báo cáo tóm tắt

Dữ liệu đầu vào được mô tả:

+ Mỗi bản ghi phải bắt đầu gồm số ID của sinh viên, chỉ chứa các giá trị số

+ Tiếp theo là tên sinh viên, chỉ chứa giá trị là các ký tự chữ cái

+ Giới tính sinh viên chỉ là một trong hai ký tự chữ cái “M” (nam) hoặc “F” (nữ) + Cuối cùng là điểm của sinh viên chỉ chứa giá trị số từ 0 đến 100

Bảng 2.2 – Ví dụ các lớp tương đương

Điều kiện đầu vào Các lớp tương đương hợp lệ Các lớp tương đương không hợp lệ

Số ID của sinh viên Các ký số Không phải ký số

Tên sinh viên Ký tự chữ cái

Không rỗng

Không phải chữ cái Rỗng

Giới tính sinh viên Ký tự chữ cái, “M” hoặc “F” Không phải chữ cái

Không phải “M” hoặc “F”

Điểm của sinh viên Số

Từ 0 đến 100

Không phải số

Số nhỏ hơn 0

Số lớn hơn 100

2.3.1.2 Phân tích giá trị biên (BVA - Boundary Value Analysis)

Khi thực hiện việc kiểm thử phần mềm theo dữ liệu, chúng ta kiểm tra xem đầu vào của người dùng, kết quả nhận được và kết quả tạm thời bên trong có được xử lý chính xác hay không

Các điều kiện biên là tình trạng trực tiếp ở phía trên và dưới của các lớp tương đầu vào và lớp tương đương đầu ra Việc phân tích các giá trị biên khác với phân hoạch tương đương theo hai điểm:

Từ mỗi lớp tương đương, phân hoạch tương đương sẽ chọn phần tử bất kỳ làm phần tử đại diện, trong khi việc phân tích giá trị biên sử dụng một hoặc một số phần tử Như vây, mỗi biên của lớp tương đương chính là đích kiểm thử Không chỉ chú ý tập trung vào những điều kiện đầu vào, các trường hợp kiểm thử cũng được suy ra từ việc xem xét các kết quả ra (tức các lớp tương đương đầu ra)

Các trường hợp kiểm thử tốt là tại các biên của lớp Những giá trị biên này là các phần tử cực tiểu/cực đại, ngắn nhất/dài nhất, chậm nhất/nhanh nhất, xấu nhất/đẹp nhất, đầu/cuối, bắt đầu/kết thúc, rỗng/đầy, sớm nhất/muộn nhất,… tức là những giá trị cận nhất Như vậy, BVA mở rộng phân hoạch tương đương trên cơ sở tập trung vào các biên của miền đầu vào hơn là các giá trị tiêu biểu của nó

Rất khó có thể có thể liệt kê hết các hướng dẫn cụ thể cho các trường hợp Tuy nhiên, cũng có một số nguyên tắc phân tích giá trị biên như sau:

1 Nếu điều kiện đầu vào xác định một khoảng giá trị giữa a và b, các trường hợp kiểm thử sẽ được thiết kế với giá trị a và b, và các giá trị sát trên và sát dưới a và b

2 Nếu một điều kiện đầu vào xác định một số các giá trị, các trường hợp kiểm thử sẽ được phát triển để thực hiện tại các giá trị cực đại, cực tiểu Các giá trị sát trên và dưới giá trị cực đại, cực tiểu cũng được kiểm thử

3 Nguyên tắc 1 và 2 được áp dụng cho các điều kiện đầu ra

4 Nếu cấu trúc dữ liệu chương trình bên trong được qui định các biên (chẳng hạn, mảng được định nghĩa giới hạn 100 mục), tập trung thiết kế trường hợp kiểm thử để thực thi cấu trúc dữ liệu tại biên của nó

Ngoài ra, người kiểm thử có thể sử dụng sự xét đoán và sáng tạo của mình để tìm các điều kiện biên

Tóm lại, chúng ta phải kiểm thử mỗi biên của một lớp tương đương về tất cả các phía Một chương trình nếu vượt qua những trường hợp kiểm thử đó có thể vượt qua các kiểm thử khác từ lớp đó

Ví dụ: Nếu phần mềm cần điều khiển một số bản ghi bất kỳ trong khoảng từ 1

đến 16383 bản ghi, sẽ có ba lớp tương đương:

Lớp tương đương hợp lệ 1: trong khoảng 1 đến 16383

Lớp tương đương không hợp lệ 2 : nhỏ hơn 1

Lớp tương đương không hợp lệ 3: lớn hơn 16383

Các trường hợp kiểm thử có thể là:

Trường hợp kiểm thử 1: 0 bản ghi, là thành viên của lớp tương đương 2 và kề sát giá trị biên

Trường hợp kiểm thử 2: 1 bản ghi, là giá trị biên

Trường hợp kiểm thử 3: 2 bản ghi, kề sát giá trị biên

Trường hợp kiểm thử 4: 723 bản ghi, là thành phần của lớp tương đương 1

Trường hợp kiểm thử 5: 16382 bản ghi, kề sát giá trị biên

Trường hợp kiểm thử 6: 16383 bản ghi, chính là giá trị biên

Trường hợp kiểm thử 7: 16384 bản ghi, thành phần của lớp tương đương 3, kề sát giá trị biên

2.3.1.3 Kỹ thuật đồ thị nhân-quả (Cause-Effect Graph)

Trong nhiều trường hợp, việc cố gắng chuyển một chính sách hoặc một thủ tục trong ngôn ngữ tự nhiên vào phần mềm dẫn đến sự thất bại và các vấn đề khó hiểu Đồ thị nhân - quả là một phương pháp thiết kế trường hợp kiểm thử trên cơ sở đưa ra một

sự mô tả súc tích các điều kiện logic và các hành vi kèm theo

Đồ thị nhân - quả sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết quả cho thành phần phần mềm Mỗi nguyên nhân được biểu diễn như một điều kiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào Mỗi kết quả được biểu diễn như là một biểu thức Bool biểu diễn một kết quả tương ứng cho những thành phần vừa thực hiện

Đồ thị nhân - quả được tạo như sau:

Tất cả các nguyên nhân (đầu vào) và các kết quả (đầu ra) được liệt kê dựa trên đặc tả và được định danh cho mỗi nhân - quả

Các quan hệ giữa các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) được biểu diễn trong đồ thị làm rõ ràng các quan hệ logic

Từ đồ thị tạo ra bảng quyết định biểu diễn các quan hệ giữa nguyên nhân và kết quả Dữ liệu kiểm thử được sinh ra dựa trên các qui tắc trong các bảng này Các ký hiệu được đơn giản hoá sử dụng trong đồ thị nhân quả, gồm các phần tử

mô tả như bảng 2.3

Bảng 2.3 - Các ký hiệu trong đồ thị nhân quả

1 Tương đương Nếu đúng thì đúng

2 AND (và) Nếu đúng và đúng, thì đúng

3 OR (hoặc) Nếu đúng hoặc đúng, thì đúng

4 NOT (phủ định) Nếu sai, thì đúng

5 Loại trừ Nếu đúng, thì sai, hoặc nếu sai thì đúng

bao hàm

Các qui tắc trong bảng quyết định được mô tả như sau:

V

í dụ: Để tính thuế thu nhập, người ta có mô tả sau:

Tên bảng Qui tắc Tên bảng: cho biết tên logic

Qui tắc: đánh số để phân biệt các qui tắc quyết

định logic

Các dòng điều kiện: Mỗi dòng bao gồm các điều

kiện để tạo quyết định cho chương trình

Người vô gia cư nộp 4% thuế thu nhập

Người có nhà ở nộp thuế theo bảng sau:

<= 5.000.000 đồng 4%

> 5.000.000 đồng 6%

Quan hệ giữa nguyên nhân (đầu vào) và kết quả (đầu ra) nhƣ sau:

Điều kiện đầu vào Điều kiện đầu ra

C1: Lệnh là tiền gửi E1: In lệnh không hợp lệ C2: Lệnh ghi nợ E2: In A/C không hợp lệ C3: A/C hợp lệ E3: In số ghi nợ không hợp lệ C4: Giá trị giao dịch hợp lệ E4: ghi nợ A/C hợp lệ

E5: gửi tiền A/C



với so sánh thời gian thực các kết quả để đảm bảo tính chắc chắn Các phiên bản độc

lập là cơ sở của kỹ thuật kiểm thử hộp đen được gọi là kiểm thử so sánh hay kiểm thử back-to-back

Khi nhiều cài đặt của cùng một đặc tả được đưa ra, các trường hợp kiểm thử được thiết kế sử dụng các kỹ thụât hộp đen khác (ví dụ phân hoạch cân bằng) được cung cấp như đầu vào cho mỗi phiên bản của phần mềm Nếu đầu ra của mỗi phiên bản là như nhau, sẽ cho rằng tất cả các cài đặt là đúng Nếu đầu ra là khác nhau, mỗi ứng dụng được nghiên cứu để xác định có sai sót nào trong một hoặc nhiều phiên bản

là nguyên nhân gây ra lỗi Trong nhiều trường hợp, so sánh các đầu ra có thể được thực hiện bởi các công cụ tự động

Kiểm thử so sánh là không rõ ràng Nếu đặc tả mà tất cả các phiên bản được phát triển trên đó là có lỗi, thì tất cả các phiên bản sẽ có khả năng dẫn đến lỗi Hơn nữa, nếu mỗi phiên bản độc lập tạo ra giống nhau, nhưng không đúng, các kết qủa, kiểm thử điều kiện sẽ thất bại trong việc phát hiện lỗi

2.3.1.5 Đoán lỗi

Không cần một phương pháp đặc biệt nào, một số chuyên gia có thể kiểm tra các điều kiện lỗi bằng cách đoán lỗi dễ xảy ra Trên cơ sở trực giác và kinh nghiệm, với các chương trình cụ thể, các chuyên gia đoán trước các loại lỗi có thể, rồi viết các trường hợp kiểm thử để phơi ra các lỗi này

Khó có thể đưa ra được một thủ tục cho việc đoán lỗi vì đó là một quá trình của trực giác và tự học Ý tưởng cơ bản là liệt kê một danh sách các lỗi có thể hoặc những tình huống dễ mắc lỗi, rồi viết các trường hợp kiểm thử dựa trên danh sách Chẳng hạn như sự xuất hiện giá trị 0 trong đầu vào hoặc đầu ra của một chương trình là tình huống dễ có lỗi Vì vậy, người ta viết những trường hợp kiểm thử cho các giá trị đầu vào có giá trị là 0 và các giá trị ra là 0 Và cũng như vậy đối với trường hợp số biến vào và ra có thể biểu diễn (chẳng hạn đầu vào là một danh sách tìm kiếm), các trường hợp danh sách rỗng hoặc chỉ chứa một phần tử là những tình huống dễ gây lỗi

Một ý tưởng khác là chỉ ra các trường hợp kiểm thử liên quan đến giả định rằng lập trình viên đã mắc phải khi đọc đặc tả (tức là những thứ bị bỏ sót từ đặc tả có thể do tình cờ)

2.3.2 Quy trình kỹ thật kiểm định hộp đen

Quy trình kỹ thuật kiểm định hộp đen là quy trình sử dụng các kỹ thuật kiểm định hộp đen một cách hợp lý để kiểm định phần mềm trên các chức năng của chúng

có thực hiện theo đúng đặc tả hay không Để thực hiện kiểm định phần mềm sử dụng các kỹ thuật hộp đen nhằm phát hiện lỗi của chương trình trên các chức năng của chúng một cách hiệu quả nhất, với chi phí và thời gian tiêu tốn ít nhất chúng ta cần có một quy trình kiểm định hợp lý Sau đây là các bước của một quy trình:

Bước 1: Xác định yêu cầu kiểm định hộp đen

Trong bước này dựa vào đặc tả của chương trình để xác định các chức năng cần kiểm định, xác định các miền giá trị dữ liệu vào và giá trị dữ liệu ra

Bước 2: Phân tích dữ liệu vào ra

Để thiết kế các trường hợp kiểm định cho mỗi chức năng ta phải tiến hành phân tích các miền giá trị dữ liệu vào và dữ liệu ra bằng cách:

- Phân hoạch miền đầu vào thành các lớp tương đương, hợp lệ hay không hợp lệ, các giá trị đặc trưng

- Xác định các giá trị biên và các giá trị kề cận trong và ngoài biên cho các lớp tương đương

Bước 3: Thiết kế các trường hợp kiểm định

- Dựa vào sự phân tích miền giá trị, thiết kế các trường hợp kiểm định đại diện cho các lớp tương đương, giá trị biên và kề cận trong và ngoài biên cũng như lỗi dự đoán theo tri thức và kinh nghiệm

- Dự kiến kết quả dữ liệu ra bằng việc xây dựng một bộ oracle kiểm định ở bước tiếp theo là bước thiết kế và lập trình kiểm định

Bước 4: Thiết kế & lập trình kiểm định hộp đen

- Thiết kế và lập trình giao diện kiểm định: Dựa vào đặc tả yêu cầu để thiết kế giao diện kiểm định, về cơ bản giao diện có thể biểu diễn được cho từng trường hợp kiểm định: dữ liệu vào, dữ liệu ra và kết quả đánh giá dữ liệu ra của chương trình cần kiểm định thực tế có đúng như đặc tả của hệ thống hay không

- Thiết kế và lập trình cấu trúc bên trong của chương trình, nhằm đáp ứng các chức năng được thiết kế trên giao diện của chương trình kiểm định

Trong việc thiết kế & lập trình kiểm định này một bộ oracle kiểm định sẽ được xây dựng

Bước 5: Thực thi kiểm định hộp đen

Tiến hành thực hiện chương trình cần kiểm định lần lượt với tất cả các trường hợp kiểm định đã được thiết kế, bao gồm đưa vào các giá trị dữ liệu vào và cho ra các kết quả dữ liệu ra của từng trường hợp Sau đó thực thi chương trình kiểm định để tiến hành kiểm tra so sánh các kết quả của chương trình cần kiểm định với đặc tả của oracle kiểm định