Các phương pháp đánh giá chất lượng phần mềm

Trong qui trình này, kiểm thử phần mềm là giai đoạn quan trọng nhằm đảm bảo chất lượng phần mềm, là quá trình chạy thử một ứng dụng để phát hiện lỗi và xem nó đã thỏa mãn yêu cầu đặt ra

LỜI CAM ĐOAN

Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi, số liệu và kết quả nghiên cứu trong luận văn này là trung thực và không trùng lặp với các đề tài khác Tôi cũng xin cam đoan rằng mọi sự giúp đỡ cho việc thực hiện luận văn này

đã được cảm ơn và các thông tin trích dẫn trong luận văn đã được chỉ rõ nguồn gốc

Học viên

Nguyễn Thị Tính

MỤC LỤC

LỜI CAM ĐOAN i

MỤC LỤC ii

MỤC LỤC HÌNH ẢNH iv

DANH MỤC BẢNG BIỂU v

ĐẶT VẤN ĐỀ vi

I.TÍNH CẤP THIẾT CỦA ĐỀ TÀI vi

II.MỤC TIÊU CỦA ĐỀ TÀI LUẬN VĂN vii

III.ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU vii

IV.PHƯƠNG PHÁP NGHIÊN CỨU vii

V.KẾT QUẢ DỰ KIẾN ĐẠT ĐƯỢC vii

VI.CẤU TRÚC LUẬN VĂN viii

CHƯƠNG 1 QUI TRÌNH VÀ CHẤT LƯỢNG PHẦN MỀM 1

1.1 SẢN PHẨM VÀ CHẤT LƯỢNG PHẦN MỀM 1

1.1.1 Khái niệm về sản phẩm phần mềm 1

1.1.2 Khái niệm lỗi phần mềm 3

1.1.3 Chi phí sửa lỗi 5

1.1.4 Khái niệm kiểm thử phần mềm 6

1.1.5 Những khó khăn của kiểm thử phần mềm 7

1.1.6 Kiểm thử trong quy trình phát triển phần mềm 7

1.2 CHẤT LƯỢNG VÀ CÁC TIÊU CHÍ ĐÁNH GIÁ PHẦN MỀM 11

1.2.1 Chất lượng phần mềm 11

1.2.2 Các tiêu chí đánh giá 12

1.3 QUY TRÌNH KIỂM THỬ PHẦN MỀM 13

1.4 TỰ ĐỘNG HÓA KIỂM THỬ 14

CHƯƠNG 2 CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM 16

2.1.NGUYÊN TẮC CƠ BẢN CỦA KIỂM THỬ PHẦN MỀM 16

2.1.1.Các nguyên tắc kiểm thử phần mềm 16

2.1.2 Luồng thông tin kiểm thử 19

2.1.3 Thiết kế trường hợp kiểm thử 20

2.2.KIỂM THỬ HỘP ĐEN 20

2.2.1 Phân hoạch tương đương 21

2.2.2 Phân tích giá trị biên 26

2.2.3 Kiểm thử giá trị đặc biệt 28

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

2.3.KIỂM THỬ HỘP TRẮNG 33

2.3.1 Kiểm thử dựa trên đồ thị luồng điều khiển 33

2.3.2.Kiểm thử dựa trên đồ thị luồng dữ liệu 41

2.3.3.Kiểm thử điều kiện 43

2.4.SO SÁNH KIỂM THỬ HỘP ĐEN VÀ KIỂM THỬ HỘP TRẮNG 44

CHƯƠNG 3MỘT SỐ ỨNG DỤNG CỦA QUY TRÌNH KIỂM THỬ 45

3.1 BÀI TOÁN NAME CORRECTING 46

3.1.1 Giới thiệu bài toán 46

3.1.2 Phạm vi giải quyết 49

3.1.3 Thiết kế trường hợp kiểm thử 49

3.2 BÀI TOÁN SORT 52

3.2.1 Phát biểu bài toán 52

3.2.2 Phạm vi giải quyết 52

3.2.3 Thiết kế trường hợp kiểm thử 52

3.2.4 Kết quả kiểm thử 60

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 61

TÀI LIỆU THAM KHẢO 62

MỤC LỤC HÌNH ẢNH

Hình 1 1 - Sản phẩm phần mềm Nguồn: [13] 3

Hình 1 2 – Các nguyên nhân gây ra lỗi phần mềm [5] 4

Hình 1 3 - Chi phí cho việc sửa lỗi Nguồn: [6], [8] 6

Hình 1 4 - Quy trình kiểm thử 13

Hình 1 5 -Quy trình chi tiết quá trình kiểm thử 14

Hình 2 1 - Mô hình luồng thông tin kiểm thử 19

Hình 2 2 - Ví dụ đồ thị nhân quả 32

Hình 2 3 – Quy trình tạo ca kiểm thử dựa trên đồ thị luồng điều khiển 34

Hình 2 4 – Đồ thị luồng điều khiển biểu diễn chương trình sum 35

Hình 2 5 - Ví dụ tiêu chí bao phủ cung 35

Hình 2 6 - Đồ thị biểu diễn chương trình tính tổng nghịch đảo 37

Hình 2 7 - Đồ thị luồng điều khiển biểu diễn hàm abc 39

Hình 2 8 - Đồ thị luồng điều khiển biểu diễn hàm foo 42

Hình 3 1 - Giao diện kiểm thử bài toán NC 51

Hình 3 2 - Minh họa thuật toán sắp xếp MergeSort 53

Hình 3 3 - Đồ thị lưu trình cho hàm Merge 54

Hình 3 4 - Kết quả được ghi ra file log 60

Hình 3 5 - Giao diện điều khiển kiểm thử các thuật toán sắp xếp 60

DANH MỤC BẢNG BIỂU

Bảng 1 1 - Tỷ lệ công việc của các giai đoạn phát triển phần mềm 1

Bảng 2 1 - Bảng liệt kê các lớp tương đương 22

Bảng 2 3 – Các lớp tương đương cho chương trình tính hoa hồng 24

Bảng 2 4 – Các ca kiểm thử lớp tương đương yếu 24

cho chương trình tính hoa hồng 24

Bảng 2 5 – Kiểm thử lớp tương đương cho chương trình tính hoa hồng 25

Bảng 2 6 – Các lớp tương đương cho chương trình tam giác dựa vào dữ liệu vào 25

Bảng 2 7 – Các ca kiểm thử cho chương trình tam giác dựa trên dữ liệu vào 26

Bảng 2 8 – Các ký hiệu trong đồ thị nhân quả 30

Bảng 2 9 - Bảng quyết định tính thuế thu nhập 32

Bảng 3 1 - Minh họa các testcase chương trình NC 50

Bảng 3 2 - Bảng các trường hợp kiểm thử cho module Merge 56

Bảng 3 3 - Các trường hợp kiểm thử cho module Split 57

ĐẶT VẤN ĐỀ

I TÍNH CẤP THIẾT CỦA ĐỀ TÀI

Với sự phát triển ngày càng mạnh mẽ của công nghiệp công nghệ thông tin nói chung và công nghệ phần mềm nói riêng, việc xây dựng và phát triển phần mềm

