Luận văn thạc sĩ nghiên cứu các kỹ thuật kiểm thử hộp trắ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ần mềm cần kiểm thử để xác địnhđơn vị phần mềm đó có th

HÀ NỘI, 2015

NGUYỄN HƯƠNG GIANG

NGHIÊN CỨU CẤC KỸ THUẬT KIỂM IHỬHỘP TRẮNG

LUẬN VĂN THẠC sĩ MÁY TÍNH

NGHIÊN CỨU CẤC KỸ THUẬT KIỂM IHỬHỘP TRẮNG

Chuyên ngành: Khoa học máy tính

hướng dẫn, chỉ bảo cho tôi trong suốt quá trình tôi làm luận văn.

Tôi cũng xin gửi lời cảm ơn đến các thầy cô trường Đại học sư phạm Hà Nội 2,các thầy cô Viện Công nghệ thông tin - Viện Hàn lâm Khoa học và Công nghệ ViệtNam đã truyền đạt những kiến thức và giúp đỡ tôi trong suốt quá trình học của mình.Tôi cũng xin gửi lời cảm ơn tới các đồng nghiệp, gia đình và bạn bè nhữngngười đã động viên tạo mọi điều kiện giúp đỡ tôi trong suốt thời gian học vừa qua

Tôi xin cam đoan toàn bộ nội dung trong luận văn này do tôi tự nghiên cứu, đọc, dịch tài liệu, tổng hợp và thực hiện, đây là công trình nghiên cứu của tôi dưới sự

hướng dẫn khoa học của thầy TS Lề Văn Phùng Các số liệu, kết quả trong luận văn

là trung thực, rõ ràng Trong luận văn tôi có sử dụng một số tài liệu tham khảo như đã trình bày trong phần tài liệu tham khảo Tôi xin chịu trách nhiệm với những nội dung được viết trong luận văn này

Hà nội, ngày tháng 12 năm 2015

Người viết luận văn

Nguyễn Hương Giang MỤC LỤC

LỜI CẢM ƠN 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ƯƠNG 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.2.2 Mô hình chiến lược tổng thể 81.2.3 Một số chiến lược kiểm thử khác 91.2.3.1 Chiến lược kiểm thử hệ thời gian thực

101.2.3.2 Kiểm thử Alpha và Beta

111.2.3.3 Kiểm thử so sánh

131.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

Ket luận 17 CHƯƠNG 2 CÁC KỸ THUẬT KIÊM THỬ HỘP TRÂNG

18

2.1 Đồ thị dòng 182.2 Ma trận kiểm thử 232.3 Điều kiện logic với chiến lược kiểm thử miền và nhánh

38

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

DANH MỤC HÌNH

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

Hình 2.1 Các cấu trúc cơ bản của đồ thị dòng (sequence, if, while, until, case) 18

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

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

Hình 2.4 Đồ thị dòng 22

Hình 2.5 Sơ đồ điều khiển chương trình của ví dụ 2 30

Hình 2.6 Sơ đồ điều khiển chương trình mức gộp của ví dụ 2 31

Hình 2.7 Đồ thị dòng mức gộp của ví dụ 2 32

Hình 2.8 Độ phức tạp của chu trình xác định từ đồ thị dòng mức gộp 34

Hình 2.9 Xác định các ca kiểm thửbằng đường cơ bản và điều kiện 44

Hình 2.10 Đồ thị dòng để xác định tập đường cơ bản nhỏ nhất phủ các lệnh 45

Hình 2.11 Xác định điều kiện cho đường cơ bản 45

Hình 2.12 Dạng vòng lặp thứ nhất 51

Hình 2.13 Dạng vòng lặp thứ hai 52

Hình 2.14 Kiểu vòng lặp lồng nhau 52

Hình 2.15 Ket hợp mỗi vòng lặp trước với mọi vòng lặp sau 48

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

Hình 3.1 Giao diện form chính 54

Hình 3.2 Cửa sổ chọn file nguồn cho chương trình 54

Hình 3.3 Hiển thị file nguồn 55

Hình 3.4 Kết quả độ phức tạp 55

Hình 3.5 Kết quả Tập kiểm thử 56

Bảng 2.3 Bảng kiểm thử kết quả ra 41

Bảng 2.4 Bảng kiểm thử có ràng buộc 41

Bảng 2.5.Tập các giá trị bảo đảm các ràng buộc đầu ra 42

Bảng 2.6 Tập các giá trị bảo đảm các ràng buộc đầu ra của c 42

Bảng 2.7.Xác định các đầu ra để kiểm thử 43

