Kiểm thử phần mềm trên cơ sở các biểu đồ UML

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

NGUYỄN THỊ NGA

KIỂM THỬ PHẦN MỀM TRÊN CƠ SỞ
CÁC BIỂU ĐỒ UML
Chuyên ngành: Khoa học máy tính
Mã số: 60-48-01

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

Người hướng dẫn khoa học: PGS. TS. Đỗ Trung Tuấn

Thái Nguyên - 2013


i

LỜI CAM ĐOAN
Tôi xin cam đoan rằng đây là luận văn nghiên cứu của tôi, có sự hỗ trợ
từ giáo viên hướng dẫn là PGS.TS Đỗ Trung Tuấn. Các nội dung nghiên cứu
và kết quả trong luận văn này là trung thực. Những số liệu trong các bảng
biểu phục vụ cho việc phân tích, nhận xét, đánh giá được tôi thu thập từ các
nguồn khác nhau có ghi trong phần tài liệu tham khảo. Ngoài ra, đề tài còn sử
dụng một số nhận xét, đánh giá cũng như số liệu của các tác giả, cơ quan tổ
chức khác, và cũng được thể hiện trong phần tài liệu tham khảo.
Nếu phát hiện có bất kỳ sự gian lận nào tôi xin hoàn toàn chịu trách
nhiệm trước Hội đồng, cũng như kết quả luận văn của mình.
Thái Nguyên, ngày 14 tháng 10 năm 2013

Học viên

Nguyễn Thị Nga


ii

LỜI CẢM ƠN
Để hoàn thành chương trình cao học và viết luận văn này, em đã nhận
được sự giúp đỡ và đóng góp nhiệt tình của các thầy cô trường Đại học Công
nghệ Thông tin và Truyền Thông, Đại học Thái Nguyên.
Trước hết, em xin chân thành cảm ơn các thầy cô trong bộ phận Đào
tạo sau đại học, Đại học Công nghệ thông tin và Truyền thông, trường Đại
học Thái Nguyên đã tận tình giảng dạy, trang bị cho em những kiến thức
quý báu trong suốt những năm học qua. Em xin gửi lời biết ơn sâu sắc tới
PGS. TS Đỗ Trung Tuấn đã dành rất nhiều thời gian và tâm huyết hướng
dẫn, chỉ bảo em trong suốt quá trình thực hiện đề tài.
Xin chân thành cảm ơn gia đình, bạn bè đã nhiệt tình ủng hộ, giúp đỡ,
động viên cả về vật chất lẫn tinh thần trong thời gian học tập và nghiên cứu.
Trong quá trình thực hiện luận văn, mặc dù đã rất cố gắng nhưng cũng
không tránh khỏi những thiếu sót. Kính mong nhận được sự cảm thông và tận
tình chỉ bảo của các thầy cô và các bạn.


iii

MỤC LỤC
LỜI CAM ĐOAN..............................................................................................i
Học viên............................................................................................................i
Nguyễn Thị Nga................................................................................................i

LỜI CẢM ƠN...................................................................................................ii
MỤC LỤC.......................................................................................................iii
DANH MỤC TỪ VIẾT TẮT............................................................................v
DANH MỤC BẢNG, HÌNH VẼ.....................................................................vi
MỞ ĐẦU...........................................................................................................1
Chương 1...........................................................................................................3
MỘT SỐ KHÁI NIỆM CƠ BẢN VỀ THIẾT KẾ PHẦN MỀM BẰNG UML
VÀ KIỂM THỬ PHẦN MỀM..........................................................................3
1.1.1. Một số khái niệm cơ bản............................................................................................................3
1.1.2. Các mô hình trong UML..............................................................................................................5
1.2.1. Một số khái niệm cơ bản..........................................................................................................15
1.2.2. Kiểm thử chức năng (Black box)...............................................................................................18
Các phương pháp kiểm thử hộp đen:...................................................................................18
1.2.2.1. Phân hoạch tương đương........................................................................................18
1.2.2.2. Phân tích giá trị biên.................................................................................................18
1.2.2.3. Kỹ thuật đồ thị nhân quả..........................................................................................19
Kĩ thuật này tuân theo bốn bước:.........................................................................................20
1.2.2.4. Kiểm thử so sánh......................................................................................................20
1.2.2.5. Kiểm thử dựa trên đặc tả.........................................................................................21
Ưu, nhược điểm....................................................................................................................22
1.2.3. Kiểm thử cấu trúc (White box).................................................................................................22
Các phương pháp kiểm thử hộp trắng:.................................................................................22
1.2.4. Công cụ kiểm thử phần mềm...................................................................................................23
Visual Studio Team System Test Edition................................................................................23
QuickTest Professional...........................................................................................................25
Ưu điểm:................................................................................................................................26
Nhược điểm:..........................................................................................................................26
JMeter....................................................................................................................................27

