Luận án Tiến sĩ: Kiểm thử dựa trên mô hình với cách tiếp cận mô hình hóa chuyên biệt miền

Luận án này trình bày một số phương pháp cho phép sinh tự động các ca kiểm thử chức năng mức hệ thống từ các ca sử dụng áp dụng các kỹ thuật kiểm thử dựa trên mô hình với hướng tiếp cận mô hình hóa chuyên biệt miền (Domain Specific Modeling DSM). Cụ thể, luận án quan tâm đến phương pháp đặc tả rõ ràng các ca sử dụng và các ca kiểm thử bằng các mô hình trong các ngôn ngữ mô hình hóa chuyên biệt miền và phương pháp chuyển tự động các mô hình ca sử dụng sang mô hình ca kiểm thử trong các ngôn ngữ đặc tả chuyên biệt miền

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Chu Thị Minh Huệ

KIỂM THỬ DỰA TRÊN

MÔ HÌNH VỚI CÁCH TIẾP

CẬN MÔ HÌNH HÓA

CHUYÊN BIỆT MIỀN

LUẬN ÁN TIẾN SỸ CÔNG NGHỆ THÔNG TIN

Hà Nội - 2019

Tôi xin cam đoan luận án “Kiểm thử dựa trên mô hình với

cách tiếp cận mô hình hóa chuyên biệt miền” là công trình nghiên

cứu của riêng tôi Các số liệu, kết quả được trình bày trong luận án là hoàntoàn trung thực và chưa từng được công bố trong bất kỳ một công trìnhnào khác

 Tôi đã trích dẫn đầy đủ các tài liệu tham khảo, công trình nghiên cứuliên quan ở trong nước và quốc tế Ngoại trừ các tài liệu tham khảonày, luận án hoàn toàn là công việc của riêng tôi

 Trong các công trình khoa học được công bố trong luận án, tôi đã thểhiện rõ ràng và chính xác đóng góp của các đồng tác giả và những gì

do tôi đã đóng góp

 Luận án được hoàn thành trong thời gian tôi làm Nghiên cứu sinh tại

Bộ môn Công nghệ phần mềm, Khoa Công nghệ Thông tin, TrườngĐại học Công nghệ, Đại học Quốc gia Hà Nội

Tác giả:

Hà Nội:

i

Trước hết, tôi muốn bày tỏ sự biết ơn đến PGS TS Nguyễn Ngọc Bình

và TS Đặng Đức Hạnh, cán bộ hướng dẫn, các thầy đã trực tiếp giảng dạy

và định hướng tôi trong suốt thời gian học cao học, thực hiện luận văn thạc

sĩ cũng như luận án này Một vinh dự lớn cho tôi được học tập, nghiên cứudưới sự hướng dẫn của các Thầy

Tôi xin bày tỏ sự biết ơn sâu sắc đến các Thầy Cô trong Bộ mônCông nghệ phần mềm vì sự giúp đỡ của các Thầy Cô về các đóng góp rấthữu ích cho luận án

Tôi xin trân trọng cảm ơn Khoa Công nghệ thông tin, Phòng Đàotạo và Ban giám hiệu trường Đại học Công nghệ đã tạo điều kiện thuận lợicho tôi trong suốt quá trình thực hiện luận án

Tôi cũng bày tỏ sự biết ơn đến Trường Đại học Sư phạm Kỹ thuậtHưng Yên đã tạo điều kiện về thời gian và tài chính cho tôi thực hiện luận

án này Tôi muốn cảm ơn đến Ban chủ nhiệm, các cán bộ, giảng viên KhoaCông nghệ thông tin - Trường Đại học Sư phạm Kỹ thuật Hưng Yên đã cổ

vũ động viên và sát cánh bên tôi trong suốt quá trình nghiên cứu

Tôi muốn cảm ơn đến tất cả những người bạn của tôi, nhữngngười luôn chia sẻ, động viên tôi bất cứ khi nào tôi cần và tôi luôn ghi nhớđiều đó

Cuối cùng, tôi xin bày tỏ lòng biết ơn vô hạn đối với cha mẹ,chồng, con và gia đình đã luôn ủng hộ và yêu thương tôi một cách vô điềukiện Nếu không có sự ủng hộ của gia đình và chồng con tôi không thể hoànthành được luận án này

ii

TÓM TẮT

Luận án này trình bày một số phương pháp cho phép sinh tự độngcác ca kiểm thử chức năng mức hệ thống từ các ca sử dụng áp dụng các kỹthuật kiểm thử dựa trên mô hình với hướng tiếp cận mô hình hóa chuyên

biệt miền (Domain Specific Modeling - DSM ) Cụ thể, luận án quan tâm

đến phương pháp đặc tả rõ ràng các ca sử dụng và các ca kiểm thử bằngcác mô hình trong các ngôn ngữ mô hình hóa chuyên biệt miền và phươngpháp chuyển tự động các mô hình ca sử dụng sang mô hình ca kiểm thửtrong các ngôn ngữ đặc tả chuyên biệt miền Các đóng góp chính của luận

án như sau

Đề xuất ngôn ngữ USL (Use Case Specification Language) để đặc tả

rõ ràng các ca sử dụng, hướng đến khả năng sinh tự động các chế tác phần

mềm (software artifacts) khác nhau trong quy trình phát triển phần mềm

bằng các chuyển đổi mô hình Ngôn ngữ được xây dựng với cách tiếp cận

mô hình hóa chuyên biệt miền

Xây dựng ngôn ngữ TCSL (Test Case Specification Language) để đặc

tả rõ ràng các ca kiểm thử Ngôn ngữ được xây dựng với cách tiếp cận môhình hóa chuyên biệt miền

Đề xuất một phương pháp USLTG (USL-based Test Generation) để

sinh tự động các ca kiểm thử từ ca sử dụng bằng cách chuyển đổi tự độngcác mô hình USL vào trong một mô hình TCSL

Xây dựng bộ công cụ hỗ trợ USL để hiện thực hóa những đề xuất củaluận án Bộ công cụ hỗ trợ USL cho phép tích hợp ngôn ngữ USL vào trongphương pháp phát triển phần mềm hướng mô hình Cụ thể, bộ công cụ cungcấp trình soạn thảo để tạo các mô hình USL một các trực quan và cung cấpcác bộ sinh tự động các chế tác khác nhau từ mô hình Trọng tâm chính củaluận án này là sinh các ca kiểm thử tự động từ các mô hình USL Ngoài ra,luận án cũng trình bày các ví dụ nghiên cứu được áp dụng cho các phươngpháp của luận án, cung cấp các đánh giá của ngôn ngữ USL với các ngônngữ đặc tả khác, và so sánh phương pháp USLTG với một số phương phápsinh ca kiểm thử từ ca sử dụng khác

Từ khóa: ca sử dụng, ca kiểm thử, sinh ca kiểm thử tự động, mô hình

hóa chuyên biệt miền, USL, TCSL, USLTG

Lời cam đoan i

1.1 Đặt vấn đề 1

1.2 Mục tiêu nghiên cứu và các đóng góp chính của luận án 5

1.3 Cấu trúc luận án 9

Chương 2 KIẾN THỨC CƠ SỞ 11 2.1 Kiểm thử dựa trên ca sử dụng 11

2.1.1 Kiểm thử phần mềm 11

2.1.2 Ca sử dụng 22

2.1.3 Xây dựng các ca kiểm thử từ ca sử dụng 25

2.2 Mô hình hóa chuyên biệt miền 27

2.2.1 Một số khái niệm cơ bản 27

2.2.2 Phương pháp xây dựng DSML 28

2.2.3 Xây dựng DSML trong Eclipse 31

2.3 Chuyển đổi mô hình 32

2.3.1 Chuyển đổi mô hình sang mô hình 32

iv

2.3.2 Chuyển đổi mô hình sang văn bản 34

2.4 Ngôn ngữ ràng buộc đối tượng OCL 38

2.4.1 Cơ bản về OCL 38

2.4.2 Công cụ hỗ trợ OCL 41

2.5 Tổng kết chương 46

Chương 3 ĐẶC TẢ CA SỬ DỤNG THEO HƯỚNG MÔ HÌNH HÓA CHUYÊN BIỆT MIỀN 47 3.1 Giới thiệu 47

3.2 Các nghiên cứu liên quan 49

3.3 Xác định miền cho ngữ cảnh đặc tả ca sử dụng 52

3.4 Cú pháp của USL 58

3.4.1 Cú pháp trừu tượng của USL 58

3.4.2 Các luật hợp lệ trên siêu mô hình của USL 62

3.4.3 Cú pháp cụ thể của USL 66

3.5 Ngữ nghĩa hình thức của mô hình USL 69

3.6 Chuyển đổi mô hình USL 76

3.6.1 Sinh các ca kiểm thử 76

3.6.2 Sinh các mô hình cấu trúc và mô hình hành vi 77

3.6.3 Sinh TUCDs 78

3.7 Tổng kết chương 81

Chương 4 PHƯƠNG PHÁP SINH TỰ ĐỘNG CÁC CA KIỂM THỬ TỪ MÔ HÌNH CA SỬ DỤNG VÀ MÔ HÌNH KHÁI NIỆM MIỀN CỦA HỆ THỐNG 82 4.1 Giới thiệu 82

4.2 Các nghiên cứu liên quan 85

4.3 Tổng quan phương pháp đề xuất 88

4.4 Ngôn ngữ đặc tả các ca kiểm thử TCSL 89

4.4.1 Xác định miền cho ngữ cảnh đặc tả ca kiểm thử chức năng 90

4.4.2 Định nghĩa siêu mô hình TCSL 92

4.5 Chuyển đổi mô hình từ USL sang TCSL 96

4.5.1 Xác định tiêu chí phủ 96

