Sinh ca kiểm thử từ các biểu đồ UML

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THỊ BÍCH HÀ

SINH CA KIỂM THỬ TỪ CÁC BIỂU ĐỒ UML

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

HÀ NỘI - 2015


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THỊ BÍCH HÀ

SINH CA KIỂM THỬ TỪ CÁC BIỂU ĐỒ UML

Ngành

: Công nghệ thông tin

Chuyên ngành : Kỹ thuật phần mềm
Mã số

: 60480103

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS Trương Ninh Thuận

HÀ NỘI - 2015


LỜI CAM ĐOAN
Tôi xin cam đoan những kết quả đạt được trong luận văn này là do tôi nghiên
cứu, sưu tầm, tổng hợp và sắp xếp lại phù hợp với yêu cầu của luận văn. Toàn bộ
những điều được trình bày trong khóa luận hoặc là của cá nhân, hoặc được tham khảo
và tổng hợp từ các nguồn tài liệu khác nhau. Tất cả tài liệu tham khảo, tổng hợp đều
được trích dẫn với nguồn gốc rõ ràng.
Toàn bộ chương trình, mã nguồn là do tôi thiết kế và xây dựng, không sao chép
của bất kỳ ai và chưa được công bố trên bất kỳ phương tiện nào.
Tôi xin chịu hoàn toàn trách nhiệm về lời cam đoan của mình. Nếu có điều gì
sai trái, tôi xin chịu mọi hình thức kỷ luật theo qui định.
Hà Nội, tháng năm
Học viên
Nguyễn Thị Bích Hà

i


LỜI CẢM ƠN
Lời đầu tiên, tôi xin bày tỏ lòng biết ơn chân thành đến các thầy cô giáo khoa
Công nghệ Thông tin, Đại học Công Nghệ, Đại học Quốc Gia Hà Nội đã tận tình
truyền đạt kiến thức và động viên giúp đỡ tôi trong học tập tại trường.
Đặc biệt, tôi muốn gửi lời cảm ơn sâu sắc đến thầy giáo, phó giáo sư, tiến sĩ
Trương Ninh Thuận, người đã tận tình chỉ bảo, hướng dẫn tôi trong suốt quá trình
nghiên cứu và hoàn thiện luận văn tốt nghiệp.
Tôi cũng xin cảm ơn bạn bè, các đồng nghiệp và nhất là các thành viên trong
gia đình đã tạo mọi điều kiện tốt nhất, động viên, cổ vũ trong suốt quá trình học tập và

làm luận văn tốt nghiệp.
Hà Nội, ngày tháng năm
Học viên

Nguyễn Thị Bích Hà

ii


MỤC LỤC
LỜI CAM ĐOAN.................................................................................................i
LỜI CẢM ƠN ....................................................................................................... ii
BẢNG CÁC CHỮ VIẾT TẮT ............................................................................. iv
DANH MỤC CÁC HÌNH VẼ VÀ CÁC BẢNG .................................................. v
CHƯƠNG 1:TỔNG QUAN .................................................................................. 1
1.1 Đặt vấn đề........................................................................................................ 1
1.2 Tổng quan tình hình nghiên cứu ..................................................................... 2
1.3 Nội dung nghiên cứu ....................................................................................... 3
1.4 Cấu trúc khóa luận........................................................................................... 3
CHƯƠNG 2: KIẾN THỨC CHUNG ................................................................... 5
2.1 Kiểm thử phần mềm ........................................................................................ 5
2.1.1 Các khái niệm kiểm thử phần mềm.............................................................. 5
2.1.2 Mức kiểm thử ............................................................................................... 7
2.2 Giới thiệu ngôn ngữ UML............................................................................. 12
2.2.1 Biểu đồ trạng thái ....................................................................................... 15
2.2.2 Biểu đồ tuần tự ........................................................................................... 16
2.2.3 Đồ thị tuần tự.............................................................................................. 18
CHƯƠNG 3: PHƯƠNG PHÁP SINH CA KIỂM THỬ TỪ BIỂU ĐỒ TUẦN
TỰ VÀ BIỂU ĐỒ TRẠNG THÁI ...................................................................... 20
3.1. Phương pháp thực hiện................................................................................. 20

3.2 Ví dụ minh họa .............................................................................................. 22
3.3 Cài đặt thử nghiệm ........................................................................................ 27
3.3.1 Giới thiệu về Modelio ................................................................................ 28
3.3.2 Các bước tạo một module cho Modelio ..................................................... 29
3.3.3 Các thuật toán áp dụng ............................................................................... 36
3.3.3.1 Thuật toán chuyển từ biểu đồ tuần tự sang đồ thị tuần tự....................... 36
3.3.3.2 Thuật toán duyệt đồ thị tuần tự xác định test path .................................. 40
3.3.3.3 Kết hợp biểu đồ trạng thái vào các test path .......................................... 41
iii


3.3.4 Kết quả cài đặt thử nghiệm ........................................................................ 42
CHƯƠNG 4: KẾT LUẬN .................................................................................. 44
4.1. Các kết quả đạt được và hạn chế .................................................................. 44
4.2. Các công việc trong tương lai ...................................................................... 44
TÀI LIỆU THAM KHẢO ................................................................................... 45

iv


BẢNG CÁC CHỮ VIẾT TẮT
Chữ viết

Cách viết đầy đủ

Dịch nghĩa Tiếng Việt

tắt
UML

Unified Modeling Language

Ngôn ngữ mô hình hóa thống nhất

BPMN

Business Process Modeling Notaion

Hệ thống ký hiệu mô hình hoá tiến
trình nghiệp vụ

SysML

System Modeling Language