iv
JUnit, NUnit...........................................................................................................................27
Một số công cụ kiểm thử phổ biến khác...............................................................................28
Công cụ kiểm thử thành phần (component hoặc unit test):.................................................28
Công cụ kiểm thử chức năng (function test):........................................................................28
Công cụ kiểm thử chịu tải (performance/load-test):............................................................28
Công cụ theo dõi thực thi (performance-monitoring):.........................................................29
Công cụ quản lý kiểm thử (test-management):.....................................................................29

Chương 2.........................................................................................................30
KIỂM THỬ TÍCH HỢP TRÊN CƠ SỞ CÁC MÔ HÌNH UML....................30
2.1.1 Mô hình kiểm thử phần mềm dựa trên thành phần.................................................................30
2.1.2 Kiểm thử tích hợp trên cơ sở mô hình UML cho phần mềm dựa trên thành phần..................32
2.2.1 Mô hình tiếp cận trên mô hình trạng thái.................................................................................33
2.2.2 Các khái niệm mô hình trạng thái.............................................................................................33
2.2.3 Sử dụng mô hình.......................................................................................................................35
2.3.1 Các khái niệm mô hình trình tự.................................................................................................39
2.3.2 Sử dụng mô hình.......................................................................................................................40
2.4.1 Các khái niệm mô hình cộng tác................................................................................................41
2.4.2 Sử dụng mô hình.......................................................................................................................42

Chương 3.........................................................................................................45
XÂY DỰNG ỨNG DỤNG THỬ NGHIỆM...................................................45
3.2.1. Quy trình xây dựng tài liệu kiểm thử dựa trên mô hình UML..................................................47
3.2.2. Mô hình xây dựng use-case với bài toán thực tế.....................................................................48
3.2.3. Xây dựng luồng nghiệp vụ trên cơ sở cách tiếp cận mô hình cộng tác /tuần tự và trạng thái 48
Trình diễn một số kịch bản của chương trình.......................................................................66

KẾT LUẬN VÀ KIẾN NGHỊ.........................................................................68
Kết quả thực hiện...............................................................................................................................68

Kiến nghị tiếp tục................................................................................................................................68

TÀI LIỆU THAM KHẢO...............................................................................69


v

DANH MỤC TỪ VIẾT TẮT

actor

Tác nhân

Black box

Hộp đen

BVA

boundary value analysis

CNTT

Công nghệ thông tin

FRAME

Khung

IBM

Tên công ty máy tính

script

Kịch bản

UC

Biểu đồ UC (Use case diagrams)

UML

Ngôn ngữ mô hình hóa tổng quát

White box

Hộp trắng


vi

DANH MỤC BẢNG, HÌNH VẼ
Bảng 2.1. Bảng biến đổi trạng thái nhận được đặc tả biểu đồ trạng thái...Error:
Reference source not found
Hình 1.1. Các ký hiệu đồ họa của biểu đồ Use Cases.......................................5
Hình 1.2. UC cho hệ thống xử lý đặt hàng........................................................6
Hình 1.3. Các ký hiệu đồ họa của biểu đồ Lớp.................................................6
Hình 1.4. Biểu đồ lớp cho hệ thống xử lý đặt hàng...........................................7
Hình 1.5. Các ký hiệu đồ họa cho biểu đồ đối tượng........................................7

Hình 1.6. Biểu đồ đối tượng cho hệ thống xử lý đặt hàng................................7
Hình 1.7. Biểu đồ giao tiếp cho hệ thống xử lý đặt hàng..................................8
Hình 1.8. Biểu đồ tuần tự cho hệ thống xử lý đặt hàng.....................................8
Hình 1.9. Biểu đồ trạng thái cho đối tượng phụ tùng trong hệ thống xử lý đặt
hàng...................................................................................................................9
Hình 1.10. Biểu đồ hoạt động cho hệ thống xử lý đặt hàng............................10
Hình 1.11. Biểu đồ gói OrderSubmission.......................................................10
Hình 1.12. Ký hiệu đồ họa cho biểu đồ thành phần........................................11
Hình 1.13. Biểu đồ thành phần cho hệ thống xử lý đặt hàng..........................11
Hình 1.14. Biểu đồ triển khai cho hệ thống xử lý đặt hàng.............................12
Hình 1.15. Biểu đồ thời gian (ký hiệu ngắn gọn) mô tả đường sống của máy in
.........................................................................................................................12
Hình 1.16. Biểu đồ thời gian (ký hiệu dày) miêu tả trạng thái của máy in.....13
Hình 1.17. Biểu đồ tương tác của hệ thống quản lý kiểm kê..........................14
Hình 1.18. Tiến trình kỹ thuật nhân quả.........................................................20
Hình 1.19. Mô hình tổ chức Visual Studio Team System 2008 Team
Foundation Server...........................................................................................23
Hình 1.20. Giao diện QuickTest Professional.................................................25
Hình 1.21. Logo JMeter..................................................................................27


vii

