Bài tập lớn môn kiểm chứng phần mềm Đề tài phương pháp hộp trắng ( white box testing)

Việc kiểm thử tích hợp có liên quan đến thẩm định và xây dựngchương trình.Các kỹ thuật thiết kế kiểm thử hộp đen được dùng trong hầuhết quá trình tích hợp, mặc dù các kiểm thử hộp trắng

BÀI TẬP LỚN MÔN

KIỂM CHỨNG PHẦN MỀM

ĐỀ TÀI PHƯƠNG PHÁP HỘP TRẮNG ( White Box Testing)

Giáo viên hướng dẫn : Cô Vũ Thị Thương Sinh viên thực hiện : Đào Công Hiện

Mã Sinh Viên : 521100022

Lớp : 521100A

Hà Nội - 2024

LỜI CẢM ON 0

LỜI CAM ĐOAN 3

MỞ ĐẦU 1

1 Lý do chọn đề tài 1

3. Nhiệm vụ nghiên cứu 2

4. Đối tượng và phạm vi nghiên cứu 2

5. Phương pháp nghiên cứu 2

6. Dự kiến đóng góp mới của đề tài 2

CHƯONG 1 TÔNG QUAN VÈ KIÊM THỬ PHẪN MỀM 3

1 Tổng quan về kỹ nghệ phần mềm 3

1.1. Khái niệm cơ bản về kiềm thử 3

1.2. Chiến lược kiểm thử 6

1.2.1. Khái niệm chiến lược kiểm thử 6

1.2.2. Mô hình chiến lược tổng thể 8

1.2.3. Một số chiến lược kiểm thử khác 9

1.2.3.1.Chiến lược kiểm thử hệ thời gian thực 10

1.2.3.2.Kiểm thử Alpha và Beta 11

1.2.3.3.Kiểm thử so sánh 13

1.3. Các phương pháp kiểm thử 14

1.4. Các kỹ thuật kiểm thử 15

1.4.1. Kỹ thuật kiểm thử hộp đen (Black - box testing) 16

1.4.2. Kỹ thuật kiểm thử hộp trắng (white - box testing) 16

Kel luận 17

CHƯƠNG 2 CÁC KỸ THUẬT KIỂM THỬ HỘP TRẮNG 18

2.3 Điều kiện logic với chiến lược kiểm thử miền và nhánh 38

2.4 Điều khiển theo dòng dữ liệu 46

2.5 Cấu trúc chu trình - giá trị đặc trưng 47

CHƯONG 3 XÂY DỰNG PHẪN MỀM THỬ NGHIỆM ỦNG DỤNG KỸ THUẬT KIÊM THỬ HỘP TRẮNG 50

3.1 Môi trường thử nghiệm 50

3.1.1. Giới thiệu cơ bản về ngôn ngữ C# 50

3.1.1.1. C# là ngôn ngữ đơn giản 50

3.1.1.2. C# là ngôn ngữ hiện đại 51

3.1.1.3. C# là ngn ngữ hướng đối tượng 51

3.2 Dữ liệu đầu vào và yêu cầu đầu ra 52

3.2.1. Dữ liệu đầu vào: 52

3.2.2 Yêu cầu đầu ra 52

3.3 Thiết kế ca kiểm thử 52

3.3.1. Quy trình thực hiện trong chương trình 52

3.3.2. Ví dụ minh họa chương trình 53

3.4 Kết quả thử nghiệm và đánh giá 53

3.4.1. Giao diện form chính của phần mềm 53

3.4.2. Chọn file nguồn 54

3.4.3. Ket quả thực hiện nút Open 54

3.4.4. Kết quả thực hiện nút Tính độ phức tạp 55

3.4.5 Kết quả thực hiện nút Tập kiểm thử 56

KẾT LUẬN 57

DANH MỤC CÁC TÀI LIỆU THAM KHẢO 58

MỞ ĐẦU

1. Lý do chọn đề tài

Các kỹ thuật kiểm thử hộp trắng có vai trò rất quan trọng trong

việc đưa một ứng dụng vào áp dụng thực tế

Kiểm thử là một trong những giai đoạn của quá trình phát triển,

hoàn thành sản phẩm Trước khi sản phẩm được phát hành tất cả các chứcnăng cũng như giao diện, ứng dụng của sản phẩm đó đều cần qua kiểmthử Một sản phẩm tuy được thiết kế tốt nhưng cũng không thể tránh khỏicác sai sót Kiểm thử hiệu quả sẽ phát hiện ra được các sai sót này, tránhcác lỗi trước khi phát hành Kiểm thử đứng dưới vai trồ của người sửdụng, sẽ giúp cho sản phẩm có sự thích ứng phù hợp hơn với thị hiếu vànhu cầu của người dùng Chính vì lẽ đó, kiểm thử là việc hết sức cần thiết,cần nghiên cứu về kiểm thử nhằm góp phần xác định chất lượng phầnmềm vừa được xây dựng

