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

Trong phát triển phần mềm hướng mô hình, các nhà thực hành cũng sử dụng các mô hình thiết kế cho việc kiểm thử phần mềm, đặc biệt là những chương trình hướng đối tượng.. Có ba lý do chín

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THỊ BÍCH HÀ

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

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

HÀ NỘI - 2015

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THỊ BÍCH HÀ

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

Ngành : Công nghệ thông tin Chuyên ngành : Kỹ thuật phần mềm

Mã số : 60480103

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

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

HÀ NỘI - 2015

LỜI CAM ĐOAN

Tôi xin cam đoan những kết quả đạt được trong luận văn này là do tôi nghiên cứu, sưu tầm, tổng hợp và sắp xếp lại phù hợp với yêu cầu của luận văn Toàn bộ những điều được trình bày trong khóa luận hoặc là của cá nhân, hoặc được tham khảo

và tổng hợp từ các nguồn tài liệu khác nhau Tất cả tài liệu tham khảo, tổng hợp đều được trích dẫn với nguồn gốc rõ ràng

Toàn bộ chương trình, mã nguồn là do tôi thiết kế và xây dựng, không sao chép của bất kỳ ai và chưa được công bố trên bất kỳ phương tiện nào

Tôi xin chịu hoàn toàn trách nhiệm về lời cam đoan của mình Nếu có điều gì sai trái, tôi xin chịu mọi hình thức kỷ luật theo qui định

Hà Nội, tháng năm

Học viên Nguyễn Thị Bích Hà

LỜI CẢM ƠN

Lời đầu tiên, tôi xin bày tỏ lòng biết ơn chân thành đến các thầy cô giáo khoa Công nghệ Thông tin, Đại học Công Nghệ, Đại học Quốc Gia Hà Nội đã tận tình truyền đạt kiến thức và động viên giúp đỡ tôi trong học tập tại trường

Đặc biệt, tôi muốn gửi lời cảm ơn sâu sắc đến thầy giáo, phó giáo sư, tiến sĩ Trương Ninh Thuận, người đã tận tình chỉ bảo, hướng dẫn tôi trong suốt quá trình nghiên cứu và hoàn thiện luận văn tốt nghiệp

Tôi cũng xin cảm ơn bạn bè, các đồng nghiệp và nhất là các thành viên trong gia đình đã tạo mọi điều kiện tốt nhất, động viên, cổ vũ trong suốt quá trình học tập và làm luận văn tốt nghiệp

Hà Nội, ngày tháng năm

Học viên

iii

MỤC LỤC

LỜI CAM ĐOAN i

LỜI CẢM ƠN ii

BẢNG CÁC CHỮ VIẾT TẮT iv

DANH MỤC CÁC HÌNH VẼ VÀ CÁC BẢNG v

CHƯƠNG 1:TỔNG QUAN 1

1.1 Đặt vấn đề 1

1.2 Tổng quan tình hình nghiên cứu 2

1.3 Nội dung nghiên cứu 3

1.4 Cấu trúc khóa luận 3

CHƯƠNG 2: KIẾN THỨC CHUNG 5

2.1 Kiểm thử phần mềm 5

2.1.1 Các khái niệm kiểm thử phần mềm 5

2.1.2 Mức kiểm thử 7

2.2 Giới thiệu ngôn ngữ UML 12

2.2.1 Biểu đồ trạng thái 15

2.2.2 Biểu đồ tuần tự 16

2.2.3 Đồ thị tuần tự 18

CHƯƠNG 3: PHƯƠNG PHÁP SINH CA KIỂM THỬ TỪ BIỂU ĐỒ TUẦN TỰ VÀ BIỂU ĐỒ TRẠNG THÁI 20

3.1 Phương pháp thực hiện 20

3.2 Ví dụ minh họa 22

3.3 Cài đặt thử nghiệm 27

3.3.1 Giới thiệu về Modelio 28

3.3.2 Các bước tạo một module cho Modelio 29

3.3.3 Các thuật toán áp dụng 36

3.3.3.1 Thuật toán chuyển từ biểu đồ tuần tự sang đồ thị tuần tự 36

3.3.3.2 Thuật toán duyệt đồ thị tuần tự xác định test path 40

3.3.3.3 Kết hợp biểu đồ trạng thái vào các test path 41

3.3.4 Kết quả cài đặt thử nghiệm 42

CHƯƠNG 4: KẾT LUẬN 44