Hình 2.1. Biểu đồ trạng thái sự đặc tả thành phần của máy bán hàng tự động
.........................................................................................................................37
Bảng 2.1. Bảng biến đổi trạng thái nhận được đặc tả biểu đồ trạng thái........38
Hình 2.2. Biểu đồ trình tự của thành phần máy chủ ATM..............................39
Hình 2.3. Biểu đồ cộng tác của thành phần máy chủ ATM............................41
Hình 2.4. Biểu đồ cộng tác cho PIN hợp lệ.....................................................42
Hình 3.1. Mô hình use case mô tả bài toán phát biểu.....................................48

Hình 3.2. Biểu đồ trình tự khởi động hệ thống...............................................49
Hình 3.3a. Biểu đồ trình tự tắt hệ thống..........................................................49
Hình 3.3b. Biểu đồ trạng thái bật và tắt hệ thống............................................50
Hình 3.4. Biểu đồ trình tự phiên......................................................................50
Hình 3.5. Biểu đồ trạng thái phiên..................................................................51
Hình 3.6. Biểu đồ trình tự giao dịch................................................................52
Hình 3.7. Biểu đồ trạng thái cho một loại giao dịch.......................................53
Hình 3.8. Biểu đồ cộng tác giao dịch rút tiền..................................................54
Hình 3.9. Biểu đồ cộng tác giao dịch gửi tiền.................................................55
Hình 3.10. Biểu đồ cộng tác giao dịch chuyển tiền.........................................56
Hình 3.11. Biểu đồ cộng tác giao dịch truy vấn..............................................56
Hình 3.12. Biểu đồ cộng tác PIN không hợp lệ..............................................57


1

MỞ ĐẦU
1. Đặt vấn đề
Công nghệ thông tin (CNTT) là sự kết hợp của hạ tầng phần cứng và
phần mềm. Hạ tầng phần cứng sẽ ngày càng mạnh trong khi phần mềm cũng
ngày càng lớn và phức tạp hơn. Chính vì lý do này mà công nghệ phần mềm
(quy trình phát triển phần mềm) đã được chú tâm bàn thảo từ rất sớm nhằm
tìm ra những phương pháp để phát triển phần mềm thuận tiện có chất lượng
cao đáp ứng tốt nhu cầu ngày càng đa dạng và phức tạp.
Tất cả các quy trình phát triển phần mềm đều trải qua các bước từ xác
định yêu cầu, phân tích, xây dựng, kiểm thử, cho tới triển khai và bảo trì.
Trong đó kiểm thử là một khâu không thể thiếu trong quá trình phát triển
phần mềm. Nhiều hệ thống phần mềm thất bại do lỗi không được tìm ra.
Kiểm thử phần mềm là một công việc khá phức tạp, tốn nhiều công sức. Quá
trình kiểm thử sẽ gồm một số pha kết hợp trong đó như: kiểm thử đơn vị,

kiểm thử chức năng, kiểm thử hệ thống, kiểm thử hồi quy và kiểm thử giải
pháp. Như vậy, kiểm thử phần mềm là điều kiện tiên quyết cho một sản phẩm
phần mềm có chất lượng tốt.
Ngày nay, phần lớn các hệ thống phần mềm được phát triển theo phương
pháp hướng đối tượng do chúng có nhiều ưu việt so với phương pháp truyền
thống. Quá trình phát triển phần mềm thường thông qua các mô hình UML.
Tuy nhiên, phương pháp hướng đối tượng đã đặt ra nhiều thách thức cho công
việc kiểm thử, ví dụ tương tác giữa các đối tượng làm cho việc tìm ra các lỗi
là rất khó khăn. Đã có nhiều nghiên cứu liên quan đến kiểm thử tích hợp trên
các mô hình UML. Nhưng cho đến nay vẫn chưa có quy trình chuẩn cho việc
áp dụng các mô hình UML vào việc kiểm thử phần mềm nói chung cũng như
kiểm thử các hệ thống phần mềm. Luận văn này nhằm mục tiêu nghiên cứu
học hỏi các kỹ thuật mô hình hoá hệ thống phần mềm bằng ngôn ngữ UML và
các kỹ thuật kiểm thử phần mềm.


2

Nội dung của đề tài
Xuất phát từ việc phân tích và mục tiêu nêu trên, nội dung của đề tài luận
văn sẽ bao gồm những vấn đề chính sau:
1. Nghiên cứu, tìm hiểu một số khái niệm cơ bản về thiết kế phần
mềm bằng UML và kiểm thử phần mềm.
2. Nghiên cứu kiểm thử tích hợp trên cơ sở các mô hình UML.
3. Xây dựng ứng dụng thử nghiệm
Cấu trúc luận văn
Luận văn sẽ được chia thành 3 chương chính dựa vào nội dung nêu trên:
• Chương 1: Một số khái niệm cơ bản về thiết kế phần mềm bằng
UML và kiểm thử phần mềm.
• Chương 2: Kiểm thử tích hợp trên cơ sở các mô hình UML.