4.5.2 Sinh các kịch bản ca sử dụng và các ràng buộc 97

4.5.3 Sinh các bộ dữ liệu đầu vào kiểm thử 101

4.5.4 Sinh mô hình TCSL 106

4.6 Tổng kết chương 109

5.1 Giới thiệu 111

5.2 Công cụ hỗ trợ USL 112

5.3 Ví dụ minh họa 115

5.4 Đánh giá 122

5.4.1 Đánh giá ngôn ngữ USL 122

5.4.2 Đánh giá phương pháp sinh các ca kiểm thử USLTG 129 5.5 Tổng kết chương 133

Chương 6 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 134 6.1 Các đóng góp của luận án 135

6.2 Hướng phát triển 137

Từ viết tắt Dạng đầy đủ Diễn giải

Language

gán nhãn

vii

NTD Navigational Development Các kỹ thuật phát triển

Language

Language

USLTG USL-based Test Generation Sinh kiểm thử dựa trên

mô hình USLXML eXtensible Markup Language Ngôn ngữ đánh dấu mở rộng

2.1 Một mẫu mô tả ca sử dụng 24

2.2 Các kịch bản của ca sử dụng Đăng nhập 25

2.3 Các ca kiểm thử cho ca sử dụng Đăng nhập 26

2.4 Các ca kiểm thử của ca sử dụng Đăng nhập với các giá trị xác

định 26

3.1 Mô tả của ca sử dụng Lend book 54

3.2 Các ký hiệu đồ họa của các khái niệm trong mô hình USL 66

3.3 Danh sách các hàm được định nghĩa trong D 72

3.4 Ngữ nghĩa dựa trên LTS của các khái niệm USL cơ bản 74

4.1 Hai ca kiểm thử của ca sử dụng Lend book 91

5.4 Các ca kiểm thử được sinh của ca sử dụng Lend book 120

5.5 So sánh khả năng diễn tả giữa các ngôn ngữ đặc tả ca sử dụng124

5.6 Số các kịch bản được sinh trong một số nghiên cứu 130

5.7 Sự so sánh các thông tin được xác định và ngôn ngữ đặc tảkiểm thử của các phương pháp 131

ix

1.1 Ngữ cảnh nghiên cứu, phương pháp thực hiện, và các đóng

góp của luận án 6

1.2 Cấu trúc luận án 9

2.1 Các pha kiểm thử và phát triển trong mô hình chữ V [50] 14

2.2 Quy trình kiểm thử dựa trên mô hình [9] 16

2.3 Các ví dụ của biểu đồ hoạt động với các cấu trúc lặp [39] 19

2.4 Ví dụ của biểu đồ hoạt động có chứa các hành động đồng thời [39] 21

2.5 Biểu đồ ca sử dụng của hệ thống đăng ký khóa học đơn giản 22 2.6 Các luồng sự kiện trong một ca sử dụng [26] 23

2.7 Một ví dụ về siêu mô hình 29

2.8 Các kiểu chuyển mô hình: (a) chuyển ngoại sinh và (b) chuyển nội sinh [9] 33

2.9 Một phần siêu mô hình của sWML và MVC [9] 33

2.10 Các mẫu, máy mẫu, và mô hình nguồn để cung cấp văn bản [9] 35 2.11 Các ca sử dụng thẩm định và kiểm chứng [18] 42

2.12 Đầu vào và đầu ra của các ca sử dụng [18] 42

2.13 Biểu đồ đối tượng OMfull 45

3.1 Mô hình ca sử dụng đơn giản và mô hình các khái niệm của hệ thống Library 52

3.2 Biểu đồ hoạt động đặc tả luồng điều khiển của ca sử dụng Lend book. 56

3.3 Siêu mô hình USL 59

3.4 Ví dụ thể hiện của siêu mô hình USL 60

3.5 Đặc tả ca sử dụng Lend Book bằng một mô hình USL. 68

3.6 Một snapshot của ca sử dụng Lend Book. 75

3.7 Tệp TUCD được sinh của ca sử dụng Lend book. 80

x

4.1 Tổng quan của cách tiếp cận USLTG 88

4.2 Siêu mô hình của TCSL 93

4.3 Lưu đồ thuật toán của Thủ tục GenerateScenarios. 100

4.4 Lưu đồ thuật toán của Thuật toán GenTestInputData. 104

4.5 Biểu đồ lớp mô hình các khái niệm của hệ thống Library và biểu đồ các đối tượng 105

4.6 Lưu đồ thuật toán của Thuật toán GenTCSLModel. 107

4.7 Các ca kiểm thử trong Bảng 4.1 được đặc tả trong mô hình TCSL 108

5.1 Các thành phần chính của công cụ USL 112

5.2 Kiến trúc của bộ sinh USLTG 114

5.3 Giao diện công cụ hỗ trợ USL 114

5.4 Mô hình USL của ca sử dụng Withdraw. 116

5.5 Mô tả theo mẫu được sinh của ca sử dụng Withdraw. 117

5.6 Biểu đồ lớp của ATM và một hình chụp hệ thống 118

4.1 GenScenarios 98

4.2 GenTestInputData 102

4.3 GenTCSLModel 106

xii

2.1 Ví dụ một chương trình chuyển trong ATL [9] 34

2.2 Ví dụ một chương trình chuyển trong Acceleo [9] 37

2.3 Ví dụ mô hình Employee trong môi trường đặc tả dựa trên UML 39

2.4 Mô hình lớp CM trong công cụ USE 43

2.5 Tệp cấu hình CONF 44

2.6 Các ràng buộc bất biến INVS 44

2.7 Các đối tượng và liên kết đã được xác định trong biểu đồ lớp OMpartial 44

3.1 Chuyển USL2TUCD 79

3.2 Chuyển libraryUCD 80

5.1 Tệp XML lưu mô hình TCSL của ca sử dụng Withdraw 121

xiii

MỞ ĐẦU

Ngày nay, các hệ thống phần mềm càng ngày càng trở nên phức tạp vàđược ứng dụng rộng rãi trong hầu hết lĩnh vực của đời sống xã hội Để tăngtính cạnh tranh của các sản phẩm phần mềm, chi phí phát triển phần mềmcần phải được cắt giảm trong khi chất lượng phần mềm phải được nâng

cao Kiểm thử phần mềm (software testing) là một hoạt động quan trọng

để đảm bảo chất lượng phần mềm Hoạt động này chiếm nhiều thời gian

và chi phí trong phát triển phần mềm thường từ 30-60% [71] Khi kiểm thử

một ứng dụng, các kiểm thử viên sẽ xây dựng các ca kiểm thử (test cases)

dựa trên tài liệu đầu vào, sau đó khi có chương trình phần mềm thì thựcthi các ca kiểm thử thủ công hoặc tự động bằng các công cụ thực thi kiểmthử tự động

Trong thực tế, các yêu cầu phần mềm thường hay thay đổi trong suốtquy trình phát triển phần mềm Khi các yêu cầu phần mềm thay đổi, các cakiểm thử liên quan phải được xây dựng và thực thi lại (kiểm thử hồi quy)

Vì vậy, những nỗ lực được yêu cầu để xác định, bảo trì, và thực thi các cakiểm thử khi các yêu cầu thay đổi là rất lớn Đối với hoạt động kiểm thửphần mềm, giải pháp sinh và thực thi các ca kiểm thử một cách tự độnggiúp tiết kiệm rất nhiều thời gian và các nỗ lực cũng như giảm được sốlượng các lỗi và các sai sót trong hoạt động kiểm thử phần mềm Do đó,nhiều nghiên cứu đã đề xuất các giải pháp tăng tính tự động trong pháttriển phần mềm cũng như hoạt động kiểm thử phần mềm

1

Hiện tại trong thực tế, kiểm thử tự động tập trung vào thực thi kiểmthử tự động, còn vấn đề sinh các ca kiểm thử tự động chưa được giải quyếttriệt để Trong các quy trình kiểm thử phần mềm, quy trình kiểm thử dựa

trên mô hình (Model-Based Testing - MBT ) đẩy mạnh mức độ tự động hóa

cao hơn [71] Quy trình này không chỉ tự động hóa trong thực thi kiểm thử

mà còn tự động hóa trong sinh các ca kiểm thử Lợi ích chính của MBT làtạo điều kiện thuận lợi cho việc duy trì bộ kiểm thử và phủ của bộ kiểmthử Khi tiến hóa phần mềm, các mô hình được cập nhật, sau đó bộ kiểmthử được sinh cập nhật một cách tự động Với ý nghĩa to lớn của MBTtrong công nghiệp phần mềm, phương pháp này đang là một giải pháp tối

ưu giúp tăng tính tự động, tăng năng suất, tăng chất lượng, và giảm chiphí trong phát triển phần mềm nói chung và trong kiểm thử nói riêng Quytrình MBT gồm năm bước chính là (1) mô hình hóa, (2) sinh các ca kiểm

thử, (3) sinh các tập lệnh thực thi kiểm thử (test scripts), (4) thực thi kiểm

thử, (5) phân tích các ca kiểm thử được minh họa như Hình 2.2 Trong đó,

ba bước cuối cùng đã được giải quyết rất tốt bằng các công cụ thực thi kiểmthử tự động thương mại hoặc miễn phí trên thị trường Hai bước đầu tiên

là (1) mô hình hóa và (2) sinh các ca kiểm thử còn gặp nhiều thách thứcvới cộng đồng nghiên cứu

Trong hoạt động kiểm thử phần mềm, các yêu cầu chức năng (functional

software requirements) của phần mềm là đầu vào để xây dựng các ca kiểm

thử chức năng Các yêu cầu chức năng phần mềm thường được cấu trúc vàbiểu diễn bằng các ca sử dụng Một mô hình ca sử dụng thường được đặc

