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

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.. Biểu đồ thành phần

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

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ảngbiể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ácnguồ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áchnhiệ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

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ôngnghệ 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 Đàotạo sau đại học, Đại học Công nghệ thông tin và Truyền thông, trường Đạihọc Thái Nguyên đã tận tình giảng dạy, trang bị cho em những kiến thứcquý 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ớiPGS TS Đỗ Trung Tuấn đã dành rất nhiều thời gian và tâm huyết hướngdẫ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ũngkhông tránh khỏi những thiếu sót Kính mong nhận được sự cảm thông và tậntình chỉ bảo của các thầy cô và các bạn

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

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

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

Black box Hộp đen

BVA boundary value analysis

UC Biểu đồ UC (Use case diagrams)

UML Ngôn ngữ mô hình hóa tổng quátWhite box Hộp trắng

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

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

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ũngngà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ằmtìm ra những phương pháp để phát triển phần mềm thuận tiện có chất lượngcao đá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ểnphầ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ảiphá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ẩmphầ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ươngpháp hướng đối tượng do chúng có nhiều ưu việt so với phương pháp truyềnthố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ôngviệ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êncá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ứuhọ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

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ậnvă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ầnmề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ằngUML 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

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ứcnă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ảiviế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ươngpháp lập trình hướng đối tượng là phương pháp phát triển phần mềm dựatrên mô hình hệ thống thế giới thực Bạn có thể nghĩ mô hình hướng đốitượng là tập các đối tượng và mối quan hệ giữa chúng Một đối tượngthường bao gồm các thuộc tính (đặc trưng của đối tượng) và phương thứchay 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ảnthiế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

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ềugó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ốngphầ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, địnhnghĩa UML như sau: ”UML là ngôn ngữ đặc tả, xây dựng, hình dung, tàiliệ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, đốitượng, giao tiếp để nhóm phát triển định nghĩa phạm vi và nộidung 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áchhiể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ầnmề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

• Mối quan hệ: mô tả mối quan hệ giữa các thành phần khác nhaucủ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ácnhâ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

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ểmsoá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ũngnhậ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ểnthị 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

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ậnthanh 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ượngnhận (qty_received) và số lượng không chấp nhận (qty_rejected) và cácphương thức của lớp Parts là đặt hàng (order()), nhận (received()) và cập nhậtkiể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

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 đốitượ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úccủ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ấpsupplier, nhà cung cấp supplier supp1 cung cấp phụ tùng cho phòng kiểm kê

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áibằ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 đơnhàng được đặt khi kho đạt đến mức độ cụ thể Trong trường hợp này thuộctí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 đượcthực hiện bởi các lớp khác nhau trong hệ thống Ví dụ, các hoạt động khácnhau 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)

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áclớp và giao tiếp có liên quan với nhau UML cung cấp biểu đồ gói Biểu đồ góitrợ 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

Biểu đồ thành phần (Component diagrams): Kết hợp các gói hoặc các thựcthể 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 đặthàng phụ thuộc file order.cs cho việc đặt phụ tùng Tương tự vậy, thành phầnthự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ủacá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 quaProcessor Server

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ộtkhoảng thời gian Biểu đồ thời gian thường được sử dụng thiết kế phầnmề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ờigian 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

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 giantrô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ầunhư các ký hiệu của biểu đồ được sử dụng trong biểu đồ tương tác là giốngvớ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

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ươngtá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 đangtồ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” trongtiê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ìnhphá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àngnhiều lỗi càng tốt

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êucầ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ầnriê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ểmthử đ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ầnbiế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ầnmềm: kiểm thử chức năng, kiểm thử hiệu năng, cấu hình, an ninh và liênquan 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ìnhkiể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ằmcung 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ảnphẩ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 racác lỗi hay khiếm khuyết của phần mềm nhằm đảm bảo hiệu quả hoạt độngtố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 trongviệ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

• Mục tiêu của kiểm thử phần mềm là thiết kế những trường hợp kiểmthử để 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ựchiệ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êucầ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ậyphầ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ọnthỏ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ưngchúng xác định các vấn đề khác nhau Validation cho thấy sản phẩm thỏa mãnmục đích sử dụng ban đầu hay chưa, trong khi Verification xác định sản phẩmhoạ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ảnphẩ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êntừ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

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ọngcủ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ầnchứ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ừngsả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ẩmvớ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 trungchủ 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ấtlượ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ủaphần mềm được tổng hợp thành năm mục tiêu V&V dưới đây Những mụctiêu này cung cấp một khuôn khổ thống nhất, hợp lí để có thể để xác định tínhkhả 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ứ trongcá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ànthà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ỏamãn những yêu cầu thực hiện của nó