• Chương 3: Xây dựng ứng dụng thử nghiệm.
Cuối luận văn là danh sách các tài liệu tham khảo và phụ lục.


3

Chương 1
MỘT SỐ KHÁI NIỆM CƠ BẢN VỀ THIẾT KẾ PHẦN MỀM
BẰNG UML VÀ KIỂM THỬ PHẦN MỀM
1.1. Thiết kế hệ thống bằng UML
Các hệ thống phần mềm thường được phát triển theo hai phương pháp:
• Phương pháp lập trình hướng cấu trúc.
• Phương pháp lập trình hướng đối tượng.
Phương pháp lập trình hướng cấu trúc: Chia dự án thành các chức năng.
Mỗi một chức năng cụ thể phải được giải quyết còn không ta lại chia chức
năng chưa được giải quyết thành các chức năng nhỏ hơn và xử lý chúng.
Nhược điểm của phương pháp này là các chức năng phụ thuộc vào dự án cụ
thể, như vậy khi pháp triển sang dự án khác ta không kế thừa được mà phải
viết lại, hơn nữa khó nâng cấp và bảo trì.
Phương pháp lập trình hướng đối tượng: Có nhiều ưu việt và tránh
được các nhược điểm so với phương pháp lập trình hướng cấu trúc phương
pháp lập trình hướng đối tượng là phương pháp phát triển phần mềm dựa
trên mô hình hệ thống thế giới thực. Bạn có thể nghĩ mô hình hướng đối
tượng là tập các đối tượng và mối quan hệ giữa chúng. Một đối tượng
thường bao gồm các thuộc tính (đặc trưng của đối tượng) và phương thức
hay thông điệp (hành động).
Hiện nay có rất nhiều ngôn ngữ lập trình và các công cụ phân tích thiết
kế hướng đối tượng. Trong luận văn này tôi sử dụng phân tích thiết kế theo
mô hình UML.
1.1.1. Một số khái niệm cơ bản

UML (Unified Modeling Language) là ngôn ngữ chuẩn cho việc tạo bản
thiết kế để mô tả cấu trúc và thiết kế của hệ thống phần mềm. UML là ngôn


4

ngữ ký hiệu cho phép các bên liên quan xem kiến trúc của hệ thống từ nhiều
góc độ. Có một vài công cụ có sẵn mà bạn có thể sử dụng để thiết kế hệ thống
phần mềm bằng sử dụng UML như là: Rational Rose, Jude, AgroUML, Visio
và Poseidon.
Phạm vi của UML: IBM đã mua lại Công ty phần mềm Rational, định
nghĩa UML như sau: ”UML là ngôn ngữ đặc tả, xây dựng, hình dung, tài
liệu”. Tài liệu phải bao gồm yêu cầu, kiến trúc, thiết kế trong nhóm các lớp và
các đối tượng hoặc giao diện, mã nguồn, kiểm thử, mẫu và các phiên bản của
hệ thống phần mềm.
Để hiểu tốt hơn, người ta chia định nghĩa UML theo các phần nhỏ hơn:
1. UML là ngôn ngữ đặc tả: UML cung cấp các ký hiệu lớp, đối
tượng, giao tiếp để nhóm phát triển định nghĩa phạm vi và nội
dung của hệ thống phần mềm.
2. UML là ngôn ngữ hình dung: UML cho phép bạn tạo ra các sơ đồ
để hình dung hệ thống phần mềm. Việc tạo sơ đồ cung cấp cách
hiểu tốt hơn về cấu trúc và nội dung của hệ thống. Ví dụ, một sơ
đồ mô tả quan hệ kế thừa của lớp là rõ ràng hơn mã lệnh.
3. UML là ngôn ngữ xây dựng: UML cho phép tạo ra mã lệnh từ mô
hình UML. Việc tạo mã từ mô hình UML gọi là cơ chế thuận,
UML cho phép cơ chế nghịch có nghĩa bạn có thể tái tạo mô hình
từ mã lệnh.
4. UML là ngôn ngữ tài liệu: Bạn có thể sử dụng biểu đồ như tài liệu
đầu vào cho các pha trong vòng đời phát triển phần mềm.
5. Các khối xây dựng của UML

Bao gồm các thành phần cần thiết để tạo ra mô hình của hệ thống phần
mềm, có ba loại là:
• Các thành phần cơ bản: bao gồm các thành phần tĩnh, động, chú
thích của UML.