tả bằng các biểu đồ ca sử dụng và các mô tả của các ca sử dụng ở dạngvăn bản có cấu trúc theo mẫu [53] Với dạng thể hiện này thì mô hình ca

sử dụng sẽ tạo điều kiện thuận lợi cho các bên liên quan trong phát triểnphần mềm dễ dàng đọc, học, và sử dụng chúng Tuy nhiên, các mô tả ca sửdụng trong ngôn ngữ tự nhiên là rất khó để xác định tự động các thông tinđược mô tả trong nó Vì vậy, bài toán sinh các ca kiểm thử chức năng tựđộng từ mô hình ca sử dụng vẫn còn rất nhiều thách thức

Nhiều nghiên cứu như trong [7, 11, 23, 24, 41, 43, 51, 58, 65, 67, 73] đãchỉ dẫn các cách tiếp cận để sinh tự động các ca kiểm thử từ mô hình ca sửdụng Một số nghiên cứu như trong [58, 73] đã đề xuất phương pháp sinh tựđộng các ca kiểm thử chức năng từ các đặc tả ca sử dụng trong ngôn ngữ tựnhiên theo mẫu với các luật hạn chế và các từ khóa Để sinh tự động được

các ca kiểm thử, đầu tiên các nghiên cứu này sử dụng kỹ thuật xử lý ngônngữ tự nhiên để sinh các mô hình trung gian Sau đó, các mô hình trunggian này được sử dụng để sinh các ca kiểm thử Tuy nhiên, các ngôn ngữđược sử dụng để đặc tả trong các nghiên cứu này là các ngôn ngữ không

hình thức (informal) (không có cú pháp trừu tượng) Vì vậy, việc đảm bảo

tính đúng đắn của các đặc tả cũng như sinh các mô hình trung gian phải

sử dụng các kỹ thuật xử lý ngôn ngữ tự nhiên vốn khó và chỉ được áp dụngcho một ngôn ngữ cụ thể Hơn nữa, các ràng buộc được mô tả trong ngônngữ tự nhiên nên muốn sinh được dữ liệu kiểm thử cần phải đặc tả chínhxác lại các ràng buộc này

Nhiều nghiên cứu đề xuất sử dụng biểu đồ hoạt động và tuần tự trongUML để đặc tả các thông tin mô tả trong ca sử dụng, sau đó sinh các cakiểm thử như trong [24, 51, 67] Tuy nhiên, các nghiên cứu này chủ yếu tậptrung đề xuất phương pháp để đặc tả phân biệt được hành động của tácnhân và hệ thống bằng các biểu đồ trong UML cho mục đích sinh các cakiểm thử trừu tượng (kịch bản kiểm thử) mà không đề cập đến sinh tự động

dữ liệu cụ thể cho các ca kiểm thử

Một số nghiên cứu khác đã đề xuất cách tiếp cận sinh tự động các cakiểm thử chức năng từ các mô hình ca sử dụng được đặc tả trong các ngôn

ngữ chuyên biệt miền (Domain-Specific Language - DSL) Như nghiên cứu

trong [23], các mô tả của ca sử dụng được đặc tả trong ngôn ngữ chuyên

biệt miền tên là NDT (Navigational Development Techniques) được đề xuất

trong [16] Tuy nhiên, nghiên cứu không đề cập đến phương pháp xác địnhcác giá trị kiểm thử cho các kịch bản kiểm thử Trong nghiên cứu [65], các mô

tả ca sử dụng được đặc tả trong ngôn ngữ RSL (Requirements Specification

Language) đã được đề xuất trong [63] để sinh các ca kiểm thử chức năng.Các ca kiểm thử được sinh cũng được đặc tả rõ ràng trong ngôn ngữ đặc tả

kiểm thử tên là TSL (Test Specification Language) Tuy nhiên trong nghiên

cứu này, dữ liệu kiểm thử được xác định như các mô tả về điều kiện thay

vì là các giá trị cụ thể

Như đã phân tích ở trên để sinh tự động các ca kiểm thử chức năng từ

mô hình ca sử dụng, đầu tiên các nghiên cứu đề xuất sử dụng một ngônngữ đặc tả để đặc tả các thông tin mô tả trong ca sử dụng Sau đó, cácnghiên cứu sử dụng các đặc tả này để sinh tự động các ca kiểm thử Trongquá trình khảo sát các phương pháp đặc tả các thông tin mô tả trong ca

sử dụng, luận án nhận thấy rằng mô hình ca sử dụng là chế tác (artifact)

trung tâm trong phát triển phần mềm Các mô hình ca sử dụng không chỉ

là đầu vào để xây dựng các ca kiểm thử chức năng mà còn là đầu vào đểxây dựng các mô hình cấu trúc (biểu đồ lớp, biểu đồ trạng thái, v.v.), các

mô hình hành vi (biểu đồ tuần tự, biểu đồ hoạt động, v.v.), và làm tài liệucho hệ thống Để tăng tính tự động hóa trong phát triển phần mềm, các môhình ca sử dụng không chỉ cần được tích hợp vào phương pháp kiểm thửhướng mô hình mà cũng cần được tích hợp vào trong phương pháp phát

triển hướng mô hình (Model-Driven Development - MDD) MDD cho phép

sử dụng mô hình ca sử dụng là mô hình trung tâm để sinh tự động các cakiểm thử, các mô hình cấu trúc, các mô hình hành vi Vì vậy, các ca sửdụng cần được đặc tả rõ ràng và đủ các thông tin cần thiết để sinh tự độngcác chế tác khác nhau trong phát triển phần mềm Trong các nghiên cứu

mà luận án đã khảo sát, có hai nghiên cứu đã đề xuất các ngôn ngữ đặc

tả RSL [63] và SelabReq [59] với mục đích cho phép tích hợp đặc tả ca sửdụng vào trong phương pháp phát triển hướng mô hình Tuy nhiên, thôngtin mô tả trong các ca sử dụng được đặc tả trong RSL không đủ chi tiết

để sinh được dữ liệu kiểm thử cụ thể như trong nghiên cứu [65] đã đề cập

ở trên Ngôn ngữ SelabReq chỉ đề cập đến khả năng sinh các mô hình cấutrúc và mô hình hành vi mà không đề cập đến việc sinh các ca kiểm thử

Mặc dù đã có nhiều nghiên cứu quan tâm giải quyết bài toán sinh các

ca kiểm thử chức năng từ mô hình ca sử dụng, cũng như bài toán đặc tảthông tin mô tả trong ca sử dụng để tích hợp vào trong phương pháp pháttriển hướng mô hình Tuy nhiên, bài toán này vẫn còn một số thách thứcđặt ra như sau: thách thức thứ nhất là một ngôn ngữ đặc tả chuyên biệtmiền cho phép đặc tả các thông tin trong ca sử dụng rõ ràng và đủ chi tiết

để có thể tích hợp mô hình ca sử dụng vào trong phương pháp phát triểnhướng mô hình Việc tích hợp mô hình ca sử dụng vào trong phương phápphát triển hướng mô hình cho phép sinh tự động các ca kiểm thử, mô hìnhcấu trúc, mô hình hành vi, và làm tài liệu Cụ thể trong luận án này, chúngtôi tập trung vào hiện thực hóa khả năng sinh tự động các ca kiểm thử.Thách thức thứ hai là một phương pháp sinh tự động các ca kiểm thử cóchứa các thông tin cần thiết để có thể sinh và thực thi tự động các tập lệnhthực thi kiểm thử bằng các công cụ thực thi kiểm thử tự động Thách thứcthứ ba là một ngôn ngữ đặc tả chuyên biệt miền để đặc tả rõ ràng và đầy

đủ các thông tin của các ca kiểm thử được sinh Thách thức cuối cùng làmột công cụ đủ tốt cho phép tích hợp ca sử dụng vào trong phương phápphát triển phần mềm hướng mô hình cho mục đích sinh tự động các chế tácphần mềm khác nhau từ mô hình ca sử dụng, trong đó có sinh tự động các

ca kiểm thử chức năng

Để giải quyết các thách thức ở trên, luận án hướng đến giải quyết bàitoán trong ngữ cảnh phát triển hướng mô hình và tập trung vào sinh tựđộng các ca kiểm thử chức năng từ các ca sử dụng theo phương pháp kiểmthử dựa trên mô hình Đầu tiên, luận án đề xuất phương pháp đặc tả rõràng các thông tin mô tả trong ca sử dụng và các ca kiểm thử bằng cách

tiếp cận mô hình hóa chuyên biệt miền (Domain-Specific Modeling - DSM ).

Sau đó, luận án đề xuất phương pháp sinh tự động các ca kiểm thử từ ca

sử dụng Cuối cùng, luận án xây dựng các công cụ hỗ trợ cho các phươngpháp đã đề xuất để cho phép tích hợp ca sử dụng vào trong phương phápphát triển hướng mô hình và đánh giá các phương pháp đã đề xuất với cácphương pháp hiện tại khác

Đối tượng nghiên cứu của luận án là các mô hình ca sử dụng, các ca kiểmthử chức năng, và phương pháp xác định các ca kiểm thử chức năng từ ca

sử dụng, phương pháp tự động hóa trong kiểm thử phần mềm áp dụng chokiểm thử chức năng Để thực hiện mục tiêu sinh tự động các ca kiểm thửchức năng từ các ca sử dụng, luận án sử dụng phương pháp kiểm thử dựatrên mô hình với hướng tiếp cận mô hình hóa chuyên biệt miền

của luận án