Kỹ thuật kiểm thử (technical testing) hộp trắng (white box) dựa

vào thuật giải cụ thể, dựa vào cấu trúc dữ liệu bên trong của đơn vị phầnmềm cần kiểm thử để xác định đơn vị phần mềm đó có thực hiện đúngkhông

Vậy tại sao ta phải quan tâm đến các kỹ thuật kiểm thử? Vì

chọn kỹ thuật kiểm thử phù hợp thì sẽ:

Giảm chi phí phát triển

Tăng độ tin cậy của sản phẩm

Giúp tìm ra nhiều lỗi nhất

Chi phí (thời gian, công sức) ít nhất

Sinh ra được kỹ thuật kiểm thử chạy tốt

Vì vậy tôi mạnh dạn chọn đề tài cho luận văn thạc sĩ của mình là

“Nghiên cứu các kỹ thuật kiểm thử hộp trắng”.

3. Nhiệm vụ nghiên cứu

- Nghiên cứu tổng quan về kiểm thử phần mềm

- Nghiên cứu tổng hợp về các kỹ thuật sử dụng để kiểm thử hộp trắngnhư kỹ thuật đồ thị dồng, ma trận kiểm thử, điều kiện logic, điều khiểntheo dòng dữ liệu, cấu trúc chu trình,

- Lập trình thử nghiệm một hoặc nhiều trong các kỹ thuật đã nghiên cứu

để xác định các ca kiểm thử và xây dựng kịch bản kiểm thử cho một bàitoán cụ thể

4. Đối tượng và phạm vi nghiên cứu

- Đối tượng nghiên cứu là đơn vị phần mềm (một đoạnlệnh/mô-đun/chương trình).Phạm vi nghiên cứu của đề tài là các kỹ thuậtkiểm thử hộp trắng trong kiểm thử phần mềm

5. Phương pháp nghiền cứu

- Phương pháp tổng hợp phân tích các vấn đề liên quan đến đề tài,

- Phương pháp thống kê kết hợp với phương pháp chuyên gia,

- Phương pháp kết hợp lý thuyết với thực nghiệm trên máy tính

6. Dự kiến đóng góp mới của đề tài

- Xác định các tiêu chuẩn thích hợp cho việc chọn phương pháp thiết kế

ca kiểm thử và ứng dụng

1. Tổng quan về kỹ nghệ phần mềm

Kỹ nghệ phần mềm {software engineering) là sự áp dụng một cách

tiếp cận có hệ thống, có kỷ luật, và định lượng được cho việc phát triển,

sử dụng và bảo trì phần mềm Ngành học kỹ nghệ phần mềm bao trùmkiến thức, các công cụ, và các phương pháp cho việc định nghĩa yêu cầu

phần mềm, và thực hiện các tác vụ thiết kế, xây dựng, kiểm thử (software testing), và bảo trì phần mềm Kỹ nghệ phần mềm cồn sử dụng kiến[2]

thức của các lĩnh vực như kỹ thuật máy tính, khoa học máy tính, quản lý,toán học, quản lý dự án, quản lý chất lượng, công thái học phần mềm

(software ergonomics), và kỹ nghệ hệ thống (systems engineering).

Trích dẫn một câu nói của Edsger Dijkstra về công nghệ phần mềm:

Khi máy tính chưa xuất hiện, thì việc ĩập trình chưa có khó khăn gì cả.Khỉ mới xuất hiện một vài chiếc máy tính chức năng kém thì việc ĩập trình bắt đầu gặp một vài khó khăn nho nhỏ.GỈỜ đây khỉ chúng ta có những chiếc máy tính khổng lồ thì những khó khăn ẩy trở nên vô cùng ỉớn.Như vậy ngành công nghiệp điện tử không giải quyết khó khăn nào cả

mà họ chi tạo thêm ra những khó khăn mớỉ.Khó khăn mà họ tạo nên chính là việc sử dụng sản phẩm của họ.

Kiểm thử phần mềm (software testing) là một trong những yếu tốgóp phần bảo đảm chất lượng phần mềm (SQA), là khâu điển hình kiểmsoát đặc tả, thiết lập, lập mã.

Theo Glen Myers: “Kiểm thử phẩn mềm là quá trình vận hành chương trình để tìm ra lỗi”.

Kiểm thử phần mềm được đặt ra với những lý do

Muốn nhận diện phần mềm như một phần tử của hệ thống hoạt động.Hạn chế chi phí cho các thất bại do lỗi gây ra sau này (hiệu quả)

Có kế hoạch tốt nâng cao chất lượng suốt quá trình phất triển (giải pháp)