5
• Mối quan hệ: mô tả mối quan hệ giữa các thành phần khác nhau
của mô hình UML.
• Biểu đồ: mô tả cách nhìn khác nhau của các hệ thống đồ họa. Biểu
đồ cho phép bạn hình dung hệ thống từ nhiều góc độ.
1.1.2. Các mô hình trong UML
UML cung cấp 12 biểu đồ sau đây để miêu tả cấu trúc và thiết kế của hệ
thống phần mềm:
1. Biểu đồ UC (Use case diagrams)
2. Biểu đồ lớp (Class diagrams)
3. Biểu đồ đối tượng (Object diagrams)
4. Biểu đồ giao tiếp (Communication diagrams)
5. Biểu đồ tuần tự (Sequence diagrams)
6. Biểu đồ trạng thái (State Machine diagrams)
7. Biểu đồ hoạt động (Activity diagrams)
8. Biểu đồ gói (Package Diagrams)
9. Biểu đồ thành phần (Component diagrams)
10.Biểu đồ triển khai (Deployment diagrams)
11.Biểu đồ thời gian (Timing Diagrams)
12.Biểu đồ tương tác (Interaction Overview Diagrams)
Biểu đồ UC (Use case diagrams): Mô tả các thao tác khác nhau mà một
hệ thống hoạt động. Nó chứa các Use Cases (trường hợp sử dụng), actors (tác
nhân) và mối quan hệ giữa chúng. Tác nhân miêu tả người sử dụng bên ngoài
hệ thống tương tác với các Use Cases.

Hình 1.1. Các ký hiệu đồ họa của biểu đồ Use Cases


6

Một biểu đồ UC có thể được vẽ cho bất cứ hệ thống phần mềm. Ví dụ
trong hệ thống xử lý đặt hàng, phòng kiểm kê đưa yêu cầu tới bộ phận kiểm
soát bên ngoài kho. Trong trường hợp này, phòng kiểm kê là một tác nhân sử
dụng hệ thống để đặt hàng cho các bộ phận. Tương tự, phòng kiểm kê cũng
nhận nguồn cung cấp để cập nhật kho. Các UC cho Actor phòng kiểm kê
(Inventory Department) là đặt hàng (Order Parts) và nhận nguồn cung cấp
(Accept Supply).

Hình 1.2. UC cho hệ thống xử lý đặt hàng

Biểu đồ lớp (Class diagrams): Mô tả tập các lớp, giao tiếp và mối quan
hệ của chúng. Bạn có thể miêu tả lớp trong hình chữ nhật với ba phần. Phần
đầu hiển thị tên lớp. Phần thứ hai hiển thị thuộc tính của lớp. Phần thứ ba hiển
thị các phương thức của lớp.

Hình 1.3. Các ký hiệu đồ họa của biểu đồ Lớp
Người ta có thể vẽ biểu đồ lớp bằng cách nhận biết các lớp trong hệ
thống. Ví dụ, các lớp được nhận biết trong hệ thống xử lý đặt hàng là nhà
cung cấp (Supplier) và phụ tùng (Parts). Các thuộc tính khác nhau của lớp


7

Supplier là mã nhà cung cấp (scode), tên nhà cung cấp (name) và thành phố

(city) và các phương thức của lớp Supplier là cung cấp (supply()) và nhận
thanh toán (receivepayment()). Các thuộc tính khác nhau của lớp Parts là mã
phụ tùng (pcode), tên phụ tùng (name), số lượng đặt (qty_ordered), số lượng
nhận (qty_received) và số lượng không chấp nhận (qty_rejected) và các
phương thức của lớp Parts là đặt hàng (order()), nhận (received()) và cập nhật
kiểm kê (updateinventory()).

Hình 1.4. Biểu đồ lớp cho hệ thống xử lý đặt hàng
Biểu đồ đối tượng (Object diagrams): Một biểu đồ đối tượng miêu tả
một thể hiện của biểu đồ lớp. Bạn miêu tả biểu đồ đối tượng trong hình chữ
nhật gồm hai phần. Phần đầu hiển thị tên đối tượng trước tên lớp. Phần thứ
hai hiển thị thuộc tính cả đối tượng.

Hình 1.5. Các ký hiệu đồ họa cho biểu đồ đối tượng
Có thể vẽ biểu đồ đối tượng bằng cách nhận biết lớp trong hệ thống.

Hình 1.6. Biểu đồ đối tượng cho hệ thống xử lý đặt hàng


8

Biểu đồ giao tiếp (Communication diagrams): Miêu tả tương tác giữa
các đối tượng bằng thông điệp. Ví dụ miêu tả sự tương tác giữa phòng kiểm
kê (Inventory department) và đối tượng của lớp cung cấp (supplier) của hệ
thống xử lý đặt hàng.

Hình 1.7. Biểu đồ giao tiếp cho hệ thống xử lý đặt hàng
Biểu đồ lớp cũng được gọi là biểu đồ cộng tác.
Biểu đồ tuần tự (Sequence diagrams): Miêu tả tương tác giữa các đối
tượng bằng thông điệp theo thứ tự thời gian. Sự khác biệt giữa biểu đồ trình