1.2.2 Kiểm thử chức năng (Black box)

Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen,hướng dữ liệu, hay hướng vào/ra Kiểm thử hộp đen xem chương trình như làmột “hộp đen” Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử

và cấu trúc bên trong của chương trình Thay vào đó, tập trung vào tìm cáctrường hợp mà chương trình không thực hiện theo các đặc tả của nó Theohướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả

Các phương pháp kiểm thử hộp đen:

• Phân hoạch tương đương - Equivalence partitioning

• Phân tích giá trị biên - Boundary value analysis

• Kỹ thuật đồ thị nhân quả

• Kiểm thử so sánh

• Kiểm thử dựa trên đặc tả - Specification-base testing

1.2.2.1 Phân hoạch tương đương

Là một phương pháp kiểm thử hộp đen phân chia tập dữ liệu thành từnglớp tương đương Mỗi lớp hoặc là đúng hay sai, chỉ cần kiểm tra một số giá trịđặc trưng của nó, từ đó rút ra được số ca kiểm thử Mỗi trường hợp kiểm thửđơn độc lí tưởng sẽ làm lộ ra một lớp lỗi (như xử lý sai cho tất cả dữ liệu là kítự) mà nếu không có nó thì có thể đòi hỏi phải thực hiện nhiều trường hợpkiểm thử trước khi phát hiện ra lỗi chung Phân hoạch tương đương cố gắngxác định ra một số trường hợp kiểm thử làm lộ ra một lớp lỗi, do đó làm giảmtổng số các trường hợp kiểm thử phải được xây dựng

1.2.2.2 Phân tích giá trị biên

Vì một số lớn các lỗi có khuynh hướng xuất hiện tại biên của miền vào

hơn là tại “trung tâm” nên phân tích giá trị biên - (BVA) đã được phát triển

như một kĩ thuật kiểm thử Việc phân tích giá trị biên dẫn tới việc chọn lựacác trường hợp kiểm thử thực hiện tại các giá trị cận

Phân tích giá trị biên là kĩ thuật thiết kế trường hợp kiểm thử, để bổsung thêm cho phân hoạch tương đương Thay vì chọn bất kỳ phần tử nào củamột lớp tương đương, BVA chọn các trường hợp kiểm thử tại các giá trị biêncủa lớp phân hoạch Phân tích giá trị biên tương tự về nhiều khía cạnh vớiphân hoạch tương đương:

1 Nếu một điều kiện vào xác định ra một miền được giới hạn bởi các giá trị a và b, thì các trường hợp kiểm thử nên được thiết kế với các giá trị a và b, ngay ở dưới a và b, tương ứng.

2 Nếu một điều kiện vào xác định một số các giá trị, thì các trườnghợp kiểm thử nên được xây dựng để thử cho các giá trị cực tiểu vàcực đại Các giá trị ngay trên và ngay dưới cực tiểu và cực đạicũng được kiểm thử

3 Áp dụng các hướng dẫn 1 và 2 cho các điều kiện ra Chẳng hạn,giả sử rằng bảng tương quan nhiệt độ và áp suất là cần đưa ra chomột chương trình phân tích kĩ nghệ Các trường hợp kiểm thử nênđược thiết kế để tạo ra báo cáo: làm phát sinh số các ô được phéptrong bảng tối đa (và tối thiểu)

4 Nếu các cấu trúc dữ liệu chương trình bên trong đã mô tả trướccác biên (như một mảng có một giới hạn xác định gồm 100 ô), thìphải chắc chắn thiết kế một trường hợp kiểm thử để thực hiện cấutrúc dữ liệu đó tại biên của nó

Phần lớn các kỹ sư phần mềm đều thực hiện BVA một cách trực giác ởmức độ nào đó Bằng việc áp dụng những hướng dẫn đã nêu ra ở trên, việckiểm thử biên sẽ đầy đủ hơn, do đó có nhiều khả năng để phát hiện lỗi hơn

