kiểm thử hộp đen - kiểm thử so sánh

3 Là phương pháp kiểm thử chỉ quan tâm đến kết quả đầu ra đối với một tập dữ liệu đầu vào mà không quan tâm đến cách thực thi của các mã lệnh bên trong của phần mềm .... Kiểm thử hộp đe

-*-* -TÊN ĐỀ TÀI:

“KIỂM THỬ HỘP ĐEN & KIỂM THỬ SO SÁNH”

GVHD: NGUYỄN ĐỨC LƯU Nhóm 8:

1 Nông Thị Ngọc Hà (*)

2 Thiều Thị Chính

3 Đinh Văn Hùng

4 Đinh Thị Hạnh

5 Hà Mạnh Tuyế́n

6 Ngô Thị Lan

7 Tô Thị Diễm

8 Triệu Hương Giang

9 Nguyễn Huyền Trang

10 Trần Ngọc Mai

11 Nguyễn Tiến Công

12 Nguyễn Đức Thanh

Hà Nội, tháng 10/2009

A Mở đầu 2

B Nội dung 3

1 Kiểm thử hộp đen 3

Là phương pháp kiểm thử chỉ quan tâm đến kết quả đầu ra đối với một tập dữ liệu đầu vào mà không quan tâm đến cách thực thi của các mã lệnh bên trong của phần mềm 3

1.2 Mục đích 3

1.3 Một số kỹ thuật được sử dụng trong kiểm thử hộp đen 4

1.3.1 Kỹ thuật phân hoạch tương đương 4

1.3.1.1 Chọn lớp tương đương 4

1.3.1.2 Áp dụng cho giá trị biên ra 6

1.5.1.3 Phân hoạch và phân tích giá trị biên 6

1.3.2 Kỹ thuật đồ thị nhân quả 7

1.4 Ưu điểm và tồn tại của kiểm thử hộp đen 9

2 Kiểm thử so sánh 11

3 Kiểm thừ thời gian thực 12

C Kết luận 15

D Tài liệu tham khảo 17

Tên đề tài: Kiểm thử hộp đen - Kiểm thử so sánh

Bắt đầu từ slide: 16 - 24 trong giáo trình Email: nhom8_tin2k2@yahoo.com

A Mở đầu

Kiểm thử là một quá trình quan trọng trong ngành phát triển phần mềm Trong thực tế có rất nhiều cách thức kiểm thử bởi các kỹ sư phần mềm trước khi sản phẩm của họ được đem ra thị trường Chính vì vậy, họ sử dụng nhiểu phương pháp khác nhau, và trong số đó là kiểm thử hộp đen Ngày nay, nhiều nhà phát triển thường lựa chọn phương pháp kiểm thử này Bởi vì nó có một

số mặt thuận lợi nhất định Kiểm thử hộp đen có thể được thực hiện bởi bất kỳ người nào, ngay cả những người không có nhiều kinh nghiệm kỹ thuật chuyên môn Điều này là do kiểm thử hộp đen không cần biết trước cấu trúc nội tại hay mã nguồn bên trong phần mềm

Kiểm thử hộp đen có thể xác thực các chức năng của toàn hệ thống phần mềm Việc kiểm thử này được thực hiện trên từng chức năng cụ thể cũng như việc kiểm tra và đánh giá các dữ liệu đầu vào và đầu ra

Mục đích của kiểm thử hộp đen là làm thế nào để tìm ra các lỗi và kiểm tra quá trình chạy của hệ thống phần mềm Sau đó tích hợp và phân loại lại trong hệ thống Nhờ đó mà các nhà phát triển sẽ được định hướng trong việc kiểm tra toàn bộ hệ thống

Kiểm thử hộp đen là công đoạn kế tiếp của kiểm thử hộp trắng Kiểm thử hộp đen tập trung vào kiểm tra các yêu cầu chức năng, giao diện phần mềm Nó được thực hiện khi việc kiểm thử hộp trắng kiểm soát được toàn bộ các lỗi,các mã lệnh bên trong phần mềm

Kiểm thử so sánh được sử dụng để phát hiện ra các lỗi bởi việc đưa ra