Ngôn ngữ mô hình hoá hệ thống

SoaML

Service Oriented Architecture

Ngôn ngữ mô hình hoá kiến trúc

Modeling Language

hướng dịch vụ

Artificial Intelligence

Trí tuệ nhân tạo

AI

iv


DANH MỤC CÁC HÌNH VẼ VÀ CÁC BẢNG
Hình 2.1: Quy trình kiểm thử phần mềm............................................................... 6
Hình 2.2: Các hướng nhìn trong UML ............................................................... 12
Hình 2.3: 9 loại biểu đồ của ngôn ngữ UML ...................................................... 14
Hình 2.4: Các thành phần mô hình thường gặp trong UML .............................. 14
Hình 2.5: Ví dụ biểu đồ trạng thái ...................................................................... 15
Hình 2.6: Ví dụ biểu đồ tuần tự........................................................................... 17
Hình 2.7: Biểu đồ tuần tự .................................................................................... 18
Hình 2.8: Đồ thị tuần tự tương ứng của hình 2.7 ............................................... 19
Hình 3.1: Các bước cơ bản sinh ca kiểm thử...................................................... 21
Hình 3.2: Sơ đồ use case của hệ thống máy rút tiền ATM từ góc nhìn người sử dụng
............................................................................................................................. 22
Hình 3.3: Biểu đồ tuần tự chức năng rút tiền ..................................................... 24
Hình 3.4: Biểu đồ trạng thái máy ATM chức năng rút tiền ................................ 25
Hình 3.5: Đồ thị tuần tự của chức năng rút tiền................................................. 26
Hình 3.6: Kết hợp đồ thị tuần tự và biểu đồ trạng thái ...................................... 26
Bảng 3.1: Kết quả danh sách các ca kiểm thử theo định nghĩa.......................... 27
Bảng 3.2: Các đặc điểm chính của Modelio ....................................................... 29
Hình 3.7: Tạo mới Maven Project ...................................................................... 30
Hình 3.8 Thêm Archetype Catalog của Modelio................................................. 31
Hình 3.9: Chọn Archetypes tương ứng với bản Modelio .................................... 32
Hình 3.10: Tạo Modelio Module......................................................................... 33
Hình 3.11: Debug Configuration ........................................................................ 34
Hình 3.12: Triển khai module ............................................................................. 35

Hình 3.13: Chọn file .jmdac ................................................................................ 35
Hình 3.14: Giao diện Config/ Module Catalog .................................................. 36
Bảng 3.3: Bảng mô tả quá trình duyệt các phần từ trong danh sách Interaction
Fragment ............................................................................................................. 39

v


Hình 3.15: Thuật toán duyệt đồ thị ..................................................................... 40
Hình 3.16: Thuật toán kết hợp state vào các test path ....................................... 41
Hình 3.17: Kết quả chạy thử nghiệm .................................................................. 43

vi


CHƯƠNG 1:TỔNG QUAN
1.1 Đặt vấn đề
Trong quá trình phát triển phần mềm, hoạt động kiểm thử nhằm đảm bảo chất
lượng phần mềm có vai trò quan trọng, quyết định đến sự tồn tại của hệ thống phần
mềm. Khi sự phức tạp và kích thước của phần mềm tăng lên, thời gian và công sức cần
thiết để thực hiện kiểm thử một cách hiệu quả cũng tăng theo. Nhiều nghiên cứu cho
rằng hơn 50% chi phí phát triển phần mềm được phân bổ cho việc kiểm thử [2].
Một trong những bài toán quan trọng nhất trong nghiên cứu kiểm thử phần mềm
đó là sinh các ca kiểm thử, việc thiết kế các ca kiểm thử và thực hiện chúng đều tốn
thời gian và công sức. Thiết kế kịch bản kiểm thử bằng cách thủ công rất tốn thời gian
và dễ gặp lỗi. Do vậy, việc nghiên cứu các kỹ thuật để sinh tự động các kịch bản kiểm
thử là rất cần thiết.
Có hai hướng tiếp cận chính trong việc sinh ca kiểm thử tự động. Một hướng
tiếp cận cố gắng thiết kế các ca kiểm thử từ các yêu cầu, đặc tả phần mềm và một
hướng khác sinh từ mã nguồn. Thiết kế ca kiểm thử từ mã nguồn rất lộn xộn và khó tự

động [3]. Các ký hiệu thiết kế có thể được sử dụng làm cơ sở cho việc kiểm tra đầu ra,
làm giảm đáng kể một trong các chi phí của quá trình kiểm thử. Tiến trình sinh các bài
kiểm tra từ thiết kế thường giúp các kiểm thử viên phát hiện được vấn đế trong chính
thiết kế. Nếu bước này được làm sớm, những vấn đề có thể được loại bỏ sớm, tiết kiệm
thời gian và nguồn lực đồng thời cho phép hoạt động kiểm thử được chuyển lên các
bước sớm hơn trong quá trình phát triển phần mềm. Khi những bài kiểm thử được sinh
ra, kiểm thử viên sẽ tìm được những điểm không nhất quán, những nhập nhằng trong
đặc tả và thiết kế, cho phép có thể cải thiện đặc tả và thiết kế trước khi chương trình
được viết ra. Một lợi điểm khác là những dữ liệu dùng để kiểm tra là độc lập với các
cài đặt (tức là độc lập với mã nguồn). Việc tự động hóa tiến trình sinh ca kiểm thử sẽ
rút ngắn được thời gian và công sức của các kiểm thử viên, cải thiện kết quả của quá
trình kiểm thử. Hầu hết các yêu cầu và những thiết kế mức cao của phần mềm được tài
liệu hóa bằng các mô hình. Những mô hình này có thể được sử dụng cho quá trình sinh
ca kiểm thử bằng công cụ tự động.