Kiểm thử giữ vai trồ lớn trong quá trình phát triển phần mềm Xéttheo tiêu chí về chi phí thì kiểm thử chiếm:

40% công sức phát triển;

> 30% tổng thời gian phát triển;

Với các phần mềm có ảnh hưởng tới sinh mạng, chi phí có thể gấp từ 3 đến 5 lần tổng các chi phí khác cộng lại

Như vây, kiểm thử tốt sẽ:

Giảm chi phí phát triển;

Tăng độ tin cậy của sản phẩm phần mềm

Vấn đề đặt ra là cần vận hành phần mềm như thế nào để:

Hiệu suất tìm ra lỗi là cao nhất?

Chi phí (thời gian, công sức) ít nhất?

Công việc trước mắt của kiểm thử phần mềm là tạo ra các ca kiểmthử để tìm ra lỗi của phần mềm

Mục đích cuối cùng của kiểm thử phần mềm nhằm có một chươngtrình tốt, chi phí ít

Glen Myers phát biểu một số quy tắc giống như mục đích kiểm thử:

©Kiểm thử là một tiến trình thực hiện một chương trình với ý định

Có một điều mà kiểm thử không thể làm được: Kiểm thử không thểchứng minh được việc không có khiếm khuyết, nó chỉ có thể chứng minhđược khiếm khuyết phần mềm hiện hữu.

Khi kiểm thử, người ta đưa ra những khái niệm về ca kiểm thử “tốt”

và “thắng lợi”:

Ca kiểm thử là ca kiểm thử có xác suất cao tìm ra 1 lỗi.tốt

Ca kiểm thử thẳng lợi là ca kiểm thử làm lộ ra ít nhất một lỗi.Vấn đề đặt ra ở chỗ nếu không tìm được lỗi nào thì có thể kết luận

phần mềm hoàn hảo?Câu trả lời chung là chưa hẳn như vậy.

Kiểm thử có nhiều lợi ích, trong đó phải kể đến các lợi ích quantrọng:

Ca kiểm thử thắng lợi làm lộ ra khiếm khuyết

Kiểm thử mang lại các lợi ích phụ là thuyết minh:

+ Chức năng tương ứng với đặc tả,

+ Thực thi phù hợp yêu cầu và đặc tả,

+ Cung cấp các chỉ số tin cậy và chất lượng

Tuy kiểm thử có nhiều lợi ích như trên nhưng chưa thể khẳng địnhphần mềm không cồn khiếm khuyết

1.2. Chiến lược kiểm thử

1.2.1. Khái niệm chiến lược kiểm thử

Chiến lược kiểm thử là sự tích hợp các kỹ thuật thiết kế ca kiểm thửtạo thành một dãy các bước nhằm hướng dẫn quá trình kiểm thử phầnmềm thành công

Chiến lược kiểm thử được đặt ra với mục tiêu nhằm phác thảo một

lộ trình để:

Nhà phát triển tổ chức việc bảo đảm chất lượng bằng kiểm thử,Khách hàng hiểu được công sức, thời gian và nguồn lực cần chokiểm thử

Chiến lược kiểm thử cần phải đạt những yếu cầu sau:

Tích hợp được các khâu như lập kế hoạch, thiết kế ca kiểm thử,

tiến hành kiểm thử, thu thập và đánh giá các thong tin kết quả.

Đủ mềm dẻo để cổ vũ óc sáng tạo, đáp ứng được nhu cầu kháchhàng

Thích ứng với mức kiểm thử cụ thể

Đáp ứng các đối tượng quan tâm khác nhau

Kiểm thử là một tập hợp những hoạt động mà có thể được lập kếhoạch trước và tiến hành một cách có hệ thống Một tập các bước màtrong đó chúng ta có thể vận dụng những kỹ thuật thiết kế ca kiểm thử và

phương pháp kiểm thử có những đặc trưng mang tính “khuôn mẫu

Bắt đầu ở mức mô-đun và tiếp tục cho đến khi tích hợp ở mức hệthống trọn vẹn

Các kỹ thuật kiểm thử khác nhau là thích hợp cho những thờiđiểm khác nhau

Được cả người phát triển và nhóm kiểm thử độc lập cùng tiếnhành

Kiểm thử đi trước gỡ lỗi, song việc gỡ lỗi phải thích ứng vớitừng chiến lược kiểm thử

Chiến lược cần thích ứng với từng mức kiểm thử và phải đưa rahướng dẫn cho người thực hành và một tập các cột mốc cho người quản

thống chủ yếu có đúng đặc tả và đáp ứng yêu cầu của khách hànghay không?

Mỗi chiến lược đáp ứng được yêu cầu cần quan tâm:

Có các hướng dẫn cho người thực hiện tiến hành kiểm thử