sự so sánh của hai hay nhiều chương trình được thi hành như nhau Tương tự như vậy, những dữ liệu đưa ra được ứng dụng từ hai hay nhiều phiên bản phần mềm và kiểm thứ so sánh sẽ tìm ra các lỗi, các điểm bất thường

Kiểm thử so sánh được thực hiện với một số lượng lớn và tìm ra lỗi một cách

nhanh nhất

B Nội dung

1 Kiểm thử hộp đen

Là phương pháp kiểm thử chỉ quan tâm đến kết quả đầu ra đối với một

tập dữ liệu đầu vào mà không quan tâm đến cách thực thi của các mã lệnh bên

trong của phần mềm

Kiểm thử hộp đen tập trung vào các yêu cầu chức năng của phần mềm

Nó cho phép thiết kế các điều kiện đầu vào để thực thi tất cả các yêu cầu chức

năng của chương trình Kiểm thử hộp đen không phải là phần bù cho kiểm thử

hộp trắng Đó là kĩ thuật kiểm thử bổ sung cho kiểm thử hộp trắng với độ bao

phủ các lớp lỗi ít hơn

Kĩ thuật kiểm thử hộp đen cố gắng tìm ra các lỗi sau: các hàm bị lỗi

hay mất, lỗi giao diện, lỗi trong cấu trúc dữ liệu hay truy cập dựa trên dữ liệu

ngoài, lỗi thực thi và các lỗi khởi đầu và kết thúc

- Mô hình:

1.2 Mục đích

Bổ sung cho phương pháp kiểm thử hộp trắng để phát hiện ra tất cả các

lỗi khác nhau mà kiểm thử hộp trắng không phát hiện ra được

Không như kĩ thuật kiểm thử hộp trắng được thực thi trong giai đoạn

sớm của quá trình kiểm thử, kiểm thử hộp đen được thực hiện trong giai đoạn

sau của quá trình kiểm thử Kiểm thử hộp đen không quan tâm tới trúc điều

khiển mà tập trung vào miền thông tin Kiểm thử được thiết kế để trả lời các

câu hỏi sau:

- Giá trị chức năng được kiểm thử như thế nào?

- Các lớp đầu vào nào sẽ cho các ca kiểm thử tốt?

- Hệ thống có bị ảnh hưởng bởi những giá trị đầu vào nhất định?

- Giá trị biên của các lớp dữ liệu được phân tách như thế nào?

- Tỷ lệ và lượng dữ liệu mà hệ thống có thể chịu được?

- Việc kết hợp dữ liệu xác định có ảnh hưởng gì trong việc vận hành hệ thống?

1.3 Một số kỹ thuật được sử dụng trong kiểm thử hộp đen

1.3.1 Kỹ thuật phân hoạch tương đương

Phân hoạch tương đương là phương pháp kiểm thử hộp đen chia miền

dữ liệu vào thành các lớp từ đó có thể thực hiện các ca kiểm thử Phân hoạch tương đương cố gắng xác định các ca kiểm thử mà không bao phủ các lớp lỗi,

do đó giảm tổng số các kiểm thử sẽ được phát triển

Thiết kế các ca kiểm thử cho phân hoạch tương đương dựa trên việc đánh giá của các lớp tương đương cho một điều kiện đầu vào Sử dụng khái niệm được đưa ra trong mục trước, nếu một tập các đối tượng có thể liên kết bởi các mối quan hệ đối xứng, chuyển tiếp và phản xạ, một lớp tương đương được biểu diễn Một lớp tương đương biểu diễn một tập các trạng thái phù hợp hay không cho các điều kiện đầu vào Điển hình, một điều kiện đầu vào hoặc là một giá trị số xác định, một miền giá trị, một tập các giá trị liên quan hay một điều kiện logíc

1.3.1.1 Chọn lớp tương đương

Đây là kỹ thuật chia vùng thông tin nhập vào của chương trình thành các lớp thông tin/dữ liệu Lớp tương đương biểu diễn thành một tập các giá trị hợp lệ và không hợp lệ Nhưng lớp dữ liệu tương đương này có thể được xác định theo những cách sau:

Nếu thông tin đầu vào chỉ định một vùng các giá trị, thì ta có một lớp