1


Phát triển phần mềm hướng mô hình là một luận thuyết phát triển phần mềm.
Lợi điểm của nó là hỗ trợ trực quan hóa các miền ứng dụng, các giải pháp. Trong phát
triển phần mềm hướng mô hình, các nhà thực hành cũng sử dụng các mô hình thiết kế
cho việc kiểm thử phần mềm, đặc biệt là những chương trình hướng đối tượng. Có ba
lý do chính để sử dụng mô hình thiết kế trong việc kiểm thử các phần mềm hướng đối
tượng là: (1) những kỹ thuật kiểm thử truyền thống chỉ quan tâm đến trạng thái tĩnh
của mã nguồn, điều này là không đủ cho việc kiểm thử các hành vi động của phần
mềm hướng đối tượng [2], (2) sử dụng mã nguồn để kiểm tra một phần mềm hướng
đối tượng là công việc phức tạp và buồn chán. Ngược lại, những mô hình giúp các
kiểm thử viên có thể hiểu hệ thống tốt hơn, tìm các thông tin cần kiểm tra sau tiến
trình so sánh các mô hình với mã nguồn. (3) việc sinh ca kiểm thử dựa vào mô hình có
thể được lên kế hoạch tại các bước đầu trong vòng đời phát triển phần mềm, cho phép

nhà phát triển phần mềm có thể lập trình và kiểm tra song song với nhau. Với 3 lý do
chính này, phương pháp sinh ca kiểm thử dựa vào mô hình là một lựa chọn hiển nhiên
trong công nghiệp phần mềm.
UML được sử dụng rộng rãi cho việc mô hình hóa hướng đối tượng trong công nghệ
phần mềm. Mặc dù UML cung cấp một cơ chế mạnh cho việc mô tả phần mềm, rất ít
nghiên cứu áp dụng những mô hình này cho mục đích kiểm thử [4]. Với việc sử dụng
UML ngày càng nhiều để mô hình hóa các phần mềm hướng đối tượng, những nhà
nghiên cứu bắt đầu xem xét cách thức sử dụng UML trong kiểm thử. Trong khuôn khổ
luận văn này tôi thực hiện nghiên cứu phương pháp sinh ca kiểm thử tự động từ biểu
đồ tuần tự và biểu đồ trạng thái UML.

1.2 Tổng quan tình hình nghiên cứu
Cách tiếp cận sử dụng các biểu đồ UML để sinh ca kiểm thử tự động có thể kể
đến một số nghiên cứu như sau:
Bertolino và Basanieri [5] đề xuất một phương pháp sinh các ca kiểm thử sử
dụng biểu đồ UML use case và những biểu đồ tương tác (đặc biệt, các biểu đồ thông
điệp tuần tự). Căn bản nó hướng đến kiểm thử tích hợp để kiểm chứng rằng những
thành phần hệ thống đã test trước tương tác chính xác. Họ sử dụng phương pháp phân

2


hoạch loại và sinh các ca kiểm thử thủ công theo luồng của các thông điệp gửi giữa các
thành phần trong biểu đồ tuần tự.
Briand và Labiche [6] mô tả phương pháp kiểm thử hệ thống TOTEM (Kiểm
thử các hệ thống hướng đối tượng bằng UML). Các yêu cầu hệ thống được lấy từ biểu
đồ ca sử dụng, biểu đồ tuần tự và lớp tương ứng với mỗi ca sử dụng. Chúng mô tả sự
phụ thuộc tuần tự giữa các ca sử dụng vào một biểu đồ hoạt động. Dựa trên các phụ
thuộc tuần tự này, họ sinh ra những chuỗi hợp lệ của các ca sử dụng để sinh các ca
kiểm thử. Cách tiếp cận của họ về cơ bản là cách thức bán tự động bao phủ kịch bản

với những điều kiện khởi tạo được định rõ trước và dự đoán về kết quả.
Sharma [7] chuyển đổi một biểu đồ ca sử dụng thành đồ thị ca sử dụng, chuyển
biểu đồ tuần tự thành một đồ thị gọi là đồ thị biểu đồ tuần tự, sau đó tích hợp hai đồ
thị này thành đồ thị kiểm thử hệ thống, duyệt đồ thị kiểm thử hệ thống để sinh các ca
kiểm thử.

1.3 Nội dung nghiên cứu
Nội dung nghiên cứu của luận văn bao gồm: Nghiên cứu tổng quan về kiểm thử
phần mềm, các phương pháp kiểm thử cơ bản. Nghiên cứu tổng quan về UML, đặc
biệt biểu đồ tuần tự và biểu đồ trạng thái là hai loại biểu đồ được sử dụng để sinh ca
kểm thử trong luận văn này.
Luận văn trình bày kỹ thuật sinh ca kiểm thử từ biểu đồ trạng thái và biểu đồ
tuần tự có kèm theo ví dụ minh họa, các thuật toán áp dụng trong phần demo của
chương trình.

1.4 Cấu trúc khóa luận
Khóa luận được tổ chức thành bốn chương như sau:
Chương 1: Mở đầu
Chương một nêu lên sự cần thiết, ý nghĩa thực tiễn, mục tiêu của đề tài “Sinh ca
kiểm thử từ các biểu đồ UML” mà cụ thể là từ biểu đồ trạng thái và biểu đồ tuần tự
UML .
Chương 2: Kiến thức chung

3