1.2.2.3 Kỹ thuật đồ thị nhân quả

Là một kỹ thuật để thiết kế test case Nó cung cấp một biểu diễn chínhxác giữa các điều kiện logic (đầu vào) và các hành động tương ứng (đầu ra

- kết quả)

Kĩ thuật này tuân theo bốn bước:

1 Nguyên nhân (điều kiện vào) và hậu quả (hành động) được liệt kê

cho một mô đun và tên gọi được gán cho mỗi mô đun

2 Xây dựng đồ thị nhân quả

3 Đồ thị được chuyển thành bảng quyết định

4 Các qui tắc của bảng quyết định được chuyển thành các test case

Hình 1.18 Tiến trình kỹ thuật nhân quả

Dữ liệu trường hợp kiểm thử được chọn lựa sao cho mỗi qui tắc trongbảng đều được thực hiện Hiển nhiên, nếu một bảng quyết định đã được dùnglàm công cụ thiết kế thì việc tạo một đồ thị nhân quả không cần nữa

Kỹ thuật đồ thị nhân quả được xây dựng dựa trên các mô đun chức năng,logic tiến trình và đặc tả hệ thống

1.2.2.4 Kiểm thử so sánh

Có một số tình huống (như điều khiển máy bay, điều khiển ngà máy,năng lượng hạt nhân) mà trong đó độ tin cậy của phần mềm là tuyệt đối, chủchốt Trong những ứng dụng như vậy, phần cứng và phần mềm dư thừa đượcdùng để tối thiểu hóa khả năng lỗi Khi phần mềm dư thừa được phát triển,nhóm kĩ nghệ phần mềm tách biệt sẽ phát triển những bản độc lập của ứngdụng bằng cách dùng cùng đặc tả Trong những tình huống như thế, mỗi bản

có thể được kiểm thứ với cùng dữ liệu thử để đảm bảo rằng tất cả đều đưa rakết quả giống nhau Tất cả các bản đều được thực hiện song song với việc sosánh thời gian thực về kết quả để đảm bảo tính nhất quán.

Từ ý tưởng trên, các nhà nghiên cứu đã gợi ý rằng các bản độc lập củaphầm mềm được phát triển cho những ứng dụng chủ chốt, thậm chí khi chỉ cómột bản được dùng trong hệ thống được bàn giao Những bản độc lập này tạonên cơ sở cho kĩ thuật kiểm thử hộp đen được gọi là kiểm thử so sánh haykiểm thử sau lưng

Khi có nhiều cài đặt của cùng một đặc tả được tạo ra, các trường hợpkiểm thử được thiết kế để dùng những kĩ thuật hộp đen khác (như phân hoạchtương đương) cũng được áp dụng cho từng bản Nếu các kết quả của mỗi bản

là giống nhau thì người ta nhận xét rằng tất cả các cài đặt đều đúng Nếuchúng khác nhau thì từng ứng dụng sẽ được nghiên cứu lại để xác định liệurằng khiếm khuyết trong một hay nhiều bản có phải là nguyên nhân sinh ra sựkhác biệt hay không

Kiểm thử so sánh không phải là hết sức dễ dùng Nếu đặc tả mà từ đó tất

cả các bản đã xây dựng bị lỗi thì mọi bản đều có thể phản ánh lỗi đó Bêncạnh đó, nếu từng bản độc lập lại tạo ra kết quả giống nhau, nhưng khôngđúng, thì việc kiểm thử điều kiện sẽ không phát hiện được lỗi

1.2.2.5 Kiểm thử dựa trên đặc tả

Tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầuthích hợp Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đốitượng kiểm thử Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để đượccung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữ liệu đầu vào

đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn

đã được xác định trong ca kiểm thử đó hay không Kiểm thử dựa trên đặc tả làcần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn

Ưu, nhược điểm

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thửviên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi Sử dụng nguyêntắc “Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ralỗi mà những lập trình viên đã không tìm ra Nhưng, mặt khác, người ta cũngnói kiểm thử hộp đen “giống như là đi trong bóng tối mà không có đèn vậy”,bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự đượcxây dựng như thế nào Đó là lý do mà có nhiều trường hợp mà một kiểm thửviên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ

có thể chỉ cần kiểm tra bằng một ca kiểm thử duy nhất, và/hoặc một số phầncủa chương trình không được kiểm tra chút nào

Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá kháchquan”, mặt khác nó lại có nhược điểm của “thăm dò mù”

1.2.3 Kiểm thử cấu trúc (White box)

Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thửhộp đen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảosát cấu trúc bên trong của chương trình Chiến lược này xuất phát từ dữliệu kiểm thử bằng sự kiểm thử tính logic của chương trình Kiểm thửviên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình(và cả mã lệnh thực hiện chúng)

Các phương pháp kiểm thử hộp trắng:

• Kiểm thử giao diện lập trình ứng dụng - API testing (applicationprogramming interface): là phương pháp kiểm thử của ứng dụng

sử dụng các API công khai và riêng tư

• Bao phủ mã lệnh - Code coverage: tạo các kiểm tra để đáp ứngmột số tiêu chuẩn về bao phủ mã lệnh

• Các phương pháp gán lỗi - Fault injection

• Các phương pháp kiểm thử hoán chuyển - Mutation testingmethods.

• Kiểm thử tĩnh - Static testing: kiểm thử hộp trắng bao gồm mọikiểm thử tĩnh

Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá

sự hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương phápkiểm thử hộp đen Điều này cho phép các nhóm phần mềm khảo sát các phầncủa một hệ thống ít khi được kiểm tra và đảm bảo rằng những điểm chức năngquan trọng nhất đã được kiểm tra

1.2.4 Công cụ kiểm thử phần mềm

Trên thị trường hiện nay có nhiều công cụ kiểm thử phần mềm Với cácnhà cung cấp như: Rational Software của IBM, Mercury Interactives, SegueSoftware Hiện có nhiều nhà cung cấp khác và cũng có một số công cụ kiểmthử nguồn mở như Ant, JUnit, và JProbe… Sau đây là một số công cụ kiểmthử phần mềm được sử dụng phổ biến hiện nay:

Visual Studio Team System Test Edition

Hình 1.19 Mô hình tổ chức Visual Studio Team System 2008 Team

Foundation Server

Visual Studio Team System Test Edition bao gồm một bộ công cụ thửnghiệm đã được tích hợp chặt chẽ với Visual Studio Nó không chỉ làm việctrong khuôn khổ của nền tảng kiểm thử, mà còn tham gia vào một nền tảnglớn hơn tham gia vào các khâu khác trong toàn bộ vòng đời của phần mềm.Test Edition cho phép ta tạo, quản lý, chỉnh sửa và chạy công việc kiểmthử, đồng thời cũng nhận được và lưu trữ kết quả kiểm thử Visual Studio tíchhợp một vài loại thử nghiệm bao gồm: kiểm thử đơn vị (Unit Test), kiểm thửweb (Web Test), kiểm thử chịu tải (Load Test), và các kiểm thử thủ công.Người ta chạy thử nghiệm bằng cách sử dụng môi trường phát triển tíchhợp của Visual Studio (IDE Visual Studio) Ngoài ra, ta có thể chạy các nhómthử nghiệm hoặc kiểm tra bất kỳ đơn vị thử nghiệm độc lập nào khác bằngcách sử dụng dòng lệnh (command line)

Do các công cụ kiểm nghiệm được tích hợp với các thành phần khác củaVisual Studio Team System, nên ta có thể lưu trữ kết quả vào cơ sở dữ liệu,tạo ra các hình thức báo cáo khác nhau, so sánh các loại dữ liệu, và xem cóbao nhiêu lỗi, là những lỗi nào đã được tìm thấy bởi công cụ kiểm thử

Đây quả là một công cụ mạnh mẽ mà Microsoft trang bị cho bộ sảnphẩm Visual Studio của mình Với lợi thế là tích hợp chặt chẽ vào môi trườngphát triển phần mềm, công cụ sẽ giảm bớt được nhiều công sức trong quátrình thực hiện các thao tác kiểm thử, đồng thời việc quản lý nó cũng thốngnhất trong suốt quá trình phát triển phần mềm Tuy nhiên để sở hữu được bộcông cụ này thì chúng ta cũng phải bỏ ra một khoản chi phí khá lớn, vàokhoảng 5.200 USD Đồng thời chúng ta cũng phải trang bị nền tảng VisualStudio Team System 2008 Team Foundation Server (mức giá tham khảo:2.500 USD) để có thể tích hợp bộ công cụ này