dữ liệu hợp lệ và hai không hợp lệ được định nghĩa

Nếu thông tin đầu vào chỉ định một giá trị, thì ta có một lớp dữ liệu hợp

lệ và hai không hợp lệ được định nghĩa

Nếu thông tin đầu vào chỉ định một giá trị của một tập, thì ta có một lớp

dữ liệu hợp lệ và hai không hợp lệ được định nghĩa

Nếu thông tin đầu vào chỉ định một giá trị boolean, thì ta có một lớp dữ liệu hợp lệ và một không hợp lệ được định nghĩa

* Ví dụ minh họa

Môt khách hàng có thể liên lạc với ngân hàng bằng máy tính cá nhân,

họ gởi một mật khẩu gồm 6 chữ số và các thao tác khởi động một số chức

năng của ngân hàng Phần mềm hổ trợ cho các ứng dụng của ngân hàng chấp nhận dữ liệu theo dạng sau:

Mã vùng - rỗng hay 3 chữ số

Tiền tố - 3 chữ số không bắt đầu bằng 0 hay 1

Hậu tố - 4 chữ số

Mật khẩu – 6 ký tự alphanumberic

Thao tác/nghiệp vụ ngân hàng – "xem_tài_khoản", "gửi_tài_khoản" ,

"rút_tài_khoản" …

Áp dụng kỹ thuật phân vùng thông tin để tạo các bộ kiểm thử như sau : Các trường hợp kiểm định

Mã vùng Boolean – giá trị của mã vùng có thể được nhập hoặc không

Range – giá trị của mã vùng có thể được định nghĩa từ 200 đến 999

Tiền tố Range – Xác định các giá trị >200

Hậu tố Value - một chuổi 4 số

Mật khẩu Boolean – giá trị của mật khẩu có thể được nhập hoặc không

Value – giá trị nhận là một chuổi 6 ký tự Thao tác/nghiệp

vụ ngân hàng

Set - một tập các thao tác được ghi bên trên

Áp dụng các chỉ dẫn trên cho việc thiết kế các lớp tương đương, các ca

kiểm thử cho mỗi miền dữ liệu có thể được phát triển và thực thi Các ca kiểm

thử được lựa chọn cốt để số lượng lớn nhất các thuộc tính của một lớp tương

đương được thực thi một lần

1.3.1.2 Áp dụng cho giá trị biên ra

Với những lí do không rõ ràng, một số lớn các lỗi có khuynh hướng

xảy ra tại giá trị biên của miền dữ liệu vào hơn là các giá trị trung tâm Vì lí

do này, việc phân tích giá trị biên được phát triển như là một kĩ thuật kiểm

thử Việc phân tích giá trị biên dẫn đến sự lựa chọn một tập các ca kiểm thử

thực thi các giá trị biên

Việc phân tích giá trị biên là kĩ thuật thiết kế các ca kiểm thử bổ sung

cho phân hoạch tương đương Đúng hơn là việc lựa chọn bất kì phần tử nào

của một lớp tương đương BVA(Boundary Value Analysis) dẫn đến việc lựa

chọn các ca kiểm thử tại “bờ” của lớp Đúng hơn là chỉ tập trung vào các điều

kiện đầu vào, BVA đưa ra các ca kiểm thử từ miền đầu ra

1.5.1.3 Phân hoạch và phân tích giá trị biên

Hướng dẫn sau cho BVA tương tự trong một số khía cạnh cho các

hướng dẫn được đưa ra trong phân hoạch tương đương:

1) Nếu một điều kiện đầu vào xác định một miền biên bởi giá trị a và b,

các ca kiểm thử cần được thiết kế với giá trị của a và b, giá trị trên a và dưới

b

a

b

•

•

•

•

•

•

Giá trị cận biên Giá trị biên

Giá trị ngoài biên

2) Nếu một điều kiện đầu vào xác định một số giá trị, các ca kiểm thử cần được thiết kế mà thực thi các số lớn nhất và nhỏ nhất Các giá trị trên và dưới các giá trị nhỏ nhất và lớn nhất cũng được kiểm thử