Mục tiêu của luận án là đặt ca sử dụng vào trong ngữ cảnh của quytrình kiểm thử dựa trên mô hình Điều này cho phép tự động hóa hoạt độngkiểm thử chức năng mà đầu vào là các yêu cầu chức năng của phần mềm.Hình 1.1 minh họa tổng quan nghiên cứu của luận án Trong đó, các Bước(1) mô hình hóa, Bước (2) sinh các ca kiểm thử, Bước (3) sinh các tập lệnhthực thi kiểm thử, Bước (4) thực thi kiểm thử, và Bước 5 phân tích các cakiểm thử là năm bước chính trong quy trình kiểm thử dựa trên mô hình.Luận án tập trung vào hai bước đầu tiên còn nhiều thách thức trong quy

trình kiểm thử dựa trên mô hình cho bài toán kiểm thử chức năng từ các

ca sử dụng là Bước (1) mô hình hóa các yêu cầu và Bước (2) sinh các cakiểm thử tự động Các Bước (3), (4), (5) đã được cung cấp đầy đủ bởi cáccông cụ thực thi kiểm thử tự động được triển khai rộng rãi trong thực tế

Để đạt được mục đích tự động hóa hoàn toàn, các ca kiểm thử được sinhtrong Bước (2) cần chứa đầy đủ các thông tin cần thiết để là đầu vào choBước (3) sinh và Bước (4) thực thi tự động các tập lệnh thực thi kiểm thửbằng các công cụ thực thi kiểm thử tự động Ngoài ra mục tiêu hướng tớicủa luận án là không chỉ đặt ca sử dụng vào trong ngữ cảnh của quy trìnhkiểm thử dựa trên mô hình mà còn đặt ca sử dụng trong ngữ cảnh pháttriển hướng mô hình nói chung Mục đích này cho phép sinh tự động cácđầu ra khác nhau từ mô hình ca sử dụng như các ca kiểm thử, các mô hìnhcấu trúc, các mô hình hành vi, cũng như sử dụng làm tài liệu đặc tả yêucầu phần mềm Để giải quyết bài toán này, luận án đã đạt được bốn đónggóp chính như được thể hiện trong phần phía trên của Hình 1.1

Hình 1.1: Ngữ cảnh nghiên cứu, phương pháp thực hiện, và các

đóng góp của luận án

Thứ nhất, luận án đề xuất một phương pháp đặc tả ca sử dụng với cách

tiếp cận mô hình hóa chuyên biệt miền Để thực hiện mục tiêu này, luận

án đề xuất ngôn ngữ đặc tả chuyên biệt miền cho ca sử dụng tên là USL

(Use case Specification Language) với cú pháp trừu tượng, cú pháp cụ thể,

và tập các luật ràng buộc trên cú pháp trừu tượng Để cung cấp một ngữnghĩa thực thi cho ngôn ngữ, luận án ánh xạ một mô hình USL sang một hệthống chuyển trạng thái được gán nhãn Sự khác biệt của phương pháp đềxuất đối với các nghiên cứu trước đây thể hiện ở khả năng đặc tả rõ ràng

và đủ các thông tin mô tả về cấu trúc và hành vi trong ca sử dụng bằng cáckhái niệm chuyên biệt cho miền ca sử dụng Vì vậy, USL đem lại khả năngtích hợp ca sử dụng vào trong phương pháp phát triển hướng mô hình và

dễ hiểu với các bên liên quan phi kỹ thuật (non-technical stakeholders).

Thứ hai, luận án đề xuất một phương pháp đặc tả ca kiểm thử Để thực

hiện ý tưởng này, luận án tiến hành khảo sát miền đặc tả các ca kiểm thửchức năng Các thông tin cần thiết để các ca kiểm thử chức năng để có thể

là đầu vào cho các công cụ kiểm thử tự động sinh và thực thi tự động cáctập lệnh thực thi kiểm thử Kế tiếp, luận án đề xuất ngôn ngữ đặc tả chuyên

biệt miền tên là TCSL (Test Case Specification Language) với cú pháp trừu

tượng và tập các luật ràng buộc hợp lệ Sự khác biệt của phương pháp đã đềxuất với các nghiên cứu trước đây là ngôn ngữ TCSL cho phép đặc tả thôngtin của các ca kiểm thử rõ ràng và chi tiết hơn cho mục đích sử dụng là đầuvào để sinh và thực thi tự động các tập lệnh thực thi kiểm thử Ngôn ngữcho phép đặc tả các thông tin như các bước kiểm thử, đối tượng kiểm thử,

hành động trên đối tượng kiểm thử, loại điểm kiểm tra (checkpoint type),

dữ liệu đầu vào, dữ liệu đầu ra mong đợi, tiền và hậu điều kiện của các cakiểm thử Trong khi các ngôn ngữ đặc tả ca kiểm thử của các nghiên cứukhác chỉ đặc tả bước kiểm thử và dữ liệu kiểm thử Ngoài ra, dữ liệu kiểmthử được xác định dựa vào trạng thái bên trong của hệ thống trước khi ca

sử dụng được thực thi Tuy nhiên, không có ngôn ngữ đặc tả ca kiểm thửnào đã được đề xuất đặc tả các trạng thái bên trong của hệ thống trước khithực hiện kiểm thử, trong khi thông tin này được TCSL đặc tả

Thứ ba, luận án đề xuất phương pháp USLTG (USL-based Test

Gene-ration) để chuyển tự động từ các mô hình ca sử dụng trong USL, và mô hình lớp các khái niệm miền của hệ thống sang mô hình đặc tả ca kiểm thử TCSL Tại mức kiểm thử hệ thống, các yêu cầu chức năng phần mềm được

sử dụng là đầu vào để xác định các ca kiểm thử chức năng Để sinh tự độngcác ca kiểm thử từ ca sử dụng, các thông tin mô tả trong các ca sử dụngđược đặc tả rõ ràng bằng các mô hình USL Sau đó, các mô hình USL nàykết hợp với mô hình lớp đặc tả các khái niệm miền của hệ thống được sửdụng là đầu vào để sinh các kịch bản, các trạng thái bên trong hệ thốngtrước khi ca sử dụng được thực hiện, và các dữ liệu kiểm thử Cuối cùng,các thông tin của các ca kiểm thử đã được sinh được chuyển vào trong một

mô hình TCSL Sự khác biệt của phương pháp đã đề xuất đối với các nghiêncứu trước đây thể hiện, thông tin các ca kiểm thử chức năng được xác định

đủ chi tiết và rõ ràng để có thể là đầu vào cho các công cụ thực thi kiểmthử tự động có thể sinh và thực thi tự động các tập lệnh thực thi kiểm thử

Cụ thể thông tin các ca kiểm thử được xác định gồm: các bước kiểm thử,kiểu của bước kiểm thử, hành động và đối tượng của bước kiểm thử, trạngthái bên trong của hệ thống, dữ liệu kiểm thử cụ thể Trong khi các nghiêncứu khác chỉ xác định được thông tin mô tả các bước kiểm thử và dữ liệukiểm thử ở dạng mô tả Hơn nữa, các ca kiểm thử được sinh được đặc tả rõràng bằng một mô hình trong TCSL Điều này tạo điều kiện thuận lợi đểthực thi và chuyển đổi giữa các định dạng khác nhau của các ca kiểm thử

Cuối cùng, luận án xây dựng bộ công cụ hỗ trợ USL Công cụ này cho

phép tích hợp ca sử dụng vào trong phương pháp phát triển hướng mô hình.Công cụ gồm một trình soạn thảo các mô hình USL và các bộ sinh tự độngcác chế tác khác nhau từ các mô hình USL Trong phạm vi luận án, luận

án tập trung xây dựng bộ sinh tự động các ca kiểm thử từ mô hình USL

và một bộ công cụ chuyển các mô hình USL sang dạng mô tả ca sử dụngtheo mẫu trong ngôn ngữ tự nhiên để làm tài liệu cho đặc tả phần mềm

Để minh chứng khả năng ứng dụng USL vào trong thực tế, luận án cũngtrình bày các kết quả khi áp dụng USL cho một số ca sử dụng Ngoài ra,luận án cũng đưa ra các đánh giá, so sánh phương pháp đặc tả ca sử dụng

và phương pháp sinh các ca kiểm thử với các nghiên cứu khác liên quan

Các kết quả nghiên cứu trên của luận án nhằm xây dựng một phươngpháp hoàn chỉnh để sinh tự động các ca kiểm thử chức năng từ các ca sửdụng bằng phương pháp kiểm thử dựa trên mô hình với cách tiếp cận môhình hóa chuyên biệt miền Từ đó nghiên cứu hướng đến một phương pháphoàn chỉnh cho phép tích hợp ca sử dụng vào trong phương pháp phát triểnhướng mô hình

1.3 Cấu trúc luận án

Luận án Kiểm thử dựa trên mô hình với cách tiếp cận mô hình hóa chuyên

biệt miền bao gồm sáu chương Trong đó Chương 1 Mở đầu trình bày về

lý do chọn đề tài và nội dung nghiên cứu của luận án Các chương còn lạiđược tổ chức như trong Hình 1.2, cụ thể như sau:

Hình 1.2: Cấu trúc luận án.

Chương 2 trình bày về các kiến thức nền được sử dụng trong luận án.

Đầu tiên, luận án trình bày về kiểm thử dựa trên ca sử dụng Kế tiếp, luận

án giới thiệu về mô hình hóa chuyên biệt miền Mục tiếp theo là ngôn ngữchuyển mô hình Các ngôn ngữ được sử dụng là phương tiện để xây dựng cácchuyển đổi mô hình trong các ngôn ngữ mô hình hóa chuyên biệt miền Phần

cuối cùng của chương là ngôn ngữ ràng buộc đối tượng (Object Constraint

Language - OCL), đây cũng là phương tiện được sử dụng cho cả hai cấp độ

siêu mô hình và mô hình để đặc tả các luật ràng buộc hợp lệ trong các siêu

