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

NGA




KIỂM THỬ PHẦN MỀM TRÊN CƠ SỞ
CÁC BIỂU ĐỒ UML

: 60-48-01








N Trung Tuấn





- 2013
i

Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu
MỤC LỤC
LỜI CAM ĐOAN i
LỜI CẢM ƠN ii
MỤC LỤC iii
DANH MỤC TỪ VIẾT TẮT v
DANH MỤC HÌNH VẼ vi
MỞ ĐẦU 1
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 3
1.1. Thiết kế hệ thống bằng UML 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. Kỹ thuật kiểm thử phần mềm 14
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
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
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
1.2.3. Kiểm thử cấu trúc (White box) 22
1.2.4. Công cụ kiểm thử phần mềm 23
Chương 2: KIỂM THỬ TÍCH HỢP TRÊN CƠ SỞ CÁC MÔ HÌNH UML 30
2.1. Phƣơng pháp 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
iv
Số hóa bởi trung tâm học liệu
2.2. Kiểm thử trên cơ sở mô hình trạng thái 33
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. Kiểm thử trên cơ sở mô hình trình tự 39
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. Kiểm thử trên cơ sở mô hình cộng tác 40
2.4.1 Các khái niệm mô hình cộng tác 40
2.4.2 Sử dụng mô hình 42
Chương 3: XÂY DỰNG ỨNG DỤNG THỬ NGHIỆM 45
3.1. Bài toán 45
3.2. Phân tích thiết bài toán trên cơ sở UML 47
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
3.3. Sinh test case, test path để kiểm thử trên mô hình UML 58
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
TÀI LIỆU THAM KHẢO 69

v
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu
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 38
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
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
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
vii
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu
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

Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu

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
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu

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
1
.
.

Ký hiệu ngắn gọn (Concise notation)
2
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
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu

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
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu
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
Số hóa bởi trung tâm học liệu
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ó.