Có các cột mốc cho các nhà quản lý kiểm soát hoạt động bảođảm chất lượng

Có thước đo để đo và nhận ra các vấn đề càng sớm càng tốt.Khách hàng có thể nhận biết được quá trình kiểm thử

Việc kiểm thử cung cấp một thành lũy cuối cùng để có thể thẩmđịnh về chất lượng và có thể phát hiện ra lỗi

Có một số quan điểm sai lầm:

Người phát triển không nên tham gia kiểm thử

Cho phép người lạ kiểm thử một cách thô bạo

- Người kiểm thử chỉ quan tâm khi kiểm thử bắt đầu

Nên xuất phát từ thực tiễn mà phân công trách nhiệm thử:

- Người phát triển chịu trách nhiệm kiểm thử đơn vị do mình pháttriển để bảo đảm thực hiện theo đúng thiết kế, có thể tham giakiểm thử tích hợp; không khoán trắng chương trình cho ngườikiểm thử mà phải cùng làm việc với người kiểm thử xuyên suốt

dự án

Nhóm kiểm thử độc lập bắt đầu làm việc khi các khoản mục cấutrúc phần mềm đã đầy đủ, giúp gỡ bỏ những thành kiến: “người

xây dựng không thể kiểm thử tốt sản phẩm”, gỡ bỏ mâu thuẫngiữa những người tham gia; đánh giá công sức người phát triển

bỏ ra tìm lỗi; tạo ra báo cáo đầy đủ cho tổ chức bảo đảm chấtlượng phần mềm

1.2.2. Mô hình chiến lược tồng thể

về mặt kỹ nghệ, việc kiểm thử gồm một số bước được thực hiệntuần tự Ban đầu, việc kiểm thử tập trung vào từng mô-đun riêng biệt bảođảm nó ban hành đúng đắn như một đơn vị Do đó mới có tên kiểm thửđơn vị Kiểm thử đơn vị dùng rất nhiều các kỹ thuật kiểm thử hộp trắng,kiểm soát các đường đặc biệt trong cấu trúc điều khiển của một lớp mô-đun nhằm phát hiện tối đa các lỗi Mặt khác, các mô-đun phải được lắpghép hay tích hợp lại để tạo nên phần mềm hoàn chỉnh

Việc kiểm thử tích hợp có liên quan đến thẩm định và xây dựngchương trình.Các kỹ thuật thiết kế kiểm thử hộp đen được dùng trong hầuhết quá trình tích hợp, mặc dù các kiểm thử hộp trắng cũng có thể đượcdùng để bao quát đa số các đường điều khiển.Sau khi phần mềm đã đượcdùng tích hợp (được xây dựng), một tập hợp các phép kiểm thử sẽ đượctiến hành.Các tiêu chuẩn hợp lệ (được thiết lập trong phân tích yêu cầu)cũng phải được kiểm thử.Việc kiểm thử hợp lệ được tiến hành nhằm bảođảm phần mềm đáp ứng đầy đủ các yêu cầu chức năng.Các kỹ thuật kiểmthử hộp đen được dùng chủ yếu trong kiểm thử hợp lệ

Kiểm thử hệ thống nằm trong khung cảnh rộng hơn của kỹ nghệ hệthống máy tính.Khi làm hợp lệ, phần mềm phải được tổ hợp với các phần

tử hệ thống khác (như phần cứng, con người, CSDL).VÌ vậy, kiểm thử hệthống là rất quan trọng

Cuối cùng, kiểm thử chẩp nhận sẽ thẩm định lại rằng tất cả cácthành phần có phối khớp với nhau không, cũng như chức năng hay độhoàn thiện của hệ thống có đạt được không.

Hình 1.1.Mô hình chiến lược kiểm thử tổng thể

1.2.3. Một số chiến lược kiểm thử khác

Ngoài chiến lược kiểm thử tổng thể, người ta còn tiến hành một loạtcác chiến lược kiểm thử bổ trợ khác như:

Kiểm thử hệ thời gian thực

Kiểm thử Alpha và Beta

Kiểm thử so sánh

1.2.3.1. Chiến lược kiểm thử hệ thời gian thực

Hệ thời gian thực là hệ thống đáp ứng đúng, chính xác các sự kiệncủa môi trường

Thẩm định Xác minh + thẩm định

Kiểm thử hệ thống thời gian thực là rất khó Những người thiết kế

ca kiểm thử không chỉ phải xem xét các trường hợp kiểm thử hộp đen vàhộp trắng mà còn phải xem xét cả việc chia thời gian cho dữ liệu cà cơchế song song cho các nhiệm vụ (tiến trình) giải quyết dữ liệu đó.Trongnhiều tình huống, trạng thái của hệ thống cũng có thể dẫn tới lỗi.Mối quan hệ mật thiết giữa phần mềm thời gian thực và môi trườngphần cứng của nó cũng có thể gây ra các vấn đề cho kiểm thử.Việc kiểmthử phần mềm phải xem xét tác động của các lỗi phần cứng đến xử lýphần mềm.những lỗi như thế rất khó mô phỏng sát thực tế