4.1 Các kết quả đạt được và hạn chế 44

4.2 Các công việc trong tương lai 44

TÀI LIỆU THAM KHẢO 45

BẢNG CÁC CHỮ VIẾT TẮT

Chữ viết

tắt

Cách viết đầy đủ Dịch nghĩa Tiếng Việt

UML Unified Modeling Language Ngôn ngữ mô hình hóa thống nhất BPMN Business Process Modeling Notaion Hệ thống ký hiệu mô hình hoá tiến

trình nghiệp vụ SysML System Modeling Language Ngôn ngữ mô hình hoá hệ thống SoaML Service Oriented Architecture

DANH MỤC CÁC HÌNH VẼ VÀ CÁC BẢNG

Hình 2.1: Quy trình kiểm thử phần mềm 6

Hình 2.2: Các hướng nhìn trong UML 12

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

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

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

Hình 2.6: Ví dụ biểu đồ tuần tự 17

Hình 2.7: Biểu đồ tuần tự 18

Hình 2.8: Đồ thị tuần tự tương ứng của hình 2.7 19

Hình 3.1: Các bước cơ bản sinh ca kiểm thử 21

Hình 3.2: Sơ đồ use case của hệ thống máy rút tiền ATM từ góc nhìn người sử dụng 22

Hình 3.3: Biểu đồ tuần tự chức năng rút tiền 24

Hình 3.4: Biểu đồ trạng thái máy ATM chức năng rút tiền 25

Hình 3.5: Đồ thị tuần tự của chức năng rút tiền 26

Hình 3.6: Kết hợp đồ thị tuần tự và biểu đồ trạng thái 26

Bảng 3.1: Kết quả danh sách các ca kiểm thử theo định nghĩa 27

Bảng 3.2: Các đặc điểm chính của Modelio 29

Hình 3.7: Tạo mới Maven Project 30

Hình 3.8 Thêm Archetype Catalog của Modelio 31

Hình 3.9: Chọn Archetypes tương ứng với bản Modelio 32

Hình 3.10: Tạo Modelio Module 33

Hình 3.11: Debug Configuration 34

Hình 3.12: Triển khai module 35

Hình 3.13: Chọn file jmdac 35

Hình 3.14: Giao diện Config/ Module Catalog 36

Bảng 3.3: Bảng mô tả quá trình duyệt các phần từ trong danh sách Interaction Fragment 39

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

Một trong những bài toán quan trọng nhất trong nghiên cứu kiểm thử phần mềm

đó là sinh các ca kiểm thử, việc thiết kế các ca kiểm thử và thực hiện chúng đều tốn thời gian và công sức Thiết kế kịch bản kiểm thử bằng cách thủ công rất tốn thời gian

và dễ gặp lỗi Do vậy, việc nghiên cứu các kỹ thuật để sinh tự động các kịch bản kiểm thử là rất cần thiết

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

ra, kiểm thử viên sẽ tìm được những điểm không nhất quán, những nhập nhằng trong đặc tả và thiết kế, cho phép có thể cải thiện đặc tả và thiết kế trước khi chương trình được viết ra Một lợi điểm khác là những dữ liệu dùng để kiểm tra là độc lập với các cài đặt (tức là độc lập với mã nguồn) Việc tự động hóa tiến trình sinh ca kiểm thử sẽ rút ngắn được thời gian và công sức của các kiểm thử viên, cải thiện kết quả của quá trình kiểm thử Hầu hết các yêu cầu và những thiết kế mức cao của phần mềm được tài liệu hóa bằng các mô hình Những mô hình này có thể được sử dụng cho quá trình sinh

ca kiểm thử bằng công cụ tự động

2

Phát triển phần mềm hướng mô hình là một luận thuyết phát triển phần mềm Lợi điểm của nó là hỗ trợ trực quan hóa các miền ứng dụng, các giải pháp Trong phát triển phần mềm hướng mô hình, các nhà thực hành cũng sử dụng các mô hình thiết kế cho việc kiểm thử phần mềm, đặc biệt là những chương trình hướng đối tượng Có ba

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

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

đồ tuần tự và biểu đồ trạng thái UML

1.2 Tổng quan tình hình nghiên cứu

Cách tiếp cận sử dụng các biểu đồ UML để sinh ca kiểm thử tự động có thể kể đến một số nghiên cứu như sau:

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