tự và biểu đồ giao tiếp đó là: biểu đồ giao tiếp nhấn mạnh về tổ chức cấu trúc
của các đối tượng trái ngược với biểu đồ trình tự thì hiển thị thông điệp trao
đổi giữa các đối tượng theo thứ tự thời gian.
Bạn có thể vẽ biểu đồ tuần tự cho hệ thống bằng cách sử dụng các lớp và
các UC được nhận biết bởi hệ thống.

Hình 1.8. Biểu đồ tuần tự cho hệ thống xử lý đặt hàng
Trong hệ thống xử lý đặt hàng, phòng kiểm kê đặt hàng với nhà cung cấp
supplier, nhà cung cấp supplier supp1 cung cấp phụ tùng cho phòng kiểm kê.


9

Biểu đồ trạng thái (State Machine diagrams): Cho thấy một lớp có phản
ứng như thế nào khi có một sự kiện xuất hiện. Bạn có thể vẽ biểu đồ trạng thái
bằng cách sử dụng các lớp và các UC được nhận biết bởi hệ thống. Ví dụ,
trong hệ thống xử lý đặt hàng lớp Parts có một thuộc tính re-order. Một đơn
hàng được đặt khi kho đạt đến mức độ cụ thể. Trong trường hợp này thuộc
tính re-order được đặt là true. Sau khi nhà cung cấp cung cấp phụ tùng thì
thuộc tính re-order lại được đặt lại là false.

Hình 1.9. Biểu đồ trạng thái cho đối tượng phụ tùng trong hệ thống xử lý
đặt hàng
Biểu đồ hoạt động (Activity diagrams): Miêu tả các thao tác khác nhau
được thực hiện bởi một lớp. Biểu đồ hoạt động miêu tả luồng điều khiển từ
hoạt động này tới hoạt động khác.
Bạn có thể vẽ biểu đồ hoạt động bằng cách nhận biết các hoạt động được
thực hiện bởi các lớp khác nhau trong hệ thống. Ví dụ, các hoạt động khác
nhau trong hệ thống xử lý đặt hàng là đặt hàng (placing order), chấp nhận hồ
sơ mời thầu (accepting tenders) và nhận nhà cung cấp (receiving supply).

10

Hình 1.10. Biểu đồ hoạt động cho hệ thống xử lý đặt hàng
Biểu đồ gói (Package Diagrams): Tất cả các lớp và giao tiếp có quan hệ
với nhau của hệ thống thì gom nhóm cùng nhau vào một gói. Để miêu tả các
lớp và giao tiếp có liên quan với nhau UML cung cấp biểu đồ gói. Biểu đồ gói
trợ giúp trong việc miêu tả các gói khác nhau trong hệ thống phần mềm và
mối quan hệ phụ thuộc giữa chúng.

Hình 1.11. Biểu đồ gói OrderSubmission


11

Biểu đồ thành phần (Component diagrams): Kết hợp các gói hoặc các thực
thể riêng lẻ để tạo lên các thành phần. Có thể miêu tả các thành phần khác nhau
và mối quan hệ phụ thuộc của chúng bằng sử dụng biểu đồ thành phần.

Hình 1.12. Ký hiệu đồ họa cho biểu đồ thành phần.
Để hiểu biểu đồ thành phần miêu tả các thành phần và mối quan hệ phụ
thuộc của chúng, xem ví dụ thành phần thực thi xử lý đặt hàng (orderprocess)
có thủ tục đặt hàng (order) và cung cấp (supply). Thành phần thực thi đặt
hàng phụ thuộc file order.cs cho việc đặt phụ tùng. Tương tự vậy, thành phần
thực thi đặt hàng phụ thuộc file processupply.cs cho việc xử lý cung cấp.

Hình 1.13. Biểu đồ thành phần cho hệ thống xử lý đặt hàng
Biểu đồ triển khai (Deployment diagrams): Cho thấy vị trí vật lý của
các thành phần trong các nút trên một mạng. Biểu đồ thành phần được vẽ

bằng cách nhận biết các nút (node) và các thành phần (components). Ví dụ
trong hệ thống xử lý đặt hàng, thành phần orderprocess.exe là được đặt ở
nút khách (node client) và thành phần cơ sở dữ liệu (database component)
là được đặt bên nút chủ (database server node). Việc yêu cầu dữ liệu cho hệ
thống xử lý đặt hàng là được chuyển tới máy chủ cơ sở dữ liệu thông qua
Processor Server.


12

Hình 1.14. Biểu đồ triển khai cho hệ thống xử lý đặt hàng
Biểu đồ thời gian (Timing Diagrams): Thường được sử dụng để miêu
tả sự thay đổi trạng thái và giá trị của một hoặc nhiều đối tượng trong một
khoảng thời gian. Biểu đồ thời gian thường được sử dụng thiết kế phần
mềm nhúng.
Biểu đồ thời gian có hai loại:
1. Ký hiệu ngắn gọn (Concise notation)
2. Ký hiệu dày (Robust notation)
Ký hiệu ngắn gọn (Concise notation): Trong biểu đồ này có giá trị
đường sống mô tả sự thay đổi giá trị của các đối tượng trọng khoảng thời
gian. Thời gian trôi qua được thể hiện trên trục X và giá trị là được hiển thị
bằng các vạch chỉ cho biết sự thay đổi giá trị.