3) Nếu điều kiện 1 và 2 (bên trên) được áp dụng cho các điều kiện đầu ra Chẳng hạn, giả sử rằng một bảng nhiệt độ và áp suất được yêu cầu như là một đầu ra từ chương trình phân tích kĩ nghệ Các ca kiểm thử cần được thiết

kế để tạo ra một báo cáo đầu ra mà đưa ra số tối đa (tối thiểu) cho phép của danh mục bảng

4) Nếu một cấu trúc dữ liệu chương trình trong quy định giá trị biên (chẳng hạn một mảng có một giới hạn xác định của 100 phần tử) có thể chắc chắn để thiết kế một tập các ca kiểm thử để thực thi cấu trúc dữ liệu tại giá trị biên của nó

Hầu hết các kĩ sư phần mềm đều thực thi bằng trực giác một số cấp độ Bằng việc áp dụng các hướng dẫn ở trên, việc kiểm thử biên có thể được hoàn thành nhiều hơn, do đó có thể có khả năng cao hơn trong việc phát hiện lỗi

1.3.2 Kỹ thuật đồ thị nhân quả

- Khái niệm:

Là một kỹ thuật để thiết kế ca kiểm thử, cung cấp một biểu diễn chính xác giữa các điều kiện logic (đầu vào) và các hành động tương ứng (đầu ra- kêt quả)

Kỹ thuật đồ thị nhân quả được xây dựng dựa trên các mô đun chức năng, lôgíc tiến trình và đặc tả hệ thống

Ta thấy rằng 2 kỹ thuật trên dữ liệu đầu vào đã được phân loại để phân tích Tuy nhiên kỹ thuật sắp trình bày dưới đây cho phép xác định ra các

trường hợp kiểm thử hiểu quả nhất ngay cả trong lúc dữ liệu đầu vào là khó phân loài thành các lớp như trong 2 kỹ thuật trên

- Một số ký hiệu sử dụng trong đồ thị nhân quả (cause - effect)

Kỹ thuật này gồm có 4 bước như sau :

Bước 1 Xác định Cause (điều kiện nhập vào) và effect (là hành động)

cho mỗi một module cần kiểm định

Bước 2 Xây dựng đồ thị cause-effect

Bước 3 Đồ thị được chuyển thành bảng quyết định

Bước 4 Những phần/luật trong bảng quyết định được chuyển thành các

trường hợp kiểm thử

* Ví dụ:

Modul đếm số lần phần tử x có mặt trong mảng A Với các dữ liệu đầu vào: x = 2; A ={0, 2, 2, 2, 4}

* Kết quả:

- "Đúng" - Nếu kết quả trả về là 3

- "Nghi ngờ"- Nếu kết quả trả về là 2

- "Sai" - Nếu kết quả trả về là 1

Bước 1: Xác định quan hệ giữa input & output của module trên

Cause ( Dữ liệu nhập) Result (Dữ liệu xuất )

1 Nếu kết quả trả về là 3

2 Nếu kết quả trả về là 2

4 Đúng

5 Nghi ngờ

GVHD: Nguyễn Đức Lưu

xác định

B A

B

A B

C

A B

C

A B

E

Exclusive-

if A== true then B = false

if B== true then A = false

A B

Include-

I

A

B

require-

8

6 Sai

Bước 2 Biểu diễn quan hệ giữa cause và result trên đồ thị cause - effect

Bước 3 Tạo bảng quyết định

Cause 1 Nếu kết quả trả về là 3 Y N N

2 Nếu kết quả trả về là 2 - Y N

Result

3 “Đúng” là kết quả xuất ra X -

-4 “Nghi ngờ” là kết quả xuất ra - X

-5 “Sai” là kết quả xuất ra - - X

Chú thích cho bảng quyết định:

- Dòng chỉ định điều kiện: mỗi dòng bao gồm các điều kiện để quyết định cho chương trình: (đây là các dòng có màu xâm hơn trên bảng)

Y : true, N false, - không có quyết định nào

- Dòng chỉ định hành động: mỗi dòng chỉ định tiến trình có được thực thi hay không: (đây là các dòng có màu sáng hơn trên bảng)

X : tiến trình hoạt động, - không có tiến trình nào hoạt động cả