Chương hai sẽ trình bày về các khái niệm cơ bản của kiểm thử phần mềm, các
mức độ kiểm thử, kỹ thuật kiểm thử tĩnh và động. Chương hai cũng đưa ra các kiến
thức cơ bản về UML, tìm hiểu biểu đồ tuần tự và biểu đồ trạng thái trong UML.
Chương 3: Phương pháp sinh ca kiểm thử từ biểu đồ tuần tự và biểu đồ

trạng thái
Chương ba trình bày phương pháp sinh ca kiểm thử từ biểu đồ tuần tự và biểu
đồ trạng thái UML, đưa ra ví dụ minh họa từng bước thực hiện cho phương pháp.
Chương này cũng trình bày về ý tưởng, phân tích và xây dựng công cụ sinh ca kiểm
thử tự động từ biểu đồ tuần tự và biểu đồ trạng thái UML, trình bày các thuật toán đã
áp dụng trong việc xây dựng công cụ.
Chương 4: Kết luận
Chương bốn đưa kết luận về các nội dung đã đạt được trong luận văn, các mặt
hạn chế và hướng phát triển trong tương lai của luận văn.

4


CHƯƠNG 2: KIẾN THỨC CHUNG
2.1 Kiểm thử phần mềm
2.1.1 Các khái niệm kiểm thử phần mềm
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần
mềm trong đúng môi trường chúng dự định sẽ được triển khai, nhằm cung cấp những
thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm đó. Hoạt động kiểm thử
phần mềm nhằm đánh giá chất lượng hoặc tính chấp nhận được của sản phẩm. Kiểm
thử với mục đích phát hiện lỗi hoặc bất cứ vấn đề gì của sản phẩm. Có thể định nghĩa
một cách dễ hiểu: Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình
được thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã được thiết
kế để làm, không thực hiện bất cứ thứ gì không mong muốn.
Trong kiểm thử phần mềm các thuật ngữ hay sử dụng như lỗi, sai, thất bại, sự
cố, chúng ta sẽ phân biệt các khái niệm này.
·

Lỗi (Error): Là các vấn đề lập trình viên phạm phải trong quá trình lập trình,
phát triển phần mềm.

·

Sai (Fault): Là kết quả của lỗi, từ lỗi sẽ dẫn đến sai, có thể phân thành 2 loại
như sau:
o Sai sót do đưa ra thừa: Đưa các thông tin không chính xác vào mô tả yêu
cầu phần mềm.
o Sai do bỏ sót: Khi người thiết kế thiếu một số phần đáng ra phải có trong
mô tả yêu cầu phần mềm.

·

Thất bại (Failure): Thất bại xảy ra khi một lỗi được thực thi, khi đó chức năng
phần mềm không thực hiện đúng như mong đợi.

·

Sự cố (Incident): Là những kết quả do sai sót mang đến, khi thất bại xuất hiện,
nó có thể hiển thị hoặc không hiển thị đối với người dùng, tức là rõ ràng hay
không rõ ràng đối với người dùng hoặc kiểm thử viên. Sự cố thể hiện bên ngoài
cho người dùng biết về sự tồn tại của thất bại.
Việc kiểm thử phần mềm được thực hiện lần lượt các bước theo quy trình, hình

vẽ dưới đây mô mả mô hình chung của quá trình kiểm thử.

5


Hình 2.1: Quy trình kiểm thử phần mềm
Một quy trình kiểm thử phần mềm được bắt đầu từ bước lập kế hoạch kiểm thử.

Dựa vào đặc tả phần mềm để thiết kế các ca kiểm thử. Dựa vào các ca kiểm thử đã viết
tiến hành tạo ra các dữ liệu kiểm tra, sau đó chạy chương trình theo kịch bản kèm theo
dữ liệu kiểm tra. Kết quả kiểm tra sẽ được so sánh với đầu ra mong muốn trong kịch
bản đã tạo. Lần lượt các thực hiện các ca kiểm thử, kết quả của mỗi ca kiểm thử là
pass hoặc fail, kết quả cuối cùng ta có là báo cáo kết quả kiểm thử (test report).
Quá trình thực hiện kiểm thử phần mềm sẽ sử dụng quy trình kiểm chứng và
thẩm định chất lượng phần mềm. Quy trình kiểm chứng đảm bảo phần mềm được xây
dựng theo đúng đặc tả ban đầu, quy trình thẩm định đảm bảo phần mềm đáp ứng được
yêu cầu của khách hàng. Trong thực tế, quy trình kiểm chứng phần mềm được áp dụng
trước quy trình thẩm định để đảm bảo phần mềm sau khi xây dựng đúng với thiết kế
ban đầu và thỏa mãn được yêu cầu của người dùng.
Kiểm thử phần mềm có thể chia làm 2 nhóm kỹ thuật chính: Kỹ thuật kiểm thử
tĩnh và kỹ thuật kiểm thử động [1].
·

Kiểm thử tĩnh không đòi hỏi phải chạy chương trình. Kỹ thuật kiểm thử tĩnh
được tiến hành dựa trên việc khảo sát các tài liệu được xây dựng trong quá trình
phát triển như tài liệu đặc tả nhu cầu người dùng, mô hình phần mềm, mã nguồn
phần mềm để tìm ra lỗi. Ngoài ra ta có thể sử dụng các kỹ thuật phân tích hình
thức như kiểm chứng mô hình, chứng minh định lý để chứng minh tính đúng

6


đắn của thiết kế và mã nguồn. Trong quy trình kiểm chứng và thẩm định chất
lượng phần mềm thì kỹ thuật kiểm thử tĩnh được sử dụng trong quy trình kiểm
chứng.
·

Kiểm thử động là kỹ thuật kiểm thử được thực hiện thông qua việc chạy chương