đã thực ngày càng tỏ ra hiệu quả hơn nhờ sự hỗ trợ của nhiều công cụ tiện ích và tiên tiến Cùng với đà phát triển đó, hoạt động quản lí chất lượng phần mềm ngày càng gánh trách nhiệm thêm nặng nề và chuyên nghiệp Tuy nhiên thực tế đã cho thấy rằng, các vấn đề về quản lý chất lượng phần mềm vẫn chưa thực sự đáp ứng được những đòi hỏi khắt khe của phần mềm về chất lượng cũng như tốc độ triển khai ứng dụng Các hoạt động đánh giá chất lượng phần mềm vẫn không đảm bảo được các sản phẩm phần mềm là không có lỗi

Quản lý chất lượng phần mềm là một lĩnh vực của công nghệ phần mềm, có nhiệm vụ kiểm tra và xác minh các tiêu chí phần mềm: tính đúng, tính khoa học, tính tin cậy, tính vững vàng, tính dễ chuyển mang, tính dễ sử dụng, dễ phát triển và hoàn thiện Đây là một quá trình liên tục, xuyên suốt mọi giai đoạn phát triển phần mềm nhằm đảm bảo phần mềm đáp ứng các yêu cầu thiết kế và nhu cầu của người dùng Các kỹ thuật đánh giá chất lượng phần mềm đã và đang được nghiên cứu cả

về chiều rộng lẫn chiều sâu, và việc đánh giá này đã trở thành quy trình bắt buộc trong các dự án phát triển phần mềm [1] Trong qui trình này, kiểm thử phần mềm

là giai đoạn quan trọng nhằm đảm bảo chất lượng phần mềm, là quá trình chạy thử một ứng dụng để phát hiện lỗi và xem nó đã thỏa mãn yêu cầu đặt ra trong giai đoạn phát triển phần mềm [3] Một sản phẩm phần mềm được phân phối phải có đầy đủ các chức năng yêu cầu và tương thích với phần cứng của khách hàng [4], [2]

Quy trình phát triển phần mềm bao gồm nhiều giai đoạn và nhiều hoạt động nhằm tạo ra sản phẩm phần mềm Trong đó, kiểm thử là một trong những hoạt động đóng vai trò quan trọng nhằm phát hiện lỗi của phần mềm [5] Đánh giá chất lượng phần mềm ngày càng khó khăn hơn, bởi vì các ngôn ngữ lập trình, các hệ điều hành

và các phương pháp, công cụ phát triển phần mềm cũng như các thiết bị phần cứng

ngày càng phong phú và đa dạng.Vì vậy, học viên chọn đề tài “Các phương pháp đánh giá chất lượng phần mềm” làm hướng nghiên cứu cho luận văn

II MỤC TIÊU CỦA ĐỀ TÀI LUẬN VĂN

Mục đích chính của luận văn là:

 Nghiên cứu, tìm hiểu về nguyên lý, phương pháp và các kỹ thuật quản lý

và đánh giá chất lượng phần mềm

 Thiết kế các trường hợp kiểm thử và xây dựng vài kịch bản kiểm thử cụ thể

III ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU

 Luận tập trung tìm hiểu, phân tích và khảo sát các đổi tượng sau đây:

 Quy trình và bản chất của các kỹ thuật đánh giá chất lượng phần mềm

 Tìm hiểu và phát triển các kĩ thuật kiểm thửhộp đen và kiểm thử hộp trắng

 Thiết kế các trường hợp kiểm thử với bộ dữ liệu lớn

IV PHƯƠNG PHÁP NGHIÊN CỨU

Phương pháp nghiên cứu được sử dụng trong luận văn chủ yếu bao gồm:

 Phương pháp luận: Nghiên cứu, tìm hiểu các khái niệm, chiến lược và kỹ thuật đánh giá chất lượng phần mềm

 Phương pháp thực nghiệm: thiết kế các trường hợp kiểm thử áp dụng cho kịch bản kiểm thử cụ thể

V KẾT QUẢ DỰ KIẾN ĐẠT ĐƯỢC

Luận văn tập trung chủ yếu vào các kĩ thuật kiểm thử phần mềm là khâu quan trọng trong quản lí chất lượng phần mềm

 Thiết kế các trường hợp kiểm thử cho một số kịch bản kiểm thử cụ thể

 Đặc tả trường hợp kiểm thử và kết quả kiểm thử

 Xây dựng kịch bản kiểm thử

Các kịch bản kiểm thử được chia làm hai loại chính: kiểm thử chức năng và kiểm thử phi chức năng.Hai bài toán 3.1 và 3.2 được đề xuất trong chương 3 nhằm minh họa cho các kĩ thuật được vận dụng trong hai loại kiểm thử nói trên

VI CẤU TRÚC LUẬN VĂN

Luận văn gồm Phần mở đầu, ba chương nội dung, Phần kết luận và Tài liệu tham khảo

Chương 1: Tổng quan về qui trình quản lí chất lượng phần mềm

Tìm hiểu khái niệm chung về sản phẩm phần mềm, vấn đề chất lượng phần mềm, tầm quan trọng, khó khăn của việc kiểm thử phần mềm và các hoạt động đánh giá chất lượng trong quy trình phát triển phần mềm

Chương 2: Các kỹ thuật kiểm thử phần mềm

Nội dung của chương này phân tích các kỹ thuật cơ bản trong kiểm thử phần mềm:

 Kiểm thử hộp đen: xây dựng lớp phân hoạch tương đương, phân tích giá trị biên, kỹ thuật đồ thị nhân quả, kiểm thử giá trị đặc biệt

 Kiểm thử hộp trắng: kiểm thử dựa trên đồ thị luồng điều khiển, kiểm thử dựa trên luồng dữ liệu, kiểm thử điều kiện

Trên cơ sở các nội dung nói trên, luận văn phân tích, làm nổi bật những yếu

tố quan trọng trong đảm bảo chất lượng phần mềm

Chương 3: Một số ứng dụng cụ thể của quy trình kiểm thử

Để minh hoạ cho phần lý thuyết ở trên, chương 3 sẽ trình bày một vài kịch bản kiểm thử áp dụng kỹ thuật hộp đen và kỹ thuật hộp trắng để kiểm thử

Xây dựng các trường hợp kiểm thử (test cases) cho từng kịch bản kiểm thử Xây dựng chương trình và giao diện: thực hiện với các trường hợp kiểm thử

đã đề xuất, đối sánh kết quả của chương trình và kết quả dự kiến của các trường hợp kiểm thử

Kết luận và hướng phát triển

Tài liệu tham khảo

CHƯƠNG 1 QUI TRÌNH VÀ CHẤT LƯỢNG PHẦN MỀM 1.1 SẢN PHẨM VÀ CHẤT LƯỢNG PHẦN MỀM

1.1.1 Khái niệm về sản phẩm phần mềm

Phần mềm là một (bộ) chương trình đươc cài đặt trên máy tính thực hiện một nhiệm vụ tương đối độc lập nhằm phục vụ cho một hoặc nhiều ứng dụng cụ thể: quản lý hoạt động của máy tính hoặc áp dụng máy tính trong các hoạt động kinh tế,

quốc phòng, văn hóa, giáo dục, giải trí…[4], [5]

Bảng 1 1 - Tỷ lệ công việc của các giai đoạn phát triển phần mềm

Giai đoạn

Phân tích yêu cầu

Thiết

kế sơ

bộ

Thiết kế chi tiết

Lập trình

và kiểm thử đơn vị

Tích hợp và kiểm thử tích hợp

Kiểm thử hệ thống

Thập kỉ