QuickTest Professional

Hình 1.20 Giao diện QuickTest Professional

QuickTest Professional (QTP) với phiên bản mới nhất 9.5 của hãngMercury khá tốt và mạnh, bao gồm nhiều chức năng điển hình của một công

bổ sung bất cứ script nào Nó cũng phù hợp trong tình huống chuyển giaocông việc mà người mới tiếp nhận chưa có thời gian hoặc không hiểu scriptvẫn có thể thực hiện

QTP giúp chúng ta Kiểm Thử Phần Mềm theo hướng chức năng trên rấtnhiều loại chương trình phần mềm khác nhau Tuy nhiên Mercury chỉ hỗ trợsẵn một số loại chương trình thông dụng như: Ứng dụng Windows; Ứng dụngweb theo chuẩn HTML, XML; Ngôn ngữ lập trình C#, VB NET

Một số loại chương trình khác yêu cầu cài đặt thêm thành phần bổ sungcủa QTP thì mới thực hiện kiểm tra được, như:.NET Framework 1.1, 2.0, 3.5;Các đối tượng chuẩn của.NET và các đối tượng khác thừa kế từ các đối tượngchuẩn; Java; Sun JDK; và IBM JDK

QTP sử dụng ngôn ngữ VBScript để viết Test Script

mà không cần thay đổi bất cứ Test Script nào

• Hỗ trợ làm việc theo nhóm thông qua sự chia sẻ thư viện, thốngnhất quản lý Object Repository

• Thực tế cho thấy, QTP thực hiện Kiểm Thử Tự Động trên nhiềutrình duyệt cùng lúc tốt hơn những công cụ khác

• Với chức năng Recovery Scenarios, QTP cho phép xử lý những sựkiện hoặc lỗi không thể đoán trước có thể làm Script bị dừng trongkhi đang chạy

• QTP có khả năng hiểu Test Script của Mercury Winrunner (mộtcông cụ kiểm tra khác của Mercury)

Nhược điểm:

• Chưa hỗ trợ tốt trên nhiều nền tảng công nghệ khác nhau

• Giá thành khá cao: cho một máy 9.000 USD; cho nhiều máy dùngcùng lúc 12.000 USD

Hình 1.21 Logo JMeter

JMeter của Apache Jakarta là công cụ được phát triển bởi ngôn ngữ Javacho phép kiểm tra máy chủ Web và thêm vào đó là khả năng kiểm tra các ứngdụng với các giao thức khách như JDBC, FTP, và LDAP Thực tế, với công

cụ mở rộng và cho phép người dùng tạo ra các tình huống giả định thì ngườidùng có khả năng kiểm tra bất kỳ giao thức nào thông qua Java Với chế độmặc định nó có thể đưa ra những file CSV để dễ dàng truyền các tham số vào

cơ sở dữ liệu và đưa ra được rất nhiều thông tin hơn CSV Đây là công cụđược rất nhiều người mới vào nghề sử dụng trong vô số các công cụ khácđang có trên mạng Internet

JUnit, NUnit

JUnit là một framework đơn giản dùng cho việc tạo các Unit Testing tựđộng, và chạy các test có thể lặp đi lặp lại Nó là một phần của họ kiến trúcxUnit cho việc tạo các unit testing JUnit là một chuẩn trên thực tế cho unittesting trong Java JUnit về nguồn gốc được viết bởi 2 tác giả Erich Gamma

và Kent Beck Tương tự, NUnit là phiên bản dùng cho các sản phẩm pháttriển trên nền tảng.NET, nó có thể tích hợp với Microsoft Visual Studio

Đây là một bộ công cụ giành cho Unit Test rất hiệu quả và hoàn toànmiễn phí Tuy nhiên công cụ mới dừng ở việc kiểm thử thành phần, chưa mởrộng thêm các hình thức kiểm thử khác

Một số công cụ kiểm thử phổ biến khác

Công cụ kiểm thử thành phần (component hoặc unit test):

• QACenter - Compuware

• PurifyPlus - IBM Rational

• Tau Architect và Tau Developer - Telelogic

• C++ Test, Java Test, Insure++, và.Test - Parasoft

Công cụ kiểm thử chức năng (function test):