Sharma [7] chuyển đổi một biểu đồ ca sử dụng thành đồ thị ca sử dụng, chuyển biểu đồ tuần tự thành một đồ thị gọi là đồ thị biểu đồ tuần tự, sau đó tích hợp hai đồ thị này thành đồ thị kiểm thử hệ thống, duyệt đồ thị kiểm thử hệ thống để sinh các ca kiểm thử

1.3 Nội dung nghiên cứu

Nội dung nghiên cứu của luận văn bao gồm: Nghiên cứu tổng quan về kiểm thử phần mềm, các phương pháp kiểm thử cơ bản Nghiên cứu tổng quan về UML, đặc biệt biểu đồ tuần tự và biểu đồ trạng thái là hai loại biểu đồ được sử dụng để sinh ca kểm thử trong luận văn này

Luận văn trình bày kỹ thuật sinh ca kiểm thử từ biểu đồ trạng thái và biểu đồ tuần tự có kèm theo ví dụ minh họa, các thuật toán áp dụng trong phần demo của chương trình

1.4 Cấu trúc khóa luận

Khóa luận được tổ chức thành bốn chương như sau:

Chương 1: Mở đầu

Chương một nêu lên sự cần thiết, ý nghĩa thực tiễn, mục tiêu của đề tài “Sinh ca kiểm thử từ các biểu đồ UML” mà cụ thể là từ biểu đồ trạng thái và biểu đồ tuần tự UML

Chương 2: Kiến thức chung

4

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

Chương 3: Phương pháp sinh ca kiểm thử từ biểu đồ tuần tự và biểu đồ trạng thái

Chương ba trình bày phương pháp sinh ca kiểm thử từ biểu đồ tuần tự và biểu

đồ trạng thái UML, đưa ra ví dụ minh họa từng bước thực hiện cho phương pháp Chương này cũng trình bày về ý tưởng, phân tích và xây dựng công cụ sinh ca kiểm thử tự động từ biểu đồ tuần tự và biểu đồ trạng thái UML, trình bày các thuật toán đã

áp dụng trong việc xây dựng công cụ

Chương 4: Kết luận

Chương bốn đưa kết luận về các nội dung đã đạt được trong luận văn, các mặt hạn chế và hướng phát triển trong tương lai của luận văn

5

CHƯƠNG 2: KIẾN THỨC CHUNG 2.1 Kiểm thử phần mềm

2.1.1 Các khái niệm kiểm thử phần mềm

Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai, nhằm cung cấp những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm đó Hoạt động kiểm thử phần mềm nhằm đánh giá chất lượng hoặc tính chấp nhận được của sản phẩm Kiểm thử với mục đích phát hiện lỗi hoặc bất cứ vấn đề gì của sản phẩm Có thể định nghĩa một cách dễ hiểu: Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã được thiết

kế để làm, không thực hiện bất cứ thứ gì không mong muốn

Trong kiểm thử phần mềm các thuật ngữ hay sử dụng như lỗi, sai, thất bại, sự

cố, chúng ta sẽ phân biệt các khái niệm này

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

· Sai (Fault): Là kết quả của lỗi, từ lỗi sẽ dẫn đến sai, có thể phân thành 2 loại như sau:

o Sai sót do đưa ra thừa: Đưa các thông tin không chính xác vào mô tả yêu cầu phần mềm

o Sai do bỏ sót: Khi người thiết kế thiếu một số phần đáng ra phải có trong

mô tả yêu cầu phần mềm

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

· Sự cố (Incident): Là những kết quả do sai sót mang đến, khi thất bại xuất hiện,

nó có thể hiển thị hoặc không hiển thị đối với người dùng, tức là rõ ràng hay không rõ ràng đối với người dùng hoặc kiểm thử viên Sự cố thể hiện bên ngoài cho người dùng biết về sự tồn tại của thất bại

Việc kiểm thử phần mềm được thực hiện lần lượt các bước theo quy trình, hình

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

6

Hình 2.1: Quy trình kiểm thử phần mềm

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

Dựa vào đặc tả phần mềm để thiết kế các ca kiểm thử Dựa vào các ca kiểm thử đã viết

tiến hành tạo ra các dữ liệu kiểm tra, sau đó chạy chương trình theo kịch bản kèm theo

dữ liệu kiểm tra Kết quả kiểm tra sẽ được so sánh với đầu ra mong muốn trong kịch

bản đã tạo Lần lượt các thực hiện các ca kiểm thử, kết quả của mỗi ca kiểm thử là