mô hình và đặc tả rõ ràng các loại ràng buộc khác nhau trong các mô hình

ca sử dụng của luận án đề xuất trong Chương 3 và 4 Trong phần này luận

án cũng trình bày một công cụ hỗ trợ giải các ràng buộc trong OCL màluận án có sử dụng như công cụ trung gian cho các đề xuất trong Chương4

Chương 3 đề xuất một ngôn ngữ đặc tả chuyên biệt miền cho miền đặc

tả các ca sử dụng tên là USL Ngôn ngữ USL với mục đích để đặc tả rõ ràngcác thông tin trong các ca sử dụng cho mục đích đặc tả yêu cầu và sinh tựđộng các đầu ra từ mô hình ca sử dụng Phương pháp đặc tả USL cho phéptích hợp ca sử dụng vào trong phương pháp phát triển phần mềm hướng môhình

Chương 4 trình bày phương pháp sinh tự động các ca kiểm thử chức

năng từ mô hình ca sử dụng và mô hình khái niệm miền của hệ thống.Trong chương này, trước hết luận án đề xuất một ngôn ngữ đặc tả các cakiểm thử hệ thống theo phương pháp mô hình hóa chuyên biệt miền tên

là TCSL Sau đó, luận án đề xuất một phương pháp cho phép chuyển tựđộng các ca sử dụng được đặc tả trong các mô hình USL và mô hình lớpcác khái niệm miền sang các ca kiểm thử được đặc tả trong một mô hìnhTCSL Phương pháp sinh tự động mô hình TCSL từ các mô hình USL được

đề xuất trong chương này thể hiện tính thống nhất về mặt phương phápluận và tính khả thi trong quá trình thực nghiệm

Chương 5 trình bày về công cụ hỗ trợ và các đánh giá của phương pháp

đã đề xuất Đầu tiên, luận án hiện thực hóa các đề xuất trong các Chương

3 và 4 bằng một công cụ hỗ trợ USL Sau đó, luận án sử dụng công cụ đã

đề xuất để thực nghiệm trên một số ca sử dụng Sau đó, luận án trình bàycác so sánh và đánh giá các kết quả đã đề xuất Công cụ hỗ trợ USL chophép tích hợp các ca sử dụng vào trong phương pháp phát triển hướng môhình Trong đó, công cụ cho phép tạo ra các mô hình đặc tả ca sử dụngtrong ngôn ngữ đặc tả USL Công cụ cũng cung cấp các bộ sinh khác nhaucho phép sinh tự động các đầu ra khác nhau từ các mô hình USL Cụ thể,luận án hiện thực hóa hai bộ sinh là sinh các đặc tả ca sử dụng trong ngônngữ tự nhiên dựa trên mẫu được gọi là USL2TUCD và sinh các ca kiểm thửđược đặc tả trong mô hình TCSL

Cuối cùng, Chương 6 phân tích về các đóng góp chính của luận án và

thảo luận về các nghiên cứu trong tương lai từ các kết quả ban đầu đã đạtđược

KIẾN THỨC CƠ SỞ

Trong chương này, luận án sẽ trình bày về những kiến thức cơ sở được

sử dụng trong các chương tiếp theo Mở đầu, Mục 2.1 sẽ làm rõ các kháiniệm trong kiểm thử phần mềm, ca sử dụng, và phương pháp xác định các

ca kiểm thử từ các ca sử dụng Các mục tiếp theo, luận án sẽ lần lượt mô

tả về mô hình hóa chuyên biệt miền (Domain-Specific Modeling - DSM ), ngôn ngữ chuyển mô hình (model transformation language), và ngôn ngữ

ràng buộc đối tượng OCL

Phần này, luận án sẽ trình bày các kiến thức nền trong kiểm thử phầnmềm, ca sử dụng, và kiểm thử dựa trên ca sử dụng Các kiến thức này đượcluận án tìm hiểu khi nghiên cứu bài toán kiểm thử chức năng từ ca sử dụng

2.1.1 Kiểm thử phần mềm

Lỗi phần mềm là một khiếm khuyết trong một thành phần hoặc hệ thống

mà nó có thể làm cho thành phần hoặc hệ thống này không thực hiện đúngchức năng yêu cầu của nó, ví dụ như thông báo sai hoặc định nghĩa dữ liệukhông đúng [5]

11

Kiểm thử (Testing) là một quy trình thực hiện một chương trình với ý

định tìm kiếm các lỗi Kiểm thử phần mềm bao gồm việc kiểm chứng độngcác hành vi của một chương trình trên một tập hữu hạn các ca kiểm thử

(test case) Các ca kiểm thử được lựa chọn phù hợp từ các miền thực thi

thường là vô hạn để có được hành vi được mong đợi [49]

Kiểm thử tĩnh (Static Testing) là hoạt động kiểm tra mà không thực

hiện chương trình Hoạt động này bao gồm kiểm tra phần mềm và một sốdạng của phân tích [5]

Kiểm thử động (Dynamic Testing) là thực hiện chương trình với các giá

trị đầu vào xác định để tìm các lỗi trong các hành vi của chương trình [5]

Hầu hết các tài liệu sử dụng thuật ngữ kiểm thử để chỉ kiểm thử động

và kiểm thử tĩnh được gọi là hoạt động xác minh

Khi thực thi kiểm thử, việc kiểm thử toàn diện chương trình thực tế làkhông thể thực hiện được Bởi vì, mỗi hoạt động trong chương trình thường

có một số lượng lớn các dữ liệu đầu vào thỏa mãn Vì vậy khi kiểm thử,kiểm thử viên cần chọn một số lượng các ca kiểm thử đủ nhỏ để có thể thựcthi các kiểm thử trong thời gian giới hạn Vậy làm thế nào để chọn đượccác ca kiểm thử có nhiều khả năng để lộ thất bại trong hệ thống Khi đó,một số chiến lược sẽ được áp dụng để xác định tập các đầu vào cho ca kiểmthử như phân lớp tương đương, kiểm thử giá trị biên Sau mỗi lần thực hiệnkiểm thử, chúng ta phải quyết định hành vi được quan sát của hệ thống làmột thất bại hay không Vấn đề này được gọi là một lời tiên tri (oracle).Vấn đề oracle thường được giải quyết thông qua kiểm tra thủ công đầu rathực tế Nhưng để kiểm thử lặp lại và hiệu quả, oracle cần được tự độnghóa

Ca kiểm thử (Test case) là tập của các dữ liệu kiểm thử (test data), các

điều kiện thực hiện (pre-condition), các bước kiểm thử (test steps), và các kết quả đầu ra mong đợi (expected output) được phát triển cho một kịch bản kiểm thử (test scenario) cụ thể để kiểm chứng sự tuân thủ một yêu cầu

kiểm thử xác định Một ca kiểm thử định nghĩa một thử nghiệm đơn lẻ sẽđược thực hiện để đạt được mục tiêu kiểm thử phần mềm cụ thể, chẳng hạnnhư đi qua một đường thực thi của chương trình cụ thể hoặc kiểm chứngtuân thủ một yêu cầu cụ thể [5]

Dữ liệu kiểm thử là tập các giá trị thực (thỏa mãn tiêu chí bao phủ dữ

liệu đã chọn) được xác định chỉ rõ là đầu vào để thực hiện các ca kiểm thửtrong quá trình kiểm thử [5].

Đầu ra mong đợi là các kết quả dự kiến sẽ được tạo ra khi thực hiện kiểm

thử Chương trình thỏa mãn khi và chỉ khi đầu ra thực tế thỏa mãn đầu ramong đợi của kiểm thử [5]

Các bước kiểm thử mô tả các bước thực hiện và kiểm tra kết quả đầu ra

của hệ thống [5]

Các điều kiện thực hiện là các điều kiện cần thỏa mãn để ca kiểm thử

được thực hiện [5]

Kịch bản kiểm thử (Test scenario) là một ca kiểm thử trừu tượng và

nó thường bao gồm nhiều ca kiểm thử liên quan nhau Một kịch bản kiểmthử mô tả một thủ tục thực hiện kiểm thử bao gồm một tập các bước kiểmthử (test step) Mục đích của kịch bản kiểm thử là kiểm tra việc thực hiệnchức năng từ đầu đến cuối của một chức năng phần mềm và đảm bảo luồnglogic đang hoạt động là đúng Với mỗi kịch bản kiểm thử, kiểm thử viên cóthể xác định được một hoặc nhiều bộ dữ liệu kiểm thử thỏa mãn kịch bảnkiểm thử Một ca kiểm thử là sự kết hợp của một kịch bản kiểm thử vớimột bộ dữ liệu kiểm thử thỏa mãn kịch bản [5]

Một hoạt động quan trọng trong kiểm thử phần mềm là thiết kế các cakiểm thử Một quy trình phát triển phần mềm tạo ra một lượng lớn thôngtin như đặc tả yêu cầu, tài liệu thiết kế và mã nguồn Để tạo các ca kiểmthử hiệu quả với chi phí thấp, các nhà thiết kế kiểm thử sẽ phân tích một số

nguồn thông tin như các đặc tả yêu cầu và đặc tả chức năng (requirements

and functional specifications), mã nguồn, các miền đầu vào và đầu ra (input and output domains), hồ sơ hoạt động (operational profile), và mô hình lỗi.

Tất cả các nguồn thông tin này cung cấp các thông tin bổ sung cho các nhàthiết kế kiểm thử Dựa trên nguồn thông tin cho thiết kế kiểm thử, kỹ thuật

kiểm thử được chia thành hai kỹ thuật chính là kiểm thử hộp trắng (white

box testing) và kiểm thử hộp đen (black box testing) như được định nghĩa

trong [5]

Kiểm thử hộp đen là kỹ thuật kiểm thử mà các ca kiểm thử được xác