Hình 1.15. Biểu đồ thời gian (ký hiệu ngắn gọn) mô tả đường sống của
máy in


13

Ký hiệu dày (Robust notation): Đường sống trạng thái thường để miêu tả

trạng thái của đối tượng qua một giai đoạn thời gian. Trục X miêu tả thời gian
trôi qua, trục Y miêu tả tập các trạng thái.

Hình 1.16. Biểu đồ thời gian (ký hiệu dày) miêu tả trạng thái của máy in
Biểu đồ tương tác (Interaction Overview Diagrams): Cung cấp tổng quan
về biểu đồ tương tác. Biểu đồ tương tác bao gồm những loại biểu đồ sau:
•

Biểu đồ tuần tự (Sequence diagram)

•

Biểu đồ giao tiếp (Communication diagram)

•

Biểu đồ thời gian (Timing diagram)

•

Biểu đồ tương tác (Interaction overview diagram)
Biểu đồ tương tác miêu tả sự tương tác logic giữa biểu đồ tương tác và

luồng xử lý.
Biểu đồ tương tác là một biến thể của biểu đồ hoạt động. Kết quả là, hầu
như các ký hiệu của biểu đồ được sử dụng trong biểu đồ tương tác là giống
với các ký hiệu của biểu đồ hoạt động. Tuy nhiên thay vì các phần tử biểu đồ
hoạt động, biểu đồ tương tác sử dụng các phần tử sau:
•

Phẩn tử tương tác

•

Phần tử xảy ra tương tác


14

Hình 1.17. Biểu đồ tương tác của hệ thống quản lý kiểm kê
Các phần tử tương tác hiển thị biểu đồ tương tác nội tại, biểu đồ đó có
thể là biểu đồ tuần tự, biểu đồ giao tiếp, biểu đồ thời gian hoặc biểu đồ tương
tác. Các loại của biểu đồ tương tác là miêu tả bởi khung (frame) với mã miêu
tả của biểu đồ trong tiêu đề của khung. Ví dụ biểu đồ trình tự là được miêu tả
bằng cách viết mã “sd” trong tiêu đề khung.
Các phần tử xảy ra tương tác là tham chiếu tới biểu đồ tương tác đang
tồn tại. Các phần tử xảy ra tương tác được đại diện bởi khung với “ref” trong
tiêu đề khung. Tên của biểu đồ chỉ cho biết nội dung của khung.
1.2. Kỹ thuật kiểm thử phần mềm
Kiểm thử phần mềm là một trong những khâu quan trọng của quy trình
phát triển phần mềm nhằm kiểm tra xem phần mềm làm ra có những lỗi gì
cần khắc phục. Kiểm thử không thể chứng minh được phần mềm là hết lỗi mà
nó chỉ giúp cho người viết mã nguồn tìm ra và có biện pháp khắc phục càng
nhiều lỗi càng tốt.


15

Bản chất của kiểm thử phần mềm là các cách thức làm việc với máy tính
và chương trình, tuy nhiên với những phần mềm lớn, việc kiểm thử cũng yêu

cầu có sự phối hợp của nhiều nhóm chuyên môn phụ trách các thành phần
riêng biệt, cho nên kiểm thử cũng cần các kĩ năng của con người.
Để thực hiện tốt công việc kiểm thử, ngoài nắm vững các kĩ thuật kiểm
thử điển hình, kiểm thử viên cũng cần xây dựng kế hoạch kiểm thử, chuẩn bị
dữ liệu kiểm thử, tiến hành kiểm thử, viết báo cáo về kết quả kiểm thử, và cần
biết quản lí toàn bộ công việc kiểm thử.
Kiểm thử cần được nhìn theo nhiều góc độ khác nhau liên quan tới phần
mềm: kiểm thử chức năng, kiểm thử hiệu năng, cấu hình, an ninh... và liên
quan tới qui trình kiểm thử: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ
thống, kiểm thử chấp nhận; đồng thời phải thực hiện quản lí toàn bộ quá trình
kiểm thử: ghi lại hoàn cảnh lỗi, việc sửa chữa, kiểm thử rà lại...
1.2.1. Một số khái niệm cơ bản
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 cho người có lợi ích liên quan những thông tin về chất lượng của sản
phẩm hay dịch vụ phần mềm.
Kiểm thử là một quá trình thực thi chương trình với mục đích là tìm ra
các lỗi hay khiếm khuyết của phần mềm nhằm đảm bảo hiệu quả hoạt động
tối ưu của phần mềm trong nhiều ngành khác nhau.
•Một trường hợp kiểm thử tốt là một trường hợp có khả năng lớn trong
việc tìm ra những lỗi chưa được phát hiện.
•Một trường hợp kiểm không tốt (không thành công) là một trường hợp
mà khả năng tìm thấy những lỗi chưa biết đến là rất ít.