• WinRunner - Mercury Interactive

• QuickTest Professional - Mercury Interactive

• Astra QuickTest - Mercury Interactive

• QACenter - Compuware

• SilkTest - Segue Software

• Rational Suite TestStudio - IBM Rational

• TauTester - Telelogic

• e-Test suite - Empirix

• Webking - Parasoft

• WetFT - RadView Software

Công cụ kiểm thử chịu tải (performance/load-test):

• LoadRunner - Mercury Interactive

• Astra LoadTest - Mercury Interactive

• QACenter - Compuware

• WebLoad - RadView Software

• Rational Suite TestStudio - IBM Rational

• SilkPerformer - Segue

• e-Test suite - Empirix

• webking - Parasoft

• Test Perspective - Keynote Systems

• LoadPro - Keynote Systems

Công cụ theo dõi thực thi (performance-monitoring):

• Vantage - Compuware

• Topaz - Mercury Interactive

• OneSight - Empirix

• FarSight - Empirix

• Rational Suite TestStudio - IBM Rational

Công cụ quản lý kiểm thử (test-management):

• QA Director - Compuware

• TestDirector - Mercury Interactive

• Rational Suite TestStudio - IBM Rational

• SilkPlan Pro - Segue

Với tư cách là một người làm việc trực tiếp trong lĩnh vực sản xuất phầnmềm và là người nghiên cứu Luận văn này, tôi đã đánh giá cao những khảnăng tuyệt vời của các công cụ kiểm thử hiện có, mặc dù tính tự động và hiệuquả của chúng chưa được như mong muốn Những hạn chế trong các công cụđược thương mại hóa là thường không theo kịp với các thay đổi của côngnghệ và khó thích ứng với quá trình thiết kế mới trong các ngành công nghiệpphần mềm Trong luận văn này, tôi sẽ nghiên cứu đề xuất nâng cấp các cơ sở

hạ tầng kiểm thử để tránh được những hạn chế này

Chương 2 KIỂM THỬ TÍCH HỢP TRÊN CƠ SỞ CÁC MÔ HÌNH UML

2.1 Phương pháp

2.1.1 Mô hình kiểm thử phần mềm dựa trên thành phần

Khi kiểm thử một hệ thống phần mềm dựa trên thành phần, chúng ta giả

sử mỗi thành phần riêng biệt là đã được kiểm thử đầy đủ Vì vậy đảm bảochính xác sự tương tác giữa các thành phần là chìa khóa thành công của hệthống phần mềm đáng tin cậy

Các thành phần có thể tương tác với các thành phần khác trực tiếphoặc gián tiếp Tương tác trực tiếp bao gồm các lời gọi của các giao tiếptiếp xúc với các thành phần hoặc hành động người dùng kích hoạt sự kiện.Tương tác gián tiếp là thông qua chuỗi các sự kiện Sau đây là bốn yếu tốchính xác định mô hình các đặc trưng của sự tương tác mà cần tham giavào kiểm thử thành phần

Giao tiếp (Interfaces): Giao tiếp là cách phổ biến nhất để kích hoạt các

thành phần Vì vậy, nó là cần thiết trong kiểm thử hệ thống và kiểm thử tíchhợp để kiểm tra mỗi giao tiếp trong môi trường tích hợp ít nhất một lần

Sự kiện (Events): Kiểm tra các giao tiếp cung cấp tin tưởng rằng mỗi

giao diện là có thể được gọi trong thời gian chạy đã được thực hiện ít nhấtmột lần kịch bản này tương tự như các tiêu chí kiểm thử truyền thống đòi hỏitất cả chức năng hoặc thủ tục được kiểm thử ít nhất một lần Tuy nhiên mộtgiao diện được gọi bởi các thành phần khác nhau trong ngữ cảnh khác nhau

có thể có kết quả khác nhau Vì vậy để quan sát các hành vi của mỗi giao tiếptrong thời gian chạy, mọi lời gọi của giao tiếp cần được kiểm tra ít nhất mộtlần Hơn nữa, mỗi sự kiện mà không kích hoạt thông qua giao diện có thể tácđộng vào thành phần mà cần phải được kiểm tra Vì vậy mỗi sự kiện trong hệthống bất kể các loại cần được bao phủ bởi một số kiểm thử