định từ các mô tả bên ngoài của phần mềm, bao gồm các đặc tả, các yêucầu, và thiết kế

Kiểm thử hộp trắng là kỹ thuật kiểm thử mà các ca kiểm thử được xác

định từ mã nguồn bên trong của phần mềm, đặc biệt bao gồm các nhánh,các điều kiện riêng, và các câu lệnh

Kiểm thử được thực hiện tại các mức khác nhau liên quan tới các hoạtđộng phát triển phần mềm Hình 2.1 là mô hình chữ V (V model), mô hìnhminh họa các mức kiểm thử và các hoạt động phát triển phần mềm

Các mức kiểm thử được trình bày trong [50, 64] gồm có kiểm thử đơn vị,kiểm thử tích hợp, kiểm thử hệ thống, và kiểm thử chấp nhận Các ca kiểmthử của các mức kiểm thử này sẽ được thiết kế dựa vào các chế tác tươngứng trong các quy trình khác nhau trong phát triển phần mềm Sau khi có

mã chương trình, các mức kiểm thử khác nhau sẽ lần lượt được thực hiện

Trong kiểm thử đơn vị (Unit testing), các lập trình viên kiểm thử riêng

lẻ các đơn vị chương trình như các hàm, thủ tục, phương thức, hoặc lớp mộtcách độc lập Sau khi chắc chắn các đơn vị riêng lẻ làm việc thỏa mãn, cácmô-đun được lắp ráp để xây dựng các hệ thống con lớn hơn bằng cách thựchiện các kỹ thuật kiểm tra tích hợp

Kiểm thử tích hợp (Integration testing) được thực hiện bởi các nhà phát

triển phần mềm và các kỹ sư kiểm thử tích hợp Mục tiêu của kiểm thử tíchhợp là để xây dựng một hệ thống thỏa mãn ổn định có thể chịu được sựnghiêm ngặt của việc kiểm thử mức hệ thống

Kiểm thử mức hệ thống (System testing) gồm một phổ rộng các kiểm thử như kiểm thử chức năng (functionality testing), kiểm thử độ bền (ro-

buntness), kiểm thử bảo mật (security testing), kiểm thử tải (load testing),

kiểm thử hiệu năng (performamce testing), kiểm thử độ tin cậy (reliability

testing), kiểm thử ổn đinh (stability), kiểm thử quá tải (stress testing) Kiểm

thử mức hệ thống là một pha quan trọng trong quy trình phát triển phầnmềm vì cần phải đáp ứng một kế hoạch chặt chẽ gần ngày chuyển giao, đểkhám phá hầu hết các lỗi, và kiểm chứng sản phẩm đang làm việc và khôngdẫn đến các lỗi mới Kiểm thử hệ thống gồm các hoạt động phân biệt như

tạo một kế hoạch kiểm thử (test plan), thiết kế một bộ kiểm thử (test suite),

chuẩn bị môi trường kiểm thử, thực hiện các kiểm thử theo một chiến lược

rõ ràng và giám sát quy trình thực hiện kiểm thử

Sau khi hoàn thành việc kiểm thử mức hệ thống, sản phẩm sẽ đượcchuyển giao đến khách hàng Khách hàng sẽ thực hiện một loạt các kiểm

thử của họ, thường biết đến như là kiểm thử chấp nhận (acceptance testing).

Kiểm thử dựa trên mô hình (Model-Based Testing - MBT) là một

kỹ thuật kiểm thử với mục đích để sinh các ca kiểm thử tự động từ mô hình

đặc tả các khía cạnh liên quan của hành vi hệ thống cần kiểm thử (System

Under Testing - SUT ) Mô hình mô tả hệ thống cần kiểm thử từ góc nhìn

của những vấn đề cần được kiểm thử Ví dụ, một mô hình luồng điều khiển

(control flow) của một phương thức sẽ mô hình khía cạnh luồng điều khiển

đi qua các câu lệnh thực hiện của phương thức [56] Cụ thể, thay vì thiết

kế hàng trăm ca kiểm thử thủ công thì người thiết kế kiểm thử xây dựng

mô hình trừu tượng của SUT, sau đó công cụ kiểm thử dựa trên mô hìnhsinh ra một tập các ca kiểm thử từ mô hình đó Toàn bộ thời gian thiết kếkiểm thử được giảm xuống, và ưu điểm nữa là có thể sinh ra một loạt cáctập ca kiểm thử khác nhau từ cùng một mô hình bằng việc sử dụng các tiêu

chí lựa chọn kiểm thử khác nhau [9] Hình 2.2 thể hiện năm bước chính củaquy trình kiểm thử dựa trên mô hình.

Bước 1 Mô hình hóa: Người tạo mô hình sẽ tạo ra các mô hình cho hệ

thống cần kiểm thử hoặc môi trường của hệ thống cần kiểm thử Sau khi

mô hình được tạo ra, các mô hình cần được kiểm tra để đảm bảo tính nhấtquán và có được các hành vi mong muốn

Bước 2 Sinh các ca kiểm thử từ các mô hình: Trong bước này, chúng

ta sẽ lựa chọn một số tiêu chí lựa chọn kiểm thử để cho bộ sinh (test case

generator ) sẽ sinh các ca kiểm thử theo yêu cầu Thông thường, chúng ta

có vô số các ca kiểm thử thỏa mãn, nên tác tiêu chí đảm bảo lựa chọn đượccác ca kiểm thử đủ nhỏ nhưng vẫn đảm khả năng khám phá được các lỗitốt nhất có thể Trong bước này, các kịch bản kiểm thử và dữ liệu kiểm thử

sẽ được sinh

Bước 3 Sinh các tập lệnh thực thi kiểm thử: Bộ sinh các tập lệnh

thực thi kiểm thử ((test script generator )) sẽ sinh tự động các tập lệnh thực thi kiểm thử (test script) từ các ca kiểm thử.

Bước 4 Thực thi kiểm thử trên SUT: Với MBT trực tuyến, công cụ

MBT sẽ quản lý quy trình thực thi kiểm thử và ghi lại kết quả Với MBT

ngoại tuyến, thì bước này sẽ được thực hiện sau bởi một công cụ thực thikiểm thử đã tồn tại.

Bước 5 Phân tích các kết quả kiểm thử: Các kết quả kiểm thử sẽ

được phân tích để đánh giá kiểm thử Các báo cáo kiểm thử sẽ được tạotrong bước này

Trong MBT, các mô hình được sử dụng để sinh các ca kiểm thử cần cóhai tính chất quan trọng đó là: các mô hình phải nhỏ so với kích thước củaSUT để việc xây dựng các mô hình không mất quá nhiều chi phí, nhưng các

mô hình phải đủ chi tiết để mô tả chính xác các tính chất chúng ta muốnkiểm thử Hai tính chất này có thể xung đột nhau Vì vậy khi mô hình hóacần phải quyết định tính chất nào của hệ thống cần được mô hình hóa vàchi tiết bao nhiêu là đủ

Mọi chiến lược kiểm thử với mục đích là để phát hiện các loại lỗi nhấtđịnh Cơ chế sinh các ca kiểm thử chức năng của luận án được dựa trên baloại mô hình lỗi trong biểu đồ hoạt động là: lỗi trong điểm quyết định, lỗivòng lặp, và lỗi đồng bộ hóa

- Lỗi trong quyết định là lỗi xuất hiện trong một quyết định của biểu

đồ hoạt động Ví dụ, một lỗi trong quyết định xảy ra tại điểm quyếtđịnh tính hợp lệ của một đăng ký: khi người dùng nhập thông tin về

ID đăng ký không hợp lệ nhưng hệ thống lại hiển thị thông tin đăng ký

và thông tin thanh toán của một số người dùng cho ID đăng ký khônghợp lệ, trong khi người dùng nhập ID đăng ký hợp lệ thì hệ thống lạihiển thị tài khoản không hợp lệ

- Lỗi trong vòng lặp là lỗi xảy ra hoặc trong điều kiện vào vòng lặp,

kết thúc vòng lặp (n lần lặp), n-1 hoặc n+1 lần lặp Ví dụ, trong

chức năng Hủy đăng ký (Registration Cancellation), nếu một lỗi tồn

tại trong điều kiện kết thúc vòng lặp thì nó có thể xảy ra sau khi đưađầu vào cho lần đầu tiên TryAgain=Yes, vòng lặp được thực hiện cholần lặp thứ 2, ở cuối lần lặp thứ 2, sau khi đưa TryAgain=No, vònglặp không thoát thay vào đó vòng lặp thực hiện cho lần lặp thứ 3, v.v

- Lỗi đồng bộ hóa xuất hiện khi một số hành động bắt đầu thực hiện

trước khi hoàn thành một nhóm của tất cả các hành động trước Ví

dụ trong ca sử dụng Hủy đăng ký, nếu hành động Hủy gửi Email thực hiện trước khi hoàn thành tất cả các hành động đồng thời Cập nhật

bản ghi đăng ký và Chuẩn bị Email để hủy, một lỗi có thể phát sinh

bởi vì các đối tượng Emails và Việc hủy được tạo bởi các hành động đồng thời trước có thể không sẵn sàng để Gửi hủy Email Lý do chính

là các hoạt động không được thực hiện một cách kịp thời, đó là hành

động Hủy gửi Email không được đồng bộ với các hành động đồng thời.

Tiêu chí bao phủ (Test coverage criteria) là một tập các quy tắc hướng

dẫn quyết định các yếu tố thích hợp cần được đề cập để được phủ Tiêu chíđược phủ này tạo ra sự đầy đủ cho các ca kiểm thử được thiết kế [76] Mụcđích để đánh giá mức độ hiệu quả của các ca kiểm thử, đo phần trăm độbao phủ của đặc tả hoặc chương trình của các ca kiểm thử so với yêu cầuphần mềm, thông qua kiểm thử để loại trừ sai sót và tăng chất lượng phầnmềm

