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

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 đồ trạng thái cho đối tượng phụ tùng trong hệ thống xử lý đặt hàng

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

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

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

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

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

Black box Hộp đen

BVA boundary value analysis

CNTT Công nghệ thông tin

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

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

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ũ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

Chương 1 MỘT SỐ KHÁI NIỆM CƠ BẢN VỀ THIẾT KẾ PHẦN MỀM

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

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

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ê

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

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

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

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

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ó

18

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ác trường hợp mà chương trình không thực hiện theo các đặc tả của nó Theo hướ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ừng lớ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ợp kiểm thử trước khi phát hiện ra lỗi chung Phân hoạch tương đương cố gắng xá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ảm tổ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ựa cá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ủa mộ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ên củ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ới phâ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ường hợ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 đại cũ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 cho mộ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ép trong 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ước cá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ấu trú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ệc kiể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ính xá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ả)

20

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 trong bảng đều được thực hiện Hiển nhiên, nếu một bảng quyết định đã được dùng là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 được dù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 ứng dụ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 ra kết quả giống nhau Tất cả các bản đều được thực hiện song song với việc so sá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ủa phầ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ạo nên cơ sở cho kĩ thuật kiểm thử hộp đen được gọi là kiểm thử so sánh hay kiể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ợp kiểm thử được thiết kế để dùng những kĩ thuật hộp đen khác (như phân hoạch tươ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ếu chúng khác nhau thì từng ứng dụng sẽ được nghiên cứu lại để xác định liệu rằ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ên cạ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ầu thí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ừ đối tượ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 để được cung 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

22

Ư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ên tắ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 ra lỗ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ũng nó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ự được xâ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ần củ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ách quan”, 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ảo sá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 (application programming 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 ứng mộ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 testing methods

Kiểm thử tĩnh - Static testing: kiểm thử hộp trắng bao gồm mọi kiể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áp kiể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ần củ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ăng quan 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ác nhà cung cấp như: Rational Software của IBM, Mercury Interactives, Segue Software Hiện có nhiều nhà cung cấp khác và cũng có một số công cụ kiểm thử nguồn mở như Ant, JUnit, và JProbe… Sau đây là một số công cụ kiểm thử 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

24

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ệc trong khuôn khổ của nền tảng kiểm thử, mà còn tham gia vào một nền tảng lớ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ểm thử, đồng thời cũng nhận được và lưu trữ kết quả kiểm thử Visual Studio tích hợ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ích hợp của Visual Studio (IDE Visual Studio) Ngoài ra, ta có thể chạy các nhóm thử nghiệm hoặc kiểm tra bất kỳ đơn vị thử nghiệm độc lập nào khác bằng cá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ủa Visual 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ản phẩ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ường phá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ống nhấ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ào khoảng 5.200 USD Đồng thời chúng ta cũng phải trang bị nền tảng Visual Studio 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ãng Mercury 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 giao công việc mà người mới tiếp nhận chưa có thời gian hoặc không hiểu script vẫ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ất nhiề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ụng web theo chuẩn HTML, XML; Ngôn ngữ lập trình C#, VB NET

26

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ổ sung củ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ượng chuẩ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ống nhấ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ều trì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 trong khi đang chạy

QTP có khả năng hiểu Test Script của Mercury Winrunner (một cô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ùng cùng lúc 12.000 USD

JMeter

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ữ Java cho phép kiểm tra máy chủ Web và thêm vào đó là khả năng kiểm tra các ứng dụ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ười dù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úc xUnit cho việc tạo các unit testing JUnit là một chuẩn trên thực tế cho unit testing 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át triể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àn miễ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

28

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ần mề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ệu quả 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ông nghệ và khó thích ứng với quá trình thiết kế mới trong các ngành công nghiệp phầ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

30

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ảo chí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ếp hoặ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ếp tiế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 gia và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ích hợ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ất mộ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ỏi tấ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ột giao 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ếp trong 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ột lầ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ử