Theo một tài liệu khác [7], chi phí liên quan từng giai đoạn của vòng đời

phần mềm được thể hiện trong biểu đồ hình quạt như đưới đây:

Nguồn [7]

Như vậy, một sản phẩm phần mềm được xem là một hệ thống bao gồm một hoặc nhiều phân hệ Mỗi phân hệ lại được xây dựng từ những cấu phần Mỗi cấu phần bao gồm các đơn vị nhỏ Các thành phần của phần mềm được liên kết với nhau thông qua các mối quan hệ và các tương tác [8] Vì vậy, việc mắc lỗi không chỉ xảy ra trong khi lập trình mà còn xảy ra cao hơn trong các công đoạn khác của quy trình phát triển một sản phẩm phần mềm Việc kiểm thử cũng vì thế phải được

tiến hành trong tất cả các phần tạo nên một sản phẩm phần mềm

y khi phần mềm hoạt động không như mong mu

i Tuy nhiên, cũng có thể dùng nhiều thuật ng thất bại, sai sót, có vấn đề, bất thường không h

i phần mềm dưới đây dựa trên khái niệm đặc t

ặc tính, quan hệ, chức năng và hành vi của s

n phần mềm hoặc giữa người phát triển phần m

ng phần mềmthông qua một ngôn ngữ nào đó [5],

ất hiện khi xảy ra một hay nhiều điều kiện sau [13]

ần mềm không thực hiện đúng những gì mà đặc tả định nghĩa

ần mềm thực hiện những gì mà đặc tả khuyến cáo không n

 Phần mềm không thực hiện những gì mà đặc tả không đề cập đến nhưng lẽ

ra nên thực hiện

 Phần mềm là khó hiểu hay khó sử dụng

Theo các kết quả nghiên cứu được thực hiện trong các dự án khác nhau, số

lỗi do đặc tả gây ra là nhiều nhất, chiếm khoảng 80% [12]

Các nguyên nhân sinh lỗi tại pha đặc tả:

 Đặc tả không hình thức: Ngôn ngữ tự nhiên dễ hiểu nhưng rườm rà,

 Yêu cầu đã thay đổi nhưng đặc tả không thay đổi

 Đặc tả khác nhau cho cùng một yêu cầu xuất hiện trong các cấu phần khác

nhau của hệ thống

Hình 1 2– Các nguyên nhân gây ra lỗi phần mềm [5]

Nguồn gây ra lỗi lớn thứ hai là thiết kế Đó là nền tảng mà lập trình viên dựa

vào để nỗ lực thực hiện kế hoạch cho phần mềm

Thời kỳ đầu, phát triển phần mềm thường đồng nhất với lập trình, công việc lập trình thì nặng nhọc, do đó lỗi do lập trình gây ra là chủ yếu [4] Ngày nay, công việc lập trình chỉ là một phần việc của quá trình lao động chất xám, việc lập trình trở nên nhẹ nhàng hơn, mặc dù độ phức tạp phần mềm lớn hơn rất nhiều Do đó, lỗi

do lập trình gây ra cũng ít hơn Tuy nhiên, nguyên nhân để lập trình tạo ra lỗi lại

nhiều hơn Đó là do độ phức tạp của phần mềm, do tài liệu nghèo nàn, do sức ép thời gian hoặc chỉ đơn giản là những lỗi “không nói lên được” [11] Một điều cũng khá hiển nhiên là nhiều lỗi xuất hiện trên văn bản chương trình, nhưng khi tìm hiểu

kỹ thì thực ra lại do lỗi của đặc tả hoặc thiết kế [10]

Một nguyên nhân khác tạo ra lỗi là do bản thân của công cụ phát triển phần mềm cũng có lỗi như công cụ trực quan, thư viện lớp, bộ biên dịch, các mẫu thường

được thiết kế theo xu hướng tổng quát hóa quá cao …

1.1.3 Chi phí sửa lỗi

Người ta ước tính, bảo trì là phần chi phí chính của phần mềm và kiểm thử là hoạt động có chi phí đắt thứ hai, ước tính khoảng 40% của chi phí trong quá trình phát triển ban đầu của sản phẩm phần mềm Kiểm thử cũng là phần chi phí chính của giai đoạn bảo trì do phải tiến hành kiểm thử lại những thay đổi trong quá trình sửa lỗi và đáp ứng yêu cầu của người dùng [1], [6]

Kiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng đời phần mềm Tuy nhiên, chi phí cho việc tìm và sửa lỗi sẽ tăng đáng kể theo thời gian trong quá trình phát triển [8]

Sự thay đổi một tài liệu hoặc yêu cầu (thí dụ, của khách hàng) khi đang trong pha thiết kế là không đắt nếu không nói là không đáng kể Chi phí sẽ tăng lên nhiều hơn nếu các yêu cầu thay đổi được đưa ra sau khi đã lập trình Thay đổi lúc này đồng nghĩa với việc phải viết lại chương trình [9]

Việc sửa lỗi sẽ không đáng kể nếu người lập trình tự phát hiện lỗi của mình,

và không có sự liên quan đến chi phí khác Họ không phải giải thích lỗi cho bất kỳ người nào trong nhóm Họ cũng không phải nhập lại lỗi đó vào cơ sở dữ liệu lỗi và lưu vết lỗi Người kiểm thử và người quản lý không phải duyệt lại tình trạng lỗi Và lỗi đó không ảnh hưởng đến công việc của người khác trong nhóm dự án

Nói chung, sửa một lỗi trước khi phát hành một phần mềm rẻ hơn rất nhiều

so với việc khắc phục nó sau khi đã phát hành [14], [15]

Theo các nghiên cứu của IBM, GTE cho biết, lỗi được phát hiện càng muộn thì chi phí cho việc sửa lỗi càng lớn Chi phí tăng theo hàm mũ như sau:

Hình 1.3 - Chi phí cho việc sửa lỗi Nguồn: [6], [8]

Chúng ta từng chứng kiến sự cố máy tính Y2K năm 2000 Nguyên nhân là

do việc tiết kiệm bộ nhớ bằng cách biểu diễn năm có 4 chữ số bằng 2 chữ số cuối của năm mà không dự tính được lỗi tiềm ẩn có thể xảy ra mà mấy chục năm sau, thế giới đã phải lo sợ và tốn nhiều tỉ đô la để khắc phục do dữ liệu ngày tháng có thể bị thay đổi khi máy tính coi năm 1900 như năm 2000 [1], [5]

1.1.4 Khái niệm kiểm thử phần mềm

Kiểm thử phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn phát triển phần mềm để đảm bảo rằng phần mềm thỏa mãn các yêu cầu thiết kế và các yêu cầu đó đáp ứng các nhu cầu của người dùng Các kỹ thuật kiểm thử phần mềm

đã, đang được nghiên cứu, và việc kiểm thử phần mềm đã trở thành quy trình bắt

buộc trong các dự án phát triển phần mềm trên thế giới

Kiểm thử phần mềm là khâu mấu chốt để đảm bảo chất lượng phần mềm, là

đánh giá cuối cùng về đặc tả thiết kế và mã hóa [7]

Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện ở thời điểm sớm nhất có thể và đảm bảo rằng lỗi đó đã được sửa Những người phát triển phần mềm và các kỹ sư kiểm thử cùng làm việc để phát hiện lỗi và đảm bảo chất

lượng sản phẩm Một sản phẩm phần mềm được phân phối phải có đầy đủ các chức