Các khái niệm tiếp theo trình bày về hai tiêu chí phủ kiểm thử là phủđường cơ bản [41] và phủ đường hoạt động được đề xuất trong [39] áp dụngcho biểu đồ hoạt động Trong đó tiêu chí phủ đường hoạt động được đề xuất

để kiểm thử vòng lặp và kiểm thử các hành động đồng thời, tiêu chí này mởrộng tiêu chí phủ đường cơ bản nhằm xác định thêm các ca kiểm thử choloại vòng lặp kiểm tra điều kiện sau Tiêu chí phủ đường hoạt động đượcluận án áp dụng để sinh các ca kiểm thử trong Chương 4

Các đường cơ bản (basic path) trong biểu đồ hoạt động là khi chúng ta

thăm một biểu đồ hoạt động từ trạng thái bắt đầu đến trạng thái kết thúcbằng thuật toán duyệt theo chiều sâu, chúng ta giới hạn các vòng lặp đượcthực hiện nhiều nhất một lần Mỗi đường cơ bản gồm một chuỗi các hànhđộng mà một hành động trong đường cơ bản chỉ xuất hiện nhiều nhất mộtlần [41, 46]

từ một đồ thị hoạt động và một tập các ca kiểm thử T, cho mỗi đường cơ

bản pi ∈ PB, phải có ít nhất một ca kiểm thử t ∈ T sao cho khi hệ thốngđược thực hiện với ca kiểm thử t thì pi được thực thi

Ví dụ, để đạt tiêu chí phủ đường cơ bản xét hai biểu đồ hoạt động(a) và (b) trong Hình 2.3, biểu đồ (a) xác định được hai đường cơ bản

là p1 = 0 → A1 → A2 → A3 → A4 → 5 (vòng lặp thực hiện 1 lần), p2

Hình 2.3: Các ví dụ của biểu đồ hoạt động với các cấu trúc lặp [39].

= 0 → A1 → A4 → 5 (vòng lặp thực hiện 0 lần); biểu đồ (b) xác địnhđược một đường cơ bản là p3 = 0 → A1 → A2 → A3 → A4 → 5 (vòng lặpđược thực hiện một lần) (với 0 và 5 là nút bắt đầu và kết thúc trong haihình (a) và (b)) Với biểu đồ hoạt động (b) trong Hình 2.3, đường p4 =

0 → A1 → A2 → A3 → A2 → A3 → A4 → 5 (vòng lặp thực hiện hai lần)

là cần thiết để kiểm tra trong trường hợp điều kiện lặp là True Tuy nhiênđường p4 không phải là đường cơ bản vì hành động A2 và A3 xuất hiệnnhiều hơn một lần vi phạm thuộc tính của đường cơ bản

Một đường hoạt động (activity path) là một đường trong một đồ thị

hoạt động xem xét một vòng lặp nhiều nhất là hai lần và duy trì mối quan

hệ ưu tiên giữa các hành động đồng thời và không đồng thời [39] Nghiêncứu trong [39] đã đề cập về các đường hoạt động và các kiểu đường hoạt

động: (1) đường hoạt động không đồng thời (non-concurrent activity path)

và (2) đường hoạt động đồng thời (concurrent activity path).

Một đường hoạt động không đồng thời là một chuỗi các hành động không

đồng thời từ hành động bắt đầu đến hành động cuối cùng trong một đồ thịhành động Khi đó, mỗi hành động trong chuỗi xuất hiện nhiều nhất mộtlần trừ các hành động ở trong vòng lặp Mỗi hành động trong vòng lặp có

thể xuất hiện nhiều nhất hai lần trong chuỗi Đường hoạt động không đồngthời là để phủ các lỗi trong vòng lặp và điều kiện nhánh Để phát hiện mộtlỗi trong một vòng lặp, tiêu chí này kiểm thử vòng lặp: không thực hiện

vòng lặp và thực hiện vòng lặp một lần với cấu trúc vòng lặp while-do, thực hiện vòng lặp một lần và hai lần với cấu trúc vòng lặp do-while.

Một đường hoạt động đồng thời là một trường hợp đặc biệt của đường

hoạt động không đồng thời, bao gồm cả các hành động đồng thời và các hành

động không đồng thời thỏa mãn mối quan hệ ưu tiên giữa chúng Nghiêncứu [39] đã đề xuất lựa chọn đường hoạt động đồng thời mà chuỗi của cáchành động đồng thời được đóng gói trong một đường tương ứng với chiềungang tìm kiếm trên bề rộng của chúng trong biểu đồ hoạt động Điều này

là bởi vì sử dụng nó đảm bảo mối quan hệ ưu tiên giữa các hành động trongbiểu đồ hoạt động được thỏa mãn

Tiêu chí phủ đường hành động (activity path coverage criterion).

Cho một tập các đường hành động PA lấy từ một đồ thị hành động và một

tập các ca kiểm thử T, với mỗi đường hành động pi ∈ PA phải có ít nhấtmột ca kiểm thử t ∈ T sao cho khi hệ thống được thực hiện với ca kiểmthử t thì đường pi được thực hiện Tiêu chí này với mục đích sử dụng chokiểm thử cả vòng lặp và kiểm thử các hành động đồng thời trong đồ thịhoạt động

Ví dụ, để đạt tiêu chí phủ đường hoạt động xét hai biểu đồ hoạt động (a)

và (b) trong Hình2.3, biểu đồ (a) xác định được hai đường hoạt động khôngđồng thời là p1 = 0 →A1→A2→A3 →A4→ 5 (vòng lặp thực hiện 1 lần),

p2=0 →A1 →A4 → 5(vòng lặp thực hiện 0 lần); biểu đồ (b) xác định đượchai đường hoạt động không đồng thời là p3 = 0 →A1→A2 →A3 →A4→ 5

(vòng lặp được thực hiện một lần), p4 = 0 →A1 →A2 →A3→A2→A3 →

A4 → 5(vòng lặp thực hiện hai lần) So sánh với các đường cơ bản, các đườnghoạt động cho phép kiểm thử tại vòng lặp kiểm tra điều kiện sau trong cả

hai trường hợp điều kiện lặp là False và True Để đạt tiêu chí phủ đường

hoạt động, biểu đồ hoạt động trong Hình2.4xác định được một đường hànhđộng đồng thời là p = 0 → A1 →A2 →A3 →A4 →A5 →A6 →A7 →A8 9 (0

và 9 là nút bắt đầu và kết thúc) Đường hành động đồng thời p gồm chuỗicác hành động giống như hoạt động tìm kiếm theo chiều rộng và thỏa mãntất cả các quan hệ có thứ tự của các hành động không đồng thời và đồngthời

Hình 2.4: Ví dụ của biểu đồ hoạt động có chứa các hành động đồng

thời [39]

Chất lượng của các ca kiểm thử phụ thuộc vào mức độ phủ tất cả cácchức năng trong một hệ thống cần kiểm thử Các ca kiểm thử phải được xácnhận theo một số tiêu chí chất lượng để đảm bảo rằng chúng ở dạng chấpnhận được cũng như đảm bảo rằng chúng kiểm thử tất cả các chức năng

của hệ thống Một độ đo phần mềm được gọi là độ phức tạp Cyclomatic

cho phép đo định lượng độ phức tạp logic của một chương trình [33] Hàm

phức tạp Cyclomatic, V(G), là một tiêu chí quan trọng vì hai thuộc tính

của nó: nó là giới hạn trên cho số lượng các ca kiểm thử cần thiết để đạtđược tiêu chí phủ nhánh Bên cạnh đó, nó là giới hạn dưới cho số lượng các

ca kiểm thử cần thiết để đạt được phủ toàn bộ đường dẫn có thể có (số cakiểm thử phủ nhánh≤ V(G)≤ số đường có thể có) Trong đồ thị hoạt độnghàm V(G) = E - N +2 hoặc V(G)=P+1, trong đó E là số cạnh, N là số nút,

P là số mệnh đề điều kiện (số nút quyết định nhị phân) [8, 31] Ví dụ, haibiểu đồ hoạt động (a) và (b) trong Hình 2.3 đều có một nút quyết định nhịphân, nên V(G)=1+1=2 Vậy trong hai hình này độ phức tạp Cyclomatic

là 2 Điều này có nghĩa là giới hạn trên để đạt được tiêu chí phủ nhánh là

2 đường hoạt động

2.1.2 Ca sử dụng

Ca sử dụng được sử dụng rộng rãi như là một phương tiện để nắm bắt

các yêu cầu chức năng của phần mềm Khái niệm này được định nghĩa lầnđầu tiên bởi Jacobson năm 1987 [27] Một ca sử dụng mô tả một chức năng

sử dụng cụ thể của hệ thống bởi một tác nhân (actor ) Mỗi ca sử dụng mô

tả các tương tác của tác nhân với hệ thống để đạt được một nhiệm vụ cụthể (hoặc ít nhất cung cấp một đầu ra có giá trị cho người dùng) Các ca

sử dụng là chế tác trung tâm trong phát triển phần mềm Chúng được sửdụng như là đầu vào để xây dựng các chế tác khác nhau của phần mềm,như các mô hình hành vi, mô hình cấu trúc, và các ca kiểm thử hệ thống,

và làm tài liệu [29]

Một mô hình ca sử dụng trong UML thường được thể hiện bằng các

biểu đồ ca sử dụng liên kết lỏng lẻo với các mô tả của các ca sử dụng trongngôn ngữ tự nhiên được trình bày trong một mẫu có cấu trúc như được đềxuất trong [13, 15, 25, 28, 37, 60,75] Trong đó các biểu đồ ca sử dụng cungcấp tổng quan về các ca sử dụng, người dùng của hệ thống và các mối quan