pass hoặc fail, kết quả cuối cùng ta có là báo cáo kết quả kiểm thử (test report)

Quá trình thực hiện kiểm thử phần mềm sẽ sử dụng quy trình kiểm chứng và

thẩm định chất lượng phần mềm Quy trình kiểm chứng đảm bảo phần mềm được xây

dựng theo đúng đặc tả ban đầu, quy trình thẩm định đảm bảo phần mềm đáp ứng được

yêu cầu của khách hàng Trong thực tế, quy trình kiểm chứng phần mềm được áp dụng

trước quy trình thẩm định để đảm bảo phần mềm sau khi xây dựng đúng với thiết kế

ban đầu và thỏa mãn được yêu cầu của người dùng

Kiểm thử phần mềm có thể chia làm 2 nhóm kỹ thuật chính: Kỹ thuật kiểm thử

tĩnh và kỹ thuật kiểm thử động [1]

· Kiểm thử tĩnh không đòi hỏi phải chạy chương trình Kỹ thuật kiểm thử tĩnh

được tiến hành dựa trên việc khảo sát các tài liệu được xây dựng trong quá trình

phát triển như tài liệu đặc tả nhu cầu người dùng, mô hình phần mềm, mã nguồn

phần mềm để tìm ra lỗi Ngoài ra ta có thể sử dụng các kỹ thuật phân tích hình

thức như kiểm chứng mô hình, chứng minh định lý để chứng minh tính đúng

7

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

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

2.1.2 Mức kiểm thử

Dựa trên các công đoạn phát triển phần mềm mà người ta chia thành các mức độ kiểm thử khác nhau: Kiểm thử mức đơn vị, kiểm thử mức tích hợp, kiểm thử mức hệ thống, kiểm thử mức chấp nhận

Kiểm thử mức đơn vị (Unit test):

Là kiểm thử ở mức độ thấp nhất Việc kiểm thử được thực hiện đối với các đơn

vị chương trình (các phương thức, hàm, lớp trong mã nguồn) một cách độc lập Mục đích của kiểm thử đơn vị là bảo đảm thông tin được xử lý và xuất khỏi đơn vị là chính xác trong mối tương quan với dữ liệu nhập và chức năng của đơn vị Điều này thường đòi hỏi tất cả các nhánh bên trong đơn vị đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi Một nhánh thường là một chuỗi các lệnh được thực thi trong một đơn vị (Ví dụ: Chuỗi các lệnh sau điều kiện If và nằm giữa then else là một nhánh) nhằm đảm bảo các thành phần trên hoạt động đúng như yêu cầu Kiểm thử đơn vị thường được làm bởi chính các lập trình viên viết chương trình

Cùng với các mức kiểm thử khác, kiểm thử đơn vị cũng đòi hỏi phải chuẩn bị trước các ca kiểm thử, trong đó chỉ định rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn Ưu điểm của kiểm thử mức đơn vị là giúp người thực hiện dễ xác định và sửa lỗi do phạm vi kiểm thử nhỏ Việc phát hiện lỗi sớm làm giảm chi phí kiểm thử so với việc phát hiện lỗi muộn ở các giai đoạn phát triển sau Tuy nhiên, kiểm thử mức đơn vị có nhược điểm là tốn thời gian, công sức thực hiện và không phát hiện các lỗi xảy ra khi các đơn vị được tích hợp với nhau

Kiểm thử mức tích hợp:

8

Mức kế tiếp với kiểm thử đơn vị là kiểm thử tích hợp Sau khi các đơn vị chương trình để cấu thành hệ thống đã được kiểm thử, chúng cần được kết nối với nhau để tạo thành hệ thống đầy đủ và có thể làm việc Kiểm thử tích hợp nhằm xem xét các vấn đề có thể xảy ra khi hai hoặc nhiều thành phần (component, module) của

hệ thống tương tác với nhau

Hai mục tiêu chính của kiểm thử tích hợp là: Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị Tích hợp các thành phần đơn lẻ thành các hệ thống nhỏ (Subsystem) và hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống

Có 4 loại kiểm thử trong kiểm thử tích hợp:

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

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

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

· Kiểm thử khả năng chịu tải của hệ thống: Là hình thức kiểm thử được sử dụng

để xác định tính ổn định của một hệ thống, kiểm thử các giới hạn của hệ thống, đánh giá hiệu năng của hệ thống với một mức tải được định nghĩa trước

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

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

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