Đẻ khắc phục khó khăn trên, chiến lược kiểm thử được vạch ra theo

Sau đó dựng kết quả hoạt động phân tích này để thiết kế các cakiểm thử (tương tự kỹ thuật đồ thị nhân quả)

Tiếp theo, phân lớp sự kiện (phân hoạch tương đương) Kiểm thử

từng lớp sự kiện và nhận ứng xử của hệ thi hành để phát hiện các sai do

xử lý đáp ứng các sự kiện đó

Cuối cùng, kiểm thử mọi lớp sự kiện Các sự kiện được đưa vàotrong hệ thống theo thứ tự ngẫu nhiên và với tần xuất ngẫu nhiên nhằmphát hiện các lỗi ứng xử

Bước 3: Kiểm thử liên tác

Kiểm thử liên tác là kiểm thử để tìm các sai liên quan đến thời gian đápứng do không đồng bộ:

Các tác vụ không đồng bộ khi liên tác với các tác vụ khác Vì thếcần kiểm thử với nhịp điệu dữ liệu và mức tải với các xử lý khácnhau

Các tác vụ không đồng bộ do giao tiếp phụ thuộc hàng đợi thôngđiệp hoặc truy nhập kho dữ liệu cũng được thử để bộc lộ các lỗi

về quy mô dữ liệu

Bước 4: Kiểm thử toàn hệ thống

Tích hợp phần cứng và phần mềm nhằm tìm lỗi trên các phương diện:Giao diện (giữa phần cứng và phần mềm)

Môi trường (tác động từ môi trường: các sự kiện)

Các ngắt (các loại ngắt và các xử lý xảy ra như hậu quả củangắt)

1.2.3.2. Kiểm thử Alpha và Beta

Kiểm thử alpha (alpha testing) và kiểm thử beta (beta testing) đều

do người dùng thực hiện và đều được thực hiện trong môi trường thực

Người phát triển không thể nào lường hết được khách hàng sẽ dùngchương trình như thế nào Các hướng dẫn sử dụng có thể bị hiểu sai, việc

tổ hợp dữ liệu lạ lại có thể hay được dùng, cái ra dường như rõ ràng vớingười kiểm thử, nhưng có thể lại khó hiểu đối với người dùng

Kiểm thử Alpha

Kiểm thử Alpha được khách hàng tiến hành tại cơ quan của ngườiphát triển Phần mềm được dùng theo sự sắp đặt tự nhiên với người pháttriển (nhìn qua vai) người dùng và ghi lại các lỗi khi sử dụng Kiểm thửAlpha còn có tên khác là kiểm thử “sau lưng” và được tiến hành trongmột môi trường có kiểm soát

Dữ liệu cho kiểm thử Alpha là dữ liệu mô phỏng

Kiểm thử Beta

Kiểm thử Beta được người dùng cuối tiến hành tại một hay nhiều cơquan khách hàng Không giống kiểm thử Alpha, người phát triển thườngkhông có mặt Do đókiểm thử Beta là việc áp dụng “sống” của phần mềmtrong một môi trường mà người phát triển không thể nào kiểm soát được.Khách hàng ghi lại tất cả các vấn đề (thực hay tưởng tượng) gặp phảitrong khi kiểm thử Beta và báo cáo lại những vấn đề đó cho người pháttriển trong những khoảng thời gian đều đặn Xem như một kết quả củavấn đề được báo cáo trong kiểm thử Beta, người phát triển tiến hành sửađổi rồi chuẩn bị đưa ra sản phẩm phần mềm cho toàn bộ khách hàng

Trường hợp kiểm thử Alpha và Beta cho 1 khách:

Khi các phần mềm dành cho một người đặt hàng, thì hoạt động

kiểm thử chỉ cần một khách hàng tiến hành thẩm định mọi yêucầu.

Kiểm thử này do người sử dụng cuối cùng thực hiện, không phải

là người đặt hàng

Kiểm thử chấp nhận có thể tiến hành vài tuần hoặc vài tháng mộtlần, nhờ đó mà bộc lộ được các lỗi tích lũy làm suy giảm hệthống theo thời gian

Trường hợp kiểm thử Alpha và Beta cho n khách:

Với phần mềm dành cho nhiều khách hàng, thì kiểm thử chấp nhậnbằng một khách hàng là không thực tế.Quá trình kiểm thử Alpha và Betacho nhiều người tiến hành là bắt buộc

