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

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ầnmề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ẫuthường được thiết kế theo xu hướng tổn

ĐẠI HỌC THÁI NGUYÊN

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

NGUYỄN THỊ TÍNH

CÁC PHƯƠNG PHÁP ĐÁNH GIÁ CHẤT LƯỢNG PHẦN MỀM

LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH

Thái Nguyên- 2016

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ếtquả 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àikhá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 ii

MỤC LỤC iv

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

DANH MỤC BẢNG BIỂU vii

ĐẶT VẤN ĐỀ viii

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

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

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

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

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

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

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]

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

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

Hình 1 4 - Các giai đoạn kiểm thử

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ĐẶT VẤN ĐỀ

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 tinnó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àycàng gánh trách nhiệm thêm nặng nề và chuyên nghiệp Tuy nhiên thực tế đã chothấ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ểnkhai ứ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ầnmề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ườidù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ộctrong 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ạnphá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 độngnhằ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ượngphầ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.

LUẬN VĂN Mục đích chính của luận

 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

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ệutham 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ầnmề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 đánhgiá 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ầnmề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ệnmộ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 độngkinh 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

Thập kỉ 1970Thập kỉ 1980Thập kỉ 1990

1960-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ộthoặ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ấuphầ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ớinhau 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ôngchỉ 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ủaquy 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 đượctiế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

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

[13] 1.1.2 Khái niệm lỗi phần mềm

Chúng ta đã thấy khi phần mềm hoạt động không như mong muốn thì ta nói

rằng phần mềm đó có lỗi Tuy nhiên, cũng có thể dùng nhiều thuật ngữ khác để mô

tả hiện tượng này như: thất bại, sai sót, có vấn đề, bất thường không hợp lý, không tương thích,…

Định nghĩa lỗi phần mềm dưới đây dựa trên khái niệm đặc tả: một đặc tảlàmột sự thống nhất về đặc tính, quan hệ, chức năng và hành vi của sản phẩm giữanhững người phát triển phần mềm hoặc giữa người phát triển phần mềm và ngườiđặt hàng hoặc sử dụng phần mềmthông qua một ngôn ngữ nào đó [5], [8], [10]

Lỗi phần mềm xuất hiện khi xảy ra một hay nhiều điều kiện sau [13], [14], [15]:

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

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

 Phần mềm thực hiện những gì mà đặc tả không đề cập đế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ẽ ranên thực hiện.

 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ựavà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ệclậ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ôngviệc lập trình chỉ là một phần việc của qúa trình lao động chất xám, việc lập trìnhtrở 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 épthờ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ũngkhá 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ầnmề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ẫuthườ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ìnhphá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ínhcủ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ìnhsử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ờigian 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 trongpha 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ềuhơ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ộnthì 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à doviệ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ủană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áttriể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ácyê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ắtbuộ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ểnphầ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ứcnă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ìmhiể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ợpthô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ánhkhỏ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ênmộ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]

Thông thường, kiểm thử thường chỉ được coi là giai đoạn đơn giản cuốicùng được dùng để hợp thức hóa sản phẩm Vì thế, nhiều lỗi nghiêm trọng mắc phảingay từ các giai đoạn đầu của quy trình phát triển (đặc tả và thiết kế) Trong khi đó,nhiều thống kê cho thấy: các lỗi mắc phải càng sớm trong quy trình phát triển, thìcác lỗi đó càng khó phát hiện và khó khắc phục Vì vậy, việc nghiên cứu cácphươ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ớtcá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ểmthử 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ểmthử 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

 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 phần

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ờngdẫ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àngbuộc phạm vi thiết lập cho kiểm thử đơn vị Kiểm thử đơn vị thường hướng hộptrắ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.

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ỏikiể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ủakiểm thử đơn vị là đảm bảo thông tin được xử lý và xuất là chính xác, trong mốiquan hệ với dữ liệu nhập và chức năng của đơn vị [3], [4].

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 đượctí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 thêmvào

Trong thực tế, với rất nhiều hệ thống, chiến lược tích hợp là sự pha trộn các phương pháp trên [11]

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ầnmề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 giaophầ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àykhô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ôitrườ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ầnmề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ử

Quy trình phát triển phần mềm, mà trong đó bao gồm kiểm thử, không dừnglạ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ầucả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ủaphầ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ềmsau 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áclỗ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àygọ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ácthà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íchhợ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ạimô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

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

Kiểm thử alphađược thực hiện trong môi trường phát triển Một nhómnhữ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ụngphầ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

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.

 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ệclâ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,

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ợpkiể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áocá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áthiệ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 đợicủ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 racủ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ểmthử Các giai đoạn kiểm thử này có thể được mô tả qua hình vẽ sau:

Phân tích

Hình 1 4 - Các giai đoạn kiểm thử

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

Phân tích Thiết kế

Mã hóa Kiểmthử

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ả thử

kiểm Báo cáo kết

quả cuối cùng

Bàn giao SP

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 ứngdụ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à nhanhchóng hơn

Tự động hóa việc kiểm thử là dùng phần mềm điều khiển việc thi hành kiểmthử, so sánh kết quả có được với kết quả mong muốn, thiết lập các điều kiện đầuvào, các kiểm sóat kiểm thử và các chức năng báo cáo kết quả…

Kiểm thử tự động là quá trình thực hiện một cách tự động các bước trongmộ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ờigian kiểm thử [8].

Để thực hiện kiểm thử tự động, quy trình kiểm thử phải hỗ trợ tốt các hoạtđộng kiểm thử tự động và phát triển các giải pháp tự động Các bước cơ bản củaquy trình kiểm thử tự động được minh họa trong Hình 1.6

Lập kế hoạch kiểm thử tự động

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ầnmề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ướngdẫ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ầnmề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ácnguyê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ũngnhư 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êucầu thực thi phần mềm

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

 Nguyên tắc 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ápphá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 ảnhhưở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àytrướ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ằmchứng minh rằng lỗi không tồn tại

 Nguyên tắc 2: 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ử Khithiế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ệuthử, 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ẽ chokiểm thử viên khẳng định mục tiêu của ca kiểm thử

 Nguyên tắc 3: 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ử Địnhnghĩ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ử

 Nguyên tắc 4: 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 domì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ừ đồngnghiệ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ìnhviê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ểukhông chính xác đó vào trong kiểm thử chương trình Như vậy, lỗi sẽ rất khó đượcphá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ôngthể 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

 Nguyên tắc 5: 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.

 Nguyên tắc 6: 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ônghợ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 chophé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ầnmề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ệ

 Nguyên tắc 7: 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ạihay 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 khikiểm thử lại bị bỏ quên

 Nguyên tắc 8: 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áclỗ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ềulỗ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ểmthử nhiều hơn đối với các đơn vị phần mềm có xu hướng lỗi này

 Nguyên tắc 9: 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ạchkiể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 giancũ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í

 Nguyên tắc 10: 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ântí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ốttrong quá trình phát triển cho đến khi sản phẩm được giao cho người sử dụng.

Đố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 đượcthiế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 testcases do người phụ trách kiểm thử xây dựng

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

Kiểm thử

Cấu hình kiểm thử

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

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ểmthử 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ácmẫ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ềukhô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ềunhất có thể

Bất kể phần mềm nào cũng đều có thể kiểm thử theo một trong hai phươngthức tiếp cận:

 Biết về các đặc tả bên ngoài của sản phẩm hoặc chương trình: Kiểm thử

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 đầuvà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áclớ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áctrạ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 concá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ụngmộ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

đươ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 đươnghợ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 chomỗ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ệuvà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 cakiể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ệ

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ộttậ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 đầuvà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ệnlogic

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 đầuvà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à

x  0 và x  100

2 Nếu điều kiện đầu vào là một giá trị xác định, thì phân hoạch thành mộtlớp tương đương hợp lệ và hai lớp tương đương không hợp lệ Ví dụ, đầu vào x=3,lớp hợp lệ là x=3, hai lớp không hợp lệ là x < 3 và x > 3

3 Nếu đầu vào xác định một phần tử của tập hợp, thì phân hoạch thành mộtlớp tương đương hợp lệ và một lớp tương đương không hợp lệ Ví dụ, X là tập số

tự nhiên lẻ, lớp hợp lệ là “X là số tự nhiên lẻ”, lớp không hợp lệ là “X là số

tự nhiên chẵn”.

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

 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

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

123

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

Ví dụ 2: Chương trình tam giác nhận đầu vào gồm ba số nguyên a, b và c,

chúng được xem là độ dài ba cạnh của một tam giác Chương trình xác định loại tam

giác bằng cách dựa vào độ dài ba cạnh: tam giác đều (ba cạnh bằng nhau), tam giác cân

(chỉ hai cạnh bằng nhau), tam giác thương (độ dài ba cạnh khác nhau) và không phải là

tam giác (có ít nhất một cạnh lớn hơn hoặc bằng tổng hai cạnh còn lại)

Đố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

STT

1234

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

Ca KT

12345678

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íchmiề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ấyrằ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, haycá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ủacá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 chophâ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 đầuvà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áclớ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ắcchung 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ẳnghạ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ủamộ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ênnộ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 thitrong 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