Điểm khác nhau giữa kiểm thử tích hợp và kiểm thử hệ thống là kiểm thử hệ thống chú trọng các hành vi và lỗi trên toàn hệ thống trong khi kiểm thử tích hợp lại chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau Thông thường ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để bảo đảm mọi đơn vị và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện kiểm tra trên toàn hệ thống

Các loại kiểm thử trong mức kiểm thử hệ thống [9]

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

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

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

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

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

· Kiểm thử khả năng mở rộng (Scalability test): Xác định giới hạn mà hệ thống

có thể mở rộng: về tài nguyên, số lượng truy cập

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

· Kiểm thử khả năng ổn định quá tải (Load and stability test): Kiểm tra khả năng

hệ thống có thể hoạt động ổn định trong thời gian quá tải kéo dài hay không

· Kiểm tra khả năng phục hồi (Recovery test): Kiểm tra nhằm bảo đảm hệ thống

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

Kiểm thử mức chấp nhận

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

xử lý Sau khi khách hàng kết thúc quá trình kiểm thử, nếu phần mềm được chấp nhận

nó sẽ được triển khai đưa vào sử dụng

Kiểm thử hồi quy

Trong quá trình phát triển phần mềm, nếu có sự thay đổi về yêu cầu chức năng, quy trình xử lý hay mã nguồn đòi hỏi kiểm tra lại chương trình phần mềm nhằm đảm bảo chương trình vẫn hoạt động tốt và không phát sinh lỗi

Thông thường, những hồi quy xảy ra khi thay đổi chương trình, một phần mới của phần mềm được phát triển xung đột với mã tồn tại trước đó Phương pháp phổ biến của kiểm thử hồi quy bao gồm chạy lại những kiểm thử trước đó và kiểm thử xem lỗi trước đây có xuất hiện lại không Kiểm thử hồi quy không phải là một mức độ kiểm

Kiểm thử hộp đen là phương pháp kiểm thử hoàn toàn không quan tâm về cách

cư xử, cấu trúc, thuật toán hay mã nguồn bên trong của chương trình Người thực hiện kiểm thử chỉ thao tác với các chức năng mà chương trình cung cấp, kiểm tra việc đưa

dữ liệu đầu vào và dữ liệu đầu ra tương ứng có đúng không

Ưu điểm của kiểm thử hộp đen là không yêu cầu người kiểm thử phải biết lập trình, do không phụ thuộc vào thuật toán cài đặt nên nếu có sự thay đổi về mã nguồn kiểm thử viên vẫn có thể sử dụng lại các ca kiểm thử đã xây dựng trước đó Tuy nhiên nhược điểm của kiểm thử hộp đen là khó khăn trong việc kiểm thử đầy đủ với bộ các giá trị đầu vào Ngoài ra phương pháp này chỉ phát hiện ra các lỗi có thể quan sát được, nếu có lỗi cũng không chỉ ra được vị trí và nguyên nhân gây ra lỗi

Kiểm thử hộp trắng

Kiểm thử hộp trắng là phương pháp kiểm thử dựa vào cấu trúc, thuật toán bên trong chương trình để xác định chương trình có lỗi không Người thực hiện kiểm thử phải có kiến thức về lập trình và hiểu được cấu trúc chương trình đang kiểm thử

Kiểm thử hộp trắng được chia làm 2 loại: Kiểm thử hộp trắng động và kiểm thử hộp trắng tĩnh Kiểm thử hộp trắng tĩnh là khảo sát thiết kế và mã nguồn của chương trình

để tìm lỗi mà không cần thực thi phần mềm Kiểm thử hộp trắng động là sử dụng các

kỹ thuật kiểm thử luồng điều kiện, kiểm thử luồng dữ liệu động và kiểm thử miền

Ưu điểm của kiểm thử hộp trắng là đảm bảo các câu lệnh được thực thi ít nhất một lần, tránh các lỗi tiềm ẩn và tối ưu được mã nguồn Tuy nhiên nhược điểm của phương pháp này là tốn chi phí, thời gian khi áp dụng do yêu cầu kỹ thuật phức tạp

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

2.2 Giới thiệu ngôn ngữ UML

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

Các thành phần chủ yếu của ngôn ngữ UML:

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

Hình 2.2: Các hướng nhìn trong UML

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

sử dụng