16
• Mục tiêu của kiểm thử phần mềm là thiết kế những trường hợp kiểm
thử để có thể phát hiện một cách có hệ thống những loại lỗi khác nhau và thực
hiện việc đó với lượng thời gian và tài nguyên ít nhất có thể.
Nếu kiểm thử được tiến hành thành công thì nó sẽ làm lộ ra một cách

có hệ thống những lớp lỗi khác nhau trong phần mềm. Kiểm thử chứng tỏ
rằng các chức năng phần mềm dường như làm theo đúng đặc tả và các yêu
cầu về hiệu năng, kĩ thuật được đáp ứng. Bên cạnh đó, dữ liệu thu thập
được khi việc kiểm thử được tiến hành đưa ra một chỉ dẫn tốt về độ tin cậy
phần mềm. Nhưng kiểm thử không thể chứng minh được việc không có
khiếm khuyết, nó chỉ có thể chứng minh rằng khiếm khuyết phần mềm đã
được phát hiện và sửa chữa.
Kiểm chứng và kiếm tra đúng đắn (Verification và Validation (V&V))
Mục đích của Verification là để đảm bảo các sản phẩm được lựa chọn
thỏa mãn yêu cầu đối với chúng. Vùng quy trình Verification bao gồm: chuẩn
bị kiểm thử, thực hiện kiểm thử và xác định hành động sửa chữa.
Vùng quy trình Verification và Validation tương tự như nhau nhưng
chúng xác định các vấn đề khác nhau. Validation cho thấy sản phẩm thỏa mãn
mục đích sử dụng ban đầu hay chưa, trong khi Verification xác định sản phẩm
hoạt động có đúng không, nói cách khác Validation cho thấy “Bạn đã tạo ra
đúng sản phẩm cần tạo chưa?” còn Verification đảm bảo “Bạn đã tạo ra sản
phẩm đó theo cách đúng đắn hay chưa”.
Mục tiêu V&V cụ thể cho mỗi sản phẩm phải được xác định dựa trên
từng dự án. Sụ xác định rõ ràng này bị ảnh hưởng bởi những ràng buộc, độ
phức tạp của phần mềm, và mức độ sai sót của nó.
Nói chung, mục tiêu của V&V là để đảm bảo rằng phần mềm sản xuất
ra đáp ứng được những đòi hỏi của người sử dụng đã chỉ ra trong bản “đặc tả
yêu cầu”. Vì vậy, tất cả các vấn đề được đề cập trong các bản đặc tả yêu cầu


17

và chi tiết kĩ thuật của sản phẩm phải là một trong những đích đến quan trọng
của hoạt động V&V. Vì thế các phương pháp V&V sẽ tập trung vào các phần
chức năng và hiệu quả thực thi các yêu cầu và các chi tiết kỹ thuật cho từng

sản phẩm. Những phương pháp tiếp cận khác để xác định liệu một sản phẩm
với những yêu cầu và đặc điểm kỹ thuật của nó có thỏa mãn được các yếu tố
sau không: sự an toàn, tính khả chuyển, tính khả dụng, tính bảo dưỡng được,
tính tiện ích, tính bảo mật,…Nhưng ở Việt Nam, những phần mềm có thể đạt
được những tính năng này còn ít. Cách tiếp cận V&V thông thường tập trung
chủ yếu vào kiểm tra mức thỏa mãn các yêu cầu và về kĩ thuật thường được
mô tả trong những bài giảng. Những hình ảnh rộng hơn về "bảo đảm chất
lượng của phần mềm" sẽ được diễn giải thêm ở những hoạt động khác như
xemina, hội thảo,…
Giới hạn phạm vi hoạt động của V&V vào các tính năng và hiệu quả của
phần mềm được tổng hợp thành năm mục tiêu V&V dưới đây. Những mục
tiêu này cung cấp một khuôn khổ thống nhất, hợp lí để có thể để xác định tính
khả dụng của nhiều phương pháp tiếp cận và kỹ thuật V&V khác nhau.
• Tính chính xác (Correctness): Trong phạm vi mà các sản phẩm là
lỗi tự do
• Tính thống nhất (Consistency): Trong phạm vi mà các sản phẩm là
nhất quán trong chính nó và với các sản phẩm khác.
• Tính chất cần thiết (Necessity): Ở mức độ mà tất cả mọi thứ trong
các sản phẩm là rất cần thiết (không có chi tiết nào dư thừa).
• Tính đầy đủ (Sufficiency): Phạm vi mà tới đó sản phẩm đã hoàn
thành đầy đủ các chức năng được yêu cầu.
• Tính thực thi (Performance): Phạm vi mà tới đó sản phẩm thỏa
mãn những yêu cầu thực hiện của nó.