1.2.3.3. Kiểm thử so sánh

Có một số tình huống (như điều khiển máy bay, điều khiển nhà máynăng lượng hạt nhân) mà trong đó độ tin cậy của phần mềm là yếu tố hàngđầu.Trong những ứng dụng như vậy, phần cứng và phần mềm thườngđược yêu cầu tối thiểu hóa khả năng lỗi.Khi phần mềm được phát triển,nhóm kỹ nghệ phần mềm tách biệt sẽ phát triển những bản độc lập ứngdụng bằng cách dùng cùng đặc tả.Trong những tình huống như thế, mỗibản có thể được kiểm thử với cùng dữ liệu để đảm bảo rằng tất cả đều chokết quả giống nhau

Các nhà nghiên cứu đã gợi ý rằng các bản phần mềm độc lập đượcphát triển Những bản độc lập này tạo nền cho kỹ thuật kiểm thử hộp đenđược gọi là kiểm thử so sánh (comparision testing) hay kiểm thử dựa vào

nhau (back-to-back testing).

Khi tạo ra nhiều cài đặt cho cùng một đặc tả, các ca kiểm thử đượcthiết kế để dùng những kỹ thuật hộp đen khác (như phân hoạch tương

đương) được xem như từng bản đầu vào của phần mềm.Vểw kết quả ra của mỗi bản là giống nhau thì người ta giả thiết rằng tất cả các cài đặt đều đúng.Neu kết quả ra là khác nhau thì từng ứng dụng sẽ được nghiên

cứu lại để xác định liệu một khiếm khuyết trong một hay nhiều bản cóphải là nguyên nhân sinh ra sự khác biệt hay không.Trong phần lớn cáctrường hợp, việc so sánh các kết quả ra có thể được thực hiện tự động.Việc kiểm thử so sánh không đơn giản Neu đặc tả mà từ đó tất cảcác phiên bản đã được xây dựng ra bị lỗi thì mọi bản đều có thể phản ánhlỗi đó.Mặt khác, nếu từng bản độc lập lại tạo ra kết quả giống nhau,nhưng không đúng, thì việc kiểm thử điều kiện sẽ không phát hiện đượclỗi

Trong quá trình kiểm thử so sánh, cần chú ý:

Khi triển khai nhiều phiên bản phần mềm từ cùng một đặc tả,kiểm thử hộp đen cho các sản phẩm này được thực hiện với cùng

ca kiểm thử và cùng các dữ liệu vào

Khi so sánh các kết quả thu được, nếu có khác biệt nghĩa là cósai trong một sản phẩm nào đó

1.3. Các phương pháp kiểm thử

Thiết kế kiểm thử cho phần mềm và các sản phẩm kỹ nghệ khác cóthể có tính thách đố như việc thiết kế ban đầu cho chính bản thân sản

phẩm Người kỹ sư phần mềm thường kiểm thử hần mềm sau khi lập trìnhxong.Các ca kiểm thử đòi hỏi vừa đúng lại vừa đủ.Mặt khác, kiểm thử cầnđược thiết kế sao cho có khả năng cao nhất để tìm ra lỗi với thời gian vàcông sức ít nhất.

Có rất nhiều phương pháp thiết kế trường hợp kiểm thử cho phầnmềm.Những phương pháp này cung cấp cho người phát triển một cáchtiếp cận hệ thống tới việc kiểm thử.Quan trọng hơn, những phương phápnày đưa ra một cơ chế có thể giúp đảm bảo tính đầy đủ của kiểm thử vàđưa ra khả năng cao nhất để phát hiện ra lỗi trong phần mềm

Bất kỳ sản phẩm kỹ nghệ nào đều có thể được kiểm thử một trong haicách:

(ỉ) Kiểm thử chức năng/ hộp đen: cho dữ liệu đầu vào đúng/ sai, kiểm tra đầu ra đúng/ sai, tức là kiểm thử xem từng chức năng có vận hành đúng không, không quan tâm đến cẩu trúc bên trong của chức năng đó;

(2) Kiểm thức cấu trúc/ hộp trắng: không những quan tâm đến mốiquan hệ đầu vào và đầu ra của chức năng đó mà còn quan tâm đếncấu trúc bên trong, quan tâm chi tiết đến từng đầu vào đầu ra củacác thành phần cấu thành trong đó và cả sự ăn khớp giữa chúngnữa, tức là đảm bảo rằng, sự vận hành bên trong thực hiện đúngtheo đặc tả và tất cả các thành phần bên trong đều được quan tâm vàđược kiểm tra một cách chi tiết

Đối với phần mềm máy tính, kiểm thử hộp đen biểu thị việc kiểmthử được tiến hành tại giao diện phần mềm Mặc dầu chúng được thiết kế