trình để kiểm tra các tác động của chương trình. Trong kỹ thuật này phần mềm
phải được biên dịch và chạy, mục đích để thẩm định chương trình phần mềm đã
hoạt động đúng và đầy đủ các chức năng theo mong muốn của người dùng hay
không.

2.1.2 Mức kiểm thử
Dựa trên các công đoạn phát triển phần mềm mà người ta chia thành các mức độ kiểm
thử khác nhau: Kiểm thử mức đơn vị, kiểm thử mức tích hợp, kiểm thử mức hệ thống,
kiểm thử mức chấp nhận.
Kiểm thử mức đơn vị (Unit test):
Là kiểm thử ở mức độ thấp nhất. Việc kiểm thử được thực hiện đối với các đơn
vị chương trình (các phương thức, hàm, lớp trong mã nguồn) một cách độc lập. Mục
đích của kiểm thử đơn vị là bảo đảm thông tin được xử lý và xuất khỏi đơn vị là chính
xác trong mối tương quan với dữ liệu nhập và chức năng của đơn vị. Điều này thường
đòi hỏi tất cả các nhánh bên trong đơn vị đều phải được kiểm tra để phát hiện nhánh
phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi trong một đơn vị
(Ví dụ: Chuỗi các lệnh sau điều kiện If và nằm giữa then ... else là một nhánh) nhằm
đảm bảo các thành phần trên hoạt động đúng như yêu cầu. Kiểm thử đơn vị thường
được làm bởi chính các lập trình viên viết chương trình.
Cùng với các mức kiểm thử khác, kiểm thử đơn vị cũng đòi hỏi phải chuẩn bị
trước các ca kiểm thử, trong đó chỉ định rõ dữ liệu đầu vào, các bước thực hiện và dữ
liệu đầu ra mong muốn. Ưu điểm của kiểm thử mức đơn vị là giúp người thực hiện dễ
xác định và sửa lỗi do phạm vi kiểm thử nhỏ. Việc phát hiện lỗi sớm làm giảm chi phí
kiểm thử so với việc phát hiện lỗi muộn ở các giai đoạn phát triển sau. Tuy nhiên,
kiểm thử mức đơn vị có nhược điểm là tốn thời gian, công sức thực hiện và không phát
hiện các lỗi xảy ra khi các đơn vị được tích hợp với nhau.
Kiểm thử mức tích hợp:

7

Mức kế tiếp với kiểm thử đơn vị là kiểm thử tích hợp. Sau khi các đơn vị
chương trình để cấu thành hệ thống đã được kiểm thử, chúng cần được kết nối với
nhau để tạo thành hệ thống đầy đủ và có thể làm việc. Kiểm thử tích hợp nhằm xem
xét các vấn đề có thể xảy ra khi hai hoặc nhiều thành phần (component, module) của
hệ thống tương tác với nhau.
Hai mục tiêu chính của kiểm thử tích hợp là: Phát hiện lỗi giao tiếp xảy ra giữa
các đơn vị. Tích hợp các thành phần đơn lẻ thành các hệ thống nhỏ (Subsystem) và hệ
thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống .
Có 4 loại kiểm thử trong kiểm thử tích hợp:
·

Kiểm thử cấu trúc: Kiểm thử cấu trúc nhằm bảo đảm các thành phần bên trong
của một chương trình chạy đúng và chú trọng đến hoạt động của các thành phần
cấu trúc nội tại của chương trình chẳng hạn các câu lệnh và nhánh bên trong.

·

Kiểm thử chức năng: Kiểm thử chức năng chú trọng đến chức năng của chương
trình và không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của
chương trình theo yêu cầu kỹ thuật.

·

Kiểm thử hiệu năng: Kiểm thử việc vận hành của hệ thống, đánh giá hiệu năng
của hệ thống ở các mức chịu tải khác nhau. Kiểm thử hiệu năng được dùng để
kiểm tra các thuộc tính chất lượng của hệ thống như khả năng mở rộng, độ tin
cậy, mức độ sử dụng tài nguyên.

·

Kiểm thử khả năng chịu tải của hệ thống: Là hình thức kiểm thử được sử dụng
để xác định tính ổn định của một hệ thống, kiểm thử các giới hạn của hệ thống,
đánh giá hiệu năng của hệ thống với một mức tải được định nghĩa trước.

Các chiến lược được áp dụng trong kiểm thử tích hợp:
·

Tích hợp từ trên xuống dưới (top – down).

·

Tích hợp từ dưới lên trên (bottom – up).

·

Tích hợp kẹp (sandwich).

·

Tích hợp Big Bang.

Kiểm thử mức hệ thống:
Là mức độ kiểm thử toàn bộ các chức năng của hệ thống phần mềm, bao gồm
tất cả các thành phần tương tác với nhau, hoạt động trong môi trường giống như môi

8


trường thực tế (hệ điều hành, cơ sở dữ liệu, kết nối mạng, khả năng tương thích với các

phần mềm khác).
Kiểm thử hệ thống thực hiện kiểm tra cả các hành vi chức năng của phần mềm
lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và
bảo mật. Mục đích của kiểm thử hệ thống là đảm bảo việc cài đặt tuân thủ đầy đủ các
yêu cầu được đặc tả của người dùng. Công việc này tốn nhiều công sức, vì có nhiều
khía cạnh về yêu cầu người dùng cần được kiểm thử.
Điểm khác nhau giữa kiểm thử tích hợp và kiểm thử hệ thống là kiểm thử hệ
thống chú trọng các hành vi và lỗi trên toàn hệ thống trong khi kiểm thử tích hợp lại
chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau.
Thông thường ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để bảo đảm mọi
đơn vị và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện kiểm tra
trên toàn hệ thống.
Các loại kiểm thử trong mức kiểm thử hệ thống [9]
·