o Hướng nhìn logic (Logic view): Chỉ ra chức năng sẽ được thiết kế bên trong hệ thống như thế nào, qua các khái niệm về cấu trúc tĩnh cũng như ứng xử của hệ thống Hướng nhìn logic được sử dụng cho các nhà thiết kế

và nhà phát triển Nó miêu tả cấu trúc tĩnh (lớp, đối tượng, các quan hệ) cũng như sự tác động sẽ xảy ra khi đối tượng gửi thông điệp cho nhau để cung cấp chức năng đã định sẵn

Cấu trúc tĩnh được miêu tả bằng biểu đồ lớp, biểu đồ đối tượng Quá trình

mô hình hóa động được miêu tả trong biểu đồ trạng thái, biểu đồ trình tự, biểu đồ tương tác và biểu đồ hoạt động

o Hướng nhìn thành phần (Component view): Chỉ ra khía cạnh tổ chức của các thành phần mã nguồn, miêu tả việc thực thi các module cũng như sự phụ thuộc giữa chúng với nhau Nó thường được sử dụng cho các nhà phát triển

o Hướng nhìn song song (Concurrent view): Chỉ ra sự tồn tại song song/ trùng hợp trong hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa trong hệ thống Hướng nhìn song song nhằm tới việc chia hệ thống thành các quy trình (process) và các bộ xử lý (processor) Khía cạnh này vốn là một thuộc tính phi chức năng của hệ thống, cho phép chúng ta sử dụng một cách hữu hiệu các nguồn tài nguyên, thực thi song song cũng như xử

lý các sự kiện không đồng bộ từ môi trường, quan tâm đến vấn đề giao tiếp và đồng bộ giữa các tiến trình

o Hướng nhìn triển khai (Deployment view): Chỉ ra khía cạnh triển khai hệ thống vào các kiến trúc vật lý, chỉ cho chúng ta sơ đồ triển khai về mặt vật

lý của hệ thống Hướng nhìn triển khai dùng cho các đội ngũ phát triển, người tích hợp, những người thử nghiệm hệ thống và được thể hiện bằng các biểu đồ triển khai Hướng nhìn này cũng bao gồm sự ánh xạ các thành phần của hệ thống vào kiến trúc vật lý, ví dụ chương trình nào hay đối tượng nào sẽ được thực thi trên máy tính nào

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

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

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

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

ý nghĩa và một kí hiệu

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

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

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

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

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

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

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

2.2.1 Biểu đồ trạng thái

Biểu đồ trạng thái mô tả chu kì tồn tại của đối tượng từ khi nó sinh ra đến khi

nó bị phá hủy Biểu đồ trạng thái được sử dụng để mô hình hóa các khía cạnh động của lớp, bao gồm các thông tin: Các trạng thái của đối tượng, hành vi của đối tượng và sự kiện tác động làm thay đổi trạng thái

Thông thường biểu đồ trạng thái không được vẽ cho tất cả các lớp, mà chỉ được

vẽ riêng cho những lớp có các trạng thái được định nghĩa rõ ràng, các hành vi của lớp

bị ảnh hưởng và thay đổi qua các trạng thái khác nhau Biểu đồ trạng thái cũng có thể được vẽ cho hệ thống tổng thể

Biểu đồ trạng thái giúp cho những người thiết kế, phân tích hệ thống và người

sử dụng biết được hành vi đối tượng, giúp đội ngũ phát triển hiểu và cài đặt chương trình

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

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

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

thái sẽ được chuyển từ Running sang Idle

2.2.2 Biểu đồ tuần tự

Biểu đồ tuần tự là một trong các loại biểu đồ UML Các biểu đồ tuần tự là các

biểu đồ căn bản cho việc mô hình hóa các phương diện hành vi của một hệ thống [8],

đặc biệt phù hợp với các phần mềm hướng đối tượng, nơi chúng có thể biểu diễn các

luồng điều khiển trong các tương tác của các đối tượng Biểu đồ tuần tự chỉ ra các đối

tượng tham gia vào quá trình tương tác, thời gian sống của từng đối tượng và trình tự

các thông điệp được trao đổi Do vậy, nó thường được sử dụng như một mô hình giải

thích cho kịch bản ca sử dụng

Các biểu đồ tuần tự chứa một loạt các đối tượng được biểu diễn bằng các đường

thẳng đứng Trục thời gian có hướng từ trên xuống dưới trong biểu đồ, biểu đồ chỉ ra