năng yêu cầu và tương thích với phần cứng của khách hàng

1.1.5 Những khó khăn của kiểm thử phần mềm

Để kiểm thử tốt hơn, cần phải quan tâm đến các yếu tố làm cho việc kiểm

thử khó khăn hơn

 Khó khăn liên quan đến quy trình phát triển phần mềm

Quá trình phát triển phần mềm là một tập hợp các hoạt động từ giai đoạn tìm hiểu, khảo sát, phân tích, thiết kế và cài đặt cho đến sử dụng và bảo trì Mỗi giai đoạn này thực ra là một sự chuyển đổi một tập hợp thông tin này sang một tập hợp thông tin khác Quá trình chuyển đổi này sẽ dẫn đến sự mất mát thông tin khó tránh khỏi, nghĩa là các lỗi sẽ xuất hiện Hơn nữa, các giai đoạn chuyển đổi có thể tạo nên một thất bại ở giai đoạn cuối cùng mà khi phát hiện lập trình viên khó có thể biết

được nguyên nhân do giai đoạn nào trước đó [10]

đó càng khó phát hiện và khó khắc phục Vì vậy, việc nghiên cứu các phương pháp

và công cụ phát triển thích ứng sẽ góp phần rất lớn vào việc giảm bớt các lỗi ngay

từ các giai đoạn đầu của quy trình phát triển [9]

1.1.6 Kiểm thử trong quy trình phát triển phần mềm

Để kiểm thử một sản phẩm phần mềm, chúng ta không chỉ kiểm thử một lần, khi mà nó đã được hoàn thành Các thành phần của phần mềm đều phải được kiểm thử trước, sau đó trong suốt quá trình tích hợp các thành phần cũng phải được kiểm thử cho đến khi đạt được sản phẩm cuối cùng

Có nhiều quy trình phát triển phần mềm được sử dụng Chúng khác nhau về bản chất, cách tiến hành, số giai đoạn phát triển, tuy nhiên chúng có những điểm chung sau trong hoạt động kiểm thử

 Kiểm thử đơn vị: tập trung trên mỗi module riêng biệt, đảm bảo rằng các

chức năng của nó tương ứng với một đơn vị

 Kiểm thử tích hợp: tập trung vào việc thiết kế và xây dựng kiến trúc

Kiểm thử đơn vị tập trung vào việc xác minh trên đơn vị nhỏ nhất của thiết

kế phần mềm Sử dụng các mô tả thiết kế thủ tục để hướng dẫn, theo dõi các đuờng dẫn điều khiển quan trọng và kiểm thử để phát hiện lỗi trong phạm vi module Độ phức tạp liên quan của các ca kiểm thử và lỗi đã phát hiện được giới hạn bởi ràng buộc phạm vi thiết lập cho kiểm thử đơn vị Kiểm thử đơn vị thường hướng hộp

trắng và các bước có thể được thực hiện song song trên nhiều module

Các kiểm thử nhằm phát hiện các lỗi trong các phạm vi của module bao gồm:

 Giao diện module

thiết kế các trường hợp kiểm thử đơn vị

Kiểm thử đơn vị được đơn giản hóa khi module có sự liên kết cao được thiết

kế Khi chỉ một chức năng được gọi bởi một module, số các trường hợp kiểm thử

được giảm xuống và các lỗi có thể dự đoán và phát hiện sớm hơn

Kiểm thử đơn vị thường do lập trình viên thực hiện Kiểm thử đơn vị đòi hỏi kiểm thử 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 thử đơn vị là đảm bảo thông tin được xử lý và xuất là chính xác, trong mối quan hệ

với dữ liệu nhập và chức năng của đơn vị [3], [4]

 Kiểm thử tích hợp

Mục tiêu của kiểm thử tích hợp nhằm thực hiện các lỗi tương tác giữa các đơn vị, tích hợp các đơn vị thành các hệ thống con vận hành tốt và cuối cùng hệ

thống hoàn toàn sẵn sàng cho kiểm thử hệ thống

Trong quá trình tích hợp, có thể có khả năng không chỉ tích hợp các đơn vị được phát triển trong dự án phần mềm, mà còn tích hợp các đơn vị hoặc thành phần được cung cấp bởi các thư viện hay thậm chí là các thành phần được cung cấp bởi

hệ điều hành

Kiểm thử tích hợp nên chỉ thực hiện với các đơn vị đã được thẩm định và đã được kiểm thử đơn vị thành công Sự tương tác và chức năng của đơn vị mới được

tích hợp và tập các đơn vị đã được tích hợp trước đó sẽ được kiểm thử

Hai chiến lược kiểm thử tích hợp cơ bản thường được áp dụng gồm:

 Tích hợp từ trên xuống : thực hiện kiểm thử các module chính trước, sau đó tích hợp thêm vào các module được gọi trực tiếp bởi các module vừa được kiểm thử

 Tích hợp từ dưới lên: tích hợp các thành phần cơ sở cung cấp các dịch vụ

chung như mạng, truy cập cơ sở dữ liệu, sau đó các thành phần chức năng được

gì mà người sử dụng mong đợi Vì thế, ở giai đoạn này, kiểm thử được thực hiện

dưới góc nhìn của người sử dụng, nên chỉ sử dụng các kĩ thuật kiểm thử chức năng

Kiểm thử hệ thống không chỉ nhằm đánh giá chức năng của hệ thống mà còn đánh giá các tính chất về chất lượng khác, như khả năng sử dụng, khả năng tin cậy, hiệu năng hay tính bảo mật…Tùy theo mỗi loại phần mềm và yêu cầu của phần mềm, các loại kiểm thử hệ thống khác nhau được áp dụng: kiểm thử giao diện, kiểm

thử hiệu năng, kiểm thử độ tin cậy, kiểm thử cấu hình, kiểm thử bảo mật…

Kiểm thử hệ thống nên được thực hiện trong môi trường như là môi trường

mà phần mềm sẽ hoạt động, vì đây là giai đoạn kiểm thử trước khi chuyển giao phần mềm cho người sử dụng để thực hiện kiểm thử chấp nhận Tuy nhiên điều này không phải lúc nào cũng thực hiện được, bởi vì chúng ta không thể có được môi trường sử dụng thực đối với một số phần mềm như phần mềm điều khiển hay phần mềm giao dịch tài chính…Trong trường hợp đó, thông thường chúng ta cần phải mô

phỏng môi trường thực để thực hiện kiểm thử

 Kiểm thử hồi quy

Quy trình phát triển phần mềm, mà trong đó bao gồm kiểm thử, không dừng lại một khi phần mềm đươc chuyển giao cho người sử dụng Bởi vì phần mềm là một trong những loại sản phẩm thay đổi rất nhanh Người sử dụng luôn có yêu cầu cải tiến phần mềm và bổ sung các chức năng mới hoặc sự không tương thích của phần mềm được tìm thấy khi đưa vào sử dụng Như thế, sự chỉnh sửa phần mềm sau khi đưa vào sử dụng là cần thiết Bất kì sự sửa đổi nào cũng có thể dẫn đến các lỗi mới Phần mềm nhất thiết phải được kiểm thử lại sau khi sửa đổi, giai đoạn này gọi

là kiểm thử hồi quy

Sau khi phân tích sự ảnh hưởng, chúng ta có thể thực hiện lại một số kiểm thử như kiểm thử đơn vị các thành phần bị sửa đổi, kiểm thử tích hợp có kích hoạt các