Kiểm thử cơ bản (Basic test): Kiểm tra hệ thống có thể cài đặt, cấu hình và hoạt
động được hay không.

·

Kiểm thử chức năng (Functionality test): Kiểm tra toàn bộ các chức năng mà
chương trình cung cấp.

·

Kiểm thử khả năng chịu lỗi (Robustness test): Kiểm tra độ ổn định của hệ
thống.

·

Kiểm thử tương thích (Interoperability test): Kiểm tra hệ thống có thể hoạt động
tương thích với sản phẩm của bên thứ ba khác hay không.

·

Kiểm thử hiệu năng (Performance test): Kiểm tra hiệu năng của hệ thống có đáp
ứng được yêu cầu không, chẳng hạn thông lượng, thời gian xử lý yêu cầu.

·

Kiểm thử khả năng mở rộng (Scalability test): Xác định giới hạn mà hệ thống
có thể mở rộng: về tài nguyên, số lượng truy cập.

·

Kiểm thử khả năng chịu tải (Stress test): Kiểm tra giới hạn tối đa mà chương
trình có thể xử lý được khi có áp lực, ví dụ lượng truy cập tối đa vào hệ thống.

·

Kiểm thử khả năng ổn định quá tải (Load and stability test): Kiểm tra khả năng
hệ thống có thể hoạt động ổn định trong thời gian quá tải kéo dài hay không.

9


·

Kiểm thử độ tin cậy (Reliability test): Kiểm tra hệ thống có thể hoạt động trong
thời gian dài mà không bị lỗi.

·

Kiểm thử tài liệu (Documentation test): Kiểm tra tài liệu hướng dẫn sử dụng hệ
thống có dùng được và chính xác không.

·

Kiểm thử tính pháp lý (Regulatory test): Kiểm tra tính pháp lý của hệ thống có
phù hợp với quy định của nước sở tại hay không.

·

Kiểm tra khả năng bảo mật (Security test): Kiểm tra nhằm bảo đảm tính toàn
vẹn, bảo mật của dữ liệu và của hệ thống.

·

Kiểm tra khả năng phục hồi (Recovery test): Kiểm tra nhằm bảo đảm hệ thống
có khả năng khôi phục về trạng thái ổn định trước đó trong tình huống mất tài
nguyên hoặc mất dữ liệu. Loại kiểm thử này đặc biệt quan trọng đối với các hệ
thống giao dịch như ngân hàng trực tuyến.

Kiểm thử mức chấp nhận
Sau khi phần mềm được kiểm tra một cách tổng thể theo các mức độ như trên,
trước khi đưa vào sử dụng nó cần trải qua giai đoạn kiểm thử chấp nhận. Kiểm thử
chấp nhận được thực hiện bởi phía khách hàng và độc lập với nhóm phát triển. Mục
đích của giai đoạn này là kiểm tra, đánh giá phần mềm đã đáp ứng được các yêu cầu
của khách hàng đã đề ra không, có thể triển khai cho công việc thực tế của khách hàng
không. Các lỗi do khách hàng phát hiện được chuyển đến nhóm phát triển phần mềm

xử lý. Sau khi khách hàng kết thúc quá trình kiểm thử, nếu phần mềm được chấp nhận
nó sẽ được triển khai đưa vào sử dụng.
Kiểm thử hồi quy
Trong quá trình phát triển phần mềm, nếu có sự thay đổi về yêu cầu chức năng,
quy trình xử lý hay mã nguồn đòi hỏi kiểm tra lại chương trình phần mềm nhằm đảm
bảo chương trình vẫn hoạt động tốt và không phát sinh lỗi.
Thông thường, những hồi quy xảy ra khi thay đổi chương trình, một phần mới
của phần mềm được phát triển xung đột với mã tồn tại trước đó. Phương pháp phổ
biến của kiểm thử hồi quy bao gồm chạy lại những kiểm thử trước đó và kiểm thử xem
lỗi trước đây có xuất hiện lại không. Kiểm thử hồi quy không phải là một mức độ kiểm

10


thử như đã trình bày phía trên nhưng nó có thể được thực hiện lặp lại ở mỗi mức độ
kiểm thử và sử dụng lại các ca kiểm thử đã xây dựng trước đó.
Ưu điểm của kiểm thử hồi quy là đảm bảo được chương trình vẫn hoạt động tốt
sau khi có thay đổi, chỉnh sửa. Tuy nhiên nhược điểm của việc kiểm thử này là tốn
kém chi phí và thời gian thực hiện.
Ca kiểm thử
Ca kiểm thử là một tập hợp các giá trị đầu vào, các điều kiện tiên quyết thực thi,
các kết quả mong đợi và các điều kiện kết thúc được xây dựng cho mục đích kiểm thử.
Có 2 cách tiếp cận để thiết kế ca kiểm thử là kiểm thử hộp đen và kiểm thử hộp trắng
Kiểm thử hộp đen
Kiểm thử hộp đen là phương pháp kiểm thử hoàn toàn không quan tâm về cách
cư xử, cấu trúc, thuật toán hay mã nguồn bên trong của chương trình. Người thực hiện
kiểm thử chỉ thao tác với các chức năng mà chương trình cung cấp, kiểm tra việc đưa
dữ liệu đầu vào và dữ liệu đầu ra tương ứng có đúng không.
Ưu điểm của kiểm thử hộp đen là không yêu cầu người kiểm thử phải biết lập
trình, do không phụ thuộc vào thuật toán cài đặt nên nếu có sự thay đổi về mã nguồn