Bước 4 Chuyển thành các trường hợp kiểm thử

- Chia thành các ca kiểm thử và tiến hành kiểm thử (có thể chia thành nhiều ca kiểm thử nhỏ hơn nếu cần thiết)

1.4 Ưu điểm và tồn tại của kiểm thử hộp đen

* Ưu điểm:

3 1

2

4 5

A E

- Mang lại nhiều hiệu quả lớn trên những đơn vị mã nguồn sau việc kiểm thử hộp đen

- Người kiểm thử phần mềm không cần có một kiến thức sâu rộng về đặc tả và ngôn ngữ lập trình

- Người kiểm thử và các lập trình viên là độc lập với nhau, kiểm thử được cân nhắc và khách quan nhất

- Người kiểm thử thực hiện những quan điểm của người xem (người chưa biết gì)

- Sẽ giúp cho việc hiển thị sự mơ hồ hoặc sự mâu thuẫn trong các đặc tả

hệ thống

- Việc kiểm thử được tiến hành một cách sớm nhất ngay sau khi hoàn thành việc đặc tả hệ thống

- Có hiệu quả cao khi được sử dụng trên hệ thống lớn

- Người kiểm thử không cần có kiến thức chi tiết về chức năng của hệ thống

- Kiểm thử phần mềm giúp hiển thị những việc chưa rõ ràng và những mâu thuẫn trong đặc tả hệ thống

* Tồn tại:

- Chỉ có một số lượng nhỏ các yếu tố đầu vào có thể đã được kiểm tra

- Nếu không có cách thức rõ ràng và chi tiết, các trường hợp kiểm thử khó có thể được thiết kế

- Có thế sẽ lặp lại những cái không cần thiết của việc kiểm tra đầu vào nếu như người kiểm thử không có được thông tin về quy tình test mà những người lập trình đã cố gắng làm

- Có thể chấp nhận nhiều đường dẫn chương trình mà chưa được kiểm tra

- Không thể định hướng tới những đoạn mã cụ thể mà được cho là rất phức tạp…

- Rất khó xác định các yếu tố đầu vào, nếu như qui trình kiểm thử không được phát triển dựa trên bản đặc tả chi tiết

2 Kiểm thử so sánh

- Kiểm thử so sánh còn được gọi là kiểm thử dựa vào nhau

- Khi triển khai nhiều bản phần mềm từ cùng 1 đặc tả: Kiểm thử hộp đen cho các sản phẩm này được thực hiện cùng ca kiểm thử và cùng các dữ liệu vào

Sau đó so sánh các kết quả thu được, nếu có sự khác nhau có nghĩa là

đã lỗi trong một sản phẩm nào đó

Có một vài tình huống (chẳng hạn điện tử hàng không, điều khiển nhà máy điện hạt nhân) ở đó độ tin cậy phần mềm là tuyệt đối then chốt Trong những ứng dụng như vậy, phần cứng và phần mềm cần thiết thường được tối thiểu hóa khả năng có lỗi Khi mà các phần mềm cần thiết được phát triển, các nhóm kĩ nghệ phần mềm riêng rẽ phát triển những phiên bản độc lập của ứng dụng cùng các chi tiết kĩ thuật Trong những tình huống như vậy, mỗi phiên bản có thể được kiểm thử với cùng dữ liệu kiểm thử để đảm bảo rằng tất cả cho ra những kết quả xác định Sau đó tất cả các phiên bản được thực thi song song với việc so sánh các kết quả thời gian thực để đảm bảo sự nhất quán

Sử dụng những bài học đã học được từ các hệ thống cần thiết, các nhà nghiên cứu gợi ý rằng các phiên bản phần mềm độc lập cho những ứng dụng tới hạn Thậm chí chỉ có phiên bản đơn được sử dụng trong hệ thống dựa trên máy tính được phân phát Những sản phẩm độc lập đó là cái cơ bản để tạo thành 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 các đa thực thi của cùng các chi tiết kĩ thuật được tạo ra, các ca kiểm thử được thiết kế sử dụng kĩ thuật kiểm thử hộp đen (chẳng hạn phân hoạch tương đương) được yêu cầu như là đầu vào cho mỗi phiên bản phần