hệ giữa các ca sử dụng và người dùng Các mô tả của mỗi ca sử dụng mô tảcác chuỗi tương tác giữa môi trường và hệ thống Mô tả ca sử dụng trongngôn ngữ tự nhiên cho phép người dùng cũng như các bên tham gia pháttriển phần mềm dễ dàng hiểu được yêu cầu của hệ thống Hình 2.5 là một

biểu đồ ca sử dụng đơn giản của hệ thống Websit trung tâm X và Bảng 2.1

là mô tả của ca sử dụng Đăng nhập theo một mẫu có cấu trúc trong ngôn

ngữ tự nhiên

Hình 2.5: Biểu đồ ca sử dụng của hệ thống đăng ký khóa học đơn

giản

Một biểu đồ ca sử dụng bao gồm bốn yếu tố riêng biệt: Hệ thống, các

tác nhân tương tác với hệ thống, các ca sử dụng (dịch vụ) mà hệ thống đượcyêu cầu thực hiện, và các mối quan hệ giữa các thành phần Thành phần

hệ thống đặt ranh giới giữa các tác nhân sử dụng hệ thống và các dịch vụ

hệ thống phải cung cấp Các tác nhân được mô tả đứng bên ngoài hệ thống

và ca sử dụng được mô tả bên trong hệ thống

Một tác nhân trong biểu đồ ca sử dụng có thể được liên kết (association)với một hoặc nhiều ca sử dụng Mối quan hệ này có thể chỉ định tác nhân khởitạo ca sử dụng hay nhận kết quả từ ca sử dụng hay cả hai UML cho phép

ba mối quan hệ khác nhau giữa các ca sử dụng: Tổng quát hóa (generation),

bao gồm (inclusion), và mở rộng (extension) Quan hệ generation của ca sử

dụng định nghĩa khái quát hóa tác nhân khi chức năng chung được tách ra

từ chức năng cụ thể trong các ca sử dụng khác nhau Hai ca sử dụng có

quan hệ inclusion nếu một ca sử dụng sử dụng chức năng được cung cấp bởi một ca sử dụng khác Mối quan hệ extension tồn tại giữa hai ca sử dụng

nếu một ca sử dụng muốn sử dụng chức năng của trường hợp sử dụng khácnếu điều kiện nhất định được thỏa mãn

phần: các trường thông tin mô tả chung của ca sử dụng và phần mô tả chitiết của các kịch bản tương tác của ca sử dụng được mô tả trong các luồng

sự kiện Ví dụ trong Bảng2.1 là một mô tả của ca sử dụng Đăng nhập trong

hệ thống Website trung tâm X.

Trong đó, phần thông tin quan trọng nhất của mô tả ca sử dụng cho mụcđích kiểm thử là thông tin về các luồng sự kiện của ca sử dụng trong luồng

sự kiện chính (basic flow) và các luồng thay thế (alternate flows) Hình 2.6

mô tả mô hình các luồng sự kiện đi qua ca sử dụng

Bảng 2.1: Một mẫu mô tả ca sử dụng

Use case name: Đăng nhập

Brief description: Sinh viên thực hiện đăng nhập để thực hiện đăng ký khóa học Actors: Sinh viên.

Precondition: Sinh viên truy cập vào website của trung tâm X.

Postcondition: Nếu đăng nhập hệ thống thành công, hệ thống hiển thị các chức năng

cho phép sinh viên thực hiện trên Website, nếu không thành công đưa ra thông báo cho sinh viên biết.

Trigger: Chức năng đăng nhập được thực hiện khi sinh viên nhấn chọn “Đăng nhập”

trên Website của trung tâm X.

Special requirement: Không có yêu cầu đặc biệt.

Basic flow

1 Sinh viên nhấn chọn chức năng đăng nhập

2 Hệ thống hiển thị giao diện đăng nhập

3 Sinh viên nhập User Name

4 Hệ thống kiếm tra tính hợp lệ của User Name, nếu thông tin không hợp lệ chuyển sang bước 4a.1

5 Sinh viên nhập PassWord

6 Hệ thống kiểm tra tính hợp lệ của PassWord, nếu Password không hợp lệ chuyển sang bước 6a.1

7 Sinh viên Click vào Button "Đăng Nhập"

8 Hệ thống kiểm tra tài khoản của sinh viên có trong hệ thống không, nếu không chuyển sang bước 8a.1

9 Hệ thống hiển thị các chức năng sinh viên có quyền thực hiện trên Website.

Alternate flows

4a User Name không hợp lệ

1 Hệ thống hiển thị thông báo "UserName phải từ 8 đến 16 ký tự, yêu cầu nhập lại", quay lại bước 4

6a Password không hợp lệ

1 Hệ thống hiển thị thông báo "PassWord phải là 8 ký tự, yêu cầu nhập lại", quay lại bước 6

8a Nếu tài khoản của sinh viên không có trong hệ thống

1 Hệ thống hiển thị thông báo "Tài khoản không tồn tại, đăng nhập lại".

Các kịch bản ca sử dụng Một kịch bản ca sử dụng (use case scenario) là

một thể hiện của ca sử dụng, hoặc là một đường thực thi hoàn chỉnh đi qua

ca sử dụng Khi thực hiện một ca sử dụng, người dùng cuối của hệ thống

có thể thực hiện theo nhiều đường thực thi khác nhau Trong đó luồng sựkiện chính sẽ xác định được một đường thực thi và kết hợp giữa luồng sựkiện chính với các luồng sự kiện thay thế chúng ta sẽ xác định được các

đường thực thi khác nhau của ca sử dụng Các kịch bản ca sử dụng sẽ được

sử dụng là cơ sở để xây dựng các ca kiểm thử Ví dụ, từ ca sử dụng Đăng

nhập, chúng ta có thể xác định được một số kịch bản thực hiện ca sử dụng

như trong Bảng 2.2

2.1.3 Xây dựng các ca kiểm thử từ ca sử dụng

Kiểm thử ca sử dụng (Use case testing) là một kỹ thuật giúp xác định

các ca kiểm thử phủ toàn bộ hệ thống, trên cơ sở từng giao dịch từ điểmbắt đầu đến điểm kết thúc [28] Các ca kiểm thử được xác định từ các ca

sử dụng gồm có ba bước

Bước 1: Xác định các kịch bản Kiểm thử viên đọc mô tả ca sử dụng và

xác định mỗi kết hợp của luồng sự kiện chính và luồng phụ là một kịch bản

và tạo ma trận kịch bản Ví dụ từ ca sử dụng Đăng nhập chúng ta có thể

xác định được một số đường thực thi (các kịch bản thực hiện ca sử dụng)như trong Bảng 2.2

Bảng 2.2: Các kịch bản của ca sử dụng Đăng nhập

SID Tên kịch bản Luồng bắt đầu Luồng phụ

SC4 Tài khoản đăng nhập không có trong

hệ thống

Bước 2: Xác định các ca kiểm thử Bước tiếp theo, kiểm thử viên cần

xác định ít nhất một ca kiểm thử cho mỗi kịch bản Kiểm thử viên đọc lại

mô tả ca sử dụng và tìm kiếm các điều kiện hoặc các yếu tố dữ liệu cầnthiết để thực hiện các kịch bản khác nhau Để ghi lại các ca kiểm thử, mộtđịnh dạng ma trận giống như Bảng 2.3 có thể được sử dụng Bảng 2.3 hiểnthị thông tin của các ca kiểm thử được xác định cho các kịch bản của ca

sử dụng Đăng nhập Trong đó, các cột từ 1 đến 6 lần lượt mô tả mã của ca

kiểm thử, mã kịch bản, giá trị User Name, giá trị PassWord, trạng thái tàikhoản có trong hệ thống hay không, và kết quả mong đợi Trong đó, V, I,

và N/A ký hiệu cho giá trị hợp lệ, giá trị không hợp lệ, và giá trị không cầnxét đến

Bảng 2.3: Các ca kiểm thử cho ca sử dụng Đăng nhập

TID SID UName PWord Tài khoản

có trong hệ thống

Kế quả mong đợi

được thực hiện

đến 16 ký tự, yêu cầu nhập lại"

ký tự, yêu cầu nhập lại"

tại, đăng nhập lại"

Bước 3: Xác định các giá trị cụ thể cho từng ca kiểm thử Khi thực

thi kiểm thử, kiểm thử viên nhập các giá trị cụ thể ứng với các trường hợplàm cho dữ liệu đầu vào thỏa mãn, không thỏa mãn theo miền giá trị Giả

sử trong cơ sở dữ liệu (trạng thái bên trong hệ thống) có bảng Acount tồn tại một tài khoản có userName="user name 1", passWord="12345678" và không tồn tại tài khoản có userName="user name 2" Bảng 2.4 là các cakiểm thử được xác định với giá trị cụ thể

Bảng 2.4: Các ca kiểm thử của ca sử dụng Đăng nhập với các giá

trị xác định

TID SID UName PWord Tài khoản có

trong hệ thống

Kế quả mong đợi

T01 SC1 "user name 1" "12345678" True Hiển thị các chức năng sinh

viên được thực hiện

phải từ 8 đến 16 ký tự, yêu cầu nhập lại"

T03 SC3 "user name 1" "123" N/A Thông báo "PassWord phải

là 8 ký tự, yêu cầu nhập lại"

T04 SC4 "user name 2" "12345678" False Thông báo "Tài khoản

không tồn tại, đăng nhập lại"

Trong giai đoạn đặc tả yêu cầu, mô hình miền của ứng dụng (domainmodel) nắm bắt các khái niệm chính của hệ thống đang được phát triển.Trong ngôn ngữ UML mô hình này được đặc tả bằng một biểu đồ lớp thực