kiểm thử viên vẫn có thể sử dụng lại các ca kiểm thử đã xây dựng trước đó. Tuy nhiên
nhược điểm của kiểm thử hộp đen là khó khăn trong việc kiểm thử đầy đủ với bộ các
giá trị đầu vào. Ngoài ra phương pháp này chỉ phát hiện ra các lỗi có thể quan sát
được, nếu có lỗi cũng không chỉ ra được vị trí và nguyên nhân gây ra lỗi.
Kiểm thử hộp trắng
Kiểm thử hộp trắng là phương pháp kiểm thử dựa vào cấu trúc, thuật toán bên
trong chương trình để xác định chương trình có lỗi không. Người thực hiện kiểm thử
phải có kiến thức về lập trình và hiểu được cấu trúc chương trình đang kiểm thử.
Kiểm thử hộp trắng được chia làm 2 loại: Kiểm thử hộp trắng động và kiểm thử hộp
trắng tĩnh. Kiểm thử hộp trắng tĩnh là khảo sát thiết kế và mã nguồn của chương trình
để tìm lỗi mà không cần thực thi phần mềm. Kiểm thử hộp trắng động là sử dụng các
kỹ thuật kiểm thử luồng điều kiện, kiểm thử luồng dữ liệu động và kiểm thử miền.
Ưu điểm của kiểm thử hộp trắng là đảm bảo các câu lệnh được thực thi ít nhất
một lần, tránh các lỗi tiềm ẩn và tối ưu được mã nguồn. Tuy nhiên nhược điểm của
phương pháp này là tốn chi phí, thời gian khi áp dụng do yêu cầu kỹ thuật phức tạp.

11


Quá trình kiểm tra không phát hiện được lỗi do dữ liệu và việc kiểm thử tất cả các
đường dẫn trong chương trình là không khả thi, nếu có thay đổi về cài đặt thuật toán
trong mã nguồn thì phải thiết kế lại các ca kiểm thử.

2.2 Giới thiệu ngôn ngữ UML
UML (Unified Modeling Language) là một ngôn ngữ dùng để mô hình hóa hướng đối
tượng, được sử dụng rộng rãi trong công nghiệp phần mềm. UML cung cấp rất nhiều
biểu đồ và có thể sử dụng để trình bày nhiều góc nhìn khác nhau về một hệ thống
hướng đối tượng ở các bước khác nhau của vòng đời phát triển. Sử dụng UML, những
nhà phát triển có thể mô hình một hệ thống lớn và phức tạp.
Các thành phần chủ yếu của ngôn ngữ UML:

·

Hướng nhìn (View): Hướng nhìn chỉ ra những khía cạnh khác nhau của hệ
thống cần phải được mô hình hóa. Một hướng nhìn là một sự trừu tượng hóa
bao gồm các biểu đồ khác nhau. Qua việc định nghĩa một loạt các hướng nhìn,
mỗi hướng nhìn chỉ ra một khía cạnh riêng biệt của hệ thống người ta có thể tạo
nên một bức tranh hoàn thiện của hệ thống cần xây dựng

Hình 2.2: Các hướng nhìn trong UML
o Hướng nhìn use case (Use case view): Đây là hướng nhìn chỉ ra các khía
cạnh chức năng của một hệ thống nhìn từ hướng tác nhân bên ngoài.
Hướng nhìn use case là hướng nhìn dành cho khách hàng, nhà thiết kế,
nhà phát triển và người thử nghiệm. Nó được miêu tả qua các biểu đồ ca
sử dụng.

12


o Hướng nhìn logic (Logic view): Chỉ ra chức năng sẽ được thiết kế bên
trong hệ thống như thế nào, qua các khái niệm về cấu trúc tĩnh cũng như
ứng xử của hệ thống. Hướng nhìn logic được sử dụng cho các nhà thiết kế
và nhà phát triển. Nó miêu tả cấu trúc tĩnh (lớp, đối tượng, các quan hệ)
cũng như sự tác động sẽ xảy ra khi đối tượng gửi thông điệp cho nhau để
cung cấp chức năng đã định sẵn.
Cấu trúc tĩnh được miêu tả bằng biểu đồ lớp, biểu đồ đối tượng. Quá trình
mô hình hóa động được miêu tả trong biểu đồ trạng thái, biểu đồ trình tự,
biểu đồ tương tác và biểu đồ hoạt động.
o Hướng nhìn thành phần (Component view): Chỉ ra khía cạnh tổ chức của
các thành phần mã nguồn, miêu tả việc thực thi các module cũng như sự
phụ thuộc giữa chúng với nhau. Nó thường được sử dụng cho các nhà phát

triển.
o Hướng nhìn song song (Concurrent view): Chỉ ra sự tồn tại song song/
trùng hợp trong hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa
trong hệ thống. Hướng nhìn song song nhằm tới việc chia hệ thống thành
các quy trình (process) và các bộ xử lý (processor). Khía cạnh này vốn là
một thuộc tính phi chức năng của hệ thống, cho phép chúng ta sử dụng
một cách hữu hiệu các nguồn tài nguyên, thực thi song song cũng như xử
lý các sự kiện không đồng bộ từ môi trường, quan tâm đến vấn đề giao
tiếp và đồng bộ giữa các tiến trình.
o Hướng nhìn triển khai (Deployment view): Chỉ ra khía cạnh triển khai hệ
thống vào các kiến trúc vật lý, chỉ cho chúng ta sơ đồ triển khai về mặt vật
lý của hệ thống. Hướng nhìn triển khai dùng cho các đội ngũ phát triển,
người tích hợp, những người thử nghiệm hệ thống và được thể hiện bằng
các biểu đồ triển khai. Hướng nhìn này cũng bao gồm sự ánh xạ các thành
phần của hệ thống vào kiến trúc vật lý, ví dụ chương trình nào hay đối
tượng nào sẽ được thực thi trên máy tính nào.
·