thành phần bị sửa đổi, kiểm thử hệ thống có kích hoạt các chức năng bị sửa đổi…

Như vậy, kiểm thử hồi quy có thể áp dụng ở kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống Để dễ dàng kiểm thử hồi quy chúng ta nên lưu trữ lại

môi trường kiểm thử, các trình điều khiển và các bộ dữ liệu thử…để tái sử dụng

 Kiểm thử chấp nhận

Kiểm thử chấp nhận không nhằm mục đích phát hiện lỗi mà nhằm giúp cho

người sử dụng đánh giá phần mềm so với mong đợi và mục tiêu của họ

Khi phát triển phần mềm cho một khách hàng cụ thể, kiểm thử chấp nhận cần phải được thực hiện sau kiểm thử hệ thống Phần mềm phải được thực thi trong môi trường thực Kiểm thử chấp nhận là một mốc quan trọng đối với người phát triển Tại thời điểm này, khách hàng sẽ quyết định phần mềm có đạt yêu cầu không Nếu khách hàng hài lòng về phần mềm, họ sẽ chấp nhận sản phẩm và bước tiếp theo

là cài đặt phần mềm tại môi trường của khách hàng

Nếu phần mềm được phát triển cho thị trường rộng lớn, thì kiểm thử cho mỗi khách hàng là không thực tế Trong trường hợp này, kiểm thử chấp nhận thường được chia làm hai giai đoạn:

 Kiểm thử alpha

Kiểm thử alphađược thực hiện trong môi trường phát triển Một nhóm những người sử dụng tiềm năng và thành viên nhóm phát triển được mời sử dụng phần mềm Các lập trình viên sẽ quan sát và ghi nhận các vấn đề xảy ra

 Kiểm thử beta

Kiểm thử beta gửi phần mềm đến những người sử dụng, họ cài đặt và sử dụng phần mềm trong môi trường làm việc thực tế Người sử dụng sẽ gửi các vấn

đề cho tổ chức phát triển và nhóm phát triển chịu trách nhiệm sửa các lỗi

1.2 CHẤT LƯỢNG VÀ CÁC TIÊU CHÍ ĐÁNH GIÁ PHẦN MỀM

1.2.1 Chất lượng phần mềm

Chất lượng trong phần mềm máy tính hiện vẫn còn là một vấn đề còn nhiều tranh luận Trong một số trường hợp, nói tới chất lượng phần mềm là nói tới tính thực tiễn và tính thẩm mỹ của phần mềm Ở đây, khái niệm này trả lời cho câu hỏi một chương trình máy tính thực thi một nhiệm vụ nào đó hiệu quả và có tính thẩm

mỹ tới mức nào Trong một ngữ cảnh khác, chất lượng phần mềm được hiểu là sự đáp ứng đến mức tối đa các yêu cầu đặt ra và không chứa lỗi Trong cả hai trường

hợp trên, có một loạt các vấn đề đặt ra cần giải quyết để đi đến một kết quả cuối cùng là phần mềm có chất lượng

1.2.2 Các tiêu chí đánh giá

Một số tiêu chí xác định chất lượng của một sản phẩm phần mềm [5]:

 Tính đúng: sản phẩm phần mềm đó thực thi đầy đủ và chính xác những yêu cầu đặc tả trong bản thiết kế

 Tính khoa học: giao diện được thiết kế hợp lý, gần với tư duy và kỳ vọng

tự nhiên của người sử dụng; các chức năng được sắp đặt khoa học, thể hiện logic của hệ thống; có thể di chuyển vị trí, thay đổi kích thước, màu sắc của các giao diện, kiểu văn bản, hình vẽ, đồ thị, bảng biểu,…

 Tính dễ sử dụng: Sau một vài lần thực thi phần mềm, người sử dụng có thể nhớ được một cách logic trình tự làm việc Phần mềm có tính năng trợ giúp người sử dụng đúng lúc và đúng chỗ Các thao tác nhanh chóng, rõ ràng, dễ theo dõi Làm việc lâu với phần mềm không gây cảm giác khó chịu

 Tính tương tác: Phần mềm có thể tương tác với các hệ thống khác, ví dụ:

 Có thể đọc các file định dạng khác

 Có thể chuyển, nhận và hiểu được các thông điệp, dữ liệu trao đổi qua lại

với các hệ thống khác hiện đang tồn tại trên thị trường

 Tính độc lập: Phần mềm có thể làm việc bình thường trong các môi trường khác nhau, với các hệ điều hành và chủng loại máy khác nhau

 Tính vững vàng: Khi xảy ra các sự cố khách quan hoặc chủ quan phần mềm nhận biết và xử lý, không bị treo, bị liệt hoặc gây ra các hiệu quả nghiêm trọng

 Tính dễ phát triển và hoàn thiện: Khi công nghệ phát triển, nhiều phần mềm phải thiết kế lại từ đầu, kể cả việc phải chọn môi trường và công cụ phát triển mới Một phần mềm được coi là dễ phát triển và hoàn thiện nếu nó thích ứng được

với những thay đổi trong yêu cầu của khách hàng cũng như nền tảng kĩ thuật

1.3 QUY TRÌNH KIỂM THỬ PHẦN MỀM

Mục đích của cuộc kiểm thử chính là thiết kế được một chuỗi các trường hợp kiểm thử mà có khả năng phát hiện lỗi cao Chuỗi các trường hợp kiểm thử đó sẽ rà soát hết tất cả các trường hợp có thể xử lý của chương trình so với đặc tả ban đầu Báo cáo kiểm thử sẽ thống kê hết tất cả các trường hợp kiểm thử đã chạy, những lỗi

đã phát hiện trong kiểm thử, chi tiết các dữ liệu đầu vào, các luồng dữ liệu, đầu ra mong đợi của chương trình (đây chính là kết quả đúng của chương trình), kết quả thực tế cho ra của chương trình và mục đích kiểm thử…Muốn có được các dữ liệu đầu vào hợp lý và có khả năng phát hiện lỗi cao như vậy thì cần phải thông qua một

kế hoạch và giai đoạn chuẩn bị hợp lý nhằm thiết kế các Testcase, các dữ liệu cho các trường hợp kiểm thử Các giai đoạn kiểm thử này có thể được mô tả qua hình vẽ sau:

Kế hoạch kiểm thử

Kiểm thử

Như vậy mô hình chi tiết quá trình kiểm thử như sau:

Hình 1 5 -Quy trình chi tiết quá trình kiểm thử

1.4 TỰ ĐỘNG HÓA KIỂM THỬ

Kiểm thử phần mềm tốn nhiều chi phí nhân công, thời gian Trong một số dự

án, chi phí kiểm thử phần mềm chiếm 50% tổng giá trị của dự án Nếu cần ứng

dụng quan trọng hơn, chi phí kiểm thử còn cao hơn nữa

Do đó một trong các mục tiêu của kiểm thử là tự động hóa nhiều, nhờ đó mà giảm thiểu chi phí, giảm lỗi, đặc biệt giúp việc kiểm thử hồi quy dễ dàng và nhanh

Chạy chương trình với dữ liệu kiểm thử

So sánh các kết quả với các trường hợp kiểm thử

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

Dữ liệu kiểm thử

Kết quả kiểm thử

Báo cáo kết quả cuối cùng