sự trao đổi thông điệp giữa các đối tượng khi thời gian trôi qua Các thông điệp được

biểu diễn bằng đường gạch ngang gắn liền với mũi tên (biểu thị thông điệp) nối liền

giữa những đường thẳng đứng thể hiện đối tượng Trục thời gian và lời nhận xét khác

thường được đưa vào phần lề của biểu đồ

Biểu đồ tuần tự có thể cũng chứa các thông tin thêm về luồng điều kiển trong

các tương tác, như các điều kiện, vòng lặp hoặc các hành vi phụ thuộc trạng thái [10]

UML 2.0 đã đề xuất một tập các tính năng mới cho các biểu đồ tuần tự, một vài tính

năng mới được biểu diễn trong ví dụ dưới

Hình 2.6: Ví dụ biểu đồ tuần tự

Biểu đồ trên mô tả sự tương tác giữa các đối tượng O1, O2, O3, mỗi tương tác

là một chuỗi các thông điệp giữa các đối tượng để thực hiện một nhiệm vụ cụ thể Các

sự kiện được sắp xếp theo lifeline Một thông điệp có hai loại sự kiện phát sinh: Sự

kiện gửi và sự kiện nhận Sự kiện gửi nằm ở gốc của mũi tên thông điệp nơi thông điệp rời đường lifeline của đối tượng gửi, sự kiện nhận nằm ở đầu mũi tên thông điệp nơi mũi tên đến lifeline của đối tượng nhận

Mỗi CombinedFragment có một toán tử tương tác (Interaction Operator) sẽ định nghĩa số lượng toán hạng tương tác cho phép (Interaction Operand) và cách thức thông điệp trong CombinedFragment được đối xử Hình 2.6 ví dụ một CombinedFragment với toán tử alt Mỗi toán hạng tương tác mô tả một cơ chế nhóm bên trong CombinedFragment Các toán hạng tương tác là tính năng tương tự với các tương tác, ngoại trừ việc chúng là một phần của Combinedfragment Hình 2.6 toán tử alt có 2 toán hạng tương tác Mỗi toán tử tương tác định nghĩa cách thức sử dụng các toán hạng tương tác trong văn cảnh của Combined Fragment Có thể kể đến các toán tử tương tác cơ bản như: Alternative (alt), option(opt), break, parallel (par), weak sequence (seq), strict sequence(strict), negative(neg), critical region(region), ignore/consider(ignore/consider), assertiong(assert), và loop

· Alternative: Cung cấp các lựa chọn đa dạng, tại đầu ra chỉ một lựa chọn được thực hiện, các toán hạng tương tác được đánh giá trên các tiêu chí cụ thể Nếu một tiêu chí được đánh giá là TRUE khi và chỉ khi tất cả các tiêu chí khác của các toán hạng tương tác khác được đánh giá là FALSE Alternative giống mô hình của cấu trúc If … then …else

· Option: Định nghĩa các phân đoạn tương tác tùy chọn Mô hình của opt giống với alt nhưng chỉ có một tương tác duy nhất

· Break: Là dạng tắt của alt, một tiến trình thực thi một tương tác, nếu tiêu chí của break được thỏa mãn, thì tương tác sẽ loại bỏ thực thi bình thường của nó

và thay vào đó sẽ thực thi các mệnh lệnh đặc tả bởi break

· Parrallel: Hỗ trợ thực thi song song một tập các toán hạng tương tác

· Loop: Biểu thị toán hạng thực thi lặp đi lặp lại và bao gồm các điều kiện để kết thúc vòng lặp

2.2.3 Đồ thị tuần tự

Đồ thị tuần tự G(N, E) trong đó N là tập hợp các nút của đồ thị, E là tập hợp các cạnh Mỗi nút trên đồ thị biểu diễn một thông điệp chuyển giữa hai đối tượng hoặc điều kiện trong biểu đồ tuần tự Mỗi cạnh trên đồ thị xuất hiện khi có một thông điệp tương ứng xảy ra ngay sau thông điệp khác theo trình tự thời gian Đỉnh của thông điệp khởi tạo một kịch bản được gọi là gốc của đồ thị, các đỉnh lá tương ứng là kết thúc trong tuần tự các thông điệp

Ví dụ biểu đồ tuần tự ở hình 2.7 được chuyển sang đồ thị tuần tự tương ứng trong hình 2.8 như sau:

Hình 2.7: Biểu đồ tuần tự