để phát hiện ra lỗi, kiểm thử hộp đen được dùng để thể hiện rằng các chứcnăng phần mềm đã vận hành, cái vào được chấp nhận đúng, và cái rađược tạo ra đúng, tính toàn vẹn thông tin ngoài (như tệp dữ liệu) là đượcduy trì Phép kiểm thử hộp đen xem xét một khía cạnh của hệ thống mà ít

để ý tới cấu trúc logic bên trong của phần mềm

Kiểm thử hộp trắng được hướng tới việc xem xét kỹ về chi tiết thủtục.Các đường logic đi qua phần mềm được kiểm thử bằng cách đưa racác trường hợp kiểm thử, vốn thực hiện trên một tập xác định các điềukiện và/ hoặc chu trình “Trạng thái của chương trình” có thể được xemxét tại nhiều điểm khác nhau để xác định liệu trạng thái dự kiến haykhẳng định có tương ứng với trạng thái thực tại hay không

Thoáng nhìn dường như là việc kiểm thử hộp trắng rất thấu đáo sẽdẫn tới “chương trình chính xác 100%” Mọi điều ta cần là xác định tất cảcác con dđường logic, xây dựng các trường hợp kiểm thử để vét hết logicchương trình Nhưng việc kiểm thử vét cạn lại có một số vấn đề.Ngay cảvới những chương trình nhỏ, số các đường logic cũng có thể rất lớn.Tuy nhiên, việc kiểm thử hộp trắng không nên bị bỏ qua không xét

vì không thực tế.Người ta có thể chọn ra một số có giới hạn đường logicquan trọng và thực hiện chúng Có thể thăm dò cấu trúc dữ liệu quantrọng về tính hợp lệ Các thuộc tính của cả kiểm thử hộp đen lẫn hộp trắng

có thể được tổ hợp để đưa ra một cách tiếp cận để làm hợp lệ cho giaodiện phần mềm và bảo đảm có chọn lựa rằng công việc bên trong củaphần mềm là đúng đắn

1.4. Các kỹ thuật kiểm thử

Mục tiêu của kiểm thử là phải thiết kế các trường hợp kiểm thử cókhả năng cao nhất trong việc phát hiện nhiều lỗi với thời gian và công sứctối thiểu Do đó, có thể chia các kỹ thuật kiểm thử thành hai loại:

Kỹ thuật kiểm thử hộp đen (Black - box testing) hay còn gọi là

kỹ thuật kiểm thử chức năng

Kỹ thuật kiểm thử hộp trắng (white - box testing) hay còn gọi là

kỹ thuật kiểm thử cấu trúc (structural testing)

1.4.1. Kỹ thuật kiểm thử hộp đen (Black - box testing)

Kiểm thử hộp đen hay còn gọi kiểm thử hướng dữ liệu (data driven)hay là kiểm thử hướng vào/ra (input/output driven)

Trong kỹ thuật này, người kiểm thử xem phần mềm như là một hộpđen Người kiểm thử hoàn toàn không quan tâm đến cấu trúc và hành vibên trong của chương trình Người kiểm thử chỉ cần quan tâm đến việctìm các hiện tượng mà phần mềm không hành xử theo đúng đặc tả của nó

Do đó, dữ liệu kiểm thử sẽ xuất phát từ đặc tả

1.4.2. Kỹ thuật kiểm thử hộp trắng (white - box testing)

Kiểm thử hộp trắng hay còn gọi là kiểm thử hướng logic, cho phépkiểm tra cấu trúc bên trong của phần mềm với mục đích bảo đảm rằng tất

cả các câu lệnh và điều kiện sẽ được thực hiện ít nhất một lần.Người kiểmthử truy nhập vào mã nguồn chương trình và có thể kiểm tra nó, lấy đólàm cơ sở để hỗ trợ việc kiểm thử

Kết luận

Trong chương 1 đã nêu tổng quan về kỹ nghệ phần mềm và các loạikiểm thử phần mềm cơ bản.Kiểm thử hộp trắng xem xét chương trình ởmức độ chi tiết và phù hợp khi kiểm tra các môđun nhỏ.Tuy nhiên, kiểmthử hộp trắng có thể không đầy đủ vì kiểm thử hết các lệnh không chứng

tỏ là chúng ta đã kiểm thử hết các trường hợp có thể.Ngoài ra chúng takhông thể kiểm thử hết các đường đi với các vồng lặp lớn

Kiểm thử hộp đen chú trọng vào việc kiểm tra các quan hệ vào/ra

và những chức năng giao diện bên ngoài, nó thích hợp hơn cho các hệthống phần mềm lớn hay các thành phần quan trọng của chúng.Nhưng chỉ