Biểu đồ (Diagram): Là các hình vẽ bao gồm các kí hiệu phần tử mô hình hóa
được sắp xếp để minh họa một thành phần cụ thể hay một khía cạnh cụ thể của

13


hệ thống. Một mô hình hệ thống thường có nhiều loại biểu đồ khác nhau. UML
cung cấp 9 loại biểu đồ khác nhau được sử dụng trong những sự kết hợp khác
nhau để cung cấp tất cả các hướng nhìn của một hệ thống

Hình 2.3: 9 loại biểu đồ của ngôn ngữ UML
·

Phần tử mô hình hóa (model element): Các khái niệm được sử dụng trong các
biểu đồ được gọi là phần tử mô hình, thể hiện các khái niệm hướng đối tượng
quen thuộc ví dụ lớp, đối tượng, thông điệp cũng như các quan hệ giữa các khái
niệm này bao gồm liên kết, phụ thuộc, khái quát hóa. Một phần tử mô hình
thường được sử dụng trong nhiều biểu đồ khác nhau, nhưng nó luôn chỉ có một
ý nghĩa và một kí hiệu.

Hình 2.4: Các thành phần mô hình thường gặp trong UML

14


o Các loại quan hệ thường dùng:
ü

Kết nối (Association): Nối các phần tử và thực thể nối (link).

ü

Khái quát hóa (Generalization): Còn được gọi là tính thừa kế, có ý
nghĩa rằng phần tử này có thể là một sự chuyên biệt hóa của một
phần tử khác.

ü

Sự phụ thuộc (Dependency): Được sử dụng để chỉ ra rằng một
phần tử này phụ thuộc vào một phần tử khác.

ü

Kết tập (Agregation): Là một dạng của kết nối, trong đó phần tử
này chứa các phần tử khác.

·

Cơ chế chung (General Mechanism): Cơ chế chung cung cấp thêm những lời
nhận xét bổ sung, các thông tin cũng như các quy tắc ngữ pháp chung về một
phần tử mô hình. Chúng còn cung cấp thêm các cơ chế để có thể mở rộng ngôn
ngữ UML cho phù hợp với một phương pháp xác định (một quy trình, một tổ
chức hoặc người dùng).

2.2.1 Biểu đồ trạng thái
Biểu đồ trạng thái mô tả chu kì tồn tại của đối tượng từ khi nó sinh ra đến khi
nó bị phá hủy. Biểu đồ trạng thái được sử dụng để mô hình hóa các khía cạnh động của
lớp, bao gồm các thông tin: Các trạng thái của đối tượng, hành vi của đối tượng và sự
kiện tác động làm thay đổi trạng thái.
Thông thường biểu đồ trạng thái không được vẽ cho tất cả các lớp, mà chỉ được
vẽ riêng cho những lớp có các trạng thái được định nghĩa rõ ràng, các hành vi của lớp
bị ảnh hưởng và thay đổi qua các trạng thái khác nhau. Biểu đồ trạng thái cũng có thể
được vẽ cho hệ thống tổng thể.
Biểu đồ trạng thái giúp cho những người thiết kế, phân tích hệ thống và người
sử dụng biết được hành vi đối tượng, giúp đội ngũ phát triển hiểu và cài đặt chương trình.

Hình 2.5: Ví dụ biểu đồ trạng thái

15


Hình 2.5 mô tả trạng thái của một công tắc điện, từ trạng thái sẵn sàng (Idle) khi

bấm mở (start) sẽ chuyển sang trạng thái Running, ngược lại chọn đóng (Stop) trạng
thái sẽ được chuyển từ Running sang Idle.

2.2.2 Biểu đồ tuần tự
Biểu đồ tuần tự là một trong các loại biểu đồ UML. Các biểu đồ tuần tự là các
biểu đồ căn bản cho việc mô hình hóa các phương diện hành vi của một hệ thống [8],
đặc biệt phù hợp với các phần mềm hướng đối tượng, nơi chúng có thể biểu diễn các
luồng điều khiển trong các tương tác của các đối tượng. Biểu đồ tuần tự chỉ ra các đối
tượng tham gia vào quá trình tương tác, thời gian sống của từng đối tượng và trình tự
các thông điệp được trao đổi. Do vậy, nó thường được sử dụng như một mô hình giải
thích cho kịch bản ca sử dụng.
Các biểu đồ tuần tự chứa một loạt các đối tượng được biểu diễn bằng các đường
thẳng đứng. Trục thời gian có hướng từ trên xuống dưới trong biểu đồ, biểu đồ chỉ ra
sự trao đổi thông điệp giữa các đối tượng khi thời gian trôi qua. Các thông điệp được
biểu diễn bằng đường gạch ngang gắn liền với mũi tên (biểu thị thông điệp) nối liền
giữa những đường thẳng đứng thể hiện đối tượng. Trục thời gian và lời nhận xét khác
thường được đưa vào phần lề của biểu đồ.
Biểu đồ tuần tự có thể cũng chứa các thông tin thêm về luồng điều kiển trong
các tương tác, như các điều kiện, vòng lặp hoặc các hành vi phụ thuộc trạng thái [10].
UML 2.0 đã đề xuất một tập các tính năng mới cho các biểu đồ tuần tự, một vài tính
năng mới được biểu diễn trong ví dụ dưới.

16