Bàn giao SP

Kiểm thử tự động là quá trình thực hiện một cách tự động các bước trong một kịch bản kiểm thử Kiểm thử tự động bằng một công cụ nhằm rút ngắn thời

Thiết kế giải pháp kiểm thử tự động

Phát triển giải pháp kiểm thử tự

Triển khai giải pháp kiểm thử tự

Đánh giá kiểm thử

tự động

CHƯƠNG 2 CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM 2.1.NGUYÊN TẮC CƠ BẢN CỦA KIỂM THỬ PHẦN MỀM

Các nguyên tắc luôn đóng vai trò quan trọng trong lĩnh vực công nghệ phần mềm Các nguyên tắc trong công nghệ phần mềm là các luật hay các quy tắc hướng dẫn làm thế nào để xây dựng (thiết kế, phát triển, kiểm thử và bảo trì) phần mềm Kiểm thử là một trong những lĩnh vực khó kiểm soát của đảm bảo chất lượng phần mềm, kiểm thử cũng có các nguyên tắc riêng dành cho các kiểm thử viên Các nguyên tắc này giúp cho kiểm thử viên xác định cách kiểm thử một phần mềm cũng như thực hiện công việc kiểm thử một cách chuyên nghiệp Chúng ta xem xét một

số nguyên tắc cơ bản [11], [12] liên quan đến kiểm thử động nghĩa là kiểm thử yêu cầu thực thi phần mềm

2.1.1.Các đặc trưng của kiểm thử phần mềm

 Đặc trưng 1: Kiểm thử là quy trình thực thi phần mềm và sử dụng các ca

kiểm thử để phát hiện lỗi

Mặc dù công nghệ phần mềm đã có rất nhiều cải tiến trong các phương pháp phát triển để hạn chế và loại bỏ lỗi Tuy nhiên, lỗi vẫn luôn xuất hiện và có các ảnh hưởng xấu đến chất lượng phần mềm Kiểm thử viên cần xác định các lỗi này trước khi phần mềm được sử dụng Không nên lên một kế hoạch kiểm thử nhằm chứng minh rằng lỗi không tồn tại

 Đặc trưng2: Với mục đích của kiểm thử nhằm phát hiện lỗi, một ca kiểm

thử tốt là ca kiểm thử có khả năng phát hiện những lỗi chưa được tìm thấy

Nguyên tắc này cung cấp cách để đánh giá sự hiệu quả một ca kiểm thử Khi thiết kế, kiểm thử viên phải xác định mục tiêu rõ ràng của mỗi ca kiểm thử, tức là nhằm phát hiện các loại lỗi gì Sau đó kiểm thử viên thực hiện lựa chọn bộ dữ liệu thử, kịch bản kiểm thử và thực thi phần mềm để kiểm thử Kết quả kiểm thử sẽ cho kiểm thử viên khẳng định mục tiêu của ca kiểm thử

 Đặc trưng3: Một ca kiểm thử phải định nghĩa kết quả mong đợi

Một ca kiểm thử phải chứa dữ liệu thử Tuy nhiên, một ca kiểm thử sẽ không

có giá trị nếu chúng ta bỏ quên kết quả mong đợi tương ứng với dữ liệu thử Định nghĩa kết quả mong đợi sẽ cho phép kiểm thử viên xác định có lỗi hay không có lỗi

và việc kiểm thử thành công hay thất bại Việc đặc tả dữ liệu thử và kết quả tương ứng là phải được thực hiện trong quá trình thiết kế các ca kiểm thử

 Đặc trưng4: Kiểm thử nên được thực hiện bởi một nhóm độc lập với

nhóm phát triển

Về mặt tâm lí, rất khó để các lập trình viên chấp nhận rằng phần mềm do mình làm ra bị lỗi Họ luôn tránh tìm ra lỗi, bởi vì họ ngại sự đánh giá thấp từ đồng nghiệp hay cấp trên Ngoài ra, một vấn đề khác rất thực tế là: chương trình có thể chứa lỗi do sự hiểu biết không chính xác về đặc tả hay mô tả bài toán của lập trình viên Trong trường hợp này, dường như rằng lập trình viên sẽ mang luôn cả sự hiểu không chính xác đó vào trong kiểm thử chương trình Như vậy, lỗi sẽ rất khó được phát hiện Tuy nhiên, nguyên tắc này không có nghĩa là những lập trình viên không thể kiểm thử chương trình của họ, mà đúng hơn là kiểm thử sẽ hiệu quả hơn khi được thực hiện bởi những người khác

 Đặc trưng5: Kết quả kiểm thử nên được phân tích một cách cẩn thận

Đây là nguyên tắc rất cơ bản, nhưng thường không được đánh giá đúng dẫn đến không phát hiện được lỗi hoặc làm xuất hiện các lỗi khác Chẳng hạn:

 Một lỗi bị bỏ qua hay coi nhẹ, khi đó việc kiểm thử sẽ được coi là không phát hiện lỗi, tuy nhiên thực tế thì lỗi tồn tại Kiểm thử sẽ được tiếp tục dựa trên kết quả không chính xác trước đó, có thể trong các bước kiểm thử sau lỗi sẽ được phát hiện Trong trường hợp đó việc định vị lỗi và sửa lỗi sẽ trở nên khó khăn hơn

 Một lỗi có thể bị nghi ngờ là tồn tại, tuy nhiên thực tế thì lỗi không tồn tại Trong trường hợp đó, chúng ta sẽ có thể mất nhiều thời gian và công sức để tìm và xác định lỗi

 Đặc trưng6: Các ca kiểm thử nên được thiết kế cho cả những dữ liệu vào

hợp lệ hay không hợp lệ

Kiểm thử một phần mềm thường chỉ chú ý đến các tập dữ liệu vào hợp lệ, tức là các tập dữ liệu vào đúng như đặc tả Trong thực tế, dữ liệu vào có thể không hợp lệ bởi vì nhiều lí do khác nhau Hơn nữa, các dữ liệu không hợp lệ còn cho phép đánh giá được khả năng bền vững của phần mềm, nghĩa là hoạt động của phần mềm khi có sự kiện không mong đợi xuất hiện Ngoài ra, các ca kiểm thử với các

dữ liệu vào không hợp lệ thường có khả năng phát hiện lỗi tốt hơn các ca kiểm thử với các dữ liệu vào hợp lệ

 Đặc trưng7: Các ca kiểm thử phải được tái sử dụng

Các ca kiểm thử nên được lưu giữ sau mỗi kiểm thử Vì sau khi kiểm thử, phần mềm chứa lỗi, cần thực hiện sửa lỗi Phần mềm sau đó sẽ được kiểm thử lại hay kiểm thử hồi quy Nếu không lưu lại các ca kiểm thử thì cần phải xây dựng lại Việc xây dựng lại các ca kiểm thử luôn yêu cầu mất nhiều thời gian, nên đôi khi kiểm thử lại bị bỏ quên

 Đặc trưng8: Xác suất tồn tại của các lỗi khác nữa trong một đơn vị phần

mềm tỉ lệ với các số lỗi đã được phát hiện trong đơn vị phần mềm đó