sử dụng kiểm thử hộp đen là chưa đủ.Bởi vì, kiểm thử chức năng chỉ dựatrên đặc tả của môđun nên không thể kiểm thử được các trường hợpkhông được khai báo trong đặc tả Ngoài ra, do không phân tích mã nguồnnên không thể biết được môđun nào của chương trình đã hay chưa đượckiểm thử, khi đó phải kiểm thử lại hay bỏ qua những lỗi tiềm ẩn trong góiphần mềm

Phương pháp kiểm thử hộp trắng và kiểm thử hộp đen là haiphương pháp cơ bản có vai trồ rất quan trọng trong quá trình phát triểnphần mềm, nếu chúng ta biết kết hợp chúng để bổ sung khiếm khuyết lẫnnhau

CHƯƠNG2 CÁC KỸ THUẬT KIỂM THỬ HỘP TRẮNG

2.1. Đồ thị dòng

Một kỹ thuật kiểm thử hộp trắng đầu tiên được TomMcCabe đềnghị là ‘‘kiểm thử đường cơ sở. Phương pháp đường cơ sở giúp cho ngườithiết kế trường hợp kiểm thử có thể suy dẫn ra một cách đo độ phức tạplogic của thiết kế thủ tục và dùng cách này như một hướng dẫn để xácđịnh một tập cơ sở các đường thực hiện Các trường hợp kiểm thử đượcsuy dẫ ra để thực hiện một tập cơ sở, đảm bảo để thực hiện mọi câu lệnhtrong chương trình ít nhất một lần trong khi kiểm thử

Trong phương pháp đường cơ sở một hệ thống ký pháp đơn giảnđược dùng để biểu diễn cho luồng điều khiển, được gọi là đồ thị dòng

(hay đồ thị chương trình) Đồ thị dồng mô tả cho dòng điều khiển logic

dung ký pháp được minh họa trong hình 2.1 Mỗi kết cấu có cấu trúc đều

có một ký hiệu đồ thị dòng tương ứng

Hình 2.1 Các cẩu trúc cơ bản của đồ thị dòng

(sequence, if, while, until, case)

Đồ thị dòng thực chất là một kỹ thuật dựa trên cấu trúc điều khiểncủa chương trình.Nó gần giống đồ thị luồng điều khiển của chương trình

Đồ thị dòng nhận được từ đồ thị luồng điều khiển bằng hai cách:

Gộp các lệnh tuần tự và điều khiển liên tiếp thành một lệnh;Thay lệnh rẽ nhánh của các đường điều khiển bằng một nút “vị tự”

Cấu trúc đồ thị dồng gồm:

Mỗi nút (hình tròn) biểu thị một hay một số lệnh tuần tự và rẽ nhánh, hoặc thay cho điểm phân nhánh hay hội tụ các đường điều khiển

Mỗi cạnh nối hai nút biểu diễn dòng điều khiển

Kết quả đồ thị dồng thể hiện:

Chia mặt phẳng thành nhiều miền

Có nút vị tự biểu thị sự phân nhánh của các cung

Mỗi cung nối từng cặp nút biểu diễn luồng điều khiển

Ví du 1:

Xét một cấu trúc điều khiển chương trình

Do while cồn bản ghi chưa xử lý

Read bản ghi chưa xử lý

if giá trị trường thứ nhất của bản ghi = 0

end do

Bước 1 - Gán nhãn cho các dòng lệnh:

1 Do while cồn bản ghi chưa xử lý

2 Read bản ghi chưa xử lý

3 if giá trị trường thứ nhất của bản ghi = 0

4 then xử lý bản ghi;

Cất vào bộ nhớ;

5 tăng biến đếm;

6 else if giá trị trường thứ hai của bản ghi = 0

7 then tạo lại bản ghi;

8 else xử lý bản ghi;

Cất vào tệp;

9 end if

10 end if

11 end do

Các dòng lệnh có liên quan đến xử lý dữ liệu đều được đánh số thứ

tự (1, 2, 11), từ đó sẽ được sơ đồ điều khiển của chương trình (hình 2.2)\

Bước 2- Vẽ sơ đồ điều khiển của chương trình :

Hình 2.2 Sơ đồ điều khiển của chương trình

Trên cơ sở gộp các lệnh thực hiện tuần tự liền kề với nhau hoặclệnh thực hiện liền kề rẽ nhánh, ta có sơ đồ luồng điều khiển (mức gộp)(hình 2.3)

Hình 2.3 Sơ đồ luồng điều khiển

Bước 3- Vẽ đồ thị dòng:

Từ sơ đồ luồng điều khiển xác định được đồ thị dòng (hình 2.4) Cácthông số của đồ thị dồng gồm: 9 nút (N=9), trong đó:3 nút là vị tự (P=3) (nút được đánh dấu tô màu sẫm), 11 cung (E=ll)

Hình 2.4 Đồ thị dòng