Bảng 2.8 Tập đường cơ bản nhỏ nhất phủ các lệnh 45

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ức năng cũng như giao diện, ứngdụng của sản phẩm đó đều cần qua kiểm thử Một sản phẩm tuy được thiết kế tốt nhưngcũng không thể tránh khỏi các sai sót Kiểm thử hiệu quả sẽ phát hiện ra được các sai sótnày, tránh cá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ópphần xác định chất lượng phần mề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ần mềm cần kiểm thử để xác địnhđơn vị phần mềm đó có thực hiện đúng khô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”.

2 Mục đích nghiền cứu

- Nâng cao kiến thức về công nghệ phần mềm, bảo đảm toán học trong khoa học máy

- Thực hành các kỳ thuật xác định các ca kiểm thử trong công nghệ 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ắng như kỳ thuật đồ thịdòng, ma trận kiểm thử, điều kiện logic, điều khiển theo 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ài toá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ạn lệnh/mô-đun/chương trình).Phạm

vi nghiên cứu của đề tài là các kỳ thuật kiể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

CHƯƠNG 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

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ùm kiế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ử

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 lập trình chưa có khó khăn gì cả.Khi 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 lập trình bắt đầu gặp một vài khó khăn nho nhỏ.Giờ đâ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 lớ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ới.Khó khăn mà họ tạo nên chỉnh là việc sử dụng sản phẩm của họ.

1.1 Khái niệm Ctf bản về kiềm thử

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ểm soá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ét theo 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ểm thử để 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ương trì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 tìm ra lỗi

©Một ca kiểm thử là một trường hợp kiểm thử có xác suất cao để tìm ra lỗi

©Việc kiểm thử thành công là việc kiểm thử làm lộ ra một lỗi còn chưa được pháthiện

Các mục đích trên dẫn đến một sự thay đổi lớn trong quan điểm.Chúng đi ngược lạiquan điểm thông thường là một phép kiểm thử thành công là kiểm thử không tìm ra lỗinào.Mục đích của chúng ta là thiết kế các ca kiểm thử để làm lộ ra một cách có hệ thốngnhững lớp lỗi khác nhau và làm như vậy với một số lượng thời gian và công sức ít nhất

Nếu kiểm thử được tiến hành thành công, thì nó sẽ làm lộ ra những lỗi trong phầnmềm Việc kiểm thử phần mềm làm việc theo đặc tả nên các yêu cầu hiệu năng dường như

là được đáp ứng Bên cạnh đó, dữ liệu thu thập được khi việc kiểm thử tiến hành đưa ramột chỉ dẫn tốt về độ tin cậy phần mềm và một chỉ dẫn nào đó về phẩm chất phần mềmvới tư cách toàn cục

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ầnmề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ử tot là ca kiểm thử có xác suất cao tìm ra 1 lỗi.

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ànhả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 quan trọ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 định phần mềmkhô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ộtdãy các bước nhằm hướng dẫn quá trình kiểm thử phần mề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 cho kiể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ểmthử, 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ách hà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ụngnhữ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

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át triển để bảođảm thực hiện theo đúng thiết kế, có thể tham gia kiểm thử tích hợp; khôngkhoán trắng chương trình cho người kiểm thử mà phải cùng làm việc với ngườikiể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ấu trú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ẫn giữa những người tham gia; đánh giá công sứcngườ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ể

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ộtlớ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ắp ghép haytí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ựng chương trình.Các

kỹ thuật thiết kế kiểm thử hộp đen được dùng trong hầu hết quá trình tích hợp, mặc dù cáckiểm thử hộp trắng cũng có thể được dùng để bao quát đa số các đường điều khiển.Sau khiphần mềm đã được dùng tích hợp (được xây dựng), một tập hợp các phép kiểm thử sẽđược tiế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ểm thử hộp đen được dùng chủ yếu trong kiểmthử 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áytí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ác thà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ạt cá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ện của môitrường

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ảixem 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ếntrình) giải quyết dữ liệu đó.Trong nhiề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ường phần cứngcủa nó cũng có thể gây ra các vấn đề cho kiểm thử.Việc kiểm thử phần mềm phảixem 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ấtkhó 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 4 bướcthực hiện:

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

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ểmthử với nhịp điệu dữ liệu và mức tải với các xử lý khác nhau

Các tác vụ không đồng bộ do giao tiếp phụ thuộc hàng đợi thông điệp hoặctruy 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ủa ngắ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ườidù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ùng chươngtrì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ới ngườ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ười phát triển.Phần mềm được dùng theo sự sắp đặt tự nhiên với người phát triể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ểmthử “sau lưng” và được tiến hành trong mộ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ơ quankhách hàng Không giống kiểm thử Alpha, người phát triển thường không có mặt Dođókiểm thử Beta là việc áp dụng “sống” của phần mềm trong 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ải trong khi kiểm thử Beta và báo cáo lại những vấn đề