Nguyên tắc này nói rằng, nếu một đơn vị phần mềm với một số lượng lớn các lỗi đã được phát hiện, thì khi tiếp tục thực hiện kiểm thử khả năng xác định được nhiều lỗi hơn nữa là rất cao Thực tế, các lỗi thường xuất hiện trong các đơn vị phần mềm có độ phức tạp cao và được thiết kế không tốt Khi đó, cần phải tiếp tục thực hiện kiểm thử nhiều hơn đối với các đơn vị phần mềm có xu hướng lỗi này

 Đặc trưng9: Kiểm thử cần được lập kế hoạch

Kế hoạch kiểm thử nên được mô tả chi tiết ở mỗi giai đoạn kiểm thử Kế hoạch kiểm thử với các mục tiêu xác định nhằm đảm bảo phân phối hợp lí về mặt thời gian cũng như tài nguyên kiểm thử và đảm bảo kiểm thử được giám sát và quản lí

 Đặc trưng10: Các hoạt động kiểm thử nên phải được tích hợp vào quy

trình phát triển phần mềm

Hoạt động kiểm thử không chỉ được thực hiện sau khi đã có mã nguồn mà cần phải được thực hiện sớm hơn trong các giai đoạn phát triển, như giai đoạn phân tích, đặc tả và thiết kế Các hoạt động kiểm thử phải được thực hiện xuyên suốt trong quá trình phát triển cho đến khi sản phẩm được giao cho người sử dụng

 Đặc trưng11: Kiểm thử là một công việc đầy sáng tạo và thách thức

Đối với các phần mềm phức tạp, yêu cầu sáng tạo trong kiểm thử thậm chí còn vượt cả yêu cầu sáng tạo trong thiết kế

2.1.2 Luồng thông tin kiểm thử

Hình 2.1 thể hiện luồng thông tin kiểm thử Hiện có hai quan điểm về xử lí

lỗi Quan điểm thứ nhất là “Mỗi lần chỉ bắt một lỗi”, sau khi xử lí xong lỗi sẽ tiếp tục kiểm thử để bắt lỗi khác, nếu có Quan điểm thứ hai là “Mỗi lần bắt và thông báo toàn bộ các lỗi” Theo quan điểm này có thể nảy sinh một số khó khăn cho lập

trình viên gỡ lỗi: một lỗi B có thể là hậu quả của lỗi A trước đó Mô hình này được thiết kế độc lập với hai quan điểm trên Cụ thể là mô hình chỉ dựa vào tập các test cases do người phụ trách kiểm thử xây dựng

Hình 2 1 - Mô hình luồng thông tin kiểm thử

Hai kiểu đầu vào được cung cấp cho tiến trình kiểm thử:

Cấu hình phần mềm gồm: bản đặc tả yêu cầu phần mềm, bản đặc tả thiết kế

và mã nguồn của chương trình

Cấu hình kiểm thử gồm: kế hoạch và thủ tục kiểm thử, công cụ kiểm thử,

trường hợp kiểm thử và kết quả dự kiến

Cấu hình phần mềm

Kiểm thử

Cấu hình kiểm thử

Kết quả kiểm thử Đánh

giá

Gỡ rối

Mô hình tin cậy Kết quả mong đợi

Tất cả các kết quả kiểm thử đều được đánh giá bằng cách so sánh với kết quả

dự kiến, nếu có sai khác thì đó có thể là lỗi

Các kết quả kiểm thử sẽ xác định chất lượng và độ tin cậy của phần mềm

2.1.3 Thiết kế trường hợp kiểm thử

Thiết kế các trường hợp kiểm thử (đầu vào và đầu ra) được sử dụng để kiểm thử hệ thống Mục đích của thiết kế trường hợp kiểm thử là tạo ra một tập hợp các mẫu kiểm thử có khả năng đánh giá hiệu quả, phát hiện khiếm khuyết, chi phí rẻ đồng thời tốn ít thời gian và công sức nhất Thực tế, kiểm thử “vét cạn” là điều không thể, và như vậy, kiểm thử một chương trình phải luôn xác định là không thể

“vét cạn” Vấn đề quan trọng là cố gắng làm giảm sự “không thể vét cạn” nhiều

 Biết cách hoạt động bên trong của sản phẩm, kiểm thử có thể được thực

hiện để đảm bảo rằng “tất cả các phần mềm ăn khớp nhau”: Kiểm thử hộp trắng

chức năng của hộp đen được đặc tả rõ ràng qua các đầu vào và đầu ra

Kiểm thử chức năng chỉ dựa vào đặc tả phần mềm để tạo ra các ca kiểm thử

Vì vậy, kiểm thử chức năng có hai ưu điểm nổi bật:

 Các ca kiểm thử độc lập với việc phần mềm được cài đặt như thế nào, nghĩa là cấu trúc bên trong của phần mềm Như thế, khi cài đặt phần mềm thay đổi, các ca kiểm thử vẫn được sử dụng

 Các ca kiểm thử có thể được thiết kế trước khi cài đặt phần mềm Ca kiểm thử được tạo ra ngay khi có đặc tả yêu cầu

Ngoài ra, kiểm thử hộp đen có các đặc điểm khác:

 Hiệu quả trong việc tìm lỗi, đặc biệt phù hợp tìm các lớp lỗi về thiết kế, nghĩa là lỗi do những người thiết kế, người đặc tả tạo ra

 Chi phí thấp so với kĩ thuật kiểm thử cấu trúc trong việc thiết kế các ca kiểm thử

 Dễ dàng áp dụng và áp dụng phổ biến, khi chỉ dựa trên đặc tả yêu cầu và có

thể được áp dụng cho tất cả các hoạt động kiểm thử (đơn vị, tích hợp và hệ thống)

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

Phân lớp tương đương là một phương pháp kiểm thử hộp đen chia miền đầu vào của một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử Phương pháp này cố gắng xác định ra một ca kiểm thử mà làm lộ ra một lớp lỗi, do

đó làm giảm tổng số các trường hợp kiểm thử phải được xây dựng

Thiết kế ca kiểm thử cho phân lớp tương đương dựa trên sự đánh giá về các lớp tương đương với một điều kiện vào Lớp tương đương biểu thị cho tập các trạng thái hợp lệ hay không hợp lệ đối với điều kiện đầu vào Để xác định tập con các dữ liệu này, mỗi dữ liệu kiểm thử được lựa chọn nên có hai tính chất sau:

 Dữ liệu kiểm thử giảm số lượng các dữ liệu thử khác cần tạo ra nhằm đạt được mục tiêu kiểm thử xác định trước

 Dữ liệu kiểm thử bao phủ một tập gồm nhiều dữ liệu thử khác, nghĩa là dữ liệu thử này cho chúng ta biết sự hiện diện của lỗi ứng với tập các dữ liệu thử

Hai tính chất mà một dữ liệu kiểm thửcầnđáp ứng tạo nên kĩ thuật kiểm thử, được gọi là kiểm thử lớp tương đương Có ba loại kiểm thử lớp tương đương:

 Kiểm thử lớp tương đương yếu: xây dựng các ca kiểm thử bởi sử dụng một giá trị từ mỗi lớp tương đương Như thế, chúng ta sẽ có số ca kiểm thử bằng số lớp tương đương của biến vào có nhiều lớp tương đương nhất

 Kiểm thử lớp tương đương mạnh: xây dựng các ca kiểm thử dựa trên tích Đề-các của các lớp tương đương Kiểm thử này bao phủ hết tất cả các lớp tương