đó cho người phát triển trong những khoảng thời gian đều đặn Xem như một kết quảcủa vấ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ồichuẩ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êu cầ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ột lầ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ận bằng mộtkhách hàng là không thực tế.Quá trình kiểm thử Alpha và Beta cho nhiều người tiếnhà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áy nănglượng hạt nhân) mà trong đó độ tin cậy của phần mềm là yếu tố hàng đầu.Trongnhữ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 ứng dụng bằng cách dùng cùng đặc tả.Trong những tìnhhuống như thế, mỗi bản có thể được kiểm thử với cùng dữ liệu để đảm bảo rằng tất cảđều cho kế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 được phá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ử được thiế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 memJVew 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.Nếu 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ộthay 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ớncác trườ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ênbản đã được xây dựng ra bị lỗi thì mọi bản đều có thể phản ánh lỗi đó.Mặt khác, nếutừ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 được lỗ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 trongmộ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ínhthá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ầnmềm thường kiểm thử hần mềm sau khi lập trình xong.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ần mềm.Nhữngphương pháp này cung cấp cho người phát triển một cách tiếp cận hệ thống tới việckiểm thử.Quan trọng hơn, những phương pháp này đưa ra một cơ chế có thể giúp đảmbả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 trongphần mềm

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

đầ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ối quan hệ đầuvào và đầu ra của chức năng đó mà còn quan tâm đến cấu trúc bên trong, quantâm chi tiết đến từng đầu vào đầu ra của các thành phần cấu thành trong đó và

cả sự ăn khớp giữa chúng nữa, tức là đảm bảo rằng, sự vận hành bên trongthực hiện đúng theo đặc tả và tất cả các thành phần bên trong đều được quantâ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ểm thử đượctiế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ức nă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 tinngoài (như tệp dữ liệu) là được duy trì Phép kiểm thử hộp đen xem xét một khía cạnhcủ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 ra các trường hợp kiểmthử, vốn thực hiện trên một tập xác định các điều kiện và/ hoặc chu trình “Trạng tháicủa chương trình” có thể được xem xét tại nhiều điểm khác nhau để xác định liệutrạng thái dự kiến hay khẳ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đườnglogic, xây dựng các trường hợp kiểm thử để vét hết logic chương trình Nhưng việckiể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ôngthực tế.Người ta có thể chọn ra một số có giới hạn đường logic quan trọng và thựchiện chúng Có thể thăm dò cấu trúc dữ liệu quan trọng về tính hợp lệ Các thuộc tínhcủ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 giao diện phần mềm và bảo đảm có chọn lựa rằng công việc bêntrong của phầ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ăngcao nhất trong việc phát hiện nhiều lỗi với thời gian và công sức tố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 vi bên trong củachương trình Người kiểm thử chỉ cần quan tâm đến việc tìm các hiện tượng mà phầnmề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ép kiểm tracấ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ểm thử truy nhập vào mã nguồnchương trình và có thể kiểm tra nó, lấy đó làm cơ sở để hỗ trợ việc kiểm thử

hợp khi kiểm tra các môđun nhỏ.Tuy nhiên, kiểm thử 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 ta khô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ữngchứ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 haycá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ựa trên đặc tả của môđun nên không thể kiểm thửđược các trường hợp không được khai báo trong đặc tả Ngoài ra, do không phân tích

mã nguồn nê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ói phần mềm

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

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

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ển của chươngtrì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ự”

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

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ườngthứ nhất của bản ghi = 0 then xử lý bản ghi;

Cất vào bộ nhớ;

tăng biến đếm;

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

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

else xử lý bản ghi;

Cất vào tệp;

end ifend if

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ý

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

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

Mỗi ô: ghi giá trị là 1 nếu có cung nối nút dòng đến nút cột, ghi giá trị là 0 nếu không có cung nối nút dòng đến nútcột.

Nhân liên tiếp k ma trận này ta được ma trận có số ở mỗi ô chỉ số con đường k cung từ nút dòng tới nút cột

Ma trận kiểm thử được sử dụng như một dữ liệu có cấu trúc để kiểm tra các con đường cơ bản: số đường đi qua nút (có thể tính cả trọng số của chúng)

Ma trận kiểm thử là 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 thử, ta thêm trọng số cho các cung của ma trận kiểm thử (ma trận kiểm thử có trọng số) như sau:

Xác suất cung đó được thực thi.Thời gian xử lý của tiến trình đi qua cung đó

Bộ nhớ đòi hỏi của tiến trình đi qua cung đó

- Nguồn lực đòi hỏi của tiến trình đi qua cung đó