đương Tập các ca kiểm thử bao gồm tất cả các kết hợp giá trị dữ liệu đại diện của các lớp tương đương

 Kiểm thử lớp tương đương truyền thống: phân biệt các lớp tương đương hợp lệ và không hợp lệ Đối với dữ liệu vào hợp lệ, sử dụng một giá trị đại diện cho mỗi lớp tương đương (tương tự kiểm thử lớp tương đương yếu).Tất cả các dữ liệu vào của các ca kiểm thử này đều hợp lệ Đối với dữ liệu vào không hợp lệ, một ca kiểm thử chỉ có một dữ liệu không hợp lệ, các dữ liệu còn lại đều hợp lệ

 Xác định lớp tương đương

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

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

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 tập giá trị (a,b), 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ệ Ví dụ: nếu đầu vào x nằm trong khoảng (0, 100), lớp hợp lệ là 0 < x < 100, hai lớp không hợp lệ là

4 Nếu đầ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 và false

Ngoài ra, chúng ta có thể sử dụng khả năng phán đoán, kinh nghiệm và trực

giác của người kiểm thử

 Xác định các trường hợp kiểm thử

Với các lớp tương đương xác định ở trên, bước thứ hai là sử dụng các lớp

tương đương đó để xác định các ca kiểm thử Quá trình này như sau:

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

 Đến khi tất cả các lớp tương đương hợp lệ được bao 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ủ

 Đế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 bao phủ

 Lý do mà mỗi ca kiểm thử riêng bao phủ các trường hợp không hợp lệ là

vì các kiểm tra đầu vào không đúng nào đó che giấu hoặc thay thế các kiểm thử đầu

Các lớp tương đương không hợp lệ

Số ID của sinh

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

 Ví dụ minh họa

Giả sử ta có chương trình tính hoa hồng cho một đại lí bán xe máy Cách tính hoa hồng dựa trên doanh thu như sau: đại lí được nhận 10% số doanh thu bán hàng đến 1 tỉ đồng; 15% số doanh thu bán hàng 500 triệu đồng tiếp theo; 20% số doanh thu bán hàng vuợt quá 1 tỉ 500 triệu đồng Miền dữ liệu đầu vào của chương trình

có thể được chia thành các lớp tương đương bằng cách dựa vào các giới hạn của hai biến đầu vào: số lượng xe sirius và số lượng xe Jupiter Bởi vì dữ liệu vào thuộc một khoảng, vì vậy chúng ta thiết kế một lớp tương đương hợp lệ và hai lớp tương đương không hợp lệ cho mỗi biến (Bảng 2.3)

Bảng 2 3 – Các lớp tương đương cho chương trình tính hoa hồng

Biến vào Lớp tương đương Ghi chú

#Sirius

1 #Sirius  100 Giá trị hợp lệ

#Sirius < 1 Giá trị không hợp lệ

#Sirius > 100 Giá trị không hợp lệ

#Jupiter

1  #Jupiter  50 Giá trị hợp lệ

#Jupiter < 1 Giá trị không hợp lệ

#Jupiter > 50 Giá trị không hợp lệ

Nếu áp dụng kiểm thử tương đương yếu, chúng ta có các ca kiểm thử trong Bảng 2.4

Bảng 2 4 – Các ca kiểm thử lớp tương đương yếu

cho chương trình tính hoa hồng

Ca KT #Sirius #Jupiter Doanh thu(triệu) Hoa Hồng(triệu)

Nếu áp dụng kiểm thử lớp tương đương truyền thống, chúng ta có các ca kiểm thử trong Bảng 2.5

Mặc dù việc phân lớp tương đương rất tốt khi lựa chọn ngẫu nhiên các ca kiểm thử, nhưng nó vẫn có những thiết sót Ví dụ, nó bỏ qua các kiểu test case có lợi nào đó Hai phương pháp tiếp theo, phân tích giá trị biên và đồ thị nguyên nhân – kết quả, bao phủ được nhiều những thiếu sót này

Bảng 2 5 – Kiểm thử lớp tương đương cho chương trình tính hoa hồng

Đối với chương trình này, ba số nguyên đầu vào có mối quan hệ phụ thuộc chặt chẽ với nhau Vì vậy, chúng ta xây dựng lớp tương đương dựa vào quan hệ ràng buộc giữa chúng Chúng ta có thể xác định lớp tương đương trong Bảng 2.6

Bảng 2 6 – Các lớp tương đương cho chương trình tam giác dựa vào dữ liệu vào

5 a ≠ c, a ≠ b, b ≠ a Tam giác thường

Dựa trên các lớp tương đương này, chúng ta thiết kế ca kiểm thử trong Bảng 2.7

Bảng 2 7 – Các ca kiểm thử cho chương trình tam giác dựa trên dữ liệu vào

2.2.2 Phân tích giá trị biên

Kiểm thử giá trị biên là một trong những kĩ thuật kiểm thử chức năng được

áp dụng rộng rãi và hiệu quả Kĩ thuật này tạo ra các ca kiểm thử bởi việc phân tích miền dữ liệu vào Kinh nghiệm của những người phát triển phần mềm cho thấy rằng các lỗi thường do chương trình không được đặc tả các hành vi đối với các giá trị biên (giá trị lớn nhất, giá trị không hay âm đối với chỉ số, chuỗi kí tự rỗng, hay các

dữ liệu không hợp lệ) Các giá trị biên được xác định dựa vào miền giá trị của các biến đầu vào

Phân tích các giá trị biên là phương pháp thiết kế ca kiểm thử bổ sung thêm cho phân lớp tương đương, nhưng khác với phân lớp tương đương ở hai khía cạnh:

Phân tích giá trị biên không lựa chọn phần tử bất kỳ nào trong một lớp tương đương là điển hình, mà nó yêu cầu là một hay nhiều phần tử được lựa chọn như vậy

mà mỗi cạnh của lớp tương đương đó chính là đối tượng kiểm tra

Ngoài việc chỉ tập trung chú ý vào các trạng thái đầu vào (không gian đầu vào), các ca kiểm thử cũng nhận được bằng việc xem xét không gian kết quả (các lớp tương đương đầu ra)

Phân tích giá trị biên yêu cầu sáng tạo và lượng chuyên môn hóa nhất định

và nó là một quá tình mang tính kinh nghiệm rất cao Tuy nhiên, có một số quy tắc

chung như sau:

 Nếu điều kiện đầu vào xác định một khoảng giá trị (a,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

 Nếu đ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 gía 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ử

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

 Nếu cấu trúc dữ liệu chương trình bên trong được quy đị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

Ví dụ: Chương trình đào tạokỹ sư Công nghệ thông tin chất lượng cao của một Trường Đại học tuyển chọn mỗi năm 20 sinh viên Đầu năm học mới, sinh viên nộp hồ sơ đăng kí vào học Trường chỉ nhận 200 hồ sơ nộp sớm nhất và sau đó chọn

20 sinh viên có hồ sơ tốt nhất Mỗi hồ sơ được đánh gía dựa trên điểm thi trong kì thi tuyển sinh đại học toàn quốc Mỗi sinh viên có điểm thi ba môn: Toán, Vật lí và Hóa học Điểm mỗi môn học thuộc khoảng 0 đến 10, điểm có thể lẻ 0.5 Tổng điểm

của mỗi sinh viên được tính theo công thức:

Tổng điểm = điểm Toán x 3 + điểm Vật lí x 2 + điểm Hóa học x 1

Sau đó, chọn 20 sinh viên có tổng điểm cao nhất